Q50 — AWS SAP-C02 第1章

第 50/75 問 | ← 第1章

Q125. ある企業は、Amazon EC2インスタンスをAuto Scalingグループで使用してAWSクラウド上で動画を処理しています。1本の動画を処理するのに30分かかります。Amazon Simple Queue Service（Amazon SQS）キュー内の動画の数に応じて、複数のEC2インスタンスがスケールインおよびスケールアウトします。企業はSQSキューにリドライブポリシーを設定しており、ターゲットとしてデッドレターキューを指定し、maxReceiveCountを1に設定しています。また、SQSキューの可視性タイムアウトは1時間に設定されています。さらに、デッドレターキューにメッセージが存在した場合に開発チームに通知するよう、Amazon CloudWatchアラームが設定されています。 1日に何度か、開発チームはデッドレターキューにメッセージが存在し、動画が正しく処理されていないという通知を受け取ります。調査の結果、アプリケーションログにはエラーは見つかりませんでした。 この問題を解決するには、企業は何を行うべきでしょうか？

正解: C. 処理中のインスタンスに対してスケールイン保護を設定する

解説

動画処理には30分かかる一方、SQSの可視性タイムアウトは1時間に設定されています。しかし、maxReceiveCountが1に設定されているため、メッセージが1回受信された後、処理が完了する前に可視性タイムアウトが切れて再びキューに表示されると、そのメッセージは再び受信され、すぐにmaxReceiveCountに達してデッドレターキューへ移動します。これは、処理中のメッセージが正常に完了せずにデッドレターキューへ送られてしまう原因です。ただし、根本的な問題は「処理が完了する前にメッセージが再び可視状態になり、再受信・再処理が試みられるが、maxReceiveCount=1のため即座にデッドレターキューへ送られてしまう」点にあります。可視性タイムアウトを処理時間（30分）より十分に長く設定しておく必要がありますが、1時間は理論上十分です。しかし、実際にはネットワーク遅延や一時的な障害などにより、処理完了の削除（DeleteMessage）が失敗する可能性があり、その場合、可視性タイムアウト後にメッセージが再び可視となり、再受信されます。maxReceiveCount=1では、再受信＝即デッドレター送信となるため、処理が完了できなかった場合に必ずデッドレターキューへ流れてしまいます。したがって、maxReceiveCountを1より大きい値（例：3や5）に設定することで、一時的な失敗を許容し、再試行機会を与えるのが適切です。しかし、選択肢にはそのような値はなく、Dの「maxReceiveCountを0に設定」は無効な値であり、AWSでは許容されません（最小値は1）。Aはインスタンスの終了防止であり、メッセージ処理の保証とは無関係です。Cのスケールイン保護は、処理中のインスタンスが意図せず終了されるのを防ぎますが、メッセージの再受信・デッドレター化の直接の原因ではありません。Bは、可視性タイムアウトを3時間に延長することで、30分の処理時間を十分にカバーし、さらに余裕を持たせて再試行の猶予を確保できます。これにより、処理中に一時的に可視性タイムアウトが切れたとしても、再受信から再処理完了まで十分な時間が確保され、maxReceiveCount=1でも正常に処理を完了できる可能性が高まります。したがって、最も現実的かつ即効性のある解決策はBです。