데이터베이스 첫걸음 4장] 데이터베이스와 아키텍쳐 구성

##본 포스팅은 "데이터베이스 첫걸음 - 미크, 기무라 메이지" 책을 보고 요약한 것입니다.

 

다중화

데이터베이스는 견고하게 유지되는 것이 중요하다.
이에 중요하게 여겨지는 것이 '다중화'에 대한 고려이다.

예를 들어, DB 서버가 2대 있다면 1대가 고장난다 하더라고 나머지 1대가 동작하면 서비스의 정지를 막을 수 있는데, 이를 '다중화' 또는 '고가용성'이라고 부른다.

 

아키텍처

'아키텍처'란 말은 다양한 의미가 있지만, 주로 '시스템을 만들기 위한 물리 레벨의 조합' 또는
'어떤 기능을 가진 서버를 준비하고 어떤 저장소나 네트워크 기기를 조합해서 시스템 전체를 만들 것인가'
즉 하드웨어와 미들웨어의 구성을 가리킨다.

이 구성을 시스템이 완수해야 할 목적과 비교하면서 결정하는 것이 '아키텍처 설계'이다.

<중요성>
'돈'의 영역과도 밀접한 관련이 있다.
모든 시스템은 예산 제약이라는 한계 속에서 만들어져 운영되기 때문에 고기능의 시스템을 만들려고 한다면 예산 초과로 좌절하기도 한다.
한마디로 '시스템에 요구되는 조건을 충족하기 위해 어떤 아키텍쳐가 적당할까'라는 것은 중요하다.

<아키텍처의 역사>
1) Stand-alone
: 데이터베이스만으로 시스템이 성립하는 가장 간단한 방법
LAN이나 인터넷 등의 네트워크에 접속하지 않고 '독립되어' 동작
데이터베이스의 미들웨어(DBMS)와 어플리케이션의 소프트웨어는 같은 DB 서버에서 동작

*단점
- 물리적으로 떨어진 장소에서는 접근 못함
- 복수의 사용자가 동시 작업 못함
- 가용성 낮음 : 서버가 1대라서 장애가 발생하면 서비스 정지
- 확장성 부족(네트워크 연결이 해결책)

* 장점
- 구축이 매우 간단해서 소규모 작업에 적절
- 네트워크 연결점이 없어 보안이 높음

2) 클라이언트/서버
클라이언트와 서버로 계층을 분리하여 상호 간에 네트워크로 접속
데이터베이스 서버 1대에 복수 사용자의 단말이 접속하는 구성
클라이언트와 서버의 2개 레이어로 구성되어, '2계층 구성'이라고도 부름
DB 서버에서는 DBMS가 동작하고, 클라이언트에서는 업무 어플리케이션이 동작하는 분업체제

이 구성은 주로 기업이나 조직 내에 닫힌 네트워크에서 이용되었고,
인터넷 등 외부 네트워크를 거쳐 데이터베이스 서버에 사용자가 접속하는 일은 없었다.

*단점
- 네트워크 접촉점을 이용한 보안 위험
- 불특정 다수의 사용자를 대비한 높은 관리 비용

 

3) Web 3계층
비즈니스 로직을 실행하는 어플리케이션을 서버에서 관리하여 비용을 절감하자는 요구로 나온 구성

클라이언트와 데이터베이스 계층 사이에 '웹 서버 계층'과 '어플리케이션 계층'이 추가됨
웹 서버는 클라이언트로부터 접속 요청을 직접 받아서 그 처리를 뒷단의 어플리케이션 계층에 넘기고, 결과를 클라이언트에 반환

*어플리케이션 계층 : 비즈니스 로직을 구현한 어플리케이션이 동작하는 층으로, 웹 서버로부터 연계된 요청을 처리하고 데이터베이스 계층에 접속하여 데이터를 추출하고 이를 가공한 결과를 웹 서버로 반환

이처럼 사용자로부터 직접적인 접속 요청을 받는 역할을 웹 서버 계층에 한정하여 어플리케이션 계층과 데이터베이스 계층의 보안을 높일 수 있다. 동시에 어플리케이션 계층에 비즈니스 로직을 집중하여 어플리케이션 관리 비용을 낮추는 구성이 될 수도 있다.

우리가 보통 개발을 진행한다면 먼저 위 Web 3계층을 전제로 논의가 진행될 것이다.

 

데이터베이스의 아키텍처

아키텍쳐 설계에서 견고한 시스템을 만들기 위해 가장 중요한 점이 가용성이다.

그렇다면 어떻게 시스템의 가용성을 담보할까?

<가용성 높이는 전략>
1) 심장전략
: 시스템을 구성하는 각 컴포넌트의 신뢰성을 높여 장애 발생률을 낮게 억제하여 가용성을 높임(소수정예 노선)

2) 신장전략
: 시스템을 구성하는 각 컴포넌트의 신뢰성을 계속해서 높이기보다는 '사물은 언젠가 망가진다'라는 체념을 전제로 여분을 준비(물량작전)
- 현재 주로 사용되는 전략
- 컴포넌트 병렬화 == '클러스터링'

< 클러스터링>
시스템 세계에서는 '동일한 기능의 컴포넌트를 복수 개 준비하여 한 개의 기능을 실현한다'는 의미로 사용한다.

또한 클러스터 구성으로 시스템의 가동률을 높이는 것도 '여유도를 확보한다' 또는 '다중화'라고 지칭한다.

하지만, 컴포넌트를 어느정도 병렬로 추가해도 시스템 가동률은 100%가 되지 않으며,
서버 대수가 증가하면 증가할 수록 1대를 추가함에 따라 얻을 수 있는 가동률의 향상 폭이 작아진다.

다중화되어있지 않아서 시스템 전체 서비스의 계속성에 영향을 주는 컴포넌트를 '단일 장애점'이라고 한다.

서버나 네트워크 기기 등 시스템을 구성하는 컴포넌트가 증가하면 당연히 돈이 더 든다.
따라서 모든 문제는 예산 제약 내에서 해결하지 않으면 안된다.

 

DB 서버의 다중화 - 클러스터링

DB 서버는 서버가 데이터를 보존하는 '영속 계층'이기에, 클러스터링이 어려운 컴포넌트로 인식되었다.

데이터베이스는 데이터를 장기간 보존하는 매체가 필요하며, 그에 따른 성능도 요구된다.
'다중화'를 유지해야하며, 유지하는 도중에 '데이터 정합성'도 중요시해야 한다.

<가장 기본 구성>

DB 서버가 2대 있지만, 이 2대가 동시에 동작하는 것을 허락할지에 따라 분류할 수 있다.

• 1) Active-Active : 클러스터를 구성하는 컴포넌트를 동시에 가동
  - 시스템 다운 시간이 짧음
  복수의 DB 서버가 동시에 동작하고 있어 한 대가 다운되어도 남은 서버가 계속 처리 가능하다.
  - 성능이 좋음
  DB 서버 대수가 증가하면 동시에 가동하는 CPU나 메모리도 증가하기 때문에 성능도 향상된다.
  
  단, 병목 현상이 발생할 수도 있다.
  
  
• 2) Active-Standby : 하나만 가동, 남은 하나는 대기하고 있다가 장애가 발생하면 가동
  - 전환 시, 시차가 생기고 서비스 다운 상태가 됨
  - 분류
     a. Cold-Standby : 평소에는 작동하지 않다가, 액티브가 다운되면 작동
     b. Hot-Standby : 평소에도 stanby가 작동(사치)

 

DB 서버와 데이터의 다중화 - 리플리케이션

Active-Active와 Active-Standby 클러스터 구성에서는 서버 부분은 다중화할 수 있어도 '저장소 부분'은 다중화할 수 없어서 데이터를 다중화하지 않는 공통적인 단점이 있다.

단점은 저장소가 부서질 경우에는 데이터를 잃게 된다는 것이다.

이런 상황에 대응하기 위한 클러스터 구성이 '리클리케이션'이다.
이는 DB 서버와 저장소 세트를 복수로 준비하는 것을 말한다.

<리플리케이션에서 주의할 점>
중요한 점은 Active 측 저장소의 데이터는 항상 사용자로부터 갱신된다는 것이다.
이 때문에, Standby 측 데이터에도 갱신을 반영하여 최신화하지 않으면 Active측과의 데이터 정합성을 유지할 수가 없다.

쉽게 말해 Standby측의 데이터는 점점 과거의 것이 된다.

이 리플리케이션 구성은 원칙적으로는 차례로 손자나 증손자 세트를 만들 수 있으며, 이를 '피라미드형'이라고 한다.
피라미드형 리플리케이션은 데이터가 오래되도 참조만 하면 된다는 처리를 손자나 증손자 세트에 하기 때문에 편리하며, 이를 통해 부모에게 걸리는 부하를 분산할 수 있다.

 

성능을 추구하기 위한 다중화 - Shared Nothing

앞서 Active-Active 구성의 DB는 저장소 부분이 병목되는 경우가 있는데, 이는 복수의 서버가 1대의 저장소를 공유(Shared Disk)하기 때문이다.

이를 해결하기 위해 고안된 것이 바로 'Shared Nothing'이다.
그대로 아무것도 공유하지 않는다란 의미로 네트워크 이외의 자원을 모두 분리하는 방식이다.

이 아키텍처는 서버와 저장소의 세트를 늘리면 병렬처리 때문에 선형적으로 성능이 향상되는 장점이 있다.

(구글에서 개발한 Shared Nothing 구조를 샤딩(Shading)이라고 부른다)

Shared Nothing 방식은 같은 구성의 DB 서버를 횡으로 나열하기 때문에 구조가 간단하며 원칙적으로 DB 서버 수에 비례해서 저장소가 늘어간다.
하지만 저장소를 공유하지 않는다는 의미는 결국 각각의 DB 서버가 동일한 1개의 데이터에 액세스할 수 없다는 뜻이기에,
이런 문제에 대처하려면 DB 서버 하나가 다운되었을 때 다른 DB 서버가 이를 이어받아 계속 처리할 수 있게 하는 '커버링 구성' 등을 고려해야 한다.

 

아키텍처 총정리