RTO/RPO 및 백업 복구 설정

필요성

- 인프라를 사용할 수 없는 경우 적절한 시간 내에 적절한 비용으로 애플리케이션을 다시 실행 할 수 있어야 한다.

 

재해 복구 계획

- 장애는 날 수 있다는 생각을 가지고 구성을 해야한다.

 

가용성 개념

- 고가용성 : 애플리케이션의 가동 중단 시간 최소화( 중복성을 가져간다)

- 백업: 데이터를 안전하게 유지 ( 저장만 할 뿐 아니라 백업 데이터를 잘 가져오는것도 필요)

- 재해 복구(DR): 주요 재해 발생 후 애플리케이션 및 데이터 백업을 가져온다.

 

RPO 및 RTO

RPO(복구 시점 목표) - 얼마나 오래?

- 얼마나 자주 데이터를 백업해야 합니까?

RTO(복구 시간 목표) - 얼마나 빨리?

- 애플리케이션을 얼마나 오래 사용할 수 없습니까?

 

AWS 리전이 다운될 수 있음을 가정한다.

 

재해 복구에 필수적인 AWS 서비스 및 기능

- 스토리지

- 컴퓨팅

- 네이트워킹
- 데이터베이스

- 배포 오케스트레이션( Cloud Fromation과 같은 자동화 이용, 휴먼 에러 방지)

 

스토리지는 중복 되어야 한다

- S3 교차리전 복제

- S3 Glacier 각 가용 영역의 여러 가용 영역 및 여러 디바이스에 복제

- EBS 특정 시점 볼륨 스냅샷 생성, 리전 및 계정 간의 스냅샷 복사

- Snowball 고속 인터넷보다 대용량(10TB 초과) 데이터를 더 빨리 전송

- EFS data sync

 

컴퓨팅 백업 조정은 쉬어야 한다.

- 새로운 서버 인스턴스 또는 컨테이너를 몇 분 내에 확보하고 부팅한다.

 

네트워킹 재해 복구 옵션

- Route 53 : 트래픽 배포, 장애조치

- ELB : 로드밸런싱, 상태 확인 및 장애 조치

- VPC : 기존 온프레미스 네트워크 토폴로지를 클라우드로 확장

- Direct Connect : 클라우드로 대규모 온프레미스 환경의 빠르고 일관적인 복제/백업

 

데이터베이스 백업 및 중복

- RDS

  - 스냅샷 데이터를 별도의 리전에 저장

  - 읽기 전용 복제본을 여러 가용 영역과 결합하여 탄력적인 재해 복구 전략을 수립

  - 자동 백업 보존

- DynamoDB : 

  - 클로벌 테이블 이용

  - 테이블 백업

 

자동화를 사용

- Cloud Formation

- Elastic Beanstalk

- OpsWorks

 

복구전략

- s3 를 백업용으로 쓴다.

 

온프레미스 데이터를 AWS로 백업

AWS Storage Gateway

- 파일 게이트웨이

- 볼륨 게이트웨이

  1. cache - s3에 모든 데이터를 넣고 자주쓰는 데이터만 온프레미스에 들고 있는다

  2. backup - 온프레미스 데이터를 s3에 백업하는 형태

- 테이프 게이트웨이

 

백업 및 복원

준비 단계

 - 현재 시스템을 백업

 - S3에 백업 저장

 - AWS의 백업으로부터 복원하는 절차를 기술 - 다음 사항을 알고 있어야 한다.

  - 사용할 AMI(필요하면 자체 AMI를 구성)

  - 백업으로부터 시스템을 복원하는 방법

  - 새로운 시스템으로 전환하는 방법

  - 배포를 구성하는 방법

재해 발생 시

 - s3로부터 백업 검색

 - 필요한 인프라 준비

 - 백업으로부터 시스템 복구

 - 새로운 시스템으로 전환

 

파일럿 라이트 ( Pilot Light)

복제된 ec2를 stop상태로 대기상태로 놓는다, DB 비용이 나간다.

- 이점 : 비용 효율적

- stop이 러닝으로 가는데 복구 시간이 걸린다.

 

재해 발생 시

- 복제된 핵심 데이터 세트 주위의 리소스를 자동으로 준비

- 트래픽을 옮긴다.

 

완전 동작 저용량 스탠바이

- 비즈니스 중단 없이 

- 오토 스케일링을 걸어논다.

- 오토스케일링 없이는 100% 트래픽을 받아낼 수는 없다.

- 언제라도 서비스 트래픽 일부를 처리 가능

 

다중 사이트 액티브-액티브

이점 : 언제라도 모든 프로덕션 로드 처리 가능

- 비싸다......