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일 목요일 내용 쇼피파이 앱 설치 인스타그램 댓글 가져오는 서비스가 쇼피파이 검수에서 반려당했다. 설치가 안된다길래 뭔소린가 싶어서 해보니 진짜 안됐다. 갑자기 왜… 겨우 세션토큰 만들어놨는데… 결국 하루종일 이것만 처리했다. 문제가 발생한 이유는, 이번에 개발한 앱이 임베디드라서 그렇다. 쇼피파이 어드민 내에 삽입되는 형태고, 서비스 내에서 주고 받는 요청은 항상 세션토큰이 헤더에 담겨있어야 한다. 이 세션 토큰은 프론트에서 앱 브릿지로 생성해야 한다. 기존 프로덕트 리뷰 같은 서비스들은 앱 설치 과정에서 프론트가 개입하지 않는다. ...
Today I Learned 날짜 2024년 7월 10일 수요일 내용 데이터 상태 처리 가져올 데이터가 많다보니, 처리에 시간이 꽤 걸린다. 따라서 유저에게 요청에 대한 응답을 보낸 후, 백그라운드에서 처리되야 한다. 대신 계속 유저에게 상태값을 알려줘야 한다. 기존에는 로우데이터가 가지는 상태의 종류는 두 가지였다. 유저가 로우 데이터 포맷을 만들면, 즉시 데이터를 임포팅해온다. 유저는 이 임포팅 상태를 알아야 한다. 진행 중인지, 대기중인지, 뭔가 잘못되서 실패했는지, 완료했는지를 임포팅 상태라고 부르고 관리하기로 했다. 위에서 말했듯, 요청은 꽤 많은 데이터를 주고 받는 작업이기 떄문에 동시에 하나씩만 처리하기로 했다. 유저가 짧은 시간내에 여러개의 로우데이터 포맷을 만들더라도 하나만 진행하고 나머지는 대기열에 두어야 한다. 클라이언트는 서버에 어떤 로우데이터 포맷의 임포팅 상태를 묻고, 서버는 그 상태를 반환하되 대기열이 있다면 대기열을 보내주도록 구현했다. ...
Today I Learned 날짜 2024년 7월 9일 화요일 내용 추상클래스 처리형식 여러 형태의 필요한 데이터들을 가져와 스프레드시트에 추가하는 기능을 만들었다. 대동소이하기 떄문에 추상클래스로 나름 깔끔하게 만들어봤다. 음청나게 길긴 하지만 결국 마지막 update_spreadsheet() 만 불러오면 된다. 이 클래스를 상속받아 데이터 타입별로 클래스를 생성했다. 그떄그떄 그 클래스를 불러오기 불편해서, 데이터타입에 맞게 알맞은 클래스를 불러오는 클래스를 추가했다. 저 변수 넣는것만 보기좋게 다듬으면 좋겠는데.. 어쩄든 클래스로 관리하니 요청 라우터는 깔끔해졌다. 회고 생각보다 구현이 잘되서 당황스럽다… ...
Today I Learned 날짜 2024년 7월 8일 월요일 내용 검색광고 데이터 가져오기(2) 기본적인 기능 구현을 완료했다. NSA_GTD, NSA_CTD 로우 데이터를 만들 때는 2가지 대용량 보고서를 만들고 데이터륿 참조해야한다. 네이버에선 100개 이상 보고서가 생성되면 가장 오래된 것을 기준으로 삭제해버린다. 이 두 가지 로우데이터는 최대 400일치 분량의 데이터를 가져와야하므로 하루에 2가지, 총 800개 보고서를 만들어서 데이터를 가져와야 한다. 보고서의 날짜는 하루짜리밖에 안된다. 100개 이상의 보고서를 만들 수 없으므로 나누어서 100개를 만들고 데이터를 취한다음 다음 100개를 다시 만들어야한다. 이때 기존에 만들어 놨던 100개는 삭제된다. ...
Today I Learned 날짜 2024년 7월 5일 금요일 내용 프리커밋 하나의 레포지토리에 여러 사람이 코드를 쓰는일이야 너무나 흔하다. 사람이 쓰는 자연어야 맞춤법을 규정하는 기관이 있지만(국립국어원), 코드는 꼭 그렇지는 않다. 팀마다, 사람마다 다르다. 들여쓰기는 4칸을 쓸것인가 2칸을 쓸것인가? import 문의 순서는 어떻게 둘것인가? 왜 중요할한가? 내가 변경사항을 깃에 올렸을때, 파일 전체의 들여쓰기가 원래 2칸이였다가 4칸으로 변경됐다면? 깃허브에서 파일의 변경점을 보여줄 때 파일 전체를 보여줄거다. “유의미한, 기능상 실질적인 변화”만 보여주는 건 불가능하다. 실제로 봐야할 곳은 1줄인데, 기록상으론 파일 전체가 바뀐셈이 되버린다. 모든 들여쓰기가 2칸 늘어났기 떄문이다. 코드 리뷰 하는 사람 입장에선 도대체 어디가 바뀐건지 눈이 빠지게 찾아야한다. 나중에 커밋 기록을 보려는 사람은 도대체 어디가 바뀐건지 알 턱이없다. 특히 깃렌즈를 쓰면 더욱. 그래서 코드 맞춤법을 맞춰야한다. ...