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일 목요일 내용 쇼피파이 앱 설치 인스타그램 댓글 가져오는 서비스가 쇼피파이 검수에서 반려당했다. 설치가 안된다길래 뭔소린가 싶어서 해보니 진짜 안됐다. 갑자기 왜… 겨우 세션토큰 만들어놨는데… 결국 하루종일 이것만 처리했다. 문제가 발생한 이유는, 이번에 개발한 앱이 임베디드라서 그렇다. 쇼피파이 어드민 내에 삽입되는 형태고, 서비스 내에서 주고 받는 요청은 항상 세션토큰이 헤더에 담겨있어야 한다. 이 세션 토큰은 프론트에서 앱 브릿지로 생성해야 한다. 기존 프로덕트 리뷰 같은 서비스들은 앱 설치 과정에서 프론트가 개입하지 않는다. ...
Today I Learned 날짜 2024년 7월 10일 수요일 내용 데이터 상태 처리 가져올 데이터가 많다보니, 처리에 시간이 꽤 걸린다. 따라서 유저에게 요청에 대한 응답을 보낸 후, 백그라운드에서 처리되야 한다. 대신 계속 유저에게 상태값을 알려줘야 한다. 기존에는 로우데이터가 가지는 상태의 종류는 두 가지였다. 유저가 로우 데이터 포맷을 만들면, 즉시 데이터를 임포팅해온다. 유저는 이 임포팅 상태를 알아야 한다. 진행 중인지, 대기중인지, 뭔가 잘못되서 실패했는지, 완료했는지를 임포팅 상태라고 부르고 관리하기로 했다. 위에서 말했듯, 요청은 꽤 많은 데이터를 주고 받는 작업이기 떄문에 동시에 하나씩만 처리하기로 했다. 유저가 짧은 시간내에 여러개의 로우데이터 포맷을 만들더라도 하나만 진행하고 나머지는 대기열에 두어야 한다. 클라이언트는 서버에 어떤 로우데이터 포맷의 임포팅 상태를 묻고, 서버는 그 상태를 반환하되 대기열이 있다면 대기열을 보내주도록 구현했다. ...
Today I Learned 날짜 2024년 7월 9일 화요일 내용 추상클래스 처리형식 여러 형태의 필요한 데이터들을 가져와 스프레드시트에 추가하는 기능을 만들었다. 대동소이하기 떄문에 추상클래스로 나름 깔끔하게 만들어봤다. 음청나게 길긴 하지만 결국 마지막 update_spreadsheet() 만 불러오면 된다. 이 클래스를 상속받아 데이터 타입별로 클래스를 생성했다. 그떄그떄 그 클래스를 불러오기 불편해서, 데이터타입에 맞게 알맞은 클래스를 불러오는 클래스를 추가했다. 저 변수 넣는것만 보기좋게 다듬으면 좋겠는데.. 어쩄든 클래스로 관리하니 요청 라우터는 깔끔해졌다. 회고 생각보다 구현이 잘되서 당황스럽다… ...