FastAPI 서버 성능 한계 돌파: Redis 캐싱(Caching)으로 DB 부하 줄이고 응답 속도 극대화하기

👤 인스피

조회 수 13

1. 왜 DB 놔두고 굳이 캐시(Cache)를 써야 할까?

상황을 한 번 가정해 보겠습니다. 여러분의 웹사이트 메인 화면에 '오늘의 인기글 TOP 10'이 떠 있습니다. 이 인기글 목록은 하루에 딱 한 번 자정에 업데이트됩니다.

그런데 하루 종일 사이트에 들어오는 수천 명의 유저들에게 이 목록을 보여주기 위해, 백엔드 서버는 매번 DB에 접속해서 "조회수 제일 높은 글 10개 찾아줘!"라고 쿼리를 날립니다. 어차피 결과는 밤 12시까지 100% 똑같은데 말이죠. 이건 마치 옆자리 동료가 "오늘 점심 메뉴 뭐야?"라고 100번 물어볼 때마다, 매번 1층 식당까지 뛰어 내려가서 메뉴판을 보고 올라와 대답해 주는 것과 같은 엄청난 낭비입니다.

이럴 때 필요한 것이 바로 캐싱(Caching)입니다. 식당 메뉴판을 내 책상 위 '포스트잇(메모장)'에 한 번만 적어두고, 누가 물어볼 때마다 그 포스트잇만 보고 0.1초 만에 대답해 주는 원리입니다. 그리고 이 포스트잇 역할을 해주는 최고의 오픈소스 소프트웨어가 바로 Redis입니다.

2. 인메모리(In-Memory)의 마법, Redis 도입하기

Redis는 하드디스크(SSD)에 데이터를 저장하는 일반적인 데이터베이스와 달리, 컴퓨터의 메모리(RAM)에 데이터를 저장합니다. 전원이 꺼지면 날아가 버리는 휘발성 공간이지만, 디스크를 뒤지는 것과는 비교도 할 수 없을 만큼 압도적으로 속도가 빠릅니다.

저는 곧바로 우분투 서버에 Redis를 설치하고, 파이썬 FastAPI 코드에 캐싱 로직을 끼워 넣었습니다. 로직의 흐름은 아주 단순명료합니다.

유저가 '인기글 목록' API를 호출한다.
백엔드는 DB에 가기 전에, 먼저 Redis(포스트잇)에 인기글 목록이 적혀 있는지 확인한다.
(Cache Hit) 만약 적혀 있다면? DB까지 갈 필요 없이 Redis에 있는 데이터를 0.001초 만에 유저에게 쏴준다.
(Cache Miss) 만약 안 적혀 있다면? 어쩔 수 없이 DB에 가서 데이터를 가져온 뒤, 유저에게 전달함과 동시에 그 결과를 Redis 포스트잇에 적어둔다. (다음 유저를 위해서!)

3. TTL(Time To Live): 오래된 쉰내 나는 데이터 방지하기

캐싱을 할 때 가장 조심해야 할 점은 '업데이트'입니다. 인기글 순위가 바뀌었는데, 포스트잇에 적어둔 옛날 순위를 계속 보여주면 안 되니까요.

그래서 Redis에는 TTL(Time To Live)이라는 아주 기가 막힌 기능이 있습니다. "이 포스트잇은 딱 10분(600초) 뒤에 스스로 불타 없어지게 해 줘"라고 유통기한을 설정하는 것입니다. 위 파이썬 코드에서 setex 함수를 사용해 600초를 설정해 두면, 10분 동안은 수만 명이 접속해도 DB 부하 없이 Redis가 모든 트래픽을 가볍게 방어합니다. 그리고 10분이 지나면 캐시가 날아가고, 딱 한 명의 유저 요청만이 다시 DB를 깨워 최신 데이터를 가져오게 만들죠.

4. 결과: API 응답 속도 40ms에서 2ms로, 쾌감의 순간

설정을 마친 후 부하 테스트(Load Testing) 도구를 이용해 짧은 시간에 엄청난 접속 요청을 쏟아부어 보았습니다.

이전에는 1초당 100번의 요청만 들어와도 Supabase DB의 CPU 그래프가 널뛰기를 하고 응답 속도가 늦어졌지만, Redis를 앞단에 세운 이후로는 DB 그래프가 바닥에 평온하게 누워 있었습니다. 모든 트래픽을 메모리 단에서 쳐내고 있었기 때문이죠. API 응답 속도는 40ms 수준에서 단 2ms(0.002초)로, 측정하는 의미가 없을 정도로 극한의 속도를 뿜어냈습니다.

맺으며: 1인 개발자에게 캐싱은 '선택이 아닌 생존'

개인 자금으로 서버를 운영하는 1인 개발자에게 트래픽 폭주로 인한 DB 서버 업그레이드는 굉장한 금전적 부담입니다. 하지만 Redis라는 훌륭한 오픈소스를 활용하면, 가장 저렴한 깡통 서버 하나로도 수천, 수만 명의 동시 접속자를 여유롭게 받아낼 수 있는 견고한 아키텍처를 설계할 수 있습니다.

"무조건 DB 사양을 올리기 전에, 코드로 해결할 수 있는 최적화 방안을 먼저 찾자."

이것이 제가 이번 캐싱 도입 작업을 통해 얻은 가장 값진 교훈입니다. 여러분의 서버에도 지금 당장 매번 똑같은 쿼리를 반복하며 땀 흘리고 있는 불쌍한 API가 있다면, 오늘 바로 Redis라는 달콤한 휴식을 선물해 보시는 것은 어떨까요?