배경카프카 학습 과정에서 동시성 경합이 발생하는 선착순 쿠폰 발급 시나리오에서 초과 발급을 막기 위해 카프카를 도입해 보라는 요구사항을 접하게 되었습니다. 처음에는 의문이 들었습니다. 카프카는 메시지 브로커이지, Redis나 DB처럼 공유 자원의 값을 원자적으로 변경해 주는 도구는 아니기 때문입니다. 그렇다면 카프카는 선착순 쿠폰 발급 시나리오에서 어떤 역할을 할 수 있을까요? 이 글에서는 선착순 쿠폰 발급 시나리오를 통해 카프카를 동시성 제어 도구처럼 사용해보고, Redis와 DB 기반 방식과 비교해 보며, 최종적으로 카프카가 이 문제에서 어떤 역할을 맡는 것이 자연스러운지 정리해보려 합니다.목표쿠폰 경합과 같은 동시성 충돌 상황에서 N개의 쿠폰을 발급해야 할 때, 카프카를 도입해야 하는 이유에 대해 ..

배경e커머스 프로젝트를 진행하며 Retry, Timeout, Circuit Breaker와 같은 기법을 사용하여 장애 허용 시스템을 구현하고, 외부 서비스의 장애로부터 우리 서비스를 보호할 수 있도록 설계했습니다. 하지만 단순히 구현만으로는 실제로 우리 서비스가 안전한지를 확신할 수 없습니다. 따라서 의도적으로 시스템에 장애 상황을 주입하고 관찰하는 Chaos Engineering을 통해 해당 기법들이 정말 효과가 있는지를 테스트하는 과정이 필요합니다. 커머스 서비스와 가상 PG사 모듈을 예시로 장애 시나리오를 가정하여 외부 서비스 장애로부터 우리 서버가 잘 보호되는지, 만일 아니라면 어떻게 조정해야 하는지를 확인해 보았습니다.제약사항재시도, 타임아웃, 서킷 브레이커의 수치 설정 세팅은 실제 관찰 근거에..

배경Shareticon 프로젝트의 `쿠폰 목록 조회`라는 핵심 쿼리는 별도의 복합 인덱스 없이 사용되고 있었습니다. 가장 빈번하게 호출되는 핵심 쿼리인 만큼 인덱스의 필요성이 있을지, 만약 아니라면 어느 규모부터 필요 해질지에 대한 궁금증이 있어 관련하여 학습 및 정리해보고자 했습니다.목표실제 운영 데이터 규모에서 출발해 데이터를 늘려가며, 인덱스 도입이 효과를 보이기 시작하는 지점을 찾아봅니다. 그리고 선택도, 카디널리티 데이터 분포, 규모 등등을 바탕으로 인덱스 후보를 비교해 보고, 현재 쿼리에 적합한 인덱스 구성을 설계합니다.전제별도의 복합 인덱스 없이 PK, FK를 위해 생성된 인덱스만 존재하는 상태에서 분석을 시작했다.측정 시간은 `EXPLAIN ANALYZE`의 실행 시간을 기준으로, warm..

배경 이커머스 서비스에서는 여러 사용자가 동시에 같은 값을 변경하는 상황을 자주 만나게 됩니다. 대표적으로 상품 재고 차감이나 좋아요 수 집계가 그렇습니다.이런 값들은 처리 방식에 따라 데이터 정합성이 깨질 수 있는데요. 예를 들어 재고가 1개 남은 상품에 여러 주문 요청이 동시에 들어오면, 실제 재고보다 더 많은 주문이 성공할 수 있습니다.이번 글에서는 상품 재고 차감 시나리오를 예시로 동시성 문제를 해결하는 과정에서 DDD 관점으로 어떤 고민을 했는지 정리합니다.목표 & 제약사항동시에 여러 요청이 들어오는 경우에도 데이터 정합성을 유지하고, 비즈니스 규칙을 준수할 수 있어야 한다.이번 설계에서는 명시적 락을 사용하지 않고 DB 원자적 연산을 사용하여 락의 범위와, 지속 시간을 최소화해야 한다는 제약 ..

배경TDD 방식으로 회원 가입 기능을 구현하며, 객체 책임을 분리하게 되었던 과정을 소개합니다. 도메인 모델 테스트에 모든 도메인 규칙을 넣어도 괜찮을까?가장 처음 접근한 부분은 도메인 모델 `UserModel`의 단위 테스트 작성입니다. 도메인은 관련된 비즈니스 규칙과 관련된 책임을 가지는 객체이므로, 단위 테스트를 통해 회원과 관련된 규칙들을 검증할 수 있을 것 같습니다. 따라서 다음 규칙들을 `UserModelTest`에서 검증하도록 테스트 코드를 작성했습니다.로그인 ID 검증회원 이름 검증이메일 검증생년월일 검증그런데 비밀번호 관련 규칙을 검증하려고 했을 때 문제가 발생했습니다. 앞선 값들과는 다르게 비밀번호는 단순히 생성 규칙을 만족하는지만 확인하면 끝나는 값이 아닙니다. 비밀번호는 반드시 암호..

배경개인 프로젝트로 운영 중인 기프티콘 공유 서비스 shareticon를 사용하던 중, 이상한 증상을 발견하게 되었습니다. 오랫동안 서비스에 접속하지 않다가 쿠폰 목록을 조회하면 응답이 눈에 띄게 느려지는 경우가 생기는 것이었습니다.증상쿠폰 목록 조회 API에서 간헐적으로 1초 이상의 응답 지연이 발생합니다.장시간 쿠폰 목록 조회 API를 사용하지 않다가 호출하는 경우, API 응답까지 평균적으로 1초 이상 소요1회의 응답 지연 호출 이후에는 응답 속도가 30ms ~ 60ms 정도 수준으로 정상치로 복귀재현 결과 서버가 재기동된 직후만의 문제는 아님증상이 간헐적으로 발생했기 때문에, 재현 조건을 알아보기 위해 스크립트를 통해 호출 간격을 조금씩 늘려가며 테스트를 진행했습니다. 30분, 1시간, 2시간, ..