わかりました。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インスタンスを使用します。
利点/アイデア： L7ロードバランサーは、非常にシンプルなEC2 AMIで、すべて同じAMIから複製され、同じ構成を使用できます。したがって、AmazonのツールはすべてのHAニーズを処理できます。ELBはL7ロードバランサーを監視します。L7 LBが停止するか、応答しなくなると、ELBとCloudwatchが一緒になって新しいインスタンスを自動的に生成し、ELBプールに取り込みます。
2）「監視方法を使用したDNSラウンドロビン：」
- 基本的なDNSラウンドロビンを使用して、2、3のIPアドレスで粗粒度の負荷分散を実現します。サイトに3つのIPアドレスを公開するとします。
- これら3つのIPはそれぞれ、選択したL7ロードバランサーを使用してEC2インスタンスにバインドされたAWS Elastic IPアドレス（EIA）です。
- EC2 L7 LBが停止した場合、準拠するユーザーエージェント（ブラウザー）は、代わりに他のIPのいずれかを使用する必要があります。
- 外部監視サーバーをセットアップします。3つのEIPをそれぞれ監視します。応答しなくなった場合は、AWSのコマンドラインツールとスクリプトを使用して、EIPを別のEC2インスタンスに移動します。
利点/アイデア：対応するユーザーエージェントが応答しなくなった場合、別のIPアドレスに自動的に切り替える必要があります。したがって、障害が発生した場合、影響を受けるのはユーザーの1/3のみであり、ユーザーのUAはサイレントに別のIPにフェールオーバーするため、これらのほとんどは何も気付かないはずです。また、外部監視ボックスは、EIPが応答しないことに気付き、数分以内に状況を修正します。
3）HAサーバーのペアへのDNS RR：
基本的に、これは1組のサーバー間の単純なハートビートに関するDon自身の提案ですが、複数のIPアドレスについては単純化されています。
- DNS RRを使用して、サービスの多数のIPアドレスを公開します。上記の例に従って、3つのIPを公開するとしましょう。
- これらの各IP はEC2サーバーのペアに送られるため、合計で6つのEC2インスタンスになります。
- これらのペアはそれぞれ、ハートビートまたは別のHAソリューションとAWSツールを使用して、アクティブ/パッシブ構成で1つのIPアドレスをライブに保ちます。
- 各EC2インスタンスには、選択したL7ロードバランサーがインストールされています。
利点/アイデア： AWSの完全に仮想化された環境では、実際にはL4サービスとフェイルオーバーモードについて簡単に推論することはできません。IPアドレスを1つだけ維持して同一のサーバーのペアを1つに簡素化することにより、推論とテストがより簡単になります。
結論：繰り返しますが、私は実際に本番環境でこれを試していません。私の直感から、オプション1はL4モードのELB、およびL7 LBとしての自己管理EC2インスタンスは、AWSプラットフォームの精神と最も整合性があり、Amazonが後で投資し拡張する可能性が最も高いと思われます。これがおそらく私の最初の選択でしょう。