amazon prime videoがマイクロサービス構造からモノリス構造へ移行して費用90%節減

この記事の内容にある意見は、個人の主観的意見を前提とします。
記事の内容は間違いがあり得ますので、ご了承いただけると幸いです。内容の間違い、認識の違い、違う意見などありましたら、コメント大歓迎です！

概要

少し過ぎた記事ではありますが、2023年3月にamazon prime video techblogにて面白い記事があり、世界から注目された事例がありました。

Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%

最近はモノリス構造は避けて、マイクロサービスやサーバーレス構造でのサービス検討が注目されている中、個人的に興味深い事例と考えたので、qiitaにて紹介しようと思います。

関連記事からわかる注目度

元のamazon prime video techからの配信記事はこちらになります。

• amazon prime video tech: Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%

その他、いろんなオンライメディアから注目され、記事化されています。

• Amazon Prime Video team throws AWS Serverless under a bus
• Prime Video Switched from Serverless to EC2 and ECS to Save Costs
• Return of the Monolith: Amazon Dumps Microservices for Video Monitoring
  
• Serverless
  Reduce costs by 90% by moving from microservices to monolith: Amazon internal case study raises eyebrows

要点

• Prime Videoはライブストリームを提供し、ストリームの品質を監視するツールを持っている
• VQA(Video Quality Analysis)ツールはコストとスケーリングの制約に直面
• AWS Step Functionsによってオーケストレーションされた分散コンポーネント構造
• 高いコストの原因は、コンポーネント間のオーケストレーションワークフローとデータ転送に関係していた
• 解決策として、データ転送コストを削減し、オーケストレーションを簡素化するためにモノリスアーキテクチャへの移行
  • デプロイメントは現在、スケーラブルなEC2、ECSインスタンスに依存
• モノリスアプリケーションへ移行の効果として、拡張性と維持補修性を高めると同時に90%の費用を節減

既存のVQAのマイクロサービスアーキテクチャとその問題点

アーキテクチャ

• サービスはメディアコンバーター、ディテクター、オーケストレーションの3つの主要コンポーネントから成り立っている
• サービスはビデオ品質を確保するための機械学習を活用しており、欠陥の検出とリアルタイム通知を提供している

問題点

• 初期の分散システム設計はAWS Step FunctionsやAWS Lambdaを使用し、迅速なサービス構築に適していたが、スケーリング制限と高コストの問題が発生
• 一部コンポーネントにおいて、予想より約5%以上のhard scaling limitが発生
• large-scale deploymentのための全体費用が飛躍的に上昇

①AWS Step Functionsによるオーケストレーション管理

• 毎秒のストリームごとに多様なstate transaction転換が行われることによって、すぐlimitsに到達

②ビデオフレームのデータ転送に関するコスト問題

• 画像をS3バケットにアップロードしAWS Lambdaで処理するマイクロサービスを使用していたが、Tier-1のS3呼び出しが高額

解決策 : 水平的(horizontally)拡張性のマイクロサービス構造から、垂直的(vertically)拡張性のモノリス構造へ移行

解決に対してのアクション

• 当初は問題解決のアプローチとして、問題ごとに別の対応を持って費用を抑え、拡張性を高めることを検討したが、いろんな検証を経て最終的には「infrastructureの再設計」をすることを決定
• 分散型マイクロサービスが、特定の事例ではデメリットをもたらすことから、全てのコンポーネントを単一アプリケーション化(Single Process化)
  • データ転送がin-memoryで行われることでS3との転送量問題を解決
• また、単一インスタンスないでのコンポーネント構成を制御するorchestrationを具現

改善後のアーキテクチャ

新しいアーキテクチャ説明

• 概念的に上位レベルのアーキテクチャは同じ形を維持したアーキテクチャを意識し、移行において多くの既存コードの再利用とともに、新しいアーキテクチャへの転換を素早く行う
• 既存のマイクロサービス設計ではdetectorを水平的に拡張することが可能だったが、そのために新しいマイクロサービスとorchestrationの連携が常に必要だった
• 新しいモノリス設計においては、detectorが同じインスタンス(process)内で実行されるため、detectorは垂直的にのみ拡張される構造になった

結論

• マイクロサービスとサーバーレスは大規模なサービスに適していのが一般的だが、MSA構造にするかMonolith構造にするかは、事例別に検討し決定することが大事
• 全てが明確なベストソリューションではないものの、実際にサービスをモノリスにしたことで、高い処理量と拡張性、維持補修性を維持しながらも、インフラ費用の90%を節減した

後書き

私も、まだ駆け出しではありますが、本格的で自ら成功と言えるマイクロサービスとサーバーレス構成を目指して、いろいろ学習や経験を検討している中で、「適材適所」という、エンジニアとして見逃してはいけない教訓を改めて考えるきっかけとなりました。

この記事を読んだ上で、私個人的には以下の軸を意識し、ソフトウェアアーキテクチャのスキルを広めていこうと思います。また判断としては、以下の基準と事例を俯瞰した上で、適切なソリューションを実施できるように精進していきたいと思います。

• Monolith
• Monolith with DDD, Clean Architecture(or other Layered Architecture), Component-driven-design
• Hybrid Monolith and partially Microservice(or Serverless)
• MicroService Architecture

### Monolith
- サービスドメインが定まっていないなく、PoCなどのために素早くPrototyping&Feecbackが求められる段階
- 行うと同時にサービスドメインの抽象設計を頻繁に並行 
    - (DDD, Communication Diagramなど)

### Monolith with DDD, Clean Architecture(or other Layered Architecture), Component-driven-design
- サービスドメインがある程度具体化されており、Pilotや初期サービス段階で検討
- 基本的にアプリケーションレベルでの階層分離を意識し、単一インスタンスからのscale-upの構成をとるようになる

### Hybrid Monolith and partially Microservice(or Serverless)
- 関連性が少ないサービスドメインが複数要求される場合や、一部機能が性能的にボトルネックになる課題が発生する際に一部分をMSAに移行を検討
- 初期サービス設計において、最初から部分MSAの検討は可能（認証認可基盤、大容量コンテンツ処理・提供、バッチ処理など）

### MSA
- サービスの分離、メッセージング設計、トランザクション管理など、MSA基盤の本格的設計を検討
- サービスドメインごとに組織が構成される要求
- 複数のサービスの統合連携の要求
- 初期サービス設計において、明白にマイクロサービスからメリットが見えている場合
    - （既存の複数の商用サービスの組み合わせて新しいサービスを迅速に開発）
- ただし、マイクロサービスが持つデメリットをちゃんと考えて検討が大事
    - （サービス複雑化と設計管理、コンテキストやデータ生合成管理の難しさ、通信オーバーヘッド、問題区間検知の難しさなど）