Server Load Balancer (SLB) は、転送ルールで指定されたスケジューリングアルゴリズムに基づいて、バックエンドサーバーにリクエストを配信します。 さまざまなシナリオで負荷分散のパフォーマンスを向上させるために、SLBはラウンドロビン、加重ラウンドロビン、加重最小接続、コンシステントハッシングなどの複数のスケジューリングアルゴリズムをサポートしています。
このトピックでは、SLBでサポートされているスケジューリングアルゴリズムについて説明します。 Application Load Balancer (ALB) 、Classic Load Balancer (CLB) 、およびNetwork Load Balancer (NLB) でサポートされているスケジューリングアルゴリズムは異なります。
ALBは、重み付きラウンドロビン、重み付き最小接続、およびソースIPアドレスとURLに基づくコンシステントハッシングをサポートしています。
NLBは、ラウンドロビン、重み付きラウンドロビン、重み付き最小接続、およびソースIPアドレス、4つの要素の組み合わせ、およびQUIC IDに基づくコンシステントハッシングをサポートします。
CLBは、送信元IPアドレス、4つの要素の組み合わせ、およびQUIC IDに基づいて、ラウンドロビン、加重ラウンドロビン、およびコンシステントハッシングをサポートします。
ラウンドロビン
概要
ラウンドロビンアルゴリズムは、リクエストがバックエンドサーバーに順番に配信されることを指定します。 ラウンドロビンは、HTTP接続などの一貫性のない接続に一般的に適用されます。
たとえば、2つのECS (Elastic Compute Service) インスタンスがバックエンドサーバーグループにある場合、リクエストはECSインスタンスに順番に均等に分散されます。
利点
簡単なスケジューリング: ラウンドロビンは、負荷分散の基本的なスケジューリングアルゴリズムです。 理解しやすく、管理しやすいです。
高いパフォーマンス: ラウンドロビンは、バックエンドサーバーに要求を均等に分散して、バックエンドサーバー間の負荷を分散できます。
デメリット
サーバーは、小さなパフォーマンスギャップを維持する必要があります。 ラウンドロビンでは、バックエンドサーバーのリアルタイム負荷を判断できません。 サーバの性能が大きく変動する場合、サーバの一部が過負荷になり、一部が過負荷になる可能性がある。
接続は、長期間にわたって占有され得る。 ラウンドロビンは、接続が占有される期間を予測することができない。 接続が長い間開いたままである場合、他の接続の待ち時間が増加する。
シナリオの使用
性能差の小さいサーバ: サーバ間の性能差が小さい場合、ラウンドロビンは、要求をサーバに均等に分配することにより、高い効率で負荷を分散することができる。
単純なスケジューリング: ラウンドロビンは、リアルタイムの負荷検出や短い接続時間を必要としないシナリオに最適です。
加重ラウンドロビン
概要
重み付きラウンドロビンアルゴリズムは、ラウンドロビンアルゴリズムに基づいて開発されるが、サーバの重みを考慮する。 サーバーの重みに基づいてリクエストを配信するため、より効率的です。 重みの大きいバックエンドサーバーは、重みの小さいバックエンドサーバーよりも多くのリクエストを受け取ります。 重み付きラウンドロビンは、HTTP接続などの一貫性のない接続に最適です。
たとえば、2つのECSインスタンスがバックエンドサーバーグループにあり、ECSインスタンスの重みは60と40です。 この場合、リクエストの60% は重み60のECSインスタンスに配信され、リクエストの40% は重み40のECSインスタンスに配信されます。
利点
柔軟性: 重み付きラウンドロビンは、サーバーの重みと容量に基づいてリクエストを分散します。 より多くのリクエストがより高い容量のサーバーに配信されます。
負荷分散: 重み付きラウンドロビンでは、各サーバーの重みを考慮し、サーバー間の負荷を分散します。
デメリット
複雑な設定: 重み付きラウンドロビンでは、バックエンドサーバーごとに重みを指定する必要があります。 多数のバックエンドサーバーがある場合や、サービスを頻繁に調整する必要がある場合は、設定とO&Mの作業に時間がかかります。
適切な重み設定: サーバーに不適切な重みを指定すると、サーバーの負荷が不均衡になる可能性があります。 サーバーの重みを頻繁に調整する必要がある場合があります。
シナリオの使用
パフォーマンスギャップのあるサーバー: サーバーのパフォーマンスギャップが大きい場合は、サーバー間の負荷のバランスを取るためにサーバーの重みを指定できます。 パフォーマンスの高いサーバーは、より多くのリクエストを受信できます。
動的スケジューリング: サーバーのパフォーマンスや負荷が変動した場合、負荷に耐えるようにサーバーの重みを動的に調整できます。
きめ細かいスケジューリング: きめ細かい粒度に基づいてサーバーにリクエストを配信する場合は、各サーバーに重みを設定して、各サーバーに配信するリクエストの割合を指定できます。
加重最小接続
概要
加重最小接続アルゴリズムは、サーバーの重みに基づいてリクエストを分散し、SLBとバックエンドサーバー間の接続数を考慮します。 2つのバックエンドサーバーの重みが同じ場合、接続数が少ないバックエンドサーバーはより多くのリクエストを受信します。 加重最小接続アルゴリズムは、データベース接続などの一貫した接続に最適です。
たとえば、2つのECSインスタンスがバックエンドサーバーグループにあり、重みは両方とも100です。 一方のECSインスタンスの接続数が100で、もう一方のECSインスタンスの接続数が50の場合、接続数の少ないECSインスタンスにリクエストが優先的に配信されます。
利点
動的調整: 重み付き最小接続は、リアルタイムでの接続数とサーバーの重みに基づいて、リクエストスケジューリングを動的に調整できます。 リクエストは、接続が最も少ないサーバーに配信されます。
負荷分散の高性能: 加重最小接続アルゴリズムでは、接続数と各サーバーの重みが考慮されます。 オーバーロードやアンダーロードの状況を防ぐために、リクエストをサーバーに公平に配信します。
デメリット
複雑な計算: ラウンドロビンおよび加重ラウンドロビンと比較して、加重最小接続アルゴリズムは、サーバーが選択される前に、SLBとバックエンドサーバー間の接続数をリアルタイムで比較するために、より複雑な計算を実行します。
サーバー接続への依存: 加重最小接続アルゴリズムは、SLBとバックエンドサーバー間の接続数に基づいてリクエストを分散します。 監視データが不正確であるか、または古くなっている場合、要求は、最小の接続でサーバに配信されない可能性がある。 さらに、加重最小接続アルゴリズムでは、SLBとバックエンドサーバー間の接続数しか取得できません。 サーバー上の接続の総数を取得することはできません。 サーバーが複数のSLBインスタンスに追加されている場合、サーバーがオーバーロードまたはアンダーロードされる可能性があります。
新しいバックエンドサーバーによる負荷スパイク: 既存の接続数が多いときに新しいバックエンドサーバーがSLBインスタンスに追加された場合、新しいバックエンドサーバーに新しい接続がスケジュールされる可能性があります。 その結果、新しいバックエンドサーバーが過負荷になり、システムの安定性が損なわれる可能性があります。
シナリオの使用
パフォーマンスギャップが大きいサーバー: サーバーのパフォーマンスギャップが大きい場合は、重み付き最小接続アルゴリズムを使用してサーバーの重みを指定し、サーバー間の負荷のバランスを取ることができます。 パフォーマンスの高いサーバーは、より多くのリクエストを受け取ります。
動的スケジューリング: サーバー上の接続数と負荷数が変化した場合、加重最小接続アルゴリズムは、リアルタイムで接続数に基づいて要求スケジューリングを動的に調整し、サーバー間の負荷のバランスを取ることができます。
安定性に対する高い要件: リアルタイム応答と高いシステム安定性が必要な場合は、加重最小接続アルゴリズムを使用してサーバーの負荷を軽減し、システムの安定性と信頼性を向上させることができます。
一貫したハッシュ
概要
コンシステントハッシュアルゴリズムは、バックエンドサーバーの数が変化しても、ハッシュ係数に基づいてバックエンドサーバー間でリクエストを均等に分散します。 同じハッシュ値を持つリクエストは、同じバックエンドサーバーに配布されます。
ハッシュ要因は次のとおりです。
送信元IPアドレス: 送信元IPアドレスに基づくハッシュ。 同じ送信元IPアドレスを持つリクエストは、同じバックエンドサーバーに配信されます。
4つの要素: 送信元IPアドレス、送信元ポート、宛先IPアドレス、および宛先ポートに基づくハッシュ。 同じ4つの要素を持つリクエストは、同じバックエンドサーバーに配信されます。
QUIC ID: QUIC IDに基づくハッシュ。 QUIC IDは、QUIC接続の一意の識別子です。 QUIC IDに基づくハッシュは、接続間の負荷のバランスを取ることができる。 同じQUIC IDを持つリクエストは、同じバックエンドサーバーに配信されます。
URLクエリ文字列: URLクエリ文字列に基づくハッシュ。 同じURLクエリ文字列を持つリクエストは、同じバックエンドサーバーに配信されます。
たとえば、2つのECSインスタンスがサーバーグループにあり、最後のリクエストがECS01に配信されたとします。 現在の要求が最後の要求と同じハッシュ値を有する場合、現在の要求はECS01にも配信される。
利点
セッション持続性: 一貫したハッシュにより、同じハッシュ値を持つリクエストが同じバックエンドサーバーに配信され、セッション持続性が維持されます。 セッションの永続性を維持するか、使用ステータスを維持する必要がある場合は、コンシステントハッシュアルゴリズムを使用します。
負荷分散: 同じハッシュ値を持つリクエストを同じバックエンドサーバーに配信できるため、一貫したハッシュがより効率的です。 これにより、バックエンドサーバー間の負荷が高効率で分散されます。
デメリット
サーバーの変更による不均衡スケジューリング: サーバーが追加または削除された場合、一貫したハッシュは要求の一貫性を優先します。 サーバーが変更された場合、一部のリクエストは再スケジュールされます。 バックエンドサーバーの数が増えると、再スケジュールされるリクエストは少なくなります。 バックエンドサーバーの数が減少すると、リクエストも再スケジュールされます。 サーバー間の負荷が不均衡になる可能性があります。
スケールアウトの複雑さの増加: 一貫したハッシュは、ハッシュファクタに基づいて要求のハッシュ値を計算します。 サーバーが追加または削除された場合、一部のリクエストは再スケジュールされます。 これにより、サーバーのスケールアウト活動が複雑になります。
シナリオの使用
セッション永続性: アプリケーションがセッション永続性を維持するか、ユーザーステータスを維持する必要がある場合は、コンシステントハッシングを使用して、同じハッシュ値を持つリクエストを同じバックエンドサーバーに配布できます。
高パフォーマンス負荷分散: 負荷分散の要件が高いシナリオでは、コンシステントハッシングでリクエストを分散して、サーバー間で負荷を分散できます。
データの一貫性: データの一貫性が必要なシナリオでは、コンシステントハッシングは、同じハッシュ値を持つリクエストを同じバックエンドサーバーに配信することで、データの一貫性を維持できます。
QUIC IDに基づくハッシュは、QUICアプリケーションにのみ適用されます。 QUICは急速にアップグレードされています。 QUICバージョンとの互換性は保証できません。 QUICを本番環境に適用する前に、アプリケーションを完全にテストすることをお勧めします。
NLBおよびCLBは、QUIC IDに基づくハッシュをサポートしています。 Q10およびQ29は支えられます。
関連ドキュメント
ALB、NLB、およびCLBの詳細については、以下のトピックを参照してください。