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

문제 상황

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

그러나,이 방식은 2가지의 한계점이 존재했습니다.

기존 사용자는 부하 유지

• 서버 확장을 해도 리밸런싱이 어려워, 이전 사용자는 계속 부하가 큰 인스턴스 사용
• 탄력적인 분산이 이루어지지 못함

인스턴스 축소의 복잡성

• 사용자 데이터가 각 인스턴스에 종속되기 때문에 1명이라도 있으면 삭제 불가
• 신규 할당을 방지하고 세션이 만료될시 삭제 가능하지만, 사용자가 적다고 가장 먼저 사용자가 0으로 수렴하는것은 아니므로 어느 인스턴스를 타겟으로 정할지 모호함
• dump를 해서 옮기면 해당 사용자는 dump 동안 데이터 삽입이 중단되는 불편함

해결 방법

실시간 인스턴스 확장/축소로도 원활히 분산이 될 수 있게 복제 기반 아키텍처로 재설계 했습니다.

아키텍처

모든 삽입 쿼리는 Master에서 실행시키고 Scale-out 대상인 Slave는 복제하는 방식 입니다.

초기 복제본 생성 방식

Scale-out을 진행할 때, 새로운 Slave를 추가하면 기존 Master의 데이터를 먼저 복제해야 합니다. 이때 크게 논리적 복제와 물리적 복제 2가지 방식을 사용할 수 있는데, 대용량 데이터를 빠른 시간에 복제해야 하므로 물리적 복제로 진행했습니다.

물리적 복제에도 여러 종류가 있습니다.

• MySQL Clone Plugin
• Percona XtraBackup
• Volume Snapshot

Replication Lag

Kubernetes ReadinessProbe

이점

• 관리의 용이성
  • Slave는 모두 같은 데이터를 가지고 있기 때문에 복잡한 로드밸런싱 없이 RR만으로 쿼리 실행 분산
• Scale-out시 모든 사용자의 부하 개선
  • Slave가 늘어나면 모든 인스턴스의 부하가 줄어들기 때문에 이전 사용자도 성능 향상

한계점

그러나,복제 방식도 한계점이 존재했습니다.

1. Master DB 부하

• 모든 유저의 삽입을 Master에서 실행
• 실시간 복제에 대한 부하

2. 스토리지 낭비

• 모든 데이터를 복제하므로 (인스턴스 수) * (모든 사용자의 데이터 용량)

결론

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

근거

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

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

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

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

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