レイヤーの負荷分散

組み込みHAProxyレイヤーはSSL終了を処理しません。サーバーSSLで終了する必要があります。このアプローチの利点は、トラフィックがサーバーに到達するまで暗号化されることです。ただし、サーバーによる復号の処理が必要であり、それによりサーバーの負荷が増えます。さらに、ユーザーがよりアクセスしやすいアプリケーションサーバーにSSL証明書を配置する必要があります。

Elastic Load Balancing を使用すると、ロードバランサーSSLで終了できます。これにより、アプリケーションサーバーの負荷は低減されますが、ロードバランサーとサーバーとの間のトラフィックは暗号化されません。Elastic Load Balancing では、サーバーSSLで終了することもできますが、セットアップは少し複雑です。

受信トラフィックが HAProxyロードバランサーの容量を超える場合は、その容量を手動で増やす必要があります。

Elastic Load Balancing は、着信トラフィックを処理するように自動的にスケーリングされます。最初にオンラインになったときに想定負荷を処理するための容量を十分に確保するには、Elastic Load Balancing ロードバランサーを事前ウォーミングします。

HAProxy サーバーをホストしているインスタンスに障害が発生した場合、インスタンスを再起動できるようになるまでサイト全体がオフラインになる可能性があります。

Elastic Load Balancing は、 よりも耐障害性に優れていますHAProxy。例えば、EC2インスタンスを登録した各アベイラビリティーゾーンにロードバランシングノードをプロビジョニングします。1 つのゾーンでサービスが中断された場合は、他のノードで受信トラフィックの処理が継続されます。詳細については、「Elastic Load Balancing Concepts」(Elastic Load Balancing のコンセプト) を参照してください。

指定したアイドルタイムアウト値よりも長い時間アイドル状態になった場合、両方のロードバランサーによって接続が終了されます。

Elastic Load Balancing のアイドル時間の制限は、ほとんどの目的に対して十分たります。より長いアイドルタイムアウトHAProxyが必要な場合は、 を使用することをお勧めします。以下に例を示します。

ロードバランサーに、リクエストの に基づいて受信リクエストを特定のサーバーに転送させることもできますURL。たとえば、オンラインコマースアプリケーションをサポートする 10 台のアプリケーションサーバーのグループがあるとします。そのうちの 8 台のサーバーではカタログを処理し、2 台のサーバーでは支払いを処理します。HTTP リクエスト に基づいて、すべての支払い関連のリクエストを支払いサーバーに転送しますURL。この場合、「支払い」または「チェックアウト」を含むすべての URLs を支払いサーバーの 1 つに転送します。

ではHAProxy、 URLベースのマッピングを使用して、指定された文字列を特定のサーバーにURLs含むように に指示できます。 AWS OpsWorks スタックで URLベースのマッピングを使用するには、haproxy組み込みクックブックの haproxy-default.erb テンプレートを上書きしてカスタムHAProxy設定ファイルを作成する必要があります。詳細については、HAProxy「設定マニュアル」および「」を参照してくださいカスタムテンプレートの使用。HTTPS リクエストに URLベースのマッピングを使用することはできません。HTTPS リクエストは暗号化されているため、 HAProxyはリクエスト を調べる方法がありませんURL。

Elastic Load Balancing では、URLマッピングのサポートが制限されています。詳細については、「Listener Configurations for Elastic Load Balancing」(Elastic Load Balancing のリスナー設定) を参照してください。