개요

AWS 엣지 서비스는 고가용성의 웹 애플리케이션을 구축하기 위한 중요한 구성 요소입니다. AWS 엣지 서비스는 분산된 특성으로 인한 기본적인 고가용성 외에도 웹 애플리케이션의 진입점 역할을 하며 오리진 인프라(예: 가용 영역 또는 리전)에서 사용 가능한 파티션으로 요청을 라우팅할 수 있습니다.

아키텍처 관련 결정

고가용성 웹 애플리케이션은 가용성 SLO, 비용 및 복잡성 측면에서 요구 사항에 따라 다양한 방식으로 설계될 수 있습니다. 최소한 비즈니스 요구 사항에 따라 다음과 같은 기술적 결정을 내려야 합니다.

  • 액티브/액티브 또는 액티브/패시브 아키텍처가 있나요?
  • 오리진이 다른가요? 가용 영역이 다른가요? 리전이 다른가요?
  • 액티브/액티브 아키텍처의 오리진 간 라우팅 로직은 무엇인가요? 액티브/패시브 아키텍처의 장애 조치 기준은 무엇인가요?

일시적인 오리진 오류 관리

CloudFront는 때때로 소수의 사용자 요청을 방해할 수 있는 일시적인 5xx 오류의 영향을 완화하는 데 도움이 될 수 있습니다. 이는 갑작스러운 트래픽 급증이나 일시적인 네트워크 문제로 인한 오리진 과부하 때문에 발생하는 경우가 많습니다. CloudFront를 사용하면 다양한 방법으로 일시적인 5xx 오류를 완화할 수 있습니다.

재시도. 오리진과의 연결을 설정할 수 없는 경우 구성 가능한 연결 제한 시간을 설정하여 TCP 연결을 최대 3회까지 재시도하도록 CloudFront를 구성할 수 있습니다. 또한 CloudFront는 구성된 재시도 횟수에 따라 멱등성 GET/HEAD를 재시도합니다.

오래된 콘텐츠로 응답. 오리진에서 재시도가 실패하는 경우 CloudFront는 기본적으로 오류 응답을 반환하는 대신 캐시에서 사용 가능한 경우 객체의 오래된 버전을 제공합니다. 이 동작은 Cache-Control: stale-if-error=0 지시문을 사용하여 비활성화할 수 있습니다.

보조 오리진으로의 오리진 장애 조치. 오리진 장애 조치 기능을 사용하여 실패한 특정 요청에 대해 보조 오리진에 실패하도록 CloudFront를 구성할 수 있습니다. 오리진 장애 조치는 멱등성 GET/HEAD 요청에만 적용됩니다. 참고로 오리진 이벤트에서 Lambda@Edge를 사용하는 경우 CloudFront는 장애 조치 시에도 함수를 실행합니다. 이 시나리오에서는 Lambda@Edge 함수에서 요청이 기본 오리진에 대한 것인지 보조 오리진에 대한 것인지 유추하여 해당 로직을 구분할 수 있습니다. 이를 위해 두 오리진 모두에 동일한 오리진 사용자 지정 헤더를 구성했지만 Lambda@Edge가 읽을 수 있는 값은 서로 다르게 구성했습니다.

원활한 장애 조치. 다른 오리진으로의 오리진 장애 조치가 바람직하지 않은 경우(예: 다른 오리진 인프라 유지), 사용자 지정 오류 페이지를 사용하여 다른 위치(예: S3 버킷)에 호스팅된 정적 파일로 장애 조치하는 것을 고려해 보세요. 기본적으로 오류가 발생하는 모든 요청에 동일한 페이지가 사용되지만 이 블로그의 세 번째 패턴을 따르면 보다 동적인 응답을 구축할 수 있습니다.

오리진 운영 중단 시 상태 저장 장애 조치

Route 53 정책 기반 장애 조치

CloudFront에서 오리진으로 구성된 오리진 도메인 이름에 대한 상태 확인과 함께 Route 53 장애 조치 라우팅 정책을 사용할 수 있습니다. 기본 오리진이 비정상 상태가 되면 Route 53이 이를 탐지한 후 보조 오리진의 IP 주소로 오리진 도메인 이름을 확인하기 시작합니다. CloudFront는 오리진 DNS TTL을 준수합니다. 즉, 트래픽이 DNS TTL 내에서 보조 오리진으로 흐르기 시작합니다. 가장 최적의 구성(Fast Check 활성화, 장애 조치 임계값 1, DNS TTL 60초)은 장애 조치가 발생하는 데 최소 70초가 걸린다는 것을 의미합니다. 그렇게 되면 상태 저장 장애 조치이므로 모든 트래픽이 보조 오리진으로 전환됩니다. 참고로 이 설계는 Route 53 Application Recovery Control을 통해 더욱 확장되어 여러 AWS 리전, 가용 영역 및 온프레미스에 걸쳐 보다 정교한 애플리케이션 장애 조치를 수행할 수 있습니다. 이 접근 방식을 GET/HEAD 요청에 대한 CloudFront 오리진 장애 조치 기능과 결합하면 Route 53이 보조 오리진으로 장애 조치하는 동안 오류를 줄일 수 있습니다. 이 패턴은 이 블로그에 설명되어 있습니다.

S3 기반 오리진과 같이 서로 다른 오리진이 동일한 도메인 이름을 공유하지 않는 경우, Route 53은 위에서 제안한 방식으로 사용할 수 없습니다. 이 시나리오에서는 어떤 오리진을 선택할지 Route 53을 쿼리한 다음 오리진 도메인 이름을 변경하고 Host 헤더를 사용하여 요청을 선택한 오리진으로 재라우팅하기 위해 오리진 요청 이벤트에 구성된 Lambda@Edge 함수가 필요합니다. 이 구현에 대해 자세히 알아보려면 다음 콘텐츠 기반 사례 연구를 읽어보세요.

Global Accelerator를 통한 장애 조치

Global Accelerator를 사용하는 애플리케이션은 기본 장애 조치 기능을 활용할 수 있습니다. Global Accelerator를 사용하면 여러 가용 영역 또는 여러 AWS 리전에 걸쳐 단일 AWS 리전에 애플리케이션을 배포할 수 있습니다. Global Accelerator는 상태 확인을 사용하여 애플리케이션 엔드포인트의 상태를 모니터링하고 수십 초 내에 트래픽을 비정상 엔드포인트에서 다른 곳으로 라우팅합니다.

액티브-액티브 아키텍처

지연 시간 기반 라우팅

CloudFront를 Route 53 지연 시간 기반 정책과 함께 사용하면 액티브-액티브 다중 리전 아키텍처에서 오리진을 복제한 가장 가까운 AWS 리전으로 사용자 요청을 라우팅할 수 있습니다. 이렇게 하려면 Route 53의 지연 시간 기반 정책을 사용하여 CloudFront에서 오리진 도메인 이름을 구성하세요. CloudFront가 오리진에 연결하고 요청을 전송할 오리진 도메인 이름을 확인하면 Route 53는 지연 시간을 기준으로 가장 가까운 오리진 IP를 반환합니다. 참고로 CloudFront가 오리진 도메인 이름을 확인하는 위치는 배포 구성 및 트래픽 유형에 따라 다릅니다. 일반적으로 도메인 이름은 동적 요청의 경우 엣지 로케이션에서, 캐시 가능한 콘텐츠의 경우 리전 엣지 캐시에서 확인됩니다. 이 블로그는 API Gateway를 위한 액티브-액티브 다중 리전 배포를 안내합니다.

S3 기반 오리진과 같이 서로 다른 오리진이 동일한 도메인 이름을 공유하지 않는 경우, Route 53은 위에서 제안한 방식으로 사용할 수 없습니다. 이 시나리오에서는 가장 가까운 오리진으로 라우팅하기 위해 오리진 요청 이벤트에 구성된 Lambda@Edge가 필요합니다. 이 구현에 대해 자세히 알아보려면 다음 블로그를 읽어보세요.

고급 라우팅

특정 시나리오에서는 요청 라우팅에 애플리케이션 수준 로직이 필요합니다. 경로를 기반으로 다른 오리진으로 라우팅하는 등 로직이 간단한 경우(예: /api1을 오리진 1로 라우팅하고 /api2를 오리진 2로 라우팅) 간단히 CloudFront의 기본 캐시 동작 기능을 사용할 수 있습니다. 로직이 더 정교한 경우 오리진 요청 이벤트에 대한 Lambda@Edge를 통해 URL, 쿠키, 헤더, 국가 등과 같은 애플리케이션 수준 속성을 기반으로 트래픽을 라우팅할 수 있습니다. 로직은 상태를 저장하지 않고 함수 코드에 완전히 포함되거나 Lambda@Edge가 라우팅 규칙을 가져와 실행하는 S3 또는 DynamoDB와 같은 외부 위치에 저장할 수 있습니다.

리소스

이 페이지의 내용이 도움이 되었나요?

 피드백