Elastic Load Balancerを調べているところです。私が理解しているように、彼らはラウンドロビンを行い、背後のサーバーへの接続を均等に分散しています。では、ELBの背後に異なるサイズのインスタンスがある場合はどうなりますか?より大きなインスタンスに多くの接続を送信しますか、それとも接続を均等に分散し続けますか?つまり、実際には異なるサイズのインスタンスを使用するべきではありません。
私が理解しているように、彼らはラウンドロビンを行い、背後のサーバーへの接続を均等に分散しています。
残念ながら、 Amazon ELB ルーティングドキュメントは存在しないため、いくつかを組み立てて結論を出す必要があります。 Elastic Load Balancing Developer Guide 私が知っている唯一のフラグメントは次のとおりです。 のセクションSticky Sessionsを参照してください/] Elastic Load Balancingの概要 :
デフォルトでは、ロードバランサーは、各リクエストを最小の負荷のアプリケーションインスタンスに個別にルーティングします。ただし、スティッキーセッション機能(セッションアフィニティとも呼ばれる)を使用して、ロードバランサーがユーザーのセッションを特定のアプリケーションインスタンスにバインドできるようにすることができます。これにより、セッション中にユーザーから送信されるすべてのリクエストが同じアプリケーションインスタンスに送信されます。 [重点鉱山]
最小負荷はどういう意味ですか?繰り返しますが、私が知っている唯一の説明は、2009年から ELB Strategy へのいくぶん漠然としたAWSチームの応答です。
ELBは、各インスタンスで未解決の要求(またはTCPの場合は接続)の数を大まかに追跡します。リソースの使用状況( CPUまたはメモリ)。 ELBは現在、未処理の要求が最も少ないと考えるインスタンス間でラウンドロビンします。 [重点鉱山]
これは、システムアーキテクチャと対応するユースケースに関して非常に理にかなっていますが、高度なHAシナリオに必要な、または必要となる可能性のあるルーティングの透明性や制御を明らかに提供していません。
解釈に応じて、これは Elastic Load Balancing-Load distribution policies に対する最近のAWSチームの応答と多少矛盾する場合があります。
ラウンドロビンが機能しますが、クライアントセッションは常にTTLまたはDNSキャッシュを尊重するとは限らないため、歪んだ結果と不均一な要求の分散を取得できます。 ELBは、トラフィックルーティングの決定において、インスタンスがこれまでに受け取ったトラフィック/リクエストの内容を有効にしません。[強調私の]
もちろん、上記は適切に文書化された、透明で制御可能な ヘルスチェック で修正されています。これにより、インスタンスがルーティングに含まれないように(一時的に)除外することができます。 、前述の ELB Strategy に対するAWSチームの対応にも要約されています。
ロードバランサーは、ロードバランサーに登録されているインスタンスの状態を監視します。ロードバランサーがインスタンスの問題を検出すると、インスタンスへのトラフィックの分散を停止します。インスタンスが再び正常になると、ロードバランサーはインスタンスへのトラフィックの分散を再開します。このプロセスにより、アプリケーションは、ヘルスチェックの構成以外に関与することなく、失敗したインスタンスに自動的に対応できます。
ELBがさまざまな Amazon EC2インスタンスタイプ のプールで動作しない理由もわかりませんが、自分で試したことがなく、両方をお勧めします、 CloudWatch を使用してロードバランサーを監視し、個々のEC2インスタンスを監視して結果を相互に関連付け、最終的にそのような設定に対する洞察と信頼をそれぞれ獲得します。
これまでの説明に基づくと、分散アルゴリズムは非常に単純です。
ELBのフロントエンドは通常、複数のELBインスタンスであり、ディストリビューションはラウンドロビンです。
バックエンド(あなたのインスタンス)アルゴは次のように主張しています:
ELBは、各インスタンスで未解決の要求(またはTCPの場合は接続)の数を大まかに追跡します。各インスタンスでのリソースの使用状況(CPUやメモリなど)は監視しません。 ELBは現在、未処理の要求が最も少ないと考えるインスタンス間でラウンドロビンします。
これは、より大きなインスタンスの未処理のリクエストが少ない場合、より多くのトラフィックがそれらにルーティングされることを意味します。これを保証する方法はありません。