AWS 기술 블로그
AWS 기반 재해 복구(DR) 아키텍처, 3부: 파일럿 라이트 및 웜 스탠바이
이 글은 AWS Architecture Blog에 게시된 Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby by Seth Eliot을 한국어로 번역 및 편집하였습니다.
이 블로그 게시물에서는, 자연 재해, 기술 오류, 또는 인적 오류와 같은 재해 상황에서 워크로드를 복구할 수 있는 두 가지의 액티브/패시브 전략에 대해 알아봅니다. 이전의 블로그 게시물에서, AWS에서의 재해 복구(DR)를 위한 4가지 전략을 소개하고, 백업 및 복원 전략을 살펴 보았습니다. 이제 파일럿 라이트(Pilot Light)와 웜 스탠바이(Warm Standby) 전략에 대해 알아 보겠습니다.
재해 복구 전략: 파일럿 라이트(Pilot light) 또는 웜 스탠바이(Warm Standby)
재해복구 전략을 선택할 때는 낮은 RTO(Recovery Time Objective) 및 RPO(Recovery Point Objective)의 이점과 구축 및 운영 비용 중 어디에 중점을 둘지 고려해야 합니다. 파일럿 라이트와 웜 스탠바이 전략은 모두 그림 1과 같이 워크로드에 따라 적절한 RTO와 RPO를 선택할 수 있는 이점과 비용의 적절한 균형을 제공합니다.
[그림 1. 재해 복구 전략]
파일럿 라이트 또는 웜 스탠바이 구현
[그림 2와 3]은 각각 파일럿 라이트 및 웜 스탠바이 전략을 구현하는 방법을 보여 줍니다. 이들은 모두 액티브/패시브 전략입니다.(이전 게시물의 “액티브/패시브 및 액티브/액티브 재해 복구 전략” 섹션 참조) 왼쪽의 AWS 리전은 액티브 상태인 운영 리전이고, 오른쪽 리전은 장애 조치 전의 패시브 상태인 복구 리전입니다.
[그림 2. 파일럿 라이트 재해 복구 전략]
[그림 3.] 웜 스탠바이 재해 복구 전략
두 가지 재해 복구 전략의 유사점
두 전략 모두 운영 리전의 데이터를 복구 리전의 Amazon Relational Database Service (Amazon RDS) 인스턴스 또는 Amazon DynamoDB 테이블과 같은 데이터 리소스로 실시간 복제를 수행합니다. 이러한 데이터 리소스는 필요시에 바로 요청을 처리할 준비가 되어 있습니다. 복제 외에도, 두 전략 모두 복구 리전에서 지속적으로 백업을 생성해야 합니다. 이는 사람의 실수로 인해 재해가 발생하면, 데이터가 삭제되거나 손상되어 잘못된 데이터를 복제할 수도 있기 때문입니다. 이런 경우 백업은 가장 최근의 정상적인 상태로 복구할 수 있기 때문에 필요합니다.
워크로드의 인프라에 사용되는 리소스들은, 두 전략 모두 복구 리전에 배포가 됩니다. 여기에는 서브넷 및 라우팅이 구성된 Amazon Virtual Private Cloud(Amazon VPC), Elastic Load Balancing 및 Amazon EC2 Auto Scaling 그룹과 같은 지원 인프라가 포함됩니다. 두 전략은 모두 배포된 인프라가 운영 준비 상태가 되기 위해서는 추가 작업이 필요합니다. 하지만 두 전략의 워크로드 인프라에 대한 준비 범위는 서로 다르며, 다음 섹션에서 자세히 설명합니다.
모든 액티브/패시브 전략에서 요구되어지는 것처럼, 두 전략 모두 평소에는 요청을 운영 리전으로 전달하고, 재해가 발생하여 복구가 필요할 때에 복구 리전으로 전달하는 방법이 필요합니다.
이 두 전략의 RPO는 동일한 데이터 전략을 사용하기 때문에 유사합니다.
두 가지 재해 복구 전략의 차이점
두 전략의 주요 차이점은 인프라 배포와 준비 상태입니다. 웜 스탠바이 전략은 운영 리전처럼 작동할 수 있는 인프라를, 보다 적은 용량으로 복구 리전에 생성합니다. 복구 리전의 재해 복구용 엔드포인트는 요청을 처리할 수는 있지만, 적은 용량을 가지고 있어 운영 수준의 트래픽은 처리할 수는 없습니다. 이는 [그림 3]에서 티어당 하나의 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 생성하였습니다. 더 많은 인프라를 생성할 수 있지만, 비용 절감을 위해 항상 운영 리전보다 적게 생성 합니다. 만약 인프라가 전체 용량으로 복구 리전에 배포 된다면, 이 전략은 “핫 스탠바이”라고 합니다. 웜 스탠바이는 복구 리전에 운영 리전처럼 작동이 가능한 인프라를 생성하기 때문에, 모의 테스트를 수행하기가 더 간단합니다.
가정용 보일러의 점화용 불씨(Pilot Light, 파일럿 라이트)가 집을 따뜻하게 하지는 않습니다. 단지 보일러의 버너에 불을 붙이고 열을 공급할 수 있는 빠른 방법을 제공할 뿐입니다. 마찬가지로, 파일럿 라이트 전략(웜 스탠바이와는 달리)의 재해 복구 리전은 추가적인 단계가 수행될 때까지 요청을 처리할 수 없습니다. [그림 2]에서 EC2 Auto Scaling 그룹이 구성되어 있지만, 실제 생성된 EC2 인스턴스는 없는 상태입니다.
두 전략의 RTO는 다릅니다. 웜 스탠바이의 경우 적은 양의 워크로드는 즉시 처리할 수 있습니다. 그 후에 인프라를 확장하기 때문에, 파일럿 라이트보다 RTO 시간이 짧습니다. 파일럿 라이트는 워크로드를 처리하기 전에, 먼저 전체 인프라를 생성해야 하기 때문입니다.
파일럿 라이트 또는 웜 스탠바이로 복구
재해의 발생 후 성공적인 복구를 위해서, “재해 상황의 인지”, “복구 리전에서 인프라의 복원 및 확장”, 그리고 복구 리전으로 트래픽을 전달하기 위한 “장애 조치(failover)”의 과정이 필요합니다.
1. 감지(Detect)
이전 블로그 게시물에서 낮은 RTO를 위해 빠른 감지가 얼마나 중요한지 설명 하고, 이를 달성하기 위한 자동화된 아키텍처를 제시하였습니다. 또한 아래와 같은 지표들을 기반으로, 워크로드의 상태를 확인할 수 있는 Amazon CloudWatch의 알람을 활용합니다.
- 서버 활성 지표(예: ping)만으로 재해복구 결정을 하기에는 충분하지 않습니다.
- 서비스 API의 오류율 및 응답 시간과 같은 지표는 워크로드 상태를 이해할 수 있는 좋은 방법입니다.
- 서비스 유효성 검사 테스트는 API의 기능 및 정확성에 대한 지표를 제공합니다. Amazon CloudWatch Synthetics를 사용하면 서비스를 호출하고 응답을 검증하는 스크립트를 생성할 수 있습니다. 이를 통해 워크로드의 상태에 대한 통계적인 정보를 얻을 수 있습니다.
- 워크로드의 KPI(Key Performance Indicator, 핵심 성과 지표)는 워크로드 상태를 이해하기 위해 사용할 수 있는 최상의 지표중의 하나입니다. KPI는 워크로드가 의도한 대로 수행되어, 고객 요구 사항을 충족하는지 여부를 나타냅니다. 예를 들면 전자 상거래 워크로드는 주문 속도를 확인하는 것을 KPI로 정의 할 수 있습니다. 또한 주문율은 시간에 따라 지속적으로 변하기 때문에 CloudWatch anomaly detection를 사용하여 주문 감소가 정상이 아닌지 자동으로 감지할 수 있습니다.
2. 복원 (Restore)
클라우드에서는 리소스를 쉽게 생성하거나 삭제할 수 있기 때문에, AWS Command Line Interface(AWS CLI) 또는 AWS SDK를 사용하여 AWS Lambda 함수의 동시성, Amazon ECS(Amazon Elastic Container Service) 작업의 개수, 또는 EC2 Auto Scaling의 EC2 용량과 같은 리소스들에 대해 필요한 스케일 확장 스크립트를 만들 수 있습니다.
또한, AWS CloudFormation은 이러한 업데이트를 위한 강력한 도구입니다. CloudFormation 파라미터와 조건부 로직을 사용하여, 운영 리전과 복구 리전의 인프라를 모두 단일 템플릿으로 생성할 수 있습니다. 다음은 CloudFormation 템플릿에서 발췌한 내용입니다. ActiveOrPassive 파라미터를 통해 EC2 인스턴스를 배포하지 않거나 몇 개의 인스턴스를 배포할지 결정할 수 있습니다.(여기에서 전체 템플릿을 다운로드할 수 있습니다.)
이 예제에서는, 두 가지 옵션 중에서 선택을 하기 위해 ! If 함수를 사용하여 DesiredCapacity 값을 설정합니다. 두 개 이상의 옵션의 경우 ! FindInMap함수도 활용 할 수 있습니다.
Parameters:
Web1AutoScaleDesired:
Default: '3'
Description: The desired number of web instances in auto scaling group
# other properties omitted
Web1AutoScaleMax:
Default: '6'
Description: The maximum number of web instances in auto scaling group
# other properties omitted
ActiveOrPassive:
Default: 'active'
Description: Is this the active (primary) deployment or the passive (recovery) deployment
Type: String
AllowedValues:
- active
- passive
ConstraintDescription: enter active or passive, all lowercase
# Determine whether this is an active stack or passive stack
Conditions:
IsActive: !Equals [!Ref "ActiveOrPassive", "active"]
Resources:
#https://docs.thinkwithwp.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-group.html
WebAppAutoScalingGroup:
Type: 'AWS::AutoScaling::AutoScalingGroup'
Properties:
MinSize: !If [IsActive, !Ref Web1AutoScaleDesired, 0]
MaxSize: !Ref Web1AutoScaleMax
DesiredCapacity: !If [IsActive, !Ref Web1AutoScaleDesired, 0]
# other properties omitted[그림 4]와 같이 파라미터 값은 AWS Management Console 통해 설정할 수 있습니다. 여기서는 “passive”로 설정되며 EC2 인스턴스가 배포되지 않습니다.
[그림 4. 파라미터를 사용하여 CloudFormation 스택에 대해 ActiveOrPassive를 “passive”로 설정]
ActiveOrPassive 값을 변경할 수 있습니다. 다음 명령은, 현재 EC2 인스턴스가 없는 EC2 Auto Scaling 그룹에 3개(
Web1AutoScaleDesired의 값)의 인스턴스를 추가하도록 업데이트합니다. 새로운 템플릿을 사용하지 않고 기존 스택의 파라미터 값만
active로 업데이트를 합니다.
aws cloudformation update-stack \
--stack-name SampleWebApp --use-previous-template \
--capabilities CAPABILITY_NAMED_IAM \
--parameters ParameterKey=ActiveOrPassive,ParameterValue=active3. 장애 조치(Fail Over)
장애 조치는 운영 트래픽을 운영 리전(워크로드를 더 이상 실행할 수 없다고 판단한 리전)에서 복구 리전으로 요청을 전달하게 합니다. DNS서버를 Amazon Route 53을 사용하는 경우, 운영 리전의 엔드포인트와 복구 리전의 엔드포인트를 하나의 도메인 이름으로 설정할 수 있습니다. 그런 다음, 해당 도메인 이름에 대해서 어떤 엔드포인트가 트래픽을 수신할지 결정하는 라우팅 정책을 설정 할 수 있습니다.
장애 조치(Failover) 라우팅은 설정한 상태 검사(Health Check)에 따라, 운영 리전이 비정상인 경우 복구 리전으로 요청을 자동으로 전달합니다. 하지만 위와 같은 자동화된 장애 조치는 주의해서 사용해야 합니다. 여기에 설명된 모범 사례를 사용하더라도 복구 시간과 복구 지점은 0보다 크며, 가용성과 데이터 손실이 발생할 수 있습니다. 잘못된 경보에 의해 장애 조치가 발생하거나, 이후 원래 위치로 복원(Fall back)이 될 경우도 데이터 손실이 발생할 수 있습니다.
AWS는 자동화된 장애 조치를 보완하는 기능을 제공 합니다. 장애 조치 시점을 완전히 제어하려면 Amazon Route 53 Application Recovery Controller를 사용하여 사람이 개입하여 수동으로 진행해야 합니다. Application Recovery Controller 사용하여 실제로 상태를 확인하지 않고도, 사용자가 완전히 제어할 수 있는Route 53 상태 검사(Route 53 Health Check)를 생성할 수 있습니다. 또한 AWS CLI 또는 AWS SDK의 고가용성 API(5개 리전에서 중복 사용 가능)를 사용하여 장애 조치 스크립트를 만들 수 있습니다. 스크립트는 Route 53 상태 검사를 수행하여, 필요시 Route 53에서 운영 리전 대신 복구 리전으로 요청을 전송하도록 설정할 수 있습니다.
Route 53 및 DNS 레코드를 사용하는 대신 AWS Global Accelerator를 사용하여 장애 조치(Failover)를 구현할 수도 있습니다. 이 경우 트래픽은 200개 이상의 엣지 로케이션 중에 가장 가까운 엣지 로케이션으로 전달되어 AWS 네트워크를 통해서 엔드포인트로 이동합니다. 이때, 장애 조치를 위해 자동으로 요청을 보낼 엔드포인트의 상태를 검사하거나, 트래픽 다이얼을 사용하여 각 엔드포인트에 대한 트래픽 비율을 설정할 수 있습니다.
결론
재해 발생시 파일럿 라이트와 웜 스탠바이는 모두 데이터 손실(RPO)을 줄일 수 있는 기능을 제공합니다. 두 가지 방법 모두 가동 중지 시간을 줄일 수 있어 복구 시간 목표(RTO)를 향상 시킬 수 있습니다. 두 가지 전략 중 복구 시간 목표(RTO)를 더 줄일 수 있는 ‘웜 스탠바이’ 또는 보다 비용을 최적화하는 ‘파일럿 라이트’를 비즈니스 요건에 맞게 선택할 수 있습니다.