[Cloudfront] 캐싱이 필요하지 않은 서버에도 Cloudfront를 앞단에 설정할 필요가 있을까?

Contents

개요

Cloudfront(이하 CF)의 캐싱기능이 필요하지 않은 서버들의 유형들이 있다.

예를 들면 동적으로 콘텐츠를 제공해야 하는 애플리케이션이 있다. 동적인 콘텐츠를 제공해야 하는 애플리케이션 같은 경우 캐싱 설정을 하게 되면 사용자는 이전에 캐싱된 데이터를 받아 잘못된 데이터가 사용자에게 제공될 수 있는 문제가 발생할 수도 있다.

CF가 콘텐츠를 빠르게 제공할 수 있는 대표적인 이유는 바로 POP서버에 콘텐츠를 캐싱하고 유저는 위치에 가까운 POP 서버에 캐싱된 콘텐츠에 접근하는 게 대표적인 이유일 것이다.

따라서 캐싱이 필요하지 않은 서버는 굳이 CF를 안두어도 되지 않나?라는 생각이 든다.

 

동적 콘텐츠 캐싱의 문제점

정적 콘텐츠마냥 동적 콘텐츠에 캐싱 설정을 하게 될 경우 오래되거나 잘못된 데이터가 사용자에게 제공될 수 있기 때문에 일반적으로 권장되는 사항은 아니다.

이러한 캐싱 문제때문에 동적 콘텐츠를 제공하는 서버에는 CF를 아예 두지 않는 경우가 일반적일 것이다.

하지만 CF를 아예 두지 않게 되면 CF를 설정함으로써 가져오는 이점들을 모두 포기하는 셈이다.

 

그러면 우리는 어떻게하면 동적 콘텐츠를 잘 제공하면서도 CF의 이점을 사용할 수 있을까?

 

TTL을 0으로 설정하기

방법은 간단하다. 동적 콘텐츠를 서빙하는 서버에 CF를 설정하고 TTL을 모두 0으로 설정하는 것이다.

 

Cache-Control: no-cache, no-store, must-revalidate

그러나 이렇게 설정하면 객체에 대해 캐싱을 전혀 하지 않아 동적 콘텐츠 제공에 문제가 안 생길 것이고 CF도 사용할 수 있을 것이다.

하지만 이렇게 설정을 하게되면 CF POP에 캐싱을 전혀 하지 않는다는 것을 뜻하고 매번 사용자의 요청마다 POP → Edge Caches → Origin 경로로 객체를 가져와서 서빙하게 될 텐데 오히려 Latency가 더 길어지지 않을까?라는 의문이 생길 수도 있다.

 

그러나 아래에 소개할 내용으로 인해 CF를 설정하면 오히려 콘텐츠 전송 속도 향상을 가져온다.

콘텐츠 전송 속도 향상의 메커니즘

별도의 캐싱설정을 하지 않아도 CF를 거치게 되면 대체 왜? 콘텐츠의 전송 속도가 향상이 될까?

먼저 일반적인 상황에서의 콘텐츠를 전송하는 과정을 먼저 살펴보자.

1. Client가 객체에 Request를 날리면 먼저 DNS Lookup을 하게 된다.
2. 이후 서버와 TCP/SSL Connection을 수행한다.
3. TTFB(TIme to First Byte)를 기다린다.
4. 콘텐츠를 다운로드한다.

위의 과정을 거쳐야 콘텐츠가 전송되었다고 볼 수 있을 것이다.

CF는 다음의 네 가지 요인으로 콘텐츠 전송 과정에 영향을 끼쳐서 콘텐츠 전송 속도를 향상 시키게 된다.

 

1️⃣ 최적화된 네트워크

CF의 POP과 Region 사이의 네트워크는 지속적으로 모니터링 되고 성능 및 가용성면에서 최적화된다.

또한 다른 네트워크 경로로 자동으로 라우팅하기 때문에 End 유저에게 미치는 영향을 최소화한다.

 

이를 통해서 더 적은 패킷 감소와 더 나은 성능을 기대할 수 있다.

2️⃣ Origin과의 지속적인 연결유지 (Keepalive)

POP과 Origin으로의 연결을 유지하고 재사용하여 수백 ms가 소요되는 TCP 연결 설정 시간을 줄여준다.

 

3️⃣ TCP/IP 최적화

CF의 모든 호스트에는 POP과 End 유저간의 시시때때로 변하는 네트워크 대역폭 사용을 최대화하기 위해 TCP initcwnd (initial congestion window) 값이 최적화되어있다.

 

4️⃣ Gzip 압축 사용

콘텐츠에 Gzip 압축을 사용하여 데이터의 크기를 줄일 수 있고 트래픽도 줄일 수 있다.

특히나 동적 콘텐츠는 대부분 매우 높은 압축률을 보여주는 텍스트 형태이기 때문에 압축을 통한 효율이 더 높다.

---

위의 네 가지 요인 외에도 CF는 지속적으로 Latency를 측정하여 End 유저가 더 나은 POP으로 연결하도록 한다.

이러한 요인들을 바탕으로 어떻게 CF에서 콘텐츠의 전송 속도를 향상하여 전송할 수 있는지 알 수 있다.

1. Client가 객체에 Request를 날리면 먼저 DNS Lookup을 하게 된다.
   • CF의 라우팅 기술, Route53과의 통합
2. 이후 서버와 TCP/SSL Connection을 수행한다.
   • CF의 연결유지 (Keepalive)
3. TTFB(TIme to First Byte)를 기다린다.
   • CF의 연결유지 (Keepalive), Gzip 압축
4. 콘텐츠를 다운로드한다.
   • CF의 TCP/IP 최적화, Gzip 압축

콘텐츠 전송 속도에 대해 Cloudfront를 설정하기 전과 후를 비교해 놓은 자료는 아래의 링크를 참고하자.

• https://aws.amazon.com/ko/blogs/korea/how-to-improve-dynamic-contents-delievery-using-amazon-cloudfront/

 

결론

캐싱이 필요하지 않은 서버여도 Latency가 중요하다면 CF를 두고 TTL을 0으로 설정하자. 소개한 메커니즘으로 Latency를 최소화할 수 있는 효과가 있다.

 

마치며

지금껏 캐싱이 필요하지 않을 경우 CF를 두어야 하나 말아야 하나에 대해서 헷갈렸었는데 확실히 그 메커니즘을 알게 되니 생각 정리가 되었다. 나중에 CF를 설정하기 전과 후의 Latency를 직접 측정해 봐야겠다.

 

 

Reference

• https://medium.com/@autumn.bom/cloudfront-dynamic-content-14efc11a5b3
• https://aws.amazon.com/ko/blogs/korea/how-to-improve-dynamic-contents-delievery-using-amazon-cloudfront/