Today I Learned 날짜 2025년 7월 28일 일요일 내용 건강하고 빠른 웹훅을 향한 여정 입사 76주차부터 WIL을 남기지 못했다. 웹훅 이슈로 인한 실시간 데이터 처리 지연과 누락이 지속적으로 발생하고 있었기 떄문이다. WIL을 읽는 사람 입장에서 “애는 배웠다고 하는데, 웹훅 계속 박살나고 있구만 뭘 배운겨” 라는 생각이 들까봐 그랬다. 사실 이걸 쓰고 있는 지금도 마음 한구석에 괜히 사망 플래그를 세우는 건 아닌지 걱정이 되지만, 더 미루면 영영 회고를 하지 못할까봐 지금이라도 이 여정을 정리하는 글을 쓰려고 한다. 제 부족한 실력으로 괜한 피해를 입은 분들(사실상 샐러드랩 모두)께 죄송스러운 마음을 가지며 글을 시작하고자 한다. ...
Today I Learned 날짜 2025년 2월 5일 수요일 내용 SQS 메시지의 수명과 전송지연 어제 저녁부터 들어온 웹훅 메시지들을 아침에 확인해봤다. 메시지 수명이 뭔가 꺼림칙하다. 저 60초선에 닿으면 뭔일이라도 나는 것마냥 구는 저 그래프가 참으로 거슬린다. 혹시 저 시간이 지난 메시지들이 삭제되는 것이 아닌지 확인할 필요가 있다는 팀장님의 제보를 받고 확인해보았는데 데이터는 잘 들어오고 있다. 어제 오후 7시부터 SQS에 들어온 메시지의 갯수 그래프다. 38만 개 정도 된다. 7시부터인 이유는 어제 오후 7시에 Redis 를 한번 초기화해버렸으니까.. ...
Today I Learned 날짜 2025년 1월 31일 금요일 내용 SQS 큐의 중복 판단 기준 Amazon SQS에서 FIFO Queue에선 메시지의 중복 여부를 확인하는 방식이 2가지가 있다. 설정 방법 동작 방식 사용 예시 자동 (Content-Based Deduplication) 메시지 본문의 SHA-256 해시 값이 Deduplication ID로 설정됨 메시지 본문이 같으면 5분 이내에 중복 제거됨 사용자 지정 (MessageDeduplicationId) 사용자가 직접 중복 제거 ID를 설정할 수 있음 메시지가 같아도 다른 ID를 부여하면 별도 메시지로 처리됨 카페24 API 웹훅은 변경된 데이터에 대한 간략한 정보만 들어온다. 웹훅에 관한 필요한 데이터만 처리해서 메시지를 작성하고 큐에 집어 넣는다. 따라서 별개의 웹훅이라도 본문이 같을 수 있다. 예를 들어 5분 간격으로 같은 스토어의 같은 상품 정보가 변경되었다고 하더라도 웹훅 정보, 샵 아이디, 몰 아이디, 상품 아이디 정도만 메시지에 담기므로 메시지가 동일해 보일 수 있다는 의미다. 이럴 경우 중복으로 처리되면 안되기 때문에 사용자 지정으로 설정해주었다. ...