ある API の p99 latency が 3s です — どのように debug して最適化しますか？

Question

IT Interview Practice · Accepted Answer

p99 = **tail latency**: 最も遅い 1% のリクエストが 3s かかる。最初の一手は **推測せず、測定して分解する** ことだ。p50 と p99 を比較する — p50 は速いのに p99 が 3s なら、経路は一様に遅いのではなく、何かが *負荷時やエッジケースでのみ* 噛みついている（pool の飽和、GC の一時停止、N+1、cold cache、タイムアウト未設定の外部呼び出し）。

**メンタルモデル:** p99 は *最も長いレジ列* であり、平均待ち時間ではない — 平均を速くしても、最後尾で詰まった客には何の意味もない。

## プロセス（どこからどこまで）
1. **測定して分解する** — RED メトリクス（Rate, Errors, Duration）+ distributed tracing。p50/p95/p99 を読む。それらの *差* が物語を語る。
2. **ステージを特定する** — 各ステップを instrument して、遅いリクエストがどこで時間を費やすか見る。勘で最適化しない。

```js
// 各ステージを計測して p99 がどこで積み上がるか確認（推測しない）
async function handler(req, res) {
  const t0 = process.hrtime.bigint();
  const mark = (label) =>
    req.log.info({ label, ms: Number(process.hrtime.bigint() - t0) / 1e6 });
  const user = await db.user.find(req.id);   mark('db.user');
  const courses = await loadCourses(user);   mark('loadCourses'); // 容疑者
  res.json(courses);                         mark('total');
}
```

3. **テールの容疑者を特定する** — たいていは *待ち* であって計算ではない: connection-pool の枯渇、N+1 クエリ、タイムアウト未設定の外部呼び出し、GC の一時停止、index の欠落、cold cache。

```js
// BEFORE: N+1 — N 回の逐次ラウンドトリップ、N が増えると p99 が爆発する
const courses = await db.course.findByUser(userId);
for (const c of courses) c.lessons = await db.lesson.byCourse(c.id);

// AFTER: 1 クエリにまとめる -> テールが下がる（N 回の逐次往復はもうない）
const courses = await db.course.findByUser(userId);
const lessons = await db.lesson.byCourseIds(courses.map((c) => c.id)); // 1 つの IN(...)
const byCourse = Map.groupBy(lessons, (l) => l.courseId);
for (const c of courses) c.lessons = byCourse.get(c.id) ?? [];
```

ここで p50（小さい N）は問題なく見えるが、負荷がかかると N が増えて pool が飽和し、**p99 が爆発する**。外部呼び出しには常に **timeout + circuit breaker** を設定し、1 つの遅い依存関係が endpoint 全体の p99 を引きずれないようにする。

4. **1 つ直す → p99 を測り直す → 繰り返す。** 一度に 1 変数、さもなくば何が効いたか分からない。
5. **固定する** — **SLO**（例: p99 < 300ms）+ アラートを設定し、後退しないようにする。

## 面接の視点
面接官は、まぐれ当てではなく *体系的な* プロセスを見ている: **テールと平均** を区別するか、変更前に測定するか、**CPU より先に queue/lock（待ち）** を見るか。弱い回答:「caching を足す / server を scale up する」。強い回答: 測定 → tracing で特定 → 特定のテール原因を直す → 数値で検証する。

## 原則
**平均ではなくテール（p99）を最適化せよ。** ほとんどの「3s p99」は *計算* よりも *待ち*（pool/queue/lock）から生じる — だから CPU より先に queue を見よ。

プロセス（どこからどこまで）

面接の視点

原則

関連する質問