회사에서 마리아 데이터베이스의 갈레라 클러스터를 활용하고 있기 때문에 해당 개념에 대한 깊은 이해가 필요할 것 같아서 개인적으로 더 공부해보았다.
그리고 추후 진행할 프로젝트에 있어서도 많이 활용할 수 있을 것 같아서 더더욱 공부를 해야겠다는 생각을 하였다. 여태까지는 AWS를 활용하여 고가용성을 확보를 했지만, 개인적인 프로젝트를 진행할 때 AWS RDS를 사용한다는 것이 비용적으로 부담이 많이 되는 부분이다.
따라서 해당 기술을 활용하여 복수개의 EC2 서버나 로컬 서버 위에 직접 MariaDB 서비스를 올려서 사용하면 굉장히 좋을 것 같았다. 차근차근 살펴보도록 하자.
MariaDB Galera Cluster란?
MariaDB Galera Cluster는 MariaDB를 위한 고가용성(HA) 및 확장성을 제공하는 멀티-마스터 클러스터링 솔루션이다. 갈레라 클러스터는 리눅스 환경에서만 동작하며, 기본적으로 InnoDB 스토리지 엔진을 지원한다.
InnoDB 스토리지 엔진?
InnoDB 스토리지 엔진은 MySQL과 MariaDB에서 기본으로 사용되는 트랜잭션 기반 스토리지 엔진이다. InnoDB는 ACID 트랜잭션을 지원하고, 외래 키 제약 조건과 충돌 복구 기능을 제공한다.
MariaDB Galera Cluster 주요 기능
- 가상 동기식 복제: 트랜잭션이 모든 노드에 거의 동시에 적용되어 데이터 일관성을 유지한다.
- 멀티-마스터 구조: 모든 노드에서 읽기와 쓰기가 가능하여 부하 분산이 용이하다.
- 자동 노드 관리: 노드의 추가 및 제거가 자동으로 처리되며, 장애가 발생한 노드는 클러스터에서 자동으로 제외된다.
- 병렬 복제: 행 수준에서의 병렬 복제를 통해 성능을 향상시킨다.
- 직접 클라이언트 연결: 각 노드에 직접 연결이 가능하여 응답 지연을 최소화한다.
장점
- 복제 지연 없음: 동기식 복제를 통해 데이터 복제 지연이 발생하지 않는다.
- 트랜잭션 손실 없음: 모든 트랜잭션이 모든 노드에 적용되어 데이터 손실을 방지한다.
- 읽기 확장성: 여러 노드에서 동시에 읽기 작업을 수행하여 읽기 성능을 향상시킨다.
- 낮은 클라이언트 지연 시간: 클라이언트는 네트워크 상에서 가장 가까운 노드에 연결되어 응답 시간을 단축할 수 있다.
구성 요소
- MariaDB Server: 기본 데이터베이스 서버로, Galera Cluster 기능을 지원한다.
- Galera wsrep provider 라이브러리: 노드 간의 복제 및 동기화를 담당하는 핵심 라이브러리이다.
CF. MariaDB 10.4 이상에서는 Galera 4를 사용하며, 이전 버전에서는 Galera 3를 사용한다.
단점 및 대처 방안
- 쓰기 확장성 한계: 모든 노드에 같은 트랜잭션을 동시에 복제하기 때문에, 쓰기 부하가 늘어나면 전체 성능이 병목될 수 있다. 읽기 부하는 분산되지만, 쓰기 작업은 전체 클러스터에 동시 적용되기 때문이다.
- 클러스터에 많은 쓰기 부하가 몰리지 않도록, 애플리케이션에서 일부 쓰기를 비동기적으로 처리하거나 큐를 활용해 처리량을 분산한다.
- 데이터가 자주 변경되지 않는 경우, 캐시 서버(예: Redis)를 앞단에 두어 읽기 요청을 오프로드한다.
- 네트워크 지연 민감: 노드 간 동기화가 네트워크에 의존하므로, 네트워크 지연이나 품질이 좋지 않으면 전체 성능에 영향을 준다.
- 노드를 같은 가용영역(AZ) 혹은 최소한 같은 리전(Region)에 배치해 네트워크 지연을 최소화한다.
- 네트워크 지연이나 패킷 손실이 생기면 즉시 감지하고 대응하도록 모니터링 솔루션을 도입한다.
- Split-Brain 위험: 노드 수가 짝수면 네트워크 단절(Partition) 상황에서 데이터 충돌이 생길 수 있다. 따라서 홀수 노드로 구성하는 것이 권장된다.
- 3대 이상, 홀수 개의 노드로 구성한다.
- Galera의 Quorum 기능을 잘 설정해 Split-Brain이 발생해도 데이터를 안전하게 복구하도록 한다.
Galera의 Quorum(과반수) 기능?
클러스터 내 과반수 노드가 살아있어야 클러스터가 계속 운영될 수 있는 개념이다.클러스터가 과반수 노드를 갖고 있지 않으면, 남은 노드들은 비- Primary Component 상태가 되어 쓰기 작업이 중단된다.
- 운영 복잡성: RDS 같은 매니지드 서비스가 아니라서, 패치·백업·모니터링·장애 대응 등을 전부 직접 관리해야 한다.
- Ansible, Chef, Puppet 같은 툴로 패치·백업·모니터링을 자동화한다.
- 장애 대응, 스케일링, 점검 등의 가이드를 미리 만들어 숙련도를 높인다.
- InnoDB 의존성: InnoDB만 안정적으로 지원되며, MyISAM이나 다른 스토리지 엔진은 Galera와 잘 맞지 않는다.
- Galera Cluster에서는 InnoDB만 쓰는 것이 안정적이다. 다른 엔진을 사용하려면 별도의 복제·백업 설계를 추가해야 한다.