マイクロサービスのコスト (2020)

• 単一バックエンドからマイクロサービスアーキテクチャへ移行するコストと利点に関する記事
• 単一のコードベースに貢献するチームの数が増えるにつれて、コンポーネント同士の結合が強まり、生産性が低下し、複雑性が増す
• こうした問題を緩和する一つの解決策は、単一バックエンドを、API を通じて通信する独立してデプロイ可能なサービス群、すなわちマイクロサービスへ分割すること
• 「マイクロ」という用語は、サービスが必ずしも「マイクロ」である必要はないため誤解を招きやすい。より適切な用語はサービス指向アーキテクチャ
• バックエンドを明確に定義された境界を持つサービス群へ分解すると、各サービスの開発と運用は小さなチーム一つで十分になるため、アプリケーションの開発速度が向上する
• 各マイクロサービスは独立してスケールでき、自身の必要に応じて異なる技術スタックを採用できるため、新しい技術の実験と評価が容易になる
• しかし、マイクロサービスアーキテクチャはシステム全体により多くの可動部分を追加するため、複雑性を高め、一定の標準化を必要とする
• 各マイクロサービスごとに異なる言語、ライブラリ、データストアを使うと、アプリケーションを保守しにくい混乱へと変わり、開発者がチーム間を移ることも難しくなる
• 独立したサービスを大規模に支えるには、新しいサーバー、データストア、その他のリソースを容易に作成できる必要があり、そのためにはかなりの自動化が求められる
• リモート呼び出しはコストが高く、システムが失敗しうる新たな経路を導入するため、タイムアウト、リトライ、サーキットブレーカーのような防御メカニズムが必要になる
• 継続的インテグレーションは、コード変更が自動ビルドおよびテストのプロセスを経た後にメインブランチへマージされることを保証する
• すべてのマイクロサービスの統合テストはモノリスのテストよりはるかに難しく、個々のサービスが相互作用するときに非常に微妙で予期しない挙動が現れることがある
• サービスを開発するチームは通常、その呼び出しへの対応も担当し、開発作業と運用コストの間に摩擦を生む
• マイクロサービスではシステム障害のデバッグがより難しくなり、あらゆるレベルで良質なロギングとモニタリングが重要になる
• アプリケーションを別々のサービスに分割すると、データモデルはもはや単一のデータストア上に存在しなくなるため、たいていは結果整合性を受け入れなければならない
• 一般にはまずモノリスで始め、サービス間の境界を正確に設定するのが難しい場合にのみ分割するのが最善
• マイクロサービス優先のアプローチで始めるのは、すでにその経験があり、そのためのプラットフォームを構築済みであるか、あるいは構築にかかる時間を織り込んでいる場合に限るべき