파이썬 FastAPI 서버 생존기: Redis를 활용한 API Rate Limiting(속도 제한) 구현과 트래픽 방어 알고리즘

👤 인스피

조회 수 12

1. 트래픽 폭탄의 공포: 왜 애플리케이션 레벨의 속도 제한이 필수일까?

보통 트래픽 방어라고 하면 인프라 단계(AWS, Cloudflare 등)에서 해결해야 한다고 생각하기 쉽습니다. 하지만 백엔드 서버(FastAPI) 내부에도 반드시 브레이크가 필요합니다.

예를 들어, 누군가 게시판에 1초 만에 100개의 '의미 없는 도배 글'을 작성하는 스크립트를 돌렸다고 가정해 보겠습니다. 이 요청들은 문법적으로 완벽한 형태를 띠고 있으므로 외부 방화벽은 이를 정상적인 사용자로 착각하고 통과시킵니다. 결국 이 100개의 데이터는 고스란히 데이터베이스에 꽂히게 되고, 서버 용량과 트래픽 비용을 무의미하게 갉아먹게 됩니다.

따라서 서버는 "동일한 사용자(IP 또는 계정)가 1분에 5번까지만 글을 쓸 수 있다"라는 명확한 규칙을 가지고 있어야 합니다. 이 규칙을 넘어서는 요청이 들어오면 서버는 즉시 문을 닫고, "너무 빠른 요청입니다. 잠시 후 다시 시도해 주세요"라는 메시지를 반환해야 합니다. 이것이 바로 Rate Limiting의 핵심 목적입니다.

2. FastAPI와 Redis의 환상적인 콜라보레이션

파이썬 웹 프레임워크인 FastAPI에서 속도 제한을 구현하는 방법은 여러 가지가 있습니다. 가장 쉬운 방법은 파이썬 내부 메모리나 관계형 데이터베이스(RDBMS)에 접속 기록을 저장하는 것입니다.

하지만 저는 이전 성능 최적화 작업 때 도입했던 Redis(레디스)를 속도 제한의 저장소로 적극 활용하기로 했습니다. 관계형 DB(PostgreSQL, MySQL 등)는 무거운 디스크 I/O를 발생시키기 때문에, 1초에도 수십 번씩 "이 IP가 몇 번 접속했지?"를 묻고 업데이트하는 작업에는 전혀 적합하지 않습니다. 반면, 인메모리(In-Memory) 기반인 Redis는 빛처럼 빠른 속도로 데이터를 읽고 쓰며, 심지어 데이터의 만료 시간(TTL: Time To Live)을 자체적으로 관리해 주는 기능까지 갖추고 있어 속도 제한 시스템에 그야말로 찰떡궁합이었습니다.

3. 고정 윈도우(Fixed Window) 알고리즘으로 효율성 잡기

Rate Limiting을 구현하는 알고리즘에는 '토큰 버킷(Token Bucket)', '슬라이딩 윈도우(Sliding Window)' 등 다양한 방식이 있지만, 저는 1인 개발자의 유지보수성과 서버 리소스를 고려하여 가장 직관적이고 가벼운 '고정 윈도우(Fixed Window)' 방식을 선택했습니다.

로직은 생각보다 단순 명쾌합니다.

사용자가 API(예: 로그인)를 요청하면, 서버는 그 사용자의 IP 주소를 추출합니다.
Redis에 rate_limit:192.168.0.1:login이라는 고유한 키(Key)를 생성하고, 카운트를 1 올립니다.
이 키의 수명(TTL)은 60초로 설정합니다. 즉, 1분이 지나면 이 기록은 Redis에서 흔적도 없이 사라집니다. (Garbage Collection의 완벽한 자동화!)
만약 60초 안에 이 카운트가 제가 설정한 임계치(예: 1분당 10회)를 초과하게 되면, FastAPI는 그 즉시 에러를 발생시킵니다.

이 로직을 모든 API마다 하드코딩하는 것은 비효율적이므로, FastAPI의 의존성 주입(Dependency Injection) 기능을 활용하여 하나의 공통 '방어 모듈'로 묶어두었습니다. 이제 새로운 기능(쪽지 보내기, 댓글 달기 등)을 개발할 때마다 함수 앞단에 @limiter(requests=5, window=60)이라는 코드 한 줄만 선언해 주면, 그 즉시 완벽한 방어막이 쳐지게 됩니다.

4. 429 Too Many Requests: 유저 경험(UX)을 지키는 우아한 거절

속도 제한에서 기술적인 구현만큼이나 중요한 것은 '정상적인 유저가 겪을 불편함을 최소화하는 것'입니다.

실수로 새로고침(F5)을 연타한 선량한 회원에게 무시무시한 서버 에러(500 Internal Server Error) 화면을 띄우거나, 아예 접속을 영구 차단해 버린다면 커뮤니티의 신뢰도는 바닥으로 떨어질 것입니다.

그래서 시스템이 임계치를 넘은 요청을 차단할 때는, 표준 HTTP 상태 코드인 429 Too Many Requests를 정확하게 반환하도록 백엔드를 설계했습니다. 프론트엔드(UI)에서는 이 429 코드를 감지하면 붉은색 경고창 대신, "요청이 너무 많습니다. 쾌적한 환경을 위해 1분 뒤에 다시 시도해 주세요"라는 부드러운 토스트 팝업(Toast Popup)을 띄우도록 예외 처리를 해두었습니다. 해커에게는 넘을 수 없는 철벽을 치면서도, 일반 유저에게는 친절한 안내를 제공하는 밸런스를 맞춘 것입니다.

맺으며: 보이지 않는 무기가 사이트의 수명을 결정합니다.

이번 API Rate Limiting 기능을 자체적으로 구현하고 서버에 배포한 첫날, Redis 로그에 수백 개의 무의미한 로그인 봇 요청들이 429 에러를 맞고 튕겨 나가는 것을 보며 엄청난 안도감과 쾌감을 느꼈습니다. 덕분에 백엔드 데이터베이스는 평온을 되찾았고, 사이트 로딩 속도는 이전보다 훨씬 안정적으로 유지되고 있습니다.

화려한 프론트엔드 디자인이나 새로운 게시판을 추가하는 것도 중요하지만, 커뮤니티가 1년, 5년, 10년 이상 튼튼하게 살아남기 위해서는 결국 보이지 않는 서버 뒷단의 방어 아키텍처가 얼마나 견고한지가 성패를 가릅니다.

지금 당장 트래픽이 많지 않더라도, 언젠가 찾아올 '트래픽 급증'이라는 즐거운 위기를 웃으며 맞이할 수 있도록 방어망을 미리 쳐두는 것. 그것이 바로 1인 개발자가 코드를 작성하며 가장 신경 써야 할 기본기라고 생각합니다. 오늘도 안전하고 쾌적한 IT 커뮤니티 생태계를 만들기 위해 고민하고 계실 수많은 서버 개발자분들의 도전을 진심으로 응원합니다. 계속해서 사이트를 다듬어가는 생생한 개발기로 다시 찾아오겠습니다!