4장

[seokhwan-an]

4장 데이터베이스와 아키텍처 구성

💡목표

고속의 견고한 시스템을 구축하기 위해서는 아키텍처가 명확한 의도로 설계되어야 한다. 아키텍처가 중요한 이유와 어떤 식으로 접근해 검토하는지 파악

다중화

DB 서버가 2대(혹은 그 이상) 중에 1대가 고장이 난다고 하더라고 나머지 1대가 정상적으로 동작하면 서비스의 정지를 막는데 이를 다중화 라고 합니다.

아키텍처

아키텍처는 시스템의 목적과 기능 을 나타내는 것이다. 즉, 아키텍처를 보았을 때 우리는 그 시스템이 어떤 용도로 이용되고 무엇을 목적으로 하는 것인지를 한 눈에 알아볼 수 있고 추측할 수 있습니다.

아키텍처의 역사

1. Stand-alone

데이터 베이스의 서버가 LAN이나 인터넷 등의 네트워크에 접속하지 않고 독립되어서 동작하는 구성방식 입니다.

장점

• 데이터베이스를 구축하는 것이 간단합니다.
• 보안이 높습니다.

단점

• 물리적으로 떨어진 장소에서 접근할 수 없습니다.
• 복수 사용자가 동시에 작업할 수 없습니다.
• 가용성이 낮습니다.
• 확장성이 부족합니다.

2. 클라이언트/서버

stand-alone의 단점을 극복한 것으로 데이터베이스 서버 1대에 복수 사용자의 단말이 접속하는 구성을 클라이언트/서버 라고 한다. 이는 클라이언트와 서버 2개의 레이어로 구성되어 있기 때문에 2계층 구성이라고도 부릅니다.

장점

• 데이터베이스로 접근하는데 물리적인 거리를 고려할 필요가 없습니다.
• 복수 사용자가 접근이 가능합니다.

단점

• 인터넷에서 직접 데이터베이스에 접속하는 것에 대한 보안 문제가 발생합니다.
• 불특정 다수의 사용자가 사용하는 애플리케이션 관리비용이 많이 발생합니다.
  • 관리비용 문제: 각종 OS에 맞는 애플리케이션을 제작해야하며 버전관리 및 그에 따른 버그 관리 등

3. Web 3계층

비즈니스 로직을 담당하는 애플리케이션을 서버에서 관리해 비용을 절감하기 위한 방식으로 웹서버 계층 , 애플리케이션 계층 , 데이터베이스 계층 으로 관리하는 모델입니다.

웹 서버 계층 : 웹 페이지가 들어 있는 파일을 사용자에게 제공하는 서버 프로그램 Ex) nginx, apache 등

애플레케이션 계층 : 비즈니스 로직을 구현한 애플리케이션이 동장하는 계층 Ex) tomcat

데이터베이스 계층 : 비즈니스 로직에 사용되는 데이터들을 저장하고 있는 계층

아키텍처에서 가용성 및 확장성 높이기

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

• 심장전략(고품질-소수전략) : 시스템을 구성하는 각 컴포넌트의 신뢰성을 높여 장애 발생률을 낮게 억제하는 방식 → 고사향 제품 이용
• 신장전략(저품질-다수전략) : 시스템을 구성하는 각 컴포넌트의 신뢰성을 높이기보다는 여분을 준비해두는 방식

과거에는 두 방식 중 무엇이 더 효율적인지 판단하지 못해 두 방식 모두 고려했지만 현재에는 심장전략보다는 신장전략을 주 방식으로 택했으며 그 이유는 중앙으로 관리하는 것은 리스크가 크기 때문입니다. 그렇다고 심장전략을 아예 이용하지 않는 것은 아니며 FT(Fault Tolerant)서버에서는 심장전략을 택하고 있습니다. 단 내부의 CPU, 메모리 등의 부품의 경우에는 신장전략을 이용한 부분들이 있습니다. 즉, 두 방법 중 하나만을 고수하는 것이 아닌 이 둘을 조화롭게 이용해 나가고 있다는 것을 알 수 있습니다.

💡FT서버란?
Fault Tolerant 서버는 시스템 내부의 하드웨어 또는 소프트웨어의 장애가 발생핬을 때에도 지속적으로 서비스를 제공할 수 있는 서버 시스템으로 장애에 대한 내성과 복구 기능을 갖추고, 중단 없이 연속적인 서비스를 유지할 수 있습니다.
Fault Tolerant 서버는 주로 중요한 비즈니스 애플리케이션, 금융 거래 시스템, 통신 인프라 등 신뢰성이 매우 중요한 시스템에서 사용됩니다. 이러한 시스템에서는 장애로 인한 중단이 큰 비용과 위험을 초래할 수 있으므로, Fault Tolerant 서버를 통해 신속하고 안정적인 서비스를 제공할 수 있습니다.

신장전략(클러스터링)으로 시스템의 가동률을 높이게 되면 가동률(여유도)를 높일 수 있습니다. 그 이유는 같은 기능을 하는 시스템을 늘릴수록 전체에서 발생하는 에러 발생률을 줄일 수 있습니다. 시스템 대수와 가동률의 관계는 다음과 같습니다.

• 가동률을 100%가 될 수 없습니다. ⇒ 에러가 발생하면 적어도 몇초간은 시스템이 정지가 되기 때문입니다.
• 서버 대수가 증가하면 증가할수록 얻을 수 있는 가동률의 폭이 작아집니다.

서버의 대수를 무작정 늘리는 것이 좋은 것이 아닌 적절하게 늘리는 것이 적은 비용으로 가동률을 높일 수 있는 방안입니다.

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

클러스터링 : 동일한 기능의 컴포넌트를 병렬화하는 것 → 신장전략으로 동일한 기능을 하는 컴포넌트를 여러개 준비하는 것

DB에서의 다중화는 단순히 서버를 다중화하는 것보다는 고려해야할 부분이 많은데 그 이유는 DB는 영속 계층으로 데이터의 정합성을 보장해야하기 때문입니다.

간단한 DB 다중화 방식(클러스터링)은 다음과 같습니다.

위의 아키텍처에서 Active-Active 방식과 Active-Standby 방식 2가지로 나뉘어집니다.

Active-Active 방식은 두 DB서버를 동시에 가동시키는 것입니다.

장점

• 시스템의 다운 시간이 짧습니다 → 시스템의 가동률이 높습니다.
• DB 서버 수가 증가하면 동시에 가동하는 CPU나 메모리가 증가하여 성능이 좋습니다.

단점

• 라이센스 비용이 비쌉니다.

Active-Standby 방식은 하나만 동작을 하고 나머지 하나는 대기를 하는 상태입니다.

장점

• 라이센스 비용이 저렴합니다.

단점

• 시스템의 전환 시간이 상대적으로 깁니다.
• standby 서버는 지속적으로 Heartbeat을 보냄으로서 active 서버가 이상이 있는지 파악해야 합니다.

Active-Standby 방식은 두가지 방식이 존재하는데 Cold-Standby와 Hot-Standby로 나뉘는데 Cold-Standby의 경우 여러대의 서버중에 하나만 활동을 하고 나머지는 대기 상태인 것이고 Hot-Standby의 경우 대기 서버들도 활동을 하는 것입니다.

💡active-active 방식과 Hot-Standby방식의 차이점
Active-Active방식의 경우 모든 노드가 동시에 읽기 및 쓰기 작업을 수행할 수 있어서 요청에 대한 부하 분산과 응답 시간 개선에 도움이 됩니다. 반면 데이터의 정합성을 맞추는데 오버헤드가 발생합니다.
반면 Hot-Standby 방식은 주로 읽기 작업에 사용되는 활성 노드와 쓰기 작업을 하는 비활성 노드로 구성되어있습니다. 하나의 노드만 쓰기 작업을 하기 때문에 데이터 정합성을 유지하는데 도움이

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

리플리케이션 : 앞선 클러스터링의 경우 저장소는 하나로 고정하고 DB 서버들만 병렬화하는 방식이었다면 리플리케이션은 저장소도 병렬화하는 것입니다.

리플리케이션은 데이터도 병렬화하기 때문에 하드웨어(저장소)가 파괴되더라도 다른 하드웨어(저장소)가 살아있다면 시스템이 문제없이 동작할 수 있으므로 가용성이 매우 높은 기술입니다.

리플리케이션의 경우 데이터의 정합성이 중요한 사항입니다. 그래서 Active 측 저장소의 데이터가 변화하면 Standby 측의 저장소 역시 갱신이되어야합니다.

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

shared-nothing VS shared-Disk

shared-Disk

• 클러스터링과 같이 하나의 저장소를 가지고 여러 DB서버가 동작하는 아키텍처
• 저장소가 공유자원이기 때문에 DB 서버가 많아지게 되면 오버헤드(lock 등)가 발생한다.

shared-Nothing

• 저장소를 분리한 상태
• 데이터 정합성을 맞추는 것이 어려운 상태입니다.
• shared-Disk에 비해서 DB 서버를 늘렸을 때 처리율이 높아집니다.

💡샤딩(sharding)
샤딩은 데이터베이스의 성능과 확장성을 항샹시키기 위해 사용되는 기술입니다. 단일 저장소에서 데이터를 관리하게 되면 요청량이 증가할 때 데이터 정합성을 위해서 오버헤드가 발생하게 되어 성능상의 문제가 발생하게 되는데 이 때 데이터를 분할 하고 여러 개의 서버에 저장소를 분산 저장함으로써 성능을 향상시키는 방법입니다.

[somefood]

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

• 데이터베이스는 문제가 생겨 기능이 정지하면 인프라로써 역할을 못하기에 견고하게 유지되는 것이 관건
• 그렇기에 다중화에 대한 고려를 해야함

아키텍처

• 시스템을 만들기 위한 물리 레벨의 조합
• 어떤 기능을 가진 서버를 준비하고 어떠한 저장소나 네트워크 기기와 조합해서 시스템 전체를 만들 것인가 고려 (하드웨어 + 미들웨어)
• 아키텍처의 다음과 같은 변화를 가짐
  • Stand-alone (~1980년대)
    • 협업의 개념이 등장하기 전이라 LAN이나 인터넷 등의 네트워크에 접속하지 않고 독립되어 동작
    • 직접 설치된 곳에 가서 물리적으로 접근해야함
    • 복수 사용자가 동시에 접근할 수 없음
    • 가용성이 낮음
    • 확장성이 부족, 실제 머신이 1대기이기 때문에 성능을 올리려면 껐다켜야하고 이는 가용성이 낮아짐을 초래함
    • 대신, 구축이 간단하여 소규모 작업이나 테스트가 빠름
    • 물리적인 접근이 필요하기에 보안성이 높아 데이터를 도둑맞을 일은 없음
  • 클라이언트/서버(1990년대~2000년)
    • 네트워크 연결을 통해 원격으로 접근 가능 <-> 해킹의 위험이 높아져 보안이 취약해질 수 있음
    • 다중 사용자가 사용할 수 있음
    • 클라이언트에서의 애플리케이션 관리비용이 많이 들게 됨 (각각 환경에 맞게 대응해야 함 -> 비즈니스 코드 중구난방)
  • Web 3 게층 (2000년~현재)
    • 비즈니스 로직을 실행하는 애플리케이션 서버를 서버에서 관리해 비용을 절감
    • 웹 서버 계층/애플리케이션 계층/데이터베이스 계층으로 3 개의 계층으로 분류
    • 그래도 가용성 문제와 확장성 부족의 문제는 해결해야할 사안

가용성과 확장성의 확보

• 견고한 아키텍처 시스템은 가용성이 가장 중요함. 가용성을 높이즌 전략은 다음과 같음
  • 심장전략(꼬품질-소수전략): 시스템을 구성하는 각 컴포넌트의 신뢰성을 높여 장애 발생률을 낮게 억제해서 가용성 확보
  • 신장전략(저품질-다수전략): 시스템을 구성하는 각 컴포넌트의 신뢰성을 계속 높이기 보다. 여러 개를 만들어서 여분을 통해 가용성 확보
• 24시간/365일 무중단 시스템을 도모하기 위해선 신장전략을 많이 취하는 추새

클러스터

• 컴포넌트를 병렬화하는 것을 클러스터링이라고 함. 이를 위해선 동일한 기능의 컴포넌트를 복수 개 준비해 한 개의 기능을 실현하는 것임
• 서버를 여러 대 준비할 수록 가용성은 높아지지만 완전 100%는 존재하지 않는다.

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

• DB 서버가 데이터를 보존하는 영속 계쯩이라 다중화에 특유의 어려움을 겪오 있다.
• 데이터는 항상 갱신되기 때문에 다중화를 유지하는 중에 데이터 정합성도 중요하게 의식해야 하기 때문
• DB의 기본적인 다중화 방식은 두 가지가 있음
  • Active-Active: 클러스터를 구성하는 컴포넌트를 동시에 가동. 시스템 다운 시간이 짧고, 성능도 좋아지지만 저장소가 병목되어 오히려 안 좋아 질 수도 있음
  • Active-Standby: 클러스터를 구성하는 컴포넌트 중 실제 가동하는 것은 Active, 남은 것은 대기(Standby)하고 있는다. HeartBeat 신호를 통해 Active의 생사여부를 체크하기 때문에 다운 시간이 길어질 수도 있음. Hot-Standby를 통해 빠르게 전환할 수도 있지만 라이선스료가 높게 되어있음

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

• 위 클러스터 구성은 서버 부분을 다중화 할 수 있지만 저장소는 다중화 할 수 없어 저장소가 부서질 경우 데이터를 일게 됨
• 리플리케이션 기술을 활용하면 저장소도 다중화 처리 가능
• Active 측 저장소의 데이터는 항상 갱신되기 때문에 Standby 측에 최신화 하지 않으면 정합성이 어긋날 수 있기에, 적절한 시간대를 통해 복제를 시도해야함

Shared Nothing

• 복수의 서버가 1대의 디스크를 사용하는 구성을 Shared Disk라고 함. 이 타입은 Active-Active 구성을 무한으로 늘려도 처리율이 향상되지 않고 한계점에 도달하게 됨. 이를 해결하기 위한 아키텍처로 고안된 것이 Shared Nothing (구글에선 개발한 것은 샤딩이라고함)이라고 함.
• '아무것도 공유하지 않는다'는 의미로 네트워크 이외의 자원을 모두 분리하는 방식. 서버와 저장소의 세트를 늘리면 병렬처리 되기에 선형적인 성능향상 가능
• 저장소를 공유하지 않기에 각각 DB서버가 동일한 1개의 데이터에 액세스할 수 없기 때문에 정리 서버가 필요함.
• 그리고 DB 서버 하나 다운되면 그쪽의 데이터는 액세스 할 수 없음. (커버링 구성 필요)

적절한 아키텍처 구조를 구성하는 것이 가장 중요하다.

[JoungMinJu]

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

1. 다중화?

__다중화(고가용성)__란 저장소를 복수로 준비해두는 것을 의미.
만약의 상황에 대비하기 위해 예방책을 마련해놓는 것.

2. 아키텍처?

시스템을 만들기 위한 물리 레벨의 조합.
그리고 이러한 시스템을 만들 때, 그 시스템이 __완수해야하는 목적__과 비교해가면서 뼈대를 결정해 가는 것이 바로 아키텍처 설계.
이를 위해선 서버부터 OS, 저장소, 네트워크 기기까지 폭넓은 지식이 요구됨.

3. 아키텍처의 역사

(1) Stand-alone

DB만으로 시스템이 성립하는 가장 간단한 방법.
DB가 동작하는 머신(DB서버)이 LAN이나 인터넷 등의 네트워크에 접속하지 않고 독립되어 동작하는 구성.

이 구성에서는 DB의 미들웨어(DBMS)와 어플리케이션의 SW는 같은 DB 서버에서 동작함. => DB를 사용하고 싶은 사용자는 DB 서버가 설치된 장소까지 물리적으로 접근하여 사용해야 함.

이는

1. 물리적으로 떨어진 장소에선 접근할 수 없고
2. 복수의 사용자가 동시에 접근할 수 없고
3. 가용성이 낮으며 (서버가 한 대 밖에 없어서 여기에 장애가 발생하면 서비스가 정지)
4. ** 확장성이 부족하다**. (한 대의 서버를 스케일업 하는 것 밖엔 개선 수단이 없음)

따라서 매우 불편한 구조가 됨.

하지만 장점도 존재.

1. 소규모 작업이나 빠른 테스트를 원할 땐 적합할 수 있다.
2. 보안성이 매우 높다 (네트워크를 통해 침입할 가능성이 없다)

물론 매우 사소한 장점.

(2) 클라이언트/서버

위의 단점을 해결하기 위해 DB를 네트워크에 연결한 구조.
DB 서버 한 대에 복수 사용자의 단말이 접속하는 구성을 클라이언트/서버 구성이라고 한다. (2계층 구성이라고도 부른다)

DB서버에선 DBMS가 동작하고, 클라이언트에선 업무 어플리케이션이 동작하는 "분업 체제"가 만들어짐.

해당 구조는 주로 기업이나 조직 내의 LAN에서 이용된다. 즉, 외부 네트워크를 거쳐 DB 서버에 접속할 방법이 없다는 것. 따라서 이 구조는 조직 내에서 제한된 용도의 시스템으로 이용되고 있음.

이 구조의 단점은 __어플리케이션 관리 비용__이다.

클라리언트/서버 시대에 연결되는 클라이언트는 스마트폰, 윈도우, 맥 등 다양한 종류가 존재. 인터넷을 통해 전세계 불특정 다수의 사용자가 어플리케이션을 이용하게 된다면, 각종 환경에 대응해 어플리케이션을 작성해야하고 각각에 대해 "버전 관리" 등을 진행하는데 비현실적인 비용이 소모.

이러한 부분에서 비즈니스 로직을 실행하는 어플리케이션을 서버에서 관리하자는 요구가 등장.

(3) WEB 3계층

그래서 등장한 것이 바로 이 WEB 3계층 구성.

해당 구성은 시스템을 다음 세 가지 계층의 조합으로 생각하는 모델이다.

1. 웹 서버 계층
2. 어플리케이션 계층
3. DB 계층

즉, 클라이언트와 DB 사이에 웹 서버 계층 과어플리케이션 계층이 추가 된 것.

웹 서버는 클라이언트로부터 접속 요청을 직접 받아서 그 처리를 뒷단의 어플리케이션 계층에 넘기고 그 결과를 클라이언트에 반환. 자주 사용되는 웹 서버 = "아파치", "IIS"

어플리케이션 계층은 비즈니스 로직을 구현한 어플리케이션이 동작하는 층. 웹 서버로부터 연계된 요청을 처리하고 필요하면 DB 계층에 접속하여 이를 가공한 결과를 웹 서버로 반환한다. "톰캣", "웹스피어" 등

이런 구조로 된다면 "웹 서버 계층"만 사용자의 직접적인 접속 요청을 받게 되어 보안이 강화된다. 또한 어플리케이션 관리 비용도 낮출 수 있다.

4. 가용성과 확장성 확보

WEB 3계층에서 많은 문제가 해결되었지만 가용성이 낮고 확장성이 부족하다는 문제는 아직 남아 있게 됨.

하지만 시스템 장애의 당사자가 되지 않으려면 가용성을 담보해야만 함.

(1) 가용성 향상 전략

1. 심장전략(고품질-소수전략) = 시스템을 구성하는 각 컴포넌트의 신뢰성을 높여 장애 발생률을 낮게 억제해서 가용성을 높임
2. 신장전략(저품질-다수전략) = 시스템을 구성하는 각 컴포넌트의 신뢰성을 계속해서 높이기보다는 "사물은 언젠가 망가진다"는 것을 전제로 여분을 준비해두기. 이를 철저히 대비하는 것을 "물량 작전"이라 함.

현재는 신장전략이 주로 채택됨.

(심장전략이 완전히 폐지된 것은 아님. 이를 채택하게 되면 전환시간이 짧아지고 무정지에 가까운 서비스를 계속하는 것이 가능)
(심장전략을 채택한 Fault Tolerant Server도 CPU, 메모리 등 부품을 다중화해서 신뢰성을 높이도록 설계한 부분이 많음. 즉, 심장전략과 신장전략은 중첩되는 경우가 많다.)

(2) 클러스터란?

동일한 기능의 컴포넌트를 병렬화 하는 것. 즉, 동일한 기능의 컴포넌트를 복수 개 준비해서 한 개의 기능을 실현한다는 의미.

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

같은 기능을 가진 서버가 많아지면 많아질 수록 좋을 것 같지지만, 전체적으로 봤을 때

1. 가동률(시스템이 무고장으로 동작할 확률)은 100%가 될 수가 없다. 근접해갈 순 있지만
2. 서버 대수가 증가하면 증가할수록 한 대를 추가함에 따라 얻을 수 있는 가동률의 향상 폭이 작아진다.

(3) 단일 장애점이란?

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

이때, 전체 시스템의 가용성은 이러한 단일 장애점에 의해 결정됨.

이때문에 단일 장애점을 없애기 위해 이중화를 해두지만, 이는 예산 제약과 직결된다.
또한, 아무리 돈을 들여도 장애 발생률 0%는 이뤄질 수 없다.

신뢰성 = HW나 SW가 고장나는 빈도(고장률)나 고장 기간을 나타내는 개념
가용성 = 사용자 입장에서 볼 때 시스템을 어느 정도 사용할 수 있는지

즉, 시스템을 구성하는 컴포넌트에 대한 것이 신뢰성
시스템 전체에서 사용자 눈높이에 맞춰 생각하는 경우가 가용성

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

(1) DB와 다른 서버의 차이

DB 서버는 영속 계층의 사명이 부여되어 다중화 문제를 결정적으로 어렵게 하고 있다. 데이터는 항상 갱신되기 때문에 다중화를 유지하는 중에 데이터 정합성도 중요하게 의식해야 하기 때문에

(2) 가장 기본적인 다중화

DB 서버만을 다중화하고 저장소는 하나만 두는 구성!
데이터가 보존되는 저장소가 한 개라서 정합성을 신경 쓸 필요가 없음.

두 개의 DB 서버가 동시에 동작하는 것을 허락할지에 따라 모드가 나뉜다.

1. Active-Active = 클러스터를 구성하는 컴포넌트를 동시에 가동
2. Active-Standby = 클러스터를 구성하는 컴포넌트 중 실제 가동하는 것은 Active. 남은 것은 대기하는 것

1번 구성 = Oracle, DB2
나머지 DBMS는 2번 구성만 제공.

(3) Active-Active

두 가지의 장점이 있다.

1. 시스템 다운 시간이 짧다
   = 복수의 DB 서버가 동시에 동작하고 있어서 한 대가 다운되어 동작 불능이 되어도 남은 서버가 처리를 계속해 시스템 전체가 정지하는 것을 방지할 수 있음. 이것은 웹 서버나 어플리케이션 서버의 클러스터링으로 얻을 수 있는 장점과 같음.

2. 성능이 좋다
   = 동시에 가동한는 CPU나 메모리도 증가하므로 성능도 향상된다. 단, 저장소가 병목되기 때문에 생각보단 향상되지 않을 수도 있음.

(4) Active-Standby

보통 standby 상태의 DB 서버는 사용되지 않다가 active DB 서버에서 장애가 일어날 때만 사용된다.
따라서 전환시 발생하는 시간적인 비용이 생김 -> 그 사이 시스템은 다운 상태!

어떻게 Active DB 서버에 장애가 일어난 것을 알까?
=> Active DB에 이상이 없느지 일정 간격으로 확인하는 통신을 함. 이 통신을 heartbeat라고 부름.

구성의 종류

1. Cold stand by = 평소에는 Standby DB가 작동하지 않다가, Active DB가 다운된 시점에 작동하는 구성
2. Hot Standby = 평소에도 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 그리고 아래 개념의 차이점?

(1) Shared Disk와 Shared Nothing

복수의 서버가 한 대의 Disk를 사용하는 구성 = Shared Disk

Shared Disk 타입의 Active-Active 구성은 DB 서버를 늘려도 무한으로 처리율이 향상되지 않고 어딘가에서 한계점에 도달한다. DB 서버 간의 정보 공유를 위한 오버헤드가 크기 때문이다.

이 단점을 극복하기 위한 아키텍처로 고안된 것이 Shared Nothing

Shared Nothing는 네트워크 이외의 자원을 모두 분리하는 방식.
이 아키텍처는 서버와 저장소의 세트를 늘리면 병렬처리 때문에 선형적으로 성능이 향상되는 장점이 있다. 또한 저장소가 병목이 되는 것을 방지하므로 처리율이 증가한다.

즉, Shared Nothing은 서버와 저장소 세트를 늘리는 것
Shared Disk는 복수의 서버가 한 개의 저장소를 공유하는 것

구글은 자사가 개발한 Shared Nothing 구조를 샤딩이라 부른다.

Shared Nothing은 비용 대비 성능이 좋다.

Shared Disk는 복잡한 동기화 구조가 필요해서 구축하려면 복잡.
하지만 Shared Nothing 구성은 DB 서버를 횡으로 나열하기 때문에 구조가 단순하고 원칙적으로 DB 서버 수에 비례하여 저장소가 늘어남.

하지만 Shared Nothing은 저장소를 공유하지 않기 때문에 각 DB 서버가 동일한 한 개의 데이터에 접근할 수 없다는 문제가 발생한다.

8. 아키텍처 종 정리

[rawfishthelgh]

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

다중화

데이터베이스의 견고한 유지를 위해 중요한 개념, 고가용성이라고도 부른다.

아키텍처 설계

하드웨어와 미들웨어의 구성, 어떤 서버? 어떤 저장소? 어떤 네트워크? → 총체적인 구성을 결정하는 것

→ 시스템 요구조건을 충족하기 위해 어떤 아키텍처가 중요할까를 생각하자

아키텍처 변천사

1. Stand - Alone : 네트워크 연결 x, 1대의 db만으로 시스템 성립→가용성 낮음, 인터넷 접속x→따라서 동시작업 불가(1명만 가능), 물리적으로 떨어지면 불가.
2. 클라이언트/서버 : 클라이언트/서버로 계층 분리해 상호 간 네트워크로 접속, 주로 기업 내부의 네트워크(LAN)에서 이용, 현재까지도 조직 내에서 제한된 용도로 사용. 그러나 인터넷에서 직접 db 접속하는 것에 대한 보안 위협 및 불특정 다수가 사용하는 관리비용이 단점 → 각각이 pc에 애플리케이션 설치해야 함(버전 관리, 버그 수정이 동시에 이뤄지지 x, 사용자 각각의 pc 환경에 모두 대응해야 함)
3. Web 3계층 : 2번을 발전시킨 현재 주류 아키텍쳐, 클라이언트/서버의 관리비용 문제 해결 위해, 비즈니스 로직을 실행하는 애플리케이션을 서버에서 관리한다.
   1. 웹서버계층(Apache) : http 요청을 받아 처리를 애플리케이션 계층에 넘기고 결과를 반환한다
   2. 애플리케이션 계층(Tomcat) → 추가됨 : 요청을 처리하고 db에 접속해 데이터를 추출 및 가공해 웹서버로 넘긴다. 사용자가 직접 요청을 받는 대신 애플리케이션 계층이 요청을 받고 필요하면 db 접속.
   3. db계층

가용성과 확정성 확보

Web 3계층으로 물리적 거리문제, 동시작업 문제는 해결했으나, 가용성(서버가 1대면 그 서버 장애나면 서비스 죽음), 확장성(서버가 1대면 그 서버가 성능 한계 나면, 서버를 상위 기종 or 고성능 부품으로 교환) 문제는 해결 x

가용성 높이는 두 가지 전략

1. 심장전략(고품질-소수전략) : 시스템 구성하는 각 컴포넌트의 신뢰성을 높여 장애 발생률을 낮게함
2. 신장전략(저품질-다수전략) : 어차피 컴포넌트가 망가질 것이라 생각하고 컴포넌트 물량을 많이 준비함(병렬화)

→ 현재는 대부분 신장전략(저품질 다수, 물량 중심)을 선택함

클러스터

신장전략과 같이 컴포넌트(서버)를 병렬화하는 것. 클러스터는 “집합”을 의미한다. 클러스터링을 통해 시스템 가동률을 높이는 것을 “여유도(redundancy) 확보”라고 한다.

시스템 가동률

1. 가동률 100퍼센트는 아무리 컴포넌트를 추가해 병렬화해도 원리적으로 불가능. 모든 서버가 동시에 고장나는 가능성 존재
2. 서버를 계속 증가시키면, 가동률이 높아지다가 한계 수준에 도달하면 계속 낮아짐 → 한정된 밭에 씨를 더 뿌린다고 수확이 늘지 않는다

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

네트워크, 애플리케이션 서버는 단순히 병렬화해서 다중화시키는 방법을 쓰면 되지만, DB서버는 데이터를 보존하는 영속 계층이므로 다중화에서 고민할 지점이 많다.

웹/애플리케이션 서버는 데이터를 일시적으로 처리하지만, db는 처리가 끝나고 데이터를 보존해야 하므로, 신뢰성이 중요하다. db서버의 아키텍처는 저장소와 묶어서 생각하자

데이터베이스는 두가지로 구성된다

1. db서버 : 계산이나 업무 로직 처리
2. 저장소 : 데이터 보존

데이터는 항상 갱신되므로 db서버가 다중화를 하려면 “데이터 정합성”을 의식해야 한다.

DB서버를 다중화하고 저장소는 하나로 유지하는 경우

DB서버가 두 개 존재하고, 저장소는 하나라고 가정하자. 이 때는 데이터를 보존하는 저장소가 1개라 정합성을 신경쓸 필요 없다.

그러나 두 개의 db서버를 동시에 동작할지 말지에 따라 두 방식으로 나뉜다

1. Active-Active : 둘 다 동시에 가동
   1. 한 대가 다운되어도 다른 서버가 즉시 처리하여 시스템 전체 정지를 방지. 짧은 시스템 다운 시간.
   2. 동시 가동하는 cpu와 메모리도 증가하므로 성능도 향상됨. 그러나 저장소가 병목되므로 기대한 만큼 성능 향상되지 않을 수 있음
2. Active-Standby : 가동 중인 클러스터는 Active, 남은 것은 StandBy 상태로 대기한다.
   1. Active한 db서버에 장애가 일어나면, Standby 상태의 서버가 사용되지 않다가 active로 전환될 때 까지 시스템 다운 상태가 됨
   2. active 서버의 장애가 일어났는지 파악하기 위해, standby 서버는 수십~수초 간격으로 active에 문제가 없는지를 조사하는 통신을 한다. 이 통신이 끊기면 active가 장애가 난거임 → 이 통신을 “Heartbeat”라고 한다.

→ 대부분의 DBMS가 Active-StandBy 클러스터링 방식에 대응한다

Active-StandBy는 두 가지로 나뉜다

1. cold - standby : 평소에는 작동하지 않다가 active가 다운된 시점에 작동한다
2. hot-standby : 평소에도 standby가 작동한다 → 이는 많은 라이선스료 지급 때문에 비싸다

따라서 가격순으로 나열하면 Active-Active → hot- standby → cold-standby 순이다.

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

그러나 위의 방식은 저장소가 1개인데, 이 저장소가 없어지면 데이터를 잃게 된다(지진, 붕괴, 공격). 따라서 이에 대응을 위해 db 서버와 저장소를 세트로 묶어 복제한다.

→ 이를 리플리케이션(replication:복제) 라고 한다.

복제된 하드웨어 시설은 멀리 떨어진 지점에 두어 안정성을 높인다(재해복구센터)

주의할 점

결국 데이터의 정합성 유지다. 여러 저장소의 데이터가 함께 갱신되어 최신화되어야 active 측과 standby 측의 데이터 정합성을 유지할 수 있다. 일정 주기로 active의 데이터를 stanby 쪽에 써줘야 한다

리플리케이션 구성은 손자와 증손자 세트를 만들 수 있다. 이는 만약 오래된 데이터라도, 단순히 “참조”만 하게 할 경우에 해당 데이터를 손자나 증손자 세트에 두고 참조하게 한다

Mysql에서는 동기화하는 측의 부모를 “마스터”, 자식을 “슬레이브”라 부른다.

→ 이를 사용해 create, update, delete 요청이 아닌 단순 read 요청을 slave db로 분산해 성능을 높일 수 있다. 우리가 Spring에 @transactional(readOnly=true) 옵션을 거는 이유 중 하나임(이는 사용하는 해당 db 벤더사가 읽기 전용 트랜잭션을 적용할 때만 유효하고(h2는 안해줌), 추가적 설정이 필요하며, master-slave 구성일 때만 사용 가능)

https://prolog.techcourse.co.kr/studylogs/3624

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

맨 위처럼 복수의 서버가 하나의 저장소를 공유하는 방식을 Shared Disk라 한다. 이 때 Active-Active 방식을 사용하면 db를 계속 늘려도 처리율이 무한으로 향상되지 않고 어디선가 한계점이 도달한다. 복수의 서버가 1대의 디스크를 사용하니 한 디스크에 정보가 몰려 병목 현상이 발생한다(좁은 페트병 뚜껑에 물이 많이 몰려듬). 저장소가 공유 자원이라 늘리기 어렵고, 서버 대수가 증가할 수록 db서버 간의 정보공유를 위한 오버헤드가 크기 때문이다.

Shared Nothing 방식은 위 단점을 극복하기 위한 아키텍처로 고안됐다. 이는 네트워크 이외의 자원을 전혀 공유하지 않는 방식이다. DB 서버와 저장소의 세트를 한꺼번에 늘려서 저장소의 병목을 방지한다(서버만 늘리는 shared disk와 달리 저장소까지 늘림). db서버간의 정보를 공유할 필요가 없다. 구글이 자사에서 개발한 Shared Nothing 구조를 “샤딩(Sharding)”이라 부른다. 따라서 저장소의 병목이 줄어들어 처리율이 증가한다.

Shared Nothing 방식은 같은 구성의 DB서버를 횡으로 나열하면 되기에 구조가 간단하고 구축이 쉽다. 그러나 저장소를 각 서버가 공유하지 않으므로, 각 서버가 동일한 데이터에 접근할 수 없다. 따라서 어떤 데이터가 필요한데, 그 데이터에 접근하는 서버가 죽으면 문제가 발생한다.

예를 들어 각 시별로 서버+저장소를 갖춘 shared nothing 구성이 있는데, 이 때 고양시의 저장소에 접근하는 서버가 죽으면 다른 서버에서 고양시 저장소로 접근이 불가능하다. 고양시와 부천시의 저장소-서버 세트들은 각각 분리되어 있기 때문이다.

따라서 db서버 하나가 다운될 때, 다른 서버가 이를 이어받아 처리할 수 있도록 해야 한다. 이를 “커버링(covering)”이라 한다.

[seokhwan-an]

찾아볼 것

1. active-standby (hot - standby) 방식은 왜 active-active가 아닌가?
2. 리플리케여선에셔 모든 저장소가 어떻게 데이터 정합성을 맞추는 것인지?