데이터베이스와 아키텍쳐 구성

아키텍쳐

시스템을 만들기 위한 물리 레벨의 조합, 하드웨어와 미들웨어의 구성을 시스템이 완수해야 할 목적과 비교하면서 결정해가는것.

시스템에 요구되는 조건을 충족하기 위해 어떤 아키텍처가 적당할지를 고려하지 않으면 시스템 구축에 걸리는 비용 산출이 불가능

아키텍처의 역사

1. Stand-alone (~1980년대) : 데이터베이스만으로 시스템이 성립하는 가장 간단한 구성.

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

3. Web 3계층 (2000년~현재) : 현재 주류, 클라이언트/서버 발전시킨 구성

1. Stand-alone

LAN이나 인터넷 등의 네트워크에 접속하지 않고 독립되어 동작하는 구성

데이터베이스의 미들웨어(DBMS)와 애플리케이션의 소프트웨어가 같은 DB서버에서 동작

네트워크 액세스가 불가능하므로 데이터베이스 사용자는 DB서버가 설치된 물리적인 장소까지 접근하여 서버 앞에서 DB를 이용해야했다.

단점 

1. 물리적으로 떨어진 장소에서 접근 불가

2. 서버 사용자가 1인으로 제한됨. 동시 작업 불가

3. 가용성이(Availability) 낮다. 서버가 한 대 뿐이므로 한대가 고장나면 서비스 정지

4. 확장성(Scalability) 부족. 머신 자체 성능을 올리는 것 이외에 개선 수단이 없다.

 

장점

1. 구축이 매우 간단

2. 보안이 매우 높다.

2. 클라이언트/서버 

서버 한 대에 복수 사용자의 단말이 접속하는 구성. 'C/S'나 '클라 서버' '2계층 구조'로 부르기도 함

DB서버에서는 DBMS가 동작하고 클라이언트에서는 업무 애플리케이션이 동작하는 분업체제

이 구성은 주로 기업이나 조직 내에 닫힌 네트워크(LAN)에서 이용됨

3. Web 3계층

EC(Electric Commerce) 사이트(Amazon, 라쿠텐 등)나 SNS, 등 온갖 서비스사 인터넷을 통해 제공되는 시대

클라 서버 구성의 문제점

1. 인터넷에서 직접 DB 접근하는 것에 대한 보안 위험

2. 불특정 다수의 클라이언트로 인한 어플리케이션 관리 비용 증가

Web 3계층

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

클라 서버 구성과 다른 점 : 웹 서버 계층/ 애플리케이션 서버 계층 존재

• 웹 서버 : 

애플리케이션 서버와 클라이언트 웹 브라우저 간의 가교 역할 ex) Apache, IIS(Internet Information Service)

• 애플리케이션 서버 : 

비즈니스 로직을 구현한 애플리케이션이 동작하는 층. 웹서버로부터 연계된 요청 처리. 

필요시 DB서버에 접속하여 데이터 추출, 가공하여 웹서버로 반환  ex) Tomcat, 웹로직, 웹스피어 등

-> 접속요청 받는 역할을 웹서버로 한정하여 보안 높임

-> 비즈니스 로직을 애플리케이션 계층에 집중시켜 애플리케이션 관리 비용 낮추는 구성

데이터베이스의 아키텍쳐

가용성과 확장성의 확보

가용성을 높이는 전략

심장 전략 : 고품질-소수전략, 시스템을 구성하는 각 컴포넌트의 신뢰성을 높여 장애 발생률을 낮춘다.

신장 전략 : 저품질-다수전략, 여분 준비, 물량 작전 // 현재는 거의 신장전략 노선

클러스터

클러스터링(Clustering) : 동일한 기능의 컴포넌트를 병렬화하는 것

클러스터 구성으로 시스템의 가동률을 높인다 = 여유도(Redundancy)를 확보한다. = 다중화

단일 장애점(SPOF, Single Point of Failure)

다중화되어있지 않아서 시스템 전체 서비스의 계속성에 영향을 주는 컴포넌트

단일 장애점의 신뢰성이 전체의 가용성을 결정

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

DB서버의 다중화

DB서버는 데이터를 영구적으로 보존하고 그에 따른 성능도 요구된다. 

서버 내부의 저장소, 메모리로는 이런 요건을 충족시킬 수 없어서 전용 외부 저장소를 이용해야하므로

DB서버 아키텍쳐는 저장소와 묶어서 생각해야 한다.

데이터는 항상 갱신되기 때문에 다중화를 유지하는 중에 '데이터 정합성'도 중요

Shared Disk 구성(가장 기본적인 다중화) : DB 서버만 다중화하고 저장소는 하나만

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

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

저장소를 공유한 Active-Active 구성이 가능한 DBMS는 현재 IOracle과 DB2

Active-Active 구성

장점

1. 시스템 다운 시간이 짧다 :  복수의 DB서버가 동시 동작하여 한 대가 다운돼도 남은 서버가 처리를 이어감

2. 성능이 좋다 : DB서버 대수가 증가하면서 가동하는 CPU나 메모리도 증가, 단 저장소가 병목이 되어 생각만큼 눈에 띄게 향상되지 않는 경우도 있다.

Active-Standby 구성에서는 보통 Active DB서버에 장애가 일어날 때만 Standby DB서버 사용. 

(Standby DB서버는 일정 간격으로 Active DB에 이상이 없는지를 조사하기 위한 통신(Heartbeat)을 함)

이 때문에 전환될 때까지 시차(보통 수십초에서 수 분)가 생기고 그동안 시스템 서비스 다운상태가 된다.

Active-Standby 구성의 종류(성능에는 차이가 없다)

Cold-Standby 

Hot-Standby : 평소에도 Standby DB가 작동

가용성과 성능 순으로 정리하면 1. Active-Active  2. Active-Standby( Hot ) 3. Active-Standby( Cold )

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

리플리케이션(Replication)

저장소 하나에 여러 서버를 연결한 기본적인 다중화 Active-Active와 Active-Standby구성은 

저장소 부분은 다중화 X 데이터는 다중화하지 않는다. 즉, 저장소가 부서질 경우엔 데이터를 잃게 된다.

이러한 경우에 대응하기 위한 클러스터 구성이 리플리케이션 : DB서버 - 저장소 세트를 복수로 준비

디스크를 다중화하는 RAID

RAID : 저장소 내부의 컴포넌트(대부분 하드웨어)를 다중화하는 기술(단일 장애점을 없앤다). 

몇 가지 종류가 있지만 기본적으로 디스크를 별렬로 나열해 디스크 하나가 망가져도 데이터 소실을 막는 방식.

저장소 내부에도 RAID가 쓰인다.

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

Standby 측 데이터도 갱신을 반영하여 최신화(동기화, Syc)하지 않으면 Active 측과의 데이터 정합성을 유지할 수 없다.

이 갱신 주기와 성능 사이가 트레이드오프 관계

리플리케이션 구성은 손자나 증손자 세트를 만들 수 있다. 

이러한 피라미드형 리플리케이션은 부모에 걸리는 부하를 분산시킬 수 있지만 

DB서버 라이선스료, 성능, 저장소 비용, 시스템 구성 노력도 증가한다.

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

서버와 저장소의 세트를 늘리면 병렬처리 때문에 선형으로 성능이 향상된다. 

단점 : DB서바가 동일한 1개의 데이터에 액세스할 수 없어서 각 세트로부터 데이터를 모아서 집계하는 정리 서버가 필요

또한 서버 하나가 다운 되었을 때 다른 서버가 이를 이어받아 계속 처리할 수 있도록하는 Covering 구성을 고려해야힘.