Skip to content

Latest commit

 

History

History
225 lines (181 loc) · 13 KB

클러스터링과 리플리케이션.md

File metadata and controls

225 lines (181 loc) · 13 KB
Raw

RDBMS, NoSQL의 클러스터링/리플리케이션 방식


Clustering(클러스터링)

  • 개념
    • 여러 개의 DB를 수평 구조로 구축하는 방식(DB 서버 확장)
    • Fail Over(장애 극복) 시스템을 구축하기 위해 사용
      • DB가 동작하지 않으면, 전체 서비스가 동작할 수 없다는 문제점을 해결하기 위해 클러스터링을 이용하여 DB 서버를 늘림
    • 동기 방식으로 노드들 간의 데이터 동기화
      • DB들 간의 데이터 무결성 검사(데이터가 일치하는지)를 하는 동기 방식으로 데이터를 동기화함
  • 처리 방식
    1. 1개의 노드에 쓰기 트랜잭션이 수행되고, COMMIT을 실행함
    2. 실제 디스트에 내용을 쓰기 전에, 다른 노드로 데이터의 복제를 요청함
    3. 다른 노드에서 복제 요청을 수락했다는 신호(OK)를 보내고, 디스크에 쓰기를 시작함
    4. 다른 노드로부터 신호(OK)를 받으면 실제 디스크에 데이터를 저장함
  • 장점
    • 노드들 간의 데이터를 동기화하기 때문에 항상 일관성있는 데이터를 얻을 수 있음
    • 1개의 노드가 죽어도 다르 노드가 살아 있어 시스템을 계속 장애 없이 운영할 수 있음
    • 여러 대의 DB 서버로 부하를 분산시켜 사용자의 요청을 더 많이 수용할 수 있음(로드 밸런싱)
    • 여러 대의 DB 서버를 가지므로, 높은 가용성을 보장함
      • DB 가용성: DB가 동작하고 있는 시간과 정지한 시간의 비율
      • DB 시스템을 구성할 서버나 스토리지 장비를 각가 2대 이상으로 구성해서, 한 쪽에 장애가 발생하더라도 단 시간내에 운용을 재개할 수 있도록 함
  • 단점
    • 여러 노드들 간의 데이터를 동기화하는 시간이 필요하기 때문에, Replication에 비해 쓰기 성능이 떨어짐
    • 장애가 전파된 경우, 처리가 까다로우며 데이터 동기화에 의해 스케일링(확장)에 한계가 있음
  • 종류
    • Active-Active Clustering
      • DB 서버를 Active(동작중) 상태로 두는 방식
      • 서버하나가 죽어도 다른 서버가 역할을 바로 수행하기 때문에 중단되는 시간이 없음
      • 여러 개의 서버가 하나의 스토리지를 공유함으로써 병목현상이 발생할 수 있음
        • 병목현상: 전체 시스템의 성능이나 용량이 하나의 구성요소로 인해 제한을 받는 현상
    • Active-StandBy Clustering
      • DB 서버 하나는 Active(동작중), 다른 하나는 StandBy 상태로 두는 방식
      • 운영중인 서버가 정지되었을 경우, StandBy 중인 서버를 Active 상태로 전환하여 문제에 대응할 수 있음
      • 서버가 한 대만 운영되기 때문에 병목 현상을 해결할 수 있음
      • 서버가 다운되었을 경우, 다른 서버가 Active로 전환되는데 시간이 들어, 서버가 중단되는 시간이 존재함

Replication(리플리케이션)

  • 개념
    • 여러 개의 DB를 권한에 따라 수직 구조(Master-Slave)로 구축하는 방식
      • 두 개 이상의 DBMS 시스템을 Master/Slave로 나눠서 동일한 데이터를 저장함
      • Master Node는 쓰기 작업만 처리(수정사항 반영)하며 Slave Node는 읽기 작업만 처리(실제 데이터 복사)함(기존의 부하를 분산)
    • DB 서버와 DB 스토리지 모두 확장
    • 비동기 방식으로 노드들간의 데이터를 동기화함(Mysql은 기본적으로 비동기 방식)
      • Master와 Slave간의 데이터 무결성 검사(데이터가 일치하는지)를 하지 않는 비동기방식으로 데이터를 동기화함
  • 처리 방식
    1. Master 노드에 쓰기 트랜잭션이 수행됨
    2. Master 노드는 데이터를 저장하고 트랜잭션에 대한 로그를 파일에 기록함(BIN LOG)
    3. Slave 노드의 IO Thread는 Master 노드의 바이너리 로그 파일(BIN LOG)을 릴레이 로그 파일(Replay Log)에 복사함
    4. Slave 노드의 SQL Thread는 파일(Replay Log)를 한 줄씩 읽으며 데이터를 저장함
  • 장점
    • DB 요청의 60~80% 정도가 읽기(SELECT) 작업이기 때문에 Slave DB 만으로도 충분히 성능을 높일 수 있음
    • 비동기 방식으로 운영되어 지연 시간이 거의 없음
  • 단점
    • 노드들 간의 데이터 동기화가 보장되지 않아 일관성있는 데이터를 얻지 못할 수 있음
    • Master 노드가 다운되면 복구 및 대처가 까다로움
    • 테이블의 데이터가 엄청나게 많을 경우, Slave DB 서버를 N대로 늘려도 원하는 데이터를 데이블로부터 찾는데 많은 시간이 소요될 수 있음
      • 이때는 Sharding 방식을 활용함

데이터 정합성 문제

  1. 비동기 복제(Asynchronous replication)
  • 비동기 리플리케이션은 Master/Slave 서버 간 데이터 동기화까지의 시간이 소요되기 때문에 데이터 정합성 문제가 발생할 수 있음
  1. 반동기 복제(Semi-synchronous replication)
  • Master DB가 Slave DB로부터 Replay Log 기록이 완료되었다는 ACK를 받고 트랜랙션을 진행하는 방식
    • Replay Log 복제 방식을 통해 Slave DB의 모든 데이터 복제 과정을 기다리지 않고, 여러 Slave 중 단 1대만이라도 Replay Log를 수신했다면, Master DB는 해당 트랜잭션을 완료함
    • Master DB가 Slave DB에게 DB 변경 내용을 언제 전달하냐에 따라서 AFTER_SYNC, AFTER_COMMIT 2가지 방식으로 구분됨
  • 비동기 리플리케이션 방식에 비해 더 많은 DB 성능저하가 발생하지만, Replay Log 보장으로 최소한의 데이터 정합성을 확보할 수 있음


Partitioning(파티셔닝)

  • 개념

    • 데이터베이스를 특정 조건을 적용해 여러 부분으로 분할하는 것
    • 하나의 DBMS에 데이터가 너무 큰 테이블이 들어갈 경우, 테이블이나 인덱스를 작은 파티션 단위로 나누어 사용하는 기법

  • 종류

    • Column 기준
      • 수직 파티셔닝
        • 데이터의 갯수를 기준으로 나누어 파티셔닝 진행
        • 데이터와 인덱스의 갯수가 줄어들어 성능 향상에 도움
        • 데이터를 찾는 과정이 기존보다 복잡하기 때문에 레이턴시 증가
      • 수평 파티셔닝
        • 같은 타입의 데이터가 저장 됨
        • 데이터 압축률을 높일 수 있고 조회 시 필요 없는 컬럼을 조회하지 않아도 됨
        • 수직적 확장과 마찬가지로 데이터 찾는 과정의 복잡
        • 4가지 분할 기준 존재
          • 범위 분할
          • 목록 분할
          • 해시 분할
          • 합성 분할

  • 장점

    • 파티션별 연산으로 I/O분산이 가능하여 성능 향상
    • 파티션별로 백업 및 복구 가능
    • 전체 데이터 손실 가능성 줄어듦

  • 단점

    • 테이블이 여러개로 나누어짐
      • 테이블간 JOIN연산에 대한 비용 증가
      • 테이블과 인덱스를 별도로 파티셔닝할 수 없음

Sharding(샤딩)

  • 개념

    • 같은 테이블 스키마를 가진 데이터를 다수의 DB에 분산하여 저장하는 방법
      • 테이블을 특정 기준으로 나눠서 저장 및 검색함
    • 다수의 복제본으로 구성하고, 각 샤드에 어떤 데이터가 저장될 지를 Shard Key를 기준으로 분리
      • Shard Key를 어떻게 정의하느냐에 따라 데이터를 효율적으로 분산시키는 것이 결정됨

  • 목적

    • DB 트래픽을 분산할 목적
      • 데이터가 급격히 증가하게 되거나 트래픽이 특정 DB로 몰리는 상황을 대비해서 빠르고 유연하고 안전하게 DB를 증설할 수 있게 함(DB 서버의 부하를 분산)
      • Scale-up(수직적 확장)에는 한계가 있고, Scale-out(수평적 확장)은 동기화라는 제약이 따름
      • DB 서버의 샤딩은 대규모 시스템 설계와 확정성 확보에 필수 불가결인 요소가 됨

  • 특징

    • 여러대의 서버를 사용하여 데이터를 분산 시킴
      • Request에 대한 부하를 서로 다른 샤드가 있는 여러 서버에 분산 가능
    • 병렬처리로 확장성과 성능 향상 가능
    • 수평적 파티셔닝의 일종으로 볼 수 있음

  • 장점

    • Scale-Out 가능
      • DB스키마를 유지하기때문에 DB확장에 유리
    • 스캔 범위를 줄여 빠른 쿼리 반응 속도
    • 샤드 단위의 장애 발생

  • 단점

    • 프로그래밍의 복잡도 증가
    • 데이터가 한 쪽 샤드로 몰릴 경우 무의미 함
    • 하나의 서버가 고장날 시 데이터 무결성이 깨질 수 있음
    • 잘못사용 시 큰 리스크
    • 샤딩 한번 이용시 샤딩 이전의 구조로 돌아가기 힘듦

    샤딩을 피하는 대표적인 방법

    • 데이터베이스 서버의 Scale-Up
    • read의 부하가 클 경우: cache사용, replication
    • 테이블의 일부 컬럼만 주로 사용할 경우: Vertical Partitioning

  • Shard Key 방식

    • Hash Sharding: 데이터를 어디에 넣을지 해싱 결과에 따라 DB 서버에 저장
    • Dynamic Sharding: 테이블 형식의 데이터를 바탕으로 샤드를 결정해서 저장
    • Entity Group: 관련된 데이터를 하나의 샤드로 사용하는 방식

  • 종류

    • 모듈러 샤딩 (해시 샤딩)
      • DB id(pk)를 Hashing하여 Shard Key결정
      • 레인지샤딩에 비해 데이터가 균일하게 분산
      • 클러스터가 포함하는 Node갯수를 변경하면 해시크기가 변경되고 key또한 변경되어 ReSharding이 필요
      • 일정 수준에서 유지될 것으로 예상되는 데이터 성격을 가진 곳에 적절
    • 레인지 샤딩(Range Sharding)
      • 해시샤딩에 비해 기본적으로 증설작업에 재정렬 비용이 들지 않고 증설작업에 드는 비용이 크지 않음
      • 활성유저가 몰린 일부 DB에 데이터가 편향될 수 있음

파티셔닝과 샤딩의 차이

  • 수평적 파티셔닝
    • 같은 스키마에 다른 테이블로 쪼개서 저장
    • 동일한 DB 서버 내에서 테이블 분할
  • 샤딩
    • 나눈 데이터들을 Shard key를 기준으로 스키마를 복제하여 다른 DB에 저장
    • DB 서버 분할


Lock

  • 개념
    • 데이터의 일관성을 보장하기 위한 방법으로, Transaction 처리의 동시성을 제어하기 위한 기능
    • 여러 커넥션에서 동시에 동일한 자원을 요청할 경우, 순서대로 한 지점에 하나의 커넥션만 변경할 수 있게 해주는 역할
  • 종류
    • Shared Lock(공유락, Read Lock)
      • 데이터를 읽을 때(Select) 사용하는 Lock
      • 공유락을 설정한 경우, 추가로 공유락을 설정할 수는 있지만, 배타락은 설정할 수 없음
        • 한 프로세스가 보고 있는 데이터를 다른 프로세스가 볼 수는 있지만, 변경할 수는 없음
    • Exclusive Lock(배타락, Write Lock)
      • 데이터를 변경할 때(Insert, Update, Delete) 사용하는 Lock
      • 락이 해제되기 전에는 다른 공유락과 배타락을 설정할 수 없음(읽기와 쓰기 모두 불가능)

Deadlock(교착상태)

  • 두 개 이상의 트랜잭션들이 동시에 진행될 때, 서로가 서로에 대한 Lock을 소유한 상태로 대기 상태로 빠져서 더 이상 진행하지 못하는 상황
    • 특정 자원(테이블 또는 행)의 Lock을 획득한 채, 다른 트랜잭션이 소유하고 있는 Lock을 요구하면 발생함
  • 해결 방법
    • 트랜잭션 진행방향을 같은 방향으로 처리
      • 테이블A 업데이트 후, 테이블B 업데이트
    • 트랜잭션 처리 속도를 최소화
      • 트랜잭션 속도가 빠르면 commit 처리도 빠르게 되기 때문에 다른 트랜잭션에서 테이블이 잠길일이 없음
    • timeout을 이용하여 잠금해제 시간 조절
      • SET LOCK_TIMEOUT으로 잠금해제 시간을 설정하여 무기한 대기하지 않고 만료되어 다음 작업을 진행할 수 있음
  • 일반적인 DBMS에서는 데드락 탐지(Deadlock detection) 기능을 제공함
    • 데드락이 발견되면 자동으로 해소해줌
    • 실제 데드락 상황이 아니더라도, 락에 대한 대기시간이 설정된 시간을 초과하면 데드락으로 처리됨