Engineering

CloudFront의 숨은 힘: 캐싱 없이도 극대화 되는 성능과 비용 효율성

원티드

2024년 12월 19일

원문에서 보기 ↗

부제: CloudFront를 동적 콘텐츠에도 사용해보세요~!

CloudFront에 대한 고정관념

CloudFront에 대해 흔히 가지고 있는 두 가지 오해가 있습니다:

정적 콘텐츠만의 영역이라고 생각 하는점.

HTML, CSS, JavaScript, 이미지, 미디어 파일과 같은 정적 자원을 빠르게 전송하기 위한 도구로만 인식
동적 콘텐츠 처리에는 부적합 하다는 편견

캐싱이 CloudFront의 주요 목적?

CloudFront 사용의 주된 이유가 캐싱이라고 잘못 인식
캐싱을 사용하지 않으면 큰 이점이 없다고 생각

원티드 서비스 전반에 Cloudfront 적용하고 있습니다.

동적웹페이지, API 같은 동적 콘텐츠에도 사용하고 있습니다.

캐싱을 사용하지 않지만, 유의미한 성능/비용 개선을 이루었습니다.

원티드 서비스에 CloudFront를 적용한 내용을 시리즈로 글을 작성해 보려고 합니다.

이 글에서는 CloudFront를 사용했을때 자동으로 주어지는 장점에 대해서 소개 합니다.

1. 접속지점(PoP 또는 Edge)을 활용한 최적화

사용자와 서버는 지리적으로 가까울수록 속도는 빨라집니다.

❌ Cloudfront 사용하지 않았을때:

부산 사용자는 서울 사용자와 비교하여 지리적으로 불리 합니다.

부산 사용자는 서울 리전까지 요청이 가야 합니다.

✅ Cloudfront 사용 했을때:

사용자와 가장 가까운 접속지점(PoP / Edge)에 연결이 됩니다.

그 다음, Amazon Global Network (= AWS 전용 네트워크망)를 통해 이동하는데, 이는 일반 인터넷에 비해 속도가 빠르고 성능이 뛰어납니다.

또한, Connection 과정이 가까운 접속지점(PoP / Edge)에서 일어나기 때문에, Connection 시간이 크게 단축 됩니다.

한국에 접속지점(PoP / Edge)가 몇개가 있을까?

AWS의 한국 내 엣지 로케이션(Edge Location)은 꾸준히 확장되어 왔습니다.

흥미로운 점은 공식 발표된 것보다 실제 운영되고 있는 엣지 로케이션이 더 많다는 사실입니다.

https://aws.amazon.com/ko/about-aws/whats-new/2018/02/amazon-cloudfront-launches-fourth-edge-location-in-seoul-south-korea/

2018년: 네 번째 엣지 로케이션 추가 공지
이후 추가 확장에 대한 공식 발표는 없었음

“AWS Edge 스페셜리스트와의 미팅에서 확인한 결과, 현재 한국에는 총 8개의 접속 지점(PoP/Edge)이 운영되고 있습니다.” (2024년 6월 기준)

AWS가 한국 시장에서 콘텐츠 전송 네트워크(CDN) 서비스의 품질 향상을 위해 지속적으로 투자하고 있음을 보여주는 좋은 예시입니다.

2. Amazon Global Network

사용자와 가장 가까운 접속지점(PoP / Edge)에 연결이 되면, AWS Global Network를 이용하여 빠르게 오리진 원본서버로 요청을 전달합니다.

❌ Cloudfront 사용하지 않을때:

공용 인터넷 네트워크 사용하여 라우팅이 일어나게 됩니다.

경로가 변경될 수 있으며 여기저기서 패킷 손실과 혼잡이 발생할 수 있습니다.

✅ Cloudfront 사용할때:

공용 인터넷 대신 AWS 글로벌 네트워크를 통한 트래픽 라우팅이 일어나며, 아래와 같은 성능 최적화가 일어납니다.

네트워크 지터 2배 감소
네트워크 대기 시간 30% 단축

네트워크 지터 (Network Jitter) 란?

네트워크에서 데이터 패킷이 도착하는 시간의 불규칙성이나 변동 을 말합니다.

예를 들어

버스를 기다리는 상황을 생각해 볼 수 있습니다.

- 이상적인 상황: 버스가 정확히 10분 간격으로 도착

- 지터가 있는 상황: 버스가 때로는 5분 일찍, 때로는 15분 늦게 도착

네트워크에서도 이와 비슷합니다.

- 패킷(데이터)이 불규칙한 시간 간격으로 도착

- 이로 인해 통화 품질 저하, 비디오 끊김, 게임 지연 등이 발생

지속적인 연결 (Persistent Connection Reuse)

접속지점(PoP / Edge)에서 오리진 서버로 지속적인 연결 유지되고, 한 번 만든 연결을 여러 사용자가 재사용 할 수 있습니다. 새로운 연결 수립에 드는 시간과 비용 절감 되고, 전체 네트워크 성능 향상 도움이 됩니다.

3. HTTP Connection 과정 최적화

크롬 개발자도구 > 네트워크 > timing 탭

크롬 개발자도구에서 볼수 있는 HTTP Connection 과정에 정보입니다.

DNS Lookup: 클라이언트가 DNS 쿼리를 DNS서버로 보내고, IP주소를 응답 받습니다.
Connection: 클라이언트가 IP주소로 연결을 설정합니다.
SSL: 클라이언트와 서버가 안전한 암호화 연결을 위해 암호화 방식을 협상하는 과정 입니다.

CloudFront 도입 후,

HTTP Connection전체 과정이 481ms에서 319ms로 단축되어 33.5% 성능이 개선 되었습니다.

HTTP connection 성능 비교

세부 성능 분석 결과:

DNS Lookup : 38.6ms에서 225ms로 변화했으며, 이는 사용자와 가장 가까운 접속 지점(PoP 또는 엣지)을 탐색하는 과정에서 발생한 지연으로 분석됩니다.
Connection: 206ms에서 31.3ms로 획기적으로 개선되었습니다.
SSL Negotiation: 236.6ms에서 63ms로 대폭 단축되었습니다.

특히 Connection과 SSL Negotiation 시간의 개선은 지리적으로 가까운 접속 지점(PoP / Edge)과 HTTP/3 기술이 결합되어 달성된 결과로 보입니다.

4. HTTP/3: 최신 프로토콜 성능

https://aws.amazon.com/ko/blogs/korea/new-http-3-support-for-amazon-cloudfront/

HTTP/3를 사용하면 위에서언급했던, HTTP Connection과정에서 Connection 과 SSL Negotiation 단계를 이 두 단계 과정을 최적화 할 수 있습니다.

CloudFront에서 HTTP/3 활성화 방법

HTTP/3 + TLS1.3

CloudFront에서 HTTP/3를 활성화하면 TLS 1.3이 자동으로 적용되어, 네트워크 통신의 성능과 보안을 동시에 강화할 수 있습니다.

http/3는 intial connection 과정을 최적화하고, TLS1.3은 SSL 과정을 최적화 합니다.

Connection 과정의 왕복(RTT) 최적화

클라이언트와 서버 간 통신에서 연결 설정은 전통적으로 여러 번의 왕복(Round Trip Time, RTT)을 필요 로 했습니다. 이 왕복 횟수를 줄이는 것이 바로 네트워크 성능 최적화의 핵심입니다.

프로토콜별 연결 왕복 비교

HTTP/2 + TLS 1.2 → 3회 (3 RTT)
HTTP/3 + TLS 1.3 → 1회 (1 RTT)

HTTP/3와 TLS 1.3의 조합은 기존 HTTP/2와 TLS 1.2에 비해 연결 설정 시간을 크게 단축 시킵니다.

HTTP/2의 Head-of-line Blocking 문제 극복

Head-of-Line Blocking 이란?

한 줄로 선 사람들이 앞사람 때문에 뒷사람이 멈춰서야 하는 것과 비슷합니다. HTTP/2에서는 여러 요청을 하나의 TCP 연결을 통해 전송하는데, TCP 레벨에서 패킷 손실이 발생하면 모든 스트림이 영향을 받게 되는 현상을 말합니다.