대기열에서 참여열로, 적정 배치 사이즈는 얼마일까?
대기열 시스템을 학습하며, 대기열을 통과한 사용자를 참여열로 이동시킬 때 "적절한 배치 사이즈와 스케줄링 주기는 얼마인가?"라는 의문이 들었다. 배치 사이즈가 너무 크면 대기열의 의미가 퇴색되고, 너무 작으면 서버 자원이 낭비되고 사용자 대기 시간이 길어져 사용자 경험이 떨어진다. 이 글에서는 실제 테스트와 계산을 통해 적정한 배치 사이즈를 찾아본 과정을 공유하고자 한다.
Recent posts
DDD를 적용하며 깨달은 객체 동등성의 중요성
학부생 때 전공 과목 프로젝트로 진행하였던 카풀 프로젝트를 도메인 주도 설계(DDD)의 헥사고날 아키텍처 기반으로 리팩토링하였다. 리팩토링 과정에서 특정 도메인을 표현하기 위해 도메인 엔티티와 VO(Value Object)를 정의하며 기능을 구현해나갔다. 이후 테스트 코드를 작성하며 스터빙(Stubbing)을 진행하고, 이를 해결하기 위해 any(...) 메서드를 사용하며 부정확한 테스트를 작성하고 있었다는 점을 인지하게 되었다. 이번 포스팅에서는 이러한 경험을 계기로 도메인 주도 설계에서 객체의 동등성 보장이 왜 중요한지에 대해 고민하고, 이를 통해 얻은 인사이트를 공유해보고자 한다.
도메인 이벤트 재발행 구조 도입기 3 - 이벤트 아웃박스 폴링을 통한 이벤트 발행
여행 기록 관리 플랫폼 '여기가' 프로젝트를 진행하며 이메일 인증·비밀번호 초기화 이메일 전송 기능 개발을 담당하게 되었다. 이메일 전송은 외부 메일 서버를 거쳐 실행되는 작업으로 Network I/O 등 시간이 오래 걸리는 작업이다. 따라서, 핵심 비즈니스 로직과 이메일 발송 로직을 분리하여 결합도를 낮추고, 향후 메일 서버 분리의 확장성을 염두에 두고 이메일 발송 로직을 이벤트 기반 아키텍처(EDA)로 분리하였다. EDA 도입 후 메시지 브로커로 이벤트가 발행되지 않아 이벤트가 유실되는 문제를 겪고 이에 대한 해결 방법을 모색하던 중 'Transactional Outbox Pattern'을 알게 되었다. 이번 포스팅에서는 저장된 이벤트 아웃박스를 폴링하여 실패·미발행 이벤트를 발행하는 구조를 구현한 경험을 공유하고자 한다.
도메인 이벤트 재발행 구조 도입기 2 - 커밋 직후 발행과 RabbitMQ Publish Confirm
여행 기록 관리 플랫폼 '여기가' 프로젝트를 진행하며 이메일 인증·비밀번호 초기화 이메일 전송 기능 개발을 담당하게 되었다. 이메일 전송은 외부 메일 서버를 거쳐 실행되는 작업으로 Network I/O 등 시간이 오래 걸리는 작업이다. 따라서, 핵심 비즈니스 로직과 이메일 발송 로직을 분리하여 결합도를 낮추고, 향후 메일 서버 분리의 확장성을 염두에 두고 이메일 발송 로직을 이벤트 기반 아키텍처(EDA)로 분리하였다. EDA 도입 후 메시지 브로커로 이벤트가 발행되지 않아 이벤트가 유실되는 문제를 겪고 이에 대한 해결 방법을 모색하던 중 'Transactional Outbox Pattern'을 알게 되었다. 이번 포스팅에서는 각 도메인 이벤트를 일관된 EventOutbox로 변환하여 저장하는 과정을 구현한 경험을 공유하고자 한다.
도메인 이벤트 재발행 구조 도입기 1 - Event Outbox의 저장
여행 기록 관리 플랫폼 '여기가' 프로젝트를 진행하며 이메일 인증·비밀번호 초기화 이메일 전송 기능 개발을 담당하게 되었다. 이메일 전송은 외부 메일 서버를 거쳐 실행되는 작업으로 Network I/O 등 시간이 오래 걸리는 작업이다. 따라서, 핵심 비즈니스 로직과 이메일 발송 로직을 분리하여 결합도를 낮추고, 향후 메일 서버 분리의 확장성을 염두에 두고 이메일 발송 로직을 이벤트 기반 아키텍처(EDA)로 분리하였다. EDA 도입 후 메시지 브로커로 이벤트가 발행되지 않아 이벤트가 유실되는 문제를 겪고 이에 대한 해결 방법을 모색하던 중 'Transactional Outbox Pattern'을 알게 되었다. 이번 포스팅에서는 각 도메인 이벤트를 일관된 EventOutbox로 변환하여 저장하는 과정을 구현한 경험을 공유하고자 한다.