Wayfair でレンダリング プラットフォームのクラウド バリューを実現 - パート 1

※この投稿は米国時間 2023 年 5 月 31 日に、Google Cloud blog に投稿されたものの抄訳です。

Wayfair には、3D モデルや 3D シーンの作成の一部を自動化し、それらのモデル / シーンから画像をレンダリングするコンテンツ作成パイプラインがあります。おおまかに言うと、サプライヤーから提供された商品画像や寸法、素材などに関する情報を使って、写真のようにリアルな 3D モデルを作成し、独自の画像を生成しています。ただし、このような 3D レンダリング画像を作成するには、かなりの計算（レンダリング）能力が必要です。昨年、クラウドへのリフト＆シフト移行を実施したのですが、ワークロードをクラウド向けに最適化していなかったため、費用が大幅に増えました。そこで Google Cloud と緊密に連携してレンダリング プラットフォームを最適化したところ、年間ベースで推定 900 万ドルの費用削減を実現できました。

その方法をご紹介しましょう。

Google Cloud にリフト＆シフト

Wayfair は Google Cloud チームと協力して、ハイブリッド クラウドから統合パブリック クラウド戦略への移行を実施しました。当社には、2 つの異なる「ファーム」があります。ひとつは主に自動化タスクに使用するファーム、もうひとつはレンダリング タスクに使用するファームです。

• 自動化ファームは、OpenCue を使用して管理され、ノードにジョブをディスパッチします。
• レンダリング ファームでは、Deadline を使用してノードにジョブをディスパッチします。2022 年第 2 四半期にオンプレミスからクラウドへの移行を完了しました。

以下は、Google Cloud 上にリフト＆シフトでデプロイした当社のアーキテクチャです。

移行時の当社の目標は、パイプラインの品質を落とすことなく、現状のままの SLA をお客様に提供することでした。移行後、私たちはデプロイしたアーキテクチャが非効率であることを認識しました。このアーキテクチャは、従量課金制のクラウドモデルの経済性に適していなかったのです。特に、このアーキテクチャには以下のような問題がありました。

• 固定されたファームサイズと画一的なマシンでインフラストラクチャを十分に最適化できない

• 自動化と統合の機会を逃している

• ファーム全体の費用やレンダリング時間の使用状況が最小限しか可視化されていない

• 最適化されていないワークフローと費用管理でレンダリングに無駄な費用をかけている

私たちは、画一的なモデルよりも良い結果を出せることに気付きました。Google Cloud のさまざまなコンピューティング機能を利用できるため、それをファームに活用することにしました。これにより、レンダリング ファーム全体を最適化するだけでなく、レンダリング時間の使用状況を詳しく把握できるようになり、より大きな節約につながりました。

費用最適化戦略

私たちは Cloud FinOps の 3 原則である「情報提供、最適化、運用」に則り、支出を最適化して今後の持続的なガバナンスを推進する全体的な戦略を策定しました。

わかりやすい表示

実行計画を策定するには、まずクラウドへの支出が増大している要因を徹底的に理解する必要がありました。オンプレミスだった頃はインフラストラクチャ チームが一元管理していたため、使用状況やインフラストラクチャ費用について十分な分析情報がありませんでした。詳しく調べるうちに、現状では使用状況が可視化されていないため、デプロイしたインフラストラクチャのフットプリントだけでなく、アーティストやモデラーによるファームの使い方に非効率な点が多数あることに気付きました。

私たちは、エンジニア、ビジネス関係者、インフラストラクチャの専門家、そして Google Cloud から成る専任チームを結成し、議論を進めました。レンダリング費用を最適化するには、レンダリング プラットフォームの費用を抑えるだけでなく、ワークフローを最適化し、アセットごとに使用するレンダリング時間を減らす必要がありました。私たちは、コアタイムあたりの包括的なレンダリング費用とアセットごとに必要な時間を算出する簡潔な数式を開発し、各チームが透明性を持ち、集中して目標達成を推進しやすくなるようにしました。Google Cloud 上では、アセットの所有から従量課金モデルに重点を移しつつありました。

費用削減策の特定

当社の目標のひとつは、レンダリングにかかる 1 時間あたりのすべての費用を最適化することでした。私たちは、ファームにかかるすべての費用をさまざまなファネルに分類し、それぞれの削減策がもたらす影響に重み付けをしました。おおまかには、以下の主要分野を調査しました。

• ノード - ファームで使用しているマシンのサイズや構成は適切か？現在のデプロイでは単一のプールを使用しているため、マシンサイズを最悪のケースに合わせて最適化せざるを得ず、ユースケースの 90% に無駄が生じていました。GPU アクセラレーションを利用してレンダリング時間を最適化できないか？Spot のようなインスタンス タイプを活用してはどうだろう？
• 使用率 - 365 日 24 時間のノードごとの使用率とファーム全体の使用率はどうなっているか？私たちは、ファームでの使用状況や送信パターンを使用率とともに調査し、効率化を推進する方法を探りました。
• ライセンス - オンプレミスのエンタープライズ ライセンスから Google Cloud のデータセンター ライセンスに変更したため、ファームでの支出全体の約 45% をライセンス費用が占めていました。ファームで利用しているソフトウェアのライセンス料はいくらか？スケーリング ニーズに対してどのような制約があるか？
• その他 - ストレージやネットワーク転送など、ファームにかかるその他の費用を調べました。合わせても支出全体の 8% にしかならなかったため、初期に最適化するほど重要ではないと判断しました。

使用状況の最適化策

包括的な戦略の一環として、レンダリング時間を最適化するワークフローの効率化も目標に掲げました。費用をモデリングしていた際、同じ作業単位で必要とされる時間を短縮することで、大きな効果が得られることがわかりました。おおまかには、以下の分野を調査しました。

• レンダリングの品質 - 最終的なレンダリングの品質に大きな影響を与えることなく、放射照度、ノイズ、しきい値、解像度などのレンダリング設定を最適化し、個々のリクエストに要するレンダリング時間を短縮できるか？
• 作業単位 - リクエストごとに必要なレンダリング フレーム数、レンダリングのラウンド数、アングル数を減らすことで、リクエスト当たりで必要なレンダリング数を低減させ、パイプラインの無駄を減らすことはできないか？
• 複雑さ - レンダリングの複雑さを軽減するために、特定の素材、ライティング設定、フレームの最適化を検討できないか？レンダリング時間に応じて p90 でレンダリング リクエストを検討し、フィードバック ループを作成することは可能か？
• アーティストのエクスペリエンス - ローカル レンダリング機能とストレージ管理機能を備えたクラウド ワークステーションを提供し、レンダリングに関する隠れた間接費用を削減することで、アーティストのワークフローを改善できないか？

次回の記事では、上述の戦略をどのように適用してこれらの取り組みを計画、実行し、何を学んだかをご紹介します。