マイクロサービス

概要

マイクロサービスとは、システムを「注文」「在庫」「決済」「通知」のような業務機能単位の小さなサービス群に分割し、それぞれを独立したアプリケーションとして開発・デプロイ・運用するアーキテクチャです。各サービスは自分専用のコードベースとデータベースを持ち、他のサービスとはネットワーク越しの API（多くは REST API）や メッセージキュー を通じてのみ会話します。

全機能をひとつにまとめる モノリス の対極にある構成で、Netflix、Amazon、Uber などの大規模サービスが実践例として知られています。「マイクロ」という名前ですが、重要なのはサービスの小ささそのものではなく、独立性です。あるサービスの変更が、他のサービスの再デプロイを必要としないこと——これがこのアーキテクチャの核心です。

そしてこの独立性は、技術の話であると同時に組織の話です。サービスごとに担当チームを置き、各チームが自分のサービスを自分のペースでリリースできるようにする。マイクロサービスは「大人数の開発組織を、互いを待たずに並行して動けるようにするための構成」として理解するのが実態に近いです。

なぜ生まれたか

2000年代後半、急成長したWebサービス企業は共通の壁に突き当たりました。数百人の開発者がひとつのモノリスを触ると、リリースは全チームの変更を束ねた一大イベントになり、誰かのバグが全員のデプロイを巻き戻す。障害はシステム全体を道連れにし、一部の機能だけ負荷が高くても全体を スケーリング するしかない。技術スタックも全体でひとつに縛られる。つまり、システムの成長速度が組織の成長に追いつかなくなったのです。

Amazon の「サービスは API のみで通信せよ」という社内方針や、Netflix のクラウド移行での実践がこの問題への答えを示しました。境界を業務機能で切り、チームとサービスを一対一で対応させれば、コミュニケーションのコストとデプロイの調整が劇的に減る。「システムの構造は組織の構造を写す」というコンウェイの法則を逆手に取り、望む組織の形に合わせてシステムを分割する——この発想が2014年頃に「マイクロサービス」として定式化され、コンテナ や クラウドコンピューティング の成熟がそれを技術的に支えました。

詳細

分割の単位とデータの所有

設計の出発点は「どこで切るか」です。定石は、技術の層（画面・ロジック・データ）ではなく業務能力（ビジネスケイパビリティ）で切ること。ドメイン駆動設計の「境界づけられたコンテキスト」が分割線の指針としてよく使われます。そして各サービスは自分のデータベースを排他的に所有し、他サービスのデータを直接読むことは禁じられます。データが欲しければ API を呼ぶ。この規律を破って複数サービスがひとつの DB を共有すると、デプロイの独立性が失われ、「分散したモノリス」という最悪の形になります。

同期と非同期、二つの会話のしかた

サービス間の通信には二つの様式があります。同期呼び出しは HTTP ベースの REST や gRPC で相手の応答を待つ方式で、単純ですが、呼び出しが連鎖すると一つのサービスの遅延・障害が波及します。非同期は メッセージキュー やイベントストリームに「起きたこと」を流し、関心のあるサービスが各自のペースで処理する方式で、疎結合になる代わりに「結果がすぐには反映されない」結果整合性を受け入れることになります。実務では、ユーザーを待たせる経路は同期、後続処理は非同期、と使い分けるのが典型です。

ユーザーを待たせる決済は同期で確実に、後続の在庫引当や通知はイベント経由で非同期に。注文サービスはキューの先に誰がいるかを知らなくてよいため、後から購読者を増やしても注文サービスの変更は不要です。

分散システムの税金

マイクロサービスの代償は、モノリスでは存在しなかった問題群です。プロセス内の関数呼び出しだったものがネットワーク通信になるため、遅延と部分的失敗が常態になります。タイムアウト、リトライ、障害の連鎖を断つサーキットブレーカといった防御が全通信に必要です。複数サービスにまたがる更新はひとつの トランザクション で守れないため、ACID の保証を諦め、Saga パターン（失敗したら補償処理で巻き戻す）のような複雑な手法で整合性を作り込みます。障害調査も一変します。一つのリクエストが何個ものサービスを渡り歩くため、リクエスト ID で ログ を横断的に紐づける分散トレーシングと、充実した 監視 が事実上の必須要件になります。

それを支える運用基盤

数十のサービスを人手でデプロイするのは不可能なので、CI/CD パイプラインの自動化が前提です。実行基盤としては、サービスを コンテナ にパッケージし Kubernetes で配置・スケーリング・自己修復を任せる構成が事実上の標準になりました。サービス間の認証や暗号化、トラフィック制御を通信層で一括して面倒を見るサービスメッシュ（Istio など）や、外部からのリクエストの入口を束ねる API ゲートウェイも、このアーキテクチャに付随して発達した道具です。逆に言えば、これらの基盤を整備・運用できる組織体力がないなら、マイクロサービスはまだ早いというサインです。

採用判断の現実

マイクロサービスで得られる最大のものは、技術的性能ではなく組織のスケーラビリティです。したがって判断基準も組織側にあります。チームが数個以下で、デプロイの衝突に苦しんでいないなら、分散の税金を払う理由はほぼありません。まず モノリス で始めて、境界が業務として確かめられ、組織が大きくなって痛みが出た箇所から切り出す——これが失敗事例の蓄積から得られた現代の定石です。「マイクロサービスを採用する資格は、モノリスをきちんと設計できることだ」と言われるのは、分割の成否が結局のところ境界設計の腕にかかっているからです。