助け合いフォーラム
AWS ソリューションアーキテクト - アソシエイト(SAA-C02)
問題ID : 29354
問題を開く
ある企業は、オンプレミス上の複数台のサーバーで構築されたオンラインモバイルゲームを公開した。ユーザーはUDP接続でサーバーの固定IPアドレスへアクセスする。公開後1か月が経ってゲームユーザーが想定よりも増加したため、サーバーの台数を増やしたい。なお、この企業はオンプレミスとAWSを接続するAWS Site-to-Site VPNを契約している。
可用性の高いシステムのために、ソリューションアーキテクトはどのような提案をすべきか。
可用性の高いシステムのために、ソリューションアーキテクトはどのような提案をすべきか。
正解
NLBを配置し、NLBのターゲットにオンプレミスのサーバーのIPアドレスを指定する
解説
NLBはレイヤー4(トランスポート層)で負荷分散を行い、TCP、UDP、TLSをサポートしています。NLBのターゲットにオンプレミスのサーバーのIPアドレスを指定することで、クライアントからNLBに接続し、AWS VPNを経由してオンプレミス上のサーバーに負荷分散できます。また、NLBはElastic IPアドレスを割り当てられるので、ユーザーはNLBの固定IPアドレスへアクセスします。
NLBはターゲットグループ内の各ターゲットが正常に動作しているかを定期的に確認します。ターゲットから正常に応答が返ってくればNLBからリクエストをターゲットへ転送し、異常があれば転送を停止します。複数台のサーバーをターゲットグループに登録することにより、1台のサーバーに障害が発生しても、他の正常なサーバーへリクエストが転送されるので、システムの可用性が高くなります。
したがって正解は
・NLBを配置し、NLBのターゲットにオンプレミスのサーバーのIPアドレスを指定する
です。
[ALB/NLB/CLBの比較表]
その他の選択肢については、以下のとおりです。
・ALBを配置し、ALBのターゲットにオンプレミスのサーバーのIPアドレスを指定する
ALBはUDPをサポートしていないので、誤りです。
・Auto Scalingグループにオンプレミスのサーバーを登録する
AWS Auto Scalingは、AWSリソースを負荷状況や設定したスケジュールに従って自動的にスケーリングする機能です。
Auto Scalingグループにオンプレミスのサーバーを登録することはできないので、誤りです。
・AWS Global Acceleratorを配置して、エンドポイントにオンプレミスのサーバーを登録する
Global Acceleratorは、ユーザーからAWSリソースまでのアクセス経路をAWSネットワークを利用して最適化するサービスです。
エンドポイントにオンプレミスのサーバーを登録することはできないので、誤りです。
NLBはターゲットグループ内の各ターゲットが正常に動作しているかを定期的に確認します。ターゲットから正常に応答が返ってくればNLBからリクエストをターゲットへ転送し、異常があれば転送を停止します。複数台のサーバーをターゲットグループに登録することにより、1台のサーバーに障害が発生しても、他の正常なサーバーへリクエストが転送されるので、システムの可用性が高くなります。
したがって正解は
・NLBを配置し、NLBのターゲットにオンプレミスのサーバーのIPアドレスを指定する
です。
[ALB/NLB/CLBの比較表]
その他の選択肢については、以下のとおりです。
・ALBを配置し、ALBのターゲットにオンプレミスのサーバーのIPアドレスを指定する
ALBはUDPをサポートしていないので、誤りです。
・Auto Scalingグループにオンプレミスのサーバーを登録する
AWS Auto Scalingは、AWSリソースを負荷状況や設定したスケジュールに従って自動的にスケーリングする機能です。
Auto Scalingグループにオンプレミスのサーバーを登録することはできないので、誤りです。
・AWS Global Acceleratorを配置して、エンドポイントにオンプレミスのサーバーを登録する
Global Acceleratorは、ユーザーからAWSリソースまでのアクセス経路をAWSネットワークを利用して最適化するサービスです。
エンドポイントにオンプレミスのサーバーを登録することはできないので、誤りです。
参考
【負荷分散(ロードバランシング)】
サービスの利用者が増えてくると、単一のリソースでは全てのリクエストを処理しきれなくなり、結果としてレスポンスの遅延が起こります。このような場合、リクエストを処理するリソースを複数配置し、それらのリソースにリクエストの処理を分散することでレスポンスの遅延が発生しないようにできます。
このような仕組みを「負荷分散(ロードバランシング)」といいます。
【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が対応しています。
UCPでなくUDP?
r
reishis
投稿日 2022/06/02
・ALBを配置し、ALBのターゲットにオンプレミスのサーバーのIPアドレスを指定する
ALBはUCPをサポートしていないので、誤りです。
上記解説でUCPとなっていますが、UDPではないでしょうか?
スタッフからの返信
この投稿に対して返信しませんか?
s staff_satomi
2022/06/02 13:22
reishis様 ご指摘の点を修正致しました。 ご報告、誠にありがとうございます。