January

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를 이용한 연결이 있는데.. 이 기능이야 말로 이때 써야하는게 아닐까 싶어 써보았는데 바로 된다! 테스터서버부터 실서버까지 로컬에 설치한 프로그램으로 캐시 데이터를 볼 수 있다. ...

Today I Learned 날짜 2025년 1월 21일 화요일 내용 Step Functions에서 Choice로 분기처리하기 웹훅 개선 작업을 진행중이다. 지난주에 말했듯 Step Functions로 계획중인데 오늘 헤매던 곳을 뚫어냈다. 기존과 마찬가지로 웹훅이 서버로 전송되면 SQS 큐에 메시지를 담는다. 매핑된 람다는 메시지가 하나 도착하면 꺼내서 Step Functions에서 정의한 상태 머신을 호출해서 로직을 진행한다. 이 상태머신은 이 메시지의 종류(주문, 혜택, 고객 등)에 따라 알맞은 람다를 호출해야 한다. 그림으로 보자면 이런 형태다. 저 노드 하나하나가 state라는 개념이다. 저기서 저 DetermineTopic이 Choice State인데, 정의한 조건에 따라 알맞은 람다를 호출해줘야 한다. 그 상단에서 최초로 호출되는 웹훅 데이터 디코딩 람다부터 살펴보자 ...

Today I Learned 날짜 2025년 1월 20일 월요일 내용 람다에 계층 추가하기 람다는 서버 없이 간단한 함수를 작성하여 실행할 수 있는 기능을 제공한다. 따라서 여기에는 기본 내장 함수들만 제공된다. 만약 람다에서 어디론가 http 요청을 보내기 위해 requests 가 필요하다면 람다에 등록하는 ZIP 파일에 해당 패키지를 추가해주어야 한다. 웹훅 개선에 람다를 이용할 계획이고, 각 람다는 다루는 웹훅 별로 나눠질 예정이다. 주문, 고객, 상품 등 다루는 데이터에 따라 여러 람다를 만들거다. 각 람다를 정의할 때마다 requests 라이브러리를 설치해주는 것은 번거롭다. 이런 일이 반복되면 람다 자체도 용량이 커진다. 모두가 쓰는 공통적인 라이브러리를 추가해주는 기능이 계층(layer)다. ...

Today I Learned 날짜 2025년 1월 16일 목요일 내용 장고에서 프린트문 바로 출력하기 장고에선 아주 특이한 현상이 있다. 개발 과정에서 프린트문을 찍어도 바로 출력이 안된다! 개발의 최 핵심 기능인데… 버퍼에 들어갔다 나와서 그런지, 괜히 코드 저장버튼을 눌러서 도커 컨테이너가 리프레쉬 되야 출력된다. 디버깅 모드는 너무 설정하기 번거롭고… 간단하게 하는 방법을 찾아냈다. 방법 1 print("출력!", flush= True) 를 사용하자. 버퍼에 쌓이지 않고 즉시 출력된다. 방법 2 프린트문을 찍을 때마다 저 옵션을 넣어줄 순 없다. 도커파일에 잠깐 손을대자. ...

Today I Learned 날짜 2025년 1월 15일 수요일 내용 내가 메타를 혐오하는 이유 꾸준히 TIL을 쓰면서 메타에 대한 온갖 불평 불만을 쏟아냈었다. 그리고 오늘 그 분노는 최대치를 찍었다. 네이버 커머스 솔루션에서 우리 서비스를 이용해주시는 고객님께 태그된 게시물을 전달해드리지 못했다는 자책에서 조금은 자유로워지고자 메타가 왜 망해 마땅한 지를 말하고자 한다. 메타 API를 이용하려면 메타 개발자 센터에서 앱을 등록해야 한다. 각 앱은 사용 유저의 어떤 데이터를 사용하느냐에 따라 필요한 권한을 설정해주어야 한다. 권한에는 Standard Access와 Advanced Access가 있는데 결국 배포해서 사용하려면 Advanced Access를 얻어야 한다. Standard 수준까지만 얻은 권한은 앱에 등록된 사람(관리자라던가 테스터라던가)만 사용할 수 있고, 앱을 이용하는 누구나(일반 유저) 사용하려면 해당 권한의 Advanced Access를 얻어야 한다. ...

Today I Learned 날짜 2025년 1월 14일 화요일 내용 웹훅 개선을 위한 계획 세우기 다음 태스크가 정해졌다. 무려 웹훅 개선하기. 코어에 오면서 큰 트래픽을 처리하게 될 거라곤 예상했지만 벌써 이렇게 본격적으로 할 줄은 몰랐다… 웹훅은 설정한 이벤트(데이터 변경 등)가 발생했을 때, 외부로 요청을 보내는 것을 의미한다. 예를 들어, 앱 설정에서 웹훅을 구독해 놓으면 CAFE24에서 우리 서비스를 사용하는 스토어의 데이터가 변경되면 우리에게 보내준다. 상품 정보라던가, 주문이 추가되었다던가, 고객이 삭제되었다던가 다양한 상황을 설정할 수 있다. ...

Today I Learned 날짜 2025년 1월 13일 월요일 내용 초기화되지 않는 컴포넌트 서버에 요청을 보내고 받아온 데이터로 작은 모달을 열어야 한다. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 facebookLogin() { FB.login((response: any) => { if (response.authResponse) { let userData = response.authResponse; this.coreApi.create(`shops/${this.shop.id}/facebook/login`, { facebook_access_token: userData['accessToken'], facebook_user_id: userData['userID'], facebook_profile: '', facebook_username: '', }).subscribe(response => { this.facebook_page_list = response.body.page_list; const dialogRef = this.dialog.open(FacebookPageComponent, { data: { facebookPageList: this.facebook_page_list }, minWidth: '600px', minHeight: '600px' }); } 분명 facebook_page_list에는 올바른 데이터가 포함되는데 모달이 떠도 내부에 데이터가 보이지 않는다. 신기한건 그 페이지의 개발자도구를 키는 순간 데이터가 나타난다는 것.. 뭐 이런 듣도보도 못한 경우가 다 있나 싶었다. ...