아키텍쳐란

아키택쳐라는 말은 여러 의미가 있지만 주로

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

• 시스템의 목적과 기능

이라는 의미로 쓰인다.

아키텍쳐 설계

아키텍쳐 설계는 매우 심도있는 영역이여서 서버, OS, 기타 미들웨어, 저장소, 로드벨러서나 방화벽 같은 네트워크 기기까지 폭넓은 지식을 요구한다.

이런 아키텍쳐 설계는 이전 장에서 설명한 '돈'의 영역과 밀접한 관련이 있다.

아키텍쳐는 변경이 어렵기 때문에 초반에 결정하는 편이다.

데이터베이스의 아키텍쳐 - 역사와 개요

데이터베이스에 관한 아키텍쳐늬 역사는 크게 3가지가 있다.

1. Stand-alone (~ 1980)
2. 클라이언트/서버 (1990 ~ 2000)
3. Web 3계층 (2000 ~ 현재)

Stand-alone

데이터베이스가 동작하는 기계가 LAN이나 인터넷에 연결되지 않고 독립되어 동작하는 구성

Stand-alone 장점

• 구축이 매우 간단하다.

• 외부에서 접속이 불가능하여 보안성이 높다.

Stand-alone 단점

• 물리적으로 떨어진 장소에서 접근할 수 없다.

• 복수 사용자가 동시에 작업할 수 없다.

• 가용성이 낮다.

  • 서버가 1대 뿐이라 장애 발생 시 서비스가 정지한다.

• 확장성이 부족하다.

  • 서버가 1대 뿐이라 성능이 한계인 경우 기기의 성능을 업그레이드 하는 방법 밖에 없다.

클라이언트/서버

데이터베이스 서버 1대에 복수의 사용자가 접근하는 구성을 말하여, 클라이언트와 서버 2개의 레이어로 구성되기 때문에 '2계층 구성'이라고도 부른다.

이어서 말할 이유 때문에 기업이나 조직 내의 닫힌 네트워크(LAN)에서 주로 쓰인다.

클라이언트/서버 장점

• 복수 사용자가 물리적으로 떨어진 상황에서 네트워크를 이용해 접근 할 수 있다.

클라이언트/서버 단점

• 사용자가 데이터베이스에 직접 접속하기 때문에 보안상의 위험이 크다.

• 불특정 다수의 사용자가 이용하는 애블리케이션의 관리 비용이 많이 든다.

  • 이 때에는 사용자의 기기에 직접 어플리케이션을 설치하여 사용하였고, 모든 사용자가 사용할 수 있도록 버전 관리나 대응 등 비용이 많이 들었다.
  • 모바일 기기에서 어플을 깔아서 사용하는 것을 생각해 보자

Web 3계층

비즈니스 로직을 담당하는 애플리케이션을 서버에서 관리해 이용을 절감하는 방식으로 아래처럼 구성되어 있다.

현재 가장 일방적으로 쓰이는 방식

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

Web 3계층 장점

• 설치를 하지않고 브라우저를 통해 접속이 가능하다.

• 사용자가 애플리케이션 관리를 할 필요가 없다.

• 사용자가 직접적으로 데이터베이스에 접근하지 않는다.

데이터베이스의 아키텍쳐 - 가용성과 확장성

앞서 말한 Stand-alone 구성의 단점 중 2가지 (확장성 부족, 가용성 낮음) 문제가 남아있다.

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

• 고품실-소수전략 : 시스템을 구성하는 각 컴포넌트의 신뢰성을 높여 장애 발생률을 낮게 억제하여 가용성을 높인다.

• 저품실-다수전략 : 시스템을 구성하는 각 컴포넌트의 여분을 준비해 둔다.

클러스터란

동일한 기능의 컴포넌트를 병렬화하는 것을 '클러스터링'이라고 부른다.

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

예시로 고장률이 10%인 서버의 대수를 늘리면 고장률이 아래처럼 변화한다.

• 서버 1대 10%
• 서버 2대 1%
• 서버 3대 0.1%

이로 인해 2가지 사실을 알 수 있다.

1. 가동률 100%는 불가능하다.
2. 서버 대수가 증가할수록 1대를 추가함에 따라 얻는 가동률이 낮아진다.

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

DB와 타 서버의 차이

간단히 병렬화를 통해 대수를 증가시킬 수 있는 웹 서버나 다른 서버와 달리 DB는 데이터를 저장하는 영속 계층이다.

DB 서버의 아키텍처는 DB 서버(계산, 업무 로직)와 저장소(데이터 보존)을 묶어서 생각해야 한다.

기본적인 다중화

저장소는 그대로 두고 DB 서버를 다중화 하는 방식이다.

DB 서버의 동작 방식에 따라 2가지로 나뉜다.

• Active-Active 클러스터를 구정하는 컴초넌트를 동시에 가동한다.
• Active-Standby 실제로는 Active 만 동작하고 나머지는 대기(Standby) 한다. (문제 상황 발생 시 동작함)

Active-Active 특징

• 시스템 다운시간이 짧다.
• 성능이 비교적 좋다.
  • 좋기는 하지만 병목 현상으로 큰 차이는 없을 수도 있다.

Active-Standby 구성

Active-Standby 구성은 다시 'Cold-Standby'와 'Hot-Standby'로 나뉜다.

• Cold-Standby : 평소에는 작동하지 않고, Active DB가 다운될 시점에 작동한다.
• Hot-Standby : 평소에도 Standby DB가 작동한다.

가격 비교

1. Active-Active
2. Hot-Standby
3. Cold-Standby

번호 순으로 비용이 많이 든다.

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

DB 서버와 저장소 세트를 복수로 준비해 다중화 하는 방식이다.

주의할 점

Active 측 저장소의 DB는 항상 사용자로부터 갱신된다. 따라서 Standby 측 DB도 갱신을 해서 데이터 정합서을 유지할 필요가 있다.

그래서 동기화 작업을 하는데, 갱신 주기를 어떻게 할 것인가 에서 트레이드 오프가 발생하고,

동기화가 잘 되었는지 확인할지 혹은 하지 않을지 결정하는 부분에도 트레이드 오프가 발생한다.

Shared Nothing

기존의 Active-Active 구성처럼 디스크를 공유하는 것을 Shared Disk 라고 한다.

Shared Disk 방식의 Active-Active 구성은 어딘가에서 한계점에 도달한다. 이런 문제를 해결하기 위해 고안된 것이 Shared Nothing이다. (샤딩 이라고 부르기도 한다.)

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

Shared Nothing의 장점

• DB 서버와 저장소의 세트를 늘려서 저장소가 병목이 되는 것을 방지하고 있다.
• 비용 대비 성능이 좋다.
• 구현이 쉽다.
  • Shared Disk 방식은 복잡한 동기화 구조를 요구하지만 Shared Nothing은 같은 구성의 DB를 횡으로 나열하여 구조가 간단하다.

Shared Nothing의 단점

• 저장소를 공유하지 않으므로 결국 각각의 DB 서버가 동일한 1개의 데이터에 엑세스 할 수 없다.
  • 이런 문제에 터하기 위해 한 DB 서버가 다운되었을 때 다른 DB 서버가 이어받는 커버링 구성 등을 고려해야 한다.

아키텍처 패턴 정리

------- 사진 ------------- 추가 예정

100% 장애 대책은 없다.

장애 대책에 대한 여러가지를 알아봤지만 장애가 발생할 가능성이 0%이 되지는 않는다. 따라서 우리는 장애 이후 '짧은 시간 안에 복구'를 생각해야 한다.