1. 다중화
•
다중화(고가용성)란 저장소를 복수로 준비해두는 것을 의미.
•
만약의 상황에 대비하기 위해 예방책을 마련해놓는 것.
2. 아키텍처
•
시스템을 만들기 위한 물리 레벨의 조합.
•
그리고 이러한 시스템을 만들 때, 그 시스템이 완수해야하는 목적과 비교해가면서 뼈대를 결정해 가는 것이 바로 아키텍처 설계.
== 하드웨어와 미들웨어의 구성
•
이를 위해선 서버부터 OS, 저장소, 네트워크 기기까지 폭넓은 지식이 요구됨.
•
아키텍처는 더 나아가서 비용과 직결되기 때문에 프로젝트 초반에 결정되는 것 중 가장 중요한 일.
3. 아키텍처의 역사
크게 Stand alone → 클라이언트/서버 → Web 3계층 으로 나뉜다.
(1) Stand-alone
•
DB만으로 시스템이 성립하는 가장 간단한 방법.
•
DB가 동작하는 머신(DB서버)이 LAN이나 인터넷 등의 네트워크에 접속하지 않고 독립되어 동작하는 구성.
•
이 구성에서는 DB의 미들웨어(DBMS)와 어플리케이션의 SW는 같은 DB 서버에서 동작함.
⇒ DB를 사용하고 싶은 사용자는 DB 서버가 설치된 장소까지 물리적으로 접근하여 사용해야 함.
•
단점
1.
물리적으로 떨어진 장소에선 접근할 수 없다
2.
복수의 사용자가 동시에 접근할 수 없다
3.
가용성이 낮다
a.
(서버가 한 대 밖에 없어서 여기에 장애가 발생하면 서비스가 정지)
4.
확장성이 부족하다.
a.
(한 대의 서버를 스케일업 하는 것 밖엔 개선 수단이 없음)
따라서 매우 불편한 구조가 된다.
하지만 장점도 존재.
1.
소규모 작업이나 빠른 테스트를 원할 땐 적합할 수 있다.
2.
보안성이 매우 높다 (네트워크를 통해 침입할 가능성이 없다)
(2) 클라이언트/서버
•
위의 단점을 해결하기 위해 DB를 네트워크에 연결한 구조.
•
DB 서버 한 대에 복수 사용자의 단말이 접속하는 구성을 클라이언트/서버 구성이라고 한다.
◦
2계층 구성이라고도 부른다
•
DB서버에선 DBMS가 동작하고, 클라이언트에선 업무 어플리케이션이 동작하는 "분업 체제"가 만들어짐.
◦
해당 구조는 주로 기업이나 조직 내의 LAN에서 이용된다.
◦
즉, 외부 네트워크를 거쳐 DB 서버에 접속할 방법이 없다는 것. 따라서 이 구조는 조직 내에서 제한된 용도의 시스템으로 이용되고 있음.
•
이 구조의 단점은 어플리케이션 관리 비용이다.
◦
클라이언트/서버 시대에 연결되는 클라이언트는 스마트폰, 윈도우, 맥 등 다양한 종류가 존재.
◦
인터넷을 통해 전세계 불특정 다수의 사용자가 어플리케이션을 이용하게 된다면, 각종 환경에 대응해 어플리케이션을 작성해야하고 각각에 대해 "버전 관리" 등을 진행하는데 비현실적인 비용이 소모.
•
이러한 부분에서 비즈니스 로직을 실행하는 어플리케이션을 서버에서 관리하자는 요구가 등장.
(3) WEB 3계층
•
그래서 등장한 것이 바로 이 WEB 3계층 구성.
◦
해당 구성은 시스템을 다음 세 가지 계층의 조합으로 생각하는 모델이다.
1.
웹 서버 계층
2.
어플리케이션 계층
3.
DB 계층
◦
즉, 클라이언트와 DB 사이에 웹 서버 계층과 어플리케이션 계층이 추가 된 것.
◦
웹 서버 : 클라이언트로부터 접속 요청을 직접 받아서 그 처리를 뒷단의 어플리케이션 계층에 넘기고 그 결과를 클라이언트에 반환.
▪
자주 사용되는 웹 서버 = "아파치", "IIS"
◦
어플리케이션 계층 : 비즈니스 로직을 구현한 어플리케이션이 동작하는 층. 웹 서버로부터 연계된 요청을 처리하고 필요하면 DB 계층에 접속하여 이를 가공한 결과를 웹 서버로 반환한다.
▪
"톰캣", "웹스피어" 등
◦
장점
▪
"웹 서버 계층"만 사용자의 직접적인 접속 요청을 받게 되어 보안이 강화된다.
▪
어플리케이션 관리 비용도 낮출 수 있다.
◦
stand alone 모드의 단점들을 극복 (물리적으로 떨어진 장소 접속 불가, 복수 사용자 동시 접속)
4. 가용성과 확장성 확보
•
WEB 3계층에서 Stand alone의 많은 문제가 해결되었지만 가용성이 낮고 확장성이 부족하다는 문제는 아직 남아 있게 됨.
•
하지만 시스템 장애의 당사자가 되지 않으려면 가용성을 담보해야만 함.
(1) 가용성 향상 전략
1.
심장전략(고품질-소수전략)
a.
시스템을 구성하는 각 컴포넌트의 신뢰성을 높여 장애 발생률을 낮게 억제해서 가용성을 높임
2.
신장전략(저품질-다수전략)
a.
시스템을 구성하는 각 컴포넌트의 신뢰성을 계속해서 높이기보다는 "사물은 언젠가 망가진다"는 것을 전제로 여분을 준비해두기.
b.
이를 철저히 대비하는 것을 "물량 작전"이라 함.
현재는 신장전략이 주로 채택됨.
(심장 전략이 완전히 폐지된 것은 아님.
⇒ 이를 채택하게 되면 전환시간이 짧아지고 무정지에 가까운 서비스를 계속하는 것이 가능)
(심장 전략을 채택한 Fault Tolerant Server도 CPU, 메모리 등 부품을 다중화해서 신뢰성을 높이도록 설계한 부분이 많음. 즉, 심장전략과 신장전략은 중첩되는 경우가 많다.)
(2) 클러스터란?
1.
동일한 기능의 컴포넌트를 병렬화 하는 것.
= 동일한 기능의 컴포넌트를 복수 개 준비해서 한 개의 기능을 실현한다는 의미.
또한, 클러스터 구성으로 시스템의 가동률을 높이는 것을 여유도를 확보한다, 다중화라고 함.
같은 기능을 가진 서버가 많아지면 많아질 수록 좋을 것 같지지만, 전체적으로 봤을 때
a.
가동률(시스템이 무고장으로 동작할 확률)은 근접할 순 있으나 100%가 될 수가 없다.
b.
서버 대수가 증가하면 증가할수록 한 대를 추가함에 따라 얻을 수 있는 가동률의 향상 폭이 작아진다.
(3) 단일 장애점이란?
•
다중화되어 있지 않아서 시스템 전체 서비스의 계속성에 영향을 주는 컴포넌트를 의미.
•
이 때, 전체 시스템의 가용성은 이러한 단일 장애점에 의해 결정됨.
•
이 때문에 단일 장애점을 없애기 위해 이중화를 해두지만, 이는 예산 제약과 직결된다.
또한, 아무리 돈을 들여도 장애 발생률 0%는 이뤄질 수 없다.
신뢰성 = HW나 SW가 고장나는 빈도(고장률)나 고장 기간을 나타내는 개념
가용성 = 사용자 입장에서 볼 때 시스템을 어느 정도 사용할 수 있는지
즉, 시스템을 구성하는 컴포넌트에 대한 것이 신뢰성
시스템 전체에서 사용자 눈높이에 맞춰 생각하는 경우가 가용성
5. DB 서버의 다중화 - 클러스터링
(1) DB와 다른 서버의 차이
•
DB 서버과 다른 서버의 차이점은 데이터 영속 계층의 존재 때문에 다중화 문제를 결정적으로 어렵게 만든다.
•
데이터가 항상 갱신되기 때문에 다중화를 유지할 때 데이터 정합성도 중요하게 고려해야 한다.
(2) 가장 기본적인 다중화
•
DB 서버만 다중화하고 저장소는 하나만 두는 구성!
◦
데이터가 보존되는 저장소가 하나 뿐이기 때문에 정합성을 신경 쓸 필요가 없다.
◦
두 개의 DB 서버가 동시에 동작하는 것을 허용할지 여부에 따라 모드가 나뉜다.
1.
Active-Active
a.
클러스터를 구성하는 컴포넌트를 동시에 가동
2.
Active-Standby
a.
클러스터를 구성하는 컴포넌트 중 실제 가동하는 것은 Active.
b.
남은 것은 대기 상태
◦
1번 구성 = Oracle, DB2
◦
나머지 DBMS는 2번 구성만 제공.
(3) Active-Active
•
두 가지 장점이 있다.
1.
시스템 다운 시간이 짧다
= 복수의 DB 서버가 동시에 동작하고 있어서 한 대가 다운되어 동작 불능이 되어도 남은 서버가 처리를 계속함으로써 시스템 전체가 정지되는 것을 방지할 수 있다.
•
이는 웹 서버나 어플리케이션 서버의 클러스터링으로 얻을 수 있는 장점과 같다.
2.
성능이 좋다
= 동시에 가동하는 CPU나 메모리도 증가하므로 성능도 향상된다.
•
하지만 저장소가 병목이 될 수 있기 때문에 생각보다 성능 향상이 되지 않을 수도 있다.
(4) Active-Standby
•
보통 대기 모드의 DB 서버는 사용되지 않다가 활성 DB 서버에서 장애가 발생할 때만 사용됩니다.
◦
따라서 전환할 때 발생하는 시간적인 비용이 있습니다. 이 시간 동안 시스템은 다운됩니다!
Active DB 서버에서 장애가 발생했는지 아는 방법
⇒ Active DB에 이상이 없는지 일정한 간격으로 확인하는 통신을 합니다.
이 통신을 heartbeat라고 부릅니다.
•
구성의 종류
1.
Cold stand by
a.
평소에는 Standby DB가 작동하지 않다가, Active DB가 다운된 시점에 작동하는 구성
2.
Hot Standby
a.
평소에도 Standby DB가 작동하는 구성
•
당연히 Hot standby가 전환시간이 짧음. 하지만 라이선스료가 비쌈.
•
어차피 실제로 동작하는 것은 Active DB 한 대 뿐이기 때문에 전환시간을 줄이기 위해 라이선스료를 많이 지급한다는 것이 의미가 없을 수 있음.
6. DB 서버의 다중화 - 리플리케이션
(1) 리플리케이션이란
•
Active-Active와 Active-Standby 클러스터 구성에서는 서버 부분은 다중화할 수 있어도 저장소 부분은 다중화할 수 없습니다.
◦
즉, 저장소가 망가지면 데이터를 손실하게 됩니다.
•
일반적으로 저장소도 내부 컴포넌트가 다중화되어 있지만, 데이터 센터 전체가 지진으로 붕괴되거나 화재가 발생하면 대처할 방법이 없습니다.
◦
이런 상황에 대응하기 위한 클러스터 구성이 리플리케이션입니다.
▪
이는 DB 서버와 저장소 세트를 복수로 준비하는 것을 의미합니다.
디스크를 다중화하는 RAID
= 저장소 내부의 컴포넌트(대부분 HDD)를 다중화하는 기술을 RAID라고 합니다.
디스크를 병렬로 나열해 디스크 한 개가 망가져도 데이터를 소실하지 않게 합니다.
◦
리플리케이션은 DB 서버와 저장소가 동시에 사용 불능일 때, 서비스를 지속할 수 있어 가용성이 매우 높습니다.
▪
이 견고함 덕분에 재해 대책으로 이용됩니다.
▪
데이터 센터가 두 개라면, 하나가 망가져도 서비스를 유지할 수 있기 때문입니다.
(2) 리플리케이션에서 주의할 점
•
Active 측 저장소의 데이터는 항상 사용자로부터 갱신된다는 점 때문에, Standby에도 이 갱신 내용을 반영할 의무가 있습니다.
•
이러한 갱신 주기는 얼마로 할 것인가와 성능 사이에 trade-off 관계가 생깁니다.
◦
또한, 이 리플리케이션 구성은 원칙적으로는 차례로 손자나 증손자 세트를 만들 수 있습니다.
◦
이러한 구성을 피라미드형이라고 부르는데, 이 경우에는 데이터가 오래되어도 참조만 하면 되기 때문에 손자나 증손자 세트에 "오래된 데이터라도 참조밖에 하지 않을 거니까 증손자를 사용하자" 라는 처리를 하기 때문에 편리합니다.
◦
이를 통해 부모에 걸리는 부하를 분산할 수 있습니다.
•
하지만, 이러한 구성은 DB 서버의 라이선스료와 서버, 저장소 비용이 증가하며 시스템을 구성하는 노력도 더 필요합니다.
7. 성능을 추구하기 위한 다중화 - Shared Nothing
Replication과 Clustering 그리고 아래 개념의 차이점?
Shared Disk와 Shared Nothing
•
복수의 서버가 하나의 Disk를 공유하는 구성은 Shared Disk라고 합니다.
•
Active-Active 구성의 Shared Disk는 DB 서버를 늘려도 처리율이 무한히 향상되지 않고 어느 한계점에 도달합니다. DB 서버 간의 정보 공유를 위한 오버헤드가 크기 때문입니다.
•
이러한 단점을 극복하기 위해 고안된 아키텍처가 Shared Nothing입니다.
•
Shared Nothing은 네트워크 이외의 자원을 모두 분리하는 방식입니다.
•
이 아키텍처는 서버와 저장소의 세트를 추가하면 병렬 처리로 인해 선형적으로 성능이 향상되는 장점이 있습니다.
◦
또한 저장소 병목을 방지하여 처리율이 증가합니다.
즉, Shared Nothing은 서버와 저장소 세트를 추가하는 것입니다.
Shared Disk는 복수의 서버가 한 개의 저장소를 공유하는 것입니다.
구글은 자사가 개발한 Shared Nothing 구조를 샤딩이라고 부릅니다.
•
Shared Nothing은 비용 대비 성능이 우수합니다.
•
Shared Disk는 복잡한 동기화 구조가 필요하여 구축하기 어렵습니다.
•
그러나 Shared Nothing 구성은 DB 서버를 수평으로 배열하기 때문에 구조가 단순하며 원칙적으로 DB 서버 수에 비례하여 저장소가 증가합니다.
•
그러나 Shared Nothing은 저장소를 공유하지 않기 때문에 각 DB 서버가 동일한 데이터에 접근할 수 없다는 문제가 발생합니다.
8. 아키텍처 총 정리
궁금한 점
Q. 파티셔닝을 통해 어떻게 메모리를 최적화하나?
1. I/O 병렬성:
•
특정 쿼리가 여러 파티션에 분산된 데이터를 읽거나 쓸 때, 이러한 I/O 작업이 병렬로 수행될 수 있습니다. 이로 인해 데이터베이스의 처리 성능이 향상될 수 있습니다.
2. 데이터 로컬리티:
•
관련된 데이터를 같은 파티션에 둘 수 있습니다. 이 경우, 하나의 쿼리로 여러 데이터 항목을 빠르게 읽어올 수 있습니다.
3. 쿼리 최적화:
•
파티션 키나 파티션 범위를 잘 선택하면, 데이터베이스 관리 시스템(DBMS)은 전체 데이터 세트를 스캔할 필요 없이 해당 파티션만 조회하면 됩니다. 예를 들어, 날짜 범위에 따라 파티셔닝된 경우, 특정 날짜의 데이터만 필요한 쿼리는 해당 파티션만을 탐색하면 됩니다.
4. 캐시 효율성:
•
파티셔닝을 통해 자주 접근되는 데이터를 몰아서 하나의 파티션에 위치시킬 수 있습니다. 이로 인해 캐시 히트율이 올라가고, 성능이 향상될 수 있습니다.
5. 데이터 관리 용이성:
•
파티셔닝된 테이블은 데이터 유지보수가 더 쉽습니다. 예를 들어, 오래된 데이터를 삭제할 때 해당 파티션만을 삭제하면 됩니다.
6. 병렬 처리:
•
대량의 데이터를 추가, 업데이트, 삭제할 때, 이 작업을 여러 파티션에 동시에 수행할 수 있어 처리 시간을 줄일 수 있습니다.
이 외에도 여러 가지 세부 사항에 따라 파티셔닝은 데이터베이스 성능을 개선할 수 있습니다.
그러나 파티셔닝이 항상 성능 향상을 보장하는 것은 아니며, 데이터의 특성과 애플리케이션의 요구 사항에 따라 적절한 파티셔닝 전략을 선택해야 합니다.
Q. 하나의 디스크에서는 샤딩이 필요하지 않나?
샤딩은 하나의 디스크나 하나의 서버 안에서도 가능은 합니다. 그러나 이런 경우에는 샤딩의 주된 이점인 분산처리와 확장성이 크게 제한됩니다. 샤딩의 가장 큰 장점은 여러 서버나 클러스터에 데이터를 분산시켜 처리 성능을 향상시키고, 시스템을 수평으로 확장할 수 있다는 것입니다.
하나의 디스크나 서버 안에서 샤딩을 구현하면, 그 디스크나 서버의 리소스 한계 때문에 성능 향상이 제한적일 수 있습니다. 예를 들어 CPU, 메모리, I/O 등의 리소스가 공유되므로, 결국 병목 현상이 발생할 가능성이 높습니다.
따라서 하나의 디스크나 서버 안에서 샤딩을 할 경우, 그 의미는 크게 희석되며 일반적으로는 이러한 설정을 추천하지 않습니다. 대신, 하나의 디스크나 서버 내에서 데이터를 분리하려면 "수평 파티셔닝"과 같은 다른 전략을 고려하는 것이 더 적절할 수 있습니다.
