유저 분산을 위한 로드밸런서 도입기
기존 아키텍처는 신규 사용자 데이터베이스 부하 분산을 위해 최소 사용자 인스턴스에 할당하는 샤딩 구조를 사용했습니다.
그러나,이 방식은 2가지의 한계점이 존재했습니다.
- 서버 확장을 해도 리밸런싱이 어려워, 이전 사용자는 계속 부하가 큰 인스턴스 사용
- 탄력적인 분산이 이루어지지 못함
- 사용자 데이터가 각 인스턴스에 종속되기 때문에 1명이라도 있으면 삭제 불가
- 신규 할당을 방지하고 세션이 만료될시 삭제 가능하지만, 사용자가 적다고 가장 먼저 사용자가 0으로 수렴하는것은 아니므로 어느 인스턴스를 타겟으로 정할지 모호함
- dump를 해서 옮기면 해당 사용자는 dump 동안 데이터 삽입이 중단되는 불편함
실시간 인스턴스 확장/축소로도 원활히 분산이 될 수 있게 복제 기반 아키텍처로 재설계 했습니다.
복제는 일관성 문제가 존재하지만 쿼리 연습 플랫폼 서비스 특성상 완벽한 일관성 보다 전체 성능을 우선시하는 것이 적합하다고 판단했습니다.
모든 삽입 쿼리는 Master에서 실행시키고 Scale-out 대상인 Slave는 복제하는 방식 입니다.
인스턴스 확장을 진행할 때, 새로운 Slave를 추가하면 기존 Master의 데이터를 먼저 복제해야 합니다.
이때 논리적 복제와 물리적 복제 2가지 방식을 사용할 수 있는데, 대용량 데이터를 빠른 시간에 복제해야 하므로 물리적 복제로 진행했습니다.
물리적 복제에도 여러 방식이 존재하고 이 중 빠른 실시간 인스턴스 확장과 Master DB 부하를 최소화할 수 있는 Volume Snapshot방식을 선택했습니다.
- MySQL Clone Plugin
- MySQL 내장 기능으로 네트워크를 통한 직접 복제
- 설정이 간단하지만 복제 중 Master에 추가 I/O 및 CPU 부하 발생
- 데이터 크기에 비례하여 복제 시간 증가
- Percona XtraBackup
- InnoDB 데이터를 기반으로 물리적 백업을 수행하는 오픈소스 도구
- 백업 수행 시 Master에 추가 I/O 및 CPU 부하 발생
- 백업·복구 절차가 복잡해 자동화 난이도가 높음
- Volume Snapshot
- 스토리지 레벨 복사로 Master DB 성능 영향 거의 없음
- 이전 아키텍처에서도 영속성을 위해 PVC를 활용하고 있어 원활하게 구현 가능
MySQL에서 Master로의 부터 복제는 다음과 같이 이루어집니다.
복제를 하는 중에 Master,Slave간에 데이터가 불일치 할 수 있는데, 이 때 발생하는 현상을 Replication Lag(복제 지연)라고 합니다.
초기 복제에서의 Replication Lag
Volume Snapshot을 통해 초기 복제 생성을 진행하는데 SnapShot주기가 5분으로 5분간의 일관성 차이가 존재할 수 있습니다.
GTID를 기반하여 Master와의 일관성을 맞출 수 도 있지만,이는 계속 복제가 진행되면 영원히 트래픽에 반영되지 못할 수 있습니다. 그러므로, 최대 일관성을 어느정도 포기하고 Seconds_Behind_Master를 통해 Master와의 지연이 30초 이내로 줄어들면 트래픽을 라우팅하도록 설계했습니다.
실시간 복제에서의 Replication Lag
대용량 데이터 삽입 API가 평균 20초 내 실행되는 특성을 반영해, 여유 기간을 두어 삽입 직후 1분간은 모든 쿼리를 Master로 라우팅하도록 했습니다.
- 서버 확장시 모든 사용자가 즉시 성능 향상 가능한 구조로 전환
- 불필요한 인스턴스 비용 절약 가능