반응형
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 서비스에 백업 가능
- 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로 라우팅을 실시함
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이 필요 없음
'Amazon Web Serivce 자격증 쉽게 공부하기 > [C00]AWS Advanced Networking Specialty' 카테고리의 다른 글
ANS #17, Billing and Costs (완결) (0) | 2020.10.06 |
---|---|
AWS Hybrid Network Architecture(On-premise와 Cloud) (0) | 2020.09.23 |
ANS #14, AWS Virtual Private Network(VPN) (0) | 2020.09.22 |
ANS #13, Direct Connect - 3 (0) | 2020.09.19 |
ANS #12, Direct Connect - 2 (0) | 2020.09.19 |
댓글