얼마 전 이미지 많은 쇼핑몰 하나를 봤는데, 서버 CPU는 20%도 안 쓰는데 페이지가 느리다는 얘기를 들었습니다. 로그를 보니 상품 상세 이미지와 자바스크립트 파일이 전부 원본 서버에서 나가고 있었습니다. 이런 경우 서버를 큰 요금제로 올리는 것보다 CDN을 붙이는 쪽이 먼저입니다.
CDN은 콘텐츠를 사용자 가까운 위치에서 내려주는 캐시 계층입니다. 어려운 말로 포장할 필요 없습니다. 원본 서버가 매번 이미지, CSS, JS, 동영상 조각까지 다 처리하던 일을 중간 캐시 서버가 나눠 맡는 구조입니다. 특히 방문자가 여러 지역에 퍼져 있거나, 이미지 용량이 크거나, 특정 시간에 접속이 몰리는 사이트라면 효과가 꽤 큽니다.
CDN을 써야 하는 구간 계산하는 방법
CDN은 트래픽이 많아야만 쓰는 장비가 아닙니다. 기준은 방문자 수보다 전송량과 반복 요청입니다. 예를 들어 하루 방문자가 3천 명이고, 한 사람이 평균 5페이지를 봅니다. 페이지당 이미지와 정적 파일이 3MB라면 하루 전송량은 대략 45GB입니다. 한 달이면 1.3TB 정도입니다. 이 정도면 원본 서버 회선과 디스크 I/O가 꽤 신경 쓰이기 시작합니다.
반대로 하루 방문자가 1만 명이어도 페이지가 가볍고 대부분 텍스트라면 CDN 효과는 작을 수 있습니다. 저는 보통 아래 기준으로 먼저 봅니다.
- 이미지, CSS, JS 같은 정적 파일 비중이 전체 전송량의 60% 이상인지
- 한 달 전송량이 300GB를 넘는지
- 특정 게시글이나 이벤트 페이지에 순간 접속이 몰리는지
- 해외 접속자가 전체의 10% 이상인지
- 원본 서버보다 네트워크 대기 시간이 먼저 병목인지
이 중 2개 이상이면 CDN을 검토할 만합니다. 특히 이미지가 많은 블로그, 쇼핑몰, 다운로드 페이지, 랜딩 페이지는 서버 사양보다 CDN 설정이 더 큰 차이를 냅니다. 근데 단순 회사 소개 사이트나 소규모 예약 페이지라면 굳이 유료 CDN까지 갈 필요 없는 경우도 많습니다.
CDN이 실제로 줄여주는 비용
서버 비용을 볼 때 CPU와 메모리만 보는 분들이 많습니다. 그런데 웹서비스에서 조용히 돈을 먹는 건 전송량입니다. VPS나 클라우드 서버는 일정량 이상 트래픽부터 비용이 붙거나 속도 제한이 생깁니다. 호스팅 업체마다 표현은 다르지만, 결국 많이 내보내면 돈이 듭니다.
예를 들어 원본 서버에서 월 2TB를 직접 내보내고 있다고 가정해보겠습니다. 이 중 이미지와 스크립트가 70%라면 1.4TB는 CDN으로 빠질 수 있습니다. 원본 서버는 동적 페이지와 관리자 요청, API 정도만 처리하게 됩니다. 이렇게 되면 서버를 2배 큰 요금제로 올리지 않아도 버티는 구간이 생깁니다.
저는 운영할 때 서버 증설보다 먼저 캐시율을 봅니다. CDN 캐시 적중률이 85% 이상이면 원본 서버 입장에서는 요청 100개 중 15개만 직접 처리하는 셈입니다. 체감상 이 차이는 큽니다. CPU 사용률보다 원본 요청 수가 먼저 줄고, 장애 때도 여유가 생깁니다.
처음 적용할 때 꼭 확인할 설정
CDN은 붙이기만 하면 빨라지는 물건이 아닙니다. 설정이 틀리면 오히려 장애 원인이 됩니다. 특히 캐시 만료 시간, 쿠키 전달, 원본 서버 접근 제한, SSL 설정은 처음부터 봐야 합니다.
캐시 만료 시간
이미지, 폰트, CSS, JS는 파일명이 바뀌는 방식이면 길게 잡아도 됩니다. 보통 7일에서 30일 정도를 많이 씁니다. 반대로 HTML은 사이트 성격에 따라 짧게 가져갑니다. 뉴스나 쇼핑몰 가격 페이지를 길게 캐시하면 예전 내용이 보일 수 있습니다. 이 사고가 생각보다 자주 납니다.
쿠키와 관리자 페이지
관리자 페이지, 장바구니, 결제, 로그인 영역은 캐시하면 안 됩니다. 쿠키가 붙은 요청을 무조건 캐시하는 설정은 위험합니다. 다른 사용자의 화면이 보이는 사고까지 이어질 수 있습니다. 일반 블로그도 로그인한 관리자 화면이 캐시되지 않게 예외 규칙을 둬야 합니다.
SSL 인증서
CDN 앞단과 원본 서버 양쪽의 SSL 상태를 같이 봐야 합니다. 앞단만 암호화하고 원본 구간이 느슨하면 운영 기준상 찝찝한 구성이 됩니다. 인증서 만료일도 CDN과 원본을 따로 확인해야 합니다. 장애 당일에 보면 이미 늦습니다.
장애를 부르는 흔한 실수
CDN 장애는 보통 CDN 자체보다 설정에서 옵니다. 파일이 안 바뀐다, 일부 사용자만 깨진다, 관리자 로그인 후 화면이 이상하다, 특정 지역에서만 느리다 같은 증상이 많습니다. 이런 문제는 서버 증설로 해결되지 않습니다.
- CSS와 JS를 길게 캐시했는데 파일명은 그대로 쓰는 경우
- 이미지 교체 후 캐시 삭제를 하지 않아 예전 이미지가 계속 보이는 경우
- 원본 서버 방화벽에서 CDN IP 대역을 막아버린 경우
- 동적 페이지까지 무리하게 캐시해 장바구니나 로그인 상태가 꼬이는 경우
- 압축 설정이 중복되어 일부 브라우저에서 파일이 깨지는 경우
운영에서는 배포 방식과 CDN 캐시 정책이 같이 움직여야 합니다. CSS 파일을 수정한다면 파일명에 버전을 붙이는 식이 안전합니다. 예를 들어 같은 파일명으로 덮어쓰는 방식은 작게 운영할 때는 편하지만, CDN이 들어오면 문제가 됩니다. 사용자는 예전 파일을 보고 서버는 새 HTML을 내려주는 식으로 화면이 깨질 수 있습니다.
작은 사이트라면 이렇게 시작하면 충분합니다
초기 블로그나 소규모 쇼핑몰이라면 모든 트래픽을 CDN 뒤로 넣기보다 정적 파일부터 분리하는 방식이 부담이 적습니다. 이미지, CSS, JS만 CDN으로 보내고 HTML은 원본 서버가 직접 처리하게 두는 구조입니다. 이러면 캐시 사고 범위가 줄고 문제를 찾기도 쉽습니다.
처음 적용 후에는 최소한 세 가지 수치를 봅니다. 원본 서버 트래픽이 얼마나 줄었는지, CDN 캐시 적중률이 어느 정도인지, 페이지 로딩 시간이 실제 사용자 기준으로 줄었는지입니다. 관리 화면의 예쁜 점수보다 원본 요청 감소가 더 중요합니다. 원본 요청이 그대로라면 CDN이 앞에 있어도 일을 제대로 못 하고 있는 겁니다.
저가 호스팅을 쓰는 사이트도 CDN을 붙이면 꽤 오래 버팁니다. 다만 백업과 원본 서버 접근 권한은 따로 챙겨야 합니다. CDN은 원본 서버가 죽었을 때 일부 정적 파일을 잠시 버텨줄 수는 있지만, 데이터베이스나 관리자 기능까지 살려주지는 않습니다. 그래서 CDN은 보험이라기보다 부하를 덜어주는 완충재에 가깝습니다.
제가 운영 기준으로 보는 좋은 CDN 구성은 거창하지 않습니다. 정적 파일은 길게 캐시하고, 로그인과 결제는 캐시하지 않고, 배포 때 파일명이 바뀌고, 원본 서버에는 CDN을 거친 정상 요청만 들어오게 만드는 정도입니다. 이 정도만 지켜도 서버 요금제를 올리기 전에 버틸 수 있는 구간이 꽤 넓어집니다. 돈을 더 쓰기 전에 요청이 어디서 새는지 먼저 보는 게 서버 운영에서는 늘 더 싸게 먹힙니다.
