クライアントサイドとサーバサイドでの負荷への導入編
Introduction to load on client side and server side
（株式会社ポリゴン・ピクチュアズ / スタジオフォンズ）
(Polygon Pictures Inc. / Studio Phones)
今後の会合の状況を見つつ加筆修正を含めブラッシュアップを進めていく予定です。
本資料は主に映像系のエンジニアでWebアプリケーションやサーバーサイドの開発を検討している方々を対象に、導入的な内容として記載しています。
■概要
■Overview
標準的なパイプラインでは、クライアントマシン上で各種処理が実行されていくことがほとんどかと思います。しかし昨今、1台のマシン内で実行されていく処理の負荷を考えて計算クラスターへの負荷分散などの対応を進めるスタジオも多く、はたまた遠隔地からアーティストが作業する際には、商用クラウド内で構築した計算クラスター上で動作する各種機能の提供といったユースケースも増え始めています。一方、これらの仕組みは、ウェブブラウザ経由で展開されていくことがほとんどで、今までの多くの映像制作プロダクションはブラウザ経由で提供する各種サービスの構築や運用経験が少ないことが課題となってきます。
この資料では、ウェブブラウザ経由でイントラあるいは商用クラウド内での計算クラスター上で提供される各種機能のサービスとしての構築を念頭に置きながら、クライアントサイド（アーティストの端末で稼働するウェブブラウザ上を想定）とサーバサイド （イントラあるいは商用クラウド内で稼働する各種機能などを想定）での設計構築の基礎、及び、クライアントサイドとサーバサイドでの負荷に関する基本的な知識に関して説明したいと思います。
映像系ではこれまでCG特有の専門的な技術にフォーカスして発展をしてきましたが、インフラを始めとするIT技術の発展が激しい昨今において、いままで扱って来なかったそれらのIT技術を積極的に活用していくことで、制作ワークフローやパイプラインも新しいパラダイムへと移行していけいる可能性を感じられます。しかしながら現在の標準的なパイプラインを拡張するかたちでの発展では、クラウドインフラなどIT技術のメリットを活かしきれない部分もあるように思われ、これまでのパイプライン開発で得られた経験なども踏まえつつ、ワークフローを大きく転換することによって近年のIT技術を上手く活用出来ていけるのではないかとモデレーター達は考えており、本資料のWebブラウザインターフェイスを用いたサーバーサイドとクライアントサイドの負荷における内容も、それらを念頭におきながら記載させていただいています。
under construction...
■注意して構築すべき点など
■Points to be carefully constructed
under construction...
■Webブラウザ経由での機能提供による変化
■Changes that providing functions via web browser
標準的なパイプラインでは、その機能の多くがDCCツールとして提供されているため、必然的にアーティストのインターフェイスとしてはDCCツール上のUI越しに作業を行うことが一般的です。一方でサーバーサイドでの開発や構築を検討していくなかで、アーティストに提供するインターフェイスはブラウザ経由になっていくとモデレーター達は考えています。
サーバーサイドでの開発を進めるうえで、標準的なパイプラインから離れていくことも多く、それらの基礎として下記資料にまとめていますので、ご参照いただけますと幸いです。
サーバサイドでの開発への移行と標準的パイプラインからの脱却
https://a-film-production-technique-seminar.com/fppat/materials/ppi_phones_departure_standard/index.html
標準的なパイプラインでは、レンダーファームを始めとする計算クラスターをイントラ内に設計・構築し、アーティストはワークステーションでDCCツールを用いて作業しつつ、負荷が重い処理をサーバーサイドの計算クラスターで、複数台のマシンを利用して分散処理をさせることが一般的になっていると思います。
これらの場合、マシンのスペックなどの違いはありますが、基本的にはクライアントサイドとサーバーサイド双方で同じツールや処理が実行されることから、インフラやその負荷についてはクライアントサイドとサーバーサイドでは大きく違いはありません。
しかしながら、Webブラウザをインターフェイスとし、機能自体はサーバーサイドで実装されているようなシステムを構築した場合、アーティストのクライアントサイドとサーバーサイドでは、これまでの標準的なパイプラインとは異なり、そのインフラや負荷などは双方で大きく違いが出ていきます。
またインフラリソース利用の最適化という面でも、大きな変化が発生するものと考えられます。現在のワークフローやパイプラインでは、工程ごとに行う作業とそれに必要となるインフラリソースを、アーティストに割り当てるワークステーションのスペックに違いを持たせることによって、コントロールしているようなスタジオも多く見られると思います。
例えばモデリングやリギングといった工程は、CPUコア数やシステムメモリなどは、他工程に比べスペックの低いワークステーションを利用していたり、またはFXやライティングなどは、イテレーションのために、実際のレンダリングやシミュレーションといった作業もローカルな環境で行える必要があり、リソースが必要となるピーク時を考慮して、比較的高スペックなワークステーションの構成になっているでしょう。
これらは、必要となるピーク値での設計で各工程のマシンの構成を考えている都合から、アーティストの作業時にそれらのリソースを常時使い切っているといった利用状況にはなりづらく、逆にいえば、常時インフラリソースを余分に確保してしまっているとも言えます。
しかしながら、前述のようなパイプライン機能の処理をサーバーサイドで実行し、Webブラウザをインターフェイスとしていくパイプラインでは、アーティスト側はほぼ一様で比較的低いスペックなマシンとなり、かつサーバーサイドでは必要なときに必要なインフラリソースを要求することから、負荷に対して適切にリソースを割り当てることが出来き、インフラリソースの無駄を削減していける可能性があると考えられます。
以下では、インフラや負荷におけるサーバーサイド、クライアントサイド双方の違いをそれぞれの観点でまとめていきたいと思います。
under construction...
■サーバーサイドでのインフラと負荷
■Infrastructure and load on the server side<
アーティストのインターフェイスをWebブラウザなどにし、パイプラインの機能などは基本的にほぼサーバーサイドで実行していくような構成のパイプラインを構築していく場合、これまでローカルなワークステーションで実行していた環境とは異なり、Webブラウザ経由で複数のアーティストがアクセスしてくることを想定する必要があるため、サーバーサイドの機能をWebサービスとして設計していく必要があります。
ユーザーセッションごとの管理が必要となるため、一般的にはWebアプリケーション用のサーバーを構築し、それらがAPIのフロントエンドしてクライアントサイドと通信を行っていき、サーバーサイド内で実装されているパイプライン処理を実行していくことになります。
サーバーサイドで実行されるパイプライン機能のひとつひとつを大きく設計してしまうと、それぞれの実行環境で大きなインフラリソースを必要としてしまうことから、その取り回しが非効率になっていくケースも考えられます。商用クラウドをはじめ、近年ではコンテナ技術が活発に利用され、サーバーサイドの実行環境はコンテナ化されたアプリケーションを呼び出すといった、よりインフラをスケールしやすい構成を組むのが一般的となっています。
サーバーサイドで構築するパイプライン機能もコンテナ化できることを念頭に、ひとつひとつの機能はマイクロサービスとしてコンパクトに構築していきつつ、それらの機能を自由に組み合わせながら、Webブラウザにインターフェイスを提供していくといった設計が理想的でもあるように考えられます。
現在の標準的なパイプラインで1台のマシンで逐次実行しているような処理が、サーバーサイドで実行された場合には、細分化された機能ごとに複数のコンテナが呼び出され処理されていくことになりますが、よりマイクロサービスとして設計されている場合には、それらコンテナが呼び出される数や頻度も多くなっていくでしょう。場合によっては一つの処理に対して、数十〜数百のコンテンが呼び出されるといったことも場合によっては考えられ、さらには、作業をするアーティストが複数人となった場合には、その人数に比例して呼び出されるコンテナの数も増えていくことになります。
作業しているアーティストの人数や実行している処理の違いによって、その時々で求められるインフラリソースは大きく変化するため、これらのインフラを構築するにあたっては、一般的にはスケールの運用面でメリットのある商用のクラウドインフラを利用していくことが予想されます。しかしながら、商用クラウドは従量課金体系であることから、インフラリソース利用の無駄を削減し、必要なときに必要なだけのインフラリソースを使用していくような無駄の少ない設計を試みていくことによって、コストとパフォーマンスとのバランスが取れていくものとモデレーター達は考えています。
すべての処理をサーバーサイドで完結することが達成出来た場合、アーティストのクライアントサイドでは、Webブラウザ経由でパイプラインにアクセスし、サーバー側の機能を呼び出しつつ、それらを自由に組み合わせながら作業を行っていくといったワークフローになるでしょう。実際にはアーティストが直接的にコンテナを呼び出すことは無いでしょうし、インフラもイメージしづらい部分もあるかと思われますが、アーティストのブラウザからの指示によってバックエンドのサーバーサイドでは、数十〜数百個のコンテナが起動され、作業を進めていくといったインフラ環境になると想定されます。
これまでアーティスト自身のワークステーションで作業を行ってきた処理がサーバーサイドへ移ることのワークフロー上の変化も大きいように感じられます。
自社内、外部のスタジオ問わず、実際のパイプライン上の処理は同じインフラ環境上で実行することも可能となるため、その場合、基本的にはスタジオ間などでデータ共有や受け渡しをする必要がなく、クライアントサイドにはデータ保持せず、サーバーサイドにのみデータを保存するようなデータフローとなり、データ転送のコストやセキュリティ面でのメリットが出ていくように思われます。
パイプライン上の処理をすべてサーバーサイドで行っていくには、既存の標準パイプラインからの移行という面で課題もありますが、その実現には設計そのものの考え方を変えていく必要があるとモデレーター達は考えています。
under construction...
■クライアントサイドでのインフラと負荷
■Infrastructure and load on the client side
実際の計算処理などはサーバーサイドで実行されるため、クライアントサイドではWebブラウザ上での表示とサーバーサイドのAPIを呼び出すことが大半となり、基本的にはWebブラウザが動作する環境があれば十分となり、標準的なパイプラインでアーティストが作業に使用してたような、高スペックなクライアントマシンは必要がなくなるものと考えられます。
クライアントサイドはサーバーサイドのRESTfulなAPIにHTTPプロトコルでアクセスを行い、サーバーサードとやりとりを行います。RESTはWebサービスのAPIに用いられる一般的な設計モデルで、近年ではほとんどのWebAPIサービスはこのRESTfulなAPIとして実装されています。レスポンスデータにはJSONやXMLなどのデータ形式が利用されます。
DCCツールのビューポートのような3Dオブジェクトの表示を提供する際は、サーバーサイドのAPIにリクエストした3Dデータが、クライアントサイドにJSONなどのフォーマットでダウンロードされ、ブラウザ上でWebGLなどを利用しながら描画されるため、それらの表示が可能なスペックのGPUは必要となります。
しかしながら、そもそもWebブラウザをインターフェイスとした場合、都度サーバーサイドから巨大なアセットデータを、ネットワーク越しにクライアントサイドにダウンロードしてくることは非常に時間的なロスとなるため、例えばバウンディングボックスやプロキシデータなど、軽量なデータで作業をしつつ、プレビューやレンダリングの確認には、サーバーサイドで実行された結果画像のみをクライアント側に転送し、確認できるようなワークフローへと変更していく、といったこれまのでフローとは異なるワークフロー上の工夫も必要になってくるものと思われます。
作業開始時にサーバーサイドのAPI経由でデータを取得し、Webブラウザ上で作業を行った後に、そのデータはJSONフォーマットなどでサーバーサイドAPI経由で返送され、データはサーバー側に保存されるようなデータフローとなるでしょう。
クライアントサイドでは、ネットワークに対する負荷への対応が重要になってくると考えられますが、なるべくサーバーサイドとクライアントのWebブラウザとの通信量を低減するようなシステム設計にすることが重要で、標準的なパイプラインでは、アーティストの自由度を高めていくことを目的に、高機能なUIを提供していくことも見受けられますが、サーバーサイドとWebインターフェイスという構成のパイプラインでは、機能面におけるアーティストの自由度を担保しつつ、無駄のない必要最低限なインターフェイスを提供していくことが大切になってくるのではとモデレーター達は考えています。
また、アーティストのインターフェイスがブラウザとなった場合にケアしなければならない点として、カラーマネージメントの課題があります。近年ではOCIOやSynColor、ICCといった手法がカラーマネージメントシステムに用いられることが一般的となっていますが、アーティストがブラウザ越しに画像を確認する場合、そこでのカラーマネージが行えるような仕組みも必要になってくるでしょう。ブラウザ側でのプロファイルの適用のためのソリューションや、外部スタジオでのモニタのキャリブレーションなども課題となってくると思われます。
本資料では課題として提起するに留めたいと思いますが、この課題については継続して会合シリーズのなかで取り組んでいきたいと考えています。
under construction...