유저 분산을 위한 로드밸런서 도입기

문제 상황

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

그러나,이 방식은 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

Kubernetes ReadinessProbe

결론

두 방식다 부하테스트 환경에선 평균 쿼리 실행 시간 7초->1.6초로 개선이 되었지만 최종적으론 복제 방식을 선택했습니다.

근거

1. 샤딩은 Scale-In이 어려워 인스턴스가 낭비되는데, 스토리지보다 인스턴스가 비용 부담이 크다.

• 스토리지 낭비 비율이 크면 PV를 낮은 용량으로 교체하여 개선 가능

2. 샤딩은 결국 기존 사용자의 성능 향상에는 직접적인 영향이 적다.

• 사용자가 많을 때 확장을 진행하고, 이때 대부분이 기존 사용자이므로 성능 개선이 모호

3. 조회 쿼리의 발생빈도가 쓰기 쿼리 보다 훨씬 높다.