AIおよび動画処理ワークロード向けオンオフスケーリングパターン
AIを活用した動画処理プラットフォームは、オフピーク時にはジョブがゼロになる状態から、ピーク時には数百の並行動画処理およびAI推論タスクが実行されるような、非常に変動の大きいワークロードを、アイドル状態のGPUおよびコンピューティングリソースに対する費用を支払うことなく処理する必要がありました。
プロジェクトを相談する
課題
AIおよび動画処理ワークロードは、本質的にバースト性があり、高価です。
- GPUインスタンスは、ジョブ処理中であろうとアイドル状態であろうとコストがかかります
- 動画エンコーディング、文字起こし、AI推論はそれぞれ異なるリソースプロファイルを要求します
- ピークと谷の比率は50:1でした — ピーク時には200以上のジョブ、夜間はほぼゼロ
- 従来のオートスケーリングは、時間制約のあるユーザーリクエストに対して遅すぎました（コールドスタートに5～10分）
- ピーク向けにプロビジョニングされた固定インフラストラクチャは、オフピーク時に80%以上の無駄を意味しました
私たちのソリューション
当社は、オンオフスケーリングパターンを実装しました。これは、アクティブなワークロードに対してコンピューティングリソースがジャストインタイムでプロビジョニングされ、アイドル時には完全に解放されるハイブリッドアーキテクチャであり、低レイテンシのタスクにはウォームプールを、バッチジョブにはコールドプールを使用します。
アーキテクチャ
- ジョブキュー: 優先度分類機能を備えたデータベースバックのジョブキュー
- オーケストレーター: リソースのライフサイクルとジョブルーティングを管理するサービス
- GPUワーカー (AI): 推論（オブジェクト検出、文字起こし、話者検出）用のクラウドGPUポッド
- CPUワーカー (動画): 動画エンコーディングとレンダリング用のクラウドVM
- ウォームプール: 低レイテンシジョブ（起動30秒未満）用の事前初期化済みインスタンス
- コールドプール: バッチ/バルク処理用オンデマンドインスタンス（起動2～5分許容）
オンオフパターンの実装
リソースのライフサイクル状態
リソースは定義されたライフサイクルを辿ります。完全に解放された状態（コストゼロ）から、プロビジョニングとウォーミングアップ（モデル読み込み、ヘルスチェック）を経て、準備完了および処理中の状態になり、その後クールダウン期間を経て再び解放された状態に戻ります。
ウォームプール戦略
低レイテンシ処理（ユーザーによる開始、数分以内の結果を期待）の場合:
- 営業時間中は最小限のウォームプールインスタンスを維持する
- コンテナ起動時にAIモデルをプリロードする
- 受信ジョブをまずウォームインスタンスにルーティングする
- キューの深さがしきい値を超えた場合、追加のウォームインスタンスをスケールアウトする
- 設定可能なクールダウンタイマーにより、散発的なジョブ間でインスタンスをアクティブに保つ
コールドプール戦略
バッチ処理（夜間の大量ジョブ、緊急性の低い再エンコード）の場合:
- デフォルトではインスタンスはゼロ
- バッチジョブが投入された際にジョブキューがプロビジョニングをトリガーする
- レイテンシよりもスループットを優先するバルク最適化インスタンス
- バッチ完了後すぐに終了する
- 大幅なコスト削減のためにスポット/プリエンプティブルインスタンスを使用する
ジョブの分類とルーティング
ジョブは優先度とタイプによって自動的に分類され、適切なプールにルーティングされます。
- 高優先度のユーザーが開始するAIタスクはウォームGPUプールにルーティングされる
- クリティカルなリアルタイムタスクは常時稼働の専用インスタンスにルーティングされる
- 中優先度のエンコーディングタスクはウォームまたはコールドCPUプールにルーティングされる
- 低優先度のバッチタスクはコールドスポット/プリエンプティブルインスタンスにルーティングされる
オーケストレーターロジック
スケールアップのトリガー
- キューの深さが設定可能なしきい値を超える
- 平均待ち時間が優先度レベルのSLAを超える
- 既知のピーク時間前の計画されたスケールアップ
- 予想されるトラフィックスパイクに対する管理API経由の手動トリガー
スケールダウンのトリガー
- クールダウン期間中、ジョブが処理されない
- ピーク時間後の計画された縮小
- キュー内のすべてのジョブが完了し、新規投入がない
- 請求期間のコストしきい値に達した
ヘルスとリカバリ
- すべてのアクティブインスタンスに対する定期的なヘルスプローブ
- 異常なインスタンスは自動的に置き換えられる
- 失敗したジョブはリトライ回数と共に再キューに入れられ、別のインスタンスにルーティングされる
- 最大リトライ回数を超えたジョブのためのデッドレターキュー
コストへの影響
オンオフパターンは、オフピーク時のアイドルコンピューティングの排除、ジョブタイプごとのリソースの適正化、およびバッチワークロードに対するスポットインスタンスの活用により、常時稼働の固定インフラストラクチャと比較して約70%のコスト削減を実現しました。
主な機能
- アイドルコストゼロ — ジョブ処理中でないときはリソースが完全に解放される
- ウォームプール — 低レイテンシのワークロード向けの事前初期化済みインスタンス
- コールドプール — 最低コストでバッチジョブのオンデマンドプロビジョニング
- ジョブ分類 — 優先度、タイプ、レイテンシ要件に基づく自動ルーティング
- クールダウン期間 — 設定可能なアイドルタイムアウトにより、バースト間の早すぎるスケールダウンを防止
- スポット/プリエンプティブルサポート — 大幅なコスト削減のためにバッチジョブを割引インスタンスにルーティング
- ヘルスとリカバリ — ジョブの再キューイングを伴う異常インスタンスの自動交換
- スケジュールされたスケーリング — 時間ベースのプロビジョニングルールで既知のトラフィックパターンを予測
成果
技術スタック
caseStudyDetail.more ケーススタディ
その他の技術実装事例をご覧ください
スケーラブルで費用対効果の高いAI推論のためのRunPod活用
AIを活用したビデオ分析プラットフォームは、複数の同時ビデオストリームにわたるリアルタイムの物体検出と推論のために、高性能なGPUコンピューティングを必要としていました。しかし、24時間年中無休で稼働する専用GPUサーバーの法外なコストは避けたいと考えていました。
AIを活用したOCRによる請求書処理とQuickBooks連携
毎月数百件の仕入先請求書を処理する中規模企業が、AI/OCRを使用して請求書データを自動抽出し、それを記帳と支払追跡のためにQuickBooksに直接同期させることで、手動データ入力を排除する必要がありました。
よくある質問
MicrocosmWorksは、予測可能なGPUを多用する処理のバーストが続き、その後に長いアイドル期間があるワークロード向けにon-off scaling patternを開発しました。従来のauto-scalingでは、アイドル時に最小限のキャパシティを維持するために費用を無駄にしますが、このパターンでは、ウォームインスタンスを稼働させ続ける代わりに、処理ジョブが到着した際にオンデマンドでGPUインフラストラクチャをプロビジョニングし、ワークロードを実行し、完了したらインフラストラクチャを完全に終了させ、アイドル期間中のコストをほぼゼロに抑えます。
MicrocosmWorksは、すべてのAIモデルの重みと依存関係が組み込まれた最適化されたコンテナイメージを事前に構築し、コンピューティングリージョンに地理的に近いレジストリに保存することで、コールドスタート時間を60秒未満に短縮しました。オーケストレーションレイヤーは、スケジュールされたワークロードに対しては予測プロビジョニングを使用し、予想される需要の2〜3分前にインフラストラクチャを起動します。予測不可能なワークロードに対しては、システムがジョブをキューに入れ、処理開始通知を送信して、ユーザーはリクエストが処理中であることを知ることができます。
MicrocosmWorksは、AIビデオ処理ワークロードが1日あたり2〜6時間実行されるクライアントに対し、24時間365日GPUインスタンスを維持する場合と比較して70〜90%のコスト削減を記録しました。この節約は、実際の処理時間に加えて数分間の起動と終了のオーバーヘッドのみを支払うことによって実現されます。このパターンは、夜間バッチビデオ処理、オンデマンドトランスコーディング、イベントトリガー型AI分析など、利用率が本質的に断続的なワークフローに特に効果的です。
はい、MicrocosmWorksはon-offパターン内にファンアウトアーキテクチャを実装しており、大規模なバッチジョブが到着した際に複数のGPUワーカーを並行してプロビジョニングし、ジョブキューを使用してワーカー間でビデオファイルを分散させ、バッチ完了後にすべてのワーカーを終了させます。システムはビデオごとの進捗を追跡し、個々のビデオの失敗をリトライロジックで処理し、残りのバッチをブロックすることなく、結果を単一の出力場所に統合してダウンストリームでの利用に供します。
MicrocosmWorksは、on-off scalingアーキテクチャを1時間あたり25ドルから45ドルの開発レートで実装します。ジョブオーケストレーション、インフラストラクチャプロビジョニング、モニタリング、障害処理を含む本番環境対応の実装は、通常3〜5週間で提供されます。この開発投資は、特に1日の50%以上アイドル状態にある常時稼働のGPUインスタンスを現在実行している組織の場合、GPUコスト削減のみによって通常1〜2ヶ月以内に回収されます。