실시간 응용 프로그램을 위해 SNS를 평가하려고했는데 실제로 메시지를 전달하는 데 2 초가 걸리는 < 시간이 정말 빨라야합니다.Amazon SNS 메시지에서 예상되는 SLA (서비스 수준 계약)는 무엇입니까?
나는 APAC 지역에 위치해 있기 때문에 싱가폴에 SNS가 있고 우리 람다는 Us-east-1 위치에 있습니다.
이 설정을 감안할 때 나는 람다를 호출 할 때 대기 시간을 알아 내고 제로 처리를하고 시간을 기록하려고하는 코드를 실행했다. 하나는이 인스턴스에서 람다 호출 대기 시간도 고려했다고 주장 할 수 있습니다. 뭐가 진실이지. 나는 람다가 호출되어 실행되어야하고 < 2 초 내에 응답해야합니다.
전송 및 람다 호출에 대해 평균 653.520 ms 인 23914 개의 메시지를 보냈습니다. 최대 봉우리가 600995 ms (~ 10 분)인데, 이는 pubsub와 같은 기술의 경우 지독한 대기 시간입니다. 
대략 20117 메시지는 람다가 < 653 ms에 보내고받은 것으로, 이는 3797 패킷 또는 15 %가 평균 시간보다 오래 걸렸음을 의미합니다.
2958 메시지 또는 12.36 %가 실행될 때 1 초 이상 걸립니다. 379 개의 메시지 또는 1.59 %가 호출되고 실행될 때 2 초 이상 걸렸습니다. 즉, 내 메시지의 1.6 %는 실시간으로 간주되어 무시할 수 없습니다. 10 초에 걸쳐 82 개의 메시지가 표시됩니다. 64 초에 ~ 45 초 후 지연 시간은 10 분입니다. 나는 10 분 지연 3 패킷 있습니다.
나를 괴롭히는 것은 내 메시지의 약 2 % (처리 시간을 포함하는 경우)를 ~ 24K 개의 작은 크기의 메시지로 실시간 처리 할 수 없다는 것입니다.
규모를 계산할 때 한 달에 약 216 억 메시지를 처리해야합니다. 이 규모에서는 실시간으로 43 억 개의 메시지를 처리 할 수 없게 될까봐 걱정합니다.
이 실험을 감안할 때 SNS가 얼마나 잘 확장되는지 확신 할 수 없습니다. 실제 메시지보다 #of 짧을 것입니다 (2 초 이상 읽음). 아니면 감소할까요?
이제 인터넷 연결 안정성에 의문을 제기하는 경향이 있습니다.이 실험을 EC2에서 다시했고 비슷한 결과를 얻었습니다.
Infact 같은 시간에 일치하는 시간 종류의 지연. SLA를 SNS 성능은 무엇
특정 질문
- ?
- 간접적으로 : 이러한 SLA는 AWS Lambda 서비스의 SLA로 어떻게 변환됩니까?
- 이러한 지연이 발생할 수있는 이유는 무엇입니까?
SNS와 관련된 확장 성 제한의 표시 일 가능성은 거의 없습니다. 조사 할 경로 중 하나는 [SNS 메시지 배달 상태] (http://docs.aws.amazon.com/sns/latest/dg/msg-status-topics.html)로, 더 많은 통찰력을 줄 수 있습니다. [SNS는 정식 전달 SLA가없는 것 같습니다] (https://forums.aws.amazon.com/thread.jspa?threadID=222330). –