유저 분산을 위한 로드밸런서 도입기
기존 아키텍처는 사용자에게 제공되는 데이터베이스가 한 서버에 의존되어있어 확장성이 매우 낮았습니다.
부하테스트를 통해 확인해보았습니다.
테스트 개요
동일한 쿼리를 실행하여 단일 유저와 다중 유저 환경에서의 성능 변화를 측정하였습니다.
테스트 결과
- 단일 유저 환경: 평균 쿼리 실행 시간 0.6초
- 동시 접속자 100명 환경: 평균 쿼리 실행 시간 7초
시사점
동시 접속자가 100명만 되어도 쿼리 실행 시간이 급격히 증가했습니다.
DB 부하 분산을 위해 크게 샤딩,복제 방식을 비교했습니다.
유저는 개별 데이터베이스(스키마)에 의존하기 때문에, 새로운 세션이 생성될 때 데이터베이스를 생성할 서버를 할당하고, 세션이 만료될 때까지 동일한 서버와 연결해야 합니다.
로드밸런싱은 세션이 유지되는 동안 부하가 가장 적을 서버에 할당하기 위해,가장 적은 사용자가 있는 인스턴스에 할당했습니다.
그러나,이 방식은 한계점이 2가지 존재했습니다.
- 기존 사용자는 부하 유지
- Scale-out을 해도 리밸런싱이 어려워, 이전 사용자는 계속 부하가 큰 인스턴스 사용
- Scale-In의 복잡성
- 사용자 데이터가 각 인스턴스에 종속되기 때문에 1명이라도 있으면 삭제 불가
- 신규 할당을 방지하고 세션이 만료될시 삭제 가능하지만, 사용자가 적다고 가장 먼저 사용자가 0으로 수렴하는것은 아니므로 어느 인스턴스를 타겟으로 정할지 모호함
- dump를 해서 옮기면 해당 사용자는 dump 동안 데이터 삽입이 중단되는 불편함
모든 삽입 쿼리는 Master에서 실행시키고 Scale-out 대상인 Slave는 복제하는 방식 입니다.
- 관리의 용이성
- Slave는 모두 같은 데이터를 가지고 있기 때문에 복잡한 로드밸런싱 없이 RR만으로 쿼리 실행 분산
- Scale-out시 모든 사용자의 부하 개선
- Slave가 늘어나면 모든 인스턴스의 부하가 줄어들기 때문에 이전 사용자도 성능 향상
그러나,복제 방식도 한계점이 2가지 존재했습니다.
- Master DB 부하
- 모든 유저의 삽입을 Master에서 실행
- 신규 Slave 생성시에도 Master에서 복제
- 스토리지 낭비
- 모든 데이터를 복제하므로 (인스턴스 수) * (모든 사용자의 데이터 용량)
두 방식다 부하테스트 환경에선 평균 쿼리 실행 시간 7초->1.6초로 개선이 되었지만 최종적으론 복제 방식을 선택했습니다.
- 샤딩은 Scale-In이 어려워 인스턴스가 낭비되는데, 스토리지보다 인스턴스가 비용 부담이 크다.
- 스토리지 낭비 비율이 크면 PV를 낮은 용량으로 교체하여 개선 가능
- 샤딩은 결국 기존 사용자의 성능 향상에는 직접적인 영향이 적다.
- 사용자가 많을 때 확장을 진행하고, 이때 대부분이 기존 사용자이므로 성능 개선이 모호