Amazon SNSメッセージで期待されるSLA（サービスレベル契約）は何ですか？

Question

私はリアルタイムアプリケーションのためにSNSを評価しようとしていましたが、実際にはメッセージを配信するのに2秒で<の時間が本当に早く必要でした。

私はAPAC地域に在住しているので、シンガポールのSNSには、Us-east-1ロケーションのLambdaに加入者がいます。

この設定では、ラムダを呼び出す際の待ち時間を把握してゼロ処理を行い、時間を記録するためのコードを実行しました。このインスタンスでラムダ呼び出し待ち時間も考慮されていると主張するかもしれません。それは本当です。ラムダが呼び出され実行され、< 2秒以内に返答が必要です。

私は23914のメッセージを送信しました。このメッセージのうち、トランスポート+ラムダの呼び出しには平均653.520ミリ秒あります。 ピークは約600995 ms（〜10分）で、これはpubsubのような技術ではひどい遅延です。 ラムダによってメッセージが送受信されたのは、< 653ミリ秒で、3797パケットまたは15％が平均時間を超えたことを意味します。

2958メッセージまたは12.36％が実行されるために1秒以上を要しました。 379メッセージまたは1.59％が呼び出されて実行されるのに2秒以上かかった（つまり、私のメッセージの1.6％がリアルタイムであるとみなされず、無視する必要があります） 82メッセージ10秒以上 64超過 〜 45秒後、遅延は10分である。私は10分の遅れで3パケットを持っています。

迷惑なことに、メッセージの処理時間を含めれば約2％は、〜24Kの小さなメッセージに対してリアルタイムで処理することはできません。

私が提示しようとしている尺度計算では、月に約216億メッセージを処理する必要があります。この規模では、私はリアルタイムで43億のメッセージを処理することができないと心配しています。

私はこの実験を考えて、SNSの規模がどれだけうまくいくかはわかりません。 ＃リアルタイムメッセージより少ない（読み込み> 2秒遅れ）でしょうか？それとも減少するだろうか？

私のインターネット接続の信頼性に疑問を呈する傾向があるかもしれません。私はこの実験をEC2でやり直しており、非常に似た結果を得ています。

Infactは、時間の種類がほぼ同じ時刻に一致しています。

固有の質問

1. SLAは、SNSのパフォーマンスには何ですか？
2. 間接的に：これらのSLAはAWSラムダサービスのものにどのように変換されますか？
3. これらの遅延が発生する可能性がある理由は何ですか？

Answer 1

おそらくラムダ機能を抑制していた可能性があります。 concurrent Lambda invocations is 100のデフォルト制限。 20Kのメッセージを送信した場合、ラムダの実行時間が短いにもかかわらず、その制限を超えた可能性があります。 SNS要求の実行時にラムダ機能が抑制されると、要求は再試行キューに送られ、最大3回まで再実行されます。これは長時間（最大1時間）にわたって発生することがよくあります。

機能のCloudWatchメトリックのスロットル数を確認できます（残念ながら、CloudWatchの保持期間が6か月前にテストを実施しました）。

Answer 2

最後に、SNS用のSLAがないことを確認しました。 SNSは、水平方向にスケーラビリティを持つように設計されており、メッセージをすぐに配信することはありません。

ラムダをAPI経由でパブリッシャから呼び出すことができず、呼び出しに渡されたイベント内にデータを格納できない理由はありますか？