Disaster Recovery
-
회사의 사업 지속이나 재정에 부정적인 영향을 미치는 모든 사건은 재해로 간주된다.
-
재해 복구(DR)는 이러한 재해에 대비하고 재해가 발생할 시 복구하는 작업을 의미한다.
-
재해 복구 유형
- 온프레미스 → 온프레미스: 전통적인 재해 복구, 비용이 많이 듦
- 온프레미스 → AWS 클라우드: 하이브리드 복구
- AWS 클라우드 리전 A → AWS 클라우드 리전 B
-
핵심 용어
- RPO: Recovery Point Objective - 복구 시점 목표
- 얼마나 자주 백업을 실행할지, 시간 상 어느 정도 과거로 되돌릴 수 있는지 결정
- 재해 발생 시 데이터 손실을 얼마만큼 감수할지 설정하는 것
- RTO: Revobery Time Objective - 복구 시간 목표
- 재해 발생 후 복구할 때 사용
- RPO: Recovery Point Objective - 복구 시점 목표
-
RTO - 재해 발생 시점 = 애플리케이션 다운 타임
Disaster Recovery Strategies
- 백업 및 복구
- 파일럿 라이트
- 웜 대기
- 핫 사이트 / 다중 사이트
Backup and Restore (High RPO)
기업 데이터 센터와 AWS Cloud, S3 버킷이 있다고 가정해보자
- 시간에 따라 데이터를 백업 - AWS Storage Gateway
- 수명 주기 정책을 만들어 비용 최적화 목적 - Glacier
- 일주일에 한 번씩 많은 양의 데이터를 Glacier로 전송 - AWS Snowball
- RPO는 대략 일주일
- AWS Cloud를 사용하는 경우 (EBS 볼륨, Redshift, RDS) 정기적으로 스냅샷을 예약하고 백업해두면 스냅샷을 만드는 기간에 따라 RPO가 달라짐
재해가 발생하면 모든 데이터를 복구해야하므로
- AMI를 사용해서 EC2 인스턴스를 다시 만들고
- 애플리케이션을 스핀 업하거나
- 스냅샷에서 RDS, DB, EBS 볼륨, Redshift 등을 바로 복원 및 재생산 가능
- 데이터 복구는 시간이 오래 걸리므로 RTO도 커지지만, 값이 저렴하기 때문에 백업 및 복구 전략을 사용함.
- 중간에서 인프라를 관리할 필요 없이 재해 발생 시 인프라를 재생산할 수 있어 백업 저장 비용 외에는 추가 비용이 발생하지 않음
- 즉, 백업 및 복구는 아주 쉽고 비용이 저렴한 대신 RPO와 RTO가 높음
Pilot Light
- 애플리케이션의 축소 버전이 클라우드에서 항상 실행됨
- 크리티컬 코어 (파일럿 라이트)에 유용함
- 백업 및 복원과 매우 유사함
- 크리티컬 시스템이 이미 가동되어 있기 때문에 백업 및 복원보다 빠름
- 크리티컬 DB에서 RDS로 데이터를 계속 복제한다면 언제든 실행할 수 있는 RDS DB를 확보하게 된다.
- 하지만 EC2 인스턴스는 아직 크리티컬 시스템이 아니다.
- 재해가 발생할 경우 Route 53이 데이터 센터 서버에 장애 조치를 허용하여 클라우드에 EC2 인스턴스를 재생산하고 실행하도록 처리한다.
- RDS DB는 이미 준비된 생태이기 때문에 RPO와 RTO가 낮아진다.
Warm Standby
- 시스템 전체를 실행하되 최소한의 규모로 가동해서 대기하는 방법
- 재해 발생 시 프로덕션 로드에 맞게 확장할 수 있음
- 역방향 프록시와 애플리케이션 서버, 마스터 DB가 있다.
- 클라우드에서는 실행중인 RDS Slave DB로 데이터 복제가 이루어지고 있다.
- EC2 오토 스케일링 그룹이 최소 용량으로 가동하며 기업 데이터 센터 DB와 소통한다.
- ELB는 준비된 상태이다.
- 재해가 발생하면 Route 53을 사용하여 ELB로 장애 조치 해서 애플리케이션이 데이터를 가져오는 곳을 변경하는 작업도 가능하다.
Multi Site / Hot Site Approach
- 매우 낮은 RTO (몇 분, 몇 초 정도) - 매우 비쌈
- 전체 프로덕션 스케일은 AWS와 온프레미스에서 실행됨
- 이미 실행중인 핫 사이트가 있기 때문에 Route 53이 기업 데이터 센터와 AWS Cloud에 요청을 라우팅할 수 있다. (active-active 유형 설정)
- 필요하다면 EC2가 RDS Slave DB 장애 조치를 할 수 있지만
- AWS와 온프레미스에서 full 프로덕션 스케일이 실행돼 많은 비용이 발생
- 동시에 장애 조치를 할 준비가 되어 있으므로 다중 데이터센터 유형 인프라를 실행할 수 있어 좋다.
All AWS Multi Region
- 아키텍처는 동일
- 다중 리전이며 클라우드 내에 있으므로 Aurora 사용 가능
- Slave로 다른 리전에 복제된 Aurora Global DB도 있음
Disaster Recovery Tips
백업
- EBS 스냅샷, RDS 자동화된 백업 / 스냅샷 등 사용
- S3 / S3 IA / Glacier로의 정기적인 백업, 수명 주기 정책 실행, 교차 리전 복제 가능
- 온프레미스에서 클라우드로 데이터 공유 시 Snowball이나 Storage Gateway 사용
고가용성
- Route53을 사용하여 DNS를 다른 리전으로 마이그레이션
- RDS Multi-AZ, ElastiCache Multi-AZ, EFS, S3
- Direct Connect에서의 복구용 Site to Site VPN
복제
- RDS 복제 (리전간 복제), AWS Aurora, Aurora Global Database
- 온프레미스에서 RDS로의 데이터베이스 복제 시 복제 소프트웨어 사용 가능
- Storage Gateway
자동화
- CloudFormation / Elastic Beanstalk을 사용하여 전체 환경 재생성
- CloudWatch 경보가 실패했을 때 EC2 인스턴스 복구 / 다시 시작
Chaos
- Netflix는 가동중인 EC2를 무작위로 종료하는 "simian-army"를 사용함
DMS – Database Migration Service
- 빠르고 안전하게 DB를 AWS로 마이그레이션하며, 복원성이 좋고 자가 복구 기능을 제공한다.
- 마이그레이션 중에도 원본 DB는 사용 가능
- 동종 (Homogeneous) 마이그레이션: ex. Oracle에서 Oracle로
- 이기종 (Heterogeneous) 마이그레이션: ex. Microsoft SQL Server에서 Aurora로
- CDC(Continuous Data Replication)를 사용한 지속적인 데이터 복제
- DMS를 사용하려면 복제 작업을 수행하기 위해 EC2 인스턴스를 생성해야 함
DMS Sources and Targets
Source
- 온프레미스 & EC2 인스턴스 DB: Oracle, MS SQL Server, MySQL, MariaDB, PostgreSQL, MongoDB, SAP, DB2 등
- Azure: Azure SQL Database
- Amazon RDS: Aurora를 포함한 모든 DB
- Amazon S3
- DocumentDB
Target
- 온프레미스 & EC2 인스턴스 DB: Oracle, MS SQL Server, MySQL, MariaDB, PostgreSQL, MongoDB, SAP 등
- Amazon RDS
- Redshift, DynamoDB, S3
- OpenSearch Service
- Kinesis Data Streams
- Apache Kafka
- DocumentDB & Amazon Neptune
- Redis & Babelfish
만약 소스 DB와 대상 DB가 같은 엔진을 갖고 있지 않을 때에는 AWS Schema ConversionTool (SCT)을 사용해야 한다.
AWS Schema ConversionTool (SCT)
- 데이터베이스의 스키마를 다른 엔진으로 변환함
- ex. OLTP: SQL Server나 Oracle에서 MySQL, PostgreSQL, Aurora로 변환
- ex. OLAP: Teradata나 Oracle에서 Amazon Redshift로 변환
- 같은 엔진을 쓰는 데이터베이스에는 SCT가 필요하지 않음
- ex. 온프레미스 PostgreSQL → RDS PostgreSQL
- DB 엔진은 여전히 PostgreSQL (RDS는 플랫폼일 뿐)
DMS - Continuous Replication
RDS & Aurora Migrations
RDS & Aurora MySQL Migrations
RDS MySQL에서 Aurora MySQL로의 마이그레이션
- 옵션 1: RDS MySQL의 DB 스냅샷을 생성해서 이 스냅샷을 MySQL Aurora DB에서 복원
- 가동을 중지한 뒤 마이그레이션하기 때문에 다운타임 발생
- 옵션 2: Aurora 읽기 전용 복제본을 RDS MySQL에 생성, 복제 지연이 0이 될 때까지 기다린 후 독립적인 DB 클러스터로 승격 (시간과 비용 발생)
외부 MySQL에서 Aurora MySQL로의 마이그레이션
- 옵션 1:
- Percona XtraBackup을 사용하여 Amazon S3에 파일 백업을 생성
- Amazon S3에서 Aurora MySQL DB를 생성
- 옵션 2:
- Aurora MySQL DB를 생성
- mysqldump를 사용하여 MySQL을 Aurora로 마이그레이션 (S3 방법보다 느릴 수 있음)
두 데이터베이스가 모두 가동 중인 경우 DMS를 사용한다.
RDS & Aurora PostgreSQL Migrations
RDS PostgreSQL에서 Aurora MySQL로의 마이그레이션
- 옵션 1: RDS PostgreSQL의 DB 스냅샷을 생성하여 이 스냅샷을 PostgreSQL Aurora DB에 복원
- 옵션 2: Aurora 읽기 전용 복제본을 RDS PostgreSQL에 생성, 복제 지연이 0이 될 때까지 기다린 후 독립적인 DB 클러스터로 승격 (시간과 비용 발생)
외부 PostgreSQL에서 Aurora MySQL로의 마이그레이션
- 백업을 생성하고 Amazon S3에 저장
- aws_s3 Aurora 확장 기능을 사용하여 백업을 가옴
두 데이터베이스가 모두 가동 중인 경우 DMS를 사용한다.
On-Premise strategy with AWS
- Amazon Linux 2 AMI를 가상 머신 (.iso 형식)으로 다운로드할 수 있음
- VMWare, KVM, VirtualBox (Oracle VM), Microsoft Hyper-V
- EC2에 대한 VM 가져오기 / 내보내기
- 기존 애플리케이션을 EC2로 마이그레이션
- 온프레미스 VM에 대한 재해 복구 리포지토리 전략 생성
- EC2에서 VM을 온프레미스로 내보낼 수 있음
- AWS Application Discovery Service
- 온프레미스 서버에 대한 정보 수집을 통해 마이그레이션 계획 수립
- 서버 사용량 및 종속성 매핑
- AWS Migration Hub로 추적
- AWS Database Migration Service (DMS)
- 온프레미스 → AWS, AWS → AWS, AWS → 온프레미스 복제 허용
- 다양한 데이터베이스 기술과 함께 작동 (Oracle, MySQL, DynamoDB 등)
- 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) 등
- 리전 간 백업 지원
- 계정 간 백업 지원
-지원되는 서비스에 대한 지정 시간 복구(Point-in-Time Recovery, PITR) 지원 - 온디맨드 및 예약된 백업 지원
- 태그 기반 백업 정책 생성 가능
- 백업 정책에서 백업 플랜 생성
- 백업 빈도 설정 (12시간마다, 매일, 매주, 매월, cron)
- 백업 윈도우 설정
- Cold Storage로의 이전 기간 설정 (절대로 이전하지 않음, 일자, 주간, 월간, 연간)
- 보존 기간 설정 (항상 보존, 일자, 주간, 월간, 연간)
AWS Backup Vault Lock
- 저장된 모든 백업에 대해 WORM (Write Once Read Many) 상태를 강제화
- 무심결 또는 악의적인 삭제 작업으로부터 백업을 보호하기 위한 추가적인 보안 기능
- 보존 기간을 단축하거나 변경하는 업데이트로부터 백업을 보호
- 루트 사용자조차도 활성화된 경우에는 백업을 삭제할 수 없음
Application Migration Service (MGN)
AWS Application Discovery Service
- 온프레미스 데이터 센터에 대한 정보 수집을 통해 마이그레이션 프로젝트를 계획할 수 있도록 지원
- 서버를 스캔하고 마이그레이션에 중요한 서버 설치 데이터 및 종속성 매핑에 대한 정보 수집
- Agentless Discovery (AWS Agentless Discover Collector)
- 가상 인벤토리, 구성 및 성능 히스토리 (ex. CPU, 메모리, 디스크 사용량) 수집
- Agent-based Discovery (AWS Application Discovery Agent)
- 시스템 구성, 시스템 성능, 실행 중인 프로세스 및 시스템 간 네트워크 연결에 대한 세부 정보를 수집
- 수집된 데이터는 AWS Migration Hub에서 확인 가능
AWS Application Migration Service (MGN)
온프레미스에서 AWS로 이동하는 가장 간단한 방법 - AWS MGN
- AWS Application Migration Service (MGN)는 CloudEndure Migration의 "AWS 진화"로서, AWS Server Migration Service (SMS)를 대체하는 서비스이다.
- MGN은 애플리케이션을 AWS로 간편하게 마이그레이션하는 Lift-and-shift (리호스팅) 솔루션
- 물리적, 가상화된, 클라우드 기반의 서버를 AWS에서 네이티브로 실행할 수 있도록 변환
- 다양한 플랫폼, 운영 체제, 데이터베이스를 지원
- 최소한의 다운타임과 비용으로 마이그레이션을 수행
Transferring large amount of data into AWS
대량의 데이터를 AWS로 전송하는 방법에 대한 예시로, 200 TB의 데이터를 클라우드로 전송한다고 가정해보자. 인터넷 연결 속도는 100 Mbps이다.
일회용 전송
- 공용 인터넷 또는 Site-to-Site VPN을 통한 전송
- 설치가 빠르고 바로 연결이 가능함
- 200(TB) 1000(GB) 1000(MB) * 8(Mb) / 100 Mbps = 16,000,000초 = 185일
- Direct Connect 1Gbps을 통한 전송
- 초기 설치에 시간이 오래 걸릴 수 있음 (한 달 이상)
- 200(TB) 1000(GB) 8(Gb) / 1 Gbps = 1,600,000초 = 18.5일
- Snowball을 통한 전송
- 병렬로 2~3개의 Snowball 사용
- 전체 전송에는 약 1주일 소요
- DMS와 결합하여 사용
지속적인 복제 / 전송: Site-to-Site VPN이나 DX를 이용하여 DMS나 DataSync와 함께 사용
VMware Cloud on AWS
- 고객이 기존의 온프레미스 데이터 센터를 관리하기 위해 VMware Cloud를 사용하고자 할 때 AWS의 확장 용량을 활용할 수 있는 솔루션
- 사용 사례:
- 컴퓨팅 성능을 확장하여 데이터 센터에서 클라우드 뿐 아니라 스토리지까지 컴퓨팅이 가능해져 VMware 기반 워크로드를 AWS로 마이그레이션 가능
- 프로덕션 워크로드를 여러 데이터 센터 간 실행 가능, 프라이빗, 퍼블릭, 하이브리드 클라우드 환경 모두 가능
- 재해 복구 전략으로 활용
- VMware Cloud on AWS는 AWS와 VMware의 협력을 통해 개발되었으며, 고객은 기존의 VMware 환경과 동일한 도구와 프로세스를 유지하면서 AWS의 유연성과 확장성을 활용할 수 있다. 이를 통해 기존의 VMware 스킬셋을 활용하여 AWS로의 이동을 간소화하고 비용과 관리 부담을 줄일 수 있다.
안녕하세요