Amazon Simple Queue Service (SQS)

1. サービス概要¶

Amazon Simple Queue Service (SQS) は、分散アプリケーション間の非同期メッセージキューイングを提供するフルマネージドサービス。
送信側(Producer)と受信側(Consumer)を疎結合にし、メッセージを一時的にキューに蓄積することで、システム全体の耐障害性・スケーラビリティを向上させる。

主なユースケースとして、

Microservices 間の非同期処理
ピーク負荷対策
デカップリング
バックログ処理
非同期ワークフローの構築

などが挙げられる。

2. 主な特徴と機能¶

2.1 スタンダードキューと FIFO キュー¶

SQS には 2 種類のキュータイプがある。

スタンダードキュー: 高スループット、少量の重複や順序の崩れが許容される。
FIFO キュー: First-In-First-Out を保証し、重複排除、厳密なメッセージ順序が必要な場合に使用。

2.2 可視性タイムアウト (Visibility Timeout)¶

コンシューマーがメッセージを受信した後、一定時間(可視性タイムアウト)そのメッセージは他のコンシューマーから見えなくなる。
コンシューマーが処理を完了し DeleteMessage する前にタイムアウトが切れると、同じメッセージが再度配信され、処理失敗時の再試行を可能にする。

2.3 デッドレタキュー (Dead-Letter Queue: DLQ)¶

処理失敗を繰り返すメッセージを別のキュー（DLQ）に隔離することで、問題あるメッセージを後から分析・再処理しやすくする。
DLQ を用いることで、正常なメッセージ処理を妨げないアーキテクチャを実現できる。

2.4 長いポーリング (Long Polling)¶

コンシューマーがキューからメッセージを取得する際に、すぐにメッセージがなければ一定時間待機できる機能。
これにより、空のレスポンスを減らし、コスト・レイテンシ削減が可能。

2.5 メッセージ属性とバッチ操作¶

メッセージには属性（キー・バリュー）を付与可能。
また、複数メッセージをまとめて送受信・削除（最大 10 件）できるバッチ操作でパフォーマンス向上が可能。

3. アーキテクチャおよび技術要素¶

Producer が SQS キューにメッセージを SendMessage または SendMessageBatch で送信。
Consumer は ReceiveMessage でキューからメッセージを取得、処理後 DeleteMessage で削除。
必要に応じて FIFO キューで順序の保証、DLQ で失敗メッセージ隔離、Long Polling で効率的なメッセージ取得を活用。
IAM ポリシーやキューポリシー、KMS による暗号化でセキュリティ・アクセス制御を実施

4. セキュリティと認証・認可¶

IAM ポリシー: 誰が SQS API（SendMessage、ReceiveMessage など）を実行できるか制御。
キューポリシー: 特定アカウントや条件に基づいてキューへの操作許可・拒否が設定可能。
SSE-KMS 暗号化: キューへ送信されるメッセージを KMS で暗号化し、メッセージ機密性を確保。
VPC エンドポイント: VPC 内からインターネット経由せずに SQS へアクセス可能。

5. 料金形態¶

SQS は次の項目で主に課金される:

リクエスト数: メッセージ送信・受信・削除リクエストごとに課金。（スタンダードキューは月 100 万リクエストまで無料枠あり）
SSE-KMS 暗号化: KMS API コールコストが追加。
データ転送料: 同一リージョン内への転送は無料だが、クロスリージョン転送には料金発生。

6. よくあるアーキテクチャ・設計パターン¶

非同期処理キュー: Web アプリから非同期ジョブを SQS キューに送信、バックエンドの Worker が処理。
キューと Lambda 連携: SQS キューを Lambda トリガーに設定し、メッセージ到着時に自動処理。
キュー間連携と DLQ: メインキュー → 処理失敗 →DLQ へ移送し、後から再処理や分析。
Fan-out パターン(併用): SNS トピック →SQS キュー複数へ配信し、並列処理を実現。

7. 設定・デプロイ手順（ハンズオン例）¶

SQS コンソールで新規キュー作成（Standard または FIFO、キュー名、属性を設定）。
必要に応じてキューポリシーや SSE-KMS 暗号化を有効化。
Producer は AWS CLI、SDK またはコンソールから SendMessage でメッセージ送信。
Consumer は ReceiveMessage でメッセージ取得後、処理完了時に DeleteMessage 。
DLQ や Long Polling 設定、Visibility Timeout 調整で可用性・再処理性を最適化。

8. 試験で問われやすいポイント¶

8.1 スタンダードキューと FIFO キュー¶

スタンダードは無制限スループットと多少のメッセージ順序崩れ許容、FIFO は順序厳密維持と重複排除。

8.2 可視性タイムアウト¶

コンシューマー処理中に同じメッセージが他から見えないようにするための時間。

8.3 デッドレタキュー（DLQ）¶

処理失敗したメッセージを隔離し、再処理やデバッグを容易にする。

8.4 Long Polling¶

空のレスポンスを減らし、コストを抑えつつリアルタイム性向上。

8.5 セキュリティと暗号化¶

IAM ポリシー、キューポリシー、SSE-KMS で制御と暗号化。

8.6 コストモデルと無料枠¶

標準キューには一定の無料枠、バッチ操作でリクエスト数低減。

SQS→Lambda 連携でイベント駆動処理、SNS→SQS 連携で Fan-out パターン、Step Functions ワークフロー内での待機状態としても活用。

8.8 試験で頻出となる具体的な問われ方と答え¶

Q: SQS のスタンダードキューと FIFO キューの違いは？
A: スタンダードは高スループットだが順序保証なし、FIFO は順序と重複排除を保証するがスループット制限あり。
Q: 可視性タイムアウトは何のためにある？
A: メッセージ処理中に同じメッセージが他のコンシューマーに見えないようにし、重複処理を防ぐため。
Q: デッドレタキューはどのように利用する？
A: 処理に何度も失敗したメッセージを DLQ に隔離し、後から分析や再処理を行うため。
Q: Long Polling を有効にすると何が得られる？
A: キューが空の場合でも一定時間待機することで、空レスポンスを減らしコスト削減と低レイテンシ取得を実現できる。
Q: SQS と Lambda を連携するとどのような利点がある？
A: SQS キュー到着メッセージを自動トリガーとして Lambda が処理することで、サーバーレスかつ非同期なワークフローを構築できる。