Amazon SNS メッセージ配信の再試行

Amazon SNS は、各配信プロトコルの配信ポリシーを定義します。配信ポリシーは、サーバー側のエラーが発生したとき (サブスクライブされたエンドポイントをホストするシステムが利用できなくなったとき) に Amazon SNS がメッセージの配信を再試行する方法を定義します。配信ポリシーが枯渇すると、Amazon SNS は配信の再試行を停止し、にデッドレターキューが添付されていない限り、メッセージを破棄します。詳細については、「Amazon SNS デッドレターキュー」を参照してください。

配信プロトコルとポリシー

¹Firehose プロトコルのスロットリングエラーの場合、Amazon SNS はカスタマーマネージドエンドポイントと同じ配信ポリシーを使用します。

配信ポリシーの段階

次の図は、配信ポリシーの段階を示しています。

各配信ポリシーは、4 つの段階で構成されます。

HTTP/S 配信ポリシーの作成

Amazon SNS が HTTP/S エンドポイントへのメッセージ配信を再試行する方法を定義できます。そのためには、遅延なし、バックオフ前、バックオフ、バックオフ後の 4 つの段階を持つ配信ポリシーを使用します。このポリシーを使用すると、デフォルトの再試行設定を上書きし、HTTP サーバーの処理能力に合わせてカスタマイズできます。

HTTP/S 配信ポリシーは、トピックレベルまたはサブスクリプションレベルのいずれかで JSON オブジェクトとして設定できます。

または、CloudFormation テンプレートで AWS::SNS::Subscription リソースを使用することもできます。

HTTP/S サーバーの処理能力に基づいて配信ポリシーをカスタマイズする必要があります。

リクエストポリシーに Content-Type ヘッダーを設定して、通知のメディアタイプを指定することもできます。デフォルトでは、Amazon SNS は、コンテンツタイプが text/plain; charset=UTF-8 に設定された HTTP/S エンドポイントにすべての通知を送信します。ただし、リクエストポリシーの headerContentType フィールドを使用して、このデフォルト設定を上書きできます。

次の JSON オブジェクトは、4 つの段階で構成された再試行を持つ配信ポリシーを定義します。

Amazon SNS では、メッセージを配信するために合計 50 回試行し、その後でメッセージを破棄します。すべての再試行の終了後に配信できないメッセージを保持するには、配信できないメッセージをデッドレターキュー (DLQ) に移動するようにサブスクリプションを設定します。詳細については、「Amazon SNS デッドレターキュー」を参照してください。

Amazon SNS では、すべての 5XX エラーと 429 エラー (送信されたリクエストが多すぎます) を再試行可能なエラーとして扱います。これらのエラーには、配信ポリシーが適用されます。他のすべてのエラーは永続的なエラーとして扱われ、再試行は行われません。

次の配信ポリシーの例では、HTTP/S 通知のデフォルトのコンテンツタイプを application/json に上書きします。

{
    "healthyRetryPolicy": {
        "minDelayTarget": 1,
        "maxDelayTarget": 60,
        "numRetries": 50,
        "numNoDelayRetries": 3,
        "numMinDelayRetries": 2,
        "numMaxDelayRetries": 35,
        "backoffFunction": "exponential"
    },
    "throttlePolicy": {
        "maxReceivesPerSecond": 10
    },
    "requestPolicy": {
        "headerContentType": "application/json"
    }
}

配信ポリシーは、再試行ポリシー、スロットルポリシー、リクエストポリシーで構成されます。配信ポリシーには、合計で 9 つの属性があります。

Amazon SNS は、次の式を使用して、バックオフ段階での再試行回数を計算します。

numRetries - numNoDelayRetries - numMinDelayRetries - numMaxDelayRetries

次の 3 つのパラメータを使用して、バックオフ段階での再試行の頻度を制御できます。

次の図は、さまざまな再試行バックオフ関数が、バックオフ段階における再試行間の遅延にどのように影響するかを示しています。この例で使用される配信ポリシーには、合計再試行回数 10 回、最小遅延時間 5 秒、最大遅延時間 260 秒の設定が含まれます。