CDN

서비스를 처음 만들면 서버는 한 곳에 둡니다. 미국 동부 데이터 센터에 한 대 올려 두고 전 세계가 그 한 대를 부르는 식입니다. 같은 나라 안에서는 아무 문제가 없다가 지구 반대편에서 접속할 때 드러납니다. 서울에서 미국 동부 서버까지 신호가 한 번 다녀오는 데 200밀리초쯤 걸리는데, 웹 페이지 하나를 여는 동안 그런 왕복이 수십 번 일어납니다. 이미지 40장과 스크립트 10개를 각각 불러오면 회선이 아무리 빨라도 거리만으로 몇 초가 쌓입니다.

그래서 해외 사용자 이야기가 나올 때마다 회의는 같은 모양이었습니다. 마케팅이 "일본 유입이 늘었는데 이탈률이 유독 높다" 고 하면 개발팀이 "서버가 미국에 있어서요" 라고 답하고, 그러면 "일본에도 서버를 하나 두죠" 라는 말이 나옵니다. 그런데 나라마다 서버를 한 벌씩 세우면 배포도 나라 수만큼, 데이터 맞추는 일도 나라 수만큼 늘어납니다. 사용자 100명 때문에 운영 부담을 두 배로 지는 셈입니다.

여기서 눈에 들어온 것은 느린 시간의 대부분이 사람마다 달라지는 화면이 아니라 누구에게나 똑같이 나가는 파일에 쓰인다는 점입니다. 로고 이미지는 서울에서 보든 상파울루에서 보든 같은 파일입니다. 서버 전체를 옮길 게 아니라 복사해도 되는 것만 곳곳에 미리 뿌려 두면 됩니다. CDN 은 그 발상을 사업으로 만든 것입니다.

거리로 생기는 지연, 원본 서버 한 대에 몰리는 부하, 갑자기 들이닥치는 트래픽 셋을 한꺼번에 덜어 냅니다.

1. 거리 — CDN 사업자는 세계 주요 도시에 거점 서버를 수백 개 깔아 둡니다. 사용자가 파일을 부르면 도메인 이름을 서버 주소로 바꿔 주는 체계인 DNS가 가장 가까운 거점을 가리킵니다. 서울 사용자는 서울 거점에서 받고, 왕복은 200밀리초에서 10밀리초로 줄어듭니다.
2. 부하 — 거점이 파일을 들고 있으면 원본 서버는 그 요청을 아예 받지 않습니다. 이미지와 스크립트가 전체 요청의 80퍼센트를 차지하는 서비스라면 원본에 닿는 요청이 5분의 1로 줄고, 남은 자원은 로그인이나 결제처럼 계산이 필요한 일에 돌아갑니다.
3. 폭주 — 어딘가에 소개되어 평소의 30배가 들어와도 대부분은 거점이 받아 내니 원본 대수를 미리 늘리지 않고도 버팁니다.

작동은 두 단계뿐입니다. 거점도 처음에는 파일이 없습니다. 첫 번째 사용자가 부르면 그때 원본에서 한 번 가져와 자기 디스크에 두고 내려 줍니다. 이걸 미스라고 부릅니다. 두 번째 사용자부터는 원본까지 가지 않고 거점이 바로 답합니다. 이게 히트입니다. 히트가 차지하는 비율이 이 장치의 성적표라서, 95퍼센트면 제 값을 하는 것이고 60퍼센트면 설정이 틀린 것입니다.

거점이 파일을 얼마나 오래 들고 있을지는 원본 서버가 표시로 정합니다. 그래서 파일 이름에 버전을 박습니다. app.js 대신 app.9f3c1.js 로 내보내면 내용이 바뀔 때 이름도 바뀌고, 거점은 바뀐 이름을 처음 보는 파일로 여겨 원본에서 새로 가져옵니다.

거리 문제를 CDN 없이 푸는 길도 셋 있지만, 셋 다 CDN 을 그대로 대신하지는 못합니다.

1. 원본 서버 증설 — 대수를 늘리고 그 앞에 로드 밸런서를 둡니다. 들어온 요청을 뒤에 선 여러 대 중 여유 있는 쪽으로 나눠 보내는 장치입니다. 부하는 나눠지지만 서버가 전부 한 지역에 있으면 서울에서 부를 때의 200밀리초는 그대로입니다.
2. 리전별 복제 — 나라마다 서버 한 벌을 통째로 세웁니다. 거리도 줄고 계산이 필요한 요청까지 가까이서 처리되지만, 지역마다 따로 도는 데이터를 맞추는 숙제가 남습니다. 도쿄에서 쓴 문서가 프랑크푸르트에서 몇 초 뒤에야 보이는 문제를 직접 풉니다.
3. 파일 줄이기 — 이미지를 압축하고 스크립트를 합치고 쓰지 않는 코드를 걷어 냅니다. 웹 성능을 손볼 때 가장 먼저 하는 일이고 효과도 큽니다. 다만 1메가를 300킬로로 줄여도 그 300킬로가 지구 반대편에서 온다는 사실은 그대로입니다.

실무에서는 셋 중 하나를 고르지 않습니다. 3번으로 보낼 양을 줄이고 그 위에 CDN 을 얹은 다음, 매출이 나오는 지역이 생기면 그때 2번을 검토합니다. CDN 은 리버스 프록시를 세계에 흩뿌려 둔 것에 가깝습니다. 요청을 대신 받아 뒤쪽 서버로 넘겨 주는 중계인데, 그것을 거점마다 두고 파일까지 들고 있게 만든 셈입니다.

"일본 사용자 첫 화면이 4초 걸린다는데, CDN 붙이면 얼마나 줄어요?"

느린 원인이 거리인지부터 가늠해 보자는 요청입니다.

"배포했는데 사용자한테 아직 옛날 화면이 보여요. 퍼지 좀 돌려 주세요."

거점이 옛 파일을 들고 있으니 강제로 지워 달라는 뜻입니다.

"히트율이 62퍼센트밖에 안 나와요. 캐시 설정부터 봅시다."

원본까지 가는 요청이 너무 많아 CDN 이 제 값을 못 하고 있다는 말입니다.

페이지덱에서 일본과 싱가포르 가입이 늘자 현우가 지역별 이탈률을 들고 왔습니다. 국내는 첫 화면까지 1.2초인데 일본은 3.9초, 싱가포르는 4.6초였습니다. 태오가 보니 그 시간의 대부분이 편집기 스크립트와 아이콘 파일을 받는 데 쓰였습니다.

서버를 옮기는 대신 그 파일들만 CDN 에 얹었습니다. 2주 뒤 일본은 1.6초, 싱가포르는 1.9초가 됐습니다. 남은 시간은 원본까지 가야 하는 문서 요청 몫이라 그건 다음 분기 과제로 남겼습니다.

CDN 을 붙이면 사이트 전체가 빨라진다고 생각하기 쉽습니다. 속도 개선 도구로 소개되니 자연스러운 기대입니다. 하지만 거점이 대신 답할 수 있는 것은 누구에게나 같은 파일뿐입니다. 로그인한 사람의 문서 목록은 사람마다 다르니 결국 원본 서버까지 갔다 와야 하고, 그 요청이 느린 이유가 데이터베이스 조회라면 CDN 을 붙여도 그대로입니다. 이걸 모르면 붙여 놓고 "효과가 없네" 라고 판단한 뒤 진짜 원인을 계속 지나치게 됩니다.

한 번 붙여 두면 손이 안 간다는 오해도 흔합니다. 설정이 자동으로 들어가는 서비스가 많아 그렇게 보입니다. 실제로는 거점이 파일을 들고 있는 기간을 잘못 잡으면 배포한 내용이 며칠씩 반영되지 않고, 더 나쁘게는 절반만 반영됩니다. 새 스크립트를 받은 사람과 옛 스크립트를 받은 사람이 섞이면 어떤 사용자에게만 화면이 깨지고, 재현이 안 되니 원인을 찾는 데 며칠이 듭니다.