フレームワーク活用ガイドひとことで言うと#
1つの大きなアプリケーションを小さな独立したサービスの集合体に分割し、各サービスが独自のデータベースを持ち、APIで通信するアーキテクチャ。チームとシステムの両方をスケールさせる。
押さえておきたい用語#
- 境界づけられたコンテキスト
- DDDの概念で、1つのサービスが担当するビジネスドメインの境界。サービス分割の最も重要な判断基準。
- 分散モノリス
- マイクロサービスに分割したのに、サービス間の結合度が高く実質的にモノリスと同じ状態。最悪のパターン。
- 結果整合性（Eventual Consistency）
- サービス間のデータが最終的に整合することを許容するモデル。即時整合性は分散システムでは困難。
- サービスメッシュ
- サービス間通信のルーティング・認証・監視をインフラ層で一括管理する仕組み。Istio、Linkerdが代表例。
- API ゲートウェイ
- クライアントからの全リクエストを受け付ける一元的な入り口。認証・レートリミット・ルーティングを担う。
マイクロサービスアーキテクチャの全体像#
こんな悩みに効く#
- モノリスが巨大化して、1つの変更がシステム全体に影響する
- チームが大きくなり、お互いのコード変更が頻繁に競合する
- 一部の機能だけスケールしたいのに、全体をスケールするしかない
基本の使い方#
ビジネスドメインに沿ってサービスを分割する。
- DDDの「境界づけられたコンテキスト」を参考にする
- 1つのサービスが1つのビジネス機能を担当する
- 例：注文サービス、在庫サービス、決済サービス、通知サービス
ポイント: 技術的な都合（フロントエンド/バックエンド）ではなく、ビジネスの境界で分ける。
同期通信と非同期通信を使い分ける。
- 同期: REST API、gRPC（即座にレスポンスが必要な場合）
- 非同期: メッセージキュー、イベントバス（結果整合性でよい場合）
- APIゲートウェイで外部からのアクセスを一元化する
ポイント: 同期通信が多いと、サービス間の結合度が上がる。できるだけ非同期にする。
各サービスが自分専用のデータストアを持つ。
- DB共有は禁止。各サービスがDBを所有する
- サービスをまたぐデータが必要な場合はAPIで取得する
- 結果整合性（Eventual Consistency）を受け入れる
ポイント: DB共有は「分散モノリス」の元凶。最も守るべきルール。
マイクロサービスを支えるインフラと監視を構築する。
- コンテナ化（Docker）とオーケストレーション（Kubernetes）
- サービスメッシュ、サーキットブレーカー
- 分散トレーシング、集中ログ管理
ポイント: マイクロサービスの技術的負債の多くは運用基盤の不備から生まれる。
具体例#
モノリス時代: 1つのRailsアプリで注文、在庫、ユーザー管理、決済、通知をすべて処理。DBは1つのPostgreSQL。デプロイに30分、リリース頻度は週1回。チーム25名が1つのリポジトリで作業し、マージコンフリクトが日常茶飯事。
分割後:
- ユーザーサービス: 認証・プロフィール管理。独自のPostgreSQL
- 商品サービス: 商品情報と在庫管理。独自のMySQL
- 注文サービス: 注文の作成と管理。イベントで在庫サービスと連携
- 決済サービス: 決済処理。注文サービスからのイベントで起動
- 通知サービス: メール・プッシュ通知。各サービスのイベントを購読
結果: デプロイ時間が30分から5分に短縮。リリース頻度が週1回から1日3〜5回に向上。Black Fridayには決済サービスだけを3倍にスケールアウト。
状況: 従業員管理SaaS。モノリスが15万行に成長し、新機能追加に平均2週間。「マイクロサービス化しよう」という声が上がった。
アプローチ: ストラングラーフィグパターンで段階的に移行。
- 最も独立性が高い「通知機能」を最初に切り出し（2週間）
- 次に「勤怠管理機能」を切り出し（3週間）
- 並行して運用基盤（分散トレーシング、ログ集約）を整備
結果: 6ヶ月かけて5サービスに分割。各チーム（4〜6名）が独立してリリースできる体制を構築。一度もサービス停止なし。「最初から全部やろうとしなかった」のが成功要因。
状況: スタートアップ（エンジニア8名）が「先進的だから」という理由でDay 1からマイクロサービスを採用。12サービスに分割。
問題:
- サービス間のAPI変更のたびに複数チームが調整に追われる
- 分散トレーシングがなく、障害調査に3時間以上
- 8名で12サービスの運用は人手が足りず、Kubernetesの運用自体に工数の40%を消費
教訓: モジュラーモノリスに統合し直して開発速度が2倍に回復。「マイクロサービスが必要だと確信できるまではモノリスで行く」が正解だった。
やりがちな失敗パターン#
- 最初からマイクロサービスで始める — ドメインの理解が浅い段階で分割すると、境界を間違えて「分散モノリス」になる。まずモノリスで始めて、成長に応じて分割するのが王道
- サービスが細かすぎる — 1API=1サービスのような極端な分割は、運用コストが爆発する。1チーム（5〜8人）が1〜3サービスを担当するサイズが目安
- 運用基盤なしで始める — CI/CD、監視、ログ集約がないままマイクロサービス化すると、障害対応が地獄になる。運用基盤を先に整備してからサービスを分割する
- DB共有を許容してしまう — 「一時的に」のつもりでDB共有すると、永久に解消できない結合が生まれる。サービス分割と同時にDBも分離することを徹底する
まとめ#
マイクロサービスは銀の弾丸ではなく、チームとシステムが一定規模を超えたときに効果を発揮するアーキテクチャ。分割の境界、データの独立性、運用基盤の3つが揃って初めて機能する。小さなチームならモノリスで十分。「マイクロサービスが必要だと確信できるまではモノリスで行く」が正解。