(レポート) CMP404: Walt Disney Animation Studioでのクラウドレンダリング #reinvent

(レポート) CMP404: Walt Disney Animation Studioでのクラウドレンダリング #reinvent

Clock Icon2015.10.08

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

丹内です。掲題のセッションをレポートします。

スピーカー

Usman Shakeel - Principal Solutions Architect, Amazon Web Services Kevin Constantine - Sr. Systems Engineer, Walt Disney Animation Studios

前提

そもそもレンダリングにAWSを使うというのは、よくあるユースケースの1つです。

  • ゲーム
  • マーケティング
  • ライフサイエンス
  • アニメスタジオ
  • エンジニアや建築

このセッションでは、アニメーションやVisual Effectの業界について取り上げます。
また、アニメーションにおけるレンダリングでも諸々もワークフローがあります。

  • アセットマネジメント
  • コンポジット
  • レンダリング

その中でも「レンダリング」に絞ってのプレゼンテーションでした。

なぜAWSが必要か

動画制作ビジネスにおいて、レンダリングに要する計算機リソースの需要は急激に変動します。
フィルムのリリース期限が近づくにつれてだんだんと需要が上がっていき、多数のサーバが必要になります。
しかしレンダリングが完了して次のワークフローに移ると、レンダリングでの需要はほぼ無くなります。
典型的な、「オンプレだと応えられない動的な計算機リソースの需要に対応しコスト最適化を行う」ということがAWSで実践可能だったということです。

レンダリングファームに求められる性質

セッションでは「レンダリングファーム」という聞き慣れない単語が出てきましたが、これはレンダリング処理をしてくれるAWS上のシステムを指します。
動画制作会社のデータセンターにアセットが配置され、それがレンダリングファームでレンダリングされるイメージです。
だいたいこんな感じです。

IMG_20151007_150454 copy

このシステムに求められる性質として、以下のものが挙げられます。

コスト最適化

計算機リソースは需要に応じて必要な量を柔軟に投入できる必要があります。
レンダリングに必要なコストは非常に高額であるため、必要なリソースを確保しつつ、不要になったらすぐ捨てられることが重要です。

project-based disposable infra

上の項目とも関連するのですが、処理を行うEC2は状態を持たない(disposable)である必要があります。
たくさんのインスタンスを起動し、処理が終わったらすぐ停止するような使い方では、いちいち設定が必要なインスタンスだと管理コストが高くなってしまいます。
「必要な量を柔軟に投入できる」ためには、いつでもどのインスタンスでも追加・停止を行えるような性質が必要となります。

実装上はどうか

EC2なら「必要な量を柔軟に投入できる」ことができるのは言うまでもありません。
その上でコスト最適化のために、スポットインスタンスを使います。
問題となるのはdisposableの部分です。複数のインスタンスが共通のアセットにアクセスすることもあり必須の性質ですが、これを実現するためにSQSとEFSを使います。そのための制御プログラムを実装したそうです。

IMG_20151007_152054 copy

実際のところは、上の図の通り、動画制作会社のデータセンターとレンダリングファームをDirect Connectで接続し、アセットをレンダリングファームに送っているそうです。
必要になるライセンスはBYOLで、ソフトウェア自体はマーケットプレースから調達します。ThinkboxやAutodeskには、この使い方のために必要なElasticなライセンスモデルがあるようです。

自動化

インスタンスの投入を手でやるわけにもいかないので、自動化します。

  • cloudformationによる作成・撤去
  • RHELをベースにEBS Backed AMIを作成
  • 基本的にエフェメラルディスクのみを使う(EBSは使わない)
  • Python/Boto3でAWSを操作する管理プログラムを作成
  • AMI起動時、構成の差分適用のためpuppetを利用
  • SQSのレンダーキューを取ってインスタンスが処理を開始

ただ、スケールアウト/インはまだ手作業で行っているそうです。

ベンチマーク

オンプレよりも良いスコアが出ていました。
ただ例外的に、ディスクのread/writeがr3.8xlargeのみオンプレより悪いスコアになっていました。

感想

セッションではベンチマークについてより詳細な話も出ていましたが、そこは金で解決できるのがAWSだと思うので、それよりもまず(大抵のユースケースでは)disposableな性質と自動化が大事なのではないかと思いました。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.