AWS 기술 블로그
Amazon CloudFront를 활용하여 비용 효율적으로 동적 워크로드 전송을 가속화하고 보호하기
이 글은 AWS Networking & Content Delivery Blog에 게시된 Accelerate, protect and make dynamic workloads delivery cost efficient with Amazon CloudFront by Yury Yakubov을 한국어 번역 및 편집하였습니다.
Amazon ELB(Amazon Elastic Load Balancer), Amazon EC2(Amazon Elastic Compute Cloud) 인스턴스, Amazon API Gateway, AWS Lambda에서 최종 사용자에게 동적 콘텐츠를 제공하는 경우, Amazon CloudFront를 사용하여 성능과 보안을 개선하고 콘텐츠 전송 비용을 최적화할 수 있습니다. 동적 콘텐츠는 모든 사용자 또는 모든 요청의 고유한 웹 객체를 의미합니다. 따라서, 캐싱의 이점을 누릴 수 없습니다. 대표적인 동적 콘텐츠의 예로, API 호출, 온라인 장바구니, 타겟팅 광고와 같은 개인화된 콘텐츠를 들 수 있습니다.
이 게시글에서는 비용 최적화, 성능, 보안 아키텍처의 관점에서 CloudFront가 동적 워크로드에 제공하는 이점에 대해 알아보도록 하겠습니다. 또한 구성 모범 사례에 대해서도 살펴보겠습니다.
성능
콘텐츠 전송 성능은 클라이언트와 서버 간 전송되는 IP 패킷의 짧은 지연 시간과 높은 처리량을 의미합니다. 정적 콘텐츠의 경우, 사용자와 더 가까운 CloudFront 엣지 로케이션에서 정적 오브젝트를 캐싱하여 이를 달성할 수 있습니다. 엣지에서 콘텐츠를 제공함으로써 클라이언트와 서버 간 IP 패킷이 이동해야 하는 네트워크 거리를 줄일 수 있기 때문입니다. 그 결과로 지연 시간이 단축되고 처리량이 증가하여 전반적으로 사용자 경험이 향상됩니다. 캐시가 불가능한 동적 콘텐츠에는 적용할 수 없지만, CloudFront를 사용할 때 성능이 향상되는 요인은 엣지에서의 캐싱뿐만은 아닙니다. 그러므로 성능에 도움이 되는 다른 요소를 고려하여 정적 콘텐츠와 동적 콘텐츠 모두에 적용해야 합니다.
정적 콘텐츠에 대한 CloudFront의 성능 이점 중 하나는 오리진 오프로드입니다. 콘텐츠가 CloudFront에 캐시되면 대부분의 요청이 오리진에 도달하지 않고 엣지 위치에서 제공됩니다. 동적 콘텐츠를 캐시할 수는 없지만 CloudFront의 지속적인 연결을 활용하여 오리진 오프로드를 달성할 수 있습니다. 이 기능을 사용하면 사용자로부터 오는 요청에 대해 이전 요청에 의해 생성된 오리진과의 TCP 연결을 재사용할 수 있습니다. 따라서 모든 사용자에게 오리진 TCP 연결과 TLS 핸드쉐이크가 필요하지 않습니다. TCP 연결 재사용의 효과와 전체 성능에 미치는 영향은 CloudFront Server-Timing 헤더를 통해 테스트하고 확인할 수 있습니다. 이 헤더를 사용하면 cdn-upstream-connect 지표를 비롯한 몇 가지의 진단 정보를 CloudFront로부터 응답받을 수 있습니다. 이 헤더 지표에는 오리진 DNS 요청이 완료된 시점과 오리진에 대한 TCP(및 해당되는 경우 TLS) 연결이 완료된 시점 사이의 시간(밀리초) 값이 포함됩니다. 값이 0이면 CloudFront가 기존 연결을 재사용했다는 것입니다. 따라서 여러 요청을 전송하고 Server-Timing 헤더를 분석하면 얼마나 많은 요청이 기존 연결을 재사용했는지 확인할 수 있습니다. Curl의 write out 옵션을 통해 클라이언트 측에서 다운로드 시간과 같은 성능에 지표가 될 만한 값들을 확인하여 연결 재사용의 영향도를 파악할 수 있습니다.
테스트를 수행하려면 테스트 환경이 필요합니다. 이를 위해 동적 콘텐츠에 유용한 관리형 캐시 정책 CachingDisabled를 사용하는 CloudFront 배포, CloudFront 배포 뒤에서 Amazon EC2로 구성된 동적 워크로드가 있는 Nginx 서버를 사용합니다. 그런 다음 테스트를 실행하고 결과를 보여줍니다. 실제 대기 시간 수치는 테스트 클라이언트에 따라 다릅니다. 테스트는 Github의 테스트 시스템을 배포하여 직접 수행할 수 있습니다. 또는 Server-Timing 헤더를 활성화하고 Curl 스크립트를 활용하여 CloudFront 배포를 테스트 할 수 있습니다. Github의 테스트 시스템은 이 게시글의 보안 섹션에서 다루는 몇 가지 보안 모범 사례를 사용합니다. 특히 ALB 및 EC2 보안 그룹은 CloudFront 배포에서 오는 요청만 허용하고 인터넷에서 직접 오는 요청은 모두 거부합니다.
그림 1: 테스트 아키텍처
먼저 테스트 스크립트를 실행하여 10개의 요청을 보냅니다.
(역자 주: 테스트를 수행하기 위해서는 Github의 테스트 시스템을 참고하고, Terraform을 이용하여 리소스를 프로비저닝하여야 합니다. AWS 계정과 AWS Command Line Interface(AWS CLI)의 구성이 필요합니다. 만약 AWS 리전, EC2 인스턴스 유형, 또는 Amazon Machine Image(AMI) ID를 변경해야 할 경우에는 Terraform의 variable.tf 환경 설정 파일을 적절한 값으로 수정하고 리소스를 프로비저닝 합니다.)
python3 timings.py -url https://d1234.cloudfront.net -n 10
그림 2: 10개 요청에 대한 테스트
결과에서 볼 수 있듯이, 10건 중 5건의 요청에 대한 업스트림 연결 시간이 0입니다. 이는 연결이 재사용되었음을 의미합니다. 즉, 연결이 사전 준비가 되었음을 뜻합니다. 이 예제에서는 연결의 재사용으로 다운로드 시간이 초기 연결에 비해 평균 39% 더 짧다는 것을 알 수 있습니다. 사전 준비된 연결은 TLS, TCP 핸드쉐이크의 오버헤드를 줄일 뿐만 아니라 Congestion Window(CWND)가 더 크기 때문에 그에 따른 처리량도 더 높습니다. 10개보다 더 많은 100개의 요청을 보내면 연결 재사용률이 증가하는 것을 볼 수 있습니다.
python3 timings.py -url https://d1234.cloudfront.net -n 100
그림 3: 100개 요청에 대한 테스트
현재 연결 재사용률은 93%이지만 요청이 많아질수록 재사용률은 더 높아질 수 있습니다. 연결 재사용은 지연 시간(특히 테스트에 사용된 작은 파일의 경우)을 줄여줄 뿐만 아니라 오리진에 부하를 분산시켜 더 적은 컴퓨팅 리소스를 사용할 수 있게 해줍니다. CloudFront가 없으면 모든 최종 사용자의 요청이 ALB에 직접 연결되므로 모든 사용자에게 새로운 연결이 필요하게 됩니다. 그래서 결과적으로 더 많은 LCU(Load Balancer Capacity Units)와 더 높은 비용이 발생하게 됩니다.
성능 벤치마킹 관련 참고 사항
테스트에서 볼 수 있듯이 연결 재사용은 적은 수의 요청에는 영향을 미치지 않습니다. 약 10개의 요청 이후부터 그 효과가 나타나기 시작하는 것을 확인할 수 있습니다. 따라서 하나 또는 두 개의 요청만 발생시키는 모든 종류의 합성 테스트(synthetic testing)에서 성능 테스트를 하는 것은 적합하지 않습니다. 연결 재사용의 이점을 확인할 수 있는 많은 요청이 있는 프로덕션 트래픽을 사용하여 성능 벤치마킹을 수행하는 것이 좋습니다. 테스트 시스템 간에 트래픽을 50 대 50으로 분할하거나, 시스템 간에 요일별 또는 주별로 트래픽을 전환하는 것이 가능합니다. 이 링크를 통해 Snap이 QUIC의 성능 벤치마킹을 위해 어떻게 트래픽을 균등하게 분배하려고 했는지 알아보시기 바랍니다.
연결 재사용율을 높이기 위한 Origin Shield
Amazon CloudFront Origin Shield는 오리진으로부터 콘텐츠 가져오기를 수행하는 단일 리전 엣지 캐시로, 모든 요청을 라우팅하는 CloudFront 솔루션입니다. Origin Shield는 향상된 캐시 적중률을 위해 설계되었지만 연결 재사용률도 높일 수 있습니다. 오리진과 상호작용하는 유일한 캐싱 레이어인 Origin Shield에서는, 요청이 이미 생성된 연결에 도달할 확률이 더 높기 때문입니다. 연결 재사용률을 더욱 높이려면 CloudFront 배포에서 Origin Shield를 활성화하는 것이 좋습니다. 콘텐츠의 시청자가 전 세계에 분산된 경우, Origin Shield를 활성화하여 분산된 요청이 Origin Shield가 활성화된 동일한 리전 엣지 캐시를 통과할 수 있도록 합니다. 그리고 연결 재사용률이 더 높아지는지 테스트합니다. Origin Shield에 대한 자세한 내용은 다른 게시글을 참조하시기를 바랍니다.
AWS 글로벌 네트워크
AWS 글로벌 네트워크는 CloudFront 엣지 로케이션을 AWS 리전에 연결하는 Amazon 소유의 고가용성, 저지연 네트워크입니다. Amazon이 네트워크를 완전히 소유하고 있기 때문에 고객 트래픽을 처리할 수 있는 충분한 용량을 확보하기 위해 수요에 따라 네트워크를 확장합니다. CloudFront를 통해 동적 콘텐츠를 제공하는 경우, 트래픽은 진입점 역할을 하는 CloudFront 엣지 로케이션을 통해 공용 인터넷에서 AWS 글로벌 네트워크로 이동합니다. 또한 CloudFront 엣지 로케이션은 모든 지역의 모든 주요 ISP와 연결되어 있어 최종 사용자 네트워크에 대한 뛰어난 연결성을 보장합니다. 인터넷에는 일반적으로 동일한 소스, 목적지에 대해 패킷을 전송할 수 있는 여러 경로가 있습니다. 자체 네트워크를 사용하지 않는 CDN은 서로 다른 네트워크 경로에서 실시간 성능 측정을 기반으로 인터넷을 통한 오버레이 라우팅을 개발하여 고객에게 추가 비용을 지불하고 제공할 수 있습니다. CloudFront의 경우 Amazon 네트워크의 혼잡 상태를 고려하고 혼잡이 없는 링크를 통해서만 트래픽을 라우팅하는 패킷 라우팅 메커니즘을 기본 기능으로 제공하고 있습니다. 엣지 로케이션과 리전 사이의 특정 링크에서 예기치 않은 트래픽 급증이나 네트워크 중단이 발생하더라도 기본 경로가 영향을 받을 때 트래픽을 대신 처리할 수 있는 대체 경로가 있습니다. 이러한 측면이 사용자가 오리진 가까이에 있고 네트워크에 정체가 없을 때 항상 더 나은 성능으로 이어지는 것은 아니지만, 관리형 네트워크를 사용할 수 있다는 것은 언제나 장점으로 작용합니다. 패킷 손실이 적고 결과적으로 재전송이 적으며, 지터(jitter)가 안정적이고 전반적인 품질의 경험이 향상되는 경우가 많기 때문입니다.
기타 성능 개선 기술
CloudFront는 HTTP/2, HTTP/3과 같은 고성능 프로토콜, 고급 TCP 혼잡 제어 알고리즘인 TCP BBR, 더 빨라진 TLS 버전 1.3(세션 재개 기능 포함)을 사용할 수 있습니다. 특히 HTTP/3은 HTTP/1.1, HTTP/2와 달리 UDP 기반의 QUIC 프로토콜을 사용하여 TCP의 일부 한계를 극복하고, 패킷 손실에 대한 의존도가 낮아 빠른 연결 설정과 효율적인 대역폭 활용이 가능합니다. 배포에서 HTTP/3을 활성화한 CloudFront 고객은 지연 시간을 최대 10%까지 개선했습니다. 다른 게시글에서 CloudFront의 HTTP/3 이점에 대해 자세히 알아보시기 바랍니다.
보안
API 엔드포인트, 로그인 서비스 등의 애플리케이션이 악성 트래픽의 대상이 되는 경우가 많기 때문에 동적 콘텐츠에 대한 보안 태세를 강화해야 합니다. 정적 콘텐츠에 대한 대부분의 요청은 엣지 로케이션에서 제공되므로 DDoS를 흡수하는 데 도움이 됩니다. 그러나 정상적이든 악의적이든 동적 콘텐츠에 대한 모든 요청은, 사전에 탐지하고 완화되지 않는 한 오리진에 도달하게 됩니다. CloudFront는 다양한 방식으로 애플리케이션의 보안 태세를 높일 수 있도록 지원합니다.
L3/L4 인라인 DDoS 완화 시스템
CloudFront로 웹 애플리케이션을 서비스하는 경우, 애플리케이션에 대한 모든 패킷은 인라인 DDoS 완화 시스템으로 검사되기 때문에 지연 시간으로 인한 영향이 없습니다. CloudFront 배포에 대한 L3/L4 DDoS 공격은 실시간으로 완화됩니다. 하지만 리전 리소스의 경우 탐지 로직이 다릅니다. 패킷이 인라인으로 검사되지 않고 인터넷에서 애플리케이션으로 직접 전송됩니다. 대신, 이러한 리소스는 방어가 필요한 DDoS 공격 여부를 확인할 수 있는 트래픽 상승에 대해 모니터링합니다. 각 AWS 리소스에 대한 트래픽은 매분마다 평가됩니다. 이는 CloudFront를 사용할 때보다 탐지 및 완화 속도가 빠르지 않다는 것을 의미합니다.
접근 제어
CloudFront를 사용하려면 오리진이 공용 IP를 사용해야 합니다. 보안을 위해 AWS에서는 오리진 서버에 CloudFront의 IP에서 들어오는 트래픽만 허용하고 애플리케이션으로 직접 들어오는 다른 트래픽은 차단할 수 있는 기능을 제공하고 있습니다. 이를 위해 VPC에서 오리진을 보호하는 보안 그룹에 CloudFront의 관리형 접두사 목록을 사용할 수 있습니다. 또한 사용자 지정 헤더를 전송하도록 CloudFront를 구성하고, 헤더의 존재 여부와 해당 값의 유효성을 검사하여 유효성 검사에 실패하면 요청을 차단하도록 오리진(예: ALB)을 구성하는 것을 권장합니다. 이러한 방법으로 사용자 접근 제어(서명된 URL 또는 서명된 쿠키, 지리적 제한 등)를 구성할 수 있는 CloudFront 배포의 트래픽만 허용할 수 있습니다.
경계 보호 구현
AWS WAF와 AWS Shield Advanced와 같은 경계 보호 서비스는 애플리케이션에 과부하를 줄 수 있는 원치 않는 트래픽을 줄이는 데 도움이 됩니다. AWS WAF 속도 기반 규칙, 봇 컨트롤, ATP(Account Takeover Prevention), Shield 자동 애플리케이션 계층 DDoS 방어 기능뿐 아니라, 요청의 유효성을 확인하고 승인하는 CloudFront 함수는 엣지에서 원치 않는 트래픽을 차단하는 데 큰 도움이 될 수 있습니다. 하지만 일부 AWS 서비스는 AWS WAF 또는 Shield Advanced를 직접 지원하지 않습니다. 예를 들어, API Gateway는 Shield Advanced에서 지원되지 않고, AWS Lambda 함수 URL은 AWS WAF에서 지원되지 않습니다. 이러한 서비스를 사용하는 애플리케이션에 CloudFront를 전면 배치시켜 Shield Advanced와 AWS WAF 보호를 적용하여 보안 태세를 강화할 수 있습니다. CloudFront와 서비스 사이에 API 키 또는 비밀 헤더를 구현함으로써, 해당 요청은 자격을 갖고 있는 CloudFront 에게만 제공되며, 오리진과 HTTPS 통신시에 패킷이 암호화되어 가로채기 공격을 받더라도 패킷 내용을 파악하는 것이 어려워지게 됩니다.
그림 4: 경계 보안
비용 혜택
CloudFront는 데이터 전송 요금을 낮출 수 있습니다. AWS 오리진에서 CloudFront로의 데이터 전송 요금은 발생하지 않지만, CloudFront 데이터 전송 요금은 발생합니다. 다시 말해, AWS 오리진의 데이터 전송 비용은 CloudFront 데이터 전송 비용으로 대체되는 것입니다. 다만, 이는 더 적은 비용이고 일반적으로 월 10TB 이상의 최소 트래픽 약정을 하거나 CloudFront Savings Bundle을 사용할 경우 더욱 감소할 수 있습니다. 또한 CloudFront는 인터넷으로 1TB의 데이터 전송과 매월 1,000만 건의 HTTP 또는 HTTPS 요청이 무료인 프리 티어도 제공합니다. 그리고 Amazon EC2의 데이터 전송은 TLS를 포함한 회선의 모든 바이트를 계산하는 반면 CloudFront 데이터 전송은 응답에서 TLS 인증서 교환에 해당하는 부분을 제외한 바이트만 계산합니다. 성능 부분에서 설명한 바와 같이 지속적인 연결을 통한 오리진 오프로드를 사용하면 ALB LCU 비용을 절감할 수 있습니다. 또한 Shield Advanced에서 보호 리소스가 CloudFront 배포인 경우, Amazon EC2와 ALB가 보호 리소스가 되는 것에 비해 데이터 전송 비용이 두 배 더 저렴합니다. 마지막으로, Shield Advanced 구독에는 웹 액세스 제어 목록(웹 ACL), 규칙 및 웹 요청에 대한 기본 AWS WAF 요금이 포함되어 있습니다.
그림 5: CloudFront 비용 구조
Lambda@Edge, CloudFront 함수, 실시간 로그, Origin Shield, 매달 제공되는 무료 요청 건수를 넘는 무효화 요청과 같은 추가적인 CloudFront 기능은 트래픽 비용에 포함되지 않으며 별도로 청구됩니다.
결론
이 게시글에서는 CloudFront가 동적 콘텐츠에 제공할 수 있는 이점에 대해 알아보았습니다. 사용자에게 콘텐츠 전송을 가속화하고, 악성 트래픽으로부터 애플리케이션을 보호하며, 데이터 전송 요금을 절감하는 등 CloudFront는 여러 가지 면에서 도움이 될 수 있습니다. 특정 동적 워크로드에 CloudFront를 사용하도록 설정하고 성능 개선, 보안 및 비용 효과를 테스트 하는 것을 고려해 보시기 바랍니다.