SQSによる疎結合のシナリオ判断

この単元で学ぶこと

• 受付と完了を分けた非同期構成を判断する
• 再試行と重複処理の原因に対応する
• 待ち時間と障害隔離を設計する

本文解説

1. 受付を止めない設計 動画変換に数分かかるサービスでは、アップロード後に変換ジョブをキューへ登録し、受付番号を返せます。ワーカーが後から変換して状態を更新します。利用者は受付番号で進捗を照会します。受付応答を早くすることと、変換完了までの時間を短くすることは別の改善です。

2. ワーカー停止時の動作 ワーカーがメンテナンスで停止していても、SQSが受理した仕事は保持期間内で待機できます。ただし依頼が無制限に待てるわけではありません。保持期限、利用者へ約束した完了期限、再開後の消化速度を照合し、受付制限や遅延通知を必要に応じて設計します。

3. 二重変換の切り分け 通常5分の処理へ不可視期間1分を設定すると、最初のワーカーが処理中でも再受信の対象になります。処理時間を測り不可視期間や延長方法を調整します。ただし設定を長くするだけで重複が完全になくなるわけではありません。業務IDによる重複対策も必要です。

4. 保存成功後の停止 変換済み動画を保存した直後、キューから削除する前にワーカーが落ちることがあります。再受信したワーカーが同じ業務IDの結果を確認し、安全に完了へ進める構成を考えます。結果保存と状態記録が食い違う場合も扱い、単に「一度処理したはず」というメモリー内のフラグへ頼りません。

5. 毒メッセージへの対応 未対応形式の動画はワーカーを増やしても成功しません。再受信回数でDLQへ分離して通知し、入力検証や変換機能を修正します。再投入時には原因が解決したかを確認します。同じ不正データを自動で戻し続けると、障害を循環させるだけになります。

6. 遅延の容量計算 1ワーカーが平均10秒で1件処理し、毎秒2件到着するなら、20ワーカーで平均処理能力が到着と等しくなる単純計算です。これだけでは既存の滞留を減らす余力がなく、ばらつきにも弱いため追加の余裕が必要です。最古メッセージの年齢を完了目標と照合し、下流の上限も確認します。

7. 通知先が複数ある場合 請求と分析の双方へ同じ完了通知を届けたいなら、同じSQSを二つのサービスで奪い合う構成は要件を満たしません。SNSから請求用・分析用のキューへ配信し、それぞれの再試行と容量を独立させます。一方、同種の変換ワーカーを複数台動かす場合は一つのキューから分担します。

8. 設定を症状へ対応させる 空受信が多いならロングポーリング、処理途中の再受信なら可視性、期限前の消失なら保持期間、繰返す特定の失敗ならDLQを調べます。設定名を丸暗記せず「いつから何を待たせるか」「何を失敗とするか」を時系列に置くと、適切な対策を選べます。

図解

重要ポイント

• 受付短縮と完了時間短縮は別
• 不可視期間の調整とアプリの冪等性は両方必要
• 同種ワーカーの分担と複数購読者への配信を区別する

間違えやすい点

• 処理能力が到着数と等しいだけでは滞留を解消する余力がない
• DLQを原因修正なしで再投入し続けない
• 保持期間を延ばすだけでは利用者の完了期限を守れない

用語解説

滞留

キューに残り、処理を待っている仕事の蓄積。

毒メッセージ

不正形式等により何度受信しても処理が成功しないメッセージ。

ファンアウト

一つの通知を複数の購読先へ配信する構成。

関連教材

• SQSによる疎結合を理解する