BackEnd Developer, Love Crossfit, Welcome to Jay's blog

데이터베이스 아키텍처 - 다중화(Clustering)

12 Dec 2020 | DB 다중화 클러스터링 리플리케이션 Shared Nothing 샤딩

Index

  • 데이터베이스의 아키텍처
    • 역사와 개요
    • 가용성과 확장성의 확보
  • 다중화(Redundancy)
    • 클러스터링(Clustering) - DB 서버의 다중화
      • Active-Active
      • Active-StandBy
      • FailOver
    • 리플리케이션(Replication) - DB 서버와 데이터의 다중화
    • Shared Nothing - 성능을 추구하기 위한 다중화

책 데이터베이스 첫걸음 - 4장 데이터베이스와 아키텍처 구성을 정리한 내용입니다.

Clustering - DB 서버의 다중화


같은 시스템을 가진 - 예비장치 - 여러개를 준비해 시스템 일부에 장애가 발생해도 서비스를 계속 유지할 수 있도록 하는 것을 다중화라 부른다. 예비 1개를 두면 이중화, 2개를 두면 3중화, 흔히 다중화를 이중화라고도 한다.

DB 서버의 다중화

DB 서버는 다중화에서 특유의 어려운 문제를 안고 있다. 간단히 병렬화해서 대수를 증가시키는 웹 서버나 애플리케이션 서버와 비교하면 다중화에 대해 고민해야할 부분이 많은데 그 이유는 DB 서버가 데이터를 보존하는 영속(Persistence) 계층이기 때문이다.

DB와 다른 서버의 차이

데이터베이스는 데이터를 장기간 보존하는 매체가 필요하다. 이 점은 데이터를 일시적으로 처리할 뿐인 웹 / 앱 서버와 다른 점이다. 그래서 데이터를 유지하는 매체의 신뢰성이나 다중화에 그다지 신경 쓸 필요가 없다. 하지만 데이터베이스는 대량의 데이터를 영구적으로 보존해야 하고 그에 따른 성능도 요구되기 때문에 데이터를 보존하는 매체에 필요한 요건이 높다. 일반적으로 서버 내부의 로컬 저장소나 메모리로는 요건을 충족시키지 못하기 때문에 전용 외부 저장소를 사용해야한다.

결국 DB 서버의 아키텍처는 서버와 저장소를 묶어서 생각해야 한다.

가장 기본적인 다중화, 클러스터링

alt text

위 사진은 DB 서버와 저장소 각각 한 대로 구성되어 있다. 만약 DB 서버가 죽게 된다면 관련된 서비스 전체가 중단되버릴 것이다. 따라서 가장 간단한 방법으로 DB 서버만을 다중화하고 저장소는 하나만 두는 구성을 선택해보자. 이 경우 데이터가 보존되는 저장소가 1개라서 정합성은 신경 쓸 필요가 없다.

alt text

이러한 클러스터링에는 동시 가동 여부에 따라 다음 2가지로 나뉜다.

  • Active-Active 클러스터를 구성하는 컴포넌트를 동시에 가동

  • Active-Standby 클러스터를 구성하는 컴포넌트 중 실제 가동하는 것은 Active, 남은 것은 대기(Standby)

Active-Active

복수의 DB 서버가 동시에 동작하고 있는 구조

  • 장점

    • DB 서버가 여러 대라 1대에서 장애가 발생해도 처리를 계속 할 수 있다
    • DB 서버의 부하 분산: 나의 서버가 부담하던 부하를 두 개의 DB가 나눠서 감당하고, 각 DB 서버의 CPU나 메모리가 동시에 가동되므로 처리 성능이 향상된다

  • 단점

    • 저장소가 병목지점이 되어 생각만큼 성능 향상이 안 될 수 있다.
    • 비용이 크다.

Active-Standby

DB 서버 중 일부를 대기상태(Standby)로 두고 있다가 운영중인 서버(Active)에 문제가 생기면 준비상태에 있던 Standby 서버가 active 상태로 변경되면서, 서비스를 이어 운영하게 된다. 즉, Failover 기능을 통해 두 서버의 상태를 상호 전환함으로서 장애를 대응하는 방법이다.

  • 종류

    • Cold-Standby: 평소에는 Standby DB가 작동하지 않다가 Active DB가 다운된 시점에 작동
    • Hot-Standby: 평소에도 Standby DB가 작동

  • 장점

    • Active-Active의 저장소 병목 현상이 해결된다

  • 단점

    • Failover(예비 시스템으로의 자동 전환)가 이뤄지는 전환시간(수십 초 ~ 수분) 동안에는 서비스가 불가능해진다.

Standby DB 서버는 어떻게 Active DB 서버에서 장애가 일어난 것을 알아챌까?

Standby DB 서버는 일정 간격(수초 ~ 수십초)으로 Active DB에 이상이 없는지 조사하기 위한 통신을 한다. 이 통신을 ‘Heartbeat’라 한다. Active DB에서 장애가 발생하면 이 신호가 끊기기 때문에 ‘죽었다’라고 인지하게 된다. 헬스체크 개념과 상통하는듯.

Failover

페일오버란 장애 대비 기능을 의미한다. 실패(fail)를 끝내는(over)것이다. 시스템에 장애가 오면 미리 준비했던 다른 시스템으로 대체해서 운영하는 것이다.

alt text

정리

데이터베이스에서 가용성을 높이는 기술로 클러스터링과 레플리케이션으로 크게 나눌 수 있다. 클러스터링에는 ‘Active-Active’와 ‘Active-Standby’가 있으며, ‘Active-Active’는 DB 서버의 부하를 분산시키지만, 저장소가 병목 지점이 된다는 단점이 있다. 저장소라는 병목 지점이 생기는 것은 웹 서버와 애플리케이션 서버와는 다른 점인데, 이 때문에 데이터베이스가 성능 문제를 쉽게 일으킨다. ‘Active-Standby’ 구조로 병목 현상을 해소 시킬 수 있지만, failover가 이뤄지는 동안에는 서비스가 불가능하다는 단점이 있다.

Active-Active와 Active-Standby 클러스터 구성에서는 서버 부분은 다중화 할 수 있어도 저장소는 다중화하지 않는다는 공통적인 단점이 있었다. 저장소에 문제가 생긴다면 데이터를 잃고 말 것이다!.

DB 서버 뿐만 아니라 데이터도 다중화하는 ‘리플리케이션(Replication)’ 개념을 알아보자.

references

Failover - https://oriyong.tistory.com/80

[다음 포스트 보기] - Replication과 Shared Nothing

Related Posts