翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Elastic Load Balancing は、アプリケーションの可用性とスケーラビリティの向上に役立つ Amazon のウェブサービスです。このサービスによって、アプリケーションの負荷を簡単に複数の Amazon EC2 インスタンスに配信できます。Elastic Load Balancing による冗長化で可用性が向上し、アプリケーションのトラフィック増加を suppot できます。
Elastic Load Balancing を使用すると、すべての実行中のインスタンス間で受信アプリケーショントラフィックを自動的に配信してバランスをとることができます。アプリケーションの容量を増やす必要がある場合は、新しいインスタンスを簡単に追加することもできます。
アプリケーションをデプロイすると、Elastic Beanstalk によって自動的に Elastic Load Balancing がプロビジョニングされます。AWS Toolkit for Visual Studio のアプリケーション環境タブ内の [Load Balancer] (ロードバランサ―) タブで Elastic Beanstalk 環境の Amazon EC2 インスタンス設定を編集できます。
ここでは、アプリケーションで設定できる Elastic Load Balancing パラメータについて説明します。
ポート
Elastic Beanstalk アプリケーションへのリクエストを処理するためにプロビジョニングされたロードバランサーは、アプリケーションを実行している Amazon EC2 インスタンスにリクエストを送信します。プロビジョニングされたロードバランサーは、HTTP ポートと HTTPS ポートのリクエストをリッスンし、AWS Elastic Beanstalk アプリケーションの Amazon EC2 インスタンスにリクエストをルーティングすることができます。デフォルトでは、ロードバランサーは HTTP ポートのリクエストを処理します。そのためには、1 つ以上のポート (HTTP または HTTPS) を有効にする必要があります。
重要
指定したポートがロックされていないことを確認してください。ロックされている場合は、Elastic Beanstalk アプリケーションに接続できません。
HTTP ポートをコントロールします
HTTP ポートをオフにするには、[HTTP Listener Port] で [OFF] を選択します。HTTP ポートを有効にするには、リストから HTTP ポート ([80] など) を選択します。
注記
デフォルトポート 80 以外のポート (例: ポート 8080) を使用して環境にアクセスする場合は、既存のロードバランサーにリスナーを追加し、そのポートでリッスンするようにリスナーを設定します。
例えば、Classic Load Balancer 用の AWS CLI を使用して、次のコマンドを入力します。LOAD_BALANCER_NAME
は Elastic Beanstalk のロードバランサーの名前に置き換えてください。
aws elb create-load-balancer-listeners --load-balancer-name LOAD_BALANCER_NAME
--listeners "Protocol=HTTP, LoadBalancerPort=8080, InstanceProtocol=HTTP, InstancePort=80"
例えば、Application Load Balancer 用の AWS CLI を使用して、次のコマンドを入力します。LOAD_BALANCER_ARN
は Elastic Beanstalk のロードバランサーの ARN に置き換えてください。
aws elbv2 create-listener --load-balancer-arn LOAD_BALANCER_ARN
--protocol HTTP --port 8080
Elastic Beanstalk を使用して環境を監視する場合は、ポート 80 のリスナーを削除しないでください。
HTTPS ポートを制御する
Elastic Load Balancing は、ロードバランサーへのクライアント接続のトラフィックを暗号化するために、HTTPS/TLS プロトコルをサポートしています。ロードバランサーから EC2 インスタンスへの接続では、プレーンテキストの暗号化が使用されます。デフォルトで、HTTPS ポートは無効です。
HTTPS ポートを有効にするには
-
AWS Certificate Manager (ACM) を使用して新しい証明書を作成するか、あるいは証明書とキーを AWS Identity and Access Management (IAM) にアップロードします。ACM 証明書のリクエストの詳細については、AWS Certificate Manager ユーザーガイドの「証明書のリクエスト」を参照してください。ACM へのサードパーティー証明書のインポートの詳細については、AWS Certificate Manager ユーザーガイドの「証明書のインポート」を参照してください。ACM がお客様のリージョンで使用できない場合は、AWS Identity and Access Management (IAM) を使用してサードパーティーの証明書をアップロードします。ACM および IAM サービスは証明書を保存し、SSL 証明書の Amazon リソースネーム (ARN) を提供します。証明書の作成と IAM へのアップロードに関する詳細については、IAM ユーザーガイドの「サーバー証明書の使用」を参照してください。
-
[HTTPS Listener Port (HTTPS リスナーポート)] のポートを選択して、HTTPS ポートを指定します。
-
[SSL 証明書 ID] に、SSL 証明書の Amazon リソースネーム (ARN) を入力します。例えば、
arn:aws:iam::123456789012:server-certificate/abc/certs/build
、arn:aws:acm:us-east-2:123456789012:certificate/12345678-12ab-34cd-56ef-12345678
などです。ステップ 1 で作成またはアップロードした SSL 証明書を使用します。
HTTPS ポートをオフにするには、[HTTPS Listener Port] で [OFF] を選択します。
ヘルスチェック
ヘルスチェックの定義には、インスタンスのヘルスを照会する URL が含まれます。デフォルトでは、Elastic Beanstalk はレガシーではないコンテナの場合は TCP:80 を使用し、レガシーコンテナの場合は HTTP:80 を使用します。デフォルト URL を上書きしてアプリケーションの既存のリソースに一致させるには (/myapp/default.aspx
などにするには)、その URL を [Application Health Check URL (アプリケーションヘルスチェックの URL)] ボックスに入力します。デフォルトの URL をオーバーライドすると、Elastic Beanstalk は HTTP を使用してリソースを照会します。レガシーコンテナタイプを使用しているかどうかを確認するには、「一部のプラットフォームバージョンがレガシーとマークされているのはなぜですか?」を参照してください。
[Load Balancing] パネルの [EC2 Instance Health Check] を使用して、ヘルスチェックの設定を制御できます。
ヘルスチェックの定義には、インスタンスのヘルスをクエリする URL が含まれます。デフォルト URL を上書きしてアプリケーションの既存のリソースに一致させるには (/myapp/index.jsp
などにするには)、その URL を [Application Health Check URL (アプリケーションヘルスチェックの URL)] ボックスに入力します。
次の一覧では、アプリケーションに設定できるヘルスチェックパラメータについて説明します。
-
[Health Check Interval (seconds)] には、Elastic Load Balancing がアプリケーションの Amazon EC2 インスタンスの各ヘルスチェックを待機する秒数を入力します。
-
[Health Check Timeout (seconds)] には、Elastic Load Balancing がインスタンスの応答がないとみなす応答待機時間の秒数を入力します。
-
[Healthy Check Count Threshold] および [Unhealthy Check Count Threshold] には、Elastic Load Balancing がインスタンスのヘルスステータスを変更するまでの URL 探索の連続成功回数または失敗回数を指定します。たとえば、[Unhealthy Check Count Threshold (ヘルスチェック失敗数のしきい値)] ボックスで
5
を指定した場合、Elastic Load Balancing がヘルスチェックを失敗とみなすには、URL からエラーメッセージまたはタイムアウトが 5 回連続して返される必要があります。
セッション
デフォルトでは、ロードバランサーは負荷が最小になるように、各リクエストを個別にサーバーインスタンスにルーティングします。比較すると、スティッキーセッションの場合、セッション中にユーザーから受信するすべてのリクエストが、同じサーバーインスタンスに送信されるように、ユーザーのセッションを特定のサーバーインスタンスにバインドします。
アプリケーションでスティッキーセッションが有効な場合、Elastic Beanstalk は、ロードバランサーで生成された HTTP Cookie を使用します。ロードバランサーは、ロードバランサーが生成する特別な Cookie を使って、各リクエストのアプリケーションインスタンスを追跡します。ロードバランサーがリクエストを受け取ると、まずこの Cookie がリクエスト内にあるかどうかを調べます。その Cookie がある場合、リクエストは Cookie で指定されたアプリケーションインスタンスに送信されます。Cookie がない場合、ロードバランサーは、既存のロードバランシングアルゴリズムに基づいてアプリケーションインスタンスを選択します。同じユーザーからの以降のリクエストをそのアプリケーションインスタンスにバインドするため、応答に Cookie が挿入されます。ポリシー設定では、各 Cookie の有効期間を設定する Cookie 期限を検証します。
[Load Balancer (ロードバランサー)] タブの [Sessions (セッション)] セクションを使用して、アプリケーションのロードバランサーでスティッキーセッションの使用を許可できるようにするかどうかを指定できます。
Elastic Load Balancing の詳細については、Elastic Load Balancing デベロッパーガイドを参照してください。