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

この単元で学ぶこと

• 同期通信とキューによる疎結合を比較する
• 受信・不可視・削除の流れを説明する
• 滞留・再試行・重複に耐える処理を設計する

本文解説

1. 同期処理の結び付き 画像をアップロードした利用者に、変換処理が終わるまで待ってもらうと、変換サーバーの遅延が受付の応答に伝わります。同期通信はその場で結果が必要な処理に向きますが、相手が止まったときの影響も直接受けます。受付と重い後続作業を分けられるかを考えます。

2. キューを挟む 生産者は仕事の情報をSQSへ送り、消費者であるワーカーが後から取り出します。変換要求ならS3上の画像の参照先と業務IDを送れます。受付が返すのは「依頼を受け付けた」という結果であり、「変換が完了した」ではありません。画面の進捗確認方法も合わせて用意します。

3. 受信は削除ではない ワーカーがメッセージを受け取ると、そのメッセージは可視性タイムアウトの間、他の受信から一時的に見えなくなります。キューに存在はしています。処理を成功させてから削除するのが基本です。先に削除してからワーカーが停止すると、未完了の仕事を再配信できなくなります。

4. タイムアウトと再試行 処理しても削除されず不可視期間が切れると、メッセージは再受信の対象になります。予想処理時間より短い設定は処理途中の再受信を招き、極端に長い設定は失敗後の再試行を遅らせます。時間が変動するなら処理中に可視性を延長する方法も使い、停止時の回復との釣合いを取ります。

5. 重複を安全に扱う Standardでは同じメッセージが複数回届く可能性があります。さらにDB更新成功後、削除前に停止することもあります。注文ID等を一意に扱い、更新と処理済み記録の整合性を確保すると、再配信で二重に発送することを防げます。受信が一度だったと期待する設計は避けます。

6. 繰返し失敗の分離 形式が壊れた仕事は何度試しても成功しません。再受信回数に応じてDLQへ隔離すると、正常な仕事と分けて調査できます。DLQは修復装置ではないため、アラーム、内容調査、原因修正、再投入の手順が必要です。元キューとDLQの保持期間も調査の猶予に合わせます。

7. バッファと容量 キューは一時的な到着増加を吸収しますが、処理能力が恒常的に不足すれば滞留は増え続けます。到着数、処理時間、ワーカー数、最古メッセージの経過時間を監視します。待ち時間の目標へ合わせて容量を調整し、下流DBの同時実行上限も越えないようにします。

8. 他の通信方式との境界 一つの仕事を複数ワーカーで分担するキューと、すべての部門へ通知する配信は異なります。全購読者が必要ならSNSと各SQS等を組み合わせます。複数段階の分岐・待機・補償を管理するならStep Functionsを検討します。ロングポーリングは空の受信を減らす仕組みで、配信先の数を増やす機能ではありません。

図解

重要ポイント

• 受付完了と業務処理完了を区別する
• 処理後に削除し、再受信を前提に冪等性を設計する
• キューは一時的な負荷差を吸収するが処理能力そのものを増やさない

間違えやすい点

• ReceiveMessageだけで削除されたと思わない
• 可視性タイムアウトと保持期間を混同しない
• DLQへ入っただけで業務エラーが解消したと判断しない

用語解説

生産者／消費者

仕事を送るプログラム／取り出して処理するプログラム。

冪等性

同じ操作を繰返しても、必要な業務上の結果を一回分に保つ性質。

DLQ

繰返し正常処理できないメッセージを分離して調査するキュー。

関連教材

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