助け合いフォーラム

AWS

AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 30670
問題を開く
ある企業はオンプレミスで多層構成のWebアプリケーションを運用している。アプリケーションのフロントエンドは静的コンテンツで構成されており、コンテンツ内のアンケートフォームにデータが入力されると、リクエストがアプリケーションへ送信される。AWSへ移行するにあたって、Webアプリケーションのデカップリングを実現した上で、スケーラブルなシステムにしたい。
次のうち最も適切なソリューションはどれか。

正解

フロントエンドにS3の静的Webサイトホスティングを使用する。アンケートフォームの入力データをAmazon API Gatewayへ送信し、SQSキューにリクエストを投入する。Auto Scalingグループに所属したEC2インスタンスでアプリケーションを実行し、SQSキューのメッセージ数に応じてスケーリングする

解説

S3の静的Webサイトホスティングは、バケットに保存している静的コンテンツをWebサイトとして公開できる機能です。静的Webサイトホスティングがサポートしているコンテンツには、JavaScriptなどクライアント側で実行されるスクリプトも含みます。

Amazon API Gatewayは、AWSサービスと連携するAPIの作成や管理ができる機能です。S3の静的Webサイトホスティングの入力フォームから受け取ったデータを、SQSのキューに投入するという橋渡しのような動作も可能です。

Amazon Simple Queue Service(SQS)はフルマネージドのメッセージキューイングサービスです。メッセージキューを利用すると、お互いのサービスがそれぞれの状況に関係なく(非同期で)処理を進行できるため、サービス間の結合度が低くなります。このように、システムを構成するサービスやコンポーネント間の結合度や依存度を低くし、独立性を高めることを「疎結合」または「デカップリング」といいます。


AWS Auto ScalingはAWSリソースを負荷状況や設定したスケジュールに従って、自動的にスケーリングする機能です。
スケーリングの発生条件のうち「動的スケーリング」は、CPUやネットワークなどのパフォーマンスの負荷状況に応じて、自動的にスケールアウト(リソースの増加)/スケールイン(リソースの削減)を実施します。

リクエストが急激に増加した場合、SQSとCloudWatch、Auto Scalingを連携することでサーバーを自動的にスケーリングできます。リクエストの増加によりSQSに滞留したメッセージ数がしきい値を超えたときにCloudWatchがアラートを上げ、Auto Scalingがサーバーを増やします。キューにメッセージがなくなり次第スケールインすることで、コストを抑えた運用が実現できます。

上記をまとめると図のような構成になります。


したがって正解は
・フロントエンドにS3の静的Webサイトホスティングを使用する。アンケートフォームの入力データをAmazon API Gatewayへ送信し、SQSキューにリクエストを投入する。Auto Scalingグループに所属したEC2インスタンスでアプリケーションを実行し、SQSキューのメッセージ数に応じてスケーリングする
です。

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

・フロントエンドにS3の静的Webサイトホスティングを使用し、アンケートフォームの入力データをS3バケットに保存する。Auto Scalingグループに所属したEC2インスタンスで、S3イベント通知をトリガーにアプリケーションを実行する
S3イベント通知は、S3バケットに発生したイベント(データの作成や削除など)をトリガーに通知を行う機能です。通知先はLambda関数、SNSトピック、SQSキュー、EventBridgeです。
EC2インスタンスにS3イベント通知を送信することはできないので、誤りです。

・フロントエンドにS3の静的Webサイトホスティングを使用する。アンケートフォームにデータが入力されるとSNSトピックにメッセージを登録する。AutoScalingに所属したEC2インスタンスが、SNSトピックのメッセージを購読してアプリケーションを実行する。SNSからの通知に応じてスケーリングする
SNSはプッシュ型のメッセージングサービスです。
SNSはアプリケーションのデカップリングに適していますが、SNSからAuto Scalingへ通知を出せないので、誤りです。

・フロントエンドに静的コンテンツ用のEC2インスタンスを配置する。アンケートフォームの入力データからSQSキューにリクエストを投入する。Auto Scalingグループに所属したアプリケーション用のEC2インスタンスで処理を実行し、SQSキューのメッセージ数に応じてスケーリングする
静的コンテンツ用のEC2インスタンスがスケーラブルではないので、誤りです。

参考

【Amazon Simple Queue Service(SQS)】
Amazon SQSはフルマネージドのメッセージキューイングサービスです。「メッセージキューイング」とは個々のサービスやシステムをメッセージを使用して連携する仕組みのことで、サービス同士の橋渡しを担います。Amazon SQSはプル型なので、受信側の都合の良いタイミングでSQSへポーリング(問い合わせ)を行って、メッセージを受け取ります。

サービスAはクライアントからのリクエストを受け、キュー(queue)と呼ばれる領域にリクエスト(メッセージ)を投入します。サービスBはキューからメッセージを取得し、処理します。

メッセージキューを利用すると、お互いのサービスがそれぞれの状況に関係なく(非同期で)処理を進行できるため、サービス間の結合度が低くなります。このように、システムを構成するサービスやコンポーネント間の結合度や依存度を低くし、独立性を高めることを「疎結合」または「デカップリング」といいます。
サービス間の結合度を低くすると以下のようなメリットがあります。
・関連するサービスの負荷や処理状況に引きずられずに自身の処理を進行できる
・関連するサービスで障害が発生した場合やアップデートなどの際に影響を受けずに済む
SQSはこのようにサービス同士を橋渡しする役割を持つAWSサービスです。

【SQSのユースケース】
SQSのユースケースには以下のようなものがあります:
○トラフィックの量が想定できないようなケース
例えばデータベースシステムに対して大量にリクエストを投入する場合、データベースシステム側が高負荷になりタイムアウトが発生する可能性があります。SQSを導入すると、データベースシステム側は負荷に応じてキューのメッセージを処理できるため、タイムアウトが発生しにくくなります。


○Auto Scalingによって運用負荷を軽減するケース
リクエストが急激に増加した場合、SQSとCloudWatch、Auto Scalingを連携することでサーバーを自動的にスケーリングできます。リクエストの増加によりSQSに滞留したメッセージ数がしきい値を超えたときにCloudWatchがアラートを上げ、Auto Scalingがサーバーを増やします。キューにメッセージがなくなり次第スケールインすることで、コストを抑えた運用が実現できます。

○優先順位を設定したいケース
SQSではキュー内のメッセージの優先度を変更することはできませんが、キューを使い分けることで処理の優先順位を操作します。
優先度の高いキューと低いキューの2つを用意し、メッセージを送信する側で優先度によってメッセージを投入するキューを使い分けます。メッセージの受信側は、先に優先度の高いキューにあるメッセージを処理し、完了後に優先度の低いキューを処理します。


【SQSの機能】
SQSではシステム間で円滑にメッセージのやり取りができるように様々な機能が実装されています。本項では以下の機能について解説します。
・標準キューとFIFOキュー
・ショートポーリングとロングポーリング
・遅延キューとメッセージタイマー
・可視性タイムアウト
・デッドレターキュー

■標準キューとFIFOキュー
SQSには2種類のキューがあります。キューの種類は作成時に選択し、作成後は変更できません。

・標準キュー
メッセージの処理順序は保証されず、送信された順番と異なることがあります。また、タイミングによっては同じメッセージが二度配信される可能性があります。メッセージの処理順序や、同じメッセージを受信した際の処理については、受信側で制御する必要があります。

・FIFOキュー
FIFO(First In First Out)とは「先入れ先出し」の意味で、送信された順番にキューに残っている最も古いものからメッセージを処理します。また、メッセージを二重に取得することもありません。

標準キューと比べてFIFOキューの方が機能的に優れている分、利用料金はFIFOキューの方が高く設定されています。また、1秒あたりの処理件数は標準キューが優れています。

■ショートポーリングとロングポーリング
キューからメッセージを取得する方式には「ショートポーリング」「ロングポーリング」の2種類があります。
※「ポーリング(polling)」… 機器などに対して、一定間隔で順番に問合せ(データの送信要求など)を行うこと
メッセージを取得する際、ショートポーリングではメッセージがあった場合はメッセージを返し、メッセージがない場合でも即座に「空である」というレスポンスを返します。
一方ロングポーリングでは、メッセージがあった場合はメッセージを返す点は同じですが、メッセージが空である場合は設定された時間(最大20秒)を待ちます。時間が経過してもメッセージを得られない場合は、「空」というレスポンスが返ります。
ショートポーリングの場合はSQSに対するAPIコールの数が増えやすく、コストが高くなる可能性があります。その場合、ロングポーリングを使用してAPIコール数を抑えることにより、コストを削減できる可能性があります。
AWSではロングポーリング方式の使用を推奨しています。

■遅延キューとメッセージタイマー
メッセージの送信者が送信したメッセージを指定時間経過後に受信させたい場合には、「遅延キュー(Delay Queue)」または「メッセージタイマー(Message Timer)」を使用します。
キューに投入されたメッセージは、指定された時間が経過した後に受信可能になります。
遅延キューはキュー全体に対して作用し、メッセージタイマーは特定のメッセージに対して作用します。

■可視性タイムアウト(Visibility Timeout)
キューのメッセージは、受信側が明示的に削除指示をしないと削除されません。SQSのメッセージを受信するクライアントが複数ある場合、タイミングによっては、メッセージが削除される前に複数のクライアントでメッセージを受信してしまうことがあります。
可視性タイムアウトはこれを防ぐために、一度クライアントがメッセージを受信した後、指定時間(デフォルト30秒)が経過するまでそのメッセージが他のクライアントからは見えないようにします。

なお、可視性タイムアウトはデフォルトで有効になっています。

■デッドレターキュー(Dead Letter Queue)
データやシステムの都合で必ず処理がエラーになるようなメッセージがあった場合、メッセージはキューに残り続けます。その場合キューにはメッセージが滞留し、受信側ではエラーになる処理をリトライし続けてしまいます。
SQSでは、一定の回数(1~1000)エラーになったメッセージを通常のキューから分離し、「デッドレターキュー」に配置します。デッドレターキュー上のメッセージは受信されませんので、エラーを繰り返すこともありません。

上に戻る

S3がスケーラブルな理由は?(問題ID:35742も同じ疑問あり)

公開日 2024/03/09

こちらの問題はともにS3とEC2インスタンスがスケーラブルではないので誤りとなっていますが
インターネットからのアクセスに対して、S3がスケーラブルかどうかというとちょっと違うように思います。
EC2のAutoscalingのほうがスケーラブルだと思います。
S3がスケーラブルと言っているのは、ストレージ容量だけですよね?

2024/03/11 23:22

インターネットからのアクセスに対して、S3がスケーラブルかどうかというとちょっと違うように思います。

この意図がよくわからないですが、S3はリクエスト数に応じて自動的にスケーリングされますよ。

https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/optimizing-performance.html

Amazon S3 は、高いリクエストレートに自動的にスケールされます。例えば、アプリケーションは、パーティショニングされた Amazon S3 プレフィックスごとに毎秒 3,500 回以上の PUT/COPY/POST/DELETE リクエストまたは 5,500 回以上の GET/HEAD リクエストを達成できます。


コメント

J Jun101

2024/03/16 17:13

そうだったんですね。知りませんでした。ありがとうございます。

この返信に対して
コメントを記入できます

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