© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
강승욱
플랫폼개발팀 서비스운영파트
AWS아키텍트담당
Amazon SNS로 지속적 관리가 가능한
대용량 푸쉬 시스템 구축 여정
떠나는건 마음대로지만 돌아오는건 아닙니다.
Introducing me.
https://www.linkedin.com/in/seunguk/
joel@glowmee.com
디지털 떠돌이, 입개발자
AWS로 서버를 배운 듣보잡 개발자
JAVA조금 PHP조금많이 Python조금
재능마켓 크몽
번역서비스 옥셔노리
워드프레스의 단비스토어를 잠시 거쳐
글로우데이즈에 정착해서 글로우픽 서비스를
하고있습니다.
야크의 털을 깎을수 밖에 없다면 예쁘게 깎고 싶어요.
본 강연에서 다룰 내용
- SNS의 개요
- SNS Topic의 운영
- 전체푸시와 그루핑 푸시
- SNS의 토큰 상태관리 및 상태 응답 받기
- DynamoDB로 토큰 분리하기
- SQS와의 긴밀함
- CloudWatchLogs로 측정하는 푸시 측정
개미는 지옥을 그냥 지나치지
못한다.
Legacy Push System
DataBase
Get Token
foreach
GCM
APNS
Legacy Push System
❏ 1000개씩 끊어 보내더라도 오래걸림
❏ 보낸 푸시의 상태와 모니터링의 어려움
❏ 토큰 변경 리스폰스 처리의 어려움
❏ 레거시 시스템의 토픽 활용의 어려움
어쨌든 SNS로 푸시 성공하기
SNS Structure
❏ Topics : 어플리케이션 엔드포인트들이
구독단위로 그루핑 되어있는 것
❏ Application : 플랫폼 별로 토큰을
적재할 수 있는 곳. 다양한 플랫폼 지원
❏ Subscriptions : 어플리케이션이 토픽을
구독하고 있는 값을 담고 있는 곳.
이곳을 체크해서 해당 엔드포인트가
특정 토픽을 구독하고있는지 체크가
가능.
Application Endpoint Register
대량등록
❏ 어플리케이션 엔드포인드 생성
토큰을 저장, 전체푸시 토픽 구독처리
❏ User data에 값을 넣으면 중복된 값을 넣으려고 할때에
예외가 발생한다. 값이 없으면 중복된 값이 어느 한계선까지
SNS Push Publish
❏ 해당 엔드포인트 혹은
토픽으로 단순 문자열
혹은 JSON Payload를
구성해서 보낼 수
있습니다.
❏ TTL은 푸시 메세지의
생명 시간을 정하는
것입니다.
Endpoint Async
언덕을 넘어서니 다시 언덕 두개
SNS Feature
SNS Set Event Notifications
❏ 발생된 이벤트를 수신할 토픽을 지정
이벤트등록
Endpoint Event Receive
❏ 해당 토픽으로 오늘 이벤트
메세지를 수신할
프로토콜은 많이
존재하지만 값이싸고,
순차처리에 용이한 SQS를
사용
❏ 어플리케이션의 이벤트를
수신할 토픽을 만들고
어플리케이션 액션에
등록해준다.
Endpoint Event Receive
❏ 어플리케이션에서 Endpoint Event Notifications를 Topic으로 보내고 그 이벤트 메세지를 다시
큐로 쌓은 후
람다가 병렬처리 혹은 배치처리로 변경사항을 다이나모에 존재하는 토큰에 반영한다.
Endpoint Token Management Point
❏ 기존의 회원 테이블에서는 한 회원에 하나의 플랫폼
엔드포인트만이 등록가능
❏ 비회원 유저를 위한 토큰 저장 테이블이 따로존재
❏ 회원이 한 기기로 로그인과 로그아웃을 반복하거나,
다른 계정으로 접속시의 처리비용이 높아짐
❏ 푸시를 위한 필요회원정보 : 회원항번,UUID,DEVICE
TOKEN,Endpoint ARN,isPush,SubscribeARN
❏ 정보가 많아짐에 따라 푸시관련 정보를 따로 분리필요
Solution
다시 레거시로 갈까?
Grouping Push
Legacy
+ ARN취득 => SNS전송
Grouping Push
Grouping Push
case3. 회원의 토픽화?
WatchOut!
❏ SQS Default Visibility Timeout
❏ Scale-Out, Provisoned Capacity 필요
❏ 람다 병렬처리 -> 트리거
❏ APNS 어플리케이션 인증은 1년마다 교체가 필요
결과는 다른이의 손으로
CloudWatchLogs
❏ CloudWatchLogs에 로그 적재
❏ Log Group Metric으로 측정
❏ 토픽발송 <> 어플리케이션 엔드포인트 발송
Measure Push
❏ SNS -> CloudWatchLogs 기록
AWS SNS Architecture
체크 포인트
! API, CLI가 올바르다.
! SNS Token 관리를 유념
! GCM,APNS Response Event Notification
! Topics publish -> Delivery Status
! DynamoDB, SQS, Lambda 조합은 극강!
! Reference + API Doc = 100%
recruit@glowmee.com
Thank you!
함께 해주셔서 감사합니다!
https://www.awssummit.kr
AWS Summit 모바일 앱을 통해 지금 세션 평가에
참여하시면, 행사 후 기념품을 드립니다.
#AWSSummitKR 해시태그로 소셜 미디어에
여러분의 행사 소감을 올려주세요.
발표 자료 및 녹화 동영상은 AWS Korea 공식 소셜
채널로 공유될 예정입니다.
여러분의 피드백을 기다립니다!

Amazon sns로 지속적 관리가 가능한 대용량 푸쉬 시스템 구축 여정

  • 1.
    © 2017, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. 강승욱 플랫폼개발팀 서비스운영파트 AWS아키텍트담당 Amazon SNS로 지속적 관리가 가능한 대용량 푸쉬 시스템 구축 여정 떠나는건 마음대로지만 돌아오는건 아닙니다.
  • 2.
    Introducing me. https://www.linkedin.com/in/seunguk/ joel@glowmee.com 디지털 떠돌이,입개발자 AWS로 서버를 배운 듣보잡 개발자 JAVA조금 PHP조금많이 Python조금 재능마켓 크몽 번역서비스 옥셔노리 워드프레스의 단비스토어를 잠시 거쳐 글로우데이즈에 정착해서 글로우픽 서비스를 하고있습니다. 야크의 털을 깎을수 밖에 없다면 예쁘게 깎고 싶어요.
  • 3.
    본 강연에서 다룰내용 - SNS의 개요 - SNS Topic의 운영 - 전체푸시와 그루핑 푸시 - SNS의 토큰 상태관리 및 상태 응답 받기 - DynamoDB로 토큰 분리하기 - SQS와의 긴밀함 - CloudWatchLogs로 측정하는 푸시 측정
  • 4.
    개미는 지옥을 그냥지나치지 못한다.
  • 5.
    Legacy Push System DataBase GetToken foreach GCM APNS
  • 6.
    Legacy Push System ❏1000개씩 끊어 보내더라도 오래걸림 ❏ 보낸 푸시의 상태와 모니터링의 어려움 ❏ 토큰 변경 리스폰스 처리의 어려움 ❏ 레거시 시스템의 토픽 활용의 어려움
  • 7.
  • 8.
    SNS Structure ❏ Topics: 어플리케이션 엔드포인트들이 구독단위로 그루핑 되어있는 것 ❏ Application : 플랫폼 별로 토큰을 적재할 수 있는 곳. 다양한 플랫폼 지원 ❏ Subscriptions : 어플리케이션이 토픽을 구독하고 있는 값을 담고 있는 곳. 이곳을 체크해서 해당 엔드포인트가 특정 토픽을 구독하고있는지 체크가 가능.
  • 9.
    Application Endpoint Register 대량등록 ❏어플리케이션 엔드포인드 생성 토큰을 저장, 전체푸시 토픽 구독처리 ❏ User data에 값을 넣으면 중복된 값을 넣으려고 할때에 예외가 발생한다. 값이 없으면 중복된 값이 어느 한계선까지
  • 10.
    SNS Push Publish ❏해당 엔드포인트 혹은 토픽으로 단순 문자열 혹은 JSON Payload를 구성해서 보낼 수 있습니다. ❏ TTL은 푸시 메세지의 생명 시간을 정하는 것입니다.
  • 11.
  • 12.
  • 13.
  • 14.
    SNS Set EventNotifications ❏ 발생된 이벤트를 수신할 토픽을 지정 이벤트등록
  • 15.
    Endpoint Event Receive ❏해당 토픽으로 오늘 이벤트 메세지를 수신할 프로토콜은 많이 존재하지만 값이싸고, 순차처리에 용이한 SQS를 사용 ❏ 어플리케이션의 이벤트를 수신할 토픽을 만들고 어플리케이션 액션에 등록해준다.
  • 16.
    Endpoint Event Receive ❏어플리케이션에서 Endpoint Event Notifications를 Topic으로 보내고 그 이벤트 메세지를 다시 큐로 쌓은 후 람다가 병렬처리 혹은 배치처리로 변경사항을 다이나모에 존재하는 토큰에 반영한다.
  • 17.
    Endpoint Token ManagementPoint ❏ 기존의 회원 테이블에서는 한 회원에 하나의 플랫폼 엔드포인트만이 등록가능 ❏ 비회원 유저를 위한 토큰 저장 테이블이 따로존재 ❏ 회원이 한 기기로 로그인과 로그아웃을 반복하거나, 다른 계정으로 접속시의 처리비용이 높아짐 ❏ 푸시를 위한 필요회원정보 : 회원항번,UUID,DEVICE TOKEN,Endpoint ARN,isPush,SubscribeARN ❏ 정보가 많아짐에 따라 푸시관련 정보를 따로 분리필요 Solution
  • 18.
  • 19.
  • 20.
  • 21.
  • 22.
    WatchOut! ❏ SQS DefaultVisibility Timeout ❏ Scale-Out, Provisoned Capacity 필요 ❏ 람다 병렬처리 -> 트리거 ❏ APNS 어플리케이션 인증은 1년마다 교체가 필요
  • 23.
  • 24.
    CloudWatchLogs ❏ CloudWatchLogs에 로그적재 ❏ Log Group Metric으로 측정 ❏ 토픽발송 <> 어플리케이션 엔드포인트 발송
  • 25.
    Measure Push ❏ SNS-> CloudWatchLogs 기록
  • 26.
  • 27.
    체크 포인트 ! API,CLI가 올바르다. ! SNS Token 관리를 유념 ! GCM,APNS Response Event Notification ! Topics publish -> Delivery Status ! DynamoDB, SQS, Lambda 조합은 극강! ! Reference + API Doc = 100%
  • 28.
  • 29.
  • 30.
    https://www.awssummit.kr AWS Summit 모바일앱을 통해 지금 세션 평가에 참여하시면, 행사 후 기념품을 드립니다. #AWSSummitKR 해시태그로 소셜 미디어에 여러분의 행사 소감을 올려주세요. 발표 자료 및 녹화 동영상은 AWS Korea 공식 소셜 채널로 공유될 예정입니다. 여러분의 피드백을 기다립니다!