develop/AWS

[SAA] Disaster Recovery & Migrations

hsleeee 2024. 6. 28. 10:00
반응형
SMALL

1. Disaster Recovery

  • 회사의 사업 지속이나 재정에 부정적인 영향을 미치는 모든 사건은 재해로 간주
  • 재해 복구(DR)는 이러한 재해에 대비하고 재해가 발생할 시 복구하는 작업을 의미
  • 재해 복구 유형
    • 온프레미스 -> 온프레미스: 전통적인 재해 복구, 비용이 많이 듦
    • 온프레미스 -> AWS 클라우드: 하이브리드 복구
    • AWS 클라우드 리전 A -> AWS 클라우드 리전 B
  • 핵심 용어
    • RPO: Recovery Point Objective - 복구 시점 목표
      • 얼마나 자주 백업을 실행할지, 시간상 어느정도 과거로 되돌릴 수 있는지 결정
      • 재해 발생 시 데이터 손실을 얼마만큼 감수할 지 설정
    • RTO: Recovery Time Objective - 복구 시간 목표
      • 재해 발생 후 복구할 때 사용
    • RTO - 재해 발생 시점 = 애플리케이션 다운 타임
  • Disaster Recovery Strategies
    • 백업 및 복구(Backup and Restore): High RPO
      • 시간에 따라 데이터 백업 - AWS Storage Gateway
      • 수명 주기 정책을 만들어 비용 최적화 - Glaciere
      • 일주일에 한 번씩 많은 데이터를 Glacier로 전송 - AWS Snowball(RPO 대략 일주일)
      • AWS Cloud 사용 시 정기적으로 스냅샷을 예약하여 백업해두면 스냅샷을 만드는 기간에 따라 RPO가 달라짐
      • 데이터 복구
        • AMI를 사용하여 EC2 인스턴스 다시 만들기
        • 애플리케이션 스핀업 or 스냅샷에서 RDS, DB, EBS Volume, Redshift 등을 바로 복원 및 재생산 가능
        • 데이터 복구는 시간이 오래 걸리므로 RTO 값도 커지지만, 값이 저렴하기 때문에 백업 및 복구 전략 사용
        • 중간에서 인프라를 관리할 필요 없이 재해 발생 시 인프라를 재생산할 수 있어 백업 저장 비용 외에는 추가비용 X
        • 백업 및 복구는 아주 쉽고 비용 저렴, BUT RPO, RTO가 높음
    • 파일럿 라이트
      • 애플리케이션의 축소 버전이 클라우드에서 항상 실행
      • 크리티컬 코어에  유용
      • 백업 및 복원과 매우 유사
      • 크리티컬 시스템이 이미 가동되어 있기 때문에 백업 및 복원보다 빠름
      • 크리티컬 DB에서 RDS로 데이터를 계속 복제한다면 언제든 실행할 수 있는 RDS DB를 확보하게 됨
      • BUT EC2 인스턴스는 아직 크리티컬 시스템이 아님
      • 재해가 발생할 경우 Route 53이 데이터 센터 서버에 장애 조치를 허용하여 클라우드에 EC2 인스턴스를 재생산하고 실행하도록 처리
      • RDS DB는 이미 준비된 상태이기 때문에 RPO, RTO가 낮아짐
    • 웜 대기
      • 시스템 전체를 실행하되 최소한의 규모로 가동해서 대기
      • 재해 발생시 프로덕션 로드에 맞게 확장 가능
      • 역방향 프록시와 애플리케이션 서버, 마스터 DB 존재
      • 클라우드에서는 실행중인 RDS slave DB로 데이터 복제가 이루어짐
      • EC2 오토 스케일링 그룹이 최소 용량으로 가동하며 기업 데이터센터 DB와 소통
      • ELB는 Ready
      • 재해가 발생하면 Route 53을 사용하여 ELB로 장애 조치를 해서 애플리케이션이 데이터를 가져오는 곳을 변경하는 작업도 가능
    • 핫 사이트 / 다중 사이트
      • 매우 낮은 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 / EElastic Beanstalk을 사용하여 전체 환경 재생성
      • CloudWatch 경보가 실패했을 때 EC2 인스턴스 복구 및 다시 시작
    • Chaos
      • Netflix는 가동중인 EC2를 무작위로 종료하는 "simian-arm 사용

2. DMS - Database Migration Service

  • 빠르고 안전하게 DB를 AWS로 마이그레이션, 복원성이 좋고 자가 복구 기능 제공
  • 마이그레이션 중에도 원본 DB 사용 가능
  • 동종(Homogeneous) 마이그레이션: oracle -> oracle
  • 이기종(Heterogeneous) 마이그레이션: Microsoft SQL Server -> Aurora
  • CDC(Continuous Data Replication)를 사용한 지속적인 데이터 복제
  • DMS를 사용하려면 복제 작업을 수행하기 위해 EC2 인스턴스 생성 필요
  • DMS Sources And Targets
    • Source
      • 온프레미스 & EC2 인스턴스 DB: Oracle, MS SQL Serveer, MySQL, MariaDB, PostgreSQL, MongoDB, SAP, DB2 등
      • Azure: Azuree SQL Database
      • Amaon RDS: Aurora를 포함한 모든 DB
      • Amazon S3
      • DocumentDB
    • Target
      • 온프레미스 & EC2 인스턴스 DB: Oracle, MS SQL Serveer, MySQL, MariaDB, PostgreSQL, MongoDB, SAP, DB2 등
      • Amazon RDS
      • Redshift, DynamoDB, S3
      • OpenSearch Service
      • Kinesis Data Streams
      • Apache Kafka
      • DocumentDB & Amazon Neptune
      • Redis & Babelfish
    • Source DB와 Target DB가 같은 엔진을 가지고 있지 않을 때는 AWS Schema Conversion Tool(SCT)를 사용해야 함
  • AWS Schema Conversion Tool(SCT)
    • 데이터베이스의 스키마를 다른 엔진으로 변환
    • 같은 엔진을 쓰는 데이터베이스에서는 필요 X
  • RDS & Aurora Migrations
    • RDS MySQL -> Aurora MySQL
      • Option 1: RDS MySQL의 DB 스냅샷을 생성해서 이 스냅샷을 MySQL Aurora DB에서 복원(가동 중지 후 마이그레이션 하기 때문에 다운타임 발생)
      • Option2 : Aurora 읽기 전용 복제본을 RDS MySQL에 생성, 복제 지연이 0이 될 때까지 기다린 후 독립적인 DB 클러스터로 승격(시간과 비용 발생)
    • 외부 MySQL -> Aurora MySQL
      • Option 1: Percona XtraBackup을 사용하여 Amazon S3에 파일 백업 생성 -> Amazon S3에서 Aurora MySQL DB 생성
      • Option 2: Aurora MySQL DB 생성 -> mysqldump를 사용하여 MySQL을 Aurora로 마이그레이션(S3보다 느릴 수 있음)
    • 두 DB가 모두 가동중인 경우 DMS 사용
  • RDS &  Aurora PostgreSQL Migrations
    • RDS postgreSQL -> Aurora MySQL
      • Option 1: RDS PostgreSQL의 DB 스냅샷 생성, 이 스냅샷을 PostgreSQL Aurora DB에 복원
      • Option 2: Aurora 읽기 전용  복제본을 RDS PostgreSQL에 생성, 복제 지연이 0이 될 때까지 기다린 후 독립적인 DB 클러스터로 승격(시간과 비용 발생)
    • 외부 PostgresQL -> Aurora MySQL
      • 백업 생성 및 Amazon S3에 저장 -> aws_s3 Aurora 확장 기능을 사용하여 백업

3. On-Premise Strategy with AWS

  • Amazon Linux 2 AMI를 가상머신(.iso) 으로 다운롣드 할 수 있음
    • VMWaree, 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로 증분 복제

4. AWS Backup

  • 완전 관리형 서비스
  • AWS 서비스 간의 백업을 중점적으로 관리하고 자동화할 수 있게 도와줌
  • 사용자 지정 스크립트나 매뉴얼을 작성할 필요 X
  • 지원 서비스
    • Amazon EC2 / Amazon EBS, Amazon S3, Amazon RDS, Amazon Aurora, Amazon DynamoDB
    • Amazon  DocumentDB, Amazon Neptune
    • Amazon EFS, Amaon FSx
    • AWS Storage Gateway(Volume Gateway) 등
  • 리전간, 계정간 백업 지원
  • 지원되는 서비스에 댇한 지정 시간 복구(Point-in-Time Recovery, PITR) 지원
  • 온디멘듣 및 예약된 백업 지원
  • 태그 기반 백업 정책 생성 가능
  • 백업 정책에서 백업 플랜 생성
    • 백업 빈도 설정, 백업 윈도우 설정
    • Cold Storage로의 이전 기간 설정
    • 보존 기간 설정
  • Vault Lock
    • 저장된 모든 백업에 대해 WORM(Write Once Read Many) 상태를 강제화
    • 무심결 또는 악의적인 삭제 작업으로부터 백업을 보호하기 위한 추가적인 보안 기능
    • 보존 기간을 단축하거나 변경하는 업데이트로부터 백업 보호
    • 루트 사용자조차도 활성화된 경우에는 백업 삭제 불가

5. Application Migration Service(MGN)

  • AWS Application Discovery Service
    • 온프레미스 데이터 센터에 대한 정보 수집을 통해 마이그레이션 프로젝트를 계획할 수 있도록 지원
    • 서버를 스캔하고 마이그레이션에 중요한 서버 설치 데ㅇ이터 및 종속성 매핑에 대한 정보 수집
    • Agentless Discovery(AWS Agentless Discover Collector)
      • 가상 인벤토리, 구성 및 성능 히스토리(ex.CPU, memory, 디스크 사용량) 수집
    • Agent-Based Discovery(AWS Application DIscovery Agent)
      • 시스템 구성, 시스템 성능, 실행중인 프로세스 및 시스템 간 네트워크 연결에 대한 세부 정보 수집
    • 수집된 데이터는 AWS Migration Hub에서 확인 가능
  • AWS Application Migration Service(MGN)
    • 온프레미스에서 AWS로 이동하는 가장 간단한 방법
    • MGN은 cloudEndure Migration의 AWS 진화로서, AWS Server Migration Service(SMS)를 대체하는 서비스
    • MGN은 애플리케이션을 AWS로 간편하게 마이그레이션하는 Lift-and-Shift(리호스팅)솔루션
    • 물리적, 가상화된, 클라우드 기반의 서버를 AWS에서 네이티브로 실행할 수 있도록 변환
    • 다양한 플랫폼, 운영 체제, 데이터베이스 지원
    • 최소한의 다운타임과 비용으로 마이그레이션 수행

6. Transferring large amoung of data into AWS

  • 일회용 전송
    • 공용 인터넷 또는 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 사용
      • 전체 전송에는 약 일주일
      • DMS와 결합하여 사용
  • 지속적인 복제 / 전송
    • Site-to-Site VPN이나 DX를 사용하여 DMS, DataSync와 함께 사용

7. VMware Cloud  on AWS

  • 고객이 기존의 온프레미스 데이터 센터를 관리하기 위해 VMware Cloud를 사용하고자 할 때 AWS의 확장 용량을 활용할 수 있는 솔루션
  • examples
    • 컴퓨팅 성능을 확장하여 데이터 센터에서 클라우드 뿐만 아니라 스토리지까지 컴퓨팅이가능해져 VMware 기반 워크로드를 AWS로 마이그레이션 가능
    • 프로덕션 워크로드를 여러 데이터 센터 간 실행 가능, 프라이빗, 퍼블릭, 하이브리드 클라우드 환경 모두가능
    • 재해복구 전략으로 활용
  • VMware Cloud on AWS는 AWS와 VMware의 협력을 통해 개발 되었으며, 고객은 기존의 VMware 환경과 동일한 돋구와 프로세스를 유지하면서 AWS의 유연성과 확장성을 활용할 수 있음
  • 이를 통해 기존의  VMware 스킬셋을 활용하여 AWS로의 이동을 간소화하고비용과 관리 부담을 줄일 수 있음
반응형
LIST
저작자표시