AWS 기반 재해 복구(DR) 아키텍처, 2부: 신속한 복구를 위한 백업 및 복원

이 글은 AWS Architecture Blog에 게시된 Disaster Recovery (DR) Architecture on AWS, Part II: Backup and Restore with Rapid Recovery by Seth Eliot 을 한국어로 번역 및 편집하였습니다.

이전 1부 게시글에서는 네 가지의 AWS 기반 재해 복구(DR) 전략에 대해서 알아 보았습니다. 재해 복구 전략은 비지니스에 영향을 주는 시스템의 장애 상황을 미리 준비하여 복구 할 수 있는 방법을 제시 하고 있습니다. AWS의 모범사례를 기반으로 한 아키텍처를 활용하여 자연적 재해, 기술적 결함, 인적 오류 상황으로부터 워크로드를 항상 가용한 상태로 유지 하십시오.

재해 복구(DR) 전략 : 신속한 복구를 위한 백업 및 복원

아래의 [그림 1] 과 같이, 백업 및 복원 방법은, 다른 방법 대비 높은 RTO (Recovery Time Objective) 와 RPO (Recovery Point Objective)를 가지고 있습니다. 이런 이유로 재해 발생시 보다 긴 복구 시간과 많은 데이터 유실이 있을 수 있습니다. 하지만 백업 및 복원은 가장 적용하기 쉽고 저렴한 방법으로 많은 워크로드에서 사용하고 있습니다. 보통 많은 시스템이 수 분 이내의 아주 작은 RTO (Recovery Time Objective) 와 RPO (Recovery Point Objective)를 필요로 하지 않습니다.

[그림 1 : 재해 복구(DR) 전략]

백업 및 복원 방법의 구현

[그림2] 에서 시스템은 아래의 AWS 자원을 사용하고 있습니다 :

Amazon Elastic Block Store (Amazon EBS): EBS 볼륨
Amazon Elastic Compute Cloud (Amazon EC2): EC2 인스턴스
Amazon Relational Database Service (Amazon RDS): DB 인스턴스
Amazon Elastic File System (Amazon EFS)

AWS Backup 서비스는 백업 및 복구 방법을 설정하고 스케줄링과 모니터링을 한번에 할 수 있는 중앙 집중적인 관리 기능을 제공 합니다. 시스템의 RPO (Recovery Point Object) 는 얼마나 자주 백업을 하는지에 의하여 결정 됩니다.

[그림 2 : 백업 및 복구 방법]

하나의 AWS 리전 안에서 백업

모든 AWS 리전(Region)은 여러 개의 가용 영역(AZ)으로 구성되어 있습니다. 여러 개의 가용영역(AZ)에 복제본을 생성하는 전략(Multi-AZ)은 높은 가용성(HA)를 제공 합니다.

여러 개의 가용영역(AZ)에 복제본을 생성하는 아키텍처는 단일 리전(Region) 에서 시스템이 필요한 재해 복구 전략이 될 수 있습니다. 하지만 인적 오류와 소프트웨어 결함을 포함한 재해에는 비지니스에 필수적인 데이터를 변형 시킬 수 있고, 변형된 데이터를 다른 가용 영역(AZ)에 복제 할 수 있습니다. 이런 이유로 재해 복구를 위해 추가적인 백업을 생성해야 합니다. [그림 2] 특정시점복구(Point-in-time recovery)가 가능한 백업(point-in-time recovery for Amazon DynamoDB, restoring a DB instance to a specified time for RDS) 과 버전관리(Versioning) 기능(Amazon Simple Storage Service – Amazon S3)은 변형되지 않은 최신의 데이터로 시스템을 복구 시킬 수 있습니다.

여러 AWS 리전을 활용한 백업

AWS Backup 은 중앙 집중적인 관리 기능을 제공할 뿐만 아니라, [그림 2] 와 같이 여러 리전(Region)에 백업의 복제본을 생성 할 수 있습니다. 여러 리전(Region)에 백업 데이터를 복제하여, 특정 리전(Region) 전체의 장애와 같은 상황도 대비 할 수 있습니다. [그림 3] 과 같이 장애가 발생한 리전(Region)과 다른 리전(Region)의 백업 복제본을 이용하여, 시스템을 복구하고 운영 할 수 있습니다.

여러 AWS 리전을 활용한 백업 방법에서는 원본 리전(Region)과 백업 리전(Region)은 서로 다른 계정 (AWS Account) 을 사용하는 것을 권장 합니다. 이렇게 하는 이유는 인적 오류나 장애가 발생한 리전(Region)의 특정 리소스가 백업 리전(Region)에 영향을 주는 것을 최소화 하기 위해서 입니다.

[그림 3 : 여러 리전을 활용한 장애 복구 전략]

백업 및 복원 전략의 활용 방법

장애가 발생 하였을 때, 아래의 세 단계로 재해복구를 진행 할 수 있습니다.

1. 1. 시스템에 장애가 발생 하였을 때 이를 감지 하고, 영향이 얼마나 될지 검토 합니다.
  2. 시스템이 다시 동작할 수 있도록 인프라와 데이터를 복구 합니다.
  3. 복구된 인프라로 요청이 전달될 수 있도록 장애 조치(Failover)를 하여 워크로드가 다시 정상적으로 처리되게 합니다.

1. 장애 발생의 감지 및 검토

RTO(Recovery Time Objective)는 일반적으로 시스템을 복구하고 장애 조치(Failover)를 하여, 다시 동작 되게 하는데 소요되는 시간을 의미 합니다. 하지만 [그림 4] 와 같이 장애를 감지하고, 복구에 필요한 의사 결정을 하는 추가적인 시간도 포함하고 있습니다.

[그림 4 : 장애발생시 복구시간에 영향을 주는 요인]

복구시간을 줄이기 위해서는 장애를 감지하는 방법이 자동화 되어야 합니다. 운영자가 문제를 인식하고 알려줄 것을 기대하거나, 고객이 문제를 알아차릴 때 까지 장애를 인식하지 못하면 안됩니다.

[그림 5] 는 시스템의 가용성을 자동으로 탐지해서 이벤트를 전달하는 아키텍처 입니다.

[그림 5 : Amazon EventBridge를 활용한 장애 탐지 및 상황 알림]

Amazon EventBridge 는 여러 AWS 서비스로 부터 이벤트를 받아서 적절한 행동을 취하게 할 수 있습니다. [그림 5] 에서는 두 개의 AWS 서비스로 부터 이벤트를 받고 있습니다.

사용자가 직접 정의 할 수 있는 Amazon CloudWatch 의 메트릭 기반의 알람 기능인 CloudWatch Alarms 이 Aamzon EventBridge에 이벤트를 전달 합니다. 이방법은 다양한 메트릭 으로부터 특정 조건이 되는 것을 감지하여 시스템 동작을 모니터링 하게 되어 아주 세부적인 시스템의 상태 파악이 가능합니다. 또한 CloudWatch Anomaly Detection 기능을 활용하여 워크로드 핵심 지표가 비정상적인 동작을 자동으로 탐지 할 수 있습니다.
AWS Health Dashboard 는 워크로드에 영향을 주는 여러 이벤트를 보여 줍니다. 또한 Amazon EventBridges 를 통하여 이벤트를 모니터링 할 수 있고, 특정 상황에 적절히 대응할 수 있습니다. 다음의 예제는 Amazon EventBridge 를 사용하여 Amazon S3 의 PUT/GET 요청의 에러를 비율기준으로 대응하는 방법을 예시 합니다.

{
  "source": ["aws.health"],
  "detail-type": ["AWS Health Event"],
  "detail": {
    "service": ["S3"],
    "eventTypeCategory": ["issue"],
    "eventTypeCode": ["AWS_S3_INCREASED_GET_API_ERROR_RATES", "AWS_S3_INCREASED_PUT_API_ERROR_RATES"]
  }
}

[그림 5] 는 이벤트에 대응하여 취할 수 있는 여러 행동들을 보여주고 있습니다. AWS Systems Manager의 OpsItem 을 생성하거나, 운영자와 개발자에게 Amazon Simple Notification Service (Amazon SNS)를 이용하여 이메일이나 문자 메시지를 전달 할 수 있습니다. 또한 AWS Lambda를 이용하여 대응하는 코드를 실행하거나, AWS Systems Manager 의 runbooks 을 실행하여 EC2 인스턴스를 시작하거나 AWS CloudFormation 의 스텍을 생성 할 수 있습니다.

2. 시스템 복구

생성된 백업으로 EBS 볼륨, RDS DB 인스턴스, DynamoDB 테이블을 복구 할 수 있습니다. [그림 6] 은 AWS Backup을 이용하여 복구 리전(Region)에 EBS 볼륨을 복구하거나, AWS CloudFormation을 이용하여 EC2 인스턴스, VPC, Subnet, Security Group 의 복구에 필요한 인프라를 새로 생성하는 예제 입니다.

리전(Region)에 인프라를 복구하기 위해서는 인프라를 코드로(Infrastructure as code) 만들어야 합니다. AWS CloudFormation이나 AWS Cloud Development Kit (AWS CDK)를 이용하여 인프라를 코드화 시켜, 여러 리전(Region)에 동일한 인프라를 만들 수 있습니다. 추가적으로 EC2 인스턴스를 생성하기 위해서는 OS 와 필요한 소프트웨어를 패키지로 만든Amazon Machine Images (AMIs) 가 필요합니다. 보통 이런 AMIs 중에 워크로드 처리에 필요한 최소한의 것을 포함하고 있는 것을 “Golden AMIs”라고 명칭 하며, 복구 리전(Region)에 복사해 놓는 것을 권장 드립니다.

[그림 6 : 백업으로 데이터 복구 / 인프라 복구]

또한 많은 경우 생성한 인프라를 백업된 데이터와 연결해야 하는 경우가 있습니다. [그림 6] 은 EBS볼륨을 백업으로부터 복구하는 예제를 보여주고, [그림 7] 은 생성된 EC2 인스턴스에 EBS 볼륨을 자동으로 연결하는 예제를 보여 주고 있습니다.

[그림 7 : 백업으로 복구된 데이터를 자동으로 생성된 인프라와 연결]

EventBridge는 서버관리가 필요 없는 서버리스(Serverless) 형태의 서비스 입니다. AWS Backup은 데이터를 복구한 후에 이벤트를 전달할 수 있으며, [그림 7] 에서는 이를 활용하여 두가지 행동을 정의하였습니다 : 3A) AWS System Manager의 OpsCenter에 히스토리를 남기고, 3B) Lambda를 호출합니다. 호출된 Lambda 는 원본 리전(Region)의 태그 정보를 얻어와 복구 리전(Region)에 새로 생성된 EBS 볼륨에 설정을 합니다. Cloud Formation 은 인프라 자원 생성 완료 후에, 다른 Lambda를 호출하여 EBS 볼륨과 EC2 인스턴스를 연결하고 있습니다.

또한 Lambda를 사용하지 않고 System Manager의 runbook 을 실행시켜 Amazon EFS나 Amazon FSx 파일 시스템을 하나 이상의 EC2 인스턴스에 연결할 수 있습니다.

보다 복잡한 복구단계를 자동화 하기위해 AWS Step Functions 을 사용 할 수 있습니다. AWS Step Functions 은 Cloud Formation의 인프라 생성, AWS Backup 의 스토리지 복구와 여러 자원을 연결시키는 복잡한 업무처리를 상태 머신형태로 구현하여 세부 단계를 모니터링하고 관리할 수 있습니다.

3. 장애 조치(Failover)

장애 조치(Failover)를 수행하여 정상 상태로 다시 시스템을 동작시키는 것은, 다른 리전(Region) 혹은 다른 가용 영역(AZ)의 새로 생성된 인프라로 요청이 전달되게 하는 것 입니다. 이 부분은 향후 Blog Post에서 계속 다룰 예정입니다.

결론

비즈니스에 필요한 재해 복구 요구사항에 따라서, 엔지니어팀과 비지니스팀은 재해 복구 목표를 구현하기 위해 서로 협력해야 합니다. 그리고 자동화된 재해 복구 방법을 이용하여, RTO(Recovery Time Objective) – 유휴시간(Downtime) 을 최소화 하여야 합니다. 백업 및 복원 전략은 네 가지 전략 중 가장 적은 비용이 소모되어, 현대의 많은 워크로드에 이용되는 전략입니다.

AWS 기술 블로그

AWS 기반 재해 복구(DR) 아키텍처, 2부: 신속한 복구를 위한 백업 및 복원

재해 복구(DR) 전략 : 신속한 복구를 위한 백업 및 복원

백업 및 복원 방법의 구현

하나의 AWS 리전 안에서 백업

여러 AWS 리전을 활용한 백업

백업 및 복원 전략의 활용 방법

1. 장애 발생의 감지 및 검토

2. 시스템 복구

3. 장애 조치(Failover)

결론

추가 자료

연재 문서

관련 정보

주요 링크 모음

팔로우하기