AWSを例にしたクラウドパイプラインの基礎
A basics of cloud pipeline with AWS
（株式会社ポリゴン・ピクチュアズ / スタジオフォンズ）
(Polygon Pictures Inc. / Studio Phones)
今後の会合の状況を見つつ加筆修正を含めブラッシュアップを進めていく予定です。
■基本的な構成
■Basic configuration
■概要
■Overview
最近は商用のパブリッククラウドを中心に、映像制作業界でもクラウドシステムの利用が進んでいます。特にレンダリングの分野では、各種レンダリングサービスの充実やディスパッチャーソフトウェアのクラウド対応などもあり、利用が拡大しています。
今後もこうした動きは活発になっていくと思われますが、ポリゴン・ピクチュアズやスタジオフォンズでは単にレンダリング処理を行うためだけでなく、パイプラインシステムそのものをクラウドインフラ上で動かすことも検討しています。
パイプラインシステムを高度にしていく方向性のひとつとして、データベースシステムの活用、外部スタジオとのデータ共有、ツールのWebアプリケーション化、並列処理による効率化などがありますが、こういった処理をクラウドインフラで実現するためには、いくつか検討しなければならないポイントがあります。
ここではAWSを例として、実際にクラウド上でパイプラインシステムを構築するにあたり必要となる基本的な機能について解説させていただきます。
under construction...
■Webシステム
Web System
各スタジオとの双方向な連携は、セキュリティが担保されたなかで、基本的にはWebシステムやAPIシステムなどを介して実行されます。
データベースシステムにデータを格納しながら、各スタジオからのトランザクションを処理していく必要があります。データベースシステムには大きく分けて、RDBのものとNoSQLのものがありますが、データ構造がほとんど変わらないようなデータについてはRDBで問題ありませんが、メタ情報などのような日々の運用の中でデータ構造が変更されていくような情報については、NoSQLなども活用すると便利です。
冗長性やスケールのために、WebシステムやAPIシステムなどは複数台で並列に実行できる必要がありますが、コンテナなどを使って運用することにより、運用の手間を下げることが可能です。
under construction...
■データ共有
■Data Sharing
スタジオ間で共有が必要となるデータもクラウドシステムを介してデータ転送をする必要があります。ワークフローによっては大きなデータを格納する必要があり、またそのストレージの性能も要件に応じた設計が必要となります。
クラウドインフラでは一般的にオブジェクトストレージの利用が多いですが、デファクトスタンダートとなっているAmazon S3のストレージAPIと、DCCソフトウェアやCG系のミドルウェアはあまり相性が良くありません。
DCCソフトウェアやCG系のミドルウェアでは、ローカルのファイルシステムにマウントされたファイルパスベースで処理を実行するものがほとんどですので、HTTPやRESTベースのストレージシステムを使用するには工夫が必要です。
AWSではS3以外にEFSといったNFSやCIFSでマウントが可能なストレージシステムも用意されていますが、比較的高価なストレージとなっています。またクラウドのストレージは一般的に使用容量に応じてI/Oパフォーマンスもスケールしていくような設計のものが多いです。
under construction...
■クラスター
■Cluster
AWSなどではコンテナのインスタンスを管理するために、クラスターとよばれる機能が用意されています。用途に応じていくつかの種類がありますが、一般的なものにAmazon ECS(Elastic Container Service)があります。
コンテナへのタスクの割り当て、オートスケーリング、スケジューリング、またAWS内の別のサービスとの連携、セキュリティのための細かな設定が行えます。
もちろん自前でもDocker管理の仕組みを構築可能ですが、ECSを使うことによって運用を簡素化できます。ただし、Dockerのなかの機能で一部使えないものなどがあり、設計時には注意が必要となります。
コンテナでいろいろなタスクを実行していく際には、このクラスター機能を上手く使うことによって、柔軟で効率的な運用が可能になります。
under construction...
■データベース
■Database
データ構造に変更が少ない情報についてはMySQLのようなRDBを使用するケースが多く、運用するエンジニア次第でもありますが、比較的歴史がありノウハウも蓄積されているので、パフォーマンスチューニングが行い易い場合があります。
MongoDBなどのNoSQLについては、参照やデータ構造の追加がやりやすいメリットがあり、パイプライン上のメタデータなどを格納するのに向いていると思います。
更新や削除処理は多少苦手だったりしますので、ポリゴン・ピクチュアズ、では参照が多く、自由にデータ構造を追加したいデータの格納に利用するケースがあります。
NoSQLにもいろいろと種類がありますが、JSONやXMLといったフォーマットをパイプラインで利用するケースが多い場合は、ドキュメント型のMongoDBを採用するのが良いかもしれません。
under construction...
■マイクロサービス
■Microservice
近年一般的なWebサービスを中心に「マイクロサービス」という単語を耳にすることがあるかと思いますが、パイプラインのWebアプリケーションを構築する上でも、有効な考え方となります。
パイプラインは日々機能追加や改修など、頻繁にバージョンアップを繰り返していくため、単体のシステムとして構築してくと、簡単にシステムは肥大化し、複雑になったシステムはメンテナンスしずらいものとなります。
そこでひとつひとつの機能を小規模なサービスとして構築し、システム全体を小規模なサービス群として構築していきます。各サービス間はRESTfulのようなAPIで相互連携がとれるようなかたちとすることで、個別にバージョンアップを頻繁に行なったり、機能の統廃合といったことを柔軟に行えるようになります。
設計の難易度は多少上がってしまいますが、マイクロサービスを意識したシステム構築は今後欠かせない手法となっていくと予想されます。
NETFLIXなどでは数千もの小規模サービスが存在し、それらがAPIやサブシステムを介して相互連携するようになっています。
・NETFLIX Tech Blog
https://medium.com/netflix-techblog/tagged/microservices
https://medium.com/netflix-techblog/netflix-conductor-a-microservices-orchestrator-2e8d4771bf40
under construction...
■クラウドレンダリング
■Cloud Rendering
クラウドインフラでは、インスタンスを複数立ち上げることにより、オンプレミスで構築しているレンダーファームと同じような形式でレンダリングサーバーを構築することが可能です。
インスタンスのイメージを複数用意することにより、ジョブごとにレンダリングの特性に合わせたスペックのインスタンスを配置することが可能となります。
例えばGPUレンダラーのRedshiftなどは、CPUをほとんど使用しないので、CPUコア数やシステムメモリが少なく、スペックの高いGPUを載せた構成にすることによって、よりコストを最適化することができます。
クラウドサービスによっては、インスタンスの起動に時間がかかったり、システム構成に制限があるものもありますので、注意が必要です。
またインスタンスの規模に応じて、前述のストレージシステムをきちんと設計する必要があります。レンダリング処理にもコンテナを利用できるとより運用が簡素化されますが、現在はパフォーマンスや機能面で課題が多いのが現状です。
国内での映像制作パイプライン設計の多くでは、自社以外のスタジオでのWindows利用も根強く、なかなかLinuxの簡便性を活かすインフラに挑戦し辛かった経緯があります。
しかし、商用クラウドの発展もあり、もう少し計算にかかるコストさえ落ちてくれば、CPU / GPUの違いを意識しないかたちで、オフスクリーンでの計算をデフォルトとした相互運用モデルの提案をクラウド上で出来るのではないかと考えられます。
例えば、RenderMan22のXPUやArnold RendererのGPU対応も予告されているなか、本会合では単なる計算としてのGPU利用だけでなく、スタジオ間での環境の交流面としての複合利用にも焦点を当てていきたいと考えています。
under construction...
■フロントエンド
■Front-end
現在多くのレンダリングのUIは、オンプレミスでのフロントエンド設計を通して行うことが多いです。しかしながら、商用クラウド内でその計算の進捗をモニタして一定の微調整を経ての再計算指示、などなどプロダクション上の細かいニーズに応えていく場合は、フロントエンドそのものの設計見直しが重要になります。
ACESなどのカラースペスの採用やOCIOによるカラーマネジメントの仕組みを考慮して、どのようにクラウド上にこれらのシステムを構築するか、これらは今後の大きな課題のひとつでもあります。
ブラウザシステムで閲覧する画像についても、カラーマネジメントの範囲に含めるなどの対応も必要になるかもしれません。
オンプレミスの各アーティストのマシンのモニタキャリブレーションをクラウドと同期させてキャリブレーションする、などなど、会合時にはこれらの課題も議論したいと思います。
under construction...
■セキュリティガイドライン
■Security guidelines
under construction...
■リンク
■Links
・AWS WAF (Web Application Firewall)
https://aws.amazon.com/jp/waf/
一般的なファイヤーウォール機能となります。WebサーバーやAPIサーバー、データサーバーは外部スタジオも含め、複数のスタジオからのアクセスも想定されるためアクセスコントロールためのルールや制限を設ける必要があります。
たとえばWhitelistなどでIPアクセスによる制限を行う場合、WAFで設定を行うこともあるでしょう。またトラフィック監視やロギングの目的もあります。
WAFがあればセキュリティが万全とうわけではもちろんありませんが、AWSで一般的なセキュリティ対策のひとつとなります。
・Amazon Route 53 (Web Application Firewall)
https://aws.amazon.com/jp/route53/
豊富な機能をそなえたDNSサーバーとなります。グローバルにマルチリージョンで運営したり、VPC内でプライベートなDNSサーバーとしても利用できます。
バックエンドのシステム（ストレージやレンダーファームなど）などの基本的にグローバルに公開する必要がないシステムなど、プライベートなドメインで運用したいケースでも利用可能です。
・Elastic Load Balancing (Application Load Balancer)
https://aws.amazon.com/jp/elasticloadbalancing/
冗長化と負荷分散のためのロードバランサーとなります。ロードバランサーにルールを適用して各サーバーやコンテナにセッションの処理を割り振ります。
AWSでは以前からElastic Load Balancingと呼ばれるサービスがあり、Appilication Load Balancer機能はその一部でコンテナアプリケーションなどにも対応しています。
・Amazon ECS (Elastic Container Service)
https://aws.amazon.com/jp/ecs/
Dockerをベースとしたコンテナサービスとなります。自前でクラスター管理のインフラを構築せずに、APIを介してアプリケーションコンテナを利用することが可能です。
自前でコンテナインフラを構築しなくてよい運用上の利点もありますが、Docker本来の機能をフルで利用できないものもありますので、設計時に注意が必要です。
・Amazon ECR (Elastic Container Registry)
https://aws.amazon.com/jp/ecr/
Dockerコンテナのイメージを管理するコンポーネントとなっていて、Amazon ECS（コンテナサービス）と一緒に利用するのが一般的です。
・Amazon S3
https://aws.amazon.com/jp/s3/
オブジェクトベースのストレージシステムで、AWSでは最もポピュラーなストレージとなります。API経由でのアクセスとなり、このS3のAPI仕様は他のクラウドサービスでも互換仕様として採用されているほど一般的になっています。
SLAも高く、AWS内の各種サービスとも容易に連携できますが、パイプラインという観点では、一般的なNFS/CIFSなどのようなファイルシステムにマウントする機能は標準で提供されていないため、注意が必要となります。
・Amazon EFS (Elastic File System)
https://aws.amazon.com/jp/efs/
NFS/CIFSなどでマウントを可能にした、シンプルなファイルストレージとなります。自動プロビジョニングやスケールも容易で、オンプレミスで利用するようなファイルストレージと同じような感覚で利用することが出来ます。
海外でもDisney社がクラウドレンダリング等で利用されています。(https://www.slideshare.net/AmazonWebServices/cmp404-cloud-rendering-at-walt-disney-animation-studios)
使用容量の増加に従ってパフォーマンスもスケールしていきますが、S3などと比べるとまだまだコスト的に割高となります。
・AWS Batch
https://aws.amazon.com/jp/batch/
バッチジョブを実行するためのフレームワークで、実行するインスタンスリソースを自動でプロビジョニングできます。またAWSの各種サービスと連携し、スケージュール実行なども可能です。
パイプライン上のバッチ処理では、代表的なものとしてレンダリング処理やアセットのビルド処理などがありますが、既存のレンダリング管理のためのDispatcherと同様な処理を実行するにはまだ機能が不足している点もありますが、将来的に機能が充実してきた際は、パイプライン処理との相性も良さそうであり、期待したい機能となります。
以下参考までに、現在レンダリングで使用されている代表的なDispatcherのリンクを記載しておきます。
Deadline
https://deadline.thinkboxsoftware.com
Tractor(Pixar)
https://renderman.pixar.com/product/tractor
Qube!
https://www.pipelinefx.com
※会合までに資料の内容を更新する可能性があります。
※There is a possibility to update the contents of materials by the meeting.