다중화
DB서버가 2대 있다면 1대가 고장 난다 하더라도 나머지 1대가 동작하면 서비스의 정지를 막을 수 있음
-> 이러한 것이 다중화
아키텍처
시스템을 만들기 위한 물리 레벨의 조합
-> 어떤 기능을 가진 서버를 준비하고, 어떠한 저장소나 네트워크 기기와 조합해서 시스템의 전체를 만들 것인가
-> 즉 하들웨어와 미들웨어의 구성
이러한 구성을 시스템이 완수해야 할 목적과 비교하면서 결정하는 것을 아키텍처 설계라고 함
-> 이러한 아키텍처 설계는 서버부터 OS, 기타 미들웨어, 저장소, 로드밸런서에 병화벽 같은 네트워크 기기까지의 폭 넓은 지식 필요
아키텍처를 보면 그 시스템이 어떠한 용도로 사용되고 무엇을 목적으로 하고있는지를 어느 정도 추측 가능
아키텍처 역사
1단계 : Stand-alone(~1980년대)
2단계 : 클라이언트/서버 (1990년대 ~ 2000년)
3단계 : Web 3계층 (2000년 ~ 현재)
1단계는 데이터베이스 만으로 시스템이 성립되는 가장 간단한 방법
2단계는 클라이언트와 서버로 계층을 분리하여 상호 간에 네트워크로 접속하는 단계
3단계는 클라이언트/서버를 더욱 발전 시킨 것
Stand-alone
가장 간단한 아키텍처
DB서버가 LAN이나 인터넷 등의 네트워크에 접속하지 않고 독립되어 동작하는 구성
-> 이때 데이터베이스의 미들웨어인 DBMS와 애플리케이션의 소프트웨어는 같은 DB서버에서 동작
-> 즉 DB를 사용하고 싶은 사용자는 DB 서버가 설치된 장소까지 물리적으로 접근하여 서버 앞에 앉아서 데이터베이스를 사용해야 함
-> 서버가 네트워크에 접속되어 있지 않아 물리적으로 떨어진 장소에서 엑세스 하는 것 불가
단점 정리
- 물리적으로 떨어진 장소에서 접근 불가
- 복수 사용자가 동시에 작업 불가
- 가용성이 낮음(서버가 1대)
-> 가용성이란서버가 서비스 제공시간에 장애 없이 서비스를 계속 지속할 수 있는 비율이 어느정도인지 나타냄 - 확장성이 부족
장점
- 구축이 간단해서 소규모 작업이나 테스트를 빨리 진행 가능
- 보안이 매우 높음
클라이언트/서버
물리적으로 떨어진 장소 접근 불가, 다수 사용자 동시 작업 불가
-> 이를 해결하기 위해 DB를 네트워크에 연결하면 됨
DB서버 한대에 복수 사용자의 단말이 접속하는 구성이 클라이언트/서버
-> 클라이언트와 서버 즉 2개의 레이어로 구성되기 때문에 2계층 구성이라고도 불림
DB서버에서는 DBMS가 동작하고 클라이언트에서는 업무 애플리케이션이 동작하는 분업 체제
클라이언트란 앤드 사용자가 직접 조작해서 수행하고 싶은 처리 명령을 내보내는 머신
-> ex) 데스크탑, 노트북 PC, 스마트폰
서버란 클라이언트로부터 받은 명령을 바탕으로 비즈니스 로직을 수행하는 머신
-> 웹서버, 어플리케이션 서버, DB 서버
이 구성은 주로 기업이나 조직 내에 LAN에서 이용
-> 이는 인터넷 등 외부 네트워크를 거쳐 데이터베이스 서버에 사용자가 접속하는 일은 없다는 뜻
-> DB에는 중요한 정보를 많이 축적하고 있어서, 외부로부터의 접속을 허가해버리면 보안상의 위험이 증가
인터넷을 통해 시스템을 이용한는 클라이언트/서버 구성의 문제점
- 인터넷에서 직접 DB에 접속하는 것에 대한 보안 위험
- 불특정 다수의 사용자가 사용하는 클라이언트에서의 애플리케이션 관리 비용이 많이 드는 점
클라이언트/서버 시대에는 개인이 이용하는 PC에 네이티브 애플리케이션을 설치해 동작하게 하였음
-> 사용자가 소수에 한정되어 있다면 상관없지만, 불특정 다수가 이용하는 애플리케이션은 각종 환경에 대응해 애플리케이션을 작성하고 버전관리나 버그 수정 버전을 배포하는데 비현실적인 비용이 들어감
이러한 이유 때문에 비즈니스 로직을 실행하는 애플리케이션을 서버에서 관리해 비용을 절감하자는 요구가 생김
-> 이를 위해 제시된 것이 Web 3계층
Web 3계층
웹 서버 계층(Apache, IIS등), 애플리케이션 서버(TomCat, WebLogic 등), DB 서버로 시스템을 구성
클라이언트/서버 구성가 다르게 웹서버 계층과 애플리케이션 계층이 추가되어 있음
웹 서버는 클라이언트로부터 HTTP 요청을 직접 받아서 그 처리를 뒷단의 애플리케이션 계층에 넘기고 그 결과를 클라이언트에게 반환
-> 즉 애플리케이션 서버와 클아이언트 웹 브라우저와의 가교 역할
애플리케이션 서버는 비즈니스 로직을 구현한 애플리케이션이 동작하는 층
-> 웹 서버로부터 연계된 요청을 처리하고, 필요하면 DB서버에 접속해서 데이터를 추출하고 이를 가공한 결과를 웹 서버로 반환
이 처럼 사용자로부터 직접적인 접속 요청을 받는 역할을 웹 서버 계층에 한정하여 애플리케이션 계층과 데이터베이스의 계층의 보안을 높일수 있음
-> 또한 애플리케이션 계층에 비즈니스 로직을 집중해서 애플리케이션 관리 비용을 낮추는 구성 또한 될 수 있음
가용성과 확장성 확보
아키텍처 설계에서 견고한 시스템을 만들기 위해 가장 중요한 점이 가용성
가용성을 높이는 2가지 전략
-
고품질-소수 전략 : 시스템을 구성하는 각 컴포넌트의 신뢰성을 높여 장애 발생률을 낮게 억제해서 가동성을 높임
-
저품질-다수 전략 : 시스템을 구성하는 각 컴포넌트의 신뢰성을 계속해서 높이기 보다는 사물은 언젠가 망가진다는 생각을 바탕으로 여분을 준비, 일종의 물량 작전
현재는 거의 저품질-다수 전략 노선을 따름
-> 이 처럼 동일한 기능의 컴포넌트를 병렬화 시키는 것을 클러스터링이라고 부름
-> 시스템 세계에서는 동일한 기능의 컴포넌트를 복수 개 준비해 한개의 기능을 실현한다는 의미로 사용
이러한 클러스터링으로 시스템의 가동률을 높이는 것을 다중화라고 지칭
컴포넌트를 어느 정도로 병렬로 추가해도 시스템 가동률은 100프로가 될 수 없음
-> 서버 대수가 증가할수록 1대를 추가함에 따라 얻을 수 있는 가동률의 향상 폭이 작아짐
단일 장애점
다중화 되어 있지 않아서 시스템 전체 서비스의 계속성에 영향을 주는 컴포넌트를 단일장애점(SPOF)이라고 함
-> SPOF의 신뢰성이 시스템 전체의 가용성을 결정
DB서버의 다중화(클러스터링)
간단히 병렬화 해서 대수를 증가시키는 웹서버나 애플리케이션 서버와 다르게 DB서버는 다중화에 대해 고민해야 할 부분이 많음
-> DB서버는 데이터를 보존하는 영속(Persistence)계층 이기 때문!
DB서버는 데이터를 장기간 보존해줄 저장소가 필요
-> 데이터를 일시적으로 처리할 뿐인 웹 서버나 애플리케이션 서버와 다른 점
-> 이 들은 데이터를 보존할 필요가 없어 신뢰성이나 다중화에 그다지 신결 쓸 필요 없음
-> 반면 DB는 대량의 데이터를 영구적으로 보존해야 하므로 필요한 요건이 높음
-> 일반적으로 서버 내부의 로컬 저장소나 메모리로는 이런 요건을 충족시키지 못하므로 전용의 외부 저장소 사용
즉 DB서버의 아키텍처는 저장소와 묶어서 생각해야 함
-> DB는 DB서버와 저장소로 구성
-> cpu나 메모리 같이 처리에 필요한 컴포넌트를 다중화 하는 것은 간단하지만, 데이터를 다중화 할려면 귀찮아짐
-> 이는 항상 갱신되기 때문에 다중화를 유지하는 중에도 데이터 정합성도 중요하게 의식해야 함
데이터 정합성은 데이터가 서로 모순 없이 일관되게 일치해야 함을 의미
가장 간단한 다중화는 DB 서버만을 다중화하고 저장소는 하나만 두는 구성
-> 저장소가 하나라 정합성을 신경쓸 필요는 없음
DB 서버 두대를 어떻게 동작시킬지에 따라 Active-Active 방식과 Active-Standby 형태로 나뉨
- Active-Active : 클러스터를 구성하는 컴포넌트를 동시에 가동
- Active-Standby : 클러스터를 구성하는 컴포넌트 중 실제로 가동하는 것은 Active, 남은 것은 standby로 둠
현재 Active-Active 구성이 가능한 DBMS는 Oracle과 DB2뿐
Active-Active는 시스템 다운 시간이 짧음
-> 한대가 다운되어도 남은 서버가 처리를 계속해 시스템 전체가 정지되는 걸 방지
-> 또한 성능이 좋음, Db 서버 대수가 증가하면 동시에 가동하는 CPU나 메모리도 증가하기 때문에 처리 성능이 향상될 수 있음(병목 때문에 생각만큼 성능이 향상 안될수도 있음)
Active-StandBy에서 standby 상태의 DB서버는 사용되지 않다가 Active Db 서버에서 장애가 일어날 때만 사용
-> 전환할때 시차가 생기고, 그 사이에 시스템은 서비스를 계속하는 것이 불가능한 상태가 됨
장애 발생 -> 장애를 검사하고 인식 -> StandBy Db 서버 작동
standBy 서버는 일정 간격 동안 Active DB에 이상이 없는지를 조사하기 위해 통신함
-> 이 통신을 HeartBeat라고 함
Active-StandBy는 Cold-StandBy와 Hot-StandBy로 나뉨
cold : 평소엔 스탠바이 DB가 작동하지 않다가 Active Db가 다운 되는 시점에 작동하는 구성
hot : 평소에도 스탠바이 Db가 작동하는 구성
-> cold보다 전환 시간이 짧지만, 그만큼 라이센스료가 높게 설정 됨
Db 서버와 데이터의 다중화(리플리케이션)
앞선 Active-Active, Active-StandBy 클러스터 구성에서는 서버 부분은 다중화 할 수 있어도, 저장소 부분은 다중화 할 수 없어 데이터를 다중화하지 않는다는 공통적인 단점이 있음
-> 즉 저장소가 부서진다면 데이터를 잃게 됨
물론 저장소도 보통은 내부 컴포넌트가 다중화되어 있지만(디스크 다중화 : RAID), 데이터 센터 전체가 지진으로 붕괴되거나 화재가 난다면 끝
-> 이런 상황 대비를 위한 클러스터 구성이 리플리케이션(Replication)
이는 단순히 말해 DB 서버와 저장소 세트를 복수로 준비하는 것!
예를 들어, 지진이나 태풍등으로 하드웨어가 설치된 시설이 파괴된 경우, 다른 1세트가 멀리 떨어진 지점에 놓여있다면 서비스를 계속하는 것이 가능하다는 점에서 매우 가용성이 높은 아키텍처
리플리케이션 기술은 Oracle : Data Guard, DB2 : HADR 이름으로 상품화
-> MYSQL은 재해 대책 이라기보다는 부하 분산을 위해 리플리케이션을 발전시키는 느낌
주의할 점
Active 측 저장소의 데이터는 항상 사용자로부터 갱신 됨
-> 즉 StandBy 측 데이터에도 갱신을 반영하여 최신화하지 않으면, Active 측과의 데이터 정합성을 유지할 수 없음
-> 예를 들어 1일에 1회, 야간에 동기화를 한다면 Active 측 저장소가 망가진 경우 최대 1일분의 데이터 갱신이 소실됨
리플리케이션에서는 Active 측 Db서버에서 갱신된 데이터를 일정 주기로 StandBy 측 Db서버에 써려내 감
-> 이때 갱신주기를 얼마로 할 것인가와 성능 사이에 트레이드 오프 관계 생김
동기화 하는 측의 Acitve DB를 마스터, 동기화되는 측의 StandBy DB를 슬레이브라고 부름
-> 멀티마스터(마스터-마스터)방식을 사용하기도 하지만, 일반적으로 리플리케이션이라면 마스터 슬레이브 방식 생각
성능을 추구하기 위한 다중화(Shared Nothing)
앞선 Active-Active 구성의 Db는 저장소 부분이 병목되는 경우가 있다고 설명
-> 이는 복수의 서버가 1대의 스토리지 사용하였기 때문
-> 이러한 구조를 Shared Disk라고 부름
이러한 Shard Disk 타입의 구성은 Db 서버를 늘려도 무한으로 처리율이 향상되지 않고, 어느 순간 한계점에 도달
-> 저장소는 공유 자원이라 쉽게 늘리기 어렵고, DB 서버 대수가 증가할수록 DB 서버간 정보 공유를 위한 오버헤드가 크기 때문
-> 이를 해결하기 위해 고안된 아키텍처가 Shared Nothing
Shared Nothing은 네트워크 이외의 자원을 모두 분리하는 방식
-> 이 아키텍처는 서버와 저장소의 세트를 늘리면 병렬처리 때문에 선형적으로 성능이 향상되는 장점이 있음
구글 자사가 개발한 Shared Nothing 구조를 샤딩이라고 부름
Shared Nothing은 비용 대비 성능이 좋음
-> Shared Disk 방식은 복잡한 동기화 구조가 필요해서 구축하려면 복잡하지만, Shared Nothing과 같은 구성은 Db서버를 횡으로 나열하기 때문에 구조가 간단하고 Db 서버 수에 비례해서 저장소가 늘어남
-> 하지만 DB서버가 저장소를 공유하지 않는 것은 즉, 각각의 Db 서버가 동일한 1개의 데이터에 엑세스 할 수 없다는 것 의미
예를 들어 도시 단위로 DB 서버 + 저장소 세트를 갖춘 Shared Nothing 구성에서는 고양시 데이터를 가진 Db 서버가 엑세스 할수 있는 것은 고양시의 데이터 뿐(부천시,광명시 또한 마찬가지)
-> 이때 시별 인구 데이터를 합산해 경기도의 인구를 계산하려면 각 세트로부터 시별 인구를 모아서 집계하는 정리 서버가 필요하게 됨
-> 또한 고양시의 DB서버가 다운되었을 때 고양시의 데이터에 엑세스 할 수 없는 문제가 발생
위처럼 DB 서버 하나가 다운되었을 때 다른 DB서버가 이를 이어받아 계속 처리할 수 있는 커버링 구성을 고려해야 함
-> Shared Nothing도 보기보다 설계하기 복잡
아키텍처 패턴 정리
Shared Nothing과 리플리케이션의 차이
-> 리플리케이션은 저장소 즉 전체 데이터를 가지고 있는 디스크를 이용하여 서버,저장소 조합을 여러개 만들어 DB의 아키텍처가 구성되있는 반면, Shared Nothing은 DB서버 마다 연결된 스토리지가 가지고 있는 내용이 각각 다름
-> 이렇게 답변하면 전체 데이터라는 단어가 애매한듯!, ex) 슬레이브가 동기화 되기 전
