映像制作パイプラインと計算資源

Film production pipeline and computing resources

（株式会社ポリゴン・ピクチュアズ / スタジオフォンズ）

(Polygon Pictures Inc. / Studio Phones)

今後の会合の状況を見つつ加筆修正を含めブラッシュアップを進めていく予定です。

■概要

■Overview

昨今、レンダーファーム以外の用途での計算クラスタの構築の機会が増えて来ました。商用クラウドの充実で、これらの可能性も飛躍的に広範囲に広がってきています。この記事では、会合参加のアーティストさんやシステム設計者を念頭に、少し利用の可能性に関して現状理解を整理したいと思います。とはいえ、執筆段階では我々含めて各社にさほどの経験もないことから、完成度の落ちた議論の叩き台程度の文章であると理解し読み進めて下さい。

映像制作分野では、計算クラスタに計算を分散させて処理する機会が増え始めた段階です。基本的にはレンダーファームの拡張として、レンダリングの前処理として幾つかの処理を挟む、計算クラスタの１ノードを占有し流体シミュレーションなど再帰的処理の必要な高負荷計算を行っていく、数ノード占有しての並列計算でデフォーマを動かしていく、などなど、慣れた形式での発展が現在は多いです。
しかし一方、昨今よく話題になるマイクロサービス化のように、小さいサービスの組み合わせで様々な種類のサービスを提供する形態は徐々に映像制作パイプラインにも取り入れられ初めています。パイプライン上で自動化対象となる処理が増えていくにつれ、それらの多くは計算クラスタ上で分散処理されることになることも増え、それらに対する汎用的な仕組みの構築により、また新たな表現手段の可能性も増えていく、そういう展開になればと期待するスタジオも多いと思います。

例えば、サーバサイドでのプロシージャルモデリングなどをサポートし、スタジオ内のアーティストのby handでのモデリングへの支援とすることも視野に出てくるでしょう。
つまり、by handの制作と、by pcの制作の緩い融合が始まる時代になって来ているという意味です。現状出ているワークフローでさえも、例えばサーバ内で、過去のこの時期のメッシュアセットの全てに対して、これこれこういう設定で全てtextureをベイクしましょう、などといった指示を投げるユースケースも登場して来ています。自動でのラッシュ生成や、その生成した動画を遠隔地のスタジオにデリバリするためのCDN的な仕組み、遠隔地から商用クラウドにアクセスしてそこで行うプロシージャルモデリングやスカルプティング、などなど、今後の映像制作のスタジオ環境は益々多様化していくと見込んでいます。現在はこれらの工夫は各スタジオで行われることが多いですが、商用クラウドもそのサービスを劇的に発展しているため、近い将来爆発的にこれらの機能が増えて行ってもおかしくありません。
それらをスタジオレベルで構築運営する際は、各アーティストの視点での無作為な操作を生成しての自動テストなどの完備を通してユーザとしてのアーティストへのUXもより良くなって来るでしょうし、そもそもスマートスタジオの登場もそろそろではないかと考えています。今までのスタジオという固定された概念での制作ではなく、広い意味での連携を見据えたスタジオ設計が近年のホットトピックになるとも言えます。
会合ではこれらの可能性に関して議論すると共に、あくまでもスタジオ単位でそれらのサービスを構築していく際の、可能性や課題、期待したいものに関して話したいと思います。

ここで少しオンプレミスでの制作環境構築特有の課題をまとめて行きたいと思います。

1.計算資源そのものの選択
レンダーファームのみならず様々な計算が分散処理対象と成り得ていく昨今では、分散処理を各計算クラスタ内で行う以上、その計算に合ったCPU、メモリ、ストレージの選択を行いジョブをクラスタに投げていくことが必要になって来ています。そこでは、CPU,GPUの各種メモリの容量は？といったことから、L2,L3キャッシュの詳細は？、この計算ではXeonのどのシリーズを使うと最適か？、などなど、HPC分野で考えていくような、様々な工夫を考えていくことになっているとも言えます。しかしながら、我々映像制作を扱うインフラのスタッフは、なかなかこれらのノウハウに今まで接する機会がなかったかと思います。しかし考えて行かないといけない課題であることは明らかです。映像制作が他分野に比べて変化も早く、映像制作特有の単語や知識も必要になることから、なかなか外部の専門家をいきなり連れてきてお願い、というわけにも行きません。
スタジオ内の研究開発チームが日々実装する様々な機能の性能を見つつ、今必要な計算資源を用意していく、それらを大規模に稼働させる、商用クラウドであれば行い易いこれらの処理も、オンプレミスではかなりの難度を生じていくと思います。
会合ではこれらに関していくつかの実践的な問題提起を行う予定です。

2.スケジューラの見直し
レンダリングだけを計算クラスタに投げるのであれば、今までのレンダーファームのスケジューラやディスパッチャで恐らくなんとか成ります。
しかし少し想像してみて下さい。前述のサーバサイドででのプロシージャルモデリングをイントラで稼働させたとして、その機能にアクセスしたいモデラーが一定数いると考えてみます。サーバへの要求はモデリングの過程で頻度高く行われていくと考えれば、場合によっては、レンダリングの数百倍程度の回数の小さな小さな計算の分散処理が必要になるかもしれません。
多くの場合、スタジオ内ではレンダリングに用いる計算資源と同じ計算資源でこれらを構築しようとするでしょう。その場合は、今までのレンダーファーム向けの様々な仕組みでは、計算資源の現在の状況把握さえ困難になるでしょうし、そもそも効果的に分散処理を仕掛けるスケジューラ無しにはまともに稼働はしないと思います。

3.様々な負荷の分散
サーバ内で全てのアーティストの様々な要求に応え、それらの計算を計算クラスタに分散させていく、これらは考えただけでも今までにないインフラへの要求を生んで行きます。それらは、「AWSを例にしたクラウドパイプラインの基礎」で説明した様々な仕組みに近い仕組みを自然とオンプレミスの環境にも必要として行きます。

4.トラッキングの見直し
扱う処理の種類が増えていくほど、それらを瞬時に把握する、そのための仕組み作りが必要になってきます。モデラーなどのアーティストがサーバ内のプロシージャルモデリングのサービスを使う場合もトラックが必要になるでしょうし、計算クラスタがどの処理にどの程度の時間稼働し、どの程度の電力とどの程度の冷却コストがかかったかなどのレポートの生成も必要になって行きます。
これらは商用の大規模ストレージに提供されているような仕組みを、計算クラスタ内でどのように実現していくかという問題も生みます。
また最も難しいと思われるのは、レガシーなオンプレミスの映像制作パイプラインに親しんでいるアーティストには、これらの感覚を掴んで頂くこと自体が難度となる点です。アーティストにとっての直感性が確保出来なければスタジオ自体の性能に影響が生じえることが予想され、今回の会合でもこれらの意思疎通の課題に関しても、議論して行きたいと思います。

under construction...

※会合までに資料の内容を更新する可能性があります。

※There is a possibility to update the contents of materials by the meeting.