翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# レイヤーの負荷分散
<a name="best-server-load-balancing"></a>

**重要**  
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。

OpsWorks スタックには、[Elastic Load Balancing](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elastic-load-balancing.html) と [HAProxy](http://www.haproxy.org/) の 2 つの負荷分散オプションが用意されています。これらは通常、アプリケーションサーバーレイヤーのインスタンス間で負荷を分散するために使用されます。このトピックでは、レイヤーに負荷分散を追加するときのオプションの選択に役立つように、各オプションの利点と制限事項について説明します。場合によって、両方のオプションの使用をお勧めします。

**SSL ターミネーション**  <a name="best-server-load-balancing-ssl"></a>
SSL ターミネーションは組み込み HAProxyLayer で処理されません。サーバーで SSL を終了させる必要があります。このアプローチの利点は、トラフィックがサーバーに到達するまで暗号化されることです。ただし、サーバーによる復号の処理が必要であり、それによりサーバーの負荷が増えます。また、アプリケーションサーバーに SSL 証明書を配置し、ユーザーからアクセスできるようにする必要があります。  
Elastic Load Balancing を使用して SSL をロードバランサーで終了することができます。これにより、アプリケーションサーバーの負荷は低減されますが、ロードバランサーとサーバーとの間のトラフィックは暗号化されません。Elastic Load Balancing で[サーバーで SSL を終了すること](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-https-load-balancers.html)もできますが、設定がやや複雑です。

**スケーリング**  <a name="best-server-load-balancing-scaling"></a>
受信トラフィックが HAProxy ロードバランサーの容量を超える場合は、その容量を手動で増やす必要があります。  
Elastic Load Balancing は、着信トラフィックを処理するように自動的にスケーリングされます。最初にオンラインになったときに想定負荷を処理するための容量を十分に確保するには、Elastic Load Balancing ロードバランサーを[事前ウォーミング](https://aws.amazon.com/articles/1636185810492479#pre-warming)します。

**ロードバランサーの障害**  <a name="best-server-load-balancing-failure"></a>
HAProxy サーバーをホストしているインスタンスに障害が発生した場合、インスタンスを再起動できるようになるまで、サイト全体をオフラインにすることができます。  
Elastic Load Balancing は、HAProxy よりも高い耐障害性を備えています。たとえば、EC2 インスタンスを登録している各アベイラビリティーゾーンで負荷分散ノードがプロビジョニングされます。1 つのゾーンでサービスが中断された場合は、他のノードで受信トラフィックの処理が継続されます。詳細については、[「Elastic Load Balancing Concepts」](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/TerminologyandKeyConcepts.html)(Elastic Load Balancing のコンセプト) を参照してください。

**アイドルタイムアウト**  <a name="best-server-load-balancing-timeout"></a>
指定したアイドルタイムアウト値よりも長い時間アイドル状態になった場合、両方のロードバランサーによって接続が終了されます。  
+ HAProxy – アイドルタイムアウト値には上限はありません。
+ Elastic Load Balancing – デフォルトのアイドルタイムアウト値は 60 秒で、最大値は 3600 秒 (60 分) です。
Elastic Load Balancing のアイドル時間の制限は、ほとんどの目的に対して十分たります。それより長いアイドルタイムアウトが必要な場合は、HAProxy を使用することをお勧めします。例えば:   
+ HTTP 接続を長時間開いたままにして、プッシュ通知を行う場合。
+ 管理インターフェイスを使用して、60 分を超える可能性のあるタスクを実行する場合。

**URL ベースのマッピング**  <a name="best-server-load-balancing-url"></a>
ロードバランサーで、リクエストの URL に基づいて、特定のサーバーに受信リクエストを転送することが必要な場合があります。たとえば、オンラインコマースアプリケーションをサポートする 10 台のアプリケーションサーバーのグループがあるとします。そのうちの 8 台のサーバーではカタログを処理し、2 台のサーバーでは支払いを処理します。リクエスト URL に基づいて、すべての支払い関連の HTTP リクエストを支払サーバーに割り振ります。この場合、"payment" または "checkout" を含むすべての URL を支払サーバーのいずれかに割り振ります。  
HAProxy では、URL ベースのマッピングを使用して、指定した文字列を含む URL を特定のサーバーに割り振ることができます。 OpsWorks スタックで URL ベースのマッピングを使用するには、`haproxy`組み込みクックブックの`haproxy-default.erb`テンプレートを上書きしてカスタム HAProxy 設定ファイルを作成する必要があります。詳細については、[HAProxy 設定マニュアル](http://cbonte.github.io/haproxy-dconv/configuration-1.5.html)と「[カスタムテンプレートの使用](workingcookbook-template-override.md)」を参照してください。HTTPS リクエストに URL ベースのマッピングを使用することはできません。HTTPS リクエストは暗号化されているため、HAProxy にはリクエスト URL を調べる方法がありません。  
Elastic Load Balancing では、URL マッピングのサポートが制限されています。詳細については、[「Listener Configurations for Elastic Load Balancing」](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html)(Elastic Load Balancing のリスナー設定) を参照してください。

**[Recommendation:]** (推奨事項:) HAProxy でしか処理できない要件がある場合を除き、負荷分散には Elastic Load Balancing for load balancing を使用することをお勧めします。その場合は、一連の HAProxy サーバーに受信トラフィックを分散させるフロントエンドロードバランサーとして Elastic Load Balancing を使用し、この 2 つを組み合わせるのが最適なアプローチになるはずです。これを実行するには:
+ スタックの各アベイラビリティーゾーンの HAProxy インスタンスを設定して、ゾーンのアプリケーションサーバーにリクエストが割り振られるようにします。
+ Elastic Load Balancing ロードバランサーに HAProxy インスタンスを割り当て、このロードバランサーから HAProxy ロードバランサーに受信リクエスト分散させます。

このアプローチでは、HAProxy の URL ベースのマッピングを使用して、さまざまなタイプのリクエストを適切なアプリケーションサーバーに割り振ることができます。ただし、HAProxy サーバーのいずれかがオフラインになっても、Elastic Load Balancing ロードバランサーが、受信トラフィックを正常な HAProxy サーバーに自動的に分散させるため、サイトは継続して機能します。フロントエンドロードバランサーとして Elastic Load Balancing を使用する必要があり、HAProxy サーバーによって他の HAProxy サーバーにリクエストを分散させることはできないことに注意してください。