Today I Learned 날짜 2025년 7월 28일 일요일 내용 건강하고 빠른 웹훅을 향한 여정 입사 76주차부터 WIL을 남기지 못했다. 웹훅 이슈로 인한 실시간 데이터 처리 지연과 누락이 지속적으로 발생하고 있었기 떄문이다. WIL을 읽는 사람 입장에서 “애는 배웠다고 하는데, 웹훅 계속 박살나고 있구만 뭘 배운겨” 라는 생각이 들까봐 그랬다. 사실 이걸 쓰고 있는 지금도 마음 한구석에 괜히 사망 플래그를 세우는 건 아닌지 걱정이 되지만, 더 미루면 영영 회고를 하지 못할까봐 지금이라도 이 여정을 정리하는 글을 쓰려고 한다. 제 부족한 실력으로 괜한 피해를 입은 분들(사실상 샐러드랩 모두)께 죄송스러운 마음을 가지며 글을 시작하고자 한다. ...
Today I Learned 날짜 2025년 2월 7일 금요일 내용 재귀의 원인 새로 구축한 웹훅 시스템에서 종종 재귀가 탐지되었다고 알람이 발생하고 있다. 루프를 탈출하지 못하고 계속 빙빙 돌고 있다는 건데.. 분명 내가 구현한 함수중에는 자기 자신을 호출할 일은 없기 때문에 이 문제가 이해되지 않았다… 우선 어떤 경우에 AWS가 재귀라고 판단하는지 알아봤다. 문서에 따르면 16회 정도 이상 호출되면 재귀라고 판단하는데, 이 판단은 헤더에 있는 특정 값으로 판단한다고 한다. 뭐 어찌됐든… 실제로 테스트서버에서 실태를 확인해봤다. 로직을 일부러 실패해서 총 몇번 재시도 하는지를 확인하면 된다. 웹훅을 2회(1번만 하려고 했는데 실수함) 호출하고 SQS 트리거 람다 함수와, Step Functions이 몇번 호출되었는지 확인해봤다. ...
Today I Learned 날짜 2025년 2월 3일 월요일 내용 메시지 재시도 실패한 메시지를 처리하는 방법에 대한 고민이 계속되는 중… 요청이 몰렸을 때 적절하게 재시도하는 방법을 열심히 찾고 있다. 예시로 동시에 주문을 생성하는 웹훅 5천개가 들어왔다고 가정해보자. 동일한 업체의 주문은 동일한 메시지 그룹에 담기므로 1개씩 트리거 람다가 호출된다. 이 람다는 상태머신을 호출하고 종료된다. 이 과정은 매우 빨라서 3천개의 상태머신이 열리는데 몇 분이 걸리지 않는다. 카페24 API의 요청 제한이 1천개라면, 1천 개의 웹훅은 바로 처리된다. 그리고 나머지 2000개는 429 Too Many Requests를 반환받는다. 여기서부터 어떻게 처리할지를 고민하고 있는 상황이다. ...
Today I Learned 날짜 2025년 1월 21일 화요일 내용 Step Functions에서 Choice로 분기처리하기 웹훅 개선 작업을 진행중이다. 지난주에 말했듯 Step Functions로 계획중인데 오늘 헤매던 곳을 뚫어냈다. 기존과 마찬가지로 웹훅이 서버로 전송되면 SQS 큐에 메시지를 담는다. 매핑된 람다는 메시지가 하나 도착하면 꺼내서 Step Functions에서 정의한 상태 머신을 호출해서 로직을 진행한다. 이 상태머신은 이 메시지의 종류(주문, 혜택, 고객 등)에 따라 알맞은 람다를 호출해야 한다. 그림으로 보자면 이런 형태다. 저 노드 하나하나가 state라는 개념이다. 저기서 저 DetermineTopic이 Choice State인데, 정의한 조건에 따라 알맞은 람다를 호출해줘야 한다. 그 상단에서 최초로 호출되는 웹훅 데이터 디코딩 람다부터 살펴보자 ...
Today I Learned 날짜 2025년 1월 14일 화요일 내용 웹훅 개선을 위한 계획 세우기 다음 태스크가 정해졌다. 무려 웹훅 개선하기. 코어에 오면서 큰 트래픽을 처리하게 될 거라곤 예상했지만 벌써 이렇게 본격적으로 할 줄은 몰랐다… 웹훅은 설정한 이벤트(데이터 변경 등)가 발생했을 때, 외부로 요청을 보내는 것을 의미한다. 예를 들어, 앱 설정에서 웹훅을 구독해 놓으면 CAFE24에서 우리 서비스를 사용하는 스토어의 데이터가 변경되면 우리에게 보내준다. 상품 정보라던가, 주문이 추가되었다던가, 고객이 삭제되었다던가 다양한 상황을 설정할 수 있다. ...