웹에 날개를 달아주는 웹 성능 최적화 기법 Chapter7

By Gyumyung Lee
book

웹에 날개를 달아주는 웹 성능 최적화 기법

  • 본 책을 읽고 책의 내용을 간략하게 정리한 글입니다.

Chapter 7. CDN

CDN을 사용하는 이유

  • CDN 서비스 이용 시 이점
    1. 성능 및 안정성 보장
      • CDN 업체들은 많은 수의 POP (Point Of Presence) 보유
      • POP가 많을수록 인터넷 병목 구간을 피할 수 있어 캐시된 컨텐츠를 더 많은 사용자에게 더 빠르게 전달 가능
      • POP 간 failover 기능이 있어 몇 개의 POP이 정지해도 다른 POP에서 서비스할 수 있어 끊김 없이 서비스 제공 가능
    2. 아키텍처 단순화
      • 원본 애플리케이션을 재배포하는 방식이 아니므로 애플리케이션 수정이나 동기화 방안 등을 고려하지 않아도 됨
    3. 높은 비즈니스 투자 수익
      • 데이터 센터를 따로 만들지 않아도 되므로 글로벌 시장에 디지털 서비스를 쉽게 제공 가능
      • CDN은 사용한 트래픽만큼 비용을 지불하고 그 원가가 굉장히 저렴해 투자 대비 효율성이 높음
  • CDN의 특징
    • 동적 컨텐츠 가속
    • 프론트엔드 최적화
    • 동영상 또는 라이브 스트리밍 서비스
    • 클라우드 보안

CDN의 원리

CDN 서비스 아키텍처
  • CDN 서비스는 컨텐츠를 제공하는 원본 서버와 실제 인터넷을 통해 컨텐츠를 사용하려는 최종 사용자들 사이에서 리버스 프록시 형태로 존재
  • CDN 업체들은 사용자들이 많은 지역에 가능한 더 많은 서버들을 배치
  • 사용자와 가장 가까운 곳에 위치한 엣지 서버 (edge server)들을 배치하고 전 세계 또는 특정 지역에 여러 개의 POP을 만들어 엣지 노드들을 구성
CDN 동작 방법
  1. CDN 사용하면 브라우저가 웹 사이트 IP 주소를 조회할 때 호스팅 조직의 DNS 서버는 자사 서버의 IP 대신 CDN 서비스 제공자의 도메인명을 반환
  2. 사용자 브라우저는 CDN 서비스 제공자의 DNS 서버에 해당 도메인명에 대한 IP를 다시 요청하고 CDN 업체의 DNS 서버는 사용자와 가장 가까이 위치한 엣지 서버 IP를 최종 반환
  3. 엣지 서버의 IP를 받은 브라우저는 사용자 요청을 해당 엣지 서버로 보냄
  4. 엣지 서버는 캐시된 컨텐츠를 사용자에게 반환하거나 캐시되어 있지 않은 경우 원본 서버에서 컨텐츠를 받아와 캐시한 후 응답
CDN 적용 방법
  • 실제 CDN을 적용할 때 직접 소스 코드를 수정하지 않고 DNS만 변경하면 됨
  1. 원본 서버로 사용할 호스트명과 IP를 네임 서버의 A 레코드로 추가
    • 기존에 서비스하던 도메인명이 www.example.com 이라면 네임 서버에는 www.example.com 에 대한 IP 정보가 A 레코드에 저장되어 있음
    • 여기에 org-www.example.com 이라는 이름의 새로운 도메인을 생성하고 www.example.com 과 동일한 IP를 가지도록 A 레코드를 추가
    • Authoritative Name   Server  Records
www.example.com      IN  A   106.10.178.36
org-www.example.com  IN  A   106.10.178.36
  2. CDN 설정에 원본 서버의 호스트명으로 org-www.example.com 등록
    • 이는 CDN 네트워크 내의 엣지 서버들이 원본 컨텐츠를 찾기 위해 www.example.com 이 아닌 org-www.example.com 으로 접속해야 한다는 의미
    • 만약 CDN의 원본 서버로 www.example.com 을 등록할 경우 이후 세 번째 단계에서 HTTP 요청이 CDN 내에서 무한 루프에 빠질 수도 있으니 주의
  3. 기존 도메인에 부여되어 있던 IP 정보를 CDN 서비스 제공자의 도메인명으로 변경
    • DNS 서버에 등록된 도메인명에 다른 도메인 정보를 부여하는 것을 CNAME 레코드라고 함
    • 원하는 CDN 업체에 서비스를 신청하면 업체는 고유한 도메인명을 생성해 알려줌, 이 도메인 정보를 자사 네임 서버에 CNAME으로 등록하면 됨
    • Authoritative Name   Server  Records
www.example.com      IN  CNAME   www.example.com
org-www.example.com  IN  A   106.10.178.36

다중 캐시 전략

캐시 축출
  • 컨텐츠가 CDN 서버에 캐시된 후 지정된 만료일까지 온전히 캐시되어 있진 않음
  • 용량이 일정 한계치에 도달하면 캐시된 컨텐츠에 우선순위를 부여해 낮은 순위의 컨텐츠부터 삭제하는데 이를 캐시 축출이라고 함
  • CDN 업체 공통적으로 다음 사항들이 적용
    1. 일정 기간 캐시 적중이 없었던 컨텐츠
      • 마지막 캐시 적중 이후 오랜 기간 해당 컨텐츠에 재방문하지 않았을 경우 가장 먼저 삭제
    2. 캐시 적중률이 미미한 컨텐츠
      • 1번 사항에 해당하는 컨텐츠가 없으면 캐시 적중률을 비교해 적중률이 낮은 컨텐츠부터 삭제
    3. 더 오래된 컨텐츠
      • 캐시 적중률이 동일하다면 캐시에 더 오래 남아 있었던 컨텐츠가 삭제
롱테일 컨텐츠
  • 생성 초기 많이 조회되다가 짧은 시간이 흐른 후 조회 수가 줄고 이후 거의 조회되지 않는 컨텐츠
  • 이러한 현상은 웹 사이트 내 컨텐츠 종류가 많을수록 그리고 사용자 층이 여러 국가에 넓게 퍼져 있을수록 심화
캐시 서버 간 캐시 컨텐츠 공유
  • 캐시된 컨텐츠가 전 세계에 분산된 엣지 서버들 사이에서 하나의 서버를 사용하는 것처럼 공유될 수 있다면 해당 컨텐츠의 캐시 적중률은 높아질 것
  • 엣지 서버 간 캐시 공유는 ICP (Internet Cache Protocol) 와 같은 특별한 프로토콜을 사용해 빠르게 이루어져야 함
  • 일반적으로 동일한 POP 서버들은 캐시된 컨텐츠를 서로 공유할 수 있음
다중 계층 캐시
  • 전 세계에 흩어져 있는 캐시 컨텐츠들을 공유하기 위해 다중 계층 캐시 전략을 사용할 수 있음
  • 다중 계층 캐시란 엣지 서버들과 원본 서버 사이에 추가 캐시 서버 계층(부모 계층)을 두어 같은 컨텐츠를 여러 번 캐시하는 방식
  • 추가 캐시 계층을 통한 공유 효과를 얻으려면 다음 조건을 만족해야 함
    1. 부모 계층은 원본 서버에 가까이 존재해야 함
    2. 부모 계층의 캐시 서버 수가 자식 계층의 캐시 서버 수보다 훨씬 적어야 함
  • 캐시 적중률 향상
    • 캐시 서버들은 부모 계층의 캐시 서버들을 사용해 컨텐츠를 공유할 수 있음
    • 부모 계층의 엣지 서버에 컨텐츠가 캐시되면 자식 계층의 나머지 엣지 서버들은 원본 서버에 컨텐츠를 요청할 필요 없이 부모 계층에서 캐시된 컨텐츠를 받아 서비스
    • 부모 계층 캐시 서버들의 캐시 적중률이 향상되고, 이로 인해 캐시된 컨텐츠가 캐시 서버에서 축출될 확률도 낮아짐
  • 과도한 트래픽으로부터 원본 서버 보호
    • POP 수가 많을수록 원본 서버의 트래픽은 늘어나지만 사용자에게 응답하는 속도가 빨라짐
    • 이 떄 다중 계층 캐시를 사용하면 사용자의 응답 속도를 떨어뜨리지 않으면서 원본 서버로의 트래픽을 획기적으로 줄일 수 있음
  • 사용자 요청에 대한 응답 속도 향상
    • TTL 주기가 짧을 수록 원본으로 접속하는 요청이 많아지면서 평균 응답 속도에 영향을 미침
    • 다중 계층 캐시를 사용하면 자식과 부모 엣지 서버 사이에 전달 경로 최적화가 적용되므로 사용자 요청에 더 빠르게 응답 가능

전달 경로 최적화

  • 전달 경로를 최적화할 떄 경로를 라스트 마일, 미들 마일, 퍼스트 마일 세 구간으로 나눌 수 있음
    • 라스트 마일: 최종 사용자와 CDN 엣지 서버 간 구간
    • 미들 마일: CDN 네트워크 구간
    • 퍼스트 마일: 엣지 서버와 원본 서버와의 구간
라스트 마일 최적화
  • 최종 사용자 요청을 가장 가까운 곳에 있는 엣지 서버로 전달하는 것
  • CDN에서 일반적으로 사용하는 가장 가까운 엣지 서버 선택 방법
    • DNS 기반 엣지 선택
      • 자사 DNS 서버로 특정 웹 사이트 도메인명에 대한 쿼리가 요청되면 사용자의 로컬 DNS와 가장 가깝고 사용량이 적은 엣지 서버의 IP 반환
      • 사용자의 로컬 DNS IP 정보는 DNS 쿼리에 포함되어 있어 이를 활용해 사용자 위치 정보 짐작
    • 애니캐스트 기반의 엣지 선택
      • 애니캐스트 역시 네트워크상에서 원하는 IP 주소로 데이터를 전송하는 방식
      • 애니캐스트는 1:1 전송 방식이지만 유니캐스트와는 다르게 다수 노드가 같은 IP 주소를 가짐
      • 보내는 측이 그 IP 주소로 메시지를 보낼 때 네트워크상 가장 가까운 노드를 선택해 전송하는 방식
      • 애니캐스트 기반으로 엣지를 선택하는 장점은 실제 사용자와 가장 가까운 네트워크의 엣지 서버가 선택된다는 점과 서버 장애 시 자동 우회하여 가용성이 어느정도 보장된다는 점
  • CDN 업체에서 일반적으로 트래픽 분산하는 방법
    • 비율에 따른 트래픽 분산
      • 각 데이터 센터로 전송하는 트래픽을 지정한 비율에 맞춰 분산
    • 지역에 따른 트래픽 분산
      • 지역을 구분하여 가장 가까운 데이터 센터로 HTTP 요청을 보내 빠르게 처리하도록 함
    • 성능에 따른 트래픽 분산
      • 각 데이터 센터의 성능을 고려해 트래픽 분산
프로토콜 최적화
  • 경로 최적화가 빠른 길을 찾는 과정이라면 프로토콜 최적화는 한번에 많은 트래픽을 보낼 수 있도록 길을 넓히는 작업
  • TCP 최적화
    • TCP는 혼잡 상황을 제어하기 위해 느린 시작 (slow start)이라는 알고리즘을 사용하는데 느린 시작이란, 송신 측이 전송을 시작할 때 적은 양의 데이터로부터 전송하는 것을 의미
    • 이렇게 전송하는 데이터 크기를 혼잡 윈도우라고 함
    • 느린 시작 알고리즘
      1. 초기 혼잡 윈도우에 정해진 만큼 데이터 패킷 전송
      2. 문제가 없으면 혼잡 윈도우 값은 제곱으로 증가
      3. 네트워크가 혼잡해 재전송 타임아웃 (RTO; Resubmit Time Out) 이 발생하면 현재 혼잡 윈도우의 절반 값으로 임계치가 설정되고 처음부터 다시 전송 시작
      4. 이후 혼잡 윈도우 값이 정해진 임계값보다 커지면 혼잡 회피를 위해 혼잡 윈도우 값은 제곱이 아닌 선형으로 증가
      5. 이후 임계값은 패킷 유실이나 네트워크 에러, 중복 응답 등에 따라 다른 방식으로 계산되어 정해짐
  • CDN 구간에서 최적화하는 방법
    1. 초기 혼잡 윈도우 값을 늘려 한 번에 많은 데이터 패킷을 보낼 수 있게 함
    2. RTO 값을 낮춰 실패한 패킷을 빠르게 재전송
  • TLS 종료와 TCP 연결 재사용
    • HTTP 통신을 위해 클라이언트와 서버는 TCP 연결을 맺기 위한 3-way-handshake 수행
    • 추가로 상호 인증서를 확인하고 메시지를 암호화하기 위한 TLS handshake 수행
    • CDN 제공자들은 효율성을 높이기 위해 원본 서버와의 TCP 연결을 바로 끊지 않고 이미 생성된 연결들을 재사용함
    • 최종 사용자는 멀리 떨어진 원본 서버가 아닌 가장 가까운 엣지 서버와 TCP, TLS handshake를 수행하므로 응답 속도개 개선됨

기타 성능 옵션

  • CDN 서비스를 사용하는 장점 중 하나는 웹 사이트 호스팅 서버에서 제공하지 못했던 기능을 CDN이 제공해준다는 점
CDN이 대신 제공하는 기본 기능
  • HTTP 압축
    • CDN 서비스를 사용 중이라면 엣지 서버는 기본적인 텍스트 파일 포맷에 위와 같은 gzip 압축을 적용해 브라우저로 전송
    • JSON 파일이나 SVG 이미지 파일, EOT, TTF 등의 폰트 파일은 압축할 수 있지만 쉽게 누락되는 파일 형식
    • CDN이 제공해주는 압축은 엣지 서버와 브라우저 네트워크 구간에만 적용됨
      • 호스팅 서버와 엣지 서버 사이의 네트워크 구간을 가속화하려면 서버 측에서 압축 설정해야 함
  • 브라우저 캐시
    • 브라우저 캐시는 쉽고 확실하게 성능을 향상시키는 기능이지만 동작 방식을 알지 못해 잘못 사용하는 경우가 많음
    • CDN 서비스 브라우저 캐시 이용 시 주의사항
      • 서버가 CDN에 컨텐츠를 캐시하기 위해 Cache-Control: max-age 나 expire 헤더를 사용할 필요 없음
      • 그렇다고 Cache-Control을 사용하지 않으면 브라우저 캐시를 이용할 수 없음
      • 대부분의 CDN 업체는 브라우저를 위한 Cache-Control을 어떻게 처리할 것인지 옵션 제공
        1. CDN에 설정한 TTL 값을 그대로 사용
        2. 서버에서 응답한 헤더를 그대로 브라우저로 전송
        3. CDN에 설정한 캐시 주기와 서버 응답 헤더의 캐시 주기 중 더 길게 남은 값 사용
        4. CDN에 설정한 캐시 주기와 서버 응답 헤더의 캐시 주기 중 더 짧게 남은 값 사용
        5. 브라우저 캐시 사용하지 않음
  • HTML, CSS, 자바스크립트 최소화
    • 엣지 서버에서는 응답 컨텐츠에서 공백, 주석 등을 제거해 캐시한 후 같은 요청에 대해 이미 최적화된 컨텐츠 제공
  • DNS 프리패치와 프리커넥트
    • 웹 개발자는 <link> 태그를 사용해 브라우저에 성능 개선 힌트를 줄 수 있음
    • // 앞으로 사용될 도메인의 IP 정보를 미리 쿼리하라는 의미
<link rel="dns-prefetch" href="//image.example.com">
    • 리소스를 다운로드할 도메인이 많은 경우 미리 도메인명의 IP를 찾으면 브라우저가 실제로 해당 리소스를 다운로드하는 시점에 IP 검색 시간을 줄일 수 있음
    • 모든 웹 페이지에 <link> 태그를 삽입하기 어렵다면 CDN에서 제공하는 DNS 프리패치 기능을 사용할 수 있음
    • 소스에 직접 <link> 태그를 삽입하기보다 HTTP 응답에 Link 헤더를 추가해 도메인에 IP를 미리 조회
    • Link: <http://image.example.com>; rel=dns-prefetch
    • 최근에는 TCP 연결까지 미리 생성하는 프리커넥트가 추가됨
    • Link: <http://image.example.com>; rel=preconnect
신기술 적용을 위한 CDN 기능
  • HTTP/2와 HTTP/3
    • CDN 네트워크에서 HTTP/2는 대부분 브라우저와 엣지 서버 사이 구간에서만 캐시할 수 있는 정적 컨텐츠를 가속하는 데 사용
    • 원본 서버의 HTTP/2 지원 여부와 상관 없이 이를 적용하고 사용자들에게 HTTP/2의 이점을 제공할 수 있음
    • HTTP/3는 HTTP/2 보다 빠르고 안전한 차세대 프로토콜로써 활발하게 표준화 논의 진행 중
  • 서버 푸시
    • 리소스에 대한 다운로드 요청을 보내지 않아도 필요한 자원들을 미리 전송해주는 기능
    • 서버 푸시는 푸시 대상을 지정하는 방식에 따라 구분
      1. CDN에 푸시할 자원들을 미리 지정하는 방식
      2. 웹 페이지에 푸시할 리소스를 태그로 지정하는 방식
    • 푸시 서비스를 잘 활용하면 큰 수고 없이 웹 사이트 렌더링 속도를 개선할 수 있으므로 사용 권장
  • IPv6 듀얼 스택
    • IPv4로 할당할 수 있는 IP 주소는 이미 포화 상태
    • IETF (Internet Engineering Task Force)에서 IP 주소의 필요성을 이미 인식해 IPv6 표준을 만듬
    • IPv6의 주요 장점
      1. 128비트 길이를 사용해 약 340조 개의 방대한 주소를 만들 수 있음
      2. IPv4의 헤더에서 불필요한 부분을 제외해 간소화
      3. 자동 구성 기능을 제공해 훨씬 단순하며 관리하기 쉬움
      4. IPv6의 자동 네트워킹 기능은 단말기를 움직일 때마다 고유 IP를 자동으로 설정
      5. 등급별, 서비스별로 패킷을 구분할 수 있어 품질 보장
      6. 보안 기능 강화; 확장 기능을 통해 보안 기능 제공

웹에 날개를 달아주는 웹 성능 최적화 기법, 강상진, 윤호성 저, 루비페이퍼 출판