Today I Learned
날짜
2025년 1월 14일 화요일
내용
웹훅 개선을 위한 계획 세우기
다음 태스크가 정해졌다. 무려 웹훅 개선하기. 코어에 오면서 큰 트래픽을 처리하게 될 거라곤 예상했지만 벌써 이렇게 본격적으로 할 줄은 몰랐다…
웹훅은 설정한 이벤트(데이터 변경 등)가 발생했을 때, 외부로 요청을 보내는 것을 의미한다. 예를 들어, 앱 설정에서 웹훅을 구독해 놓으면 CAFE24에서 우리 서비스를 사용하는 스토어의 데이터가 변경되면 우리에게 보내준다. 상품 정보라던가, 주문이 추가되었다던가, 고객이 삭제되었다던가 다양한 상황을 설정할 수 있다.
웹훅을 제때 알맞게 처리하지 않으면, 특히 누락되면 문제가 발생한다. 실제(그리고 카페 24 데이터베이스에서)는 상품 가격이 5만원인데, 우리 서버에선 4만원짜리로 저장되어 있다던가 있어야 할 고객이 없는 경우가 문제가 되리란건 쉽게 짐작할 수 있다. 곧 리뷰가 통합되는데, 가장 많은 스토어가 사용하고 있는 서비스인 만큼 웹훅 수가 상당히 많이 발생할 예정이다.
현재 웹훅 메시지는 Amazon SQS라는 큐에 저장되고 있다. 큐에 담긴 메시지를 EC2에서 끊임없이 탐색하고 꺼내와서 처리하는 로직이 작동하고 있다. 현재는 상관 없으나 요청이 늘어나서 쌓이는 속도가 처리하는 속도보다 커지면 문제가 될게 분명하다. 웹훅은 특정 시간대(주문이 많은)에 몰리는 경향이 있는데, EC2로 처리하는 현재 방식은 스케일링도 까다롭다. 필요할 때마다 EC2의 인스턴스를 바꿔줄 수는 없는 노릇이니까.
그래서 어떻게 고칠것인가… 현재는 Lambda와 Step Functions를 고려하고 있다.
람다는 서버없이 코드를 실행해주는 서비스다. 대표적으로 “매일 오후 6시에 샐러드랩 슬랙 저녁식사 주문방에 음식점을 입력해” 라는 기능을 만들 수 있다. 고작 이거하자고 서버와 데이터베이스 까지 구축할 필요는 없다. 그냥 슬랙 API에 요청을 보내는 코드만 만들고 람다에 등록해놓으면 된다.
스텝 펑션은 AWS 내의 여러 서비스들의 실행을 조절해주는 서비스다. 어떤 상황에 어떤 람다(ECS나 그 외의 모든 서비스도 가능하다)를 실행할 것인지 어떤 경우에 성공으로 처리하고 그 다음은 어떻게 할 것인지 등을 설정할 수 있다.
웹훅이 처리되는 과정을 정리해보면 다음과 같다. 웹훅이 서버에 들어오면 서버는 SQS 큐에 메시지를 보낸다. SQS 큐에 매핑된 람다는 큐에 메시지가 들어오는 순간 실행되고 이 람다는 스텝 펑션을 호출한다. 스텝 펑션은 데이터에 따라 알맞은 람다(주문 정보 다루는 람다, 고객 정보 다루는 람다 등)를 호출한다.
이 방식의 장점은 웹훅으로 인한 서버 부하가 감소한다는 점, 웹훅 메시지를 병렬적으로 관리하기 용이해 진다는 점 등이 있다. 물론 내가 똑바로 만든다면…
회고
처음 써보는 거다. 재밌겠다.
