Amazon SNS - プッシュ型通知サービス

SNS とは何か

Amazon SNS（Simple Notification Service）は、AWS が提供するフルマネージド型のプッシュ型通知サービスです。他のサービスとの非同期通信を可能にする、Pub/Sub（パブリッシュ・サブスクライブ）メッセージングモデルを採用しています。

基本的な仕組み

SNS は以下の3つのステップで動作します

1. パブリッシャーがトピックにメッセージを発行: アプリケーション、AWS サービス、または外部システムから SNS トピックにメッセージが送信される
2. SNS が通信処理を実行: SNS はパブリッシャーから受け取ったメッセージを、登録されているすべてのサブスクライバーに対して処理する
3. 複数のサブスクライバーに通知内容をプッシュ配信: メッセージは複数の通信プロトコル（HTTPS、EMAIL、SQS、モバイルプッシュ通知など）を通じて、サブスクライバーへ一斉に配信される

トピックの役割

トピック（Topic）は SNS の中核となる概念です：

• 発行点: パブリッシャーがメッセージを発行する場所
• 配信管理: トピックに登録されたすべてのサブスクライバーを管理して、メッセージを一斉配信

トピックはメッセージの集約点として機能し、複数の発行元からのメッセージを受け取り、複数の購読者へ即座に配信します。

AWS メッセージングサービスの比較（SNS と SQS）

SNS と SQS は両方ともメッセージング機能を提供していますが、動作方式と用途が異なります。

SQS（ポーリング型）

• メッセージの永続性: あり（保持期間中はキューに保持）
• 配信方式: ポーリング型（コンシューマーが自身のタイミングでメッセージを取得）
• 受信側の独立性: 高い（送信側と受信側の処理速度が独立）
• 用途: 送信側が受信側の処理能力や状態に関わらず、メッセージをキューに蓄積して非同期処理したい場合に利用
• メッセージ動作: 送信されたメッセージはキューに蓄積され、コンシューマーの削除まで保持される

SNS（プッシュ型）

• メッセージの永続性: なし（配信されたらメッセージは終了）
• 配信方式: プッシュ型（SNS が即座にサブスクライバーに配信）
• 受信側の独立性: 低い（配信は即座で、受け取れない場合は失われる）
• 用途: 「特定のタイミングで通知したい」場合に利用
• メッセージ動作: 発行直後に全サブスクライバーへ即座に配信。受け取れないと情報は失われる可能性

使い分けの指針

シーン	選択サービス	理由
バックエンド処理のタスク分散	SQS	ワーカー側が自身のペースで処理する必要がある
イベント発生時の複数受信者への一斉通知	SNS	複数の受信者へ同時に即座に通知する必要があり、受信側が異なる場合
メール/SMS通知	SNS	リアルタイム通知が必要
メッセージ永続化と順序処理が必須	SQS（FIFO）	メッセージの永続性と順序保証が必要。受信側の処理速度に依存せず蓄積
複数の同一順序の通知が必須	SNS（FIFO）	複数の受信者に同じ順序で即座に通知する必要がある

SNS の基本的な特徴

メッセージ特性

• 単一発行メッセージ: 1つのメッセージが複数のサブスクライバーに配信される
• メッセージの永続性なし: 配信後、メッセージは保持されない
• メッセージサイズ: 最大256KB
• 取り消し不可: 一度発行されたメッセージは取り消せない
• 配信ポリシーによる再試行: 配信に失敗した場合、設定されたポリシーに基づいて自動的に再試行される

配信の信頼性

配信ポリシーを設定することで、以下の再試行戦略を実装できます：

• 即座の再試行
• 指数バックオフによる遅延再試行
• 最大試行回数の制限
• デッドレターキューへの送信

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

標準トピック

• メッセージ順序: 保証されない（受信順序は不定）
• 配信方式: プッシュ型で即座に配信
• スループット: ほぼ無制限
• 用途: 「順序が重要でない」通知シーン
• 特徴: 最高のスループットとシンプルな構成

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

FIFO トピック

• メッセージ順序: 厳密に保証（先入れ先出し）
• 配信方式: 送信順序通りに配信
• スループット: 標準トピックより制限あり
• 用途: 「操作やイベントの順序が重要」なシーン
• 特徴: 重複排除（Deduplication）をサポート

動作イメージ: 送信順序 [4, 3, 2, 1] → 受信順序 [4, 3, 2, 1]（順序を保証）

標準トピックと FIFO トピックの比較

項目	標準トピック	FIFO トピック
順序保証	しない	する
スループット	ほぼ無制限	制限あり
重複排除	なし	サポート
用途	リアルタイム通知	金融取引、ステート管理

SNS メッセージ形式

SNS では以下のように HTTP/HTTPS/JSON 形式のメッセージを利用しています：

メッセージ形式の種類

• HTTP/HTTPS ヘッダー: リクエスト・レスポンスの通信情報
• HTTP/HTTPS 受信登録の確認の JSON 形式: サブスクライバーが購読リクエストを確認する際のメッセージ形式
• HTTP/HTTPS 通知の JSON 形式: 実際のメッセージ配信時の形式
• HTTP/HTTPS 受信登録の解除の JSON 形式: 購読解除時のメッセージ形式
• SetSubscriptionAttributes 配信ポリシー JSON 形式: サブスクリプション単位での配信ポリシー設定
• SetTopicAttributes 配信ポリシー JSON 形式: トピック全体の配信ポリシー設定

SNS と AWS サービスの連携

SNS は AWS の様々なサービスと統合され、多くのユースケースで活用されています。

主要な連携サービス

Amazon CloudWatch

• Billing Alert の通知をトリガーする
• CloudWatch アラームが発火した時点で SNS トピックに通知を送信

Amazon SES（Simple Email Service）

• Bounce（バウンス）と Complaint（苦情）のフィードバック通知を受け取る
• メール配信結果を SNS 経由で監視

Amazon SQS

• SNS 通知によってキューにメッセージを配信
• ワーカーが非同期で処理を実行

Amazon S3

• ファイルがアップロードされた時点で SNS に通知
• イベント駆動型のワークフローを実現

Amazon Elastic Transcoder

• 動画変換処理が完了または失敗した時に SNS で通知
• バッチ処理の完了を監視

AWS Lambda

• SNS をトリガーとして Lambda 関数を起動
• サーバーレス型のイベント駆動アーキテクチャを構築

ファンアウト構成（SNS + SQS）

SNS と SQS を組み合わせることで、「ファンアウト構成」と呼ばれる強力なアーキテクチャパターンが実現されます。

ファンアウト構成とは

1. イベント発生: S3 にファイルがアップロードされるなどのイベント発生
2. SNS トピックへ発行: イベントが SNS トピックに通知される
3. 複数の SQS キューへ配信: SNS が複数の SQS キューに同じメッセージを配信
4. 独立した処理実行:
   • SQS キューA からメッセージを受け取った EC2 が削除処理を実行
   • SQS キューB からメッセージを受け取った EC2 が変換処理を実行
   • SQS キューC からメッセージを受け取った Lambda が解析処理を実行

ファンアウト構成のメリット

• 疎結合性: 各ワーカーがキューから独立して処理を取得できる
• スケーラビリティ: 後から新しい SQS キュー（ワーカー）を追加可能
• 耐障害性: 1つのワーカーがダウンしても他のワーカーに影響しない
• 非同期処理: 異なるスピードの処理を並行実行可能

フィルタリング機能

メッセージフィルタリング

フィルタリング機能を利用することで、SNS から SQS キューへ配信する際に、特定の条件に基づいてメッセージを選別できます。

活用シーン

例：EC2 から「データ処理要求」を発行する場合

• State: 削除 → 削除処理用 SQS キューへのみ配信
• State: 変換 → 変換処理用 SQS キューへのみ配信

メッセージペイロード内の属性値を評価し、マッチした条件のキューにだけメッセージを配信します。

フィルタリングのメリット

• 不要なメッセージの送信削減: 該当しないキューへの配信をスキップ
• 処理効率の向上: ワーカーが必要なメッセージのみ処理
• コスト削減: 不要な API 呼び出しが減少

アクセス管理

IAM ポリシー

• 用途: 一般的な IAM ポリシーによる SNS リソースへのアクセス許可設定
• 対象: SNS サービスへのアクセスを制御
• 例: ユーザーが SNS トピックに対して Publish 操作のみ可能、Subscribe は不可など

SNS ポリシー

• 用途: リソースベースポリシーとして SNS リソース側でアクセス対象を制御
• 特徴: 他のアカウント、IAM ロール、AWS サービスが SNS にアクセスする際に適用
• 可能な設定:
  • 他のアカウントと SNS を共有する許可
  • 他のサービス（S3、CloudWatch など）が SNS にメッセージを送信することを許可

ポリシー設定例

別のアカウント（999888777666）から SNS トピックへメッセージ送信を許可する場合、以下の要素を含めます：

• Principal: アカウント ARN または IAM ロール ARN
• Action: sns:Publish など実行可能なアクション
• Resource: 対象となる SNS トピックの ARN
• Effect: Allow または Deny

SNS のメッセージ配信保証

配信試行

SNS は複数の配信プロトコルをサポートしており、各プロトコルで信頼性メカニズムが異なります：

• HTTPS エンドポイント: HTTP ステータスコード 200 番台を受け取るまで再試行
• Email: メール送信に失敗した場合の再試行ロジック
• SQS: SQS の確認メカニズムに依存

再試行ポリシーの設定

配信ポリシーを設定することで、以下をカスタマイズ可能：

• 初回配信失敗時の待機時間
• 再試行間隔（指数バックオフ対応可能）
• 最大試行回数
• 最終的に失敗した場合の処理（デッドレターキューへ送信など）

SNS と SQS の連携フロー

典型的なユースケース

1. アプリケーション側の処理:

   • ユーザーリクエストを受け取る
   • 処理開始を SNS トピックに発行

2. SNS の処理:

   • トピックにメッセージが到着
   • 複数の SQS キューにメッセージを配信

3. ワーカーの処理:

   • SQS キューからメッセージをポーリング
   • 受け取ったメッセージに基づいて処理を実行
   • 処理完了後、DeleteMessage API でキューからメッセージを削除

4. 応答返却:

   • ワーカーが処理結果を記録（DynamoDB、S3 など）
   • アプリケーション側が結果を確認

SNS の制限と注意点

メッセージの特性

• 永続性なし: メッセージ配信後は保持されない。受け取り損ねた場合、情報は失われる
• 順序保証なし（標準トピック）: 複数のプッシュ通知の到着順序は保証されない
• 取り消し不可: 発行したメッセージは取り消せない

パフォーマンス特性

• スループット: 標準トピックはほぼ無制限だが、FIFO トピックは制限がある
• レイテンシー: プッシュ型のため、配信は即座だが、受信側がオフラインの場合は失われる

SNS を選ぶべき場面

• リアルタイム通知: 即座に複数のコンポーネントに通知を送る
• イベント駆動型: ファイルアップロード、トランザクション完了など、イベント発生時に複数の処理を開始
• メール/SMS 送信: 確認メール、アラート通知などのエンドユーザー向け通知
• AWS サービス連携: CloudWatch アラーム、S3 イベント、CloudTrail など

まとめ

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

1. プッシュ型通知: 即座に複数の受信者へメッセージを配信
2. Pub/Sub モデル: パブリッシャーとサブスクライバーを分離し疎結合化
3. マルチプロトコル対応: HTTP、Email、SQS、モバイルプッシュなど多様な配信手段
4. AWS サービス連携: CloudWatch、S3、Lambda など、AWS エコシステムとの深い統合
5. ファンアウト構成: SNS + SQS で強力な非同期処理アーキテクチャを実現

SNS と SQS の特性を理解し、適切に組み合わせることで、スケーラブルで信頼性の高い分散システムを構築できます。これらは AWS Solutions Architect Associate 試験でも頻出のサービスであり、実務でも広く活用されています。