前作『天気の子』から3年を経て公開となった新海 誠監督の最新作『すずめの戸締まり』。

監督自らが全カット設計した色彩をはじめ、日本各地を描く美しい美術背景、動く椅子・巨大な現象「ミミズ」における3DCGの活用、それらを全てまとめあげて最終的な画に仕上げる撮影など、全ての工程が細部にいたるまで緻密に編み上げられている。

そして、それらの制作を支えたデータ管理も重要なポイントだ。 コミックス・ウェーブ・フィルム（CWF）のシステム面を支える、システム管理部の都川眞栄氏に話を聞いた。

※本記事は、CGWORLD vol.294（2023年2月号）掲載の記事に加筆し、再構成したものです

関連記事

・映画『すずめの戸締まり』CGレイアウトからアセット、カメラマップまで。協力体制で過去最大の物量をつくりきった3DCG
・「新海監督作品に携わると、世界の見え方が変わる」映画『すずめの戸締まり』監督の緻密な画面設計を支える撮影工程

Information

クリエイティブを加速するデータ管理

システム管理部を任された都川氏は2018年にCWFに入社。当時動き出していた『天気の子』のプロジェクトにアサインされると、設定制作やCG制作、そしてシステム管理を担当した。

CWFのシステム管理部は、クライアントPC、ストレージ、アプリケーション、ネットワーク、レンダーファーム等を担当・管理し、全体のデジタルインフラを支える部署だと言える。しかし、入社前までデザイナーとして活動してきた都川氏にとって、本格的なシステム管理は初めてのことだった。

「『天気の子』では、システム管理の知識や準備が足りず、 改善点も残っていました」と都川氏。そこで本作『すずめの戸締まり』ではシステム管理の専任として、前作の反省点を活かし、業界のプロフェッショナルからのアドバイスをもらいながら様々な改善策を実践。

「クリエイティブを加速するシステム構築・運用・保守の実現」を合言葉 に、「ストレージ」、「レンダリング」、「制作ツール」の3本柱で改善を進めていった。

都川氏は「今回のシステム改善では、 クリエイターさんにとっていつも通りの使い方ができるというのが目標でした。達成できたのは本当に皆さんのおかげです。ひとりではできませんでしたね」と語る。

メインストレージを一本化するクラウドストレージ

前作までは複数のストレージを用意していたCWFだが、本作ではメインストレージを一本化することを目指した。データを集約することで、これまで悩まされてきた管理の煩雑さやデータ管理の属人化を防ぐためだ。

しかし、ストレージを設計する段階では、プロジェクト全体で必要な合計容量や同時接続ユーザー数がわからない。さらに、転送速度の高い水準での維持、ストレー ジサーバへの認証・セキュリティ面、バックアップ、そして近年流行しているランサムウェアなどによる災害等が起きた際の復旧対策といった数々のハードルを超えたストレージが求められた。

そこで目をつけたのがAmazon Web Service（以下、AWS）が提供するストレージサービスだ。

「例えばランサムウェアに感染した場合も、複数のデータセンター群で共有しているバックアップから迅速にリストアすることができます」（アマゾン ウェブ サービス ジャパン合同会社・門田 梓氏）。

2021年5月からAmazon FSx for Windows File Serverの利用を開始。途中、HDDのIOPS（1秒間に読み込み・書き込みできる回数）不足に起因する速度遅延が発生したが、Amazon FSx for NetApp ONTAPへ切り替えることで解決した。

数々のハードルを乗り越え、最終的にはCG部を除いた全ての部署で問題なくクラウドストレージに移行。前作と比べて、データ量は1.6倍以上、ファイル数は1.8倍以上となった本作だが、無事のりきることができた。

ストレージ構成

最終的なシステム構成を以下に図示する。Amazon FSx for NetApp ONTAPに切り替えた後の構成だ。AWSのクラウドとCWF内のローカルネットワークをAWS Direct Connectを使って接続している。

AWS Direct Connectは、AWS Direct Connectロケーションを経由してクラウドと物理的な専用線で接続するサービス。ここで注目したいのがONTAP Cache Serverだ。

今回の構成では、拠点間を専用線で接続しているため、ネットワーク帯域幅としては10Gbpsという数値が確保されている。しかし、拠点間は物理的な距離が離れているため、クラウド側へデータを要求してから送られてくるまでの時間、つまりレイテンシが大きくなってしまった。

データ通信をクルマの行き来にたとえてみる。クルマ（データ）は道路（通信回線）を走って拠点間を行き来すると考えると帯域幅は車線の数と言える。車線が多い分、一度に多くのクルマが走ることができるが、道路が長ければ、それだけ目的地に着くのには時間がかかる。

実際には、レイテンシが発生する原因は様々だが、今回はこの距離が大きな問題となった。そこで活躍したのがNetAppのFlexCache® テクノロジーだ。

このシステムでは、クラウド内に保存されているデータの中から、一定期間内にアクセスされたデータのみをオンプレミスサーバであるONTAP Cache Server内にキャッシュとして保存する。ユーザーがデータを開くときには、クラウド側ではなく、まずこちらのキャッシュサーバを参照するため、物理的な距離に起因するレイテンシを小さくすることができた。

ONTAP Cache Serverとクラウドの同期作業はバックグラウンドで行われており、ユーザー側が影響を感じることはない。

Amazon FSxのちがい

FSx for WIndows File Server（左）は、Amazonが提供するクラウドの中に仮想的にWIndows File Serverを立てるイメージ、FSx for NetApp ONTAP（右）はNetApp社が提供するストレージOS。こちらはONTAPのストレージサーバを利用する。

今回、両者を選ぶ際に大きな決め手となったのが、ストレージタイプのちがいだ。FSx for WIndows File Serverの場合、SSDもしくはHDDのどちらかを選択する。HDDは価格の面で、SSDではパフォーマンスの面（IOPS）でメリットがあるタイプだ。

一方で、FSx for NetApp ONTAPの場合、2つの階層をもつストレージとなっている。Volumeの上層はプライマリストレージ（プライマリティア）といい、過去7日間でアクセスのあったデータを保管しておくストレージだ。

このストレージにはSSDを採用しているため、頻繁に使われるデータはスムーズに利用することができる。また、8日間以上アクセスされなかったデータは、キャパシティプールストレージへと移される。キャパシティプールストレージはパフォーマンス面ではSSDに劣るが、その分価格面で利がある。

当初CWFでは最終的に必要な容量がわからないこともあり、費用面を考慮してFSx for WIndows File ServerのHDDタイプを選んだ。しかし、制作が進むとIOPSを原因とする遅延が発生。そこで、それを機にFSx for NetApp ONTAPに変更することとなった。

前述のFlex Cacheと組み合わせることで、価格を抑えつつも速度、容量、セキュリティを担保できるストレージシステムを構築することができたという。また、容量が足りなくなった場合でもボタンひとつで増やすことができる。バックアップは1日1回7世代分とるようになっており、万が一の事態でもデータをすぐに復旧できるそうだ。

最大300台相当のレンダーファーム

『天気の子』では、3ds MaxやHoudiniなど複数のソフトを使用しており、プログラミングのちがいからディスパッチャはそれぞれ別のものとなっていた。そのため、ディスパッチャごとにエラー確認が必要になるなど、対応が煩雑化してしまったという。

加えて、ディスパッチャの複数運用により、リソース不足も加速。レンダーサーバは初期14台用意していたが、最終的には40台ほどに。ハードウェアを追加するたびに必要となるキッティングやグルーピングの手間、電源や発熱、収納場所の確保と様々な問題が発生した。

そこで今作では、ディスパッチャをAWS Thinkbox Deadlineに統一して運用することを目標にし、併せてクラウドのレンダーファームも導入することとなったため、シリコンスタジオに依頼した。同社の井上正治氏が環境構築、サブミッタの開発を担当し、2021年9月にはオンプレミスサーバでの運用を開始。

途中、当初予定になかったHoudiniやプラグインが追加されたものの、2022年9月にはCG部でクラウドのレンダーファームの運用を開始した。最終的には1週間あたり6,200回以上、時間にして約1,200時間分のレンダリングを可能にするほどの体制を確立。オンプレミスとクラウドを合わせて、最大で約300台での同時レンダリングが実現したそうだ。

システム構成

レンダリングシステム構成。AWSとの接続等は、前述のストレージのときと同様。オンプレミスのレンダーファームのほかに、クラウド内にある仮想のコンピュータであるEC2インスタンスを使用してレンダーファームを構築。ユーザーは、サブミットツール、AWS Thinkbox Deadlineを経由して、オンプレミスやクラウドのレンダーファームへとデータを送信する。

サブミットツール

CWFのために作られた専用サブミットツール（簡易表示モード）。基本的に、ユーザーは「Group」欄のプルダウンメニューから使いたいレンダーファームを選択するだけで良い。クラウドかオンプレミスかにかかわらず、ユーザーは同じ手順でサブミットすることができる。

2種類の情報管理ツール

制作補助ツール

Googleスプレッドシート、ShotGrid、Slackの3つのツールをつなぐパイプラインのようなツール、それが制作補助ツールと撮影管理システムだ。

1つ目に紹介する制作補助ツールは、データの移動を起点として表記入と連絡を一本化するツールで、SMILE TECHNOLOGY UNITEDの高橋 涼氏に開発を依頼した。

それまでCWFでは工程ごとにスプレッドシートが作られ、制作進行スタッフが各自手作業でカット表・香盤表のスプレッドシートへ転記するというフローだった。フォーマットの統一も難しく、その結果、更新頻度が低下するだけでなく、入力ミスや記入漏れが発生する可能性も高くなり、信用度の低いデータになってしまう側面もあったという。

制作進行スタッフのひとりは「アニメーション制作では膨大な数の素材を管理するため、素材管理を行う制作スタッフの負担が大きいのが課題でし た。このツールによって素材管理の見通しが良くなり、それによって生まれた時間で他の仕事にも力を割くことができました」と語る。

この制作補助ツールの導入によって、ヒューマンエラーや手間を大きく減少させることに成功したそうだ。

• 

• 

撮影管理システム

2つ目の撮影管理システムは、本作で撮影を担当するCLIP+BISON, LLCの八木昌彦氏が開発したものだ。

撮影部がレンダリングしたムービーファイルをパブリッシャへドラッグ＆ドロップすると、それをトリガーとして、チェックフォルダへの格納、尺やテイク、コーデックの確認、スプレッドシートや各種ビューアの更新、Slackへの投稿が行われる。

「本作のファイルには全てカットナンバー、テイク、素材の種類といった情報が規則に従って命名されています。撮影管理ツールでこれらの情報をチェックしていたので、管理の自動化に役立ちました」（八木氏）。

また、前述の制作補助ツールによってSlackに投稿されたメッセージから情報を取得し、スプレッドシートに記載するツールも開発。そのため各カットが現在どの工程にあるのか、スプレッドシートを見ればひと目でわかるしくみだ。Slackへの自動連絡は該当カットのチェック担当者に対してメンションをつけて投稿されるため、見落としも防げる。

詳細・購入はこちらから