안녕하세요, 강남언니 백엔드 엔지니어 Eddy(안정균)입니다.저는 현재 강남언니에서 미용 의료 병원용 B2B SaaS 제품(이하 KOS)을 개발하고 있습니다.KOS 제품을 개발하면서 자동화 테스트에서는 성공하였으나 운영계 배포 후 버그가 발생했던 아찔한 경험을 한 이후로 테스트를 작성하는 방법이 많이 바뀌었는데요. 이번 글에서는 KOS의 예약 시스템 개발 과정에서 발생했던 사례를 기반으로 배운 인사이트에 대해 소개드려보고자 합니다.KOS의 서비스들은 여러 Microservice들로 이루어져있고, 여러 컴포넌트 간 동기 방식의 HTTP 통신 또는 메시지를 발행하여 Message Broker 등을 활용하는 등의 여러 통신 방식이 존재합니다. 그리고 메인 데이터베이스로는 MongoDB를 사용하고 있습니다.대개 복잡한 비지니스 요구사항을 만족하기 위해 시스템은 하나의 명령(Command)이 실행 되었을 때 여러 서비스 컴포넌트 간 여러 인프라를 이용한 통신이 발생하고 이를 제어하기 위해선 하나의 유즈케이스에 많은 의존성이 필요해질 때가 있습니다.다음과 같이 복잡한 비즈니스 요구사항과 시스템 제약사항을 만족하기 위해 다양한 의존 관계가 형성되었을 때, 어떻게 시스템을 설계하고 테스트를 작성하는지에 대한 경험을 KOS 예약 시스템의 예제 코드 기반으로 공유하고자 합니다.• 동일한 내원객(Visitor)은 동 시간대 중복 예약을 할 수 없어야 한다.• 예약 완료 시 해당 내원객에게 예약 확정 SMS 문자가 발송되어야 한다.• 예약 완료 시 내원객 스케줄의 조회 모델이 만들어져야 한다. (ref. CQRS)• 위 조건을 만족하기 위해, 스케줄 서비스에서 발생한 사건들(Events)을 발행하여 Downstream Services 에서 요구사항에 맞게 소비하여 처리하고 있습니다.예약 요구사항을 만족하기 위한 시스템 구성도스케줄 서비스에서 예약 성공 후 발행되는 도메인 이벤트를 알림 이벤트 처리기와 스케줄 이벤트 처리기 등에서 소비하여 요구사항을 만족하는 과정을 추상적으로 도식화해 보면 위와 같습니다.내원객의 식별값(visitorId)으로 내원객 정보를 읽어오는 Reader입니다.⇒ Spring Webflux의 WebClient를 이용하여 Visitor Service를 호출합니다.중복 예약 방지 요구사항을 만족하기 위해 필요한 내원객의 식별 값과 예약 시간을 파라미터로 받는 중복 예약 검증기입니다.⇒ 예약 시 Redis에 캐싱하여 내원객 + 예약 시간 기반으로 중복 예약인지 검증합니다.KOS는 예약 시스템에 Event Sourcing을 적용하여, 명령이 발생하면 관련된 도메인 이벤트들을 스토어에 적재하고 있습니다. EventStore는 도메인 이벤트들을 관리하는 스토어입니다. (ref. 시간여행이 가능한 시스템 아키텍처)⇒ MongoDB와 AWS Kinesis Data Stream을 이용하여 생산된 Message에 대해 Store and Forward 작업을 수행합니다.이어서 유즈케이스 구현체에 대응하는 테스트를 작성해 보겠습니다.현재의 구조에서는 테스트를

안녕하세요, 힐링페이퍼 백엔드 엔지니어 안정균(Eddy)입니다.저는 현재 강남언니 팀에서 미용 의료 병원용 B2B SaaS 제품(이하 KOS)을 개발하고 있습니다.KOS 제품을 개발하면서 자동화 테스트에서는 성공하였으나 운영계 배포 후 버그가 발생했던 아찔한 경험을 한 이후로 테스트를 작성하는 방법이 많이 바뀌었는데요. 이번 글에서는 KOS의 예약 시스템 개발 과정에서 발생했던 사례를 기반으로 배운 인사이트에 대해 소개드려보고자 합니다.KOS의 서비스들은 여러 Microservice들로 이루어져있고, 여러 컴포넌트 간 동기 방식의 HTTP 통신 또는 메시지를 발행하여 Message Broker 등을 활용하는 등의 여러 통신 방식이 존재합니다. 그리고 메인 데이터베이스로는 MongoDB를 사용하고 있습니다.대개 복잡한 비지니스 요구사항을 만족하기 위해 시스템은 하나의 명령(Command)이 실행 되었을 때 여러 서비스 컴포넌트 간 여러 인프라를 이용한 통신이 발생하고 이를 제어하기 위해선 하나의 유즈케이스에 많은 의존성이 필요해질 때가 있습니다.다음과 같이 복잡한 비즈니스 요구사항과 시스템 제약사항을 만족하기 위해 다양한 의존 관계가 형성되었을 때, 어떻게 시스템을 설계하고 테스트를 작성하는지에 대한 경험을 KOS 예약 시스템의 예제 코드 기반으로 공유하고자 합니다.• 동일한 내원객(Visitor)은 동 시간대 중복 예약을 할 수 없어야 한다.• 예약 완료 시 해당 내원객에게 예약 확정 SMS 문자가 발송되어야 한다.• 예약 완료 시 내원객 스케줄의 조회 모델이 만들어져야 한다. (ref. CQRS)위 조건을 만족하기 위해, 스케줄 서비스에서 발생한 사건들(Events)을 발행하여 Downstream Services 에서 요구사항에 맞게 소비하여 처리하고 있습니다.예약 요구사항을 만족하기 위한 시스템 구성도스케줄 서비스에서 예약 성공 후 발행되는 도메인 이벤트를 알림 이벤트 처리기와 스케줄 이벤트 처리기 등에서 소비하여 요구사항을 만족하는 과정을 추상적으로 도식화해 보면 위와 같습니다.내원객의 식별값(visitorId)으로 내원객 정보를 읽어오는 Reader입니다.⇒ Spring Webflux의 WebClient를 이용하여 Visitor Service를 호출합니다.중복 예약 방지 요구사항을 만족하기 위해 필요한 내원객의 식별 값과 예약 시간을 파라미터로 받는 중복 예약 검증기입니다.⇒ 예약 시 Redis에 캐싱하여 내원객 + 예약 시간 기반으로 중복 예약인지 검증합니다.KOS는 예약 시스템에 Event Sourcing을 적용하여, 명령이 발생하면 관련된 도메인 이벤트들을 스토어에 적재하고 있습니다. EventStore는 도메인 이벤트들을 관리하는 스토어입니다. (ref. 시간여행이 가능한 시스템 아키텍처)⇒ MongoDB와 AWS Kinesis Data Stream을 이용하여 생산된 Message에 대해 Store and Forward 작업을 수행합니다.이어서 유즈케이스 구현체에 대응하는 테스트를 작성해 보겠습니다.현재의 구조에서는 테스트

카카오 분산데이터베이스 조직에서 안정적인 MongoDB 운영을 위해 노력하고 있습니다.안녕하세요, 카카오 분산데이터베이스 조직에서 MongoDB를 운영하고 있는 앤디입니다.MongoDB의 메인 스토리지 엔진인 WiredTiger에 관한 시리즈의 첫 글 "MongoDB WiredTiger의 파일 구조"에서는 WiredTiger의 구성요소와 아키텍처를 전반적으로 살펴보았습니다.이번 글에서는 조금 더 세부적으로 들어가서, MongoDB WiredTiger에서 B+Tree를 활용한 데이터 관리 방법을 심층적으로 다루어 보겠습니다. 앞선 “MongoDB WiredTiger의 파일 구조” 내용과 더불어 MongoDB에 대한 기반 지식이 필요한 내용이 포함될 수 있으니 참고해 주시길 바라며, MongoDB의 데이터 저장 방식에 관심 있는 분들께 유용한 자료가 되기를 기대합니다.이번 글 작성에 사용된 MongoDB 버전과 주요 도구는 아래와 같습니다.• gdb (GNU Debugger) : 프로그램 실행을 제어하고 메모리 상태를 분석하는 데 유용한 도구입니다. (구체적인 빌드 방법 및 사용법은 부록을 참조해 주시기 바랍니다.)B+Tree는 1970년대에 등장해 지금까지도 Oracle, MySQL, PostgreSQL과 같은 주요 DBMS에서 사용되고 있는 자료구조입니다. B+Tree는 데이터 삽입과 삭제 시에도 트리의 높이를 균형 있게 유지하는 동적인 트리 구조로, 여기에서 'B’는 보통 Balanced를 의미합니다. "+"는 실제 레코드가 가장 하위 레벨인 리프 노드(leaf node)에만 저장된다는 것을 의미하며 레코드들은 항상 정렬된 상태를 유지합니다. 아래 그림은 가장 일반적으로 접할 수 있는 B+Tree의 형태를 나타냅니다.앞서 언급한 DBMS보다는 한참 어린 2007년생 MongoDB도 B+Tree를 사용하고 있는데요. 이렇게 오랜 기간 동안 발전하면서 범용적으로 쓰이다 보니, B+Tree의 세부 구현은 각 DBMS의 특성에 따라 다를 수 있습니다.이번 문서에서는 제가 주목하는 MongoDB WiredTiger의 B+tree에 대해 몇가지 특징을 살펴보려고 합니다. 특히 페이지 간의 연결구조와 리프 페이지에서의 데이터 추가, 삭제, 변경 처리를 상세히 다루고, 마지막으로 이해를 돕기 위해 MySQL의 InnoDB에서 사용되는 B+Tree와도 가볍게 비교해 보도록 하겠습니다.페이지는 B+Tree에서 노드라고도 불리며, 데이터를 저장하거나 검색하는 기본 단위로 사용됩니다. 그리고 여러 페이지를 스캔해야하는 범위 쿼리(range query) 혹은 순차 접근(sequential access)이 필요한 작업에서의 효율성을 위해 <그림 1>과 같이 동일한 레벨의 페이지끼리의 연결을 유지하는 방식을 보편적으로 사용합니다.하지만 WiredTiger에서는 동일한 레벨의 페이지끼리 연결을 유지하지 않습니다. 이를 확인하기 위해 WiredTiger의 B+Tree 구조를 살펴보겠습니다.먼저 그림에서 확인할 수 있는 내용을 정리하고, gdb를 통해 상세 구조를 하

안녕하세요, 백엔드팀 허민지입니다.오늘은 똑닥에서 멤버십 서비스를 도입하게 된 배경과 함께, 멤버십 런칭 과정에서 새롭게 적용한 MongoDB Transaction, 그리고 그 과정에서 발생했던 에러 사례와 이를 예방하기 위한 방법에 대해 이야기해보려고 합니다.비브로스는 2023년 8월 2일 멤버십 서비스를 정식 출시했습니다. 무료 서비스에서 유료 멤버십으로 전환하게 된 주요 이유는 '운영 자금' 확보가 절실했기 때문입니다. 글로벌 경제 위기와 침체된 투자 시장 속에서, 스타트업인 비브로스는 자금 조달에 큰 어려움을 겪었으며, 서비스를 지속하기 위해 유료 멤버십 전환이 불가피한 선택이었습니다. 유료 멤버십 도입이 확정된 이후, 백엔드팀은 멤버십 관련 업무를 담당할 인원 2명과 결제 시스템을 전담할 인원 1명으로 업무를 분담하여 작업을 시작했습니다.백엔드팀의 주요 목표는 두 가지로 나뉘었습니다. 첫째, 사용자 요청일에 정확히 한 번씩 결제가 이루어질 수 있도록 안전한 정기 결제 시스템을 구축하는 것이었고, 둘째, 멤버십 조회성 서버 부하를 대비할 대안을 마련하는 것이었습니다. 특히 첫 번째 목표인 안전한 정기 결제 시스템 구축을 위해 MongoDB Transaction을 도입하여 데이터 일관성과 신뢰성을 확보하고자 했습니다.트랜잭션은 하나 이상의 읽기 또는 쓰기 작업을 포함하는 데이터베이스의 논리적 처리 단위입니다. 애플리케이션에서 여러 도큐먼트에 대한 읽기 및 쓰기를 논리적으로 묶어서 처리해야 하는 상황이 종종 발생합니다. 트랜잭션의 핵심은 작업이 성공하든 실패하든 부분적으로 완료되지 않는다는 점입니다. 즉, 트랜잭션 내 모든 작업이 완료되거나, 그렇지 않으면 모두 롤백됩니다.트랜잭션이 진정한 트랜잭션으로 간주되기 위해서는 ACID(원자성, 일관성, 고립성, 지속성) 속성을 충족해야 합니다. ACID 트랜잭션은 오류가 발생하더라도 데이터 및 데이터베이스 상태의 유효성을 보장합니다.MongoDB는 4.0 버전부터 멀티 문서 트랜잭션을 지원하며, 이를 통해 관계형 데이터베이스의 ACID 트랜잭션 특성을 제공합니다. 이 기능은 MongoDB를 활용하여 복잡한 비즈니스 로직을 처리하거나 다중 문서 작업을 단일 작업처럼 수행할 수 있도록 돕습니다. 이러한 특징은 데이터의 일관성을 유지하면서도 유연한 트랜잭션 설계를 가능하게 합니다.• 원자성: 트랜잭션 내의 모든 작업은 성공적으로 완료되거나, 실패 시 모두 롤백됩니다.• 일관성: 트랜잭션 완료 후 데이터베이스는 항상 유효하고 일관된 상태를 유지합니다.• 고립성: 여러 트랜잭션이 동시에 실행되더라도 서로의 상태에 영향을 미치지 않습니다.• 지속성: 트랜잭션이 커밋되면 그 결과는 영구적으로 저장됩니다.MongoDB 트랜잭션은 특히 복잡한 다중 문서 작업이나 데이터의 일관성이 필수적인 시나리오에서 유용합니다. 이러한 특성은 원자성이 중요한 멤버십 데이터 관리에 적합한 선택이었습니다.비브로스에서는 멤버십 데이터를 멤버십, 멤버십 트랜잭션, 멤버십 트랜잭션 히스토리로 세분화하여 관리하며, 트랜잭션을 적극