ロードバランサ (L4 / L7)

サーバーを 2 台に増やしたのに、1 台しか働いていない

台数を増やしても、利用者がつなぐ先が 1 つの住所である以上、勝手には分かれません。前に立って割り振る役が要ります。それがロードバランサです。

役目は 3 つあります。負荷を分けること、1 台が落ちても受け続けること、そして裏の台数が変わっても外から見た住所は変わらないことです。3 つ目のおかげで、混む時間だけ台数を足す、といった運用ができます。

割り振り方は順番に配るのが基本です。台ごとに性能差があるなら重みを付け、処理時間にばらつきがあるなら、今つながっている数が一番少ない台へ送る方式に切り替えます。

IP とポートだけ見るか、中を開けて読むか

ロードバランサには 2 つの立ち位置があります。どこまで中身を見るか、の違いです。

浅いほうは、宛先の IP アドレスとポート番号だけを見て流します。中身を解釈しないので速く、暗号化されたまま裏へ渡せます。データベースの前など、とにかく速さが要る場所で使います。

深いほうは、HTTP として中身を読みます。/api で始まる URL はこちらのグループ、それ以外はこちら、といった振り分けができるのはこちらだけです。暗号を解いて読むので、証明書の管理をここに集約でき、認証やレート制限もまとめて置けます。そのぶん 1 リクエストあたりの処理は重くなります。

パスやホスト名で分けたい要件が 1 つでもあるなら、浅いほうでは実現できません。ここが選択の分かれ目です。

落ちた 1 台に、まだリクエストが飛んでいる

割り振る役は、裏の台が生きているかどうかを知りません。放っておくと、止まった台にも順番どおりに送り続けます。だから定期的に生存確認を投げます。

ポートにつながるかを見るだけの確認と、決められた URL を叩いて正常な結果が返るかを見る確認があります。前者は、プロセスは動いているが中身が壊れている状態を見逃します。アプリ側に確認用の URL を 1 つ用意し、その中でデータベースへの接続まで見て結果を返すようにしておくと、壊れた台が早く外れます。

確認の間隔と、何回続けて失敗したら外すかは調整が要ります。厳しすぎると、一時的に遅れただけの台が外れ、残りに負荷が寄って連鎖して倒れます。

もう 1 つ、時間の設定を裏の台と合わせておく必要があります。使っていない接続を切るまでの時間が、割り振る役のほうが長いと、すでに閉じられた接続にリクエストを流してしまいます。原因不明の失敗がときどき混ざる、という形で出てくるので気づきにくい部類です。裏側を少し長めにしておくと起きません。

ログインが、リロードのたびに切れる

利用者の情報を、受け付けた台のメモリに置いている場合、次のリクエストが別の台に振られると何も残っていません。ログインし直しになります。

その場しのぎは、同じ人を必ず同じ台に送ることです。ただしこれをやると、その台が落ちた時点でその人の情報は消えますし、台数を増やしても既存の利用者は移りません。せっかく前に立てた意味が薄れます。

素直な解き方は、台のメモリに置くのをやめることです。情報を外の共有の置き場に出してしまえば、どの台が受けても同じ結果になります。台を自由に足したり落としたりできる状態は、この形にして初めて手に入ります。