ラウンドロビンは、リクエスト、ワークロード、またはプロセスを複数のサーバーまたはリソースに均等に分散する、単純な負荷分散およびタスク スケジューリング方法です。これは循環的な順序に従うため、プール内の各サーバーは、最初のサーバーに戻る前に、順番に着信リクエストを処理します。
A、B、C の 3 つのサーバーがあるシステムを想像してください。リクエストが次の順序で到着するとします。
1 → サーバーA
2 → サーバーB
3 → サーバーC
4 → サーバーA（サイクルを繰り返す）
このパターンにより、単一のサーバーが過負荷になることがなくなり、トラフィックを分散するシンプルで効果的な方法になります。
基本ラウンドロビン: サーバーの負荷や容量を考慮せずに、リクエストを厳密な順序で割り当てます。
加重ラウンドロビン: 事前に定義されたサーバーの重みに基づいてリクエストを割り当て、より強力なサーバーを優先します。たとえば、サーバー A が B および C の 2 倍の速度である場合、2 倍のリクエストを受信します。
ダイナミック ラウンドロビン: リアルタイムのサーバー状態とパフォーマンス メトリックに基づいて要求の分散を調整します。
シンプル: DNS、プロキシ サーバー、またはアプリケーション レベルのロード バランサーに簡単に実装および構成できます。
公平な分散: すべてのサーバーにトラフィックが均等に分配され、過負荷を防ぎます。
スケーラビリティ: 複数のバックエンド サーバーを備えた水平スケーリングされた環境に適しています。
不均等な負荷分散: 基本的なラウンドロビンではリアルタイムのパフォーマンスが考慮されないため、一部のサーバーが苦戦し、他のサーバーが十分に活用されない可能性があります。
セッション永続性の問題: ステートレス アプリケーションはラウンドロビンで適切に動作しますが、ユーザー セッションが特定のサーバー (ログイン セッションなど) に関連付けられている場合、この方法ではスティッキー セッションやセッション レプリケーションなしで問題が発生する可能性があります。
ヘルス チェックの制限: 標準ラウンドロビンは本質的にサーバーの障害を検出しないため、ヘルス モニタリングと組み合わせない限り、障害が発生したサーバーでもリクエストを受信する可能性があります。
DNS ロード バランシング: 冗長性とパフォーマンスの最適化のために、トラフィックを複数の IP に分散します。
アプリケーション負荷分散: Web サーバー、プロキシ、クラウド環境で使用され、バックエンド インスタンス全体にリクエストを分散します。
タスク スケジューリング: ジョブまたはプロセスをワーカー ノード全体に均等に分散する必要があるコンピューティング クラスターに適用されます。
ラウンドロビンは、特にリアルタイムのパフォーマンス最適化よりもシンプルさと公平な分散が重要となる環境では、負荷分散の基本的な手法として残っています。ただし、トラフィック量が多いアプリケーションやパフォーマンスが重要なアプリケーションでは、適応型または加重型の戦略が好まれることがよくあります。