[DB] RDS Aurora가 아닌 MySQL Engine 읽기 전용 부하 분산

들어가기에 앞서

이전부터 관심 있던 부하 분산이라는 주제로 RDS 읽기 전용 복제본을 생성해 트래픽을 분산시키는 작업을 진행했다. 하지만 RDS Aurora가 아니라 MySQL Engine을 이미 선택해 마이그레이션 하기에는 비용 걱정과 운영 걱정이 이만저만이 아니기 때문에.. 애플리케이션 단에서 스케쥴링을 하는 방법을 찾았다.

---

먼저 아키텍쳐는 아래 그림과 같이 설계했다. 여기서 마스터 RDS를 1개 더 추가하여 구성할 수 있지만, 그렇게 하려면 단일 DB 인스턴스가 아닌 다중 AZ DB 인스턴스로 구성해야 한다.
(*다중 AZ DB란 쉽게 고가용성을 위해 예비 DB 인스턴스를 자동 구성해 주며, fail-over기능도 제공한다.)

다중 AZ DB 인스턴스로 구성한다면 직접 fail-over를 구현하지 않아도 되는 점에서 개발 비용을 절감하겠지만, 인스턴스를 프리티어 사양으로 고르지 못하며, 인스턴스가 대체적으로 비싸다. 그래서 결국 1대의 마스터만 생성한다.

RDS Replication

처음에는 위 그림과 다르게 Replica 1대로 구성하였지만, 단일 Replica구성시 fail-over시 읽기 작업을 아무도 하지 못한다. 이는 큰 문제이기에 Replica 2대를 추가해 위 그림과 같이 구성되었다.

아래는 Spring에서 DB DataSource를 설정하는 방법이다. DB를 쓰기 전용과 읽기 전용으로 분리했다면 각 트랜잭션이 어디로 가서 정보를 가져오고 써야 하는지 동적으로 DataSource를 분리해야만 한다.

[Spring] MySQL DB Replication 설정하기

그런데 Replica가 3대로 늘어나버리면 문제가 발생한다. 바로 쉬고있는 2대의 Replica에게는 트래픽은 전하지 못하는 것이다.

또한, 그렇게 놀고 있다면 자원을 낭비하지 않는 방법은 우린 이미 알고 있다. 스케쥴링을 하면 된다.

먼저 대안을 생각해보면
1. 애플리케이션 단 내에서 스케쥴링
2. AWS RDS Proxy

3. AWS Route 53 등등

4. JDBC Connector에서 

 

위처럼 4가지가 존재하지만 

2. RDS Proxy를 직접 공식문서를 보면서 시도해 보았지만 RDS Proxy도 당연하게 비용을 발생시킨다. 이는 비용을 아끼려는 내 목적에 맞지 않다.

3. AWS Route 53을 이용해 DNS 기반으로 분산 시킬수 있겠지만, 개인적인 도메인은 현재 사용하지 않는다. 추가적인 개발 비용과 도메인 비용이 발생한다.

4. JDBC Connector는 자체기능으로 라운드 로빈, 연결수가 작은 것부터, 가장 빠른 응답인 것부터, 랜덤 등 많은 로드 밸런싱을 지원한다. 하지만 추후 더 많은 Replica기 생길 것을 예상하고 좀 더 나은 확장성을 위해서는 애플리케이션 단 내에서 스케쥴링하는 것이 더 나을 거 같아 1번은 선택했다. (물론 관리가 어려워진다면 ProxySQL 등을 쓰겠지만, 개발 비용이 너무 큼)

 

1번의 코드와 아이디어는 https://kim-jong-hyun.tistory.com/125 이 분의 블로그를 참고했다.

 

사실 자료조사를 해보고 처음에는 RDS Proxy로 해결하려고 했다. 이미 공식문서를 보고 DB 자격증명, IAM 등을 생성한터라 돌아가기 싫었지만 항상 비용이 문제다. 이번만큼은 더 이상 인프라에 비용을 더 발생시키고 싶지 않았다. 그래서 애플리케이션 단 내에서 스케쥴링하고자 했으며, JDBC Connector를 사용해도 되지만 직적 로직으로 구현해보고 싶었다. 

 

이렇게 가시적으로 보이는 비용을 절감시킨 것은 이번이 거의 처음이다. 쿼리 튜닝, 속도 개선 등을 통해 분명 조금의 비용일 줄 수도 있겠지만 사용자에게 직접 서비스를 하지 않는 이상 그 수치를 쉽게 알 수 없다.

이번 경험 덕분에, 서비스를 하는 입장에서 문제를 해결하기 위해 기술을 구매하여 사용한다는 것은 큰 비용을 발생시킬 수 있다는 걸 깨달을 수 있었다. 또한, 직접 로직을 개발하여 비용을 절감하는 것을 체감함으로써 무분별한 스케일 아웃/업을 지양해야겠다고 생각할 수 있었다.