Amazon SNS消息的預期SLA（服務級別協議）是什麼？

Question

我正試圖評估SNS的實時應用程序，我正在建設，需要非常快速的交付時間< 2秒來傳遞消息。

因爲我位於亞太地區，我在新加坡的SNS，其在LAMBDA在我們東-1位置的用戶。

鑑於此設置，我運行了一段代碼，試圖找出調用lambda時的延遲，並進行零處理並記錄時間。有人可能會爭辯說，在這種情況下你也有lambda調用延遲。這是真的。我需要Lambda被調用並執行並在2秒內回覆到<。

我發送了23914條消息，其中對於傳輸+ lambda調用，其平均值爲653.520 ms。 峯值大約600995毫秒（~10分鐘），這對於像pubsub這樣的技術來說是非常可怕的延遲。 關於20117消息已發送並由lambda接收，在< 653毫秒，這意味着3797或15％的數據包比平均時間多。

2958消息或12.36％接管1秒鐘執行。 379消息或1.59％花了2秒鐘被調用和執行（這意味着我的消息的1.6％不能被認爲是實時的並且必須被忽略） 82消息超過10秒 64超過20秒 它持續到〜 45秒，之後延遲10分鐘。我有3個數據包延遲10分鐘。

讓我困擾的是，大約2％（如果包括的處理時間也）不能實時處理爲24K〜消息的微小尺度我的消息。

在我試圖呈現的規模計算中，要求我每個月處理大約2160億條消息。在這個規模上，我擔心我無法實時處理43億條消息。

鑑於這種體驗，我不確定SNS的擴展程度如何。小於實時消息的消息（讀取> 2秒延遲）會更多嗎？還是會減少？

現在有可能會質疑我的互聯網連接可靠性，我重新在EC2上做了這個實驗，得到了非常相似的結果。

事實上，大約在同一時間匹配的時間種類的延誤。

具體問題

1. 哪些SLA到SNS的表現？
2. 間接：這些SLA如何轉化爲AWS Lambda服務的SLA？
3. 任何有關這些延遲可能發生的原因？

Answer 1

這裏最有可能發生的事情是節流的lambda函數。默認限制爲concurrent Lambda invocations is 100。如果發送了20K條消息，儘管lambda運行時間很短，您可能會超出該限制。當執行SNS請求時，如果您的lambda函數受到限制，請求會進入重試隊列並重新執行多達3次，這通常會在很長一段時間內（最多一小時）發生。

您可以在CloudWatch指標中看到該函數的節流數量（不幸的是，您在6個月發佈CloudWatch保留之前運行了測試）。

Answer 2

最後我檢查了SNS沒有SLA。 SNS被設計爲可水平擴展，並且（幾乎）從不丟棄消息而不快速傳遞。

是否有任何理由不能通過API從發佈者調用lambda並將數據存儲到傳遞給調用的事件中？