Project

서론 우리 타임딜 서비스 프로젝트에서의 대기열(Waiting Queue)의 목적은 "여러 사용자들이 몰릴 경우, 사용자의 주문 요청을 튕겨내지 않고 줄을 세워서 붙잡아두는 것"이다. 또한, 서비스 지속성 면에서의 목적으로는 대규모의 사용자가 주문을 요청할 경우, 주문(Order) 서버의 DB에 엄청난 부하가 가해지기에 서버 쪽에서 장애가 나거나 죽을 수도 있다. 따라서 대기열(Queue) 서버에서는 이러한 대규모 트래픽 상황에서의 DB 부하를 최소화하기 위해 Redis를 기반으로 대기열 데이터 구조를 설계하게 되었다. 본론 대기열 서비스에서 쓰일 Redis 큐를 다음과 같이 정의했다. Waiting Queue(대기열) : 주문 페이지에 입장하기까지 대기하는 상황Active Queue(활성열) : 주문 페..

DDD의 VO라는 개념에 대해 간단히 정리해보고, 대기열 서비스(msa)에서는 어떻게 적용되는지 정리해보았다. VO(Value Object)란 무엇이며, 대기열에 어떻게 적용할까? DDD에서 객체는 크게 엔티티(Entity)와 값 객체(VO)로 나뉜다.Entity: 식별자(ID)가 있고, 생명주기가 있어 내용이 변할 수 있는 객체. (예: QueuePolicy, QueueToken)VO (Value Object): 식별자가 없고, 값 그 자체로 의미를 가지며, 불변(Immutable)인 객체 그러면 아래에 있는 QueueToken은 VO일까 아니면 Entity일까? 보시다시피 @Entity 어노테이션은 따로 붙여져 있지 않은 상태이다.@Getter@Builderpublic class QueueToken ..

서론 새로운 프로젝트에 참여하게 되었다. 이번 프로젝트에서는 MSA에 대한 기본적인 이해를 바탕으로 DDD 기반의 대용량 처리 프로세스를 경험해보기로 하였는데, 그 중에서도 짧은 시간 동안 폭발적인 트래픽이 몰리는 특수한 도메인이기도 하고, 데이터 정합성 면에서의 문제 해결 경험을 다룰 수 있는 타임딜(Time Deal) 서비스를 주제로 선정하게 되었다. 타임딜 서비스의 핵심적인 문제는 다음과 같다.트래픽 과부하: DB 커넥션 풀이 과부화되어 전체 서비스가 마비될 위험동시성 이슈: 재고는 1개인데, 동시에 100명이 결제에 성공하는 '재고 초과 판매' 이슈 본론현재 프로젝트에서는 타임딜 상품만 판매하는 것으로 하게 되었는데, 타임딜 동안 몰리는 대규모 동시 접속과 대기열을 안정적으로 구성하는데에 집중하기..

서론 현재 프로젝트에서는 Gateway 서버를 통해 각 서비스에 요청을 하는 구조이다. 내가 현재 개발하고 있는 배송 서비스는 외부에서도 요청을 받아서 응답을 주고, 내부 서비스 간을 통해서도 요청/응답을 주고 받는 역할을 하는데 여기서 Delivery-Service가 느려지거나 멈추면 다른 MSA 서비스에도 장애를 전파할 위험이 높다. 현재 배송 서비스에서 장애가 날 법한 상황들은 다음과 같다. 데이터베이스 연결 지연/실패: 배송 정보 조회 시, DB 응답이 느려지거나 연결이 끊기는 경우이다. 서비스는 DB 응답을 기다리느라 쓰레드를 붙잡아 두게 되고, 이렇게 되면 Delivery-Service의 쓰레드가 모두 소진되어 서비스 전체의 장애로 이어질 수 있다.다른 마이크로 서비스 장애: 예를 들어, De..

서론 물류 시스템에서 "누가 이 배송을 담당할 것인가"는 서비스의 효율성을 결정짓는 기초적이면서도 중요한 요소이다.Delivery-Signal 프로젝트는 허브 간 이동부터 최종 배송까지의 전 과정을 다룬다. 이때 수많은 주문이 실시간으로 쏟아지는 상황에서 관리자가 일일이 배송 기사를 지정하는 것은 불가능하며, 특정 기사에게만 업무가 몰리는 상황 또한 방지되어야 한ㄷ.ㅏ 따라서 아래와 같은 목표를 설정하였다모든 배송 담당자에게 업무를 균등하게 분배해야 한다. (특정 담당자에게 일이 몰리는 일이 없어야 한다)주문 발생 시 시스템이 즉시 배송 담당자를 주문건에 매칭하도록 이를 자동화해야 한다.담당자가 퇴사하거나 삭제되어도 배송 담당자 매칭 절차(순번 할당)에 이상이 없어야 한다. 이를 해결하기 위해 가장 일반..

최근 진행하는 프로젝트에서는 MSA 학습과 동시에 DDD(Domain-Driven Design)와 CQRS도 시도해보기로 하였다. 다른 팀원들도 도메인 주도 설계라는 것을 처음 접해보기에 설계 원칙에 대해 이런저런 논의를 나누며 학습을 진행하고 있다. 어떻게 DDD 흉내를 내서 기능을 구현하고 PR을 올렸는데 다음과 같은 리뷰를 받았다. application 계층인 CreateDeliveryCommand에서 presentation 계층인 DeliveryManagerRequest를 역으로 의존하고 있다는 말이다. (command는 CQRS의 조회/쓰기 모델 분리 개념이다. 해당 프로젝트에서는 application 계층에서 command와 query DTO를 분리하여 CQRS 스타일의 조회 로직을 구성하였..

앱스토어에 앱을 배포한 이후, 테스트를 해보는 중에 해변별 기상 정보들을 불러오는 부분에서 필요 이상으로 시간이 오래 걸리기에 이를 해결하기로 하였다. 문제점 저번에도 꽤 걸렸었지만 이번에는 엄청 오래 걸린다.. 대략 13.30 s 정도..?현재 도시에 있는 해변 별로 기상청 API를 3가지 정도(해양 정보, 파주기, 수온) 불러오고 있는데 이를 순차적으로 불러오다보니 속도가 저하되는 것으로 의심하고 있다. 아마 말로만 듣던 순차적 API 호출로 인한 성능 저하로 의심되는데.. 이를 확인하기 위해 로그를 출력해보았다. 4번 도시에는 3개의 해변이 등록되어 있고, 각 해변 당 BeachForecast, WaterTemp, WavePeriod 기상청 API를 호출하고 있는데 이들 모두를 불러오는데 걸린..

이전 포스팅에 이어 서버에서 커서 기반 페이징 기법을 통하여 클라이언트 쪽에서 무한 스크롤 방식으로 데이터를 요청할 수 있도록 처리하는 과정을 정리해보고자 한다. Pageable일반적으로 페이징 처리를 할 경우, JPA에서 제공하는 Pageable이나 Slice 를 쓴다.클라이언트가 page와 size를 전달해야 한다. 일반적으로 page = 0부터 시작한다. Page 쿼리는 다음과 같이 실행된다.SELECT COUNT(*) FROM review WHERE vinyl_id = ?;SELECT * FROM review WHERE vinyl_id = ? LIMIT ? OFFSET ?; 전체 데이터의 개수를 알려주기 위해 COUNT 쿼리를 실행한다.총 데이터 개수와 총 페이지 개수를 반환해준다. 이를 통해 ..