메인 콘텐츠로 건너뛰기
TILNOTEAI 노트
page thumbnail

AI와 인공지능 시대, 캐시를 Redis 대신 Postgres에 두는 이유는?

A
alpha
•조회수 69

AI 서비스와 인공지능 애플리케이션이 점점 늘어나면서, 빠른 데이터 접근을 위한 캐시 시스템의 선택이 중요해졌습니다. 많은 개발자들이 ‘속도=Redis’라고 생각합니다. 그럼에도 불구하고 간단한 캐시라면 데이터베이스인 Postgres를 선택하는 사례도 적지 않습니다. 오늘은 실제 벤치마크 실험을 통해, Redis와 Postgres 중 어떤 것이 더 적합한지, 그리고 캐시 설계 시 어떤 점을 고려해야 하는지 쉽고 재미있게 풀어봅니다.

Redis와 Postgres: 캐시 용도로 어떻게 다를까?

Redis는 메모리 기반의 초고속 캐시 솔루션입니다. 반면, Postgres는 전통적인 디스크 기반 데이터베이스지만, 최근에는 unlogged 테이블 등 여러 튜닝 옵션을 통해 빠른 읽기/쓰기가 필요한 캐시 역할에도 활용되고 있습니다.

Redis는 요청당 몇 밀리초 미만의 답변을 내놓을 수 있고, TTL(Time To Live)·세션 관리 등 캐시 특화 기능을 내장하고 있습니다. Postgres는 이미 사용 중인 데이터베이스라면 추가 설치나 인프라 관리 부담이 적다는 장점이 있습니다.

실제 벤치마크: Redis vs Postgres 캐시 성능

과연 숫자는 어떻게 나올까요? 두 시스템에 3천만 개의 데이터를 동일하게 저장하고, GET(읽기), SET(쓰기), 혼합 작업에 대해 각 2분씩 벤치마크를 진행하면 다음과 같은 결과가 나왔습니다.

  • 속도(처리량) : Redis가 Postgres에 비해 훨씬 많은 요청을 동시에 처리할 수 있습니다.

  • CPU와 메모리 사용 : Redis는 테스트 내내 CPU와 RAM을 비교적 안정적으로 사용(약 3800MiB), Postgres는 CPU 2코어나 5000MiB 이상의 메모리를 연속으로 소모합니다.

  • 지연시간(Latency) : Redis가 Postgres보다 일관적으로 빠른 응답을 보여줍니다.

이로써 Redis가 캐시 용도에선 명확히 우위에 있습니다. 하지만 "Postgres도 못 따라갈 정도로 느린가?"라는 질문에는 답이 다릅니다. Postgres도 테스트에서 초당 7000건 이상의 요청을 처리하며, 웬만한 중소형 서비스에선 충분한 스펙을 제공합니다.

Postgres의 unlogged 테이블로 캐시 성능 개선하기

Postgres에는 ‘unlogged 테이블’이라는 특별한 옵션이 있습니다. 이 방법을 쓰면 쓰기 성능이 대폭 향상됩니다. 왜냐하면 데이터의 변경을 WAL(Write-Ahead Log)에 기록하지 않기 때문이죠.

  • 쓰기 성능 : unlogged 테이블을 사용하면 일반 테이블 대비 2배 이상의 처리량을 기대할 수 있습니다.

  • 단점 : 서버가 다운되면 데이터가 날아갈 수 있습니다. 캐시의 특성상 큰 문제가 되지 않는 경우가 많지만, 미션 크리티컬한 데이터에는 주의가 필요합니다.

Redis만의 기능과 Postgres의 만능성, 무엇을 고를까?

캐시 만을 위한 전문 기능이 필요한가요? Redis는 TTL, 다양한 자료구조, 클러스터링 등 수많은 캐시 지향 기능을 기본 제공합니다.

DB 하나로 끝내고 싶다면? 이미 Postgres를 메인 데이터베이스로 쓰고 있다면, 캐시를 Postgres에 구현하면 추가 인프라 관리를 피할 수 있습니다. 앞으로 요청량이 폭증한다면, 그 때는 Redis로 갈아타도 늦지 않습니다.

아주 중요한 팁: 캐시 인터페이스를 미리 만들어뒀다면, 백엔드를 Postgres에서 Redis로 자유롭게 갈아탈 수 있습니다. 실전 서비스 운영에서는 이런 유연성이 큰 도움이 됩니다.

AI 서비스에 적합한 캐시 전략: 실제 선택 기준

  1. 작은 프로젝트, 적당한 트래픽 : Postgres 캐시로 충분합니다. 성능도 괜찮고 관리도 간편!

  2. 고성능, 대규모 트래픽 : Redis는 빠르고 신뢰할 만한 선택입니다.

  3. 추가 의존성 줄이기 : 데이터베이스에 캐시까지 집중!

  4. 만약 확장성이 필요해질 때 : 인터페이스 기반으로 백엔드를 교체할 수도 있습니다.

결론적으로, 모든 상황에서 ‘무조건 Redis’가 답은 아닙니다. 프로젝트의 규모, 기능 요구, 관리 복잡성을 고려해 선택하세요.

캐시 설계의 현명한 접근: 미래를 준비하자

현대 AI·인공지능 서비스에서는 캐시 성능뿐만 아니라 관리 효율, 확장성, 장애 대응 등을 패키지로 고민해야 합니다. Redis는 분명 캐시용으로 탁월하지만, Postgres도 충분히 쓸모 있고, 프로젝트의 성장 과정에서 선택지를 넓혀줍니다. 무엇보다 캐시 인터페이스를 만들어 두면 미래에 더 많은 자유와 확장성을 누릴 수 있습니다.

지금은 Postgres, 미래엔 Redis—캐시 전략의 정답은 지금 내가 가진 것과 앞으로 필요할 것의 균형 잡기에 있습니다!

참고문헌

[1] Redis is fast – I'll cache in Postgres - Dizzy zone

[2] Redis - Wikipedia - Wikipedia

[3] PostgreSQL: Documentation: 18: CREATE TABLE - PostgreSQL 공식 문서

[4] Client-side caching reference | Docs - Redis 공식 문서

이미지 출처

#AI뉴스#인공지능