モダンなCGパイプラインは分散されています。アーティストは別々のマシンで作業し、レンダーファームは何千ものフレームを並列に処理し、パイプラインのツールは同時に多数の要素を連携させる必要があります。
コンポジターはショットのレンダリングが完了したタイミングを把握しなければなりません。下流のすべてのプロセスは、アセットが承認されたら即座に反応すべきです。監督側が、3時間後になって「フレーム847でレンダリングが失敗した」と知る必要があってはなりません。
それでも多くのスタジオでは、更新をタイマーで確認するような仕組みや、ダッシュボードを手作業で更新する運用、タスクが完了したことをアーティストに同僚へ知らせてもらう運用に頼っており、人為的なミスが、作業を自動化すべき場所に入り込んでしまっています。
この記事では、5つのリアルタイム・コミュニケーションのパターン（ポーリング、Webhook、WebSockets、Server-Sent Events（SSE）、WebRTC）を扱います。それぞれについて、何であるか、CGパイプラインの文脈でどのように適用できるか、そしてどこで役に立ち、どこで問題が起きるのかを学びます。最後には、適切な技術を適切な課題に選び取るための明確な判断マトリクスが得られるでしょう。
CGパイプラインにおけるリアルタイム性が重要な理由
リアルタイム・コミュニケーションは、生産パイプラインにおける贅沢ではありません。
ハードウェアの稼働率は、素早いフィードバック・ループに依存します。下流のジョブが、まだ届いていないステータス更新を待っていてレンダーファームがアイドル状態になっているのは、直接的なコストです。コンポジットのジョブが、レンダーレイヤーがすべて完了したことを把握し、それが通知として届くまで開始できず、ポーリングの遅延で通知が5分後に到着するとしたら、各ショットあたり5分分のスループットの可能性を失うことになります。数百のショットと複数のファームにまたがると、ムダになったキャパシティが数日分に膨らむこともすぐに起こり得ます。
また、アーティストの反復速度も、ツールの応答性によって制約されます。アーティストがキャッシュのジョブを投入したあと、進捗を確認するためにパネルを手作業で更新しないといけない場合、作業の流れや文脈が途切れてしまいます。即時に更新をプッシュしてくれるツールなら、アーティストは文脈の中にとどまり、失敗を早期に察知し、精神的なスイッチを切り替えずにフォローアップ作業をキューに積めます。
最後に、自動化されたパイプラインは、信頼できるイベント伝播がなければ成り立ちません。手順Aが完了したあとに手順Bが自動でトリガーされるはずのパイプラインは、それらをつなぐものの信頼性に左右されます。その接続が脆弱だったり、遅かったり、取りこぼしたりすると、自動化は破綻し、人間がその穴埋めをしなければなりません。リアルタイム・コミュニケーション技術は、自動化パイプラインの「つなぎ目（コネクティブ・ティッシュ）」です。間違ったものを選ぶと、修正に費用のかかる見えにくいバグが混入します。だからこそ、私たちはこの記事を書きました。
1. ポーリング
ポーリングは、リアルタイム・システムを実装する最もシンプルな方法です。クライアントがサーバーに対して、「今あなたが持っている新しい情報はありますか？」と、一定の間隔で繰り返し問いかけます。
クライアントがリクエストを送信し、サーバーが現在の状態、または更新内容を返します。そしてクライアントは、次の間隔まで待ってから再び問い合わせます。
CGパイプラインでは、典型的な例として、レンダーマネジメントAPIに対して30秒ごとに問い合わせ、ジョブのステータスが変わったかどうかを確認するレンダーワッチャースクリプトがあります。
このスクリプトは、ファームからの呼び出しを待ちません。自ら能動的に問い合わせ、レスポンスを解析し、ローカルのダッシュボードを更新するか、下流アクションをトリガーします。
CGパイプラインにおける利点
- ポーリングは実装が簡単です。HTTPリクエストを作れる任意のツールならポーリングできます。つまり、特別なインフラが不要で、ほぼすべてのパイプライン言語やフレームワークと連携可能です。イベント駆動型インフラを立ち上げるコストが正当化できない、小規模スタジオや手早い社内ツールでは現実的な選択肢です。
- ポーリングはサーバー側でステートレスです。サーバーは、永続的な接続を維持したり、誰がリスンしているかを追跡したりする必要がありません。すでにRESTサービスとして構築されているレンダーマネジメントAPIであれば、ポーリングにはサーバー側の変更は一切不要です。
CGパイプラインにおける欠点
- ポーリングは非効率です。クライアントは変更があるかどうかに関係なくスケジュールどおりに確認するため、問い合わせの大半は新しい情報を返しません。たとえば静かな夜で、2時間のあいだジョブが完了しないような状況では、ワッチャースクリプトは不要なリクエストを何百回も送ります。スケールすると、負荷がすでに高いAPIに対して、余計な負荷を追加してしまいます。
- ポーリングは、間隔に比例したレイテンシーも生みます。30秒のポーリング間隔では、ジョブ完了のアクションが最大30秒遅れる可能性があります。上流が完了した直後に下流ジョブがキューに積まれるようなパイプラインでは、この遅延は各受け渡しに織り込まれてしまいます。間隔を短くすればこの遅れは減りますが、リクエスト数が増えるため、スケール時のトレードオフ調整が難しくなります。
2. Webhook
Webhookは、機械同士の通信におけるポーリングのモデルを反転させます。あるWebサーバーが別のサーバーに対して繰り返し問い合わせるのではなく、何かが起きたときにサーバーがクライアントを呼び出します。クライアントはURLエンドポイント（Webhookエンドポイント）を登録し、サーバーは関連するイベントが発生した瞬間、そのURLへ通知をPOSTします。
CGパイプラインでは、実用的な例として、アセットが正しいステータスに到達した瞬間にWebhookを発火させるパブリッシュシステムが挙げられます。たとえばSlackボットやパイプラインのオーケストレーターへ通知します。軽量側がlookdevアセットを承認し、アセット管理システムがその承認を記録すると、アセット管理システムは直ちにオーケストレーターのWebhookエンドポイントへ、アセットIDと新しいステータスを含むHTTP POSTを送ります。するとオーケストレーターは、ループ内にポーリングを入れることなく下流のライティングビルドをトリガーします。
CGパイプラインにおける利点
- Webhookはイベント駆動です。つまり、無駄なトラフィックがありません。サーバーは何かが起きたときにだけデータを送信し、クライアントは呼び出しを受け取ったときにだけ処理を実行します。イベント頻度が比較的低い一方で、すぐに対応する必要があるパイプラインでは、ポーリングよりも大きな効率向上が得られます。
- Webhookはサービスを適切に疎結合にもします。アセット管理システムは、通知を受け取ったあとオーケストレーターが何をするかを知る必要はありません。発火して忘れるだけです。これにより、元のシステムを変更せずにパイプラインイベントの新しい消費者を追加しやすくなります。これは、異なるツールが異なるチームに所有されているスタジオにおいて重要です。
CGパイプラインにおける欠点
- Webhookは、受信側サービスが送信側から公開可能、もしくは少なくともネットワークアクセス可能であることを必要とします。複雑なネットワーク構成、VPN、ファイアウォールが絡むスタジオ環境では、必ずしも簡単ではありません。たとえばプライベートサブネット上で動いているレンダーファームは、テスト中に開発者のローカルマシンへWebHookを容易に発火できません。
- Webhookはデフォルトで「送って終わり」です。イベントが発火したときに受信エンドポイントがダウンしている場合、通知は送信システムが指数バックオフ付きのリトライ処理やデッドレターキューを実装していない限り、失われます。この信頼性レイヤーを構築するには複雑さが増します。ジョブ完了イベントを取りこぼせないパイプラインでは、その背後にインフラが必要です。単なるWebhook連携だけでは足りません。
3. WebSockets
WebSocketsは、クライアントとサーバーの間に永続的な双方向接続を確立します。通常のHTTPとは異なり、HTTPはリクエストとレスポンスのサイクルが終わると接続が閉じられますが、WebSocket接続は開いたまま維持されます。どちらの側も、相手が開始するのを待たずに任意のタイミングでメッセージを送れます。
CGパイプラインでは、WebSocketsはライブレンダーモニタリングのダッシュボードに自然に適合します。アーティストや監督がショットの進捗ページを開くと、ブラウザがレンダーマネジメントのバックエンドに対してWebSocket接続を確立します。フレームの完了、エラー、ジョブ状態の変更がファームで発生すると、サーバーがそれらの更新を開いている接続へ直接プッシュします。ブラウザは新たなリクエストを行うことなく、ダッシュボードはリアルタイムに更新されます。
これが、Kitsuでイベントを扱うために私たちが使っている方法です。
CGパイプラインにおける利点
- WebSocketsは、インタラクティブなツールに対してWebhookより低レイテンシーを提供しつつ、ポーリングのオーバーヘッドをなくします。接続が永続的なので、更新のたびにTCPのハンドシェイク費用は発生しません。複数の同時ジョブを表示し、状態変化をミリ秒単位で反映する必要があるダッシュボードでは、WebSocketsはポーリングにはない応答性を提供します。
- WebSocketsの双方向性は、インタラクティブなパイプラインツールも可能にします。アーティストがレンダージョブを設定し、送信し、同じ画面でライブな進捗フィードバックを即座に見られるような提出UIは、WebSocketsと相性が良いです。クライアントは、プロトコルを切り替えることなく同じ接続上でジョブパラメータを送信し、ステータス更新のストリームを受け取れます。
CGパイプラインにおける欠点
- WebSocketsは状態を持つ接続であり、サーバーが管理する必要があります。レンダーマネジメントサーバーが、ファームノードやモニタリング用ダッシュボードからの大量の同時WebSocket接続（数千）をさばく場合、メモリやファイルディスクリプタのオーバーヘッドが現実的なエンジニアリング上の懸念になります。WebSocketサーバーを水平スケールするには、RedisやKafkaのような共有メッセージブローカーを用いて、インスタンス間でメッセージをファンアウトする必要があり、インフラの複雑さが増します。
- WebSocketsは、攻撃的なプロキシやロードバランサが絡む環境ではHTTPよりも脆弱です。古いスタジオ向けネットワーク基盤の中には、WebSocketのアップグレードを正しく処理できず、接続がサイレントに切断されたり、まったく接続できなかったりするものがあります。クライアント側の再接続ロジックは必須ですが、標準ライブラリでは実装が不十分なことがしばしばあります。
4. Server-Sent Events（SSE）
Server-Sent Events（SSE）は、通信が片方向で済むケースにおいてWebSocketsのより単純な代替となります。つまり、サーバーがクライアントへ更新をプッシュする一方で、クライアントは返信のメッセージを送る必要がありません。SSEは標準的なHTTP接続を使い、サーバーがそれを開いたまま維持し、シンプルなテキストベースの形式でイベントをストリーミングします。
CGパイプラインでは、SSEはログストリーミングに適しています。アーティストがシミュレーションを開始し、ソルバーの出力をリアルタイムで見たい場合、パイプラインサーバー側のSSEエンドポイントが、書き込まれるたびに各ログ行をストリーミングできます。ブラウザは1つのHTTP接続を開き、ポーリングもWebSocketの複雑さも、特別なクライアントライブラリもなく、継続的なテキストのストリームを受け取ります。
CGパイプラインにおける利点
- SSEは、サーバーからクライアントへの利用ケースにおいてWebSocketsよりも大幅に実装が簡単です。プレーンHTTP上で動作するため、設定変更なしに多くのプロキシやロードバランサを通過できます。標準的なWebスタック上で社内ツールを構築しているスタジオでは、既存のAPIサービスにSSEエンドポイントを追加するのは簡単です。
- SSEは再接続も自動で処理します。ブラウザのネイティブEventSource APIは、接続が切れても再接続し、サーバーが対応していれば直近に受信したイベントIDから再開します。ログストリーミングのツールで、短時間のネットワークの不調で出力を失わずに動き続ける必要がある場合、このビルトインの信頼性は、カスタムコードなしで価値があります。
CGパイプラインにおける欠点
- SSEは片方向です。ストリーム中にクライアントがサーバーへデータを送る必要がある場合、別のチャネルで別途HTTPリクエストを行う必要があります。シンプルなログビューアなら問題ありませんが、インタラクティブなツールではSSEが遅れてしまい、WebSocket接続のほうが適しています。
- SSEはまた、環境によってはブラウザの接続プールにも制限されます。古いブラウザでは、同一オリジンに対する同時SSE接続数が6に上限されており、パイプラインのダッシュボードが同時に複数の独立したSSEストリームを開く場合に問題になり得ます。実際には社内ツールでブロッキングになることは稀ですが、1つのページから多数の同時ストリームに依存する設計をする前に知っておくとよいでしょう。
- SSEはバイナリメッセージをネイティブに扱えません。もちろんバイナリファイルをテキストとしてエンコードすることはできますが、WebSocket相当の方式と比べるとサイズのオーバーヘッドが大きくなります。
5. WebRTC
WebRTC（Web Real-Time Communication）は、低レイテンシーかつ高スループットなデータ転送のために設計されたピアツーピアの通信プロトコルです。データチャネル自体はサーバーを経由せず、クライアント間で直接転送されます。ブラウザアプリケーションにおける動画・音声ストリーミングでよく知られていますが、データチャネルを通じて任意のバイナリデータ転送もサポートします。
CGパイプラインでは、WebRTCはライブプレビューのストリーミング、チャット、あるいはP2P転送のようなニッチですが強力な用途に向いています。たとえば、アーティストがリモートのGPUワークステーションでシェーディングやライティングを反復していて、サーバーを経由せずにローカルのブラウザでビューポートのレンダリング出力を見たい場合、WebRTCのデータチャネルが、ピクセルバッファをGPUマシンからブラウザへ単桁ミリ秒のレイテンシーでストリームできます。これは、ほとんどのWeb会議ソリューションが使っている方式です。
CGパイプラインにおける利点
- WebRTCは、データが中継サーバーではなくピアツーピアで転送されるため、ブラウザベースのストリーミングで到達できる最小レイテンシーを提供します。ユーザーがマウス移動に応じて、認識できる遅延なしに画像が更新されることを期待するインタラクティブなビューポート・ストリーミングでは、WebRTCはその条件を満たす唯一のブラウザネイティブ選択肢です。
- WebRTCは効率的なバイナリエンコードと、内蔵の輻輳制御も利用します。そのため、ネットワーク条件が変動する状況下で大きな画像データをストリーミングするのに適しています。プロトコルはビットレートを動的に適応するため、利用可能帯域に関係なくフル解像度のフレームを送るような素朴なWebSocket実装よりも有利です。
CGパイプラインにおける欠点
- WebRTCは、このリストの中ではおそらく最も実装・運用が複雑なパターンです。ピアツーピアの接続を確立するには、セッション記述とネットワーク候補を交換するためのシグナリングサーバーが必要であり、NATやファイアウォールのルールによって直接のピア接続が妨げられる環境では、多くの場合TURNリレイサーバーも必要になります。VPN、プロキシ、セグメント化されたサブネットを備えるスタジオネットワークは、まさに直接のピア接続が失敗しがちで、TURNサーバーが必須になるような環境です。
- WebRTCは主にブラウザ環境向けに設計されていますが、サーバープログラミング言語でもクライアントライブラリは利用可能です。ただし、データストリームの消費先が別のサーバープロセスやネイティブアプリであり、ブラウザではない場合、WebRTCはピアツーピア効率という本来の強みを活かしにくい一方で複雑さだけが増えます。そうしたケースでは、よりシンプルなバイナリのWebSocketストリームのほうが適していることが多いです。
まとめ
この記事で扱った5つの技術は、スペクトラム上の異なる地点に位置します。
- ポーリングは出発点です。実装が簡単で、互換性も高い一方で、無駄が多く遅いです。リアルタイムの精度が不要で低頻度の確認で足りる場合、たとえば「すべてのデイリーズがレンダリングされたか」を夜間レポートジェネレーターで確認するような用途に適しています。
- Webhookは、サーバーが永続的な接続を維持することなく、離散的なイベントについて1つ以上の外部サービスに通知する必要があるときに適した手段です。アセット承認のワークフロー、パブリッシュのトリガー、システム横断の連携は自然な適用先です。
- WebSocketsは、インタラクティブなツールで低レイテンシーかつ双方向の通信が必要な場合に有効です。たとえば、ジョブの一時停止や優先度変更のためのユーザーコマンドも受け付けられるライブなレンダーダッシュボードのようなケースです。
- SSEは、サーバーがクライアントへ継続的なデータストリームをプッシュし、クライアントが応答を返す必要がないときのよりシンプルな代替です。ログテールのビューアや、長時間実行されるパイプライン処理の進捗フィードのような用途に向きます。
- WebRTCは、到達可能な限り最小のレイテンシーでピアツーピアのデータ転送が必要なときの解決策です。特にブラウザ向けのインタラクティブなビューポートやプレビューのストリーミングに適しています。
どれも万能に優れているわけではありません。最も応答性が高く信頼できるパイプラインを構築できるスタジオは、目の前の課題に対して各ツールを「ちょうど適切に」当てはめられるだけの理解を持っているところです。
まずは、今のパイプラインの中でアーティストが情報を待っている場面を1か所監査してください。状況に合うパターンを選び、実装して、その差を測定しましょう。
