Amazon SNS メッセージ配信の再試行 - Amazon Simple Notification Service

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

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

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

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

注記
  • を除いて、 はカスタムポリシーHTTP/S, you can't change Amazon SNS-defined delivery policies. Only HTTP/Sをサポートします。「HTTP/S 配信ポリシーの作成」を参照してください。

  • Amazon SNSは配信再試行にジッターを適用します。詳細については、『AWS アーキテクチャブログ』の「エクスポネンシャルバックオフとジッター」を参照してください。

  • HTTP/S エンドポイントの合計ポリシー再試行時間は 3,600 秒を超えることはできません。これはハード制限であり、時間を延長することはできません

[エンドポイントタイプ] 配信プロトコル 即時の再試行 (遅延なし) 段階 バックオフ前段階 バックオフ段階 バックオフ後段階 合計試行回数
AWS マネージドエンドポイント Amazon Data Firehose1 3 回、遅延なし 2 回、1 秒間隔で 10 回、エクスポネンシャルバックオフで 1 秒から 20 秒まで 100,000 回、20 秒間隔で 100,015 回、23 日間
AWS Lambda
Amazon SQS
カスタマー管理のエンドポイント SMTP 0 回、遅延なし 2 回、10 秒間隔で 10 回、エクスポネンシャルバックオフで 10 秒から 600 秒まで (10 分) 38 回、600 秒 (10 分) 間隔で 50 回、6 時間以上
SMS
モバイルプッシュ

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

配信ポリシーの段階

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

Time を x 値、Initial Delivery Attempt を y 値として表示する x y 軸図。配信ポリシーは、y 軸の即時再試行フェーズで始まり、x 軸でバックオフ前フェーズ、バックオフフェーズ、およびバックオフ後フェーズが続きます。

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

  1. 即時の再試行段階(遅延なし) - この段階は遅延なしの段階とも呼ばれ、最初の配信の試行の直後に発生します。この段階では再試行間の遅延時間はありません。

  2. バックオフ前段階 - この段階は即時の再試行段階の後に続きます。Amazon SNSはこのフェーズを使用して、バックオフ関数を適用する前に一連の再試行を試みます。この段階では、再試行回数と再試行間の遅延量を指定します。

  3. バックオフ段階 - この段階では、再試行バックオフ関数を使用して、再試行間の遅延を制御します。この段階では、最小遅延、最大遅延、および遅延が最小遅延から最大遅延までどれだけ速く増加するかを定義する再試行バックオフ関数を設定します。バックオフ関数は、数論的、指数、幾何学的、または一次です。

  4. バックオフ後段階 - この段階はバックオフ段階の後に続きます。再試行回数とその間の遅延量を指定します。これが最終段階です。

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

配信ポリシーとその 4 SNS つのフェーズを使用して、Amazon が HTTP/S エンドポイントへのメッセージの配信を再試行する方法を定義できます。Amazon SNS では、HTTPサーバーの容量に基づいてポリシーをカスタマイズする場合などに、HTTPエンドポイントのデフォルトの再試行ポリシーを上書きできます。

トピックに関連付けられたHTTP/S delivery policy as a JSON object at the subscription or topic level. When you define the policy at the topic level, it applies to all HTTP/Sサブスクリプションを設定できます。配信ポリシーをサブスクリプションレベルで設定するには、 Subscribe または SetSubscriptionAttributesAPIアクションのいずれかを使用できます。配信ポリシーをトピックレベルで設定するには、 CreateTopic または SetTopicAttributesAPIアクションのいずれかを使用できます。または、 AWS CloudFormation テンプレートで AWS::SNS::Subscription リソースを使用することもできます。

ポリシーがターゲットとするHTTP/S server's capacity. You can set the policy as a topic attribute or a subscription attribute. If all HTTP/S subscriptions in your topic target the same HTTP/S server, we recommend that you set the delivery policy as a topic attribute, so that it remains valid for all HTTP/S subscriptions in the topic. Otherwise, you must compose a delivery policy for each HTTP/S subscription in your topic, according the capacity of the HTTP/Sサーバーに応じて、配信ポリシーをカスタマイズする必要があります。

リクエストポリシーに Content-Type ヘッダーを設定して、通知のメディアタイプを指定することもできます。デフォルトでは、Amazon はコンテンツタイプを に設定して、すべての通知を HTTP/S エンドポイントSNSに送信しますtext/plain; charset=UTF-8。Amazon SNS では、デフォルトのリクエストポリシーを上書きできます。サポート対象の headerContentType と制約事項については、次の表を参照してください。

次のJSONオブジェクトは、失敗した HTTP/S 配信試行を再試行SNSするように Amazon に指示する配信ポリシーを表しています。

  1. 遅延なし段階ですぐに 3 回

  2. バックオフ前段階で 2 回 (1 秒間隔で)

  3. 10 回 (1 秒から 60 秒までのエクスポネンシャルバックオフで)

  4. バックオフ後段階で 35 回 (60 秒間隔で)

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

注記

この配信ポリシーは、 maxReceivesPerSecondプロパティを使用して、配信を 1 秒あたり 10 個以下にスロットリングSNSするように Amazon に指示します。このセルフスロットリングレートは、配信された (アウトバウンドトラフィック) よりも多くのメッセージが発行される (インバウンドトラフィック) 可能性があります。インバウンドトラフィックがアウトバウンドトラフィックよりも多い場合、サブスクリプションによって大きなメッセージバックログが蓄積され、メッセージ配信のレイテンシーが高くなる可能性があります。配信ポリシーでは、必ず maxReceivesPerSecond ワークロードに悪影響を与えない値を指定してください。

注記

この配信ポリシーは、 への 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 つの属性があります。

ポリシー 説明 制約事項
minDelayTarget 再試行の最小遅延。

単位:

1 から最大遅延まで

デフォルト: 20

maxDelayTarget 再試行の最大遅延。

単位:

最小遅延から 3,600 まで

デフォルト: 20

numRetries 即時再試行、バックオフ前再試行、バックオフ再試行、ポストバックオフ再試行の合計数。 0~100

デフォルト: 3

numNoDelayRetries 即時に行う再試行の回数。再試行の間に遅延はありません。 0 以上

デフォルト: 0

numMinDelayRetries バックオフ前段階での再試行回数と、これらの間に指定された最小遅延時間。 0 以上

デフォルト: 0

numMaxDelayRetries バックオフ後段階での再試行回数と、その間の最大遅延。 0 以上

デフォルト: 0

backoffFunction 再試行間のバックオフのモデル。

次の 4 つのオプションのいずれか。

  • 数論的

  • 指数

  • 幾何学的

  • 一次

デフォルト: linear

maxReceivesPerSecond サブスクリプションごとの 1 秒あたりの配信の最大数。 1 以上

デフォルト: スロットリングなし

headerContentType

HTTP/S エンドポイントに送信される通知のコンテンツタイプ。

リクエストポリシーが定義されていない場合、コンテンツタイプはデフォルトで text/plain; charset=UTF-8 に設定されます。

サブスクリプションに対する raw メッセージ配信が無効になっている場合 (デフォルト)、または配信ポリシーがトピックレベルで定義されている場合、サポートされるヘッダーコンテンツタイプは application/json および text/plain です。

サブスクリプションに対する raw メッセージ配信を有効にすると、以下のコンテンツタイプがサポートされます。

  • text/css

  • text/csv

  • text/html

  • text/plain

  • text/xml

  • application/atom+xml

  • application/json

  • application/octet-stream

  • application/soap+xml

  • アプリケーション/x-www-form-urlencoded

  • application/xhtml+xml

  • application/xml

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

numRetries - numNoDelayRetries - numMinDelayRetries - numMaxDelayRetries

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

  • minDelayTarget - バックオフ段階の最初の再試行に関連する遅延を定義します。

  • maxDelayTarget - バックオフ段階の最後の再試行に関連する遅延を定義します。

  • backoffFunction – Amazon がバックオフフェーズの最初の再試行と最後の再試行の間のすべての再試行に関連する遅延を計算するためにSNS使用するアルゴリズムを定義します。4 つの再試行バックオフ関数の 1 つを使用できます。

次の図は、各再試行バックオフ関数が、バックオフ段階での再試行に関連する遅延にどのように影響するかを示しています。再試行の合計回数を 10、最小遅延を 5 秒、最大遅延を 260 秒に設定した配信ポリシーです。縦軸は、10 回ごとの再試行に関連する遅延時間を秒単位で表します。横軸は、最初の試行から 10 回目の試行までの再試行回数を表します。

配信ポリシーのバックオフフェーズ中の再試行の遅延時間。再試行回数は 10 回を超えます。指数関数、算術関数、線形関数、ジオメトリ関数の 4 つの異なるバックオフ関数が、それぞれ異なる色の線で示され、再試行ごとに遅延がどのように増加するかを示します。指数バックオフ関数は、最も急激な上昇を示し、他の関数よりも速く最大遅延近くに達し、線形関数は安定した速度で増加します。算術関数とジオメトリ関数は、遅延が中程度に増加しますが、線形モデルよりも急激です。各行は最小遅延 5 秒前後で始まり、10 回目の再試行で最大遅延 260 秒に進みます。