Q1 — 単一選択画像アップロードサービスでは通常500件/秒の要求を処理しているが、イベント開始直後だけ5,000件/秒まで増加する。
画像変換処理は非同期でよく、ワーカーは継続的に1,000件/秒を処理できる。ピークのためだけに常時最大数のワーカーを起動したくない。
最も適切な設計はどれか。
A. キューを置かず、リクエスト数を基準にAmazon EC2 Auto Scalingでワーカーを一時的に大幅増加させ、流入した処理をその場で処理する
B. Amazon ElastiCacheのリスト構造へ処理要求を一時保存し、アプリケーション側で処理待ち・再取得・削除を管理する
C. Amazon SQSを送信側と処理側の間に配置し、急増した要求をキューへ蓄積して処理側が対応可能な速度で取り出す
D. Amazon SQSを配置するが、スパイクに備えてワーカーも常時5,000件/秒を処理できる最大構成で維持する
答えと解説
答え：C
Aはピーク時だけワーカーを増やせるため常時最大構成より効率的ですが、到着した処理量をその場で吸収できるだけの急速なスケールと下流処理能力が必要です。Bも一時保存は可能ですが、処理待ちメッセージの受け渡しを目的としたマネージドキューではなく、アプリケーション側でキュー動作を実装する必要があります。DはSQSでバッファリングできますが、
ピークのためだけに
常時最大数のワーカーを起動したくない
という条件を満たしません。決定条件は、
一時的なトラフィックスパイク
+
非同期処理可能
+
ピーク時の処理能力を常時維持したくない
です。
Q2 — 単一選択Amazon SQSを送信側と処理側の間に配置している。送信側は平均2,000件/秒でメッセージを送信し、処理側群は最大1,500件/秒しか処理できない。この状態が数時間継続し、バックログと最古メッセージの経過時間が増え続けている。下流システムには2,500件/秒まで安全に処理できる余裕がある。最も適切な性能改善はどれか。
A. 処理側の実効スループットを少なくとも2,000件/秒以上へ増やし、長期平均の処理能力が到着量を下回る状態を解消する
B. SQSのメッセージ保持期間だけを延長し、処理側の1,500件/秒という能力は変更しない
C. SQSキューを2つへ分割するが、処理側全体の実効スループットは1,500件/秒のままにする
D. バックログが増えていてもメッセージを保持できるため、処理側の能力は変更しない
答えと解説
答え：A
キューは一時的な速度差を吸収できますが、数時間にわたり 到着量 2,000件/秒 > 処理能力 1,500件/秒 が続けばバックログは増え続けます。このケースでは下流に余裕があるため、まず処理側の実効スループットを長期平均の到着量以上へ引き上げ、恒常的な処理能力不足を解消します。
Q3 — 単一選択Amazon SQSをバッファとして使用しているシステムで、処理側がトラフィックスパイクへ追いついているかを確認したい。
未処理量だけでなく、処理待ち時間が長くなっていないかも把握したい。
最も適切な監視方法はどれか。
A. NumberOfMessagesSentとNumberOfMessagesReceivedを監視し、送信数と受信数が近ければキュー内の待ち時間も短いと判断する
B. ApproximateNumberOfMessagesNotVisibleだけを監視し、処理中メッセージ数が増えていれば未処理バックログも減少していると判断する
C. ApproximateNumberOfMessagesVisibleだけを監視し、メッセージごとの待ち時間は確認せず件数だけで性能目標を判定する
D. ApproximateNumberOfMessagesVisibleとApproximateAgeOfOldestMessageを監視し、未処理件数と待ち時間の増加を確認する
答えと解説
答え：D
ApproximateNumberOfMessagesVisible
→ 未処理バックログ
ApproximateAgeOfOldestMessage
→ 最古メッセージの経過時間
を組み合わせることで、件数だけでなく待ち時間の悪化も確認できます。
Q4 — 単一選択Amazon SQSを20台のEC2ワーカーで処理している。
1件のメッセージ処理には平均0.2秒かかり、業務上許容できるキュー待ち時間は20秒である。
インスタンスあたりの許容バックログとして最も適切な値はどれか。
A. 1,000メッセージ/インスタンス。許容レイテンシーと処理時間は計算へ含めない
B. 100メッセージ/インスタンス。20秒 ÷ 0.2秒で許容バックログを求める
C. 20メッセージ/インスタンス。許容レイテンシーの秒数をそのまま使用する
D. 5メッセージ/インスタンス。0.2秒の逆数だけを使用する
答えと解説
答え：B
許容待ち時間
÷
平均処理時間
20
÷
0.2
=
100
なので、100メッセージ/インスタンスが基準になります。これを現在の、
ApproximateNumberOfMessagesVisible
÷
InServiceインスタンス数
と比較してスケーリングを判断できます。
Q5 — 単一選択SQSキュー内のメッセージ件数は時間帯によって大きく変動する。
性能目標として「最も長く待っているメッセージでも60秒以内に処理したい」という条件がある。
この目標に最も直接対応するCloudWatchメトリクスはどれか。
A. NumberOfMessagesSent。送信されたメッセージ総数だけで最古メッセージの待ち時間を直接測定できる
B. ApproximateNumberOfMessagesNotVisible。処理中メッセージ数だけでキュー内の最長待ち時間を直接表す
C. ApproximateAgeOfOldestMessage。キュー内で最も古い未処理メッセージの経過時間を追跡する
D. NumberOfEmptyReceives。空の受信回数から最古メッセージの経過時間を直接算出する
答えと解説
答え：C
この要件は、
何件待っているか
より、
最も古い要求が
どれだけ待っているか
が決定条件です。したがってApproximateAgeOfOldestMessageを評価します。
Q6 — 単一選択Amazon SQSからAWS Lambdaでメッセージを処理し、その後Amazon RDSへ書き込んでいる。
トラフィックスパイク時にLambdaが急速にスケールすると、RDSが安全に処理できる同時実行数を超える可能性がある。
最も適切な設計はどれか。
A. RDSが安全に処理できる並列度を基準にSQSイベントソースの最大同時実行数を設定し、余った要求はSQSへ一時的に滞留させる
B. SQSのバックログ件数だけを基準にLambdaの最大同時実行数を引き上げ、RDSの同時接続上限はスケーリング条件へ含めない
C. Lambdaのバッチサイズを大きくして1回の起動で処理するメッセージ数を増やすが、同時実行数には上限を設けない
D. Lambdaの予約済み同時実行数を十分大きく設定し、RDSが処理上限を超えた場合は再試行によって吸収する
答えと解説
答え：A
BとCはキュー処理能力を上げる方向ですが、RDSが安全に処理できる同時実行数を考慮していません。DはLambda側の実行余力を確保できますが、RDSの処理上限を超えてから再試行へ任せる設計になります。このシナリオでは、
キューを最速で空にする
ことより、
RDSが安全に処理できる並列度
を上限として処理側を制御し、余剰要求をSQSで待たせることが重要です。
Q7 — 単一選択EC2ワーカー群がAmazon SQSを処理している。
処理の多くは外部API待ちで、CPU使用率は30%程度だが、SQSのバックログとApproximateAgeOfOldestMessageは増え続けている。
処理側のスケーリング判断として最も適切なのはどれか。
A. CPU使用率を引き続き主要指標とするが、目標CPU使用率を現在より低く設定してスケールアウトしやすくする
B. ApproximateNumberOfMessagesVisibleのキュー全体件数だけをしきい値にし、稼働ワーカー数に関係なく同じ件数でスケールする
C. ApproximateAgeOfOldestMessageだけを使用し、ワーカー1台あたりが抱えている未処理仕事量は評価しない
D. SQSバックログを稼働中ワーカー数で割ったインスタンスあたりバックログを使い、許容待ち時間から目標値を決める
答えと解説
答え：D
AはCPUを低い目標値へ変更することでスケールアウトしやすくできますが、I/O待ち中心の処理ではCPU使用率と実際の未処理仕事量が一致しない可能性があります。Bはバックログを直接見られますが、同じ10,000件でも、
ワーカー10台
と
ワーカー100台
では1台あたりの負荷が異なります。Cは待ち時間の性能目標を直接確認できますが、処理側台数に応じた目標追跡を行う指標としては、インスタンスあたりバックログの方が処理能力へ結び付けやすくなります。このケースでは、
未処理仕事量
÷
処理側数
を性能目標へ結び付ける方法が最も適しています。
Q8 — 単一選択一時的なトラフィックスパイクが終了した時点で、Amazon SQSに20万件のバックログが残っている。
その後の送信側は500件/秒、処理側群は1,500件/秒を処理できる。
処理速度が一定だとすると、バックログを解消するまでのおおよその時間はどれか。
A. 100秒。キューへ新しいメッセージが到着していても、処理能力1,500件/秒をすべて既存バックログに使えるため
B. 200秒。スパイク後は毎秒1,000件ずつバックログを減らせるため、20万件を処理するには200秒かかる
C. 400秒。処理能力1,500件/秒と到着率500件/秒を加算し、毎秒2,000件として逆算するため
D. 600秒。スパイク後の到着率500件/秒だけで既存バックログを処理すると考えるため
答えと解説
答え：B
バックログを実際に減らせる速度は、
処理側の処理能力
-
送信側の到着速度
1,500
-
500
=
1,000件 / 秒
です。したがって、
200,000
÷
1,000
=
200秒
となります。
Q9 — 単一選択Amazon SQSの処理側はすでに最大までスケールしている。送信側から2,000件/秒の要求が継続して到着する一方、後段のAmazon RDSは安全に1,200件/秒までしか処理できず、これ以上コンシューマーを増やすと接続数と書き込みレイテンシーが急増する。ApproximateAgeOfOldestMessageも業務上限を超えた。バックプレッシャーとして最も適切な判断はどれか。
A. キューの保持期間だけを延長し、送信側2,000件/秒を無制限に受け付け続ける
B. コンシューマーをさらに増やし、RDSの安全な処理能力を超えてもキューを最短時間で空にする
C. 送信側でレート制限や受付制御を行い、後段が安全に処理できる速度を超える流入を抑えながらバックログを解消する
D. SQSキューを複数へ分割すればRDSの安全な処理能力も自動的に増えるため、送信側は変更しない
答えと解説
答え：C
このケースでは処理側を増やす余地ではなく、後段RDSの安全な処理能力が上限です。バックプレッシャーでは、後段が処理できない速度で前段から要求を流し続けないよう、レート制限や受付制御を使って流入を抑えます。キュー容量や保持期間を増やしても、下流の処理上限そのものは変わりません。