[IT 개발기] 새벽의 비상벨, Supabase DB 리밋 초과 사태와 캐싱(Caching)을 통한 서버 구출 작전

👤 인스피

조회 수 21

1. 무너진 서버와 수파베이스의 붉은색 경고창

<당시 발생한 어마어마한 사용량>

황급히 이불을 박차고 일어나 노트북을 켜고 제 웹사이트 주소를 입력해 보았습니다. 하지만 화면에 돌아오는 것은 응답 없는 하얀 브라우저 창과 무시무시한 '500 Internal Server Error'뿐이었습니다. 말 그대로 사이트가 완전히 뻗어버린 것이죠.

떨리는 손으로 Supabase 관리자 대시보드에 접속해 보았습니다. 디스크 I/O와 데이터베이스 커넥션(Connection) 수치를 나타내는 그래프가 제가 이용 중이던 요금제의 한계치를 아득히 돌파하여 붉은색 경고등을 미친 듯이 깜빡이고 있었습니다. 제가 운영하는 커뮤니티가 아직 그 새벽 시간대에 엄청난 수의 실제 유저가 동시에 몰릴 만한 규모는 아니었기에, 순간적으로 머릿속이 하얗게 비어버렸습니다. "도대체 누가, 왜, 무엇을 위해 내 데이터베이스를 이렇게 긁어간 걸까?"

2. 서버 마비의 진짜 범인: 악성 봇(Bot) 트래픽의 무차별 습격

원인을 찾기 위해 클라우드플레어와 백엔드 서버의 접속 로그(Access Log)를 샅샅이 뒤지기 시작했습니다. 아니나 다를까, 새벽 특정 시간대부터 정체를 알 수 없는 해외 IP 수십 개가 사이트의 모든 게시글과 목록 페이지를 무차별적으로 호출(Request)한 흔적을 발견했습니다.

이들은 진짜 사람이 아니라, 웹사이트의 콘텐츠(IT 글, 유저 게시물 등)를 무단으로 긁어가는 '웹 스크래핑 봇(Scraping Bot)'이거나 사이트의 취약점을 찾기 위해 아무 주소나 찔러보는 악성 봇들이었습니다. 수백, 수천 번의 새로고침과 페이지 이동이 1초 단위로 쏟아지니, 매번 그 요청에 맞춰 하드디스크를 뒤져 데이터를 꺼내주어야 했던 가엾은 Supabase 데이터베이스는 결국 과부하를 견디지 못하고 시스템을 셧다운 해버린 것입니다.

3. 근본적인 해결책을 찾아서: 요금제 업그레이드가 정답일까?

당장 멈춰버린 사이트를 복구하기 위해 Supabase의 요금제를 비싼 플랜으로 결제하고 서버의 물리적 체급을 늘리는(Scale-up) 가장 쉬운 방법도 있었습니다. 하지만 1인 개발자 입장에서, 광고 수익도 클릭해주지 않는 유령 같은 봇 트래픽을 감당하기 위해 매달 값비싼 서버 비용을 추가로 지불하는 것은 '밑 빠진 독에 물 붓기'라고 판단했습니다.

봇들이 또다시 공격해 오더라도, 그 충격파가 데이터베이스까지 닿지 않도록 중간에 강력한 방어막을 세워야만 했습니다. 그 방어막이자 훌륭한 완충재가 바로 '캐시(Cache)'였습니다.

4. 캐싱(Caching) 시스템 전격 도입: 방어력과 속도, 두 마리 토끼를 잡다

<현재는 대부분 50% 선에서 사용되고 있다>

캐싱의 원리는 우리 일상과 아주 비슷합니다. 식당에서 손님이 얼음물을 달라고 할 때마다 종업원이 매번 주방 안쪽 깊숙한 냉장고(데이터베이스)까지 뛰어가서 물을 떠 오는 것은 매우 비효율적입니다. 대신 홀(서버 앞단)에 커다란 얼음물 통(캐시)을 미리 준비해 두고, 손님이 물을 찾으면 즉시 그 자리에서 컵에 따라주는 방식입니다.

저는 백엔드 아키텍처를 전면 수정하여 이 캐시 시스템을 도입했습니다.

작동 방식: 봇들이 가장 집요하게 긁어가는 '메인 게시판 통합 목록'과 '조회수가 높은 IT 칼럼'의 데이터를 데이터베이스에서 딱 한 번만 정성껏 꺼내온 뒤, 접근 속도가 매우 빠른 메모리(Memory) 단에 수 분 동안 복사해 둡니다.
놀라운 결과: 시스템 도입 후, 악성 봇이 1초에 1,000번 똑같은 페이지를 새로고침 하더라도 서버는 더 이상 데이터베이스를 귀찮게 찌르지 않습니다. 메모리에 저장된 복사본 화면을 0.01초 만에 튕겨내 버릴 뿐입니다.

적용 직후 Supabase 대시보드를 다시 확인해 보니, 요동치던 데이터베이스 사용량 그래프가 언제 그랬냐는 듯 바닥에 착 달라붙어 평온한 일직선을 그리고 있었습니다. 서버가 완벽한 안정을 되찾은 순간이었습니다.

5. 맺으며: 위기는 가장 훌륭한 시스템 아키텍트다

고요한 새벽의 단잠을 깨운 끔찍한 서버 에러 사태였지만, 돌이켜보면 이 사건 덕분에 제 웹사이트의 백엔드 구조는 이전과 비교할 수 없을 정도로 견고하게 진화했습니다.

캐싱을 도입한 덕분에 봇 트래픽을 비용 증가 없이 완벽하게 방어해 낸 것은 물론이고, 부수적으로 실제 사람 방문자들이 사이트를 이용할 때 체감하는 페이지 로딩 속도까지 비약적으로 빨라지는 일석이조의 효과를 누리게 되었으니까요.

지금 이 순간에도 보이지 않는 봇들과 사이버 공간에서 소리 없는 전쟁을 치르고 있을 수많은 개인 블로거와 1인 개발자분들께, 저의 뼈아픈 데이터베이스 한도 초과 경험과 캐싱을 통한 극복기가 작은 힌트와 위로가 되기를 바랍니다. 트래픽 폭탄에 서버는 잠시 무너질 수 있지만, 우리는 그 에러 로그를 딛고 더 단단한 코드를 짜내면 되니까요.