マイクロサービスとは一体何なのか？

マイクロサービスとは一体何なのか？ 2026年7月26日 ソフトウェアアーキテクチャに関する会話で、マイクロサービスに言及しないことはほとんど不可能だ。私の前回の投稿への議論を見ればわかるだろう。誰に聞くかによって、「良いアーキテクチャ」と「過剰設計」の両方のデフォルトの例となっている。興味深いのは、誰もが見たときにマイクロサービスを認識しているように見えるのに、実際に何かがマイクロサービスである理由を説明できる人はほとんどいないことだ。 不可能な定義 どれくらい小さいのがマイクロなのか？サービスは正確に一つのことだけをするべきか？二つ？コード行数に上限はあるのか？千行？一万行？説得力のある答えは誰も持っていない、なぜならそれらは存在しないからだ。業界は長年、技術的な特性によってマイクロサービスを定義しようとしてきたが、それらの特性は驚くほど曖昧で不明瞭だ。境界は、責任の範囲や1日あたりのデプロイ数で測定されるのではない。それは全く別の場所で測定される。そしてそれが重要な気づきだ：マイクロサービスは主に技術的な抽象化ではない。 解決している問題 モノリスから離れる理由として人々が通常挙げることを聞いてほしい：デプロイが遅い、テストに時間がかかりすぎる、ビルドが面倒だ。これらは実際の問題だが、どれもマイクロサービスを必要としない。一つ残らず、モノリスの中に留まったままでも改善できる。では、なぜ組織はそれでも移行するのだろうか？それは、ボトルネックが技術的なものではないことがほとんどだからだ。それは組織的なものだ。企業が成長するにつれて、数十人、数百人のエンジニアが独立して働く必要が出てくる。チームはオーナーシップを必要とする。彼らは、他の全員と絶えず調整することなく、独自のスケジュールでリリースする必要がある。マイクロサービスは、組織的な境界を反映した境界を作り出す。それが彼らの真の価値だ。 すべての利点には代償が伴う エンジニアリングとは、トレードオフを管理する技術だ。マイクロサービスも例外ではない。自律性を得るが、中央集権性を失う。モノリスの中では、「どの依存関係をデプロイしているのか？」や「このコード片はまだ使われているのか？」といった質問に答えるのは簡単だ。静的解析でしばしばわかる。コードが数十の独立したサービスに分散されると、それらの答えを得ることははるかに難しくなる。同じパターンがあらゆる場所で繰り返される。関数間の通信は、ネットワーク越しの通信になる。メソッド呼び出しはHTTPリクエストになる。コンパイラエラーは実行時エラーになる。レイテンシー、リトライ、部分的な障害、シリアライゼーション、一貫性など、あらゆる分散システムの問題が、突然あなたのアプリケーションの一部となる。これらのコストはどれも驚くべきものではない。それらは単に、分散システムが提供する柔軟性のために支払う代償だ。 隠れたコミュニケーションコスト 人々がコミュニケーションオーバーヘッドについて話すとき、通常はAPI同士が通信することを考える。それは話の半分に過ぎない。チームもコミュニケーションをとる必要が出てくる。APIの変更はもはやリファクタリングではない。それは交渉だ。コンシューマーは事前の通知を必要とする。バージョニングが必要になる。全員が移行する間、古いバージョンを維持する必要がある。データベースの変更は、簡単なコミットではなく、調整された作業となる。ソフトウェアだけが分散しているのではない。意思決定も同様だ。 正しい理由で選択する これらはどれもマイクロサービスに反対する議論ではない。それらは適切な環境においては優れたアーキテクチャの選択肢だ。多くの成功した企業は、それなしでは運営できないだろう。しかし、なぜそれらが機能するのかについて正直であることは価値がある。あなたの主な問題が組織的なスケーリングであれば、マイクロサービスはまさに正しい答えかもしれない。あなたの問題が純粋に技術的なものであれば、あなたはまず、問題自体よりもはるかに大きな解決策を求めているのではないかと自問すべきだ。マイクロサービスが魔法の技術ツールであるという偽りをやめれば、アーキテクチャははるかに理解しやすくなる。それらは技術的な結果を伴う組織的なツールなのだ。 もし見たいのであれば、この議論のビデオ版も作成しました：What even are microservices? 読んでくれてありがとう。