Tech Hotoke Blog

IT観音とは私のことです。

AWS SNSとSQSの連携についての学習メモ

これは何？

AWS SNS, SQSの連携周りを触ることになったので、その際の学習メモ。

AWS SNSって何？

  • Amazon Simple Notification Serviceの略
  • 配信者から受信者へのメッセージ配信を提供するマネージドサービス
  • 論理アクセスポイントおよび通信チャネルであるトピックという単位で管理される
  • 非同期的に通信する
  • A2A(aplication-to-application) メッセージングとA2P(aplication-to-person)通知が可能

A2Aメッセージング

  {
   "Type" : "Notification",
   "MessageId" : "63a3f6b6-d533-4a47-aef9-fcf5cf758c76",
   "TopicArn" : "arn:aws:sns:us-west-2:123456789012:MyTopic",
   "Subject" : "Testing publish to subscribed queues",
   "Message" : "Hello world!",
   "Timestamp" : "2012-03-29T05:12:16.901Z",
   "SignatureVersion" : "1",
   "Signature" : "EXAMPLEnTrFPa3...",
   "SigningCertURL" : "https://sns.us-west-2.amazonaws.com/SimpleNotificationService-f3ecfb7224c7233fe7bb5f59f96de52f.pem",
   "UnsubscribeURL" : "https://sns.us-west-2.amazonaws.com/?Action=Unsubscribe&SubscriptionArn=arn:aws:sns:us-west-2:123456789012:MyTopic:c7fe3a54-ab0e-4ec2-88e0-db410a0f2bee"
}

A2P(aplication-to-person)通知

標準および FIFO トピック

  • FIFO トピック：メッセージの順序を厳格に保つ。メッセージグループを定義し、メッセージの重複を防止する。FIFO トピックにサブスクライブするには、FIFO キューと標準キューの両方を使用可能。(AWS SESと連携する場合は2024/02/27時点ではサポートされていないので注意)
  • 標準トピック：メッセージの配信順序やメッセージの重複が重要でない場合。サポートされているすべての配信プロトコルは、スタンダードトピックにサブスクライブ可能。

メッセージの耐久性

  • 公開されたメッセージは、地理的に分離された複数のサーバーおよびデータセンターの間で保存されます。
  • サブスクライブされたエンドポイントが利用できない場合、Amazon SNS は配信の再試行ポリシーを実行します。
    • 配信の再試行ポリシー：サブスクライブされたエンドポイントをホストするシステムが利用できなくなったときにメッセージの配信を再試行する方法

    • 配信ポリシーが枯渇すると、Amazon SNS は配信の再試行を停止し、 メッセージを破棄 する (デッドレターキューが添付されていれば破棄されない)

    • 配信ポリシーの段階

      1. 即時の再試行段階(遅延なし) - 最初の配信の試行の直後に発生。この段階では再試行間の遅延時間はない。
      2. バックオフ前段階 - 即時の再試行段階の後。Amazon SNS は、バックオフ関数を適用する前に、この段階を使用して一連の再試行を試みる。この段階では、再試行回数と再試行間の遅延量を指定する。
      3. バックオフ段階 - この段階では、再試行バックオフ関数を使用して、再試行間の遅延を制御する。この段階では、最小遅延、最大遅延、および遅延が最小遅延から最大遅延までどれだけ速く増加するかを定義する再試行バックオフ関数を設定する。
      4. バックオフ後段階 - この段階はバックオフ段階の後。再試行回数とその間の遅延量を指定する。

デッドレターキュー

  • Amazon SNS サブスクリプションが受信者に正常に配信できないメッセージの送信先としての Amazon SQS キュー
  • どんなときにメッセージの配信が失敗する？
    • クライアントサイドの原因
      • 所有者がエンドポイント (Amazon SNS トピックにサブスクライブされている Lambda 関数など) を削除した場合
      • サブスクライブしているエンドポイントに添付されているポリシーを、Amazon SNS がエンドポイントにメッセージを配信できないように所有者が変更した場合
    • サーバーサイドの原因
      • サブスクライブされたエンドポイントを担当するシステムが利用できなくなった場合
      • Amazon SNS からの有効なリクエストを処理できないことを示す例外を返す場合

  • サーバー側のエラーが発生するとどんな挙動をする？

    • サーバー側のエラーが発生すると、一次バックオフ関数またはエクスポネンシャルバックオフ関数を使用して、失敗した配信を再試行する。
    • Amazon SQS または AWS Lambda によってバックアップされた AWS 管理のエンドポイントに起因するサーバー側エラーについては、Amazon SNS は 23 日間にわたって 100,015 回まで配信を再試行する (そうなんだ。。。)
    • カスタマー管理のエンドポイント (HTTP、SMTP、SMS、モバイルプッシュなど) では、SMTP、SMS、およびモバイルプッシュエンドポイントに対して、内部配信再試行ポリシーを 6 時間にわたって 50 回に設定する。

  • デッドレターキューのしくみ

  • メッセージをデッドレターキューから移動する方法

    • Amazon SQS コンシューマロジックの作成を避ける
      • デッドレターキューをイベントソースとして Lambda 関数に設定して、デッドレターキューを吸い出します。
    • Amazon SQS コンシューマロジックを作成する
      • Amazon SQS API、AWS SDK、または AWS CLI を使用して、デッドレターキュー内のメッセージのポーリング、処理、削除を行うカスタムコンシューマーロジックを記述します。

  • デッドレターキューのモニタリングとログ記録方法

メッセージのアーカイブ、リプレイ、および分析

coming soon

メッセージ属性

coming soon

メッセージのフィルター処理

coming soon

メッセージセキュリティ

coming soon