マイクロサービスの実務

1つのアプリケーションに、すべての機能が入っている—— これをモノリスと呼びます。そして、最初はこれが正解です。

では、なぜ分割する話が出てくるのか。規模が大きくなると、次が起きます。

□ 100人の開発者が、同じコードベースを触る
   → コンフリクトが頻発し、レビューが渋滞する
□ リリースが週1回に固定される
   → 1行の修正でも、全機能のテストが終わるまで出せない
□ 誰かの変更が原因で、全体が落ちる
   → 障害の影響範囲が「サービス全部」になる
□ 一部の機能だけスケールしたいのに、全体を増やすしかない
   → コストが跳ね上がる
□ 新しい言語や技術を試せない
   → すべてが1つの技術に縛られる

「チームの人数」と「変更の速度」が、技術ではなく組織の問題として詰まる—— これがマイクロサービスという発想が生まれた背景です。

そして分割すると、問題は消えるのではなく、場所が変わります。

モノリス:        1つの中が複雑になる（コードの複雑さ）
マイクロサービス: サービスとサービスの「あいだ」が複雑になる（分散の複雑さ）

この章で扱うのは、後者です。 そして分散の複雑さは、関数呼び出しでは絶対に起きなかった種類の問題を持ち込みます。

□ 開発者が5人      → モノリスのほうが速い。圧倒的に
□ 開発者が100人    → 分割しないと詰まる

なぜ分割するのか、その代償

分けて得られるもの

• チームごとに独立してデプロイできる（他チームを待たなくていい）
• 障害の影響範囲を限定できる
• サービスごとに適した技術を選べる

分けて失うもの

前提: ネットワークは失敗する

分散システムを考える上での出発点です。

• パケットは失われる
• 相手は落ちているかもしれない
• 遅いだけかもしれない（落ちているのと区別できない）
• 応答が返らなくても、相手は処理を完了しているかもしれない

最後の項目が最も重要です。 「タイムアウトした = 失敗した」ではありません。

タイムアウト

すべての外部呼び出しにタイムアウトを設定してください。

設定しないと、相手が応答しない時にこちらのリソースが解放されず、 自分も道連れで落ちます。

上流ほど長く

ユーザー ──3秒──→ [API GW] ──2秒──→ [注文] ──1秒──→ [在庫]

呼ぶ側のタイムアウトは、呼ばれる側より長くします。逆にすると、

❌ [注文: 1秒] ──→ [在庫: 3秒]

在庫サービスが2秒かけて正常に処理を終えても、 注文側は1秒で諦めており、その処理は無駄になります。 しかも在庫側は「成功した」と記録しているかもしれません。

API GW 3秒
 ├ 認証     0.2秒
 ├ 注文     2.0秒
 │   └ 在庫  0.8秒
 └ 整形     0.1秒

リトライ

失敗したら再試行する。単純に見えて、危険な機能です。

リトライしてよい条件

INVALID_ARGUMENT や 400 はリトライしても無駄です（何度送っても同じ結果）。

リトライストーム

新人が最も理解しておくべき失敗パターンです。

在庫サービスが遅くなる
      ↓
注文サービスがタイムアウトしてリトライ
      ↓
在庫サービスへのリクエストが 2倍・3倍に
      ↓
在庫サービスがさらに遅くなる
      ↓
もっとリトライされる
      ↓
完全に停止 → 全体が停止

弱っている相手を、善意のリトライで殺します。

正しいリトライ

// 危険: すぐに、何度も
for (let i = 0; i < 5; i++) {
  try { return await call(); } catch { /* すぐ再試行 */ }
}
 
// 安全: 間隔を空け、ばらつかせ、回数を絞る
async function callWithRetry() {
  for (let attempt = 0; attempt < 3; attempt++) {
    try {
      return await call();
    } catch (error) {
      if (!isRetryable(error) || attempt === 2) throw error;
      // 指数バックオフ + ジッター
      const base = 100 * 2 ** attempt;          // 100, 200, 400ms
      const jitter = Math.random() * base;      // ばらつかせる
      await sleep(base + jitter);
    }
  }
}

GW(3回) → 注文(3回) → 在庫(3回)

冪等性

冪等なもの:   「残高を1000円にする」→ 何回やっても1000円
冪等でないもの: 「残高に1000円足す」→ やるたびに増える

リトライを安全にするための鍵です。

同じ操作を何回実行しても、結果が1回分と同じになる性質

GET    /items/42        冪等（何回読んでも同じ）
DELETE /items/42        冪等（2回目は「もう無い」で同じ結果）
POST   /orders          冪等でない ← 呼ぶたびに注文が増える

冪等キー

POST を冪等にするには、クライアントが一意なキーを付けます。

POST /payments
Idempotency-Key: 7f3c1e2a-...
 
{ "orderId": "42", "amount": 1200 }

サーバー側の処理はこうなります。

1. このキーで処理済みか確認する
2. 済みなら、前回の結果をそのまま返す（再処理しない）
3. 未処理なら実行し、キーと結果を保存する

これで、ネットワークが不安定でも二重決済が起きません。

1. 注文APIを呼ぶ → タイムアウト
2. 「失敗したはず」と考えて、もう一度呼ぶ
3. 実は1回目も成功していた → 注文が2件できる

サーキットブレーカー

相手が明らかに壊れている時、呼ぶのをやめる仕組みです。

Closed（通常）  ──失敗が閾値を超えた──→  Open（遮断）
      ↑                                    │
      │                              一定時間後
      └────  成功したら戻る  ──── Half-Open（試しに1本流す）

Open の間は、相手を呼ばずに即座に失敗を返します。

意味があるのは2つです。

1. 相手に回復の時間を与える（叩き続けない）
2. 自分のリソースを守る（応答待ちで詰まらない）

分散トレース

複数サービスにまたがるリクエストを追跡する仕組みです。

[trace: abc123]
├── API Gateway            5ms
│   └── 注文サービス       850ms   ← 遅い
│       ├── ユーザー取得    20ms
│       ├── 在庫確認         30ms
│       └── 商品取得        780ms  ← 犯人はここ
│           ├── 商品1        26ms
│           ├── 商品2        26ms
│           ├── ...（30回）

このウォーターフォールを見れば、どこで時間を使っているかが一目で分かります。 上の例は、商品取得が N+1 になっているパターンです（データベース）。

よく見るパターン

構造化ログと相関 ID

トレースがなくても、相関 ID があればログを繋げられます。

{"level":"info","msg":"order created","trace_id":"abc123","order_id":"42","service":"order"}
{"level":"info","msg":"stock reserved","trace_id":"abc123","item_id":"7","service":"stock"}
{"level":"error","msg":"payment failed","trace_id":"abc123","service":"payment"}

trace_id で検索すれば、1つのリクエストの全経路が一列に並びます。

これがないと、「10時5分ごろのエラー」を各サービスのログから 目視で突き合わせることになります。障害対応の速度が桁違いに変わります。

強い整合性    書いた瞬間から、誰が読んでも同じ値が見える
結果整合性    少し遅れて反映される（数ミリ秒〜数秒）

データの整合性

マイクロサービスで最も難しい部分です。

注文サービス: 注文を作成した
在庫サービス: 在庫を減らそうとして失敗した
        ↓
   注文だけ残ってしまう

1つの DB なら、トランザクションで両方なかったことにできます。 サービスが分かれていると、それができません。

現実的な対処

新人が最初に気をつけること

実務に入ってすぐ役立つ順に並べます。

1. ctx を必ず下流に渡す — キャンセルとトレースが伝わる
2. 外部呼び出しには必ずタイムアウト — 設定しないと道連れで落ちる
3. ログに trace_id を含める — 調査できるかどうかが決まる
4. リトライを足す前に相談する — ストームと二重実行のリスクがある
5. 副作用のある操作は冪等性を考える — 「タイムアウト = 失敗」ではない

実務の落とし穴まとめ

1. タイムアウトを設定しない — 相手の不調で自分も落ちる
2. タイムアウトが上流 < 下流 — 無駄な処理が走る
3. 各層でリトライ — 27倍のリクエストになる
4. バックオフなしのリトライ — リトライストームで相手を殺す
5. 冪等性を考えずにリトライ — 二重決済
6. ctx を渡さない — トレースが切れ、キャンセルも効かない

まとめ

• マイクロサービスの難しさは サービスの「あいだ」 にある
• ネットワークは失敗する。「タイムアウト = 失敗」ではない
• すべての外部呼び出しにタイムアウト。上流ほど長く
• リトライは一時的な失敗 × 冪等な操作の時だけ。 指数バックオフ + ジッター + 回数制限、そして1箇所だけ
• 副作用のある操作には冪等キー
• 壊れた相手はサーキットブレーカーで切り離し、フォールバックを返す
• trace_id を全ログに。分散トレースで N+1 と直列実行が見える
• 整合性が難しいなら、まず分割の境界を疑う

公式ドキュメント

迷ったら一次情報に戻ってください。

章末問題

これで第5部は終わりです。

サービスを書き、繋ぎ、動かす—— ここまでが、Web アプリ開発の現場で必要になる技術の骨格です。

次の章では、それが利用者が集中しても倒れないかを扱います。 1件が速いことと、1000件同時でも動くことは別の問題です。