* この投稿は、米国時間 5 月 1 日、Google Cloud Platform US Team によって投稿されたものの抄訳です。今回のゲストは、Industriromantik のテクニカル ディレクター Fredrik Averpil 氏です。Industriromantik は静止画および動画のコンピュータ生成を専門とするデジタル制作会社で、Fredrik はカスタムのコンピュータ グラフィックス パイプラインを開発しています。
我々は小さなデザインおよび視覚化スタジオで、高解像度の製品画像やテレビ コマーシャルなどの美しい 3D 画像を制作することに注力しています。制作を成功させるためには十分なレンダリング能力が必要ですが、時に社内のレンダリング能力では対応できないという状況がでてきます。これが Google Compute Engine を採用した理由です。


3D グラフィックスのパイプライン、アプリケーション、およびプロジェクト ファイルを Compute Engine で処理するようにしたことで、一気にレンダリングのキャパシティをオンデマンドで拡大・伸縮できます。このため、コスト効率を維持しながらプロジェクトのスループットを向上させ、クライアントの要求を満たし、レンダリングのピーク時にも容易に対応することできます。夕食の時間を家庭で過ごせる、というおまけつきです。

セットアップ方法

ローカルのレンダリング ジョブの管理ソフトには、非常に堅牢な Pixar Tractor を使っています。スケーリング向けに設計されていて、多数のタスクを同時処理できるからです。ローカルのサーバー（アプリケーション、カスタムツール、およびプロジェクトファイルに対応）は、あらかじめレンダリング時間の前に Compute Engine にミラーリングされます。こうすることにより、クラウド レンダリングはローカル レンダリングと同等の速さで応答できます。Compute Engine のインスタンスで Tractor クライアントを実行させることにより、ローカルのオフィスにある Tractor の管理ダッシュボードにそれらがシームレスに表示されます。1600 コア相当のインスタンスを 800 コアのローカルのレンダリング施設に追加できると考えれば、その技術がいかにパワフルかがわかるでしょう。


ファイルサーバーの基本的なセットアップでは、インスタンスに、良好なファイル キャッシング性能を得るのに十分な RAM を搭載しています。50 個 の n1-standard-32 レンダリング インスタンスに対応するファイルサーバーとして n1-highmem-4 インスタンスを使用しています。その後、プロジェクトやアプリケーションを保持させるために、ファイルサーバーのインスタンスに（高い IOPS を得るために 1.5TB の単位で）追加のパーシステント ディスクストレージを接続しています。このパーシステント ディスクのプールに ZFS を使用しているので、レンダリングが進行中であっても、ファイルサーバーのストレージをオンデマンドで増やすことができます。ZFS のキャッシュ性能を向上させるために、ローカル SSD ディスクをファイルサーバーのインスタンスに接続することができます（ベータ版機能）。以上はプロジェクトに何を必要としているかによります。つまり、どれだけの数のインスタンスを使用するか、どんなパフォーマンスを必要としているかによってセットアップは異なります。


次に示すように、ファイルサーバーとファイル転送の操作は Google Compute Engine の認証セッションから SSH 経由で行うことが可能で、最終的には Tractor を介して自動化されます。


バケットにプロジェクト データを保存すると、次のようにしてそこから取り出すこともできます。


Compute Engine 上で実行される（Tractor によって管理された）ソフトウェアは、インターネットを介して、ローカル オフィスが提供するソフトウェア ライセンスにアクセスします。また、Tractor クライアントを実行中のインスタンスは、ローカルの Tractor サーバーに接続できるようにする必要があります。上の図 2 に示すように、これらすべては VPN のベータ版を使用することによって実行できます。


ソフトウェア ライセンス数はインスタンス数のようにはオンデマンドでスケールできないので、利用可能な最速のマシン、つまり 32 コアのインスタンスを利用しています。我々が選択した主要なレンダラーである V-Ray for Maya でレンダリングすると、16 コアよりも 97-98% のスピードアップになります（素晴らしいスケーリングです！）。


レンダリング タスクが完了すると、ファイルは簡単にローカルの元の場所へコピーバックすることができます。この場合も、フレーム レンダリング完了後に直接 Tractor で管理されます。

自動化

Compute Engine のレンダリングでは、手作業や細かい管理は避けることを強くお勧めします。複雑なプロセスの自動化は Tractor が優れています。ファイルサーバのスピンアップ、ストレージの割り当て、ファイル転送、などのデイジーチェーン タスクを Tractor で実行させることにより、大規模かつ同時ジョブの管理が容易になります。


図 4 にタスクのデイジーチェーンを示します。Google Compute Engine のファイルサーバーへプロジェクトがアップロードされると、ディスクがファイルサーバーに接続され、ZFS プールに追加されます。必要なソフトウェアの特定のバージョンと共にプロジェクト ファイルがアップロードされます。ディスク ストレージが接続されてからでないとファイルはアップロードされないので、この場合には、いくつかのプロセスは他のプロセスが完了するのを待ってから開始します。


Compute Engine と分単位の課金とによって懸念は解消し、インスタンスの自動スケーリングを好きになることができました。ときどき保留中のタスクのために Tractor を使って（その query Python API を使用して）スクリプトをチェックインさせることにより、（Google Cloud SDK を介して）インスタンスをスピンアップして、レンダリングを実行させたり、不要になったときにすぐに停止させたりすることができます。このようにして細かな管理を行なうことができます。


Compute Engine のレンダリングを利用したいけれどもターンキーの管理ソリューションを必要とする人には、 Google Cloud Platform の優れたインフラを利用する Zync Render のベータ版を検討することをお勧めします。Zync Render は、ファイル転送を管理する独自のフロントエンド UI を持ち、レンダリングに必要なソフトウェア ライセンスを提供するので、Compute Engine 固有の統合機能を実装する必要はありません。このため、レンダリングの部分が非常に簡単になります。最終的には Zync Render が Google Compute Engine ユーザー向けにソフトウェア ライセンス サーバーを提供し、インスタンスがいくつあってもシームレスにライセンスを拡張できるようになることを願っています。

まとめ

今日 3D レンダリングを扱うすべてのデジタル制作会社は、その規模に関係なく、競争力を維持するためになんらかの形で手頃な価格のクラウド レンダリングを活用する必要があると考えています。また、成功の鍵は自動化に重点を置くことであると信じています。 Google Cloud SDK は、パワフルな Google Compute Engine を Pixar Tractor などの先進的で高度にカスタマイズ可能なレンダリング ジョブ管理ソフトと組み合わせることで、これを実行する優れたツールです。これらの先進的なキューイング システムを自分で維持したくない中小企業や個人のために、Zync Render は Compute Engine のインフラを利用しています。


コンピュータ グラフィックス パイプラインに関する他の記事やヒントについては、http://fredrik.averpil.com で Fredrik のブログを参照してください。また、Industriromantik の詳細については、http://www.industriromantik.se を参照してください。


-- Google Cloud Platform Japan Team