クラウドに第二のレンダー ファームを――マーザの取り組みにみる、クラウド レンダリングの在るべき姿

レンダリング リソースを枯らしてはならない

CG アニメーションは、膨大な数のカットによってできています。カットは複数が連なることでシーンとなり、シーンが集まると今度はシークエンス (章) が形成されます。映像作品におけるシークエンスの数は、2 時間の CG 長編アニメーションの場合 20 以上にものぼります。

様々なクリエイターが力を合わせて魅力あるシークエンスを生み出す、そしてこれを繋ぎ合わせて高品質な映像作品を創り出す。そこで欠かすことのできないのが、レンダリングです。クリエイターの業務は、レンダリングによって初めて映像となります。今の出来栄えを映像によって確認し、より作品を磨き上げていく。そのために、CG アニメーションの制作現場では日々、シークエンス単位でレンダリングが行われているのです。

マーザ・アニメーションプラネット株式会社 プロダクション本部 技術課 課長のギデ ガエトン 氏は、「1つのプロジェクトにおいて、レンダリングは常に行われています。クリエイターにとって、もはやレンダリングのリソースは "あって当然のもの" になっています。仮にこの前提が揺らいでレンダリング待ちなどが生じれば、制作工程に大きな停滞を引き起こしてしまうのでしょう。」と語ります。しかし、"あって当然のもの" であり続けることは、決して容易ではないと続けます。

アニメーション業界において、一定の期間に複数プロジェクトが並立することは珍しくありません。プロジェクトのオファーはマーザへの期待の証です。ただ、レンダリングは膨大な演算処理を必要とします。スケーラビリティを持つレンダー ファームがなければ、この期待に応え続けることが困難なのです。

同社は現在、台数にして約 80 台、コア数 (スレッド数) にして 4,608 コアの規模をもった、クラスタ構成によるレンダー ファームをオンプレミスに構えています。また、これ以外にも一部処理リソースとしてレンタル サーバーも利用。ただ、この規模をもってしても、従来型の運用には限界が訪れていたとギデ 氏は言います。

「この業界では突如新たなプロジェクトが立ち上がるということが往々にしてあるため、計画立てて処理リソースを運用することが極めて困難です。ただ、それでもレンダリング用の処理リソースは枯らしてはなりません。物理ハードウェアに依存するオンプレミスではどうしても限界がありますから、クラウドの活用は必須だと言えるでしょう。残念ながら、レンダー ファームにクラウドを活用している例は、日本にほとんどありません。だからこそ当社が先陣を切ってここに取り組むことには業界的にも意義があると考え、クラウドの活用に着手しました」(ギデ 氏)。

• マーザの業務風景。クリエイターが本業に専念できる。レンダリング リソースに左右されずプロジェクトが進められる。同社がクラウド活用を進める理由は、"高品質な作品を生み出し続ける" という思いにあった

レンダー ファームでクラウドを活用することの難しさ

ギデ 氏が触れたように、多くの企業はレンダー ファームをオンプレミスで運用しています。規模の大きなシステムを固定資産として所有しているため、オンプレミスからクラウドへと " 切り替える" のは、まだ先のことでしょう。ただ、同氏は、一部処理にクラウドを "活用" するという動きさえも稀であると語ります。ここにはどのような理由があるのでしょうか。

1 つ挙げられるのが、レンダー ファームに求められる複雑なジョブ管理です。マーザの場合、クラスタ環境で適切にジョブを実行するために、Render Manager (レンダリングのジョブ管理システム) に独自開発の「Harvester」を利用しています。マーザ・アニメーションプラネット株式会社 プロダクション本部 システム課 課長の秋重 有希 氏はこの「Harvester」を例に挙げて、クラウド活用の難しさを説明します。

「クラウドにクラスタ環境を用意する場合、ネットワークや処理性能は、オンプレミスと同一にはできません。『Harvester』では、高速な社内ネットワークを利用すること、高性能なクラスタ環境であることを前提にしてロジックを組んでいます。先述した条件の異なる環境においても『Harvester』は適用できますし、大規模なクラスタ環境で一定期間運用する事も可能です。ただ、どうしても規模の変更が頻繁に必要になる場合にはフレキシビリティに弱い面がありました。クラウドの持つスケーラビリティを最大限活かすならば、『Harvester』とは別に Render Manager を用意する必要がありました」( 秋重 氏)。

マーザでは、CG 制作の主要ソフトウェアとして Autodesk Maya を利用しています。同社ではこの Autodesk Maya をサブ スクリプション契約に切り替えて以降、新たな Render Manager「 Job Center」の検討を進めるなど、クラウド活用に向けた歩みを進めてきました。ただ、ここではある点に留意する必要があったといいます。マーザ・アニメーションプラネット株式会社 CGエンジニアの松成 隆生 氏は、クリエイターとしても活躍する自らの視点を交えてこう話します。

「クリエイターは創造的業務に時間や意識を割くべきですから、レンダリング作業は可能な限り簡素化する必要がありました。オンプレミス、クラウド問わず同じプロセスでレンダリングできる、そんな環境が理想です。ただ、ここにはある懸念がありました。ユーザーの持つ "あって当然のもの" という意識から、クラウドのリソースが青天井になる恐れがあったのです。ユーザーはインフラを意識することなくこれを利用できる、しかもクラウドのリソースは自動で制御されている、そんな仕組みを構築せねばならなかったのです。」(松成 氏)。

Azure の機能とマイクロソフトの技術支援で、クラウド活用を加速させる

既述の通り、マーザでは兼ねてからクラウドの実用性を強く感じていました。しかし、システム設計や業務設計の難航もあり、クラウド活用の一歩が中々踏み出せなかったといいます。そんな同社の背中を押したのは、マイクロソフトのソリューションでした。

ギデ 氏は、世にある大手クラウドはいずれもレンダリング用途に有用な機能を有していたと説明します。では、なぜ Azure がその中から選ばれたのでしょうか。

「各ベンダーと商談を重ねる中で、マイクロソフトには特別なものを感じました。一言で表すならば " 熱量が違う" のです。単にサービスを提供するのではなく、我々の課題に一緒になって取り組んでくれる。IT と業務プロセスの双方で最適な設計を考案してくれる。私たちが頭を悩ませていたのは、正にこうした " 設計の支援" でした。同社を選択すれば早期にクラウド活用を果たすことができる、そう判断したのです」(ギデ 氏)。

クラウド活用に向けたマーザの歩みは、Azure、Autodesk に深い知見を持つネクストスケープをパートナーに迎え、大きく加速しました。株式会社ネクストスケープ システムインテグレーション事業本部 クラウド推進部の濵野 晶彦 氏は、Azure にはレンダリング用途で有用な機能が揃っていると述べ、ジョブ管理とコンピューティング管理を提供する Azure Batch を例に、こう説明します。

「今回の設計では、『Job Center』から 2 種の処理を Azure へ投げています。『Job Center』はユーザーが投入するジョブに応じて、はじめに Azureのインスタンスを起動・終了する処理を投げます。ここで Azure Batch を介することにより、クラスタ構成のコンピューティング環境を即座に増減することが可能です。そしてこのコンピューティング環境に対して今度はレンダリング処理を投げることで、『Harvester』と同じ業務プロセスでありながらクラウドのリソースを自動制御できるという仕組みを実現しています」(濱野 氏)。

• Azure を活用したレンダリング環境のアーキテクチャ設計。インスタンスを起動・終了する処理とレンダリング 処理とを分けることで、クラウドのリソース制御を自動化している。濱野 氏は、「マーザ様は『Job Center』という独自の Render Manager を利用していますが、Azure Batch はジョブ管理の機能も有するため、Azure Batch 自体を Render Manager として使用することも可能です。」と、Azure の優位性を強調した

試験的な活用から、本格的な活用へ

マーザでは 2019 年、試験的ながら Azure の活用をスタートさせています。その成果は、環境の整備から間もなく形となって表れました。

同社では 2019 年の 1 月から 3 月にかけて、オンプレミスの処理リソースが足りなくなる事態が発生しました。秋重 氏は、「大きなプロジェクトが複数重なったのが理由ですが、幸いクラウドのレンダー ファームを整備済みだったため、過不足なく処理リソースを提供できました。仮にオンプレミスしか環境がなければ、ユーザーへレンダリング待ちを強要していたでしょう。現場の制作プロセスに少なくない影響を及ぼしますから、クオリティの低下や納期遅れが生じていたかもしれません。」と述べ、Azureでレンダリング環境を整備したことを高く評価します。

また、松成 氏は、レンダリング リソースでクラウドを活用する場合、多くはコスト条件が合わないと言及。そうした中で今回、オンプレミスとほぼ同水準のコストで Azure が利用できたと、ギデ 氏とともに理由を語ります。

「クラウドのスケーラビリティはクリエイター目線でも大変魅力的です。ただ、コストが肥大化するのであれば、オンプレミスの環境を拡張すべきと判断せざるを得ません。今回クラウド活用にチャレンジできたのは、ネクストスケープから低優先度の仮想マシン (VM) を紹介いただいたことも理由にあります。VM 自体の料金を引き下げることで、オンプレミスと同等のコストでスケーラビリティのある環境を利用することができたのです」( 松成 氏)。

「低優先度 VM にも課題はあります。SLA が約束されないことです。今回は 3 か月と期間が決まっていたため活用に踏み切れましたが、常に利用するならば別の策を考えねばならないでしょう。これを見越して、ネクストスケープからは 1 年間または 3 年間の VM を予約するという Azure Reserved Virtual Machine Instances も案内頂いています。低優先度VM に近いコストで通常の VM が利用できるため、今後は、スポットでは無く常時稼働可能な環境として Azure を利用することを考えています」(ギデ 氏)。

第二のレンダー ファームにするために

Azure を、常時利用可能な第二のレンダー ファームにしていく。ここに向けて、マーザとネクストスケープ、マイクロソフトでは、アーキテクチャの最適解に関する議論を現在進めています。

Azure Reserved Virtual Machine Instances を利用すれば、VM の料金は引き下げられるでしょう。ただ、シークエンスを構成する各種情報がオンプレミスにあっては、レンダー ノードから読み込みを行う度に多量のトラフィックが発生とします。

濵野 氏は、「1 月から 3 月の利用実績では、CG の素材データの転送によって全体費用のおよそ 4 分の 1 がデータ通信費で占められていました。マイクロソフトから Azure File Sync や Avere vFXT for Azure、Azure Data Box などオンプレミスのデータを Azure に簡単に送信できるサービスがリリースされていますので、必要なデータをあらかじめ Azure に同期することによって、ストレージ費用はかかるものの全体のコストは引き下げられるかもしれません。様々な可能性から、第二のレンダーファームとして最適な形を検討してまいります。」と意気込みを見せます。

これを受けてギデ 氏は、「公開前の作品に関わる情報を外部に保管して良いのか、そんな声がもしかするとあるかもしれません。ただ、Azureは極めて高い信頼性を有しています。IPsec によるセキュアな通信も敷いていますので、ストレージ サービスを利用するとなった場合にもパブリッシャーの皆様には合意いただけると考えています。」と語りました。

レンダリング リソースに左右されることなくプロジェクトが進められる。ここへ向けたマーザの試みは、クリエイターが創造的業務に注力できる職場づくりへと繋がっていくはずです。

[PR]提供：日本マイクロソフト