インフラ・運用見積もり
100件/秒なら、同時に何件処理している？
使うツール
毎秒100件のAPIを処理するなら、100個の処理枠が必要でしょうか。答えは、各リクエストがどれくらいの時間そこに滞在するかによって変わります。0.01秒で終わる仕事と、2秒待つ仕事では、同じ到着数でも同時に残る件数が違います。QPS・平均同時処理数ツールでは、安定した系の平均を見積もります。必要なサーバー台数を自動決定するものではなく、観測値同士のつながりを整理するための計算です。
100件/秒と0.2秒で、平均20件になる
L = λ × W
100 requests/second × 0.2 seconds = 20 requests平均同時処理数を求める方式で、到着率100、平均滞在時間0.2秒を入力します。結果は20です。毎秒の件数に秒を掛けると、秒が消えて件数になります。100人の利用者という意味でも、100個のCPUという意味でもありません。ここで数える対象は、選んだシステムの中にあるリクエストです。何を一件として数えたかを先にそろえます。
200msという観測値なら、0.2秒にして入力します。200と入れると200秒として平均20000件になり、1000倍の誤差です。また、到着率が一分あたりの100件なら、毎秒100件とは違います。単位変換の間違いを性能問題と取り違えないよう、計算式を結果と一緒に残します。
滞在時間は、処理している時間だけとは限らない
受付から応答までをシステムの範囲にするなら、キュー待ちや外部サービスの応答待ちも滞在時間に含まれます。CPUを使っている時間だけを入力すると、リクエスト全体の平均滞在数とは別の問いになります。到着率はAPI全体、時間はDB処理だけ、という混ぜ方では、何の平均件数を求めたか分からなくなります。同じ境界へ入って出る対象の時間と率を使います。
例えば平均0.2秒のうち0.15秒が外部API待ちなら、平均20件が滞在していても20個のCPUが常に必要とは言えません。非同期処理や接続待ちの扱いによって資源の使い方が違います。待ちも含めた件数を知る計算と、CPU時間や接続プールを見積もる計算は分けて検討します。
処理が遅くなると、到着数が同じでも滞在数が増える
100/s × 0.2 s = 20
100/s × 0.5 s = 50
100/s × 2.0 s = 200到着率を100のまま、平均時間を0.5秒、2秒へ変えてみます。結果は50、200へ増えます。アクセス件数が急増していなくても、外部処理が遅くなれば同時に残るリクエストが増えることを説明できます。ただし、時間が長くなった原因をこの式が診断するわけではありません。待ち時間の内訳は実際の観測で確認します。
逆に改善で平均時間が短くなれば、同じ到着率での平均滞在数も減るモデルです。ただし、短くなったのが平均ではなく最速値だけなら、この入力へ置き換える根拠にはなりません。改善前後を比較するときも、同じ種類のリクエストと同じ集計方法で計測した平均を使います。
平均20件は、最大20件でも20枠で十分でもない
到着がまとまる時間帯や、長く待つリクエストがあると、瞬間の件数は平均を上回ります。平均20という結果だけで、上限を20にすれば待ちが起きないとは言えません。また、p95やp99の応答時間を平均時間の代わりに入れた積を、そのままp95やp99の同時処理数と呼ぶこともできません。分位点同士の関係をこの式が求めているわけではないためです。
画面に整数へ切り上げた参考値があっても、資源の必要数を保証する値ではありません。平均0.5件なら、常に半件の処理が存在するのではなく、空いている時間も含めた平均です。何枠設けるかを決めるには、許容する待ち、ピーク、失敗率、負荷試験など、平均とは別の条件が必要になります。
積み残しが増え続けていないかも確認する
このツールの説明は、平均として安定した系を前提にしています。処理し切れない仕事が増え続ける区間を、ずっと同じ平均で運転できる状態として扱わないでください。計測開始時の積み残し、途中の失敗やキャンセル、対象期間の端をまたぐ長い処理も、集計のしかたに影響します。到着件数と完了件数を確認し、比較可能な観測区間かを判断します。
報告には『毎秒100件、平均滞在0.2秒、受付から応答までを対象にした平均20件』のように、入力と境界を添えます。数字だけをCPU数や最大同時接続数へ置き換えず、待ちの増加を説明したり、計測値の不整合に気付いたりするための材料として使うと、この小さな計算を実務へ結び付けられます。