Amazon SQS

解決する課題

• アクセス急増でバックエンドが詰まる → キューでバッファ
• 送信側と処理側を疎結合にして独立にスケールしたい
• 失敗したジョブを安全に退避・再試行したい

主要概念と用語

• 標準キュー: 高スループット・順序保証なし・最低1回配信
• FIFOキュー: 順序保証＋重複排除（exactly-once処理）
• 可視性タイムアウト: 取り出し中のメッセージを一時的に隠す
• デッドレターキュー（DLQ）: 規定回数失敗したメッセージの退避先
• ロングポーリング: 空ポーリングを減らしコスト削減

仕様・制限・クォータ

• メッセージ保持は最大14日（既定4日）
• メッセージ最大256KB（大きいデータはS3＋参照）
• プル型（ワーカーがポーリング）

内部の仕組み

ワーカーがキューをポーリングしてメッセージを取得すると、可視性タイムアウトの間そのメッセージは他のワーカーから見えなくなります。処理が成功したら削除、失敗（タイムアウト）したら再び見えるようになり再試行されます。規定回数失敗するとDLQへ移動します（＝最低1回配信なので冪等な処理が前提）。

設計パターン / ベストプラクティス

• SQS + Auto Scaling: キューの深さでワーカー数をスケール
• SQS → Lambda: メッセージ到着でLambda起動
• DLQ で失敗を退避し、原因調査・再投入
• 大きいペイロードはS3に置きキューには参照

運用・監視・トラブルシュート

• メトリクス: ApproximateNumberOfMessagesVisible ApproximateAgeOfOldestMessage
• 滞留増 → ワーカー不足やダウンストリーム障害を疑う
• DLQに溜まる → 処理ロジック/権限/フォーマットを確認

コスト

• リクエスト数課金。ロングポーリングで空ポーリングを減らすと安くなる

セキュリティ

• IAM/キューポリシーでアクセス制御
• 保存時暗号化（SSE/KMS）、VPCからはインターフェース型エンドポイント

Well-Architected の観点

• 信頼性: バッファ＋リトライ＋DLQで取りこぼさない
• パフォーマンス効率: 処理側を独立にスケール
• コスト最適化: 必要な時だけ処理

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# キュー作成 → 送信 → 受信
aws sqs create-queue --queue-name jobs
aws sqs send-message --queue-url "$URL" --message-body '{"id":"job-1"}'
aws sqs receive-message --queue-url "$URL" --wait-time-seconds 20  # ロングポーリング