Amazon Prime Videoの事例から考察する「モノリシックとマイクロサービスの最適解」：サービスの成長に合わせて検討し直すことが重要

　TechTargetは、システム構成に関するアーキテクチャ「マイクロサービス」と「モノリシック」について記事を公開した。多くの企業はマイクロサービス化を検討するが、サービスの成長に合わせモノリシックに戻す企業もある。

[TechTarget]

　モノリシックアーキテクチャは、アプリケーション全体を1つのプログラムとして構築するアプローチだ。簡単に始めやすいというメリットはあるが、アプリケーション（もしくはシステム）の規模が大きくなるとさまざまな問題が顕在化する。例えば「ある部分を変更したら、他の部分で予期せぬ問題が起こる」などだ。

　こうした問題は、「調査に時間を取られ、新しい機能のリリースが遅れる」などさらなる問題を引き起こす可能性がある。そのため、アプリケーションの成長に合わせて、モノリシックアプリケーションをマイクロサービス化するのが一般的だ。

　だが、常にマイクロサービスアーキテクチャが最適とは限らない。Amazon.comが最近実施したアーキテクチャの変更はマイクロサービスとモノリシックを選択する際にどこに注目すればいいのかを理解するのに役立つだろう。

マイクロサービスやモノリスを超えたアーキテクチャ（提供：TechTarget）

一部をモノリシックに戻したAmazon.comの決断

　Amazon.comの「Amazon Prime Video」は、世界有数の動画ストリーミングサービスだ。多くのサービス加入者を抱えており、膨大な量のストリーミングデータを扱っている。あるとき、Amazon Prime Videoの技術チームは、品質モニタリングサービスのスケーリングに関する問題に直面した。Amazon Prime Video向けに開発された品質モニタリングサービスは、予想よりもずっと少ない負荷（想定負荷の5％）がかかっただけで、うまく動かなかったのだ。

　また機能しないだけでなく、コストも発生していた。技術チームによると「1秒ごとに状態変更を行ったため、すぐに『AWS Step Functions』のアカウント制限に達した。サービス（Amazon Prime Video）は止まらなかったものの、その代わりインフラが繰り返し再構築され、コストが増加していた」という。

　その結果、Amazon Prime Videoの技術チームは品質モニタリングサービスをモノリシックアーキテクチャに戻す決断をした。この変更によって「スケーラビリティが向上しただけでなく、コストを90％削減できた」と技術チームは述べている。

　だが、一部の業界関係者はAmazon.comのこの新しいアプローチに対する説明を疑問に思っている。「同社が実現したことは単なるモノリシックではなく、もっと複雑なものではないか」と。

アーキテクチャ選択のポイント

　Amazon.comの事例は品質モニタリング、つまり単一のサブシステムのことでAmazon.com全体の話ではない点には注意が必要だ。その上で同社のアプローチが自社にも有効だと考えるのであれば、次の5点を考慮するのがいいだろう。

1．リポジトリ

　コードを単一のリポジトリに保存できるかどうかを考える。コンポーネントが1つ（もしくは最低限）にまとまっていればコードの管理を整理しやすくなり、コード間の結び付きも緩やかになる。異なるコードへの関心も分離できる。

2．結束力

　結合したマイクロサービスは、単一の統一的なビジネスプロセスを提供すべきだ。それが難しい場合は、関連するマイクロサービスを同じ仮想ハードウェア上、例えば「Docker」コンテナなどに配置するといいだろう。同じコンテナ内のサービス、特にお互いを呼び出すことができるサービスを組み合わせることで、帯域幅とメッセージングのオーバーヘッドを削減できる。

3．機能チーム　vs.　コンポーネントチーム

　誰かが実施した変更作業が、思わぬ部分に影響を与えるというモノリシックアーキテクチャの問題は、同じコードベースで複数のチームが作業するときに発生する。「コンポーネントチーム」を持つことで、複数のチームが同時に作業をすることがなくなるため、その問題を回避できる。

　チーム間の調整にも注意が必要だ。「機能チーム」は、コンポーネント間の分離を増やしたり、結合を緩めたりすることを望んでいるため、コストが増加しがちだ。

4．デザインの構成と依存関係

　サービスをテストする古典的な方法は、そのサービスを独立させ、そのサービスが依存する他の部分をモックで確認することだ。また、コストも時間も掛かってしまうが、全体の本番環境を再現する方法もある。

　ただ、依存関係が明確でシステムが標準のデータシードを使用しているのであれば、別の方法を試せる。ソフトウェアは、そのサービスの依存する部分だけを仮想環境として構築できる。それにデータを追加すれば開発者は非常に信頼性の高いエンドツーエンドのテストを実行可能だ。この方法を使うには依存関係が明確で、必要な場合にテスト環境を作成できる仕組みが必要だ。関連するサービスをサービスレベルで結合していれば、その作業は容易になるだろう。

5．将来の成長

　システムの将来の成長を考慮し、アーキテクチャを計画することが重要だ。システムのパフォーマンスと拡張コストを計算し、グラフに表してみたとき、1つの要素の傾きが急速に増加していたら、問題が発生する前にアーキテクチャの変更を検討すべきだ。その際、正しい選択は恐らく「モノリスかマイクロサービスか」といった両極端な意見の中間にあるだろう。