CDN·해외 가속 도입 검토 안내서

CDN은 되풀이해 내려받는 콘텐츠를 사용자와 가까운 지점에서 대신 내보내 주는 장치입니다. 대륙을 건너던 왕복이 줄어드는 만큼 이미지와 영상, 정적 파일의 도착이 빨라지고 원본 서버에 닿는 요청 수가 줄어듭니다. 반대로 못 푸는 문제가 분명합니다. 데이터베이스 조회가 오래 걸리거나 애플리케이션이 응답을 늦게 만들면 그 시간은 어디에 캐시를 둬도 그대로 남습니다. 로그인한 사용자에게만 보이는 화면, 매 요청마다 값이 달라지는 API 응답, 결제 흐름의 각 단계도 캐시 대상이 아닙니다. 그래서 도입 검토의 첫 갈래에서는 지금 느린 것이 원본에서 생긴 시간인지 전송에서 생긴 시간인지를 가릅니다. 앞이면 애플리케이션과 데이터 계층을 고쳐야 하고 뒤라야 앞단을 두는 일이 효과를 냅니다. 이 구분 없이 붙이면 값은 나가는데 체감은 그대로인 상태가 됩니다.

측정 없이 붙이면 도입 뒤에 효과를 설명할 방법이 없습니다. 세 가지를 기준선으로 남깁니다. 첫째, 사용자가 실제로 어느 지역에 있는지입니다. 접속이 많은 지역을 몇 곳 골라 그 지역에서 같은 페이지를 같은 시간대에 잽니다. 사무실 회선에서 한 번 잰 값은 기준선이 되지 못합니다. 둘째, 첫 응답까지 걸린 시간과 화면이 다 그려질 때까지 걸린 시간을 나눠 봅니다. 앞의 값이 크면 원본과 경로를, 뒤의 값이 크면 내려받는 자원의 수와 크기를 봐야 합니다. 셋째, 전체 요청 가운데 캐시가 가능한 응답의 비율입니다. 이 값이 낮으면 정적 캐싱으로 얻을 몫이 처음부터 작습니다. 세 값을 적어 두면 도입 여부의 판단이 감이 아니라 비교가 되고 전환 뒤 같은 방식으로 다시 재서 어디에서 효과가 났는지 읽습니다.

앞단에 두는 일은 하나로 보이지만 안에서 둘로 갈립니다. 정적 캐싱은 이미지와 영상, 배포된 자원처럼 여러 사용자에게 같은 것을 내보내는 응답을 지점에 보관해 두는 일입니다. 효과가 크고 계산도 쉽습니다. 동적 가속은 캐시할 수 없는 요청의 왕복 자체를 줄이는 일입니다. 지점과 원본 사이의 경로를 고르고 연결을 재사용하며 압축과 프로토콜 설정을 맞추는 쪽입니다. 효과는 정적 캐싱보다 작고 값은 대개 더 비쌉니다. 우리 트래픽이 둘 중 어느 쪽에 몰려 있는지를 보고 기대치와 견적을 함께 잡습니다. 콘텐츠와 커머스처럼 같은 자산을 반복해 내보내는 서비스는 앞쪽에서 답이 나오고 로그인 뒤에 일어나는 일이 대부분인 업무형 서비스는 뒤쪽이 됩니다. 견적을 받을 때 이 구분을 먼저 말해야 서로 다른 물건의 값을 비교하는 일을 피합니다.

전송을 앞당겨도 원본 호출이 그대로면 비용은 줄지 않습니다. 절감액은 원본에서 나가던 트래픽 가운데 얼마나 앞단에서 처리되는지를 놓고 계산합니다. 현재 원본에서 나가는 월 전송량과 그 단가, 그 가운데 캐시가 가능한 비율, 앞단의 요금을 나란히 놓으면 차액이 나옵니다. 클라우드에서 나가는 트래픽 요금은 대체로 비싸므로 그 몫이 앞단 요금으로 옮겨가는 것만으로도 값이 내려가는 구간이 있습니다. 여기에 원본 서버 쪽 절감이 더해집니다. 몰리는 시간에 맞춰 늘려 둔 서버 대수와 자동 확장 한도를 낮출 수 있으면 그 몫도 같은 계산에 들어갑니다. 반대로 적중률이 낮으면 요금이 두 겹으로 붙습니다. 앞단 요금을 내면서 원본 전송량도 그대로 나가는 상태입니다. 그래서 도입 뒤 첫 달에 볼 숫자는 응답 시간이 아니라 콘텐츠 유형별 적중률과 원본 전송량입니다.

엣지 지점의 개수는 비교표에서 가장 눈에 띄는 숫자이지만 체감 속도를 바로 설명하지는 않습니다. 우리 사용자가 몰려 있는 나라와 통신사에 지점이 있는지, 그 지점에서 원본까지의 경로가 어떻게 잡히는지가 실제 값을 가릅니다. 지점이 많아도 사용자와 지점 사이의 마지막 구간이 막혀 있으면 도착 시간은 줄지 않습니다. 원본이 국내에 있고 사용자가 해외에 있는 구조에서는 캐시에 없는 요청이 결국 국내까지 다녀오므로 적중률과 대체 응답 규칙이 함께 중요해집니다. 판단은 자료가 아니라 시험에서 나옵니다. 후보를 좁힌 뒤 실제 도메인의 일부 경로를 붙여 같은 지역에서 같은 방식으로 재 보는 절차를 검토 일정에 넣습니다. 며칠이면 끝나고 그 결과가 나머지 조건을 판단하는 근거가 됩니다.

CDN과 웹 방화벽, 대량 요청 방어는 서비스 앞단이라는 같은 자리에 놓입니다. 한 곳에서 함께 다루면 인증서와 DNS, 로그가 한 벌로 유지되고 규칙을 바꿀 때 두 회사의 회신을 기다리지 않습니다. 따로 사면 앞단이 둘로 겹쳐 요청 경로가 길어지고 어느 단에서 막혔는지 확인하는 일부터 두 화면을 봐야 합니다. 로그인과 결제가 있는 서비스, 해외 접속이 많아 정상 이용자와 자동화된 접근을 가르기 어려운 사이트라면 같은 검토에서 함께 정하는 편이 낫습니다. 다만 지금 아픈 곳이 속도 하나뿐이면 순서를 나눠도 됩니다. 앞단 구조를 같은 곳에 두는 결정만 먼저 하고 규칙 설계는 다음 단계로 미룹니다. 구성 단계에서 짚을 항목은 CDN·WAF 구성 점검표에 따로 있습니다. 견적을 받을 때는 방어 기능이 기본 요금에 들어 있는지, 규칙 수와 차단 기록 보관 기간에 따라 값이 다시 오르는지를 함께 묻습니다. 이 조건을 빼고 받은 값은 나중에 같은 구성에서 다른 청구서가 됩니다.

요금은 대체로 전송량과 요청 수를 축으로 매겨지고 지역별 단가와 기능별 추가 요금이 그 위에 얹힙니다. 같은 전송량이라도 사용자가 어느 대륙에 있는지에 따라 값이 달라지므로 지역 구성을 모르면 견적을 비교하지 못합니다. 계약 형태는 둘입니다. 약정은 일정량을 미리 사서 단가를 낮춥니다. 종량은 쓴 만큼 냅니다. 약정에서는 초과분의 단가와 미달분의 처리를 확인합니다. 초과 단가가 약정 단가보다 높게 잡히면 트래픽이 튀는 달에 값이 크게 오르고 미달분을 다음 달로 넘기지 못하면 비수기 몫을 버립니다. 트래픽이 계절이나 행사에 따라 크게 오르내리는 서비스는 바닥 구간만 약정으로 덮고 그 위를 종량으로 두는 구성이 안전합니다. 최소 계약 기간과 청구 통화, 세금계산서 발행 여부도 같은 자리에서 확인합니다.

전환 자체는 도메인이 가리키는 곳을 앞단으로 바꾸는 작업이라 애플리케이션 코드를 고치지 않습니다. 실제로 시간이 드는 곳은 그 주변입니다. 인증서를 누가 발급하고 갱신하는지, 갱신이 자동으로 도는지를 먼저 정합니다. DNS는 최상위 도메인과 하위 도메인의 처리 방식이 다르므로 지금 구성을 확인하고 전환 전에 유효 기간을 짧게 내려 둡니다. 캐시 무효화 정책은 배포 파이프라인과 맞물립니다. 파일 이름에 버전을 넣어 갈아 끼우는 방식과 배포 때마다 지우는 방식 가운데 무엇을 쓸지 정하고 무효화 요청에 걸리는 시간과 횟수 제한을 확인합니다. 원본으로 직접 들어오는 경로를 막을지도 이때 정합니다. 앞단을 우회하는 주소가 열려 있으면 캐시도 차단 규칙도 지나칩니다. 전환은 트래픽이 적은 시간대에 단계적으로 올리고 되돌리는 조건과 판단하는 사람을 작업 전에 정해 둡니다.

같은 네트워크를 쓰더라도 어디를 거쳐 사는지에 따라 일하는 방식이 달라집니다. 직접 계약은 최소 계약 규모가 있고 설정과 튜닝을 내부 인력이 맡습니다. 규칙을 자주 바꾸는 조직에는 맞지만 담당자가 없으면 기본 설정으로 몇 해가 지나갑니다. 재판매를 거치면 국내 계약과 원화 결제가 붙는 대신 설정 변경과 장애 대응이 몇 단계를 거쳐 돌아옵니다. 단계의 수와 각 단계의 권한을 확인합니다. 캐시 규칙 하나를 바꾸는 데 며칠이 걸리는지, 장애가 났을 때 1차로 판단하는 사람이 어디에 있는지가 계약서보다 운영에서 크게 갈립니다. IXC는 Akamai와 직접 파트너 관계를 맺어 리셀러를 거치지 않고 글로벌 엣지 네트워크를 그대로 쓰며 웹 방화벽과 대량 요청 방어를 같은 앞단에서 함께 다룹니다. 규칙 변경과 차단 기록 확인이 한 곳에서 끝나므로 판단을 다른 회사의 회신에 맡기고 기다리는 자리가 없습니다.