3月12日編集
マイクロサービスは、俊敏性、スケーラビリティ、そして独立した展開を約束します。 そのため、新しい要件が現れると、「もう一つだけ追加しよう」と言いたくなります。 しかし、時間が経つにつれて、そうした小さな決定がアーキテクチャ図では見えにくいコストを静かに積み重ねていくことがあります。
まず、オペレーショナルオーバーヘッドがあります。 新しいマイクロサービスごとに、それぞれ独自のビルドパイプライン、ランタイム構成、モニタリング、ロギング、アラート、そしてセキュリティの表面が追加されます。 サービスが3つのときには軽く感じられたものが、30個になると深刻な保守負担になり得ます。
そして次に認知的負荷がやってきます。 エンジニアは現在、ビジネスロジックだけでなく、サービスの境界、API、契約、リトライ、タイムアウト、そして失敗モードも理解する必要があります。 単純なユーザー発行のデバッグが、複数のチームやツールを巻き込んだ分散システムの調査に発展することがあります。
パフォーマンスと信頼性も損なわれる可能性があります。 ネットワーク呼び出しはインプロセス呼び出しを置き換え、レイテンシーを追加し、失敗のポイントを増やします。 理論上はレジリエンスを得られますが、それは観測性、サーキットブレーカー、CHAOSテストに多大な投資を行った場合に限られます。これらの投資はしばしば過小評価されがちです。
最後に、組織的コストがあります。 マイクロサービスはチーム構成を反映する傾向があります。 明確なオーナーシップがないままサービスを追加すると、責任が曖昧になり、意思決定が遅くなり、調整の手間が増加します。
問題なのはマイクロサービスそのものではなく、検証されないままの成長です。 「もう一つだけ」追加する前に、その複雑さが本当にスピード、レジリエンス、明確さをもたらしているのかを問い直す価値があります。 時には、最もスケーラブルな判断は、分割しないタイミングを見極めることです。
Comments