[ DB ] 아키텍처 설계, 어떻게 들어가야할까?

최근 한빛미디어에서 나온 데이터베이스 첫걸음이라는 책을 읽고 있다.

이 책을 읽으며 내가 기록하고 싶은 것들을 기록해나가겠다.

 

나는 현재 회사에서 서버 이전 작업중이다.

그러면서 기존 db를 전부 분리하고, table 설계를 다시 하는 등의 작업을 예상하고 있다.

 

그래서 이 책을 집어들었다.

 

 

아키텍처는 어떻게 우리에게 왔는가 - 아키텍처의 역사

 

 

사실 아키텍처라는 단어 자체가 굉장히 추상적이다.

이를 이해하기 위해 역사를 좀 되짚어보자.

 

stand-alone 구조

 

초기에는 DB 서버가 네트워크에 접속하지 않고 독립되어 동작했다.

이러한 구성에서는 DBMS(데이터베이스 미들웨어)와 애플리케이션 소프트웨어는 같은 DB 서버에서 동작한다.

그렇기 때문에 내가 DB를 쓰고 싶으면, 물리적으로 그 DB에 가야지만 사용할 수 있었다.

 

클라이언트/서버 구조

 

드디어 네트워크를 이용해 데이터베이스 서버 1대에 복수 사용자 단말이 접속하기 시작했다.

서버에서는 DBMS가 동작하고, 클라이언트에서는 업무 애플리케이션이 동작하는 분업체계가 마련된 것이다.

 

 

Web 3계층

 

클라이언트/서버 구조에서는 클라이언트에 설치되어 있는 애플리케이션이 각기 다르다는 문제점이 있었다.

이 애플리케이션은 버전 관리, 버그 수정 버전을 배포하는데 엄청난 비용이 필요하다.

때문에 비즈니스 로직을 실행하는 애플리케이션을 서버에서 관리해 비용을 절감하기 시작했다.

Web 3 계층은 이를 위해 제시된 것이다.

 

Web 3계층의 3가지 계층은 아래와 같다.

 

• 웹 서버 계층
• 애플리케이션 계층
• 데이터베이스 계층

 

웹 서버는 클라이언트로부터 접속 요청을 받아 처리를 애플리케이션 서버에 넘기고 그 결과를 반환한다.

애플리케이션 계층은 요청을 받는 역할을 웹 서버 계층해 한정해 애플리케이션 계층과 데이터베이스 계층의 보안을 높인다.

 

 

 

가용성과 확장성, 어떻게 높일까?

 

이번 카카오 사태를 보면서 우리 회사에서도 가용성에 대해 다시한번 생각해보게 되었다.

 

 

가용성을 높이려면 '심장전략' 과 '신장전략' 을 먼저 고려해야한다.

 

심장전략은 고품질 소수전략으로, 시스템을 구성하는 각 컴포넌트의 신뢰성을 높여 장애 발생률을 낮게 억제한다.

신장전략은 저품질 다수전략으로, '사물은 언젠가 망가진다' 라는 생각을 전제로 여분을 준비한다. 물량 작전인 것이다.

 

나는 학생 때 볼펜이 고장날 때를 대비해서 항상 여분을 들고다녔다. 물량 작전이다.

하지만 세탁기가 고장날 때를 대비해 세탁기 여분을 준비해놓진 않는다. 뭐, 이런 것이다!

 

 

클러스터?

 

신장 전략처럼 동일한 기능의 컴포넌트를 병렬화하는 것을 '클러스터링'이라고 한다.

이러한 클러스터들의 구성으로 시스템의 가동률을 높이는 것을 'Redundancy(여유도)를 확보한다' 또는

'다중화' 라고 칭한다.

 

단일 장애점? (SPOF)

 

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

쇠사슬의 강도는 가장 약한 고리의 강도로 결정된다는 말 처럼,

단일 장애점의 신뢰성이 시스템 전체의 가용성을 결정한다.

 

 

 

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

 

이제 드디어 DB와 관련된 얘기를 해보겠다.

DB는 데이터를 보존해야하는 영속 계층이기 때문에, 다중화에 대해 고민이 더욱 더 필요하다.

 

데이터는 항상 갱신되기에 다중화를 유지하는 중에 '데이터 정합성'도 중요하게 의식해야한다.

 

기본 다중화

 

가장 간단한 다중화 구성은 DB 서버만 다중화하고, 저장소는 하나만 두는 구성이다.

이는 저장소가 1개라 정합성을 신경쓸 필요가 없다.

 

DB 서버가 2대지만,

이 두 대를 동시에 실행하는 Active-Active 와 하나는 실행, 하나는 대기 시켜놓는 Active-Standby 중 선택해야한다.

 

+ 현재 Active-Active 를 지원하는 DB는 Oracle과 DB2 뿐이라고 한다.

 

 

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

 

DB서버와 저장소 세트를 복수로 준비하는 것이다.

리플리케이션은 저장소와 db 서버가 동시에 사용불능일 때 다른 세트가 존재한다면

서비스를 계속하게 하는것이 가능해 가용성이 매우 높은 아키텍처이다.

 

이 단단함 덕분에 재난 복구 계획으로 이용되는 경우도 있다.

 

리플리케이션에서 중요한 점은 Active 측 저장소의 데이터와 Standby 저장소와의 동기화다.

항상 최신화하지 않으면 데이터 정합성을 유지할 수 없다.

 

 

성능을 추구하는 다중화 - Shared Nothing

 

복수의 서버가 1대의 디스크를 사용하는 구성을 Shared Disk 라고 부른다.

이 구성의 Active-Active 구성은 DB 서버를 늘려도 어느 순간 한계가 온다.

DB 서버 대수가 증가할 수록 이 서버간 정보 공유를 위한 오버헤드가 커지기 때문이다.

 

이를 해결하기 위한 아키텍처로 고안된 것이 'Shared Nothing' 이다.

아무것도 공유하지 않는다는 의미로, 네트워크 외의 자원을 모두 분리하는 방식이다.

 

구글은 이를 '샤딩'이라고 칭한다. 어디서 많이 들어본 단어다.

 

 

 

아키텍처를 고르는 것은 시스템이 어떤 요건을 충족시켜줘야하는지에 따라 달라지기 때문에

그 요건을 결정하지 않으면 아키텍처도 결정할 수 없다는걸 기억하자.