Amazon Route 53 애플리케이션 복구 컨트롤러 기능 정식 출시 – 높은 가용성을 위한 장애 복구 모니터링

오늘 Amazon Route 53 Application Recovery Controller를 정식 출시합니다. 본 기능은 애플리케이션의 장애 복구 기능을 지속적으로 모니터링하고, 여러 AWS 리전 및 가용 영역, 온프레미스 환경에서 애플리케이션 복구를 제어하여 매우 높은 가용성을 제공할 수 있습니다.

일부 워크로드 목표 가용성은 99.99% 이상이며, 복구 시간 목표(RTO)는 초 또는 분 단위로 측정되는 등, 고가용성 측면에서 더 높은 요구 사항을 가지고 있습니다. 실시간 결제 처리 또는 거래 엔진이 중단될 경우 전체 경제에 어떤 영향을 미칠 수 있는지 생각해 보세요. 이러한 요구 사항을 해결하기 위해 보통 다양한 AWS 가용 영역, AWS 리전 및 온프레미스 환경에 여러 개의 복제본을 배포합니다. 그런 다음 Amazon Route 53을 사용하여 최종 사용자를 적절한 복제본으로 안정적으로 라우팅합니다.

Amazon Route 53 애플리케이션 복구 컨트롤러를 사용하면 매우 높은 가용성과 낮은 RTO가 필요한 애플리케이션을 구축할 수 있도록 지원하며, 일반적으로 이는 활성/활성 아키텍처를 사용하지만 다른 유형의 중복 아키텍처 또한 Amazon Route 53 애플리케이션 복구 컨트롤러의 이점을 누릴 수 있습니다. 복구 컨트롤러는 준비 상태 확인 및 라우팅 제어의 두 부분으로 구성됩니다.

준비 상태 확인은 AWS 리소스 구성, 용량 및 네트워크 라우팅 정책을 지속적으로 모니터링하고 복구 작업 실행 기능에 영향을 줄 수 있는 변경 사항을 모니터링할 수 있습니다. 이러한 검사를 통해 복구 환경이 확장되고 필요할 때 인수하도록 구성되었는지 확인할 수 있습니다. 해당 검사는 Auto Scaling 그룹, Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스, Amazon Elastic Block Store(EBS) 볼륨, 로드 밸런서, Amazon Relational DatabaseService(RDS) 인스턴스, Amazon DynamoDB 테이블 및 기타 여러 가지 구성을 검사합니다. 예를 들어 준비 상태 확인은 장애 조치가 발생할 경우 AWS 리전에 충분한 용량을 배포할 수 있도록 AWS 서비스 한도를 확인합니다. 또한 애플리케이션 복제본의 용량 및 확장 특성이 AWS 리전 전체에서 동일한지 확인합니다.

라우팅 제어를 통해 장애 발생 시 애플리케이션 복제본 간에 트래픽을 재조정하여 애플리케이션의 가용성을 유지할 수 있습니다. 라우팅 제어는 Amazon Route 53 상태 확인과 함께 작동하며 DNS 확인을 사용해 트래픽을 애플리케이션 복제본으로 리디렉션합니다. 라우팅 제어는 다음과 같은 세 가지 방법으로 기존의 자동화된Amazon Route 53 상태 확인 기반 장애 조치를 개선합니다.

• 첫째, 라우팅 제어는 5% 증가 오류율 또는 밀리초의 지연 시간 증가와 같은 애플리케이션 지표나 부분 실패를 기반으로 전체 애플리케이션 스택을 장애 조치할 수 있는 방법을 제공합니다.
• 둘째, 라우팅 제어는 안전하고 간단한 수동 재정의를 제공합니다. 이를 사용하여 유지 관리 목적으로 트래픽을 이동하거나 모니터링에서 문제를 감지하지 못할 경우 오류를 복구할 수 있습니다.
• 셋째, 라우팅 제어는 안전 규칙이라는 기능을 사용하여 준비되지 않은 복제본으로 장애 조치나 플래핑 이슈를 방지하는 등 완전 자동화된 상태 확인과 관련된 일반적인 부작용을 방지할 수 있습니다.

Route 53 애플리케이션 복구 컨트롤러의 작동 방식을 쉽게 이해할 수 있도록 자체 고가용성 애플리케이션을 구성하는 데 사용한 과정을 안내해 드리겠습니다.

애플리케이션 복구 컨트롤러 작동 방식
본 기능의 데모를 위해 로드 밸런서, 두 개의 EC2 인스턴스가 있는 Auto Scaling 그룹, 글로벌 DynamoDB 테이블로 구성된 애플리케이션을 구축했습니다. 미국 동부(버지니아 북부)와 미국 서부(오레곤)의 두 AWS 리전에서 애플리케이션을 배포하는 CDK 스크립트를 작성했습니다. 글로벌 DynamoDB 테이블을 통해 데이터가 두 AWS 리전에 복제됩니다. 이 아키텍처는 앞에서 설명한 것처럼 활성 대기 아키텍처입니다.

이 애플리케이션은 멀티 플레이어 TicTacToe 게임으로, 일반적으로 99.99% 이상의 가용성이 필요한 애플리케이션입니다. 하나의 DNS 레코드(tictactoe.seb.go-aws.com)는 미국 동부(버지니아 북부) 리전의 로드 밸런서를 가리킵니다. 다음 다이어그램은 이 애플리케이션의 아키텍처를 보여 줍니다.

데모 애플리케이션 준비
애플리케이션에 대해 Route 53 애플리케이션 복구 컨트롤러를 구성하기 위해, 먼저 스택 간 트래픽을 장애 조치할 수 있도록 애플리케이션 스택의 독립 복제본을 배포했습니다. 이러한 복사본은 가용 영역 또는 AWS 리전과 같은 AWS 고가용성 경계 전체에 배포됩니다. 여러 AWS 리전에 애플리케이션 복제본을 배포하기로 선택했습니다.

그런 다음 이러한 독립 복제본 간에 데이터 복제를 구성했습니다. 데이터 복제를 돕기 위해 DynamoDB 글로벌 테이블을 사용합니다. 마지막으로 DNS 이름을 노출하도록 각 독립 스택을 구성했습니다. 이 DNS 이름은 리전 로드 밸런서 DNS 이름과 같은 내 애플리케이션의 진입점입니다.

용어
준비 상태 확인을 구성하기 전에 몇 가지 기본 용어를 공유해 보겠습니다.

셀이란 애플리케이션의 독립적인 장애 조치 단위를 포함하는 사일로를 정의합니다. 이는 애플리케이션이 독립적으로 작동하는 데 필요한 모든 AWS 리소스를 그룹화합니다. 데모에는 두 개의 셀이 있습니다. 즉, 애플리케이션이 배포된 AWS 리전당 하나씩 있습니다. 셀은 일반적으로 AWS 리전 또는 가용 영역과 같은 AWS 고가용성 경계와 일치하지만 더 작을 수도 있습니다. 하나의 가용 영역에 여러 셀이 있을 수 있습니다. 이는 특히 한 번에 한 셀 씩 변경 관리 관행을 따르는 경우 피해 반경을 줄이는 효과적인 방법입니다.

복구 그룹은 장애 조치 준비 상태를 확인하려는 애플리케이션 또는 애플리케이션 그룹을 나타내는 셀 모음입니다. 복구 그룹은 일반적으로 기능 측면에서 서로 미러링하는 두 개 이상의 셀로 구성됩니다.

리소스 세트는 여러 셀에 걸쳐 있을 수 있는 AWS 리소스 집합입니다. 이 데모에는 세 가지 리소스 세트가 있습니다. 하나는 us-east-1과 us-west-2에 있는 두 개의 로드 밸런서, 하나는 두 리전에 있는 두 개의 Auto Scaling 그룹에 대해, 하나는 글로벌 DynamoDB 테이블용입니다.

준비 상태 확인은 장애 조치가 완료될 AWS 리소스 집합의 준비 상태를 검증합니다. 이 예에서는 로드 밸런서, Auto Scaling 그룹 및 DynamoDB 테이블에 대한 준비 상태를 감사하려고 합니다. Auto Scaling 그룹에 대한 준비 상태 확인을 생성합니다. 이 서비스는 그룹의 인스턴스 유형과 카운트를 지속적으로 모니터링하여 각 그룹이 균등하게 조정되었는지 확인합니다. 로드 밸런서와 글로벌 DynamoDB 테이블에 대해 이 과정을 반복합니다.

내 애플리케이션에 대한 복구 준비 상태를 파악하기 위해 Route 53 애플리케이션 복구 컨트롤러는 애플리케이션 셀(가용 영역 또는 리전) 간의 용량 불일치, AWS 리소스 제한 및 AWS 스로틀 제한을 지속적으로 감사합니다.  Route 53 애플리케이션 복구 컨트롤러가 제한에서 불일치를 감지하면 셀 전체에서 리소스에 대한 AWS 서비스 할당량 요청이 발생합니다. Route 53 애플리케이션 복구 컨트롤러가 리소스에서 용량 불일치를 감지하면 셀 간에 용량을 정렬하는 작업을 수행할 수 있습니다. 예를 들어 Auto Scaling 그룹에 대한 확장 증가를 트리거할 수 있습니다.

준비 상태 확인 생성
준비 상태 확인을 생성하려면 AWS 관리 콘솔을 열고 Route 53에서 애플리케이션 복구 컨트롤러 섹션으로 이동합니다.

내 애플리케이션에 대한 복구 그룹을 생성하려면 시작하기 섹션으로 이동한 다음 복구 그룹 생성을 선택합니다.

이름(예: AWSNewsBlogDemo)을 입력한 후 다음을 선택합니다.

아키텍처 구성에서 셀 추가를 선택한 다음 셀 이름(AWSNewsBlogDemo-RegionWEST)을 입력하고 셀 추가를 다시 선택하여 두 번째 셀을 추가합니다. 두 번째 셀에 대해 AWSNewsBlogDemo-RegionEAST를 입력합니다. 다음을 선택하여 입력 내용을 검토한 다음 복구 그룹 생성을 선택합니다.

이제 로드 밸런서, Auto Scaling 그룹 및 DynamoDB 테이블과 같은 리소스를 복구 그룹과 연결해야 합니다.

왼쪽 탐색 창에서 리소스 세트를 선택한 다음 생성을 선택합니다.

첫 번째 리소스 세트의 이름을 입력합니다(예: load_balancers). 리소스 유형의 경우 네트워크 로드 밸런서 또는 애플리케이션 로드 밸런서를 선택한 다음 추가를 선택하여 로드 밸런서 ARN을 추가합니다.

추가를 다시 선택하여 두 번째 로드 밸런서 ARN을 입력한 다음리소스 세트 생성을 선택합니다.

이 과정을 반복하여 두 개의 Auto Scaling 그룹에 대한 하나의 리소스 세트와 글로벌 DynamoDB 테이블(ARN 하나)에 대한 세 번째 리소스 세트를 생성합니다. 이제 세 가지 리소스 세트가 있습니다.

마지막 단계는 준비 상태 확인을 생성하는 것입니다. 이렇게 하면 리소스가 리소스 그룹의 셀과 연결됩니다.

준비 상태 확인에서 화면 오른쪽 상단에 있는 생성을 선택한 다음 준비 상태 확인을 선택합니다.

1단계(준비 상태 확인 생성), 이름(예: load_balancers)을 입력합니다. 리소스 유형에서 네트워크 로드 밸런서 또는 애플리케이션 로드 밸런서를 선택한 후 다음을 선택합니다.

2단계(리소스 세트 추가), 기본 선택을 유지합니다. 기존 리소스 세트를 사용하고 리소스 세트 이름에 대해 load_balancers를 선택한 후 다음을 선택합니다.

3단계(준비 규칙 적용), 규칙을 검토한 후 다음을 선택합니다.

4단계(복구 그룹 옵션), 기존 복구 그룹과 연결 기본 선택을 유지합니다. 복구 그룹 이름에 대해 AWSNewsBlog를 선택합니다. 그런 다음 두 셀(EAST 및 WEST)을 두 개의 로드 밸런서 ARN과 연결합니다. 각 셀에 올바른 로드 밸런서를 연결해야 합니다. 리전 이름은 ARN에 포함됩니다.

5단계(검토 및 생성)에서 선택 사항을 검토한 다음 준비 상태 확인 생성을 선택합니다.

Auto Scaling 그룹과 DynamoDB 글로벌 테이블에 대해 이 과정을 반복합니다.

그룹의 모든 준비 상태 확인이 녹색이면 그룹의 상태가 준비 상태가 됩니다.

이제 라우팅 제어를 구성하고 테스트할 수 있습니다.

용어
라우팅 제어를 구성하기 전에 몇 가지 기본 용어를 공유해 보겠습니다.

클러스터는 API 호출을 실행하여 라우팅 제어의 상태를 업데이트하거나 가져올 수 있는 5개의 중복 리전 엔드포인트 집합입니다. 하나의 클러스터에 여러 컨트롤 패널 및 라우팅 제어를 호스팅할 수 있습니다.

라우팅 제어는 클러스터에서 호스팅되는 간단한 켜기/끄기 스위치로, 셀 안팎의 클라이언트 트래픽 라우팅을 제어하는 데 사용합니다. 라우팅 제어를 생성할 때 Route 53 애플리케이션 복구 컨트롤러에서 라우팅 제어를 업데이트할 경우 트래픽을 다시 라우팅할 수 있도록 Route 53에 상태 확인을 추가합니다. 라우팅 제어를 사용하여 트래픽을 라우팅하는 데 사용할 경우 상태 확인은 각 애플리케이션 복제본 앞에 있는 DNS 장애 조치 레코드와 연결되어야 합니다.

제어판에서 관련 라우팅 제어 세트를 함께 그룹화합니다.

라우팅 제어 구성
Route 53 콘솔 또는 API 작업을 사용하여 내 애플리케이션의 각 AWS 리전에 대한 라우팅 제어를 생성할 수 있습니다. 라우팅 제어를 생성한 후 각각에 대해 Amazon Route 53 애플리케이션 복구 컨트롤러 상태 확인을 생성한 다음 각 상태 확인을 각 리전의 로드 밸런서에 대한 DNS 장애 조치 레코드와 연결합니다. 그런 다음 리전 간의 트래픽을 장애 조치하려면 한 라우팅 제어에 대한 라우팅 제어 상태를 끄고 다른 라우팅 제어 상태를 on으로 변경합니다.

첫 번째 단계는 클러스터를 생성하는 것입니다. 클러스터에는 시간당 2.5 USD가 부과됩니다. Route 53 애플리케이션 복구 컨트롤러를 경험할 클러스터를 생성한다면 실험 후에 클러스터를 삭제해야 합니다.

왼쪽 탐색 창에서 클러스터 패널로 이동한 다음 생성을 선택합니다.

클러스터 이름을 입력한 다음 클러스터 생성을 선택합니다.

클러스터가 몇 분 동안 보류 중 상태입니다. 잠시 후 상태가 배포됨으로 변경됩니다.

배포된 후에는 클러스터 이름을 선택하여 5개의 중복 API 엔드포인트를 검색합니다. 라우팅 제어 상태를 검색하거나 설정하려면 복구 도구를 빌드할 때 이러한 엔드포인트 중 하나를 지정해야 합니다. 클러스터 엔드포인트를 사용할 수 있지만 복잡하거나 자동화된 시나리오에서는 각 재시도 요청마다 다른 엔드포인트를 사용하여 사용 가능한 각 엔드포인트로 다시 시도할 수 있도록 시스템을 준비하는 것이 좋습니다.

트래픽 라우팅은 제어판에 그룹화된 라우팅 제어를 통해 관리됩니다. 하나를 생성하거나 직접 생성한 기본 항목을 사용할 수 있습니다.

기본 제어판을 선택합니다.

라우팅 제어 추가를 선택합니다.

라우팅 제어의 이름(FailToWEST)을 입력한 다음 라우팅 제어 생성을 선택합니다. 두 번째 라우팅 제어(FailToEAST)에 대해 작업을 반복합니다.

라우팅 제어가 생성된 후 목록에서 선택합니다. 세부 정보 페이지에서 상태 확인 생성을 선택하여 Route 53에서 상태 확인을 생성합니다.

상태 확인의 이름을 입력한 다음 생성을 선택합니다. Route 53 콘솔로 이동하여 상태 확인이 올바르게 생성되었는지 확인합니다.

각 라우팅 제어에 대해 하나의 상태 확인을 생성합니다.

제어판에서 안전 규칙을 추가할 수 있는 장소를 제공한다는 것을 알았을 것입니다. 여러 라우팅 제어를 동시에 사용하는 경우, 이를 활성화하거나 비활성화할 때 일부 안전 조치가 필요할 수 있습니다. 이를 통해 복제본이 준비되지 않은 경우 장애 조치가 시작되거나 라우팅 제어를 모두 끄고 모든 트래픽 흐름을 중지하는 등의 의도하지 않은 결과를 방지할 수 있습니다. 이러한 안전 장치를 생성하려면 안전 규칙을 작성해야 합니다. 사용 예를 포함하여 안전 규칙에 대한 자세한 내용은 Route 53 애플리케이션 복구 컨트롤러 개발자 안내서를 참조하세요.

이제 라우팅 제어와 DNS 상태 확인이 이루어집니다. 마지막 단계는 트래픽을 내 애플리케이션으로 라우팅하는 것입니다.

DNS 설정 조정
트래픽을 내 애플리케이션으로 라우팅합니다. 셀에서 애플리케이션의 최상위 엔트리 포인트에 DNS 별칭을 할당합니다. 이 예에서는 Route 53 콘솔을 사용하여 장애 조치 유형의 두 개의 ALIAS A 레코드를 생성하고 각 상태 확인을 각 DNS 레코드와 연결합니다. 두 레코드의 레코드 이름은 같습니다. 하나는 기본 레코드이고 다른 하나는 보조 레코드입니다. Amazon Route 53 상태 확인에 대한 자세한 내용은 Amazon Route 53 개발자 안내서를 참조하세요.

애플리케이션 복구 라우팅 제어 페이지에서 두 라우팅 제어 중 하나를 활성화합니다.

곧바로 tictactoe.seb.go-aws.com을 가리키는 모든 트래픽은 us-east-1에 배포된 인프라로 이동합니다.

설정 테스트
내 설정을 테스트하려면 먼저 터미널에서 dig 명령을 사용합니다. us-east-1에 배포된 로드 밸런서를 가리키는 DNS CNAME 레코드를 보여줍니다.

또한 웹 브라우저로 애플리케이션을 테스트합니다. tictactoe.seb.go-aws.com 이름이 us-east-1으로 가는 것을 확인했습니다.

이제 update-routing-control-state API 작업, CLI 또는 콘솔을 사용하여 us-east-1 지역에 대한 라우팅 제어를 끄고 us-west-2 리전으로 설정합니다. CLI를 사용할 때 클러스터에서 제공하는 엔드포인트를 사용합니다.

aws route53-recovery-cluster update-routing-control-state \
     --routing-control-arn arn:aws:route53-recovery-control::012345678:controlpanel/xxx/routingcontrol/abcd \
     --routing-control-state On \
     --region us-west-2 \
     --endpoint-url https://host-xxx.us-west-2.cluster.routing-control.amazonaws.com/v1

콘솔에서 제어판으로 이동하여 변경할 라우팅 제어를 선택하고 라우팅 제어 상태 변경을 클릭합니다.

1분 이내에 DNS 주소가 업데이트됩니다. 이제 애플리케이션 트래픽이 us-west-2 리전으로 라우팅됩니다.

준비 상태 확인 및 라우팅 제어는 애플리케이션 트래픽에 대해 제어된 장애 조치를 제공하여 내 활성 복제본에서 다른 AWS 리전의 대기 복제본으로 트래픽을 리디렉션합니다. 데모에서 보여 주듯이 트래픽 라우팅을 수동으로 변경하거나 애플리케이션의 기술 및 비즈니스 지표를 기반으로 Amazon CloudWatch 경보를 사용하여 자동화할 수 있습니다.

요금
이 새로운 기능은 온디맨드 방식으로 청구됩니다. 선결제 비용은 없습니다. 준비 상태 확인당 및 시간당 클러스터당 요금이 부과됩니다. 준비 확인에는 시간당 0.045 USD가 부과됩니다. 클러스터에는 시간당 2.5 USD가 부과됩니다. 이 블로그 게시물에 사용되는 데모 예시에는 세 가지 준비 상태 확인과 하나의 클러스터가 있습니다. 애플리케이션 자체를 제외한 이 설정의 시간당 가격은 3×0.045 USD + 1×2.5 USD=시간당 2.635 USD입니다. 예를 포함하여 요금에 대한 자세한 내용은 Route 53 요금 페이지를 참조하세요.

이 새로운 기능은 퍼블릭 상용 AWS 리전에서 실행되는 애플리케이션의 애플리케이션 복구를 모니터링하고 제어하는 데 사용할 수 있는 글로벌 서비스입니다. 사용해보시고 여러분의 의견을 알려주세요. 늘 그렇듯이 일반적인 AWS Support 연락처를 통해 피드백을 보내거나 AWS 포럼에 게시할 수 있습니다.

— seb