데이터베이스 확장 Q&A — 트레이드오프 16선과 32문답
선택지 열여섯 개가 각각 무엇을 얻고 무엇을 내주는지, 실패 모드 열한 가지가 어떤 증상으로 드러나고 무엇으로 되받는지를 표로 모았다. 파티셔닝과 샤딩, 복제, 분산 시스템, 합의에 걸친 서른두 개 문답은 먼저 답을 내고 근거를 뒤에 붙인다.
태그
8편
선택지 열여섯 개가 각각 무엇을 얻고 무엇을 내주는지, 실패 모드 열한 가지가 어떤 증상으로 드러나고 무엇으로 되받는지를 표로 모았다. 파티셔닝과 샤딩, 복제, 분산 시스템, 합의에 걸친 서른두 개 문답은 먼저 답을 내고 근거를 뒤에 붙인다.
같은 데이터를 여러 벌 두면 가용성과 읽기 처리량을 얻지만, 그 순간부터 복제본끼리 값이 다를 수 있다는 문제를 떠안는다. 토폴로지 세 가지가 그 문제를 어떻게 처리하는지, 동기·반동기·비동기가 무엇을 담보로 속도를 사는지, 복제 지연과 장애가 무엇을 사라지게 하는지를 정리한다.
여러 머신에 걸친 순간, 예산이나 기술로 밀어낼 수 없는 제약이 붙는다. 이 글은 분산 시스템이 어떤 장애를 상정하고 출발하는지, 완벽한 합의가 왜 불가능한지, 네트워크가 끊어졌을 때와 멀쩡할 때 각각 무엇을 내주게 되는지, 그리고 그 한계 위에서 장애 감지와 리더 선출과 결함 격리를 어떻게 배치하는지를 다룬다.
노드가 여러 대로 늘어난 순간 커밋은 선언이 아니라 합의가 된다. 이 글은 2PC가 코디네이터 장애에서 정확히 무엇을 잃는지, 3PC·Calvin·Spanner와 Saga가 그 대가를 각각 어디로 옮기는지, Paxos·Raft·PBFT가 견디는 장애 모델이 어떻게 다른지, 그리고 분산 원장이 데이터베이스와 갈라지는 지점을 정리한다.
서버를 두 대로 늘리는 순간 세 가지가 동시에 깨진다. 트래픽 분배, 로그인 세션, 그리고 서버 간 메시지 전파다. 이 글은 앞의 둘이 왜 일반적인 문제이고 마지막 하나만이 WebSocket 고유의 난점인지, 그리고 브로커를 넣어도 남는 것이 무엇인지를 다룬다.
실시간 채팅 시리즈가 내린 판단을 세 벌로 다시 짠다. 아직 방식을 고르는 중이라면 선택지 표를, 이미 돌아가는 서비스에서 메시지가 안 오거나 연결이 끊긴다면 증상에서 출발하는 진단 표를, 근거를 설명해야 한다면 25문답을 쓴다.
데이터가 커졌을 때 손댈 수 있는 축은 나누는 것과 복사하는 것 둘뿐이다. 이 글은 그 지도를 먼저 그리고, 파티셔닝의 값어치가 조회 성능보다 운영 작업 쪽에서 나온다는 것, 그리고 수직과 수평이 각각 무엇을 노리는 분할인지를 다룬다.
브로커를 끼워 넣으면 장애가 거꾸로 번지는 경로는 사라지지만 그 대가로 지연과 중복과 순서 뒤집힘이 청구된다. 토픽과 파티션이 무엇을 정하는지, 컨슈머를 늘려도 처리량이 늘지 않는 구간이 왜 생기는지, 오프셋을 언제 커밋하느냐가 전달 보장을 어떻게 바꾸는지를 차례로 본다. 이어서 순서가 지켜지는 범위와 중복을 견디는 도메인 설계, 끝내 실패하는 한 건을 줄 밖으로 빼내는 장치까지 다룬다.