助け合いフォーラム
AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 30430
問題を開く
あるWebシステムでは、有料会員の処理は優先して行い、無料会員は低優先で行うようにしたい。Amazon SQSを使って実装するとき、ソリューションアーキテクトが推奨するキューの構成はどれか。
正解
2つのキューを作成し、優先度ごとにキューを使い分ける。メッセージの受信側は優先度の高いキューを先に処理するようにする
解説
Amazon Simple Queue Service(SQS)において、優先度を分けてメッセージを処理したい場合は以下のようにします。
優先度の高いキューと低いキューの2つを用意し、メッセージを送信する側で優先度によってメッセージを投入するキューを使い分けます。メッセージの受信側は、先に優先度の高いキューにあるメッセージを処理し、完了後に優先度の低いキューを処理します。
なお、1つのキュー内のメッセージの優先度を変更することはできません。
本ケースの場合は優先度付けは2種類のため、2つのメッセージキューを作成する必要があります。
以上より正解は
・2つのキューを作成し、優先度ごとにキューを使い分ける。メッセージの受信側は優先度の高いキューを先に処理するようにする
です。
その他の選択肢については以下の通りです。
・1つのFIFOキューを作成し、有料会員からの処理は高い優先度のメッセージとして扱う
1つのキュー内のメッセージの優先度を変更することはできませんので誤りです。
・1つのFIFOキューと1つの標準キューを作成し、有料会員の処理はFIFOキューで、無料会員の処理は標準キューで処理する
キューの種類によって優先度を分けることはできませんので誤りです。
・1つの標準キューを作成し、無料会員のメッセージに対してメッセージタイマーを使用する。無料会員のメッセージは遅延して配信されるようにする
1つのキュー内のメッセージの優先度を変更することはできません。またメッセージタイマーは特定のメッセージの受信を遅らせたい場合に使用するものであり、優先度を決定する機能ではありませんので誤りです。
優先度の高いキューと低いキューの2つを用意し、メッセージを送信する側で優先度によってメッセージを投入するキューを使い分けます。メッセージの受信側は、先に優先度の高いキューにあるメッセージを処理し、完了後に優先度の低いキューを処理します。
なお、1つのキュー内のメッセージの優先度を変更することはできません。
本ケースの場合は優先度付けは2種類のため、2つのメッセージキューを作成する必要があります。
以上より正解は
・2つのキューを作成し、優先度ごとにキューを使い分ける。メッセージの受信側は優先度の高いキューを先に処理するようにする
です。
その他の選択肢については以下の通りです。
・1つのFIFOキューを作成し、有料会員からの処理は高い優先度のメッセージとして扱う
1つのキュー内のメッセージの優先度を変更することはできませんので誤りです。
・1つのFIFOキューと1つの標準キューを作成し、有料会員の処理はFIFOキューで、無料会員の処理は標準キューで処理する
キューの種類によって優先度を分けることはできませんので誤りです。
・1つの標準キューを作成し、無料会員のメッセージに対してメッセージタイマーを使用する。無料会員のメッセージは遅延して配信されるようにする
1つのキュー内のメッセージの優先度を変更することはできません。またメッセージタイマーは特定のメッセージの受信を遅らせたい場合に使用するものであり、優先度を決定する機能ではありませんので誤りです。
参考
【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)エラーになったメッセージを通常のキューから分離し、「デッドレターキュー」に配置します。デッドレターキュー上のメッセージは受信されませんので、エラーを繰り返すこともありません。
【SQSのアクセス制御】
Amazon SQSでは、キューに対してアクセスポリシー(リソースベースのポリシー)を設定することができます。SQSアクセスポリシーは、特定のSQSキューに対するアクセス権を定義し、他のAWSアカウントからのアクセスも制御することが可能です。適切なアクセスポリシーを設定することで、管理者はセキュアなメッセージキューの運用を実現できます。
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)エラーになったメッセージを通常のキューから分離し、「デッドレターキュー」に配置します。デッドレターキュー上のメッセージは受信されませんので、エラーを繰り返すこともありません。
【SQSのアクセス制御】
Amazon SQSでは、キューに対してアクセスポリシー(リソースベースのポリシー)を設定することができます。SQSアクセスポリシーは、特定のSQSキューに対するアクセス権を定義し、他のAWSアカウントからのアクセスも制御することが可能です。適切なアクセスポリシーを設定することで、管理者はセキュアなメッセージキューの運用を実現できます。
参考URL
回答の間違い
投稿日 2024/11/12
1つのFIFOキューと1つの標準キューを作成し、有料会員の処理はFIFOキューで、無料会員の処理は標準キューで処理する
上記の回答は、十分実現可能です。
FIFOキューに有料会員のデータ、標準キューに無料会員のデータを処理すれば、受信側はFIFOキューから優先して受信すればいいだけです。
2024/11/13 01:02
単なるコメントですみません。
設問に
ソリューションアーキテクトが推奨するキューの構成
という条件があったので気になったのですが
FIFOキューに有料会員のデータ、標準キューに無料会員のデータを処理すれば、受信側はFIFOキューから優先して受信すればいいだけです。
だと、リクエスト数によっては正答選択肢よりも高額(FIFOキューの方が同じリクエスト数で1.25〜1.45倍高い)になる点は気にしなくて良いでしょうか?(解説でも言及されていないので気にしないで良いのかもしれませんが)
https://aws.amazon.com/jp/sqs/pricing/
他の問題で「これでもできるがコスト的に不適切」みたいなのがあった気がしたので、そういう観点も気にした方が良いのかなと思いまして。
コメント
この投稿に対して返信しませんか?
t takizawat
2024/11/19 23:19
ありがとうございます。 コスト的な点は考慮していませんでした。 参考にさせていただきます。