AWS RDS를 활용한 부하분산 아키텍쳐 고민

Architecture

DEV_BLOG 2023. 6. 19. 21:00

Relational Database - AWS RDS를 활용한 부하분산 아키텍쳐를 고안하다가 다른 방향으로 전환하였는데 기존에 정리해둔 내용을 노션에 묵혀두기 아까워서 약간의 내용을 가져와서 오랜만에 포스팅을 할까한다.

Goal

대부분의 Database Application에서 Read와 Write의 비율은 100:1 ~ 10000:1 가량이다.

트래픽이 급증하면 1대의 데이터베이스에 읽기(Read) / 쓰기(Write,Update,Delete)처리 요청시 많은 부하가 발생.

Primary DB에 write, Secondary DB에 Read 하도록 트래픽 분산처리를 적용하기 위한 고민.

비슷한 Terminology

- Primary DB <----> StandBy DB(Read도 불가능한 복제본 DB를 지칭하는 느낌이 강하다.)

- Primary DB <----> Secondary DB

=> Master DB <----> Slave DB(인종차별 문제로 해당 용어 사용은 지양하는 추세이다.)

=> Master DB <----> Replica DB

(Staging DB는 살짝 다른범주라고 생각해서 같이 두지는 않겠다.)

Multi A-Z

- Synchronous Replication : Primary Storage와 ReplicaDB에 동시에 data를 write함.

- Disaster Recovery 목적이 크다. 실제 서비스 시 필요한 옵션

=> application downtime(시스템을 이용할 수 없는 시간)이 발생하지 않는 real-time(instantaneous)방식으로 장애 대비 기능(fail-over)를 제공함.

- 예비 복제본 프로비저닝, Master DB 장애 발생시 StandBy Instance를 Master로 승격하며 새 StandBy DB Instance 생성하여 장애조치 수행

- Single AZ->Multi AZ 변경은 설정 몇번이 전부, Downtime 발생 X, DB정지 X, 내부적으로 DB의 스냅샷 생성 후 해당 스냅샷으로부터 다른 AZ에 새 DB가 생성되어 양 DB간의 동기화 수행

- 장애조치 완료 소요시간 : 대략 60~120초

Read Replica

- Asynchronous Replication : Primary Storage에 데이터를 write한 이후 ReplicaDB에 복사함.

- Traffic 대응 목적이 크다.

- 짧은 시간동안 Replica와 Master간의 데이터 차이 발생가능성 있음.

- Read Replica를 Master로 변경 가능

- Master DB에 write시 자동으로 Read Replica DB에 복제 수행. 즉시 복제 되는 것 아니며 약간의 시간차 발생

생각할거리

- Read Replica를 적용하였을때 master DB에 write 하는 경우 Replica DB에 반영되기까지 latency는 얼마나 소요되는가?

- latency가 많이 소요되는 경우 정확성이 높아야하는 최신 데이터가 요구되는경우에 MasterDB에서 read/write이 이루어지도록 해야하는가?

- Read Replica DB 장애발생하는 Case가 존재하면 수동으로 다른 Replica DB를 재활성해야하는지 여부.

Reference

Synchronous Replication VS asynchronous Replication

AWS RDS 공식문서

AWS RDS Multi-AZ,Replica 관련

Primary, Secondary DB Architecture