데이터베이스 첫걸음 | 4장

4장. 데이터베이스와 아키텍처 구성

견고하고 고속의 시스템을 구축하기 위해

1. 데이터베이스 아키텍처
2. 클러스터링
3. 리플리케이션
4. 샤딩

 

데이터베이스의 아키텍처

💡 아키텍처란

시스템을 만들기 위한 물리 레벨의 조합

➡️ 하드웨어와 미들웨어의 구성 = 어떤 기능을 가진 서버를 준비하고 어떠한 저장소나 네트워크 기기와 조합할 것인지?

 

데이터베이스 아키텍처 패턴

1. 역사와 개요

아키텍처의 역사

'아키텍처'라는 말은 추상적이어서 딱 들었을 때 이미지를 떠올리기가 쉽지 않다.

그래서 구체적인 시스템 구성을 예로 들어보려고 한다.

 

데이터베이스에 관한 아키텍처의 역사는 다음 3단계로 나누어진다.

1) Stand-alone (~1980년대)

2) 클라이언트/서버 (1990년대~2000년)

3) Web 3계층 (2000년~현재)

---

1) Stand-alone

• 특징
  • 데이터베이스가 동작하는 머신이 LAN이나 인터넷 등의 네트워크에 접속하지 않고 독립되어 동작하는 구성
  • DBMS와 애플리케이션의 소프트웨어는 같은 DB 서버에서 동작 → 사용자는 물리적으로 DB 서버가 설치된 장소까지 접근해야 함
• 장점
  • 구축이 간단해서 소규모 작업이나 테스트에 적합
  • 보안이 매우 높음 (아무도 만나지 않으면 전염병 감염의 위험이 낮은 것과 같음)
• 단점
  • 물리적으로 떨어진 장소에서 접근할 수 없다
  • 복수 사용자가 동시에 작업할 수 없다
  • 가용성이 낮다
  • 확장성이 부족하다 (서버가 성능의 한계에 달하는 경우 머신 자체 성능을 올리는 것외에 개선 수단이 없다)

 

2) 클라이언트/서버

• 특징
  • DB 서버 1대에 복수 사용자가 접속하는 구성
  • C/S, 클라 서버 또는 2계층 구성이라고 부르기도 함
• 확장
  • 기업이나 조직 내 닫힌 네트워크에서 이용되어 외부를 거쳐서 접속하는 일은 없었음
  • 조직 내에서 제한된 용도의 시스템으로 이용됨
  • 인터넷 시대에는 결정적으로 부적합한 몇 가지 단점을 가지고 있음
• 단점
  • 보안 위험 : 인터넷에서 직접 DB에 접속하기 때문에
  • 관리비용 문제 : 클라이언트마다의 환경을 고려해서 애플리케이션을 배포하기 어려움 → Web 3계층 제시됨

 

3) Web 3계층

• 웹 서버 + 애플리케이션 서버 + 데이터베이스 서버
• 웹 서버
  • 클라이언트로부터 HTTP 요청을 받아서 애플리케이션 서버로 넘기고 결과를 클라이언트에 반환
  • Apache, IIS
• 애플리케이션 서버
  • 비즈니스 로직을 구현한 애플리케이션이 동작
  • 웹 서버와 연계된 요청을 처리하고 필요하면 DB 서버에 접속해서 데이터 추출하고 결과를 웹 서버로 반환
  • Tomcat, WebLogic, WebSphere
• 특징
  • 사용자로부터 직접적인 접속 요청 → only 웹 서버 : 애플리케이션과 데이터베이스 계층의 보안이 높아짐
  • 애플리케이션 계층에 비즈니스 로직 집중 → 애플리케이션 관리 비용이 낮아짐
  • 현재 웹 시스템에서의 표준

 

2. 가용성과 확장성의 확보

🧐 어떻게 하면 정지하지 않는 시스템을 만들 수 있을까?

 

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

 

가용성을 높이는 2가지 전략

• 심장전략 : 시스템을 구성하는 각 컴포넌트의 신뢰성을 높여 장애 발생률을 억제해서 가용성을 높임 (고품질-소수전략)
• 신장전략 : '사물은 언젠가 망가진다'는 전제로 여분을 준비해 둠, 물량작전 (저품질-다수전략)
• 관계
  • 현재는 신장전략 노선 위주, FT 서버 등에서는 심장전략 이용 중
  • 심장전략과 신장전략은 중첩되며, 심장전략도 사실은 신장전략에 의해 실현되는 중

💡 클러스터란

• 동일한 기능의 컴포넌트를 복수 개 준비해 한 개의 기능을 실현
• 신장전략처럼 동일한 기능의 컴포넌트 병렬화하는 것 → 클러스터링
• 클러스터 구성으로 시스템의 가동률을 높이는 것 → 여유도(Redundancy)를 확보한다, 다중화

예를 들어, 어떤 서버의 고장률이 10%라고 하자.

시스템 전체 장애 발생률은 전 서버가 동시에 고장났을 때 한하기 때문에

서버가 증가할수록 장애 발생률은 아래와 같이 줄어든다.

• 서버 1대 = 10% (0.1)
• 서버 2대 = 1% (0.1 * 0.1)
• 서버 3대 = 0.1% (0.1 * 0.1 * 0.1)

💡 가동률 = 100% - 장애 발생률

 

 

💡 단일 장애점이란

SPOF(Single Point of Failure), 다중화되어 있지 않아서 시스템 전체 서비스의 계속성에 영향을 주는 컴포넌트

쇠사슬의 강도는 가장 약한 고리의 강도로 결정된다 = 단일 장애점의 신뢰성이 시스템의 전체의 가용성을 결정한다

 

신뢰성과 가용성

신뢰성 : 하드웨어나 소프트웨어 고장 빈도를 나타내는 개념 → 시스템을 구성하는 컴포넌트에 대해 

가용성 : 사용자 입장에서 볼 때 시스템을 어느정도 사용할 수 있는지 → 시스템 전체에서 사용자 눈높이에 맞춰 생각

→ 신뢰성이 낮은 컴포넌트를 사용한다 하더라도, 다중화한다면 시스템 전체의 가용성을 높일 수 있다.

 

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

💡 다중화란

고가용성(HA)이라고 부르기도 하는데,

예를 들면 DB 서버 2대에서 1대가 고장이 나도 나머지 1대가 동작하도록 해서 서비스의 정지를 막는 것과 같다.

 

DB 서버의 다중화

DB 서버는 오랫동안 클러스터링이 어려운 컴포넌트로 인식됨

데이터를 보존하는 영속(Persistence) 계층이기 때문에

 

DB와 다른 서버의 차이

1. 웹 서버, 애플리케이션 서버 : 일시적인 처리
2. DB서버 : 대량의 데이터를 영구적으로 보존해야 하고 그에 따른 성능도 요구되어 필요 요건이 높음

DB서버(계산이나 업무 로직 처리)의 아키텍처는 저장소(데이터 보존)와 묶어서 생각

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

 

가장 기본적인 다중화

가장 간단한 다중화 구성 = DB 서버 여러개 + 저장소 1개

 

1) Active-Active

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

• 장점
  • 시스템 다운 시간이 짧음 : DB 서버 여러 대가 동시에 동작하고 있어서 1대가 다운되더라도 남은 서버가 처리를 계속해 시스템 전체가 정지하는 것을 방지
  • 성능이 좋음 : DB 서버 대수가 증가하면 동시에 가동하는 CPU나 메모리도 증가해서 성능도 향상됨 (저장소가 버틀넥이 되기 때문에 생각만큼 향상되지 않기도..)
  • Oracle RAC(Real Application Clusters), DB2 pureScale
• 단점 : 비싸다

💡 Heartbeat이란

Standby DB 서버에서 일정 간격으로 Active DB에 이상이 업는지 조사하기 위한 통신

 

2) Active-Standby

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

• Cold-Standby : 평소에는 Standby DB가 작동하지 않다가 Active DB가 다운된 시점에 작동
• Hot-Standby : 평소에도 Standby DB가 작동하는 구성
  • 전환 시간이 짧은 만큼 라이선스료가 높음 (Active-Active보다는 저렴)

가용성과 성능이 좋은 순서

1. Active-Actvie
2. Active-Standby (Hot-Standby)
3. Active-Standby (Cold-Standby)

 

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

💡 리플리케이션이란

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

• Active-Active, Active-Standby 클러스터는 서버는 다중화할 수 있지만, 저장소는 다중화하지 않는 단점을 보완
• 저장소도 내부 컴포넌트가 다중화되어 있지만(RAID), 리플리케이션은 재난 상황을 대응하기 위한 클러스터 구성임
  • DB서버와 저장소가 동시에 사용 불능일 때, 서비스를 지속하는 것이 가능하다는 점에서 가용성이 높은 아키텍처
• Oracle Data Guard, DB2 HADR, MySQL(부하 분산용에 가까움)

 

💡 RAID란

Redundant Array of Independent Disks, 저장소 내부의 컴포넌트를 다중화하는 기술

기본적으로 클러스터링과 동일하게 단일 장애점을 제거하여, 디스크를 병렬로 나열해 한개가 망가져도 데이터 소실이 발생하지 않도록 함

 

리플리케이션에서 주의할 점

• Active와 Standby 저장소의 데이터 정합성을 유지할 것
  • Active 측 저장소의 데이터 - 항상 사용자로부터 갱신됨 → Standby 측 데이터를 늘 최신화하지 않으면 정합성이 깨짐
  • 최신화를 위한 동기화를 일정 주기로 할 때, 갱신 주기를 얼마로 할 것인가와 성능 사이에 트레이드 오프 발생
• 구성을 피라미드형으로 (= 손자나 증손자 세트를 만드는 것)
  • 데이터가 오래 되어도 참조만 하면 된다는 처리를 손자나 증손자 세트에서 하여 부모에 걸리는 부하를 분산함

 

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

💡 Share Disk란

• Active-Active 구성 DB = 여러대의 DB서버가 1대의 디스크 저장소를 공유 → 저장소 부분에서 병목이 발생한다.
• DB서버를 늘려도 처리율이 언젠가 한계점에 도달한다.
  • 저장소는 공유 자원이라서 쉽게 늘리기 어렵고, DB서버 대수가 증가할수록 DB 서버 간의 정보공유를 위한 동기화 오버헤드가 발생하기 때문

 

💡 Share Nothing이란

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

• 장점 : 서버와 저장소 세트를 늘리면 병렬처리 때문에 성능이 선형적으로 향상
• 단점 : 각각의 DB 서버가 동일한 1개의 데이터에 액세스할 수 없음 → 커버링 구성을 고려해야 함
• Google이 개발한 Shared Nothing 구조 = 샤딩(Sharding)

 

정리

가용성, 신뢰성, 재해대책, 성능, 보안 같은 비기능적인 요건에 대해서도 고려

아키텍처는 변경이 어렵기 때문에 신중히 결정

고기능의 아키텍처를 채용한다면 예산, 시간과 인적 자원 같은 제약 요건도 생각