バックプレッシャーとスループットを扱う

目標

キューの深さを遅延時間に翻訳する方法を身につけ、上限とロードシェディングでシステムが自分自身を守るようにしたうえで、並行数の調整で処理率を実際に上げます。

なぜ重要なのか

キューを入れたシステムの事故は、ほとんどが「キューが溜まっているのに、誰も知らなかった」です。APIのダッシュボードはすべて緑で、応答時間も正常で、ユーザーだけが結果を見られません。キューの深さを遅延に翻訳できなければ、この状況がどれほど深刻かを判断できません。リトルの法則W = L / λの1行で済みます。深さ3,000、処理率が毎秒50件なら、いま受け付けているユーザーは60秒待ちます。そして、利用率が100%に近づくほど待ち時間が線形ではなく爆発的に増えるという事実を、グラフで一度見れば、なぜワーカーの容量を流入のちょうど100%に合わせてはいけないのかが、体に残ります。

ステップ

/opt/app/loadgen.pyでq:workに、毎秒200件ずつ10秒間入れます。LLEN q:workが1500以上である必要があります。
/root/qb/measure.shで、1秒間隔で10回キューの深さを測り、/root/qb/depth.csvにt,depthのヘッダーと一緒に11行で残します。
/root/qb/little.txtにL=<깊이> lambda=<초당 처리 건수> W=<초>の3つの値を書きます(プレースホルダーは順に、深さ、毎秒の処理件数、秒数です)。WはLをlambdaで割った値で、小数第1位まで合っている必要があります。
/root/qb/api.pyを127.0.0.1:8142で起動します。POST /enqueueは、キューの長さが1000以上なら429を返します。それ未満なら202を返します。
429の応答に、Retry-Afterヘッダーを整数の秒数で載せます。/root/qb/shed.outにstatus=429 retry_after=<정수>を書きます(プレースホルダーは整数です)。
同じ500件を、ワーカー1つと4つでそれぞれ処理し、/root/qb/concurrency.txtにworkers=1 seconds=<값>とworkers=4 seconds=<값>の2行を書きます(プレースホルダーは値です)。4つのほうが速い必要があります。
/root/qb/report.mdに## 안정 조건、## 목표 이용률、## 상한 정책の3つの見出しを入れ(韓国語の3つの見出しは、順に「安定条件」「目標利用率」「上限ポリシー」を意味します)、各節を25文字以上で書きます。

参考

安定条件: λ < μ。利用率ρ = λ/μは0.7–0.8を目標にします。
リトルの法則: L = λ x W、逆にするとW = L / λ
キューの深さのアラートは、絶対値よりも「5分間増え続けている」のような傾向のほうが信頼できます。
よくある間違いは、ワーカーだけを増やして、その後ろのDBが新しいボトルネックになったことを確認しないことです。

負荷を入れてキューを埋める

/opt/app/loadgen.pyでq:workに、毎秒200件ずつ10秒間入れてください。LLEN q:workが1500以上である必要があります。

/opt/app/loadgen.pyは、毎秒何件ずつ何秒間入れるかを引数で受け取ります。処理より速く入れないと、深さは増えません。

キューの深さを時系列で記録する

/root/qb/measure.shで、1秒間隔で10回キューの深さを測り、/root/qb/depth.csvにt,depthのヘッダーと一緒に11行で残してください。

1秒ごとに長さを測って、CSVで残します。ヘッダー行を忘れないでください。

リトルの法則で待ち時間を推定する

/root/qb/little.txtにL=<깊이> lambda=<초당 처리 건수> W=<초>の3つの値を書いてください(プレースホルダーは順に、深さ、毎秒の処理件数、秒数です)。WはLをlambdaで割った値で、小数第1位まで合っている必要があります。

滞留時間は、深さを処理率で割った値です。3つの値をそれぞれ書かないと採点されません。

キューの上限と429を付ける

/root/qb/api.pyを127.0.0.1:8142で起動してください。POST /enqueueは、キューの長さが1000以上なら429を返します。それ未満なら202を返します。

受け取ってできなくなるより、いまは受けられないと言うほうが誠実です。上限を超えたら拒否してください。

Retry-Afterでリトライの時点を知らせる

429の応答に、Retry-Afterヘッダーを整数の秒数で載せてください。/root/qb/shed.outにstatus=429 retry_after=<정수>を書きます(プレースホルダーは整数です)。

クライアントがいつまた来ればよいかを、数字で知らせます。キューの深さから計算すると、より正確です。

ワーカーの並行数を上げて処理率を改善する

同じ500件を、ワーカー1つと4つでそれぞれ処理し、/root/qb/concurrency.txtにworkers=1 seconds=<값>とworkers=4 seconds=<값>の2行を書いてください(プレースホルダーは値です)。4つのほうが速い必要があります。

同じ負荷を、ワーカー1つと4つでそれぞれ処理して、所要時間を比較します。2つの値をどちらも残してください。

安定条件をまとめる

/root/qb/report.mdに## 안정 조건、## 목표 이용률、## 상한 정책の3つの見出しを入れ(韓国語の3つの見出しは、順に「安定条件」「目標利用率」「上限ポリシー」を意味します)、各節を25文字以上で書いてください。

流入率と処理率の関係、目標利用率、上限ポリシーを、ドキュメントにまとめます。指定された見出しを正確に書いてください。