このドキュメントでは、Google Cloud でコンピューティング リソースを使用するように既存のオンプレミス レンダー ファームを拡張する方法について説明します。このドキュメントでは、お客様がオンプレミスでレンダー ファームをすでに実装しており、ビジュアル エフェクト（VFX）とアニメーション パイプラインの基本コンセプト、キュー管理ソフトウェア、および一般的なソフトウェア ライセンス方式に精通していることを前提としています。
概要
アニメーション、映画、コマーシャル、またはビデオゲーム用の 2D 要素や 3D 要素をレンダリングする作業には多くのコンピューティングと時間が必要です。これらの要素のレンダリングには、ハードウェアとインフラストラクチャへの多額の投資が必要なだけでなく、ハードウェアとソフトウェアのデプロイとメンテナンスを担当する専任の IT プロフェッショナル チームが必要になります。
オンプレミス レンダー ファームの利用率が 100% になると、ジョブの管理が困難になる場合があります。タスクの優先順位と依存関係、ドロップされたフレームの再開、そしてネットワーク、ディスク、CPU の負荷すべてが複雑な方程式の一部になり、厳密なモニタリングと制御が必要となります。厳しい締め切りを守らなければならないことも少なくありません。
これらのジョブを管理するために、VFX 施設ではキュー管理ソフトウェアがパイプラインに組み込まれています。キュー管理ソフトウェアを使用すると、以下を行えます。
- ジョブをオンプレミスおよびクラウドベースのリソースにデプロイする。
- ジョブ間の依存関係を管理する。
- アセット管理システムと通信する。
- Python などの一般的な言語用のユーザー インターフェースと API をユーザーに提供する。
一部のキュー管理ソフトウェアはクラウドベースのワーカーにジョブをデプロイできますが、クラウドへの接続、アセットの同期、ストレージ フレームワークの選択、イメージ テンプレートの管理、独自のソフトウェア ライセンスの提供は、お客様自身で行う必要があります。
クラウド環境またはハイブリッド クラウド環境でレンダリング パイプラインとワークフローを構築および管理する場合は、次のオプションを使用できます。
- オンプレミス リソースまたはクラウド リソースがまだない場合は、Conductor のような Software as a Service（SaaS）型のクラウドベースのレンダリング サービスを使用できます。
- 独自のインフラストラクチャを管理する場合は、このドキュメントで説明するクラウド リソースをビルドしてデプロイできます。
- 特定の要件に基づいてカスタム ワークフローを構築する場合は、Gunpowder や Qodea などの Google Cloud サービス インテグレーター パートナーを利用できます。このオプションには、独自の安全な Google Cloud 環境ですべてのクラウド サービスを実行できるという利点があります。
お客様の施設に最適なソリューションを判断する際は、Google Cloud の担当者にお問い合わせください。
注: プロダクション メモをこのドキュメントの各所に掲載しています。これらのメモには、レンダー ファームを構築する際のベスト プラクティスが記載されています。
クラウドに接続する
ワークロードに応じて、お客様の施設が Google Cloud に接続する方法（パートナー ISP 経由、直接接続、または公共インターネット経由）を決定します。
インターネット経由で接続する
特に接続要件がなければ、インターネット経由で Google Cloud サービスにアクセスすると、Google のネットワークに接続してエンドツーエンドのセキュリティ モデルを使用できます。Google Cloud CLI などのユーティリティや Compute Engine API などのリソースはすべて、セキュアな認証、認可、暗号化を使用してデータを保護します。
Cloud VPN
接続方法にかかわらず、接続を保護するためにバーチャル プライベート ネットワーク（VPN）を使用することをおすすめします。
Cloud VPN を使用すると、IPsec VPN 接続を介してオンプレミス ネットワークから Google Virtual Private Cloud（VPC）ネットワークに安全に接続できます。転送されるデータは、VPN トンネルを通過する前に暗号化されます。
プロジェクトの VPN の作成をご覧ください。
顧客指定の VPN
貴社独自の VPN ゲートウェイをセットアップして直接 Google に接続することも可能ですが、Cloud VPN を使用して接続することをおすすめします。これにより、柔軟性が向上し、Google Cloud とより適切に統合できるようになります。
Cloud Interconnect
ご使用のインフラストラクチャを Google Cloud に接続する方法として、Google は複数の方法をサポートしています。これらのエンタープライズ クラスの接続は、総称して Cloud Interconnect と呼ばれ、標準のインターネット接続よりも可用性が高くレイテンシが低いうえ、下り（外向き）料金も抑えられます。
Cross-Cloud Interconnect を使用すると、別のクラウドにあるデータ用に Google Cloud への高帯域幅の専用接続を確立できます。これにより、ネットワークの複雑さが軽減され、データ転送コストが削減され、高スループットのマルチクラウド レンダー ファームを実現できます。
Dedicated Interconnect
Dedicated Interconnect は、お客様のオンプレミス ネットワークと Google のネットワークの間に直接的な物理接続と RFC 1918 通信を提供します。次の種類の接続に対して接続容量を提供します。
- 1 つ以上の 10 Gbps イーサネット接続、最大で 8 つの接続（1 つの相互接続あたり合計 80 Gbps）。
- 1 つ以上の 100 Gbps イーサネット接続、最大で 2 つの接続（1 つの相互接続あたり合計 200 Gbps）。
Dedicated Interconnect のトラフィックは暗号化されません。そのため、Dedicated Interconnect でデータを安全に送信するには、独自の VPN 接続を確立する必要があります。Cloud VPN は Dedicated Interconnect に対応していません。そのため、Cloud VPN をお使いの場合でも独自の VPN を用意していただく必要があります。
Partner Interconnect
Partner Interconnect は、サポート対象のサービス プロバイダを介して、お客様のオンプレミス ネットワークと VPC ネットワークの間の接続を提供します。Partner Interconnect による接続は、Dedicated Interconnect コロケーション施設から地理的に離れた場所にインフラストラクチャを設置しているお客様や、常時 10 Gbps の専用回線を必要としないお客様に便利にお使いいただけます。
その他の接続タイプ
お客様の所在地によっては、他の方法で Google に接続できる場合があります。Google Cloud に接続する最も費用対効果の高い方法については、Google Cloud の担当者にお問い合わせください。
コンテンツを保護する
ハリウッドの大手スタジオのようなコンテンツ所有者は、コンテンツをパブリック クラウド プラットフォーム上で管理するために、社内のセキュリティ ベスト プラクティスと、MPAA のような組織が規定したセキュリティ ベスト プラクティスを遵守するようベンダーに要求します。Google Cloud は、Google Workspace、Chrome Enterprise Premium、BeyondProd などのプロダクトに組み込まれているゼロトラスト セキュリティ モデルを提供します。
レンダリング ワークロードを保護するための要件は、スタジオごとに異なります。セキュリティに関するホワイトペーパーとコンプライアンスのドキュメントは cloud.google.com/security でご覧いただけます。
セキュリティ コンプライアンスの監査プロセスについてご不明な点がある場合は、Google Cloud の担当者にお問い合わせください。
プロジェクトを組織する
プロジェクトは、Google Cloud の中核的な構成要素です。ジョブをそれぞれのプロジェクトの下で整理することも、複数のプロジェクトに分割することもできます。たとえば、映画の事前映像化段階、研究開発段階、制作段階のために別々のプロジェクトを作成できます。
プロジェクトは、ネットワーク データとプロジェクト管理の両方に対して分離境界を確立します。しかし、共有 VPC によりネットワークを複数のプロジェクト間で共有でき、それぞれのプロジェクトが共通リソースにアクセス可能になります。
プロダクション メモ: すべてのプロダクション ツールに関するリソースを含む共有 VPC ホスト プロジェクトを作成します。組織で作成したすべてのプロジェクトを、共有 VPC サービス プロジェクトとして指定できます。この指定により、組織内のすべてのプロジェクトが、ホスト プロジェクトが提供する同じライブラリ、スクリプト、ソフトウェアにアクセスできるようになります。
組織リソース
組織リソースの下でプロジェクトを管理できます。こうした組織リソースは、すでに確立されている場合があります。すべてのプロジェクトを組織に移行することには、多くのメリットがあります。
プロダクション メモ: プロダクション マネージャーを個々のプロジェクトの所有者として指定し、スタジオ管理者を組織リソースの所有者として指定します。
リソースへのアクセス権を定義する
プロジェクトには、リソースへの安全なアクセスと、ユーザーまたはサービスによる操作に対する制限が必要です。アクセス権の定義に役立てられるように、Google Cloud は Identity and Access Management（IAM）を提供しています。IAM を使用すると、どのロールがどのリソースに対して、どのレベルのアクセス権を持つかを定義することでアクセス制御を管理できます。
プロダクション メモ: ユーザーのアクセス権を、各自のロールに基づいて、特定のタスクを実行するために必要となるリソースだけに制限するには、オンプレミスとクラウドの両方に最小権限の原則を導入します。
たとえば、レンダリング ワーカーについて考えてみましょう。これは、カスタム イメージを使用する定義済みインスタンス テンプレートからデプロイできる仮想マシン（VM）です。サービス アカウントで実行されているレンダリング ワーカーは、Cloud Storage からの読み込みと、クラウド ファイラーや永続ディスクなどの接続型ストレージへの書き込みが可能です。ただし、個々のアーティストを Google Cloud プロジェクトに追加する必要はまったくありません。アーティストがクラウド リソースに直接アクセスする必要がないためです。
すべての Compute Engine リソースにアクセスできるレンダリング ラングラーやプロジェクト管理者にロールを割り当てることが可能です。これにより、他のユーザーがアクセスできないリソースに対して処理を行えるようになります。
組織内でどのロールがどのようなタイプのリソースにアクセスできるかを決定するポリシーを定義します。次の表は、代表的なプロダクション タスクと Google Cloud の IAM ロールとの対応関係を示しています。
| プロダクション タスク | ロール名 | リソースタイプ |
|---|---|---|
| スタジオ マネージャー | resourcemanager.organizationAdmin |
組織 プロジェクト |
| プロダクション マネージャー | owner、editor |
プロジェクト |
| レンダリング ラングラー | compute.admin、iam.serviceAccountActor |
プロジェクト |
| キュー管理アカウント | compute.admin、iam.serviceAccountActor |
組織 プロジェクト |
| 個々のアーティスト | [アクセスなし] | 該当なし |
アクセス スコープ
アクセス スコープを使用すると、ログインしているユーザーに関係なく、実行中インスタンスの権限を制御できます。スコープを指定できるのは、自分でインスタンスを作成するとき、およびキュー管理ソフトウェアがリソースをインスタンス テンプレートからデプロイするときです。
スコープは、個々のユーザーおよびサービス アカウントの IAM 権限より優先されます。そのため、アクセス スコープによって、プロジェクト管理者がインスタンスにログインしてストレージ バケットを削除したりファイアウォール設定を変更したりするのを防止できます。
プロダクション メモ: デフォルトでは、インスタンスは Cloud Storage の読み込みはできますが、書き込みはできません。レンダリング パイプラインで、終了したレンダリングを Cloud Storage に書き戻す場合は、インスタンスの作成時にスコープ devstorage.read_write をインスタンスに追加します。
リソースのデプロイ方法を選択する
クラウド レンダリングでは、リソースを必要なときだけ使用できますが、リソースをレンダー ファームで利用できるようにする方法はいくつかあります。
オンデマンドでデプロイする
リソースを最適に使用するために、レンダー ファームにジョブを送信するときだけレンダリング ワーカーをデプロイできます。多数の VM をデプロイしてジョブ内のすべてのフレームで共有することも、フレームごとに 1 つの VM を作成することも可能です。
キュー管理システムは実行中のインスタンスをモニタリングできます。インスタンスは、VM がプリエンプトされた場合は再度キューに入れることができ、個々のタスクが完了したときは終了できます。
リソースのプールをデプロイする
特定のジョブに関係がなく、オンプレミスのキュー管理システムが追加のリソースとしてアクセスできる、インスタンスのグループをデプロイすることもできます。Google Cloud の Spot VM を使用すれば、実行中のインスタンスのグループは、すべてのコアを使用してリソース使用量を最大化しながら、VM ごとに複数のジョブを受け入れることができます。このアプローチは、おそらく最も簡単な実装方式です。オンプレミス レンダー ファームにジョブが取り込まれる方法が再現されるためです。
ソフトウェアのライセンス方式
サードパーティ ソフトウェアのライセンス方式は、パッケージごとに大きく異なる場合があります。以下に、VFX パイプラインで使用する可能性があるライセンスの方式とモデルの一部を示します。各方式で、推奨されるライセンス アプローチを 3 番目の列に示します。
| 方式 | 説明 | 推奨 |
|---|---|---|
| ノードロック | 特定の MAC アドレス、IP アドレス、あるいは CPU ID に対してライセンスが供与されます。単一プロセスによる場合のみ実行可能です。 | インスタンス ベース |
| ノードベース | 特定のノード（インスタンス）にライセンスが供与されます。ライセンスが供与されたノードで任意の数のユーザーまたはプロセスが実行できます。 | インスタンス ベース |
| フローティング | 使用状況を追跡するライセンス サーバーからチェックアウトされます。 | ライセンス サーバー |
| ソフトウェア ライセンス方式 | ||
| インタラクティブ | ユーザーがグラフィックス ベースの環境でソフトウェアをインタラクティブに実行できます。 | ライセンス サーバーまたはインスタンス ベース |
| バッチ | ユーザーがソフトウェアをコマンドライン環境だけで実行できます。 | ライセンス サーバー |
| クラウドベース ライセンス方式 | ||
| 使用時間ベース | プロセスがクラウド インスタンス上で実行されているときだけチェックアウトされます。プロセスが完了または終了すると、ライセンスが解放されます。 | クラウドベースのライセンス サーバー |
| 稼働時間ベース | インスタンスがアクティブで実行中の間チェックアウトされます。インスタンスが停止または削除されると、ライセンスは解放されます。 | クラウドベースのライセンス サーバー |
インスタンスベースのライセンス方式を使用する
一部のソフトウェア プログラムまたはプラグインは、ハードウェアに直接ライセンスが供与され、そこで実行されます。このライセンス アプローチでは、クラウドで問題が生じる可能性があります。クラウドでは、MAC アドレスや IP アドレスなどのハードウェア識別子が動的に割り当てられるためです。
MAC アドレス
インスタンスが作成されると、MAC アドレスが割り当てられます。MAC アドレスは、インスタンスが削除されない限り保持されます。インスタンスを停止または再起動しても、MAC アドレスは保持されます。この MAC アドレスは、インスタンスが削除されるまで、ライセンスの作成および検証に使用できます。
静的 IP アドレスを割り当てる
インスタンスを作成すると、内部 IP アドレスと、必要に応じて外部 IP アドレスが割り当てられます。インスタンスの外部 IP アドレスを保持するには、静的 IP アドレスを予約してインスタンスに割り当てます。この IP アドレスは、このインスタンス専用として予約されます。静的 IP アドレスはプロジェクトベースのリソースであるため、リージョン割り当ての対象となります。
インスタンスの作成時に内部 IP アドレスを割り当てることもできます。これは、インスタンスのグループの内部 IP アドレスが同じ範囲内に収まるようにしたい場合に便利です。
ハードウェア ドングル
古いソフトウェアは、ドングル（プロダクトのライセンス情報を含むハードウェア キー）を介してライセンスを受けている場合があります。ほとんどのソフトウェア会社はハードウェア ドングルを使用していませんが、ユーザーの中にはこうしたデバイスに連動したレガシー ソフトウェアを使用している方もいます。こうした問題が発生した場合は、ソフトウェア メーカーに問い合わせて、該当のソフトウェアの更新済みライセンスがないか確認してください。
ソフトウェア メーカーがそうしたライセンスを提供できない場合は、ネットワーク接続型 USB ハブまたは USB over IP ソリューションを実装できます。
ライセンス サーバーを使用する
通常、最近のソフトウェアには、フローティング ライセンスというオプションがあります。このオプションはクラウド環境で使用するのが最適です。ただし、限られた数のライセンスを使いすぎないために、より強力なライセンス管理とアクセス制御が必要になります。
最大ライセンス数を超えないようにするため、ジョブ キュー プロセスの一環として、使用するライセンスを選び、ライセンスを使用するジョブの数を管理できます。
オンプレミス ライセンス サーバー
既存のオンプレミス ライセンス サーバーを使用して、クラウドで実行されているインスタンスにライセンスを付与できます。この方式を選択する場合、レンダリング ワーカーがオンプレミス ネットワークと通信するための方法を提供する必要があります。この通信は、VPN または他の安全な接続を介して行います。
クラウドベースのライセンス サーバー
クラウドでは、共有 VPC を使用して、プロジェクト内のインスタンスや複数のプロジェクトにまたがるインスタンスを処理するライセンス サーバーを運用できます。フローティング ライセンスはハードウェア MAC アドレスにリンクされることがあります。そのため、静的 IP アドレスを持つ小規模の長時間実行型インスタンスが、多数のレンダリング インスタンスに対してライセンスを容易に付与できます。
ハイブリッド ライセンス サーバー
一部のソフトウェアでは、複数のライセンス サーバーを優先順位に基づいて使用できます。たとえば、あるレンダラがオンプレミス サーバーから利用可能なライセンスの数をクエリし、利用可能なライセンスがない場合は、クラウドベースのライセンス サーバーを使用します。この方式は、永久ライセンスを最大限に使用した後で、他のライセンス タイプをチェックアウトする場合に便利です。
プロダクション メモ: 1 つまたは複数のライセンス サーバーを環境変数で定義して、優先順位を定義します。Autodesk Arnold は、このような場合に便利なレンダラです。ジョブは最初のサーバーを使用してライセンスを取得できない場合、次の例で示すように、リストされている他のサーバーを使用します。
export solidangle_LICENSE=5053@x.x.0.1;5053@x.x.0.2
前述の例で、Arnold レンダラは x.x.0.1、ポート 5053 でサーバーからライセンスを取得しようとしています。それが失敗すると、同じポートから IP アドレス x.x.0.2 でライセンスを取得しようとします。
クラウドベース ライセンス方式
一部のベンダーによるクラウドベースのライセンス方式では、ユーザーのインスタンスに対してソフトウェア ライセンスをオンデマンドで提供しています。クラウドベース ライセンス方式では、一般に使用時間ベースと稼働時間ベースという 2 つの課金方法があります。
使用時間ベースのライセンス方式
使用時間ベースのライセンス方式では、ソフトウェアが使用されている時間に基づいて課金されます。一般に、プロセスが開始するとライセンスがクラウドベースのサーバーからチェックアウトされ、プロセスが完了するとライセンスが解放されます。ライセンスがチェックアウトされている間、そのライセンスの使用について課金されます。このタイプのライセンス方式は、通常はレンダリング ソフトウェアに使用されます。
稼働時間ベースのライセンス方式
稼働時間ベースあるいは計測型ライセンス方式では、使用している Compute Engine インスタンスの稼働時間に基づいて課金されます。インスタンスは、起動プロセス中にクラウドベースのライセンス サーバーに登録するよう構成されます。インスタンスを実行している間、ライセンスはチェックアウトされます。インスタンスが停止または削除されると、ライセンスは解放されます。このタイプのライセンス方式は、一般にキュー マネージャーがデプロイするレンダリング ワーカーに使用されます。
データを保存する方法を選択する
Google Cloud 上で選択するストレージのタイプは、選択したストレージ方式と、耐久性要件や費用などの要因により変わってきます。
永続ディスク
永続ディスク（PD）をワークロードに組み込むことで、ファイル サーバーの完全な実装を回避できる場合があります。PD は POSIX 準拠ブロック ストレージの一種で、サイズは最大で 64 TB あり、ほとんどの VFX 施設でよく知られています。永続ディスクには、標準ドライブとソリッド ステート ドライブ（SSD）の両方があります。PD を読み書きモードで 1 つのインスタンスに接続することも、読み取り専用モードで多数のインスタンス（レンダリング ワーカーのグループなど）に接続することもできます。
| 長所 | 短所 | 理想的な使用例 |
|---|---|---|
| 標準的な NFS または SMB ボリュームとしてマウント。 動的にサイズを変更可能。 1 つのインスタンスに最大で 128 個の PD を接続可能。 同じ PD を多数のインスタンスに読み取り専用でマウント可能。 |
最大サイズが 64 TB まで。 1 つのインスタンスに接続しているときしか PD に書き込むことができない。 同じリージョン内にあるリソースしかアクセスできない。 |
新しいディスクをジョブごとに構築できる高度なパイプライン。 ソフトウェアや共通ライブラリなど更新頻度の低いデータをレンダリング ワーカーへ配信するパイプライン。 |
オブジェクト ストレージ
Cloud Storage は、冗長性が高く耐久性に優れたストレージです。従来のファイル システムと違って構造化されておらず、容量の制限が実質的にありません。Cloud Storage 上のファイルは、フォルダに似たバケットに格納され、世界中からアクセス可能です。
従来のストレージとは異なり、オブジェクト ストレージを論理ボリュームとしてオペレーティング システム（OS）がマウントすることはできません。オブジェクト ストレージをレンダリング パイプラインに組み込む場合は、データを読み書きする方法を、gcloud CLI などのコマンドライン ユーティリティか Cloud Storage API を使用して変更する必要があります。
| 長所 | 短所 | 理想的な使用例 |
|---|---|---|
| あらゆるサイズのファイルに適した、耐久性に優れ可用性の高いストレージ。 単一の API ですべてのストレージ クラスに対応。 低価格。 データを世界中で利用可能。 容量が実質的に無制限。 |
POSIX に準拠していない。 API またはコマンドライン ユーティリティを使用してアクセスする必要がある。 レンダリング パイプラインでは、使用する前にデータをローカルに転送する必要がある。 |
データを Cloud Storage に公開できるアセット管理システムを備えたレンダリング パイプライン。 レンダリングの前に Cloud Storage からデータをフェッチできるキュー管理システムを備えたレンダリング パイプライン。 |
その他のストレージ サービス
他のストレージ サービスは、Cloud Marketplace などのサードパーティ チャネルからマネージド サービスとして、あるいはソフトウェア リポジトリや GitHub からオープンソース プロジェクトとしてご利用になれます。
| サービス | 長所 | 短所 | 理想的な使用例 |
|---|---|---|---|
| Filestore | 膨大な数の同時 NFS 接続をサポートできるクラスタ化ファイル システム。 オンプレミス NAS クラスタと同期可能。 |
ファイルを選択的に同期させる方法がない。双方向同期がない。 | 多数の TB のデータをクラウドに置く中規模から大規模の VFX 施設。 |
| Pixit Media、PixStor | 膨大な数の同時 NFS や POSIX クライアントをサポートできるスケールアウト ファイル システム。データをオンプレミス NAS からオンデマンドでキャッシュでき、更新が自動的にオンプレミス ストレージへ送信される。 | コスト、Pixit によるサードパーティ サポート。 | 多数の TB のデータをクラウドに置く中規模から大規模の VFX 施設。 |
| Google Cloud NetApp Volumes | Google Cloud 上のフルマネージド型ストレージ ソリューション。 NFS、SMB、マルチプロトコル環境をサポート。 インスタンスの復元を伴うポイントインタイム スナップショット |
一部の Google Cloud リージョンでは利用できない。 | アセットの同期が可能なパイプラインを備えた VFX 施設。 仮想ワークステーション間で共有するディスク。 |
| Cloud Storage FUSE | Cloud Storage バケットをファイル システムとしてマウント。低コスト。 | POSIX 準拠のファイル システムではない。構成や最適化が難しい場合がある。 | アセット同期対応のパイプラインを使用して、オープンソース ファイル システムのデプロイ、構成、メンテナンスが可能な VFX 施設。 |
他のストレージ タイプを Google Cloud でご利用になれます。詳しくは、Google Cloud の担当者にお問い合わせください。
データ ストレージ オプションに関する参考資料
ストレージ方式を実装する
オンプレミス ストレージのデータに直接アクセスする場合も、オンプレミス ストレージとクラウドを同期させる場合も、データを処理する方法を定めた規則を確立することで、VFX またはアニメーション制作パイプラインで数多くのストレージ方式を実装できます。
方式 1: オンプレミス ストレージを直接マウントする
お客様の施設が 10 Gbps 以上で Google Cloud に接続でき、Google Cloud リージョンに近接している場合、オンプレミス NAS をクラウド レンダリング ワーカーに直接マウントできます。この方式は単純ですが、クラウド上で作成し、ストレージに書き戻すデータすべてが下りデータとしてカウントされるため、費用と使用帯域幅が増える可能性があります。
| 長所 | 短所 | 理想的な使用例 |
|---|---|---|
| 実装が単純。 共通ストレージに読み書きする。 データをすぐに利用できる。キャッシュや同期が不要。 |
他の選択肢より高額になる可能性がある。 低レイテンシを実現するには Google データセンターに近接していなければならない。 オンプレミス NAS に接続できる最大インスタンス数は、使用している帯域幅と接続タイプによって異なる。 |
Google データセンターの近くにあり、クラウドへのレンダリング ワークロードのバーストを必要とし、コストが問題にならない施設。 Google Cloud と 10 Gbps 以上で接続できる施設。 |
方式 2: オンデマンドで同期する
フレームをレンダリングするときやアセットを公開するときなど、データが必要なときだけ、データをクラウドに push するか、データをオンプレミス ストレージから pull するか、あるいはその逆にするかを選択できます。この方式を使用する場合、監視スクリプトなどのパイプラインのメカニズム、Pub/Sub などのイベント ハンドラ、ジョブ スクリプトの一部である一連のコマンドのいずれかによって、同期をトリガーできます。
同期するには、gcloud CLI scp コマンド、gcloud CLI rsync コマンド、UDP ベースのデータ転送プロトコル（UDT）などさまざまなコマンドを使用できます。Aspera、Cloud FastPath、BitSpeed、FDT などのサードパーティ UDT を使用して Cloud Storage バケットと通信する場合は、サードパーティのドキュメントを参照してそのセキュリティ モデルとベスト プラクティスをご確認ください。Google はそれらのサードパーティ サービスについて関与していません。
push 方式
一般に push 方式を使用するのは、アセットを公開するとき、ファイルを監視フォルダに置くとき、あるいはレンダリング ジョブを完了するときです。その後は、定義済みの場所に push します。
例:
- クラウド レンダリング ワーカーがレンダリング ジョブを完了し、その結果となるフレームがオンプレミス ストレージに再び push される。
- アーティストがアセットを公開する。アセット公開プロセスの一環として、関連するデータを Cloud Storage の事前定義済みパスに push する。
pull 方式
pull 方式を使用するのは、通常クラウドベースのレンダリング インスタンスによりファイルが要求されたときです。
例: レンダリング ジョブ スクリプトの一部として、シーンをレンダリングするために必要となるすべてのアセットがレンダリングの前にファイル システムに pull されて、すべてのレンダリング ワーカーがアクセスできるようになる。
| 長所 | 短所 | 理想的な使用例 |
|---|---|---|
| どのデータをいつ同期するかを完全に管理できる。 転送の方法とプロトコルを選択できる。 |
push/pull 同期をトリガーするためのイベント処理を制作パイプラインが対応可能でなければならない。 同期キューを処理するために追加のリソースが必要になる場合がある。 |
カスタム パイプラインを持ち、アセットの同期を完全に管理したい小規模から大規模の施設。 |
プロダクション メモ: レンダリング ジョブの操作に使用するのと同じキュー管理システムでデータ同期を管理します。同期タスクは別々のクラウド リソースを使用して、可能な帯域幅を最大化し、ネットワーク トラフィックを最小限に抑えられます。
方式 3: オンプレミス ストレージ、クラウドベースのリードスルー キャッシュ
Google Cloud は、オープンソースのオプションとして KNFSD キャッシュ ソリューションの拡張と開発を行いました。このソリューションは、ストレージ インフラストラクチャの機能では対応できないレンダー ファームのパフォーマンス要件に対応できます。KNFSD キャッシュは、高パフォーマンスのリードスルー キャッシュを提供します。これにより、複数のリージョンとハイブリッド ストレージ プールにまたがって、ワークロードを数百、場合によっては数千のレンダリング ノードにスケーリングできます。
KNFSD キャッシュは、メインのファイル共有サービスの負荷を軽減するスケールアウト ソリューションです。また、多くのレンダリング ノードがファイル サーバーからファイルを同時に取得しようとした場合も、KNFSD キャッシュにより過負荷状態の影響が軽減されます。レンダリング ノードと同じ VPC ネットワーク上でキャッシュ レイヤを使用することで、読み取りレイテンシが短縮され、レンダリング ジョブの開始と完了がより速くなります。キャッシング ファイル サーバーをどのように構成したかに応じて、データはキャッシュに残り、その後以下のいずれかの状態になります。
- データの期限が切れます。つまり、指定された期間放置されたままになります。
- ファイル サーバーで領域が必要になり、存続期間に基づいてデータがキャッシュから削除されます。
この方式により、帯域幅の量と、多数の同時レンダリング インスタンスをデプロイする際の手間が削減されます。
場合によっては、キャッシュを事前に準備して、レンダリング前にすべてのジョブ関連データが存在するようにしなければなりません。キャッシュを事前に準備するには、クラウド ファイル サーバー上のディレクトリの内容を読み込むために、1 つまたは複数のファイルの read または stat を実行します。ファイルにこの方法でアクセスすることで、同期メカニズムがトリガーされます。
物理オンプレミス アプライアンスを追加して、仮想アプライアンスと通信することもできます。たとえば、NetApp が提供するストレージ ソリューションによって、オンプレミス ストレージとクラウドの間のレイテンシをさらに短縮できます。
| 長所 | 短所 | 理想的な使用例 |
|---|---|---|
| キャッシュに保存されたデータが自動的に管理される。 必要な帯域幅が減る。 クラスタ化クラウド ファイル システムをジョブの要件に応じてスケールアップまたはスケールダウンできる。 |
追加コストが発生する可能性がある。 キャッシュを事前に準備する場合、ジョブ実行前タスクを実装する必要がある。 |
多くの同時インスタンスをデプロイし、多数のジョブに共通するアセットを読み込む大規模な施設。 |
データのフィルタリング
特定のタイプのデータを同期するかどうかを定義するために、アセットタイプと関連条件のデータベースを構築できます。変換プロセスの一環として生成される一時的なデータ、キャッシュ ファイル、シミュレーション データなど、一部のデータタイプを同期しない場合があります。承認されていないアセットを同期するかどうかも検討してください。すべての繰り返しが最終レンダリングで使用されるとは限りません。
初期一括転送を実行する
ハイブリッド レンダー ファームを実装するとき、すべてまたは一部のデータセットを Cloud Storage、永続ディスク、または他のクラウドベース ストレージに初期転送できます。転送するデータの量と種類、接続速度などの要因に応じて、完全な同期を数日または数週間にわたって行う場合があります。以下の図に、オンライン転送と物理転送に要する一般的な時間の比較を示します。
転送ワークロードが時間や帯域幅の制約を超えている場合、Google の Transfer Appliance など、数多くの転送オプションを使用してデータをクラウドに転送できます。
アーカイブと障害復旧
データのアーカイブと障害復旧の違いに注目することは重要です。アーカイブは完了した作業を選択的にコピーすることであり、障害復旧は復元可能なデータの状態です。お客様の施設のニーズに一致し、現場外の緊急時対応計画が示された障害復旧計画を策定してください。お客様固有のストレージ プラットフォームに適した障害復旧計画については、オンプレミス ストレージのベンダーにお問い合わせください。
データをクラウドにアーカイブする
プロジェクトが完了した後は、完成した作業をなんらかの長期記憶装置、一般には LTO などの磁気テープメディアなどに保存します。これらのカートリッジは環境要件に左右され、長期的な管理が困難な場合があります。大規模なプロダクション施設によっては、アーカイブ全体を専用の部屋に収容し、専任のアーカイブ担当者がデータの記録をとり、依頼があったときに取り出します。
データが複数のカートリッジに格納されていたり、アーカイブ索引がなくなっていたり不完全であったり、磁気テープからデータを読み取る際の速度が限られていたりすることがあるため、アーカイブした特定のアセット、ショット、映像を検索する際に時間がかかる場合があります。
データ アーカイブをクラウドに移行することで、アーカイブ メディアのオンプレミスの管理やストレージの必要がなくなります。しかも、従来のアーカイブ方式と比べてデータのアクセス性と検索性がはるかに向上します。
基本的なアーカイブ パイプラインは以下の図のようになります。さまざまなクラウド サービスを使用して、アーカイブを調べて、分類、タグ付け、整理を行っています。クラウドから、アーカイブ管理および検索ツールを作成し、日付、プロジェクト、形式、解像度などさまざまなメタデータ基準を使用してデータを検索できます。Machine Learning API を使用して画像や動画をタグ付けして分類し、BigQuery などのクラウドベースのデータベースにその結果を保存することもできます。
考慮すべきその他のトピック:
- 取得料金が適用される Cloud Storage ストレージ クラス内にあるコンテンツのサムネイルまたはプロキシの生成を自動化します。ユーザーが、アーカイブされたアセットではなく、プロキシだけを読み取りながらデータを閲覧できるように、これらのプロキシをメディア アセット管理システム内で使用します。
- ML を使用して実写コンテンツを分類することを検討します。Cloud Vision を使用してテクスチャやバックグラウンド プレートにラベル付けをし、Video Intelligence API を使用して参照映像を検索して取得します。
- また、Vertex AI AutoML Image を使用して、実写やレンダリングなど、あらゆるアセットを認識するためのカスタム画像モデルを作成することもできます。
- レンダリングされたコンテンツについては、レンダリング ワーカーのディスク イメージのコピーを、レンダリングされたアセットとともに保存することを検討してください。セットアップを再作成する場合、アーカイブ ショットの再レンダリングが必要であれば、適切なソフトウェア バージョン、プラグイン、OS ライブラリ、依存関係を用意します。
アセットとプロダクションを管理する
同じプロジェクトを複数の施設が分担する場合、特にコンテンツやアセットを世界中で利用可能にする際に、固有の問題が生じることがあります。データをプライベート ネットワーク間で手動で同期すると、コストがかかるとともにリソースを大量に消費し、さらに地域ごとに帯域幅の制約を受けます。
グローバルに利用可能なデータがワークロードで必要な場合は、Cloud Storage を使用することを検討してください。Cloud Storage には、Google サービスにアクセスできる場所であれば、どこからでもアクセスできます。Cloud Storage をパイプラインに組み込むには、パイプラインを変更してオブジェクト パスを確認してから、レンダリング前にデータをレンダリング ワーカーに対して pull または push する必要があります。この方法を使用すると、公開されたデータへのグローバルなアクセスが可能になります。ただし、パイプラインによって、アセットが必要とされる場所にアセットを適切な時間内に配信する必要があります。
たとえば、ロサンゼルスのテクスチャ アーティストが、ロンドンの照明アーティストが使用する画像ファイルを公開するとします。このプロセスは次のようになります。
- 公開パイプラインはファイルを Cloud Storage に push し、クラウドベースのアセット データベースにエントリを追加します。
- ロンドンにいるアーティストが、シーンのアセットを収集するスクリプトを実行します。ファイルの場所がデータベースから照会され、Cloud Storage からローカル ディスクに読み込まれます。
- キュー管理ソフトウェアがレンダリングに必要なアセットのリストを収集し、アセット データベースから照会して、Cloud Storage から各レンダリング ワーカーのローカル ストレージにダウンロードします。
Cloud Storage をこの方法で使用することで、Cloud Storage をアーカイブ パイプラインの一部として使用した場合に、クラウド上のすべての公開データのアーカイブも提供されます。
データベースを管理する
アセットおよび制作管理ソフトウェアは、毎秒数百から数千のクエリを処理可能なホストでサービスを提供する、可用性と耐久性の高いデータベースに依存しています。データベースは一般にレンダリング ワーカーと同じラック内で稼働するオンプレミス サーバーでホストされ、電力、ネットワーク、HVAC に関して同じ制約を受けます。
MySQL、NoSQL、および PostgreSQL 制作データベースを、クラウドベースのマネージド サービスとして稼働させることも検討できます。これらのサービスは可用性が高く世界中でアクセスでき、データが保存時も転送時も暗号化されます。また、組み込みの複製機能が備わっています。
キューを管理する
Qube!、Deadline、Tractor などの市販のキュー管理ソフトウェア プログラムは、VFX やアニメーション業界で広く使われています。OpenCue などの利用可能なオープンソース ソフトウェア オプションもあります。このソフトウェアを使用すると、レンダリングだけでなく各種ワーカーに対して任意のコンピューティング ワークロードをデプロイして管理できます。アセット公開、粒子および流体シミュレーション、テクスチャ ベーキング、合成をデプロイして管理する際に、レンダリングの管理に使用するのと同じスケジューリング フレームワークを使用できます。
施設によっては、HTCondor（ウィスコンシン大学）、Slurm （SchedMD）、Univa Grid Engine などの汎用的スケジューリング ソフトウェアを VFX パイプラインに実装しています。しかし、特に VFX 業界向けに設計されたソフトウェアは、次のような機能を重視しています。
- ジョブベース、フレームベース、レイヤベースの依存関係。一部のタスクは、他のタスクを開始する前に完了する必要がある。たとえば、流体シミュレーションはレンダリングの前に完了する。
- ジョブの優先度。レンダリング ラングラーが使用して、それぞれの期限とスケジュールに基づいてジョブの順序を変更できる。
- リソースのタイプ、ラベル、またはターゲット。これらは、特定のリソースを必要とするジョブとそうしたリソースを適合させるために使用できる。たとえば、GPU 高速化レンダリングを、GPU が接続されている VM だけにデプロイする。
- リソース使用量に関する履歴データをキャプチャし、API やダッシュボードを介して詳細に分析できるようにする。たとえば、最後の数回のレンダリング繰り返しについて CPU とメモリの平均使用率を調べて、次の反復におけるリソース使用量を予測する。
- プリフライト ジョブとポストフライト ジョブ。たとえば、プリフライト ジョブは、レンダリング前に必要なすべてのアセットをローカル レンダリング ワーカーに pull する。ポストフライト ジョブは、レンダリング後のフレームをファイル システム上の指定の場所にコピーして、そのフレームをアセット管理システムで完了としてマークする。
- Maya、3ds Max、Houdini、Cinema 4D、Nuke などの普及度の高い 2D および 3D ソフトウェア アプリケーションとの統合。
プロダクション メモ: キュー管理ソフトウェアを使用すると、クラウドベース リソースのプールがオンプレミス レンダリング ワーカーにある場合と同様にそのプールを認識できます。この方式では、各インスタンスが処理可能な数のレンダリングを実行することでリソースの使用率を最大化にするための監視が必要です。この手法はビンパッキングと呼ばれます。これらの操作は、通常、アルゴリズムとレンダリング ラングラーの両方によって処理されます。
クラウドベースのリソースの作成、管理、終了をオンデマンドで自動化することもできます。この方法では、キュー マネージャーが、レンダリング前およびレンダリング後のスクリプトを実行します。これらのスクリプトによって、リソースを必要に応じて作成し、それらをレンダリング中にモニタリングして、タスクの完了後にリソースを終了します。
ジョブのデプロイに関する考慮事項
実装しているレンダー ファームがオンプレミス ストレージとクラウドベース ストレージの両方を使用する場合、キュー マネージャーは以下の事項を考慮に入れてください。
- ライセンス方式がクラウド デプロイとオンプレミス デプロイで異なる場合があります。ノードベースのライセンスもあれば、プロセス駆動型のライセンスもあります。キュー管理ソフトウェアによってジョブをデプロイする際に、ご使用のライセンスが最大限活用されるようにジョブをデプロイしてください。
- クラウドベースのリソースに一意のタグまたはラベルを追加して、リソースが特定のジョブタイプに割り当てられたときだけ使用されるようにすることを検討してください。
- Cloud Logging を使用して、未使用のインスタンスやアイドル状態のインスタンスを検出します。
- 従属ジョブを起動する際に、結果データの保存場所と、そのデータが次のステップで必要になる場所を考慮してください。
- パスの名前空間がオンプレミスとクラウドベース ストレージで異なる場合、相対パスを使用してレンダリングが場所に依存しないようにすることを検討してください。また、プラットフォームによっては、レンダリング時にパスを入れ替える仕組みを構築できます。
- 一部のレンダリング、シミュレーション、ポストプロセスは乱数発生を使用しますが、乱数発生は CPU メーカーによって異なる場合があります。同じメーカーの CPU でもチップ世代が違えば、異なる結果になる可能性があります。不確実性がある場合は、ジョブのすべてのフレームで同一または類似した CPU タイプを使用してください。
- リードスルー キャッシュ アプライアンスを使用している場合、キャッシュを事前に準備するためのプリフライト ジョブのデプロイを検討してください。また、クラウド リソースをデプロイする前にすべてのアセットがクラウド上で利用可能になっていることを確認してください。この方法により、クラウドへのアセットの移動中にレンダリング ワーカーの待機時間を最小限に抑えることができます。
ロギングとモニタリング
リソース使用量とパフォーマンスの記録とモニタリングは、すべてのレンダー ファームにおいて不可欠の機能です。Google Cloud は、リソースやサービスの使用状況についての洞察を得るために役立つさまざまな API、ツール、ソリューションを提供しています。
VM のアクティビティをモニタリングする最も簡単な方法は、VM のシリアルポート出力を確認することです。この出力は、一般的なサービス コントロール プレーン（レンダリング キュー管理スーパーバイザーなど）からインスタンスの応答がない場合に役立ちます。
以下の方法でも Google Cloud でのリソース使用量を収集およびモニタリングできます。
- Cloud Logging を使用して、使用状況と監査ログをキャプチャし、その結果のログを Cloud Storage や BigQuery などのサービスにエクスポートします。
- Cloud Monitoring を使用して、システム指標をモニタリングするエージェントを VM にインストールします。
- Cloud Logging API をパイプライン スクリプトに組み込んで、一般的なスクリプト言語のクライアント ライブラリを使用することで Cloud Logging に直接ログを出力します。
- Cloud Monitoring を使用してグラフを作成し、リソースの使用状況を把握します。
レンダリング ワーカー インスタンスを構成する
ワークロードを完全なハイブリッドにするには、オンプレミス レンダリング ノードがクラウドベースのレンダリング ノードと同一であり、OS バージョン、カーネルビルド、インストールされたライブラリ、およびソフトウェアが一致しなければなりません。マウント ポイント、パス名前空間、ユーザー環境もオンプレミスにあるため、クラウド上に再現する必要があります。
ディスク イメージを選択する
公開イメージからディスク イメージを選択することも、ご使用のオンプレミス レンダリング ノードイメージをベースにしたカスタム イメージを作成することもできます。公開イメージには、ユーザー アカウントを設定および管理し、Secure Shell（SSH）キーベースの認証を有効にするパッケージのコレクションが含まれています。
カスタム イメージを作成する
カスタム イメージを作成する場合、ライブラリを Linux と Windows の両方に追加して、それらのライブラリが Compute Engine 環境で適切に機能するようにしてください。
カスタム イメージは、セキュリティのベスト プラクティスに適合している必要があります。Linux を使用している場合は、Compute Engine の Linux ゲスト環境をインストールして、公開イメージによってデフォルトで提供される機能にアクセスします。ゲスト環境をインストールすることで、公開イメージで使用するのと同じセキュリティ管理をカスタム イメージで使用して、メタデータ アクセス、システム構成、Google Cloud 用の OS の最適化などのタスクを実行できます。
プロダクション メモ: カスタム イメージは、別個のプロジェクトを使用して組織レベルで管理してください。この方法により、イメージの作成方法と変更方法をより詳細に管理できます。また、バージョンを適用できるため、複数の制作において異なるバージョンのソフトウェアや OS を使用する場合に役立ちます。
イメージの作成とインスタンスのデプロイを自動化する
Packer などのツールを使用して、イメージ作成の再現性、監査性、構成可能性、信頼性を高めることが可能です。Ansible などのツールを使用して、実行中のレンダリング ノードを構成し、その構成やライフサイクルをきめ細かく管理することもできます。
マシンタイプを選択する
Google Cloud では、事前定義されたマシンタイプの中から選択することも、カスタム マシンタイプを指定することもできます。カスタム マシンタイプを使用するとリソースを管理でき、Google Cloud で実行するジョブタイプに基づいてインスタンスをカスタマイズできます。インスタンスを作成するときに、GPU を追加して、CPU 数、CPU プラットフォーム、RAM 量、ディスクの種類とサイズを指定できます。
プロダクション メモ: フレームごとに 1 つのインスタンスをデプロイするパイプラインの場合、CPU 負荷やメモリ使用量などの過去のジョブ統計に基づいてインスタンスをカスタマイズし、ショットの全フレームにわたってリソース使用を最適化することを検討してください。たとえば、モーション ブラーが多いフレームに対して CPU 数の多いマシンをデプロイすることで、すべてのフレームでレンダリング時間の標準化が可能になります。
標準 VM またはプリエンプティブル VM を選択する
プリエンプティブル VM（PVM）とは、標準 VM よりもはるかに低価格で販売されている追加の Compute Engine 容量のことです。他のタスクがその容量へのアクセスを必要としている場合、Compute Engine によってそれらのインスタンスが終了またはプリエンプトされることがあります。PVM が最も適しているのは、プリエンプションがないジョブを追跡するキューイング システムによって管理されるフォールト トレラントなレンダリング ワークロードです。
標準 VM は無期限に実行できるため、永続的に実行する必要があるライセンス サーバーやキュー管理者ホストに最適です。
プリエンプティブル VM は 24 時間後に自動的に終了するため、実行時間の長いレンダリングやシミュレーションの実行には使用しないでください。
プリエンプション レートは 5% から 15% ですが、一般的なレンダリング ワークロードではコストの低さを考えれば許容範囲内と想定されます。プリエンプションのベスト プラクティスを使用すると、PVM をレンダリング パイプラインに統合するための最適な方法を決定できます。インスタンスがプリエンプトされると、Compute Engine がプリエンプション信号をインスタンスに送信します。この信号を使用して、現行ジョブを終了して再キューするようにスケジューラをトリガーできます。
| 標準 VM | プリエンプティブル VM |
|---|---|
| 長時間実行ジョブに使用可能。 優先度が高く期限の厳しいジョブに最適。 無期限に実行できるため、ライセンス サーバーやキュー管理者のホスティングに最適。 |
24 時間後に自動的に終了する。 プリエンプトされたインスタンスを処理するためのキュー管理システムが必要。 |
プロダクション メモ: レンダラによっては、進行中のレンダリングのスナップショットを指定した間隔で実行できます。そのため、VM がプリエンプトされた場合、レンダリングを一時停止して再開できます。フレームを最初から再開する必要はありません。スナップショットをサポートするレンダラで PVM を使用する場合は、パイプラインにおけるレンダリング スナップショットを有効にして、作業が失われないようにします。スナップショットの作成および更新中に、データを Cloud Storage に書き込みできます。レンダリング ワーカーがプリエンプトされた場合、データは新しい PVM がデプロイされたとき取得されます。ストレージのコストを避けるには、完了したレンダリングのスナップショット データを削除します。
レンダリング ワーカーへのアクセスを許可する
IAM を使用すると、クラウド リソースへのアクセス権を必要とする個人にそのアクセス権を容易に割り当てられます。Linux レンダリング ワーカーの場合、OS Login を使用して SSH セッション内のアクセス権を制限することで、誰が管理者であるかを管理できます。
ハイブリッド レンダー ファームのコストを抑える
コストは多くの要素を考慮して見積もる必要がありますが、ハイブリッド レンダー ファームのポリシーとして以下の一般的なベスト プラクティスを実施することをおすすめします。
- プリエンプティブル インスタンスをデフォルトで使用する。レンダリング ジョブが非常に長時間（フレームあたり 4 時間以上）である場合やショット配信の期限が厳しい場合を除き、プリエンプティブル VM を使用してください。
- 下り（外向き）データを最小にする。必要なデータだけをコピーしてオンプレミス ストレージに保管してください。ほとんどの場合、このデータが最終的なレンダリング フレームになりますが、このデータは別のパスあるいはシミュレーション データになる場合もあります。オンプレミス NAS を直接マウントしている場合や、自動的に同期するストレージ サービスを使用している場合、すべてのレンダリング データをレンダリング ワーカーのローカル ファイル システムに書き込み、それから必要なものをコピーしてオンプレミス ストレージに保管し、一時的で不要な下りデータを回避します。
- 適切なサイズの VM。レンダリング ワーカーを最適なリソース使用量で作成してください。必要な数の vCPU、最適な RAM 容量、正しい GPU 数（該当する場合）だけを割り当てます。また、接続ディスクのサイズを最小限に抑える方法も検討してください。
- 最小使用料金の 1 分間分をベースにして考える。Google Cloud では、インスタンスは秒単位で課金され、最小使用料金は 1 分間分です。ワークロードに含まれているレンダリング フレームが 1 分間未満の場合、複数のタスクをひとまとめにして、コンピューティング時間が 1 分間未満のインスタンスをデプロイしないようにすることをおすすめします。
- 大きなデータセットをクラウドに保管する。大規模な EXR やシミュレーション データなど、大量のデータを生成するためにレンダー ファームを使用する場合、パイプラインの下流にあるクラウドベースのワークステーションを使用することを検討してください。たとえば、FX アーティストが流体シミュレーションをクラウド上で実行し、キャッシュ ファイルをクラウドベース ストレージに書き込むとします。その後、照明アーティストが Google Cloud 上の仮想ワークステーションからこのシミュレーション データにアクセスできます。仮想ワークステーションの詳細については、Google Cloud の担当者にお問い合わせください。
- 継続利用割引と確約利用割引を活用する。リソースのプールを実行する場合、継続利用割引により、1 か月間実行するインスタンスの費用を最大で 30% 節約できます。確約利用割引を使用して節約できる場合もあります。
既存のレンダー ファームをクラウドに拡張すると、投資コストをかけずに有用かつ低コストのリソースを使用できます。これはコスト効率の高い方法です。制作パイプラインはそれぞれ異なるため、すべてのトピックと固有の要件が記載されたドキュメントはありません。クラウドへのレンダリング ワークロードの移行については、Google Cloud の担当者にお問い合わせください。
次のステップ
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センターをご覧ください。