cdn 서버를 붙이기 전에 사양 계산하는 방법

얼마 전 이미지가 많은 쇼핑몰에서 서버를 한 단계 올려야겠다는 이야기를 들었다. 로그를 보니 페이지를 만드는 작업보다 이미지와 자바스크립트 파일을 보내는 데 트래픽이 몰려 있었다. 이런 경우 서버 사양을 먼저 올리면 비용은 늘어도 체감 속도는 별로 달라지지 않을 수 있다. cdn 서버를 붙일지 판단할 때도 월 방문자 수 하나만 보지 않는다. 무엇을 얼마나 전송하는지부터 계산한다.

원본 서버가 하는 일부터 구분한다

CDN은 방문자와 원본 서버 사이에서 파일을 대신 전달한다. 방문자가 요청한 파일이 가까운 CDN 거점에 있으면 원본까지 가지 않는다. 없거나 보관 기간이 끝났다면 원본에서 가져온 뒤 전달한다. 그래서 CDN을 붙여도 원본 서버는 계속 필요하다. 로그인 처리, 장바구니, 관리자 화면처럼 사용자마다 결과가 달라지는 요청도 대개 원본이 처리한다.

효과가 큰 대상은 이미지, 글꼴, 자바스크립트, 스타일 파일처럼 여러 방문자가 같은 내용을 받는 파일이다. 반대로 HTML이 매번 달라지고 정적 파일도 적은 사이트라면 CDN을 추가해도 원본 부하가 크게 줄지 않는다. 원본의 데이터베이스가 느린데 CDN 요금제를 올리는 것도 순서가 맞지 않다.

먼저 서버 로그에서 요청 수와 전송 바이트를 파일 종류별로 나눈다. 요청 수가 많은 작은 파일과 전송량이 큰 이미지는 개선 방향이 다르다. CDN의 캐시 적중률도 요청 기준과 바이트 기준을 함께 봐야 한다. 작은 파일만 잘 저장되면 요청 적중률은 높아 보여도 원본의 전송량은 그대로일 수 있다.

월 전송량으로 필요한 구간을 계산한다

예를 들어 한 달 페이지 조회가 5만 회이고 페이지 한 번에 평균 2MB를 내려보낸다면 방문자에게 보내는 양은 약 100GB다. 이 중 이미지와 정적 파일이 80GB이고 CDN에서 바이트 기준 90%가 적중하면, 그 파일 때문에 원본이 보내는 양은 약 8GB가 된다. 나머지 20GB가 원본에서 그대로 나간다고 가정하면 원본 전송량은 약 28GB다. 방문자에게 전달되는 총량 100GB가 없어지는 것은 아니다. 전송 비용을 원본과 CDN 중 어디에서 내는지가 달라진다.

요금 비교에는 월 전송량, 요청 건수, 원본으로 되돌아가는 전송량을 각각 넣는다. 무료 구간이 이 수치를 감당하고 필요한 기능이 포함된다면 유료 요금제를 고를 이유가 없다. 반면 이미지 변환이나 추가 보안 기능을 켜면 별도 과금이 붙을 수 있다. 요금표의 무료 전송량만 보고 판단하면 월말 청구서가 예상과 달라진다.

트래픽이 하루에 고르게 오는지도 중요하다. 월 100GB라도 특정 게시물이 퍼지는 한 시간에 요청이 몰릴 수 있다. CDN은 저장된 파일 요청을 분산하지만, 그 시간에 로그인이나 검색 요청까지 몰리면 원본의 CPU와 데이터베이스 연결 수를 따로 봐야 한다. 동시접속자 수만으로 서버 사양을 정하기 어려운 이유다.

캐시는 파일 종류별로 다르게 건다

처음 설정할 때는 이미지와 정적 파일부터 캐시한다. 파일 내용이 바뀔 때 이름도 함께 바뀌는 방식이라면 보관 시간을 길게 잡기 쉽다. 같은 이름의 파일을 덮어쓰는 운영 방식이라면 보관 시간을 짧게 두거나 배포 때 캐시 삭제 절차를 넣어야 한다. 방문자마다 다른 HTML을 오래 저장하면 새 글이 늦게 보이는 정도에서 끝나지 않을 수 있다.

특히 로그인 상태에 따라 달라지는 페이지, 주문 내역, 관리자 화면은 캐시 규칙을 따로 확인한다. 쿠키나 요청 매개변수를 무시하도록 설정하면 다른 사람의 화면이 전달될 위험이 있다. 처음부터 사이트 전체에 동일한 규칙을 거는 것보다 경로별로 작은 범위에서 확인하는 편이 안전하다.

캐시를 켠 뒤에는 CDN에서 응답한 비율과 원본의 요청 수를 같이 본다. 적중률이 낮다면 파일의 보관 지시가 너무 짧은지, 매 요청마다 주소의 매개변수가 바뀌는지, 쿠키 때문에 캐시를 건너뛰는지 확인한다. 수치가 낮다고 무조건 보관 시간부터 늘리면 오래된 파일을 방문자에게 보여줄 수 있다.

전환과 장애 복구 순서를 미리 적어 둔다

운영 중인 사이트라면 DNS를 바꾸기 전에 CDN에서 원본 연결과 인증서 발급 상태를 확인한다. 정적 파일 몇 개와 로그인 화면, 업로드, 결제처럼 중요한 동작을 먼저 시험한다. 전환 전에는 DNS의 기존 값을 기록하고 응답이 갱신되는 시간을 확인해 둔다. 되돌릴 때 어디로 돌려야 하는지 모르면 장애 시간이 길어진다.

전환 직후 화면이 깨지면 원본 서버부터 재시작하지 않는다. 브라우저가 받은 응답 코드와 캐시 상태를 보고, CDN이 원본에 연결할 수 있는지 확인한다. 일부 지역에서만 문제가 나면 전파 상태와 거점별 응답을 비교한다. 오래된 파일이 보이는 경우에는 파일 배포 상태를 먼저 확인한 뒤 필요한 파일만 캐시에서 삭제한다. 전체 캐시를 한꺼번에 비우면 원본으로 요청이 몰릴 수 있다.

CDN을 붙여도 백업은 원본의 파일과 데이터베이스를 기준으로 유지한다. CDN에 남아 있는 파일은 백업본이 아니다. 복원 시험을 한 적이 없다면 서버 요금제보다 그 절차에 시간을 먼저 쓰는 편이 낫다. 내 경험상 작은 사이트는 저렴한 원본 서버와 단순한 정적 파일 캐시만으로도 오래 버틴다. 비용을 더 쓰기 전에 로그에서 병목이 실제로 어디에 있는지 확인하는 게 가장 확실하다.