マイクロサービスは『目的が明確な時だけ』有効
マイクロサービスは万能ではなく、目的が明確なときだけ価値を発揮するアーキテクチャ選択です。小規模なのに分割しすぎると、運用負荷だけが増えて開発速度が落ちる失敗例が多くあります。本記事では、マイクロサービス化の判断軸、分割パターン、運用負荷を編集部の視点で整理します。SREへの転身ガイド もご参考に。
マイクロサービスで得られるもの
(1) 独立したデプロイ：チーム単位で速度を上げられる。(2) 技術選択の自由：サービスごとに最適な技術。(3) 障害分離：一部の障害が全体に波及しにくい。(4) スケール独立：負荷の高い部分だけ拡張。(5) 組織のスケール：チーム規模に応じて分割。テックリード vs EM もご参考に（チーム設計）。
マイクロサービスで失うもの
(1) 分散トランザクション：データ整合性の難しさ。(2) 運用負荷：サービスごとのデプロイ・監視。(3) テスト複雑性：統合テストが難しい。(4) ネットワーク信頼性：レイテンシ・障害。(5) 開発者体験：ローカル開発の難しさ。「コンウェイの法則」を理解し、チーム構造とアーキテクチャを揃えることが鍵です。Docker・K8s学習 もご参考に。
判断軸（モノリスを選ぶべき時）
(1) チーム規模が小さい：10人以下。(2) ドメインが固まっていない：分割の境界が見えない。(3) 運用基盤が未整備：監視・デプロイの自動化が不十分。(4) スタートアップ初期：プロダクト市場適合性が優先。(5) 分散トランザクションが多い：整合性が複雑。SaaS MVPの作り方 もご参考に。
モジュラーモノリスという選択
(1) モノリスの中で論理的に分割：モジュール境界を作る。(2) 運用は1つ：デプロイ・監視がシンプル。(3) 後で切り出せる：境界が明確なら分割は容易。(4) 多くのケースで最適：中規模までは強い選択。(5) 境界の維持が課題：規律が必要。「将来分割できる構造のモノリス」が現代の標準的な選択肢になっています。
分割の典型的な単位
(1) 境界づけられたコンテキスト：DDD の概念。(2) サブドメイン：注文・在庫・課金 等。(3) 変更頻度の違い：頻繁に変わる部分を分離。(4) スケール特性の違い：負荷特性が違う部分。(5) 所有チーム：チーム境界に合わせる。データベース基礎の学習ロードマップ もご参考に。
分散システムの基本パターン
(1) 同期 HTTP/gRPC：シンプルだが結合が強い。(2) 非同期メッセージング：キュー・イベント駆動。(3) Saga パターン：分散トランザクションの代替。(4) API Gateway：クライアントとの集約。(5) サーキットブレーカー：障害伝播を防ぐ。SREへの転身ガイド もご参考に。
運用の必須コンポーネント
(1) サービス検出：動的な接続先解決。(2) 監視・トレーシング：分散トレーシング必須。(3) ログ集約：横断検索。(4) CI/CD パイプライン：サービスごとの自動化。(5) シークレット管理：集中管理。CI/CDパイプライン設計、Sentry活用 もご参考に。
失敗しがちなパターン
(1) 早すぎる分割：必要性なく分散の罠に陥る。(2) 分散モノリス：強く結合した分散システム。(3) 運用基盤後手：監視・トレーシングなしで本番運用。(4) データ共有 DB：分散の利点を失う。(5) チーム構造とのミスマッチ：コンウェイの法則無視。対策は、(1)モノリスから始める、(2)分割は1つずつ、(3)運用基盤先行、(4)DB 分離、(5)組織連動、です。IT・Web業界の職種完全マップ もご活用ください。