ロードバランシングアルゴリズムの比較分析
重み付けラウンドロビンアルゴリズム Weighted Round-Robin Scheduling
重み付けラウンドロビンアルゴリズムは、ラウンドロビンの方式によって、リクエストを順に異なるサーバーにスケジューリングするものです。重み付けラウンドロビンスケジューリングアルゴリズムでは、サーバー間でパフォーマンスに違いがある状態を解決することができます。サーバーの処理パフォーマンスをそれに応じた重みの値で表し、重みの高低とラウンドロビンの方式によってリクエストを各サーバーに分配します。重み付けラウンドロビンアルゴリズムでは新規接続数に基づいてスケジューリングを行います。重みが高いサーバーは先に接続を確立することができ、重みが高いほどラウンドロビンの回数が多く（確率が高く）なります。同じ重みのサーバーは同等の接続数を処理します。
メリット：シンプルで実用的であり、現時点のすべての接続ステータスを記録する必要がない、ステートレスなスケジューリングです。
デメリット：相対的にシンプルなため、リクエストのサービス時間の変化が大きい場合や、各リクエストの消費時間が一致しない場合に、サーバー間の負荷がアンバランスになりやすいです。
適用ケース：各リクエストがバックエンドを占有する時間が基本的に同じ場合に、負荷の状態が最適になります。HTTPなどの短時間接続サービスによく用いられます。
ユーザーへの推奨事項：各リクエストのバックエンド占有時間が基本的に同じであり、バックエンドサーバーが処理するリクエストタイプが同一または類似している場合は、重み付けラウンドロビン方式を選択することをお勧めします。リクエスト時間の差があまりない場合も重み付けラウンドロビン方式を使用することをお勧めします。この実現方式は低消費かつトラバーサルの必要がなく、高効率なためです。
重み付け最小接続 Weighted Least-Connection Scheduling
原理
実際の状況では、クライアントの各サービスリクエストがサーバーにとどまる時間には比較的大きな差異があります。シンプルなラウンドロビンやランダムなバランシングアルゴリズムを用いた場合、動作時間が長くなるに従って、各サーバー上の接続プロセス数に大きな違いが生じるようになり、これでは実際には負荷分散の真の効果を得ることができません。最小接続スケジューリングは一種の動的スケジューリングアルゴリズムであり、サーバーのその時点でアクティブな接続数によってサーバーの負荷状況を評価するもので、ラウンドロビンスケジューリングアルゴリズムとは異なります。スケジューラーが各サーバーの確立した接続数を記録する必要があり、あるサーバーにリクエストがスケジューリングされると接続数に1をプラスし、接続が中断またはタイムアウトになると、接続数から1をマイナスします。重み付け最小接続スケジューリングアルゴリズムは最小接続スケジューリングアルゴリズムをベースに、サーバーの処理能力に応じて各サーバーに異なる重みを割り当て、各サーバーがその重みに応じた数のサービスリクエストを受け付けることができるようにするもので、最小接続スケジューリングアルゴリズムをベースに改善を加えたものです。
1.1 仮に各RSの重みを順にWi（i=1…n）とし、現在の接続数を順にCi（i=1…n）とした場合、Ci/Wiの値が最小のRSが、次に割り当てられるRSとなります。
1.2 Ci/Wiと同一のRSが存在する場合、これらのRSにはさらに重み付けラウンドロビン方式を使用してスケジューリングを行います。
メリット
このタイプのアルゴリズムは、FTPなどのアプリケーションのような、処理時間の長いリクエストサービスに適しています。
デメリット
ポートの制限により、現在最小接続とセッション維持機能を同時に有効にすることはできません。
適用ケース
各リクエストがバックエンドを占有する時間の差が比較的大きいケースです。長時間接続サービスによく用いられます。
ユーザーへの推奨事項
ユーザーがさまざまなリクエストを処理する必要があり、かつリクエストがバックエンドを占有する時間の差が比較的大きい場合（例えば3ミリ秒と3秒のように、単位レベルの違いがある場合など）では、重み付け最小接続アルゴリズムを使用して負荷分散を実現することをお勧めします。
ソースIPハッシュスケジューリングアルゴリズム ip_hash
原理
リクエストのソースIPアドレスをハッシュキー（Hash Key）として、静的に割り当てられたハッシュテーブルから対応するサーバーを見つけます。そのサーバーが使用可能であり、かつオーバーロードになっていない場合はリクエストがそのサーバーに送信され、そうではない場合は空が返されます。
メリット
ip_hashでは一部のセッション維持の効果が実現できます。ソースIPを記憶することで、あるclientリクエストを、hashテーブルによって同一のrs上に一貫してマッピングできます。このため、セッション維持がサポートされていないシーンでも、ip_hashを使用したスケジューリングが可能です。
ユーザーへの推奨事項
リクエストのソースアドレスに対しhash計算を行い、バックエンドサーバーの重みに応じて、リクエストをマッチしたサーバーに転送することで、同一のクライアントIPのリクエストが常に特定のサーバーに転送されるようになります。この方式はCLBのCookie機能を持たないTCPプロトコルに適しています。
バランシングアルゴリズムの選択と重みの設定の例
CLBの近日中にリリース予定の新機能では、レイヤー7転送での最小接続バランシング方式のサポートを開始します。ユーザーのRSクラスターがさまざまなシナリオの下で安定して業務を担うことができるよう、CLBの選択と重みの設定の例を参考までにいくつかご紹介します。
シナリオ1
同一の設定（CPU/メモリ）のRSが3台あるとします。パフォーマンスが同じであるため、ユーザーはRSの重みをすべて10に設定することができます。現在、各RSとclientの間に100のTCP接続を確立しており、さらにRSを1台増設するとします。このシナリオでは、最小接続のバランシング方式の使用をお勧めします。この設定で速やかに4台目のRSの負荷を増大させ、他の3台のRSの負荷を低減することができます。
シナリオ2
ユーザーがクラウドサービスを初めて使用する場合で、なおかつウェブサイト構築からあまり時間が経っておらず、サイトの負荷が比較的小さい場合は、同一の設定のRSの購入をお勧めします。RSはすべて同様のアクセス層サーバーだからです。このシナリオでは、ユーザーはRSの重みをすべて10に設定し、重み付けラウンドロビンのバランシング方式によってトラフィックを振り分けることができます。
シナリオ3
ユーザーは単純な静的ウェブサイトへのアクセスを担う5台のサーバーを持っており、5台のサーバーのコンピューティング能力の比率は9：3：3：3：1（CPU、メモリ換算）です。このシナリオでは、RSの重みの割合を、順に90、30、30、30、10に設定することができます。静的ウェブサイトへのアクセスの大半は短時間接続のリクエストであるため、重み付けラウンドロビンのバランシング方式を使用して、RSのパフォーマンス比率に従ってCLBにリクエストを分配させることができます。
シナリオ4
あるユーザーは、大量のWebアクセスリクエストの処理を担う10台のRSを持っていますが、RS増設のための追加支出は望んでいません。あるRSはオーバーロードのために頻繁にサーバー再起動が発生しているとします。このシナリオでは、RSのパフォーマンスに応じた重みを設定し、オーバーロードになっているRSに低い重みを設定することをユーザーにお勧めします。このほか、最小接続のロードバランシング方式を用いて、リクエストをアクティブ接続数が比較的少ないRSに分配することで、問題のRSのオーバーロードを解決することもできます。
シナリオ5
あるユーザーは、いくつかの長時間接続リクエストの処理に用いる3台のRSを持っており、これらの3台のサーバーのコンピューティング能力の比率は3：1：1（CPU、メモリ換算）です。この場合、パフォーマンスが最も良好なサーバーが多くのリクエストを処理しますが、ユーザーはこのサーバーがオーバーロードにならないように、新しいリクエストをアイドル状態のサーバーに分配したいと考えています。このシナリオでは、最小接続のバランシング方式を使用し、かつビジーなサーバーの重みを適宜低下させることで、CLBがリクエストをアクティブ接続数の比較的少ないRSに分配し、負荷分散を実現できるようにすることが可能です。
シナリオ6
あるユーザーは、後続のクライアントリクエストを同一のサーバー上に分配したいと考えています。重み付けラウンドロビンまたは重み付け最小接続の方式を用いると、同一のクライアントからのリクエストを固定のサーバーに転送することが保証されません。顧客の特定のアプリケーションサーバーのニーズに合わせるため、クライアントのセッションの「粘着性」あるいは「継続性」を保証する必要があります。このシナリオでは、ip_hashのバランシング方式を用いてトラフィックを振り分けることができます。この方法では、同一のクライアントからのリクエストが常に同一のRSに振り分けられるようにすることが可能です（サーバー数に変化があった場合またはこのサーバーが使用不能になった場合を除きます）。
重みを0に設定することとRSのバインド解除の違い
重みを0に設定：TCPリスナーの既存の接続は転送を継続し、UDPリスナーは同一の5つ組による転送を継続し、 HTTP/HTTPSリスナーの既存の接続は転送を継続します。
RSのバインド解除：TCP/UDPリスナーの既存の接続は転送を停止し、HTTP/HTTPSリスナーの既存の接続は転送を継続します。
関連ドキュメント