[SAA] AWS의 재해 복구

Disaster Recovery Overview

• 재해란 회사의 사업 지속이나 재정에 부정적인 영향을 미치는 이벤트
• 재해 복구는 재해에 대비하고 재해가 발생할 시 복구하는 작업을 의미
• AWS에서 혹은 일반적으로 수행하는 재해 복구 유형
  
  
  • 온프레미스 간 재해 복구 실행
    예) 캘리포니아에 첫 번째 데이터 센터가 있고, 나머지 하나는 시애틀에 있을 때
    이는 전형적인 재해 복구 유형으로 비용이 아주 많이 듦
  • 하이브리드 복구
    온프레미스를 기본 데이터 센터에 두고 재해 발생 시 클라우드를 사용하는 방식
  • 완전 클라우드 유형
    모두 클라우드에 있는 경우 AWS Cloud 리전 A에서 B로 재해 복구를 수행

RPO and RTO

• 복구 시점 목표를 의미하는 RPO (Recovery Point Objective)
  복구 시점 목표란 얼마나 자주 백업을 실행할지, 시간상 어느 정도 과거로 되돌릴 수 있는지를 결정
  재해가 일어나면 RPO와 재해 발생 시점 사이에 데이터 손실이 발생하므로 재해 발생 시 데이터 손실을 얼마나 감수할지 설정 
  한 시간, 1분 등 원하는 대로 설정할 수 있음
• 복구 시간 목표를 의미하는 RTO (Recovery Time Objective)
  재해 발생 후 복구할 때 사용되며, 재해 발생 시점과 RTO의 시간 차는 애플리케이션 다운타임을 뜻함
  다운타임을 24시간으로 두기도 하며 때로는 1분으로 설정해야 하는 경우도 있음
• RPO와 RTO 최적화는 솔루션 아키텍처를 결정하는 요인이 되며 시간 간격이 짧을수록 비용은 높아짐

Disaster Recovery Strategies

• 재해 복구 전략 : RTO가 각기 다름
  
  
  • 백업 및 복구 : RTO가 작음
  • 파일럿 라이트 : 비용이 더 들지만 RTO가 빠르므로 다운타임이 줄어듦
  • 웜 대기 : 비용이 더 들지만 RTO가 빠르므로 다운타임이 줄어듦
  • 핫 사이트 혹은 다중 사이트 접근 : 비용이 더 들지만 RTO가 빠르므로 다운타임이 줄어듦

Backup and Restore (High RPO)

• 백업 및 복구는 RPO가 큼
  
• 예1) 기업 데이터 센터와 AWS Cloud의 S3 버킷과 Glacier를 사용할 때
  시간에 따라 데이터를 백업하고 싶다면 AWS Storage Gateway 사용한 후, 수명 주기 정책을 만들어
  비용 최적화 목적으로 Glacier에 데이터를 입력하거나 Snowball을 사용해 일주일에 한 번 많은 양의 데이터를 Glacier에 전송
  Snowball을 사용하면 RPO는 대략 일주일이 되게 되며 데이터 센터의 데이터가 전부 사라진다면 한 주 치 데이터를 잃게 됨
  
• 예2) AWS Cloud에서 EBS 볼륨과 Redshift, RDS를 사용할 때
  정기적으로 스냅샷을 예약하고 백업해두면 24시간이든 한 시간이든 스냅샷을 만드는 간격에 따라 PRO가 달라짐
  재해가 발생하면 모든 데이터를 복구해야 하므로 AMI를 사용해 EC2 인스턴스를 다시 만들고 
  애플리케이션을 스핀 업하거나 스냅샷에서 RDS, EBS 볼륨, Redshift 등으로 바로 복원 및 재생산
  데이터 복구는 시간이 오래 걸리므로 RTO는 커지겠지만 값이 저렴하기 때문에 백업 및 복구 전략을 사용하며
  중간에서 인프라를 관리할 필요 없이 재해 발생 시 인프라를 재생산할 수 있으므로 백업 저장 비용 외에는 따로 들지 않음
• 백업 및 복구는 아주 쉽고 비용이 저렴하지만 PRO와 RTO가 높음

Disaster Recovery – Pilot Light

• 파일럿 라이트는 애플리케이션 축소 버전이 클라우드에서 하상 실행되는 것을 뜻하며 크리티컬 코어가 됨
  백업 및 복구와 아주 비슷하지만 크리티컬 시스템이 항상 작동하기 때문에 복구할 때 몇 가지 시스템만 더 해주므로 속도가 빠름
• 예) 서버와 데이터베이스를 갖춘 데이터 센터가 있고 AWS Cloud가 있을 때
  크리티컬 데이터베이스에서 RDS로 데이터를 계속 복제한다면 언제든 실행할 수 있는 RDS 데이터베이스를 확보하게 됨
  하지만 EC2 인스턴스는 아직 크리티컬 시스템이 아니므로 작동하지 않고 있다가
  재해가 발생하면 Route53가 데이터 센터 서버에 장애 조치를 허용해 클라우드에 EC2 인스턴스를 재생산하고 실행하도록 처리
  이때 RDS 데이터베이스는 이미 준비된 상태이므로 RPO와 RTP가 낮아짐
• 크리티컬 코어 보조에만 사용함

Warm Standby

• 웜 대기는 시스템 전체를 실행하되 최소한의 규모로 가동해서 대기하는 방법
  재해가 발생하면 프로덕션 로드로 확장할 수 있음
• 예) 기업 데이터 센터가 있고 역방향 프록시와 애플리케이션 서버, 마스터 데이터베이스를 포함할 때
  Route 53이 DNS를 기업 데이터 센터로 가리키며 클라우드에서는 RDS Slave 데이터베이스로 데이터 복제가 이루어지고 있음
  EC2 오토 스케일링 그룹이 최소 용량으로 가동하며 기업 데이터 센터 데이터베이스와 소통하며 ELB는 준비된 상태
  재해가 발생하면 웜 대기 전략이 있기 때문에 Route 53을 사용해서 ELB로 장애 조치해
  애플리케이션이 데이터를 가져오는 곳을 변경하는 작업도 가능
  즉, RDS Slave로 변경한 뒤 효과적으로 대기했다가 오토 스케일링을 사용하면 애플리케이션이 빠르게 확장
  이는 ELB와 EC2 오토 스케일링이 동시에 실행되기 때문에 비용이 조금 더 들지만 RPO와 RTO는 줄어듦

Multi Site / Hot Site Approach

• 몇 분, 몇 초 정도로 RTO가 낮지만 비용이 굉장히 큼
  
• AWS와 온프레미스에서 두 완전 프로덕션 스케일을 얻게 되므로
  온프레미스 데이터 센터 완전 프로덕션 스케일과 데이터 복제를 진행하는 동시에 AWS 데이터 센터 완전 프로덕션 스케일이 가능
• 이미 실행 중인 핫 사이트가 있기 때문에 Route 53가 기업 데이터 센터와 AWS Cloud에 요청을 라우팅할 수 있으므로
  액티브- 액티브 유형 설정이라고 하며 필요하다면 EC2가 RDS Slave 데이터베이스에 장애 조치를 할 수 있음
  AWS와 온프레미스에서 오나전 프로덕션 스케일이 실행돼 많은 비용이 발생하지만
  동시에 장애 조치를 할 준비가 되어 있으므로 다중 DC 유형 인프라를 실행할 수 있음

All AWS Multi Region

• 모두 클라우드로 실행하는 경우
• 아키텍처는 동일하게 다중 리전이며 클라우드 내에 있으므로 Aurora 사용도 가능
  리전에 마스터 데이터베이스가 있고 Slave로 다른 리전에 복제된 Aurora Global 데이터베이스도 있음
  두 리전 모두 잘 작동하는데 장애 조치를 할 때 필요에 따라 완전 프로덕션 스케일이 다른 리전에서 가능

Disaster Recovery Tips

• Backup
  백업에는 EBS 스냅샷과 RDS로 자동화된 스냅샷과 백업 등을 사용
  S3, S3 IA, Glacier 등에 스냅샷을 규칙적으로 푸시할 수 있음
  수명 주기 정책 실행도 가능
  백업이 다른 리전에 있길 바란다면 리전 간 복제도 가능
  온프레미스에서 클라우드로 데이터 공유 시 Snowball과 Storage Gateway가 유용
  
• High Availability
  고가용성을 위해서는 Route 53을 사용해 DNS를 다른 리전으로 옮기면 됨
  다중 AZ를 실행하는 기술에는 RDS 다중 AZ, ElastiCache, 다중 AZ EFS, S3 등이 있으며 웹사이트를 활성화하면 가용성이 높음
  기업 데이터 센터에서 AWS로 연결할 때 Direct Connect를 실행하면 네트워크 가용성이 높아짐
• Replication
  만약 연결이 끊기면 Site-to-Site VPN을 네트워크 복구 옵션으로 사용할 수 있음
  RDS 리전 간 복제, 오로라 글로벌 데이터베이스에 복제 가능
  온프레미스 데이터베이스를 RDS로 복제할 때 데이터베이스 복제 소프트웨어나 Storage Gateway 사용 가능
• Automation
  자동화의 경우 CloudFormation과 Elastic Beanstalk가 클라우드에 새로운 환경을 빠르게 재생산하도록 도움
  CloudWatch를 사용한다면 CloudWatch 경보가 실패했을 때 EC2 인스턴스를 복구하거나 다시 시작할 수 있음
  AWS Lambda는 사용자 맞춤 자동화에 유용하며 REST API에도 좋지만 AWS 인프라 자체를 자동화할 때 효고적
• Chaos
  재해 복구 방법을 알기 위해서는 재해를 만들어서 대처해보면 됨
  예) 넷플릭스의 경우
  모든 것을 AWS에서 실행하고 simian0army를 만들어 EC2 인스턴스를 무작위로 종료하여
  무작위로 실제로 가동 중인 애플리케이션 서버를 중단하여 장애가 발생해도 인프라가 무사하도록 카오스 몽키를 실행
  이를 통해 인프라 기반을 단단히 다져 어떤 장애에도 끄떡없도록 함