マイクロサービス vs モノリス・アーキテクチャ：どちらを構築すべきか？
ある創業者が、アーキテクチャの提案をレビューしてほしいと私に頼んできました。
そのエージェンシーが提案したのは、11個のサービス、メッセージキュー、そしてサービスメッシュでした。しかも、それはユーザーがゼロの、単純な予約ツールに対する提案でした。
それは罠です。
アーキテクチャの決定は、ホスティング費用、デリバリー速度、そして採用計画を決定づけます。開発者に予算を渡す前に、そのコストを把握しておく必要があります。
モノリス
モノリスは、単一のコードベース、単一のデプロイ、単一のデータベースを使用します。シンプルです。
立ち上げ当初は、ドメインの境界がどこにあるのか分かりません。もしサービスを早すぎる段階で分割してしまうと、本来存在する必要のない境界線を動かすことに時間を費やすことになります。チームが小さいときは、モノリスの方が管理が容易です。APIを構築する代わりに、単に関数を呼び出すだけで済みます。深夜2時にバグが発生しても、エラーはネットワーク障害ではなく、コードの箇所を指し示してくれます。
マイクロサービス
マイクロサービスは組織的な問題を解決するためのものです。異なるチームがそれぞれのスケジュールでコードをリリースできるようになります。Netflixは、一つの障害がシステム全体を沈没させるのを防ぐためにマイクロサービスを採用しています。
しかし、その代償は日々発生します。ネットワークコールによってレイテンシが増加し、データの整合性を保つことが困難になります。ログやトレーシングを管理するためには、専門的なツールと大規模なチームが必要です。適切な人員がいないと、結局「分散モノリス」に行き着いてしまいます。これでは、ネットワーク特有の複雑さだけを抱え込み、マイクロサービスの利点である独立性が得られません。
モジュラー・モノリス
これは中間的なアプローチです。一つのアプリケーションでありながら、コードの異なる部分の間に強固な境界を持たせます。例えば、課金機能が注文処理の内部ロジックに干渉することはできません。
ShopifyやGitHubはこの手法を採用しています。これにより、クリーンな境界を保ちつつ、ネットワークによるオーバーヘッドを回避できます。アプリの一部を単独でスケールさせる必要が出てきたときも、境界がすでに定義されているため、容易に切り出すことができます。
判断基準：
- チームの規模: もしメンバーが3人しかいないなら、個別のサービス管理や、それに伴うオンコール体制を維持することは不可能です。
- 製品の安定性: もし製品が毎週のように変わるなら、来月にはサービス境界が間違ったものになっているでしょう。
- オペレーション: 自動ロールバックやログ集約の仕組みはありますか？ もしないのであれば、マイクロサービスは苦痛をもたらすでしょう。
- スケール: 仮定の話としての成長のために構築してはいけません。目に見えている具体的な成長の道筋に合わせて構築してください。
もし答えが「まだできていない」のであれば、モジュラー・モノリスを構築してください。
「マイクロサービス」という言葉がモダンに聞こえるからといって、それを要求してはいけません。製品が何を行い、誰がそれをメンテナンスするのかを、パートナーに伝えましょう。
プロダクトが死ぬのは、リリースされないからだ。整理されたモノリスこそが、最も早くユーザーの前にプロダクトを届ける方法である。まずはそれを構築せよ。分割すべきタイミングは、トラフィックの状況に判断させればいい。
学習コミュニティ（任意）: https://t.me/GyaanSetuAi