[개안뽑] ⑯CDN으로 트래픽 분산, 웹사이트 성능 개선하기

Picture

Member for

4 months

Real name

Keith Lee

Bio

Head of GIAI Korea
Professor of AI/Data Science @ SIAI

Input

2023-12-19 18:30

웹서비스 최적화는 다양한 기능들의 조합이 갖춰져야
성능 개선 문제는 자사 서비스에 대한 이해에 맞춰 다른 서비스 활용해야
해외 서비스 접속자를 위해 CDN 서비스 붙이면서도 자사 서비스 상황 고민은 필수

우리 SIAI 학생 중 하나가 구글 페이지 스피드 점수 정보를 보고는 자기가 다니고 있는 회사의 웹페이지를 넣어봤단다. 파비리서치처럼 이미지가 많이 들어가 있는 웹페이지도 아니고, 단순히 회사 소개 이미지 몇 개 들어가 있는 상황에 불과한데, 성능 점수가 60점대로 나오는 걸 보면서, 우리 회사 개발자는 진짜 뭐하는건가 싶었고, 반대로 SIAI 운영하는 저 사람은 개발자도 아니고, 수학 모델링 기반으로 Data Science 모델 만드는게 전문인 사람인데, 저 사람이 혼자서 파트 타임으로 만든 시스템을 우리 회사 개발자 몇 명이 따라갈 수 없다는게 말이되나는 생각을 했단다.

사실 내 기준으로 더 큰 문제는 눈 앞의 성능 점수 몇 점 차이가 아니라, 그 뒤에 추가된 나머지 3개 영역의 점수들이다. 성능은 하드웨어에 막대한 비용을 쓰면 어느 정도는 따라 잡을 수 있는 반면, 나머지 3개 영역 점수는 웹사이트 완성도를 가늠할 수 있는 잣대이기도 하고, 실제로 구글 검색에서 그 웹사이트가 얼마나 잘 보이는지에 큰 영향을 미치기 때문이기도 하다. 막대한 하드웨어 비용 부분을 고정 값으로 놓으면, 그 4개 영역의 점수는 각각 백엔드 개발자, 프론트엔드 개발자, 퍼블리셔, 디자이너, 그리고 그 웹페이지 만든 프로젝트 총괄(PM)의 역량을 그대로 반영한다. 그 역량이 부족하면 결국 모자란 부분을 대체하기 위해 하드웨어에 큰 비용을 쏟아야 하고, 마케팅에 많은 비용을 부어야 하는 것이다.

왜 못 할까? 왜 모를까? 왜 다들 파편화 되어 있을까?

직원들을 뽑아보면 자꾸 자기는 특정 분야의 일만 하고 싶다고 분리해달라고 그러는데, 난 안 된다고 자르기도 하고, 직원들이 자기들끼리 마음대로 일을 분리하고 다른 사람 업무를 아예 무시하고 있는 걸 보면 좀 답답하다. 위의 웹페이지 개발 관련 주제도 그렇게 분리하기 애매모호한 부분이 많다.

예를 들어, 성능 점수가 안 나오고 있으면 나머지 부분을 아무리 잘 만들어 놨어도 결국 구글 검색에 노출이 안 될 것이다. 결국은 백엔드 개발자가 DB 효율화를 안 해놨거나, 프론트가 웹페이지 화면에 로딩되는 데이터 쿼리를 분리를 안 해 놨거나, 퍼블리셔가 뭔가 이상한 작업을 해서 과부하가 걸리도록 해 놨거나, 디자이너가 무리한 디자인을 했거나, 아니면 PM이 이런 기능 만들면 웹페이지 무거워진다며 위나 아래에서 나오는 이야기를 쳐내지 않아서 생긴 문제일 것이다. 누가 문제의 원인이건 결국 그 회사는 웹서비스 홍보를 위해서 막대한 비용의 광고비를 지출해야하는 회사가 된다.

제발 좀 다른 사람들이 무슨 일을 하는지, 그래서 서로 조율해가면서 서비스 수준을 끌어올려달라고 부탁해도 전혀 듣질 않는다. 아마 듣기는 하겠지만, 다른 사람들이 무슨 일을 하는지 전혀 모르니, 그저 남들이 하는대로 따라하기만 했으니, 도대체 어떤 문제가 있어서 시스템 효율화가 안 되는지에 대해서 피상적인 정보 밖에 없는 것이다. 그런 사람들에게 왜 못하냐고 불평하면, [개안뽑] ⑫못하는 걸 시킨 나는 악덕 기업주였다 같은 상황이 벌어진다. 이것저것 배워와서 가르쳐줘봐야 [개안뽑] ⑪모르는 걸 시킨 나는 악덕 기업주였다 같은 상황으로 상황만 바뀔 뿐, 문제는 해결되지 않는다.

우리 OTT랭킹을 글로벌 서비스로 전환하는 것도 상황은 크게 다르지 않았다. 이 글을 쓰고 있는 2023년 12월 시점을 기준으로, 저 도메인을 구매한지 1년 8개월이 지났고, 서비스에 각종 기능을 붙이려고 사람을 뽑아보고, 일을 이래저래 바꿔보고, 기획을 뜯어고쳐보고, 도대체 뭐가 문제냐고 꾸중하고 상담하고, 정말 온갖 도전을 다 해 봤는데, 기사를 쓰는 애들은 딱 그 부분만 알고 있고, 웹사이트 디자인을 하는 사람들도 딱 디자인 구성만 알고, 개발자는 그간 이야기한대로 자기가 하는 일을 제외하면 그냥 아무것도 몰랐다. 그냥 좀 다들 학습 능력이 너무 떨어지더라.

CDN으로 트래픽 분산, 웹사이트 성능 개선

이번에 번역기를 붙일 때도 수 많은 시행착오가 있었다. 이전에 다른 번역기 플러그인을 붙여본 적도 있고, 서비스 속도가 확 느려지는 경우가 엄청 많았기 때문에 대부분 포기했고, 전문 번역가가 붙어야 된다며 직원들이 대표님의 무리한 욕심 때문에 자기들이 고생한다며 불평을 늘어놓는걸 주워 들은 적도 있다.

이번에도 플러그인을 붙여서 '서브 도메인(Sub-domain)'방식을 선택하기 전에 서버 레코드 작업을 안 해도 되는 '서브 디렉토리(Sub-directory)'로 먼저 출발했었는데, 기존에 다른 플러그인들로 엄청난 실패를 경험한대로 서비스 속도가 현격하게 느려지더라. 이번엔 구글 Sitemap 파일까지 만들어주는 플러그인이니까 좀 나을려나, 우리 본사 팀의 추천을 받았으니 괜찮겠지라는 생각을 했었던 것이 모두 물거품이 됐다는 생각에 많이 우울했다.

그러다 서비스 담당자랑 이야기를 나누면서 서브 디렉토리 방식은 모든 접속자가 한국에 있는 내 서버로 찾아오고, 번역 정보를 받으려고 다시 유럽 서버로 이동해야 하는데, 서브 도메인을 쓰면서 언어별 각각의 레코드를 자기네 유럽 서버로 바로 지정하면 한국 서버의 정보를 자기들이 갖고 간 이후에는 한국에 접속할 일이 없어진다고 하더라.

그럼 서브 도메인으로 구성을 바꾸면 유럽에서는 빠르게 접속이 되겠구나는 생각에 서버 레코드 값을 다 조정했다.

근데 html의 text 부분은 유럽에서 갖고 있는데, 이미지는 여전히 한국 서버를 찾아와서 갖고 가니 접속 속도가 별반 달라지는게 없었다.

그간 경험상 개발자들을 썼으면 여기서 문제가 있다는 지적만 내놓고 해결책이 없으니 날 더러 마음을 비우고 환불 받아라고 그랬을 것이다.

CDN이 글로벌에 200개 서버 나눠진 서비스 아닌가? 그 분들이 파일을 갖고가면 우리 서버는 놀잖아?

글로벌 시장에 수 많은 서비스들이 비슷한 문제를 겪었을 것이고, 대형 회사들이 그런 문제들을 당연히 풀었을 것이다. 안 그러면 구글 서비스 접속 속도가 한국에서는 엄청나게 느려야 정상이겠지.

이걸 어떻게 해결하려나 싶어서 처음에는 예전에 썼던 Amazon의 S3와 CloudFront라는 서비스로 고개를 돌렸다. S3는 이미지 파일 저장소고, CloudFront는 그 이미지를 글로벌 수십개의 서버에 나눠서 서비스하는 기능이다. 더불어 이미지의 원본을 찾을 수 없도록 각종 보안도 추가해준다.

CloudFront를 쓰면 될 것 같기는 한데, 이제 다시는 외부 서버에 우리 이미지 파일을 넘기기가 싫더라. 이번에 서버 이전하면서 날려먹은 이미지 파일도 많고, 파일 저장 방식도 달라서 서버 이전을 중간에 그만두고 싶었던 적이 한두번이 아니었기 때문이다. 거기다 요금도 들쭉날쭉이고, 자칫 우리 회사 서버에 과부하가 걸리는 사건이 터지면 엄청난 비용을 물어야 할 수도 있다는 경험치도 쌓여있다. 예전에 운영했던 커뮤니티 사이트는 한 달에 몇 백만원씩 S3 + CloudFront 비용을 낸 적도 있으니까.

각종 고민과 정보 검색 끝에 CloudFlare라는 서비스를 찾았고, 글로벌에 수백 개의 서버를 갖고 있으면서 접속자에게 가장 가까운 서버를 연결해주는 기능, 그 때 캐시된 정보를 보여줘서 접속 속도를 크게 개선하는 것이 CloudFlare 서비스의 핵심이라는 것을 알게 됐다.

유사한 서비스들로 경쟁 중인 회사들이 많았고, 기능들도 조금씩 달랐는데, 일단 내 입장에서는 OTT랭킹을 찾아오는 글로벌 사용자들이 자국과 가까운 곳에 있는 서버에서 접속할 수 있는 경험을 주고, 그 경험에 한국 서버의 이미지, 유럽 서버의 번역을 동시에 전달할 수 있는 곳을 찾아야 했다.

위의 스크린 샷에서 확인할 수 있듯이, 설정 값을 조정해주고 나니 기존에는 50%도 안 되던 캐시 비율이 90%를 안정적으로 뛰어넘을 수 있게 됐다. 이쪽 분들 용어로 캐시된 정보를 보고 가면 Hit, 아니면 Miss라고 표현한다던데, 우리 서비스 접속자들의 90% 이상이 Hit인 상태인 것이다.

이렇게 구성이 되면 처음에만 한국 서버와 유럽 서버가 일을 하고, 그 이후에는 CloudFlare 서버만 돌 것이다. 해외 어느 나라에서건 접속하려고 하면 근처에 있는 CloudFlare의 서버에 접근해서 그 정보를 보게 되겠지.

해외 서버 웹사이트 로딩 속도, 30점에서 70점으로

글로벌 서비스들이 한국에서도 성능에 무리없이 서비스가 가능한 이유가 한국에 따로 서버를 두거나, 인근 지역인 일본, 상해 등에 있는 서버를 활용하기 때문이라는 것을 이미 주워들어서 알고 있는 마당이니, 비슷한 방식으로 서비스만 해 주면 우리가 쓸 수 있겠다며 몇몇 서비스들을 점검해봤다.

결국 위의 CloudFlare로 정착하게 됐는데, 이미지 로딩 속도를 제외하면 영어 사이트 접속도 Total Blocking Time이 0에 가깝게 나오고, 전반적으로 성능 개선도 두드러지게 나왔다. 유럽에서는 80점대 중반 이상이 나오니까, 본사 애들은 자기네들 웹페이지도 80점대 중반 밖에 안 나오는데 내가 90점대 만들려고 욕심 낼 필요 없지 않냐는 반응이었다. 좀 욕심을 내면서 보여준 한국 웹페이지들 99점을 보더니 무슨 마법 썼냐고 농담이 잠깐 오가기도 했었다^^

처음에는 원인을 모르니 유럽 서버 탓을 하며 불평을 내놓기도 했으나, 이미지 파일이 여전히 웹사이트 로딩 속도를 느리게 하는 장본인이라는 것을 First Contentful Paint, Largest Contentful Paint 등의 정보들로 알게 된만큼, 이미지 파일 전달을 최적화하는데 계속 고민을 쏟는 쪽으로 초점이 정리되기도 했다.

위에 쓴대로 Amazon의 S3와 CloudFront를 쓰는 것이 해결책인지, 아니면 Cloudflare를 좀 더 미세조정하는 것이 답인지 아직은 모르겠다. 이런건 무조건 실험만 해 본다고 되는게 아니라, 그 서비스들 구성 방식을 이해하고, 내가 적절하게 조정을 해 줘야 하더라.

아뭏튼, 이렇게 정리되니 이제 해외 서비스 하겠다고 한국 서버에 막대한 하드웨어 비용을 들여야 할 이유가 사라져 버렸다. 어차피 한국 밖의 모든 접속자는 한국 서버가 아니라 CDN을 접속하고, 번역 정보가 있는 유럽 서버를 접속한다. Amazon의 S3 및 CloudFront 조합과 달리, CloudFlare 이용료는 0원에 가깝고, 나는 개발자 1명 쓰지 않고, 연간 50만원, 아니 30만원도 안 쓰면서, 내가 원하는 대로 거의 모든 조율이 다 된 글로벌 다국어 서비스를 할 수 있게 됐다.

웹사이트 접속 속도는 해외 서버 접속해도 네이버, 카카오 같은 국내 회사의 성능 점수와 비슷하고, 구글SEO 최적화가 완성된 웹사이트인만큼 광고비는 여기서도 0원이다. 작은 회사의 모든 자원은 오직 콘텐츠 고급화에만 투입될 뿐이다.

서비스 시작 2주일 만에 지난 7일간 Unique visitors가 15K인데, 해외 구글 검색을 다 뚫고 들어갔을 내년 3월말에 Monthly로 확인하면 얼마쯤으로 뛰어올라 있을까? 아래는 위의 1주일 그래프에서 하루가 더 지난 12월 19일 오후 1시에 뽑은 직전 24시간 자료다.