AWS 재해복구와 마이그레이션

1. Disaster Recovery(재해복구)

시험에도 상당히 잘 나오고 SA라면 재해복구가 매우 중요하다는 걸 명심

• 재해란 회사의 사업 지속이나 재정에 매우 부정적인 영향을 미치는 이벤트
• 재해복구는 이러한 것을 예방하고 발생할 시 복구하는 작업
• 재해 복구 종류(재해복구를 위한 방법)
  • 온프레미스 ⇒ 온프레미스 - 전통적인 재해복구로 매우 비쌈
  • 온프레미스 ⇒ 클라우드 - 하이브리드 복구라고도 함
  • 클라우드 리전 A ⇒ 클라우드 리전 B
• Recovery Point Objective(RPO) → 복구 시점 목표
• Recovery Time Objective(RTO) → 복구 시간 목표

 

2. RPO와 RTO

• RPO란 얼마나 자주 백업을 실시할지, 어느정도로 되돌릴지를 결정할 수 있다
  • RPO는 백업을 하는 시간을 1분 혹은 1시간 단위로 정한다면 이후 재해가 발생한 시간과 백업한 시간 사이의 데이터 손실을 얼마만큼 감수할지 설정
  • 짧으면 짧을수록 손실이 짧아진다
• RTO란 재해 발생 후 복구할 때 사용
  • 재해-RTO 사이의 시간은 애플리케이션 서비스의 다운타임으로 둔다
  • 1분~하루까지 둘수도 있고 시간 복구에 따른 용어도 존재(Hotsite, Warmsite…)

 

3. Disaster Recovery Strategies(재해 복구 전략)

• 백업 및 복구
• 파일럿 라이트(Pilot light)
• 웜 대기(Warm Standby)
• Hotsite / Multi Site Approach

Multi Site Approach는 상당히 RTO가 빠르다 (다운타임이 적다)

 

 

3.1. Backup and Restore(High RPO)

• 스노우볼 같은 경우는 RPO가 일주일(AWS로 보내야하기 때문)
• 스케쥴을 만들어 정기적으로 스냅샷을 생성
• 모든 데이터를 복구해야하므로 AMI를 사용해서 인스턴스를 다시만들고 스핀업하거나 스냅샷에서 바로 복원 및 재생산 가능
• 데이터 복구는 시간이 오래 걸리기 때문에 RTO도 크지만 값이 저렴하다
• 인프라를 관리할 필요 없이 재해 발생시 바로 재생산 가능하며 따로 비용이 들지 않기 때문

RPO와 RTO 둘다 높다(데이터 손실을 허용하는 시간과 다운타임을 허용하는 시간이 둘다 높다)

 

3.2. Pilot Light

• 애플리케이션 축소 버전이 클라우드에서 실행되고 있다
• 크리티컬 시스템이 한창 작동하고 있고 복구시 여타 코어에 시스템만 변경해주면 된다
• 데이터가 중요하기 때문에 RDS로 계속 복제를 진행한다 이후 문제가 생길 시 Route53에서 데이터 센터 서버에 장애 조치를 허용해 클라우드 인스턴스를 재생산하고 실행하도록 처리

RPO와 RTO가 감소하지만 비용은 관리가 필요하며 재해 복구를 진행할 때 인스턴스만 불러온다.

크리티컬 코어 시스템에서만 사용한다는 것을 명심

 

3.3. Warm Standby

• 시스템 전체를 실행하되 최소한의 규모로 가동한다. 이후 재해가 발생하면 프로덕션 워크로드로 확장한다.
• 클라우드에서는 Master-Slave 구조로 데이터 복제가 계속해서 이루어지고 있다
• ELB는 준비상태로 재해가 발생한다면 ELB를 통해 데이터를 가져오는 곳을 변경할 수도 있다
• 효과적으로 대기하다가 오토스케일링을 통해 빠르게 확장 가능

ELB, EC2 오토 스케일링이 준비, 실행되어야하기 때문에 RPO, RTO는 감소하지만 비용은 올라감

 

3.4. Multi Site / Hot Site Approach

• 몇 분, 몇 초 정도로 RTO가 낮지만 비용이 굉장히 비싸다
• AWS와 온프레미스에서 완전한 프로덕션 스케일을 얻게 된다
• 온프레미스 데이터 센터 프로덕션 스케일과 데이터 복제를 진행하는 동시에 AWS 클라우드 또한 완전 프로덕션 스케일로 동작이 가능
• Route53가 기업 데이터 센터와 AWS Cloud에 요청을 라우팅할 수 있다
  • Active-Active 유형 설정
• 많은 비용이 들지만 다중 Data Center 유형 인프라를 실행할 수 있어 좋다.

 

3.5. All AWS Multi Region

• 모두 클라우드를 사용할 때 또한 구조가 같다
• Aurora 글로벌을 통해 더 나은 옵션들을 선택 가능

 

4. Disaster Recovery Tips

• 백업
  • EBS 스냅샷, RDS 자동 백업 / 스냅샷
  • s3, s3 IA, Glacier 라이프 사이클 정책과 리전간 복제
  • 온프레미스 → 클라우드 - 스노우볼과 Storage Gateway
• 고가용성
  • Route53을 위해 DNS를 다른 리전으로 옮기면 된다
  • RDS 다중 AZ, ElastiCache 다중 AZ, EFS, s3
  • Site-to-Site VPN, DX
• 복제
  • RDS 복제, Aurora 글로벌 데이터베이스
  • 온프레미스 환경에서 RDS로 데이터 복제
  • Storage Gateway
• 자동화
  • CloudFormation, Elastic Beanstalk
  • Recover, CloudWatch를 통해 복구하거나 재시작
  • 람다를 통한 사용자 맞춤 자동화
• 카오스
  • 재해를 만들어서 대응해보면 된다
  • 넷플릭스는 Simian-Army로 실행중인 ec2 인스턴스를 무작위로 종료한다

 

5. DMS - Database Migration Service

• 데이터베이스를 마이그레이션하는 빠르고 안전한 데이터베이스 서비스
• 온프레미스 → AWS로 데이터베이스 마이그레이션을 해준다 복원성이 높고 자가 복구 가능
• 마이그레이션 과정에서 소스 데이터베이스도 사용가능 동종 마이그레이션과 다양한 유형의 엔진 지원
  • Microsoft SQL Server → Aurora & Oracle → Oracle
• 변경 데이터 캡쳐(CDC - Continuous Data Replication)를 사용한 지속적 데이터 복제를 지원
• DMS를 사용하려면 ec2 인스턴스를 생성해서 복제를 처리하도록 지시해야한다.

 

5.1. DMS Sources and Targets

5.1.1. Sources

• 온프레미스와 ec2 인스턴스 db
• RDS, s3…

5.1.2. Targets

• 온프레미스와 ec2 인스턴스 db
• RDS, s3
• Redshift, DynamoDB, Kinesis Data Streams…

타겟은 주로 AWS에서 흔한 DB라고 생각하면 된다

 

5.2. Schema Conversion Tool(SCT)

• 소스와 타겟이 같은 엔진이 아니라면 SCT를 사용해야한다
• DMS가 SCT를 실행하는 것은 아니다

같은 엔진을 쓴다면 SCT를 쓰지 않는다(PostgreSQL은 엔진이고 RDS는 플랫폼이다)

 

 

5.3. DMS - Continuous Replication

• AWS SCT를 설치해서 온프레미스를 구성한다.
• 이후 스키마 변환을 통해 RDS에 적용시킨다
• 이후 DMS를 통해 풀로드와 CDC를 사용할 수 있다. 지속적 복제가 생겨 온프레미스 데이터베이스를 읽어 마이그레이션 데이터를 Private 서브넷에 있는 RDS로 옮김

 

6. Aurora MySQL로 마이그레이션

• RDS MySQL → Aurora MySQL
  • 데이터베이스의 스냅샷을 생성해서 해당 스냅샷을 Aurora에서 복제 다운타임이 발생한다
  • 지속적인 방법으로 Aurora 읽기 전용 복제본을 RDS MySQL에 생성 복제본의 지연이 0이된다면 Aurora 복제본이 MySQL과 완전히 일치한다는 뜻 복제본을 데이터베이스 클러스터로 승격
    • 스냅샷보다는 시간이 많이 걸리고 네트워크 비용 발생 가능
• 외부 MySQL → Aurora MySQL
  • Percona XtraBackup을 사용 가능 s3로 백업해서 import를 통해 Aurora MySQL db 클러스터로 가져올 수 있다
  • MySQLDump를 사용하여 기존 Amazon Aurora 데이터베이스로 출력값을 내보내는 것 시간이 많이들지만 S3를 사용하지 않는다
  • 이 외 데이터베이스에서는 aws_s3 Aurora 확장을 통해 새로운 데이터베이스를 생성 가능
• DMS를 이용해서 두 데이터베이스가 가용되는 상태에서 지속적인 복제를 진행

 

7. AWS를 통한 온프레미스 전략

모두 온프레미스에서 사용 가능한 전략들이다

• Amazon Linux2 AMI를 가상 머신으로 구축 ISO를 통해 가상 머신으로 실행 가능(VMWare, KVM…)
• VM 가져오기와 내보내기
  • 기존의 VM과 애플리케이션을 ec2로 마이그레이션
  • 재해 복구 전략 또한 생성 가능
  • 온프레미스 VM이 많은 경우 이를 클라우드에 백업하고 싶을 때 import export VM을 ec2에서 온프레미스 환경으로 마이그레이션 가능
• AWS Application Discovery Service
  • 온프레미스의 정보를 모아주고 마이그레이션을 계획할 수 있게 해준다
    • 서버 사용량 정보와 종속성 매핑에 대한 정보를 제공
  • 온프레미스 → 클라우드로 대량의 마이그레이션 시 유용
  • AWS Migration Hub를 사용해서 마이그레이션 추적도 가능
• AWS Database Migration Servce(DMS)
  • 온프레미스 → AWS, AWS → AWS, AWS → 온프레미스로 복제를 허용
  • 다양한 데이터베이스들과 함께 작동해서 사용하기 편리
    • MySQL → DynamoDB
• AWS Service Migration Service(SMS)
  • 온프레미스의 라이브 서버들을 AWS로 증분 복제할 때 사용
  • AWS로 볼륨을 직접 복제 가능 → 지속적인 복제 유형에 적용되는 증분 복제

 

8. AWS Backup

• 완전 관리형 서비스로 AWS 서비스 간의 백업을 중점적으로 관리하고 자동화를 도와준다
• 중앙시스템이나 사용자 지정 스크립트, 메뉴얼없이 사용 가능
• 적용 가능한 목록
  • Amazon EC2 / Amazon EBS
  • Amazon S3
  • Amazon RDS (All Engines) / Amazon Aurora / Amazon DynamoDB
  • Amazon DocumentDB / Amazon Neptune
  • Amazon EFS / Amazon FSx (Lustre, Windows File Server)
  • AWS Storage Gateway (Volume Gateway)
• 리전간 백업을 지원하기 때문에 한 곳의 재해 복구 전략을 다른 리전에 푸시 가능
• 계정간 백업도 지원
• 지정 시간 복구(PITR)을 지원
• 온디맨드, 예약된 백업 지원
• 태그 기반 백업 정책이 있어 프로덕션 태그가 지정된 리소스만 백업 가능
• 백업 플랜 생성 가능
  • 빈도(매월,매달,매년)
  • 백업 윈도우
  • 백업을 콜드 스토리지로 옮길지
  • 백업 보유 기간
• AWS Backup에서 지정한 내부 버킷이나 s3에 자동으로 저장됨

 

8.1. AWS Backup Vault Lock

• WORM(Write Once Read Many)을 시행하면 백업 볼트에 저장한 백업을 삭제 불가 볼트 잠금 정책 덕분에 백업을 삭제할 수 없어 추가적인 보호를 제공하며 악의적인 삭제를 방어 유지 기간을 변경하는 것 또한 막을 수 있고 루트사용자도 스스로 백업을 삭제 불가

 

9. AWS Application Discovery Service

• 온프레미스 서버나 데이터 센터가 있어 클라우드로 마이그레이션 하려면 계획을 세워야함 AWS Application Discovery 서비스로 마이그레이션 계획 가능
• 서버를 스캔하고 마이그레이션에 중요한 서버 설치 데이터 및 종속성 매핑에 대한 정보를 수집
• Agentless Discovery(AWS Agentless Discovery Connector)
  • 가상 머신, 구성, CPU, 메모리, 디스크 사용량같은 성능 기록에대한 정보 제공
• Agent-based Discovery(AWS Application Discovery Agent)
  • 가상 머신 내에서 더 많은 업데이트와 정보를 얻을 수 있다 시스템 구성, 성능, 실행중인 프로세스, 시스템 사이 네트워크 연결같은 세부 정보…
• 모든 결과 데이터를 AWS Migration Hub에서 확인 가능
• 이동해야할 항목과 그것들이 내부적으로 어떻게 상호 연결되어있는지 확인만 가능

실제로 옮겨야 한다

 

10. AWS Application Migration Service(MGN)

• 온프레미스 → AWS로 이동하기 가장 쉬움
• MGN을 사용하여 리호스팅을 할 수 있다.(Lift-and-shift 솔루션) 물리적, 가상, 클라우드에 있는 다른 서버를 AWS 클라우드 네이티브로 옮긴다
• 작동방식
  • 복제 에이전트가 디스크를 연속적으로 복제
  • 저비용 ec2 인스턴스, ebs 볼륨이 데이터를 갖고 있다
  • 컷오버를 수행할 정도가 되면 스테이징에서 프로덕션으로 이동한다
  • 이후 필요한 성능에 맞는 EBS와 인스턴스를 갖춘 후 실행시킴
• 데이터를 복제한 다음 어느 시점에서 컷오버를 수행
• 광범위한 플랫폼,운영체제,데이터베이스 지원하고 다운타임도 적다
• 자동 수행이므로 관련 엔지니어도 고용할 필요 없음

 

11. 대규모 데이터를 AWS로 전송

• 200TB의 데이터를 클라우드로 옮기려도 할 때
• Site-to-Site VPN / 공용 인터넷
  • 설치가 빠르고 연결이 바로 가능하다
  • 속도에 따라 다르지만 100Mbps 속도라면 185일정도 걸림
• Direct Connect 1Gbps
  • 초기 설치가 걸린다.
  • 연결이 만들어진다면 10배정도 빠르며 18.5일이 걸린다
• Snowball
  • 스노우볼을 2~3개 병렬 주문
  • 도착해서 로드하고 옮기는 end-to-end 전송에 일주일
  • DMS와 결합하여 나머지 데이터 전송 가능
  • 일회성 전송이다
• 지속적인 복제/전송을 위해선 Site-to-Site VPN, DX with DMS or DataSync를 활용 가능

주의할 점은 데이터셋에 따라 사용해야하는 방식이 달라진다

크기가 작은데 굳이 DX를 활용할 필요는 없음

 

 

12. VMware Cloud on AWS

• 온프레미스에 데이터센터가 있을 때 VMware를 사용해서 데이터 센터를 관리하는 경우가 있다
  • vSphere 기반 환경
• 데이터센터와 클라우드를 관리하는데 계속해서 VMware Cloud를 사용하고 싶을 수 있다
• 이를 도와주는 기능이 VMware Cloud on AWS 전체 VMware Cloud의 인프라를 AWS에서 확장함으로써 vmware에서 제공하는 하위 서비스 이용 가능하다
• 사용 사례
  • 컴퓨팅 성능을 확장하여 데이터센터에서 클라우드뿐 아니라 스토리지까지 컴퓨팅이 가능 VMware 기반 워크로드를 AWS로 마이그레이션 가능
  • 프로덕션 워크로드를 여러 데이터센터간 실행 가능하며 프라이빗,퍼블릭,하이브리드 클라우드 환경 모두 가능
  • 재해복구전략으로 활용 가능 → 신속하게 클라우드 엑세스가 가능하기 때문이다
  • AWS를 사용하므로 다양한 AWS 서비스를 사용 가능