ロードバランサ

要求を各台へ配る

席の予約サービスでアプリを複数台にしたら、届いた要求をどの台へ渡すかを決めます。その役を引き受けるのがロードバランサです。

最も単純な配り方は、各台へ順番に1件ずつ渡す方法です。3台なら、1台目、2台目、3台目と配り、次は1台目に戻ります。

利用者は入り口へ要求を送ればよく、アプリの台数を知る必要はありません。台を足すときは、振り分け先の一覧を更新します。

台を増やしても、振り分け先が元の1台だけなら新しい台には要求が届きません。変更後は、各台が実際に要求を受けていることを記録で確かめます。

空きを見て配るには、各台の接続数などの負荷情報を集め続けます。順番配りも次に渡す位置は覚えますが、配る順序を決めるために各台の負荷情報は要りません。

集める情報が少なければ、負荷情報の遅れで判断を誤る場面も減ります。同じ重さの要求が中心なら、単純な順番配りから始められます。

件数の差と負荷の差を分ける

要求の数が台数で割り切れないと、順番配りでも件数に差が出ます。5件を3台へ配れば、2件、2件、1件になります。

端数だけなら、差は最大1件です。件数が増えるほど差の割合は小さくなり、配り方を複雑にしてまで消す必要はありません。

一方、空席の表示と重い予約処理が混ざると、同じ件数でも負荷が違います。1台だけCPUが高い、応答が遅いといった状態が続くなら、要求の重さと配り方を調べます。

配り方を比べるときは、空席表示と予約処理の割合をそろえて要求を流します。件数だけでなく、利用者が答えを待つ時間を比較すれば、変えた配り方が役に立ったかを確かめられます。

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

DAU3万人、1人1日6回の要求から平均を約2 QPSと丸めます。ピーク係数50で100 QPSを想定し、毎秒40件までのアプリを3台に分けます。

100件を順番に配ると、34件、33件、33件です。同じ重さの要求なら、最も多い台も毎秒40件の上限に収まるため、1件の差を直す変更は要りません。

ただし、件数がほぼ同じでも1台に重い予約処理が集まれば話が変わります。台ごとの応答時間やCPUを比べ、処理中の接続数を見る配り方などを候補にします。

配り方を替える前に、保存先の待ちが全台に起きていないかも確かめます。共通の保存先が詰まっているなら、振り分けだけではその待ちは消えません。

月5万円の予算にはアプリだけでなく、ロードバランサなどの費用も含めます。台へ均等に件数を配ることと、予約サービス全体がピークを処理できることを分けて確認します。