재해복구

2023. 7. 22. 07:41·Cloud/AWS
반응형

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 등의 서비스
반응형
'Cloud/AWS' 카테고리의 다른 글
  • AWS Certified Solutions Architect - Associate(SAA-C03) 자격증 취득 후기
  • 기타 서비스
  • VPC
  • AWS 보안 및 암호화
Debin
Debin
공부 기록을 남기며 게시글 리팩토링을 진행하는 블로그입니다.
  • Debin
    리팩토링하는 블로그
    Debin
  • 전체
    오늘
    어제
    • 분류 전체보기
      • DB
        • DB 기초
        • MySQL
        • SQL 튜닝
      • OS
      • Network
      • Git
      • 디지털콘텐츠기획
      • 소프트웨어공학
      • 코딩테스트
        • 프로그래머스
        • 백준
        • 인프런
      • 공부 일지
      • 독서
        • 클린코드
        • 일상 속 사물이 알려주는 웹 API 디자인
        • 토비의 스프링
        • 객체지향의 사실과 오해
        • 자바 잘 읽는 법
      • 기록 및 회고
      • Cloud
        • AWS
      • 개발
        • Java
        • Spring Core
        • Spring MVC
        • Spring DB
        • Spring Boot
        • Spring Security
        • Spring Batch
        • JPA
        • Test
        • Android
      • 대외활동
        • UMC SERVER
        • 카엔프 SW 아카데미
      • 프로젝트
      • Docker
      • Gradle
      • ELK
      • 실무 이야기
  • 블로그 메뉴

    • 홈
    • 태그
    • 방명록
  • 링크

    • 깃허브
  • 공지사항

    • 본인 깃허브입니다!
  • 인기 글

  • 태그

    redis
    자바
    코딩 #개발자 #노마드북클럽 #노개북
    test
    spring boot
    spring mvc
    mysql
    innodb
    spring
    docker
    토비의 스프링
    컨테이너
    스프링
    AWS
    인덱스
    container
    객체
    프록시
    JPA
    스프링 부트
    ORM
    AOP
    객체지향
    운영체제
    데이터베이스
    SQL
    트랜잭션
    리눅스
    도커
    Java
  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.6
Debin
재해복구
상단으로

티스토리툴바