個別のサービスをスケーリングし、パフォーマンスのボトルネックを見つけるにはどうするのか？

Question

Accepted Answer

マイクロサービスの主な利点は、アプリ全体をスケールするのではなく、**各サービスを独立してスケール**して独自の負荷に対応できることです。ボトルネックを見つけることは、サービスごとおよびホップごとの測定の問題です。

## スケーリング技術

- **水平スケーリング** — ロードバランサーの背後にステートレスなインスタンスを追加します。
- **オートスケーリング** — CPU、メモリ、キューの深さ、またはカスタムメトリクスに基づいてスケールします。
- **キャッシング** — 重複する作業とダウンストリームの負荷を削減します。
- **非同期 + キュー** — スパイクを吸収し、低速の作業を分離します。
- **データスケーリング** — read replicas、sharding、サービス別ストア。

```yaml
# Kubernetes HPA: scale orders on CPU
minReplicas: 3
maxReplicas: 20
metric: cpu
targetUtilization: 70   # add pods when avg CPU > 70%
```

## ボトルネックを見つける

```text
1. Metrics: which service has high latency / saturation? (RED/USE)
2. Traces: which SPAN in the request is slow?
3. Drill in: DB query? lock? N+1 calls? GC pause?
```

```text
Gateway ──┤ Orders ──┤ Payments ████████████ ← 80% of latency here
                       Inventory ─┤
```

## 一般的なボトルネック

```text
⚠️ Chatty synchronous calls (fan-out per request)
⚠️ Shared/overloaded database
⚠️ Missing or cold cache
⚠️ Unbounded retries amplifying load
```

## 落とし穴

ボトルネックが**共有データベース**であるサービスをスケールすると、単により多くの負荷をDBに移動させるだけです — 症状ではなく実際の制約をスケールしてください。

## なぜ重要なのか

独立したスケーリングにより、負荷がある場所に正確に容量を費やすことができ、これはモノリスをまとめてスケールするよりもはるかに安価です。

ただし、盲目的にスケーリングするとお金を浪費し、状況を悪化させる可能性があります。サービスごとのメトリクスとホップごとのトレースを測定することで、修正すべき実際の制約がわかります。