문제 상황

기존 아키텍처는 신규 사용자 데이터베이스 부하 분산을 위해 최소 사용자 인스턴스에 할당하는 샤딩 구조를 사용했습니다.

그러나,이 방식은 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를 활용하고 있어 원활하게 구현 가능

Replication Lag

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로 라우팅하도록 했습니다.

결과

• 서버 확장시 모든 사용자가 즉시 성능 향상 가능한 구조로 전환
• 불필요한 인스턴스 비용 절약 가능