ANS #16, Disaster Recovery

Backup and Recover Disaster(DR)

• RPO and RTO에 대한 이해 필요
• RTO : Recovery Time Objective(RTO)
  • 얼마나 빨리 백업할 수 있는가?
  • 업무 중단 시점부터 복구되어 가동될 때가지의 시간 목표
• RPO : Recovery Point Objective(RPO)
  • 데이터 손실을 어느 정도까지 허용할 수 있는가?
  • 업무 중단 시점부터 데이터 손실을 수용할 수 있는 시점
• Traditianal DR
  • Primary Site / Recover Site
  • 양쪽 모두 동일한 하드웨어/소프트웨어 자원을 구비함
  • 비용이 많이 소요됨
• Backup and Resotre to AWS
  • Primary Site / AWS
  • Primary Site에 있는 하드웨어 내 데이터를 용도에 맞는 AWS 서비스에 백업 가능

<Restore to AWS(출처 : Rick Crisci ANS 강의)>

• DR 계획은 주기적으로 테스트되어야 함!
• Restore Prcoess
  • 새로운 인스턴스 시작
    • Autoscaling / ELB 사용
    • Cloudfront 사용
  • S3에서 백업본을 복원
  • DNS 재설정

AWS Pilot light

• AWS의 재해 복구 서비스
• Primary Site의 Database는 주기적으로 AWS로 복제되며 Web Server, App Server의 경우 해당 서버들로부터 복제된 AMI를 미리 대기시켜둠
• 장애 발생시 Web AMI / App AMI로부터 빠르게 인스턴스를 생성하며 복제된 Database로부터 데이터를 제공받음
  • Autoscaling를 설정하여 원하는 수의 최소 EC2를 실행할 수 있음
• Route 53 또한 Failover를 실시하여 Primary Site가 아닌 AWS로 라우팅을 실시함

<AWS Pilot(출처 : Rick Crisci ANS 강의)>

Warm Standby

• Warm Standby라는 이름처럼 AWS 내에서 이미 실행된 상태에서 대기하는 것
• 실제 워크로드를 감당할 정도의 용량을 갖고 있지 않음
• 장애 발생 후 Failover시 Scale up을 통해 성능을 워크로드를 감당할 수준으로 비약적으로 향상시킴
• Restore Process
  • Route 53 Failover Routing(With Health Check)
  • 워크로드 처리를 위한 Autoscaling
  • 이미 가동중인 상태이기 때문에 RTO는 낮지만, 성능을 올리는데 시간이 소요됨

Active/Active Disaster Recovery(DR)

• Priamry Site와 AWS를 Active/Active로 활용하는 방법(Full-Capacity Standby)
• Primary Site와 AWS 모두 비슷한 수준의 워크로드 처리 가능
• 장애 발생시 아주 낮은 RTO를 보여줌
• Primary Site의 Web, WAS가 AWS의 AMI에 지속적으로 동기화됨(Database도 마찬가지)
• Route 53의 Weighted Routing을 통해 트래픽 분배
• Restore Process
  • Route 53 Failover Routing
  • Scale up이 필요 없음

<Full-Capacity Multi-Site(출처 : Rick Crisci ANS 강의)>