[AWS RDS] 배포 전략
01. 배포 옵션 선택
RDS를 배포하기 위해 가용성 및 내구성을 인프라에 맞게 선택하자!
💁♂️다중 AZ DB 클러스터 배포
- 구성 : 하나의 Writer + 최대 2개의 Reader 인스턴스 (모두 서로 다른 AZ에 위치)
- 복제 방식 : 공유 스토리지 기반
- FailOver : Writer 장애 시 Reader 중 하나가 Writer로 승격됨
- 읽기 처리 : Reader 인스턴스에서 읽기 분산 가능
1. 장점
- 고가용성 + 읽기 성능 확장
- Reader 인스턴스를 통해 읽기 부하 분산
- 장애 시 빠른 Failover (30초 이내)
2. 단점
- 비용이 더 높을 수 있음
- 일부 RDS 엔진에서만 지원 (예: MySQL, PostgreSQL)
💁♂️다중 AZ DB 인스턴스 배포
- 구성 : 하나의 Primary (Writer) 인스턴스 + 하나의 Standby 인스턴스 (다른 AZ에 위치)
- 복제 방식 : 동기식 복제 (Synchronous replication)
- FailOver : Primary 장애 시 Standby가 자동으로 승격됨
- 읽기 처리 : 읽기 전용 인스턴스 없음 → 모든 읽기/쓰기는 Primary에서 처리
1. 장점
- 고가용성 (HA) 보장
- 자동 장애 조치 (Failover)
2. 단점
- Standby는 평소에 읽기 처리 불가 → 리소스 낭비
- 성능 확장성 부족 (읽기 부하 분산 불가)
즉, 한마디로 표현하자면?
다중 AZ DB 클러스터 배포 : "운전자는 한 명이지만, 옆에 두 명의 내비게이터가 실시간으로 도와주는 구조"
다중 AZ DB 인스턴스 배포 : "백업 운전자가 옆에 앉아 있다가 사고 나면 운전대를 잡는 구조"
1-1. 인프라 아키텍처에 따라 전략 선택
📌 단순한 웹 애플리케이션 [트래픽 적음, 고가용성만 필요]
- 예시 : 사내 포털, 내부 관리 시스템
- 요구 사항 : 장애 시 자동복구, 읽기 부하 적음
- 추천 옵션 : 다중 AZ DB 인스턴스 배포
- 이유 : Standby 인스턴스를 통해 장애 복구 가능, 비용 효율적
📌 읽기 부하가 많은 애플리케이션 서비스 [쇼핑몰, 뉴스, 커뮤니티 등..]
- 예시 : 상품 조회, 게시글 조회가 많은 서비스
- 요구 사항 : 읽기 성능 확장, 고가용성
- 추천 옵션 : 다중 AZ DB 클러스터 (Multi-AZ DB Cluster)
- 이유 : Reader 인스턴스를 통해 읽기 부하 분산 가능 + 빠른 장애 복구
📌 글로벌 서비스 [리전 간 복제 필요]
- 예시 : 글로벌 SaaS, 해외 지사 연동
- 요구 사항 : 리전 간 데이터 복제, 재해 복구
- 추천 옵션 : Read Replica + Cross-Region Read Replica
- 이유 : 읽기 전용 복제본을 다른 리전에 배포 가능
이런 식으로 기업의 인프라 환경에 맞춰서 RDS 배포 전략을 알맞게 선택 후
비용적인 측면이나 효율적으로 운영을 해보자!
02. 데이터 흐름 / 역할
Writer, Reader 라는 용어가 좀 추상적으로 느껴질 수 있어서 실제 데이터 흐름과 역할 기반으로 설명해볼게요.
💁♂️Writer 인스턴스
- SQL로 보면 INSERT, UPDATE, DELETE 같은 쿼리가 Writer로 간다.
- 예를 들면, 사용자가 웹사이트에 회원가입 하거나 게시글을 작성 하거나 주문을 넣는 등의 데이터 변경 작업이 발생한다면 이 데이터를 모두 Writer 인스턴스가 처리한다.
예시 : 사용자가 쇼핑몰에서 주문 → 주문 정보가 DB에 저장됨 → Writer 인스턴스에서 처리
💁♂️Reader 인스턴스
- SQL로 보면 SELECT 쿼리가 Reader로 간다.
- 예를 들면, 사용자가 상품 목록을 조회하거나 게시글을 읽고 주문 내역을 확인하는 등의 데이터 조회 작업이 발생한다면 이 데이터를 모두 Reader 인스턴스가 처리한다.
예시 : 사용자가 마이페이지에서 주문 내역을 조회 → Reader 인스턴스에서 처리
Data Flow에 적용하였을때 다중 AZ DB 클러스터 vs DB 인스턴스 배포 옵션 비교
항목 다중 AZ DB 인스턴스 다중 AZ DB 클러스터 Writer 1개 (쓰기 + 읽기) 1개 (쓰기 전용) Reader 없음 (읽기도 Writer가 처리) 1~2개 (읽기 전용 인스턴스 존재) 읽기 부하 분산 불가능 가능 (Reader로 분산) 예시 단순한 트랜잭션 처리 시스템 읽기 부하가 많은 서비스 (예: 뉴스, 쇼핑몰 등)
📌 요약
- Writer : 데이터 변경 작업 담당자
- Reader : 데이터 조회 작업 담당자
- 다중 AZ DB 인스턴스 : "백업용"이라 평소에는 혼자 Wirter 혼자 일처리
- 다중 AZ DB 클러스터 : "팀플레이"라 Writer는 쓰기, Reader는 읽기 전담.
RDS 배포 전략에 대해 알아보았고, 다음에는 RDS에서 사용중인 인스턴스의 엔진을 업그레이드 하기 위해
Blue - Green 배포에 대해 포스팅 해보도록 하겠습니다
감사합니다 :)