Film Production Pipelines and Artist Techniques

クラウドインフラとマイクロパイプラインの詳細

Cloud infrastructure and details of micro pipeline

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

(Polygon Pictures Inc. / Studio Phones)

本資料は会合後にディスカッションされた内容を踏まえ記載しています。今後の会合の状況を見つつ加筆修正を含めブラッシュアップを進めていく予定です。

■概要

■Overview

この資料では、会合での講演「映像制作におけるクラウドインフラ拡張への課題と対策」及び「パイプラインでのクラウド利用とマイクロパイプラインデモ」で紹介した内容をもとに、映像制作分野に置けるクラウドインフラについての基礎的導入と、そこから見えて来る課題に関して説明したいと思います。
本資料は、今後の会合での考察を行いながら、ブラッシュアップを行いつつ、他の関連資料を閲覧する上での俯瞰的な役割を持つ資料として記載していきます。

under construction...

■背景

■Background

他の資料でも記載させていただいている内容ですが、簡単に再喝したいと思います。
近年、商用クラウドサービスの広がりにより、映像製作におけるオンプレミス、商用クラウドが複合してのインフラ構築の検討が課題の一つとなって来ています。
しかしながら、実際にクラウドインフラの構築とオンプレミスのインフラの構築を行いつつパイプラインのデザインを行うにはあまりに膨大な技術上の選択肢があり、なおかつ日々の技術革新が加速していく一方で、エンジニア側での設計上の難しさだけでなく、ユーザーとしてのアーティストやテクニカルアーティストへの説明も含めて、非常に難度が高くなりつつあります。

そこで、これらを構築する際の枠組みを抜き出したものとして、スタジオフォンズの協力の元、ポリゴン・ピクチュアズでは現在、マイクロパイプラインと呼ばれるフレームワークのみのパイプラインツールキットの開発に着手しています。
このマイクロパイプラインは、それそのものではプロダクションユースとして利用することは難しいものではありますが、一般のプロダクションレベルのパイプラインの多くは、このフレームワークに各社の事情で様々な機能追加が行われているものが多いと思われますが、逆に各社特有の工夫を除外した機能のみを抽出することで、今後の会合時のディスカッションでの共通知識の拡充に役立てたいと考えています。

マイクロパイプラインは、OSSなども組み入れて構成していますが、これらは実践利用よりは、ディスカッションの土台として機能を確保して行くため、インフラ構築やパイプラインのデザインを行う際の仮組みやトライアルのための開発にも将来的にはつなげて行きたいと思います。

なお、映像製作パイプラインの実践的課題に関しては、下記の資料でまとめていますので、よろしければこちらもご参照頂けたらと思います。

「映像制作パイプラインの実践と課題」
https://a-film-production-technique-seminar.com/fppat/materials/ppi_phones_production_pipeline_issue/index.html

under construction...

■クラウドインフラの基礎

■A basics of cloud infrastructure

クラウドインフラは商用クラウドサービスを展開する各社でサービス上の多少の違いはありますが、一定規模以上の商用サービスでは、基本的な機能はほぼ同じものが各サービスで用意されています。 AWSを例としていますが、クラウドパイプラインを構築するうえでの基礎的なインフラの情報については、下記の関連資料

「AWSを例にしたクラウドパイプラインの基礎」
https://a-film-production-technique-seminar.com/fppat/materials/ppi_basic_cloudpipeline/index.html

で細かく紹介させていただいていますので、そちらを参照ください。

under construction...

■クラウドインフラの特性とパイプライン

■Features of the cloud infrastructure and pipeline

パイプラインシステムで必要となる各システムについて、それらに対するクラウドインフラ上の特性について解説していきます。

●Webアプリケーション / データベース
昨今のパイプラインシステムはアーティスト向けにDCCを拡張したツールやスタンドアローンのツール以外に、複雑化したワークフローに対応するために、Webアプリケーションやデータベースシステム、APIサーバーなどを構成して、パイプラインシステムを高度化しているものも多く見られます。
クラウドインフラでは、もともとWebサービスを構築するためのインフラとして発展してきた経緯があり、仮想化されたWebアプリケーションやデータベースシステムのソリューションは充実しています。
サーバーやネットワークはすべて仮想化されおり、需要に応じてサーバー台数を増減させるといったスケール調整も容易となっており、ロードバランシグやファイヤーウォールといったネットワーク関連のシステムも柔軟に構成することが可能です。またインスタンスだけではなく、コンテナといったサービスもクラウド上で利用可能で、WebサービスやAPIサーバーをDockerコンテナ上で稼働させることができます。

コンテナはインスタンスに比べ構成が単純なため、高密度が可能であったりオーバーヘッドが少ないといったメリットがあります。また起動もインスタンスに比べ非常に高速です。
一方ですべてのコンテナでホストのカーネルを共有するため、異なるOS環境でアプリケーションを実行したり、アプリケーションごとに個別にカーネルの設定を変更できないといったデメリットもあります。

クラウドインフラでは運用を効率化するための機能も豊富にあり、インスタンスやコンテナのイメージ管理やアクセス権のコントロール、システムリソースのトラッキングなどオンプレ環境ではそれぞれ自前でいちから構築しなければならないシステムも、サービスとして提供されているため、それらを利用することで初期セットアップの手間を低減し、運用面でもコストを下げることが可能です。
また、クラウドインフラで用意されているサービスの多くはLinuxOSを前提に構成されています。パイプラインシステムのツールやライブラリをアーティストの作業環境に合わせてWindowsベースで開発をされるケースも多々あるかと思いますが、クラウド環境で実行させるには、Linux環境で動作するかたちでアプリケーションを開発することが重要となります。
普段よく利用するPythonなどはクロスプラットフォームで動作しますし、DCCツール系の処理やOSSライブラリなどもPython対応が進んでいることから、サーバーサイドの開発言語として相性のよいPythonを選択することも可能です。
また昨今のWebサービス設計のトレンドとして、マイクロサービスといった各々のシステムを小さく開発し、それらのシステム間がAPIなどを介して疎結合に動作することにより、システムの更新を個別に行えたり、ビルドの処理時間の短縮、障害時にも原因を究明しやすいといった設計手法がありますが、そのような設計に対応したインフラも構築しやすい特徴があります。

●ストレージシステム
パイプラインシステムで重要なシステムのひとつにストレージシステムがあります。ネットワーク上にファイルサーバーとして配置されたストレージシテステムにはDCCツールで私用されるデータやパブリッシュされた共有データ、レンダリングイメージやキャッシュデータといった様々なデータが格納されます。
また数百人のアーティストが同時にアクセスしたり、計算クラスターマシンからなどのアクセスも含めると、規模によっては数百〜数千台のマシンからのアクセスがあり、高いÍ/O性能が必要となります。
クラウドインフラではAWSのS3を代表とするようにオブジェクトストレージが一般的で、ストレージアクセスにRESTといったhttpベースのプロトコルでI/Oを行います。DCCツールをはじめCG系のOSSライブラリはファイルシステムにマウントされたファイルパスを必要とするため、 RESTインターフェイスのストレージをそのまま利用することは難しいです。AWSなどの商用クラウドサービスでは、NFSやCIFSプロトコルのソリューションとしてEFSやStorageGatewayなどのストレージサービスやサードパーティ製のソリューションも用意されていますが、高いI/O要件に対してスペックが十分でなかったり、オブジェクトストレージと比較してコストがかなり高くなってしまうのが現状があります。

●レンダーファームと分散処理
通常オンプレミス環境のパイプラインシステムでは、社内の環境に数百台の計算クラスター用のサーバー群を構築し、レンダリング処理を分散して行いますが、プロジェクトからのレンダリング需要には時期によって波があります。
以下は過去のポリゴン・ピクチュアズでのプロジェクトでの週間ごとのレンダリング画像のフレーム枚数となり、時期によってその週でレンダリングしなければならないレンダリング画像の枚数に大きな差があることがわかります。

これらのピーク需要に対応できるだけの台数を社内のオンプレミス環境に構築するのは、システム稼働率という面で非効率的な状況を発生させることになります。
クラウドインフラは通常利用した分だけコストがかかる従量課金制となるため、一定以上の需要に関しては、クラウドインフラを使うといったワークフローを組むことによって、クラウドインフラの柔軟なインスタンスのスケールアップ機能を利用しながら、コストの最適化を行いつつピーク需要に対応していくことが可能です。
またクラウドインフラでは、多様なラインナップのCPUとメモリ構成のインスタンスタイプから必要なスペックを選択することも可能なため、分散処理で実行されるアプリからのスペック要求に合わせて、インスタンスのシステムリソースを最適化することも可能です。
AWSなどの商用クラウドでは、通常のインスタンス課金形態だけではなく、リザーブドインスタンスやスポットインスタンスなど、多様なインスタンスの利用形態が用意されており、こららのサービスを効率よく利用するためには、レンダリング用のディスパッチャーも提供されているインスタンス形態のなかから、最適なインスタンスを選択できるような仕組みが必要となってきます。
DeadlineディスパッチャーはAWSへのインテグレーションが進んでおり、ディスパッチャーとAWSの各種サービスを連携させることも可能で、インスタンスの確保やスペックの選択を自動化するといった機能も備わっています。
また、パイプライン上で発生するバッチ処理のようなタスクをコマンドラインでも実行できるような形式にしておくことで、レンダリング以外の処理も分散して実行することが可能となり、アーティスト作業環境でのツール処理待ち時間を低減するといったことにも効果的に機能します。

AWSでは分散処理のために、AWS Batchと呼ばれるタスク管理用のソリューションも用意されており、スケジュール実行や分散処理を自動化することも可能です。

under construction...

■クラウドインフラでの課題

■Challenges in cloud infrastructure

前述のとおりクラウドインフラからは様々なメリットが得られる点もありますが、オンプレミスの環境で設計・構築している一般的な映像制作パイプラインシステムを、そのままクラウドインフラへと移行しようとした場合には、いくつか課題が生じる点もあります。

映像制作パイプラインで使用するストレージシステムには、NFSやCIFSプロトコルに対応したものが求められますが、現在オンプレミス環境で構築しているようなストレージシステムと同様な機能や性能を求めることは、現状では難しい状況があります。
これは昨今のクラウドインフラではRESTfulなAPIをインターフェイスにしたオブジェクトストレージが主流のため、NFSやCIFSといったプロトコルに対応したストレージソリューションが非常に少なく、それらのプロトコルに対応したソリューションでもいくつか存在しますが、映像制作で求められるI/O性能に対して十分であるとは言えません。
映像制作分野の技術はこれまでイントラ内でのインフラを前提とした技術開発を行なって発展してきた経緯があり、特にネットワーク越しのデータアクセスの部分では、ローカルのファイルシステムにマウントされたファイルパスを利用するものがほとんです。これは近年海外の大手スタジオがオープンソースとして公開しているライブラリなどもそうであるように、映像制作の現場では、ある種当たり前のこととして設計されてきました。
もちろんこれらの背景には、I/O性能要求への優先度の高さやファイルシステムを複雑化させないといったことが考えられますが、OpenStackや仮想化技術を中心に発展してきたクラウドストレージとは相互に簡単に乗り換えを行うことは難しく、現状クラウドインフラでパイプラインを扱ううえで大きな課題となっていると言えます。
Amazon EFSなどクラウドサービス側でも比較的高いI/O性能をもつNFSやCIFSに対応したソリューションが登場しつつありますが、まだまだコスト的に高価なストレージシステムとなっています。パイプライン上、ストレージに高いI/Oを求める処理のひとつにシミュレーションキャッシュやジオメトリキャッシュなどのI/Oがありますが、これらのI/O負荷を減らすために、ファイルサーバー上に事前にキャッシュファイルを作成するようなワークフローを見直したり、レンダリング時に作成する一時的なキャッシュファイルの作成場所についても、ローカルのストレージ内に作成するとった工夫で回避できる点もあるように思います。
またパイプラインシステムの設計においても、すべてのストレージアクセスをファイルシステムにマウントされたNFSなどのプロトコルを前提に考えるのではなく、変更可能なものについてはAPI経由でストレージアクセスするような方式に切り替えていくことで、パフォーマンスを向上させることも可能です。
会合中もオンラインゲームのインフラ設計者のかたなどから、クラウドストレージの性能についての課題を感じているといった意見もあり、クラウドインフラを検討していくうえで評価を慎重に行い、クラウドサービスの発展を注視しながらパイプライン設計のなかに組み込んでいく必要があると思います。

またクラウドインフラでは基本的に従量課金となるため、パイプラインシステムとしてはデータ量そのものを削減したり、データの転送量そのものを減らすようなワークフローを構築していく必要があります。
オンプレミスの環境ではシステム投資の都合上、保有しているシステムリソースの稼働率を上げ、いかに最大限利用するかに主眼がおかれていました。一方クラウドインフラでは可能な限り無駄を排除し、必要最低限のリソース利用に抑えながら運用していく考え方が重要となります。
また、クラウドサービスは価格の変更や新しいソリューションの統廃合も頻繁なため、コストを最適化していくためにはそれらの情報に常に気を配り、常に新しいサービスとコストをトラッキングしていくことも必要になってきます。
これらは既存のワークフローで単にデータ量を削減することでは解決に至らない点も多く、データ転送量をおさえたワークフローにシフトしていくことの重要性も感じます。
加えて、レンダリングの処理をオンプレミス環境で実行する際に、何らかの不具合などにより、マシンがフリーズしたような状況となって、いつまでもそのジョブが終了しないといったこともたまに見受けられると思います。クラウドインフラのインスタンスでそれらが発生した場合、インスタンスは起動した状態が維持されるため、無駄に課金をし続けるといった状況が発生します。そのためクラウド上で実行しているインスタンスのシステム状況もトラッキングし、無駄なコストを発生させないための仕組みやフローづくりも重要になってくると考えられます。

DCCツールをはじめ昨今の映像制作ではGPUによるアクセラレーションを利用するソフトウェアが増えてきています。また自社開発のソフトウェアでもGPUを積極的に活用する流れもありますが、クラウドインフラで提供されているGPUインスタンスはまだまだコスト的に割高な印象もあり、かつ仮想化という面においてもまだまだ柔軟にGPUのリソースを切り出して使えるといったことろまで、技術が成熟しているとは言えない状況であるとも言えます。
またインスタンスの構成についてもCPUインスタンスのような柔軟な選択肢が少なく、実行させたい処理のリソース要件によっては、使用しないまま無駄となってしまうリソースが発生するケースも考えられます。
例えば、GPUを使ったレンダラーなどでは、性能の高いGPUを要求しますが、CPUについてはほとんど利用しないような挙動をするものも多いですが、しかしながら現在のクラウドサービスでは高性能なGPUを選択するとそれに比例してCPUやシステムメモリについても高性能なインスタンスしか選択できない状況もあり、オンプレミスと比較してもかなりのコスト高となってしまいます。
クラウドでのGPUソリューションについては、登場してまだ間もない時期でもありますが、今後機械学習や深層学習分野からの需要が後押しするかたちで、より柔軟な構成が組めるようなソリューションが増えていくことを期待したいと考えています。
計算のアクセラレーションという点では、現在はGPUリソースをCUDAライブラリから利用するケースがほとんどですが、OpenCLに特化したソリューションが登場し、CPU/GPUをハイブリッドに利用したソフトウェアをクラウド上で実行させることが可能になることによって、柔軟な構成のクラウドインフラを活用したアクセラレーション処理の選択肢が広がっていくように思われます。

少し違った視点からは、クラウドインフラ上にパイプラインを構築していくうえで、セキュリティへの配慮も重要となり、これらはパイプライン設計時からそれらを意識していかなければなりません。
特にこれまで外部からの直接的なアクセスが発生しないオンプレミス環境では、ある程度セキュリティ面に対するケアもイントラ内での対応に限定されていたと思いますが、クラウドインフラでは強固なセキュリティ対策を求められることとなります。
セキュリティレベルやポリシーを策定するうえでは、自社そのビジネス形態や案件ごとの契約形態において多少の違いはでてくるもと思われますが、映像、配信、メディア向けのガイドラインとして、米国のMPAA(Motion Picture Association of America)が提唱している、保護されたメディアやコンテンツを安全に保存、処理、および配信するためのベストプラクティスガイドラインがあります。
大手商用クラウドサービスをはじめ、業界内の多くの企業やスタジオでセキュリティガイドラインやコンプライアンスの基本となってきています。ベストプラクティスという位置付けとなりますが、クラウド環境を構築していくにあたり、これらを参照していくことで、グローバル基準でのセキュリティポリシーとその仕組みを検討していくことが可能です。

・MPAA Best Practices
https://www.mpaa.org/content-protection/

・AWS MPAA Compliance
https://aws.amazon.com/jp/compliance/mpaa/
https://d1.awsstatic.com/whitepapers/compliance/AWS_Alignment_with_Motion_Picture_of_America_Association.pdf
https://d1.awsstatic.com/whitepapers/compliance/AWS_Alignment_with_Motion_Picture_of_America_Association_Application_and_Cloud.pdf

・GCP MPAA Compliance Mapping
https://cloud.google.com/security/compliance
https://cloud.google.com/files/gcp-mpaa-compliancemapping.pdf

オンプレミス環境の現状での課題でもあるように、これまでの映像制作のためのパイプラインやインフラはDCCツールやソフトウェアなどの性能要求に応えるかたちで、年々その規模を大きくしてきた背景があります。
制作体制が大規模になればなるほど、より大きなインフラを必要とする傾向が強く、これまでそういった側面でのインフラの最適化が十分ではない部分があると思われますが、クラウドインフラという新しい環境を活用していくなかで、パイプラインシステムの再設計やワークフローを見直すよい機会であるとも感じられます。
これまでのオンプレミス環境をそのままクラウドインフラへと移行するだけでは、メリットが得られることもゼロではありませんが、インフラの特性を生かしきれず、性能面やコスト面でデメリットとなってしまう側面もあります。スタジオごとにこれまでオンプレミス環境で培ったノウハウや開発資産もあるとは思いますが、それらの一部を捨てるような覚悟を持って、パイプラインの設計自体を根本から見直したり、DCCツールなどに依存しすぎないワークフローを開発し、ソフトウェア側からのインフラ要件をある程度コントロールしていくことによって、クラウドインフラにより適した設計へと変革し、これらの課題を解決していく必要があるように強く思いました。
しかしながら、パイプラインの設計変更を行なっていく過程では、さまざまな試行錯誤が発生するものと予想され、多様な選択肢のなかからどのような技術を選択していくべきか、またはどういった技術開発をおこなって行くべきか、といった議論が生じるものと思っています。
本会合では、今後もそれらの課題について、さまざまな視点や角度から焦点を当てていき、そのディスカッションの場となれるような企画を推進していければと考えていますし、後述のマイクロパイプラインもそれらの議論に役立てられればと思います。

under construction...

■マイクロパイプラインの詳細

■Details of micro pipeline

前述のとおり、クラウドインフラ上にパイプラインを構築していくうえではいくつか課題があり、その解決のためには、パイプラインシステムの設計そのものを見直し、クラウドインフラに適した設計と変更していく必要があります。
それらの課題解決を目的に、クラウド環境を意識した設計を実験的に試行錯誤できるような簡易的なフレームワークをマイクロパイプラインとして会合用に作成しています。
機能としては小さく実験的ではありますが、クラウドインフラに適した設計のパイプラインシステムとは何か、といった課題の本質的な議論のために、ディスカッション時の説明用の枠組みとしてこれらを開発しています。

●アセットのエクスポートとアセットカタログ
パイプラインシステムの主要な機能のひとつにアセット管理があります。DCCツールなどで作成されたアセットはパブリッシュという行為によって、社内のファイルサーバー上に書き出され、データベースに登録されることが一般的です。
アセットの点数は数百から数千となるので、パブリッシュされたアセットを一覧で表示したり、それらのアセットのメタ情報を確認するための機能が必要になります。

　

マイクロパイプラインでは、上記の画像のようにDCCツールからアセットをOBJ形式でパブリッシュする機能と、パブリッシュされたアセットからカタログのHTMLを生成する機能があります。また、それらを一覧して確認することができ、パブリッシュ時のメタ情報なども表示しています。
特徴的な点として、カタログはHTML化されていますのでブラウザベースで確認することができ、サーバーに配置した場合にはWebアプリケーションとして機能させることも可能です。静止画のキャプチャでは分かりづらいですが、サムネイル画像を事前に生成しておらず、OBJファイルを直接ロードして、WebGLを使用して3次元ビューアーとしてデータを表示させています。
こういったカタログツールは、場合によってはスタンドアロンのツールなどで開発されることも多いですが、ブラウザベースにすることによって、よりクラウドインフラを意識したパイプラインツールへと発展させることができます。
例えば外部のスタジオで作成されたモデルデータを、データを取り寄せて自社内のDCCツールでファイルを開いて確認するといったことも、Webサーバーにアップロードされるだけで、誰もが簡易にアセットデータを確認することが可能になります。
さらにはブラウザ上での機能を追加してくことによって、そのままブラウザ上でアセットデータの形状やマテリアルを変更するといったことも出来るでしょう。
クラウドインフラでのパイプラインの課題としても紹介しましたが、なるべくデータの転送や移動をおさえていくようなワークフローが今後求められていきます。Webアプリケーション化することにより、実際の制作データを各スタジオのストレージシステムへデータをダウンロードする必要がなくなり、コストや時間の削減につながると考えられます。
このマイクロパイプラインでは、3DビューアーにOSSのthree.js(https://threejs.org)を利用しています。3Dビューアーとして必要となる機能がひと通り用意されているライブラリで、サンプルコードも多く非常に使いやすいです。2018年2月現在、MITライセンスとして配布されていますので、組み込みやすいOSSとなっています。
OpenGLやDirectX、WebGLの経験がれば、誰でもすぐに使いこなすことができるライブラリとなっています。

●RESTプロトコルとAPIによるサーバーサイドでの処理
オンプレミスの環境で設計されたパイプライン上の処理は、そのひとつひとつの処理内容が肥大したものであったり、GUIツールとして動作するものが多かったりしますが、それらをクラウドインフラで実行した場合、コンテナなどの仮想化されたインフラをスケールさせながら利用してくうえでそのインフラの恩恵を受けづらく、設計そのものが課題といえます。
クラウドインフラを意識したパイプラインシステムとしては、ひとつの処理の単位を小さくし、かつAPIインターフェイスを持つような、サーバーサイドプログラムに変更することによって、よりスケールメリットを得ることが可能になります。
計算クラスターでの分散処理を行う際にも基本的な考えかたとして有効で、システム同士がAPIを介して連携するようなマイクロサービスをコンテナで実行してくといった処理環境を構築するといった点でも相性よく動作するものと思います。
パイプライン上の分散処理と計算資源ついての事前資料も掲載していますので、関連する内容として参照していただければと思います。

「映像制作パイプラインと計算資源」
https://a-film-production-technique-seminar.com/fppat/materials/ppi_phones_compute_resource/index.html

マイクロパイプラインでは、サーバーサイドの処理自体は簡易なものとなりますが、APIを通じてサーバーにデータがアップロードされ、受け取ったデータに画像処理を加え表示する機能を実装しています。
WebサーバーはデータをアップロードするためのAPI機能があり、クライアント側からはRESTプロトコルを利用して画像をアップロードします。 RESTプロトコルはLinuxやMacからはcurlコマンド(https://curl.haxx.se)を使って簡単に通信を行うことができます。また自社のツールなどはPythonで開発されていることも多いかと思いますが、PythonのライブラリのRESTfulを使うことで、Pythonからも簡単に通信することが可能です。
マイクロパイプラインでは画像データを受け取ってRGBチャンネルを入れ替える処理をサーバーサイドで実行していますが、もちろんOBJのようなモデルデータをアップロードしたり、その他のデータについてもRESTプロトコルの通信上問題はありません。
ユーザーがサーバーサイドでの処理を自由に書き換えることによって、いろいろな処理を試行錯誤するといったことも可能になります。
最終的にはWebサーバーなどのインフラをクラウド環境に用意して実行させていくことになりますが、アーティストやTA/TD側でサーバーインフラを用意するといったことはやや手間であったり、専門的なインフラ知識が必要な場合があるかと思います。
そのためこのマイクロパイプラインでは、Webサーバーをインフラとして用意しなくても、flask(http://flask.pocoo.org)というPythonフレームワークでWebサーバーを構築し、APIを動作させています。 flaskを利用すれば2〜3行のコードでWebサーバーを構築することができ、インフラ構築が難しい環境でもサーバーサイド処理のテストや試行錯誤を行うことができます。
（ただしセキュリティ面で問題になるケースもありますので、利用の際は十分ご注意いただければと思います。）
サーバーサイドでの処理を意識し、それらをAPIを介して利用していくことで、クラウドインフラのスケール機能を効率よく使っていくことが可能になり、今後こうした実行処理のサーバーサイドへの移行はより加速し、高度に発展していくものと考えています。

今回ご紹介したマイクロパイプラインは機能的には大きなものではありませんが、クラウドインフラを意識するうえでポイントなる点をふまえ会合企画と連動するかたちで作成されています。
今後、ポリゴン・ピクチュアズではこの一連の会合のディスカッション用にこのマイクロパイプラインの開発を進めながら、会合内でディスカッションされる課題の本質を議論するための助けとなるよう、説明用の枠組みとして利用していき、そこで得られた状況などは随時会合の関連資料に記載していく予定です。

under construction...