RDS 다중 AZ 구성으로 장애 대비하기

AWS RDS의 다중 AZ 구성을 통해 데이터베이스 고가용성을 확보하는 방법을 알아봅니다. 동기식 복제, 자동 장애 조치, 실습 방법까지 초급자도 이해할 수 있도록 쉽게 설명합니다.

---

목차

1. RDS_다중_AZ의_아키텍처
2. 동기식_복제의_동작_원리
3. 자동_장애_조치_프로세스
4. 다중_AZ_설정_실습
5. 장애_조치_테스트
6. 다중_AZ_vs_읽기_전용_복제본_비교

---

1. RDS 다중 AZ의 아키텍처

김개발 씨가 운영하던 서비스에 갑자기 장애가 발생했습니다. 데이터베이스 서버가 있는 데이터센터에 문제가 생긴 것입니다.

사용자들의 불만이 쏟아지고, 복구에만 몇 시간이 걸렸습니다. "어떻게 하면 이런 상황을 예방할 수 있을까요?"

**RDS 다중 AZ(Multi-AZ)**는 한마디로 데이터베이스의 백업 선수를 항상 대기시켜 두는 것입니다. 마치 축구 경기에서 주전 선수가 부상당하면 바로 교체 선수가 투입되는 것처럼, 메인 데이터베이스에 문제가 생기면 예비 데이터베이스가 즉시 역할을 대신합니다.

이것을 제대로 이해하면 서비스 중단 시간을 획기적으로 줄일 수 있습니다.

다음 코드를 살펴봅시다.

-- RDS 다중 AZ 아키텍처 개념 (AWS CLI)
-- 메인 DB 인스턴스: 가용 영역 A (예: ap-northeast-2a)
-- 스탠바이 DB 인스턴스: 가용 영역 B (예: ap-northeast-2b)

-- 다중 AZ 활성화된 RDS 인스턴스 생성
aws rds create-db-instance \
    --db-instance-identifier my-production-db \
    --db-instance-class db.t3.medium \
    --engine mysql \
    --master-username admin \
    --master-user-password MySecurePassword123 \
    --allocated-storage 100 \
    --multi-az  -- 핵심: 이 옵션이 다중 AZ를 활성화합니다

-- 현재 인스턴스의 다중 AZ 상태 확인
aws rds describe-db-instances \
    --db-instance-identifier my-production-db \
    --query 'DBInstances[0].MultiAZ'

김개발 씨는 스타트업에서 백엔드 개발을 담당하는 2년 차 개발자입니다. 어느 날 새벽 3시, 갑자기 휴대폰이 울렸습니다.

모니터링 시스템에서 보낸 알람이었습니다. 데이터베이스 서버가 응답하지 않는다는 내용이었습니다.

부랴부랴 노트북을 열어 확인해 보니, AWS의 특정 데이터센터에 하드웨어 장애가 발생한 것이었습니다. 단일 DB 인스턴스로 운영하고 있던 김개발 씨는 복구될 때까지 속수무책으로 기다릴 수밖에 없었습니다.

다음 날, 선배 박시니어 씨가 출근하자마자 김개발 씨에게 물었습니다. "혹시 다중 AZ 설정은 해두셨어요?" 김개발 씨는 멋쩍게 고개를 저었습니다.

그렇다면 다중 AZ 아키텍처란 정확히 무엇일까요? 쉽게 비유하자면, 다중 AZ는 마치 쌍둥이 데이터베이스를 운영하는 것과 같습니다.

형이 아프면 동생이 바로 일을 대신하는 것처럼, 메인 데이터베이스에 문제가 생기면 스탠바이 데이터베이스가 즉시 역할을 넘겨받습니다. 이 둘은 항상 똑같은 데이터를 가지고 있기 때문에 교체가 매끄럽게 이루어집니다.

여기서 **AZ(Availability Zone)**는 AWS 리전 내의 독립된 데이터센터를 의미합니다. 서울 리전(ap-northeast-2)을 예로 들면, 2a, 2b, 2c, 2d라는 네 개의 가용 영역이 있습니다.

각 가용 영역은 물리적으로 분리되어 있어서, 하나의 데이터센터에 화재나 정전이 발생해도 다른 데이터센터는 영향을 받지 않습니다. 다중 AZ 구성에서는 프라이머리 인스턴스가 가용 영역 A에, 스탠바이 인스턴스가 가용 영역 B에 위치합니다.

프라이머리가 모든 읽기와 쓰기 요청을 처리하는 동안, 스탠바이는 조용히 데이터를 동기화하며 대기합니다. 중요한 점은 스탠바이 인스턴스에는 직접 접속할 수 없다는 것입니다.

이것은 **읽기 전용 복제본(Read Replica)**과의 핵심적인 차이점입니다. 스탠바이는 오직 장애 상황에서만 활성화되는 진정한 백업입니다.

애플리케이션 입장에서는 아무것도 변경할 필요가 없습니다. 데이터베이스 연결에 사용하는 **엔드포인트(Endpoint)**는 항상 같습니다.

AWS가 내부적으로 트래픽을 현재 활성화된 인스턴스로 라우팅해 주기 때문입니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 조언을 들은 후, 김개발 씨는 즉시 다중 AZ 설정을 활성화했습니다. 비용이 약간 늘어났지만, 새벽에 급하게 일어나는 일은 확실히 줄었습니다.

실전 팁

💡 - 프로덕션 환경에서는 반드시 다중 AZ를 활성화하세요

• 스탠바이 인스턴스는 직접 접근이 불가능하므로 읽기 분산 용도로는 사용할 수 없습니다
• 다중 AZ 설정은 언제든지 수정 가능하지만, 변경 시 잠시 다운타임이 발생할 수 있습니다

---

2. 동기식 복제의 동작 원리

김개발 씨가 다중 AZ에 대해 배우다가 문득 궁금해졌습니다. "스탠바이 데이터베이스는 어떻게 메인과 똑같은 데이터를 유지하는 거죠?" 박시니어 씨가 화이트보드에 그림을 그리며 설명하기 시작했습니다.

**동기식 복제(Synchronous Replication)**는 메인 데이터베이스에 데이터가 저장될 때, 반드시 스탠바이에도 동시에 저장되어야 완료로 처리되는 방식입니다. 마치 중요한 문서에 두 사람이 동시에 서명해야 효력이 발생하는 것처럼, 두 곳에 모두 기록되어야 트랜잭션이 완료됩니다.

이렇게 하면 장애 발생 시에도 데이터 손실이 없습니다.

다음 코드를 살펴봅시다.

-- 동기식 복제 과정 이해하기 (개념적 흐름)

-- 1단계: 애플리케이션이 INSERT 요청 전송
INSERT INTO orders (user_id, product_id, quantity, created_at)
VALUES (1001, 'PROD-A', 3, NOW());

-- 2단계: 프라이머리 DB가 데이터를 로컬 스토리지에 기록
-- (AWS가 내부적으로 처리)

-- 3단계: 동시에 스탠바이 DB로 데이터 전송
-- (네트워크를 통한 동기 복제)

-- 4단계: 스탠바이 DB가 기록 완료 확인 응답
-- (양쪽 모두 기록 완료)

-- 5단계: 애플리케이션에 성공 응답 반환
-- Query OK, 1 row affected (0.02 sec)

-- 복제 지연 확인 (MySQL 예시)
SHOW SLAVE STATUS\G
-- Seconds_Behind_Master: 0 (동기식이므로 항상 0에 가까움)

박시니어 씨가 화이트보드 앞에 섰습니다. "데이터 복제에는 크게 두 가지 방식이 있어요.

동기식과 비동기식이죠." 김개발 씨가 고개를 갸웃거렸습니다. "둘이 뭐가 다른 거예요?" 박시니어 씨가 펜을 들어 그림을 그리기 시작했습니다.

"일상적인 예로 설명해 볼게요. 당신이 친구에게 카카오톡을 보낸다고 가정해 봅시다." 비동기식 복제는 메시지를 보내고 읽음 표시를 기다리지 않는 것과 같습니다.

보내기 버튼을 누르면 바로 다음 할 일을 할 수 있습니다. 상대방이 실제로 메시지를 받았는지는 나중에 확인됩니다.

빠르지만, 중간에 문제가 생기면 메시지가 유실될 수 있습니다. 반면 동기식 복제는 상대방이 메시지를 확인할 때까지 기다리는 것과 같습니다.

읽음 표시가 뜨고 나서야 비로소 보내기가 완료됩니다. 조금 느리지만, 메시지가 확실히 전달되었다는 것을 보장합니다.

RDS 다중 AZ는 바로 이 동기식 복제를 사용합니다. 왜 그럴까요?

데이터베이스에서 데이터 손실은 치명적이기 때문입니다. 쇼핑몰을 예로 들어봅시다.

고객이 100만 원을 결제했는데, 그 기록이 사라진다면 어떻게 될까요? 고객은 돈을 냈는데 주문 기록이 없고, 회사는 손해를 보게 됩니다.

이런 상황을 막기 위해 AWS는 동기식 복제를 선택했습니다. 구체적인 동작 과정을 살펴봅시다.

애플리케이션이 INSERT 쿼리를 실행하면, 프라이머리 DB는 먼저 자신의 스토리지에 데이터를 기록합니다. 동시에 스탠바이 DB로도 같은 데이터를 전송합니다.

스탠바이 DB가 "나도 기록 완료!"라고 응답을 보내면, 그제야 프라이머리 DB는 애플리케이션에 "성공"이라고 답합니다. 이 과정에서 중요한 점이 있습니다.

만약 스탠바이 DB가 응답하지 않으면 어떻게 될까요? 이 경우 트랜잭션은 실패로 처리됩니다.

데이터 무결성을 위해 양쪽 모두에 기록되어야만 성공으로 인정하는 것입니다. 물론 이 방식에는 성능 오버헤드가 있습니다.

두 곳에 기록하고 응답을 기다려야 하니, 단일 인스턴스보다 응답 시간이 약간 길어질 수 있습니다. 하지만 AWS는 프라이머리와 스탠바이 간에 고속 네트워크를 사용하기 때문에, 이 지연은 대부분 밀리초 단위로 미미합니다.

김개발 씨가 물었습니다. "그럼 읽기 전용 복제본도 동기식인가요?" 박시니어 씨가 고개를 저었습니다.

"아니요, 읽기 전용 복제본은 비동기식이에요. 용도가 다르거든요.

그건 나중에 자세히 비교해 볼게요."

실전 팁

💡 - 동기식 복제로 인한 지연은 보통 수 밀리초 정도로 미미합니다

• 데이터 무결성이 중요한 프로덕션 환경에서는 동기식 복제가 필수입니다
• 복제 상태는 AWS 콘솔이나 CloudWatch 메트릭으로 모니터링할 수 있습니다

---

3. 자동 장애 조치 프로세스

어느 날 박시니어 씨가 팀 미팅에서 발표를 했습니다. "다음 주에 인프라 점검이 있는데, 데이터베이스 장애 조치 테스트도 같이 진행하려고 합니다." 김개발 씨가 손을 들었습니다.

"장애가 발생하면 정확히 어떤 과정으로 전환되는 건가요?"

**자동 장애 조치(Automatic Failover)**는 프라이머리 DB에 문제가 감지되면 AWS가 자동으로 스탠바이를 새로운 프라이머리로 승격시키는 과정입니다. 마치 비행기 조종사가 의식을 잃으면 부조종사가 즉시 조종간을 잡는 것처럼, 사람의 개입 없이 자동으로 진행됩니다.

보통 60초에서 120초 내에 완료됩니다.

다음 코드를 살펴봅시다.

-- 장애 조치 이벤트 확인 (AWS CLI)
aws rds describe-events \
    --source-identifier my-production-db \
    --source-type db-instance \
    --duration 1440  -- 최근 24시간 이벤트

-- 결과 예시:
-- "Multi-AZ instance failover started"
-- "Multi-AZ instance failover completed"

-- 장애 조치 후 현재 가용 영역 확인
aws rds describe-db-instances \
    --db-instance-identifier my-production-db \
    --query 'DBInstances[0].AvailabilityZone'

-- 장애 조치 발생 시 애플리케이션에서의 재연결 처리 (Python)
import mysql.connector
from mysql.connector import Error
import time

def get_connection_with_retry(max_retries=5):
    for attempt in range(max_retries):
        try:
            connection = mysql.connector.connect(
                host='my-production-db.xxx.rds.amazonaws.com',
                database='myapp',
                user='admin',
                password='password'
            )
            return connection
        except Error as e:
            print(f"연결 실패 (시도 {attempt + 1}): {e}")
            time.sleep(2 ** attempt)  # 지수 백오프
    raise Exception("데이터베이스 연결 불가")

박시니어 씨가 화이트보드에 타임라인을 그리기 시작했습니다. "장애 조치 과정을 단계별로 설명해 볼게요." 1단계: 장애 감지입니다.

AWS는 프라이머리 DB의 상태를 지속적으로 모니터링합니다. 네트워크 연결 불가, 스토리지 장애, 인스턴스 비정상 종료 등 다양한 문제를 감지합니다.

문제가 감지되면 장애 조치 프로세스가 시작됩니다. 2단계: 스탠바이 승격입니다.

스탠바이 인스턴스가 새로운 프라이머리로 승격됩니다. 동기식 복제 덕분에 스탠바이는 이미 최신 데이터를 가지고 있으므로, 데이터 손실 없이 바로 서비스를 시작할 수 있습니다.

3단계: DNS 업데이트입니다. 여기가 핵심입니다.

AWS는 데이터베이스 엔드포인트의 DNS 레코드를 업데이트합니다. 기존에는 가용 영역 A의 IP를 가리키던 주소가, 이제 가용 영역 B의 IP를 가리키게 됩니다.

김개발 씨가 질문했습니다. "그럼 애플리케이션 코드를 수정해야 하나요?" 박시니어 씨가 고개를 저었습니다.

"아니요, 그게 다중 AZ의 장점이에요. 엔드포인트 주소 자체는 변하지 않거든요.

다만 한 가지 주의할 점이 있어요." DNS 캐싱 문제입니다. 일부 애플리케이션이나 커넥션 풀은 DNS 조회 결과를 캐싱합니다.

장애 조치 후에도 예전 IP 주소로 연결을 시도하면 실패하게 됩니다. 따라서 DNS TTL(Time To Live)을 적절히 설정하고, 연결 실패 시 재연결 로직을 구현해야 합니다.

위 코드에서 보듯이, 재시도 로직과 지수 백오프(Exponential Backoff) 패턴을 사용하면 일시적인 연결 실패를 우아하게 처리할 수 있습니다. 첫 번째 시도가 실패하면 2초 후에, 두 번째 실패하면 4초 후에 재시도하는 방식입니다.

장애 조치가 발생하는 상황은 다양합니다. 첫째, 인프라 장애입니다.

하드웨어 문제, 네트워크 장애, 데이터센터 문제 등이 여기에 해당합니다. 둘째, 계획된 유지보수입니다.

AWS가 패치를 적용하거나 하드웨어를 교체할 때도 장애 조치가 발생합니다. 셋째, 사용자 요청입니다.

테스트 목적으로 수동으로 장애 조치를 트리거할 수도 있습니다. 한 가지 알아둘 점이 있습니다.

장애 조치 중에는 약 60초에서 120초 정도 연결이 불가능할 수 있습니다. 완전한 무중단은 아니지만, 수동으로 복구하는 것에 비하면 획기적으로 짧은 시간입니다.

김개발 씨가 고개를 끄덕였습니다. "그래서 애플리케이션에 재연결 로직이 중요한 거군요." 박시니어 씨가 미소 지었습니다.

"맞아요. 인프라만 잘 구성한다고 끝이 아니에요.

애플리케이션도 장애 상황에 대비해야 해요."

실전 팁

💡 - 애플리케이션에 반드시 재연결 로직을 구현하세요

• DNS TTL을 30초 이하로 설정하여 빠른 전환을 보장하세요
• CloudWatch 알람을 설정하여 장애 조치 발생 시 알림을 받으세요

---

4. 다중 AZ 설정 실습

박시니어 씨가 김개발 씨에게 말했습니다. "이제 이론은 충분히 배웠으니, 직접 설정해 볼까요?" 김개발 씨는 노트북을 열고 AWS 콘솔에 접속했습니다.

실제로 다중 AZ를 설정하는 과정을 함께 살펴보겠습니다.

다중 AZ 설정은 RDS 인스턴스 생성 시 체크박스 하나로 활성화할 수 있습니다. 마치 스마트폰 설정에서 백업을 켜는 것처럼 간단합니다.

기존 인스턴스도 수정을 통해 언제든지 다중 AZ로 전환할 수 있습니다. 다만 전환 과정에서 잠시 다운타임이 발생할 수 있으니 유지보수 시간을 활용하는 것이 좋습니다.

다음 코드를 살펴봅시다.

-- 1. 새 RDS 인스턴스 생성 시 다중 AZ 활성화 (AWS CLI)
aws rds create-db-instance \
    --db-instance-identifier prod-mysql-db \
    --db-instance-class db.t3.medium \
    --engine mysql \
    --engine-version 8.0.35 \
    --master-username admin \
    --master-user-password 'SecurePass123!' \
    --allocated-storage 100 \
    --storage-type gp3 \
    --vpc-security-group-ids sg-12345678 \
    --db-subnet-group-name my-db-subnet-group \
    --multi-az \
    --backup-retention-period 7 \
    --preferred-backup-window "03:00-04:00" \
    --preferred-maintenance-window "Mon:04:00-Mon:05:00"

-- 2. 기존 인스턴스를 다중 AZ로 전환
aws rds modify-db-instance \
    --db-instance-identifier existing-db \
    --multi-az \
    --apply-immediately

-- 3. 다중 AZ 상태 확인
aws rds describe-db-instances \
    --db-instance-identifier prod-mysql-db \
    --query 'DBInstances[0].{MultiAZ:MultiAZ,AZ:AvailabilityZone,SecondaryAZ:SecondaryAvailabilityZone}'

김개발 씨가 AWS 콘솔에 접속했습니다. 박시니어 씨가 옆에서 가이드를 시작합니다.

"먼저 AWS Management Console에서 RDS 서비스로 이동하세요." 왼쪽 메뉴에서 데이터베이스를 클릭하고, 오른쪽 상단의 데이터베이스 생성 버튼을 누릅니다. 여기서 다양한 설정을 할 수 있는 화면이 나타납니다.

엔진 옵션에서 MySQL, PostgreSQL, MariaDB 등 원하는 데이터베이스 엔진을 선택합니다. 참고로 다중 AZ는 Aurora를 제외한 모든 RDS 엔진에서 지원됩니다.

Aurora는 자체적인 고가용성 메커니즘을 가지고 있습니다. 템플릿 섹션에서는 프로덕션, 개발/테스트, 프리 티어 중 하나를 선택할 수 있습니다.

프로덕션을 선택하면 다중 AZ가 기본으로 활성화됩니다. 스크롤을 내리면 가용성 및 내구성 섹션이 나옵니다.

여기서 핵심 설정을 합니다. 다중 AZ 배포에서 "대기 인스턴스 생성"을 선택하면 다중 AZ가 활성화됩니다.

김개발 씨가 물었습니다. "CLI로도 할 수 있나요?" 박시니어 씨가 고개를 끄덕였습니다.

"물론이죠. 인프라를 코드로 관리하는 Infrastructure as Code 관점에서는 CLI나 Terraform을 사용하는 게 더 좋아요." 위 코드의 첫 번째 예시가 바로 CLI를 사용한 생성 방법입니다.

--multi-az 플래그 하나만 추가하면 됩니다. 나머지 옵션들도 살펴봅시다.

--db-subnet-group-name은 RDS가 배치될 서브넷 그룹을 지정합니다. 다중 AZ를 사용하려면 최소 두 개의 가용 영역에 걸친 서브넷이 필요합니다.

하나의 가용 영역에만 서브넷이 있으면 다중 AZ 설정이 실패합니다. --backup-retention-period는 자동 백업 보관 기간입니다.

다중 AZ와 별개로 백업도 중요한 재해 복구 전략입니다. 이미 운영 중인 인스턴스를 다중 AZ로 전환하려면 어떻게 할까요?

modify-db-instance 명령을 사용합니다. --apply-immediately 옵션을 주면 즉시 적용되고, 생략하면 다음 유지보수 시간에 적용됩니다.

한 가지 주의할 점이 있습니다. 단일 AZ에서 다중 AZ로 전환할 때, AWS는 먼저 현재 인스턴스의 스냅샷을 생성합니다.

그리고 그 스냅샷으로부터 스탠바이 인스턴스를 생성합니다. 이 과정에서 I/O가 잠시 중단될 수 있으므로, 트래픽이 적은 시간에 진행하는 것이 좋습니다.

마지막으로 비용에 대해 언급하겠습니다. 다중 AZ를 활성화하면 인스턴스 비용이 약 2배가 됩니다.

스탠바이 인스턴스도 동일한 사양으로 유지되기 때문입니다. 하지만 장애로 인한 서비스 중단 비용을 생각하면, 프로덕션 환경에서는 충분히 가치 있는 투자입니다.

실전 팁

💡 - 서브넷 그룹에 최소 2개 가용 영역의 서브넷이 포함되어야 합니다

• 기존 인스턴스 전환 시 트래픽이 적은 시간을 선택하세요
• Terraform이나 CloudFormation으로 설정을 코드화하면 관리가 편합니다

---

5. 장애 조치 테스트

김개발 씨가 다중 AZ 설정을 완료하고 뿌듯해하고 있을 때, 박시니어 씨가 말했습니다. "설정만 하고 끝내면 안 돼요.

실제로 장애 조치가 잘 동작하는지 테스트해 봐야죠." 실전에서 문제가 발생하기 전에 미리 검증하는 것이 진정한 준비입니다.

장애 조치 테스트는 의도적으로 장애 상황을 만들어 시스템이 제대로 대응하는지 확인하는 과정입니다. 마치 소방 훈련처럼, 실제 화재가 발생하기 전에 대피 경로를 숙지하는 것과 같습니다.

AWS는 리부팅 옵션을 통해 안전하게 장애 조치를 테스트할 수 있는 방법을 제공합니다.

다음 코드를 살펴봅시다.

-- 장애 조치 강제 실행 (AWS CLI)
aws rds reboot-db-instance \
    --db-instance-identifier prod-mysql-db \
    --force-failover

-- 장애 조치 진행 상황 모니터링
aws rds describe-events \
    --source-identifier prod-mysql-db \
    --source-type db-instance \
    --duration 60

-- 모니터링 스크립트 (Python)
import boto3
import time
from datetime import datetime

def monitor_failover(db_instance_id):
    rds = boto3.client('rds')
    start_time = datetime.now()

    print(f"[{start_time}] 장애 조치 시작")

    while True:
        response = rds.describe_db_instances(
            DBInstanceIdentifier=db_instance_id
        )
        status = response['DBInstances'][0]['DBInstanceStatus']
        az = response['DBInstances'][0]['AvailabilityZone']

        elapsed = (datetime.now() - start_time).seconds
        print(f"[+{elapsed}초] 상태: {status}, 가용 영역: {az}")

        if status == 'available':
            print(f"장애 조치 완료! 총 소요 시간: {elapsed}초")
            break

        time.sleep(5)

# 실행: monitor_failover('prod-mysql-db')

박시니어 씨가 팀 회의에서 발표를 시작했습니다. "오늘은 장애 조치 테스트를 진행하겠습니다.

모두 모니터링 대시보드를 켜주세요." 장애 조치 테스트는 왜 필요할까요? 첫째, 설정이 제대로 되었는지 확인할 수 있습니다.

다중 AZ를 활성화했다고 해서 자동으로 모든 것이 완벽하게 동작하는 것은 아닙니다. 둘째, 복구 시간을 측정할 수 있습니다.

우리 시스템에서 장애 조치가 몇 초 만에 완료되는지 알아야 SLA를 정의할 수 있습니다. 셋째, 애플리케이션의 대응을 확인할 수 있습니다.

연결 풀이 제대로 재연결되는지, 에러 핸들링이 적절한지 검증합니다. 테스트를 시작하기 전에 준비해야 할 것들이 있습니다.

먼저 모니터링 환경을 구성합니다. CloudWatch 대시보드에서 데이터베이스 연결 수, CPU 사용률, 읽기/쓰기 지연 시간 등을 실시간으로 볼 수 있도록 합니다.

장애 조치 중 어떤 변화가 일어나는지 관찰하기 위해서입니다. 다음으로 테스트 시간을 선택합니다.

가능하면 트래픽이 가장 적은 시간대를 선택합니다. 아무리 테스트라도 실제 사용자에게 영향을 줄 수 있기 때문입니다.

이제 테스트를 진행합니다. aws rds reboot-db-instance 명령에 --force-failover 옵션을 추가하면 장애 조치가 강제로 실행됩니다.

이 명령을 실행하면 현재 프라이머리가 종료되고, 스탠바이가 새로운 프라이머리로 승격됩니다. 김개발 씨가 타이머를 시작했습니다.

명령 실행 후 약 30초가 지나자 데이터베이스 상태가 rebooting으로 변경되었습니다. 연결 수 그래프가 급격히 떨어지는 것이 보입니다.

60초가 지났습니다. 상태가 여전히 rebooting입니다.

김개발 씨의 테스트 애플리케이션에서 연결 실패 로그가 출력되고 있습니다. 하지만 재연결 로직이 작동하면서 계속 시도하고 있습니다.

85초가 지나자 상태가 available로 변경되었습니다. 가용 영역을 확인해 보니, 기존 ap-northeast-2a에서 ap-northeast-2b로 변경되어 있습니다.

장애 조치가 성공적으로 완료된 것입니다. 테스트 애플리케이션도 곧 정상적으로 연결되었습니다.

전체 다운타임은 약 70초였습니다. 박시니어 씨가 정리했습니다.

"이 정도면 우리 SLA인 99.9%를 충족할 수 있겠네요. 연간 다운타임 허용치가 약 8시간인데, 장애 조치 한 번에 2분이 안 걸리니까요." 테스트 후에는 반드시 결과를 문서화해야 합니다.

장애 조치 소요 시간, 발생한 에러 로그, 개선이 필요한 부분 등을 기록해 둡니다. 이 기록은 다음 테스트나 실제 장애 상황에서 귀중한 참고 자료가 됩니다.

실전 팁

💡 - 장애 조치 테스트는 분기별로 정기적으로 수행하세요

• 테스트 전 모든 팀원에게 사전 공지하여 혼란을 방지하세요
• 테스트 결과는 반드시 문서화하여 보관하세요

---

6. 다중 AZ vs 읽기 전용 복제본 비교

어느 날 신입 개발자 이주니어 씨가 김개발 씨에게 물었습니다. "선배, 다중 AZ랑 읽기 전용 복제본이랑 뭐가 다른 거예요?

둘 다 데이터베이스를 복제하는 거 아닌가요?" 김개발 씨는 잠시 생각하다가 박시니어 씨에게 배운 내용을 떠올렸습니다.

다중 AZ와 **읽기 전용 복제본(Read Replica)**은 모두 데이터베이스 복제를 사용하지만, 목적이 완전히 다릅니다. 다중 AZ는 고가용성을 위한 것이고, 읽기 전용 복제본은 읽기 성능 향상을 위한 것입니다.

마치 예비 운전자와 합승 운전자의 차이와 같습니다. 예비 운전자는 주 운전자가 아플 때만 운전하고, 합승 운전자는 평소에도 같이 운전합니다.

다음 코드를 살펴봅시다.

-- 다중 AZ 구성 확인
aws rds describe-db-instances \
    --db-instance-identifier prod-db \
    --query 'DBInstances[0].{MultiAZ:MultiAZ,SecondaryAZ:SecondaryAvailabilityZone}'
-- 결과: {"MultiAZ": true, "SecondaryAZ": "ap-northeast-2b"}

-- 읽기 전용 복제본 생성
aws rds create-db-instance-read-replica \
    --db-instance-identifier prod-db-read \
    --source-db-instance-identifier prod-db \
    --db-instance-class db.t3.medium \
    --availability-zone ap-northeast-2c

-- 읽기 전용 복제본 목록 확인
aws rds describe-db-instances \
    --db-instance-identifier prod-db \
    --query 'DBInstances[0].ReadReplicaDBInstanceIdentifiers'

-- 읽기 전용 복제본의 복제 지연 확인
aws cloudwatch get-metric-statistics \
    --namespace AWS/RDS \
    --metric-name ReplicaLag \
    --dimensions Name=DBInstanceIdentifier,Value=prod-db-read \
    --start-time 2024-01-01T00:00:00Z \
    --end-time 2024-01-01T01:00:00Z \
    --period 300 \
    --statistics Average

김개발 씨가 화이트보드에 두 개의 열을 그렸습니다. "비교표를 만들어서 설명해 줄게요." 첫 번째 차이점은 목적입니다.

다중 AZ의 목적은 **고가용성(High Availability)**입니다. 프라이머리에 장애가 발생했을 때 서비스가 중단되지 않도록 하는 것이 목표입니다.

반면 읽기 전용 복제본의 목적은 읽기 성능 향상입니다. 읽기 트래픽을 분산시켜 프라이머리의 부하를 줄이는 것이 목표입니다.

두 번째 차이점은 복제 방식입니다. 다중 AZ는 동기식 복제를 사용합니다.

앞서 배웠듯이, 프라이머리와 스탠바이 모두에 데이터가 기록되어야 트랜잭션이 완료됩니다. 읽기 전용 복제본은 비동기식 복제를 사용합니다.

프라이머리에 먼저 기록하고, 나중에 복제본으로 전파됩니다. 그래서 복제 지연(Replica Lag)이 발생할 수 있습니다.

세 번째 차이점은 접근 가능 여부입니다. 다중 AZ의 스탠바이 인스턴스에는 직접 접근할 수 없습니다.

오직 장애 조치 시에만 활성화됩니다. 읽기 전용 복제본은 별도의 엔드포인트가 있어서 언제든지 읽기 쿼리를 실행할 수 있습니다.

네 번째 차이점은 장애 조치입니다. 다중 AZ는 장애 조치가 자동으로 이루어집니다.

프라이머리에 문제가 생기면 스탠바이가 자동으로 승격됩니다. 읽기 전용 복제본은 수동으로 프라이머리로 승격시켜야 합니다.

자동 장애 조치 기능이 없습니다. 이주니어 씨가 물었습니다.

"그럼 둘 중 하나만 선택해야 하나요?" 김개발 씨가 고개를 저었습니다. "아니요, 둘을 함께 사용할 수 있어요.

사실 프로덕션 환경에서는 둘 다 사용하는 경우가 많아요." 구체적인 시나리오를 생각해 봅시다. 대형 이커머스 사이트를 운영한다고 가정합니다.

상품 조회는 읽기 작업이고, 주문은 쓰기 작업입니다. 일반적으로 읽기가 쓰기보다 훨씬 많습니다.

이 경우 다중 AZ로 프라이머리를 구성하여 고가용성을 확보합니다. 주문 처리 같은 중요한 쓰기 작업이 장애로 중단되면 안 되기 때문입니다.

동시에 읽기 전용 복제본을 여러 개 생성하여 상품 조회 트래픽을 분산시킵니다. 프라이머리의 부하를 줄이고 응답 속도를 개선할 수 있습니다.

비용 측면에서도 차이가 있습니다. 다중 AZ는 스탠바이 인스턴스 비용이 프라이머리와 동일합니다.

읽기 전용 복제본은 인스턴스 사양을 다르게 설정할 수 있어서 비용을 유연하게 조절할 수 있습니다. 마지막으로 리전 간 배치 차이가 있습니다.

다중 AZ의 스탠바이는 같은 리전 내 다른 가용 영역에만 배치됩니다. 읽기 전용 복제본은 다른 리전에도 생성할 수 있습니다.

글로벌 서비스를 운영할 때 사용자와 가까운 리전에 복제본을 두면 지연 시간을 줄일 수 있습니다. 이주니어 씨가 고개를 끄덕였습니다.

"이제 차이가 확실히 이해됐어요. 목적이 다른 거였군요!"

실전 팁

💡 - 프로덕션 환경에서는 다중 AZ와 읽기 전용 복제본을 함께 사용하는 것을 권장합니다

• 읽기 전용 복제본의 복제 지연은 CloudWatch ReplicaLag 메트릭으로 모니터링하세요
• 재해 복구(DR)를 위해 다른 리전에 읽기 전용 복제본을 배치하는 것도 좋은 전략입니다

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!