Jayendra’s Blog

この記事は自己学習用に「AWS Elastic Load Balancing – ELB – Certification（Jayendra’s Blogより）」を日本語に訳した記事です。

AWS Elastic Load Balancer – ELB

  • ELBでは、受信トラフィックを複数の正常な EC2 インスタンスに自動的に分散させることができます。
  • ELB は、クライアントへの接触の単一のポイントとして機能します。
  • ELB は、情報の全体的な流れを中断することなく、1つ以上のアベイラビリティーゾーンにまたがる複数の EC2 インスタンスの追加または削除を許可することで、透過的で、アプリケーションの可用性を向上させます。
  • ELB の利点
    • ELB は、フォールトトレラントでアクティブに監視される分散システムです。
    • ロードバランサーの管理、保守、およびスケーリングの複雑さを抽象化する。
    • また、ネットワーク上の攻撃に対する防御の最初の行として機能することができます。
    • EC2 インスタンスが主な作業に集中できるように、暗号化と復号化 (SSL termination) の作業をオフロードできます。
    • オートスケーリングとの統合が可能で、さまざまなトラフィックレベルに対応できるバックエンド容量を確保。
    • 単一障害点にならないように設計されている。
  • ELB は、既定では、各要求を、最小の負荷で登録されたインスタンスに個別にルーティングします。
  • EC2 インスタンスが失敗した場合、ELB は、残りの実行中の正常な EC2 インスタンスにトラフィックを自動的に経路します。失敗した EC2 インスタンスが復元されると、ELB そのインスタンスへのトラフィックを復元します。
  • ロードバランサーは、リージョン内の AZ 間でのみ機能します。

ELB

ELB キーポイント

スケーリング ELB

  • 各 ELB は、デフォルトの容量で割り当てられ、構成されます。
  • ELB コントローラは、すべての構成を格納し、またロードバランサーを監視し、クライアントの要求を処理するために使用される容量を管理するサービスです。
  • トラフィックプロファイルが変更されると、コントローラサービスはロードバランサーをスケールして、より多くの要求を処理し、すべての AZ で均等にスケーリングします。
  • ELB は、より大きなリソース (スケールアップ-パフォーマンス特性の高いリソース) または個々のリソース (スケールアウト) のいずれかを利用して、容量を増加させます。
  • AWS 自体が ELB 容量のスケーリングを処理します。このスケーリングは、ELB がリクエストをルーティングする EC2 インスタンスのスケーリングとは異なります。これは自動スケーリングによって処理されます
  • Elastic Load Balancingに必要な時間は、トラフィックプロファイルの変更に応じて1〜7分です

暖気（Pre-warming）ELB

  • ELBはトラフィックの段階的な増加に最も効果的です。
  • AWS は、自動的にスケーリングし、大部分のユースケースを処理することができます。
  • ただし、特定のシナリオでは、フラッシュトラフィックのスパイクが予想される場合、または負荷テストを構成してトラフィックを徐々に増やすことができない場合は、AWS サポートに連絡してロードバランサーを “事前に温めておく” ことをお勧めします。
  • AWS は、ロードバランサーが予想されるトラフィックに基づいて適切なレベルの容量を持つように構成することにより、ELB を事前にウォームアップするのに役立ちます。
  • AWS では、リクエスト/レスポンスの合計サイズで、開始日、終了日、および予想される1秒あたりのリクエストレートに関する情報が必要です。

DNS の解決

  • ELB は、トラフィックプロファイルに応じて自動的にスケーリングされます。
  • スケーリングすると、ELB は、ロードバランサーのドメインネームシステム (DNS) レコードを更新して、新しいリソースにそれぞれの IP アドレスが DNS に登録されるようにします。
  • 作成された DNS レコードには、60秒のタイム・ツー・ライブ (TTL) 設定が含まれています。
  • 既定では、ELB はクライアントが DNS 解決を実行するときに複数の IP アドレスを返し、各 DNS 解決要求に対してランダムにレコードが順序付けられます。
  • クライアントは、容量の増加を利用するために、少なくとも60秒ごとに DNS を再検索することをお勧めします。

ロードバランサーの種類

  • インターネットロードバランサー
    • インターネットに接続するロードバランサーは、インターネット経由でクライアントからのリクエストを受け取り、ロードバランサーに登録されている EC2 インスタンス全体に分散します。
  • 内部ロードバランサー
    • 内部ロードバランサーは、プライベートサブネット内の EC2 インスタンスへのトラフィックをルーティングします。

アベイラビリティーゾーン/サブネット

  • ELB を使用すると、サブネットを追加することができるので、それぞれのアベイラビリティーゾーンにロードバランサーノードが作成されます。
  • ELB には少なくとも1つのサブネットが接続されている。
  • ELB には、AZ ごとに1つのサブネットしか接続できません。既にアタッチされた AZ でサブネットをアタッチすると、既存のサブネットが置き換えられます。
  • 各サブネットは、少なくとも a/27 ビットマスクを持つ CIDR ブロックを持ち、ELB がバックエンドインスタンスとの接続を確立するために使用する少なくとも8つの空き IP アドレスを持っている必要があります。
  • 高可用性を実現するには、インスタンスが単一のサブネット内にある場合でも、1つのサブネットを AZ ごとに少なくとも2つの AZ にアタッチすることをお勧めします。
  • サブネットは ELB からアタッチまたはデタッチすることができ、それに応じてサブネット内のインスタンスへの要求の送信を開始または停止します。

セキュリティグループと NACL

  • セキュリティグループ & NACLs は、内部 ELB のインターネット ELB または VPC CIDR のクライアントからロードバランサーリスナポートで受信トラフィックを許可する必要があります。
  • セキュリティグループ & NACLs は、インスタンスリスナポートとヘルスチェックポートの両方でバックエンドインスタンスへのアウトバウンドトラフィックを許可する必要があります。
  • NACLs は、さらに、一時的にポートの応答を許可する必要があります。
  • すべての EC2 インスタンスは、ELB からの着信トラフィックを許可する必要があります。

SSL ネゴシエーションの構成

  • HTTPS ロードバランサーの場合、ELB では、セキュリティポリシーと呼ばれるセキュアソケットレイヤー (SSL) ネゴシエーション構成を使用して、クライアントとロードバランサー間の SSL 接続をネゴシエートします。
  • セキュリティポリシーは、SSL プロトコル、SSL 暗号、およびサーバーの順序設定オプションを組み合わせたものです。
    • ELB は、次のバージョンの SSL プロトコル TLS 1.2、TLS 1.1、TLS 1.0、SSL 3.0、SSL 2.0 をサポートしています。
    • SSL プロトコルは、インターネット経由でデータを暗号化するために複数の SSL 暗号を使用します。
    • ELB は、クライアントとロードバランサーの間の接続をネゴシエートするために、サーバーの順序の優先オプションをサポートします。
    • SSL 接続ネゴシエーションプロセス中に、ロードバランサーは、クライアントのリストにある最初の暗号をサーバーのリストと照合する既定の動作ではなく、クライアントのリストにある最初の暗号を制御して選択することができます。
  • ELB では、定義済みのセキュリティポリシーを使用したり、特定のニーズに合わせてカスタムセキュリティポリシーを作成したりできます。None が指定されている場合、ELB は、最新の定義済みセキュリティポリシーを選択します。

ヘルスチェック

  • ロードバランサーは、インスタンスが正常な状態か異常な状態かにかかわらず、登録されているすべてのインスタンスでヘルスチェックを実行します。
  • ロードバランサーは、EC2 インスタンスの可用性を検出するためにヘルスチェックを実行し、ロードバランサーは定期的に ping を送信し、接続を試行するか、EC2 インスタンスをヘルスチェックに要求を送信します。
  • ヘルスチェックは正常なインスタンスのステータスを InService、不健全なインスタンスの OutOfService です。
  • ロードバランサーは、ping プロトコル、ping ポート、および ping パスごとに・間隔秒で、登録されている各インスタンスに要求を送信します。応答タイムアウト期間内にインスタンスが応答するのを待機します。正常性チェックが、連続して失敗した応答に対して異常なしきい値を超えた場合、ロードバランサーはインスタンスをサービスから取り出します。ヘルスチェックが正常なしきい値を超えて成功した応答を継続すると、ロードバランサーはインスタンスをサービスに戻します。
  • ロードバランサーは、正常な EC2 インスタンスに要求を送信し、正常でないインスタンスへの要求のルーティングを停止します。

リスナー

  • リスナーは、クライアントからの接続要求をチェックするプロセスです。
  • リスナーは、フロントエンド (クライアントからロードバランサー) 接続のプロトコルとポート、およびバックエンド (バックエンドインスタンスへのロードバランサー) 接続のプロトコルとポートで構成されます。
  • リスナーは、HTTP、HTTPS、SSL、TCP プロトコルをサポートします。
  • HTTPS または SSL 接続に x.509 証明書が必要であり、ロードバランサーは証明書を使用して接続を終了し、クライアントから要求を復号化してからバックエンドインスタンスに送信します。
  • SSL を使用するが、ロードバランサーの接続を終了したくない場合は、クライアントからロードバランサーへの接続に TCP を使用し、ロードバランサーからバックエンドアプリケーションへの接続に SSL プロトコルを使用し、要求を処理するバックエンドインスタンスに証明書を展開します。
  • バックエンドに HTTPS/SSL 接続を使用する場合は、バックエンドインスタンスで認証を有効にすることができます。この認証は、バックエンドインスタンスが暗号化された通信のみを受け付けるようにし、バックエンドインスタンスに正しい証明書があることを確認するために使用できます。
  • ELB HTTPS リスナーはクライアント側 SSL 証明書をサポートしていません。

アイドル接続タイムアウト

  • クライアントがロードバランサーを介して行う要求ごとに、クライアント要求ごとに2つの接続を保持し、クライアントとの接続を1つ、もう一方の接続をバックエンドインスタンスに対して行います。
  • 各接続について、ロードバランサーは、指定された期間、接続を介してデータが送信されない場合にトリガーされるアイドルタイムアウトを管理します。データが送信または受信されていない場合、アイドルタイムアウト期間 (デフォルトは60秒) の経過後に接続を閉じます。
  • ファイルのアップロードなどの長時間の操作では、接続のアイドルタイムアウト設定を調整して、長い操作が完了するまでの時間を確保する必要があります。

X-Forwarded Headers とプロキシプロトコルのサポート

  • ELB は、クライアントとバックエンドサーバー間のトラフィックをインターセプトするため、バックエンドサーバーは、クライアントとロードバランサーの間で使用される IP アドレス、プロトコル、およびポートを認識しません。
  • ELB は、HTTP プロトコルを使用するときに、バックエンドサーバーが同じように追跡するのに役立つ X-Forwarded Headers サポートを提供します。
    • X-Forwarded-For: HTTP または HTTPS ロードバランサを使用するときに、バックエンドサーバーがクライアントの IP アドレスを識別するのを支援するために、要求ヘッダーを使用します。
    • X-Forwarded-Proto: バックエンドサーバがクライアントとサーバの接続に使用したプロトコル（HTTP/S）を識別するためのリクエストヘッダ。
    • X-Forwarded-Port: HTTP または HTTPS ロードバランサがクライアントに接続するために使用するポートを識別します。
  • ELB は、非 HTTP プロトコルを使用する場合、または HTTPS を使用していて、ロードバランサーの SSL 接続を終了しない場合に、バックエンドサーバーが同じように追跡するためのプロキシプロトコルサポートを提供します。
  • プロキシプロトコルは、接続が要求された宛先への接続を要求するソースから接続情報を運ぶために使用されるインターネットプロトコルです。
  • ELB は、送信元 IP アドレス、宛先 IP アドレス、ポート番号などの接続情報を持つ、人間が判読できるヘッダー形式を使用するプロキシプロトコルバージョン1を使用します。
  • プロキシプロトコルが有効になっているプロキシの背後に ELB が既に存在する場合は、ELB でプロキシプロトコルを有効にすると、ヘッダーが2回追加されます。

クロスゾーン

  • デフォルトでは、ロードバランサは、受信可能な可用性ゾーン全体に着信要求を均等に配信します。 AZ-a に5つのインスタンスがあり、AZ-b に2つのインスタンスがある場合、負荷はそれぞれの AZ に50％ ずつ分散されます。
  • クロスゾーン負荷分散を有効にすると、ELB は、AZ に関係なく、すべてのバックエンドインスタンスに対して、受信要求を均等に分散できます。
  • クロスゾーンロードバランサーを使用すると、各アベイラビリティーゾーンで同等の数のバックエンドインスタンスを維持する必要性が軽減され、1つ以上のバックエンドインスタンスの損失を処理するアプリケーションの機能が向上します。
  • フォールトトレランスを向上させるために、各アベイラビリティーゾーンでほぼ同等の数のインスタンスを維持することをお勧めします。

接続ドレイン

  • 既定では、ELB を持つ登録済みの EC2 インスタンスが登録または異常になった場合、ロードバランサーはすぐに接続を閉じます。
  • 接続のドレインは、ロードバランサーが既存の接続を開いたままにしている飛行中の要求を完了し、登録解除または異常なインスタンスに新しい要求が送信されるのを防ぐのに役立ちます。
  • 接続のドレインは、ソフトウェアのアップグレードを展開したり、顧客の経験に影響を与えることなくバックエンドのインスタンスを交換するなどのメンテナンスを実行するのに役立ちます。
  • 接続のドレインは、インスタンスを登録解除して報告する前に、最大時間（1〜3,600秒とデフォルトの300秒）を指定して接続を有効に保つことができます。 不健全なインスタンスへの接続には、最大タイムアウト制限は適用されません。
  • インスタンスが自動スケーリンググループの一部であり、ロードバランサーで接続のドレインが有効になっている場合、auto scaling は、スケーリングイベントまたはヘルスチェックの交換のためにインスタンスを終了する前に、フライト中の要求が完了するのを待機するか、最大タイムアウト時間を超過します。

スティッキー・セッション (セッションアフィニティ)

  • ELB は、ユーザーのセッションをインスタンスにバインドし、すべての要求を同じインスタンスに送信できるようにする、スティッキーセッション機能 (セッションアフィニティとも呼ばれます) を使用するように構成できます。
  • スティッキー性は、アプリケーションのセッションクッキー (存在する場合)、またはエラスティックロードバランサーによって作成された AWSELB という名前の cookie によって制御される期間の間、残ります。
  • デフォルトでは、ELB のスティッキー・セッションは無効になっています。

要件

  • HTTP/HTTPS ロードバランサー。
  • SSL トラフィックは ELB で終了する必要があります。ELB は、HTTP クッキーを利用することによって、HTTP / HTTPSリスナー上のセッション・スティッキー性を実現します。 SSL トラフィックが
    ELB 上で終了せず、バックエンドインスタンスで終了した場合、ELB は HTTP ヘッダーの可視性を持たないため、渡される HTTP ヘッダーを設定または読み取ることができません。
  • 各アベイラビリティーゾーン内の少なくとも1つの正常なインスタンス。

持続時間ベースのセッションのスティッキー性

  • 期間ベースのセッションスティッキ性は、各リスナーへの各要求のインスタンスを追跡するために作成された特別な cookie を使用して、ELB によって維持されます。
  • ロードバランサーが要求を受信すると、最初にこの cookie が要求に存在するかどうかが確認されます。その場合、要求は cookie で指定されたインスタンスに送信されます。
  • cookie が存在しない場合、ELB は既存の負荷分散アルゴリズムに基づいてインスタンスを選択し、そのインスタンスに対して同じユーザーからの後続の要求をバインドするための応答に cookie が挿入されます。
  • スティッキーのポリシー構成では、cookie の有効期限が定義され、各 cookie の有効期間が決まります。cookie は、期間の有効期限が切れると自動的に更新されます。

アプリケーション制御セッションのスティッキー

  • ロードバランサーは、特別な cookie のみを使用して、最初の要求を処理したインスタンスにセッションを関連付けますが、ポリシー構成で指定されたアプリケーション cookie の有効期間に従います。
  • ロードバランサは、アプリケーション応答に新しいアプリケーション　Cookie　が含まれている場合にのみ、新しいスティッキクッキーを挿入します。ロードバランサのスティッキークッキーは、要求ごとに更新されません。
  • アプリケーション cookie が明示的に削除または期限切れになった場合、新しいアプリケーション cookie が発行されるまでセッションはスティッキーで停止します。
  • インスタンスが失敗した場合、または異常が発生した場合、ロードバランサーはそのインスタンスへのルーティング要求を停止し、代わりに既存の負荷分散アルゴリズムに基づいて新しい正常なインスタンスを選択します。ロードバランサーは、セッションを “スタック” として新しい正常なインスタンスに処理し、失敗したインスタンスが戻った場合でもそのインスタンスへの要求のルーティングを続行します。

ロードバランサーの削除

  • ロードバランサーを削除しても、ロードバランサーに登録されているインスタンスは影響を受けず、引き続き実行されます。

ELB with Autoscaling

オートスケーリングとELBについてを参照してください。

AWS認定試験の練習問題

  • 質問はインターネットから収集され、答えは自分の知識と理解に基づいてマークされます（これはあなたと異なる場合があります）。
  • AWSサービスは毎日更新され、回答と質問はすぐに時代遅れになる可能性がありますので、それに応じて調査してください。
  • AWSのアップデートのペースを追うためにAWS試験の質問は更新されないため、基礎となる機能が変更されても質問が更新されないことがあります。
  • さらなるフィードバック、ディスカッション、修正を可能にします。
  1. ユーザーが ELB で HTTPS リスナを構成しました。ユーザーは、クライアントと ELB の間で SSL をネゴシエートするのに役立つセキュリティポリシーを構成していません。このシナリオでは、ELB は何を行いますか？
    1. デフォルトでは、ELB はセキュリティポリシーの最初のバージョンを選択します。
    2. デフォルトでは、ELB はポリシーの最新バージョンを選択します。
    3. ELB の作成はセキュリティポリシーなしで失敗します。
    4. SSL が既にインストールされているため、セキュリティポリシーを持っている必要はありません
  2. ユーザは、クライアントとロードバランサ間の安全なネゴシエーションのためのセキュリティポリシーを使用して、SSL を使用して ELB を設定しました。 ELB のセキュリティポリシーは、さまざまな暗号をサポートしています。 下記のどのオプションが、クライアントが SSL 経由で ELB DNS を要求しているときに、クライアント側で一致する暗号を ELB 暗号リストと識別するのに役立つか。
    1. 暗号プロトコル
    2. クライアント構成の設定
    3. サーバーの順序の優先順位
    4. ロードバランサーの優先順位
  3. ユーザーは、クライアントとロードバランサー間のセキュリティで保護されたネゴシエーションを行うために、SSL を使用して ELB を構成しています。ELB でサポートされているセキュリティポリシーを以下に示します。
    1. 動的セキュリティポリシー
    2. 他のすべてのオプション
    3. 定義済みのセキュリティポリシー
    4. 既定のセキュリティポリシー
  4. ユーザは、クライアントとロードバランサ間の安全なネゴシエーションのためのセキュリティポリシーを使用して、SSL を使用して ELB を設定しました。 次の SSL プロトコルのうち、セキュリティポリシーでサポートされていないものはどれですか？
    1. TLS 1.3
    2. TLS 1.2
    3. SSL 2.0
    4. SSL 3.0
  5. ユーザーは、バックエンドインスタンスと同様に ELB でリスナを使用して。ユーザーはヘッダー内の送信元と送信先の IP 情報を取得するためにプロキシプロトコルを有効にする必要があります。以下のステートメントのうちユーザーは TCP 構成でプロキシプロトコルを理解するのに役立ちますか？
    1. エンドユーザーがプロキシサーバーの背後で要求している場合、ユーザーは ELB でプロキシプロトコルを有効にしないでください。
    2. ELB ロードバランサーとバックエンドインスタンスの両方でリッスンしているときにプロキシプロトコルをサポートしていません。
    3. エンドユーザーがプロキシサーバーから直接要求しているかどうかにかかわらず、プロキシプロトコルの違いはありません。
    4. エンドユーザーがプロキシの背後に要求している場合、ユーザーは ELB 構成に「isproxy」フラグを追加する必要があります。
  6. ユーザーが ELB でセッションの粘りを有効にしました。ユーザーは、ELB にクッキーを管理させたくありません。代わりに、彼は、アプリケーションがクッキーを管理することを望んでいます。cookie にバインドされているサーバーインスタンスがクラッシュした場合はどうなりますか。
    1. 応答は、クッキーを持っていますが、スティッキーが削除されます
    2. 新しい cookie が挿入されるまで、セッションは固定されません。
    3. ELB は、クッキーの可用性のためにエラーをスローします。
    4. セッションはスティッキーになり、ELB は ELB がクッキーを複製し続けるので、リクエストを別のサーバにルーティングします。
  7. ユーザが自動スケーリング付きの ELB を作成しました。 下記の ELB のオファリングは、実行中のリクエストを継続しながらインスタンスの登録抹消中にロードバランサから EC2 インスタンスへの新しいリクエストトラフィックの送信を停止するのに役立ちますか？
    1. ELB スティッキーセッション
    2. ELB 登録チェック
    3. ELB 接続ドレイン
    4. ELB 自動登録オフ
  8. ELB を使用して Web サーバーへのトラフィックを提供する場合、次のいずれかが当てはまりますか？
    1. Web サーバーはパブリックにアクセスできる必要があります。
    2. ELB と EC2 インスタンスの両方に同じセキュリティグループを適用する必要があります。
    3. ELB と EC2 インスタンスは同じサブネット内にある必要があります。
    4. ELB と EC2 インスタンスは同じ VPC 内にある必要があります。
  9. セキュリティポリシーと呼ばれるセキュアソケットレイヤ (SSL) ネゴシエーション構成を有効にすることにより、ユーザーは ELB を構成しました。以下のうち、ユーザーとクライアントの間の SSL 接続をネゴシエートする際に、このセキュリティポリシーの一部ではないオプションはどれですか？
    1. SSL プロトコル
    2. クライアントの注文の優先順位
    3. SSL 暗号
    4. サーバーの順序の優先順位
  10. ユーザーがアベイラビリティーゾーンの ELB を作成しました。ユーザーは、高可用性を実現するために、ELB にゾーンを追加したいと考えています。どのようにユーザーが既存の ELB により多くのゾーンを追加できますか?
    1. 既存の ELB にゾーンを追加することはできません。
    2. 唯一のオプションは、別のゾーンでインスタンスを起動し、ELB に追加することです。
    3. ユーザーは ELB を停止し、必要に応じてゾーンとインスタンスを追加する必要があります。
    4. ユーザーは AWS コンソールからその場でゾーンを追加できます。
  11. ユーザーは、5つのインスタンスが登録された ELB を起動しました。ユーザーは誤って ELB を削除します。インスタンスはどうなるのでしょうか?
    1. ELB は、インスタンスを削除するかどうかをユーザーにたずねます。
    2. インスタンスは終了されます。
    3. ELB が登録されているインスタンスを実行している場合は削除できません。
    4. インスタンスが実行され続ける。
  12. システム管理者は、ショッピングカートアプリケーションを作成し、EC2 上でホストしています。EC2 インスタンスは ELB の背後で実行されています。管理者は、エンドユーザーの要求が、ユーザーセッションが作成された EC2 インスタンスに常に移動するようにしたいと考えています。どのように管理者はこれを構成できますか?
    1. ELB クロスゾーン負荷分散を有効にする。
    2. ELB クッキーの設定を有効にする。
    3. ELB スティッキーセッションを有効にする。
    4. ELB 接続のドレインを有効にする。
  13. ユーザーは、自動スケーリングを使用してインスタンスが登録解除されている間に、飛行中のリクエストを続行できるように、ELB を使用して接続をドレインします。 ユーザーがドレイン時間を指定していない場合、ELB は機内リクエスト要求のトラフィックをどのくらいの期間にわたって継続できますか？
    1. 600秒
    2. 3600秒
    3. 300秒
    4. 0秒
  14. 顧客には、cookie ベースのセッションを使用してログインしたユーザーを追跡する Web アプリケーションがあります。ELB と Auto スケーリングを使用して AWS にデプロイされます。お客様は、負荷が増加すると自動スケーリングによって新しいインスタンスが起動されますが、既存のインスタンスの負荷は減少せず、既存のすべてのユーザーの操作性が低下します。 どの2つの選択肢が、ユーザーエクスペリエンスの低迷の原因となる可能性のある動作を個別に記述していますか？
    1. ELB の通常の動作では、同じユーザーから同じバックエンドインスタンスに要求が送信されます (既定ではありません)。
    2. スティッキー・セッションが有効になっている場合の ELB の動作により、ELB は同じセッションで同じバックエンドに要求を送信します。
    3. 障害のあるブラウザは、ELB DNS 名の TTL を尊重していません (DNS TTL は、トラフィックがルーティングされる EC2 インスタンスではなく、スケーリングした場合にのみ ELB インスタンスに影響します)
    4. Web アプリケーションは、comet やウェブソケットなどの長いポーリングを使用します。これにより、Web サーバへの接続を長時間開いたままにすることができます。
  15. 顧客には、cookie ベースのセッションを使用してログインした顧客を追跡するオンラインストアがあります。ELB とオートスケーリングを使用して AWS にデプロイされます。負荷が増加すると、自動スケーリングによって新しい Web サーバーが自動的に起動されますが、Web サーバーの負荷は減少しません。これにより、顧客エクスペリエンスが乏しくなります。何が問題を引き起こしている可能性がありますか?
    1. ELB DNS レコードの生存時間が大きすぎます (DNS TTL は、トラフィックがルーティングされる EC2 インスタンスではなく、スケーリングされた場合にのみ ELB インスタンスに影響を及ぼします)
    2. ELB は、以前に確立したセッションで要求を送信するように構成されます。
    3. ウェブサイトは、セッションを生きて維持している cloudfront を使用して
    4. 自動スケーリングのクールダウン期間中に新しいインスタンスが ELB に追加されない
  16. AWS 用のマルチプラットフォーム Web アプリケーションを設計しています。アプリケーションは EC2 インスタンス上で実行され、PC、タブレット、スマートフォンからアクセスされます。サポートされているプラットフォームへのアクセスは、windows、MacOS、iOS、アンドロイドです。異なるプラットフォームタイプには、個別のスティッキー・セッションと SSL 証明書のセットアップが必要です。次のうち最もコスト効率が高く、パフォーマンスが高いアーキテクチャのセットアップについて説明してください。
    1. オンプレミスのセッション状態と SSL 証明書を処理するためのハイブリッドアーキテクチャをセットアップし、VPC で実行されているさまざまなプラットフォームの種類に対して Web アプリケーションを実行する個別の EC2 インスタンスグループを設定します。
    2. すべてのプラットフォームに対して1つの ELB を設定し、その下に複数のインスタンス間で負荷を分散します。各 EC2 インスタンスは、特定のプラットフォームのすべての機能を実装します。
    3. 2つの ELB を設定します。最初の ELB はすべてのプラットフォームの SSL 証明書を処理し、2番目の ELB は各プラットフォームの Web アプリケーションを処理するために、それぞれの ELB を実行する個別の EC2 インスタンスグループのすべてのプラットフォームのセッションのスティッキーを処理します。)
    4. Web アプリケーションの共通コンポーネントを実行している EC2 インスタンスまたは EC2 インスタンスのグループに複数のエルを割り当て、各プラットフォームタイプごとに1つの ELB を指定します。セッションのスティッキーと SSL の終了は、エルで行われます。(セッションのスティッキーは、ELB 上で SSL ターミネーションを持つ HTTPS リスナを必要とし、ELB は複数の SSL 証明をサポートしていないため、各 cert に1つが必要です)
  17. レガシクライアントサーバーアプリケーションを AWS に移行しています。アプリケーションは、特定の DNS ドメイン (例: www.example.com) に応答し、2層アーキテクチャを持ち、複数のアプリケーションサーバーとデータベースサーバーを備えています。リモートクライアントは TCP を使用してアプリケーションサーバーに接続します。アプリケーションサーバーは、適切に機能するためにクライアントの IP アドレスを知り、現在 TCP ソケットからその情報を取得している必要があります。マルチ AZ RDS MySQL インスタンスがデータベースに使用されます。移行中にアプリケーションコードを変更できますが、変更要求をファイルする必要があります。スケーラビリティと高可用性を最大限に引き出すために、AWS のアーキテクチャをどのように実装しますか?
    1. アプリケーションでプロキシプロトコルサポートを実装するための変更要求をファイルします。TCP リスナとプロキシプロトコルが有効になっている ELB を使用して、異なる AZ の2つのアプリケーションサーバーに負荷を分散します。(TCP リスナとプロキシプロトコルを使用した ELB は IP を通過できるようになります)
    2. アプリケーションでクロスゾーンサポートを実装するための変更要求をファイルします。TCP リスナとクロスゾーン負荷分散を有効にした ELB を使用して、異なる AZ の2つのアプリケーションサーバーを利用します。
    3. アプリケーションで遅延ベースのルーティングサポートを実装するための変更要求をファイルします。異なる AZ の2つのアプリケーションサーバーに負荷を分散するために、遅延ベースのルーティングを有効にした Route53 を使用します。
    4. アプリケーションで Alias リソースサポートを実装するための変更要求をファイルする Route53 Alias リソースレコードを使用して、異なる AZ の2つのアプリケーションサーバーに負荷を分散します。
  18. ユーザーは3つのインスタンスを持つ ELB を作成しました。 ELB はデフォルトでいくつのセキュリティグループを作成しますか？
    1. 3
    2. 5
    3. 2 (1つは ELB がインスタンスのリスナとヘルスチェックポートへのインバウンドとアウトバウンドを許可し、もう1つはインスタンスがELBからのインバウンドを許可するためです)
    4. 1
  19. ステートレスですが、VPC 内の cc2 8xlarge EC2 インスタンス上で実行されるステートレスな CPU /メモリ集約型 Web 層を持つ Web スタイルのアプリケーションがあります。負荷がかかっているインスタンスが、ビジネスで定義された SLA 内の要求を返すときに問題が発生します。 その状態は DynamoDB テーブルにありますが、データ層は適切にプロビジョニングされており、応答は一貫して高速です。 SLAを 満たしていないアプリケーションの応答の問題を、どのようにして解決するのがベストでしょうか？
    1. 別の CC2.8xlarge アプリケーションインスタンスを追加し、両方を ELB の背後に配置する。
    2. CC2.8xlarge を DynamoDB テーブルと同じアベイラビリティーゾーンに移動します (応答時間とパフォーマンスは向上しません)。
    3. より迅速なアクセスのために elasticache でデータベース応答をキャッシュする (データ層が高速に応答している)。
    4. スケールアウト読み取り/レプリカ構成で DynamoDB から RDS MySQL にデータベースを移動する (データ層が高速に応答している)。
  20. 組織は、インターネットゲートウェイ (IGW) を持つ VPC を構成しています。パブリックおよびプライベートサブネットのペア (各 AZ ごとに1つのサブネットを持つ) と、パブリックサブネットを使用するように構成されたエラスティックロードバランサー (ELB)。アプリケーション Web 層は、ELB、自動スケーリング、およびマルチ AZ RDS データベースインスタンスを活用します。組織は、この設計で障害の潜在的な単一のポイントを排除したいと思います。この組織の目標を達成するために、どのようなステップを踏むべきでしょうか？
    1. 何も、このアーキテクチャでは単一の障害点はありません。
    2. 2番目の IGW を作成して接続し、冗長なインターネット接続を提供します。(VPC は 1 IGW のみ接続可能)
    3. 冗長ロードバランサーを提供するために、2つ目の ELB を作成して構成します。(ELB はそれで構成される複数の AZ とそれ自身によってスケールする)
    4. 別の AZ 2つ目のマルチ AZ RDS インスタンスを作成し、冗長データベースを提供するようにレプリケーションを構成します。(マルチ AZ は、セットアップのための2つの異なる AZ を必要とし、すでにスタンバイを持っている)
  21. アプリケーションは現在、AWS Auto スケーリングを活用して、負荷が増減するにつれて拡大/縮小し、パフォーマンスも向上しています。あなたのマーケティングチームは、トラフィックの着実なランプアップ4週間以上のトラフィックの20倍の成長につながる今後のキャンペーンに従うことを期待しています。ピークの需要を満たすために必要な Amazon EC2 インスタンスのおおよその数の予測は、175です。あなたは、トラフィックのランプアップ中に潜在的なサービスの中断を回避するために何をすべきか?
    1. 各サーバーが起動中に1つを取得できるように、事前に割り当てられた 175 Elastic IP アドレスがあることを確認します (max limit 5 eip およびサービスリクエストの送信が必要)。
    2. Trusted Advisor のサービス制限を確認し、必要に応じて調整して、予測数が制限内に収まるようにします。
    3. Auto スケーリングの設定を変更して、マーケティングキャンペーンを開始する前に175の容量を設定します (175 インスタンスの起動と実行が発生しますが、徐々にスケーリングされることはありません)
    4. ピーク要求時に予想される1秒あたりの要求に合わせて、エラスティックロードバランサーを事前にウォームアップ。
  22. ロードバランサーに登録されている複数のアベイラビリティーゾーンの Amazon EC2 インスタンスへのトラフィックの分散も、次のどの機能によって保証されますか？
    1. ELB リクエストルーティング
    2. Amazon Route53 加重ルーティングポリシー (EC2 インスタンスへのトラフィックを制御しません)
    3. ELB クロスゾーン負荷分散
    4. Amazon Route53 レイテンシルーティングポリシー (ec2 インスタンスへのトラフィックを制御しません)
  23. Web アプリケーションのフロントエンドは、エラスティックロードバランサーの背後にある複数の EC2 インスタンスで構成されます。インスタンスが正常性チェックに合格しなかった場合、これらの EC2 インスタンスでヘルスチェックを実行するように ELB を構成した場合、どのステートメントが True になりますか。
    1. インスタンスは ELB によって自動的に終了します (自動スケーリングによって行われます)。
    2. インスタンスは、根本原因分析のために ELB によって検疫されます。
    3. インスタンスは、ELB によって自動的に置き換えられます。(自動スケーリングによって行われます)
    4. ELB は、ヘルスチェックに失敗したインスタンスへのトラフィックの送信を停止します。
  24. Web アプリケーションは、6つの Amazon EC2 インスタンスで実行され、各インスタンスのリソースの約 45% を消費します。自動スケーリングを使用して、6つのインスタンスが常時実行されていることを確認します。このアプリケーションプロセスの要求の数は一貫しており、スパイクは発生しません。アプリケーションはビジネスにとって非常に重要であり、常に高可用性が求められます。すべてのインスタンス間で負荷を均等に分散する必要があります。また、すべてのインスタンスに同じ Amazon マシンイメージ (AMI) を使用することもできます。次のどちらのアーキテクチャを選択する必要がありますか？
    1. 1つのアベイラビリティーゾーンに6個の EC2 インスタンスをデプロイし、Amazon ELB を使用します。(シングル az は高可用性を提供しません)
    2. あるリージョンに3つの EC2 インスタンスをデプロイし、別のリージョンに3つ、Amazon ELB を使用します。(異なるリージョン AMI はコピーされない限り利用できません)
    3. 1つのアベイラビリティーゾーンに3個の EC2 インスタンスをデプロイし、別のアベイラビリティーゾーンに3つを配置し、Amazon エラスティックロードバランサーを使用します。
    4. 3つのリージョンに2つの EC2 インスタンスをデプロイし、Amazon エラスティックロードバランサーを使用します。(異なるリージョン、AMI はコピーされない限り利用できません)
  25. クライアント証明書認証を使用して Web サーバーで HTTPS クライアントを認証する必要がある SSL/TLS ソリューションを設計しています。ソリューションは、弾力性のある必要があります。Web サーバーインフラストラクチャの構成について、次のどちらのオプションを検討しますか。(2 つの回答を選択)
    1. TCP/443 で TCP リスナを使用して ELB を構成します。Web サーバーをその背後に配置します。(クライアント側の証明書を使用してインスタンスの SSL を終了する)
    2. EIP を使用して Web サーバーを構成します。Web サーバーを Route53 レコードセットに配置し、すべての Web サーバーに対してヘルスチェックを構成します。(ELB を削除し、Route53で直接 Web サーバを使用)
    3. HTTPS リスナを使用して ELB を構成し、Web サーバーをその背後に配置します。(HTTPS を使用した ELB はクライアント側の証明書をサポートしていません)**
    4. Web サーバーを CloudFront ディストリビューションのオリジンとして設定します。CloudFront ディストリビューションでカスタム SSL 証明書を使用する (CloudFront はクライアント側の SSL 証明書を提供しません)
  26. 保護された正常性情報を含むアプリケーションを設計しています。アプリケーションのすべての保護された正常性情報が、残りの部分および転送中に暗号化を使用することを申請のためのセキュリティおよびコンプライアンス要件。アプリケーションは、データがロードバランサーを通過する3層アーキテクチャを使用し、処理のために Amazon EBS ボリュームに格納され、結果は AWS SDK を使用して Amazon S3 に格納されます。セキュリティ要件を満たす次の2つのオプションを選択してください。2つの回答を選択。
    1. ロードバランサー、Amazon EC2 インスタンスでの Amazon EBS 暗号化、およびサーバー側の暗号化による Amazon S3 の SSL ターミネーションを使用します。(ELB と EC2 の間の接続は暗号化されません)
    2. ロードバランサーの SAN SSL 証明書、Amazon EBS のすべての Amazon EBS ボリュームを使用した Amazon EC2、および Amazon S3 を使用して、お客様が管理するキーでサーバー側の暗号化を行うことができます。
    3. ロードバランサーでの TCP 負荷分散、Amazon EC2 インスタンスでの SSL ターミネーション、Amaozn EBS ボリューム上の OS レベルのディスク暗号化、およびサーバー側の暗号化による Amazon S3 の使用。
    4. ロードバランサーでの TCP 負荷分散、Amazon EC2 インスタンスでの SSL の終了、およびサーバー側の暗号化による Amazon S3 の使用。(EBS 暗号化については言及しません)
    5. ロードバランサー、Amazon EC2 インスタンス上の SSL リスナ、PHI を含む EBS ボリューム上の Amazon EBS 暗号化、およびサーバー側の暗号化による Amazon S3 の SSL ターミネーションを使用します。
  27. スタートアップは、その写真共有サイトを VPC 内に展開します。ELB は、2つのサブネット間で Web トラフィックを分散します。ロードバランサーセッションのスティッキーは、AWS で生成されたセッション cookie を使用するように構成されており、セッション TTL は5分です。Web サーバーの自動スケーリンググループは、最小サイズ = 4、最大サイズ = 4 として構成されています。スタートアップは、us-west-2a で実行されている単一の Amazon エラスティックコンピューティングクラウド (EC2) インスタンスにインストールされているロードテストソフトウェアを実行することによって、パブリック起動の準備をしています。負荷テストの60分後、Web サーバーのログは次のように表示されます。ウェブサーバログ |ロードテスターからの HTTP リクエスト数 |プライベートベータユーザーからの HTTP リクエストの # | |ウェブサーバ # 1 (subnet in us-west-2a): |19210 |434 | |ウェブサーバ # 2 (subnet in us-west-2a): |21790 |490 | |ウェブサーバ # 3 (subnet in us-west-2b): |0 |410 | |ウェブサーバ # 4 (subnet in us-west-2b): |0 |428 |負荷テストの HTTP 要求が4つの web サーバーに均等に分散されるようにするための推奨事項はどれですか。2つの回答を選択
    1. 代わりに、ロードテスター Amazon EC2 インスタンスを起動して実行します。
    2. アプリケーション固有のセッション cookie を使用するように、ELB セッションのスティッキーを構成します。
    3. 各 Web 要求の DNS を再解決するために、ロードテストソフトウェアを再構成します。(リンク参照)
    4. ELB と Auto スケーリングを構成して、us-west-2a と us-west-2b をまたがって配布します。
    5. サードパーティのロードテストサービスを使用して、グローバルに分散されたテストクライアントを提供します。(リンク参照)
  28. 人気のある製品のための Web トラフィックを提供するあなたの最高財務責任者と IT ディレクターは、10 m1 を購入している。大規模なヘビー使用リザーブドインスタンス (RIS) は、2つのアベイラビリティーゾーンに均等に分散されます。Route53 は、トラフィックをエラスティックロードバランサー (ELB)数ヶ月後、製品はさらに普及して成長し、結果として、追加の容量を必要とする、あなたの会社は2つの c3.2xlarge 媒体の使用率の RIS を購入あなたの ELB と2つの c3.2xlarge インスタンスを登録し、すぐに ml の大規模なインスタンスがでていることを見つける容量の 100% と c3.2xlarge インスタンスは、最もコスト効率がよく、EC2 容量を最も効果的に使用するオプションが未使用の重要な容量を持っていますか?
    1. 各インスタンスタイプに別々の ELB を使用し、Route53 加重ラウンドロビンを使用して ELB に負荷を分散する
    2. オートスケーリンググループを構成し、ELB を使用して構成を起動し、Cloudwatch によってトリガされた場合に最大10個のオンデマンド mi の大規模なインスタンスを追加します。 c3.2xlarge インスタンスをシャットオフします (RI に支払う費用を増額します)
    3. EC2 m1 へのトラフィックをルーティングします。Route53 レイテンシベースのルーティングとヘルスチェックを使用して、大規模および c3.2xlarge インスタンスを直接 ELB (まだ容量を有効に使用しません)
    4. 2つの c3.2xlarge インスタンスで ELB を構成し、最大2つの追加の c3.2xlarge インスタンスに対してオンデマンドの Autoscailng グループを使用します。大規模なインスタンス (あなたはまだ 10 m1 のために支払うように、コストが増加します。)
  29. EC2 インスタンスで受信したヘッダーは、ELB を要求している間にクライアントが使用したポートを識別しますか？
    1. X-Forwarded-Prot
    2. X-Requested-Proto
    3. X-Forwarded-Port
    4. X-Requested-Port
  30. ユーザーは、同じリージョンの別々の AZ で実行されている2つのインスタンスで ELB を構成しましたか？次のうちどれに該当するのか？
    1. マルチ AZ インスタンスは HA に ELB を提供します (ELB は、トラフィックを正常なインスタンスにルーティングする HA を提供し、スケーラビリティを提供しません)
    2. マルチ AZ インスタンスは、単一の ELB では使用できません。
    3. マルチ AZ インスタンスは、ELB でスケーラビリティを提供します。
    4. ユーザーは ELB を使用して HA とスケーラビリティの両方を実現できます。
  31. ユーザーは、フロントエンド ELB の HTTPS プロトコルと、ELB のバックエンドリスナの SSL プロトコルを構成しています。ELB は何をしますか?
    1. これにより、構成を作成できますが、インスタンスは正常性チェックに合格しません。
    2. HTTPS で要求を受信し、SSL のバックエンドインスタンスに送信します。
    3. これは、この構成を作成することはできません (エラー “ロードバランサープロトコルは、アプリケーション層プロトコルですが、インスタンスプロトコルではありません。ロードバランサープロトコルとインスタンスプロトコルの両方が同じレイヤーにある必要があります。修正してください。
    4. これは、構成を作成することができますが、ELB は期待どおりに動作しません
  32. ELB は、5つのインスタンス間でトラフィックを迂回しています。インスタンスの1つは20分間だけ不健康だった。インスタンスが正常になる20分後に何が起こるか。
    1. ELB は、同じインスタンスにトラフィックを迂回することはありません。
    2. ELB は、同じインスタンスに自動的にトラフィックを送信しません。ただし、ユーザーは同じインスタンスへのトラフィックの送信を開始するように構成できます。
    3. ELB が正常なインスタンスにトラフィックの送信を開始する。
    4. ELB は、インスタンスが異常な場合に終了します。したがって、10分後にインスタンスを正常にすることはできません。
  33. ユーザーは AWS 上で Web サイトをホストし、ELB を使用して複数のインスタンスの負荷分散を行います。ユーザーアプリケーションには、cookie の管理はありません。ユーザーはどのようにして、リクエスタのセッションを特定のインスタンスにバインドできますか。
    1. IP アドレスをスティッキーの cookie にバインドする。
    2. ELB で設定するアプリケーションレベルで cookie を作成します。
    3. ELB とのセッション同期を使用する。
    4. 指定した期間の cookie を生成する ELB。
  34. ユーザーが Web サイトを構成し、ポート80の Apache web サーバーを使用して起動しました。ユーザーは、負荷分散のために EC2 インスタンスと ELB を使用しています。EC2 インスタンスが ELB からの要求のみを受け付けるようにするには、ユーザーは何をすべきでしょうか。
    1. EC2 セキュリティグループの ELB 静的 IP のポートを開きます。
    2. ELB ソースセキュリティグループへのアクセスを許可する EC2 のセキュリティグループを構成する。
    3. ELB ポートでのみリッスンするように EC2 インスタンスを構成します。
    4. ELB リスナへのアクセスのみを許可する EC2 のセキュリティグループを構成する。
  35. AWS エラスティックロードバランサーは、SSL ターミネーションをサポートします。
    1. 特定のアベイラビリティーゾーンのみ
    2. false
    3. 特定の AZ のみ
    4. すべての地域
  36. ユーザーは ELB で5つのインスタンスを起動しました。ユーザーは、6番目の EC2 インスタンスを ELB に追加する方法を教えてください。
    1. ユーザーは、その場で6番目のインスタンスを追加できます。
    2. ユーザーは ELB を停止し、6番目のインスタンスを追加する必要があります。
    3. ユーザーはインスタンスを追加し、ELB 設定ファイルを変更できます。
    4. ELB には、最大5つのインスタンスのみを持つことができます。

リファレンス

Elastic Load Balancer ドキュメント
ELB Best Practices
AWS Black Belt Online Seminar 2016 Elastic Load Balancing SlideShare / オンデマンドセミナー