[AWS SAA] 재해복구 / 마이그레이션

RTO / RPO 개념

개념	설명
RTO	Recovery Time Objective. 장애 발생 후 서비스 복원까지 허용되는 최대 시간
RPO	Recovery Point Objective. 장애 발생 시 손실을 허용할 수 있는 최대 데이터 시간

• RTO는 “얼마나 빨리 복구해야 하는가”에 대한 목표
• RPO는 “얼마나 최근 데이터까지 복구해야 하는가”에 대한 목표
• 낮은 RTO/RPO는 빠른 복구와 데이터 손실 최소화를 의미
• 낮은 RTO/RPO를 달성하려면 일반적으로 더 많은 비용과 복잡한 구성이 필요
• 높은 RTO/RPO는 복구 시간이 길고 데이터 손실 가능성이 더 크지만 비용은 상대적으로 낮음

DR 전략 비교

전략	RTO	RPO	특징
Backup and Restore	높음	높음	백업만 보관하고 장애 시 인프라와 데이터를 복원
Pilot Light	중간	낮음~중간	핵심 데이터 계층만 유지하고 장애 시 애플리케이션 계층 확장
Warm Standby	낮음	낮음	축소된 전체 환경을 항상 실행하고 장애 시 확장
Multi-Site Active/Active	매우 낮음	매우 낮음	여러 리전에서 동시에 실제 트래픽 처리

• Backup and Restore는 가장 저렴하지만 복구 시간이 가장 김
• Pilot Light는 핵심 구성요소만 미리 켜두고 장애 시 나머지 리소스를 빠르게 확장
• Warm Standby는 축소 규모의 전체 시스템이 항상 실행 중이므로 Pilot Light보다 복구가 빠름
• Multi-Site Active/Active는 여러 리전이 동시에 트래픽을 처리하므로 RTO/RPO가 가장 낮지만 비용과 운영 복잡도가 가장 높음

Backup and Restore

• 데이터를 S3, Glacier, AWS Backup, EBS Snapshot, RDS Snapshot 등에 백업
• 장애 발생 시 백업에서 데이터를 복원하고 인프라를 다시 배포
• 실제 애플리케이션 리소스가 복구 리전에서 항상 실행 중이지 않을 수 있음
• 가장 저렴한 DR 전략
• 복구 시간이 길어도 되는 워크로드에 적합
• IaC를 사용하면 복구 시 인프라 재생성 시간을 줄일 수 있음
• 장기 보관 데이터는 S3 Glacier 계열을 사용할 수 있지만, 검색 시간이 길어질 수 있으므로 빠른 RTO가 필요한 경우 주의

Pilot Light

• 핵심 데이터 계층만 복구 리전에 계속 유지하는 전략
• 예를 들어 데이터베이스 복제본, 최소 네트워크 구성, 핵심 설정만 유지
• 장애 발생 시 애플리케이션 서버, Auto Scaling Group, 로드 밸런서 등을 빠르게 확장하여 서비스 복구
• Backup and Restore보다 빠르지만 Warm Standby보다 느릴 수 있음
• 비용과 복구 시간 사이의 균형이 필요한 경우 적합

Warm Standby

• 복구 리전에 축소 규모의 전체 애플리케이션 환경을 항상 실행하는 전략
• 장애 발생 시 축소된 환경을 프로덕션 규모로 확장하고 트래픽을 전환
• Pilot Light보다 더 빠른 복구가 가능
• 리소스가 항상 일부 실행 중이므로 Backup and Restore나 Pilot Light보다 비용이 높음
• 수 분 단위 복구가 필요한 서비스에 적합

Multi-Site Active/Active

• 여러 리전에서 애플리케이션이 동시에 실행되고 실제 트래픽을 처리하는 전략
• Route 53, Global Accelerator, DynamoDB Global Tables, Aurora Global Database 등을 조합할 수 있음
• 리전 장애 시 다른 리전이 이미 트래픽을 처리하고 있으므로 복구 시간이 매우 짧음
• RTO/RPO를 매우 낮게 가져갈 수 있음
• 가장 높은 가용성을 제공하지만 비용과 운영 복잡도가 가장 큼
• 데이터 충돌, 글로벌 쓰기 전략, 세션 관리, 일관성 모델을 신중하게 설계해야 함

재해 복구 선택 가이드

RPO/RTO 목표	전략
수 시간 이상 허용	Backup and Restore
수십 분 수준 허용	Pilot Light
수 분 수준 허용	Warm Standby
거의 0에 가까운 복구 목표	Multi-Site Active/Active

• 매우 낮은 RPO와 다중 리전 읽기 복제가 필요하면 Aurora Global Database 고려
• 다중 리전 NoSQL 읽기/쓰기가 필요하면 DynamoDB Global Tables 고려
• 정적 콘텐츠나 객체 데이터를 다른 리전에 복제해야 하면 S3 Cross-Region Replication 고려
• 글로벌 트래픽 라우팅과 장애 조치가 필요하면 Route 53 또는 Global Accelerator 고려

AWS Backup

• AWS Backup은 여러 AWS 서비스의 백업을 중앙에서 관리하는 서비스
• EC2, EBS, RDS, Aurora, DynamoDB, EFS, FSx, Storage Gateway 등 다양한 리소스 백업을 관리할 수 있음
• 백업 계획, 백업 일정, 보존 기간, 백업 Vault를 중앙에서 관리 가능
• 교차 리전 백업과 교차 계정 백업을 지원
• 조직 단위 백업 정책 관리에 적합
• 보안 데이터 보호와 백업 업무 중앙 관리 요구사항에 적합
• 백업 데이터 보호를 강화하려면 Backup Vault Lock을 고려할 수 있음
• Backup and Restore 전략에서 핵심 서비스로 자주 사용

CloudFront Origin Failover

• CloudFront는 여러 오리진을 오리진 그룹으로 구성할 수 있음
• 기본 오리진 장애 시 보조 오리진으로 Failover 가능
• 예를 들어 기본 S3 버킷 장애 시 다른 리전의 복제된 S3 버킷으로 장애 조치 가능
• 정적 콘텐츠 배포의 가용성을 높일 때 유용
• S3 Cross-Region Replication과 함께 사용하면 다른 리전의 객체 복제본을 보조 오리진으로 활용 가능

DynamoDB PITR vs Glacier

항목	DynamoDB PITR	S3 Glacier 계열
목적	특정 시점 복구	장기 보관
복구 속도	비교적 빠른 복구 목적	스토리지 클래스에 따라 검색 시간이 길 수 있음
사용 사례	실수 삭제, 잘못된 업데이트 복구	규정 준수, 장기 아카이브
RPO/RTO 관점	짧은 RPO 요구사항에 적합	빠른 RTO/RPO 요구사항에는 부적합할 수 있음

• DynamoDB PITR은 특정 시점으로 테이블을 복구해야 할 때 사용
• Glacier는 비용 효율적인 장기 보관에 적합
• 빠른 복구가 필요한 운영 데이터는 Glacier만으로 대응하기 어려울 수 있음

DMS

핵심 개념

• DMS는 Database Migration Service의 약자
• 데이터베이스 마이그레이션에 사용하는 서비스
• 동종 DB 엔진 간 이전과 이기종 DB 엔진 간 이전을 모두 지원
• CDC, 즉 Change Data Capture 기반 지속적 복제를 지원
• 마이그레이션 중 소스 DB의 변경 사항을 대상 DB에 계속 반영하여 다운타임을 줄일 수 있음
• DMS CDC는 지속 복제에 적합하지만, 지연 시간이 0인 실시간 복제를 보장하는 서비스는 아님
• DB 엔진을 변경하는 이기종 마이그레이션에서는 SCT와 함께 사용하는 경우가 많음

DMS 사용 시나리오

시나리오	설명
동종 DB 엔진 이전	Oracle → Oracle, MySQL → Aurora MySQL, PostgreSQL → RDS PostgreSQL
이기종 DB 엔진 이전	Oracle → Aurora PostgreSQL, SQL Server → MySQL
최소 다운타임 이전	Full Load + CDC 구성
지속 복제	CDC Only 구성
서버리스 복제	DMS Serverless 사용

DMS 마이그레이션 유형

유형	설명
Full Load	전체 데이터를 한 번에 이전
Full Load + CDC	전체 데이터 이전 후 변경 사항을 지속적으로 동기화
CDC Only	기존 초기 적재 이후 변경 데이터만 지속적으로 동기화

• Full Load는 초기 전체 데이터 적재에 사용
• Full Load + CDC는 전체 데이터 이전 후 변경분을 계속 반영해야 할 때 사용
• CDC Only는 이미 데이터가 적재된 상태에서 변경분만 동기화할 때 사용
• DMS Serverless는 복제 워크로드에 따라 컴퓨팅과 메모리 리소스를 자동으로 할당

SCT

• SCT는 Schema Conversion Tool의 약자
• 이기종 DB 간 스키마 변환에 사용하는 도구
• Oracle → Aurora PostgreSQL, SQL Server → Aurora PostgreSQL처럼 DB 엔진을 바꾸는 경우 사용
• 테이블, 인덱스, 뷰, 함수, 저장 프로시저 등을 변환하는 데 도움
• 자동 변환이 어려운 객체는 수동 수정이 필요할 수 있음
• 일반적인 조합은 SCT로 스키마 변환 후 DMS로 데이터를 이전하는 방식

DataSync

• DataSync는 데이터 이동과 동기화를 자동화하는 서비스
• 온프레미스 스토리지, 다른 클라우드, AWS 스토리지 간 데이터를 전송할 수 있음
• S3, EFS, FSx for Windows File Server, FSx for Lustre, FSx for NetApp ONTAP 등과 연동 가능
• 파일 데이터뿐 아니라 메타데이터도 함께 전송 가능
• 일정 기반 반복 전송을 구성할 수 있음
• 파일 서버, NAS, 오브젝트 스토리지에서 AWS 스토리지로 마이그레이션할 때 적합
• 온라인 네트워크 전송이 가능하고 반복 동기화가 필요하면 DataSync 고려
• 네트워크 대역폭이 부족하거나 온라인 전송이 현실적으로 어렵다면 Snow Family 고려
• 온프레미스 애플리케이션이 기존 방식으로 AWS 스토리지에 계속 접근해야 하면 Storage Gateway가 더 적합할 수 있음

Snow Family

• Snow Family는 네트워크로 전송하기 어렵거나 시간이 오래 걸리는 대용량 데이터를 물리 장비로 이전하는 서비스
• 대역폭이 부족하거나 보안상 오프라인 반출입이 필요한 경우 사용
• 1회성 또는 제한된 기간의 대용량 오프라인 이전 요구사항에 적합
• 엣지 환경에서 데이터 수집, 전처리, 간단한 컴퓨팅을 수행할 때도 사용할 수 있음

Snow Family 유형

유형	특징
Snowcone	작은 용량의 엣지/오프라인 이전 장비. 휴대성이 높음
Snowball Edge Storage Optimized	대용량 데이터 오프라인 이전에 적합
Snowball Edge Compute Optimized	엣지 환경에서 컴퓨팅 작업이 필요한 경우 적합

• Snowball Edge Storage Optimized는 대용량 데이터 이전에 적합
• 최신 Snowball Edge Storage Optimized 장비는 210TB급 usable storage 옵션을 제공
• 기존 시험 자료나 예전 문서에서는 80TB급 Snowball Edge가 등장할 수 있으므로 문제의 전제에 맞춰 판단
• 수십 TB~PB 단위 데이터 이전에는 Snowball Edge 여러 대를 사용할 수 있음
• 소규모 엣지 환경이나 휴대성이 중요하면 Snowcone 고려
• 10PB 이상의 초대용량 이전은 SAA 시험에서는 보통 Snowball Edge 여러 대 또는 AWS와 별도 협의가 필요한 시나리오로 이해하면 안전
• 반복 백업이나 지속 접근 목적이라면 Snowball보다 DataSync, Storage Gateway, Backup 등을 고려

Application Migration Service

• Application Migration Service는 MGN이라고도 부름
• 온프레미스, 다른 클라우드, 가상 서버, 물리 서버를 AWS로 lift-and-shift 이전할 때 사용
• 서버 단위 마이그레이션에 적합
• 소스 서버에 AWS Replication Agent를 설치하여 블록 레벨로 지속 복제
• 초기 복제 후 변경된 블록을 계속 복제하여 컷오버 시 다운타임을 줄임
• 복제된 서버는 AWS에서 EC2 인스턴스로 변환되어 실행됨
• 애플리케이션을 크게 수정하지 않고 빠르게 AWS로 이전해야 할 때 적합
• 리팩터링보다는 Rehost, 즉 lift-and-shift 전략에 가까움

Application Discovery Service

• Application Discovery Service는 온프레미스 서버와 데이터베이스의 사용 및 구성 데이터를 수집하는 서비스
• 서버 사양, 네트워크 연결, 사용률, 종속성 정보를 수집할 수 있음
• 마이그레이션 대상 시스템을 파악하고 이전 계획을 세울 때 사용
• AWS Migration Hub와 연동하여 마이그레이션 계획과 진행 상황을 관리할 수 있음
• 마이그레이션 전에 현재 IT 자산을 분석해야 할 때 적합

Migration Hub

• Migration Hub는 AWS 마이그레이션 진행 상황을 중앙에서 추적하는 서비스
• 여러 마이그레이션 도구의 진행 상황을 한 곳에서 확인 가능
• Application Discovery Service로 수집한 온프레미스 서버와 DB 정보를 활용할 수 있음
• 대규모 마이그레이션 프로젝트에서 서버별 진행 상태와 도구별 상태를 관리할 때 유용
• 마이그레이션 계획, 추적, 가시성 확보에 사용

가용성 계산 공식

상황	계산
EC2 2대 중 하나만 살아도 되는 구조, 각 90% 가용성	100% - (10% × 10%) = 99%
두 구성요소가 모두 정상이어야 하는 구조, 99%와 95%	99% × 95% = 94.05%
월 30일 기준 월간 30분 다운타임	약 99.93%
월 30일 기준 월간 3.6시간 다운타임	약 99.5%

• 병렬 중복 구조에서는 전체 장애 확률을 줄일 수 있음
• 직렬 의존 구조에서는 각 구성요소의 가용성을 곱해서 전체 가용성을 계산
• 월간 가용성은 (전체 시간 - 다운타임) / 전체 시간 × 100으로 계산
• 월간 30분 다운타임은 99.5%가 아니라 약 99.93%에 가까움
• 월간 99.5%는 30일 기준 약 3.6시간 다운타임에 해당

마이그레이션 시나리오 요약

시나리오	권장 서비스
DB 엔진 변경을 원함	SCT + DMS
같은 DB 엔진으로 이전	DMS
DB 이전 중 다운타임 최소화	DMS Full Load + CDC
대용량 데이터, 네트워크 제약	Snow Family
지속적 파일 동기화	DataSync
온프레미스 앱이 기존 파일/블록 방식으로 계속 접근	Storage Gateway
서버 lift-and-shift	Application Migration Service
온프레미스 정보 수집	Application Discovery Service
마이그레이션 진행 상황 중앙 추적	Migration Hub
여러 AWS 리소스 백업 중앙 관리	AWS Backup
정적 콘텐츠 오리진 장애 조치	CloudFront Origin Failover
매우 낮은 RPO의 관계형 DB 글로벌 복제	Aurora Global Database
다중 리전 NoSQL 읽기/쓰기	DynamoDB Global Tables

재해복구 / 마이그레이션 서비스 선택 기준 요약

요구사항	적합한 서비스
백업 중앙 관리	AWS Backup
가장 저렴한 DR 전략	Backup and Restore
핵심 데이터 계층만 유지	Pilot Light
축소된 전체 환경 상시 운영	Warm Standby
여러 리전에서 동시 트래픽 처리	Multi-Site Active/Active
S3 객체 다중 리전 복제	S3 Cross-Region Replication
정적 콘텐츠 오리진 장애 조치	CloudFront Origin Failover
관계형 DB 다중 리전 DR	Aurora Global Database
DynamoDB 특정 시점 복구	DynamoDB PITR
장기 아카이브 보관	S3 Glacier 계열
데이터베이스 마이그레이션	DMS
이기종 DB 스키마 변환	SCT
파일 데이터 마이그레이션/동기화	DataSync
대용량 오프라인 데이터 이전	Snow Family
서버 lift-and-shift 이전	Application Migration Service
온프레미스 자산 검색	Application Discovery Service
마이그레이션 진행 상황 추적	Migration Hub
하이브리드 스토리지 지속 연결	Storage Gateway