아마존에서 메시지를 broadcasting하는 방법 중의 하나로 SNS가 존재합니다. 즉 동일…

아마존에서 메시지를 broadcasting하는 방법 중의 하나로 SNS가 존재합니다. 즉 동일 메시지를 Topic Subscriber에게 모두 전달해야 할 경우 Console이나 Subscription API를 통해 endpoint를 등록하면 되지만 이 경우 auto scaling이 안될 수 있습니다.
대안으로 EC2 인스턴스 내에서 pub/sub 솔루션을 사용하여 처리해도 되겠지만, AWS API만을 사용하여 처리하는 방법에는 어떤 것들이 있을까요?

9 thoughts on “아마존에서 메시지를 broadcasting하는 방법 중의 하나로 SNS가 존재합니다. 즉 동일…

  1. SQS의 경우 즉시 푸시알림을 받을 수 없는 단점이 있습니다. 게다가 SQS의 경우 폴링으로 인한 time delay가 발생하게 되고 가끔 폴링 타임의 3~4배수의 시간동안 메시지가 조회되지 않는 경우도 존재합니다. 일반적인 메시징 시스템의 P2P, pub/sub이 각각 SQS, SNS인데 SQS는 의도하는 목적에 부합하지 읺는 것 같아요.

  2. SNS를 사용하여 등록된 subscriber가 모두 메시지를 받고자 할 경우에 ELB를 사용하게 되면 ELB에 연결된 모든 인스턴스로 메시지가 날아가게 되나요? ELB를 타게 될 경우 연결된 인스턴스 중 하나로 메시지가 전송되어 결국 메시지 전체 전송이라는 원래 목적이 상실될 것 같아요. <-- 우선 이게 질문의 주 목적이었구요.

  3. 결국 모든 인스턴스가 메시지를 받고자 한다면 ELB를 사용하지 못하고 auto scaling 대상인 인스턴스가 등록될때마다 SNS의 endpoint로 등록을 해야 합니다. 아마존에서는 스팸을 막기 위해 endpoint JRL에 대한 verification을 진행하는데 이게 HTTP를 사용할 경우 요청으로 들어온 키값을 다시 Subscription API를 통해 인증작업을 해줘야 작동이 된다는 거지요. 억지로 만들려면 할 수 있지만 HTTP URL의 경우 요청중 SNS에서 온 값을 다시 파악하고 API를 써야 한다는 부가적이 작업이 필요하겠지요.

  4. 아아. 등록된 subscriber가 같은 메세지를 모두 수신해야 되는 상황인가 보군요. SQS같은 경우는 topic 모델이 없어서 좀 미묘할 수 있을꺼 같습니다. 제 생각에는 말씀하신 것처럼 SNS에 subscribe 할 수 있도록 API구성을 하거나, 하지 않으면 지금 AWS상에서는 딱 맞는 솔루션은 없을꺼 같네요. ELB는 모든 인스턴스로 요청을 포워딩 하지 않습니다

답글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다.