jyunee

Kafka 컨슈머 그룹과 오프셋: 중복과 누락을 결정하는 처리 구조

Kafka 컨슈머의 핵심은 레코드를 읽는 코드보다 처리 완료 시점과 오프셋 커밋 시점을 맞추는 것이다. 이 둘이 어긋나면 장애 복구 과정에서 중복 처리나 데이터 누락이 발생한다.컨슈머 그룹은 하나의 논리적 구독자다같은 group.id를 사용하는 컨슈머들은 토픽의 파티션을 나눠 처리한다. 한 파티션은 같은 그룹 안에서 한 컨슈머에게만 할당된다.컨슈머가 추가되거나 종료되고, 구독 토픽의 파티션 수가 바뀌면 그룹 코디네이터가 파티션을 다시 할당한다. 이 과정을 리밸런스(rebalance)라고 한다. 리밸런스는 장애 복구와 수평 확장을 가능하게 하지만 처리 중단과 중복 가능성도 만든다. 파티션이 4개인 토픽에 같은 그룹의 컨슈머를 6개 실행하면 동시에 일하는 컨슈머는 최대 4개다. 반대로 컨슈머가 2개라면 각 ..

Kafka 복제와 내구성: acks만 all로 설정하면 충분할까

Kafka에 이벤트를 전송해 성공 응답을 받았다고 해서 어떤 장애에서도 데이터가 안전하다는 뜻은 아니다. 복제 팩터, ISR, acks, min.insync.replicas가 함께 맞아야 원하는 내구성을 얻을 수 있다.파티션 복제본은 리더와 팔로워로 나뉜다파티션의 복제 팩터가 3이면 서로 다른 브로커에 복제본 세 개가 배치된다. 이 가운데 하나가 리더이고 나머지는 팔로워다. 프로듀서의 쓰기와 일반적인 컨슈머 읽기는 리더를 기준으로 처리되며, 팔로워는 리더의 로그를 따라간다.리더 브로커에 장애가 발생하면 동기화 상태가 양호한 팔로워 가운데 하나가 새 리더가 된다. 복제 팩터 3은 복제본이 세 개라는 뜻이지 언제나 두 대 장애를 견딘다는 보장은 아니다. 어떤 복제본이 최신 상태인지, 쓰기를 승인할 때 몇 개..

Kafka 토픽과 파티션 이해하기: 순서와 병렬 처리의 기준

Kafka를 설계할 때 가장 중요한 결정은 어떤 이벤트를 어느 토픽에 넣고, 어떤 키로 파티션을 선택할지 정하는 것이다. 이 결정은 이벤트 순서, 컨슈머 병렬 처리량, 확장 방식에 직접 영향을 준다.토픽은 이벤트 종류를 구분한다토픽은 레코드를 분류하는 논리적 이름이다. 예를 들어 주문 상태가 바뀔 때마다 이벤트를 발행한다면 order-events 같은 토픽을 사용할 수 있다. 토픽 이름만 보고도 소유 팀과 이벤트의 의미를 알 수 있도록 조직 차원의 규칙을 정하는 편이 좋다.다음과 같은 형식이 한 예다...commerce.order-events.v1 환경 이름을 토픽에 넣을지는 클러스터를 환경별로 분리하는지에 따라 달라진다. 중요한 것은 규칙을 일관되게 적용하고, 토픽의 소유자·스키마·보관 정책을 함께 관..

Apache Kafka는 왜 이벤트 스트리밍의 중심이 되었을까

서비스가 몇 개뿐일 때는 데이터를 보내는 쪽이 받는 쪽의 API를 직접 호출해도 큰 문제가 없다. 하지만 주문 데이터를 결제, 배송, 알림, 검색, 분석 시스템이 함께 사용하기 시작하면 연결은 빠르게 복잡해진다. 한 시스템의 장애나 처리 지연이 다른 시스템으로 전파되고, 새로운 소비자가 생길 때마다 기존 서비스도 수정해야 한다. Apache Kafka는 이런 연결을 지속해서 보관되는 이벤트 스트림으로 바꾼다. 프로듀서는 이벤트를 토픽에 기록하고, 컨슈머는 자신의 속도로 읽는다. 양쪽은 서로의 주소와 처리 시점을 몰라도 된다.메시지 브로커보다 로그에 가깝다Kafka를 단순한 메시지 전달 도구로만 보면 중요한 특징을 놓친다. 일반적인 큐에서는 소비가 끝난 메시지가 사라지는 경우가 많지만, Kafka의 레코드..

전술적 DDD로 마이크로서비스 내부 모델 설계하기

서비스 경계를 잘 나눠도 내부 구현이 데이터베이스 테이블과 절차형 조건문에만 의존하면 복잡한 업무 규칙을 이해하고 변경하기 어렵다. 전술적 DDD는 엔티티, 값 객체, 애그리거트, 도메인 서비스와 도메인 이벤트 같은 구성 요소로 비즈니스 개념을 코드에 표현한다. 모든 서비스에 DDD 구성 요소를 기계적으로 적용할 필요는 없다. 업무 규칙이 단순한 서비스라면 풍부한 도메인 모델을 구성하기보다, 애플리케이션 서비스에서 처리 흐름을 조정하는 절차적인 구조가 더 명확할 수 있다. 이러한 구조는 아키텍처 패턴상 트랜잭션 스크립트에 가깝다. 규칙과 상태 전이가 복잡하고 모델이 장기간 발전하는 영역에서 전술적 DDD의 가치가 커진다.엔티티: 식별자로 이어지는 생명주기엔티티(entity)는 속성 값이 아니라 고유한 식..

이벤트 스토밍 결과를 API와 애플리케이션 설계로 옮기기

이벤트 스토밍으로 커맨드, 이벤트, 정책과 경계 후보를 찾았다면 이를 실행 가능한 설계로 구체화해야 한다. 이때 포스트잇을 기계적으로 엔드포인트나 클래스에 대응시키면 탐색 모델의 모호함이 코드로 그대로 옮겨진다. 상세 설계의 목표는 업무 의도를 유지하면서 외부 계약, 애플리케이션 유스케이스, 도메인 모델과 기술 어댑터의 책임을 분명히 하는 것이다.탐색 결과를 먼저 정리한다각 바운디드 컨텍스트 후보에 대해 다음 항목을 정리한다.탐색 요소상세 설계에서 확인할 내용커맨드실행할 유스케이스, 입력, 권한과 거부 조건도메인 이벤트이미 발생한 사실, 발행 시점과 스키마정책이벤트에 반응하는 규칙과 다음 행동애그리거트 후보함께 일관성을 지켜야 하는 상태와 규칙읽기 모델사용자 또는 다른 서비스가 필요한 조회 형태외부 시스..

이벤트 스토밍으로 마이크로서비스 후보 도출하기

서비스 경계를 회의실에서 몇 명의 설계자가 정하면 실제 업무의 예외와 부서마다 다른 언어를 놓치기 쉽다. 이벤트 스토밍(EventStorming)은 도메인 전문가, 기획자, 개발자, 운영자 등 다양한 이해관계자가 함께 업무에서 일어나는 사건을 시간순으로 탐색하는 협업 모델링 방식이다. EventStorming 공식 소개는 이를 의도적인 집단 학습 활동으로 설명한다. 완성된 다이어그램보다 서로 다른 관점을 빠르게 드러내고 공통 이해를 만드는 과정이 더 중요하다.무엇을 발견하려는가이벤트 스토밍은 테이블이나 화면 목록에서 시작하지 않는다. 업무에서 이미 일어난 중요한 사실인 도메인 이벤트에서 출발한다.쇼핑몰 주문 흐름이라면 다음과 같은 사건이 있다.상품이 장바구니에 담겼다주문이 접수됐다결제가 승인됐다재고가 예..

컨텍스트 맵으로 서비스 관계 설계하기: DDD 통합 패턴

바운디드 컨텍스트를 찾았다고 서비스 설계가 끝나는 것은 아니다. 주문은 상품 가격을 확인하고, 결제 결과는 주문 상태를 바꾸며, 배송은 수취인 정보를 필요로 한다. 경계를 나눈 뒤에는 누가 누구에게 의존하고 어떤 모델로 대화할지를 설계해야 한다. 컨텍스트 맵(context map)은 바운디드 컨텍스트와 그 사이의 관계를 시각화한다. 단순한 호출 다이어그램이 아니라 모델의 영향력, 팀 사이의 협력 방식, 번역 책임을 함께 보여주는 지도다.상류와 하류데이터나 모델을 제공하는 쪽을 상류(upstream), 이를 소비하는 쪽을 하류(downstream)라고 한다. 상류의 계약이 바뀌면 하류가 영향을 받기 쉬우므로 두 팀의 힘과 협력 관계를 명시해야 한다.호출 방향과 영향 방향은 같지 않을 수 있다. 주문 서비스..

DDD로 마이크로서비스 경계 찾기: 비즈니스 역량과 바운디드 컨텍스트

마이크로서비스 설계에서 가장 어려운 질문은 “서비스를 얼마나 작게 만들 것인가?”가 아니다. 어떤 책임과 데이터를 한 경계 안에 둘 것인가가 핵심이다. 경계를 잘못 나누면 변경 하나가 여러 서비스를 동시에 건드리고, 서비스 사이의 호출과 분산 트랜잭션만 늘어난다. 도메인 주도 설계(Domain-Driven Design, DDD)는 비즈니스의 언어와 모델이 달라지는 지점을 찾아 서비스 경계를 설계하는 데 유용한 관점을 제공한다.좋은 경계의 두 가지 조건모듈화의 기본 목표는 높은 응집도와 낮은 결합도다.높은 응집도(high cohesion): 같은 이유로 변경되는 기능과 데이터가 한곳에 모여 있다.낮은 결합도(low coupling): 다른 영역의 내부 구현을 모르고도 협력할 수 있다.예를 들어 주문 생성 ..

마이크로서비스 내부 설계: 계층형, 헥사고날, 클린 아키텍처

서비스를 작게 나눴다고 내부 코드가 자동으로 유연해지는 것은 아니다. 컨트롤러, SQL, 프레임워크 코드에 업무 규칙이 흩어져 있으면 데이터베이스나 메시징 기술을 바꿀 때 서비스 전체를 다시 작성해야 한다. 마이크로서비스의 외부 경계만큼 내부의 의존성 방향도 중요하다.비즈니스 로직은 어디에 있어야 하는가비즈니스 로직은 도메인의 규칙과 의사결정이다. 할인 조건, 대출 가능 여부, 주문 상태 전이처럼 기술이 바뀌어도 유지되어야 하는 지식이다. 데이터베이스 조회와 화면 전환은 그 규칙을 실행하기 위한 세부 사항이다. 데이터베이스 중심 구조에서는 테이블을 먼저 설계하고 SQL에 계산과 조건을 집중시키기 쉽다. 간단한 CRUD에는 효율적이지만 업무가 복잡해질수록 규칙이 SQL, 서비스 클래스, 화면 코드에 분산된..