Today I Learned 날짜 2024년 7월 24일 수요일 내용 리뷰 요청 메일 리뷰를 요청하는 메일은 중요한 기능이기 떄문에 매일매일 확인하고 있다. 발송 자체는 올바르게 되나 한가지 문제점을 발견했다. 발송 여부에 관한 데이터를 메시징 로그라 하는데, 이 데이터가 조회가 안된다. 메뉴에서 collect 메뉴에 들어가면 유저는 메시징 로그가 생성된 메일들 목록을 볼 수 있다. 특정 날짜에 발송되었거나, 취소되었거나, 발송할 예정인 메일들과 그 메일의 기점이 된 주문 데이터를 볼 수 있다. 주문데이터를 볼떄는 필터링을 추가할 수 있는데 주문시점, 배송완료 시점, 요청 메일 발송 시점 3가지다. ...

Today I Learned 날짜 2024년 7월 23일 화요일 내용 자주 추가될 템플릿. 네트워크 문제를 해결하니 무사히 람다함수가 완성됐다. 그동안 임시로 멀티스레드로 처리하도록 구현해놓은거를 다 바꿔주었다. 그런데 변경사항이 발생했다. 템플릿이 여러 스프레드시트에 나눠져서 만들어질 것이고 자주 추가될 듯하다. 매번 코드를 엎거나 수정하기엔 번거로울 듯하여 새로운 방안을 모색했다. 각 템플릿의 정보를 담은 테이블을 사용하려고 한다. 그동안은 유저에 의해 생성되는 데이터들만을 위해 데이터베이스를 사용했지만, 이번엔 기능에 추가되는 템플릿들을 저장하는 테이블을 생성하려고 한다. 1 2 3 4 5 6 7 8 9 template : { "id" : 데이터베이스 내 고유 id, "number" : 각각에게 부여되는 고유 숫자, "name" : 템플릿 이름(ex. NSA_GTD 항목별 캠페인 유형, "description": 템플릿에 관한 설명, "spreadsheet_id": 템플릿 원본이 존재하는 스프레드시트의 아이디, "sheetfile_id": 템플릿 원본이 존재하는 시트파일의 아이디, "raw_data_foramt_type": 템플릿이 참조하는 로우데이터의 형식 } 쯤으로 만들면 되지 않을까! 앞으로 추가, 삭제, 변경도 쉬워지도록… ...

Today I Learned 날짜 2024년 7월 22일 월요일 내용 Public Subnet VS Private Subnet 지난 주 금요일부터 계속 처리하던 람다 함수를 계속 만졌다. 웬걸? 람다함수는 구글 드라이브에 스프레드 시트를 생성하는 것부터 실패하고 있었다. 아예 요청 자체가 가질 못하고 있었다. 요청의 문제라기보단 통신의 문제였다. 람다함수가 외부 인터넷과 통신을 못하고 있는게 분명했다. AWS Lambda 함수가 VPC 내의 퍼블릭 서브넷에 배치될 때, 자동으로 퍼블릭 IP를 할당받지는 않습니다. Lambda 함수는 ENI(Elastic Network Interface)를 사용하여 VPC 내에서 네트워크 통신을 수행합니다. 이러한 ENI는 퍼블릭 IP를 갖지 않기 때문에 퍼블릭 서브넷에 배치되어도 인터넷에 직접 접근할 수 없습니다. ...

Today I Learned 날짜 2024년 7월 19일 금요일 내용 람다 AWS Lambda란 무엇인가요? ✔ 서버 프로비저닝 또는 관리, 워크로드 인식 클러스터 확장 로직 생성, 이벤트 통합 유지 또는 런타임 관리 없이 코드를 실행합니다. ✔ 사실상 모든 유형의 애플리케이션이나 백엔드 서비스에 대한 코드를 실행합니다. 코드를 ZIP 파일 또는 컨테이너 이미지로 업로드하기만 하면 Lambda는 자동으로 컴퓨팅 실행 능력을 할당하고, 모든 트래픽 규모에 대하여 수신 요청 또는 이벤트를 기반으로 코드를 실행합니다. ✔ Lambda 기능을 선호하는 언어(Node.js, Python, Go, Java 등)로 작성하고 서버리스 및 컨테이너 도구(AWS SAM 또는 Docker CLI)를 사용하여 기능을 구축, 테스트 및 배포합니다. ...

Today I Learned 날짜 2024년 7월 18일 목요일 내용 중복된 리뷰 요청 메일 주문한 고객에게 리뷰 요청 메일이 중복되서 발송된다는 이슈가 발생했다. 확인해보니 주문 데이터가 여러개 생기는데, 이를 처리하지 않아서 생기는 문제였다. 무슨말이냐면 A, B, C, D 상품을 주문했다고 가정해보자. 그럼 이 주문 데이터가 들어오는데 발송상태는 ‘발송중’, 완료상태에는 빈값으로 들어온다. 여기서 B 상품만 배송이 완료되었다면 주문 데이터가 또 들어온다. 발송 상태는 여전히 ‘발송중’, 완료 상태는 ‘Partial’로 들어온다. 이게 A 상품, C 상품, D 상품이 발송될 떄마다 들어온다. 주문은 1번이지만 최대 데이터가 5개까지 생성될 수 있다는 의미다. 이떄마다 리뷰 요청 메일 로그가 생성되어서 발생한 문제로 파악했다. ...

Today I Learned 날짜 2024년 7월 17일 수요일 내용 테섭 배포 로컬에서 기능 구현이 끝나고 테스트 서버 배포를 했다. 주기적으로 많은 데이터를 한번에 처리해야 하는 만큼, 로컬이 아닌 환경에서 돌려보는게 중요하다고 생각했다. 글로벌 처음 왔을 때, 우리 서비스가 어떤 AWS를 어떻게 쓰고있는지 궁금해서 혼자 사이드 프로젝트로 따라해봤었는데 그 경험이 정말 도움이 많이 되고있다. 그떄 3달간 요금이 70 나와서 아마존에 메일보내긴 했지만… 일단 VPC, RDS, KMS, S3, ECS, ECR 이것저것 없는것 빼고 다 했다. ...

Today I Learned 날짜 2024년 7월 16일 화요일 내용 이름을 잘 짓자 어제 기능을 완성했지만, 프론트와 싱크를 맞추는 과정에서 발생하는 문제들이 있어 여러가지 수정 작업에 들어갔다. import_log 를 생성할 때, 처음 상태의 기본값을 “WAITING”으로 설정했었다. 이후 로그의 생성 순서대로 “IMPORTING”으로 변경하면서 처리하면 될거라고 생각했기 때문이다. 문제는, 데이터 업데이트를 시작한 직후 프론트에서 데이터 조회 요청을 다시 보내는데 이때 “WAITING”이 반환되는 점이다. 이러면 프론트에선 그 로그에 대해서 지속적으로 상태를 추적하지 않는다. “IMPORTING” 중인 로그만 10초에 한번씩 상태를 추적하기 때문. WAITING인 것들을 굳이 상태가 변했는지 추적할 이유가 없는 것은 당연하다. ...

Today I Learned 날짜 2024년 7월 15일 월요일 내용 구현 마무리 전반적인 기능들은 구현이 마무리됐다. 이제 네이버에서 데이터를 가져오고, 알맞게 처리해서 스프레드시트를 만들어 넣는 것은 잘 작동된다. 이제, 실질적인 데이터들을 처리하면서 성능과 소요 시간을 알아보고 테스트서버에 배포해서 처리해봐야 할듯 하다. 얼마나 걸리는지가 핵심적인 키라고 생각이 들어, 임포트 로그 테이블에 처음 요청이 시작될떄의 시간과 끝날떄의 시간을 추가해놨다. 나중에 배포되고 나서도, 고객들의 요청이 처리되는데 어느정도 시간이 걸렸는지 데이터로 처리할 수 있도록. 회고 구현은 끝났다. 세상에서 제일 어려운 배포시간. ...

Today I Learned 날짜 2024년 7월 12일 금요일 내용 관계되지 않은 테이블 유저가 데이터를 가져오는 작업은 로그로 남기려고 한다. 다소 시간이 걸리는 작업이라 유저에게 임포팅 상태를 말해주기 위함이다. 로우데이터를 가져오기 떄문에, 로우데이터 테이블과 관계되어 NaverRawData 테이블의 하위 테이블로 NaverImportLog 를 만들었다. 문득 든 생각은, 이후 플랫폼이 추가될 떄마다 로그 테이블을 따로 둬야 하는게 맞는지에 대한 고민이다. 애초에 상태를 추적하기 위해서도 있지만, 동시에 다수의 임포팅작업이 진행될 경우 너무 많은 부하가 걸릴 수 있어 이를 제한하기 위한 목적도 있었다. 물론 이후 테스트를 통해 조절할 생각있지만.. 플랫폼(네이버, 메타, 카카오 등)별로 로그를 따로 두면 동시에 발생하는 임포팅 작업은 플랫폼 별 1개로 제한해야 하나? 그렇다면 제한하는 의미가 있나? 만약 통틀어서 1개만 동시에 진행되도록 해야한다면 현재 진행중인 작업이 있는지 확인하기 위해 모든 플랫폼의 로그 테이블을 탐색해야 한다. 그리고 새로운 플랫폼이 추가될 떄마다 이 부분에 대한 수정이 필요하다. 너무 불합리하다. 그래서 로그 테이블은 아에 독립되서 두기로 했다. 단, 탐색을 용이하게 하기 위해 플랫폼 필드를 추가하고, 로우 데이터 아이디도 추가했다. 두 값에 따라 연관된 로우데이터를 찾기 위해 향해야 할 테이블을 설정할 수 있다. ...

Today I Learned 날짜 2024년 7월 11일 목요일 내용 쇼피파이 앱 설치 인스타그램 댓글 가져오는 서비스가 쇼피파이 검수에서 반려당했다. 설치가 안된다길래 뭔소린가 싶어서 해보니 진짜 안됐다. 갑자기 왜… 겨우 세션토큰 만들어놨는데… 결국 하루종일 이것만 처리했다. 문제가 발생한 이유는, 이번에 개발한 앱이 임베디드라서 그렇다. 쇼피파이 어드민 내에 삽입되는 형태고, 서비스 내에서 주고 받는 요청은 항상 세션토큰이 헤더에 담겨있어야 한다. 이 세션 토큰은 프론트에서 앱 브릿지로 생성해야 한다. 기존 프로덕트 리뷰 같은 서비스들은 앱 설치 과정에서 프론트가 개입하지 않는다. ...