이 단계에서 얻는 것
이 단계는 단일 서버를 넘어선 분산 환경에서의 아키텍처를 다룹니다.
- 데이터 분산의 기술: 샤딩(Sharding), 컨시스턴트 해싱으로 무한 확장의 원리를 이해합니다.
- 분산 정합성: 2PC, Saga 패턴으로 분산 환경에서 트랜잭션을 설계합니다.
- 이벤트 기반 아키텍처: Kafka를 활용한 비동기 통신과 결과적 일관성을 확보합니다.
이 모듈을 보는 방법
- 분산의 기초: CAP 이론과 일관성 모델(Strong vs Eventual)을 이해하고
- 데이터 확장: 샤딩 전략과 라우팅 원리를 파악한 뒤
- 트랜잭션: 분산된 서비스 간 정합성을 맞추는 패턴(Saga)을 학습합니다.
읽을 때는 “기술 이름을 외운다"보다 어떤 실패를 감수하고 어떤 보상을 준비할지를 먼저 적어보는 방식이 좋습니다. 예를 들어 샤딩을 공부할 때는 “어떤 컬럼을 키로 잡을까?“에서 멈추지 말고, 특정 테넌트에 트래픽이 몰릴 때 라우터/인덱스/캐시/재배치가 각각 어떻게 흔들리는지까지 같이 봐야 합니다. Kafka도 마찬가지입니다. 메시지를 넣고 빼는 API보다, 재시도·중복·순서·DLQ·리밸런싱이 실제 장애 시간에 어떤 운영 선택지를 주는지가 핵심입니다.
왜 이런 순서인가
분산 시스템은 “확장성"을 얻는 대신 “일관성"을 희생하는 트레이드오프의 연속입니다. 그래서 이론적 배경(CAP/Consistency)을 먼저 잡고, 구체적인 기술(Kafka, Sharding)로 들어가는 흐름입니다.
초반에는 정답을 하나로 고르기 어렵습니다. 강한 일관성을 택하면 지연과 가용성이 흔들리고, 결과적 일관성을 택하면 사용자 경험과 보정 작업이 복잡해집니다. 따라서 이 모듈은 “개념 → 설계 선택 → 장애 시나리오 → 운영 체크” 순서로 반복해서 읽는 것을 전제로 합니다. 처음 읽을 때는 큰 그림을 잡고, 두 번째 읽을 때는 자신이 운영하는 서비스의 주문/결제/알림/정산 같은 흐름에 대입해보세요.
추천 학습 경로
분산 시스템 글은 많기 때문에, 처음부터 전체 목록을 훑으면 주제가 흩어질 수 있습니다. 아래 순서로 읽으면 “왜 분산이 어려운가"에서 “어떻게 운영 가능한 설계로 낮출 것인가"까지 연결됩니다.
- CAP 이론과 일관성 모델로 가용성·일관성·지연의 언어를 맞춥니다.
- 샤딩과 컨시스턴트 해싱을 읽고, 키 선택이 핫 파티션과 리밸런싱 비용으로 이어지는 과정을 봅니다.
- 분산 트랜잭션과 Outbox/Saga 패턴을 이어서 읽으며, 원자성 대신 보상과 재처리로 정합성을 맞추는 방식을 정리합니다.
- Kafka 기초, 멱등성과 순서 보장, Retry/DLQ를 묶어서 읽고, 메시지 기반 시스템의 운영 실패 모드를 확인합니다.
- 서비스 디스커버리와 헬스 기반 라우팅까지 보면, 데이터뿐 아니라 트래픽 라우팅도 분산 시스템의 일부라는 감각이 생깁니다.
이 단계의 핵심 주제
- CAP/PACELC, 일관성 모델
- 샤딩/라우팅/리밸런싱 전략
- 분산 트랜잭션(2PC/Saga)
- 이벤트 기반 통신(Kafka, Outbox)
실무 판단 기준
분산 설계는 “멋진 아키텍처"보다 복구 가능한 실패 경로가 더 중요합니다. 아래 질문에 답하지 못하면, 기술 선택을 조금 늦추고 장애 시나리오를 먼저 구체화하는 편이 안전합니다.
- 데이터 정합성: 사용자가 즉시 같은 값을 봐야 하는가, 아니면 몇 초 뒤 수렴해도 되는가?
- 중복 처리: 메시지/요청/잡이 두 번 실행되어도 결과가 한 번 실행한 것과 같게 만들었는가?
- 부분 실패: 결제는 성공했지만 주문 이벤트 발행이 실패하면, 누가 언제 어떻게 보정하는가?
- 순서 의존성: 이벤트 순서가 바뀌거나 늦게 도착해도 읽기 모델이 깨지지 않는가?
- 운영 가시성: lag, retry, DLQ, shard skew, 보상 트랜잭션 수를 대시보드에서 바로 볼 수 있는가?
- 롤백 가능성: 샤딩 키, 토픽 스키마, 라우팅 정책을 바꿨을 때 이전 상태로 되돌릴 절차가 있는가?
이 기준은 설계 리뷰 체크리스트로도 쓸 수 있습니다. 특히 “결과적 일관성"이라는 말을 썼다면, 반드시 사용자에게 보이는 중간 상태와 운영자가 실행할 보정 도구까지 같이 정의해야 합니다.
예시 시나리오: 주문 생성과 재고 차감
가장 흔한 예시는 주문 서비스와 재고 서비스가 분리된 상황입니다. 단일 DB라면 하나의 트랜잭션으로 묶을 수 있지만, 서비스와 저장소가 나뉘면 네트워크 실패, 메시지 중복, 재시도 순서가 모두 설계 대상이 됩니다.
- 주문 생성 요청을 받으면 주문 서비스는 먼저
PENDING상태로 주문을 기록합니다. - 같은 트랜잭션 안에서 Outbox 테이블에
OrderCreated이벤트를 저장합니다. - 별도 퍼블리셔가 Outbox를 읽어 Kafka로 이벤트를 발행합니다.
- 재고 서비스는 이벤트를 소비하고, 주문 ID를 멱등 키로 사용해 중복 차감을 막습니다.
- 재고 차감에 실패하면
StockReservationFailed이벤트를 발행하고, 주문 서비스는 주문을 취소 또는 보류 상태로 전환합니다. - 운영자는 DLQ와 보정 잡을 통해 “발행 실패”, “소비 실패”, “보상 실패"를 분리해서 확인합니다.
이 흐름에서 중요한 것은 “Kafka를 썼다"가 아니라, 실패가 난 지점을 재실행 가능한 단위로 쪼갰다는 점입니다.
Outbox는 DB 커밋과 이벤트 발행 사이의 틈을 줄이고, Saga는 전체 성공을 기다리는 대신 단계별 상태 전이를 명시합니다.
대신 사용자에게는 일시적인 PENDING 상태가 보일 수 있으므로, 화면 문구와 고객지원 대응까지 함께 설계해야 합니다.
미니 실습
- 샤딩 키 설계: 데이터 분포가 치우치는 케이스 만들기
- SAGA 시나리오: 보상 트랜잭션 흐름을 시퀀스로 정리
- 이벤트 흐름 추적: Producer→Consumer 지연 구간 찾기
운영 체크리스트
- 새 토픽/이벤트를 만들 때 producer, consumer, schema owner를 문서에 남겼는가?
- consumer lag 임계값과 알림 기준이 업무 영향 기준으로 정의되어 있는가?
- DLQ 메시지를 재처리할 때 중복 처리와 순서 역전 문제가 없는가?
- 샤드별 QPS, 저장 용량, p95/p99 지연을 따로 볼 수 있는가?
- 리밸런싱 또는 재샤딩 중 쓰기 경로를 멈출지, 이중 쓰기로 넘길지 결정했는가?
- 보상 트랜잭션이 실패했을 때 수동 처리 절차와 감사 로그가 남는가?
흔한 함정
- 2PC를 기본값으로 선택: 강한 정합성이 필요한 구간은 있지만, 모든 서비스 호출을 2PC로 묶으면 가용성과 운영성이 급격히 나빠집니다.
- 샤딩 키를 현재 트래픽만 보고 결정: 초기에는 균등해 보여도 테넌트 성장, 지역 확장, 이벤트성 트래픽으로 핫 샤드가 생길 수 있습니다.
- 메시지 중복을 예외로 취급: 대부분의 브로커/컨슈머 조합에서 중복은 정상적인 운영 조건으로 보고 멱등성을 설계해야 합니다.
- DLQ를 쓰레기통처럼 방치: DLQ는 실패 원인의 압축 로그입니다. 재처리 정책, 보존 기간, 알림 담당자가 없으면 장애가 조용히 쌓입니다.
- 결과적 일관성을 UX 없이 도입: 데이터가 늦게 맞춰지는 동안 사용자가 어떤 상태를 보게 되는지 설명하지 않으면, 기술적으로는 정상이어도 제품 경험은 장애처럼 보입니다.
완료 기준
- 일관성/가용성/지연의 트레이드오프를 사례로 설명할 수 있다
- 샤딩 키가 잘못될 때 어떤 문제가 생기는지 말로 설명할 수 있다
- 분산 트랜잭션에서 “성공/실패/보상” 흐름을 그릴 수 있다
- Kafka consumer lag, DLQ, 중복 메시지, 재처리 정책을 한 장애 시나리오 안에서 설명할 수 있다
- 특정 기능에 대해 “강한 일관성”, “결과적 일관성”, “수동 보정” 중 무엇을 선택할지 이유와 함께 말할 수 있다