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