AWS API 사용에 있어 요청 할당량 고려하기

App Notification Push를 위한 자체 유틸 함수 사용

💬 이번에 회사에서 별도의 push 서버를 만들기로 했다. 이를 위해 기존 push를 날리는 함수에 대해 성능 테스트를 하기로 했다. 테스트 결과를 통해 push 서버를 만드는 과정에서 고려해야 할 사항들을 체크하기로 했다.  

 

✔ 테스트 진행

💬 1만 유저에게 push를 보내는 테스트를 했는데, 소요되는 시간이 10분이 넘어갔다. 시간을 줄이기 위해 Thread 10, 20개로 늘려가며 추가적인 테스트를 했다. 그랬더니 throttling 예외가 발생을 했다. 초당 처리량이 200~300건 밖에 안되었는데 기존 함수에서 사용하고 있는 AWS SNS API에서 성능 제한을 위해 throttling이 발생한 것이다.

 

✔ 원인 파악

💬 AWS SNS로 Push 요청을 날리기 위하여 대상이 되는 ARN이 필요 했는데, 이것을 얻기 위해 Push를 날릴 때 마다 기존 함수에서는 ARN을 만들고 반환하는 createPlatformEndpoint를 호출을 하고 있었다. 해당 API는 할당량이 150/sec였고 Thread가 늘어나면서 할당량을 넘어가면서 생기는 문제였다.

 

✔ 해결 방법

💬 createPlatformEndpoint 이외에 ARN을 얻어올 수 있는 함수에 대해서 먼저 확인을 했다. 그런데 전체 리스트를 가져오는 API 이외에는 특정 디바이스 토큰으로 가져올 수 있는 API는 없었다. 그래서 기존에 작성했던 개발자가 단일 요청을 위해 임시방편으로 createPlatformEndpoint를 사용하여 ARN을 얻어온 것 같다. 하지만 대용량 푸시를 할 때는 해당 API의 할당량은 문제가 되기 때문에 사용을 할 수 없었다. 별도로 DB에 ARN을 저장을 해뒀다가 사용을 하는 것으로 대체하기로 했다.

 

✔ 결과

💬 DB에 ARN을 저장하는 것으로 대체하니, AWS SNS로 Push를 날리는 publish에 할당량 1500/seconds를 온전히 사용을 할 수 있게 되었다. 우리의 목표인 1,000,000 이상의 유저에게 푸시를 날리는 테스트를 했을 때도 초당 처리량 1200~1500이 나왔고 12분 내외에서 처리가 되는 것을 확인 할 수 있었다.

 

✔ 결론

💬 외부 API를 사용을 할 때, 기존 Spec을 정확하게 알고 사용을 해야한다는 것을 여실히 느꼈다. 그리고 때로는 내가 임시방편으로 짜놓은 코드 때문에 다른 개발자가 사용할 때 문제가 되기도 한다는 것을 알았다. 이런 것들을 잘 주의해서 코드를 작성하는 개발자가 되어야겠다.