처음부터 차근차근

TL;DR대기열 토큰 발급 속도를 무작정 올리면 처리량이 느는 게 아니라 시스템만 터지므로, 다운스트림 처리량에 맞춰 초당 10명(100ms당 1명)으로 제한하는 것이 시스템 안정성의 정답이었다.들어가며E-Commerce 개인 프로젝트에서 블랙프라이데이를 가정한 주문 대기열 및 입장 토큰을 통해 DB 및 PG Client에 부하를 줄이기로 하였습니다. Redis Sorted Set을 통해 대기열을 구성하고, 입장 토큰 생명주기 등 설계 및 구현을 완료하였지만, "몇명씩 그리고 발급 주기는 어떻게 해야하는가"에 대한 고민이 생겨서 여러번의 테스트를 돌리고 적합한 발급 배치를 선정하게 되었습니다.대기열을 어떻게 설계했는가??대기열은 빠르게 넣고, 순서 보장이 되어야 하는 구조입니다. 또한 자신의 순서를 알 ..

TL;DR단일 모놀리식 환경에서 결제 도메인의 강결합을 해소하기 위해, 내부 일관성이 중요한 기존 도메인은 ApplicationEvent로 처리하고, 메인 흐름과 무관한 신규 후속 처리 도메인(product_metric)만 Kafka로 외부에 전파하여 코드 복제와 오버엔지니어링 없이 혼용하기로 결정했습니다. 이벤트 주도 설계의 도입, 그리고 뜻밖의 고민현재 제 프로젝트는 모든 도메인이 commerce-api에 집중되어 있는 모놀리식 구조입니다. 그러다 보니 트랜잭션 내에 도메인 간 과도한 결합이 존재했습니다.특히 Payment(결제) 도메인이 성공/실패할 때 주문 상태 변경, 재고 차감, 쿠폰 소멸에 이어 신규 기능인 product_metric(좋아요, 조회, 구매 통계)까지 너무 많은 주변 도메인이 하..

TL;DR옵티마이저는 쿼리 최적화 시, '비용(Cost)' 관점에서 가장 저렴해 보이는 선택을 하며, 이때 불확실성을 제거하는 부분이 포함되어있다.배경 - 상품 목록 조회 동작을 빠르게 한다.E-commerce 프로젝트 중, 상품 목록 조회 API에서 N+1의 문제가 존재했었습니다. 이 문제를 해결하면서 상품 목록 조회 성능 개선을 위해 여러가지 방법을 고려했습니다.현재 상품 목록 조회 시 사용하는 Table은 3개가 존재합니다.각각의 테스트 데이터 수는 이렇습니다.Brand : 1,000개Product : 1,000,000개 (Brand 당 1000개 씩 보유)Inventory : 1,000,000개 (Product와 1:1)상품 목록 조회 시 상품의 Brand와 재고 또한 알아야 하기 때문에, 2개의..

나는 현업에서 TDD를 쓰지 않았다.웹 스크래핑 & 크롤링 전문이였던 전 회사를 다니면서 사실 저는 TDD를 쓰지 않았습니다.외부 의존성(외부 사이트라고 생각)에 너무 크고, 시시 각각 수집해야되는 대상이 변경되고, 요구사항은 많고, 에러는 외부 의존성이 조금이라도 변경되면 계속 발생하고.. 그러다 보니 잘 안쓰게 된것입니다. 올해 2월 퇴사를 하고, 부트캠프 교육을 듣는데- 프로젝트에 TDD를 적용해서 user 도메인 만들기이것을 딱 보고서, 저는 굉장히 과제가 처음에는 쉽다고 느껴졌습니다. 하지만 하다보면서, 느낀점은 TDD도 안쓰고, 심지어 DDD(이미 프로젝트에 DDD가 적용되어 있는 상태)도 안써본 저로써는. TestDouble, @SpringBootTest, DDD 시 각 Layer마다 하는 ..

Page.on()이란Puppeteer 공식문서에는 이렇게 적혀있다.Listen to page events.This method exists to define event typings and handle proper wireup of cooperative request interception. Actual event listening and dispatching is delegated to EventEmitter.즉, 어떤 이벤트가 발생하면, 어떤 동작을 할 수 있도록 설정하는 것이다.class Page { on( eventName: K, handler: (event: PageEventObject[K]) => void ): EventEmitter;}이 메서드를 사용하려면 우선, 모든 Requ..

날짜와 시간 라이브러리가 필요한 이유우리가 프로그래밍을 하면서, 로그를 남기거나, 혹은 회원 생성 시간 및 게시글 생성 시간 등 날짜와 시간에 대한 기록이 필요하다.단순히 날짜와 시간만 기록하면 되는게 아닌가? 싶지만, 날짜와 시간을 계산하는 것은 의외로 복잡하다.날짜와 시간 차이 계산윤년 계산일광 절약 시간 변환타임존 계산이를 위해서 Java에서는 라이브러리를 제공하고 있다.Java 날짜와 시간 라이브러리*: 초는 나노초 단위의 정밀도로 캡처된다. (밀리초, 나노초 가능)**: 이 클래스는 이 정보를 저장하지는 않지만 이러한 단위로 시간을 제공하는 메서드가 있다.***: ZonedDateTime 에 Period 를 추가하면 서머타임 또는 기타 현지 시간 차이를 준수한다.LocalDate, LocalTi..

Overview웹 크롤링 시, page가 로딩되는 것을 기다리거나, 혹은 특정 API의 응답을 기다리거나 할 떄가 필요하다.이러한 경우, page의 waitForXXX 메서드를 사용해서 특정 시간, 응답까지 기다릴 수 있도록 만들어준다.이를 통해 웹 크롤링 시 page 로드 관련 대기 시간을 설정하는 것이 아니라, page가 load 되면 바로 진행할 수 있도록 하거나, 특정 API가 load 된다면 바로 작업을 진행할 수 있도록 하여 웹 크롤링 로직 시간을 단축할 수 있다.page.goto 시 waitUntil 관련waitUntil은 puppeteerLifeCycleEvent과 연관되어있다.load : 페이지의 모든 리소스(이미지, 스타일시트, 스크립트 등)가 완전히 로드되었을 때 발생하는 이벤트입니다..

NFS subdir external provisioner란 무엇인가?NFS subdir external provisioner는 PVC(Persistent Volumes Claim)을 통해 NFS 서버를 쿠버네티스 PV(Persistent Volum)로 동적 프로비저닝(dynamic provisioning) 하기 위한 automatic provisioner 입니다. PV(Persistent Volum)는 ${namespace}-${pvcName}-${pvName}으로 프로비저닝 됩니다. 공식 문서에도 보면, Kubernetes에는 내장 nfs provisioner가 존재하지 않는다.따라서 외부 provisioner를 사용하라고 나와있다. Storage ClassesThis document describes..

Kubernetes Volumes의 정의쿠버네티스 파드 내에서 돌아가는 컨테이너는 고유한 파일 시스템을 갖는다. 파일 시스템은 컨테이너 이미지에서 제공되기 때문이다.컨테이너 내의 디스크에 있는 파일은 임시적이며, 컨테이너에서 실행될 때 애플리케이션에 적지 않은 몇 가지 문제가 발생한다.컨테이너가 재시작될 때 파일이 손실된다는 것이다. 컨테이너를 다시 시작하면 초기화된 상태이기 떄문이다.Pod에서 같이 실행되는 컨테이너 간에 파일을 공유할 때 발생한다.이러한 문제를 해결하기 위해 쿠버네티스는 볼륨 추상화를 제공하고 있다.Kubernetes Volumes의 배경Ephemeral volume(일회성의 볼륨)은 pod의 life time에 따라 결정되지만, persistent volume(PV, 영구적인 볼륨)..

NFS란?Network File System의 약자로, 네트워크에 파일을 저장하는 메커니즘이다.이 시스템을 통해 사용자가 원격 컴퓨터에 있는 파일 및 디렉토리에 엑세스 할 수 있고 해당 파일 및 디렉토리가 로컬에 있는 것처럼 허용하는 분산 파일 시스템입니다.사용자는 운영 체제 명령을 사용하여 원격 파일 및 디렉토리에 대한 파일 속성을 작성, 제거, 읽기, 쓰기, 설정할 수 있습니다.NFS를 왜 사용할까??여러 사용자 혹은 서버에서 파일을 공유하는데 유용하게 사용된다.또한 서버가 망가지더라도 데이터는 유지되기 때문에, 데이터를 보존하는데 굉장히 좋다.그러나 단점도 존재한다.네트워크를 사용하여 파일을 접근하기 때문에 보안에 취약할 수 있다.NFS 구축 방법CentOS 7.9 버전 환경에서 구축하는 방법을 소..