1台構成の限界

1台の上限を時間から考える

席の予約サービスでは、要求が届いてから答えを返すまでの時間を測ります。1件の処理時間が分かれば、1秒に処理できる件数の目安を出せます。

1秒のミリ秒数を1件の時間で割り、同時に動く処理の本数を掛けます。1件25ミリ秒、1本なら、1000 ÷ 25 × 1 で毎秒40件です。

これは1本の処理が順番に要求を終えるモデルです。独立した4本なら計算上は毎秒160件ですが、保存先を共有すると、その通りには増えません。

計算は最初の目安で、実際の上限は負荷をかけて測ります。CPU、メモリ、保存先の待ち時間のどれが先に増えるかも一緒に記録します。

測るときは空席の表示だけでなく、実際に想定する割合の予約処理も流します。軽い要求だけで出した上限を、発売開始の重い要求が混ざる場面にそのまま使うと、性能を多く見積もってしまいます。

本数を増やす前に見る所

アプリが同時に動かす本数を増やすと、データベースへの接続も増えます。接続が埋まれば後の要求は待ち、その待ち時間も1件の処理時間に乗ります。

接続の上限を上げても、同じディスクを取り合う状態は変わりません。ある本数を超えると待ちが増え、全体の処理量が下がることもあります。

まず、1件が必要な読み書きだけをしているかを調べます。同じ空席数を繰り返し読む処理があれば、まとめて読むなど、1件の仕事を減らせないかを考えます。

独立した4本のモデルで25ミリ秒を10ミリ秒にできれば、毎秒160件から400件になります。本数を変えずに改善できる可能性があるため、先に時間の内訳を測るのです。

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

DAUは3万人、1人が1日に6回要求します。1日の18万件を86400秒で割った平均は約2 QPSと丸め、ピーク係数50を掛けて100 QPSと置きます。

いまの1台は毎秒40件までという実測で、月の予算は5万円です。平均では足りても、ピーク100件に対して上限は40件なので、毎秒60件不足します。

ここで本数を増やすと即決せず、予約要求の処理時間を測ります。保存先の接続待ちが長いなら、本数を増やす変更はその待ちをさらに増やしかねません。

不要な読み書きを減らした後に同じ負荷で測り直し、なお100 QPSに届かないなら構成を変えます。上限ぴったりでは揺れを吸収できないため、実測では余裕も確かめます。

月5万円に収まることと、ピークに耐えることは別の条件です。時間と待ちの記録を残せば、次の回で大きい1台と複数台を比べる根拠になります。