쿠팡 「대용량 트래픽 처리를 위한 쿠팡의 백엔드 전략」 리뷰 — 캐시 두 겹과 '분 단위 99.99% 동일'이라는 문장, 그리고 그 0.01%를 누가 어떻게 세는가

원문: 대용량 트래픽 처리를 위한 쿠팡의 백엔드 전략 — 마이크로서비스로 고객에게 데이터 서빙하기: 고가용성, 고처리량, 그리고 지연시간 최소화 (Part 1) — Coupang Engineering Blog, Gogi (Du Hyeong) Kim·Key (Ki Hyeon) Kim, 2022-09-02

JSP 전환기 3편에서 조회와 명령을 분리하는 CQRS를 도입했고, parity-pay 7편에서 원장(진실)과 잔액 스냅샷(조회)을 나눴다. 둘 다 “읽기용 표현을 따로 둔다”는 결정이고, 그 결정의 대가는 “둘이 어긋날 수 있다”였다. 쿠팡 글은 그 결정을 1,800만 사용자의 상품 페이지 규모에서 한 것이다. 대가를 어떻게 지불했는지 보고 싶었다.

원문이 말하는 것

상품 상세 페이지 하나에 이미지·이름(Catalog), 가격(Pricing), 재고·도착 보장일(Fulfillment) 같은 데이터가 각기 다른 마이크로서비스에서 온다. 데이터는 고객별로 다르고 실시간으로 바뀐다. 물류센터가 일일 출고 한도에 닿으면 그 센터의 재고·배송일이 즉시 바뀌어야 한다. 모든 페이지가 서비스를 직접 부르면 모든 서비스가 상시 고가용이어야 하고, 공통 비즈니스 로직이 페이지마다 중복된다.

그래서 코어 서빙 레이어를 뒀다. 목표는 넷이다. 99.99% 가용성, 고처리량·저지연 읽기, 여러 도메인에서 집계된 데이터의 일관성과 최신성, 비즈니스 로직 통합. 구성은 네 겹이다.

1. 통합 NoSQL 저장소. 각 마이크로서비스가 갱신을 큐로 보내고 공용 NoSQL에 저장한다. 최종적 일관성. 한 번의 읽기로 모든 서비스의 데이터를 가져온다.
2. read-through 캐시. 저장소 대비 처리량 10배, 지연 1/3. 대신 캐시가 과거 데이터를 줄 수 있으므로 저장소 갱신 시 알림 큐로 신호를 보내 캐시를 무효화한다. 이것으로 저장소와 캐시가 분 단위로 99.99% 동일하다.
3. 실시간 캐시. 재고처럼 초 단위여야 하는 데이터는 분 단위로는 안 된다. 품절을 늦게 알면 결제 뒤 환불이다. 그래서 큐의 변경을 즉시 별도 실시간 캐시에 쓰고, 서빙 레이어가 두 캐시를 동시에 읽어 최신 쪽을 고른다.
4. 고가용성. 모든 I/O를 회로 차단기로 감싸 장애가 번지지 않게 하고, 매출과 직결된 홈·검색·주문 페이지를 CSP(핵심 서빙 경로) 클러스터로 분리한다. N-CSP 장애는 CSP에 안 닿고, CSP 장애 시 배포 없이 CSP 페이지를 N-CSP로 돌린다.

마지막으로 이 구조를 템플릿으로 만들어 주문·이츠·멤버 도메인이 설정만으로 자기 서빙 레이어를 만든다.

같은 곳: 읽기 표현을 따로 둔다

MCP에서 조회를 QueryDSL 읽기 모델로 뺀 이유, parity-pay에서 잔액 스냅샷을 둔 이유, 원문에서 NoSQL 통합 저장소를 둔 이유는 같다. 원본은 쓰기에 맞게 정규화돼 있고, 읽기는 조인 없이 한 번에 가져와야 빠르다. 원문은 여기에 “여러 서비스에 흩어진 원본”이라는 조건이 더해져, 읽기 모델이 성능 장치이면서 가용성 장치가 된다. 원본 서비스 하나가 죽어도 마지막으로 받은 값을 서빙할 수 있다.

monticker 23편의 100ms conflation도 같은 자리다. 틱을 전부 보내지 않고 100ms 안의 최신값만 보낸다. 원문의 실시간 캐시가 “최신 쪽을 고른다”고 한 것과 같은 판단이다. 시세와 재고는 이력이 아니라 현재 값이 중요한 데이터이고, 그런 데이터는 마지막 값만 남기는 것이 정합성이다.

원문이 더 나간 곳: 신선도를 데이터별로 나눈다

내가 하지 않은 것이 하나 있다. 원문은 신선도 요구를 데이터 종류별로 나눴다. 이미지·이름은 분 단위면 되고 재고는 초 단위여야 한다. 그래서 캐시가 둘이고, 같은 레이어가 둘을 읽어 최신을 고른다. 하나의 캐시로 전부를 초 단위로 맞추면 비용이 재고 기준으로 올라가고, 분 단위로 맞추면 재고가 틀린다.

parity-pay의 잔액 스냅샷은 하나의 신선도(트랜잭션 동기)다. 원장 전기와 같은 트랜잭션에서 갱신하므로 어긋남이 생기면 그것은 버그다. 원문의 구조는 어긋남을 정상 조건으로 두고(최종적 일관성) 어긋남의 크기를 데이터별로 다르게 허용한다. 결제 잔액에는 내 방식이 맞고 상품 페이지에는 원문 방식이 맞다. 어느 쪽이든 “어긋날 수 있는가, 얼마나”를 데이터마다 명시하는 것이 먼저다.

원문이 답하지 않는 것: 0.01%를 누가 세는가

“분 단위로 99.99% 동일”은 측정된 문장이다. 그런데 어떻게 쟀는지가 없다. 저장소와 캐시를 주기적으로 대조하는 검증기가 있어야 이 숫자가 나오고, 그 검증기는 캐시된 전체 키를 훑거나 샘플링해야 한다.

이 빈칸이 내가 가장 궁금한 부분인 이유는 parity-pay 4편 결함 G 때문이다. 원장과 스냅샷의 어긋남(INV-010)을 세는 지표가 스크레이프마다 원장 전체를 집계했고, 200만 건에서 4.5초가 되어 지표가 먼저 무너졌다. 어긋남을 세는 것 자체가 비용이고, 데이터가 늘수록 커진다. 원문의 규모에서 전수 대조는 불가능할 것이고, 샘플링이면 0.01%라는 숫자의 신뢰 구간이 있어야 한다. 그리고 어긋난 0.01%는 무엇이 되는가. 다음 무효화 신호까지 틀린 값을 서빙하는가, 검증기가 강제로 무효화하는가. 6편에서 “찾는 것과 고치는 것을 분리하고 고치는 쪽은 자동화하지 않는다”고 적었는데, 캐시 불일치는 고치는 쪽을 자동화해도 되는 드문 경우다. 원본이 진실이고 캐시는 언제든 다시 만들 수 있기 때문이다. Part 2가 이것을 다루기를 기대한다.

같은 곳: 핵심 경로를 따로 둔다

CSP/N-CSP 분리는 9편의 벌크헤드와 같은 논리를 클러스터 단위로 올린 것이다. 느린 것 때문에 잃는 것을 일부로 한정한다. 원문은 그 “일부”를 매출과 직결되지 않는 페이지로 정했고, 반대로 CSP가 죽으면 N-CSP로 돌린다는 양방향 fallback을 뒀다. 내가 재지 못한 것은 이 전환에 걸리는 시간이다. 23편에서 Kafka 정지 뒤 복구까지 45.7초였고 그중 15초가 재연결이었다. “배포 없이 동적으로” 돌린다는 원문의 전환이 몇 초인지가 CSP 설계의 실제 가치다.

가져갈 것

• 읽기 모델은 성능 장치이자 가용성 장치다. 원본이 죽어도 마지막 값을 서빙할 수 있다.
• 신선도는 데이터 종류마다 다르게 정한다. 하나의 캐시로 전부를 맞추면 가장 엄격한 데이터의 비용을 전부가 낸다.
• “99.99% 동일”에는 세는 방법이 따라와야 한다. 세는 비용은 데이터에 비례해 자라고, 지표가 먼저 무너질 수 있다.
• 핵심 경로의 분리는 클러스터 단위 벌크헤드다. 전환 시간이 그 설계의 실제 값이다.