ストーリー

マイクロサービスのメリット

1. 独立デプロイ

モノリス:
  変更 → ビルド(30分) → テスト(60分) → デプロイ(30分)  = 2時間

マイクロサービス:
  変更 → ビルド(5分) → テスト(10分) → デプロイ(5分)    = 20分

各サービスが独立してデプロイできるため、リリースサイクルが大幅に短縮されます。

2. 技術の多様性

// サービスごとに最適な技術を選択できる
const techStack = {
  userService:    { language: "TypeScript", db: "PostgreSQL" },
  searchService:  { language: "Go",         db: "Elasticsearch" },
  mlService:      { language: "Python",     db: "Redis" },
  paymentService: { language: "Java",       db: "MySQL" },
};

3. 独立スケーリング

月末セール時:
  注文サービス: 10インスタンス ← 負荷が高い
  ユーザーサービス: 2インスタンス ← 通常通り
  商品サービス: 5インスタンス ← やや高い

4. 障害の分離

1つのサービスがダウンしても、他のサービスは動作し続けます（適切に設計されていれば）。

5. チームの自律性

各チームがサービスを所有し、自律的に意思決定できます（Two-Pizza Team）。

マイクロサービスのリスク

1. 運用の複雑さ

// モノリス: 1つのプロセスを監視
const monitoring = { targets: ["monolith-app"] };

// マイクロサービス: 数十〜数百のサービスを監視
const monitoring = {
  targets: [
    "user-service", "order-service", "payment-service",
    "notification-service", "search-service", "inventory-service",
    "shipping-service", "analytics-service", "auth-service",
    // ... さらに続く
  ],
  // さらにこれらの間の通信も監視が必要
  tracing: "distributed-tracing-required",
  logging: "centralized-logging-required",
};

2. ネットワーク通信のコスト

3. データの一貫性

// モノリスなら簡単なトランザクション
async function transferMoney(from: string, to: string, amount: number) {
  await db.transaction(async (tx) => {
    await tx.debit(from, amount);
    await tx.credit(to, amount);
  }); // ACID保証
}

// マイクロサービスでは...
// AccountServiceとPaymentServiceが別のDBを持つ
// → 分散トランザクション（Saga）が必要
// → 結果整合性を受け入れる必要がある

4. テストの難しさ

モノリス:
  単体テスト → 統合テスト → E2Eテスト

マイクロサービス:
  単体テスト → コンポーネントテスト → Contract Testing
  → 統合テスト → E2Eテスト → Chaos Engineering

5. 「分散モノリス」のリスク

不適切に分割すると、モノリスの問題とマイクロサービスの問題を両方抱えます。

分散モノリス の特徴:
  ✗ サービスが密結合で独立デプロイできない
  ✗ 1つのサービス変更に他サービスの同時変更が必要
  ✗ 同期呼び出しの連鎖でレイテンシが悪化
  ✗ 共有データベースで境界が曖昧

採用判断のフレームワーク

interface MicroservicesReadinessCheck {
  // 組織の準備
  teamSize: ">= 20人";           // 小さすぎるチームには過剰
  devOpsMaturity: "CI/CDが整備済み";
  monitoringCapability: "集中ログ・メトリクス基盤あり";

  // 技術的な動機
  scalingNeeds: "サービスごとに異なるスケーリング要件";
  deployFrequency: "頻繁な独立デプロイが必要";
  techDiversity: "異なる技術スタックが有利";

  // ビジネスの動機
  domainComplexity: "明確なドメイン境界が存在";
  teamAutonomy: "チームの自律性が重要";
}

まとめ

チェックリスト

• マイクロサービスの5つのメリットを列挙できる
• マイクロサービスの5つのリスクを列挙できる
• 分散モノリスが何か説明できる
• 採用判断のフレームワークを使える

次のステップへ

メリットとリスクを理解したところで、次は「どのようにサービスを分割するか」を学びます。適切な境界を見極める力が、マイクロサービス成功の鍵です。

推定読了時間: 25分