Amazon SQS で構築する非同期メッセージング - Standard と FIFO キューの設計
Standard と FIFO キューの使い分け、DLQ による処理失敗メッセージの退避、Lambda イベントソースマッピングによる自動処理を紹介します。
SQS の概要
SQS はフルマネージドのメッセージキューイングサービスです。SNS が 1 対多のファンアウトを提供するのに対し、SQS は 1 対 1 のポイントツーポイントメッセージングを提供します。Web アプリケーションのリクエスト処理とバックエンドの重い処理を分離し、スケーラビリティと耐障害性を向上させます。SQS はメッセージを複数の AZ に冗長保存するため、単一 AZ の障害でメッセージが消失することはありません。メッセージの保持期間はデフォルト 4 日間で、最大 14 日間まで延長可能です。Visibility Timeout はデフォルト 30 秒で、コンシューマが処理中のメッセージを他のコンシューマが受信しないよう制御します。
キュー設計と DLQ
Standard キューは 1 つの API アクション (SendMessage / ReceiveMessage / DeleteMessage) あたりの秒間リクエスト数がほぼ無制限とされており (公式ドキュメント記載・2026 年 8 月時点)、メッセージの順序は保証されません (ベストエフォート順序)。少なくとも 1 回の配信 (at-least-once) を保証するため、コンシューマ側で冪等性を確保する設計が必要です。FIFO キューはメッセージグループ ID ごとに順序を保証し、重複排除 ID で exactly-once 処理を実現します。スループットは API アクションあたり秒間 300 メッセージ (バッチ利用時 3,000) が既定で、高スループットモードを有効にするとバージニア北部・オレゴン・アイルランドでは秒間 70,000 メッセージ (バッチ利用時 700,000)、東京では秒間 9,000 メッセージ (バッチ利用時 90,000) まで拡張できます (公式ドキュメント記載値・2026 年 8 月時点)。DLQ は maxReceiveCount 回処理に失敗したメッセージを自動的に移動し、メインキューの処理を妨げません。DLQ のメッセージを調査し、原因を修正した後にメインキューに再ドライブ (再送) できます。DLQ の保持期間はソースキューと独立して設定できるため、調査に十分な期間 (例: 14 日) を設定することが推奨されます。
Lambda 統合と大容量メッセージ
SQS と Lambda のイベントソースマッピングで、キューのメッセージを自動的に Lambda 関数で処理します。バッチサイズ (Standard キューは最大 10,000、FIFO キューは最大 10) とバッチウィンドウ (最大 300 秒・FIFO キューでは非対応) を設定し、複数メッセージをまとめて処理することで Lambda の呼び出し回数を削減します。部分バッチ応答 (ReportBatchItemFailures) を有効にすると、バッチ内の失敗メッセージのみを再処理でき、成功メッセージの重複処理を回避できます。FIFO キューでは Lambda の同時実行数がメッセージグループ数に制限されます。Extended Client Library で 256 KB を超えるメッセージを S3 経由で送受信し、大容量データの非同期処理に対応します。メッセージの暗号化は SSE-SQS (無料) または SSE-KMS で設定します。
設計のベストプラクティスと落とし穴
Visibility Timeout はコンシューマの最大処理時間よりも長く設定します。短すぎるとメッセージが再配信され重複処理の原因になります。Standard キューではコンシューマの冪等性が必須です。DynamoDB の条件付き書き込みやデータベースの一意制約で重複処理を防ぎます。FIFO キューの重複排除ウィンドウは 5 分間固定であり、5 分以内に同じ重複排除 ID でメッセージを送信すると後続が破棄されます。ロングポーリング (WaitTimeSeconds を 1〜20 秒に設定) は必ず有効にしてください。ショートポーリングでは空レスポンスが頻発し、無駄なリクエスト課金が発生します。メッセージ属性 (MessageAttributes) をルーティングやフィルタリングに活用し、メッセージ本文のパースを最小限に抑えることでコンシューマのパフォーマンスが向上します。
SQS の料金と制限の注意点
(2026 年 8 月時点・バージニア北部と東京) SQS のリクエスト料金は Standard キューが 100 万リクエストあたり 0.40 ドル、FIFO キューが 0.50 ドルから始まり、月間リクエスト量に応じて 3 段階に逓減します (第 1 段階 = 月間 1,000 億リクエストまで・第 2 段階 = 2,000 億リクエストまで・第 3 段階 = それ以上。両リージョン共通の境界)。逓減後の単価はリージョンで異なり、最安帯はバージニア北部が Standard 0.24 ドル・FIFO 0.35 ドル、東京が Standard 0.32 ドル・FIFO 0.42 ドルです。Standard キューでメッセージグループ ID を伴う fair queue のリクエストは、両リージョンとも 100 万あたり 0.10 ドルが Standard 料金に加算されます。最初の 100 万リクエスト/月は無料です。1 リクエストには最大 10 件のメッセージ (合計ペイロード 1 MiB まで) を含められ、ペイロードは 64 KB チャンクごとに 1 リクエストとして課金されます (1 MiB のペイロードは 16 リクエスト相当)。ロングポーリング (WaitTimeSeconds=20) で空のレスポンスを削減し、リクエスト数を最適化します。DLQ のメッセージは通常のキューと同じ料金で課金されるため、DLQ のメッセージを定期的に処理または削除します。インフライトメッセージ数の上限は Standard キュー・FIFO キューともに 120,000 で (公式ドキュメント記載値・2026 年 8 月時点)、Standard はクォータ引き上げ申請、FIFO は AWS Support への連絡で緩和を依頼します。上限に達したときの挙動はポーリング方式で異なり、ショートポーリングでは OverLimit エラーが返り、ロングポーリングではエラーにならずインフライト数が減るまで新しいメッセージが返りません。いずれの場合もコンシューマのスケーリングで処理速度を確保する設計が重要です。SSE-KMS 暗号化を使用する場合、KMS API 呼び出しに追加費用が発生します。大量メッセージを処理するキューでは SSE-SQS (追加費用なし) の利用を検討してください。
SQS と他のメッセージングサービスの比較
SQS はプルベースのポイントツーポイント型キューです。SNS はプッシュベースのパブサブ型で、1 つのメッセージを複数のサブスクライバに同時配信します。SNS + SQS のファンアウトパターンでは、SNS トピックに複数の SQS キューをサブスクライブし、各キューで独立した処理を並行実行できます。Amazon MQ は Apache ActiveMQ や RabbitMQ のマネージド版で、JMS や AMQP など既存プロトコルとの互換性が必要な場合に選択します。EventBridge はイベント駆動アーキテクチャ向けで、200 以上のイベントソースと 20 以上のターゲットを組み込みで備え、AWS サービスや SaaS からのイベントをルールベースでルーティングします (公式機能ページ記載値・2026 年 8 月時点)。SQS は大量メッセージのバッファリングとワーカーパターンに最適化されており、コスト効率と運用のシンプルさで優れています。
まとめ
SQS は非同期メッセージングで疎結合なアーキテクチャを構築するサービスです。Standard キューでほぼ無制限のリクエストスループットを扱い、FIFO キューで順序保証と重複排除を実現します。Lambda のイベントソースマッピングでメッセージを自動処理し、DLQ で処理失敗メッセージを退避させます。ロングポーリングでリクエスト数を最適化し、Extended Client Library で 256 KB 超のメッセージにも対応します。冪等性の確保と Visibility Timeout の適切な設定が、本番運用の安定性を左右する重要な設計ポイントです。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。