マイクロサービスを使用すべきでないのはいつですか?

Question

Accepted Answer

マイクロサービスは多くの場合、**間違った**最初の選択肢です。一般的なルールは**「モノリス優先」**です。構造の良いモノリスから始めて、具体的な理由がある場合にのみサービスを抽出します。

## マイクロサービスを避けるべき場合

```text
✗ Small team — more services than people to run them
✗ Early-stage product — domain boundaries still shifting
✗ No CI/CD, monitoring, or tracing in place
✗ Low traffic — no real scaling pressure
✗ Simple domain — splitting adds cost, not value
```

## 早すぎる分割のコスト

プロセス内メソッド呼び出しをネットワーク呼び出しに移動すると、レイテンシ、障害モード、シリアライゼーション、およびデプロイメント単位が追加されます。境界が間違っていない場合、すべてのコストを支払い**それでも**サービス間でリファクタリングする必要があります。

```text
method call        →  microseconds, can't fail
network call       →  milliseconds, can time out, can be down
```

## より良いパス

```text
Start: modular monolith (clear internal boundaries)
  └─▶ Extract a service ONLY when:
         · it needs independent scaling, OR
         · a separate team needs independent deploys, OR
         · it needs a different tech/SLA
```

## なぜ重要なのか

マイクロサービスを早すぎる段階で採用するほとんどのチームは、より速くなるのではなく遅くなります。必要になる前に分散システムのオーバーヘッドを負担しているからです。

最初はモノリス内に境界を保つことで、ドメインを低コストで学ぶことができ、後で正しいシームに沿って分割できます。