그런데 GA4를 열어보니 현실은 달랐거든요.

문제: 숫자가 말해주는 현실

GA4 리포트를 열어봤더니 대시보드 페이지뷰는 429인데, 시험 결과 페이지뷰는 고작 몇십 건이었습니다. 오답노트 페이지는 거의 방문이 없었고요.

"리텐션이 안 좋은 것 같다"는 느낌은 있었는데, 정확히 어디서 얼마나 빠지는지 모르고 있었습니다. 그래서 이번에 제대로 파보기로 했습니다.

데이터 파이프라인부터 만들었습니다

보통은 GA4 화면을 캡처해서 공유하고, DB는 SQL 쿼리를 하나하나 돌리는데요. 이번엔 다른 방식을 써봤습니다. Claude Code(AI 코딩 에이전트)가 직접 데이터를 조회하고 분석할 수 있도록 파이프라인을 구성했거든요.

Supabase DB 직접 조회

Supabase는 REST API를 제공하고 있어서, Service Role Key만 있으면 바로 쿼리가 가능합니다.

curl -s "https://{url}/rest/v1/exams?select=user_id,status,created_at" \
  -H "apikey: {SERVICE_ROLE_KEY}" \
  -H "Authorization: Bearer {SERVICE_ROLE_KEY}"

GA4 Data API 연동

GA4는 서비스 계정을 만들고 Python google-analytics-data 라이브러리로 접근했습니다. 트래픽, 이벤트 퍼널, 트래픽 소스 같은 데이터를 프로그래밍으로 뽑을 수 있게 됐거든요.

이렇게 세팅해두니까 "가입 전환율이 몇 %야?", "오답노트 사용률은?" 같은 질문에 바로 데이터로 답할 수 있게 되었습니다. 감이 아니라 숫자로 판단할 수 있는 환경이 된 거죠.

퍼널을 뜯어봤더니

GA4 이벤트 데이터와 DB 데이터를 교차 분석해서 전체 퍼널을 그려봤습니다.

방문 131명 → 가입 40명(31%) → 시험시작 28명 → 시험완료 22명 → 재방문 3명(11%)

이벤트 기반으로 더 상세하게 보면

여기서 눈에 띄는 건 두 가지였는데요.

첫째, CTA를 클릭한 71명 중 가입 완료는 29명뿐이었습니다. 카카오 로그인 과정에서 42%가 이탈하고 있었거든요.

둘째, 가입하면 시험은 거의 100% 시작합니다. 근데 그 다음이 문제였습니다.

DB를 파보니 더 심각했습니다

DB에서 유저별 행동 패턴을 분류해봤더니 이런 그림이 나왔습니다.

75%가 첫날 이후 돌아오지 않는 거였습니다. 그리고 오답노트 데이터를 보면 더 놀라운데요.

오답노트 126개 생성, 6개 열람(5%), 메모 작성은 4개(3%)

핵심 기능이라고 생각했던 오답노트를 아무도 안 쓰고 있었습니다.

한 가지 더 확인한 건 점수와 이탈의 상관관계였는데요. 이탈 유저 평균 60점, 재방문 유저 평균 62점으로 유의미한 차이가 없었습니다. 시험을 못 봐서 떠나는 게 아니었던 거죠.

진단: 새는 양동이에 물 붓기

데이터를 종합해보니 사용자 여정이 이렇게 흘러가고 있었습니다.

랜딩 방문 → 가입 → 시험 시작 → 시험 완료 → 점수 확인 → "그래서?" → 이탈

문제의 핵심은 시험 완료 후 "다음 행동"이 없다는 거였습니다. 점수를 확인하고 나면 할 게 없거든요. 오답노트 페이지는 별도로 찾아가야 했고, 재시험을 보려면 처음부터 새로 만들어야 했습니다.

처음에는 "마케팅을 더 열심히 해야 하나?" 싶었는데요. 데이터를 보니 정반대였습니다.

지금 상태로 마케팅 예산을 2배 써서 262명이 와도, 재방문하는 건 6명뿐입니다. 전환율은 변하지 않거든요.

리텐션을 해결하지 않고 마케팅을 늘리는 건 새는 양동이에 물을 더 붓는 거였습니다.

실행 계획: P0부터 차근차근

분석 결과를 토대로 우선순위를 매겼습니다. 기준은 간단했는데요 - 퍼널에서 가장 많이 새는 곳부터 막는 겁니다.

P0: 활성화 루프 만들기 (가장 시급)

시험 완료 후 "다음에 뭘 해야 하지?"를 해결하는 게 1순위입니다.

결과 화면 강화 - 현재는 점수와 오답 리스트만 보여주는데, 약점 토픽 분석("인덱싱에서 0/2 틀림")과 함께 "이 개념 복습하기" 링크로 학습 가이드에 바로 연결하려고 합니다.

오답노트 인라인 표시 - 별도 페이지로 이동해야 보이던 오답노트를 결과 화면 하단에 바로 보여줍니다. 사용자가 "찾아가는" 게 아니라 "자동으로 보이는" 경험으로 바꾸는 거죠.

오답만 재시험 - 틀린 문제만 모아서 바로 다시 풀 수 있게 합니다. 전부 맞출 때까지 반복하면 당일 학습 루프가 완성되는 구조입니다.

P1: 랜딩 전환율 개선 (31% → 50%)

CTA 클릭 71명 중 가입은 29명이었는데요. 카카오 로그인 허들이 큰 게 문제였습니다. 그래서 로그인 없이 3문제를 체험할 수 있게 하고, 결과를 보려면 가입하도록 유도하려 합니다.

P2: 재방문 동기 만들기

학습 현황 대시보드(토픽별 마스터율 시각화), 약점 기반 시험 추천 같은 것들입니다. P0가 해결되고 나서 진행할 예정입니다.

AI를 분석 도구로 쓴 소감

이번에 인상적이었던 건, AI한테 "리텐션이 낮은데 어떡해?"라고 물어본 게 아니라 GA4와 DB 데이터를 직접 조회할 수 있는 환경을 만들어줬다는 점입니다.

Claude Code에 Supabase REST API 접근 권한과 GA4 서비스 계정을 연결해두니, "유저별 시험 횟수 분포 보여줘", "이벤트 퍼널 그려봐" 같은 요청에 즉시 데이터를 뽑아서 분석해주더라고요. 사람이 GA4 화면을 캡처해서 공유하는 것보다 훨씬 빠르고, 교차 분석도 바로 가능했습니다.

핵심은 AI한테 "답을 달라"고 한 게 아니라 "데이터를 볼 수 있는 눈을 줬다"는 것인데요. 데이터에 접근할 수 있으니 추측이 아닌 근거 기반 분석이 나온 거죠.

정리하며

느낌으로 "리텐션이 안 좋다"를 알고 있는 것과, 데이터로 "75%가 첫날 이탈하고 오답노트 사용률은 5%"를 확인하는 건 전혀 다른 문제였습니다.

전자는 "마케팅을 더 해볼까?" 같은 막연한 대응으로 이어지는 반면, 후자는 "시험 결과 화면 다음에 할 게 없어서 나간다"는 구체적인 진단이 되거든요.

사이드 프로젝트에서 데이터 파이프라인을 만드는 게 거창하게 느껴질 수 있는데요. Supabase REST API + GA4 Data API 조합이면 생각보다 간단하게 세팅할 수 있었습니다. 비슷한 상황에 계신 분들 참고가 되면 좋겠습니다.

아키텍처에서 가장 흔한 안티패턴 중 하나 101

\=> 모든 아키텍처 특성을 지원하는 제네릭 아키텍처를 설계하려는것.

1. 그래서 우선 도메인 관심사에서 아키텍처 특성을 도출해야한다.

2. 도메인 이해관계자들과 아키텍트는 서로 다른 말을 한다. 그래서 도메인 관심사를 아키텍처 특성을 옮겨야한다. 아래는 일반적인 도메인 관심사와 이를 뒷받침 하는 아키텍처 특성을 정리하는 표이다.

4. 암묵적 아키텍처 특성

• 가용성 => 유저는 언제든지 접속할 수 있어야한다.

• 신뢰성 => 시스템을 문제없이 사용하려면 반드시 필요하다.

  • 구입하려고 사이트 접속했는데 자꾸 접속 끊기면 리텐션 없을거임.

• 보안 => 모든 시스템에 공통적인 암묵적 특성

  • 안전하지않은 소프트웨어를 원하는 사람은 아무도 없다.

아키텍처 특서은 서로 연관되어 움직이므로 중요도(Criticality)에 따라 우선순위는 달라질 수 있다. 아키텍트는 보안이 설계의 구조적인 측면에 영향을 미치거나 애플리케이션에 매우 중대한 요소라고 판단할 경우 아키텍처 특성으로 간주한다.

다만, 그 과정에서 얼마나 의미있는 알맹이를 가지고있느냐가 중요한거같다. 또한, 통합과 전달을 하는 매개체가 올바르지않다면, 아무리 통합과 전달을 주기적으로 잘 실행해도 성숙해지지 않을 수 있다.

DDD의 전략적 설계 안에는 여러가지 개념들이 있다.

그 개념중 하나로는 Subdomain이 있는데, 이 개념안에는 몇가지 유형들로 나뉘어진다.

유형으로 나눈 목적과 그로 얻고자 하는 가치가 매우 확고하여, 유형들의 구분은 매우 중요하다고 생각된다.

반버논이 말한 팩터들을 가지고 내용을 정리해본다.

Subdomain이 뭐죠?

Subdomain은 전체 비지니스 도메인의 하위 부분을 말한다.

대부분의 비지니스 도메인은 전체를 포괄적으로 바라보기에는 너무 크고 복잡하기 마련이다.

그래서 거대하고 복잡한, 프로젝트 내에서 문제 영역을 논리적으로 쪼개는데 사용되는것이 Subdomain이다.

결국 비지니스의 핵심 영역에 대해 관심사를 나누는것이다. 그리고 Subdomain을 개발하는데, DDD를 사용했다면 매우 명확한 Bounded Context를 만들어낼 수 있다. (반버논은 DDD를 사용할 때, Bounded Context와 Subdomain은 일대일 관계를 맺도록 권장한다. 다만 목표에 가깝고, 예외는 언제든지 있다)

Subdomain의 유형은 3가지로 나뉜다

핵심 도메인

보편언어를 신중하게 만들기 위한 전략적 투자 영역으로, 주요 자원을 할당하는 명시적인 Bounded Context이다.

여기에는 잘 정의된 도메인 모델이 존재한다. 이 핵심 도메인은 다른 경쟁자들에 대한 차별화를 만들 영역이기 때문에 프로젝트 목록에서 매우 높은 우선순위를 갖는다.

기업은 경쟁사와 모든 것을 차별화 할 수 없기 때문에, 핵심 도메인은 기업이 특히 더 뛰어나야하는 부분에 대한 경계를 구분해준다.

따라서, 핵심 도메인은 소프트웨어에서 가장 큰 투자가 필요한 곳이다.

지원 서브도메인

이미 존재하는 제품으로 해결할 수 없는 맞춤 제작 개발이 필요한 모델링 영역을 말한다.

여기에는 핵심 도메인에서와 같은 투자 방식을 동일하게 따를 필요는 없다. 전략적 차별화를 위해 투자한 것에 실패하지않으면서도 지원 형태의 Bounded Context에 너무 큰 투자를 하지 않기위해 아웃소싱을 고려해볼 수 있다.

하지만, 알겠지만 지원 서브도메인 없이는 핵심 도메인을 성공시킬수는 없다. 지원 서브도메인이 존재해야 핵심 도메인을 성공시킬 수 있다. 즉, 지원 서브도메인도 중요한 소프트웨어 모델이다.

일반 서브도메인

기존 제품 구매를 통해 바로 충족시킬 수 있는 경우에 해당한다. 아웃소싱을 할 수도있고, 핵심 도메인 또는 좀 더 작은 지원 서브도메인에 할당된 엘리트 개발자가 없는 팀에서 직접 개발을 할 수 있는 영역이다.

따라서, 일반 서브도메인을 핵심 도메인으로 오해하지않아야한다. 오해하게된다면, 핵심 도메인의 투자를 일반 도메인에 할 수 있기때문이다.

위 세가지 유형을 현재 내가 기여하고있는 제품에 접목시켜보면, 생각보다 쉽게 유형 구분이 가능하다. 놀라운것은 팀원 모두가 위 유형을 명확하게 표현만 안했지, 서브 도메인들을 설명하고 개선이 필요할 때 암묵적으로 유형들을 나뉘어 설명하곤했다.

요즘 개인적으로, 표현할 때 암묵적으로, 느낌적인 느낌(?)으로, 감각적으로 등의 설명을 정의된 용어를 찾았을 때 작은 희열을 느낀다. 우리는 대개 전략적으로 보편 언어를 사용하게되는 이점은 매우 뚜렷한것을 알지만, 제품 관련이 아니라면 보편언어 선정을 고려하지않는 경우가 많다. 개념에 대한 명확한 확립이 안되면, 목적은 동일하지만 표현 차이로 불필요한 비용이 발생할 수 있는데 이런 부분들을 하나씩 해소해나가고자 이번 글을 작성했다.

특히 어떤 일에 대한 착상이나 구상인 Idea에 대해 이야기를 전달해야한다면, 더더욱 어렵다.

이럴 때, 먼저 함께 이해하고 쓸 수 있는 방법과 용어 같은 “공통 기반”을 마련하면 좋다.

• A가 B에게 비지니스에 관해 이야기할 때, 어떤 용어를 사용하며, 그 용어가 뭘 의미하는지 설명하고

• 지금 얘기하고있는것은 어떤 업무처리 과정과 관련이 있는지 설명하고

• 업무처리 과정에서 중요한 단계는 무엇일지 설명하고

• 누가 그 업무처리 과정에 관련이 있을지 설명한다

이런 일련의 과정을 어떻게 설명하면 좋을까?

EDA(Event-Driven Architecuture) 환경을 설계할 때 Event에 대해서 여러 종류가 존재한다는것을 대부분 알고있을것이다.

필자가 최근 기여하고있는 제품은 다양한 이벤트들을 생산(produce)하고 소비(consume)하여 많은 도메인 서비스 컴포넌트 간 데이터를 동기화하고 일관성을 최종적으로 확보하는 구조이다.

팀 내에서 제품을 만들 때 DDD(Domain-Driven Design) 방법론을 적극적으로 활용하고 있음에도, 욕구적으로 도메인 이벤트라 정의했는데도 불구하고 애그리것의 상태만 담긴것이 아닌 다른 컴포넌트에서 처리까지를 기대하여 개념에 위배되는 이벤트 설계를 하는 좋지않은 사고가 생긴다 생각되어 이번 기회에 명확하게 개념들을 구분지어보려한다.

개념들은 크게는 도메인 이벤트(Domain Event), 통합 이벤트(Integration Event), 외부 이벤트(External Event)로 나눌 수 있다. 외부 이벤트는 정말 외부에서 호출되는 훅이나 API 요청을 말하는것이기때문에 이번 글에서 생략한다.

이벤트 기반 시스템은 왜 채택하는걸까?

전통적인 모놀리식(monolithic) 아키텍처에서는 서비스 간 강한 결합 (tight coupling) 때문에 확장성과 유지보수성이 떨어지는 경우가 많았다. 이런 문제점을 해결하기 위해 서비스들을 분리했고, 단순 컴포넌트들을 분리만 한다고 위 문제들을 해결할 수 없기에 이벤트 기반 시스템(Event-Driven Architecture, EDA)을 구축해 비동기 메시징을 통해 서비스 간 결합도를 낮추고, 확장성을 높이는 방식을 택하면서 많은 기업에서 채택하기 시작했다.

(물론 비동기 프로세싱을 통해 동시 처리량을 높이는 이유도 있을 수 있겠지만, 이는 이번글에서 큰 관련이 없어 넘어간다)

그래서 이벤트 기반 시스템이 각광받는 이유를 정리해보면 다음과 같다.

1. 비동기 처리 및 확장성

이벤트를 큐잉하여 병렬로 처리가 가능해진다. (e.g. 결제 승인 후 즉시 배송 준비 or 배치 잡에서 메시징을 이용해 동시 처리 성능을 올려야할 때 등)

2. 마이크로서비스 간 결합도 감소

직접적인 API 호출 없이 서비스 간 독립적인 비동기 통신이 가능해진다. 즉, 각 서비스들 간 직접 통신이 아닌 메시지 브로커를 통해 처리하는것이다.

3. 최종적 일관성 (Eventual Consistency) 보장

중앙 데이터베이스가 없더라도, 이벤트 기반으로 데이터 정합성을 맞출 수 있다.

4. 실시간 반응형 시스템 구축 용이

고객 행동 데이터를 실시간 분석해야하거나, 특정 도메인에서 사건이 발생했을 때 리액티브하게 알림을 처리하거나 등등의 유즈케이스에서 최적화를 할 수 있다.

그러나 여기서 말하는 이벤트들은 모두 동일한 책임과 관심사를 갖고있진않다. 이는 이벤트를 설계할 때 정말 중요한 요소이다. 하나씩 알아보자.

도메인 이벤트 (Domain Event)

도메인 이벤트는 도메인 모델 내부에서 발생하는 비지니스적으로 중요한 사건을 말한다. 주로 특정 애그리거트(Aggregate)에서 비지니스 규칙을 반영하고 같은 Bounded Context 내에서 동작한다.

도메인 이벤트는 어떻게 동작하나요?

• 특정 Aggregate에서 상태 변화가 발생하면, 트랜잭션 내에서 이벤트를 발생시킨다.

• 같은 Bounded Context 내에서 이벤트 핸들러를 통해 비지니스 로직을 확장하거나 후속 처리를 수행한다.

• 보통 실무에선 동기 또는 내부 비동기 메시징 방식으로 처리한다.

예시

일반적인 커머스에서 주문을 처리하는 과정을 묘사해보면, 주문 완료 시 재고가 할당되고, 결제가 요청될것이다.

이를 주문됨(OrderPlaced) => 재고 할당됨(ItemStockAllocated) => 결제 요청됨(PaymentInitiated) 순으로 후속 트리거 되어 주문의 프로세스가 처리된다.

이 때, 주의를 해야하는것은 주문됨 사건은 Order Aggregate의 도메인 이벤트임으로 외부 서비스(e.g. 배송)에 대한 내용을 담으면 안된다. 예시 코드로 보면 다음과 같다.

잘못된 예시

data class OrderPlaced(
    val orderId: String,
    val userId: String,
    val shippingAddress: String,  // X 배송 관련 정보가 포함되어 있다
    val deliveryDate: LocalDate   // X 주문 서비스의 도메인 이벤트에서 배송 컨텍스트가 포함되어있다
)

@Service
class OrderService(private val applicationEventPublisher: ApplicationEventPublisher) {

    fun placeOrder(orderId: String, userId: String, shippingAddress: String) {
        // place order domain logic...
        println("주문이 생성되었습니다. 주문 ID: $orderId")

        // 여기서 주문됨 이벤트를 생산할 때, 배송 서비스의 처리를 위해 배송 컨텍스트가 주문 애그리것 도메인 이벤트에 포함이 되어있다.
        val event = OrderPlaced(orderId, userId, shippingAddress, LocalDate.now().plusDays(3))
        applicationEventPublisher.publishEvent(event)
    }
}

주문을 할 때 보통 배송지와 같은 정보를 입력한다. 이 때, 배송지에 대한 컨텍스트가 주문 애그리거트의 속성인지 아닌지를 이벤트 설계할 때 판단해야한다. 단순하게 해당 이벤트를 브로커를 통해 발행해 배송 컴포넌트에서 처리가 되어야하기에 넣는다면, 이는 도메인 이벤트가 아닌 통합이벤트가 된다.

대게 주문의 생성과 배송의 생성은 별개이다. 주문이 생성되었다고 반드시 배송이 생성된다는 보장이 없으며, 위 논리라면 배송 서비스가 OrderPlaced 도메인 이벤트에 강하게 의존되며 주문 서비스가 배송 서비스의 변경에 취약해진다.

올바르게 수정한 OrderService

data class OrderPlaced(val orderId: String, val userId: String)

@Service
class OrderService(
    private val applicationEventPublisher: ApplicationEventPublisher,
    private val kafkaTemplate: KafkaTemplate<String, OrderCreatedIntegrationEvent>
) {

    fun placeOrder(orderId: String, userId: String, shippingAddress: String) {
        // place order domain logic...
        println("주문이 생성되었습니다. 주문 ID: $orderId")

        val domainEvent = OrderPlaced(orderId, userId)
        applicationEventPublisher.publishEvent(domainEvent)

        val integrationEvent = OrderCreatedIntegrationEvent(orderId, userId, shippingAddress, LocalDate.now().plusDays(3))
        kafkaTemplate.send("order-created-topic", integrationEvent)
    }
}

ShippingService

data class OrderCreatedIntegrationEvent(
    val orderId: String,
    val userId: String,
    val shippingAddress: String,
    val deliveryDate: LocalDate
)

@Component
class ShippingService {

    // 주문 애그리것의 도메인 이벤트가 아닌 통합 이벤트를 구독하고있다.
    @KafkaListener(topics = ["order-created-topic"], groupId = "shipping-service")
    fun handleOrderCreatedEvent(event: OrderCreatedIntegrationEvent) {
        println("배송 준비 시작! 주문 ID: ${event.orderId}, 주소: ${event.shippingAddress}")
    }
}

그래서 위와 같이 생성된 Order Aggregate의 변화만 담기는 것이 중요하다. 도메인 이벤트와 통합 이벤트를 잘 구분지어 발행 논리를 설계하고 구현해야한다. 외부 서비스에선 통합 이벤트에 집중할 뿐이다. 이 때, 해당 애그리것의 전역 식별자(Aggregate Root Identifier)를 통해 추가 정보는 조회하여 얻어 처리하는 방식을 택할 수 있다.

통합 이벤트 (Integration Event)

위 도메인 이벤트 설명에서 말했듯 통합 이벤트는 다른 서비스와 데이터를 공유할 때 사용된다.

주문이 완료되면 결제 요청이 이루어지며 결제가 완료 된 이후에 배송 요청이 되어야한다는 프로세스의 가정으로 이벤트를 설계하면 다음과 같이 도출될것이다.

주문 서비스

• OrderPlacedEvent (도메인 이벤트) 발생

• OrderCreatedIntegrationEvent (통합 이벤트) 발행 → Kafka → 결제 서비스 전달

결제 서비스

• OrderCreatedIntegrationEvent를 구독하여 결제 진행

• PaymentCompletedIntegrationEvent (통합 이벤트) 발행 → Kafka → 배송 서비스 전달

배송 서비스

• PaymentCompletedIntegrationEvent를 구독하여 배송 시작

근데 통합 이벤트는 왜 사용하는것일까?

도메인 이벤트를 소비하는 시점에 비지니스 요구사항에 맞춰 다른 서비스를 호출하면 될텐데 왜 통합 이벤트를 굳이 발행해서 처리하는것일까?

위에서 언급한 EDA가 각광받는 이유에 답이 있다. 메시징을 이용하지않으면 각 서비스들을 아무리 잘 분리시켜놔도 결합도를 느슨하게 만들기 힘들다. 즉, 서비스들을 마이크로하게 가져간 이득이 사라지는셈이다. 오히려 시스템 관리 복잡도와 코스트만 올라가고 MSA의 이점을 보기힘들어진다.

fun placeOrder() {
    // ... order domain logic

    // 주문 생성 후 결제 API 호출
    paymentService.processPayment(orderId, amount)

    // 결제 후 배송 API 호출
    shippingService.startShipping(orderId)
}

통합 이벤트를 메시징 하지않으면 위와 같이 동기이던 비동기 요청이던 각 서비스들이 서로간 강한 결합이 유지된다. 그런데 통합 이벤트를 이용하여 메시징 처리를 하면 서비스들은 브로커를 의존하게 되어 서비스들 간의 결합도를 낮출 수 있고, 브로커의 특성에 따라 다르긴하지만 대게 순차처리, 파티셔닝 등을 통해 동시 처리량도 높게 확보할 수 있어진다.

CQRS(Command Query Responsibility Segregation) Pattern은 명령(Command)과 조회(Query)를 분리하여 각각 독립적으로 최적화할 수 있는 강력한 아키텍처 패턴이다. 이를 통해 시스템의 확장성과 유지보수성을 높일 수 있다.

CQRS에서 명령을 처리하는 과정에서 Command Bus라는 개념이 등장하는데, 많은 자료에서 이를 비동기 방식으로 처리하는 예시를 주로 다루고 있다. 그러나 반드시 비동기 처리가 요구되는 것은 아니며, 오히려 동기 방식을 기본으로 시작하는 것이 더 적절할 수 있다.

이번 글에서는 Command Bus의 동기 및 비동기 방식에 대한 선택 기준을 알아보고, 어떤 경우에 비동기 방식을 도입하는 것이 적절한지에 대해 다뤄보려한다.

반드시 비동기를 지원해야하는가?

CQRS 패턴에서 Command Bus가 반드시 비동기로 동작해야 하는 것은 아니다.

실제로 많은 시스템에서 Command Bus는 기본적으로 동기적으로 동작하며, 필요에 따라 비동기 방식으로 전환하는 것이 더 바람직하다.

반 버논(Vaughn Vernon)의 Implementing Domain-Driven Design 책에서는 다음과 같이 언급된다.

"커맨드를 비동기식 메시지로 보내며, 이는 전용 스타일로 설계된 핸들러로 전달된다. 이는 각 커맨드 처리기 컴포넌트가 특정 타입의 메시지를 받도록 할 뿐만 아니라, 커맨드 프로세싱 부하를 처리할 수 있도록 주어진 타입의 처리기를 추가할 수 있다. 그러나 이 접근법에는 좀 더 복잡한 설계가 필요하기 때문에 이를 기본으로 사용하면 안 된다. 일단은 동기식 커맨드 처리기로 선택해 시작하자. 확장성(Scalability)의 요구가 있을 때에만 비동기식으로 변경하자."

즉, 비동기 처리는 기본값이 아니라 필요할 때 적용하는 것이 적절하다.

그렇다면 기본적으로 동기 방식이 적절한 이유는 무엇일까?

일관성 유지가 용이하다

• 동기적으로 커맨드를 처리하면, 명령 실행 후 즉시 조회 모델이 최신 상태로 유지될 가능성이 높아진다.

• 이는 사용자가 커맨드 실행 후 변경 사항을 즉시 확인할 수 있음을 의미한다.

  • 예를들어, 고객이 쇼핑몰에서 주문하면 주문 정보가 즉시 반영되어 보여주기를 기대한다. 만약 비동기 방식이라면, 메세지 큐에 의해 주문이 나중에 처리될 수 있으므로 즉시 조회했을 때 아직 데이터가 반영되지 않았을 가능성이 존재한다.

트랜잭션 관리가 단순하다

• 동기 방식에서는 하나의 트랜잭션 내에서 명령을 실행하고 필요 시 쉽게 롤백할 수 있다.

  • 예를들어, 은행 계좌 이체를 수행할 때 하나의 트랜잭션으로 송금과 입금을 처리하면, 실패 시 쉽게 복구할 수 있다.

• 반면 비동기 시스템에서는 비동기 방식에서는 분산 트랜잭션(Distributed Transaction) 처리가 필요해지는 복잡성이 초래된다.

디버깅이 용이하다

• 동기 방식에서는 문제가 발생한 시점과 원인을 즉시 파악할 수 있다. 요청을 보낸 후 응답이 즉시 오기 때문에, 에러 발생 시 트레이스를 쉽게 따라갈 수 있다.

• 반면 비동기 시스템에서는 메시지 지연이나 실패 시 추적이 어려울 수 있다.

그럼 언제 비동기 방식을 고려해야할까?

확장성이 요구될 때

• 사용자가 많아지면 동기 방식의 커맨드 처리는 서버 부하를 증가시키고, 응답 속도가 느려질 수 있다.

• 커맨드 처리를 메세징 서비스(e.g. Kafka)를 통해 비동기로 분산하면 수평 확장이 쉬워지고, 부하를 분산할 수 있다.

고성능이 요구되는 시스템일 때

• 대량의 트래픽을 처리하는 시스템에서는 동기 방식으로 인해 성능 병목(Bottleneck)이 발생할 수 있다.

  • 예를들어, 실시간 데이터 스트리밍이 필요한 시스템에서는 빠른 응답을 위해 비동기 방식이 적절할 수 있다. 대규모 로그 처리 시스테에서 Kafka와 같은 서비스를 이용하여 이벤트를 비동기로 수집하는 사례까 대표적이다.

즉각적인 응답이 필요하지 않은 경우

• 일부 도메인에서는 명령 실행 후 즉시 결과를 제공할 필요없는 경우가 있다.

위 케이스 외에도 더 다양한 트레이드 오프가 존재할것이라 생각한다. 만약 비동기로 명령을 처리하고 프론트쪽에서는 폴링 기법을 활용하여 처리가 완료될 때 까지 조회를 진행하는 방식을 채택할 수도 있다.

CQRS Pattern는 다양한 비지니스 요구사항을 만족할 수 있는 좋은 기법이라 생각하지만, 이번글에서 다룬 명령 처리 부분 외에도 읽기 모델(Read Model)을 가공하는 부분에서 대게 결과적 일관성 방식으로 구현되어 지연(Lag)과 실패에 대한 핸들링이 필요해진다.

이번 글에서는 필자가 기여하고있는 B2B SaaS 제품(이하 KOS)에서 단일 장애지점을 파악해보려한다. 이슈 지점에 대해 낙관적으로 바라보고 솔루션을 강구하지않으면 정말 ‘문제’가 되기때문에 솔직 담백하게 문제라고 생각되는 부분들을 정리해보고 항목 별로 액션 아이템을 도출해보려한다.

근데, 단일 장애 지점이 뭔가요?

단일 장애 지점(Single Point Of Failure, 이하 SPOF)은 시스템에서 하나의 구성 요소가 실패하면 전체 시스템이 중단되는 취약점을 의미한다. 마치 의존도가 높은 다리의 한 기둥이 무너질 경우, 다리가 전체적으로 무너질 위험이 있는것과 같다. 특정 구성 요소가 실패했을 때 대체하거나 복구할 수 없는 구조를 가진 경우 해당 요소가 단일 장애 지점으로 간주된다.

단일 장애 지점 식별하기

KOS 서비스는 Kubernetes 환경에서 서비스들이 오케스트레이션되는 구조이다. 즉, 스케일링과 회복성이 뛰어나다. 어플리케이션이 모종의 이유로 다운되더라도, ReplicaSet 설정에 따라 새로운 파드(pod)가 자동으로 생성된다.

그럼 현재 어플리케이션의 최대 처리량 및 가용 허용치는 어느정도인가?

현재 운영되고있는 서비스들의 정량적 가용 지표를 파악하고 있지않았다. 특정 중요 서비스들은 성능 테스트 도구가 아닌 매뉴얼로 스크립트를 만들어 레이턴시 측정은 진행된적이 있으나 서비스별로 부하 테스트를 통해 최대 처리량에 대한 지표측정이 필요하다.

왜 그동안 지표 측정을 안했나?

대규모 트래픽에 예민한 시스템이였다면 필수적으로 진행했겠으나, B2B 제품 특성상 스파크성 트래픽이 발생하지않아 데일리로 모니터링 도구를 통해 어플리케이션 CPU, Memory 지표등을 파악하여 스케일링을 하고있었다. 그러나 곧 정말 큰 규모의 고객이 두달내 입점할 예정이기에 이젠 코어 서비스들의 최대 처리량 파악을 통해 가시성을 올리는 액션 아이템이 필요할것같다.

[] 코어 서비스를 우선으로 스트레스 테스트 진행하기

[] 테스트를 통해 처리량 지표 파악하기

데이터베이스는 괜찮나?

현재 KOS는 MongoDB를 메인 데이터베이스로 사용하고있다.

MongoDB는 고가용성과 데이터 무결성을 보장하기위해 최소 3개의 노드(Primary-Secondary)를 구성해야한다. 따라서, Primary 노드가 죽더라도 Secondary 노드가 Primary로 승격되면서 페일오버가 진행한다.

그럼 데이터베이스는 SPOF가 아닌건가?

데이터베이스(Shared Database)는 단일 장애지점이 아닐 수 없다. (Shread Database 환경이라면 더더욱) 페일오버를 통해 회복탄력성이 빠르게 보장이 되는것뿐이지 승격되는 과정에서 데이터 유실이 발생할 수 있고, 특정 타이밍에 따라 복구가 불가능한 상황이 발생할수도 있다. 따라서 잠재적인 단일 장애 지점으로 볼 수 있다.

그러나 현재 초기단계의 제품 사이즈에서는 데이터베이스의 물리적 확장 방식인 샤딩이나 노드 수를 확장하는 전략을 취하기보다는 데이터 접근에 대한 쿼리에 대한 Observability에 더 집중하는게 맞다고 생각된다.

정상적인 인덱싱 작업이 되어있지않은 무거운 쿼리가 발생한다던가, 불필요한 쿼리(e.g. n+1)가 발생하고있다던가 등의 Query Observability를 확보하여 이를 어플리케이션에서 개선시키는 과정이 더 중요할것같다.

또한, 현재 Write, Query가 모두 Primary에서 이루어지고있는데, 강한 일관성이 필요하지않는 부분에 대해서 Query는 Secondary를 바라보도록 하는 Read Concern 설정을 통해 Query I/O를 분산하는 작업도 필요한 상황이다.

[] Read Concern을 통해 DB I/O 분산시키기

[] Database Observability 확보

API Gateway는 괜찮나?

KOS의 Gateway는 Spring Webflux로 이루어져있다. API Gateway Pattern을 기반으로 모든 도메인 서비스들의 프록시 역할과 인가 역할도 진행하며 BFF에 대한 책임도 갖고있다.

Gateway는 번역 그대로 ‘통로, 연결지점’의 역할을 지니고있기에 이 서비스가 다운되면 전면 장애는 피할 수 없는 사실이다.

그럼 어떻게 SPOF를 방지할 수 있을까?

Observability 도구를 통해 주기적인 점검과 지표에 맞는 스케일링을 통해 사전 예방을 하고있다. 또한 Kubernetes의 Liveness/ Readness Probe 설정을 통해 장애 감지 및 자동 복구가 진행된다.

그러나 다운스트림 서비스들로 라우팅할 때 특정 서비스가 정상적인 응답을 주지못하고 지연이 걸리거나 타임아웃등이 발생하면 Gateway Service에 또한 작업 스레드가 밀려 장애가 전파될 수 있다.

위 상황을 방지하기위해 Rate Limitting과 Circuit Breaker에 대한 Handling이 필요한 상황이라 생각한다. Circuit Breaker를 통해 다운 스트림 장애 시 원격 서비스 대상의 회복 시간을 제공하고, 요청을 차단하여 폴백을 통해 빠른 피드백을 전달하여 스레드를 오래 잡지않도록 할 수 있다.

또한, 어뷰저가 악의성을 갖고 과도한 요청(e.g. DoS)을 통해 Gateway Service를 과부하 상태로 만들 수 있다. 이는 Rate Limitting을 통해 방지할 수 있어야하겠다.

[] Circuit Breaker 구성

[] Rate Limitting 구성

마치며

기여하고있는 시스템에서의 단일 장애 지점을 식별하는 작업은 매우 중요하다 생각한다.

이번 글에서 나온 액션 아이템들은 (처절한..) 우선순위에 따라 하나씩 해결나갈 예정이고, 그 과정에서 공유할만한 트러블 슈팅이 생긴다면 꼭 남겨보도록 하겠다.

소프트웨어 개발에서는 데이터 저장 방식이 시스템의 확장성과 유지보수성에 큰 영향을 미친다. 특히, 변화가 빈번하고 복잡한 비즈니스 요구사항이 있는 환경에서는 단순한 CRUD 기반의 상태 저장 방식으로는 한계에 봉착하곤한다.

필자가 현재 기여하고있는 신사업 B2B SaaS 제품(이하 KOS)도 마찬가지였다. 병원 내에서는 고객의 내원부터 귀가까지 다양한 이벤트가 발생하며, 이 과정에서 실시간으로 예약 변경, 시술 추가, 환불 처리 등 여러 상황이 동시다발적으로 이루어진다. 이러한 복잡한 프로세스를 모두 데이터로 기록하고, 추적 가능한 방식으로 관리하는 것은 병원 운영의 효율성을 높이고 직원들의 업무 평가에 활용할 수 있는 중요한 과제였다.

이벤트 소싱?

모든 상태 변화를 이벤트(Event)라는 형태로 기록하고, 이를 기반으로 시스템의 현재 상태를 재화(Rehydration)시키는 방식이다. 단순한 CRUD 방식의 상태(State) 저장 방식과 달리, 과거의 모든 이벤트를 영속적으로 유지하며 감사 로그(Audit Log)와 데이터 추적을 용이하게 만들어 준다.

현실 세계의 문제는 생각보다 더 복잡했다

미용의료 병원에서 고객의 내원 ~ 귀가 프로세스를 바라보면, 병원 내원 -> 데스크 접수 -> 시술 -> 귀가 정도로 보일 수 있겠지만, 이 과정을 좀 더 톺아보면 정말 많은 과정들이 숨어있다. 하나의 예시로는 시술을 받는 과정에서 업셀링을 통해 새로운 시술을 실시간으로 추가하여 받을 수 있고, 받고 나와서 서비스가 불만족스러워 환불 처리를 밟을 수도 있다. 또는 피부 케어 서비스가 들어가 추가 시술들이 언제든지 추가될 수 있다.

무엇보다 이 복잡한 모든 과정을 데이터로 영속하여 사실에 기반한 데이터로 통계를 내고, 해당 통계를 기반하여 병원의 서비스적인 품질과 다른 제품에선 제공할 수 없는 여러 인사이트를 혁신적으로 제공하는것이 우리 팀이 그린 KOS 제품의 최종적인 모습이였다.

도입하여 제품팀이 얻은 가치는?

신사업에서 많은 레퍼런스가 없는 이벤트 소싱을 도입하는것이 챌린징적인 요소이긴했지만, 도입 이후 결과적으론, 사실 기반의 정량적 데이터로 효과적인 결과를 거둘 수 있었다. (특히, Product Owner와 Product Designer가 제품의 새로운 문제 영역을 식별하고 정책을 마련하는데있어 가장 크게 도움이 되었던것같다)

도입하여 고객이 얻은 가치는?

병원의 담당 부서마다 얻은 가치가 다르긴하지만 가장 반응이 좋았던것은 병원 관리자가 누가, 왜, 언제, 어떤 작업을 수행한것인지 파악하는게 가장 큰 골칫덩어리였는데 하나의 Stream에서 발생한 모든 사건(Event)를 기록하고있기때문에 이는 자연스럽게 해결할 수 있었다. 예를들어 다음과 같이 말이다.

e.g. 어딧로그

병원 CS 담당자: 1.6일 내원한 안정균 고객님의 예약 정보를 누가 변경한것인지 알 수 있을까요? 가능하면, 변경한 시각도 알고싶어요 !

KOS 제품의 예약 현황 View

KOS: 예약 현황 or 예약 상세에서 어딧 로그 기능을 제공하고있습니다. (위 사진 참고)

병원 담당자: 혹시 그렇다면 예약별로 ‘어느’ 시술을 받는데 ‘얼마나’ 시간이 소요되었고, ‘언제’ 귀가했는지를 알 수있을까요?

KOS: 네, 예약 통계에서 요청 주신 데이터 모두 확인가능합니다.

병원 담당자: 와우!

위 과정이 가능하게된것은 병원에서 수행된 모든 이벤트가 기록되어있음으로, 어떤 상품으로 시술을 받았고, 언제부터 시술을 받았고, 종료되었는지, 또한 귀가는 언제했는지 등 모든것을 제공할 수 있었다.

그럼 Event Sourcing를 사용안했다면 해결못하는 문제였나?

(당연히) 아니다. 문제를 식별하고 이를 해결하는 과정에는 팀의 환경, 구성원들의 역량, 제품 특성 등 모든것을 고려하여 다양한 솔루션을 내세울 수 있다. 이 과정에서 KOS 제품이 Event Sourcing을 진행하기에 적합한 환경이였을뿐이다.

적합했던 이유라하면, KOS 제품은 도메인 주도 설계(Domain-Driven Design) 방법론에서 여러 전략, 개념들을 이용하여 제품 설계를 초기부터 진행했었기에, 명확한 명령(Commands), 사건(Events), 집합(Aggregates)가 정의를 해놓은 상태였고 필요 시 이벤트 스토밍도 진행하여 필요한 재료들은 세팅이 되어있었기 때문인것같다.

적용하면서 발생한 문제는?

이벤트 재화(Rehydration)에 따른 성능 비용

이벤트 소싱은 모든 상태(State)를 이벤트의 흐름(Event Stream)으로부터 재구성해야 한다. 그러나 다수의 이벤트가 포함된 스트림을 조회할 때, 각 이벤트를 순차적으로 재생하는 작업이 성능 병목을 초래했다. 특히 예약 현황을 조회하거나 변경 이력을 확인하는 기능에서 조회 시간이 급격히 늘어나는 문제가 발생했다.

e.g. 예약현황 뷰

위와 같이 예약현황이 있고, 만약 각 내원객의 예약마다 100개의 이벤트가 존재한다면, 예약 수 x 이벤트의 재화 연산을 거쳐야한다. 단순하게 예약이 100개 있고, 각 예약마다 100번의 이벤트가 발생했었다면 최소한 예약 현황을 제공하기위해 10,000번의 연산이 애플리케이션에서 이루어져야한다는 말이다. (또한 Stream마다 Query I/O 비용도 추가로 발생한다)

이러한 문제를 CQRS 패턴을 도입하여, 재화 연산 비용에 대한 문제를 해결했다.

명령과 조회를 분리하여 이벤트 소스 데이터는 Write Model로 유지하고, 조회는 별도의 Read Model을 통해 처리하는 방식으로 개선하였다. 이때 Read Model은 필요한 데이터를 이벤트로부터 미리 연산하여 물리적 테이블로 저장해 두는 방식으로 성능 최적화를 진행했다.

CQRS 패턴 도입 외 또 다른 솔루션으론 특정 시점의 상태를 스냅샷으로 저장하고, 이후 이벤트만 재생시켜 최종 상태를 재구성하는 전략도 있었으나, 실시간으로 여러 Read Model을 구성해야하는 요구사항이 있어 CQRS 패턴을 택하게되었다.

이벤트 순서 보장

이벤트 기반 아키텍쳐(Event-Driven Architecture)에서도 중요하게 다뤄지는 이벤트의 순서 보장에 대한 내용이다.

이벤트가 시스템에 저장되거나 소비될 때 순서가 보장되지 않으면, 잘못된 상태가 만들어질 수 있다. 예를 들어, “예약 변경됨”이라는 이벤트가 “예약 생성됨“ 이벤트보다 먼저 처리되는 경우 비지니스 로직이 올바르게 동작하지 않을것이다.

해결안

이러한 문제를 방지하기위해 Message Broker의 파티션 키를 이용하여 순차처리하도록 진행하였다.

Message Broker로는 AWS Kinesis Data Stream을 사용하였고, 순서 보장과 더불어 온디멘드 샤딩을 지원하여 Stream 처리량이 매우 뛰어난 서비스이기에 채택하게 되었다.

중복 메세지 처리

메세징 시스템을 구성에 있어 메세지 전달 전략들이 여러가지가 있는데, 가장 쉽게 구성할 수 있는것이 At Least Once 방식이다. 말그대로 최소한 한번 이벤트가 발생할 수 있다는 말이다. 그냥 한번만 생산(Produce)하면 되는것아닌가? 싶을 수 있는데, 이것은 이번 주제와 무관하다 생각하여 자세한 이야기는 생략한다. (이벤트 전달 전략은 조만간 작성해 볼 예정)

해결안

중복 메세지가 소비될 수 있는 부분에 대해선 소비자 워커(Consumer Worker)에서 멱등성 논리를 구성하였다. 모든 소비자에 멱등성 논리가 들어간것은 아니고, 요구사항에 따라 소비자 모델의 고유 ID를 통해 이미 처리된 이벤트는 무시되도록 설계한 방식도 존재한다.

최종적 일관성으로 인한 동기화

이벤트를 생산(Produce)하고 Write Model은 수행을 끝낸다. Read Model의 워커에서 비동기로 이벤트를 소비하여 데이터를 처리한다. 즉, 강한 일관성(strong consistency)을 보장하지못하며, 비동기로 인해 최종적으로 데이터 일관성을 보장한다.

이러한 최종적 일관성에 대해 사용자는 다음과 같은 불편감이 생길 수 있다.

병원 담당자: 예약 생성 버튼 클릭 → 성공 ! → 응? 성공인데 왜 화면에 생성이 안되는거지? (버그인가?)

시스템적으로 보았을 땐, 당연한 이야기처럼 보이지만 사용자 입장에선 황당한 일이고 버그로 인지하기 딱 좋은 케이스이다.

해결안

위와 같은 이슈를 해결하기 위해 WebSocket을 지원하는 이벤트 워커를 구현하여, 생산된 이벤트를 워커에서 소비하면 WebSocket에 연결되어있는 모든 웹 브라우저에게 변경된 사항을 실시간으로 전달하도록했다.

동시성 문제

여러 사용자가 동시에 하나의 스트림(e.g. 예약 데이터)에 수정을 가하면 갱신 손실 문제가 발생할 수 있다. 제품 특성 상 병원 데스크에서 동일한 예약 정보에 동시에 변경을 가하는일이 간혹 일어난다. 이런 상황에서 동시성 문제가 제대로 관리되지않으면 고객은 예상치 못한 혼란스러움을 겪을 수 있다.

e.g. 동시성 상황

[동시 요청]
(데스크 직원 A) a, b, c 시술 테스크 저장

(데스크 직원 B) c, d, e 시술 테스크 저장

시술 테스크의 Sequence Key는 애플리케이션에서 1씩 증가하는 논리를 갖고 있다. 하지만 동시 요청이 발생하면, 동일한 Sequence Key를 가진 테스크가 저장될 가능성이 있다. 이는 데이터 충돌을 초래하며, 결과적으로 잘못된 시술 테스크 정보가 저장될 위험이 있다.

해결안

동시성 문제를 제어하는 방법은 요구사항마다 다르긴하지만, KOS에서 이벤트 소싱을 다루고있는 영역안에선 Event Schema에 이벤트가 쌓일 때마다 1씩 증가하는 version이라는 속성을 유니크 색인으로 정의하여 낙관적 잠금(Optimistic Lokcing)을 통해 제어하고있다. 이벤트 소싱에선 이벤트가 쌓인 순서가 매우 중요한 요소이기때문에 version이 꼭 필요하다. 그런데 만약 제품 특성 상 동시성 문제가 빈번하게 일어나며 이로인해 고객의 서비스 품질이 저하된다 생각하면 다른 잠금 전략들을 고려하였을것이다.

마치며

이벤트 소싱을 신사업 B2B SaaS 제품에 적용하면서 얻은 가치와 직면했던 문제들을 정리해보았다. 이벤트 소싱은 복잡한 도메인 문제를 해결하고, 과거 데이터를 기반으로 명확한 인사이트를 제공하는 데 강력한 도구가 될 수 있었다.

그러나 이벤트 소싱은 제시한 모든 문제를 해결하는 은탄환이 절대 아니다.

결국, 기술의 선택은 팀 또는 개인의 환경과 목표에 따라 달라진다 생각한다. 이벤트 소싱이 적합한 상황에서는 강력한 도구가 될 수 있지만, 단순한 상태 저장이나 CRUD 중심의 애플리케이션에서는 오히려 과도한 설계 복잡성을 초래할 수 있다.

최근 회사 동료분과 Database Sharding 관련해서 실시간 이벤트 동기화 방식에 대해 이야기를 나누다가 Thin, Fat Payload 방식에 대해 의견을 나누는 시간이 있었는데, 이 과정에서 두 전략 모두 명확한 트레이드 오프를 갖고있다는 것을 다시 한번 느꼈고, 휘발되기전에 내용들을 정리해보려한다.

Thin Payload (aka. Event Notification, Zero Payload)

위 예시로 그려본 도식처럼 Thin Payload는 이벤트가 발생했다는 사실만을 알리는 방식으로 최소한의 정보만을 포함한다. 주로 이벤트 타입과 관련된 식별자만을 포함하며, 구체적인 데이터(속성)는 포함하지않는다.

따라서, Thin Payload는 소비자가 필요한 데이터를 이벤트 원천 소스로부터 조회를 통해 필요한 값들을 획득하는 특징이 있다.

장점

• 상태의 식별값 외 속성값을 포함하고있지않아 메세지 사이즈가 작다.

  • 따라서, Network 대역폭과 Storage 사용량이 적다.

• 상태 모델이 확장 되더라도 소비자의 이벤트 워커에 부작용(Side Effect)이 발생하지않는다.

단점

• 이벤트 워커에서 수신할 때마다, 수신자가 생산자 API를 조회하는 Network I/O가 발생한다.

  • 따라서, 이벤트 원천 서비스의 가용성과 성능에 강한 의존성이 생긴다. (생산자 API 장애 발생 시 수신자 이벤트 워커에도 장애가 전파된다)

Fat Payload (aka. Event Carried State Transfer)

위 예시로 그려본 도식처럼 Fat Payload는 이벤트와 관련된 상태 정보를 포함한 방식이다. 소비자가 이벤트와 관련된 모든 필요한 데이터를 페이로드에 넣어 별도로 생산자 API를 조회하지않고도 처리할 수 있도록 설계하는것이 특징이다.

장점

• 페이로드에 상태의 속성 값들이 모두 들어있어, 수신자가 생산자 API 조회 비용없이 이벤트 워커의 작업을 수행할 수 있다.

  • 따라서, 소비자가 생산자에 대한 물리적 의존성을 느슨하게 만들 수 있다.

단점

• 상태의 속성 값들이 모두 들어있어, 메세지 사이즈가 크다.

  • 따라서, Network 대역폭과 Storage 사용량이 크다.

• 모델의 확장 또는 변경에 따라 생산자와 소비자 모두 부작용(Side-Effect)이 발생한다.

  • 이벤트 생산 시 상태의 확장된 부분을 이벤트 페이로드에 반영해야한다.

  • 만약 모든 속성이 표기 되어있지 않은 Fat이라면, 소비자가 생산자에게 이벤트 확장을 요구하는 논의가 필요해진다.

• 이벤트 생산 시점의 데이터를 신뢰하고 사용하기때문에, 소비자 워커 작업 시 최신 상태의 데이터가 아닐 수 있다. (일관성 이슈)

선택 기준이 항상 명확할 수 있는건가?

아니다. 뻔한 얘기일 수 있지만, 당연하게 시스템 요구사항에 따라 다르다.

하지만.. 필자는 대게 일반적인 상황이라면 Fat Payload 방식을 우선 고민하는편인것같다.

이유는 필자에겐 꽤나 결정적이라고 생각하는데, Thin Payload 방식은 Fat Payload 방식을 제공할 수 없지만, Fat Payload는 Thin Payload 방식을 제공할 수 있다. 이를 공식적인 포함 관계로 표현하기는 조금 위험해보이지만, Fat에도 식별값이 들어있기때문에 기능을 지원하는 영역에선 포함관계라고 생각된다.

그리고 무엇보다, Thin Payload 방식은 수신 시 생산자 API를 콜백하는 방식으로 강하게 의존하는 형태이기때문에 API 지연이 걸릴 수 있는 시간적 결함문제가 존재한다. (Fat Payload도 필요하다면 생산자에게 API를 콜백할 수 있다)

그럼 Fat Payload가 적합하지않은 상황은 어떤것들이 있을까?

가장 단순하게는 상태의 모든 속성들이 필요하지않은 경우이다.

제어가능한 서비스에서 소비자가 필요로하는 데이터가 모든 속성이 아니라면, 굳이 네트워크 대역폭을 오염시킬 필요가 없다. 앞에 “제어가능한”을 붙인 이유는 EDA 특성 상 생산자의 입장에서 소비자들의 컨텍스트는 알 필요가 없지만, 엔지니어가 이를 필요로 하는 소비자들에 대해 화이트 박스인 상황이고, 확장의 여지가 없거나 확장이 되더라도 제어가 가능하다면 DTO(Data Transfer Object) 패턴을 통해 프로젝션하여 필요한 데이터만 조회하는것이 더 나은 판단일 수 있다.

두번째로는 대역폭이 낮게 설정된 인프라를 사용하고있는 경우라면 Fat Payload이 제한될 수 있다. Fat 방식은 상태의 특징에 따라 이벤트 사이즈가 기하급수적으로 증가할 가능성이 있기때문에 정말 무거워질 수 있다. 예를들어, 필자가 만들고있는 시스템에는 TicketGroup 이라는 도메인 엔터티가 존재하는데, 내부에 Tickets 이라는 배열 속성이 있다. 이는 1:N 관계로 Ticket은 상황에 따라 100개가 넘어갈수도 있다. 만약 AWS SQS를 사용하고있다면, 현재 SQS의 Size Max가 262,144바이트(256KiB)이기때문에 발행에 실패할 수 있다.

세번째로는 이벤트 워커 작업 시 최신 데이터를 보장해야하는 경우라면 이벤트 원천 서비스와 직접 상호작용하는 방식인 Thin Payload를 선택하는것이 적합하다. 물론 위에서 언급했듯이 Fat Payload도 식별값을 들고있기때문에 최신 데이터를 조회할 수는 있지만, 발행 시점의 상태를 포함하여 이벤트 소비자 간 독립성을 높이는 Fat Payload의 장점이 희석될 수 있다.

일반적으로 소비자 입장에선 모든 데이터가 이벤트에 포함되면 처리하는데 용이하겠지만, 모든 객체 그래프를 포함시키는것은 느슨하게 결합된 Bounded Context에서 애그리거트 간 외부 엔터티를 얼마나 포함하는지 도메인 모델의 속성들을 이벤트에 모두 노출하는 것과 동일할 수 있기때문에 고민이 꼭 필요하다.

또한, Thin Payload의 가장 큰 장점중에 하나가 내부 도메인 모델링의 확장 또는 변경이 되더라도 소비자들은 식별값으로 조회하기때문에 확장에 대해 사이드 이펙트가 없다. 따라서, 이벤트 생산자를 담당하고있는 작업자와 다른 팀이여도 Fat Payload에 비해 커뮤니케이션이 적게들어가는 이점이 있다. (* 없는것은 아님!)

마치며

이번 포스팅에서는 Thin Payload와 Fat Payload의 개념과 각 트레이드 오프에 대해서 알아보았다. 결국 이 두가지 전략의 선택은 시스템 요구사항에 따라 달라질 수 밖에 없다. 이 두 전략을 공부하면서 느낀 한가지 분명한 점은 이벤트 설계는 단순한 데이터 전달을 넘어 시스템 아키텍쳐링의 설계 철학까지 고려해야한다는 점이였다.

필자가 기여하고있는 제품에선 많은 서비스에서 이벤트들을 소싱하고있는데, 초반엔 시스템 특성, 요구사항을 우선 고려하기보단 큰 고민 없이 이벤트를 설계하면서 여러번 넘어진 경험이 있어 소개해보고싶었으며, 무엇보다 가장 중요한것은 완벽한 설계가 아닌, 팀과 시스템에 가장 적합한 설계를 찾아가는 과정인것같다.

필자는 현재 B2B SaaS 제품(이하 KOS)을 만들고있다. 제품을 만들면서 테스트에선 분명 성공했지만 운영에서 장애를 발생시킨 경험을 하고 난 이후 테스트 대역을 어떻게 바라보고 사용하는지에 대해 소개해보려한다.

테스트 대역이 습관화 되는것이 해롭다는것은 많은 개발자들이 인지하고있는 사실이다. 그러나 안타깝게도 테스트를 작성하다보면 테스트 대역이 필요한 순간은 있기마련이다. 이에 대해 필자는 어떤 기준을 갖고 테스트 대역을 활용하고있는지에 대해 소개한다.

배경

KOS의 아키텍처는 Mircroservices 환경으로 이루어져있고, 여러 컴포넌트 간 동기 방식의 HTTP 통신 또는 메세지를 발행하여 Message Broker 등을 활용하는 여러 통신 방식이 존재한다. 그리고 메인 데이터베이스로는 MongoDB를 사용하고있다.

시스템에서 복잡한 비지니스 요구사항을 만족하기위해서 하나의 명령(Command)이 실행 됐을 때 여러 서비스 컴포넌트 간 데이터 일관성을 위해 다양한 방식의 통신이 발생하고 이를 제어하기 위해선 하나의 유즈케이스에 많은 의존성이 필요해질 때가 있다.

다음과 같이 복잡한 비즈니스 요구사항과 시스템 제약사항을 만족하기위해 다양한 의존 관계가 형성되었을 때, 어떻게 시스템을 설계하여 테스트 대역을 설정하는지에 대한 경험을 KOS 예약 시스템의 예제 코드 기반으로 공유하고자한다.

시스템 요구사항

• 동일한 내원객(Visitor)은 동 시간대 중복 예약을 할 수 없다.

• 예약 완료 시 해당 내원객에게 예약 확정 SMS 문자가 발송되어야한다.

• 예약 완료 시 내원객의 스케줄 내역의 읽기 모델이 만들어져야한다 (ref. CQRS)

  • 위 조건을 만족하기 위해, KOS에서는 여러 도메인 서비스 에서 변경이 발생한 사건들(Domain Events)을 발행하여 Downstream 서비스 에서 요구사항에 맞추어 처리하고있다.

예약 요구사항을 만족하기 위한 아키텍처 구성도

(위 이미지는 요구사항을 이해하기 위한 보충 설명일 뿐이니, 깊게 이해를 필요로하지않는다.)

스케줄 B.C 에서 예약 성공 후 발행되는 Reserved 도메인 이벤트를 Notification B.C 와 스케줄의 리드모델 이벤트 처리기 등에서 이벤트를 소비하여 요구사항을 만족하는 과정을 추상적으로 도식화해보면 위와 같다.

이제 위 요구사항을 만족하는 예제 코드를 구현해보면 아래와 같이 작성할 수 있다.

예약 유즈케이스 구현 (As-Is)

public class ReserveUseCase {
    private final ScheduleEventStore eventStore;
    private final VisitorClient visitorClient;
    private final ReservationOverlapValidator reservationOverlapValidator;

    public ReserveUseCase(
        ScheduleEventStore eventStore,
        VisitorClient visitorClient,
        ReservationOverlapValidator reservationOverlapValidator
    ) {
        this.eventStore = eventStore;
        this.visitorClient = visitorClient;
        this.reservationOverlapValidator = reservationOverlapValidator;
    }

    public void execute(Reserve command) {
        Visitor visitor = visitorClient.read(command.getVisitorId());

        if (
            !reservationOverlapValidator.validate(
                visitor.getId(),
            command.getStartDateTime(),
            command.getEndDateTime()
        )) {
            throw new RuntimeException("overlapped reservation");
        }

        eventStore.collectEvents(
              List.of(new Reserved(...))
        );
    }
}

public class ScheduleEventStore {
    private final IScheduleEventRepository mongoRepository;
    private final IMessageBus kinesisClient;

    public void collectEvents(String streamId, Iterable<Object> events) {
          mongoRepository.save(...)
          kinesisClient.send(...)
          // ...
    }

    public List<Object> queryEvents(String streamId) {
          return mongoRepository.findAll(...)
          // ...
    }
}

public class VisitorClient {
    private final WebClient webClient;

    Visitor read(String visitorId) {
        return webClient.get(...)
        // ...
    }
}

public class ReservationOverlapValidator {
    private final JedisPool redis;

    Boolean validate(
        String visitorId,
        OffsetDateTime requestedStartDateTime,
        OffsetDateTime requestedEndDateTime
    ) {
          redis.exists(key)
          // ...
    }
}

VisitorClient

내원객의 식별값(VisitorId)으로 내원객 정보를 읽어오는 Reader이다

⇒ Spring Webflux의 WebClient를 이용하여 Visitor Component를 호출한다

ReservationOverlapValidator

중복 예약 방지 요구사항을 만족하기 위해 필요한 내원객의 식별값(VisitorId)과 예약 시간을 파라미터로 받는 중복 예약 검증기이다

⇒ 예약 시 Redis에 캐싱하여 내원객 + 예약 시간 기반으로 중복 예약인지 검증한다

EventStore

KOS는 Event Sourcing을 사용하고있어 명령이 발생하면 관련된 도메인 이벤트들을 스토어에 적재하고있는데, EventStore는 도메인 이벤트들을 관리하는 스토어이다

⇒ MongoDB와 AWS Kinesis Data Stream을 이용하여 Message의 Store And Forward 역할을 한다

Test (As-Is)

@SpringBootTest
public class ReserveUseCaseTest() {

    @Autowired
    private final ScheduleEventStore eventStore;

    @Autowired
    private final VisitorClient visitorClient;

    @Autowired
    private final ReservationOverlapValidator reservationOverlapValidator;

      @Test
      void `Sut는 내원객은 동 시간대 중복 예약을 할 수 없다`() {
            //Arrange
            var sut = new ReserveUseCase(
                eventStore,
                visitorClient,
                reservationOverlapValidator
            );

            var command = new Reserve(...);

            //Act & Assert
            assertThrows(RuntimeException.class, () -> sut.execute(command));
      }

  //...
}

현재의 구조에서는 테스트를 실행하기 위해서 Redis, WebClient, AWS Kinesis Data Stream, Mongo 등 많은 의존성이 필요한 상황이다. 즉, 모든 인프라 계층의 자원들에게 강결합이 되어있는 지금은 Docker와 같은 컨테이너 서비스를 이용하여 Redis, MongoDB, LocalStack 등의 컨테이너를 띄워서 테스팅을 진행할 수 밖에없는 상황인것이다.

게다가 Docker를 사용하기 힘든 환경이라면, 개발자들은 로컬 장비에 MongoDB, Redis를 설치받아야하고 AWS와 같은 자원은 테스트를 위한 서비스 계정을 추가로 관리해야할 수 있다.

Q. 그렇다면 테스팅을 할 때 실제 인프라 자원들을 실행시키는것이 좋지않은것인가?

아니다. (강력) 몇가지 필요 조건에 부합하기만 한다면 실제 인프라 자원과 객체를 사용하는것이 우선되어야한다고 생각한다.

필자가 고려하는 테스트 대역을 사용해야하는 조건은 크게 아래와 같다.

• 실제 구성 요소 제어가 불가능한 의존성인가?

• 실제 구성 요소의 출력이 비일관적인가?

• 실제 구성 요소가 테스트 실행 시 속도가 느린가?

위 조건에 N개라도 부합한다면, 필자는 고민없이 필요 인프라 자원을 실행시키고, 실제 운영 객체(depended-on component, 이하 DOC)를 사용할 것이다. 그렇게 운영이 가능하면 당연하게도 실제 운영에서도 동일한 동작을 할것이기때문에 실패하는 거짓 음성(False-Nagative)의 상황을 제거할 수 있다.

테스트를 작성하는 이유에는 몇 가지 이유들이 있지만 필자는 안정감을 유지하기 위해 꼭 필요한 도구라고 생각한다. 만약 가짜 객체를 주입시키고, 가짜 인프라를 실행시키면 분명 자동화 테스트에서 다 성공해서 운영에 배포했는데, 시스템 장애를 맞이할 수 있는것이다.

(실제로 필자는 Redis TTL 제어가 필요한 유즈케이스 논리에서 대역을 사용했다가 운영에서 TTL에 음수가 들어갈 수 있는 상황이 발생해서 장애를 맞이한적이 존재한다 🫨 만약 실제 Redis 의존성을 주입해서 사용했다면, 테스트에서 잡혔을것이다.)

이제 위 대역 조건을 통해, 선정해보면 AWS Kinesis는 실행 속도가 느리고, 자원 세팅이 번거롭다. (협업자들의 자원 세팅의 비용도 중요하다 생각한다.) 그리고 Visitor API를 제어하는 WebClient는 제어가 불가능하다고 생각했다. Visitor API에 대한 논리를 요청자가 제어하는것은 불가능하다.

반면, Redis와 MongoDB는 실행 속도가 빠르고 입력에 따른 출력이 일관적이다. 제어도 주어진 인터페이스 내에선 가능하다고 생각했다. 이제 위의 결정대로 의존성을 주입할 수 있는 설계가 되도록 리팩터해보자.

예약 유즈케이스 구현 (To-Be)

public class ReserveUseCase {
    private final EventStore eventStore;
    private final VisitorReader visitorReader;
    private final ReservationOverlapValidator reservationOverlapValidator;

    public ReserveUseCase(
        EventStore eventStore,
        VisitorReader visitorReader,
        ReservationOverlapValidator reservationOverlapValidator
    ) {
        this.eventStore = eventStore;
        this.visitorReader = visitorReader;
        this.reservationOverlapValidator = reservationOverlapValidator;
    }

    public void execute(Reserve command) {
        Visitor visitor = visitorReader.read(command.getVisitorId());

        if (
            !reservationOverlapValidator.validate(
                  visitor.getId(),
              command.getStartDateTime(),
              command.getEndDateTime()
          )
        ) {
            throw new RuntimeException("overlapped reservation");
        }

        eventStore.collectEvents(
            List.of(new Reserved(...))
        );
    }

public interface EventStore {
    void store(String streamId, Iterable<Object> events);
    List<Object> queryEvents(String streamId);
}

public interface VisitorReader {
    Visitor read(String visitorId);
}

public interface ReservationOverlapValidator {
    Boolean validate(
        String visitorId,
        OffsetDateTime requestedStartDateTime,
        OffsetDateTime requestedEndDateTime
    );
}

예약 유즈케이스를 기존 인프라스트럭쳐 레벨의 의존성들을 의존하던것들을 제거하고 순수한 인터페이스만을 의존하고있는 구조로 변경하였다. 이제 리팩터링 한 내용을 기반으로 테스트를 작성해보면 다음과 같다. (도메인 모델 입장에서 순수한 인터페이스를 의존하고 다양한 의존성을 주입할 수 있는 환경을 만드는게 주 목적이다)

Test (To-Be)

@SpringBootTest
public class ReserveUseCaseTest() {  
    @Autowired
    private final JedisPool redis;

    @Autowired
    private final ScheduleMongoRepository mongoRepository;

  @Test
  void `Sut는 동일한 내원객은 동 시간대 중복 예약을 할 수 없다`() {
        //Arrange
        var sut = new ReserveUseCase(
            new ScheduleEventStore(
                mongoRepository,
                new MessageBusStub()
            ),
            VisitorReaderStub(),
            new ReservationOverlapValidator(redis)
        );

        var command = new Reserve(...)

        //Act & Assert
        assertThrows(RuntimeException.class, () -> sut.execute(command));
  }

  //...
}

public class VisitorReaderStub implements VisitorReader {
    @Override
    public Visitor read(...) { }
}

public class MessageBusStub implements IMessageBus {
    @Override
    public void send(...) { }
}

현재 테스트 대상(System Under Test, 이하 SUT)의 의존성을 조립하는 부분을 보면, 인터페이스를 구현한 테스트 대역들을 주입하고있는 것을 확인할 수 있다. 이 때, Redis와 Mongo와 관련된 의존성인 실제 운영 객체를 주입하고있는것도 볼 수 있다.

테스트 대역에는 Stub, Fake, Spy, Mock, Dummy 와 같은 많은 방법들이 있는데, 이번엔 예시 코드에서 사용한 개념들에 대해서만 예시 코드로 알아본다.

테스트 대역(Test Double)

테스트 환경에서 실제 객체를 대신하여 사용되는 객체들을 의미한다. 이는 테스트의 독립성을 유지하고, 외부 의존성에 대한 제어를 통해 다양한 시나리오를 검증하는데 유용하게 사용된다

Fake

SUT가 의존하는 실제 구성 요소(DOC)를 대체하여 동일한 기능을 간단하게 구현한 객체이다. 검증 목적으로 사용되지는 않으며, 제어점이나 관찰점으로 사용되지 않는다

e.g.

public class InMemoryEventStoreFake implements EventStore {
    private final Map<String, List<Object>> store;

    public InMemorySaasEventStore() {
        this.store = new HashMap<>();
    }

    @Overrride
    public void collectEvents(String streamId, Iterable<Object> events) {
        store.computeIfAbsent(
            streamId,
            x -> new ArrayList<>()
        )
        .addAll(events);
    }

    @Override
  public List<Object> queryEvents(String streamId) {
      return store.getOrDefault(streamId, Collections.emptyList());
  }
}

위 시나리오에서는 실제 구성 요소(DOC)를 사용하고있지만, 만약 메인으로 검증하고자 하는 DB가 아니라면, 위와 같이 구현하여 사용할 수 있다.

Stub

SUT가 의존하는 실제 구성 요소(DOC)를 대체하여, 미리 정의된 응답이나 동작을 제공하는 객체이다. SUT가 특정 조건이나 상황에서 어떻게 동작하는지를 테스트하기 위해 사용되며, 내부 동작이나 호출된 메서드를 기록하지는 않는다

e.g.

public class VisitorReaderStub implements VisitorReader {
        private Visitor visitor;

        public VisitorReaderStub(Visitor visitor) {
            this.visitor = visitor;
        }

    @Override
    public Visitor read(String visitorId) {
        return new Visitor(
            visitor.getId(),
            visitor.getName()
        ); 
    }
}

• 내부 간접 입력을 통해 미리 정해진 결과를 반환하는 VisitorReaderStub의 구현체이다.

• 만약 실제 구성 요소 객체(DOC)를 SUT에 주입했다면, WebClient를 이용하여 Visitor Component로 HTTP 요청을 보내야한다. 그러나 Stub 객체를 읽어 간접 출력한 값으로 테스트를 진행하도록 했다.

Spy

실제 구성 요소(DOC)를 대체하면서, 호출된 메서드나 전달된 인자를 기록하는 객체이다. SUT의 상호작용을 검증하는 데 사용되며, Stub처럼 미리 정의된 동작을 제공할 수도 있다.

public class EventStoreSpy implements EventStore {
    private final List<Object> eventLogs = new ArrayList<>();

    @Override
    public void collectEvents(Iterable<Object> events) {
        this.eventLogs.addAll(events);
    }

    public List<Object> getEvents() {
        return this.eventLogs;
    }
}

• 위와 같이 Spy는 실제 해당 메서드가 호출(출력)되었는지 관찰하고 싶을 때 사용한다.

• 만약 유즈케이스가 실행되었을 때, EventStore의 collectEvents가 호출되었는지, 그리고 예상한 형태의 이벤트가 수집되었는지 검증하고자 할 때 사용한다.

  • 대게 Spy는 명령이 몇 번 실행되었는지, 또는 메세지가 정상적으로 발행을 했는지 등을 검증할 때 사용한다.

Classists vs Mockists

테스트 주도 개발(Test-Driven Development, TDD)이 널리 확산되면서, 테스트 작성 방법에 대한 다양한 철학과 접근 방식이 등장했다. 이 중에서도 Classists와 Mockists는 테스트의 초점과 목적에 따라 나뉘는 두 가지 대표적인 테스트 철학이다.

두 학파 중 어떤 방식을 선택하느냐는 테스트하려는 시스템의 복잡성과 팀의 철학에 따라 달라질 수 있다고 생각하나.. 최근엔 전체적인 시장에서도 Classists쪽으로 많이 기운것같다. (기울게 된 이유도 명확하다 생각한다)

Classists

실제 객체를 사용하여 검증하고, 통합된 시스템의 동작을 확인하며 상태 검증(State Verification)에 중점을 둔다. 시스템이 의도한 대로 동작하는지를 검증하기 위해 실제 객체(DOC)를 사용하거나 ‘간혹 상황에 따라’ 이를 대체하는 테스트 대역을 활용한다.

Mockists

특정 메서드 호출이나 객체 간 상호작용을 검증한다. 행위 검증(Behaviour Verification)에 주로 중점을 두고, 객체 간의 상호작용이 올바르게 이루어졌는지 확인한다.

어떤 방식을 더 선호하나요?

필자는 Classists 방식을 선호한다.

Mockists의 접근 방식은 행위 검증을 통해 간단한 반환값을 특정하여 메서드 호출의 정확성을 확인할 수 있는 장점이 있지만, 상태 검증이 부족하여 거짓 음성(False Nagative)이 발생할 수 있기때문이다.

이로 인해, 테스트는 통과하나 실제 구성 요소(DOC) 동작은 실패하는 경험을 할 수 있다. 그래서 가능하다면 실제 객체를 사용하고있으며, 외부 시스템과 협력이 필요한 경우에는 테스트 대역(Test Double)을 사용하여 Classists 방식의 테스팅을 진행하고있다.

마치며

테스트를 작성하는 가장 큰 이유가 안정감이라고 생각한다.

그 안정감을 유지하기 위해선 거짓 음성, 거짓 양성을 최소화해야한다. 그러기위해서 우리는 테스트 대역을 지양해야하고, 실제 객체를 사용하는것이 좋다. 이번 글에선 대역에 대한 기준을 정하고, 코드를 재설계하여 필요한 의존성을 주입해서 사용하는 과정을 소개해보았다.

흔히 Microservices, Miniservices와 같이 분산 시스템 환경에서 컴포넌트 간 데이터를 전달하기 위해 Message를 생산하고 소비한다.

이번 포스팅에선 Message가 무엇인지, 그리고 Command, Query, Event의 각 개념과 차이점은 무엇인지에 대해서 작성해보려고한다.

Message의 본질

Message는 시스템 간 통신의 기본 단위로, 정보를 주고받는 매개체 역할을 한다. 그리고 데이터를 담은 컨테이너일 뿐만 아니라, 전송 의도와 의미를 전달한다.

이 때, 의도에 따라 Message는 아래와 같이 세가지 유형으로 분류 해볼 수 있다.

Message

ㄴ Command

ㄴ Event

ㄴ Query

명령(Command)

명시적으로 특정 동작을 수행하라는 요청을 뜻한다.

시스템에선 상태의 변경을 발생시키는 요청이라고 할 수 있다. 예를들어, 결제를 요청(ProcessPaymentCommand)하거나 예약을 하는것(ReserveCommand)처럼 일반적으로 상태를 변경하기 위한 요청이라고 볼 수 있다.

주요 특징으로는 요청자가 수신자(Consumer)를 의존한다. 예약을 요청한다는것은, 요청자가 수신자를 알고 Message를 요청한다는것과 같다.

사건(Event)

이미 발생한 사실을 뜻한다.

시스템에선 과거의 상태 변경을 전달하고, 수신자가 이를 기반으로 적절히 반응(Reaction)할 수 있다. 예를 들어, 결제 완료됨(PaymentCompleted)예약됨(Reserved)처럼 과거에 발생한 사실의 정보가 담긴 값이다.

주요 특징으로는 수신자가 특정되지않고, 발행자(Producer)는 수신자(Consumer)의 존재 여부에 의존하지않는다.

조회(Query)

데이터를 요청하거나 조회하기 위한 요청을 뜻한다.

시스템에선 상태에 변경을 가하지않고, 단순히 정보를 반환하는데 초점이 맞춰져있다. 예를들어, 결제 내역 조회(PaymentsQuery)를 하거나 예약 내역 조회(ReservationsQuery)처럼 시스템 상태를 유지하면서 필요한 정보를 얻는데 사용된다.

예시로 알아보면

대게 커머스 주문 시스템에선 사용자가 상품을 주문하면, 다양한 서비스들이 협력하여 주문 생성, 결제 처리, 재고 차감 등을 수행하는 구조를 갖게된다. 이 과정에서 Message를 어떻게 구분 하는지에 대해 알아보면 다음과 같다.

(물론 시스템 설계자에 따라 의존 방향, 이벤트 설계는 다를 수 있다.)

1. 주문 생성 명령 (Command)

클라이언트가 Order Service로 주문 생성 명령(CreateOrderCommand)을 전달한다. 이 때, 내부 논리를 통해 Order Entity가 생성될 것이다.

이 때, Order Serivce로 요청자가 수신자를 알고 요청하는(의존하는) 형태가 되는것을 알 수 있다.

2. 주문 생성됨 사건 (Event)

주문 생성이 완료되면 Order Service에서는 주문 생성됨(OrderCreated)의 실제 발생한 사건에 대해 발행한다.

이 때, 일반적으로 해당 주문이 완료되면 결제가 진행되어야하고 상품 인벤토리의 개수가 차감되어야한다. 그리고 사용자에게 주문이 완료되었다는 알림을 보내야한다.

각 Payment Service, Inventory Service, Notification Service는 해당 이벤트를 구독하고 있는 상태라면, 사건이 발생한것을 반응하여 Payment Service에서는 결제 프로세스를 진행하고 Inventory Service에서는 해당 상품의 재고 차감을 진행할 것이다. 그리고 Notification Service는 주문 완료되었다는 고객의 번호 또는 이메일로 완료 내용을 알릴 것이다.

이 때, Order Service는 주문 생성을 완료하고 해당 사건에 대해 발행만 했을 뿐, 구독자와 이벤트를 소비한 주체가 누군지 모른다. 즉, Event의 의존방향은 Command와 달리 발행자는 수신자를 모르는 형태가 된다.

3. 주문 조회 (Query)

주문이 완료된 내역을 조회(OrderQuery)한다.

상태의 부작용을 갖고있지않기에 특별한 복잡성 없이 주문의 식별값을 통해 구체적인 상태의 정보를 취득할 수 있다.

마치며

Messaging Services에서 Message는 Command, Query, Event를 포괄한 넓은 개념이라는것을 알아보았다. 대게 이를 명확하게 구분지어 표현할 때가 얻는 이점이 더 많을 때가 있기때문에 각 개념들을 정확히 이해하고 사용하는것이 중요하다고 생각한다.

필자는 현재 B2B SaaS 신사업팀에서 백엔드 엔지니어로 일 하고있다.

메인 데이터베이스로 MongoDB를 사용하고있는데, 그 이유와 사용 방법에 대해 소개해보려한다. (실제로 질문도 많이 받았었다)

왜 MongoDB를 메인 데이터베이스로 채택했나요?

MongoDB는 세부적인 보안 설정을 컬렉션 별로 지원하기때문이다.

왜 세부적인 보안 설정이 필요하고, 이를 어떻게 활용한 계획인지 설명하기 위해선 우선 Multi-Tenancy에 대해 간략히 설명이 필요할것같다.

Multi-Tenancy가 뭔가요?

Multi-Tenancy는 단일 인스턴스에서 여러 테넌트(고객 또는 조직)를 독립적으로 지원하는 아키텍처이다.

위 이미지처럼 Multi-Tenancy는 소프트웨어 개발과 유지보수 비용을 공유하기 때문에 경제적이다. 따라서, 공급자는 업데이트를 한 번만 하면 다중 테넌트에게 업데이트 된 서비스를 제공할 수 있다.

(Single-Tenant라면, 공급자는 여러 소프트웨어의 인스턴스에 모두 업데이트가 필요하다.)

그런데 각 테넌트마다 독립적인 Database Server를 사용하면, 고객사가 10000개라면, 10000개의 DB Server를 관리해야하는 비용이 발생한다. 그래서 서비스 목적성에 맞추어 Multi-Tenancy Model을 채택하여 설계한다.

내가 속한 팀의 Multi-Tenancy 구조는 3번이다. 하나의 인스턴스에서 논리적으로 테넌트를 분리하고 Database Server는 한대만 기동하고있다.

물론, 엔터프라이즈 고객의 요구에 따라 Database Server와 어플리케이션 인스턴스를 독립적으로 분리할 수 있는 인프라 세팅도 준비되어있다.

어떻게 Tenant 별로 데이터를 관리하고있나요?

위에서 말했듯이, 어플리케이션에서 논리적으로 테넌트들을 분리하고있다. 논리적으로 분리된 테넌트는 각 독립된 MongoDB Collection에 저장이된다.

이를 코드로 나타내면 아래와 같다.

class ReservationRepositoryImpl(
    database: MongodbConfiguration,
) : ReservationRepository {
    private val entityType: Class<ReservationDataModel> = ReservationDataModel::class.java
    private val collection: MongoTemplate = MongoTemplate(database.mongoDatabaseFactory)

    fun create(tenantId: String, entity: ReservationDataModel) {
        val collectionName = "reservations_$tenantId"
        collection.insert(entity, collectionName)
    }

    fun findById(tenantId: String, reservationId: String): ReservationDataModel? {
        val collectionName = "reservations_$tenantId"
        return collection.findById(reservationId, entityType, collectionName)
    }
}

최초 고객이 로그인할 때, 테넌트를 설정할 수 있고 접속하면 URL에서 tenantId를 관리하고있고, 도메인 서비스에게 보내는 요청의 Request Param에 tenantId가 모두 포함되어있는 형태이다.

따라서, Domain Service들의 API Endpoint에는 .../tenants/{tenant}/...가 붙어있다. 이러한 요청을 통해 구분된 TenantId는 MongoDB의 CollectionName에 Suffix에 붙여 사용한다.

e.g. collection name

• reservations_{tenantId}

• products_{tenantId}

따라서 각 테넌트별로 독립적인 컬렉션을 갖고있는 형태가된다. 독립적이기때문에 얻을 수 있는 이점은 컬렉션 별 보안 설정을 할 수 있다. 물론, 특정 테넌트에 잘못된 데이터가 Hard Updating 되었을 때 다른 테넌트들은 장애 전파가 안되기도하지만 이는 매우 특별한 케이스이긴하다.

그래서 중요한 보안은 어떻게 설정을 하고있나요?

MongoDB는 컬렉션 수준 보안 설정 기능을 제공한다.

역할 기반 액세스 제어 (RBAC) 기능

• 역할 기반 액세스 제어를 통해 DB의 특정 컬렉션에 대한 권한을 세밀하게 부여할 수 있다.

  • 관리자는 사용자 정의 역할(User Defined Role)을 생성하여 각 테넌트의 컬렉션에 대한 읽기, 쓰기, 업데이트 등의 권한을 개별적으로 설정할 수 있다.

  • 권한의 수준 범위는 아래와 같다.

    • 데이터 베이스 수준

      • 특정 테넌트 전용의 DB에만 접근 권한만 부여할 수 있다 (하나의 테넌트가 N개의 DB에 접근할 수도 있다)

    • 컬렉션 수준

      • 테넌트의 컬렉션만 접근 가능하도록 제한이 가능하다

    • 필드 수준

      • 특정 필드에도 read, write의 제한이 가능하다

사용자 정의 역할(User Defined Role)

• MongoDB 관리자(제품팀)는 특정 컬렉션이나 DB에 대해 사용자 정의 역할을 생성할 수 있다.

• 각 역할 별 read, write, update와 같은 세부 권한을 커스텀 할 수 있고, 특정 테넌트의 컬렉션에만 적용되도록 제한할 수도 있다.

  • e.g.

    • reservation_{tenantA}에서 병원 IT 관리자1 에게 해당 컬렉션의 read 권한을 줄 수 있다.

    • 제품팀 개발자들의 책임에 따라 관리자가 책임별로 세부 권한을 나누어 관리할 수 있다.

      • SaaS 제품 특성 상 병원의 데이터를 제품 개발자라고 모두 볼 수 있는것은 법적으로 안된다.

위의 MongoDB RBAC 특성을 통해, 잘못된 쿼리나 운영 실수로 인해 다른 테넌트에 데이터가 노출되거나, 수정되는것을 방지할 수 있게되어 데이터 격리 수준을 한층 강화할 수 있다.

db.createRole({
  role: "tenant_admin_reader",
  privileges: [
    {
      resource: { db: "myDatabase", collection: "reservations_tenantA" },
      actions: ["find"]
    }
  ],
  roles: []
});

// 2. 사용자에게 역할 할당
db.createUser({
  user: "tenantAUser",
  pwd: "pw1234",
  roles: ["tenant_admin_reader"]
});

위 스크립트처럼 RBAC 설정들을 모두 DB Query를 제공하고 있어서, 백오피스를 구축하면 쉽게 권한 분리도 가능하다.

마치며

속한 SaaS팀에서 Multi-Tenancy 환경을 구축하면서 MognoDB를 메인 데이터베이스로 사용하고있는 이유에 대해서 다뤄보았다. 포스트에서 유의할점은 RDBMS에서도 RBAC에 준하는 권한 관리가 가능하다.

그러나 MongoDB는 동적 데이터 구조 관리(Dynamic Data Structure Management) + 스키마 리스(Schema-less)하여 보다 현재 속한 신사업 팀이 보다 빠르고 간단하게 Multi-Tenancy를 구축하는데 도움이 되었던 내용을 공유한것이니 MongoDB 라서 가능했다!는 아니라는것을 유의바란다.

(실제로, Mongo Atlas를 사용하고 있었기때문에 Atlas Search 기능을 통해 보다 쉽게 검색 엔진을 도입할 수 있었던 사례도 있는데 이것도 추후 기회가 되면 작성해보도록 하겠다.)