AWS_복구

- 고가용성 : APP 가동 중단 시간 최소화

- 백업 : 데이터 안전 유지

- 재해복구 : 재해 발생 후 APP및 데이터 백업본 가져오기

1. 재해 복구

1) RTO(Recovery Time Object)

 : 재해 발생 후, 기준 시간 내에 복구할 것인지에 대한 기준. 기준 시간이 1시간이라면 재해 발생 후 1시간 내에 서비스가 재가동되어야 한다. 

2) RPO(Recovery Point Object)

 : 데이터의 손실이 발생하였을때 어느 정도의 데이터를 복구할 수 있는지에 대한 기준. 최장 12시간 주기로 백업이 이루어지며 그 사이에 장애가 발생하면 마지막 백업을 이후에 만들어진 데이터는 복구할 수 없다. 주기가 짧을수록 비용과 저장공간의 요구가 높아진다.

 

아주 극히 드문 확률로 리전 전체에 장애가 발생할 수도 있다. 이를 어떻게 대처할 것인가?

3) 복구 필수 서비스

 i. 스토리지

  - S3, Glacier : 다른 리전, 다른 가용영역에 복제하여 대비

  - EBS : 파티션 분할로 복제가 자주 되지만 특정 시점을 저장하는 스냅샷기능으로 장애 대비. 스냅샷은 S3에 저장

  - Snowball : On-Premise 환경에서 Cloud로 이전하 때 고속 인터넷보다 더빠른 10TB 초과된 속도로 데이터 전송

  - DataSync : S3, EBS쪽으로 데이터를 옮길때 더 빠르고 안전하게 동기화 시켜주는 기능

 

 ii. DB

 - RDS : 고가용성 보장. 멀티 Age를 통해 재해 복구 전략 수립, 자동 백업

 - DynamoDB : 고가용성 보장, 특정 시점 백업, 손쉬운 백업 기능 제공 

 

 iii. 컴퓨팅

 : 인스턴스, 컨테이너 AMI를 주기적으로 관리하고 최신화 시켜놓는다면 서버가 소실돠더라도 곧바로 복구

 

 vi. 네트워크

 - Route 53 : 서로다른 리전에 만들어진 인프라를 이용해 장애 조치 및 모니터링 기능 

 - ELB : 서로 다른 가용영역에 로드 밸런싱 및 모니터링 기능

 - VPC : On-Premise 환경의 네트워크 토폴로지를 Cloud로 확장하여 하이브리드 환경으로 서로 장애 보완 기능

 - Direct Connect : 백업 작업 수행 시 더 안전하게 완료 가능 

 

 v. 배포 조직화

: RTO를 보장하기 위한 서비스. RTO를 보장하기 위해선 Disaster Recovery Center가 있어야 하지만 DRC없이 Cloud Formation을 통해 장애가 발생하여도 템플릿이나 AMI가 잘 구축되어 있다면 다른 리전을 사용해 곧바로 서비스를 재개할 수 있다. 

 - CloudFormation : 템플릿을 활용하여 필요에 따라 리소스 모음을 신속히 배포

 - Elastic Beanstalk : 최소한의 클릭으로 전체 스택 배포

 - OpsWorks : 자동 호스트 교체, 복구 단계에서 CloudFormation과 결합

2. AWS BackUP

 : 여러 시스템의 자체적 복구 시스템은 좋지만 중구난방하여 관리가 어려운데 이를 관리해주는 서비스

 - 중앙 집중식 백업 관리

 - 정책 기반 백업 솔루션

 - 태그 기반 백업 정책

 - 자동화된 백업 일정 관리 

3. 복구 전략

1) 백업 및 복원

 : 인프라는 신경쓰지 않고 데이터에 집중하는 백업 전략. 인프라에 장애가 생겼을 시 수동으로 재구축하거나 CloudFormation을 사용하여 자동화된 배포환경을 사용할 수 있다. 

 - 가장 저렴하지만 RTO가 2,3시간 정도 소모

 - 시스템 백업에 필요한 목록과 절차 수립

 - 모의 훈련 필수

 

i. AWS Storage Gateway : On-Premise 데이터 백업 

 :  게이트웨이가 담긴 AMI를 제공하고 On-Premise 환경에서 VM을 생성하여 이 AMI를 통해 서버 구축

  - 파일 게이트웨이 

  - 볼륨 게이트웨이

  - 테이프 게이트웨이 : 매우 저렴하나 데이터 검색에 매우 많은 시간이 소모. 대부분 아카이빙용

2) 파일럿 라이트

 : DRC을 만들어 서비스를 제공해야 하는 필수적인 서버 외에는 OFF 시켜 놓는 형태. RPO에 맞게 미러링이나 백업을 통해 백업을 해두고 DRC에는 인프라와 동일한 인프라를 구축하여 대비. 장애 발생 시 DRC를 부팅시키고 정상 작동하는지 확인 후 트래픽 인계

 - 효율적인 비용, RTO 1시간 이내

 - 데이터 복제, 미러링 필수

 - 새로운 인프라를 구동시킬 때 테스트 정책 수립 및 관리 점검

3) 완전 동작 저용량 스탠바이

 : DRC를 생성 후 ON. 단, 소규모로 생성하여 '가중치 기반 라운드 로빈'을 통해 DRC가 감당할 수 있는 트래픽만 흘려 구동. 장애 발생 시 DRC의 규모를 확장시켜 메인 인프라로 가는 인프라까지 감당하여 장애 복구

 - 비용 지출이 있으나 RTO가 '분' 단위

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

 - 계속 구동중인 인프라기 때문에 큰 테스트 필요 X

4) 다중 사이트 Active - Active

 : 메인 인프라와 DRC의 규모가 동일하게 정상적으로 구축한다. 목표 RTO는 '0' 단, 메인 인프라에 장애가 발생 시 그 요청에 한해서는 '응답없음'이 반환되기까지 Route 53이 트래픽을 차단하는 시간이 소모된다. 

 - 비용 지출이 2배이지만 RTO는 '초' 단위

 - 언제라도 모든 트래픽 처리 가능

 - 완전 동작 저용량 스탠바이와 동일하나 가동률의 차이

4. 복구 전략 전 참고사항

- 기본적으로 백업&복구 전략을 사용하며, 버거워 질수록 강력한 전략을 수립하는 것을 추천

- 백업&복구를 제외하고는 2번째 인프라가 있기 때문에 라이센스 확인 필수(추가 비용 재비)

- "게임 데이" : Cloud 환경에서 실제 인프라와 동일한 인프라를 구축하고 인위적으로 장애를 일으켜 복구 전략을 시행. 그 후 테스트용 인프라를 삭제