Cloud/AWS

재해복구

Debin 2023. 7. 22.
반응형

RPO, RTO

  • 복구 시점 목표를 의미하는 RPO
  • RPO, 즉 복구 시점 목표란 얼마나 자주 백업을 실행할지 시간상 어느 정도 과거로 되돌릴 수 있는지를 결정한다.
  • 복구 시간 목표를 의미하는 RTO
  • RTO는 재해 발생 후 복구할 때 사용된다.
  • 재해 발생 시점과 RTO의 시간 차는 애플리케이션 다운타임이다.

재해 복구 전략

  1. 백업 및 복구
  2. 파일럿 라이트
  3. 웜 대기
  4. 핫 사이트 혹은 다중 사이트 접근

RTO는 각기 다르다. 백업 및 복구는 RTO가 작은 반면 파일럿 라이트와 웜 대기 다중 사이트는 비용이 더 들지만 RTO가 빠르다.

백업 및 복구

  • 니다 백업 및 복구는 아주 쉽고 비용이 저렴한데 RPO와 RTO가 높다.

파일럿 라이트

  • 애플리케이션 축소 버전이 클라우드에서 항상 실행되고 보통 크리티컬 코어가 되는데 이를 파일럿 라이트라고 한다.
  • 백업 및 복구와 아주 비슷하다.
  • 크리티컬 시스템이 한창 작동하고 있기 때문에 복구할 때 여타 시스템만 더해 주면 되니까 속도가 더 빠르다.
  • 크리티컬 코어 보조에만 사용한다.

웜대기

  • 웜 대기는 시스템 전체를 실행하되 최소한의 규모로 가동해서 대기하는 방법
  • 재해가 발생하면 프로덕션 로드로 확장할 수 있다.
  • 이건 비용이 조금 더 드들고 파일럿 라이트와 비교해서는 RPO와 RTO는 줄어든다.

핫 사이트

  • 몇 분, 몇 초 정도로 RTO가 낮지만 비용이 굉장하다.
  • AWS와 온프레미스에서 두 완전 프로덕션 스케일을 얻게 된다.
  • 온프레미스 데이터 센터 완전 프로덕션 스케일과 데이터 복제를 진행하는 동시에 AWS 데이터 센터 완전 프로덕션 스케일이 가능하다.
  • 이미 실행 중인 핫 사이트가 있기 때문에 Route 53가 기업 데이터 센터와 AWS Cloud에 요청을 라우팅할 수 있는데 이를 액티브-액티브 유형 설정이라고 한다.

All AWS Multi Region

  • 모두 클라우드로 실행하는 경우, 다중 리전

재해 복구 Tip

백업

  • 백업에는 EBS 스냅샷과 RDS로 자동화된 스냅샷과 백업 등을 사용
  • S3, S3 IA, Glacier 등에 스냅샷을 규칙적으로 푸시할 수 있다. 수명 주기 정책 실행도 가능
  • 백업이 다른 리전에 있길 바란다면 리전 간 복제도 가능
  • 온프레미스에서 클라우드로 데이터 공유 시 Snowball과 Storage Gateway가 유용

고가용성

  • 고가용성을 위해서는 Route 53를 사용해 DNS를 다른 리전으로 옮기면 된다. 
  • 다중 AZ를 실행하는 기술도 이용할 수 있다. (RDS 다중 AZ, 일래스티 캐시 다중 AZ EFS, S3 등)
  • 네트워크 고가용성은 기업 데이터 센터에서 AWS로 연결할 때 Direct Connect를 사용하는 경우와 연결이 끊겼을 때 Site-to-Site VPN을 네트워크 복구 옵션으로 사용하는 경우를 예로 들 수 있다.
  • RDS 리전 간 복제, 오로라 글로벌 데이터베이스로 복제 가능하고 온프레미스 데이터베이스를 RDS로 복제할 때 데이터베이스 복제 소프트웨어를 쓸 수도 있다.
  • Storage Gateway도 있다.

자동화

  • CloudFormation과 일래스틱 Beanstalk가 클라우드에 새로운 환경을 빠르게 재생산하도록 돕는다.
  • CloudWatch를 사용한다면 CloudWatch 경보가 실패했을 때 EC2 인스턴스를 복구하거나 다시 시작할 수 있다.
  • AWS Lambda는 사용자 맞춤 자동화에 유용하다.
  • REST API에도 좋지만 AWS 인프라 전체를 자동화할 때 효과적 

카오스

  • 재해를 만들어서 대처하는 방법
  • 요즘 AWS에서 자주 인용되는 사례는 넷플릭스
  • 무작위로 가동 중인 애플리케이션 서버를 중단한다.
  • 장애가 발생해도 인프라가 무사하도록 카오스 몽키를 실행해 이것저것 무작위로 종료하는 것이다.

DMS(Database Migration Service)

  • 온프레미스 시스템에서 AWS 클라우드로 데이터베이스를 마이그레이션 하고 싶을 때 사용
  • 빠르고 안전한 데이터베이스 서비스이며 온프레미스에서 AWS로 데이터베이스 마이그레이션을 해주는데 복원성이 좋고 자가 복구가 된다는 점이 장점
  • 마이그레이션을 하는 과정에서 소스 데이터베이스도 여전히 사용 가능하며 동종 마이그레이션 등 다양한 유형의 엔진을 지원하고, Oracle 또는 Postgre 간에도 지원한다.
  • 하지만 예를 들면 이기종 마이그레이션은 Microsoft SQL 서버를 오로라(Aurora)로 마이그레이션하고 싶다면 변경 데이터 캡처, 즉 CDC를 사용한 지속적 데이터 복제를 지원한다.
  • 마지막으로 DMS를 사용하려면 EC2 인스턴스를 생성해서 복제를 처리하도록 해야 한다.

DMS Sources

  • 먼저 온프레미스와 EC2 데이터베이스 인스턴스인데 Oracle, MS SQL 서버 MySQL, MariaDB, PostgreSQL MongoDB, SAP, DB2 등이 있다.
  • Azure는 Azure SQL 데이터베이스를 위해 쓰입니다
  • RDS는 오로라와 Amazon S3를 포함한 모든 데이터베이스

DMS Targets

  • Oracle, MS SQL 서버 MySQL MariaDB, Postgres SAP 등의 온프레미스와 EC2 인스턴스
  • Amazon RDS, 레드시프트 DynamoDB, S3, 일래스틱서치 서비스 Kinesis, DocumentDB도 있다.
  • 온프레미스에서 대상으로 하는 소스를 변환할 수 있고 이 대상은 보통 AWS에 해당되는데 이 대상들이 AWS에서 흔한 데이터베이스라는 것이 중요하다.

SCT ( Schema Conversion Tool)

  • 만약 소스 데이터베이스와 대상 데이터베이스가 같은 엔진을 갖고 있지 않다면 AWS SCT를 사용해야 한다.
  • 데이터베이스의 스키마를 다른 엔진으로 변환해 준다.
  • 예를 들어 OLTP를 사용한다면 SQL 서버나 Oracle을 MySQL PostgreSQL, 오로라로 마이그레이션 가능
  • Teradata나 Oracle 등의 분석적 과정에서 Amazon 레드시프트로의 변환도 가능
  • 핵심은 소스 데이터베이스가 대상 데이터베이스와 다른 엔진을 쓴다는 것
  • 같은 엔진을 쓰는 데이터베이스의 마이그레이션에는 SCT가 필요 없다

RDS & Aurora MySQL Migrations

  • RDS 데이터베이스를 Aurora MySQL로 옮기고자 할 경우의 방법을 살펴보자.
  • 첫 번째 방법은 RDS MySQL 데이터베이스의 스냅샷을 생성해서 이 스냅샷을 MySQL Aurora 데이터베이스에서 복원하는 것
  • 이때 다운타임이 발생. 가동을 중지한 뒤 Aurora로 마이그레이션해야 하기 때문이다.
  • 두 번째는 좀 더 지속적인 방법으로 Amazon Aurora 읽기 전용 복제본을 RDS MySQL에 생성하는 것이다.
  • 복제본의 지연이 0이 되면 Aurora 복제본이 MySQL과 완전히 일치한다는 뜻이니 이때 복제본을 데이터베이스 클러스터로 승격시키면 된다.
  • 이 방법은 데이터베이스 스냅샷보다는 시간이 많이 걸리고 복제본 생성과 관련한 네트워크 비용도 발생할 수 있다.
  • MySQL 데이터베이스가 RDS 외부에 있는 경우에는 Percona XtraBackup 기능을 사용하여 백업할 수 있다.
  • 백업 파일을 생성하여 Amazon S3에 두면 Amazon Aurora의 기능을 사용해서 새로운 Aurora MySQL DB 클러스터로 백업 파일을 가져올 수 있다.
  • 이 기능은 Percona XtraBackup에서만 사용할 수 있다.
  • 또 다른 방법은 mysqldump 기능을 MySQL 데이터베이스에서 실행하여 기존 Amazon Aurora 데이터베이스로 출력값을 내보내는 것
  • 이 경우에는 시간이 많이 들고 Amazon S3를 사용하지 않는다.
  • 마지막 선택지는 Amazon DMS를 이용해서 두 데이터베이스가 가동되는 채로 이 데이터베이스 간 지속적인 복제를 진행하는 방법이 있다. PostgreSQL에서도 방법은 같다.

AWS를 통한 온프레미스 전략 

Ability to download Amazon Linux 2 AMI as a VM (.iso format)

  • Amazon Linux 2 AMI를 가상 머신으로 다운로드 할 수 있고 이건 ISO 형식이다.
  • 이 ISO 이미지를 흔한 VM을 생성하는 소프트웨어로 로드할 수 있다.
  • 이는 Oracle VM과 Microsoft Hyper-V에 해당하는 VMWare, KVM Virtual Box를 포함한다.
  • 이를 통해 직접 VM을 통해 온프레미스 인프라에서 Amazon Linux 2를 실행할 수 있게 된다.
  • 사용자 데이터로도 이걸 작동할 수가 있다는 뜻

VM Import/ Export

  • VM 가져오기와 내보내기 기능이 있다.
  • 이 기능을 통해 기존의 VM과 애플리케이션을 EC2로 마이그레이션 할 수 있다.
  • 재해 복구 리포지토리 전략도 생성할 수 있다.
  • 온프레미스 VM이 많은 경우 이를 클라우드에 백업하고 싶을 때 가져오기, 내보내기 기능을 통해 VM을 EC2에서 온프레미스 환경으로 다시 빼올 수도 있다.

Application Discovery Service

  • AWS 애플리케이션 Discovery Service는 온프레미스의 정보를 모아주고 마이그레이션을 계획할 수 있게 해 주는 서비스
  • 상위 수준의 서비스이지만 서버 사용량 정보와 종속성 매핑에 대한 정보를 제공
  • 온프레미스에서 클라우드로 대량의 마이그레이션 할 때 유용하다.
  • AWS Migration Hub를 사용해서 모든 마이그레이션을 추적할 수도 있다.

DMS (Data Migration Service)

  • AWS data Migration Service, DMS는 온프레미스에서 AWS로의 복제를 허용하고 AWS에서 AWS로, AWS에서 온프레미스로 복제를 허용
  • MySQL나 Postgres 데이터베이스가 온프레미스에 있고 AWS로 워크로드를 옮기고 싶다면 DMS를 써서 그동안 데이터베이스를 복제하고 준비가 됐을 때 AWS만을 사용해서 처리할 수 있기 때문
  • Oracle, MySQL DynamoDB 등 다양한 데이터베이스들과 함께 작동해서 사용하기에 편리

SMS (AWS Server Migration Service)

  • 온프레미스의 라이브 서버들을 AWS로 증분 복제할 때 사용
  • AWS로 볼륨을 직접 복제할 수 있다.
  • 이는 보다 지속적인 복제 유형에 적용되는 증분 복제

온프레미스에서 AWS로의 마이그레이션

  • 온프레미스에서 가능한 것은 온프레미스와 EC2에 대한 VM 가져오기와 내보내기가 있었고 애플리케이션 Discovery Service AWS와 같은 마이그레이션 서비스 Migration Hub DMS, SMS 등의 서비스도 있다

AWS 백업 

  • AWS Backup은 완전 관리형 서비스이며 AWS 서비스 간의 백업을 중점적으로 관리하고 자동화할 수 있게 도와준다.
  • 가능한 서비스는 매일같이 늘어나고 있다.
  • 실제 중앙 시스템이 없고 사용자 지정 스크립트나 매뉴얼을 만들 필요도 없이 백업 전략으로 AWS Backup을 생각해 볼 수 있다.
  • 다양한 서비스를 지원한다.
    • Amazon EC2, EBS Amazon S3
    • RDS 및 모든 데이터베이스 엔진이 지원되고 Aurora, DynamoDB, DocumentDB Amazon Neptune
    • EFS, 그리고 Lustre와 Windows 파일 서버를 포함하는 FSx가 지원
    • AWS Storage Gateway의 볼륨 게이트웨이 등
  • 리전 간 백업을 지원하므로 한 곳의 재해 복구 전략을 다른 리전에 푸시할 수 있다.
  • 계정 간 백업도 지원한다. AWS에서 여러 계정을 사용할 경우에 도움이 된다.
  • Aurora와 같은 지정 시간 복구(PITR)를 지원하고 온디맨드와 함께 예약된 백업을 지원
  • 태그 기반 백업 정책이 있어서 이를 사용하면 예를 들어 프로덕션 태그가 지정된 리소스만 백업할 수 있다.
  • 백업 정책에서 백업 플랜(Plan)도 만든다.
    • 백업 빈도를 정의하여 예를 들어 매 12시간 또는 매주, 매달 및 cron 표현식을 정하고 백업 기간도 지정
    • 백업을 콜드 스토리지로 이전할지 여부도 결정. 보내지 않거나 혹은 며칠, 몇 주 몇 달, 몇 년 후에 보낼 수도 있다.
    • 백업 보유 기간도 정한다. 계속 보유하거나 일, 주, 월 년으로 기간을 정할 수 있다.

볼트(Vault) 잠금

  • WORM(Write Once Read Many) 정책을 시행하면 백업 볼트(Vault)에 저장한 백업을 삭제할 수 없게 된다.
  • 볼트 잠금 정책 덕분에 백업을 삭제할 수 없다.
  • 백업에 대한 추가 방어막을 제공
    • 의도치 않거나 악의적인 삭제 작업을 막고 백업 유지 기간 축소 또는 변경 작업을 방지한다.
  • 이 기능이 활성화되면 루트 사용자 자신도 백업을 삭제할 수 없다.

Application Discovery Service

  • 서버를 스캔하고 마이그레이션에 중요한 서버 설치 데이터 및 종속성 매핑에 대한 정보를 수집
  • 그러면 어떻게 마이그레이션할지, 무엇을 먼저 마이그레이션할지 알 수 있다.
  • 마이그레이션은 두 가지 방법으로 할 수 있는데요
  • 하나는 Connector를 사용하는 Agentless Discovery
    • 가상 머신, 구성, CPU와 메모리 및 디스크 사용량과 같은 성능 기록에 대한 정보를 제공
  • 다른 하나는 Application Discovery 에이전트를 실행할 수도 있다
    • 가상 머신 내에서 더 많은 업데이트와 정보를 얻을 수 있다
    • 시스템 구성, 성능, 실행 중인 프로세스, 시스템 사이의 네트워크 연결에 대한 세부 정보 등을 얻을 수 있다.
    • 종속성 매핑을 얻는 데 좋다.
  • 이 모든 결과 데이터를 AWS Migration Hub라는 서비스에서 볼 수 있다.
  • Application Discovery 서비스는 이동해야 할 항목과 그것들이 내부적으로 어떻게 상호 연결되어 있는지 파악하기에 정말 유용하다.

Application Migration Service  (MGN)

  • MGN을 사용하여 리호스팅을 할 수 있어요
  • Lift-and-shift 솔루션이라고도 한다. 물리적, 가상, 또는 클라우드에 있는 다른 서버를 AWS 클라우드 네이티브로 실행하는 것
  • MGN을 실행하면 데이터 센터에 설치된 복제 에이전트가 디스크를 연속적으로 복제한다. 예를 들어, 저비용 EC2 인스턴스, EBS 볼륨이 이런 데이터 복제.
  • 컷오버를 수행할 준비가 되면, 스테이징에서 프로덕션으로 이동시킨다.
  • 이 방법은 광범위한 플랫폼, 운영 체제, 데이터베이스를 지원한다. 다운타임도 최소
  • 이 서비스가 자동으로 수행하니까 관련 엔지니어를 고용할 필요가 없기 때문에 비용도 절감

대규모 데이터 세트를 AWS로 전송 

인터넷을 가로지르는 VPN

  • 이 방법의 장점은 설치가 빠르고 바로 연결이 가능하다.
  • 대신 느리다.

Direct Connect

  • 만약 Direct Connect를 통해 보내고 싶다면 연결 라인을 통해 1Gbps로 프로비저닝한다고 했을 때 먼저 초기 설치에 시간이 오래 걸리는 것을 감안해야 한다.
  • 그러니 Direct Connect를 사용한다면 먼저 연결을 만드는 데에만 한 달 정도가 걸릴 수 있고 연결이 만들어진 후에 정확히 계산을 해보자면 첫 번째 연결보다는 훨씬 빠름.

Snowball 사용

  • 퍼실리티(facility)에 동시에 도착하도록 Snowball을 병렬 주문 (2 ~ 3개)
  • 약 일주일이 소요
  • Snowball이 도착해서 로드하고 다시 싣고 AWS로 보내져서 데이터가 송신되어 종단 간 전송에 일주일 정도가 걸린다.
  • Snowball을 통해 전송되고 있던 데이터베이스가 있었다면 DMS와 결합하여 나머지 데이터를 전송할 수 있다
  • 일회성 전송에 유리

Vmware Cloud on AWS

  • 온프레미스에 데이터 센터가 있고 클라우드도 사용하는데 VMware Cloud로 데이터 센터를 관리하는 경우가 있다
  • 이때 VMware Cloud on AWS를 사용
  • 이 서비스를 이용하면 전체 VMware Cloud의 인프라를 AWS에서 확장함으로써 vSphere, vSAN, NSX 등에서 사용할 수 있다.

사용 사례

  • 컴퓨팅 성능을 확장하여 데이터 센터에서 클라우드뿐 아니라 스토리지까지 컴퓨팅이 가능해져 VMWare 기반 워크로드를 AWS로 마이그레이션할 수 있다
  • 프로덕션 워크로드를 여러 데이터 센터 간 실행할 수 있고 프라이빗, 퍼블릭, 하이브리드 클라우드 환경 모두 가능
  •  재해 복구 전략으로도 활용할 수 있다.
  • 익숙한 소프트웨어 제품군을 이용해서 신속하게 클라우드에 액세스할 수 있기 때문
  • AWS 클라우드를 사용하므로 다양한 AWS 서비스를 이용할 수 있게 된다.
  • Amazon EC2, Amazon FSx, S3, RDS Direct Connect, Redshift 등의 서비스
반응형

댓글