1 つのサービスの遅れが全体に広がるのを、どう防ぎますか

どう広がるか

商品の画面が、おすすめのサービスを呼んでいるとします。おすすめのサービスが 10 秒かかるようになると、商品の画面のサーバーは、1 つのリクエストのために 10 秒ずつ接続と処理の枠を握ります。枠が埋まると、おすすめと関係の無い購入やログインのリクエストまで待たされ、やがて商品の画面のサーバーも遅くなります。それを呼んでいるほかのサービスも同じように詰まり、遅れが上へ上へと広がります。

さらに、呼び出し元が失敗を見て再試行すると、弱っている相手への呼び出しが増え、立ち直りを遅らせます。

待ちを切る、呼ぶのを止める

まず、外を呼ぶ所すべてにタイムアウトを置き、待ちの長さに上限を付けます。それでも、失敗するとわかっている相手を毎回タイムアウトまで待つのは無駄です。

サーキットブレーカーは、失敗が続いた相手を「開」の状態にして、しばらく呼ばずにすぐ代わりの答えを返す仕組みです。時間がたったら「半開」で 1 回だけ試し、成功すれば「閉」に戻して呼び出しを再開します。失敗が 3 回続いたら開き、3 単位の時間たったら試す、という動きを小さく書くと次の通りです。

function createBreaker(limit, coolDown) {
  let state = "閉";
  let failures = 0;
  let openedAt = 0;

  return function call(time, ok) {
    if (state === "開") {
      if (time - openedAt < coolDown) {
        return time + " 開 呼ばずに代わりの表示";
      }
      state = "半開";
    }
    if (ok) {
      state = "閉";
      failures = 0;
      return time + " 呼んで成功 → 閉";
    }
    failures += 1;
    if (state === "半開" || failures >= limit) {
      state = "開";
      openedAt = time;
      failures = 0;
      return time + " 呼んで失敗 → 開";
    }
    return time + " 呼んで失敗 (" + failures + " 回目)";
  };
}

const call = createBreaker(3, 3);
const results = [false, false, false, true, true, false, true, true, true, true];
results.forEach((ok, time) => console.log(call(time, ok)));

0 呼んで失敗 (1 回目)
1 呼んで失敗 (2 回目)
2 呼んで失敗 → 開
3 開 呼ばずに代わりの表示
4 開 呼ばずに代わりの表示
5 呼んで失敗 → 開
6 開 呼ばずに代わりの表示
7 開 呼ばずに代わりの表示
8 呼んで成功 → 閉
9 呼んで成功 → 閉

開いている間は相手を呼ばないので、自分は待たずに済み、相手は休んで立ち直る時間を得ます。

枠を分ける、早めに断る

• 相手ごとに枠を分ける接続の数や同時に走る処理の数を、呼ぶ相手ごとに分けておきます。おすすめのサービス向けの枠が埋まっても、決済向けの枠は残ります。船の区画を仕切って、1 つの穴で全体が沈まないようにする考えで、バルクヘッドと呼ばれます
• 溢れた分は早めに断る自分が受けきれないほどのリクエストが来たら、待たせて全部を遅くするより、一部をすぐに 503 で断るほうが、残りを速く返せます。待ち行列にも長さの上限を付けます

代わりの表示で動き続ける

機能ごとに、止まったときの振る舞いを先に決めておきます。おすすめが出せなければ人気順の固定の一覧を出す、レビューが読めなければ欄を隠す、のようにします。守るべき機能 (ログイン、購入) と、止まってもよい機能を分けておけば、障害のときに何を切り捨てるかで迷いません。

ヘルスチェックにも気をつけます。ヘルスチェックの中で外の相手まで調べると、相手が止まっただけで自分の全台が「不健康」と判定され、ロードバランサから外されてしまいます。自分が動けるかだけを見るようにします。

トレードオフ

サーキットブレーカーは、開く条件が敏感すぎると、少しの揺れで本当は使える相手を止めてしまい、鈍すぎると広がりを防げません。枠を分けると、空いている枠を融通できず、全体の使い方は少し無駄になります。代わりの表示も、作って確かめる手間がかかります。全部の呼び出しに入れるのではなく、止まると全体を巻き込む相手、止まっても代わりがある機能から入れます。

話す例は架空の例で構いません。「通知のサービスが遅くなった日に、投稿の保存まで遅くなったので、通知の呼び出しにタイムアウトとサーキットブレーカーを入れ、通知は後でキューから送る形にした」のように話せると伝わります。