誤解を解く: Amazon Prime Videoのマイクロサービスとサーバレスへのアプローチ
サーバレスファーストという考え方を再考する
2023年8月30日
翻訳: 竹洞 陽一郎
この記事は米Catchpoint Systems社のブログ記事「Debunking Misconceptions: Amazon Prime Video's Approach to Microservices and Serverless
」の翻訳です。
Spelldataは、Catchpointの日本代理店です。
この記事は、Catchpoint Systemsの許可を得て、翻訳しています。
サーバレスアーキテクチャに関する深掘りシリーズの第二回目のブログです。
第一回では、マイクロサービスとサーバレス・アーキテクチャの利点と妥協点を探り、Amazon Prime Videoのアーキテクチャの再設計がコスト最適化のためにどのように行われたかを強調しました。
このブログでは、Amazon Prime Videoの再設計されたアーキテクチャについて詳しく見ていきます。
それがモノリスへの回帰を意味するのか、それとも最適なパフォーマンスとコスト効率のために異なるアーキテクチャスタイルを調和させて統合するものなのかを分析します。
さらに、「サーバレスファースト」という考え方と、特定のユースケースと要件に基づいて代替的なアーキテクチャアプローチを考慮する重要性についても議論します。
私たち自身がトレーシングコレクタAPIを構築する際にサーバレスコンポーネントを使用した経験から、私たちが直面した課題と、それがどのようにして私たちのアプローチを再評価することにつながったかを共有します。それでは、詳しく見ていきましょう。
Amazonはマイクロサービスとサーバレスから脱却するのか？
X : It means that serverless is over and Prime video killed it!
— Simon Wardley (@swardley) May 4, 2023
Me : Gosh. That is a desperately twisted reading of what is said. Try reading it again without looking for a magic "the end of serverless" quote. They built the system quickly and industrialised it at huge scale.
X : それは、サーバレスが終わりで、Primeビデオがそれを潰したということですね！
私 : うわっ、それは本当に歪んだ解釈ですね。
もう一度、「サーバレスの終わり」という魔法のような言葉を探さずに読んでみてください。
彼らはシステムを素早く構築し、それを大規模に産業化しました。
Prime Videoがどのようにシステムを再構築したかを、彼ら自身の言葉で紹介します。
初期設計では、いくつかの検出器（detector）を水平にスケーリングすることができました。
それぞれが独立したマイクロサービスとして動作していたため、新しい検出器を追加するには、新しいマイクロサービスを作成してオーケストレーションにプラグインする必要がありました。
しかし、新しいアプローチでは、すべての検出器が同じインスタンス内で動作するため、検出器の数は垂直にしかスケーリングできません。
私たちのチームは定期的にサービスに新しい検出器を追加しており、すでに単一のインスタンスの容量を超えています。
この問題を解決するために、サービスを複数回クローンし、それぞれのコピーに異なる検出器のサブセットでパラメータを設定しました。
また、顧客のリクエストを分散するための軽量なオーケストレーション層も実装しました。
― Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%
明らかに、Amazon Prime Videoはマイクロサービスベースのサーバレスアーキテクチャを実際には放棄していません。
記事で説明されているように、彼らは運用コストを削減するために、アーキテクチャ（ストリーム監視）の一部を再設計しています。
初期設計にあった場所からサーバレスコンポーネントを取り除いたとしても（そのバージョンではAWS Step Functionsを検出器のオーケストレーションに使用しています）、他の場所にはそれを追加しています。
新しい設計を分析する
Prime Videoの新しいアーキテクチャ設計は、モノリスへの完全な逆戻りではなく、特定のユースケースに合わせて異なるアーキテクチャスタイルを熟考して統合したものでした。
この再設計では、サーバレスコンポーネント、モノリス風の構造、そしてマイクロサービスが組み合わされました。
モノリス的な部分は、すべてのコンポーネントが単一のプロセスにコンパイルされる形で登場し、中間ストレージの必要性を排除し、オーケストレーションロジックを単純化し、運用コストを大幅に削減しました。
しかし、特定の機能は依然としてマイクロサービスを活用しており、AWS Lambda—サーバレスコンポーネント—は、着信リクエストを分散するために使用され、効率的な水平スケーリングを可能にしました。
これは、特定の問題に対してよりモノリス的な構造に移行するにもかかわらず、サーバレスコンポーネントの有用性とスケーラビリティを強調しています。
これらの観察を考慮に入れると、サーバレスファーストという考え方を再考することが重要です。
サーバレスファーストの考え方とは何か？
サーバレスファーストの考え方を採用するということは、必ずしもすべての可能な機会でサーバレス技術を使用するということではありません。
それよりも、サーバレスアーキテクチャがもたらす潜在的な利点を認識し、新しいアプリケーションやサービスを設計・開発する際の主要な選択肢として考慮することです。
しかし、特定のユースケース、ワークロードの性質、またはシステムの要件に応じて、サーバレスが常に最適な選択肢であるわけではないことも理解することが重要です。
したがって、サーバレスファーストのアプローチはサーバレスソリューションの探求と適用を促進しますが、異なるアーキテクチャのアプローチがより適している場合には、バランスの取れた視点とその判断力も必要です。
Prime Videoチームの投稿では、彼らがオーディオとビデオの監視サービスを構築するためにサーバレスファーストの考え方をどのように適用したかを示しています。
初めは、スケーラビリティと運用オーバーヘッドの削減という利点を活用してサーバレスアーキテクチャからスタートしました。
製品を早く出荷することにはいくつかの利点があります。
- 事前に予測または生成するのが難しいエッジケースを含む、実際のケースを経験するでしょう。
- ユーザからのフィードバックを早く得ることができるので、正確な製品を構築し、製品と市場の適合を早く得ることができます。
- 早く出荷するほど、チームはよりモチベーションを持ち、製品に対するオーナーシップも高まります。
しかし、Prime Videoがさらなるコスト最適化を求めた際には、システムの一部のコンポーネントをコンテナに戦略的に移行しました。
これは、リソースのより大きなコントロールとコンテナが提供できる潜在的なコスト削減を活用するものです。
このアプローチは、サーバレスソリューションが主要な選択肢とされているものの、特定のユースケースや要件に追加の利点を提供する他の代替手段、例えばコンテナ、にもチームが開かれているという、バランスの取れた「サーバレスファースト」の考え方を体現しています。
私たちのサーバレスコンポーネントに対する経験
私たちは、トレーシングコレクタAPIを実装する際に、類似の経験をしました。
初めてこのAPIは、AWS API Gatewayの背後でAWS Lambdaによって実装されました。
このフローでは、コレクタはエージェントからデータを取得し、それをAWS Kinesisストリームに非同期で処理されるように送信していました。
サーバレスコンポーネント（AWS API GatewayとAWS Lambda）を用いてコレクタAPIを構築することで、最初のバージョンをより早く出荷することができ、ユーザには早く試してフィードバックを提供してもらうことができました。
この初版をリリースする作業を進める中で、私たちがアプローチを再考する必要があると感じるいくつかの課題に直面しました。
このシリーズの次回でそれについて詳しく共有します。