サーバサイドでの開発への移行と標準的パイプラインからの脱却

Transition to server side development and departure from standard pipeline

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

(Polygon Pictures Inc. / Studio Phones)

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

We plan to continue making additions and emendations based on the situation at seminars hereafter.

translated by PPI Translation Team

■概要

■Overview

今回の会合では、サーバーサイドでのモデリングについてディスカッションを行いますが、この資料では、サーバサイドでの開発への移行と標準的パイプラインからの脱却に関する背景及び、過去とどう異なる展開を見込んでいるかなど、ディスカッションのために少し考えをまとめていきたいと思います。
加えて、実際に既存のパイプラインで行われている処理をサーバーサイドで実行出来るよう移行していく際に生じる、様々な課題に関して整理を進めていきたいと思います。

In this session we will hold a discussion on modeling on the server side, however in these materials I would also like to sum up a number of thoughts in order to discuss the background to this transition to server-side development and departure from standard pipelines, and how development is expected to be different than in the past.
In addition, I would like to clarify the various issues which have occurred when making the processes of an actual, existing pipeline able to be executed on the server side.

■背景

■Background

近年、商用DCCツールの機能が強化されていくなかで、開発されるすべての機能が必要になるようなスタジオはそう多くは無くなってきているようです。一方、商用DCCツールをベースとしたインハウスプラグインなどの開発は、スタジオのワークフローや制作する作品の形態にあわせるかたちでアーティストには商用DCCツールでの慣れたインターフェースとして利用しつつ、機能開発そのものは内製で進める流れも出てきています。
インハウスでの機能開発は可能な限りサーバー側にデプロイして、それを効果的にアーティストにマイクロサービスとして提供していくスタンスのインフラやパイプラインを模索しているスタジオも多いと思います。
また一部では、サーバーサイドでのこれらの環境構築を一定以上に進めた段階にあるスタジオも登場しているようななか、全てをサーバー内でデプロイし、ウェブブラウザ経由でアーティスト向けのインターフェースを提供できないか、商用DCCツールでのアーティスト制作作業データやアセットをストレージにアップロードし、それらをウェブブラウザ上のコンソール越しにインハウスの計算エンジンなどに送っていく形態での運用も増えて来たように思います。
これらの設計は、映像制作の現場よりは、一般的なIT技術やWebアプリケーションをベースとした開発環境で比較的進んだ技術でもあり、映像制作のパイプラインの設計をブラウザベースのインターフェースに切り替えていこうとする流れは、自然なもののようにも感じられます。
そこでは、サーバーサイドでの機能拡張とウェブブラウザ上でのインターフェースの設計が切り分けられていくことにより、開発者はより開発に専念し、アーティスト側には完結な操作性のみを抜き出したインターフェースのみを用意していく、このような制作スタイルへの移行が様々なかたちで模索、あるいは実践され始めた段階ではないかと思います。
これらの制作スタイルへ我々が向かっていくモチベーションはいくつもありますが、アセットサーバーとアーティストへの端末間でのアセットの通信コストの高さであったり、インハウスで構築する様々な機能の構築に使うライブラリなどの管理の面での行いやすさであったり、各スタジオごとに動機となる点は異なるかもしれません。
まだ既存の制作ワークフローとは大きな違いが発生してくるものと考えられますが、しかしながら大きなメリットとして、標準的なパイプラインをアーティストや連携するスタジオ間で強制しなくてもよく、あえて標準化を進めずにサーバーでデプロイした機能に、アーティストがアクセスして利用していくことの柔軟な制作スタイルを構築することも可能となり、制作上のパイプライン構築の自由度を得ていけることではないかと考えています。

In recent years, as features available in commercial DCC tools continue to grow stronger, it seems that many studios no longer need all of the features which have been developed. On the other hand, a pattern has been appearing in which feature development itself has been proceeding internally for development of in-house plugins which are based on those commercial DCC tools, in a format which matches the studio workflow and the title being worked on, while using the interface which artists are used to from those commercial DCC tools. I believe that many studios are searching for infrastructure and pipeline solutions where in-house feature development is, as much as possible, deployed on the server side, and then supplied to the artists effectively as microservices.
Also, among some studios who have proceeded with this kind of server-side environment setup beyond a certain level, a style of operation seems to be becoming more common in which all features are deployed on the server, with an artist-oriented interface provided via web browser, with artist work data and assets uploaded to storage and sent to an in-house rendering engine via a web browser console.

This kind of design uses the comparatively advanced technology of a development environment based on general IT technologies or web applications, rather than a video production studio; however the switch in video production pipeline to web browser-based interfaces feels like a natural progression.
So, by separating this issue into the expansion of features on the server side, and web browser interface setup, we can have development focused on preparing an interface for the artist side which isolates pure operability only, and I believe we are in the stages of starting to grasp at how to transition to this kind of work style, or just starting to put this into practice.
There are a number of motivations for us to move toward this kind of production style, but there are different factors that each studio might consider, such as a heightened cost in transmitting assets from the asset server to the artist’s console, or ease of administering libraries, etc., using various features built in-house.
The point which could be considered the greatest departure from existing production workflows, but perhaps one of the largest merits, is not having to force a standardized pipeline on artists or between partnered studios, and instead deploy features to the server without worrying about standardization, allowing us to build a flexible working style for the artists who access these tools, giving us further freedom in the construction of a production pipeline.

■パイプラインの標準化とそのデメリット

■Standardization of pipeline and its disadvantages

分業制による作業効率化と、それを支えるパイプラインの構築という過程の中で、流動性高く各スタジオ間を行き来するアーティストへのラーニングコストのケアや、パイプラインを実際に開発するエンジニアのためにも、これまでパイプラインやワークフローのある程度の標準化というものを各スタジオが意識して来たとモデレーター達は考えています。
それは細かな点で異なっている部分はあるものの、画一化といえるほどに、どのスタジオでも共通の何かという意識の元でのパイプライン構築になりがちになっているように思え、各スタジオがスタジオとしての個性を発展させるための障害ともなって来たように思います。
つまり、他社と連携し効果的に作業する上では一定のルールのもとでの協調という側面は当然必要となりますが、分業制により細分化されて関わるスタジオが増えていくほど、その制約は肥大化する傾向にあり、自然にその流れのもと、画一化されたシステム構成に向かっていってしまう、そういう側面があるようにも思えます。
アセットなどのデータトランスファーに対してその制約が強く効いて来てしまったこれらの制作パラダイムに比べ、サーバーサイドで機能をデプロイし提供していくパラダイムではその制限や制約は減っていく傾向にあります。ウェブブラウザ越しにサーバー内のアセットを扱っていく、サーバー内でマイクロサービスとして構築された機能を自由に呼び出し、作業完了後、そのままサーバー内の別の格納場所に保管する、これらの自由度はアーティストはクリエイティブな作業に必要なインターフェースだけをウェブブラウザ越しに提供され、開発者はサーバー内にデプロイする機能の開発に専念していけるのでは？とモデレーター達は考えています。これらの可能性に関しては、会合時にディスカッションを行っていきたいと考えています。

Within the process of building an efficient segmented production workflow and the pipeline which supports this, care towards running costs of artists moving between studios which is highly fluid, and also for the benefit of the engineers actually developing the pipeline, it is the belief of the moderators that pipelines and workflows up until now were created with a certain level of standardization.
While a number of finer points may differ, it can be thought that pipeline construction tends to follow a certain degree of shared understandings which could be said to be “normalization”, and I believe this has been a barrier to studios developing their own unique characteristics as a studio.
In other words, while of course there is a requirement for a set of standard rules in order to work efficiently when coordinating with another company, it can also be thought that as the number of studios compartmentalizing their workflows has increased, these restrictions have tended to hypertrophy, and based on this natural progression, have tended to head toward the building of normalized systems.
Regarding data transfer for assets, etc., compared to the paradigm wherein those restrictions have become ever stronger, the paradigm wherein features are deployed server side tends to lead to a lightening of restrictions and limitations. Handling assets on the server via web browser, being able to call up features freely as microservices, then after work is complete, simply storing the file in another location on the server, the freedom here is in supplying an interface sufficient for the artists’ creative work via web browser, while developers can focus on development of the features to be deployed on the servers; this is the belief of the moderators. I would like to hold further discussions on this during our seminars.

■DCCツールとパイプライン

■DCC tools and pipeline

一般的な映像制作におけるパイプラインは、商用またはOSSなどのDCCツールを主体にパイプラインが設計されているのもが多く見られます。DCCツールですでに用意されているアセットマネジメントやパイプラインのためのツールを使用するものから、自社のワークフローにあわせるかたちで、インハウスツールやプラグイン開発を行っていくものまで、規模に応じて様々な形態があるように思われ、またスタジオごとに自社のワークフローに合わせるかたちで、ユニークな発展をしてきている部分でもあるように思われます。
パイプライン上を流れるデータは、DCCツール固有のファイルフォーマットから、近年ではOpenEXRやAlembic、USDなどデータ保存のためのファイルフォーマットはオープンソースプロジェクトなどで共通化されてきており、DCCツール間のデータ交換につてもより汎用的になってきていると考えられます。
しかしながら、共通して言えることとして、日々DCCツールに便利な機能が追加されていくなかで、制作における処理の大半をDCCツール内で行うようになってきており、その依存度が高まるなかでDCCツールのフレームワークやAPI仕様に準じたパイプラインを構築していく傾向もあるように思われます。
またDCCツール側の仕様変更にあわせるかたちで、パイプラインをアップデートしていく必要もあり、時にはそれらがスタジオの考えるワークフローや方向性と異なるケースもあることから、意図せずメンテナンスコストを上げる結果となってしまうこともゼロではありません。特に規模が大きいパイプラインを構築しているようなスタジオでは、それらアップデート作業かかるコストは増大していく傾向にあると思われます。
一方で、DCCツール群は、基本的には1台のクライアントマシン環境で実行されることがある種前提となっており、昨今のクラウドサービスにおけるサーバーインフラ上でパフォーマンスを発揮していくためには、課題が多いように思われます。クラウドインフラを意識したサーバーサイドでの開発を検討するうえでは、既存のDCCツール内部で行われているような処理を細分化し、マイクロサービスとしてインフラ上で実行していくような設計へと変更が必要となり、DCCツールの利用を前提とした場合では対応が困難になることから、パイプラインの設計を見直すなかで、既存のDCCツールに依存している部分についてはそれらを別の機能として開発していくことが必要ではないかとモデレーターは考えています。

The pipeline in a standard video production mainly uses commercial or perhaps OSS DCC tools. I believe this can take a number of forms, from simply using the asset management and pipeline tools pre-packaged with those DCC tools, up to developing in-house tools and plugins to fit the studio’s workflow, and depending on the studio there are also parts where unique developments can be made to fit that studio’s workflow.
Data transmitted over these pipelines can also be in the proprietary file formats of those DCC tools, to the shared, open-source project data storage file formats such as OpenEXR, Alembic, or USD which have appeared in recent years. In this way the exchange of data between DCC tools can also be thought to have become standardized.
However, one thing that can be said to be in common, is that as convenient features have been added to the DCC tools used every day, more of the processes involved in the production have come to be done in those DCC tools, and as the dependence on these tools grows, pipeline constructions has tended to follow these DCC tools’ frameworks and API specifications.
Also, by further matching specifications on the DCC tool-side, it becomes necessary to update the pipeline, and occasionally this direction and workflow may differ from what the studio wishes, in some cases increasing unintended maintenance costs. Particularly in studios constructing large-scale pipelines, this can lead to increased costs for work relating to these updates.
On the other hand, these suites of DCC tools are generally assumed to be running on a single client machine environment, and recently as good performance has been demonstrated using server infrastructure on cloud services, it seems there are a lot of potential issues to be discussed. In looking into server-side development taking cloud infrastructure into account, changes to the setup need to be made in order to have the kinds of processes performed internally in existing DCC tools broken down and run on the infrastructure as microservices. Assuming that DCC tools will be used also adds difficulty in addressing this; while reviewing pipeline planning, regarding the parts that are dependent on DCC tools, it is this moderator’s belief that we will need to develop these as different features.

■サーバーインフラとマイクロサービス

■Server infrastructure and micro service

クラウドインフラでは、仮想化やコンテナ化されている環境が一般的で、マイクロサービスとして設計された処理が実行しやすい環境であるとも言えます。マイクロサービス化しておくことで、柔軟なスケールが可能なクラウドインフラのメリットを享受できるようになると考えられますが、パイプラインをサーバーサイドでの構築に向けて開発をしていくうえでは、それらのインフラ特性を考慮した設計が必要があると考えられます。
DCCツールは様々な機能をひとつのアプリケーションとして実装しているため、起動そのものに時間がかかってしまったり、起動するだけでも多くのリソースを必要とする場合がほとんどです。標準的なパイプラインでは、DCCツールはアーティストのクライアントマシン環境で実行されていくため問題になるようなことはありませんが、サーバーインフラのコンテナ上での実行を考えた場合、ひとつのアプリケーションとしては規模が大きすぎるため、サーバーサイドのインフラ目線では、内部で行われている処理を、より軽量なかたちで実行できる形態へ切り出して実行していくことが出来ると、サーバーサイドの実行でより高いパフォーマンを得られていけるものと思われます。
しかしながら、既存のDCCツールの機能をユーザー側で切り出したり、カスタマイズすることは難しく、DCCツールのAPIを駆使したとしても、それらの実現は難しいように思われ、コンテナなどのサーバーインフラに適したかたちへの対応は、DCCツール越しには難しく、現状ではインハウス開発でのみ対応が可能な状況かもしれません。
マイクロサービス化されたコンパクトな機能を自由に呼び出して、組み合わせることが可能になると、クラウドインフラでのコンテナ利用による計算クラスターのスケールメリットを得られやすくなり、短時間で多くの計算リソースで一斉に計算させるといったことや、高性能とはいえ、1台のワークステーションで処理できる範囲には限界があったような処理についても、それ以上の計算リソースを割り当てて実行するインフラを構築できる可能性が出てくるでしょう。
またデータのI/O面においても、クラウド上のストレージ特性を考慮する必要があると思われます。DCCツールはファイルシステムにマウントされたファイルパスベースでのI/Oがほとんどですが、クラウドストレージではRESTfulなインターフェースを持つオブジェクトストレージが一般的であるため、データI/Oそのものの設計を作り変えなければならなくなってしまいます。
それ故、これまでの標準的なパイプラインをそのままサーバーサイドで実行する形態では、クラウドインフラ上での性能を引き出すことが難しく、サーバーサイドでの実行を前提に根本的な設計変更を求められるため、既存のシステムでのノウハウやツールなども作り変えていく必要があり、標準的なパイプラインから離れていくといった側面から、それらの多くをインハウスで開発するなど、DCCツールを利用しないような形態も検討していく流れが出てくるように思われます。

In cloud infrastructure, virtualized or containerized environments are the standard, so this can be said to be an environment in which it is easy to run processes designed as microservices. By turning these into microservices, I believe we can feel the merit of cloud infrastructure in this flexible scalability, but as we move toward developing the pipeline on the server side, I believe we will need to take the characteristics of these infrastructures into consideration.
In order to implement various features of DCC tools in a single application, launching the application will take time, and even just launching will require a lot of resources in most cases. In a standard pipeline, as the DCC tools are run on a client machine used by the artist, this will not be a problem; but in the case it is run on a container on the server infrastructure, since the scale of a single application is so large, from the perspective of the infrastructure on the server side, if it would be possible to switch to a format that is lighter to execute I believe we could achieve better performance server side.
However, isolating and customizing the features found in existing DCC tools and serving these to the user side would be difficult, even using the DCC tools’ APIs, and handling this in a form suitable to server infrastructure, such as a container, would be difficult via the DCC tools, and so at present in-house development may be the only option.
If it is possible to package and serve these features freely as compact microservices, it would be easy to gain the scalability merits of render clusters through containers on cloud infrastructure, and use a large amount of render resources at once within a short period of time; and for processes which have limitations on how much they can be performed on single workstations - even high-powered machines, it would be possible to build an infrastructure system where the excess render resources are allocated and run as necessary.
Also on the data I/O side, we need to consider the particular characteristics of storage on the cloud. Most I/O with DCC tools happens based on file paths mounted on a file system, but as cloud storage tends to use object storage with a RESTful interface, we will need to redesign the entire data I/O blueprint.
Therefore, simply running an existing standard pipeline as is on the server side makes it difficult to extract the advantages of cloud infrastructure, and requires us to change the fundamental setup to one which assumes server-side execution, which requires rethinking both our know-how of existing systems and the tools, and from the perspective of moving away from the standard pipeline, I believe we will move to a format of not using DCC tools and see an increase in in-house development.

■ユーザーインターフェイス

■User interface

標準的なパイプラインでは、多様なアーティストがなるべく慣れ親しんだインターフェイスで作業ができるように、DCCツールのAPIに依存しつつも、UIとしての機能が豊富で汎用性のある設計が好まれています。これらは長い期間にわたりアーティストからの要望にこたえるかたちで発展してきた経緯もありますが、クライアントアプリケーションとしての実装上の自由度の高さから、複雑なUIを構築するといった傾向もあるように思われます。
一方でサーバーサイドでの開発では、UI/UXはブラウザベースでの実装が主体となり、またインターフェースと実際の処理とのやりとりをネットワーク越しに行う場合もあるため、タイムラグや同期処理など、スタンドアロンのアプリケーションでは気にする必要がなかった処理ロジックについても対応が求められていきます。また、JavascriptやHTML5などの進化により、高機能なUIを作れる環境も発展してきてはいますが、そもそもブラウザベースでスタンドアロンのアプリケーションと同等のUI機能を構築することは難度が高く、標準的なパイプラインのインターフェースに慣れたアーティスト目線では、UIの機能不足として感じられてしまうこともあるかもしれません。
しかしながら、標準的なパイプラインではDCCツールごとにAPIの仕様が異なるため、DCCツールごとに個別にUIを開発していく必要があり、DCCツールのバージョンアップに対応するメンテナンスも含め、非常にコストがかかる設計となっています。

それに比べて、個々の機能をインハウスでサーバーインフラ上に開発を進めていくことによって、機能とインターフェイスを切り分ける設計も自由に行えることから、マイクロサービス化された機能を呼び出して利用していくためのインターフェイスは、必要最低限なUI/UXの提供していくかたちで、DCCツールで用いられているインターフェイスに比べ簡素化していくことも可能になると考えられます。
これらの変更は、UIとコンテナで実行する機能のみを開発しデプロイしていくというシンプルなシステム構成にしていくことが可能であるという利点もあり、状況によっては開発やメンテナンスコストも下げていくことができるかもしれません。
サーバーサイドでの開発を考えた場合、これまでのDCCツールと同様なUIをアーティストに提供することを前提とせずに、サーバーサイドで開発、実装することによるメリットとのバランスを考えながら構築していくことが重要だと考えます。アーティストにとって最適なブラウザベースのUI/UXにはどのようなものか、これらの議論について本会合でも参加者のみなさんとディスカッションしていければと考えています。

In a standard pipeline, so that numerous artists can work with a familiar interface, while depending on the DCC tools’ APIs, as a UI something that is planned to be generic with a broad array of features is desirable. While these have been developed over a long time in order to meet artists’ demands, due to the high level of freedom from implementing these as a client application, these have tended toward the creation of complicated UIs.
On the other hand, with development on the server side, as the UI/UX is based on a browser, and also as the interface and its interactions are handled over the network, it requires paying attention to process logic such as time lag and synchronization processes, etc., which did not require much attention with standalone applications. Also, due to advances in Javascript and HTML5, etc., the environment to create an advanced UI has been developed, but the difficulty in creating a UI in a web browser with the same level of features as a standalone application itself is high, and from the point-of-view of an artist used to working on the interfaces in a standard pipeline, it may feel the UI lacks functionality.
However, in a standard pipeline as the specifications of the API differs with each DCC tool, a separate UI for each DCC tool needs to be developed, including maintenance each time the DCC tool version is updated, which increases costs dramatically.

Compared to this, by proceeding with development in-house on the server infrastructure for the individual features, we are free to delineate planning of features and interface, and for the interface in order to call up and use features which have been turned into microservices, by supplying a UI/UX which meets the minimum requirements, I believe we can simplify this in comparison to the interfaces used in DCC tools.
These changes have the benefit of building a simple system in which only the UI and features to be run in the container are developed and deployed, and depending on the situation it may also lower development and maintenance costs.
If we do consider development on the server side, I believe it will be important to build this while considering the balance of the merits of server side development and implementation, without assuming that we will be supplying this to the artists with the same kind of UI as in DCC tools up until now. I believe we will need to consider what would be the most appropriate browser-based UI/UX, and discuss this with the members of these seminars.