AWS 기반 재해 복구(DR: Disaster Recovery) 아키텍처 - active/passive & active/active | RTO & RPO | Poilot Light & Warm Standby

RTO & RPO 

RTO (Recovery Time Objective)

: 서비스 중단과 서비스 복원 사이의 최대로 허용 되는 지연시간

RPO (Recovery Point Objective)

: 마지막 데이터 복구 가능한 시점 이후에 장애시 데이터 손실을 허용 할수 있는 최대 시간

 

재해 복구 전략 

: 낮은 RTO(Recovery Time Objective) 및 RPO(Recovery Point Objective)의 이점과 구축 및 운영 비용 중 어디에 중점을 둘지 고려해야 함

1)  백업 및 복구

• 다른 전략대비 RTO가 가장 높아, 복구에 많은 시간이 소요됨
• Amazon EventBridge와 같은 AWS 리소스를 사용하여 재해 상황의 감지 및 복구 시나리오를 개선하여, 복구 시간을 줄이고 자동화할수 있음 

 

2) 파일럿 라이트

 

장애 발생으로 모든 인프라를 생성 및 동작 시키기 전까지 어떤 요청도 처리할수 없음

 

3) 웜 스탠바이

주기적인 백업 외에도 최신의  데이터를 유지 + 요청을 처리할 수 있는 최소의 인프라를 유지(프로덕션 수준 트래픽 처리는 불가) 

- 파일럿 라이트 배포보다 자동화되고 더 확장 가능한 설정을 제공

 

 - active/passive & active/active 

active/passive 전략

: 워크로드는 단일 사이트에서 작동하며 모든 요청은 이 액티브 리전에서 처리, 재해 상황이 발생하고 액티브 지역이 워크로드를 처리 할수없는 경우, 패시브 사이트로 시스템이 복구됨

 

active/active 전략

: 한 리전이 재해 상황이 발생하였을 경우, 해당 리전의 트래픽이 나머지 액티브 리전(Region)으로 전달 되는 구조,  리전 간에 데이터는 복제되고 있지만, 재해 복구 전략의 일부로 데이터를 백업함

- 복구 시간이 가장 빠르고(가장 낮은 RTO), 데이터 손실이 가장 적은(가장 낮은 RPO) 재해복구가 필요한 경우 Multi-site Active/Active 사용

 

 

reference

https://aws.amazon.com/ko/blogs/tech/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud-1/

https://aws.amazon.com/ko/blogs/tech/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud-3/