FastAPI & Redis 캐싱 최적화: DB 조회 병목 해결 및 TTFB(첫 바이트 로딩 시간) 90% 단축기

👤 인스피

조회 수 7

1. 범인 분석: 매번 디스크를 두드리는 무거운 SQL 쿼리

개발자 도구(F12)의 Network 탭과 FastAPI APM 프로파일러를 띄워 백엔드 내부 수행 시간을 측정해 본 결과, 원인은 데이터베이스(PostgreSQL) 호출 방식에 있었습니다.

커뮤니티 메인 페이지 하나를 렌더링하기 위해서는 다음과 같은 쿼리들이 동시에 실행됩니다.

상단 고정 공지사항 목록 조회 (ORDER BY created_at DESC)
실시간 실시간 인기글 TOP 10 산출 (LIKE, VIEW COUNT 기준 정렬)
전체 카테고리별 최신 게시글 5개씩 추출 (JOIN 및 Subquery)
사이트 실시간 통계 (전체 회원수, 오늘 작성된 글 수)

유저 1명이 메인 페이지에 접속할 때마다 데이터베이스는 고성능 SSD 디스크를 10번 이상 왕복하며 똑같은 데이터를 반복해서 계산하고 있었습니다. 동시 접속자가 100명만 되어도 초당 1,000번이 넘는 무거운 Disk I/O가 쏠리며 DB CPU 점유율이 90%를 뚫어버린 것입니다.

디스크 기반의 RDBMS는 데이터의 영속성을 보장하는 데 특화되어 있을 뿐, 1초에 수천 번씩 반복되는 '읽기 전용(Read-Only) 요청'을 처리하기에는 구조적인 한계가 있었습니다.

2. 해결책 1단계: Cache-Aside 패턴과 비동기 Redis 구현

이 문제를 해결하기 위해 데이터 읽기 속도가 나노초(ns) 단위에 가까운 Redis(Remote Dictionary Server) 인메모리 데이터베이스를 아키텍처 중앙에 배치했습니다.

FastAPI의 비동기(async/await) 이벤트 루프가 멈추지 않도록, redis-py 라이브러리의 비동기 모듈(redis.asyncio)을 활용하여 Cache-Aside(Look-Aside) 패턴을 구현했습니다.

이 구조에서는 유저가 메인 페이지 요청을 보냈을 때 백엔드가 다음과 같이 동작합니다.

Cache Hit (캐시 성공): 먼저 Redis 메모리에서 main:popular_posts 키를 조회합니다. 데이터가 존재하면 DB를 거치지 않고 0.005초 만에 즉시 유저에게 응답합니다.
Cache Miss (캐시 실패): Redis에 데이터가 없으면 데이터베이스(PostgreSQL)에서 데이터를 가져온 뒤, 이를 Redis에 저장(TTL 5분)하고 유저에게 응답합니다.

3. 해결책 2단계: 캐시 스탬피드(Cache Stampede)와 무효화(Invalidation) 대응

캐시를 도입할 때 가장 주의해야 할 함정이 바로 캐시 스탬피드(Cache Stampede) 현상과 데이터 불일치(Stale Data) 문제입니다.

캐시 무효화 (Cache Invalidation): 관리자가 새로운 공지사항을 등록하거나 인기글 순위가 급변했을 때, 기존 캐시가 만료될 때까지 유저가 옛날 데이터를 보고 있으면 안 됩니다. 이를 위해 게시글 작성/수정 API 실행 시 await redis_client.delete("main:popular_posts") 코드를 연동하여, 이벤트 발생 즉시 캐시를 원자적으로 삭제하도록 설계했습니다.
TTL(Time-To-Live) 분산: 모든 캐시의 만료 시간을 동일하게 300초(5분)로 설정하면, 5분마다 모든 캐시가 동시에 터지면서 DB로 순간적인 트래픽 폭주가 몰립니다. 이를 막기 위해 TTL 값에 random.randint(-30, 30) 초 단위의 지터(Jitter)를 부여하여 캐시 만료 시점을 자연스럽게 분산시켰습니다.

맺으며: 45ms의 기적, SEO와 애드센스 승인의 지름길

Redis 캐싱 레이어를 적용한 후, 메인 페이지 로딩 속도는 그야말로 개벽을 맞이했습니다.

TTFB (Time to First Byte): 850ms -> 45ms (94.7% 감소)
DB CPU 점유율: 피크 타임 85% -> 8% 이하 유지
구글 서치 콘솔 LCP (Largest Contentful Paint): 2.8초 -> 0.9초 달성

구글 애드센스 2026 체크리스트의 핵심 요소인 "Fast loading website (빠른 로딩 속도)"는 단순히 CSS나 이미지를 압축하는 것만으로 완벽해지지 않습니다. 백엔드 단에서 데이터베이스의 무거운 연산을 메모리 수준으로 끌어올려 응답 속도(TTFB)를 극대화하는 엔지니어링이 뒷받침되어야 합니다.

1인 개발자로서 인프라 효율성을 극대화하고 유저와 검색엔진 봇 모두에게 극상의 쾌적함을 선물한 이번 Redis 캐싱 구축 경험은, 웹사이트의 기술적 완성도(E-E-A-T)를 증명하는 강력한 자산이 될 것입니다.

자주 묻는 질문 (FAQ)

Q1. 메모리 용량이 작은 저사양 VPS 서버에서도 Redis를 사용할 수 있나요?

A. 네, 충분히 가능합니다. Redis는 C언어로 작성되어 매우 가볍기 때문에, 텍스트 형태의 쿼리 결과값 수천 개를 캐싱하더라도 소모되는 RAM 용량은 수십 메가바이트(MB) 수준에 불과합니다. 또한 redis.conf 파일에서 maxmemory 256mb와 같이 최대 메모리 한도를 지정하고, 메모리가 차면 가장 오래된 캐시를 자동으로 지우는 maxmemory-policy allkeys-lru 옵션을 설정해 두면 저사양 서버에서도 안정적으로 운영할 수 있습니다.

Q2. Redis 캐시와 브라우저 캐시(HTTP Cache-Control)는 어떻게 다른가요?

A. 브라우저 캐시는 유저의 개인 기기(스마트폰, PC)에 정적 파일(이미지, CSS, JS)을 저장하여 재다운로드를 막는 클라이언트 측 기술입니다. 반면 Redis 캐시는 서버 내부의 메모리에 DB 쿼리 결과나 API 응답 데이터를 저장하여, 모든 유저가 공통으로 요청하는 백엔드 연산 부하를 줄여주는 서버 측 기술입니다. 두 기술을 함께 적용해야 완벽한 속도 최적화가 이루어집니다.

Q3. 실시간성이 중요한 댓글이나 좋아요 수도 Redis에 캐싱해도 되나요?

A. 실시간이 생명인 데이터는 캐시 TTL을 3~5초 정도로 매우 짧게 가져가거나, DB에 직접 쓰기 전에 Redis의 INCR(원자적 증가) 명령어를 활용해 메모리에서 먼저 숫자를 올린 뒤 주기적으로 DB에 동기화하는 'Write-Back' 패턴을 사용하는 것이 좋습니다. 데이터의 특성에 맞춰 적절한 캐싱 전략을 선택하는 것이 중요합니다.