알림톡 프로세스를 개선 하며, AWS Lambda 동시성 제어에 대한 고민

배경

최근에 회사에서 알림톡 프로세스를 개선했다. 자세한 내용: 여기

알림톡 기능 퍼포먼스 개선

 

 

알림톡 발송 후 콜백을 받아 람다에서 후처리 하는 프로세스까지는 성공적이었다. 람다에 대해 더 알아보며 Reserved Concurrency/Provisioning Concurrency 가 있었다. 여기서 파생해서 람다에 대해 더 알게 된 이후로 현재 설계로는 서비스가 장기적으로 잘 돌아가지 않을 것이고 큰 기술부채로 남겨질 것 같다고 생각해서 더 고민을 해보았다.

 

해결 방법 모색

 

Reserved Concurrency 에 대한 고민

 

람다는 동시에 1000개의 함수가 실행될 수 있는데, 해당 Region의 모든 람다가 통틀어 1000개 라고 한다. 즉, 여러개의 함수가 있을 때, 중요하지 않은 함수의 요청이 갑자기 많아지만 정작 중요한 함수에 대한 요청이 거부되면서, 실행하지 못하는 이슈가 발생할 수 있다. 그래서 전체 1000개의 pool에서 특정 중요한 함수에 할당 해놓기 위해서 Reserved Concurrency 를 설정 해둘 필요성을 느꼈다.

(추가적으로, 해당 설정으로 인해 디도스나 비용절감에도 도움이 될 것 같다.)

 

그래서 알림톡 후처리를 하는 람다 함수에 Reserved Concurrency를 300개 정도 설정 해놓고, 해당 함수에 대한 전체 요청은 어플리케이션내에서 처리하는 방향이 낫지 않을까 생각 해보았다. 해당 기능은 LB 환경에 대한 고려도 하지 않아도 된다. 왜냐하면 람다로 보내질 이벤트에 담길 정보들은 Notify가 아닌 다른 서버에서 요청을 받기 때문에 데이터 정합성이 이미 확보 돼있고, 순서에 크게 상관없기 때문이다.

 

그리고 알림톡 프로세스 개선을 V4 까지 잡아 놓았는데, V2 부터는 람다에서 메시지 큐에 들어갈 이벤트를 발행 할 예정이다. 이러한 부분에서도 내부 큐에서 번들로 람다에 요청 보내는것이 필요하다고 생각한다. 메시지 큐 이벤트 하나하나 발행할 때마다 람다에 요청하기엔

람다의 컨넥션 풀이 한정적이고 Reserved Concurrency 에 설정 된 임계값이 넘어가면 throttling이 일어나기 때문에 내부적으로 번들링 하는거는 현재 상황에서 필수불가결하지 않을까 생각해본다.

 

 

Provisioned Concurrency 에 대한 고민

 

람다를 사용하는 많은 분들이 고민하는 부분중 하나는 Cold start 일것이다. 요청을 받고 인스턴스가 띄워지는 시간 동안은 요청을 처리하지 못하기 때문에 그만큼 고객은 기다리는 시간도 정비례한다. 이거를 해결하기 위해서는 Provisioned Concurency 를 설정하면 된다. 해당 기능은 미리 Warm up 될 람다 인스턴스의 개수를 설정 하면, 바로 처리 할 수 있게 그만큼 함수를 warm up 시켜놓는다. 그러나 해당 기능은 비용이 발생한다.

개선 하려고 하는 프로세스는 실시간성을 띄고있지 않기 때문에 비용을 부담하면서 까지 해당 기능이 필요하지 않을 것 같다.

 

 

마무리

기술 하나를 도입할 때 양보다 질이라고 생각이 든다. 좋다고 하는 기술들을 이것저것 덕지덕지 붙이다 보면 미래에는 큰 부채가 될 가능성이 많을 것 같다. 그래서 최대한 많이 알아보고 테스트도 거쳐 보아야 할 것 같다.