데이터베이스 확장 Q&A — 트레이드오프 16선과 32문답

확장을 다루는 일이 어려운 이유는 개별 기법을 몰라서가 아니다. 파티셔닝도 알고 복제도 아는 상태에서, 이 서비스가 지금 무엇을 내주고 무엇을 받을지 정해야 하기 때문이다. 손실을 0으로 둘 것인가 응답을 빠르게 할 것인가, 샤딩을 지금 넣을 것인가 더 버틸 것인가 — 답이 하나로 고정되지 않는 자리들이다.

이 글은 앞 다섯 편이 세운 선택지들을 선택지 표 · 실패 모드 표 · 문답 세 형태로 다시 세운다. 확장 방식을 지금 결정해야 하는 상황, 그리고 이미 운영 중인 시스템에서 출처가 잡히지 않는 지연·불일치·데이터 소실을 추적하는 상황에서 쓸모가 있다.

오른쪽 열의 숫자를 더하면 28이고, 한 줄로 답할 수 없어 뒤에 따로 뺀 네 문항을 더하면 32다. 주제별로 묶고 개수를 배정한 것은 이 글의 편집이다 — 바탕이 된 자료는 번호만 차례로 매긴 한 장의 표였다.

선택지 16개 — 무엇을 얻고 무엇을 내주는가

열여섯 행을 확장의 축으로 갈라 보면 나누기 6행 · 복사하기 6행 · 합의 4행이다. 앞 여섯이 파티셔닝·인덱스·샤딩, 가운데 여섯이 토폴로지 셋과 동기화 강도 셋, 뒤 넷이 분산 트랜잭션 둘과 합의 알고리즘 둘이다. 이 6·6·4 배정은 이 글이 매긴 것이다.

「내주는 것」 열을 세로로 읽으면 한 행만 성격이 다르다. 나머지 열다섯 행이 내주는 것은 성능이거나 복잡도이거나 운영 부담이어서, 나중에 값을 더 치르면 되돌릴 수 있는 종류다. 샤딩 한 행만 되돌림 자체가 불가능하다는 것을 대가로 적는다. 뒤에 따로 뺀 네 문항 중 하나가 그 행의 도입 시점을 다룬다.

실패 모드 11가지 — 증상에서 대응으로

「대응」 열을 기준으로 열한 행을 가르면 앞 네 행과 뒤 일곱 행으로 갈린다. 앞 네 행의 대응에는 「키를 다시 고른다」·「전략을 다시 짠다」·「리샤딩한다」가 들어간다. 이미 확정된 설계를 되돌리는 작업이고, 셋째·넷째 행에서는 그 되돌림이 곧 리샤딩이다. 선택지 표에서 샤딩만 되돌릴 수 없다고 적혔던 것이 여기서 실제 청구서로 돌아온다.

뒤 일곱 행의 대응은 이미 자른 것을 다시 자르지 않는다. 설정을 바꾸거나, 경로·복제본을 하나 더 두거나, 보정 장치를 덧대는 선에서 끝난다. 4와 7로 가른 이 배정은 이 글이 매긴 것이다.

나누기 — 파티셔닝과 샤딩 8문답

여덟 문항은 1·2·5로 갈린다. 첫 문항이 경계 자체를 정의하고, 둘째와 셋째가 같은 인스턴스 안에서 끝나는 문제이며, 나머지 다섯이 경계를 넘은 뒤의 문제다. 경계를 넘는 순간 질문의 성격이 「어떻게 빠르게 할까」에서 「무엇을 포기하고 시작할까」로 바뀐다는 것이 첫 문항의 답이 말하는 바다. 분할 전략을 고르는 기준과 인덱스를 함께 자를지의 판단, 그리고 파티셔닝이 샤딩으로 넘어가는 경계는 파티셔닝 전략과 샤딩에 있다.

복사하기 — 복제 9문답

둘째 문항의 답에서 뒤집히는 조건 하나가 이 묶음 전체의 요점이다. 반동기를 켜 두었다는 사실이 손실 0을 뜻하지 않는다 — 강등이 일어난 그 순간의 쓰기는 비동기와 똑같은 위험을 진다. 「반동기로 설정했다」와 「지금 반동기로 동작하고 있다」가 다른 문장이라는 뜻이고, 그래서 여섯째 실패 모드의 대응에 지연 모니터링 알람이 들어간다. 토폴로지 셋의 구조와 지연이 만드는 이상 현상은 복제에 있다.

갈라짐 — 분산 시스템 5문답

이 다섯은 앞의 두 묶음과 층이 다르다. 나누기와 복사하기가 「어떻게 할 것인가」를 묻는다면, 여기는 먼저 무엇이 원리적으로 불가능한가를 확정하고, 그 불가능성을 인정한 채 무엇을 덧대어 버틸 것인가를 잇는다. 앞의 세 문항이 앞쪽을, 뒤의 두 문항이 뒤쪽을 맡는다. 분할은 반드시 일어나고 죽음은 느림과 구별되지 않는다 — 이 두 사실이 다음 묶음의 프로토콜들이 왜 그런 모양인지를 설명한다. 장애 모델과 감지·선출, 그리고 CAP와 PACELC의 전체 맥락은 분산 시스템과 CAP에 있다.

합의 — 분산 트랜잭션과 합의 6문답

여섯 문항이 두 종류로 갈린다. 앞 셋은 여러 자원에 걸친 하나의 작업을 어떻게 끝낼 것인가의 문제이고, 뒤 셋은 여러 노드가 하나의 값에 어떻게 동의할 것인가의 문제다. 둘은 자주 뭉뚱그려지지만 실패했을 때 남는 것이 다르다 — 앞쪽이 실패하면 데이터가 어중간한 상태로 남고, 뒤쪽이 실패하면 시스템이 결정을 내리지 못한 채 멈춘다. 2PC의 구조와 Saga, 합의 알고리즘들의 비교는 분산 트랜잭션과 합의에 있다.

Q. 방금 쓴 글이 안 보인다는 제보가 올라왔다

이것을 버그가 아니라 구조의 알려진 성질로 규정하는 데서 시작한다. 읽기 부하를 나누려고 팔로워에서 읽게 만든 순간, 비동기 복제 위에서 Read-Your-Writes 위반은 예외가 아니라 정상 동작이다. 원인을 애플리케이션 코드에서 찾기 시작하면 고칠 자리를 영영 못 찾는다.

그다음은 범위를 좁히는 일이다. 모든 읽기를 리더로 되돌리면 부하 분산이 통째로 사라지므로, 쓰기 직후 일정 시간 동안 그 사용자의 읽기만 리더로 보낸다. 세션에 마지막 쓰기 시각을 남기고, 그 시점부터 정해진 구간 안이면 리더로 라우팅하는 방식이다.

셋째 행은 둘째 행의 대체재가 아니다. 팔로워를 고정해도 그 팔로워가 자기 쓰기를 아직 못 받았을 수 있으므로 RYW는 여전히 깨진다. 팔로워 라우팅을 유지해야 할 때 최소한을 건지는 선택이지, 같은 문제를 푸는 다른 방법이 아니다.

마지막으로 지표를 건다. 복제 지연에 알람이 없으면 같은 문제가 다음번에는 더 큰 규모로 돌아온다. 근본 대책은 라우팅 코드가 아니라 지연을 관측 가능한 값으로 만들어 두는 쪽에 있다.

Q. 주문과 재고가 각각 DB를 가진 MSA에서 정합성을 어떻게 세우나

2PC는 후보에서 뺀다. 코디네이터가 1단계 뒤에 죽으면 두 서비스가 락을 쥔 채 무한히 기다리고, 이 블로킹은 한 트랜잭션의 실패로 끝나지 않는다. 대기가 쌓이면서 서비스 전체의 가용성 사고로 번진다.

남는 선택은 Saga다. 「주문 생성(PENDING) → 재고 차감 → 주문 확정」 순서로 로컬 트랜잭션을 잇고, 재고 차감이 실패하면 주문 취소 보상 트랜잭션을 돌린다.

도식에서 한 줄만 정상 흐름이고 나머지 갈래는 전부 실패 경로다.

대가는 분명하게 적어 두는 편이 낫다. 격리성이 없다. PENDING 주문이라는 중간 상태가 외부에 노출되므로, 그 상태를 화면과 정책이 이름 붙여 다뤄야 한다.

그리고 실전에서 사고가 나는 자리는 정상 흐름이 아니라 보상의 멱등성이다. 정상 흐름은 개발 중에 수없이 밟아 보지만 보상 경로는 장애가 나야 처음 밟히고, 그때 재시도가 겹치면 두 번 실행된다. 표의 셋째 행과 넷째 행이 하나로 묶여 있는 이유다.

Q. 「CAP에서 CA를 선택했다」는 설명은 어떻게 읽히나

그 문장은 성립하지 않는다. 네트워크 분할은 설계자가 고를 수 있는 항목이 아니라, 분산 시스템이라면 반드시 일어나는 사실이기 때문이다.

따라서 CA를 골랐다는 말은 둘 중 하나를 뜻한다. 실제로는 분산 시스템이 아니거나(단일 노드 RDB), 분할이 일어났을 때 어떻게 동작할지를 아직 정하지 않았다는 뜻이다. 뒤쪽이 훨씬 흔하고 훨씬 위험하다.

그래서 확인할 것은 CAP 분류명이 아니라 구체적 동작이다.

네 행이 위에서 아래로 좁혀 들어간다. 분류를 동작으로 바꾸고, 그 동작의 규칙을 특정하고, 규칙의 결과를 비즈니스 언어로 옮기고, 끝으로 분할이 없는 평상시까지 질문을 넓힌다. 넷째 행을 빼면 거의 일어나지 않는 사건만 이야기하다 끝나는데, 사용자 체감을 만드는 것은 매 요청 붙는 지연 쪽이다.

Q. 서비스 초기에 샤딩을 미리 넣어 두는 것은 어떤가

권할 만하지 않다. 이유는 성능이 아니라 되돌릴 수 없다는 성질이다. 샤딩에는 롤백이 없고, 샤드 키를 바꾸려면 컬렉션 전체를 리샤딩해야 한다. 데이터가 적을 때 잘못 고른 샤드 키는 데이터가 많아진 뒤에 가장 비싼 부채가 되어 돌아온다.

게다가 초기에는 샤드 키를 잘 고를 정보 자체가 없다. 카디널리티도 데이터 분포도 쿼리 패턴도 실제 트래픽을 봐야 알 수 있는데, 그 전에 결정을 고정하는 셈이다.

세 단계를 이 순서로 두는 근거는 오른쪽 열이다. 되돌릴 수 있는 수단을 먼저 다 써 보고, 그것으로 부족하다는 사실이 데이터로 확인된 다음에 되돌릴 수 없는 수단으로 넘어간다.

다만 미리 해 둘 것이 하나 있다. 샤드 키가 될 만한 컬럼을 애플리케이션이 항상 쿼리 조건에 싣도록 접근 경로를 정리해 두는 일이다. 지금 하면 비용이 들지 않고, 나중에 샤딩할 때 가장 큰 장벽을 미리 치워 둔다. 크로스 샤드 브로드캐스트가 다섯째 실패 모드로 올라와 있는 것이 이 준비를 건너뛴 결과다.

정리

이 시리즈 여섯 편을 관통하는 갈림은 셋이다.

세 번째가 가장 늦게 손에 잡힌다. 앞의 둘은 선택지가 표에 나열되어 있어 고르기만 하면 되지만, 세 번째는 문제를 푸는 대신 문제가 생기지 않도록 경계를 다시 긋는 일이라 기술 목록 어디에도 항목으로 적혀 있지 않다.

그래서 확장 설계를 마무리할 때 마지막으로 확인할 것은 「이 구조가 얼마나 확장되는가」가 아니라 **「지금 되돌릴 수 없는 것을 무엇으로 정했고, 그 근거가 실제 데이터인가」**다. 근거가 예측뿐이라면 그 결정은 아직 이른 것이고, 미룰 수 있다면 미루는 편이 거의 항상 싸다.