FastAPI 서버 503 에러 트러블슈팅: DB 커넥션 풀 고갈(QueuePool Overflow) 해결 및 Cloudflare 속도 제한(Rate Limiting) 방어기

👤 인스피

조회 수 12

1. 범인은 무한대의 무기를 쥔 'IPv6 봇넷(Botnet)'

진짜 사람(브라우저)이 웹사이트에 접속하면 HTML 문서를 읽은 뒤, 화면을 그리기 위해 본문에 포함된 수십 개의 썸네일 이미지 파일들(/static/uploads/*.webp)을 연달아 요청합니다.

하지만 로그에 찍힌 악성 봇들은 이미지 파일은 단 하나도 요청하지 않은 채, 오직 텍스트 데이터만 빼가기 위해 page=170, page=448 같은 일반 유저라면 절대 누르지 않을 아득히 깊은 페이지(Deep Pagination)의 주소만 1초 간격으로 무자비하게 긁어가고 있었습니다.

가장 큰 문제는 이들이 기존 IPv4가 아닌 무한대에 가까운 IP를 생성할 수 있는 IPv6 주소(2a10:..., 2a11:..., 2a13:..., 2a01:...) 대역을 사용하고 있었다는 점입니다. 개별 IP를 하나씩 차단하는 '두더지 게임'으로는 이 방대한 봇넷 부대를 절대 막을 수 없었습니다. 데이터베이스는 수백 페이지 뒤의 데이터를 찾기 위해 무거운 연산(Offset/Limit)을 반복하다 결국 커넥션 풀을 모두 소진하고 기절해버린 것입니다.

2. 방어막 1: Cloudflare 속도 제한(Rate Limiting)과 DB 튜닝

서버 코드를 고치기 전에 앞단(네트워크)에서 트래픽의 홍수를 막아야 했습니다. 저는 즉시 Cloudflare 대시보드를 열어 강력한 속도 제한(Rate Limiting) 규칙을 적용했습니다.

적용 경로: 자동 업로드 API 등의 예외 경로를 제외한 사이트 전체(/)
제한 기준: 10초당 400회 요청 초과 시, 10초간 강제 차단(Block)
추가 보안: 로그인 엔드포인트 등을 겨냥한 봇 공격을 방어하기 위해 유출된 비밀번호 검증(Leaked credential check) 기능 활성화

'10초에 400회'라는 기준은 사람 기준으로는 절대 넘을 수 없는 수치 같지만, 실제 웹 페이지 하나가 로딩될 때 수십 개의 이미지와 정적 파일이 동시에 호출된다는 점을 고려하여 일반 유저들이 억울하게 차단당하지 않도록 매우 넉넉하지만 확실한 임계치(Threshold)로 설정한 것입니다. 이와 더불어 DB 쿼리 타임아웃을 짧게 줄이는 'Fail-Fast' 튜닝을 곁들여, 봇이 무거운 요청을 던져도 DB가 오랫동안 붙잡고 있지 않고 즉시 연결을 끊도록 조치했습니다.

3. 방어막 2: '페이징 봇(Paging Bots)' 맞춤형 스마트 룰

속도 제한으로 급한 불을 껐다면, 이번에는 서버 자원을 가장 많이 갉아먹는 '무단 딥 페이징 스크래핑'을 원천 봉쇄할 차례입니다.

봇넷들은 끈질기게 URL 쿼리의 파라미터(page=, lang=)를 조작하며 들어왔습니다. 저는 Cloudflare WAF 사용자 지정 규칙에 다음과 같은 아주 스마트한 논리 구조(AND)를 작성하여 배포했습니다.

조건 A: HTTP 요청의 User-Agent 문자열에 bot, facebook, spider, crawl 등의 단어가 포함되어 있을 것.
조건 B: URL의 Query String에 page= 또는 lang= 파라미터가 포함되어 있을 것.
조치 (Action): 위 두 조건을 동시에 만족하면 서버 자원 보호를 위해 즉시 차단(Block)할 것.

이 스마트 룰은 검색 엔진 최적화(SEO)를 위해 메인 화면을 읽어가는 착한 크롤러들의 기본 활동은 허용하면서도, DB를 죽이는 주범인 '게시판 하단 페이징 버튼 광클 봇'들만 정확하게 식별하여 목을 베어버리는 최고의 가성비 방어책이 되었습니다.

서버 방어 인프라 세팅을 마치고 터미널 창을 모니터링하자 기적 같은 평화가 찾아왔습니다. 지긋지긋하던 QueuePool 에러와 503 에러는 단 한 줄도 보이지 않았고, 대신 진짜 사람 유저들이 이미지를 정상적으로 요청하는 쾌적한 200 OK와 304 Not Modified 로그만이 물 흐르듯 아름답게 올라오고 있었습니다.

웹 서버 운영은 결국 '보이지 않는 악성 트래픽과의 끝없는 영토 전쟁'입니다. 백엔드 코드의 최적화도 중요하지만, 1인 개발자일수록 Cloudflare WAF와 같은 강력한 엣지(Edge) 네트워크 방어막을 적극적으로 활용하여 서버 자원을 보호하는 것이 성공적인 커뮤니티 성장의 첫걸음임을 다시 한번 새길 수 있었습니다.

❓ 자주 묻는 질문 (FAQ)

Q1. User-Agent에 bot을 차단하면 구글 애드센스 심사 봇이나 SEO 크롤러도 막히는 것 아닌가요?

A. 일반적인 텍스트 차단만 쓰면 막힐 위험이 있습니다. 하지만 Cloudflare의 WAF 규칙을 작성할 때, 조건문에 Known Bots (알려진 봇) = Off (꺼짐)을 추가해주면, 구글(Googlebot, Mediapartners-Google)이나 빙(Bingbot) 같이 공식적으로 인증된 착한 봇들은 이 차단 규칙을 프리패스로 우회하게 됩니다. 따라서 애드센스 심사나 구글 검색 노출에는 1%의 악영향도 미치지 않습니다.

Q2. 왜 '10초당 400회'라는 높은 숫자로 속도 제한을 걸었나요? 좀 더 빡빡하게 50회 정도로 줄이면 안 되나요?

A. 현대의 반응형 웹사이트는 HTML 문서 한 장만 불러오는 것이 아닙니다. 본문에 삽입된 수십 장의 고화질 이미지(.webp), CSS, 자바스크립트 파일들이 비동기적으로 동시에 로딩됩니다. 만약 속도 제한을 10초에 50회 정도로 빡빡하게 잡으면, 스마트폰으로 게시글을 빠르게 스크롤하며 이미지를 훑어보는 평범한 '진짜 유저'들까지 악성 봇으로 오해받아 10초간 사이트 접속이 차단(Block)되는 최악의 사용자 경험(UX) 오류가 발생할 수 있습니다.

Q3. 정적 파일(이미지)을 서빙할 때 봇들이 몰려오면 DB가 죽지 않나요?

A. 이미지 파일(.webp, .jpg) 등을 가져가는 요청(/static/uploads/...)은 데이터베이스(PostgreSQL)를 전혀 거치지 않습니다. 파이썬 워커가 하드디스크에 있는 파일을 직접 건네주거나 Cloudflare의 엣지(Edge) 캐시 서버가 대신 반환하므로, 이미지 요청이 1초에 수백 번 쏟아지더라도 DB 커넥션 풀을 소모하지 않아 서버가 안전하게 유지됩니다. 문제가 되는 것은 오직 무거운 SQL 연산을 유발하는 동적 페이지 호출(/post/...?page=)입니다.