助け合いフォーラム

AWS

AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 36486
問題を開く
あるゲーム会社では、複数のEC2インスタンスを用いてオンラインゲームのサーバを運営している。ユーザからのアクセスは、Route 53を用いた独自ドメインのURLで受け付けている。先日、一部のプレイヤーからゲームに接続できないという報告が寄せられた。会社の運用担当者は、これが一部のEC2インスタンスの一時的な問題によるものであることを確認した。同社では、インスタンスの障害発生時にはトラフィックを正常なサーバへ振り分けてサービスを継続できる、可用性の高いソリューションを探している。最も効果的な方法でこの要件を満たすためには、どのアプローチを採用すべきか。

正解

新たにALBを構成し、Route 53からALBにルーティングするように設定する。ALBのヘルスチェックの結果に基づいてトラフィックを適切なEC2インスタンスに振り分ける

解説

本設問では、EC2インスタンスに障害が発生した場合でもユーザからのトラフィックを正常なサーバに振り分け、サービスを継続稼働させることができる可用性の高いシステムを実現する方法について問われています。

ALB(Application Load Balancer)はAWSが提供する負荷分散サービスです。配下に持つターゲット(本設問ではEC2インスタンス)に対して、トラフィックを分散させることができます。
ALBには、各ターゲットが正常に動作しているか定期的に確認するヘルスチェックの機能があり、この結果に基づいて、正常なEC2インスタンスにのみ処理を振り分けることができます。
この機能を用いることで、一部のサーバに障害が発生した場合でも他の正常なサーバに自動的に処理が振り分けられ、ユーザにエラーが返されたりサービスが停止したりすることを抑制できます。

したがって正解は、
・新たにALBを構成し、Route 53からALBにルーティングするように設定する。ALBのヘルスチェックの結果に基づいてトラフィックを適切なEC2インスタンスに振り分ける
です。

その他の選択肢については、以下のとおりです。

・Route 53の加重ルーティングポリシーを使用し、全てのインスタンスに同じ割合の重みづけを行い、トラフィックを均等に振り分ける
加重ルーティングポリシーを使用することで、あらかじめ設定しておいた重みづけの割合に応じてトラフィックを分散させることができますが、これだけではインスタンスの状態に応じた動的な振り分けは行えないため、誤りです。

・CloudFrontを使用して、ユーザからのトラフィックをエッジサーバで受けつけコンテンツを高速で配信する
Amazon CloudFrontは、AWS上で動作する安全で高速なコンテンツ配信ネットワークです。CloudFrontを使用することで、ウェブサービスへのアクセス速度の向上は期待できますが、それだけでは負荷に応じたスケーリングや障害発生時の振り分けを行うことはできないため、誤りです。

・各EC2インスタンスのステータスをCloudWatchで監視し、異常を検出した場合に管理者に通知を送る
CloudWatchを用いてインスタンスの異常を監視・通知することはできますが、これだけでは自動的なトラフィックの振り分けは行えません。また、通知を受けた管理者が手動で次の対応を行うという方法では障害の復旧までに時間を要する可能性があるため、ALBを用いた自動的な振り分けの方が適切です。したがって、誤りです。

・Route 53のフェイルオーバールーティングポリシーを使用し、プライマリ/セカンダリの設定を行い、ヘルスチェックの結果プライマリのインスタンスが異常と判断された場合には、自動的にセカンダリのインスタンスにフェイルオーバーさせる
フェイルオーバールーティングポリシーは、1つのプライマリと1つのセカンダリの構成でフェイルオーバーを行うことを目的とした機能です。本設問のように複数インスタンスが稼働している状況における可用性の高い構成としては、ALBを用いた振り分けの方が適切です。したがって、誤りです。

参考

【負荷分散(ロードバランシング)】
サービスの利用者が増えてくると、単一のリソースでは全てのリクエストを処理しきれなくなり、結果としてレスポンスの遅延が起こります。このような場合、リクエストを処理するリソースを複数配置し、それらのリソースにリクエストの処理を分散することでレスポンスの遅延が発生しないようにできます。
このような仕組みを「負荷分散(ロードバランシング)」といいます。

【Elastic Load Balancing(ELB)】
Elastic Load Balancing(ELB)は、AWSが提供する負荷分散サービスです。マネージドサービスであり、ユーザーは負荷分散機能を利用する際にアプリケーションのインストールやバージョンアップなどを考慮する必要がありません。

ELB配下の負荷分散先リソースのことを「ターゲット」といい、一つのELB配下で管理されるターゲットの集合を「ターゲットグループ」といいます。ターゲットにはインスタンス、IPアドレス、Lambda関数を指定できます。ターゲットグループ単位で負荷分散を行い、適切なターゲットにリクエストがルーティングされるようになります。
ターゲットは、可用性を向上させるためにマルチAZ(複数のAZに配置する構成)にするのが一般的です。これにより一部のAZに障害が発生した場合でも、他のAZに配置されたターゲットで引き続きリクエストが処理されます。また、ELB自体もマルチAZ構成で動作するので、高い可用性と冗長性を確保できます。


【ELBの種類】
ELBにはロードバランシングの方式によって複数の種類があります。

■Application Load Balancer(ALB)
・レイヤー7(アプリケーション層)で負荷分散を行う
・HTTP、HTTPSをサポート
・WebSocketや、同一インスタンス内の複数ポートへの負荷分散、ホストベースやパスベース、URLクエリ文字列でのルーティングに対応するなど、高度なルーティング機能を提供する

WebSocketとは、ひとつのコネクション内で永続的にサーバー/クライアント双方からデータ送信できる技術です。通常のWebアプリケーションの場合、クライアントからのリクエストにサーバーがレスポンスを返して接続終了となりますが、WebSocketを使うと、一度接続したコネクションではクライアントからのリクエストがなくてもサーバー側からデータを送信できます。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)
・レイヤー4(トランスポート層)で負荷分散を行う
・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)
・レイヤー7(アプリケーション層)およびレイヤー4(トランスポート層)で負荷分散を行う
・HTTP、HTTPS、TCP、SSL/TLSをサポート
・ALBやNLBより古いサービスでパフォーマンスが劣るので、基本的にはALBやNLBの利用が推奨される

[ALB/NLB/CLBの比較表]


【ELBの機能】
ELBには負荷分散に関する様々な機能があります。下記では代表的な機能を紹介します。

■ELBのヘルスチェック
ELBはターゲットグループ内の各ターゲットが正常に動作しているかを定期的にヘルスチェックで確認します。ターゲットから正常に応答が返ってくれば、ELBはそのターゲットへのルーティングを継続します。もしターゲットが異常であると判断された場合は、ELBはそのターゲットへのルーティングを停止します。


ELBのヘルスチェックにはターゲットの復旧機能が含まれていないため、稼働するターゲット数を維持するにはAuto Scalingを用いて自動的に復旧する設計が必要です。

[ヘルスチェックの主な設定項目]


■アクセスログ
ELBに送信されるリクエストを記録しログをAmazon S3に保存します。記録されたログはトラフィックの分析やコンプライアンスの監査に利用できます。アクセスログには、クライアントのアクセス日時、接続元IPアドレス、ポート番号、ステータスコードなどクライアントの接続情報が記録されます。

■ELB自身のスケーリング
ELBにはリクエスト数の増減に応じてELB自身が自動的にスケーリングする機能があります。リクエスト数が増加したらELB自身を自動的にスケールアウト(追加)し、リクエスト数が減少したらスケールイン(削除)して元の状態に戻ります。

■リダイレクト
ALBには、ALBに送られてきたリクエストを別のURLにリダイレクトする機能があります。例えば、ユーザーから「http://www.example.com」(HTTP)へ送られたリクエストを「https://www.example.com」(HTTPS)に変換することで、セキュアな通信が可能になります。
HTTPのリクエストをHTTPSに変換するには、ALBでHTTPリスナーを作成し、HTTPSへリダイレクトするルールを設定します。下記の図は、HTTPリスナーのルール設定の例です。


【ELB経由の暗号化通信】
ELB経由でクライアントとターゲット間の通信を暗号化させるには、暗号化する通信の範囲とサーバー証明書(SSL/TLS証明書)の配置によって3つの方法があります。サーバー証明書とは、ユーザーとの通信をHTTPSで暗号化するとともに、ドメイン(ping-t.com など)の使用権を確認してアクセス先のサーバーが本物であるという証明する電子証明書のことです。ELB経由の暗号化通信に利用するサーバー証明書は、AWS Certificate Manager(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が対応しています。
上に戻る

正解の選択肢について

投稿日 2024/01/22

ALBはNW構成として「Route 53と各インスタンスの間」に配置するものでは無いと思うのですが、違うでしょうか。
「ユーザからのアクセスをALBで受けるよう構成し、ALBのヘルスチェックの結果に基づいてトラフィックを適切なEC2インスタンスに振り分ける」
などの表記のほうがより適切ではないかと思います。

スタッフからの返信

s staff_ishii

2024/01/23 16:34

wjavasparrow さん ご指摘の点を修正いたしました。 ご報告、誠にありがとうございました。

この投稿に対して返信しませんか?