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

문제 상황

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

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

결론

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

근거

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

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

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

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

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