분류 전체보기

서론 우리 타임딜 서비스 프로젝트에서의 대기열(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 스타일의 조회 로직을 구성하였..

배포 알못인 나는 AWS와 k8s는 막연하게 배포할 때 사용하는 기술들이라고만 알고 있었다. 최근 CI/CD에 대해 공부하면서 이들에 대해서도 알아야 할 필요성이 생겼고, 그 둘의 특징과 차이점을 정리해보았다. 구분AWSK8s (Kubernetes)분류클라우드 인프라 서비스 (IaaS)컨테이너 오케스트레이션 플랫폼 (PaaS)제공 역할서버, 네트워크, 스토리지 등 물리적 인프라 자원 제공.컨테이너화된 애플리케이션의 배포, 확장, 관리, 자동화를 담당위치애플리케이션이 실행될 바탕그 바탕 위에서 컨테이너를 관리하는 운영 체제/관리 시스템관계K8s는 AWS 위에서 실행될 수 있다 (EKS 서비스 등)AWS는 K8s에 실행 환경과 자원을 제공하는 하위 인프라 이 둘의 관계를 비유하자면 다음과 같다. AWS는 ..

구현하기 바빠서 넘어간 부분들을 조금이라도 정리해보고자 쓰는 TIL 시리즈입니다. 무중단배포라고 하면 일단 하나의 서버에 서비스가 중단되지 않고 계속 실행되고 배포되는 상태라고 막연히 알고 있었다. 그러나 개념을 잘못 알고 있었던 것을 최근에서야 깨닫게 되었다. 그래서 무중단배포란.. 기본 개념 / 필요성 하나의 서버가 아닌, 여러 대의 서버와 로드 밸런서를 이용하여 서비스를 계속 운영하면서 새 버전을 배포하는 기술이다. 구 버전 서버가 작동 중인 상태에서 신 버전 서버를 배포하고, 모든 준비가 완료되면 트래픽을 전환하여 서비스 중단(다운타임)을 방지하는 것을 목적으로 한다. 서비스가 중단되는 시간(다운타임) 없이 새로운 버전의 애플리케이션을 배포하는 전략무중단 배포는 하나의 서버가 아니라, 최소 두..