트래픽 20GB/일 제한과 같이 사는 법

우리 팀이 운영하는 서버는 하루 트래픽이 20GB로 제한된다. 처음에는 “20GB면 충분하지 않나?” 싶었다. 그런데 막상 운영해보면 이 숫자가 생각보다 빠르게 닳는다는 걸 알게 된다.

특히 정적 파일이 많은 사이트나 이미지 용량이 큰 페이지를 운영하면, 방문자가 몇백 명만 돼도 하루치를 금방 소진할 수 있다. 이 제약 안에서 서비스를 안정적으로 유지하기 위해 우리가 배운 것들을 정리했다.

CDN을 트래픽 방패로 쓴다

가장 효과적인 방법은 Cloudflare를 앞단에 두는 것이다. Cloudflare의 프리 플랜도 정적 콘텐츠를 상당 부분 캐싱해준다. HTML, CSS, JS, 이미지 등이 엣지에 캐싱되면 원본 서버까지 요청이 도달하지 않는다.

실제로 Cloudflare를 붙이기 전과 후를 비교해봤을 때, 같은 트래픽 패턴에서 원본 서버가 받는 요청이 60~70%가량 줄었다. 비용 한 푼 안 쓰고 서버 트래픽 문제를 크게 개선한 셈이다. 캐시 TTL 설정을 넉넉하게 잡아두는 것이 핵심이다.

이미지 최적화는 선택이 아니다

이미지 하나가 2MB라면, 방문자 100명만 봐도 200MB가 소진된다. 하루 방문자가 1,000명이면 2GB가 이미지 하나에서 나간다. 이미지 최적화를 처음에 귀찮다고 미루면 트래픽 소진이 예상보다 훨씬 빠르게 발생한다.

우리가 택한 방법은 WebP 포맷 변환과 업로드 전 리사이즈다. 사이트에서 실제로 필요한 최대 너비를 정하고, 그 이상의 해상도는 업로드 전에 잘라버린다. 이것만으로도 이미지 용량이 원본 대비 40~60% 줄어드는 경우가 많았다.

응답 압축을 켜두자

nginx 설정에서 gzip 또는 brotli 압축을 켜두면 텍스트 기반 응답이 대폭 줄어든다. HTML 10KB짜리가 압축 후 3KB가 되는 것은 드문 일이 아니다. JSON API 응답도 마찬가지다.

압축 설정은 한 번만 하면 되고, 이후에는 자동으로 적용된다. 트래픽 절감 대비 설정 비용이 거의 없는 작업이다.

트래픽 모니터링을 습관화한다

제한이 있다는 사실보다 더 위험한 것은 현재 사용량을 모르는 것이다. 우리는 매일 아침 전날 트래픽 소비량을 간단히 확인하는 루틴을 만들었다. 별도 대시보드까지 갈 것 없이, 서버 측에서 하루 단위로 집계된 로그를 간단히 파싱하는 스크립트 하나면 충분하다.

예상보다 트래픽이 급증한 날을 포착하면, 원인을 역추적해서 이후에 같은 패턴이 반복되지 않도록 대응할 수 있다.

제약은 설계를 가르친다

20GB라는 숫자가 처음에는 불편하게 느껴졌지만, 이 제약 덕분에 우리는 불필요한 요청을 줄이고, 캐싱 전략을 제대로 배우고, 이미지 최적화 습관을 들였다. 제약이 없었다면 느슨하게 넘어갔을 것들이다.

적은 자원으로 최대한 효율적으로 운영하는 것 — 작은 팀이 장기적으로 살아남는 방법 중 하나라고 생각한다.

— by slecs