728x90

DB 분산 구조

DB 분산 구조는 말 그대로 DB를 여러 개의 서버에 나누어 저장하고 관리하는 시스템을 의미함

단일 DB 시스템이 가질 수 있는 한계 (성능, 용량, 가용성 등)을 극복하고, 더욱 확장성 있고 안정적인 서비스를 제공하기 위해 도입된 개념

DB 분산 구조를 사용하는 이유

단일 데이터 베이스는 아래와 같은 한계를 가짐

  1. 성능 한계
    • 모든 R/W 요청이 하나의 서버로 집중되면, 서버의 CPU, 메모리, I/O 자원이 고갈되어 처리 속도가 급격히 느려짐
    • 데이터 양이 방대해지면 인덱스를 사용해도 쿼리 속도가 저하됨
  2. 용량 한계
    • 하나의 서버에 저장할 수 있는 데이터 양에는 물리적 한계 존재
    • 데이터가 계속 증가하면, 언젠가는 공간 부족
  3. 가용성 문제
    • 단일 서버에 장애가 발생하면 전체 서비스가 중단될 수 있음

DB 분산 구조는 위와 같은 문제들을 해결하기 위해 데이터와 작업을 여러 서버에 분산하여 효율적으로 관리함

DB 분산 구조의 핵심 목표

목표 설명
확장성 데이터 양이나 사용자 수가 증가해도, 시스템의 성능을 유연하게 확장
고가용성 시스템 일부에 장애가 발생해도 서비스 중단 없이 제공
성능 향상 데이터와 요청을 분산해 처리 속도를 높이고 응답 시간 단축
신뢰성 데이터 손실 위험을 줄이고 장애 발생 시 복구 용이
📌 수직 확장 / 수평 확장
- 수직 확장: 더 좋은 하드웨어를 추가하여 성능을 높이는 방식
- 수평 확장: 서버의 대수를 늘려 성능을 높이는 방식 (DB 분산 구조는 주로 수평 확장을 목표로 함)

DB 분산 구조의 주요 기법

  1. 레플리카 (Replication - 복제)
  2. 샤딩 (Shading - 분할)
  3. 파티셔닝 (Partitioning)
  4. etc...

레플리카 (Replication)

레플리카 (= 복제) 는 DB의 복사본을 여러 개 만드는 것을 의미

주로 `Master-Slave` (또는 Primary-Secondary) 구조로 구성

  • Master 서버 : 모든 쓰기 (Insert, Update, Delete) 작업 처리
  • Slave 서버: Master 서버로부터 데이터를 복제하여 읽기(Select) 요청 처리

장점

장점 설명
읽기 성능 향상 여러 Slave 서버로 읽기 트래픽을 분산하여 전체적인 읽기 성능 향상
고가용성 확보  Master 서버에 장애가 발생하더라도 Slave 서버 中 하나를 Master로 승격시켜 서비스 중단 최소화
데이터 백업/ 복구 복제본을 활용하여 데이터 백업 및 재해 복구에 활용

단점

단점 설명
쓰기 성능의 한계 모든 쓰기 작업은 Master에서만 이루어지므로, 쓰기 트래픽이 많아지면 Master 서버 병목
데이터 일관성 문제 대부분의 복제는 비동기 방식, Master와 Slave 간 데이터 동기화 지연 발생 가능
= 일시적 데이터 불일치 발생
운영 복잡성 Master-Slave 구조 관리, 장애 발생 시 Failover 처리 등 운영 측면의 복잡성 존재

예시: 온라인 쇼핑몰 웹사이트

온라인 쇼핑몰에 매우 많은 고객들이 접속하여 상품 정보를 조회하고 주문하려는 상황

  1. 초기 상태:
    • DB 서버 1대 존재 (Master)
    • 모든 고객의 상품 조회 (읽기) & 주문 (쓰기) 요청이 해당 서버에 몰림
  2. 문제 발생:
    • 특정 시간대에 동시 접속자가 폭주하면 서버에 과부하가 걸려 웹사이트가 느려지거나 먹통도미
    • 만일 해당 서버가 고장 나면, 쇼핑몰 서비는 완전히 중단됨
  3. 레플리카 적용:
    • DB 서버를 2대 더 추가하여 총 3대 운용 (Master:1대, Slave:2대)
    • `Master 서버`: 모든 주문(쓰기) 요청을 처리하고, 최신 데이터를 가짐
    • `Slave 서버`: Master 서버의 데이터를 실시간 복제하여 가짐
      모든 상품 조회 요청은 해당 두 서버로 분산
    • 만일 Master 서버가 고장 나면, Slave 서버 중 하나를 새로운 Master로 승격하여 서비스 중단 최소화
  4. 결과:
    • 상품 조회 속도 상승, 더 많은 고객들이 접속해도 원활히 서비스 이용 가능
    • 서버 한 대가 고장 나도 서비스가 중단되지 않고 운영됨
📌 레플리카는 데이터를 여러 대의 서버에 복사해서 저장하고, 주로 읽기 성능 향상과 고가용성 확보에 사용

❓Master - Slave간 실시간 동기화는 어떻게 이루어지는가

실시간 동기화: Master에서 발생하는 모든 쓰기 작업을 Slave로 전파하는 과정

주로 다음과 같은 메커니즘을 통해 이루어짐

로깅 (Logging): WAL (Write-Ahead-Logging) / 바이너리 로그 (Binary Log/ Binlog)

대부분의 RDB는 트랜잭션이 커밋되기 전에 모든 변경 사항을 선행 기록 로그(WAL) 라는 특별한 파일에 기록함

이 로그는 데이터 파일 자체에 변경 사항이 적용되기 전에 모든 트랜잭션의 기록을 남김

PostgreSQL: WAL 파일 사용 / MySQL: 바이너리 로그 사용

로그 전송 (Log Shipping)

  • Master 서버의 데이터 변경 사항이 기록된 로그 파일(또는 로그 스트림)을 Slave에 전달
  • Slave 서버는 이 로그를 받아 자신이 가지고 있는 데이터에 동일한 변경 사항을 순서대로 적용

동기화 방식

동기화 방식에 따라 실시간의 정도와 데이터 정합성의 강도가 달라짐

1. 비동기 복제 (Asynchronous Replication)

가장 흔하게 사용되는 방식으로, 마스터(Master) 서버의 쓰기 성능을 최우선

  • 동작 방식:
    1. 마스터는 트랜잭션을 커밋하고 사용자에게 즉시 성공을 알림
    2. 이후 백그라운드에서 변경된 로그를 슬레이브(Slave) 서버로 전송
    3. 슬레이브는 로그를 받아 자신의 데이터에 변경 사항을 적용.
  • 실시간성 및 정합성:
    • 슬레이브가 마스터보다 약간 뒤처질 수 있음. 이 지연을 `복제 지연(Replication Lag)` 이라 칭함
    • 이로 인해 마스터에서는 최신 데이터를 볼 수 있지만, 슬레이브에서는 일시적으로 이전 데이터를 읽게 되는
      `데이터 불일치`가 발생할 가능성 有
    • 결국은 모든 데이터가 일치하는 `결과적 일관성(Eventual Consistency)`을 가짐
  • 장점: 마스터의 쓰기 성능에 거의 영향을 주지 않아 높은 처리량을 유지
  • 단점: 마스터 장애 발생 시, 아직 슬레이브로 전파되지 않은 최신 데이터는 유실될 수 있음
📌 가장 널리 사용되나, 정합성 문제를 완화하기 위한 추가적 고려 必

2. 동기 복제 (Synchronous Replication)

데이터 정합성을 최우선으로 하는 방식

  • 동작 방식:
    마스터는 트랜잭션을 커밋하기 전에, 해당 변경 로그가 모든 슬레이브에 성공적으로 수신되고 응답까지 받아야
    커밋을 완료하고 사용자에게 성공을 알림
  • 실시간성 및 정합성:
    • 마스터와 슬레이브 간의 데이터가 거의 완벽하게 일치합니다.
      "실시간 동기화"에 가장 가깝고, 항상 최신 데이터를 읽을 수 있는 `강한 일관성(Strong Consistency)`을 보장
  • 장점: 마스터 장애 시에도 데이터 유실이 전혀 없습니다.
  • 단점:
    • 슬레이브의 응답을 기다려야 하므로 마스터의 쓰기 성능이 저하
    • 네트워크 지연이나 슬레이브 서버의 성능 문제에 매우 민감
    • 모든 슬레이브가 동시에 다운되면 마스터도 쓰기 작업을 할 수 없게 되어 서비스가 블록될 수 있음
📌 복제 시스템 자체가 강한 일관성을 보장하도록 설계되어 있으므로, 별도의 애플리케이션 레벨의 정합성 보장 로직이 거의 필요 없음
👉 쓰기가 성공했으면, "모든 복제본에서 즉시 읽을 수 있다"는 강력한 보장 제공

3. 준동기 복제 (Semi-Synchronous Replication)

동기 복제와 비동기 복제의 절충안으로, 데이터 유실 위험을 줄이면서 성능 저하를 완화

  • 동작 방식:
    마스터는 트랜잭션을 커밋하기 전에, 모든 슬레이브가 아닌 최소한 하나 이상의 슬레이브가 변경 로그를 수신했음을 확인하면 커밋을 완료하고 사용자에게 성공을 알림
  • 실시간성 및 정합성:비동기 복제보다는 정합성이 높고, 동기 복제보다는 성능 저하가 덜함
  • 장점: 데이터 유실 위험을 줄이면서도 동기 복제보다 마스터의 성능 저하가 적음
  • 단점:
    • 여전히 성능 오버헤드 존재
    • 설정된 최소 슬레이브 수가 특정 시점에 응답하지 못하면 마스터의 쓰기 작업이 블록될 수 있음
📌 동기 복제와 유사하게, 어느 정도의 정합성을 시스템 자체적으로 보장

❓ 비동기 방식에서 데이터 정합성 유지는 어떻게 하는가

Master-Slave 복제는 기본적으로 마스터에만 쓰기작업이 발생하고, 슬레이브는 읽기 작업을 처리함

이 구조에서 정합성을 유지한다는 것은 주로 "Slave에서 읽는 데이터가 얼마나 최신 상태인가" 그리고 "장애 발생 시 데이터 유실을 어떻게 최소화하는가"에 초점이 맞춰짐

복제 지연 모니터링 및 관리

비동기 복제의 가장 큰 문제인 복제 지연을 관리하는 것이 정합성 유지의 핵심

  • 지속적인 복제 지연 모니터링: `Seconds_Behind_Master` (MySQL) 또는 `pg_stat_replication` (PostgreSQL) 같은 지표를 사용하여 슬레이브가 마스터로부터 얼마나 뒤처져 있는지 지속적으로 모니터링
  • 알림 및 경고: 복제 지연이 임계값을 초과하면 즉시 운영팀에 알림
  • 자동화된 조치: 심각한 지연 발생 시 해당 슬레이브로의 읽기 요청을 일시적으로 중단하거나, 아예 복제에서 제외시키는 자동화된 스크립트를 구현 (예: 헬스체크 실패 시 로드밸런서에서 제외)
  • 워크로드 분리 및 최적화: 마스터와 슬레이브의 네트워크 대역폭, I/O 성능 등을 최적화하여 복제 지연 자체를 최소화

2. 읽기 요청의 라우팅 전략 (Read Routing Policies)

어떤 상황에서 어느 서버로부터 읽기 요청을 처리할 것인지 명확히 정의하여 정합성 문제를 완화

  • Master 읽기 (Read-Your-Writes Consistency):
    • 사용자가 데이터를 쓰자마자(Master) 바로 이어서 자신의 데이터를 읽는 상황(예: 게시물 작성 후 바로 목록에서 확인)에서, 슬레이브의 복제 지연으로 인해 이전 데이터를 읽는 문제 방지
    • 방법: 특정 시간(예: 5초) 동안 해당 사용자의 모든 읽기 요청을 마스터로 라우팅하거나,
      세션 정보에 최근 쓰기 작업 여부를 저장하여 마스터로 직접 읽도록 강제
    • 단점: 마스터에 읽기 부하가 가중
  • 일관성 요구 수준에 따른 라우팅:
    1. 높은 정합성 요구 (예: 결제 확인, 중요한 사용자 정보 조회):
       항상 마스터에서 읽도록 강제
    2. 느슨한 정합성 허용 (예: 인기 게시물 목록, 캐시 데이터):
      슬레이브에서 읽도록 하여 읽기 부하를 분산
    3. N초 이내의 데이터만 허용:
       N초 이내의 복제 지연을 가진 슬레이브로만 라우팅하고, 그렇지 않은 슬레이브는 잠시 격리

4. 데이터 손실 방지 및 복구 전략 (Durability & Recovery)

정합성 유지는 단순히 데이터가 "최신"인가뿐만 아니라, "유실되지 않는가"와도 관련

  • WAL(Write-Ahead Log) / 바이너리 로그 (Binary Log)의 안정적인 관리:
    • 마스터에서 발생하는 모든 변경 사항은 이 로그 파일에 기록되므로,
      이 로그 파일 자체가 손상되거나 유실되지 않도록 안정적인 스토리지(RAID, 네트워크 스토리지 등)에 저장
    • 로그 파일의 백업 및 보존 정책을 수립
  • 정기적인 백업:
    데이터베이스 전체의 정기적인 백업(풀 백업, 증분 백업)은 최악의 상황(모든 복제본 손상)에 대비한 최종적인 정합성 유지 및 복구 수단
  • 복구 프로세스 수립:
    • 마스터 장애 시 슬레이브를 새로운 마스터로 승격시키는 `페일오버(Failover)` 절차를 명확히 하고, 자동화된 도구를 사용할 경우 해당 도구의 신뢰성을 확보
      이때, 복제 지연이 적은 슬레이브를 우선적으로 선택하여 데이터 유실을 최소화
    • 슬레이브 장애 시 새로운 슬레이브를 신속하게 프로비저닝하고 마스터로부터 복제를 시작하도록 하는 절차를 마련

5. 애플리케이션 레벨에서의 고려

데이터베이스 레벨의 정합성 유지 노력 외에, 애플리케이션에서도 정합성 문제를 인지하고 대응

  • 멱등성(Idempotency) 설계:
    동일한 작업을 여러 번 수행하더라도 결과가 항상 동일하도록 트랜잭션을 설계하여,
    네트워크 오류나 복제 지연으로 인해 재시도가 발생했을 때 데이터 불일치가 심화되는 것을 방지
  • 낙관적/비관적 잠금:
    특정 데이터를 수정할 때 동시성 제어를 통해 정합성을 유지 (분산 환경에서는 복잡도가 높아지지만, 단일 마스터 내에서는 유효한 방법)
  • 사용자에게 정합성 모델 고지:
    서비스의 특성에 따라 "게시글이 바로 보이지 않을 수 있습니다"와 같은 문구를 통해 사용자에게 결과적 일관성 모델을 인지

샤딩 (Shading)

하나의 DB 테이블을 여러 개의 작은 조각 (Shard)로 나누어 여러 서버에 분산 저장하는 기술

👉 Scale-Out 달성

  • 샤드 (Shard): 분할된 DB의 각 조각을 의미, 각각 별도 서버에 저장 가능
  • 샤딩 키(Sharding Key): 데이터를 어떤 샤드에 저장할지 결정하는 기준이 되는 컬럼

샤딩 방법

  1. 범위 기반 샤딩 (Range-Based Sharding):
    특정 컬럼의 값 범위를 기준으로 데이터 나눔 (예: ID 1~100 = ShardA, ID 101 ~ 200 = ShardB)
  2. 해시 기반 샤딩 (Hash-Based Sharding):
    샤딩 키에서 해시 함수를 적용해 나온 값으로 샤드 결정, 데이터를 비교적 균등 분산 가능
  3. 디렉토리 기반 샤딩 (Directory-Based Sharding):
    별도의 조회 테이블을 두어 어떤 샤드에 어떤 데이터가 있는지 매핑 정보 관리
장점 설명
뛰어난 확장성 DB의 크기와 처리량을 거의 무한하게 확장
성능 향상 샤드가 처리하는 데이터 양이 줄어들어 쿼리 성능 향상 및 병렬 처리 가능
장애 격리 특정 샤드에 문제가 발생해도 다른 샤드들은 영향을 받지 않아 전체 서비스 중단 위험 줄임

 

단점 설명
구현 복잡성 데이터 모델, 애플리케이션 로직, 운영 전반에 걸쳐 큰 변화 요구 & 구현 매우 복잡
조인 및 트랜잭션 어려움 여러 샤드에 걸쳐 있는 데이터에 대하 조인이나 트랜잭션 처리가 어려워지거나
성능 저하 초래
데이터 재분배 (Resharding) 어려움 데이터 양이 늘어나거나 샤딩 키 변경 등으로
샤드 재분배 시 매우 복잡하고 多 시간 소요

레플리카 vs 샤딩

레플리카

  • 동일한 데이터를 여러 곳에 복제하여 읽기 성능을 높이고 가용성을 확보하는 데 중점
  • 데이터는 여전히 논리적으로 하나의 단위를 이룸 (수직 확장 또는 읽기 부하 분산)

샤딩

  • 서로 다른 데이터를 여러 곳에 분산하여 저장함으로써 전체 데이터베이스의 크기 한계를 극복
  • 쓰기/읽기 처리량을 높이는 데 중점 (수평 확장 또는 데이터 분할)

728x90

티스토리툴바