복제·파티셔닝·샤딩

데이터가 커지면 무엇을 여러 개로 만들어야 할까

온라인 주문이 늘어 한 데이터베이스가 버거워졌다고 하자. 운영자는 서버를 여러 대 두자고 말하지만, 같은 주문을 여러 곳에 복사할지, 주문을 여러 조각으로 나눌지, 그 조각을 여러 서버에 흩어 놓을지를 먼저 정하지 않으면 “여러 대”라는 말만으로는 설계가 되지 않는다. 세 선택은 데이터의 개수와 위치를 서로 다르게 바꾸기 때문이다.

복제·파티셔닝·샤딩은 서로를 대신하는 세 제품명이 아니다. 복제는 사본을 만들어 장애대응과 읽기 분산의 기반을 마련하고, 파티셔닝은 큰 데이터 집합을 관리 가능한 조각으로 나누며, 샤딩은 조각을 여러 노드에 배치해 수평 확장을 꾀한다. 실제 설계는 세 전략을 함께 쓸 수 있지만, 그때 라우팅·일관성·재균형·장애조치와 운영 가시성이라는 비용도 함께 커진다.

앞 절의 조각을 사본·노드 배치와 비교한다

복제는 같은 데이터를 여러 벌 두는 것이고, 샤딩은 데이터 조각을 여러 노드에 나누어 맡기는 것이다. 여기서는 앞 절에서 배운 조각과 복제의 사본·샤딩의 노드 배치를 같은 그림에 놓고 비교한다.

주문 1번부터 100번까지 있다고 하자. 복제하면 노드 A와 B가 원칙적으로 1~100번 주문의 사본을 각각 가진다. 파티셔닝하면 1~50번과 51~100번처럼 하나의 논리적 주문 테이블을 작은 물리 조각으로 나눈다. 샤딩하면 그 조각을 노드 A와 B가 나누어 가진다. 따라서 “복제했으니 데이터도 반씩 나뉜다”거나 “파티션을 만들었으니 자동으로 여러 서버에 퍼진다”는 설명은 틀리다.

앞 절 물리 DB 설계·인덱스·파티션의 저장 분할은 한 논리 표의 행을 규칙에 따라 서로 다른 저장 부분에 두는 방식이었으며, 그것만으로 서버가 분산되지는 않았다. 이제 같은 조각을 어디에 배치하고 그 사본을 몇 벌 유지할지 분리해 본다.

정확히 말하면

복제(replication)는 같은 데이터셋의 사본을 둘 이상의 구성원에 유지하는 배치 전략이다. 사본이 존재한다고 해서 어느 장애에서도 서비스가 멈추지 않거나 데이터가 전혀 손실되지 않는 것은 아니다. 쓰기를 어느 구성원이 받고, 다른 사본이 언제 따라오며, 장애 뒤 어느 사본을 새 기준으로 삼을지를 별도로 정해야 한다.

테이블 파티셔닝의 정식 정의·분할키·가지치기는 앞 절 물리 DB 설계·인덱스·파티션의 설명을 사용하고, 여기서는 그 조각의 노드 배치와 사본 수를 비교한다. 데이터 조각인 파티션은 일관성·응답 지속성·네트워크 분할에서 배운 노드 사이 통신 단절인 네트워크 분할과 다른 뜻이다.

샤딩(sharding)은 데이터셋과 부하를 여러 머신의 부분집합으로 나누는 수평 확장 전략이다. 이 교재에서는 각 노드가 맡은 데이터 조각을 샤드(shard), 어떤 조각으로 보낼지를 결정하는 값을 샤드 키(shard key)라고 부른다. 제품마다 partition과 shard라는 말을 겹쳐 쓰기도 하므로, 시험 답안에서는 논리 데이터가 몇 조각인지, 그 조각이 몇 노드에 놓이는지, 사본이 몇 개인지를 함께 적어 의미를 고정한다.

한 데이터셋이 세 방식으로 놓이는 모습

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

D={1,2,3,4,5,6}을 P1={1,2,3}, P2={4,5,6}로 나누어 각 샤드에 배치하고 샤드별 사본을 두는 조합 예다. 분할·노드 배치·복제는 서로 다른 선택이며 이 그림이 모든 경우에 셋을 강제하지 않는다. 전체 D를 두 노드에 각각 복사하는 단순 복제와 구분한다.

이 그림에서 읽어야 할 결론은 복제 = 중복, 파티셔닝 = 조각, 샤딩 = 조각의 노드 분산이다. 마지막 구조처럼 샤딩과 복제를 조합하면 각 노드는 전체 데이터가 아니라 자신이 맡은 조각의 사본을 유지할 수 있다. 이 구분을 먼저 잡아야 “노드 하나가 고장 났을 때 데이터 조각은 남는가?”와 “쓰기 부하가 여러 노드로 나뉘는가?”를 서로 다른 질문으로 다룰 수 있다.

먼저 알아둘 것

아래 복습은 새 이론이 아니라 앞 장의 담당 절에서 배운 개념을 이 절의 데이터 배치 문제에 연결한다. 낯선 개념이 있으면 표시된 앞 절을 먼저 가볍게 읽고 돌아온다.

노드와 실패

시간초과·재시도·멱등성과 부분실패에서 분산 노드는 독립적으로 실행되는 계산 단위, 부분실패는 그중 일부만 고장 난 상태라고 배웠다. 이어 일관성·응답 지속성·네트워크 분할에서 네트워크 분할은 일부 노드 집합 사이에 메시지가 전달되지 않는 통신 장애라고 배웠다. 이 절에서는 사본과 샤드가 이런 실패 뒤에도 어떤 데이터를 가지고 있는지 확인한다.

테이블·키·인덱스

테이블·행·열·키·관계에서 기본키는 행을 유일하게 식별하고 외래키는 다른 행을 참조하는 역할을 맡았다. 이어 DBMS·질의·인덱스에서 인덱스는 필요한 행을 찾는 접근 경로를 돕는 구조라고 배웠다. 조각을 정하는 분할키·샤드 키는 이런 식별·참조와 목적이 다르며, 같은 배치키를 가진 여러 행이 한 조각에 놓일 수 있으므로 항상 행의 유일키인 것은 아니다.

트랜잭션과 일관성

트랜잭션의 네 성질(ACID)에서 트랜잭션은 함께 성공하거나 실패해야 할 작업의 묶음이고 ACID는 그 작업에 요구되는 네 가지 보장이라고 배웠다. 일관성·응답 지속성·네트워크 분할에서 일관성은 여러 사본이 관찰할 값과 순서에 관한 보장이라고 배웠다. 이 절에서는 복제 지연과 여러 샤드가 그 보장 범위를 어떻게 바꾸는지 본다.

가용성과 신뢰성

성능·가용성·신뢰성·복구성·확장성에서 가용성은 필요할 때 서비스를 쓸 수 있는 정도, 신뢰성은 일정 시간 고장 없이 동작할 가능성이라고 배웠다. 사본을 늘렸다는 사실만으로 두 속성이 자동 보장되지는 않는다. 이 절에서는 장애조치 조건과 장애 뒤 데이터 검증까지 함께 본다.

지연시간·대역폭·처리량

지연·대역폭·처리량·혼잡에서 지연시간은 요청이 시작해 결과를 얻기까지 걸린 시간, 대역폭은 경로가 단위시간에 실어 나를 수 있는 최대 데이터량, 처리량은 실제로 단위시간에 처리한 양이라고 배웠다. 데이터 조각을 늘리면 이 세 값이 서로 다르게 움직일 수 있다. 이 절에서는 평균값 하나가 아니라 샤드와 사본별 상태를 관찰한다.

시간초과·재시도·멱등성

시간초과·재시도·멱등성과 부분실패에서 시간초과는 기다림의 상한, 재시도는 요청을 다시 보내는 동작이라고 배웠다. 멱등성은 같은 요청을 반복해도 의도하지 않은 중복 효과가 생기지 않게 하는 성질이다. 이 절에서는 역할변경과 재시도 뒤 주문이 중복 처리되지 않는지 확인한다.

이미 배운 분할 규칙을 노드 배치에 적용한다

앞 절 물리 DB 설계·인덱스·파티션에서는 분할키의 값과 규칙이 각 행을 어느 저장 부분에 둘지 정한다고 배웠다. 기간 조건으로 답이 없는 조각은 읽을 대상에서 제외할 수 있지만, 날짜와 무관한 주문번호 조회나 보관·유일성 요구도 함께 확인해야 했다. 이 절에서는 이렇게 정한 데이터 조각을 어느 노드가 맡고 그 조각의 사본은 어디에 남는지로 질문을 이어 간다.

어떻게 작동하는가 ② 복제

MongoDB 8.3의 복제 집합(replica set)은 같은 데이터셋의 사본을 가진 구성원들의 묶음이다. 대표 흐름에서 주 구성원(primary)은 변경을 받고 변경 작업의 기록인 oplog(operation log, 작업 로그)를 남기며, 보조 구성원(secondary)은 그 기록을 비동기로 재생한다. 주 구성원이 실패하면 남은 구성원이 선거를 거쳐 새 주 구성원을 정할 수 있다.

비동기라는 말은 보조 사본의 반영이 주 사본의 변경 완료와 정확히 같은 순간에 끝나지 않을 수 있다는 뜻이다. 그 간격이 복제 지연(replication lag)이고, 지연 중 보조 사본에서 읽으면 주 사본보다 오래된 값을 볼 수 있다. 장애 시 보조 사본이 관찰했던 일부 쓰기가 이후 되돌려질 수도 있으므로, 어디서 읽을지와 쓰기를 몇 단계까지 확인할지를 업무가 요구하는 최신성·확정성에 맞춰 함께 정해야 한다. 구체 보장 수준은 제품 설정 문서를 따로 확인하지 않고 이 절에서 단정하지 않는다.

PostgreSQL 18의 논리 복제는 발행·구독 모델의 다른 예다. 처음에는 데이터 스냅샷을 복사하고 이후 변경을 계속 전달한다. 한 구독 안에서 변경의 트랜잭션 일관성을 유지하지만, 이를 여러 구독 사이의 전역 순서 보장으로 확대하면 안 된다. ACID는 정해진 트랜잭션 경계의 보장이므로 여러 구독이나 노드 전체의 보장으로 자동 확대되지 않는다. 네트워크 분할이나 노드 장애 동안 어느 변경을 확정할지도 별도 정책이 필요하다. 또한 스키마와 데이터 정의 언어(Data Definition Language, DDL) 변경, 시퀀스 상태와 대형 객체 등이 자동 복제되지 않는 제한을 별도로 처리해야 한다.

어떻게 작동하는가 ③ 샤딩

샤딩의 핵심 상태는 샤드 키 규칙, 키 구간과 샤드의 대응, 각 샤드의 현재 부하다. 요청을 받은 라우터는 질의에 샤드 키가 있는지 확인하고, 대응 규칙으로 목표 샤드를 고른다. 샤드 키를 포함하지 못한 질의는 여러 샤드에 흩어져 실행될 수 있다. 이것이 항상 금지되거나 항상 느리다는 뜻은 아니지만, 대상 샤드가 늘수록 네트워크 요청과 결과 합치기의 범위도 넓어진다.

MongoDB 8.3의 샤딩 구성에서는 각 샤드가 데이터의 부분집합을 보유하며, 각 샤드는 복제 집합으로 배포해야 한다. 일반 개념에서 샤딩과 복제는 조각의 노드 배치와 사본 수라는 서로 다른 축이지만, 이 제품의 배포 구성은 둘의 조합을 요구한다. 따라서 “개념의 축이 다르다”는 설명을 “standalone mongod를 그대로 MongoDB 샤드로 배포해도 된다”는 제품 설정 허용으로 읽으면 안 된다. 샤딩은 전체 데이터를 나누어 쓰기·저장 부하를 분산하고, 복제는 각 조각의 사본을 유지해 해당 조각의 장애대응 기반을 마련한다.

샤드 키는 데이터 분포와 질의 경로를 동시에 바꾼다. 범위 방식은 인접 키의 지역성을 살릴 수 있어 범위 질의에 유리할 수 있지만, 새 데이터가 한쪽 끝으로 몰리면 특정 샤드가 뜨거워지는 핫 샤드(hot shard)가 될 수 있다. 해시 방식은 키를 더 고르게 흩을 수 있지만 인접 값이 다른 샤드로 갈 수 있어 범위 지역성이 약해질 수 있다. 데이터 분포와 질의 패턴을 보지 않고 어느 한쪽을 항상 우월하다고 고르면 안 된다.

작은 배치 계산으로 흐름을 끝까지 읽어 보자. 숫자 고객번호를 2로 나눈 나머지가 0이면 A, 1이면 B로 보낸다는 자체 교육 규칙을 가정한다. 실제 MongoDB의 해시 함수나 분포 보장이 아니라 입력→계산값→샤드의 연결을 보여 주는 단순 모형이다. 고객 101의 주문은 101=2×50+1이므로 B에, 102의 주문은 102=2×51+0이므로 A에, 103의 주문은 B에 놓인다. 고객 101의 주문내역을 묻는 읽기도 같은 계산으로 B에 보내지만 고객번호 없이 모든 주문을 집계하려면 A와 B의 결과를 함께 받아야 한다.

노드를 추가하는 일과 배치 규칙을 바꾸는 일은 다르다. 이 자체 모형에서 나머지의 제수를 2에서 3으로 바꾸면 새 키뿐 아니라 기존 고객의 목표 샤드도 바뀔 수 있다. 라우터만 새 계산으로 바꾸면 기존 주문이 옛 샤드에 남아 있는데 새 샤드에서 찾게 된다. 변경 대상 데이터, 이동 중 쓰기 처리, 배치 정보·캐시 갱신과 전환 뒤 검증을 하나의 이전 절차로 정해야 한다. 실제 MongoDB의 해시 배치나 재균형은 이 단순 나머지 계산으로 구현된다는 뜻이 아니다.

조건을 바꾸어 판단하기. 같은 나머지 규칙에서 고객 104의 주문은 어느 샤드로 가는가? 전체 쓰기의 90%가 고객 101 한 명에게서 온다면 요청량도 A/B로 반씩 나뉘는가? 배치 계산과 부하 계산을 각각 적어 본다.

키 배치와 요청량을 나누어 교정하기

고객 104는 104=2×52+0이므로 A다. 그러나 고객번호 101은 계속 B로 가므로 그 고객의 90% 쓰기는 B에 몰린다. A가 한가하다는 사실이 B의 부하를 없애지 못한다. 해시 배치이면 항상 균등이라는 답은 키 종류의 배치와 키별 요청량을 같은 양으로 센 것이다. 핫 샤드가 생기는 조건으로 돌아가 고객별 요청량과 배치 결과를 함께 센다. 고객의 주문을 같은 경로로 모으는 이득과 그 고객의 부하를 한 샤드가 맡는 비용을 함께 판단한다.

쓰기·읽기에서 데이터흐름과 제어흐름

다음은 샤드마다 복제 집합을 둔 MongoDB형 구성을 이해하기 위해 새로 만든 단순 흐름도다. 실선은 요청·변경값의 데이터흐름이고, 점선은 배치·확인 판단의 제어 입력이다. 장애조치의 선거·역할 변경은 뒤의 상태전이에서 구분한다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

실선은 요청·변경 기록 전달, 점선은 배치·역할 판단 입력이다. 샤드 키 K로 A를 선택하면 주 구성원이 변경을 받고 A의 보조 1·2가 기록을 따라간다. 실제 성공 확인 수준과 장애 뒤 확정성은 별도 업무 계약이다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

실선은 요청·결과 전달, 점선은 읽기 허용 판단 입력이다. K로 목표 샤드 A를 찾더라도 사본 반영 상태와 읽기 조건을 확인하여 허용된 구성원에서 읽는다. 이름이 주 구성원이라는 이유로 반영 조건을 생략하지 않는다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

샤드 키가 없으면 A·B·그 밖의 대상 샤드로 요청을 분산하고 결과를 합친다. 추가 샤드는 같은 역할의 묶음으로 표시했다. 대상이 늘면 요청과 결합 범위도 늘지만 항상 금지되거나 항상 느리다는 뜻은 아니다.

주 구성원이 실패하면 남은 구성원의 선거·역할 변경으로 새 주 구성원을 정한다. 이어지는 상태전이 그림처럼 바뀐 역할과 반영 상태를 다시 확인한다.

사본이 남았다는 사실과 선거를 완료할 수 있다는 사실은 다르다. MongoDB의 선거에는 투표 구성원의 과반과 후보 자격·반영 상태 같은 조건이 필요하다. 데이터 사본을 가진 A·B·C가 각각 한 표를 갖는 구성이라면 과반은 2표다. A가 격리되고 B·C가 서로 통신하면 그쪽은 과반 조건을 충족할 수 있지만, B만 남으면 사본을 읽을 가능성과 별개로 새 주를 선출하는 과반을 얻지 못한다. 선거가 성공하기 전에는 정상 쓰기를 재개할 수 없다. 투표하지 않는 데이터 사본도 있고, 데이터 사본 없이 투표하는 중재자도 있으므로 실제 선거에서는 사본 수를 그대로 표 수로 세지 않는다. 이 제품의 조건을 모든 복제 방식의 공통 선거 규칙으로 확대하지 않는다.

정상조건은 라우터가 키와 배치 정보를 바르게 보고, 주 구성원이 변경을 기록하며, 보조 구성원이 그 변경을 따라가고, 읽기 위치와 쓰기 확인 수준이 업무 요구와 맞는 상태다. 보조 사본이 아직 따라오지 않았는데 최신값이 필요한 읽기를 보내면 오래된 결과가 생길 수 있다. 장애조치가 일어났다는 사실만으로 무중단·무손실을 단정하지 않고, 지연과 되돌림 가능성을 운영 판단에 포함한다.

같은 축으로 비교해야 선택할 수 있다

표의 핵심은 세 전략의 “장단점”을 한 줄씩 나열하는 데 그치지 않는 것이다. 복제는 동일 조각의 사본 수, 파티셔닝은 논리 데이터의 조각 수, 샤딩은 조각을 맡는 노드 수라는 서로 다른 축을 조절한다. 한 전략의 이점이 다른 전략의 목적을 자동으로 달성하지 않으므로, 실제 병목과 실패 요구를 먼저 적은 뒤 조합한다.

배치 키와 복제 확인시점의 선택

조회형 또는 디렉터리 기반 샤딩은 샤드 키 → 데이터가 있는 샤드의 대응표를 따로 두고 그 표를 조회해 요청을 보낸다. 키를 바로 물리 파티션에 연결할 수도 있고, 키 → 가상 샤드 → 물리 파티션의 두 단계로 나눌 수도 있다. 두 단계 방식은 가상 샤드가 가리키는 물리 위치만 바꾸면 애플리케이션 코드를 고치지 않고도 재배치할 수 있다는 장점이 있다. 그 대신 요청마다 위치를 알아내는 비용이 생기며, 데이터를 옮긴 뒤 대응표와 이를 저장한 캐시가 같은 새 위치를 가리키도록 갱신해야 한다. 이 설명은 일반 패턴의 구조이며 특정 제품의 무중단 재배치나 캐시 일관성을 보장하지 않는다.

복제는 응답시점으로도 비교할 수 있다. 이해를 위해, 쓰기 성공을 돌려주기 전에 필요한 사본의 확인을 기다리는 쪽을 동기식 경계, 성공을 돌려준 뒤 다른 사본이 따라오는 쪽을 비동기식 경계라고 하자. 비동기식은 사본이 뒤따르는 동안 복제 지연과 오래된 읽기가 생길 수 있다. 반대쪽은 무엇을 몇 사본까지 확인해야 성공인지가 제품과 설정마다 다르므로, 이 장은 특정 제품의 대기시간·무손실 보장을 단정하지 않는다. 답안에서는 업무 일관성 요구에 맞는 읽기 위치·쓰기 확인 수준과 그 조건을 확인하지 못했을 때의 동작을 함께 쓴다. 아래 결제 조회 예처럼 실제 요청의 반영 여부를 확인하는 절차까지 보여 주되, 제품별 설정의 보장 범위는 별도로 검증한다.

무엇을 얻고 무엇을 치르는가

사본을 늘리면 한 구성원 실패 뒤 다른 사본을 사용할 기반과 읽기 위치 선택지가 생긴다. 그러나 사본마다 변경을 전달하고 어느 값이 확정됐는지 판단해야 하므로 복제 지연·오래된 읽기·되돌림과 장애조치 복잡도가 생긴다. “가용성 향상”이라는 한 줄 뒤에 어떤 실패에서, 어느 사본을, 어떤 최신성 조건으로 읽고 쓸지가 반드시 따라야 한다.

현재 사본은 과거 상태를 보존하는 백업과 목적이 다르다. 잘못된 주문 삭제가 정상 변경으로 기록되어 모든 즉시 반영 사본에 전달되면, 사본을 바꾸는 것만으로 삭제 전 주문이 되살아나지 않는다. 장애 뒤 현재 사본을 계속 쓰는 절차와, 삭제 전 상태를 되찾는 백업·시점 복구 절차를 따로 설계한다. 예를 들어 PostgreSQL의 시점 복구는 베이스 백업과 필요한 연속 WAL 보관이 있어야 하며 원하는 시점까지 재생한다. 복제 사본만 있다는 이유로 그 과거 복원 경로가 준비됐다고 단정하지 않는다.

조각을 늘리면 한 번에 살필 데이터와 유지보수 범위를 줄일 수 있다. 그러나 질의가 경계와 맞지 않으면 여러 조각을 살펴야 하고, 파티션·샤드의 수와 위치를 관리하는 상태가 늘어난다. 샤딩은 저장과 부하를 여러 노드로 나눌 수 있지만, 키 편중·다중 샤드 질의·재균형·노드 장애라는 분산 운영비용을 만든다.

따라서 판단은 성능 대 안정성처럼 한 축으로 끝나지 않는다. 가용성, 읽기확장, 쓰기확장, 데이터 지역성, 일관성, 복구 가능성, 운영복잡도를 같은 요구조건 아래 함께 평가한다. 특정 방식의 장점을 얻더라도 운영팀이 배치 상태와 지연을 관찰하고 장애 뒤 결과를 검증할 수 없다면 실제 서비스 품질로 이어지지 않는다.

선택은 병목과 업무질문에서 시작한다

1. 현재 한계를 분리한다. 저장용량, 쓰기처리량, 읽기부하, 장애대응, 유지보수 중 무엇이 문제인지 적는다.
2. 주요 접근경로를 적는다. 어떤 키로 단건을 찾고 어떤 범위를 모으며, 어느 요청이 최신값을 요구하는지 적는다.
3. 데이터 조각 규칙을 고른다. 경계와 질의가 맞으면 파티셔닝을, 여러 노드에 조각을 나눠야 하면 샤딩을 검토한다. 범위와 해시는 분포와 지역성의 교환을 실제 데이터로 확인한다.
4. 사본과 확인 수준을 정한다. 각 조각의 장애대응 필요, 읽기 위치, 허용 가능한 지연과 되돌림 가능성을 업무 요구에 연결한다.
5. 운영 가능한지 검증한다. 라우팅 정확성, 조각별 부하, 복제 지연, 장애조치, 충돌, 재균형을 관찰·복구할 수 있는지 확인한다.

이 순서를 거꾸로 하면 제품 기능을 먼저 켠 뒤 병목이 그대로 남는 일이 생긴다. 예를 들어 읽기부하가 문제인데 샤딩부터 하면 라우팅과 재균형만 늘 수 있고, 단일 노드의 쓰기한계가 문제인데 동일 데이터를 복제하기만 하면 쓰기 경로의 병목이 자동으로 나뉘지 않는다. 채택 이유는 “분산이 좋아서”가 아니라 어떤 한계를 어떤 배치 규칙으로 바꾸고, 새로 생긴 실패를 어떻게 통제하는가로 쓴다.

어디서 실패하는가

복제 지연과 오래된 읽기는 보조 사본이 아직 변경을 반영하지 못했는데 그 사본에서 최신값이 필요한 읽기를 수행할 때 나타난다. 징후는 사본별 값·반영시각 차이이고, 영향은 방금 바꾼 주문상태가 이전 값으로 보이는 것이다. 읽기 위치와 쓰기 확인 수준을 업무 최신성 요구에 맞추고 복제 지연을 관찰한다.

충돌하거나 되돌려지는 쓰기는 장애·역할변경 중 서로 다른 쓰기 이력이 생기거나, 보조 사본에서 본 변경이 새 기준 이력에 남지 않을 때 문제가 된다. 중복 재시도까지 겹치면 의도하지 않은 주문이 생길 수 있다. 변경의 확정 기준, 역할변경 뒤 검증, 요청 식별자와 멱등 처리를 함께 둔다. 이 절은 특정 충돌 해결 알고리즘을 근거 없이 단정하지 않는다.

핫 샤드는 키 분포나 시간 방향 쓰기가 한 조각에 몰려 그 노드만 지연·처리량 한계를 보이는 상태다. 전체 평균만 보면 숨을 수 있으므로 샤드별 데이터량·요청량·지연을 따로 본다. 범위 지역성과 분산성 사이의 선택을 실제 분포로 다시 검토한다.

다중 샤드 질의·트랜잭션 비용은 요청이 배치 키를 포함하지 못하거나 한 논리 작업이 여러 샤드의 데이터를 함께 다룰 때 커진다. 대상 노드와 결과 결합·일관성 조정 범위가 늘기 때문이다. 자주 함께 읽고 바꾸는 데이터가 가능하면 같은 배치 경로를 타도록 키를 검토하고, 여러 샤드를 건너는 요청은 별도 지표로 관찰한다. 특정 분산 트랜잭션 프로토콜은 현 근거 팩의 범위 밖이므로 이 절에서 정답처럼 제시하지 않는다.

재균형 과부하는 편중을 고치기 위해 데이터 조각을 옮기는 동안 기존 서비스 부하와 이동 부하가 겹칠 때 나타날 수 있다. 징후는 이동 중 지연·대역폭·처리량의 동시 악화와 배치 상태 불일치다. 재균형 전후의 조각 분포와 요청 지표를 비교하고, 이동 실패 시 어느 배치 상태를 기준으로 복구할지 명시한다.

복제 범위 누락은 데이터 행만 복제되고 운영에 필요한 다른 상태가 빠질 때 생긴다. PostgreSQL 18 논리 복제에서는 스키마·DDL 변경, 시퀀스 상태와 대형 객체 등이 자동 복제되지 않는 제한이 있으므로 별도 변경·검증 절차가 필요하다. 이 제한을 다른 제품의 공통 목록으로 복사하지 않는다.

복제된 ID 값과 다음 ID를 만드는 상태를 구별한다. PostgreSQL 논리 복제에서 시퀀스를 사용하는 열의 행 값은 전달되지만 시퀀스 자체의 상태는 자동으로 따라가지 않는다. 구독 테이블에 ID 1~1000이 모두 있는데 구독 측 시퀀스의 다음 생성값이 1이면, 그 구독자를 쓰기 역할로 전환했을 때 기본키 충돌이 날 수 있다. 읽기 사본으로 정상 조회되었다는 사실만으로 쓰기 전환 준비가 끝난 것은 아니다. 전환 전에 시퀀스·스키마와 다른 쓰기 주체의 상태를 확인하고, 조정 절차와 중복 방지를 함께 검증한다. 동시 쓰기나 예약한 번호가 있는 실제 운영에서 테이블 최댓값만 보고 임의로 시퀀스를 고치면 안 된다.

실패와 재균형은 상태전이로 관리한다

역할이 바뀐 뒤에도 정상 여부를 다시 확인한다 · 상태 따라가기

샤드별 주 구성원·복제 지연·부하를 관찰한다. 모든 단계에서 복제 역할·정상 확인의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

정상 배치의 샤드별 부하·복제 지연·역할을 관찰한다. 주 구성원 실패 뒤 남은 구성원 선거로 역할을 바꾸고 새 주를 확인하여 정상 상태 또는 후속 검증으로 이어 간다. 자동 선거만으로 무손실·무중단을 보장하지 않는다.

이 예의 조건

• 정상 배치의 샤드별 부하·복제 지연·역할을 관찰한다. 주 구성원 실패 뒤 남은 구성원 선거로 역할을 바꾸고 새 주를 확인하여 정상 상태 또는 후속 검증으로 이어 간다. 자동 선거만으로 무손실·무중단을 보장하지 않는다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상정상 배치	원 설명부하·복제 지연·역할 관찰
대상역할 선거	원 설명주 구성원 실패 뒤 남은 구성원 선거
대상새 주 확인	원 설명바뀐 역할·반영 상태
대상정상/후속 검증	원 설명업무 요구와 대조

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결정상 배치 → 역할 선거	원 라벨·방향실패 / 정방향 / 실선
연결역할 선거 → 새 주 확인	원 라벨·방향선출 / 정방향 / 실선
연결새 주 확인 → 정상/후속 검증	원 라벨·방향검증 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
정상 배치 샤드별 주 구성원·복제 지연·부하를 관찰한다.	값·보충 정보 복제 역할: 기존 주·복제 구성 정상 확인: 정상 조건 관찰	변화·이유 정상이라는 명칭만으로 최신성은 보장되지 않는다.
주 실패·선거 주 구성원 실패 뒤 남은 구성원이 새 주 구성원을 선출한다.	값·보충 정보 복제 역할: 기존 주 실패·선거 정상 확인: 정상 판정 보류	변화·이유 특정 제품의 내부 선거 알고리즘을 추가하지 않는다.
새 주 확인 새 주의 역할과 자료 반영 상태를 대조한다.	값·보충 정보 복제 역할: 새 주 선출 정상 확인: 업무 요구 재검증	변화·이유 선출 성공만으로 무손실·무중단을 약속하지 않는다.
정상 또는 후속 검증 조건 충족은 정상, 미충족은 후속 확인으로 관리한다.	값·보충 정보 복제 역할: 새 역할 유지 정상 확인: 정상 / 후속 검증	변화·이유 반영 상태의 실제 근거가 종료 조건이다.

역할이 바뀐 뒤에도 정상 여부를 다시 확인한다 · 상태 따라가기

샤드별 주 구성원·복제 지연·부하를 관찰한다. 모든 단계에서 복제 역할·정상 확인의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

정상 배치의 샤드별 부하·복제 지연·역할을 관찰한다. 주 구성원 실패 뒤 남은 구성원 선거로 역할을 바꾸고 새 주를 확인하여 정상 상태 또는 후속 검증으로 이어 간다. 자동 선거만으로 무손실·무중단을 보장하지 않는다.

이 예의 조건

• 정상 배치의 샤드별 부하·복제 지연·역할을 관찰한다. 주 구성원 실패 뒤 남은 구성원 선거로 역할을 바꾸고 새 주를 확인하여 정상 상태 또는 후속 검증으로 이어 간다. 자동 선거만으로 무손실·무중단을 보장하지 않는다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상정상 배치	원 설명부하·복제 지연·역할 관찰
대상역할 선거	원 설명주 구성원 실패 뒤 남은 구성원 선거
대상새 주 확인	원 설명바뀐 역할·반영 상태
대상정상/후속 검증	원 설명업무 요구와 대조

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결정상 배치 → 역할 선거	원 라벨·방향실패 / 정방향 / 실선
연결역할 선거 → 새 주 확인	원 라벨·방향선출 / 정방향 / 실선
연결새 주 확인 → 정상/후속 검증	원 라벨·방향검증 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
정상 배치 샤드별 주 구성원·복제 지연·부하를 관찰한다.	값·보충 정보 복제 역할: 기존 주·복제 구성 정상 확인: 정상 조건 관찰	변화·이유 정상이라는 명칭만으로 최신성은 보장되지 않는다.
주 실패·선거 주 구성원 실패 뒤 남은 구성원이 새 주 구성원을 선출한다.	값·보충 정보 복제 역할: 기존 주 실패·선거 정상 확인: 정상 판정 보류	변화·이유 특정 제품의 내부 선거 알고리즘을 추가하지 않는다.
새 주 확인 새 주의 역할과 자료 반영 상태를 대조한다.	값·보충 정보 복제 역할: 새 주 선출 정상 확인: 업무 요구 재검증	변화·이유 선출 성공만으로 무손실·무중단을 약속하지 않는다.
정상 또는 후속 검증 조건 충족은 정상, 미충족은 후속 확인으로 관리한다.	값·보충 정보 복제 역할: 새 역할 유지 정상 확인: 정상 / 후속 검증	변화·이유 반영 상태의 실제 근거가 종료 조건이다.

이동 뒤 배치·라우팅이 맞아야 정상으로 돌아간다 · 상태 따라가기

샤드 부하에서 핫 샤드와 옮길 대상을 확인한다. 모든 단계에서 조각 배치·라우팅·확인의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

키 편중을 관찰하면 핫 샤드와 재균형 대상을 확인하고 조각을 이동한다. 새 배치·라우팅이 일치하면 정상 배치로 돌아가고 불일치하면 복구·재검증한다. 이는 운영 확인 상태이며 특정 제품의 내부 알고리즘이 아니다.

이 예의 조건

• 키 편중을 관찰하면 핫 샤드와 재균형 대상을 확인하고 조각을 이동한다. 새 배치·라우팅이 일치하면 정상 배치로 돌아가고 불일치하면 복구·재검증한다. 이는 운영 확인 상태이며 특정 제품의 내부 알고리즘이 아니다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상정상 배치	원 설명샤드별 부하 관찰
대상핫 샤드	원 설명키 편중 확인
대상재균형 대상 결정	원 설명옮길 조각·노드 판단
대상새 배치 일치?	원 설명라우팅·데이터 확인
대상복구·재검증	원 설명불일치한 상태를 대조

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결정상 배치 → 핫 샤드	원 라벨·방향편중 / 정방향 / 실선
연결핫 샤드 → 재균형 대상 결정	원 라벨·방향대상 / 정방향 / 실선
연결재균형 대상 결정 → 새 배치 일치?	원 라벨·방향조각 이동 / 정방향 / 실선
연결새 배치 일치? → 정상 배치	원 라벨·방향일치 / 정방향 / 실선
연결새 배치 일치? → 복구·재검증	원 라벨·방향불일치 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
키 편중 샤드 부하에서 핫 샤드와 옮길 대상을 확인한다.	값·보충 정보 조각 배치: 핫 샤드 관찰 라우팅·확인: 이동 대상 미정	변화·이유 단순 총부하만으로 조각을 고르지 않는다.
재균형 이동 정한 조각을 새 노드로 옮긴다.	값·보충 정보 조각 배치: 새 배치 진행 라우팅·확인: 라우팅 확인 대기	변화·이유 이동 작업이 반환됐다고 해서 실제 상태가 일치하는 것은 아니다.
일치 검사 새 배치의 자료와 라우팅이 맞는지 확인한다.	값·보충 정보 조각 배치: 새 배치 대조 라우팅·확인: 일치 / 불일치	변화·이유 동일 업무의 읽기·쓰기 대상을 대조한다.
정상 또는 복구 일치하면 정상, 불일치하면 복구·재검증한다.	값·보충 정보 조각 배치: 배치 유지·수습 라우팅·확인: 정상 판정 조건	변화·이유 자동 재균형 명칭만으로 정상 완료를 선언하지 않는다.

이동 뒤 배치·라우팅이 맞아야 정상으로 돌아간다 · 상태 따라가기

샤드 부하에서 핫 샤드와 옮길 대상을 확인한다. 모든 단계에서 조각 배치·라우팅·확인의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

키 편중을 관찰하면 핫 샤드와 재균형 대상을 확인하고 조각을 이동한다. 새 배치·라우팅이 일치하면 정상 배치로 돌아가고 불일치하면 복구·재검증한다. 이는 운영 확인 상태이며 특정 제품의 내부 알고리즘이 아니다.

이 예의 조건

• 키 편중을 관찰하면 핫 샤드와 재균형 대상을 확인하고 조각을 이동한다. 새 배치·라우팅이 일치하면 정상 배치로 돌아가고 불일치하면 복구·재검증한다. 이는 운영 확인 상태이며 특정 제품의 내부 알고리즘이 아니다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상정상 배치	원 설명샤드별 부하 관찰
대상핫 샤드	원 설명키 편중 확인
대상재균형 대상 결정	원 설명옮길 조각·노드 판단
대상새 배치 일치?	원 설명라우팅·데이터 확인
대상복구·재검증	원 설명불일치한 상태를 대조

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결정상 배치 → 핫 샤드	원 라벨·방향편중 / 정방향 / 실선
연결핫 샤드 → 재균형 대상 결정	원 라벨·방향대상 / 정방향 / 실선
연결재균형 대상 결정 → 새 배치 일치?	원 라벨·방향조각 이동 / 정방향 / 실선
연결새 배치 일치? → 정상 배치	원 라벨·방향일치 / 정방향 / 실선
연결새 배치 일치? → 복구·재검증	원 라벨·방향불일치 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
키 편중 샤드 부하에서 핫 샤드와 옮길 대상을 확인한다.	값·보충 정보 조각 배치: 핫 샤드 관찰 라우팅·확인: 이동 대상 미정	변화·이유 단순 총부하만으로 조각을 고르지 않는다.
재균형 이동 정한 조각을 새 노드로 옮긴다.	값·보충 정보 조각 배치: 새 배치 진행 라우팅·확인: 라우팅 확인 대기	변화·이유 이동 작업이 반환됐다고 해서 실제 상태가 일치하는 것은 아니다.
일치 검사 새 배치의 자료와 라우팅이 맞는지 확인한다.	값·보충 정보 조각 배치: 새 배치 대조 라우팅·확인: 일치 / 불일치	변화·이유 동일 업무의 읽기·쓰기 대상을 대조한다.
정상 또는 복구 일치하면 정상, 불일치하면 복구·재검증한다.	값·보충 정보 조각 배치: 배치 유지·수습 라우팅·확인: 정상 판정 조건	변화·이유 자동 재균형 명칭만으로 정상 완료를 선언하지 않는다.

복제 지연으로 오래된 사본이 생기면 읽기 위치·확인 수준을 다시 판단한다. 역할·배치가 바뀐 뒤에는 데이터와 라우팅이 업무 요구에 맞는지도 확인한다.

이 그림은 특정 제품의 내부 알고리즘이 아니라 운영자가 확인해야 할 상태를 이 교재에서 재구성한 것이다. 화살표의 핵심은 “자동 장애조치”나 “자동 재균형”이라는 기능명이 아니라, 역할·배치가 바뀐 뒤 데이터와 라우팅이 업무 요구에 맞는지 다시 확인한다는 점이다. 예방과 복구가 있으려면 정상 상태의 기준, 이상 징후, 전환 조건, 전환 뒤 검증이 모두 있어야 한다.

실무에서는 이렇게 보인다: 대규모 주문 데이터

상황은 다음과 같다. 주문 테이블이 커져 월별 보관·삭제가 오래 걸리고, 한 노드의 쓰기처리량이 한계에 가까우며, 고객은 자신의 주문내역을 자주 조회한다. 일부 노드가 실패해도 주문 접수를 이어가야 하지만, 결제완료 직후 고객 화면에 이전 상태가 보이는 것은 허용하기 어렵다.

채택안은 세 축을 나누어 조합한다. 먼저 한 논리 주문 테이블의 보관·유지보수 경계를 시간 범위 파티션으로 나눈다. 다음으로 고객 주문내역이 같은 경로를 타고 부하가 고르게 퍼질 수 있도록 고객 식별값의 해시 배치를 샤드 키 후보로 검증한다. 마지막으로 각 샤드를 복제해 해당 조각의 장애대응 기반을 두되, 결제 직후 읽기는 오래된 보조 사본을 무조건 사용하지 않고 업무 최신성에 맞는 읽기 위치와 쓰기 확인 수준을 정한다.

결제 결과 조회를 작은 순서로 따라가 보자. 설명을 위해 한 주문의 확정된 변경 이력에 순서 있는 위치 번호를 붙이고, 사본이 위치 42까지 반영했다고 확인되면 그 위치의 변경을 읽기에 반영한다는 계약을 가정한다. 다음 절 분산 트랜잭션·합의·일관성 모델에서 다룰 자기 쓰기 위치 추적의 적용 예이며, 번호 42는 특정 제품의 설정값이 아니다.

1. 권한 있는 쓰기 경로에서 주문의 결제완료 변경이 정한 성공 기준을 충족하면, 응답과 후속 조회 문맥에 주문 식별자·샤드와 그 변경 위치 42를 연결한다. 응답 자체가 미확인이면 결제실패로 단정해 새 결제를 하지 않고 같은 요청의 처리 결과를 확인한다.
2. 후속 읽기는 최소 위치 42를 요구한다. 보조 사본 R1의 반영 위치가 41이면 아직 미결제로 보이는 값을 최종 결과로 내보내지 않는다. 위치 42 이상을 반영했고 읽기 권한·상태가 유효한 사본 R2가 있으면 그쪽에서 읽는다.
3. 그런 사본이 없으면 정한 읽기 대기 한도 안에서 반영을 기다리거나, 현재 권한과 위치 42의 반영을 확인할 수 있는 주 구성원 경로로 전환한다. 이름이 주 구성원이라는 이유만으로 조건 확인을 생략하지 않는다.
4. 대기 한도나 역할변경 뒤에도 반영을 확인하지 못하면 결제 결과 조회 지연·확인 중으로 응답한다. 오래된 미결제 값을 확정 상태처럼 표시하거나 이를 재결제 근거로 쓰지 않는다. 장애조치 때 위치의 식별과 확정 이력이 유지되는지도 제품의 계약으로 확인한다.

이 규칙은 자신의 완료된 쓰기를 후속 조회에 반영하기 위한 조건이다. 다른 사용자의 모든 읽기나 여러 샤드 전체의 최신 상태를 동시에 보장한다는 뜻은 아니며, 위치 42 뒤의 적법한 취소가 반영됐다면 현재 취소 상태를 보여 줄 수 있다.

대안도 함께 기각한다. 주문일 범위만으로 샤딩하면 최근 주문 쓰기가 한쪽 끝에 몰릴 수 있어 기각한다. 주문번호 해시만 쓰면 분산에는 도움이 될 수 있지만 고객별 조회가 샤드 키를 포함하지 못해 여러 샤드에 흩어질 수 있으므로 핵심 조회와 맞지 않는다. 복제만 늘리는 안은 사본을 만들지만 전체 쓰기 데이터를 조각별 노드로 나누는 답이 되지 않아 단일 쓰기 경로 한계를 해결하지 못한다.

운영지표는 평균 한 개가 아니라 구조의 각 상태를 본다. 배치: 샤드별 데이터량·쓰기량·읽기량, 라우팅: 목표 샤드만 찾은 질의와 여러 샤드를 찾은 질의, 복제: 사본별 반영 지연과 역할변경, 재균형: 이동 전후 분포와 서비스 지연, 정확성: 되돌림·충돌·중복처리와 복구 결과를 기록한다. 숫자 목표는 업무와 제품 검증 없이 이 절에서 임의로 정하지 않는다.

시험에서는 어떻게 묻는가

아래 문항은 이 절의 이론을 검증하기 위한 자체 제작 문제다. 실제 기출·출제 빈도·공식 채점 기준을 뜻하지 않는다.

10점 복제, 파티셔닝, 샤딩을 정의하고 데이터 개수·배치 위치·주요 목적·운영비용의 동일축으로 비교하시오.

요구어 정의는 사본·조각·노드 분산의 경계를 구별하라는 뜻이다. 비교는 세 용어를 따로 설명한 뒤 끝내라는 뜻이 아니라, 같은 데이터셋을 놓고 데이터 개수·위치·목적·비용을 같은 축에 정렬하라는 뜻이다. 조합 가능성까지 한 줄로 정리해야 복제와 샤딩을 배타적 대안으로 오해하지 않는다.

25점 대규모 온라인 주문 데이터의 쓰기확장과 장애대응을 위한 복제·파티셔닝·샤딩 조합안을 제시하고, 쓰기·읽기 흐름, 키 선택, 실패모드와 운영통제를 설명하시오.

요구는 여섯 산출물로 나뉜다. ①요구와 병목, ②조합 아키텍처, ③키 기반 쓰기·읽기 흐름, ④주요 질의와 데이터 분포를 함께 본 키 선택·트레이드오프, ⑤복제 지연·핫 샤드·다중 샤드 처리·재균형의 실패대책, ⑥배치·라우팅·복제·정확성 지표다. 정의를 길게 쓰고 실제 조합과 통제 중 하나를 빠뜨리면 문제의 요구에 완전히 답하지 못한다.

10점·25점의 목차·도식·완성 답안 보기

10점과 25점 목차 전환

10점 목차

1. 세 개념의 정의와 경계
   • 복제=사본, 파티셔닝=조각, 샤딩=조각의 노드 분산
2. 동일축 비교
   • 데이터 개수·배치 위치·주목적·쓰기확장·운영비용
3. 조합과 결론
   • 샤드별 복제, 요구에 따른 선택과 관찰 필요

25점 목차

1. 현황과 설계 요구
   • 쓰기·저장 한계, 주요 질의, 최신성·장애대응 요구
2. 데이터 배치 조합안
   • 유지보수 파티션, 키 기반 샤딩, 샤드별 복제
3. 쓰기·읽기·장애조치 흐름
   • 라우팅, 주 구성원 변경, 보조 반영, 읽기 위치와 확인 수준
4. 키 선택과 트레이드오프
   • 범위 지역성 대 편중, 해시 분산 대 범위질의, 다중 샤드 범위
5. 실패모드와 예방·복구
   • 지연·오래된 읽기, 충돌·되돌림, 핫 샤드, 재균형, 복제 누락
6. 운영지표와 결론
   • 배치·라우팅·복제·정확성의 조각별 관찰

10점에서 25점으로 갈 때 정의를 늘리지 않는다. 25점은 업무 요구에 맞춘 조합, 실제 흐름, 실패 상태, 예방·복구와 운영 증거를 추가한다.

답안 도식

앞의 조각을 노드에 맡기고 각 조각을 복제한다 배치도와 세 쓰기·읽기 경로를 답안의 도식으로 사용한다. 샤드 A·B는 각 고객군의 데이터를 보유한 주 구성원과 복제 사본을 가지며 주에서 사본으로 변경이 전달된다.

샤드 키·배치 정보·읽기 조건은 라우터의 대상·허용 여부 판단에 들어간다. 주문 쓰기·읽기는 그 판단으로 허용된 A·B 구성원에 요청을 전달한다. 각 샤드의 배치·지연·역할·오류 관찰은 운영 검증·복구의 근거이며, 변경된 배치·허용 경로를 라우터에 반영한다.

답안에서도 실선은 요청·변경 데이터 전달, 점선은 배치·읽기 허용 판단의 제어 입력으로 읽는다. 운영 조치 판단은 상태전이와 관찰 근거로 구분한다. 라우터에서 샤드로 가는 실선은 선택 결과에 따라 실제 요청을 보내는 경로다. 쓰기는 해당 주 구성원으로, 읽기는 반영 조건을 충족한 구성원으로 보낸다. 요청 전달·복제·운영 판단을 나누면 “데이터를 어디에 쓰는가”, “사본은 언제 따라오는가”, “바뀐 배치와 역할이 정상인가”를 한 그림에서 답할 수 있다.

10점 모범답안

복제는 동일 데이터셋의 사본을 여러 구성원에 유지하는 전략이고, 파티셔닝은 하나의 논리 데이터 집합을 작은 물리 조각으로 나누는 전략이며, 샤딩은 그 데이터셋과 부하의 부분집합을 여러 머신에 나누는 수평 확장 전략이다. 파티션은 한 서버 안에도 둘 수 있으므로 자동 샤딩이 아니고, 복제는 데이터를 나누는 대신 같은 조각의 사본을 만든다.

동일축으로 보면 복제는 사본 수를 늘려 중복성과 장애대응 기반·읽기 위치를 얻는 대신 복제 지연·오래된 읽기·장애조치 비용을 만든다. 파티셔닝은 큰 데이터의 질의·유지보수 범위를 줄일 수 있지만 질의와 경계가 맞아야 하며, 그 자체가 성능을 보장하지 않는다. 샤딩은 조각을 여러 노드가 맡아 저장과 부하를 분산할 수 있지만 샤드 키 라우팅, 핫 샤드, 다중 샤드 질의와 재균형의 운영비용이 생긴다.

세 전략은 배타적이지 않다. 논리 테이블 → 파티션 → 여러 샤드 → 샤드별 사본으로 조합할 수 있다. 따라서 설계자는 저장·읽기·쓰기·장애대응 중 실제 한계와 주요 질의를 먼저 확인하고, 가용성·일관성·데이터 지역성·운영복잡도를 함께 평가해야 한다.

25점 모범답안

대규모 주문 데이터 설계는 “서버를 늘린다”가 아니라 저장·쓰기·읽기·장애대응 요구를 데이터 배치 규칙으로 바꾸는 문제다. 주문 테이블의 월별 유지보수가 오래 걸리고 단일 노드 쓰기한계가 있으며 고객별 주문조회가 빈번하다고 가정한다. 결제 직후 상태는 오래된 값으로 보이지 않아야 하고, 한 노드 실패 뒤에도 해당 조각을 복구·계속 사용할 기반이 필요하다.

첫째, 하나의 논리 주문 테이블을 시간 범위 파티션으로 나누어 보관·삭제와 해당 기간 질의의 물리 범위를 줄인다. 파티셔닝은 한 서버 안에서도 가능하므로 쓰기확장의 답으로 과장하지 않는다. 둘째, 고객별 조회가 같은 경로를 타도록 고객 식별값의 해시 배치를 샤드 키 후보로 검증한다. 주문일 범위 샤딩은 최근 쓰기가 한 조각에 몰릴 수 있고, 주문번호만 해시하면 고객별 조회가 여러 샤드에 흩어질 수 있으므로 주요 질의와 실제 분포로 선택한다.

셋째, 각 샤드를 복제한다. 쓰기 요청은 라우터가 샤드 키로 목표 샤드를 찾고 그 샤드의 주 구성원이 변경을 기록한 뒤 보조 구성원이 비동기로 따라간다. 읽기는 키가 있으면 목표 샤드로 가고, 키가 없으면 여러 샤드의 결과를 합칠 수 있다. 결제 직후 조회에는 완료된 쓰기의 위치를 함께 전달하고 그 위치 이상을 반영한 유효한 사본에서 읽는다. 위치 42의 쓰기 뒤 반영 위치 41인 사본은 피하고, 조건을 충족한 사본 선택·반영 대기·검증된 주 구성원 경로를 사용한다. 대기 한도에도 확인하지 못하면 조회 지연·확인 중으로 표시하며 오래된 미결제 값을 재결제 근거로 쓰지 않는다. 장애조치 뒤에는 새 주 구성원의 역할과 확정 이력·반영 상태를 다시 확인한다.

넷째, 실패를 구조별로 통제한다. 복제 지연은 사본별 반영시각을 관찰하고 최신성이 필요한 읽기 경로를 분리한다. 충돌·되돌림과 중복 재시도에는 확정 기준, 요청 식별자와 멱등 처리, 역할변경 뒤 검증을 둔다. 핫 샤드는 샤드별 데이터량·요청량·지연으로 탐지하고 키 선택을 재검토한다. 다중 샤드 질의·트랜잭션은 대상 노드와 일관성 조정 범위를 관찰하며, 재균형은 이동 전후 분포·라우팅·서비스 지연이 정상인지 검증한다.

마지막으로 배치·라우팅·복제·정확성을 함께 운영한다. 샤드별 데이터와 쓰기 분포, 목표 샤드만 찾은 요청 비율, 복제 지연과 역할변경, 재균형 전후 지연, 충돌·되돌림·중복처리와 복구 결과를 본다. 결론적으로 파티셔닝은 관리할 조각을, 샤딩은 조각의 노드 분산을, 복제는 조각의 사본을 설계한다. 세 축을 업무 질의와 실패조건에 연결해야 성능 향상이 일관성·가용성과 운영 가능성을 해치지 않는다.

근거와 표현 범위

PostgreSQL의 사실은 18판 논리 복제와 복제 제한, 저장 분할은 앞 절의 18판 근거를 사용한다. MongoDB의 복제 집합과 샤딩에서는 주·보조 구성원, 비동기 oplog 재생, 샤드별 데이터 배치를 확인한다. 조회형 배치는 Microsoft의 Sharding pattern의 대응표·가상 샤드·재배치 설명을 사용한다. 이번 보완의 원문 확인일은 2026-10-09이며, 동적으로 바뀌는 매뉴얼의 내용으로 특정 패치 릴리스의 실행 결과를 주장하지 않는다. 제품 구조를 모든 DBMS의 보편 규칙으로 일반화하지 않는다.

PostgreSQL 문서는 허용 조건을 지키는 재서술만 사용하고, MongoDB와 Microsoft 문서는 사실관계만 독립적으로 요약한다. 외부 문구·코드·표·도식·스크린샷·브랜드 자산을 복제하거나 따라 그리지 않았으며, 이 절의 배치·흐름·상태 도식과 비교표는 주장 범위 안에서 새로 만들었다. 권리 검토와 기술 검토는 별도의 검증된 사람이 현재 파일 해시에 대해 승인하기 전까지 완료로 표시하지 않는다.

여기서 확인한 디렉터리 샤딩은 일반 구조와 비용이다. 특정 제품의 캐시 일관성·무중단 재배치·동기 복제 확인 규칙이나 수치화된 복구목표까지 이 설명으로 보장하지 않는다. 그런 보장이 필요한 설계에서는 해당 제품·설정·장애 조건의 원문과 실제 검증 결과를 추가로 확인한다.

30초 정리

1. 복제는 같은 데이터의 사본, 파티셔닝은 논리 데이터의 조각, 샤딩은 조각의 노드 분산을 설계한다.
2. 샤드 키는 데이터 분포와 질의 경로를 함께 바꾸고, 복제 확인 수준은 지연·오래된 읽기·장애 뒤 결과를 바꾼다.
3. 세 전략은 함께 쓸 수 있지만 라우팅·일관성·핫 샤드·재균형·장애조치의 상태를 관찰하고 복구할 수 있을 때만 실제 확장성과 가용성으로 이어진다.

다음 절에서는 여러 샤드가 하나의 논리 작업을 함께 수행할 때 생기는 분산 트랜잭션·합의·일관성 모델을 다룬다. 이 절에서 근거 없이 생략한 특정 분산 트랜잭션 알고리즘은 다음 절에서 정식으로 설명한다.

직접 연습: 사본·투표·위치·생성 상태를 따로 센다.

문제 1: 나머지 규칙의 2를 3으로 바꾸면 무엇이 이동하는가?

교육용 배치에서 기존에는 고객번호를 2로 나눈 나머지 0을 A, 1을 B로 보냈다. 노드 C를 추가하고 3으로 나눈 나머지 0을 A, 1을 B, 2를 C로 보내려 한다. 고객 101~106의 기존·새 위치를 각각 계산하고 이동 대상 수를 구하라. 데이터는 아직 옮기지 않았고 새 규칙으로 라우터만 바꿨다면 고객 101 주문 조회가 왜 실패할 수 있는가?

풀이: 계산 결과는 다음과 같다.

고객	기존 나머지·위치	새 나머지·위치	위치 변경
101	1·B	2·C	필요
102	0·A	0·A	없음
103	1·B	1·B	없음
104	0·A	2·C	필요
105	1·B	0·A	필요
106	0·A	1·B	필요

이 표본에서는 6명 중 4명의 목표가 바뀐다. 고객 101의 주문은 아직 B에 있으나 새 라우터는 C를 조회하므로 주문이 없다는 잘못된 결과가 나올 수 있다. 새 계산의 정확성과 데이터·라우팅의 일치는 다른 검증이다. 데이터 이동 중 변경 처리와 배치 전환·캐시 갱신·복구 절차를 먼저 정한다. 표본의 4/6을 모든 키와 실제 MongoDB의 이동 비율로 일반화하지 않는다.

문제 2: 데이터 사본이 하나 남으면 새 주 구성원을 선출할 수 있는가?

MongoDB형 교육 구성 A·B·C는 모두 데이터를 가진 투표 구성원이고 각각 한 표를 갖는다. 구성 재변경이나 중재자는 없고, B·C는 후보 자격과 필요한 반영 상태를 갖췄다고 가정한다. 주 A가 격리된 뒤 B·C끼리는 통신하는 경우와, 이어 C도 실패해 B만 남은 경우의 과반 조건을 비교하라. 같은 주문의 복제 사본 수를 새로운 주문 세 건으로 세어도 되는가?

풀이: 현재 구성의 3표 중 과반은 ⌊3/2⌋+1=2표다. B·C는 2표로 과반을 확보할 수 있으므로 나머지 선거 조건이 충족되면 새 주를 선출할 수 있다. B만 남으면 1표여서 선거 과반을 충족하지 못하며, 남은 데이터 사본이나 허용된 읽기의 가능성을 정상 쓰기 재개와 혼동하지 않는다. 선거 성공 전에는 쓰기 경로가 중단될 수 있다. 같은 주문이 세 사본에 있어도 논리 주문은 한 건이며 세 건의 업무 효과가 아니다. 투표 조건과 데이터·업무 건수를 각각 센다.

문제 3: 행은 복제됐는데 ID 생성기가 뒤처져 있다면?

PostgreSQL 논리 복제의 구독 테이블에 기본키 ID 1부터 1000까지가 모두 들어 있다. 구독 측 시퀀스의 다음 생성값은 1이고, 1씩 증가하며 순환하지 않는다. 이 문제에서는 다른 쓰기 주체·예약값·동시 쓰기가 없고 전환 전 상태가 고정됐다고 가정한다. 시퀀스를 그대로 둔 신규 삽입은 어떻게 되는가? 1부터 1000까지의 ID와 충돌하지 않는 가장 작은 다음 ID는 무엇이며, 실제 쓰기 전환에서 추가로 무엇을 검증해야 하는가?

풀이: 시퀀스가 생성한 1은 이미 있는 기본키 1과 충돌하므로 삽입은 기본키 유일성 검사를 통과하지 못한다. 고정된 이 문제 조건에서 가장 작은 안전한 다음 값은 1000+1=1001이다. 행의 ID 값이 복제된 것과 시퀀스 생성 상태가 복제된 것은 다르다. 실제 전환에서는 스키마·시퀀스·예약값·동시 쓰기와 역할 권한을 확인하고 정한 조정·검증 절차를 따라야 한다. “읽기 조회가 정상이라면 즉시 쓰기를 열어도 된다”거나 운영 중 최댓값만 보고 시퀀스를 바꾸는 답은 조건을 빠뜨린 것이다.