Disaster Recovery Overview

재해 복구 개요

• 재해(Disaster): 기업의 비즈니스 연속성이나 재정에 부정적인 영향을 미치는 모든 사건.
• 재해 복구(DR, Disaster Recovery): 이러한 재해에 대비하고 복구하는 과정.
• 재해 복구 유형:
  • 온프레미스 → 온프레미스: 기존의 물리적 인프라를 이용한 전통적인 재해 복구 방식으로 비용이 많이 듦.
  • 온프레미스 → AWS 클라우드: AWS 클라우드를 활용하는 하이브리드 복구 모델로, 백업이나 장애 조치에 활용.
  • AWS 클라우드 리전 A → AWS 클라우드 리전 B: 클라우드 환경 내에서 여러 리전을 활용하는 멀티 리전 재해 복구 방식.
• 주요 용어:
  • RPO (복구 시점 목표, Recovery Point Objective): 허용 가능한 최대 데이터 손실 시간.
  • RTO (복구 시간 목표, Recovery Time Objective): 시스템이 복구되어 정상 작동하는 데 허용 가능한 최대 다운타임 시간.

재해 복구 – 파일럿 라이트(Pilot Light)

• 클라우드에서 애플리케이션의 축소 버전이 항상 실행되고 있음
• 중요 핵심 시스템(Pilot Light)을 유지하는 데 유용
• 백업 & 복구(Backup and Restore) 방식과 매우 유사
• 중요한 시스템이 이미 실행 중이므로 백업 & 복구보다 더 빠르게 복구 가능

재해 복구 – 웜 스탠바이(Warm Standby)

• 전체 시스템이 항상 구동 중이지만 최소 규모로 운영됨
• 재해 발생 시, 프로덕션(실서비스) 수준으로 확장 가능

재해 복구 – 멀티 사이트 / 핫 사이트(Multi Site / Hot Site)

• 매우 낮은 RTO(수 분 또는 수 초 수준) 달성 가능 → 하지만 비용이 매우 높음
• 전체 프로덕션 규모가 AWS와 온프레미스에서 동시에 운영됨

 

 

 

 

재해 복구(Disaster Recovery) 팁

1. 백업 (Backup)

• EBS 스냅샷, RDS 자동 백업 / 스냅샷 활용
• 정기적으로 S3 / S3 IA / Glacier로 데이터 전송
• Lifecycle Policy로 오래된 데이터 자동 이동
• Cross Region Replication으로 다른 리전에 복제
• 온프레미스 → AWS: Snowball 또는 Storage Gateway 활용

2. 고가용성 (High Availability)

• Route 53으로 리전 간 DNS 전환
• RDS Multi-AZ, ElastiCache Multi-AZ, EFS, S3 사용
• Site-to-Site VPN을 Direct Connect 복구 대안으로 사용

3. 복제 (Replication)

• RDS Cross-Region Replication, Aurora Global Database
• 온프레미스 DB → RDS로 데이터 복제
• AWS Storage Gateway를 통한 스토리지 연계

4. 자동화 (Automation)

• CloudFormation / Elastic Beanstalk로 전체 환경 재구성
• CloudWatch 경보 실패 시 EC2 인스턴스 복구 또는 재부팅
• AWS Lambda로 맞춤형 자동화 구현

5. 카오스 테스트 (Chaos Engineering)

• Netflix Simian Army처럼 EC2를 무작위로 종료하여 장애 대비 테스트

 

DMS – 데이터베이스 마이그레이션 서비스

• 빠르고 안전하게 데이터베이스를 AWS로 마이그레이션 가능
• **복원력(Resilient)**과 자가 복구(Self-healing) 기능 제공
• 마이그레이션 중에도 소스 데이터베이스는 계속 사용 가능

지원 유형

• 동종 마이그레이션 (Homogeneous): 예) Oracle → Oracle
• 이종 마이그레이션 (Heterogeneous): 예) Microsoft SQL Server → Aurora

기능

• **CDC (Change Data Capture)**를 통한 지속적인 데이터 복제 지원
• **복제 작업(Replication Task)**을 수행하기 위해 EC2 인스턴스 생성 필요

 

DMS – 지원 소스와 타겟

소스(Sources)

• 온프레미스 & EC2 인스턴스 DB
  • Oracle, Microsoft SQL Server, MySQL, MariaDB, PostgreSQL, MongoDB, SAP, DB2
• Azure
  • Azure SQL Database
• Amazon RDS
  • 모든 엔진 포함 (Aurora 포함)
• Amazon S3
• Amazon DocumentDB

타겟(Targets)

• 온프레미스 & EC2 인스턴스 DB
  • Oracle, Microsoft SQL Server, MySQL, MariaDB, PostgreSQL, SAP
• Amazon RDS
• Amazon Redshift, Amazon DynamoDB, Amazon S3
• Amazon OpenSearch Service
• Amazon Kinesis Data Streams
• Apache Kafka
• Amazon DocumentDB, Amazon Neptune
• Redis, Babelfish for PostgreSQL

AWS Schema Conversion Tool (SCT)

• 데이터베이스 스키마를 한 데이터베이스 엔진에서 다른 엔진으로 변환
• OLTP 예시: SQL Server 또는 Oracle → MySQL, PostgreSQL, Aurora
• OLAP 예시: Teradata 또는 Oracle → Amazon Redshift
• 데이터 변환 속도 최적화를 위해 컴퓨팅 집약형 인스턴스 사용 권장

마이그레이션 흐름

Source DB  →  DMS + SCT  →  Target DB (다른 엔진)

주의 사항

• 같은 DB 엔진으로 마이그레이션할 경우 SCT 필요 없음
  • 예: 온프레미스 PostgreSQL → RDS PostgreSQL
  • 엔진은 PostgreSQL 그대로이며, RDS는 플랫폼만 변경

 

DMS – Continuous Replication (지속적 복제)

• CDC (Change Data Capture) 기술을 사용하여 소스 DB의 변경 사항을 실시간 또는 거의 실시간으로 타겟 DB에 반영
• 초기 마이그레이션 완료 후에도 소스와 타겟 간 데이터 동기화 유지 가능
• 활용 사례
  • 온프레미스 DB → AWS RDS로 단계적 마이그레이션
  • DR(재해 복구) 환경에서 핫 스탠바이 DB 유지
  • 분석용 DB(예: Redshift)로 운영 데이터 스트리밍

 

AWS DMS – Multi-AZ 배포

• Multi-AZ 활성화 시
  • DMS가 **다른 가용 영역(AZ)**에 동기식 스탠바이 복제본을 자동 생성 및 유지 관리

장점

1. 데이터 중복성(Data Redundancy) 제공
2. I/O 프리즈(I/O Freeze) 방지
3. 지연 시간(Latency) 급증 최소화

RDS & Aurora MySQL 마이그레이션

1. RDS MySQL → Aurora MySQL

• 옵션 1:
  • RDS MySQL에서 DB 스냅샷을 생성 후, 이를 Aurora MySQL로 복원
• 옵션 2:
  • RDS MySQL에서 Aurora Read Replica 생성
  • 복제 지연(Replication lag)이 0이 되면, 리플리카를 독립적인 DB 클러스터로 승격
  • 단, 시간과 비용이 소요될 수 있음

2. 외부 MySQL → Aurora MySQL

• 옵션 1:
  • Percona XtraBackup을 이용해 백업 파일을 Amazon S3에 저장
  • S3에 저장된 백업 파일로 Aurora MySQL DB 생성
• 옵션 2:
  • Aurora MySQL DB 생성
  • mysqldump 유틸리티로 MySQL 데이터를 Aurora로 마이그레이션 (S3 방식보다 느림)
  • 양쪽 DB가 모두 가동 중이라면 DMS 사용 가능

RDS & Aurora PostgreSQL 마이그레이션

1. RDS PostgreSQL → Aurora PostgreSQL

• 옵션 1:
  • RDS PostgreSQL에서 DB 스냅샷 생성 후, 이를 Aurora PostgreSQL로 복원
• 옵션 2:
  • RDS PostgreSQL에서 Aurora Read Replica 생성
  • 복제 지연(Replication lag)이 0이 되면, 리플리카를 독립적인 DB 클러스터로 승격
  • 시간과 비용이 소요될 수 있음

2. 외부 PostgreSQL → Aurora PostgreSQL

• 백업을 생성하여 Amazon S3에 저장
• Aurora의 aws_s3 확장 기능을 사용해 S3 백업 데이터 임포트
• 양쪽 DB가 모두 가동 중이라면 DMS 사용 가능

온프레미스 전략과 AWS

1. Amazon Linux 2 AMI 다운로드 및 가상머신 활용

• Amazon Linux 2 AMI를 VM용 ISO 파일로 다운로드 가능
• 지원 가상화 플랫폼: VMWare, KVM, VirtualBox (Oracle VM), Microsoft Hyper-V

2. VM Import / Export

• 기존 애플리케이션을 EC2로 마이그레이션 가능
• 온프레미스 VM을 AWS로 가져오고, 반대로 EC2 VM을 온프레미스로 내보낼 수 있음
• DR용 온프레미스 VM 저장소 전략 수립 가능

3. AWS Application Discovery Service

• 온프레미스 서버 정보를 수집하여 마이그레이션 계획 수립에 활용
• 서버 활용도 및 의존성 매핑 제공

4. AWS Migration Hub

• 마이그레이션 진행 상황 통합 관리 및 추적

5. AWS Database Migration Service (DMS)

• 온프레미스 ⇄ AWS 간 데이터베이스 복제 및 마이그레이션 지원
• 다양한 DB 엔진 지원 (Oracle, MySQL, DynamoDB 등)

6. AWS Server Migration Service (SMS)

• 온프레미스의 라이브 서버를 AWS로 증분 복제

 

AWS Backup

• 완전 관리형 서비스
• AWS 내 여러 서비스의 백업을 중앙에서 관리하고 자동화
• 별도의 스크립트나 수동 작업 없이 사용 가능

지원 서비스

• Amazon EC2 / Amazon EBS
• Amazon S3
• Amazon RDS (모든 DB 엔진) / Amazon Aurora / Amazon DynamoDB
• Amazon DocumentDB / Amazon Neptune
• Amazon EFS / Amazon FSx (Lustre & Windows File Server)
• AWS Storage Gateway (Volume Gateway)

추가 기능

• 크로스 리전(다른 리전) 백업 지원
• 크로스 계정(다른 AWS 계정) 백업 지원

 

AWS Backup 추가 기능

• PITR(Point-In-Time Recovery) 지원 (지원되는 서비스에 한함)
• 즉시 백업(On-Demand) 및 예약 백업(Scheduled Backup) 가능
• 태그 기반 백업 정책 설정 지원
• Backup Plan(백업 계획) 생성 가능
  • 백업 주기 설정: 매 12시간, 일간, 주간, 월간, 또는 크론 표현식 사용 가능
  • 백업 실행 시간대(Backup Window) 지정 가능
  • 백업 데이터의 콜드 스토리지 전환 시점 설정 (사용 안 함, 일/주/월/년 단위 선택 가능)
  • 백업 데이터 보존 기간(Retention Period) 설정 (영구 보관 또는 일정 기간 설정 가능)

 

 

 

AWS Backup Vault Lock

• AWS Backup Vault에 저장된 모든 백업에 대해
  WORM(Write Once Read Many) 상태를 적용하여 데이터 변경 불가(쓰기 후 읽기만 가능) 상태를 강제함
• 백업을 보호하는 추가 방어층 제공
  • 실수나 악의적인 삭제 방지
  • 보존 기간을 줄이거나 변경하는 업데이트 방지
• 활성화 시에는 루트 사용자(root)조차도 백업 삭제 불가능

 

 

AWS Application Discovery Service

• 온프레미스 데이터센터에 대한 정보를 수집하여 마이그레이션 프로젝트 계획 수립에 도움
• 서버 활용도 데이터 및 의존성 매핑이 마이그레이션에 매우 중요

Discovery 방식

• 에이전트리스(Agentless) 디스커버리
  • AWS Agentless Discovery Connector 사용
  • VM 인벤토리, 구성 정보, CPU/메모리/디스크 사용량 등 성능 이력 수집
• 에이전트 기반(Agent-based) 디스커버리
  • AWS Application Discovery Agent 사용
  • 시스템 구성, 성능, 실행 중인 프로세스, 시스템 간 네트워크 연결 상세 정보 수집

결과

• 수집된 데이터는 AWS Migration Hub에서 시각화 및 관리 가능

AWS Application Migration Service (MGN)

• CloudEndure Migration의 AWS 최신 버전이며, 기존 AWS Server Migration Service (SMS)를 대체
• 애플리케이션을 AWS로 쉽게 이전하는 Lift-and-Shift (리호스트) 솔루션
• 물리 서버, 가상 서버, 클라우드 기반 서버를 AWS 네이티브 환경으로 변환하여 실행
• 다양한 플랫폼, 운영체제, 데이터베이스 지원
• 최소 다운타임과 비용 절감 효과 제공

 

대용량 데이터 AWS 전송

• 예시: 200TB 데이터를 클라우드로 전송하는 경우
• 네트워크 속도와 전송 방법에 따른 예상 소요 시간 계산

1. 인터넷 / Site-to-Site VPN (100Mbps 연결)

• 즉시 설정 가능
• 계산:
  200 TB × 1000 GB × 1000 MB × 8 Mb / 100 Mbps = 16,000,000초 ≈ 185일

2. Direct Connect (1Gbps 연결)

• 설정 준비 기간이 길어 한 달 이상 소요될 수 있음
• 계산:
  200 TB × 1000 GB × 8 Gb / 1 Gbps = 1,600,000초 ≈ 18.5일

3. AWS Snowball

• 엔드투엔드 전송에 약 1주일 소요
• DMS(Database Migration Service)와 조합하여 사용 가능

4. 지속적 복제 및 데이터 전송

• Site-to-Site VPN 또는 Direct Connect와 함께
• DMS 또는 AWS DataSync 사용

 

VMware Cloud on AWS

• 일부 고객들은 온프레미스 데이터센터 관리를 위해 VMware Cloud를 사용
• 데이터센터 용량을 AWS로 확장하면서도 기존 VMware Cloud 소프트웨어를 계속 사용하고자 함
• 이를 위한 솔루션이 바로 VMware Cloud on AWS

주요 사용 사례

• VMware vSphere 기반 워크로드를 AWS로 마이그레이션
• VMware vSphere 기반의 프라이빗, 퍼블릭, 하이브리드 클라우드 환경에서 프로덕션 워크로드 운영
• 재해 복구(Disaster Recovery) 전략 수립 및 운영