리전 장애에 대비한 DR을 설계하라

상황

결제 중개 서비스가 단일 리전에서 다중 가용 영역으로 운영되고 있습니다. 가용 영역 장애에는 대비되어 있지만, 리전 전체가 손상되는 경우에는 복구 계획이 없습니다. 경영진은 다음을 요구했습니다.

• 리전 장애가 나도 결제 기록이 유실되면 안 됩니다.
• 서비스는 수십 분 안에 다른 리전에서 재개되어야 합니다.
• 평상시 비용은 현재의 두 배가 되어서는 안 됩니다.
• 규정상 데이터는 국내 리전 안에서만 처리되어야 합니다.

현재 구성은 이렇습니다.

먼저 RTO와 RPO를 숫자로 만든다

두 값은 서로 독립적으로 정해집니다. RPO는 데이터 복제 방식이 결정하고, RTO는 대상 리전의 준비 수준이 결정합니다. RPO를 0에 가깝게 만들면서 RTO는 몇 시간을 허용하는 설계도 가능하고, 그 반대도 가능합니다.

이 케이스에서는 요구가 갈립니다 — 결제 기록은 RPO가 매우 작아야 하지만, 서비스 재개는 수십 분을 허용합니다. 그래서 데이터는 상시 복제하되 컴퓨팅은 최소만 켜 두는 구성이 자연스럽게 나옵니다.

후보 설계안 비교 — DR 4전략

네 전략의 차이는 한 문장으로 요약됩니다 — 평상시에 대상 리전에서 무엇이 켜져 있는가.

선택과 근거

C · 웜 스탠바이를 고릅니다. RTO 요구(수십 분)는 인프라를 새로 만들 여유가 없다는 뜻이고, 비용 제약은 운영 규모를 그대로 두 벌 유지할 수 없다는 뜻입니다. 축소된 규모로 상시 가동하되 장애 시 확장하는 구성이 두 요구 사이에 정확히 놓입니다.

규정 제약(국내 리전)은 대상 리전 후보를 좁힙니다. 데이터가 국경을 넘어서는 안 된다면, 다른 나라의 리전은 아무리 가깝고 싸도 선택지가 아닙니다. 국내에 사용 가능한 리전이 하나뿐이라면 DR 전략 자체를 다시 논의해야 하며, 이 사실을 먼저 확인합니다.

결정 1 · 데이터 복제

aws s3api put-bucket-versioning \
  --bucket example-receipts-primary \
  --versioning-configuration Status=Enabled

aws s3api put-bucket-versioning \
  --bucket example-receipts-dr \
  --versioning-configuration Status=Enabled

aws s3api put-bucket-replication \
  --bucket example-receipts-primary \
  --replication-configuration file://replication.json

{
  "Role": "arn:aws:iam::123456789012:role/S3ReplicationRole",
  "Rules": [
    {
      "ID": "receipts-to-dr",
      "Status": "Enabled",
      "Priority": 1,
      "Filter": { "Prefix": "" },
      "DeleteMarkerReplication": { "Status": "Disabled" },
      "Destination": {
        "Bucket": "arn:aws:s3:::example-receipts-dr",
        "StorageClass": "STANDARD_IA"
      }
    }
  ]
}

aws rds create-db-instance-read-replica \
  --db-instance-identifier payments-dr \
  --source-db-instance-identifier arn:aws:rds:ap-northeast-2:123456789012:db:payments-prod \
  --region us-west-2

# 장애 시에는 복제본을 독립 인스턴스로 승격합니다. 자동으로 일어나지 않습니다.
aws rds promote-read-replica \
  --db-instance-identifier payments-dr \
  --region us-west-2

위 예시의 리전 코드는 명령 형태를 보이기 위한 값입니다. 실제 대상 리전은 규정 제약(데이터 레지던시)을 먼저 확인해 정합니다.

결정 2 · 전환 경로

데이터가 대상 리전에 있어도 사용자를 그쪽으로 보내지 못하면 복구가 아닙니다. Amazon Route 53의 장애 조치 라우팅은 상태 확인 결과에 따라 기본(primary) 레코드에서 보조(secondary) 레코드로 응답을 바꿉니다.

결정 3 · 대상 리전의 용량

웜 스탠바이에서 가장 자주 간과되는 위험이 여기 있습니다. 장애가 나면 우리만 확장하는 것이 아닙니다. 같은 리전을 DR 대상으로 삼은 다른 조직들도 동시에 확장을 시도하므로, 필요한 만큼의 인스턴스를 즉시 얻지 못할 수 있습니다.

• 축소된 규모라도 실제로 가동해 두면 그만큼은 이미 확보된 것입니다. 이것이 파일럿 라이트보다 웜 스탠바이의 RTO가 짧은 이유이기도 합니다.
• 중요한 워크로드는 용량 예약을 검토합니다.
• 인스턴스 타입을 하나로 고정하지 말고 대체 가능한 타입 목록을 시작 템플릿에 넣어 둡니다.

결정 4 · 인프라를 코드로

현재 인프라의 일부만 CloudFormation으로 정의되어 있다는 점은 그 자체로 위험입니다. 수동으로 만든 리소스는 대상 리전에 재현할 방법이 사람의 기억뿐입니다.

• 모든 계층을 템플릿으로 정의하고, 리전에 따라 달라지는 값은 파라미터로 뺍니다.
• 템플릿을 대상 리전에도 실제로 배포해 봅니다. 배포해 보지 않은 템플릿은 검증되지 않은 계획입니다.
• AWS CloudFormation은 시험 범위 안이며, 이 사이트도 정식으로 다룹니다.

비용과 운영에 미치는 영향

설계 체크리스트

요구 정의

• RTO와 RPO를 워크로드별로 정의했다 (하나의 값으로 뭉뚱그리지 않았다)
• 데이터 레지던시 등 규정 제약으로 대상 리전 후보를 먼저 좁혔다
• 요구 RTO·RPO에 맞는 전략을 골랐고, 그 근거를 문서로 남겼다
• 평상시 비용 상한을 정하고 전략과 대조했다

데이터

• 모든 데이터 저장소에 리전 간 복제 또는 복사 수단이 배정되어 있다
• S3 교차 리전 복제를 쓴다면 양쪽 버킷의 버전 관리가 켜져 있다
• 규칙 생성 이전 객체를 옮기는 계획이 있다
• 암호화된 스냅샷·객체의 대상 리전 키 설정을 확인했다
• 읽기 전용 복제본 승격이 수동이라는 사실이 절차서에 반영되어 있다
• 복제 지연을 지표로 감시하고 있다

전환

• DNS 레코드에 장애 조치 라우팅과 상태 확인이 구성되어 있다
• DR 관련 레코드의 TTL이 짧다
• 상태 확인이 의존 관계까지 확인하는 경로를 본다
• 전환을 누가 언제 결정하는지(사람인지 자동인지) 정해져 있다
• 원래 리전이 복구됐을 때 되돌리는 절차도 정의되어 있다

훈련

• 대상 리전에 인프라 템플릿을 실제로 배포해 봤다
• 백업에서 복원하는 절차를 실제로 수행해 봤다
• 전환 훈련의 측정된 소요 시간이 요구 RTO 안에 들어간다
• 훈련 주기가 정해져 있고 담당이 지정되어 있다
• 두 리전의 구성 차이(드리프트)를 감지하는 수단이 있다

관련 시험 포인트

이어서 볼 곳

• 18장 · 비용 최적화 · 마이그레이션 · 재해 복구 DR 4전략과 RTO·RPO의 교환, 6R 마이그레이션 전략을 정면으로 다룹니다. 기본개념 · 도메인 2·4
• 14장 · 엣지와 DNS Route 53 라우팅 정책 8종과 상태 확인, Global Accelerator의 차이를 다룹니다. 기본개념 · 도메인 3
• 케이스 5 · 단일 AZ 설계가 장애로 전면 중단됐다 가용 영역 수준의 대비가 먼저입니다. 그 위에 리전 대비를 얹습니다. 아키텍처 케이스
• 케이스 10 · 규정 준수 감사에 대응하라 데이터 레지던시와 보관 요구가 DR 설계를 어떻게 제약하는지 이어서 봅니다. 아키텍처 케이스
• 실습 4 · RDS Multi-AZ와 읽기 전용 복제본 장애 조치와 복제본 승격의 차이를 직접 실행해 확인합니다. 실습 예제
• 복원력 있는 아키텍처 설계 (26%) 고가용성과 내결함성, DR의 출제 포인트를 정리했습니다. 시험 대비

공식 문서 출처

• Amazon S3 사용 설명서 — 객체 복제 — 버전 관리 전제, 규칙 생성 이전 객체가 복제되지 않는다는 제약, 대상 스토리지 클래스 지정
• Amazon S3 API 레퍼런스 — PutBucketReplication — 복제 규칙의 요소와 삭제 마커 복제 설정
• Amazon RDS 사용 설명서 — 읽기 전용 복제본 사용 — 비동기 복제, 교차 리전 생성, 승격이 별도의 작업이라는 서술
• Amazon RDS API 레퍼런스 — CreateDBInstanceReadReplica — 원본을 ARN으로 지정해 다른 리전에 복제본을 만드는 방법
• Amazon DynamoDB 개발자 안내서 — 글로벌 테이블 — 다중 리전 복제의 동작과 일관성 모드
• Amazon Route 53 개발자 안내서 — DNS 장애 조치 구성 — 기본·보조 레코드와 상태 확인의 연동
• Amazon Route 53 개발자 안내서 — 엔드포인트 상태 판정 — 상태 확인이 정상·비정상을 확정하는 방식
• Amazon Route 53 개발자 안내서 — 라우팅 정책 선택 — 장애 조치 · 가중치 기반 등 정책별 용도
• AWS Backup 개발자 안내서 — 복구 지점 복사 — 리전 간 백업 복사 동작