Redis를 버리고 PostgreSQL로, 비용 절감과 운영 간소화 성공!
Redis를 사용하던 웹 애플리케이션에서 PostgreSQL로의 마이그레이션을 통해 비용 절감 및 운영 복잡성을 줄임
UNLOGGED 테이블(Unlogged Tables), LISTEN/NOTIFY, SKIP LOCKED 등 PostgreSQL의 기능을 활용하여 캐싱, Pub/Sub, 작업 큐를 구현
벤치마크 결과(Benchmark Results)를 통해 PostgreSQL이 Redis보다 약간 느리지만, 전체적인 성능은 충분하며 트랜잭션 일관성을 확보
극단적인 성능 요구 사항(Extreme Performance Requirements)이 아니라면, PostgreSQL을 Redis의 대안으로 고려할 수 있음을 시사
PostgreSQL을 활용한 캐싱 구현
저자는 UNLOGGED 테이블(Unlogged Tables)을 활용하여 Redis의 캐싱 기능을 PostgreSQL로 대체했다. UNLOGGED 테이블은 Write-Ahead Log(WAL)를 생략(Skip)하여 쓰기 성능을 향상시키고, 서버 충돌 시 데이터 손실을 감수하는 대신 빠른 속도를 제공한다. 벤치마크 결과, PostgreSQL의 UNLOGGED INSERT는 Redis SET보다 약간 느리지만, 캐싱에 충분한 성능을 보였다. 또한, 데이터베이스와 캐시 간의 데이터 일관성(Data Consistency)을 트랜잭션으로 보장할 수 있다는 장점이 있다.
PostgreSQL Pub/Sub(LISTEN/NOTIFY)의 활용
PostgreSQL의 LISTEN/NOTIFY 기능을 사용하여 Redis의 Pub/Sub 기능을 대체했다. NOTIFY는 메시지를 발행하고, LISTEN은 채널을 구독하여 실시간 알림을 구현한다. Redis Pub/Sub에 비해 약간의 지연 시간 증가가 있었지만, 별도의 인프라 없이 데이터베이스 내에서 모든 작업을 처리할 수 있다는 장점이 있다. 특히, 데이터베이스 트랜잭션과 결합하여 원자적 연산(Atomic Operation)을 보장할 수 있어, 데이터 일관성을 유지하면서 실시간 로그 스트리밍과 같은 기능을 구현할 수 있다.
PostgreSQL의 작업 큐(Job Queue) 구현
저자는 SKIP LOCKED 기능을 활용하여 PostgreSQL 기반의 작업 큐를 구현했다. SKIP LOCKED는 여러 워커(Worker)가 동시에 작업을 처리할 수 있도록 하며, 작업 실패 시 자동으로 재시도하도록 설계되었다. Redis 기반의 작업 큐(Bull/BullMQ)에 비해 약간의 성능 저하가 있었지만, PostgreSQL의 데이터 격리 아키텍처(Data Isolation Architecture)를 활용하여 데이터베이스 내에서 모든 작업을 처리할 수 있다는 장점이 있다. 또한, 작업 큐와 관련된 모든 데이터를 데이터베이스 트랜잭션으로 관리하여 데이터 일관성을 확보할 수 있다.
Redis vs PostgreSQL: 성능 및 운영 효율성 비교
저자는 실제 벤치마크를 통해 Redis와 PostgreSQL의 성능을 비교 분석했다. 결과적으로 PostgreSQL은 캐싱, Pub/Sub, 작업 큐 등에서 Redis보다 약간 느린 성능을 보였지만, 전반적으로 1ms 이내의 응답 시간을 유지했다. 하지만, PostgreSQL은 Redis에 비해 운영 복잡성(Operational Complexity)을 줄이고, 데이터 일관성(Data Consistency)을 확보할 수 있다는 장점이 있다. 특히, 데이터베이스 백업, 모니터링, 장애 조치(Failover)를 통합 관리할 수 있어, 운영 효율성을 크게 향상시킬 수 있다.
