📌Clustering

클러스터링은 여러 대의 서버(또는 노드)를 하나의 그룹으로 묶어 하나의 시스템처럼 동작하도록 구성하는 기술입니다. 이러한 클러스터링은 Active & Active 방식과 Active & StandBy 방식이 있다.

• 고가용성(High Availability): 한 서버에 장애가 발생해도 다른 서버가 대체하여 서비스 중단을 최소화.
• 로드 밸런싱(Load Balancing): 요청을 여러 서버에 분산시켜 성능을 향상.
• 분산 환경을 구성하여 Single point of failure와 같은 문제를 해결할 수 있는 Fail Over 시스템을 구축하기 위해서 사용
• 동기 방식으로 노드들 간의 데이터를 동기화

Single point of failure(단일 장애점,SPOF)
시스템 구성 요소 중에서, 동작하지 않으면 전체 시스템이 중단되는 요소가 이중화가 되어 있지 않다면 SPOF일 가능성 높음

Fail over
실 운용환경(컴퓨터 서버, 시스템, 네트워크) 등에서 이상이 생겼을 때, 대체 작동 또는 장애 극복(조치)을 위해 예비 운용환경으로 자동전환되는 기능

Active & Active

• 서버 한대가 죽더라도 하나의 서버가 동작하고 있어서 서비스에 큰 문제 X
• 다른 서버가 동작하는 동안 복구를 하여 서비스의 중단 없음
• 하나의 데이터베이스에 가해지는 부하가 두개로 나눠지므로 CPU, Memory 부하도 줄어듦
• 여러 개의 서버가 하나의 스토리지 공유하기 때문에 병목현상 발생

Active & Stand-By

• Active 상태의 서버에 문제가 생겼을 때 Fail over를 하여 Stand-by 서버를 Active로 전환하여 문제에 대응
• Fail over가 발생하는 시간동안에는 서비스가 중단될 수 밖에 없음
• 결론적으로 한 대만 운영 -> 효율은 Active&Active의 절반
• 비용이 저렴 (standby는 실제로 운용되지 않기 때문)

📌Replication

데이터베이스 리플리케이션(Replication)이란 말 그대로 복제본 데이터베이스를 운용하는 것이다. 원본 데이터베이스를 Master, 복제된 데이터베이스를 Slave라고 부른다. Slave 데이터베이스는 Master 데이터베이스를 복제(Replication)하여 동일한 데이터를 가지게 된다.

• 데이터베이스 스토리지 복제
• 데이터베이스 서버를 확장한 Clustering과 달리 서버와 스토리지 모두 확장
• 여러 개의 DB를 권한에 따라 수직적인 구조(Master-Slave)로 구축하는 방식
  • Master : INSERT, UPDATE, DELETE
  • Slave : SELECT
• Slave 서버 여러개를 통해 분산하여 처리할 수 있어 성능 향상에 도움이 된다.
• 버전 관리 필요, 적어도 Slave가 상위버전
• 비동기방식으로 데이터 동기화하기 때문에 일관성있는 데이터 얻지 못 할 수 있음
  • 동기 방식으로 Replication할 수 있지만, 속도가 느려짐
• Master 서버가 다운되면 복구 및 대처 까다로움

현재는 master-slave 단어를 안쓰는 추세인 만큼 source-replica 구조로 불리기도 함.

구축 목적

• 스케일 아웃
  • 갑자기 늘어나는 트래픽에 대해 부하를 줄이기 위해 서버를 늘리는 것
• 데이터 백업
  • 백업 과정은 실제 실행중인 쿼리에 영향을 줄 수 있다.
  • => 레플리카 서버에서 데이터 백업을 진행
• 데이터 분석
  • 데이터 분석의 경우, 대량의 데이터 조회, 복잡한 쿼리가 많을 수 있다.
  • 소스 서버에서 데이터 분석을 할 경우, 실제 서비스에 문제가 생길 수 있다.
  • => 데이터 분석 전담 서버를 두는 것이 좋다.
• 데이터의 지리적 분산
  • 데이터베이스 서버가 멀리 떨어져 있다면 빠른 응답을 받기 어렵다.
  • 다양한 지역에 레플리카 서버를 두어 응답 속도를 높일 수 있다.

※ Replication 데이터 정합성 문제
https://da-nyee.github.io/posts/db-replication-data-consistency-issue/

📌Sharding

같은 테이블 스키마를 가진 데이터를 다수의 데이터베이스에 분산하여 저장하는 방법. 테이블을 특정 기준으로 나눠서 저장 및 검색

• Sharding Key : 나눠진 Shard 중 어떤 shard를 선택할 지 결정하는 키, 결정방식에 따라 Sharding 방법이 나누어짐

Hash Sharding

• Shard Key : Database id를 Hashing 하여 결정
  • Hash크기는 Cluster안에 있는 Node개수로 정하게 됨
• 구현이 간단하다(key-value)
• 확장성이 떨어진다
  • Node개수를 늘리거나 줄일 경우, Hash 크기와 Key가 변함 -> Data 분산 Rule 어긋남
  • => Resharding 필요
• 공간에 대한 효율을 고려하지 않는다

Dynamic Sharding

• 확장에 용이하다
  • Node의 개수를 늘릴 경우 : Locatoer Service에 Shard Key 추가만 하면 됨
  • 기존 Data Shard Key 변경 X
• 데이터를 재배치 시 Locator Service의 Shard Key Table도 동기화 해야한다.
• Locator Service를 통해 Shard Key를 얻는다.
• Locator에 의존적이다.
  • Locator가 성능을 위해 Cache하거나 Replication할 경우, 잘못된 Routing을 통해 Data 찾지 못하고 Error 발생
• ex ) HDFS : Name Node, MongoDB : Config Server

Entity Group

• Key-Value가 아닌 다양한 객체로 구성된 경우 Applicaiton의 복잡도를 줄이는 방향으로 Sharding하는 방법
• 관계가 있는 Entity끼리 같은 Shard 내에 공유하도록 만든 방식
• 단일 Shard 내에서 쿼리가 효율적이고 강한 응집도를 가진다
• 다른 Shard의 Entity와 연관되는 경우 비효율적
• 사용자가 늘어남에 따라 확장성이 좋은 Partitioning

※ Shared Disk & Shared Nothing
https://milhouse93.tistory.com/43

출처

https://eunsun-zizone-zzang.tistory.com/50
https://code-lab1.com/%ED%81%B4%EB%9F%AC%EC%8A%A4%ED%84%B0%EB%A7%81/
https://jordy-torvalds.tistory.com/94