AWS 기반 재해 복구(DR) 아키텍처, 1부: 클라우드에서의 재해 복구 전략

이 글은 AWS Architecture Blog에 게시된 Disaster Recovery (DR) Architecture on AWS, Part I: Strategies for Recovery in the Cloud을 한국어로 번역 및 편집하였습니다.

필자는 AWS Well-Architected 신뢰성 원칙의 수석 솔루션 설계자로서 고객이 AWS에서 복원력이 있는 워크로드를 구축하도록 돕고 있습니다. 고객이 직면할 수 있는 가장 큰 도전 중 하나인 재해 상황에 대비하는 데 도움이 됩니다. 이러한 재해 상황은 지진이나 홍수와 같은 자연 재해, 전원 또는 네트워크 손실과 같은 기술적 오류, 우발적이거나 승인되지 않은 수정과 같은 인간의 행동을 포함합니다. 궁극적으로 워크로드 또는 시스템이 기본 위치에서 비즈니스 목표를 달성하지 못하게 하는 모든 이벤트는 재해로 분류됩니다. 이 블로그 게시물은 재해에 대비하고 재해로부터 복구하는 프로세스인 재해 복구(DR)를 설계하는 방법을 보여줍니다. 재해 복구는 비즈니스 연속성 계획의 중요한 부분입니다.

재해 복구 목표

재해 상황은 잠재적으로 워크로드를 중단시킬 수 있으므로 재해 복구의 목표는 워크로드를 복구하거나 다운타임을 완전히 방지하는 것입니다. 재해 복구 목표는 다음과 같습니다.

RTO (Recovery Time Objective): 서비스 중단과 서비스 복원 사이의 최대로 허용 되는 지연시간 입니다. 이에 따라 서비스 다운타임의 허용 가능한 기간이 결정됩니다.
RPO(Recovery Point Objective): 마지막 데이터 복구 가능한 시점 이후에 장애시 데이터 손실을 허용 할수 있는 최대 시간입니다. 허용 가능한 데이터 손실을 결정 합니다.

[그림 1 : 재해 복구 목표 : RTO 및 RPO]

재해 상황의 영향 범위와 대응 전략

*다중 가용영역(AZ)*** 전략

모든 AWS 리전(Region)은 여러개의 가용 영역(AZ – Availability Zone)으로 구성됩니다. 각 가용영역(AZ)은, 각각 독립된 지리적 위치의 하나 이상의 데이터 센터로 구성됩니다. 이러한 구성은 하나의 장애 원인이 두개 이상의 가용영역(AZ)에 영향을 미칠 위험을 크게 줄일수 있습니다. 따라서 정전, 홍수 및 기타 국지적 문제로 인한 재해 상황을 고려하여 재해 복구 전략을 설계하는 경우, AWS 리전 내에서 다중 가용역역(AZ) 전략을 사용하면 필요한 서비스 가용성을 확보하고 데이터 보호를 보호할 수 있습니다.

*다중 리전(Region)*** 전략

AWS는 워크로드에 대한 다중 리전(Region) 전략을 제공합니다. 이는 넓은 지역의 여러 데이터 센터에 영향을 미칠 수 있는 광범위한 재해 상황을 극복할수 있어, 비지니스의 높은 가용성을 제공합니다. 이 블로그는 대부분 다중 리전(Region) 접근 방식을 사용하는 재해 복구 전략을 제시합니다. 물론 다중 가용영역(AZ) 전략 또는 하이브리드(온프레미스 워크로드/클라우드 복구) 전략도 같이 제시 합니다.

재해 복구 전략

AWS는 재해 복구와 관련된 비즈니스 요구사항을 충족하기 위해 필요한 리소스와 서비스를 제공합니다.

[그림 2 : 재해 복구 전략 : RTO/RPO와 비용 균형]

[그림 2]는 재해 복구 백서에서 강조 표시된 네가지 재해 복구 전략을 제시하고, 각각 충족 시킬수 있는 RTO 및 RPO를 보여주고 있습니다. 왼쪽에서 오른쪽으로 RTO 및 RPO 가 증가하는 순서대로 기술 되었습니다.

최선의 전략을 선택하려면 IT엔지니어와 비지니스 워크로드 담장자가 함께 서비스에 영향을 줄수 있는 위험을 분석해야 합니다. 분석 과정을 통하여 비지니스 워크로드에 필요한 RTO 및 RPO와 비용, 시간 및 노력에 대한 투자를 결정합니다.

액티브/패시브와 액티브/액티브 전략

[그림 3 : 액티브/패시브 재해 복구]

[그림 2]는 재해 복구 전략은 크게 액티브/패시브 또는 액티브/액티브로 분류합니다. [그림 3]에서는 액티브/패시브 작동 방식을 보여줍니다. 워크로드는 단일 사이트(이 경우 AWS 리전(Region))에서 작동하며 모든 요청은 이 액티브 리전에서 처리됩니다. 재해 상황이 발생하고 액티브 지역이 워크로드를 처리 할수없는 경우, 패시브 사이트로 시스템이 복구 됩니다. 이후 복구된 시스템이 워크로드를 실행할 수 있도록 장애 조치(Failover)를 취합니다. 장애 조치(Failover) 이후 모든 요청은 이제 새로 복구된 사이트로 전달 되도록 전환됩니다. RTO/RPO 를 최소화 하여 보다 효율적인 재해 복구를 위해 데이터는 실시간으로 유지되며, 인프라는 “장애 조치(Failover)” 전에 복구 사이트에 전체 또는 부분적으로 생성 됩니다. 백업에서 데이터를 복원해야 하는 경우 백업 시점 혹은 복구가능 시점 이후의 데이터 손실이 있을수 있습니다. 또한 “장애 조치(Failover)” 전에 인프라에서 추가 작업이 필요한 경우 복구 시간이 늘어날 수 있습니다. 비즈니스 목표 달성이 가능한 범위에서 RTO/RPO는 충분히 높을수 있습니다.

[그림 4 : 액티브/액티브 재해 복구]

[그림 4]는 2개 이상의 리전(Region)에서 워크로드를 나누어서 처리하고, 리전(Region) 간에 데이터가 복제되는 액티브/액티브 전략을 보여줍니다. 한 리전이 재해 상황이 발생하였을 경우, 해당 리전의 트래픽이 나머지 액티브 리전(Region)으로 전달 되는 구조 입니다. 리전 간에 데이터는 복제되고 있지만, 재해 복구 전략의 일부로 데이터를 백업합니다. 백업은 “인간의 행동 오류” 또는 “기술적 소프트웨어 결함”으로 부터 워크로드 및 데이터를 복구할수 있는 방법을 제시 합니다.

재해 복구 전략의 아키텍처

각 재해 복구 전략은 향후 블로그 게시물에서 자세히 설명할 예정이며, 이 블로그에서는 네개의 전략을 대해 간략히 소개합니다.

백업 및 복구

[그림 5 : 백업 및 복원 재해 복구 아키텍처]

[그림 5]는 다양한 AWS 데이터 저장소의 백업을 보여줍니다. 백업은 소스와 동일한 리전에 생성되며 다른 리전으로 복사도 가능합니다. 백업을 이용하여 대부분의 재해 상황의로부터 가장 효과적으로 데이터를 보호할수 있습니다. 장애 발생시 백업에서 데이터를 복구하는 것 외에도, 지정된 리전(Region)에서 인프라를 복원할 수 있어야 합니다. AWS CloudFormation 또는 AWS Cloud Development Kit(AWS CDK)와 같은 코드 인프라를 생성하는 툴을 사용하면 리전(Region)에 동일한 인프라를 배포할 수 있습니다.

백업 및 복구 전략은 다른 전략대비 RTO가 가장 높아, 복구에 많은 시간이 소요 됩니다. 이를 보완하기 위해 Amazon EventBridge와 같은 AWS 리소스를 사용하여 재해 상황의 감지 및 복구 시나리오를 개선하여, 복구 시간을 줄이고 자동화할수 있습니다. 이부분에 대해서는 향후 블로그 게시물에서 자세히 살펴보겠습니다.

파일럿 라이트

[그림 6 : 파일럿 라이트 재해 복구 아키텍처]

파일럿 라이트 전략을 사용하면 데이터는 실시간으로 복구될 리전(Region) 혹은 가용영역(AZ)에 복제 되지만, 복구될 리전(Region) 혹은 가용영역(AZ)은 유휴 상태로, 데이터 저장소와 데이터베이스가 최신 상태(또는 거의 최신 상태)를 유지하며 읽기 작업을 서비스할 준비가 되어 있습니다. [그림 6]에서 Amazon Aurora 글로벌 데이터베이스는 복구될 리전(Region)의 로컬 읽기 전용 클러스터에 데이터를 복제합니다. 그러나 다른 재해 복구 전략과 동일하게 백업(예: [그림 6]의 Aurora DB 클러스터 스냅샷)도 필요합니다. 데이터를 지우거나 손상시키는 재해 상황의 경우 이러한 백업을 통해 가장 최신의 정상 상태로 되돌릴수 있습니다.

파일럿 라이트 전략에서는 [그림 6]의 Elastic Load Balancing 및 Amazon EC2 Auto Scaling과 같은 기본 인프라 요소가 있습니다. 하지만 컴퓨팅과 같은 기능적 요소는 “차단”된 상태가 됩니다. 클라우드에서 Amazon EC2 인스턴스를 차단하는 가장 좋은 방법은 배포하지 않는 것입니다. [그림 6]은 배포된 인스턴스가 0개임을 보여줍니다. 이러한 인스턴스를 “동작” 시키기 위해 이전에 구축되어 모든 리전에 복사된 Amazon 머신 이미지(AMI)를 사용합니다. AMI는 동작에 필요한 운영 체제와 소프트웨어 패키지로 Amazon EC2 인스턴스를 생성합니다. 파일럿 라이트 전략은 장애 발생으로 모든 인프라를 생성 및 동작 시키기 전까지 어떤 요청도 처리할수 없습니다.

웜 스탠바이

[그림 7 : 웜 스탠바이 재해 복구 아키텍처]

파일럿 라이트 전략과 마찬가지로 웜 스탠바이 전략은 주기적인 백업 외에도 최신의 데이터를 유지합니다. 이 둘의 차이점은 인프라와 인프라에서 실행되는 코드입니다. 웜 스탠바이는 요청을 처리할 수 있는 최소의 인프라를 유지하지만, 최소한의 인프라에서 프로덕션 수준 트래픽을 처리할 수는 없습니다. 계층당 하나의 Amazon EC2 인스턴스가 생성된 [그림 7]에서 이를 확인할 수 있습니다. 이러한 구성은 파일럿 라이트 대비 복구될 리전(Region) 혹은 가용영역(AZ)을 모의 테스트하기 더 간단합니다. 장애가 발생하면 프로덕션 수준 트래픽을 처리할수 있도록 인프라를 확장한후 장애 조치(Failover)를 하여 서비스를 정상화 합니다.

다중 사이트 액티브/액티브

[그림 8 : 다중 사이트 액티브/액티브 재해 복구 아키텍처]

다중 사이트 액티브/액티브 상태에서는 둘 이상의 리전(Region) 혹은 가용영역(AZ)에서 워크로드를 나누어서 처리하고 있습니다. 장애 조치(Failover)는 요청을 서비스할 수 없는 리전(Region) 혹은 가용영역(AZ)에서 다른 곳으로 요청을 보내는 것으로 완료 됩니다. 여기서 데이터는 여러 리전(Region) 혹은 가용영역(AZ)에 걸쳐 복제되며 해당 리전에서 읽기 요청을 처리하는데 사용됩니다. 쓰기 요청의 경우 로컬 영역에 쓰기 또는 특정 리전에 쓰기를 재전송하는 등 여러 형태로 구성할수 있습니다. 이에 대한 자세한 내용은 다음 블로그 게시물을 참조하십시오. 재해 복구의 경우 항상 그렇듯이 실수로 삭제하거나 손상된 데이터를 복원해야 할 경우를 위해 백업을 생성 합니다. [그림 8]은 데이터베이스 계층으로 사용되는 Amazon DynamoDB 글로벌 테이블을 보여줍니다. 이것은 모든 리전의 테이블에 쓸 수 있고 데이터가 일반적으로 1초 이내에 다른 모든 리전으로 전파되기 때문에 다중 사이트 액티브/액티브에 매우 적합합니다.

결론

재해 상황은 워크로드의 가용성을 위협하지만, AWS 클라우드 서비스를 사용하면 이러한 위협을 완화하거나 제거할 수 있습니다. 워크로드에 대한 비즈니스 요구 사항을 먼저 이해하면 적절한 재해 복구 전략을 선택할 수 있고, 이를 토대로AWS 서비스를 사용하여 비즈니스에 필요한 RTO/RPO 목표를 달성하는 아키텍처를 설계할 수 있습니다.

추가 자료

재해 복구 시리즈의 다른 블로그 글

쿠키 기본 설정 선택

AWS 기술 블로그