Amazon Route 53 Application Recovery Controller – Zonal autoshift 통한 가용 영역 자동 이동

오늘 AWS는 Amazon Route 53 Application Recovery Controller의 새로운 기능인 Zonal autoshift(영역 자동변속)을 출시합니다. 이 기능을 사용하면 AWS에서 가용 영역에 영향을 미치는 잠재적 장애를 식별할 때 워크로드의 트래픽을 해당 가용 영역 이외의 위치로 자동으로 안전하게 전환하고 장애가 해결되면 다시 되돌릴 수 있습니다.

복원력이 뛰어난 애플리케이션을 배포할 때는 일반적으로 한 리전의 여러 가용 영역에 리소스를 배포합니다. 가용 영역은 전력, 연결, 네트워크 디바이스, 범람원이 서로 다르도록 충분한 거리(일반적으로 몇 마일)를 두고 설치된 물리적 데이터 센터로 구성되는 별개의 그룹입니다.

배포 실패, 구성 오류, 운영자 오류 등의 애플리케이션 오류로부터 보호할 수 있도록 작년에 수동 또는 프로그래밍 방식으로 영역 전환을 트리거하는 기능을 도입했습니다. 이 기능은 특정 가용 영역에서 지표가 저하된 경우 트래픽을 해당 영역에서 다른 곳으로 전환할 수 있습니다. 이를 위해 모든 새 연결을 정상 가용 영역의 인프라에만 연결하도록 로드 밸런서를 구성합니다. 따라서 장애의 근본 원인을 조사하는 동안 고객의 애플리케이션 가용성이 유지됩니다. 문제가 해결되면 영역 전환을 중지하여 트래픽이 모든 영역에 다시 분산되도록 합니다.

영역 전환은 NLB의 기본값인 영역 간 로드 밸런싱이 비활성화된 경우에만 Application Load Balancer(ALB) 또는 Network Load Balancer(NLB) 수준에서 작동합니다. 간단히 말해, 로드 밸런서는 두 가지 수준의 로드 밸런싱을 제공합니다. 첫 번째 수준은 DNS에서 구성됩니다. 로드 밸런서는 각 가용 영역에 대해 하나 이상의 IP 주소를 노출하여 영역 간 클라이언트 측 로드 밸런싱을 제공합니다. 트래픽이 가용 영역에 도달하면 로드 밸런서는 일반적으로 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스인 등록된 정상 상태의 대상으로 트래픽을 전송합니다. 기본적으로 ALB는 모든 가용 영역의 대상으로 트래픽을 전송합니다. 영역 전환이 제대로 작동하려면 영역 간 부하 분산을 비활성화하여 로드 밸런서를 구성해야 합니다.

다음 다이어그램에서 보듯이, 영역 전환이 시작되면 DNS는 모든 트래픽을 단일 가용 영역에서 다른 위치로 보냅니다.

수동 영역 전환은 사용자 측에서 발생하는 오류로부터 워크로드를 보호하는 데 도움이 됩니다. 하지만 가용 영역에서 잠재적 장애가 발생할 경우 장애를 식별하거나 감지하기 어려운 경우가 있습니다. 대부분의 경우 가용 영역별로 지표를 추적하지 않기 때문에 애플리케이션 지표를 사용하여 가용 영역에서 문제를 감지하기는 어렵습니다. 또한 서비스가 가용 영역 경계를 넘어 종속 구성 요소를 직접적으로 호출하는 경우가 많아 모든 가용 영역에서 오류가 발생합니다. 최신 마이크로서비스 아키텍처에서는 이러한 탐지 및 복구 단계를 수십 또는 수백 개의 개별 마이크로서비스에서 수행해야 하는 경우가 많으며, 이로 인해 복구에 몇 시간이 걸립니다.

고객들은 가용 영역에서 발생할 수 있는 장애를 감지하는 부담을 덜어줄 수 있는지 문의했습니다. AWS는 내부 모니터링 도구를 통해 잠재적인 문제를 고객보다 먼저 파악할 수 있기 때문입니다.

이번 출시로 이제 Zonal autoshift(영역 자동변속)을 구성하여 가용 영역의 잠재적 장애로부터 워크로드를 보호할 수 있게 되었습니다. AWS는 자체 AWS 내부 모니터링 도구 및 지표를 사용하여 네트워크 트래픽 전환을 트리거하는 시점을 결정합니다. 전환은 자동으로 시작되며 직접 호출해야 하는 API는 없습니다. 영역에서 전원 또는 네트워크 장애와 같은 잠재적 장애가 감지되면, 인프라의 NLB 또는 ALB 트래픽의 자동 전환을 자동으로 트리거하고 장애가 해결되면 트래픽을 다시 전환합니다.

당연히, 트래픽을 가용 영역 외부의 위치로 전환하는 것은 신중하게 준비해야 하는 섬세한 작업입니다. 이에 AWS는 실수로 애플리케이션 가용성이 저하되지 않도록 일련의 안전 장치를 마련했습니다.

첫째, 트래픽을 한 번에 둘 이상의 가용 영역에서 다른 곳으로 전환하지 않도록 하는 내부 제어 기능이 있습니다. 둘째, 매주 30분 동안 고객의 인프라 전환을 연습합니다. 고객은 연습을 실행하지 않으려는 시간대를 정의할 수 있습니다(예: 월요일~금요일 08:00~18:00). 셋째, 연습 실행 중에 회로 차단기 역할을 하도록 두 개의 Amazon CloudWatch 경보를 정의할 수 있습니다. 하나는 연습 실행을 아예 시작하지 못하도록 하는 경보이고 다른 하나는 연습 실행 중에 애플리케이션 상태를 모니터링하기 위한 경보입니다. 연습 실행 중에 두 경보 중 하나가 트리거되면 연습을 중지하고 모든 가용 영역으로 트래픽을 복원합니다. 연습 실행 종료 시 애플리케이션 상태 경보의 상태는 결과(성공 또는 실패)를 나타냅니다.

공동 책임 원칙에 따라, 고객에게는 두 가지 책임이 있습니다.

먼저, 고객은 모든 가용 영역에 충분한 용량을 배포하여 트래픽이 전환된 후 나머지 가용 영역에서 증가하는 트래픽을 처리할 수 있게 해야 합니다. 나머지 가용 영역에 항상 충분한 용량을 할당하고 애플리케이션 복구를 지연시키거나 가용성에 영향을 줄 수 있는 규모 조정 메커니즘에 의존하지 않는 것이 좋습니다. 영역 자동변속이 트리거되면 AWS Auto Scaling이 리소스의 규모를 조정하는 데 평소보다 시간이 더 걸릴 수 있습니다. 리소스의 규모를 사전 조정하면 가장 까다로운 애플리케이션의 복구 시간을 예측할 수 있습니다.

일반 사용자 트래픽을 처리하려면 애플리케이션에 3개의 가용 영역에 걸쳐 6개의 EC2 인스턴스(2×3개의 인스턴스)가 필요하다고 가정해보겠습니다. 영역 자동변속을 구성하기 전에, 가용 영역 하나를 사용할 수 없게 되었을 때 나머지 가용 영역에 트래픽을 처리할 용량이 충분한지 확인해야 합니다. 이 예시에서 이는 가용 영역당 인스턴스 3개를 의미합니다(트래픽이 2개의 가용 영역으로 전환될 때 부하를 처리할 2×3=6개의 인스턴스를 유지하기 위해 3개의 가용 영역에서 3×3=9개 인스턴스 확보).

실제로 높은 신뢰성이 요구되는 서비스를 운영하는 경우 고객으로 인한 부하 급증, 간헐적인 호스트 장애 등 만일의 사태에 대비하여 온라인상에서 일부 중복 용량을 확보한 상태로 운영하는 것이 일반적입니다. 이러한 방식으로 기존 이중화를 보완하면 가용 영역 문제 발생 시 신속하게 복구할 수 있을 뿐만 아니라 다른 이벤트에 대한 견고성을 높일 수 있습니다.

둘째, 선택한 리소스에 대해 영역 자동변속을 명시적으로 활성화해야 합니다. AWS는 고객이 선택한 리소스에만 영역 자동변속을 적용합니다. 영역 자동변속을 적용하면 애플리케이션에 할당된 총 용량에 영향을 미칩니다. 방금 설명했듯이, 애플리케이션에서 나머지 가용 영역에 충분한 용량을 배포하여 이에 대비해야 합니다.

물론 이 추가 용량을 모든 가용 영역에 배포하려면 비용이 듭니다. 복원력을 구현할 때는 애플리케이션 가용성과 비용을 결정하는 비즈니스상의 절충점을 찾아야 합니다. 이는 고객이 선택한 리소스에만 영역 자동변속을 적용하는 또 다른 이유입니다.

Zonal autoshift(영역 자동변속)을 구성하는 방법을 살펴보겠습니다.
영역 자동변속을 구성하는 방법을 보여드리기 위해, 이제 유명해진 TicTacToe 웹 애플리케이션을 CDK 스크립트를 사용하여 배포하겠습니다. AWS Management Console의 Route 53 Application Recovery Controller 페이지를 엽니다. 왼쪽 창에서 Zonal autoshift(영역 자동변속)을 선택합니다. 그런 다음 시작 페이지에서 Configure zonal autoshift for a resource(리소스의 영역 자동변속 구성)을 선택합니다.

데모 애플리케이션의 로드 밸런서를 선택합니다. 현재는 영역 간 로드 밸런싱이 Disabled(비활성화)된 로드 밸런서에만 영역 자동변속을 사용할 수 있다는 점을 기억하세요. 콘솔의 경고를 보면 알 수 있듯이 가용 영역 하나가 소실되더라도 애플리케이션이 계속 작동하기에 충분한 용량이 확보되어 있어야 합니다.

페이지를 아래로 스크롤하여 AWS에서 30분간 연습을 실행하지 못하게 하려는 시간과 요일을 구성합니다. 처음에는 자동변속에 익숙해질 때까지 월요일부터 금요일까지 08:00~18:00 연습을 차단합니다. 시간은 UTC로 표시되며 일광 절약 시간제에 따라 달라지지 않는다는 점에 유의하세요. UTC 시간 변환기 애플리케이션을 사용하면 도움이 됩니다. 처음에는 업무 시간을 제외하는 것이 안전하지만, 애플리케이션에 트래픽이 적거나 없을 때에는 눈에 잘 띄지 않을 수 있는 문제를 캡처할 수 있도록 업무 시간에도 연습을 실행하도록 구성하는 것이 좋습니다. 영역 자동변속의 가장 중요한 조건은 피크 타임에 영향을 미치지 않으면서 작동해야 한다는 것입니다. 하지만 테스트해보지 않는다면 어떻게 확신할 수 있을까요? 어떤 시간도 차단하지 않는 것이 가장 좋지만, 현실적으로 그렇게 하기 어렵다는 것을 잘 알고 있습니다.

같은 페이지 아래쪽에 두 가지 회로 차단기 경보를 입력합니다. 첫 번째는 연습이 시작되지 않도록 합니다. 이 경보를 사용하여 지금은 연습을 시작하기에 적절한 시간이 아니라고 알릴 수 있습니다. 예를 들어 애플리케이션에 지속적인 문제가 있거나 애플리케이션의 새 버전을 프로덕션 환경에 배포하는 경우가 이에 해당합니다. 두 번째 CloudWatch 경보는 연습 실행 결과를 제공합니다. 이를 통해 영역 자동변속의 연습 실행에 애플리케이션이 어떻게 반응하는지를 판단할 수 있습니다. 경보가 녹색으로 계속 켜져 있으면 모든 것이 정상적으로 작동했다는 의미입니다.

연습 실행 중에 이 두 경보 중 하나가 트리거되면 영역 자동변속이 연습을 중단하고 트래픽을 모든 가용 영역으로 복원합니다.

마지막으로, 30분 동안의 연습은 매주 진행되며, 애플리케이션의 가용성을 떨어뜨릴 수 있습니다.

다음으로 생성을 선택합니다.

이것으로 끝입니다.

며칠 후 콘솔의 Zonal shift history for resource(리소스의 영역 전환 기록) 탭에서 실행 기록을 확인할 수 있습니다. 두 회로 차단기 경보의 기록을 모니터링하여 모두 올바르게 모니터링 및 구성되었는지 확인합니다.

자동변속 자체를 테스트하는 것은 불가능합니다. 이 기능은 가용 영역에서 잠재적 문제가 감지되면 자동으로 트리거됩니다. 이 게시물에서 공유한 지침을 테스트하기 위해 Service 팀에 가용 영역을 종료할 수 있는지 물었지만, Service 팀은 정중하게 제 요청을 거절했습니다.

자동변속과 동일하게 작동하는 수동 전환을 트리거하여 구성을 테스트할 수 있습니다.

몇 가지 추가 유의 사항
이제 중국과 GovCloud를 제외한 모든 AWS 리전에서 추가 비용 없이 영역 자동변속을 사용할 수 있습니다.

기어가기, 걷기, 달리기 방법론을 적용하는 것이 좋습니다. 먼저 수동 영역 전환을 시작하여 애플리케이션이 제대로 작동한다는 확신을 얻어야 합니다. 그런 다음 업무 시간 외에 연습을 실행하도록 구성된 영역 자동변속을 활성화합니다. 마지막으로 업무 시간 중에 영역 전환 연습을 포함하도록 일정을 수정합니다. 가장 이벤트가 발생해서는 안 되는 시간대에 이벤트에 대한 애플리케이션 응답을 테스트하는 것이 좋습니다.

또한 트래픽을 특정 가용 영역에서 다른 곳으로 전환했다가 다시 되돌릴 때 애플리케이션의 모든 부분이 어떻게 복구될지를 전반적으로 생각해 보는 것이 좋습니다. 제가 떠올린 목록은 (완전하지는 않지만) 다음과 같습니다.

첫째, 앞서 설명한 대로 추가 용량을 계획하세요. 둘째, 단일 EC2 인스턴스에서 실행되는 자체 관리형 데이터베이스, 단일 가용 영역에 남아 있는 마이크로서비스 등, 각 가용 영역에서 발생할 수 있는 단일 장애 지점을 생각해보세요. 영역 전환이 필요한 애플리케이션에는 Amazon DynamoDB 또는 Amazon Aurora와 같은 관리형 데이터베이스를 사용하는 것이 좋습니다. 이들 데이터베이스에는 복제 및 장애 복구 메커니즘이 내장되어 있습니다. 셋째, 가용 영역을 다시 사용할 수 있게 되면 다시 전환할 계획을 세워야 합니다. 리소스를 확장하는 데 시간이 얼마나 걸리는지, 캐시를 리하이드레이션해야 되는지 등을 고려합니다.

제 동료 Adrian이 작성한 이 훌륭한 기사 시리즈를 통해 복원력 있는 아키텍처와 방법론에 대해 자세히 알아볼 수 있습니다.

마지막으로, 현재는 영역 간 로드 밸런싱이 비활성화된 로드 밸런서에만 영역 자동변속을 사용할 수 있다는 점을 기억하세요. CDK 스크립트에서 영역 간 로드 밸런싱을 비활성화하려면 대상 그룹에서 stickinessCookieDuration을 제거하고 load_balancing.cross_zone.enabled=false를 추가해야 합니다. 다음은 CDK와 Typescript를 사용한 예시입니다.

    // Add the auto scaling group as a load balancing
    // target to the listener.
    const targetGroup = listener.addTargets('MyApplicationFleet', {
      port: 8080,
      // for zonal shift, stickiness & cross-zones load balancing must be disabled
      // stickinessCookieDuration: Duration.hours(1),
      targets: [asg]
    });    
    // disable cross zone load balancing
    targetGroup.setAttribute("load_balancing.cross_zone.enabled", "false");

이제 영역 자동변속의 이점을 활용할 애플리케이션을 선택할 차례입니다. 먼저 각 가용 영역의 인프라 용량을 검토한 다음 회로 차단기 경보를 정의합니다. 모니터링이 올바르게 구성된 것을 확인한 후 Zonal autoshift(영역 자동변속)을 활성화합니다.

— seb