Prime Video のモノリシック アーキテクチャへの移行の長所と短所: リスクを冒す価値はありますか?

コストを削減するか、柔軟性を犠牲にするか?

Amazon Prime Video は最近、ライブ ビデオ監視サービスをマイクロ サービスからモノリスに移行し、90% のコスト削減を実現しました。

アーキテクチャを深く掘り下げて、単にコストを節約するだけでなく、移行の背後にある動機を理解し、それが本当にマイクロサービス アーキテクチャなのかマクロサービス アーキテクチャなのかを判断してみましょう。

一般的に使用される用語:

VMS (ビデオ監視サービス) : このツールを使用すると、Amazon は知覚的な品質の問題 (ブロックの破損やオーディオ/ビデオの同期の問題など) を自動的に特定し、それらを修正するプロセスをトリガーできます。

MCS (メディア コンバーター サービス) : 入力オーディオ/ビデオ ストリームをフレームまたは復号化されたオーディオ バッファーに変換し、検出器に送信します。

欠陥検出器: フレームとオーディオ バッファをリアルタイムで分析して欠陥 (ビデオのフリーズ、ブロックの破損、オーディオ/ビデオの同期の問題など) を探し、欠陥が見つかるたびにリアルタイムの通知を送信するアルゴリズムを実行します。

初期の分散サーバーレス アーキテクチャ

上の図は、オーケストレーターの役割を果たす AWS Lambda を使用して AWS ステップ関数を使用して構築された、ライブ ビデオ監視サービスの初期のサーバーレス アーキテクチャです。

理解を深めるために、段階的に分解してみましょう。（参考：元の記事で提供された情報/明確さが不足しているため、いくつかの仮説が考えられています）

• 最初のステップでは、クライアント アプリケーションがオーディオまたはビデオ ストリームをメディア変換サービスにアップロードし、ステップ関数をトリガーして同期的に変換を開始します。
• これを実現するには、メディア変換サービスに送信する前に、 受信した暗号化されたオーディオ/ビデオ ストリームをデコードするツールをコンシューマ側で実行する必要があります(ブログでは言及されていないため) 。

• 変換が完了すると、MCS はオーディオ/ビデオ ストリームを s3 バケットに保存し、並行して実行される欠陥検出サービスへの呼び出しをトリガーします。集約された結果は S3 バケットに再度保存され、対象の消費者がそれに応じてアクションを実行できるように SNS トピックにもプッシュされます。
• システム全体は、サーバーレス アーキテクチャ (AWS Step Functions と Lambda) とマイクロサービス アーキテクチャ (MCS と欠陥検出器) を使用して構築されます。主なコストは、分散コンポーネント間のオーケストレーション ワークフローとデータ転送から生じます。言うまでもなく、現在の設計では、ホット ライブ ストリームに関連するスケーリングのボトルネックがあります。

モノリス アーキテクチャ

更新されたアーキテクチャでは、ほとんどのコンポーネント (MCS、Detector、Orchestrator) は同じままですが、唯一の重要な変更は、コンポーネントが単一の ECS インスタンスに統合されたことです。しかし、これは何を意味し、システムにどのような影響を与えるのでしょうか? 分解してみましょう。

• 以前は費用がかかり、AWS ステップ関数と Lambda を使用していたオーケストレーションは、新しいオーケストレーション レイヤーに置き換えられました。これにより、単一インスタンス内のコンポーネントをより適切に制御できるようになり、大幅なコスト削減につながります。
• メディア コンバーター (MCS) は、以前はマイクロ サービスとして実行されていましたが、現在は単一の ECS インスタンスに移動されています。この変更により、アクティブなヒープでローカルにデータを変換および保存できるようになり、処理が高速になり、パフォーマンスが向上します。
• 最後に、ML モデルを使用してオーディオ/ビデオ ストリームの欠陥を検出する検出器も、単一の ECS インスタンスに移動されました。これは水平方向のスケーラビリティーの能力を失うことを意味しますが、コストの削減は価値のあるトレードオフになります。ただし、検出器が高負荷下で壊れる可能性があることは注目に値するため、克服すべき潜在的な課題がまだいくつかあります。

• 長所: 余分な S3 バケットの読み書き階層 1 呼び出しが不要になり、オーケストレーションのための AWS Step 関数と Lambda のコストのかかる操作が個々のコンポーネントに置き換えられたため、コストが削減されました。
• 短所: 水平方向のスケーラビリティが失われます (たとえば、単一の ECS インスタンスでも実行されている検出器など)。将来的には、オーディオ/ビデオ ストリームに複数のコンシューマーが存在する可能性があるため、柔軟性が失われますが、現在は検出器に密結合されています。

以前のモノリシック アーキテクチャには、単一の ECS インスタンス内で、特に検出器の水平スケーラビリティが失われるという大きな問題がありました。しかし、新しいマクロ + モノリス デザインは、この問題に取り組みました。その方法を詳しく見てみましょう。

• 検出器は、単一の ECS インスタンスでのみ垂直方向にスケーリングできるため、このモノリス サービス インスタンスは、異なる ECS クラスターの検出器のパラメーター化されたサブセットと、要求の分散に AWS ラムダを使用する軽量オーケストレーター レイヤーで複製されます。
• 上記の設計では、まだある程度の柔軟性が失われています。現在、オーディオ/ビデオ ストリームのコンシューマーは 1 つだけで、将来的には複数のコンシューマーが到着するため、設計アプローチの変更が必要になる可能性があります。

ソフトウェア開発の世界では、マイクロサービスとモノリシック アーキテクチャの間に万能のソリューションや設計の優位性はありません。Prime Video がモノリシック デザインに移行した場合、最大 90% の大幅なコスト削減が実現し、ユース ケースにうまく収束しました。

ただし、オーディオ/ビデオ ストリームの複数のコンシューマーが発生した場合、またはバッファー サイズが原因で MCS サービス自体を 1 つの ECS インスタンス内に保持できない場合は、現在の設計を再評価する必要がある可能性があることに注意することが重要です。ソフトウェア エンジニアとして、変化する要件に対応し、コストとパフォーマンスを最適化するために、設計を継続的に評価および調整することが重要です。

参考文献

• Amazon プライム ビデオ ブログ (プライム ビデオ オーディオ/ビデオ監視サービスをスケールアップし、コストを 90% 削減 — プライム ビデオ テック)

• コンピューティング Live ストリームの視聴者数をリアルタイムで High Scale !! | | Aashirwad Kashyap | | グランス ()
• CI / CD を使用して Google Cloud 経由で Node.js アプリケーションをデプロイする | Aashirwad Kashyap | | Bits and Pieces ()
• AirFlow アーキテクチャを深く掘り下げて復元力のあるデータ パイプラインを構築する | Aashirwad Kashyap | | オタク文化 | 中くらい

私たちのコミュニティに参加してくれてありがとう！行く前に：

• ストーリーに拍手して作者をフォローしてください
• Level Up Coding の出版物のコンテンツをもっと見る
• 無料コーディング面接コース ⇒コースを見る
• フォローしてください: Twitter | リンクトイン| ニュースレター