生き死にを見る

配ってよい台を確かめる

席の予約サービスの振り分けは、一定間隔で各アプリへ確認の要求を送ります。時間内に正常な応答が返るかを見て、予約の要求を配ってよい台を選ぶのがヘルスチェックです。

確認に失敗した台へ配り続けると、利用者は予約できる台が残っていても失敗します。外した台は、回復を確かめてから配り先へ戻します。

確認の中身も決めます。単にプロセスが動いているかと、予約の要求を受け付けられるかは違うので、配り先の判定には後者を確かめる応答を使います。

その可能性があります。一時的な回線の詰まりまで故障と扱うと、正常な台が次々に外れ、残った台へ負荷が集まります。

外す判定には連続した失敗を使います。間に成功があれば失敗の回数をゼロへ戻し、離れた時刻の失敗を足し合わせないようにします。

戻す判定も連続で数える

外す回数と戻す回数は、別々に決めます。戻す側を慎重にすると、一度だけ応答が返った不安定な台をすぐに戻すことを防げます。

要求が再び不調な台へ届き、失敗や再試行が増えます。残った台の負荷も増減するので、配り先の揺れが障害を広げることがあります。

連続回数を増やすほど一時的な失敗には強くなりますが、本当の故障を外すまでの時間は延びます。確認間隔と回数を組にして、検知の遅れと誤判定を比べます。

全台に共通する保存先の障害にも注意します。それを各アプリの故障と判定して全台を外しても保存先は直らないため、共通部分の状態を別に監視します。

予約サービスで解いてみる

平均2 QPSにピーク係数50を掛けた予約サービスは、毎秒100件を受ける想定です。1台40件のアプリ3台なら120件ですが、1台を外すと80件まで下がります。

一時的な遅れで外すだけでも、残った2台ではピークを処理しきれません。故障中の余力を確保する台数の判断と、配り先の判定を両方行います。

ここでは5秒間隔で確認し、3回連続の失敗で外し、4回連続の成功で戻します。開始時は配り先に入っているものとします。

失敗を確認してから外すまで、追加の2回を待つので10秒かかります。故障の発生からなら次の確認までの待ちもあり、確認の時間を除いて最大約15秒です。

この設定を万能の数字とは考えません。月5万円の制約の中で余力と検知時間を確認し、一時的な失敗を拾いすぎないか、故障した台へ長く配っていないかを測って調整します。