基本を超えた分散アルゴリズム
ラウンドロビンと最小接続数は代表的な出発点にすぎず、実際の本番環境ではさらに工夫が加えられることが多くあります。処理能力の高いサーバーにより多くのリクエストを割り当てる重み付きラウンドロビン、直近の応答速度を加味する最小応答時間方式、そしてキャッシュ層で多用され、サーバーが追加・削除されても同じキーがほぼ常に同じサーバーにマッピングされるコンシステントハッシュなどが代表的です。
クラウドネイティブ環境における負荷分散
単体の専用機器だけでなく、現在の負荷分散は複数のレイヤーで同時に行われることが一般的です。クラウド事業者が提供するマネージド型ロードバランサーがアプリケーション全体の手前に立ち、Kubernetesクラスタ内ではIngressコントローラーがトラフィックを分散し、サービスメッシュが内部サービス間の負荷分散を担います。それぞれのレイヤーは、特定のインスタンスに負荷が集中しないようにするという同じ課題を、異なる範囲で解決しています。
ロードバランサーでは解決できないこと
ロードバランサーは仕事を分けますが、遅いアプリケーションを速くはしません。すべてのサーバーが1つの過負荷なデータベースを共有している場合、Webサーバーを増やしてもボトルネックが移るだけで消えません。また、状態をローカルに保持するサーバーの前に置くと、ログインやカートが壊れることもあります。サーバーを増やす前に、監視でボトルネックを特定し、可能ならアプリケーションをステートレスにしましょう。
リクエストの流れを追ってみる
訪問者がサイトを開くと、ブラウザはドメイン名をロードバランサーのアドレスに解決します。ロードバランサーは接続を受け付け、アルゴリズムに従って正常なサーバーを選び、リクエストを転送します。サーバーが作ったレスポンスはロードバランサーを経由して訪問者に戻ります。直近のヘルスチェックに失敗したサーバーはスキップされ、訪問者は障害に気づきません。運用担当者は、サーバーごとの毎秒リクエスト数、エラー率、応答時間を見て、分散が健全かを確認します。
よくある質問
ロードバランサー自体が故障したらどうなりますか?
ロードバランサー自体が単一障害点にならないよう、実際の運用では通常2台以上のロードバランサーをアクティブ・スタンバイ、またはアクティブ・アクティブ構成で稼働させ、一方が停止してももう一方が処理を継続できるようにします。
小規模なサイトにもロードバランシングは必要ですか?
1台のサーバーで十分にトラフィックを処理できるなら、当面は必要ありません。ただしトラフィックが増えて複数台のサーバーが必要になった時点からは、ロードバランサーなしでは分散のしようがないため、必須の要素になります。
ロードバランサーとリバースプロキシは同じものですか?
重なる部分があります。リバースプロキシはサーバーの手前に立ってクライアントのリクエストを転送するもので、多くは負荷分散も行えます。L7ロードバランサーは、分散とヘルスチェックの機能を備えたリバースプロキシのようなものです。L4は内容を読まずに、より低い層で動作します。
どのアルゴリズムを選べばよいですか?
同程度のサーバーで処理時間が短いなら、ラウンドロビンが無難な初期選択です。処理時間のばらつきが大きいなら最小接続数、サーバーの規模が違うなら重み付き、同じサーバーに留めたい場合のみハッシュやCookieを使います。
ロードバランサーは攻撃からも守ってくれますか?
一部のトラフィックを吸収し、バックエンドのアドレスを隠せます。マネージド型にはレート制限やWAFを備えるものもありますが、大規模なDoS攻撃に対する完全な防御はロードバランサー単体ではできません。