ヴィシャル・パレク氏はMeta Platformsのプリンシパルエンジニアである。
10年前、多くの人が大規模インフラを構築しようとしていた時代には、モノリスサービスが主要な選択肢だった。しかし状況は急速に進化しており、本記事では技術的、運用的、開発の観点からマイクロサービスが有益である主な理由について説明する。
特に現在の広告システムにおいて、マイクロサービスがアジリティと製品の市場投入までの時間短縮にどれほど有益であるかを見ていく。広告チームが成長するにつれ、モノリスはボトルネックとなり、最適化や新機能の提供を遅らせ、運用負担を増大させる。以下は、より大きなビジネス目標を達成するためにモノリスからマイクロサービスへと進化させる典型的な理由である。
ビジネス要件：新機能の追加
モノリスは実装する必要がある機能が2、3つだけの場合には優れているが、機能セットが増えるにつれ、コードは非常に複雑で入り組んだものになり、数行のコードを追加することさえ困難になる。
これは広告システムにおいて特に関連性が高い。収益を向上させ、広告主の要件に対応するために、新機能を継続的に追加する必要があるからだ。各マイクロサービスがスタック内の特定の問題を解決する場合、開発は1つのサービス、または少数のサービスだけに集中でき、新機能をより迅速かつ効率的に追加できる。そのため、機能の追加がより速く、シンプルになる。
システム：スケーラビリティと効率性
マイクロサービスはスケーリングがはるかに容易である。さまざまな機能がシステムリソースを異なる方向に引っ張るため、各マイクロサービスを個別に最適化してスケールする方が簡単だ。これにより、QPSが向上するだけでなく、全体的なマシンフットプリントも削減される。さらに、バイナリはマシン上でホストされるため、小さなバイナリによってより多くのスタッキングと配置の機会が生まれる。これは単一のコードベースとそのバイナリのサイズが大きくなるにつれて困難になる。
広告サービスは、膨大な量のデータが通過するため、データセンターでのマシンフットプリントが大きい。これは、最適化によって運用コストを数百万、さらには数十億ドル節約できる可能性があることを意味する。そのため、マシンフットプリントの改善はビジネス上極めて重要となる。
運用：デバッグ
「干し草の中の針」の問題により、モノリスでは問題を特定するのに時間がかかる。マイクロサービスでは、責任がより明確に定義され、変更セットがはるかに小さいため、より迅速な検出が可能になる。アラートの構築と理解も容易になる。
ダウンタイムの1分ごとに大きな収益損失が発生し、広告主の感情に影響を与え、ROIと広告パフォーマンスの低下により将来の予算配分に影響を与える可能性がある。したがって、問題をできるだけ迅速にデバッグして解決することが広告ビジネスにとって極めて重要である。
運用：本番環境への移行
少数のサービスセットを扱う場合、小さな変更をより迅速に本番環境に移行できる。大規模なモノリスでは、多くの競合する変更が正確性を確保し、意図しない影響を防ぐためのテストに依存している。マイクロサービスでは、問題のあるバンドルはサービスの1つのレイヤーの変更をロールバックするだけで元に戻すことができる。
広告では、複数の機能が同時にロールアウトされることが多い。本番サービスを以前のバージョンにロールバックすると、意図せず他の機能に影響を与える可能性がある。例えば、機能1を元に戻すと、広告主が積極的に使用している機能2もロールバックされる可能性がある。これはマイクロサービスでも起こり得るが、モノリスではより顕著である。
人材：開発ペース
マイクロサービスを使用すると、個々のチームが別々のコードベースで作業し、本番環境に変更をデプロイする際の競合が少なくなるため、開発速度が大幅に向上する。これは特にチーム数が増えるにつれて重要になり、そうでなければ大きなボトルネックとなる可能性がある。
より迅速な機能開発により、より大きな広告主の予算を可能にし、より高い収益を生み出す。一部の変更はコア広告チームからもたらされるが、非広告チームも同じコードベースに大きく貢献している。マイクロサービスにより、これらの変更を複数のサービスに分割でき、より迅速な開発が可能になる。
これらは、広告システムで観察された主要な理由であり、収益に不可欠な機能の提供を妨げ、開発者の速度を低下させる。モノリスからの移行は、多数のチームが関わる複数年の取り組みである。その間、これらのモノリスを所有するチームは、コードベースの管理、他のチームとの調整、サービスの全体的な健全性の維持に苦労している。したがって、マイクロサービスアーキテクチャへの移行に早期に投資し、適切な基盤を構築することが、将来の減速を防ぐのに役立つことは明らかである。
