4장. 데이터베이스와 아키텍쳐 구성 - (1) 클러스터링

 

우리가 알고자 하는 데이터베이스의 아키택쳐는 다음과 같다.

데이터베이스 아키택쳐 패턴

이번 챕터에서는 데이터베이스의 클러스터링에 대해서 알아보며,

이번 포스팅에서는 Active - Active, Active - Stand by와 Shared Disk, Shared Nothing을 알아보도록 하자.

 

장애가 발생할 때마다 정지를 한다면 인프라로써 역할을 다하지 못할 것이다.

견고한 시스템을 구축하기 위해서는 다중화를 고려해야 하고 다중화를 하기 위해선 가용성을 고려해야 한다.

가용성을 높이기 위한 방법은 2가지가 있다.

 

1. 심장 전략

2. 신장 전략

 

이 전략들을 쉽게 예로 표현해보면 

 

신장은 한쪽에 문제 생겨도 다른 한쪽이 문제없다면 일상생활에 지장이 없다. (이식도 가능)

그러나 심장은 10초라도 정지한다면 목숨이 위태로울 정도로 중요한 급소이다.

그 대신 여간해선 쉽게 정지하지 않는 견고한 신뢰성을 갖추고 있다.

 

일상생활에서 우리는 열쇠를 잃어버리는 것을 대비해 여분을 가지지만 세탁기나 냉장고는 여분을 가지지 않는다.

가전제품은 비싼 만큼 신뢰성이 높다.

 

위 두 가지 예를 보면 심장 전략은 고품질의 소수 전략, 신장 전략은 저품질의 다수 전략이라고 말할 수 있다.

시스템 입장으로 돌아와서 시스템 다운을 방지하기 위해 우리는 주로 신장 전략을 사용하고 있다.

부품 한 개 한 개의 신뢰성을 최대로 올리는 것보다 저품질이라도 수로 보완하는 물량 작전을 사용하고 있다.

 

 

클러스터링

클러스터링이 나오게된 배경은 다음과 같다. '데이터 베이스 서버가 죽으면 어떻게 하지?'
이에 대한 해결 방법은 '데이터 베이스 서버를 여러개로 만들자!' 였으며 클러스터링을 고려하게 되었다.

신장 전략처럼 두대 이상의 서버를 동일한 기능을 처리하는 것처럼 보이도록 병렬화 하는 것을 클러스터링이라고 한다.

클러스터를 포도송이로 예를 들 수 있으며, 동일한 컴포넌트를 복수 개 준비해 하나의 목적(기능)에 맞게 실현하는 의미로 사용된다.

 

클러스터링을 통해 적어도 1대가 동작하고 있을 때 서비스를 계속할 수 있다고 간주한다면
DB 서버를 늘릴수록 장애 발생률이 줄어들게 된다.

 

다만, DB 서버는 다중화에 대해 어려운 문제점을 안고 있다.

서버를 병렬화해서 대수를 증가시키게 되면 각 DB 서버마다 데이터가 동기화되어 정합성이 지켜져야 하기 때문이다.

다중화로 된 구조가 있을 때 보통 Active - Active 구성과 Active - Stand by 구성으로 나누어볼 수 있는데
이 두 가지의 구성을 알아보고 다음 포스팅에선 정합성을 어떻게 맞춰나가는지는 알아보자.

 

 

Active - Active, Active - Stand by

가장 기본적인 다중화의 구조인 DB서버 2대, 저장소 1대가 있다고 가정하고 생각해보자.

 

이런 경우 데이터가 보존되는 저장소가 1개라서 정합성을 신경 쓸 필요가 없다.

이 2대가 동시에 동작하는 것을 허락할지 안 할지에 따라 Active - Active 구성과 Active - Stand by 구성으로 나뉜다.

 

Active - Active

클러스터를 구성하는 컴포넌트를 동시에 가동한다.

Active - Active 구성의 장점은 다음과 같다.

• 장점
  
  - DB 서버가 동시에 동작하고 있어 한 대가 다운되어도 남은 서버가 서비스를 지속적으로 운영할 수 있어
  사용자 입장에서 장애가 발생하더라도 체감하는 시스템 다운 시간이 짧다.
  
  
• 단점
  
  - 동시에 저장소가 사용됨으로써 저장소가 병목이 되는 현상이 발생할 수 있다.

Active - Active 구성이 가능한 DBMS는 Oracle과 DB2이며 Oracle은 RAC(Real Application Cluster)를 활용한다.

 

 

 

Active - Stand by

클러스터를 구성하는 컴포넌트 중 실제 가동하는 것만 Active, 나머지 것들은 대기 (Stand - by) 한다.

보통 StandBy 상태인 대기 서버는 사용되지 않다가 Active 서버가 장애 발생 시 사용된다.

상태가 전환될 때 시스템 다운 시간이 생기고 서비스를 계속하는 것이 불가능한 상태가 된다.

 

* Active - Stand by 구성에서 Active 서버가 장애 발생했을 때 Stand by 서버는 Active 서버가 장애가 발생했다는 걸
어떻게 알아차릴까?

 

바로 클러스터 HeartBeat 를 통해 알 수 있다.

Stand by 서버는 일정 간격 동안 Active 서버에게 이상이 없는지 통신을 한다.

Active 서버가 HeartBeat에 대한 반응이 없다면 죽은 것으로 간주한다.

 

Active - Stand by 구성은 두 가지의 종류로 구분된다. (성능은 큰 차이가 없다.)

• Cold - Stand by
  
  - 평소에는 Stand by 서버가 작동하지 않다가 Active 서버가 다운된 시점에 작동
  
  
• Hot - Stand by
  
  - 평소에도 Stand by 서버가 작동 
  - Cold - Stand by 보다 전환 시간이 짧음
  - 대신 라이선스 료가 높게 설정되어 있음 (Active - Active 보다 쌈)

 

 

Shared Disk, Shared Nothing

Shared Disk

앞서 설명한 것처럼 Active - Active 구성에는 여러 서버가 1대의 저장소를 공유하도록 구성되었기 때문에 병목현상이 발생할 수 있다. 이렇게 여러 대의 서버가 1대의 저장소를 사용하는 구성을 Shared Disk 라고 한다.

 

Shared Disk 타입인 Active - Active 구성에는 DB 서버를 늘려도 저장소가 공유 자원이라 쉽게 늘리기 어렵고

DB 서버 대수가 증가할수록 DB 서버 간의 정보 공유를 위한 오버헤드가 큰 단점이 존재한다.

이런 단점을 보완하고자 고안된 아키택쳐는 Shared Noting이다.

 

 

Shared Nothing

Shared Nothing은 말 그대로 아무것도 공유하지 않는다. 즉, 자원을 분리하는 것이다.

이 아키택쳐는 서버와 저장소를 세트로 묶어 늘리면 저장소가 병목이 되는 것을 방지하고 있어 성능이 향상되는 장점이 있다. Shared Nothing 구조를 샤딩이라고도 부른다.
(데이터가 너무 많아서 느린 검색을 더 빠르게 개선하는 방법도 샤딩이라고 한다.)

 

Shared Nothing의 단점은 저장소가 공유되지 않아 데이터의 정합성을 맞춰야 하며
이런 구조는 복잡한 구조라는 것이 단점이라고 할 수 있다.

[DB 서버 + 저장소] 세트를 갖춘 Shared Nothing 구성에서 만약 Active 서버가 다운이 되면

Active 서버의 저장소에 접근할 수 있는 서버는 Active 서버밖에 하지 못한다.

이런 문제에 대처하려면 DB 서버 하나가 다운되었을 때 다른 DB 서버 + 저장소 세트가 이를 이어받아
계속 처리할 수 있는 커버링(Covering) 구성을 고려해야 하므로 보기보다 구조가 복잡하다는 단점이 있다.

---

이번 포스팅에서는 데이터베이스 클러스터링을 간략하게 알아보았다.

가용성과 확장성, 성능 등을 고려하고 구축한 아키택처가 후에 변경이 되어야 한다면

매우 어려운 작업일 것이라고 예상이 된다.

이런 작업을 없게 하기 위해 공부를 해가며 데이터베이스 아키택쳐를 익혀야겠다.

 

다음 포스팅은 리플리케이션, MMM, MHA에 포스팅할 것이다.