Amazon EC2にスケーラブルで信頼性の高いhaproxyクラスターをデプロイするにはどうすればよいですか？
ELBが提供するものよりも高度な機能が必要です（主にL7検査）。ただし、ハートビートや高可用性などの処理方法は、EC2を使用するhaproxyなどで明確ではありません。クラスター内に3つ以上のhaproxyノードが必要になる可能性が高いため、2つのノード間の単純なハートビートは機能しません。
Haproxyノードの前にハートビートレイヤーを配置するのがよいようですが、おそらくIPVSを使用しますが、EC2クラスターの変更として構成の変更を処理します（拡張などの意図的な変更、またはEC2ノード）は簡単ではないようです。
好ましくは、ソリューションは少なくとも2つのアベイラビリティーゾーンにまたがります。
Qsへの回答：いいえ、セッションはスティッキーではありません。はい、SSLが必要ですが、理論的には別の設定で完全に処理できます。SSLトラフィックを非SSLトラフィックとは異なる場所に転送できます。
OK、私は自分でSmugMugレベルのトラフィックでAWSロードバランシングソリューションを構築したことがありませんが、理論とAWSのサービスを考えるだけで、いくつかのアイデアが思い浮かびます。
元の質問には、負荷分散設計に影響を与える傾向があるいくつかのものが欠けています。
- スティッキーセッションかどうか？スティッキーセッションを使用せず、すべてのロードバランサー（LB）でラウンドロビン（RR）またはランダムバックエンドの選択を使用させることをお勧めします。 RRまたはランダムバックエンドの選択はシンプルでスケーラブルであり、あらゆる状況で負荷分散を提供します。
- SSLかどうか？ SSLが使用されているかどうか、および要求の何パーセントを超えるかは、一般的に負荷分散設計に影響を与えます。証明書の処理を簡素化し、SSL CPUの負荷をWebアプリケーションサーバーから遠ざけるために、SSLをできるだけ早く終了することが望ましい場合がよくあります。
負荷分散層自体の高可用性を維持する方法の観点から答えています。アプリケーションサーバーのHAを維持するには、L7ロードバランサーに組み込まれたヘルスチェックを使用します。
OK、機能するはずのいくつかのアイデア：
1）「AWSの方法」：
- 最初のレイヤーの最前部では、L4（TCP/IP）モードでELBを使用します。
- 2番目のレイヤーでは、選択したL7ロードバランサー（nginx、HAProxy、Apacheなど）でEC2インスタンスを使用します。
Benefits/idea：L7ロードバランサーは、すべて同じAMIから複製され、同じ設定を使用する、かなり単純なEC2 AMIにすることができます。 AmazonのツールはすべてのHAニーズを処理できます： ELBはL7ロードバランサーを監視します。 L7 LBが停止するか応答しなくなった場合、ELBとCloudwatchは一緒に新しいインスタンスを自動的に生成し、それをELBプールに取り込みます。
2）「監視方法を備えたDNSラウンドロビン：」
- 基本的なDNSラウンドロビンを使用して、いくつかのIPアドレスに大まかな負荷分散を行います。サイトに3つのIPアドレスを公開しているとしましょう。
- これら3つのIPはそれぞれ、AWS Elastic IPアドレス（EIA）であり、選択したL7ロードバランサーを使用してEC2インスタンスにバインドされます。
- EC2 L7 LBが停止した場合、代わりに 準拠ユーザーエージェント（ブラウザー）する必要があります他のIPの1つを使用する 。
- 外部監視サーバーを設定します。 3つのEIPをそれぞれ監視します。 1つが応答しなくなった場合は、AWSのコマンドラインツールとスクリプトを使用して、EIPを別のEC2インスタンスに移動します。
メリット/アイデア：対応するユーザーエージェントは、IPアドレスが応答しなくなった場合、自動的に別のIPアドレスに切り替える必要があります。したがって、障害が発生した場合、影響を受けるのはユーザーの1/3だけであり、UAが静かに別のIPにフェイルオーバーするため、これらのユーザーのほとんどは何も気付かないはずです。また、外部監視ボックスは、EIPが応答しないことを認識し、数分以内に状況を修正します。
3）HAサーバーのペアへのDNS RR：
基本的に、これはサーバーのペア間の単純なハートビートについてのDon自身の提案ですが、複数のIPアドレスに対して簡略化されています。
- DNS RRを使用して、サービスのいくつかのIPアドレスを公開します。上記の例に従って、3つのIPを公開するとします。
- これらのIPはそれぞれ、EC2サーバーのpairに送られるため、合計で6つのEC2インスタンスになります。
- これらの各ペアは、ハートビートまたは別のHAソリューションとAWSツールを使用して、アクティブ/パッシブ構成で1つのIPアドレスをライブに保ちます。
- 各EC2インスタンスには、選択したL7ロードバランサーがインストールされています。
Benefits/idea：AWSの完全に仮想化された環境では、L4サービスとフェイルオーバーモードを実際に考えるのはそれほど簡単ではありません。 1つのIPアドレスのみを有効に保つ1ペアの同一サーバーに簡略化することで、推論とテストが簡単になります。
結論：繰り返しますが、私は実際にこれを実際に試したことがありません。ちょうど私の直感から、L4モードのELBを使用するオプション1、およびL7 LBとしての自己管理EC2インスタンスは、AWSプラットフォームの精神と最も整合しており、Amazonが投資して拡張する可能性が最も高い場所です。これはおそらく私の最初の選択でしょう。
スティッキーセッションを実行していない場合、またはTomcat/Apacheスタイル（ノードIDをセッションIDに追加し、状態をLBに格納するのではなく）を使用している場合、私はhaproxiesのグループの前でELBを使用します。 ELBにはヘルスチェックが組み込まれているので、haproxiesを監視してプールからダウンしているものを削除できます。ハートビートフェイルオーバーよりも設定が少なくて済みます。
変更を伝播する限り、私は良い答えはありません。 Puppetは初期構成と変更の実装に最適ですが、ノードの追加/削除には、30分のポーリング間隔よりも速い応答が必要になる傾向があります。
私自身は使用していませんが、EC2でこの種の問題を処理するために人形を使用することを言及する多くの人を見てきました。