助け合いフォーラム
AWS ソリューションアーキテクト - アソシエイト(SAA-C02)
問題ID : 29351
問題を開く
ELBの背後に2台のEC2インスタンスがWebサーバーとして稼働している。クライアントの接続先URLが「http://www.example.com/web?lang=jp」の場合はWebサーバー1に、「http://www.example.com/web?lang=en」の場合はWebサーバー2にアクセスさせるにはどうすればよいか。
正解
ALBでURLクエリ文字列でのルーティングを使用する
解説
ELBにはロードバランシングの方式によって複数の種類があります。
ELBのうちALBのみ、URLクエリ文字列でのルーティングに対応しています。
したがって正解は
・ALBでURLクエリ文字列でのルーティングを使用する
です。
URLクエリ文字列でのルーティングとは、クライアントがリクエストした接続先URLのクエリ文字列に従ってルーティングできる機能のことです。URLクエリ文字列とは、ブラウザがWebサーバーに送信するデータをURLに表記したものです。URLが「http://www.example.com/web?lang=jp」であれば「lang=jp」がURLクエリ文字列に該当します。
設問の例であれば、クライアントの接続先URLが「http://www.example.com/web?lang=jp」の場合は日本語サイトのあるWebサーバーにアクセスさせて、「http://www.example.com/web?lang=en」の場合は英語サイトのあるWebサーバーにアクセスさせることができます。
その他の選択肢については、以下のとおりです。
・NLBでURLクエリ文字列でのルーティングを使用する
URLクエリ文字列でのルーティングはALBのみ対応しているため、誤りです。
・ALBでパスベースのルーティングを使用する
パスベースのルーティングは、クライアントがリクエストした接続先URLのパスに従ってルーティングできる機能なので、誤りです。
・CLBでパスベースのルーティングを使用する
パスベースのルーティングは、クライアントがリクエストした接続先URLのパスに従ってルーティングできる機能なので、誤りです。
また、パスベースのルーティングはALBのみ対応しています。
ELBのうちALBのみ、URLクエリ文字列でのルーティングに対応しています。
したがって正解は
・ALBでURLクエリ文字列でのルーティングを使用する
です。
URLクエリ文字列でのルーティングとは、クライアントがリクエストした接続先URLのクエリ文字列に従ってルーティングできる機能のことです。URLクエリ文字列とは、ブラウザがWebサーバーに送信するデータをURLに表記したものです。URLが「http://www.example.com/web?lang=jp」であれば「lang=jp」がURLクエリ文字列に該当します。
設問の例であれば、クライアントの接続先URLが「http://www.example.com/web?lang=jp」の場合は日本語サイトのあるWebサーバーにアクセスさせて、「http://www.example.com/web?lang=en」の場合は英語サイトのあるWebサーバーにアクセスさせることができます。
その他の選択肢については、以下のとおりです。
・NLBでURLクエリ文字列でのルーティングを使用する
URLクエリ文字列でのルーティングはALBのみ対応しているため、誤りです。
・ALBでパスベースのルーティングを使用する
パスベースのルーティングは、クライアントがリクエストした接続先URLのパスに従ってルーティングできる機能なので、誤りです。
・CLBでパスベースのルーティングを使用する
パスベースのルーティングは、クライアントがリクエストした接続先URLのパスに従ってルーティングできる機能なので、誤りです。
また、パスベースのルーティングはALBのみ対応しています。
参考
【負荷分散(ロードバランシング)】
サービスの利用者が増えてくると、単一のリソースでは全てのリクエストを処理しきれなくなり、結果としてレスポンスの遅延が起こります。このような場合、リクエストを処理するリソースを複数配置し、それらのリソースにリクエストの処理を分散することでレスポンスの遅延が発生しないようにできます。
このような仕組みを「負荷分散(ロードバランシング)」といいます。
【Elastic Load Balancing(ELB)】
Elastic Load Balancing(ELB)は、AWSが提供する負荷分散サービスです。マネージドサービスであり、ユーザーは必要なアプリケーションのインストールやバージョンアップなどを考慮することなく、負荷分散機能を利用できます。
ELB配下の負荷分散先リソースのことを「ターゲット」といい、一つのELB配下で管理されるターゲットの集合を「ターゲットグループ」といいます。ターゲットにはEC2などのインスタンスや、IPアドレス、Lambda関数が指定でき、それらをまとめたターゲットグループ単位に負荷分散を行います。
なお、AZ障害時の影響を少なくするためにも、ターゲットはマルチAZ(複数のAZに配置する構成)にするのが一般的です。
[ELBの動作イメージ]
ELBはAWS Auto Scalingに対応しています。負荷の増減によって自動的にEC2などのインスタンスを追加(スケールアウト)したり、削除(スケールイン)したりできます。
【ELBの種類】
ELBにはロードバランシングの方式によって複数の種類があります。
■Application Load Balancer(ALB)
ALBはレイヤー7(アプリケーション層)で負荷分散を行います。
ALBではHTTP、HTTPSをサポートしています。また、WebSocketや、同一インスタンス内の複数ポートへの負荷分散、ホストベースやパスベース、URLクエリ文字列でのルーティングに対応しています。
WebSocketとは、ひとつのコネクション内で永続的にサーバー/クライアント双方からデータ送信できる技術です。通常のWebアプリケーションの場合、クライアントからのリクエストにサーバーがレスポンスを返して接続終了となりますが、WebSocketを使うと、一度接続したコネクションではクライアントからのリクエストがなくてもサーバー側からデータを送信できます。
チャットや株価情報のような、リアルタイムな情報提供を必要とするアプリケーションでよく使われます。
○ALBが対応している主なルーティング
・ホストベース
ホストベースのルーティングとは、クライアントがリクエストした接続先URLのFQDNに従ってルーティングできる機能のことです。例えば、クライアントの接続先URLが「http://www1.example.com」の場合はWebサーバー1にアクセスさせて、「http://www2.example.com」の場合はWebサーバー2にアクセスさせることができます。
・パスベース
パスベースのルーティングとは、クライアントがリクエストした接続先URLのパスに従ってルーティングできる機能のことです。例えば、クライアントの接続先URLが「http://www.example.com/web1/」の場合はWebサーバー1にアクセスさせて、「http://www.example.com/web2/」の場合はWebサーバー2にアクセスさせることができます。
・URLクエリ文字列
URLクエリ文字列でのルーティングとは、クライアントがリクエストした接続先URLのクエリ文字列に従ってルーティングできる機能のことです。URLクエリ文字列とは、ブラウザがWebサーバーに送信するデータをURLに表記したものです。URLが「http://www.example.com/web?lang=jp」であれば「lang=jp」がURLクエリ文字列に該当します。
例えば、クライアントの接続先URLが「http://www.example.com/web?lang=jp」の場合は日本語サイトのあるWebサーバーにアクセスさせて、「http://www.example.com/web?lang=en」の場合は英語サイトのあるWebサーバーにアクセスさせることができます。
■Network Load Balancer(NLB)
NLBはレイヤー4(トランスポート層)で負荷分散を行います。
NLBではTCP、UDP、TLSをサポートしています。また、WebSocketや、同一インスタンス内の複数ポートへの負荷分散に対応しています。
NLBはElasitc IPアドレス(固定のパブリックIPアドレス)と関連付けることができます。これによりクライアントからNLB配下のサーバーに、NLBに関連付けられたElastic IPアドレスでアクセスできるようになります。サーバーへのアクセスをドメイン名ではなくIPアドレスで行いたい場合や、クライアントのアクセス先をIPアドレスで管理・制限している環境などで有用です。
Elasitc IPアドレスと関連付けられるのはNLBのみですが、NLBのターゲットにALBを指定すると、クライアントからALB配下のサーバーにNLBのElastic IPアドレスでアクセスできるようになります。
■Classic Load Balancer(CLB)
CLBはレイヤー7(アプリケーション層)およびレイヤー4(トランスポート層)で負荷分散を行います。
CLBではHTTP、HTTPS、TCP、SSL/TLSをサポートしています。CLBはALBやNLBより古いサービスでパフォーマンスが劣るため、基本的にはALBやNLBの利用が推奨されています。
[ALB/NLB/CLBの比較表]
【ELBの機能】
ELBにはリクエストを複数のリソースへ振り分ける「負荷分散」の他にも、以下のような機能があります。
■ヘルスチェック
ターゲットグループ内の各ターゲットが正常に動作しているかを定期的に確認します。ターゲットから正常に応答が返ってくればELBからターゲットへの転送を行い、異常があればターゲットへの転送を停止します。ELBのヘルスチェックにはターゲットの復旧機能はないので、AWS Auto Scalingにて自動的に復旧させる設計が必要です。
[ヘルスチェックの主な設定項目]
■アクセスログ
ELBに送信されるリクエストを記録しログをAmazon S3に保存します。記録されたログはトラフィックの分析やコンプライアンスの監査に利用できます。アクセスログには、クライアントのアクセス日時、接続元IPアドレス、ポート番号、ステータスコードなどクライアントの接続情報が記録されます。
■ELB自身のスケーリング
ELBにはリクエスト数の増減に応じてELB自身が自動的にスケーリングする機能があります。リクエスト数が増加したらELB自身を自動的にスケールアウト(追加)し、リクエスト数が減少したらスケールイン(削除)して元の状態に戻ります。
【ELB経由の暗号化通信】
ELB経由でクライアントとターゲット間の通信を暗号化させるには、暗号化する通信の範囲とサーバー証明書の配置によって3つの方法があります。サーバー証明書とは、クライアントがアクセスしようとしているサーバーが安全であると証明し、クライアントとサーバー間の暗号化通信(SSL/TLS通信)を可能にする電子証明書のことです。
■クライアントとELB間の通信を暗号化する
○ELBにサーバー証明書を導入する
クライアントとELB間で通信を暗号化し、ELBとターゲット間は平文の通信(暗号化されていない通信)を行う方法です。クライアントとELB間での通信の暗号化・復号をELBが行うため、ターゲットに暗号化・復号による負荷が発生しません。すべてのELBが対応しています。
■クライアントとターゲット間の通信を暗号化する
○ELBとターゲットにサーバー証明書を導入する
クライアントとELB間、ELBとターゲット間で別の暗号化通信を行う方法です。暗号化接続はELBが終端となり、ELBから別の暗号化接続を確立して通信します。ELB、ターゲットに暗号化・復号による負荷がかかりますが、クライアントからターゲットまでの通信すべてを暗号化できます。ALB、CLBが対応しています。
○ターゲットにサーバー証明書を導入する
ELBでは暗号化・復号せず、直接クライアントとターゲット間で暗号化通信を行う方法です。ターゲットに暗号化・復号による負荷が発生しますが、ELBによる暗号化・復号の遅延を発生させずに通信全てを暗号できます。NLB、CLBが対応しています。
【SNIを利用したELB経由の暗号化通信】
通常のサーバー証明書は、一つのパブリックIPアドレスを持つサーバーに対して一つのドメイン名が紐づきます。例えば「example.com」と「example.co.jp」の2つのドメイン名を持つWebサーバーの場合、ドメイン名ごとに異なるパブリックIPアドレスを取得してサーバー証明書を導入する必要があります。しかしELBからドメイン名を複数持つWebサーバーへ通信を転送しようとすると、クライアントから見たWebサーバーのパブリックIPアドレスは窓口であるELBのパブリックIPアドレスしかないため、通常のサーバー証明書では対応できません。
SNI(Server Name Indication)は、暗号化通信で使用するサーバー証明書をパブリックIPアドレスではなくドメイン名によって判断する技術です。SNIに対応したELBに複数のサーバー証明書を導入すると、ELBが宛先ドメイン名から適切なサーバー証明書を判断してサーバーへ通信を転送します。SNIはALBとNLBが対応しています。
サービスの利用者が増えてくると、単一のリソースでは全てのリクエストを処理しきれなくなり、結果としてレスポンスの遅延が起こります。このような場合、リクエストを処理するリソースを複数配置し、それらのリソースにリクエストの処理を分散することでレスポンスの遅延が発生しないようにできます。
このような仕組みを「負荷分散(ロードバランシング)」といいます。
【Elastic Load Balancing(ELB)】
Elastic Load Balancing(ELB)は、AWSが提供する負荷分散サービスです。マネージドサービスであり、ユーザーは必要なアプリケーションのインストールやバージョンアップなどを考慮することなく、負荷分散機能を利用できます。
ELB配下の負荷分散先リソースのことを「ターゲット」といい、一つのELB配下で管理されるターゲットの集合を「ターゲットグループ」といいます。ターゲットにはEC2などのインスタンスや、IPアドレス、Lambda関数が指定でき、それらをまとめたターゲットグループ単位に負荷分散を行います。
なお、AZ障害時の影響を少なくするためにも、ターゲットはマルチAZ(複数のAZに配置する構成)にするのが一般的です。
[ELBの動作イメージ]
ELBはAWS Auto Scalingに対応しています。負荷の増減によって自動的にEC2などのインスタンスを追加(スケールアウト)したり、削除(スケールイン)したりできます。
【ELBの種類】
ELBにはロードバランシングの方式によって複数の種類があります。
■Application Load Balancer(ALB)
ALBはレイヤー7(アプリケーション層)で負荷分散を行います。
ALBではHTTP、HTTPSをサポートしています。また、WebSocketや、同一インスタンス内の複数ポートへの負荷分散、ホストベースやパスベース、URLクエリ文字列でのルーティングに対応しています。
WebSocketとは、ひとつのコネクション内で永続的にサーバー/クライアント双方からデータ送信できる技術です。通常のWebアプリケーションの場合、クライアントからのリクエストにサーバーがレスポンスを返して接続終了となりますが、WebSocketを使うと、一度接続したコネクションではクライアントからのリクエストがなくてもサーバー側からデータを送信できます。
チャットや株価情報のような、リアルタイムな情報提供を必要とするアプリケーションでよく使われます。
○ALBが対応している主なルーティング
・ホストベース
ホストベースのルーティングとは、クライアントがリクエストした接続先URLのFQDNに従ってルーティングできる機能のことです。例えば、クライアントの接続先URLが「http://www1.example.com」の場合はWebサーバー1にアクセスさせて、「http://www2.example.com」の場合はWebサーバー2にアクセスさせることができます。
・パスベース
パスベースのルーティングとは、クライアントがリクエストした接続先URLのパスに従ってルーティングできる機能のことです。例えば、クライアントの接続先URLが「http://www.example.com/web1/」の場合はWebサーバー1にアクセスさせて、「http://www.example.com/web2/」の場合はWebサーバー2にアクセスさせることができます。
・URLクエリ文字列
URLクエリ文字列でのルーティングとは、クライアントがリクエストした接続先URLのクエリ文字列に従ってルーティングできる機能のことです。URLクエリ文字列とは、ブラウザがWebサーバーに送信するデータをURLに表記したものです。URLが「http://www.example.com/web?lang=jp」であれば「lang=jp」がURLクエリ文字列に該当します。
例えば、クライアントの接続先URLが「http://www.example.com/web?lang=jp」の場合は日本語サイトのあるWebサーバーにアクセスさせて、「http://www.example.com/web?lang=en」の場合は英語サイトのあるWebサーバーにアクセスさせることができます。
■Network Load Balancer(NLB)
NLBはレイヤー4(トランスポート層)で負荷分散を行います。
NLBではTCP、UDP、TLSをサポートしています。また、WebSocketや、同一インスタンス内の複数ポートへの負荷分散に対応しています。
NLBはElasitc IPアドレス(固定のパブリックIPアドレス)と関連付けることができます。これによりクライアントからNLB配下のサーバーに、NLBに関連付けられたElastic IPアドレスでアクセスできるようになります。サーバーへのアクセスをドメイン名ではなくIPアドレスで行いたい場合や、クライアントのアクセス先をIPアドレスで管理・制限している環境などで有用です。
Elasitc IPアドレスと関連付けられるのはNLBのみですが、NLBのターゲットにALBを指定すると、クライアントからALB配下のサーバーにNLBのElastic IPアドレスでアクセスできるようになります。
■Classic Load Balancer(CLB)
CLBはレイヤー7(アプリケーション層)およびレイヤー4(トランスポート層)で負荷分散を行います。
CLBではHTTP、HTTPS、TCP、SSL/TLSをサポートしています。CLBはALBやNLBより古いサービスでパフォーマンスが劣るため、基本的にはALBやNLBの利用が推奨されています。
[ALB/NLB/CLBの比較表]
【ELBの機能】
ELBにはリクエストを複数のリソースへ振り分ける「負荷分散」の他にも、以下のような機能があります。
■ヘルスチェック
ターゲットグループ内の各ターゲットが正常に動作しているかを定期的に確認します。ターゲットから正常に応答が返ってくればELBからターゲットへの転送を行い、異常があればターゲットへの転送を停止します。ELBのヘルスチェックにはターゲットの復旧機能はないので、AWS Auto Scalingにて自動的に復旧させる設計が必要です。
[ヘルスチェックの主な設定項目]
■アクセスログ
ELBに送信されるリクエストを記録しログをAmazon S3に保存します。記録されたログはトラフィックの分析やコンプライアンスの監査に利用できます。アクセスログには、クライアントのアクセス日時、接続元IPアドレス、ポート番号、ステータスコードなどクライアントの接続情報が記録されます。
■ELB自身のスケーリング
ELBにはリクエスト数の増減に応じてELB自身が自動的にスケーリングする機能があります。リクエスト数が増加したらELB自身を自動的にスケールアウト(追加)し、リクエスト数が減少したらスケールイン(削除)して元の状態に戻ります。
【ELB経由の暗号化通信】
ELB経由でクライアントとターゲット間の通信を暗号化させるには、暗号化する通信の範囲とサーバー証明書の配置によって3つの方法があります。サーバー証明書とは、クライアントがアクセスしようとしているサーバーが安全であると証明し、クライアントとサーバー間の暗号化通信(SSL/TLS通信)を可能にする電子証明書のことです。
■クライアントとELB間の通信を暗号化する
○ELBにサーバー証明書を導入する
クライアントとELB間で通信を暗号化し、ELBとターゲット間は平文の通信(暗号化されていない通信)を行う方法です。クライアントとELB間での通信の暗号化・復号をELBが行うため、ターゲットに暗号化・復号による負荷が発生しません。すべてのELBが対応しています。
■クライアントとターゲット間の通信を暗号化する
○ELBとターゲットにサーバー証明書を導入する
クライアントとELB間、ELBとターゲット間で別の暗号化通信を行う方法です。暗号化接続はELBが終端となり、ELBから別の暗号化接続を確立して通信します。ELB、ターゲットに暗号化・復号による負荷がかかりますが、クライアントからターゲットまでの通信すべてを暗号化できます。ALB、CLBが対応しています。
○ターゲットにサーバー証明書を導入する
ELBでは暗号化・復号せず、直接クライアントとターゲット間で暗号化通信を行う方法です。ターゲットに暗号化・復号による負荷が発生しますが、ELBによる暗号化・復号の遅延を発生させずに通信全てを暗号できます。NLB、CLBが対応しています。
【SNIを利用したELB経由の暗号化通信】
通常のサーバー証明書は、一つのパブリックIPアドレスを持つサーバーに対して一つのドメイン名が紐づきます。例えば「example.com」と「example.co.jp」の2つのドメイン名を持つWebサーバーの場合、ドメイン名ごとに異なるパブリックIPアドレスを取得してサーバー証明書を導入する必要があります。しかしELBからドメイン名を複数持つWebサーバーへ通信を転送しようとすると、クライアントから見たWebサーバーのパブリックIPアドレスは窓口であるELBのパブリックIPアドレスしかないため、通常のサーバー証明書では対応できません。
SNI(Server Name Indication)は、暗号化通信で使用するサーバー証明書をパブリックIPアドレスではなくドメイン名によって判断する技術です。SNIに対応したELBに複数のサーバー証明書を導入すると、ELBが宛先ドメイン名から適切なサーバー証明書を判断してサーバーへ通信を転送します。SNIはALBとNLBが対応しています。
URLクエリ文字列に「?」は含まれるか
投稿日 2022/08/05
「解説」および「参考」にて
URLが「http://www.example.com/web?lang=jp」であれば「?lang=jp」がURLクエリ文字列に該当します。
とありますが、この場合のURLクエリ文字列は「?」を含まない「lang=jp」ではないでしょうか。
エビデンスとしては、Wikipediaしか示せず恐縮ですが、
https://en.wikipedia.org/wiki/Query_string
では「https://example.com/over/there?name=ferret」に対し「passing the query string, which in this case is name=ferret,」とあります。
また、環境によるかもしれませんが手元のCGI において環境変数QUERY_STRING に「?」は含まれていませんでした。
2022/08/09 02:21
対応ありがとうございます。
ただ、「解説」の部分は対応されましたが、「参考」の部分にも同様の記述がありまして、そちらも対応いただければ幸いです。
コメント
スタッフからの返信
この投稿に対して返信しませんか?
s staff_satomi
2022/08/08 11:05
tnishita2様 ご指摘の点を修正いたしました。 ご報告下さり、誠にありがとうございます。