안녕하세요. 아마존 SNS 서비스를 이용해서 모바일 푸시를 구현하려고 하고 있는데,…

안녕하세요.
아마존 SNS 서비스를 이용해서 모바일 푸시를 구현하려고 하고 있는데, 어떻게 아키텍쳐를 만들어야 바람직할지 잘 그림이 그려지지 않네요.
혹시 SNS를 이용한 모바일 푸시 서비스를 만들어보신 분이 계시다면 관련 경험이나 지식을 공유해주시면 감사하겠습니다.
제가 현재 생각하기로는 오토스케일이 걸려있는 EC2 인스턴스들이 푸시를 보낼 필요가 있으면 SNS를 통해서 SQS에 관련 id값 정도만 던지면 노티 전용 람다 또는 EC2에서 돌아가는 노티 서비스가 DB를 통해 노티 보내질 내용을 가공하고 SNS를 통해서 단말까지 보낸다고 생각하고 있거든요..
구글/SlideShare를 뒤져봐도 관련 자료가 나오지 않으니 제가 뭔가 잘못 생각하고 있는 건 아닌가 싶기도 하고..;;

2 thoughts on “안녕하세요. 아마존 SNS 서비스를 이용해서 모바일 푸시를 구현하려고 하고 있는데,…

  1. sns topic에 subscription 상태로 디바이스들을 등록하시고 등록시 발급되는 arn 값을 디바이스 – arn 매핑 테이블로 보관해놓고 ec2 인스턴스에서 해당 arn값을 sns sdk를 통해서 push content와 함께 실어서 보내는 flow로 서비스 운영했었습니다.(지금은 퇴사해서. 아직도 그대로 인프라는 유지중) 대량 발송의 경우는 topic arn에다 content를 실어서 sns sdk 호출하구요. topic 단위로 다루실 일이 없다면 단일 topic으로 운영하셔도 되겠지만 공식문서에서 봤던거 같은데 토픽내 subscription 개수 제한도 있었던걸로 기억합니다. 제 경험은 2015년 기준입니다. subscription 지우는게 dashboard를 통해서 하는건 1-2개 단위지 수만-수백만 단위 넘어가면 sdk를 통해서 해야 되는데 이 부분 개선됐는지 모르겠는데 정말 느립니다. pagenation 처리가 되어서 마지막 record면 다음 page 다시 긁어오는 호출해주고 이런식의 loop logic 이었던걸로 기억하는데 암튼 엄청 느려서 결국엔 새로운 토픽 만들어서 신규 subscription 생성하는게 더 빨랐던 경험이 있습니다. 두서 없이 적어서 필요한 내용이신지는 모르겠네요.

  2. 모바일 푸시는 SNS 내부에 APP 을 이용하여, crendential 을 던진 뒤 나오는 AppArn 을 이용해서 보내실 수 있습니다. 위에 창용님이 이야기하신 것 처럼 topic 을 사용하면 다량의 앱에 ‘같은내용’의 모바일 푸시도 보낼 수 있습니다. (topic subscription 제한 10,000 은 풀렸습니다.)
    결국은 appArn 이 Key 가 될 수 있으며, appArn 을 그루핑하면 topicArn 이 key 가 될 수 있습니다.

    말씀해주신 SNS – SQS 를 통해서 메세지를 큐잉하고 보내는 방식을 저도 사용하고 있는데, 그건 인프라 쪽이니 어떻게 구현해도 크게 상관이 없으실 것 같습니다.

    몇가지 팁을 알려드리자면, 창용님이 말씀하신것처럼 다량의 유저를 다루기 시작하면 API call 을 이용해야하는데 이게 생각보다 느립니다. 유저가 몇백만씩 되면.. 진짜 힘들어집니다. 저희는 ec2 t2.micro 100대쯤 띄워서 이런 것들을 처리하고 있는데, 한대가 초당 60개 정도의 API call 이 가능합니다. (물론 API Throttling 이 안 걸린다는 가정하에..)
    각 계정당 토픽 한도가 100개 이니, 이걸 먼저 늘려놓고 작업하시는 걸 추천드립니다.
    푸시를 보내는 것 보다는, 보냈는데 안 간 경우, 앱이 지워진 경우 등에 대해서 또다시 topic 을 연결해서 내용을 받을 수 있고, cloudwatch 의 logs 에도 로그가 남는데 그 부분까지 잘 구현하셔야 실제로 서비스에서 사용하실 수 잇을 것 같습니다.

답글 남기기

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