데이터베이스 HA(고가용성)와 Sharding(샤딩)

 

HA (High Availability, 고가용성)

 

- DabaBase HA 구성 or DataBase 이중화

- 여러 개의 Database Server를 세팅하여 Active - Active or Active - Standby(Primary - Secondary)로 동작

- 일부의 Database Server에 문제가 발생하여도 서비스에 이상이 없도록 구성

=모든 Database Server는 모두 공통된 최신 데이터를 가지고 있어야 한다. (DB Replication)

= 전달되는 각종 Request들이 여러 Database Server 전달되어 실행되는 분산 환경이 구성되어있어야 한다. (Load Balance)

= Active - Standby의 경우 Active Server에 문제가 생겼을경우 Standby Server 가 이를 감지하고 Active 되어야한다. (Failover)

- 여러 Active Server가 나누어 Request들을 처리하여 Database성능 향상

- 오라클의 RAC가 대표적

 

* Replication : 두 개이상의 DBMS 시스템을 Mater / Slave로 나누어 동일한 데이터를 저장하는 방식.

* Load Balance : 하나의 서비스가 트래픽이 많을때 여러 대의 서버가 분산처리하여 서버의 로드율, 부하량, 속도저하를 적절히 분산하여 해결하는 서비스

* Failover (장애극복) : 1차 시스템이 이용불가 상태가 되었을 때, 2차 시스템이 즉시 그 임무를 넘겨받아 서비스가 중단없이 유지될 수 있는 모드

 

 

 

샤딩(Sharding)이란?

같은 테이블 스키마를 가진 데이터를 다수의 데이터베이스에 분산하여 저장하는 방법을 의미한다.

application level에서도 가능하지만 database level에서도 가능. Horizontal Partitioning이라고 볼 수 있다.

 

 

샤딩(Sharding)에 필요한 원리

- 분산된 Database에서 Data를 어떻게 Read할 것인가?

- 분산된 Database에 Data를 어떻게 잘 분산시켜서 저장할 것인가?

- 분산이 잘 되지 않고, 한 쪽으로 Data가 몰리게 되면 자연스럽게 Hotspot이 되어 성능이 느려지게 된다.

 

 

샤딩(Sharding) 방법에 대해

 

1. Hash Sharding

Shard Key : Database id를 Hashing 하여 결정한다.

Hash크기는 Cluster안에 있는 Node개수로 정하게 된다.

 

2. Dynamic Sharding

Locator Service를 통해 Shard Key를 얻는다.

확장에 유연한 구조이다.

Locator Service의 Shard Key Table도 일치시켜줘야 한다.

Locator에 의존할 수 밖에 없는 단점이 있다.

 

3. Entity Group

우리는 RDBMS의 join, index, transaction을 사용함으로써 Application의 복잡도를 줄이는 효과를 얻었습니다.

이와 유사한 방법으로 Sharding하는 방법이 Entity Group이다.

 

하나의 물리적인 Shard에 쿼리를 진행한다면 효율적이다. 하나의 Shard에서 강한 응집도를 가질 수 있다.

데이터는 자연스럽게 사용자별로 분리되어 저장된다. 사용자가 늘어남에 따라 확장성이 좋은 Partitioning이다.

cross-partition 쿼리는 single partition 쿼리보다 consistency의 보장과 성능을 잃는다. 그렇기 때문에 이런 쿼리들이 자주 실행하지 않도록 만들어야 한다.

 

 

Pitfall

Logical Shard는 반드시 Sigle Node안에 있어야 합니다.

출처 입력

Dynamic Sharding을 진행하게 된다면 작업량을 효과적으로 줄일 수 있다.

HotSpot을 찾고 Sharding을 진행한다.

지속적으로 Sharding을 진행하게 된다면 가장 오른쪽 Node만 Write을 진행하게 된다.

나머지 Node들은 Read Performance가 향상하는 효과를 얻을 수 있다.

 

 

정리하며

Sharding을 피하는 방법을 우선 적용해보고 불가피하다면 적용하는게 좋다.

Locator와 Sync해야하는 비용이 필요하다.

Cross-Partition Query가 발생할 경우 기존의 Query보다 느릴 수 있다.

 

 

 

출처 : https://nesoy.github.io/articles/2018-05/Database-Shard

https://danew.tistory.com/26