분산 데이터

여러 장비 간 분산된 데이터베이스를 필요로 하는 이유

고부하로 확장

더 강력한 장비로 변경을 통해 더 많은 트래픽을 처리할 수 있으며, 공유 메모리를 통해 한대의 서버 처럼 처리할 수 있다.
Hot 스왑등을 이용해 다운타임 없이 장비를 유지 보수 할 수 있다.

이를 수직 확장이라고도 한다.

하지만 이런경우 무한한 증가가 어렵기에 다른 물리 서버를 추가하는 방식을 사용한다.

비공유 메모리 아키텍처

공유 메모리 아키텍처에 비해 많은 장점이 있지만, 복잡도를 증가시키고, 발생 할 수 있는 문제가 있다.

복제 대 파티셔닝


복제

네트워크로 연결된 여러 장비에 동일한 데이터의 복사본을 유지한다 란 뜻

이때 노드간 데이터를 동일하게 유지하기 위해 변경 사항을 각 노드로 복제

복제 알고리즘에서 가장 많이 사용되는 알고리즘이다.

리더와 팔로워

DB의 복제본(replica)를 가지고 리더 기반 복제(혹은 master-slave, active-passive)

복제된 노드중 하나를 리더(master or primary)로 지정하고 쓰기는 리더에서 한다.
다른 복제 서버는 팔로워(read replica, slave, secondary)라고 한다.

결국 클라이언트는 write는 리더에게, read는 팔로워에게 요청하게 된다.

동기식 대 비동기식 복제

동기식 복제: 일관성 있는 데이터 유지, but 응답이 지연되면 쓰기가 처리되지 않음 비동기식 복제: 쓰기에 영향을 끼치지 않음, but 일관성이 깨질 수 있음 반동기식: 팔로워 중 하나라도 응답하면 나머지는 비동기식으로 처리되는것

새로운 팔로워 추가

  1. DB 전체 백업
  2. 새 팔로워에 복사
  3. binlog를 통해 변경 이후 데이터 요청
  4. 모두 처리 완료 후 “따라잡음”

노드 중단 처리

노드가 멈추는 경우 자동/수동으로 복구해줘야하며, 팔로워/리더가 멈췄을 때 각각 대응이 필요하다.

팔로워 장애: 따라잡기 복구

일관성이 깨진 지점 부터 지금 지점까지 따라잡으며 복구한다.

리더 장애: 장애 복구

  1. 리더가 장애인지 판단.
  2. 새로운 리더 선출
  3. 새로운 리더 사용을 위해 시스템 재설정

다만 팔로워 복구와는 다르게 잘못될 경우 여러 문제 점이 생길 수 있다.

복제 로그 구현

다양한 방법으로 복제를 진행한다.

구문 기반 복제

SQL 구문을 그대로 파싱하고 실행해 데이터를 복제한다.

쓰기 전 로그 배송

추가되는 바이트로 열을 복제한다.

오라클, Postgresql에서 사용

논리적 로그 복제

Row 단위로 DB 테이블에 쓰기를 기술한 레코드 열이다.

MySQL에서 사용

트리거 기반 복제

DBMS상에서 사용되는 트리거나, 스토어드 프로시저를 이용한 방법

애플리케이션 코드를 사용할 수 있는 만큼 오버헤드가 크지만, 그만큼 유연하기에 많이 사용되어진다.

(쓰기 충돌 해소 로직 등을 추가하여 사용할 수 있다.)

복제 지연 문제

리더의 쓰기속도를 팔로워가 따라가지 못해 발생하는 이슈이다.

동기식에선 읽기 서버 확장을 통해 해소할 수 있지만, 그만큼 장애 확율이 높아지기에 불안정해진다.

비동기 방식은 잠시 따라가지 못하더라도 최종적으로 따라가게 된다.

자신이 쓴 내용 읽기

자신이 쓰고 바로 읽을 때 팔루워 DB에 까지 아직 복제가 이뤄지지 않은 경우

단조 읽기

시간이 거꾸로 가는 현상

팔로워가 여럿일 때 모든 팔로워에 복제가 이뤄지지 않아 각 요청시 다른 결과를 반환 하는 경우

일관된 순서로 읽기

데이터의 순서가 뒤바뀌는 증상

샤딩된 DB에서 많이 발생하는 증상이며, 질문전에 답이 나오는 등의 문제가 발생하는 경우

복제 지연을 윈한 해결책

최종적으로 일관된 시스템을 유지하며, 비동기식이면서 동기식으로 동작하는 척 하는 것이 해결방법이다.

이에 관련된 방법은 Part 3에서 다루게 된다.

다중 리더 복제

리더 기반 복제의 단점인 리더가 하나만 존재 해야하는 상황에 대한 대응 방안이다.

하지만 다중 리더인 만큼 쓰기에 대한 복잡성, 장애 대응, 운영 난이도가 크게 올라게된다.