Today I Learned 날짜 2025년 2월 7일 금요일 내용 재귀의 원인 새로 구축한 웹훅 시스템에서 종종 재귀가 탐지되었다고 알람이 발생하고 있다. 루프를 탈출하지 못하고 계속 빙빙 돌고 있다는 건데.. 분명 내가 구현한 함수중에는 자기 자신을 호출할 일은 없기 때문에 이 문제가 이해되지 않았다… 우선 어떤 경우에 AWS가 재귀라고 판단하는지 알아봤다. 문서에 따르면 16회 정도 이상 호출되면 재귀라고 판단하는데, 이 판단은 헤더에 있는 특정 값으로 판단한다고 한다. 뭐 어찌됐든… 실제로 테스트서버에서 실태를 확인해봤다. 로직을 일부러 실패해서 총 몇번 재시도 하는지를 확인하면 된다. 웹훅을 2회(1번만 하려고 했는데 실수함) 호출하고 SQS 트리거 람다 함수와, Step Functions이 몇번 호출되었는지 확인해봤다. ...

Today I Learned 날짜 2025년 2월 6일 목요일 내용 is와 ==의 차이 네이버 커머스 솔루션 관련 버그를 고치던 중, 네이버 스토어 데이터에도 샵의 비활성화 여부를 나타내는 필드를 추가해야 했다. 따라서 NaverStore 테이블에 is_active 필드를 추가했다. 이제 스토어를 탐색하는 경우의 대부분은 ‘활성화된 스토어’를 기준으로 하는게 당연해졌으므로 탐색 함수에 is_active 필드가 True인 경우를 추가해줬다. 따라서 1 2 3 stmt = select(models.NaverStore).where( models.NaverStore.is_active == True ) 이런식으로 쿼리를 작성했다. 그런데 Flake8에서 경고 메시지가 떴다. ...

Today I Learned 날짜 2025년 2월 5일 수요일 내용 SQS 메시지의 수명과 전송지연 어제 저녁부터 들어온 웹훅 메시지들을 아침에 확인해봤다. 메시지 수명이 뭔가 꺼림칙하다. 저 60초선에 닿으면 뭔일이라도 나는 것마냥 구는 저 그래프가 참으로 거슬린다. 혹시 저 시간이 지난 메시지들이 삭제되는 것이 아닌지 확인할 필요가 있다는 팀장님의 제보를 받고 확인해보았는데 데이터는 잘 들어오고 있다. 어제 오후 7시부터 SQS에 들어온 메시지의 갯수 그래프다. 38만 개 정도 된다. 7시부터인 이유는 어제 오후 7시에 Redis 를 한번 초기화해버렸으니까.. ...

Today I Laerned 날짜 2025년 2월 4일 화요일 내용 이름을 잘짓자 이번 웹훅 개선작업을 진행하면서 가장 뼈저리게 느끼는 부분이다. 그동안의 TIL에서도 꽤나 자주 말했던 부분이긴 한데, 타겟(?)이 약간 다르다. 그동안은 코드 내에서 함수나 변수 명명에 관한 이야기였다면 어제부터 오늘 느낀건 AWS 자원에 대한 이야기다. 첫번째 경험이다. 이번 웹훅 개선 작업에서 쓴 AWS Step Functions와 SQS는 처음 써보는 거라 이것저것 해볼 필요가 있었다. 안되는게 원래 안되는 건지 내가 못한건지 파악하랴, 있다느 기능을 어떻게 설정하는지 파악하랴, 이게 좋은지 저게 좋은지 파악하랴 만들다 삭제했다를 끊임없이 반복하다보면 이름따위는 안중에 두지 않게 된다. 왜냐면 ‘어차피 작동 되도 이건 삭제할거야. 잘 작동하면 이름 제대로 지어서 만들면 되니까’ 라고 생각하기 때문이다. 실제로 무조건 틀린 생각은 아니긴 한데.. 이번엔 틀렸다. 이번 웹훅 작업을 하면서 만든 AWS 자원을 보면 ...

Today I Learned 날짜 2025년 2월 3일 월요일 내용 메시지 재시도 실패한 메시지를 처리하는 방법에 대한 고민이 계속되는 중… 요청이 몰렸을 때 적절하게 재시도하는 방법을 열심히 찾고 있다. 예시로 동시에 주문을 생성하는 웹훅 5천개가 들어왔다고 가정해보자. 동일한 업체의 주문은 동일한 메시지 그룹에 담기므로 1개씩 트리거 람다가 호출된다. 이 람다는 상태머신을 호출하고 종료된다. 이 과정은 매우 빨라서 3천개의 상태머신이 열리는데 몇 분이 걸리지 않는다. 카페24 API의 요청 제한이 1천개라면, 1천 개의 웹훅은 바로 처리된다. 그리고 나머지 2000개는 429 Too Many Requests를 반환받는다. 여기서부터 어떻게 처리할지를 고민하고 있는 상황이다. ...

국가란 무엇인가 지은이: 유시민 출판사: 돌베개 감상 이게 나라냐? 언젠가부터 떄로는 농담으로 떄로는 진지하게 하는 말이다. 어릴 때는 일부 정치인들의 망언이나 행보를 보면 과연 저 사람도 진심으로 대한민국을 사랑하는 사람인지 궁금했다. 더 좋은 나라가 되기 위해, 가난하고 힘든 사람들을 외면하는 듯한 모습을 보고 내가 하면 다를거라고 생각했고 실제로 고등학생 때까지는 정치가가 꿈이었다. 그들과 달리 나는 논리적이고 정의로우며 직접적인 해결책을 알고 제시할 수 있다고 생각했다. 나이를 들며 생각이 많이 변했다. 듣고 있자면 마음이 처참해지는 소식이 뉴스에 들려오는 것은 여전하나 그들이 ‘고의로’ 사회를 어지럽힌다고 생각하지는 않는다. 나와 살아온 경험이, 거기서 배운 것이 달라 보는 관점이 다르다고 생각한다. 분명 그들도 ‘나름대로’ 애국하고 있을 것이며, 자신의 주장에 근거가 있을 것이다. 내가 그들이 가졌다고 생각했던 아집은, 내가 가졌던 확신에 찬 신념과 똑같다고 생각한다. 하지만 이해가 되진 않는다. 왜 그렇게 생각하는 걸까? 어떤 관점일까? ...

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분 간격으로 같은 스토어의 같은 상품 정보가 변경되었다고 하더라도 웹훅 정보, 샵 아이디, 몰 아이디, 상품 아이디 정도만 메시지에 담기므로 메시지가 동일해 보일 수 있다는 의미다. 이럴 경우 중복으로 처리되면 안되기 때문에 사용자 지정으로 설정해주었다. ...

Today I Learned 날짜 2025년 1월 24일 금요일 메타에게 함께해서 더러웠고 다신 보지말자. 드디어 마침내 검수를 통과했다. 이 권한 하나를 얻기 위해 15번을 신청했다. 통과할 수 있는 비법을 공개하겠다. 지피지기면 백전백승 실제로는 15전 1승 14패지만, 그래도 결국은 내가 이겼다. 페이스북에는 개발자 커뮤니티가 있다. 본인들은 거기에 본인들 욕이 한가득이라는 사실을 아는지 모르겠으나 메타에 대한 분노를 동병상련으로 치료하기에 적절한 곳이다. 내가 거부당한 이유가 이해가 안되어 열심히 망령처럼 떠돌아다니다가 한 글을 보았다. ...

Today I Learned 날짜 2025년 1월 23일 목요일 내용 ElastiCache 서버리스 연결의 특징 람다에서 ㄷ웹훅으로 생성된 데이터를 데이터베이스에 어떻게 연결할 것인가에 대해 많은 고민과 조언이 있었다. 현재 시도 가능한 방식 3가지는 다음과 같다. 람다에서 데이터베이스 직접 접근 AWS Lambda와 RDS를 연결하는 기능도 따로 있을 뿐더러, 모든 로직이 Step Functions 내에 있는 람다에서 종료되니 설계도 깔끔하다. 다만, 데이터베이스에 접근하는 곳이 2곳(서버, 람다)이 되어서 오류가 발생하거나 수정 사항이 생겼을 때의 관리소요가 추가된다. 서버에 HTTP 요청 서버에 있는 데이터 수정 엔드포인트를 이용. 굳이 서버 데이터 처리하는 작업에 API를 사용하는 부담 캐시 데이터를 Redis 리스트에 보관하고 서버가 풀링하여 저장하는 방식 결국 풀링이 필요함 결국 3으로 구현하고 있다. 웹훅은 시간대에 따라 요청 수가 차이가 나므로 오토 스케일링이 필요하다고 판단했다. 가장 요청이 몰릴 때를 기준으로 생성하면 돈 아깝다. 다행히 Amazon ElastiCache에는 서버리스가 있었기 떄문에 이걸 이용했다. ...

Today I Learned 날짜 2025년 1월 22일 수요일 내용 로컬 Redis Insight로 캐시 데이터 보는 방법 AWS ElastiCache 에 올라가 있는 캐시를 눈으로 직접 보고싶다. 시각적으로 데이터를 표현하고 관리할 수 있는 툴을 GUI라고 하는데, PostgreSQL에 pgadmin4가 듯 Redis에는 Redis Insight가 있다. 문제는 이 서버가 VPC에 들어가 있어서 그런지 로컬에서 접속이 안된다는 것.. 해당 VPC에 구현된 EC2 인스턴스에 접속해야 접근할 수 있다고 한다. 내가 알기론 Redis Insight에는 SSH를 이용한 연결이 있는데.. 이 기능이야 말로 이때 써야하는게 아닐까 싶어 써보았는데 바로 된다! 테스터서버부터 실서버까지 로컬에 설치한 프로그램으로 캐시 데이터를 볼 수 있다. ...