翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon SNS メッセージ配信の再試行
Amazon SNS は、各配信プロトコルの*配信ポリシー*を定義します。配信ポリシーは、サーバー側のエラーが発生したとき (サブスクライブされたエンドポイントをホストするシステムが利用できなくなったとき) に Amazon SNS がメッセージの配信を再試行する方法を定義します。配信ポリシーが枯渇すると、Amazon SNS は配信の再試行を停止し、にデッドレターキューが添付されていない限り、メッセージを破棄します。詳細については、「[Amazon SNS デッドレターキュー](sns-dead-letter-queues.md)」を参照してください。
## 配信プロトコルとポリシー
**注記**
HTTP/S を除き、Amazon SNS で定義された配信ポリシーを変更することはできません。HTTP/S のみがカスタムポリシーをサポートしています。「[HTTP/S 配信ポリシーの作成](#creating-delivery-policy)」を参照してください。
Amazon SNS は、配信の再試行にジッタリングを適用します。詳細については、『*AWS アーキテクチャブログ*』の「[エクスポネンシャルバックオフとジッター](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/)」を参照してください。
**HTTP/S エンドポイントのポリシー再試行時間は、全体で 3,600 秒を超えることはできません。これはハード制限であり、時間を延長することはできません**。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/sns/latest/dg/sns-message-delivery-retries.html)
¹Firehose プロトコルのスロットリングエラーの場合、Amazon SNS はカスタマーマネージドエンドポイントと同じ配信ポリシーを使用します。
## 配信ポリシーの段階
次の図は、配信ポリシーの段階を示しています。
![\[X Y 軸図では、Time が X 軸、Initial Delivery Attempt が Y 軸として表示されています。配信ポリシーは、Y 軸の即時の再試行段階から始まり、X 軸上でバックオフ前段階、バックオフ段階、バックオフ後段階と続きます。\]](http://docs.aws.amazon.com/ja_jp/sns/latest/dg/images/sns-delivery-policy-phases.png)
各配信ポリシーは、4 つの段階で構成されます。
1. **即時の再試行段階 (遅延なし)** – 最初の配信の試行の直後に発生します。この段階では再試行間の遅延時間はありません。
1. **バックオフ前段階** – この段階は即時の再試行段階の後に続きます。Amazon SNS は、バックオフ関数を適用する前に、この段階を使用して一連の再試行を試みます。この段階では、再試行回数と再試行間の遅延量を指定します。
1. **バックオフ段階** - この段階では、再試行バックオフ関数を使用して、再試行間の遅延を制御します。この段階では、最小遅延、最大遅延、および遅延が最小遅延から最大遅延までどれだけ速く増加するかを定義する再試行バックオフ関数を設定します。バックオフ関数は、数論的、指数、幾何学的、または一次です。
1. **バックオフ後段階** – この段階はバックオフ段階の後に続きます。再試行回数とその間の遅延量を指定します。これが最終段階です。
## HTTP/S 配信ポリシーの作成
Amazon SNS が HTTP/S エンドポイントへのメッセージ配信を再試行する方法を定義できます。そのためには、*遅延なし*、*バックオフ前*、*バックオフ*、*バックオフ後*の 4 つの段階を持つ配信ポリシーを使用します。このポリシーを使用すると、デフォルトの再試行設定を上書きし、HTTP サーバーの処理能力に合わせてカスタマイズできます。
HTTP/S 配信ポリシーは、**トピック**レベルまたは**サブスクリプション**レベルのいずれかで JSON オブジェクトとして設定できます。
+ **トピックレベルのポリシー** – トピックにリンクされたすべての HTTP/S サブスクリプションに適用されます。[https://docs.aws.amazon.com/sns/latest/api/API_CreateTopic.html](https://docs.aws.amazon.com/sns/latest/api/API_CreateTopic.html) または [https://docs.aws.amazon.com/sns/latest/api/API_SetTopicAttributes.html](https://docs.aws.amazon.com/sns/latest/api/API_SetTopicAttributes.html) API アクションを使用して、このポリシーを設定します。
+ **サブスクリプションレベルのポリシー** – 特定のサブスクリプションにのみ適用されます。[https://docs.aws.amazon.com/sns/latest/api/API_Subscribe.html](https://docs.aws.amazon.com/sns/latest/api/API_Subscribe.html) または [https://docs.aws.amazon.com/sns/latest/api/API_SetSubscriptionAttributes.html](https://docs.aws.amazon.com/sns/latest/api/API_SetSubscriptionAttributes.html) API アクションを使用して、このポリシーを設定します。
または、 CloudFormation テンプレートで [AWS::SNS::Subscription](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-sns-subscription.html) リソースを使用することもできます。
HTTP/S サーバーの処理能力に基づいて配信ポリシーをカスタマイズする必要があります。
+ **すべてのサブスクリプションで 1 つのサーバーを使用** – トピック内のすべての HTTP/S サブスクリプションが同じサーバーを使用している場合は、配信ポリシーをトピック属性として設定して、すべてのサブスクリプション間で一貫性を確保します。
+ **サブスクリプションごとに異なるサーバーを使用** – 各サブスクリプションが異なるサーバーをターゲットにしている場合は、特定のサーバーの処理能力に合わせて、サブスクリプションごとに固有の配信ポリシーを作成します。
リクエストポリシーに `Content-Type` ヘッダーを設定して、通知のメディアタイプを指定することもできます。デフォルトでは、Amazon SNS は、コンテンツタイプが `text/plain; charset=UTF-8` に設定された HTTP/S エンドポイントにすべての通知を送信します。ただし、リクエストポリシーの [`headerContentType`](#header-content-type) フィールドを使用して、このデフォルト設定を上書きできます。
次の JSON オブジェクトは、4 つの段階で構成された再試行を持つ配信ポリシーを定義します。
1. **遅延なし段階** – 直ちに 3 回再試行します。
1. **バックオフ前段階** – 1 秒間隔で 2 回再試行します。
1. **バックオフ段階** – 1～60 秒の範囲の指数関数的遅延で 10 回再試行します。
1. **バックオフ後段階** – 60 秒の一定間隔で 35 回再試行します。
Amazon SNS では、メッセージを配信するために合計 **50 回試行**し、その後でメッセージを破棄します。すべての再試行の終了後に配信できないメッセージを保持するには、配信できないメッセージをデッドレターキュー (DLQ) に移動するようにサブスクリプションを設定します。詳細については、「[Amazon SNS デッドレターキュー](sns-dead-letter-queues.md)」を参照してください。
Amazon SNS では、すべての 5XX エラーと 429 エラー (送信されたリクエストが多すぎます) を再試行可能なエラーとして扱います。これらのエラーには、配信ポリシーが適用されます。他のすべてのエラーは永続的なエラーとして扱われ、再試行は行われません。
**注記**
この配信ポリシーは `maxReceivesPerSecond` プロパティを使用して、各サブスクリプションで 1 秒あたり平均 10 件のメッセージになるように配信トラフィックをスロットリングします。このメカニズムは、高トラフィックによって HTTP/S エンドポイントの負荷が高くなるのを防ぐ際に役立ちますが、平均配信レートを維持するように設計されており、厳密な上限を課すものではありません。特に発行レートがスロットリング制限よりも大幅に高い場合、配信トラフィックが指定された制限を超えることがあります。
発行 (インバウンド) トラフィックが配信 (アウトバウンド) レートを超えると、メッセージバックログが発生し、配信レイテンシーが高くなる可能性があります。このような問題を回避するには、`maxReceivesPerSecond` の値が、HTTP/S サーバーの処理能力とワークロードの要件に合致していることを確認してください。
次の配信ポリシーの例では、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 つのオプションのいずれか。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/sns/latest/dg/sns-message-delivery-retries.html) **デフォルト:** linear |
| maxReceivesPerSecond | 各サブスクリプションにおける 1 秒あたりのメッセージ配信の最大平均数。 | 1 以上**デフォルト:** スロットリングなし (配信レートに制限なし) |
| headerContentType | HTTP/S エンドポイントに送信される通知のコンテンツタイプ。 | リクエストポリシーが定義されていない場合、コンテンツタイプはデフォルトで `text/plain; charset=UTF-8` に設定されます。 サブスクリプションに対する raw メッセージ配信が無効になっている場合 (デフォルト)、または配信ポリシーがトピックレベルで定義されている場合、サポートされるヘッダーコンテンツタイプは `application/json` および `text/plain` です。 サブスクリプションに対する raw メッセージ配信を有効にすると、以下のコンテンツタイプがサポートされます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/sns/latest/dg/sns-message-delivery-retries.html) |
Amazon SNS は、次の式を使用して、バックオフ段階での再試行回数を計算します。
```
numRetries - numNoDelayRetries - numMinDelayRetries - numMaxDelayRetries
```
次の 3 つのパラメータを使用して、バックオフ段階での再試行の頻度を制御できます。
+ **`minDelayTarget`** – バックオフ段階における最初の再試行の遅延を設定します。
+ **`maxDelayTarget`** – バックオフ段階における最後の再試行の遅延を設定します。
+ **`backoffFunction`** – 最初の再試行と最後の再試行の間に行われるすべての再試行について、遅延を計算するために Amazon SNS で使用されるアルゴリズムを決定します。利用可能な 4 つの再試行バックオフ関数から選択できます。
次の図は、さまざまな再試行バックオフ関数が、バックオフ段階における再試行間の遅延にどのように影響するかを示しています。この例で使用される配信ポリシーには、**合計再試行回数 10 回**、**最小遅延時間 5 秒**、**最大遅延時間 260 秒**の設定が含まれます。
+ **縦軸**は、再試行ごとの遅延 (秒単位) を示します。
+ **横軸**は、最初の試行から 10 回目の試行までの再試行シーケンスを示します。
![\[この図は、指数関数、数論的関数、一次関数、幾何学的関数の 4 つのバックオフ関数に基づいて 10 回の試行で再試行の遅延がどのように進行するかを示しています。各色付き線は関数の遅延パターンを表します。指数関数: 急激に増加し、最も速く最大遅延に達します。一次関数: 再試行するたびに着実に増加します。数論的関数および幾何学的関数: 中程度の増加を示します。指数関数よりも急激ですが、一次関数ほど急激ではありません。すべての線は最小遅延である 5 秒付近から始まり、10 回目の再試行までに最大遅延である 260 秒に達します。\]](http://docs.aws.amazon.com/ja_jp/sns/latest/dg/images/backoff-graph.png)