HAQM CloudFront를 활용한 다중 리전 액티브-액티브 아키텍처의 지연 시간 기반 라우팅 구현

이 글은 AWS Networking & Content Delivery Blog에 게시된 Using latency-based routing with HAQM CloudFront for a multi-Region active-active architecture by Artem Lovan, Nikhil Bhagat, Mohan Pasappulatti, and Tulip Gupta Pahuja을 한국어 번역 및 편집하였습니다.

이 게시물은 AWS에서 HAQM Route 53의 지연 시간 기반 라우팅과 HAQM CloudFront를 사용하여 다중 리전 액티브-액티브 애플리케이션 아키텍처를 위한 네트워크 계층 구성 방법을 안내하여 드립니다. 이를 통해 사용자에게 낮은 지연 시간과 안정적인 경험을 제공할 수 있습니다.

AWS 네트워킹 서비스를 사용하여 액티브-액티브 아키텍처를 구축하면 애플리케이션의 복원력과 성능이 향상되나, 비용과 복잡성 측면에서의 트레이드오프가 존재 할 수 있으므로 아키텍처 고려사항과 애플리케이션의 기능성, 복원력, 성능에 미치는 영향에 대한 지침도 또한 제공합니다.

다중 리전 액티브–액티브 아키텍처의 장점은 무엇입니까?

다중 리전 액티브-액티브 아키텍처는 지리적으로 분리된 두 개 이상의 AWS 리전에서 동시에 실행되는 애플리케이션 배포 방식입니다. 두(또는 모든) 리전은 애플리케이션에 필요한 모든 구성 요소와 데이터를 보유하고 있으며, 최종 사용자의 위치를 기반으로 요청을 능동적으로 처리합니다. 만약 한 리전에서 애플리케이션에 장애가 발생하면, 전 세계 사용자에게 다운타임 없이 다른 리전이 자동으로 사용자 트래픽을 처리할 수 있습니다.

다중 리전 액티브–액티브 아키텍처는 도입을 언제 고려해야 할까요?

애플리케이션 장애 단위가 AWS 리전 수준인 경우 다중 리전 액티브-액티브 아키텍처를 고려 할 수 있습니다. 액티브-액티브 아키텍처의 도입 시 높은 비용 발생 가능성과 증가된 복잡성을 신중히 고려해야 합니다. 교차 리전 간의 데이터 복제가 필요한 상태 기반 애플리케이션의 경우, 데이터 불일치, 높은 지연 시간, 성능 저하 등의 요소도 또한 고려 대상이 될 수 있습니다.

비즈니스 요구사항

엄격한 복구 시간 목표(Recovery Time Objective, RTO)와 복구 시점 목표(Recovery Point Objective, RPO) 요구사항: 액티브-액티브 아키텍처의 사용을 고려할 이유 중 하나는, 액티브-패시브, 웜 스탠바이, 파일럿 라이트 구성들과 같은 다른 재해 복구(Disaster Recovery, DR) 전략으로 충족할 수 없는 엄격한 SLA 요구사항의 충족입니다. 또한 비즈니스의 장애 단위가 리전 수준이어야 하며, RTO가 초 또는 분 단위로 측정되어야 하는 경우에도 액티브-액티브 아키텍처를 고려할 수 있습니다.

법률 및 규정 준수 : 현지 정부가 시행하는 데이터 주권 법률 및 규정에 따라, 데이터가 최종 사용자와 물리적으로 가까운 곳에 보관되어야 할 수 있습니다. 데이터 주권 요구사항을 충족하기 위해 사용자의 지리적 위치를 기반으로, 여러 AWS 리전에 애플리케이션을 배포하도록 선택할 수 있습니다.

지연 시간 및 성능 개선

지리적으로 분산된 사용자에게 동적 컨텐츠를 제공하는 경우, 성능 향상을 위해 액티브-액티브 아키텍처 도입을 선택할 수 있습니다. 이 시나리오에서는 긴 네트워크 홉에 따른 오버헤드가 없이 비정적 데이터를 처리하고 제공할 수 있으므로 지연 시간을 줄일 수 있습니다.

다중 리전 액티브–액티브 아키텍처에서 사용되는 AWS 네트워킹 서비스

액티브-액티브 아키텍처에서는 다중 리전 아키텍처 구성에서 애플리케이션을 배포할 때, 지연 시간의 개선을 위해 HAQM CloudFront와 AWS Global Accelerator를 사용할 수 있습니다. Global Accelerator는 AWS 글로벌 네트워크 인프라를 활용하여 인터넷 사용자의 성능과 가용성을 향상시키는 네트워킹 서비스입니다. Global Accelerator는 정적 애니캐스트 IP 주소나 즉각적인 AWS 리전 장애 조치가 필요한 사용 사례에 적합하지만, 컨텐츠 캐싱이나 엣지 프로세싱은 지원하지 않습니다. 그러므로 애플리케이션에 따라 이 블로그 포스트에서 설명하는 것처럼, CloudFront를 활용한 아키텍처를 고려하는 것이 더 나을 수 있습니다.

CloudFront는 캐싱이 가능한 컨텐츠(이미지와 비디오 등)와 동적 컨텐츠(API 가속화 및 동적 사이트 전송) 모두의 성능을 향상시킵니다. CloudFront는 다음과 같은 추가적인 이점도 제공합니다:

보안

접근 제어: CloudFront의 지리적 제한 기능을 사용하여 특정 지리적 위치의 사용자가 CloudFront를 통해 배포되는 컨텐츠에 접근하는 것을 제한할 수 있습니다.

엣지 컴퓨팅

CloudFront는 AWS Lambda@Edge와 CloudFront Functions를 통해 프로그래밍 가능하고 안전한 엣지 CDN 컴퓨팅 기능을 제공합니다.

Lambda@Edge: AWS Lambda@Edge는 엣지에서 수행되는 광범위한 컴퓨팅 요구사항과 사용자화를 지원하는 범용 서버리스 컴퓨팅 기능입니다.

CloudFront Functions: CloudFront Functions는 HTTP 헤더 변경, URL 재작성/리디렉션, 캐시 키 정규화와 같은 대규모 서브밀리초 단위의 컴퓨팅 작업에 이상적입니다.

솔루션 개요

그림 1: AWS 리전의 오리진 서비스로 연결이 되는 클라이언트 브라우저의 사용자 흐름

그림 1에서 보여지는 다이어그램은 액티브-액티브 아키텍처에서 최종 사용자 API 호출의 흐름을 설명합니다. 사용자 요청은 가장 가까운 AWS 엣지 로케이션[1]에 도착하여 CloudFront[2]를 통해 HAQM API Gateway[3]로 전달됩니다. CloudFront는 Elastic Load Balancing 로드 밸런서, HAQM Elastic Compute Cloud(HAQM EC2) 서버, 또는 HAQM Simple Storage Service (HAQM S3) 버킷과 같은 다른 오리진과도 함께 사용할 수 있습니다.

이 과정에서 CloudFront 대신 Global Accelerator를 사용한다면, 필요시 AWS 리전 간 자동 장애 조치를 포함하여, 엣지 로케이션에서 애플리케이션까지의 최적 경로를 찾게 됩니다. CloudFront는 현재 액티브-액티브 다중 리전 아키텍처에서 다른 AWS 리전으로 장애 조치하는 기본 제공 솔루션을 제공하지 않습니다. 그러므로 이 블로그 다음 섹션에서 Global Accelerator와 유사한 장애 조치 기능을 어떻게 설계하고 구현할 수 있는지 설명하겠습니다. Route 53에서 지연 시간 기반 라우팅을 사용하는 액티브-액티브 구성을 통해 이러한 리전 장애 조치 기능을 사용할 것입니다.

작동 방식

다중 리전 액티브-액티브 구성을 구현할 때 특별히 주의해야 할 두 가지 주요 영역이 있습니다:

• 클라이언트가 애플리케이션에 접근시에 사용되는 커스텀 도메인을 위한 보안 소켓 계층/전송 계층 보안(Secure Sockets Layer, SSL / Transport Layer Security, TLS) 인증서
• 클라이언트 요청을 AWS 리전으로 라우팅하는 지연 시간 기반 라우팅 로직

먼저 SSL/TLS 인증서 구성 방법을 단계별로 안내하고, AWS 리전으로의 클라이언트 트래픽 라우팅 로직을 살펴보겠습니다.

AWS 웹사이트 및 애플리케이션 보호를 위한 SSL/TLS 인증서 소개

다중 리전 설정에서 트래픽을 전송 중 암호화를 위해, 애플리케이션을 배포한 각 리전에 일치하는 SSL/TLS 인증서가 존재해야 합니다. 이 섹션에서는 AWS에서 이를 구현하는 방법에 대해 논의하겠습니다.

애플리케이션을 배포하는 각 리전에 일치하는 SSL/TLS 인증서를 생성해야 합니다. 인증서는 AWS 웹사이트와 애플리케이션을 보호하기 위해 다중 리전 구정에서 전송 중인 트래픽이 암호화되도록 보장합니다. AWS Certificate Manager (ACM)를 사용하여 AWS에서 인증서를 생성할 수 있습니다.

ACM은 AWS 서비스 및 내부 연결 리소스에서 사용할 공개 및 비공개 SSL/TLS 인증서를 쉽게 프로비저닝, 관리 및 배포 지원 서비스입니다. SSL/TLS 인증서는 네트워크 통신을 보호하고 인터넷상의 웹사이트 및 사설 네트워크의 리소스 인증에 사용됩니다.

ACM이 AWS 웹사이트와 애플리케이션 보호를 위해, AWS 서비스가 전송 트래픽의 암호화에 사용하는 인증서가 각 리전에 존재 해야 합니다. 예를 들어, API Gateway가 사용자 정의 도메인 이름 리전 엔드포인트 유형을 사용하고, US East (Ohio)와 US West (Oregon) 리전 모두에 배포된 경우, 인증서는 두 리전 모두의 ACM에서 생성되거나 등록되어 있어야 합니다. ACM에 대해 자세히 알아보려면 AWS Certificate Manager란 무엇인가요? 를 참조하세요.

Note: CloudFront이 경우, 리전 서비스가 아닌 글로벌 서비스임을 유의하세요. 따라서 인증서는 US East (N. Virginia) 리전의 ACM에서 발급되어야 합니다.

Route 53은 가용성이 높고 확장 가능한 도메인 네임 시스템(DNS) 웹 서비스입니다. Route 53을 사용하여 도메인 등록, DNS 라우팅, 상태 확인등 세 가지 주요 기능을 어떤 조합으로도 사용 할 수 있습니다. Route 53 트래픽 흐름으로 다양한 라우팅 유형을 통해 전역적으로 트래픽을 관리할 수 있습니다. 이 게시물에서는 지연 시간 라우팅 정책에 중점을 두겠습니다. 지원되는 모든 라우팅 유형에 대해 자세히 알아보려면 라우팅 정책 선택을 참조하세요.

그림 2: 사용자 지정 도메인을 사용한 DNS 해석 및 요청 흐름

위의 그림 2에 나타난 사용자 요청 흐름이 어떻게 작동하는지 살펴보겠습니다.

1. 배포의 기본 CloudFront 도메인 이름을 가리키는 사용자 지정 도메인 example.com으로 Route 53 별칭 레코드를 생성합니다. Route 53 별칭 레코드와 CNAME에 대해 자세히 알아보려면 ‘단순 별칭 레코드에 특정한 값‘을 참조하십시오.
2. CloudFront에서 대체 도메인 이름(CNAME)을 구성하고, US East (N. Virginia) 리전의 ACM에서 인증서를 등록합니다. Route 53 별칭 레코드와 CNAME에 대해 자세히 알아보려면 ‘대체 도메인 이름 추가하여 사용자 지정 URL 사용‘을 참조하십시오.
3. 리전별 AWS 서비스에 대한 Route 53 레코드 세트를 구성합니다. 이 예시에서는 동일한 도메인 이름(api.example.com)으로 두 개의 레코드를 생성하고 라우팅 정책을 지연 시간 기반으로 설정합니다. 다중 리전 액티브-액티브 설정에서는 지연 시간 기반 라우팅이 왕복 시간이 가장 짧은 최상의 지연 시간을 가진 각 리전으로 트래픽을 라우팅합니다. 지연 시간 기반 라우팅 정책에 대해 자세히 알아보려면 ‘지연 시간 기반 라우팅‘을 참조하십시오.
4. 공개적 접근이 가능한 AWS 서비스가 위치한 각 리전에서 ACM에 공개 인증서를 요청합니다. 이 예시에서는 리전 1과 리전 2의 ACM에 인증서를 요청합니다.
5. 또는 Application Load Balancer를 오리진으로 사용할 수도 있습니다. 위의 단계들은 S3를 제외한 모든 AWS 오리진에 적용가능합니다.

AWS Region으로 클라이언트 요청 라우팅 로직

제안된 요청 흐름에서는 API Gateway가 요청을 처리하기 전에 두 단계의 DNS 해석이 이루어집니다:

• 클라이언트 브라우저에서 도메인 이름을 CloudFront IP 주소로 해석
• CloudFront 엣지 로케이션에서 API Gateway또는 Application Load Balancer(원본 유형에 따라)의 사용자 지정 도메인 이름을 IP 주소로 해석

다음 그림 3의 다이어그램은 CloudFront와 Route 53을 사용한 다중 리전 액티브-액티브 지연 시간 기반 라우팅을 보여줍니다.

그림 3: CloudFront와 Route 53을 사용한 다중 리전 액티브–액티브 지연 시간 기반 라우팅

위 그림에 설명된 DNS 해석 흐름을 살펴보겠습니다.

1. 클라이언트가 example.com 도메인으로 HTTPS 요청을 작성하고 Route 53이 도메인을 해석합니다.
2. 클라이언트는 자신과 가장 가까운 CloudFront 접속 지점(PoP) 위치로 요청을 전달합니다.
3. CloudFront는 AWS 글로벌 네트워크를 통해 각 요청을 컨텐츠를 가장 잘 제공할 수 있는 엣지 로케이션으로 라우팅하여 컨텐츠 배포 속도를 높입니다. 일반적으로 이는 사용자에게 가장 빠른 전송을 제공하는 CloudFront 엣지 서버입니다.
4. CloudFront PoP 에서 오리진 도메인 이름 example.com을 해석하기 위해 Route 53에 DNS 요청 합니다. 이 도메인 이름에는 Route 53에서 지연 시간 기반 라우팅 정책이 구성되어 있으므로, CloudFront PoP 위치에서 가장 가까운 리전에 있는 API Gateway의 IP 주소가 반환됩니다. 이 예제에서는 API Gateway를 오리진으로 사용했습니다. 다른 오리진 유형을 사용하더라도 (단 HAQM Simple Storage Service 제외) 데이터 흐름은 동일하게 유지됩니다.
5. CloudFront PoP 은 가장 가까운 리전의 적절한 오리진(API GW/ALB)로 HTTP 요청을 전달합니다.

배포 절차

배포 절차는 4단계 접근 방식을 따릅니다: 파트 1은 오리진 및 DNS 등록 설정에 중점을 둡니다. 파트 2는 Route 53 퍼블릭 호스팅 영역과 AWS ACM 구성을 보여줍니다. 파트 3은 Route53 퍼블릭 호스팅 영역에 사용자 지정 도메인 추가에 중점을 둡니다; 마지막으로 파트 4는 CloudFront 배포 설정에 중점을 둡니다

파트 1 – API GW/EC2 인스턴스 배포, 도메인 등록 및 Route 53 레코드 구성

웹사이트 www.example.com을 호스팅할 각 리전에 백엔드 서버를 구성합니다.

1. 위 두 리전에서 각각의 API Gateway 생성 단계를 따릅니다. 동적 웹사이트의 성능과 보안을 향상시키기 위한 AWS 엣지 서비스 설정 방법에 대한 블로그를 참조하십시오.
2. 또는 오리진으로 Application Load Balancer를 사용할 계획이라면, 위 두 리전에서 각각의 Application Load Balancer(ALB)를 생성 단계를 따릅니다.

파트 2 – Route 53에서 사용자 지정 도메인용 퍼블릭 호스팅 영역 생성 및 공개 인증서 추가

1. 인터넷에서 트래픽을 라우팅하고자 하는 도메인 이름(예: example.com)에 대해 Route 53을 사용하여 퍼블릭 호스팅 영역을 생성합니다. 도메인 이름을 등록하기 위해 Route 53 또는 다른 도메인 등록 대행사를 이용할 수 있습니다. DNS 관리를 위해 Route 53을 사용하는 경우, 반드시 서드파티 등록 대행사의 웹사이트에서 DNS 서버를 업데이트하시기 바랍니다.
2. 등록된 도메인 네임에 대해 US East (N. Virginia)의 AWS Certificate Manager를 통해 퍼블릭 인증서를 요청합니다.주의: ACM의 컨트롤 플레인이 us-east-1에 존재하므로, 리소스가 위치한 리전과는 관계없이 반드시 us-east-1 리전에서 퍼블릭 인증서를 요청해야 합니다.

파트 3 – 동일한 퍼블릭 호스팅 영역에서 사용자 지정 오리진 도메인에 대한 A 레코드 추가

액티브-액티브(active-active) 아키텍처는 사용자 지정 도메인 이름들로 구성되어 있으므로, 퍼블릭 호스팅 영역에 사용자 지정 오리진 도메인을 위한 A 레코드들을 반드시 추가해야 합니다. 위의 예와 같이, CloudFront 배포의 오리진 역할을 하는 사용자 지정 오리진 도메인(예: api.example.com)에 대해 두 개의 A 레코드가 필요합니다.

다음과 같이 지연 시간 기반 라우팅을 사용하여 두 로드 밸런서에 대해 각각의 A 레코드를 생성합니다.:

1. example.com 퍼블릭 호스팅 영역에서 ‘레코드 생성’을 선택합니다.
2. 레코드 이름을 api로 추가하고 레코드 유형에서 A 레코드를 선택합니다.
3. 별칭을 켜고 ‘다음으로 트래픽 라우팅’에서 사용 중인 적절한 오리진을 선택합니다.
4. us-east-1 리전(예시 기준)을 선택하고 구성된 오리진을 선택합니다.
5. 라우팅 정책에서 ‘지연 시간’을 선택합니다.
6. 다른 레코드를 추가하고 두 번째 us-west-2 리전(현재 예시 기준)에 대해 위 단계를 반복합니다.
7. 완료되면 ‘레코드 생성’을 선택합니다.

파트 4 – 오리진으로 API GW/ALB을 사용하는 CloudFront 배포 설정

퍼블릭 호스팅 영역에서 사용자 지정 도메인 이름을 A 레코드로 추가한 후, 이를CloudFront 배포의 오리진으로 구성합니다.

1. AWS 콘솔을 통해 HAQM CloudFront 탐색 창으로 이동하여 배포 생성을 선택합니다.
2. CloudFront 배포 생성 단계를 따릅니다.
3. 오리진 도메인으로 사용자 지정 서브도메인 api.example.com을 추가합니다.
4. 뷰어 프로토콜 정책으로 ‘HTTP를 HTTPS로 리디렉션’을 선택합니다. (또는 적용 가능한 다른 정책 선택)
5. 캐시 키 및 오리진 요청 하단 의 ‘캐시 정책 및 오리진 요청 정책(권장)’을 선택한 다음, 설계 요구 사항에 따라 적절한 캐시 정책을 선택합니다.
6. 설정 섹션 하단의 ‘대체 도메인 이름(CNAME)’을 선택한 후, ‘항목 추가’ 하단에 파트 2에서 구성한 도메인 이름(www.example.com)을 추가합니다.
7. 사용자 지정 SSL 인증서로 파트2에서 생성한 도메인용 ACM 인증서를 선택합니다.
8. ‘배포 생성’을 선택합니다.
9. 배포가 완료되면 배포 하단 오리진 탭으로 이동하여 오리진을 선택하고 편집을 클릭합니다. 선택된 프로토콜이 ‘HTTPS 전용’인지 확인합니다. (AWS는 HTTPS를 권장하지만, 설계 따라 적합한 옵션을 선택할 수 있습니다)

지연 시간 기반 라우팅 테스트

서로 다른 지리적 위치에 있는 클라이언트를 시뮬레이션하기 위해, 샘플 애플리케이션 배포에 사용된 두 개의 AWS 리전(us-east-1과 us-west-2)에 각각HAQM EC2 인스턴스를 실행했습니다. 각 인스턴스에서 애플리케이션에 접근하는 데 사용되는 도메인 이름에 대해 curl요청을 실행할 수 있습니다. 이 실습에서는 각 Linux EC2 인스턴스에서 다음 명령을 실행할 것입니다. 여기서 172-31-56-168은 us-east-1 리전의 인스턴스를 나타내고, 172-31-16-193은 us-west-2 리전의 인스턴스를 나타냅니다.

그림4: 클라이언트 요청은 가장 가까운 리전에서 처리됨

두 리전 모두 정상 상태이며 트래픽을 수용하고 있어, 각각의 클라이언트 요청은 가장 가까운 리전에서 처리되었습니다.

리전 장애 조치 테스트

이제 us-east-1의 애플리케이션이 유지보수 모드로 전환되어 축소된 용량으로 운영되는 상황을 시뮬레이션해 보겠습니다. 테스트 목적으로 이 리전에서 일반 트래픽을 우회시키기 위해 유지보수 기간을 표시하도록 헬스 체크 상태를 업데이트했습니다. 172-31-16-193에서 curl 요청을 실행하면 동일한 결과가 나오지만, us-east-1 리전의 172-31-56-168 인스턴스에서 실행한 결과는 다음과 같습니다.

그림 5: 가장 가까운 리전이 사용 불가시 다음으로 가까운 리전으로 클라이언트 요청이 전달됨

us-east-1 리전에서 요청을 처리할 수 없기 때문에, 해당 요청은 그 다음으로 가까운 리전으로 전달됩니다.

예시에서 샘플 애플리케이션은 단 두 개의 리전에만 배포되어 있으므로, 요청은 us-west-2 리전에서 처리됩니다. 세 개 이상의 리전으로 구성된 설정에서는, 사용 불가능한 리전의 트래픽이 최종 사용자와 두번째로 가까운 리전에 전달됩니다.

리전 장애 조치가 제대로 작동하기위해 헬스 체크가 정상적으로 작동하는 것이 필수적입니다. 즉, 애플리케이션 계층에서 신뢰할 수 있는 헬스 체크만이 애플리케이션이 예상대로 작동하고 클라이언트 요청 처리를 보장합니다. 최상의 신뢰성과 장애 허용을 위해 데이터 플레인 기능을 활용하는 장애 조치 메커니즘을 설계하는 것을 권장합니다. 예를 들어, 호스팅 영역의 DNS 레코드나 헬스 체크 구성(컨트롤 플레인 기능)을 업데이트하는 대신 Route 53 헬스 체크(데이터 플레인 기능)를 사용하는 메커니즘을 선택합니다. Route 53 헬스 체크를 사용하여 장애 조치 시나리오를 처리하는 방법에 대한 자세한 정보는 ‘HAQM Route 53을 사용한 재해 복구 메커니즘 생성하기‘를 참조하십시오.

결론

이 게시물에서는 CloudFront와 Route 53을 사용하여 다중 리전 액티브-액티브 아키텍처를 설계방법에 대해 알아보았습니다. CloudFront는 AWS 글로벌 네트워크를 활용하여 보안, 엣지 용량, 가용성과 같은 여러 이점과 함께 컨텐츠 전송을 빠르게 제공하는 데 사용됩니다. Route 53은 최종 사용자의 위치에서 애플리케이션이 배포된 가장 가까운 리전으로 지연 시간 기반 라우팅을 구성하는 데 사용됩니다. 다중 리전 액티브-액티브 아키텍처에서 이러한 서비스들을 결합함으로써 최종 사용자에게 낮은 지연 시간의 경험을 제공할 수 있습니다.

시작하시려면 Route 53 콘솔을 사용하여 레코드 생성과 CloudFront 배포 생성 페이지를 방문해주시길 바랍니다.