4장. 데이터베이스와 아키텍처 구성
Reference : 데이터베이스 첫걸음
다중화에 대해 생각해 보자
데이터베이스는 견고하게 유지되는 것이 요구된다.
DB서버 2대가 있다면 1대가 고장나더라도 나머지 1대가 동작하면 서비스의 정지를 막을 수 있는데, 이를 '다중화'라 한다.
아키텍처란
시스템을 만들기 위한 물리 레벨의 조합
어떤 기능을 가진 서버를 준비하고 어떠한 저장소나 네트워크 기기와 조합해서 시스템 전체를 만들 것인가
즉, 하드웨어와 미들웨어의 구성.
아키텍처를 보면 그 시스템이 어떤 용도로 사용되고 무엇을 목적으로 하고 있는지 추측 할 수 있다.
시스템에 요구되는 조건을 충족하기 위해 어떤 아키텍처가 적당한지 시스템 개발의 초반에 시행.
데이터베이스의 아키텍처
역사와 개요
아키텍처의 역사는 구체적으로 다음 3단계로 나누어서 파악 할 수 있다.
Stand-alone (~1980년대)
클라이언트/서버 (1990년대~2000년)
Web 3계층 (2000년~현재)
Stand-alone
데이터베이스가 동작하는 머신(데이터베이스 서버)이 LAN이나 인터넷 등의 네트워크에 접속하지 않고 '독립되어' 동작하는 구성.
데이터베이스의 미들웨어(DBMS)와 애플리케이션의 소프트웨어는 같은 DB 서버에서 동작한다.
따라서 데이터베이스를 사용하고 싶은 사용자는 DB서버가 설치된 장소까지 물리적으로 접근하여 사용해야함.
Stand-alone의 단점
물리적으로 떨어진 장소에서 접근할 수 없다.
복수 사용자가 동시에 작업할 수 없다. (동시에 서버를 이용할 수 있는 사람은 1명)
가용성이 낮다. 서버가 1대이므로 이 서버에 장애가 발생하면 서비스가 정지한다.
확장성이 부족하다. 성능이 나쁠 때 개선 수단이 부족하다.
Stand-alone의 장점
구축이 매우 간단해 소규모 작업이나 테스트를 빨리 할 수 있다.
보안이 매우 높다. 네트워크를 매개로 침입할 위험이 없기 때문.
데이터 유출 위험이 낮다. (위와 같은 이유)
클라이언트/서버
데이터베이스를 네트워크에 연결해 복수 사용자가 물리적으로 떨어진 장소에서 접속 가능.
데이터베이스 서버 1대에 복수 사용자의 단말이 접속하는 구성. C/S 또는 클라서버로 부르기도 함.
시스템이 클라이언트와 서버의 2개 레이어로 구성되므로 '2게층 구성'이라고 부르는 경우도 있음.
DB서버에서는 DBMS가 동작, 클라이언트에서는 업무 애플리케이션이 동작.
'클라이언트'란 엔드 사용자가 직접 조작해서 수행하고 싶은 처리 명령을 내보내는 머신.
'서버'란 클라이언트로부터 받은 명령을 실행하여 업무 처리를 실행하기 위한 머신.
주로 기업이나 조직 내에 닫힌 네트워크(LAN)에서 이용되었다. 외부로부터의 접속을 막기 위해.
클라이언트/서버 구성의 단점
인터넷에서 직접 데이터베이스에 접속하는 것에 대한 보안 위험
불특정 다수의 사용자가 사용하는 클라이언트에서의 애플리케이션 관리 비용이 많이 드는 점.
애플리케이션은 각종 환경에 대으앻 애플리케이션을 작성해야 하고 각각에 대해 버전 관리나 버그 수정 버전을 배포하는데 비현실적인 비용이 필요함.
Web 3계층
웹 서버 계층 + 애플리케이션 계층 + 데이터베이스 계층 의 조합
웹 서버는 클라이언트로부터 접속 요청(HTTP 요청)을 직접 받아서 그 처리를 뒷단의 애플리케이션 계층에 넘기고 그 결과를 클라이언트에 반환.
애플리케이션 계층은 비즈니스 로직을 구현한 애플리케이션이 동작하는 층. 웹 서버로부터 연계된 요청을 처리, DB서버에 접속해 데이터를 추출하고 이를 가공한 결과를 웹 서버로 반환.
사용자로부터 직접적인 접속 요청을 받는 역할을 웹 서버 계층에 한정하여 애플리케이션 계층과 데이터베이스 계층의 보안을 높인다.
가용성과 확장성의 확보
Stand-alone구성의 단점 중 가용성이 낮고 확장성이 부족한 문제의 해결책에 대해 생각해보자.
가용성을 높이는 2가지 전략
심장전략 : 시스템을 구성하는 각 컴포넌트의 신뢰성을 높여 장애 발생률을 낮게 억제해서 가용성을 높인다. 소수 정예 노선.
신장전략 : '사물은 언젠가 망가진다'란 체념을 전제로 여분을 준비해둔다. 이를 철저히 대비하는 것을 '물량작전'이라 부른다. (컴포넌트를 병렬화)
★클러스터
동일한 기능의 컴포넌트를 병렬화하는 것을 '클러스터링'이라고 한다.
동일한 기능의 컴포넌트를 복수 개 준비해 한 개의 기능을 실현한다.
클러스터 구성으로 시스템의 가동률을 높이는 것을 '여유도(Redundancy)를 확보한다' 또는 '다중화'라고 한다.
다중화 : 내구성이 더 높고 견고하다
단일 장애점
다중화되어 있지 않아서 시스템 전체 서비스의 계속성에 영향을 주는 컴포넌트.
단일 장애점의 신뢰성이 시스템 전체의 가용성을 결정한다.
단일 장애점을 없애기 위해 대부분 이중화(가장 비용이 많이 듬)는 해두지만, 그 이상 어느 정도 돈을 들여 다중화할지는 예산 제약과 바라는 신뢰성 수준에 따라서 결정해야한다.
신뢰성과 가용성
신뢰성 : 하드웨어나 소프트웨어가 고장나는 빈도나 고장 기간을 나타내는 개념
가용성 : 사용자 입장에서 볼 때 시스템을 어느 정도 사용할 수 있는지
따라서 신뢰성이 낮은 하드웨어나 소프트웨어를 사용하고 있더라도 다중화(클러스터링)한다면 시스템 전체의 가용성을 높일 수 있다.
DB 서버의 다중화 - 클러스터링
DB서버는 데이터를 보존하는 '영속 계층' 이다. 따라서 클러스터링이 어려운 컴포넌트이다.
데이터베이스는 다량의 데이터를 영구적으로 보존, 그에 따른 성능이 요구됨.
따라서 데이터를 보존하는 매체에 필요한 요건이 높다.
전용의 외부 저장소를 사용하므로, DB 서버의 아키텍처는 저장소와 묶어 생각해야한다.
데이터는 항상 갱신되기 때문에, 다중화 시에 '데이터 정합성'을 중요하게 의식해야 한다.
가장 기본적인 다중화
DB 서버만을 다중화하고 저장소는 하나만 두는 구성.
서버가 동시에 동작하는 것을 허락할 지 여부
Active-Active : 클러스터를 구성하는 컴포넌트를 동시에 가동
Active-Standby : 클러스터를 구성하는 컴포넌트 중 실제 가동하는 것은 Active, 남은 것은 대기(Standby)하고 있는다.
Active-Active 구성의 장점
시스템 다운 시간이 짧다.
복수의 DB 서버가 동시에 동작하고 있어 한 대가 다운되어도 남은 서버가 처리해 시스템 전체가 정지되는 것을 막을 수 있다.
성능이 좋다.
DB 서버 대수가 증가하면 동시에 가동하는 CPU나 메모리도 증가하므로 성능이 향상 될 수 있다.
Active-Standby
Standby 상태의 DB서버는 사용되지 않다가 Active DB 서버에서 장애가 일어날 때만 사용된다.
따라서 전환하는 시차동안 서비스를 사용하지 못하는 다운 상태가 된다.
Heartbeat : Standby DB 서버가 일정 간격으로 Active DB에 이상이 없는지 조사하기 위한 통신.
Cold-Standby : 평소에는 Standby DB가 자공하지 않다가 Active DB가 다운된 시점에 작동하는 구성
Hot-Standby : 평소에소 Standby DB가 작동하는 구성 (전환 시간이 짧다)
▶ 가용성과 성능이 좋은 순 (가격순)
Active-Active
Active-Standby (Hot-Standby)
Active-Standby (Cold-Standby)
DB 서버와 데이터의 다중화 - 리플리케이션
리플리케이션이란
DB 서버와 저장소 세트를 복수로 준비. 즉, DB 서버 뿐만 아니라 데이터도 다중화한다.
RAID : 저장소 내부의 컴포넌트 (대부분 하드디스크)를 다중화. 클러스터링과 동일하게 단일 장애점을 없앤다.
리플리케이션 기술
'달걀을 한 바구니에 다 담지 않는다'
하드웨어가 설치된 시설이 파괴된 경우 다른 시설이 멀리 떨어져 있다면 서비스를 계속 사용 가능.
주의할 점
Active 측 저장소의 데이터는 항상 사용자로부터 갱신된다.
따라서 Standby 측 데이터에도 반영을 하여 최신화 해야하는데, 이 갱신 주기를 얼마나 할 것인가와 성능 사이의 트레이드오프 관계가 생긴다.
피라미드형 리플리케이션 구성 : '데이터가 오래되어도 참조만 하면 된다'는 처리를 손자나 증손자 세트에 한다.
부모(Master), 자식(Slave) 관계
100% 장애 대책은 있을 수 없다. 따라서 다음 단계로는 '데이터의 백업과 복구'에 대해 생각해야한다.
성능을 추구하기 위한 다중화 - Shared Nothing
Shared Disk
복수의 서버가 1대의 디스크를 사용
DB 서버를 늘려도 무한으로 처리율이 향상되지 않고 한계점에 도달한다.
저장소가 공유 자원이라 쉽게 늘리기 어렵고 DB 서버 대수가 증가할수록 DB 서버간의 정보 공유를 위한 오버헤드가 크기 때문.
Shared Nothing
네트워크 이외의 자원을 모두 분리하는 방식.
서버와 저장소의 세트를 늘리면 병렬처리 되기 때문에 선형적으로 성능이 향상된다.
저장소가 병목이 되는 것을 방지해 세트에 비례해서 처리율이 증가한다.
구글에서 개발한 구조를 '샤딩 (Sharding)' 이라 부른다.
같은 구성의 DB 서버를 횡으로 나열하기 때문에 구조가 간단하며 원칙적으로 서버 수에 비례해 저장소가 늘어남.
저장소를 공유하지 않으므로 각각의 DB 서버가 동일한 1개의 데이터에 액세스 할 수 없다.
따라서 합산하는 경우 집계하는 정리 서버 필요
→ 커버링 구성. DB 서버가 하나가 다운되었을 때 다른 DB서버가 이를 이어받아 처리.
시스템이 충족해야하는 요건에 따라 최적의 아키텍처를 선택하여 사용한다.
Last updated