회사에서 운영 중인 대부분의 서비스들의 웹서버가 AWS의 Elastic Beanstalk로 구성되어 있다. 기존에는 Beanstalk에 직접 DNS를 설정하여 운영중이었는데 WAF(Web Application Firewall) 구성을 위해 Beanstalk 앞에 CloudFront를 연동 한 뒤, TTL(Time to live)을 0으로 설정하여 매번 원본 저장소에서 콘텐츠가 전송되도록 설정했는데도 서비스가 빨라진 느낌적인 느낌을 받았다.

빨라진 느낌을 객관화하기 위해 CloudFront 연동 전/후 서비스의 페이지 로드 시간과 API Latency를 테스트 했는데 약 1.6배 정도 속도 향상이 있었다.  TTL을 0으로 설정했는데도 빨라진 이유는 ‘Edge 서버와 Origin 서버가 AWS 내부망으로 연결되어 있어 더 빠르겠지’ 하는 막연한 추측만 갖고 있었다.
* CloudFront 연동 전/후의 속도 차이는 테스트 환경과 Origin 서버의 지리적인 거리에 직접적인 영향을 받기 때문에 차이가 발생 할 수 있습니다. 저는 Ireland에 구축된 웹서버를 기준으로 테스트 했습니다.

나의 막연한 추측을 기술적으로 설명해주는 2개의 글을 읽고, 페이지 로드 시간이 빨라진 이유를 이해하게 됐다.

글에서 설명하는 이유를 정리하면 아래와 같다.

요청에 대한 응답 시간은 크게 4가지 요소의 합이다.
응답 시간 = DNS Lookup + TCP Connection + Time to First Byte + Content Download

  • CloudFront의 Edge 서버와 Origin 서버는 Keep Alive Connection을 통해 연결을 유지 및 재사용하기 때문에 TCP 3-way handshake 과정에서 SYN, SYN-ACK, ACK 과정을 생략 할 수 있는 경우가 많다.  지리적으로 거리가 떨어진 경우 높은 RTT(Round-Trip Time)로 인해 위의 SYN, SYN-ACK, ACK 과정의 생략을 통해 얻을 수 있는 속도 향상이 크다. Edge와 Origin과의 Keep Alive Connection을 통한 속도 향상은 TTFB(Time to First Byte) 시간의 감소로 확인 할 수 있다.
  • Gzip 압축을 통해 실제 전송되는 컨텐츠의 크기를 줄임으로써 Content Download에 필요한 시간을 줄일 수 있고, 비용도 절감 할 수 있다.
  • AWS Edge 서버와 Origin 서버 사이의 네트워크는 고성능 및 가용성을 유지함으로써 Content Download에 필요한 시간을 줄일 수 있다.
  • CloudFront의 최적의 라우팅 기술이 Route 53의 LBR(Latency Based Routing)과 통합되어 DNS Lookup 시간을 단축 할 수 있다.

 

결론

  • CloudFront의 Cache 기능을 사용하지 않는다고 하더라도 CloudFront 연동을 통해 1.6~1.8배 사이의 성능 향상을 기대 할 수 있다.
  • CloudFront에서 L3/L4 Flood Attack을 방어해주기 때문에 설정하는 것 만으로도 DDoS 방어 효과가 탁월하다.
  • CloudFront + WAF 구성을 통해 일반적인 웹 취약점 공격으로부터 보호하는 데 도움이 된다.
  • CloudFront의 gzip 옵션을 통해 전송되는 콘텐츠의 사이즈를 줄여 비용을 절감 할 수 있고, 콘텐츠 전송 속도를 줄일 수 있다.
  • GB당 컨텐츠 전송 비용은 설정 전/후 큰차이를 보이지 않는다. 다만 텍스트와 같이 gzip 옵션을 통해 높은 압축 효과를 기대 할 수 있는 콘텐츠의 경우는 비용 절감 효과도 기대 할 수 있다.
  • 속도와 보안 두마리 토끼를 잡을 수 있으니 CloudFront를 설정하지 않을 이유가 없다.