しばらく前から考えていましたが、Amazon がElastic Load Balancing (ELB) をリリースした今、トラフィックの多い Web アプリケーションにこのソリューションをデプロイすることについてどう思いますか?
HAProxyを置き換える必要がありますか、それとも ELB を HAProxy の前の無料サービスと見なす必要がありますか?
しばらく前から考えていましたが、Amazon がElastic Load Balancing (ELB) をリリースした今、トラフィックの多い Web アプリケーションにこのソリューションをデプロイすることについてどう思いますか?
HAProxyを置き換える必要がありますか、それとも ELB を HAProxy の前の無料サービスと見なす必要がありますか?
1 日あたり約 100,000 の訪問者がいるサイトで、HAProxy の代わりに ELB を約 1 か月実行しており、その結果には非常に満足しています。
ただし、落とし穴 (UPDATE、この問題はAmazon AWSによって修正されました。以下のコメントを参照してください):
http://mysite.com
ことhttp://www.mysite.com
です。それを除けば、AWS ELB の提供物について十分に語ることはできません。Cloudwatch のモニタリングと自動スケーリングも使用しています。小さなEC2インスタンスを実行するよりも安価であることを忘れないでください(1 時間あたり $0.10 ではなく $0.025)。
ELB が DNS CNAME レコード インダイレクションに依存していることは、非常に高速である必要がある Web サービスにとってかなりの障害となります。私たちの場合、非常に優れた応答時間が必要です。簡単なパフォーマンス テストでは、ELB を使用すると、HTTP リクエストの平均レイテンシがほぼ 2 倍に増加しました。これは主に、CNAME ルックアップの TTL がゼロであるためです。したがって、すべてのルックアップには 2 つの異なるドメインのネーム サーバーへのヒットが含まれるため、名前解決は非常に遅くなります。(DNS でキャッシングを無効にすることは、単にシステムの悪用ではないかと心配しています。) 私たちの場合の ELB の唯一の希望は、Amazon がロード バランサー インスタンスのアドレスとして Elastic IP をサポートするようにすることで、CNAME レコードから逃れることです。
もう1つの問題は、クライアントのIPアドレスを取得することです。通常のHTTPの場合、ELBがX-FORWARDED-FORヘッダーを設定するため、これは正常に機能します。ただし、HTTPSの場合、TCP層で転送しているため、これは不可能です。うまくいけば、いつかELBでSSLが終了するでしょう。
Amazon フォーラムには、ELB の信頼性に関する苦情が寄せられています。そこに向かい、ELB を検索して、その面で自分の意見を形成することをお勧めします。
ELB を使用して Web サービス リクエストの負荷を分散したかったのですが、多くの外部呼び出し元があり、そのうちのいくつかは 100-Continue HTTP メッセージを送信します。残念ながら、ELB は HTTP プロトコルのその部分を理解していないため、それが解決されるまで、概念実証を超えることはできません。
2013年アップデート
AWS フォーラムの投稿によると、HTTP 100-Continue がサポートされるようになりました。
ELB を使用する多くのユーザーにとっての主な問題の 1 つは、多くの Web アプリケーションにとってキラーである粘着性がサポートされていないことです。
ただし、 Amazon AWS開発者によると、次のリリースで提供されるはずです。