Amazon CloudFront 및 Route53 하이브리드 오리진 장애 조치를 통해 웹 애플리케이션 가용성 향상시키기

이 글은 AWS Networking & Content Delivery Blog에 게시된 Improve web application availability with CloudFront and Route53 hybrid origin failover by Chakib Sahraoui and Abhinav Bannerjee을 한국어 번역 및 편집하였습니다.

올해 초, 우리는 Amazon CloudFront와 Amazon Route 53을 활용한 고가용성 애플리케이션을 구현하기 위한 세 가지 고급 설계 패턴에 관한 지침을 발표했습니다. 이 블로그에서는 웹 애플리케이션 가용성을 더욱 향상시키기 위한 접근 방식으로 CloudFront 오리진 장애 조치, Amazon Route 53 DNS 장애 조치 그리고 하이브리드 오리진 장애 조치에 대해 자세히 살펴봅니다. 또한 이 글에서 소개하는 고가용성 패턴들을 테스트할 수 있는 환경으로 AWS Cloud Development Kit (CDK) 으로 구현한 솔루션을 제공합니다.

CloudFront 오리진 장애 조치

CloudFront를 사용하면 고객이 오리진 그룹 내에서 기본(Primary) 및 보조(Secondary) 오리진을 구성하고 장애 조치를 트리거하는 HTTP 오류 코드를 지정할 수 있습니다. CloudFront는 기본 오리진으로부터 HTTP 오류 코드를 응답으로 수신하면 (예: server error 또는 server unreachable), 기본 오리진의 요청을 보조 오리진에 보냅니다.

그림 1. 이 다이어그램은 CloudFront 오리진 장애 조치가 어떻게 작동하는지 보여줍니다.

CloudFront에서 장애 조치는 스테이트리스(Stateless) 합니다. 즉, CloudFront는 오리진의 상태를 추적하지 않습니다. 모든 요청은 처음에는 기본 오리진으로 전달 됩니다. 제한 시간안에 오리진이 응답하지 않거나 장애 조치를 위해 구성된 HTTP 상태 코드를 반환해야 CloudFront가 오리진 그룹의 보조 오리진에 요청을 전달합니다. 결과적으로 즉시 장애 조치가 이루어지지만, 지연이 발생합니다. 참고. CloudFront 캐시 동작(Behavior)을 구성할 때 허용되는 HTTP 메서드를 설정할 수 있지만, 뷰어의 요청 HTTP 메서드가 GET, HEAD, 또는 OPTIONS인 경우에만 보조 오리진으로 장애 조치 된다는 점을 유의하십시오.

Route 53 DNS 장애 조치

또는 Route 53 상태확인(Health Check) 과 함께 Route 53 장애 조치 라우팅 정책을 활용하여 스테이트풀(Stateful)한 오리진 장애 조치 메커니즘을 구현할 수 있습니다. 이 시나리오에서 Route 53은 기본 오리진의 상태확인 결과가 정상(Healthy)으로 감지되면 오리진 도메인 이름의 DNS 쿼리 응답으로 기본 오리진의 IP 주소값을 반환합니다. 만약, 기본 오리진의 상태가 비정상(Unhealthy)이 되고 보조 오리진의 상태가 정상이면, Route 53 는 자동으로 DNS 질의 응답 결과로 보조 오리진의 IP 주소값을 반환합니다. 참고. 기본 오리진과 보조 오리진 모두 상태확인 결과가 정상이 아닌 경우 기본 오리진의 IP 주소값을 반환한다는 점을 유의하십시오.

그림 2. 이 다이어그램은 CloudFront(기본 오리진의 상태가 정상)와 함께 Route 53 DNS 장애 조치를 사용할 수 있는 방법을 보여줍니다.

그림 3. 이 다이어그램은 CloudFront(기본 오리진의 상태가 비정상)와 함께 Route 53 DNS 장애 조치를 사용할 수 있는 방법을 보여줍니다.

장애 조치 지연은 상태 확인 간격(Request Interval)과 실패 임계값(Failure threshold)에 따라 달라집니다. 비정상 상태로 전이되는 동안에는 서비스 및 애플리케이션 사용이 불가할 수 있습니다. 실퍠 임계값 및 상태 확인 간격은 상태확인 설정에서 조정할 수 있으며, 애플리케이션 요구사항에 따라 구성해야 합니다.

요약하면 CloudFront 오리진 장애 조치는 오리진에서 장애가 감지되면 바로 장애 조치가 이루어집니다. 하지만, 모든 요청을 기본 오리진에 전달하기 때문에 지연 시간이 발생할 수 있습니다.

Route53 DNS 장애 조치는 더 높은 안정성을 제공하지만 오리진에서 장애를 감지하는데 더 많은 시간이 필요합니다. 그러나 CloudFront 와 Route 53 두 서비스 모두 활용하여 성능에 영향을 주지 않고 가용성을 높일 수 있습니다.

CloudFront 및 Route 53 하이브리드 장애 조치로 가용성 개선

다음 솔루션에서는 Route 53 에서 단일 도메인 이름으로 기본 오리진 및 보조 오리진 모두 포함되도록 장애 조치 정책(Failover Policy)을 구성합니다. 다음으로 이전에 생성한 도메인 이름을 기본 오리진의 도메인 이름으로, 백업 엔드포인트를 보조 오리진의 도메인 이름으로 CloudFront 오리진 그룹을 설정합니다.

이 설정의 장점은 Route 53가 장애를 감지하고 장애 조치를 하는데 필요한 몇 분 동안 CloudFront의 오리진 장애 조치 기능으로 즉시 보조 오리진에 요청을 재시도하여 애플리케이션 가용성을 높일 수 있다는 것입니다. 참고. 앞서 설명한 것처럼 이 접근 방식은 GET, HEAD, 또는 OPTIONS HTTP 메서드에서만 작동합니다.

그림 4.이 다이어그램은 CloudFront 오리진 장애 조치와 Route 53 장애 조치가 함께 작동하는 방식을 보여줍니다.

이 솔루션은 다음 순서에 따라 구현됩니다.

기본 리전과 백업 리전에서 Amazon API Gateway와 AWS Lambda를 사용하여 API 엔드포인트를 생성합니다. (사용자 지정 도메인 이름+인증서 사용)
기본 및 보조 API 엔드포인트의 Route 53 상태확인(Health check)을 생성합니다.
기본 및 보조 API 엔드포인트에 대해 별칭(Alias)으로 Route 53 DNS 레코드를 생성합니다.
다음 설정으로 CloudFront 배포(Distribution)를 두 개 생성합니다.
- 설정 1: 오리진의 도메인 이름으로 Route 53 장애 조치 DNS 레코드를 사용하는 CloudFront 배포(Distribution)을 생성합니다.
- 설정 2: Origin 장애 조치 그룹으로 구성합니다. 기본 오리진의 도메인 이름으로 Route 53 장애 조치 DNS 레코드를 사용하고, 보조 오리진의 도메인 이름으로 API 게이트웨이 도메인 이름을 사용하는 CloudFront 배포(Distribution)을 생성합니다.
Route 53 DNS 장애 조치 솔루션과 CloudFront 및 Route 53 하이브리드 장애 조치 솔루션 모두 테스트할 수 있는 CloudFront 배포의 도메인 이름을 내보냅니다.

사전 준비사항

실습 진행을 위해 필요한 사항은 다음과 같습니다.

AWS Account
Amazon Route 53에서 호스팅되는 공인 도메인
Amazon Route 53에서 오리진 레코드 및 상태 확인을 생성할 수 있는 권한
서로 다른 두 리전에서 AWS Identity and Access Management (IAM) 역할, AWS Certificate Manager (ACM) 공인 인증서, CloudFront 배포, API 게이트웨이 구성 그리고 Lambda 함수를 생성하거나 업데이트할 수 있는 권한
npm install -g aws-cdk 명령어로 AWS CDK Toolkit 설치

솔루션 배포

솔루션 배포에는 약 10분이 소요됩니다.

먼저 GitHub repository 에서 CDK 템플릿을 다운로드합니다.

git clone https://github.com/aws-samples/cloudfront-hybrid-origin-failover.git
cd cloudfront-hybrid-origin-failover

CDK 및 필수 의존성 패키지를 설치합니다.

npm install -g aws-cdk
npm install

기본 및 대체 리전에 스택을 배포합니다.

./deployment/deploy.sh AWS_REGION AWS_BACKUP_REGION DOMAIN_NAME HOSTED_ZONE_ID

다음 필수 인자(Argument) 에 값을 입력합니다.

AWS_REGION : 기본 리전을 입력하세요.
AWS_BACKUP_REGION : 대체 리전을 입력하세요.
DOMAIN_NAME : 이 스택을 사용하려면 Amazon Route53에서 호스팅되는 공인 도메인 이름이 있어야 합니다. 도메인 이름을 입력하세요.
HOSTED_ZONE_ID : 이 스택을 사용하려면 Amazon Route53에서 호스팅되는 공인 도메인 이름이 있어야 합니다. 호스팅 영역 ID를 입력하세요.

배포 예시:

./deployment/deploy.sh eu-west-1 us-east-1 mydomain.com Z0XXXXXXXXXXXX

배포가 끝나면 생성된 2개의 CloudFront 배포 FQDN을 AWS CloudFormation 익스포트명 에서 확인할 수 있습니다.

Route53 장애 조치에 사용되는 CloudFront 배포
- 익스포트명 = R53-Failover-Distrib-Domain
CloudFront 및 Route53 하이브리드 장애 조치에 사용되는 CloudFront 배포
- 익스포트명= Hybrid-Failover-Distrib-Domain

출력 예시:

CdkRegionStack.HybridFailoverDistribDomain = https://XXXXXXX.cloudfront.net/prod
CdkRegionStack.R53FailoverDistribDomain = https://YYYYYYYY.cloudfront.net/prod

터미널 출력 외에도 CloudFormation 콘솔에서 생성된 스택을 선택하고 Outputs 탭으로 이동하여 익스포트된 출력을 확인할 수 있습니다.

그림 5. 이 스크린샷은 CloudFormation 스택의 출력을 보여줍니다.

솔루션 테스트

두 장애 조치 솔루션을 모두 테스트하려면 다음의 bash 스크립트를 사용할 수 있습니다. 익스포트된 출력에서 확인한 CloudFront 배포 URL을 제공해야 합니다.

테스트를 시작하려면 다음 스크립트를 실행합니다.

./testing/test.sh https://<R53Failover/Hybrid-CF-Distrib>.cloudfront.net/prod

기본 오리진 장애를 시뮬레이션하기 위해 Lambda 콘솔에서 기본 API 엔드포인트에서 반환되는 상태 코드를 변경합니다.

기본 리전을 선택한 다음, CloudFormation 스택에 의해 생성된 Lambda 함수로 이동합니다. Lambda 함수명은 CdkCloudFrontFailover-PRIMARYappContentHandler으로 시작합니다.
구성(Configuration) 탭으로 이동한 다음 환경 변수(Environment variables)를 찾습니다. StatusCodeVar 환경 변수의 값을 200에서 502로 변경합니다.

그림 6. 이 스크린샷은 statusCodeVar 환경 변수의 값을 변경하는 방법을 보여줍니다.

Route 53 DNS 오리진 장애 조치를 테스트한 예시:

./testing/test.sh https://<R53Failover-CF-Distrib>/prod
---------------------------------------------
req# | status | timestamp | statusCode | TTFB
---------------------------------------------
1,PRIMARY,2022-11-12 00:43:29,200,0.126647
2,PRIMARY,2022-11-12 00:43:30,200,0.132606
...
33,PRIMARY,2022-11-12 00:44:06,200,0.134515
34,DOWN,2022-11-12 00:44:08,502      <-- Changed Lambda status code to 502
35,DOWN,2022-11-12 00:44:09,502
...
114,DOWN,2022-11-12 00:45:44,502
115,DOWN,2022-11-12 00:45:45,502
116,SECONDARY,2022-11-12 00:45:46,200,0.394419 <-- R53 failover kicked (82 seconds)
117,SECONDARY,2022-11-12 00:45:48,200,0.395510
118,SECONDARY,2022-11-12 00:45:49,200,0.389113
...

참고로 Route 53 장애 조치가 시작되려면 시간이 소요됩니다. 이는 상태 확인에서 엔드포인트를 비정상으로 표시하는 데 필요한 시간입니다.

CloudFront 하이브리드 오리진 장애 조치를 테스트한 예시:

테스트를 실행하기 전에 먼저 Lambda 함수의 StatusCodeVar환경 변수를 200으로 되돌려야 합니다.

./testing/test.sh https://<Hybrid-Failover-CF-Distrib>/prod
---------------------------------------------
req# | status | timestamp | statusCode | TTFB
---------------------------------------------
1,PRIMARY,2022-11-12 00:55:19,200,0.168231
2,PRIMARY,2022-11-12 00:55:20,200,0.123779
...
14,PRIMARY,2022-11-12 00:55:34,200,0.069994
15,SECONDARY,2022-11-12 00:55:36,200,0.827250 <-- Changed Lambda status code to 502
16,SECONDARY,2022-11-12 00:55:37,200,0.486308
17,SECONDARY,2022-11-12 00:55:39,200,0.421217
18,SECONDARY,2022-11-12 00:55:40,200,0.497715
19,SECONDARY,2022-11-12 00:55:42,200,0.490106
20,SECONDARY,2022-11-12 00:55:43,200,0.494140
...

테스트를 통해 Route 53가 보조 오리진으로 장애 조치하는데 소요되는 시간 동안 CloudFront 오리진 장애 조치가 애플리케이션의 가용성을 유지하는 데 어떻게 도움이 되는지를 확인할 수 있습니다.

리소스 정리

기본 리전 및 대체 리전에서 Cloudformation 스택을 삭제합니다.

./deployment/destroy.sh AWS_REGION AWS_BACKUP_REGION DOMAIN_NAME HOSTED_ZONE_ID

출력에서 두 리전 모두에서 스택이 성공적으로 삭제되었는지 확인합니다.

✅ CdkCloudFrontFailover: destroyed

삭제 예시:

./deployment/destroy.sh eu-west-1 us-east-1 mydomain.com Z0XXXXXXXXXXXX

결론

고객 대면 워크로드의 가용성과 안정성은 고객에게 긍정적인 사용자 경험을 유지하는데 매우 중요합니다. 그리고 워크로드의 고가용성을 달성하기 위해서는 오리진 인프라에 이중화를 도입할 수 있습니다. 이 블로그에서는 서로 다른 장애 조치 메커니즘을 사용하는 CloudFront 배포를 설정하는 방법을 알아보았습니다. 또한, 테스트를 통해 CloudFront와 Route 53의 기능을 함께 사용하여 성능에 영향을 주지 않으면서 워크로드의 고가용성을 보장할 수 있는 방법에 대해 알아보았습니다.

비용 및 추가 자료

제공된 AWS CDK의 기본 테스트 비용은 월 $10 미만입니다.

Amazon Route 53 비용
Amazon CloudFront를 사용하는 고가용성 애플리케이션을 위한 세 가지 고급 설계 패턴
Amazon CloudFront와 AWS Lambda @Edge 를 활용한 향상된 오리진 장애 조치

AWS 기술 블로그