← 홈으로 PROJECT DECK — 02 / 06
02 · DB · Kafka · Observability 2025.11 — 상시

성능 · 안정성,
오픈을 버티는 기반.

대량 데이터가 흐르자 드러난 병목과 불안정을 DB → 메시징 → 동시성 → 관측성 순서로 층별 제거 — 각 층에 "같은 문제가 다시 안 생기는 구조"를 남겼습니다.

← → 방향키 · 휠 · 스와이프로 넘겨보세요

오픈 준비기에 드러난 것들

PROBLEM 01 — 쓰기 경로

행 단위 INSERT와 N+1

수천 행 엑셀 업로드가 행 단위로 저장되고, 재고 증차감은 N+1 조회를 동반 — 대량 데이터 앞에서 처리 시간이 무너졌습니다.

PROBLEM 02 — 소비 경로

리밸런싱발 무한 재처리

엑셀 다운로드 컨슈머가 폴링 간격을 넘기면 Kafka 리밸런싱 → 같은 작업이 무한 재처리되는 사고 패턴. 배치 생성 경로엔 경합 방어도 없었고, 전부 APM 없이 로그로만 관측됐습니다.

판단개별 튜닝의 나열로는 부족하다 — 층마다 불변식과 구조를 남겨서 같은 종류의 문제를 재발 불가능하게 만들어야 한다.

층별로 다졌다

DB
R/W 분리 · 배치 삽입 · 인덱스 → 메시징
리밸런싱 차단 불변식 → 동시성
분산락 UntilCommit → 관측성
Datadog APM · 노이즈 분리
AWS JDBC Wrapper
읽기 트랜잭션을 리더로 — 코드 변경 최소화
배치 삽입 + ID 반환
성능을 위해 정합성을 포기하지 않는 구조
BusinessWarnException
예상 가능한 실패 분리 — 에러 신호의 SNR 회복

다섯 가지 설계 결정

D1읽기 부하는 커넥션 층에서 가른다
Aurora R/W 분리 — 읽기 전용 트랜잭션을 리더 인스턴스로 라우팅.
D2대량 쓰기는 배치 삽입으로
이력 · 원장 · Outbox를 jOOQ 배치 삽입으로, 생성 ID까지 반환. N+1 동시 제거.
D3리밸런싱은 불변식으로 막는다
타임아웃(5분) < max.poll.interval(8분) 보장 + fail-fast + 전용 그룹 분리.
D4분산락은 커밋까지
UntilCommit 패턴 — 커밋 전에 풀리는 락은 락이 아니다. 주요 UseCase 일괄 적용.
D5운영 데이터가 인덱스를 정한다
seq scan 통계 분석으로 24건 보강 — 감이 아니라 실측으로.

결과 — 전부 실측입니다

+24건
운영 seq scan 분석 기반 인덱스
9 → 3
컨슈머 concurrency 정합화
500 → 2,000
다운로드 내부 조회 페이지 크기
5분 < 8분
리밸런싱 차단 불변식

배치 삽입 + Transactional Outbox가 대량 처리의 표준 경로로 정착했고, 무한 재처리는 구조적으로 차단 — 이후 QA 기간을 성능 이슈 재발 없이 통과했습니다.

다음 프로젝트 — WMS AI 챗봇 → 홈으로