1인 개발자의 트래픽 생존기: FastAPI와 Cloudflare 캐시 규칙(Cache Rules)으로 이미지 서버 부하 및 503 에러 완벽 해결

👤 인스피

조회 수 29

1. 웹 서버의 기본을 망각한 대가: 모든 것을 파이썬이 처리하다

현업에서 대규모 트래픽을 처리하는 아키텍처를 보면, 파이썬이나 자바 같은 백엔드 애플리케이션은 오직 '데이터 연산'만 담당합니다. 이미지나 CSS, JS 같은 정적(Static) 파일들은 그 앞단에 있는 Nginx나 CDN(콘텐츠 전송 네트워크)이 대신 클라이언트에게 던져주는 것이 정석입니다.

하지만 저는 1인 개발의 편의성을 위해 FastAPI의 StaticFiles 라우터를 이용해 서버가 이미지를 직접 반환하도록 세팅해 두었습니다. 유저가 적을 때는 문제가 없었지만, 구글 검색 봇과 글로벌 악성 크롤러들이 게시글을 무차별적으로 긁어가기 시작하자 서버의 대역폭은 순식간에 임계치를 넘어버렸습니다.

이 문제를 해결하기 위해 서버 사양(Scale-up)을 올리는 것은 엄청난 비용 낭비였습니다. 저는 이 엄청난 트래픽을 서버 바깥에서 무료로 처리해 줄 강력한 방패, Cloudflare(클라우드플레어) 캐시(Cache) 기능을 적극 활용하기로 했습니다.

2. 구원투수 등장: Cloudflare 완벽 캐시 규칙(Cache Rules) 세팅

클라우드플레어는 전 세계에 글로벌 엣지(Edge) 서버를 두고 있습니다. 유저가 내 사이트의 이미지를 요청하면, 한국에 있는 내 서버까지 오지 않고 유저와 가장 가까운 클라우드플레어 서버가 이미지를 대신 쏴주도록(캐싱) 설정할 수 있습니다.

저는 즉시 Cloudflare 대시보드에 접속하여 아래와 같이 강력한 캐시 규칙(Cache Rules)을 생성했습니다.

메뉴 이동: Caching ➡️ Cache Rules ➡️ Create rule 클릭
규칙 조건(If): URI Path starts with /static/ (이미지, CSS 등 모든 정적 파일 경로)
캐시 동작(Then):
- Cache eligibility: Eligible for cache (캐시 허용)
- Edge TTL: Override origin (원본 서버 설정 무시) ➡️ 1 month (1개월)
- Browser TTL: Override origin ➡️ 1 month (1개월)

이 설정의 의미는 간단합니다. "누군가 /static/ 경로에 있는 썸네일 이미지를 요청하면, 무조건 클라우드플레어 서버에 한 달(1개월) 동안 저장(캐싱)해 두고 네가 알아서 방문자들에게 나눠줘라! 내 파이썬 원본 서버에는 절대 요청을 보내지 마라!"라는 뜻입니다.

설정을 마친 후, 규칙을 즉시 배포(Deploy)하고 [Caching] ➡️ [Configuration] 메뉴에서 [Purge Everything (모든 캐시 지우기)] 버튼을 눌러 새로운 규칙이 백지상태에서 완벽하게 적용되도록 갱신했습니다.

3. 극적인 변화: 서버 점유율 0%의 평화를 되찾다

설정을 완료하고 단 10분 뒤, 터미널 로그 창에 기적 같은 변화가 일어났습니다.

1초에 수백 줄씩 미친 듯이 쏟아지며 서버를 괴롭히던 GET /static/uploads/...webp 200 OK 로그가 거짓말처럼 뚝 끊겼습니다. 구글 검색 로봇과 실제 유저들이 아무리 게시판을 광클하며 이미지를 긁어가도, 원본 서버(오라클 클라우드)에는 단 1건의 이미지 요청도 도달하지 않았습니다. 클라우드플레어의 글로벌 엣지 서버들이 철통같이 제 서버를 보호하며 대신 이미지를 뿌려주고 있었기 때문입니다.

서버의 CPU 점유율은 100%에서 5% 밑으로 뚝 떨어졌고, 503 에러는 완벽하게 자취를 감추었습니다. 파이썬 워커(Worker) 프로세스들은 오직 가벼운 텍스트(JSON, HTML) 연산에만 집중할 수 있게 되어, 전체적인 사이트 로딩 속도도 눈에 띄게 빨라졌습니다.

맺으며: 클라우드 인프라 활용의 중요성

백엔드 로직을 아름답게 짜는 것만큼이나 중요한 것은, '어떤 트래픽을 서버가 직접 처리하고 어떤 트래픽을 앞단(CDN)으로 위임할 것인가'를 설계하는 인프라 최적화 능력입니다.

1인 개발자나 소규모 스타트업일수록 비싼 서버 비용을 감당하기 어렵습니다. 만약 지금 운영 중인 웹사이트에 원인 모를 병목 현상이나 서버 다운이 발생하고 있다면, 애플리케이션 코드를 뒤엎기 전에 정적 자원(이미지, 폰트, CSS)이 백엔드 리소스를 갉아먹고 있지는 않은지 먼저 점검해 보시기 바랍니다. 클라우드플레어의 캐시 규칙 하나가 여러분의 서버 생명줄을 연장해 줄 최고의 치트키가 될 것입니다.

❓ 자주 묻는 질문 (FAQ)

Q1. Edge TTL과 Browser TTL의 차이는 무엇인가요?

A. Edge TTL은 클라우드플레어의 글로벌 서버(CDN)에 파일을 얼마 동안 저장해 둘지 결정하는 시간입니다. Browser TTL은 방문자(유저)의 개인 스마트폰이나 PC 브라우저(크롬, 사파리 등) 캐시에 파일을 얼마나 저장해 둘지 결정합니다. 정적 이미지 파일은 한 번 올라가면 수정될 일이 거의 없으므로 둘 다 1달(1 month) 정도로 길게 넉넉히 잡는 것이 가장 효율적입니다.

Q2. 캐시를 1달로 설정했는데, 만약 이미지를 수정(교체)하면 어떻게 되나요?

A. 유저들은 한 달 동안 클라우드플레어에 저장된 '옛날 이미지'를 보게 됩니다. 만약 이미지를 긴급하게 변경해야 한다면, 클라우드플레어 대시보드의 [Caching] 메뉴에서 [Purge Custom URL] 기능을 이용해 해당 이미지의 특정 주소만 캐시를 강제로 삭제(초기화)해 주시면 원본 서버의 최신 이미지를 다시 가져옵니다.

Q3. Nginx 같은 웹 서버 소프트웨어를 로컬에 직접 설치해서 캐싱하면 안 되나요?

A. 물론 Nginx를 활용한 로컬 캐싱도 훌륭한 방법입니다. 하지만 1인 개발 환경이나 무료 클라우드(Oracle Free Tier 등)를 사용할 때는 로컬 디스크 공간과 대역폭(Bandwidth)에 한계가 존재합니다. 클라우드플레어는 이 대역폭 요금을 무료로 방어해 주면서 글로벌 전송 속도까지 보장하므로, 압도적으로 유리한 인프라 구성 방식입니다.