データの流れ

1件の道のりを順に並べる

構成図は部品の繋がりを表し、流れ図は要求1件が通る順番を表します。席の予約サービスでは、空席を見る要求と予約を確定する要求で、使う線も順番も違います。

アプリから保存先への線が1本でも、予約では在庫の確認と書き込みが必要です。線の本数から、保存先を呼ぶ回数は決められません。

構成図だけでは、何を先に確かめたかは分かりません。予約の流れには、同じ要求かの確認、席の確認、確定した結果の返却までを順に書きます。

DAU 3万、1人6回で平均約2 QPS、ピーク係数50で100 QPSという規模の前提は共通です。1台40件毎秒なら3台ですが、この台数から予約1件の待ち時間は分かりません。

QPS は毎秒の件数で、待ち時間は1件にかかる時間です。月5万円の予算で台を増やせなくても、長い段を見つければ別の改善を検討できます。

抜けを確かめてから時間を足す

前の段の終わりと次の段の始まりを突き合わせます。名前が一致しなければ、書き忘れた段か、名前の揺れがあると考えます。

直列に実行する段なら、段ごとの時間を足して全体を出せます。並列に進む仕事や、返答後に行う通知の時間まで足すと、利用者が待つ時間とは違う値になります。

抜けた段の時間は分からないので、誤差とは言えません。認証や保存の確認を飛ばした合計は、応答時間を説明する根拠に使えません。

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

予約を確定して利用者へ返すまでを、直列の段として見ます。次は説明用に置いた時間で、実測値ではありません。

合計は各段の時間の和なので、2＋1＋3＋20＋4＝30ミリ秒です。保存先の段は20÷30で約67％を占め、ここを測ると全体の遅さを調べられます。

3段目を落とすと、合計は27ミリ秒に見えてしまいます。app 内の処理は名前の繋がりだけでは発見できないので、処理内容も併せて確認します。

通知は予約の返答後にキューから別の処理へ渡します。予約が成功した地点と通知が終わった地点を分けておけば、通知の遅れを予約の失敗と取り違えません。