コンシューマーが遅延または失敗してもジョブを保持し、後続チームに通知し、繰り返し配信から業務結果を保護します。小さな注文処理を通じて SQS と SNS を学びます。
5 つのガイド付きラボで、消費、可視性、デッドレターキュー、SNS ファンアウト、重複保護を扱います。自主課題では、失敗したジョブが回復用キューに届かないインシデントを修復します。
学習する内容
- SQS ジョブを送信、受信、処理し、処理済みとして確認する
- 可視性期間、再配信、現在のレシートハンドルを観察する
- 失敗したジョブをデッドレターキューに隔離する
- フィルター付き SQS サブスクリプションに SNS 通知を配信する
- DynamoDB の条件付き書き込みで、繰り返される業務操作を保護する
- 正常な処理を継続しながら、失敗したジョブのルーティングを修復する
- 保存結果を確認し、自分のリソースだけを削除する
このコースの対象者
サーバーレスアプリケーションに非同期処理と障害対応を追加する準備ができた学習者が対象です。
前提知識： Lambda–DynamoDB アクセス（FN03）とその前提を先に学びます。Q01 → Q02 → Q03 は処理と失敗隔離です。Q04 は IAM リソースポリシーも必要な SNS 支線、Q05 は DynamoDB 条件付き書き込み（D04）と Lambda コード更新（FN02）が必要です。サービスチャレンジは Q03 の後、PS02 は Q05 も使用します。
学習環境： すべての演習は、ブラウザーから利用できる LabEx の Linux 環境で行います。AWS CLI のコマンドには Terminal を使い、その隣の AWS View で同じリソースとアプリケーションの状態を確認します。ツールと接続は準備済みで、個人の AWS アカウントやアクセスキーは不要です。各ラボは新しい VM で独立して開始します。 AWS View はキュー、メッセージ本文、試行、ログ、SNS エンベロープ、保存済み注文を表示します。読み取り専用の観察ではメッセージを受信したり、処理済みとして確認したりしません。
よくある質問
キューを設定すればジョブが処理されたと証明できますか？
いいえ。実際の処理、保存結果、処理済みの送信元メッセージ、保持された失敗ジョブを確認します。処理プログラムと参照データは提供され、架空のジョブを使って結果に集中できます。
メッセージに新しいレシートハンドルがあるのはなぜですか？
レシートハンドルは 1 回の配信に属します。可視性が切れると別の試行が発生し、その配信の現在のハンドルが使われます。処理済みとして確認する配信のハンドルを使ってください。
重複保護は厳密に 1 回の配信を意味しますか？
いいえ。標準キューは複数回配信する場合があります。単一アイテムの条件付き書き込みは、学習した業務上の効果を保護しますが、キュー操作とデータベース書き込みは別です。アトミックなトランザクションでも、エンドツーエンドの厳密に 1 回の保証でもありません。
メッセージングの例はどこまで扱いますか？
1 件ずつ処理するコンシューマーを使う標準キュー、デッドレターへの再ルーティング、同一アカウント内の SNS から SQS へのファンアウト、メッセージ属性フィルターを扱います。FIFO 順序、任意のバッチ、本番スループット、クロスアカウントポリシー設計、サービス全体のリトライ保証は範囲外です。
次にどのプロジェクトへ進めますか？
Serverless プロジェクトコースの Recover Poison Messages Without Duplicating Orders です。 サービスチャレンジは Q03 とその前提、プロジェクトは Q05 も必要です。機能確認後にクリーンアップします。
