피드로 돌아가기
A Production Python Telegram Bot Was Crashing Every 2 Hours. The Fix Was 18 Lines.
Dev.toDev.to
Backend

18줄의 Throttle Middleware로 2시간 주기 OOM Crash 완전 해결

A Production Python Telegram Bot Was Crashing Every 2 Hours. The Fix Was 18 Lines.

Boris Kl2026년 5월 20일8intermediate

Context

Python asyncio 기반 Telegram 봇이 약 140분 간격으로 반복적 Crash 발생. 일 평균 4,000건의 낮은 트래픽임에도 불구하고 특정 시점의 Burst Traffic이 Telegram API Rate Limit을 초과하며 시스템 전체로 장애가 전이되는 Cascading Failure 구조를 가짐.

Technical Solution

  • Inbound Traffic에 대한 Rate Limit 부재로 인한 Outbound API 요청 폭증 지점 식별
  • TelegramRetryAfter 발생 시 HTTP Session을 점유한 채 대기하는 asyncio Task의 누적 현상 분석
  • 누적된 Task가 SQLite Row Lock을 유발하여 Database Deadlock으로 이어지는 인과관계 파악
  • TTLCache를 활용한 Throttle Middleware를 도입하여 사용자별 1초 이내 중복 메시지 즉시 드랍 설계
  • Upstream 단계에서 Backpressure를 제어함으로써 Downstream의 Resource 고갈을 원천 차단하는 구조 구현
  • 불필요한 아키텍처 변경(Postgres 전환, Go 재작성) 대신 Root Cause인 진입점 제어에 집중

1. 장애 로그 분석 시 첫 번째 실패 지점을 식별하고 이후의 연쇄 반응과 구분할 것

2. 전체 Throughput보다 Peak Concurrency가 시스템 안정성에 미치는 영향을 검토할 것

3. 비동기 환경에서 외부 API 의존성이 있을 경우 반드시 Inbound Throttle/Rate Limit 계층을 설계할 것

4. 인프라 확장이나 언어 교체 전, 로직 레벨의 병목 지점과 리소스 점유 시간을 먼저 검증할 것

원문 읽기