Amazon SQS - サーバーレスメッセージングサービス

SQSとは何か

Amazon SQS（Simple Queue Service）は、AWS が提供する完全マネージド型のメッセージキューイングサービスです。タスクのトリガーとなるキューを複数管理することで、ワークロードの並列実行を実現します。

SQS の基本的な仕組みは以下の通りです：

1. プロデューサーがメッセージをキューに送信
2. SQSキューがメッセージを保管
3. コンシューマーがポーリング処理によりメッセージを取得・処理

この仕組みにより、送信側と受信側が疎結合となり、スケーラブルで信頼性の高いアーキテクチャを実現できます。

AWS メッセージングサービスの選択

AWS はメッセージング関連の複数のサービスを提供しており、用途に応じて使い分けることが重要です。

Amazon SNS

• 通信モデル: Pub/Sub（発行・購読）型
• 用途: メール通知、プッシュ通知、複数のエンドポイントへの並行配信
• 特徴: 1つのメッセージが複数のサブスクライバーに即座に配信される

Amazon SQS

• 通信モデル: ポーリング型キューイングサービス
• 用途: タスク処理の並列実行、ワークロード分散
• 特徴: コンシューマーが能動的にポーリングしてメッセージを取得

Amazon SES

• 用途: Eメール送受信機能をアプリケーションに実装する場合
• 特徴: 安全で大規模なメール送信に対応

Amazon MQ

• 用途: JMS、NMS、AMQP、STOMP、MQTT、WebSocket などの業界標準 API に対応する必要がある場合
• 特徴: Apache ActiveMQ 向けのマネージド型メッセージブローカー

Amazon Kinesis Data Streams

• 用途: 大規模なストリームデータ処理（最大5MB/メッセージ）
• 特徴: シャード単位でデータを順序を保って送信、リアルタイム分析に適している

SQSの基本的な特徴

ポーリング処理型の仕組み

SQS は以下の4つのステップで動作します：

1. プロデューサーがメッセージを送信: Webアプリケーション、API、またはその他のAWSサービスからキューへメッセージが投入される
2. SQSキューにメッセージを保持: 設定された保持期間の間、メッセージが蓄積される
3. コンシューマーが問い合わせ（ポーリング）: バックエンドのワーカー（EC2、ECS、Lambda など）がメッセージの有無を確認する
4. メッセージがあれば受信: 複数のコンシューマーが存在する場合、そのうちの1つが受信して処理

この仕組みにより、プロデューサーとコンシューマーが直接通信せず、疎結合なアーキテクチャが実現されます。

AWS サービスとの連携

SQS は様々な AWS サービスと統合でき、幅広い用途に対応できます：

• EC2、ECS、Lambda との連携による自動スケーリング
• CloudWatch メトリクスの活用
• IAM ポリシー、リソースベースポリシーによるアクセス制御
• AWS KMS による暗号化

SQS キューのメッセージ制約

メッセージ数

• 無制限にメッセージを利用可能
• ただしメッセージ保持期間を適切に設定する必要があります

メッセージサイズ

• 標準: 最大 256KB
• 拡張クライアント使用時: 最大 2GB（拡張クライアントライブラリを利用）

受信数

• コンシューマー側では一度に最大10件までメッセージを受信可能

メッセージ保持期間

デフォルト設定

• デフォルト: 4日間（14,400秒）
• 設定可能範囲: 60秒 ～ 14日間

重要な注意点

DeleteMessage API で明示的に削除しない場合、メッセージは保持期間中ずっとキューに残ります。つまり、既に処理済みのメッセージが再度ポーリングされ、重複処理される可能性があります。正確なメッセージ処理のため、処理完了後は DeleteMessage API でメッセージを削除する必要があります。保持期間を超過すれば自動削除されますが、それまでの間、メッセージはキューに残り続けます。

SQS キューの基本タイプ（標準とFIFO）

SQS では、初期設定時に2つのキュータイプから選択します。

標準キュー

特徴：

• メッセージの順序を保証しない（ベストエフォート）
• メッセージの1回以上配信を保証（重複の可能性がある）
• 1秒あたりのトランザクション数はほぼ無制限
• 高スループット、低コストなオプション

用途：

• 「順序が重要でなく、1回以上の配信で十分」なユースケース
• タスク配信、ログ収集など順序不問な処理

動作イメージ： 送信順序 [6, 4, 5, 3, 4, 2, 1] → 受信順序は不定（例：[4, 5, 3, 1, 4, 2, 6]）

FIFO キュー

特徴：

• 先入れ先出し方式（FIFO）により配信順番を厳密に守る
• 1回だけの配信を保証（重複なし）
• 1秒あたり300トランザクションに制限
• コンシューマーがプロセスを処理して削除するまでメッセージはキューに保持

用途：

• 「操作やイベントの順序が重要」なユースケース
• 金融取引、在庫管理、注文処理など順序が重要な業務

動作イメージ： 送信順序 [5, 4, 3, 2, 1] → 受信順序 [5, 4, 3, 2, 1]（順序を厳密に保持）

標準キューとFIFOキューの比較表

項目	標準キュー	FIFOキュー
順序保証	しない（ベストエフォート）	する
重複保証	1回以上（重複の可能性）	1回のみ（重複なし）
スループット	ほぼ無制限	300トランザクション/秒
用途	順序不問な処理	順序が重要な処理

SQS キューの識別子

キューURL

• キューに割り当てられるURL
• SQS のリソース識別に使用
• 例：arn:aws:sqs:us-east-2:444455556666:queue1

メッセージID

• メッセージに対して割り当てられた一意のID
• メッセージの識別と追跡に使用

メッセージグループID（FIFO キュー専用）

メッセージグループID は FIFO キューにおいて重要な概念です：

• 定義: 特定のメッセージグループに属するメッセージを指定するタグ
• 動作: 同じメッセージグループに属するメッセージは、メッセージグループに相対的な厳密な順序で1つずつ処理される
• 並列処理: 単一の FIFO キュー内で複数の異なるメッセージグループをインターリーブするには、メッセージグループID値を使用する

例： 3つのメッセージグループ（A、B、C）がある場合、グループID を活用することで：

• グループAのメッセージ（A4, A3, A2, A1）を1つのコンシューマーで順序を守って処理
• グループBのメッセージ（B6, B5, B4, B3, B2, B1）を別のコンシューマーで順序を守って処理
• グループCのメッセージ（C3, C2, C1）をさらに別のコンシューマーで順序を守って処理

これにより、全体としての処理スループットを向上させながら、グループ内の順序を保証できます。

可視性タイムアウト

可視性タイムアウトは、重複処理を防ぐための重要な機能です。

仕組み

メッセージがコンシューマーに受信された直後、そのメッセージは SQS キューに残ったままとなります。この状態で、他のコンシューマーがそのメッセージを再度受信し、重複処理されることを防ぐため、可視性タイムアウトを設定します。

動作

1. コンシューマー1がメッセージを受信
2. メッセージは「処理中」状態となり、可視性タイムアウト期間（例：10分）の間、他のコンシューマーからは見えなくなる
3. コンシューマー2、3などは、この期間メッセージを見ることができない
4. コンシューマー1が処理完了後、DeleteMessage API でメッセージを削除

設定範囲

• 最小: 30秒
• 最大: 12時間

可視性タイムアウトは、処理にかかる予想時間より十分に長く設定することが重要です。

ポーリングの方式

SQS でメッセージを取得する際、2つのポーリング方式から選択できます。

ショートポーリング

• 動作: キューが空の場合に、すぐに空のメッセージレスポンスを返す
• 特徴: 即座に応答が返るが、空のレスポンスが頻繁に発生する可能性
• トレードオフ: API 呼び出し数が多くなり、コストが増加

ロングポーリング

• 動作: 問い合わせの結果が空の場合、指定したメッセージ受信待機時間、SQS は待機してから応答を返す
• 待機時間: 0秒 ～ 20秒で設定可能
• 特徴: 空のレスポンス数を大幅に削減できる
• 推奨: ほとんどの場合、ロングポーリングを使用することで効率化できます

SQS キューの機能オプション

SQS では、用途に応じて複数の機能オプションを組み合わせて使用できます。

遅延キュー（Delay Queue）

• 機能: キューへの新しいメッセージの配信を数秒間遅延させることができる
• 設定範囲: 0秒 ～ 15分
• 違い: 可視性タイムアウトとは異なり、キューが発行された直後から見えなくなる
• 範囲: キューレベルでのデフォルト設定が可能
• 個別設定: DelaySeconds パラメーターを利用してデフォルトを更新可能

用途: タスク処理を故意に遅延させたい場合（例：重試行の待機）

優先度付きキュー（Priority Queue）

• 機能: キューの処理順序に優先度をつけることができる
• 利用方法: これにより、優先対応があるタスクを最初に処理するようにワークフローを設定できる
• 実装: 複数のキューを活用し、優先度の高いキューを優先的にポーリング

デッドレターキュー（Dead Letter Queue）

• 機能: 正常に処理（消費）できないメッセージを別のキューへと移動させる
• メリット1: 処理不能なキューが蓄積されるのを防ぐ
• メリット2: 処理できなかった理由を後で解析できる
• 用途: エラーハンドリング、デバッグ

一時キュー（Temporary Queue）

一時キューは高スループットでコスト効率に優れたアプリケーション管理向けのキューです。

特徴：

• トラフィックが少ない場合は API 呼び出しが少なくなり、スループットが向上
• 使用されなくなると、クライアントは一時キューを自動的にクリーンアップ
• 特定スレッドまたはプロセスの軽量通信チャネルとして機能
• 追加のコストなく作成および削除可能
• 仮想キューとメッセージを送受信可能

用途：

• リクエスト/レスポンスパターンの実装
• 一時キュークライアントを利用して、リクエスト応答などの一般的なメッセージパターンを開発可能

リクエスト/レスポンス構成

一時キュークライアントを利用することで、リクエスト・レスポンス処理を実装できます。

動作フロー

1. フロントエンド側：

   • リクエスト用の一時キューを生成
   • バックエンドへリクエストを送信（リクエストメッセージにはレスポンス先キュー情報を含める）

2. バックエンド側：

   • リクエストメッセージを受信
   • 処理を実行
   • リクエストメッセージに指定されたレスポンス先キューへ結果を送信

3. フロントエンド側（再度）：

   • 一時キュー内のレスポンスを受信
   • 一時キューをクリーンアップ

この方式により、Request/Response パターンのような双方向通信を SQS でも実現できます。

キューの詳細設定

メッセージ重複排除ID

• 用途: 送信されたメッセージの重複排除に使用するトークン
• 動作: 同一の重複排除ID が設定されたメッセージをキューへ送っても、5分間の間は受け付けられないように設定できる
• 範囲: 個別のメッセージグループではなくキュー全体に適用される
• 対象: FIFO キューのみで利用する

暗号化（AWS KMS）

• AWS Key Management Service（AWS KMS）を使用して、送信データを暗号化する
• キュー内のデータ保護、コンプライアンス要件対応に有効

メッセージタイマー

• 機能: メッセージが発出された瞬間から、キューに追加されたメッセージが表示されないようにする機能
• 例: 45秒のタイマーでメッセージを送信すると、キューの最初の45秒間は表示されない
• 範囲: 個々のメッセージではなくキュー全体に対して遅延の秒数を設定するには、遅延キューを使用する
• 優先度: 個々のメッセージのメッセージタイマー設定はキュー全体よりも優先される

アクセス管理

SQS ポリシーを利用して、他アカウントや他リソースからのアクセスをコントロールできます。

IAM ポリシー

• 一般的な IAM ポリシーによる SQS リソースへのアクセス許可を設定
• SQS サービスへのアクセスを制御

SQS ポリシー

• リソースベースポリシーとして SQS リソース側でアクセス対象を制御するポリシー
• 他のアカウントと SQS キューを共有する許可が可能
• 他のサービスが SQS キューにメッセージを送信することを許可するなどの設定が可能

例：別のAWSアカウント（999888777666）からメッセージ送信を許可する場合

{
  "Version": "2012-10-17",
  "Id": "AllowCrossAccountSendMessage",
  "Statement": [
    {
      "Sid": "AllowExternalAccountSend",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::999888777666:root"
      },
      "Action": "sqs:SendMessage",
      "Resource": "arn:aws:sqs:ap-northeast-1:123456789012:task-queue"
    }
  ]
}

SQS のバッチアクション

バッチアクション機能により、1回のアクションで複数のメッセージを操作できます。

バッチ処理の3つのメソッド

AWS SDK を使用して、以下のバッチ処理が利用可能です：

• SendMessageBatch: 複数のメッセージを一度に送信
• DeleteMessageBatch: 複数のメッセージを一度に削除
• ChangeMessageVisibilityBatch: 複数のメッセージの可視性タイムアウトを一度に変更

バッチアクションを活用することで、API 呼び出し数を削減し、パフォーマンスを向上させられます。

SQS の基本アーキテクチャ

プロデューサー・コンシューマー分離構成

SQS の基本的で最も重要なアーキテクチャパターンは、メッセージ送信側（プロデューサー）と受信側（コンシューマー）を SQS キューで分離する構成です。

構成：

• プロデューサー側（複数の EC2）: ユーザーリクエストを受け取り、処理指示メッセージをキューに投入
• SQS キュー: メッセージを蓄積
• コンシューマー側（複数の EC2）: ポーリングによりメッセージを取得し、実際の処理を実行
• Auto Scaling: キューに蓄積されているメッセージ数に応じてインスタンスを自動スケーリング

メリット：

• 送受信側の疎結合化
• フロントエンドのレスポンス時間短縮
• バックエンド処理の効率化とスケーラビリティ

SQS と Auto Scaling の構成

SQS と Auto Scaling を統合することで、キューの状態に応じた自動スケーリングが実現されます。

スケーリングメトリクス

CloudWatch メトリクスに基づいてスケーリングを実行：

• インスタンスあたりの適正バックログ: キューの深さに応じたスケーリング
• メッセージ数: キュー内のメッセージ数を監視
• メッセージサイズ: 処理負荷を考慮した設定
• 処理時間: 実際の処理時間に基づいた最適化

動作フロー

1. フロントエンドが処理命令をキューに投入
2. CloudWatch がメトリクスを収集
3. Auto Scaling グループが CloudWatch メトリクスを監視
4. メッセージ数が増加すると、バックエンドインスタンスを自動スケールアップ
5. 処理が完了してメッセージが減ると、スケールダウン

この仕組みにより、「需要に応じた最適なリソース利用」が実現されます。

Kinesis と SQS の使い分け

Kinesis と SQS は異なる用途で設計されており、適切に使い分けることが重要です。

項目	Kinesis Data Streams	SQS
メッセージサイズ	最大5MB/メッセージ	最大256KB/メッセージ
データ型	ストリームデータ	コマンド・命令
処理モデル	リアルタイムストリーム	ポーリング型キュー
順序保証	シャード内で順序保証	FIFO キューで順序保証
用途	センサーデータ、ログ、動画、大規模データ分析	タスク処理、システム連携、ジョブスケジューリング

使い分けの指針

• Kinesis: 大容量データをリアルタイムで分析・処理する場合
• SQS: コマンドや制御メッセージを複数のワーカー間で分配する場合

例：

• IoT センサーからのデータ（温度、湿度など）→ Kinesis
• Webアプリケーションから送られる処理リクエスト → SQS

まとめ

Amazon SQS は、以下の点で AWS アーキテクチャの重要な構成要素です：

1. 疎結合化: プロデューサーとコンシューマーを分離し、独立したスケーリングが可能
2. 信頼性: メッセージの保持、重複排除、デッドレターキューなど多数の機能
3. 柔軟性: 標準キュー、FIFO キュー、各種オプション設定により多様な要件に対応
4. スケーラビリティ: Auto Scaling との統合により負荷に応じた自動調整
5. マネージド: インフラストラクチャ管理不要で、ビジネスロジックに集中

これらの特徴により、SQS は AWS Solutions Architect Associate 試験においても頻出であり、実務でも広く活用されるサービスです。