AWS 재해복구

Disater

재해란 회사의 사업 지속이나 재정에 부정적인 영향을 미치는 이벤트를 말한다.

재해 복구는 이러한 재해에 대비하고 재해가 발생할 시 복구하는 작업을 의미한다.

전형적인 것은 온프레미스를 2개 두는 것이다. 비용이 엄청든다.

 

아니면 온프레미스를 기본데이터 센터로 두고 클라우드를 사용할 수도 있다. 재해 발생 시 클라우드를 사용하는 방식을 

하이브리드 복구라고 한다.

 

하지만 모두 클라우드에 있는경우 AWS Cloud 리전 A에서 B로 재해 복구를 수행하면 완전 클라우드 유형이 될 것이다.

 

RPO : 복구 시점 목표를 의미한다.

RTO : 복구 시간 목표를 의미한다 .

RPO란 얼마나 자주 백업을 실행할지를 정한다. 1분 한시간 등 원하는 대로 설정할 수 있다.

예를들어 한시간으로 설정을 해두었다면 RPO가 일어난 시점이 후 50분 뒤에 재해가 발생했다면 50분 동안의 데이터 손실이 발생할 것이다.

 

반면 RTO는 재해 발생 후 복구할 때 사용된다. 재해 발생 시점과 RTO의 시간 차는 애플리케이션 다운 타임이다.

다운 타임을 24시간으로 두기도 하는데 때로는 1분으로 설정해야 하는 경우도 있다.

 

두 경우 시간이 짧을 수록 비용이 높아진다.

 

Disaster Recovery Strategies

Backup and Restore ,

Pilot Light,

Warm Standby ,

Hot Site / Multi Site Approach 등이 있다.

RTO는 각기 다르다. 백업 및 복구는 RTO가 작은 반면 파일럿 라이트와 웜 대기 다중 사이트는 비용이 더 들지만 RTO가 빠르다. 전반적으로 다운타임이 줄어든다는 뜻이다.

 

Backup and Restore ( High RPO)

예를들어 기업 데이터 센터와 AWS Cloud 및 버킷이 있다고 가정해보자. 시간에 따라 백업하고 싶다면 AWS Storage Gateway를 사용할 수 있다. 수명 주기 정책을 만들어 비용 최적화 목적으로 glacier에 데이터를 입력하거나 snowball을 사용해 일주일에 한번씩 많은 양의 데이터를 Glacier로 전송할 수도 있다.

 

AWS Cloud를 사용하는 경우

EBS볼륨 Redshift, RDS가 해당된다. 정기적으로 스냅샷을 예약하고 백업해두면 24시간이든 한시간이든 스냅샷을 만드는 간격에 따라 RPO가 달라진다.

 

재해가 발생하면 모든 데이터를 복구해야 하므로 AMI를 사용해서 EC2인스턴스를 다시 만들고 애플맄이션을 스냅샷에서 RDS 데이터베이스, EBS볼륨, Redshift 등을 바로 복원 및 재생산할 수 있다.

 

데이터 복구는 시간이 오래 걸리므로 RTO는 커지지만 값디 저렴하기 때문에 백업 및 복구 전략을 사용한다.

쉽고 비용이 저렴하여 RPO와 RTO가 높다.

 

Pilot Light

서버와 데이터 베이스를 갖춘 데이터 센터가 있다고 가정하자

여기서 AWS Cloud도 있고 온프로미스(크리티컬 데이터베이스)에서 RDS로 데이터를 계속 복제한다면

언제든 실행할 수 있는 RDS를 확보한다. EC2도 존재하지만 running상태가 아니고 재해가 발생할 경우 route53에 의해

ec2를 재 생산 후 실행시켜 계속 복제중인 RDS와 연결시킨다. 이때 RPO와 RTO가 낮아진다.

크리티컬 코어 보조에만 사용한다는 점을 기억하자.

 

Warm Standby

시스템 전체를 실행하되 최소한의 규모로 가동해서 대기하는 방법이다.

기업 데이터 센터가 있고 Route53이 DNS를 기업 데이터 센터로 가리킨다.

클라우드에서는 실행중인 RDS Slave로 데이터 복제가 이루어지고 있다.

EC2 오토 스케일링 그룹이 최소 용량으로 가동하며, 기업 데이터 센터 데이터베이스와 소통한다.

ELB도 준비상태가 된다. 재해가 발생하면 Route53이 ELB로 장애조치하여 애플리케이션이 데이터를 가져오는 곳을 변경하는 작업도 가능하다. RDS Slave에서 데이터를 취하도록 변경한 뒤 효과적으로 대기했다 오토스케일링을 사용하면 애플리케이션이 빠르게 확장할 것이다. ELB와 EC2 오토스케일링이 동시에 실행되기 때문이다. RPO와 RTO는 줄어든다.

 

Multi site / Hot site approuch

몇분, 몇 초 정도로 RTO가 낮지만 비용이 굉장하다. AWS와 온프레미스에서 두 완전 프로덕션 스케일을 얻게된다.

온프레미스 데이터 센터 완전 프로덕션 스케일과 데이터 복제를 진행하는 동시

 

 

DMS Database Migration Service 데이터베이스 마이그레이션 서비스

온프레미스 시스템에서 AWS클라우드로 데이터베이스를 마이그레이션 하고 싶다고 해보자.

데이터베이스 마이그레이션 서비스로 DMS를 사용해야 한다.

빠르고 안전한 데이터 베이스 서비스이며 온프레미스에서 AWS로 데이터베이스 마이그레이션을 해주는데 복원성이 좋고 자가 복구가 된다는 장점이 있다.

마이그레이션을 하는 과정에서도 소스 데이터베이스도 여전히 사용가능하며 다양한 유형의 엔진을 지원한다.

하지만 이기종 마이그레이션은 (Microsoft SQL서버를 Aurora로 마이그레이션 하는 경우) 변경 데이터 캡쳐 CDC를 사용한 지속적 데이터 복제를 지원한다.

서로 다른 종류의 데이터베이스를 마이그레이션할 때 SCT를 꼭 사용해야한다.

온프레미스에 데이터베이스와, SCT installed를 설치하고, 데이터마이그레이션은 AWS Cloud안에있는 public Ec2에서 마이그래이션 하고 이걸 프라이빗 서브넷에 있는 RDS로 마이그레이션 시킨다.

SCT installed는 프라이빗 서브넷에 있는 RDS로 스키마 변환을 한다.

 

RDS , Aurora 를 Mysql로 부터옮기고자 할 경우 

첫번째방법은 RDS MySQL 데이터 베이스의 스냅샷을 생성하여 이 스냅샷을 MySQL Aurora로 복원하는 것이다.

이 때 다운타임이 발생한다. 

 

두번째 방법은 Aurora 읽기 전용 복제본을 계속 MySQL로 부터 생성한다.

지연이 0이 되면 그걸 승격시킨다.돈과 시간이 좀 들 수 있다.

 

세번째방법 MySQL데이터베이스가 RDS외부에 있는 경우에는 Percona XtraBackup기능을 사용하여 백업할 수 있다.

백업 파일을 생성하여 s3에 두면 aurora의 기능을 사용해서 새로운 Aurora MySQL DB클러스터로 백업 파일을 가져올 수 있다. 

 

네번째 방법 mysqldump기능을 mysql테이터베이스에서 실행하여 기존 amazon aurora 데이터베이스로 출력값을 내보내는 것이다.

 

마지막으로 DMS를 사용하여 지속적으로 마이그레이션을 하는 방법니다.

 

 

AWS를 통한 온프레미스 전략

온프레미스와 EC2에 대한 VM가져오기와 내보내기가 있고, 애플리케이션 discovery service AWS와 같은 마이그레이션 서비스 Migration Hub DMS, SMS등의 서비스도 있다. 이건 전부 온프레미스와 관련된 것이다.

 

AWS백업

완전 관리형 서비스이다. 서비스 간 백업을 중점적으로 관리하고 자동으로 할 수 있게 도와준다. 사용자 지정 스크립트나 매뉴얼을 만들 필요 없이 백업 전략으로 AWS Backup을 생각해볼 수 있다. 

EC2, EBS, S3, RDS, Aurora, DynamoDB,Neptune, EFS, FSx등을 지원한다. 

리전간 백업을 지원하므로 한곳의 재해 복구 전략을 다른 리전에 푸시 가능, 계정간 백업도 지원한다.

Aurora와 같은 지정 시간 복구를 지원한다. 백업을 콜드 스토리지로 이전할 지 말지도 결정한다.

 

먼저 백업 플랜을 만들고 그걸 특정 AWS Resourceㅇ에 할당한다. 할당이 완료되면 데이터가 자동으로 Amazon S3에 백업된다. 

 

Backup Vault Lock

Write Once Read Many 정책을 시행하면 백업 볼트에 저장한 백업을 삭제할 수 없게 된다./ 

볼트 잠금 정책 덕분에 백업을 삭제할 수 없으며 백업에 대한 추가 방어막을 제공한다. 

악의적인 삭제 작업을 막고 백업 유지 기간 축소 또는 변경 작업을 방지한다. 이 기능이 활성화 되면 루트 사용자도 백업을 삭제할 수 없다.

 

Application Discovery Service

온프레미스 서버나 데이터 센터가 있어서 클라우드로 마이그레이션 하려면 마이그레이션을 계획해야한다.

한가지 방법은 AWS Application Discovery 서비스로 마이그레이션을 계획하는 것이다.

서버를 스캔하고 마이그레이션에 중요한 서버 설치 데이터 및 종속성 매핑에 대한 정보를 수집합니다.

그러면 어떻게 마이그레이션할지, 무엇을 먼저 마이그레이션할지 알 수 있다.

마이그레이션은 두 가지 방법으로 할 수 있다.

 

1. Agentless Discovery Connector

가상 머신, 구성, CPU와 메모리 및 디스크 사용량과 같은 성능 기록에 대한 정보를 제공한다.

2. Agent Discovery Agent

예를 들어, 시스템 구성, 성능, 실행중인 프로세스, 시스템 사이의 네트워크 연결에 대한 세부 정보등을 얻을 수 있다.

이 모든 결과 데이터를 AWS Migration Hub라는 서비스에서 볼 수 있다.

 

온프레미스에서 AWS로 이동하는 가장 간단한 방법은 AWS Application Migrations Service(MGN)를 사용하는 것이다.

물리적, 가상, 클라우드에 있는 다른 서버를 AWS 클라우드 네이티브로 실행하는 것이다.  Lift and Shift라고도한다.

 

MGN을 실행시키면 온프레미스에 설치된 replication agent에의해 OS, APPS, DB, DISK등과 같은 것이 연속적으로 클라우드에 복제할 것이다. 먼저 저비용으로 복제를 하고 컷오버를 수행할 준비가 되면 프로덕션으로 이동하여 큰 스펙으로 복제되는 것이다. 즉 처음 데이터를 저비용으로 복제한다음 어느 시점에서 컷오버를 수행하는 것이다.

 

Transferring large amount of data into AWS

200TB의 데이터를 클라우드로 옮기고 싶다고 해보자

현재 인터넷 속도는 100Mbps이다.

1. 먼저 공용인터넷을 사용하는 방법이 있고, 또 공용 인터넷을 사용해 사이트간 VPN을 설치하는 방법도있다.

이 방법의 장점은 설치가 빠르고 바로 연결 가능하다. 근데 시간이 오래걸린다. 반년정도 걸릴 것이다.

 

2. Direct Connect를 통해 보내고 싶다면 1Gbps로 프로비저닝한다고 했을 때 먼저 초기설치에 시간이 오래걸리는 것을 감안해야 한다. 연결을 만드는 데만 한달정도가 걸릴 수 있지만 첫번째 연결보다는 10배는 빠를 것이다.

 

3. snow ball을쓰면 2~3개 정도 필요하고 오는데 약 일주일 정도 소요 되며 로드한 뒤 다시 싣고 보내면 일주일 정도가 걸린다.  

지속적 복제에는 Site to Site VPN or DX with DMS, or DataSync를 사용하면 된다.

 

VMware Cloud on AWS

상황을 소개하자면 온프레미스에 데이터 센터가 있을 때 VMware cloud로 데이터 센터를 관리하는 경우가 있다.

이를 AWS에 옮겨 VMware cloud on AWS로 실행시키면 훨씬 확장이 용이하고 다른 AWS서비스와 연계하기 수월하여 좋다.