캐시를 도입하면서 고민했던 기록
Redis vs Memcached
INSK를 만들면서 처음으로 “캐시”를 진지하게 고민하게 됐다.
데이터가 많아지고 기능이 늘어나면서, DB만으로는 점점 부담이 커졌기 때문이다.
그래서 자연스럽게 이런 질문이 생겼다.
"캐시를 쓰자. 그런데 어떤 캐시를 쓰지?"
Memcached? 아니면 Redis?
막연하게 “Redis가 더 유명하니까” 같은 기준이 대신,
우리 프로젝트의 특징과 미래 확장까지 함께 고려해보면서 정리해 보았다.
캐시는 왜 필요한가
웹 서비스 구조를 보면, 캐시는 결국 속도를 위한 계층이다.
요청이 들어올 때 항상 DB까지 내려가면 느려질 수밖에 없다.
자주 조회되지만 매 순간 최신일 필요는 없는 데이터라면, 메모리에 저장해 놓고 빠르게 꺼내 쓰는 것이 훨씬 효율적이다.
그래서 캐시는 보통 이렇게 이용된다.
사용자 요청
캐시에서 먼저 확인
(없으면) DB 조회
결과를 캐시에 저장
이 단순한 구조 하나로 서비스 체감 속도는 크게 달라진다.
!캐시는 동일하거나 자주 반복되는 요청에 대해 DB 대신 빠르게 응답하기 위해 사용된다.
다만, 캐시는 한 번 저장된 값을 일정 시간 그대로 유지하기 때문에, 시점에 따라 값이 달라지는 데이터에는 만료 전략이나 무효화(캐시 삭제) 설계가 필요하다.
Memcached
Memcached는 아주 단순한 캐시 서버다.
메모리 기반
key-value만 저장
영속성 없음
구조가 직관적이고 빠름
즉, 단순 조회 캐시에 정말 적합하다.
예를 들면,
메인 화면에 노출되는 데이터
자주 바뀌지 않는 목록
자주 조회되지만 중요도가 낮은 정보
우리 프로젝트인 INSK는 AI 기반 뉴스 트렌드 센싱을 하는 서비스이다.
뉴스 같은 경우, 속도가 아주 중요하다거나 정확한 최신 데이터가 아니어도 된다면
Memcached만으로도 충분히 운영할 수 있다는 얘기가 많다.
실제로 맞는 말이다.
하지만, 곧바로 “우리 서비스에도 충분하다”라고 보기엔 애매했다.
조금 다른 방향의 도구 Redis
Redis를 공부하고 프로젝트 'INSK'와 '냉장Goat'등에 적용하며 느낀 점은,
Redis가 단순 캐시라기보다 “메모리 기반 데이터 저장소”에 가깝다는 것이다.
문자열뿐 아니라 리스트, 집합, 정렬된 집합, 해시, 큐, 카운터 등
여러 구조를 다룰 수 있고,
필요하면 데이터 일부를 디스크에 남길 수도 있다.
그래서 세션 관리, 랭킹, 분산락, 메시지 큐 비슷한 역할까지 맡을 수 있다.
단순히 “빠르다”를 넘어서, 서비스 전체 구조에 자연스럽게 녹일 수 있는 도구였다.
우리 프로젝트에서 실제로 고민했던 지점들
INSK는 단순한 뉴스 열람 서비스가 아니다.
다음과 같은 기능을 갖춘 뉴스 트렌드 센싱 자동화 플랫폼이다.
키워드 기반 자동 뉴스 수집
AI 요약과 인사이트 분석
중복 기사 판정
좋아요/싫어요 피드백
기사 점수 계산
부서별 TOP5 추천
PDF 보고서 생성
이 흐름을 만들다 보니, 캐시가 단순 조회에서 끝나지 않았다.
점수 랭킹이 필요했고,
파이프라인 중복 실행을 막아야 했고,
나중에 세션/토큰 관리까지 고려해야 했다.
여기서 Memcached는 기능적으로 한계가 있었고,
Redis는 이미 잘 알려진 패턴이 많았다.
특히 점수와 랭킹이 결정적이었다.
기사 점수는 계속 변한다.
추천 결과도 계속 변한다.
이걸 모두 DB만으로 처리하려고 하면 부하가 크다.
Redis의 정렬된 집합 구조를 사용하면,
점수를 기준으로 정렬
상위 N개 즉시 조회
이런 기능을 자연스럽게 만들 수 있었다.
이 지점에서 “Redis가 필요하겠다”라는 그림이 어느 정도 확정됐다.
Cloud Wave 이후
Redis vs Kafka
캐시를 고민하다 보니, 자연스럽게 “캐시로 감당하면 안 되는 데이터는 어디로 가야 하는가”라는 질문이 생겼다.
CJ올리브네트웍스 부트캠프 Cloud Wave 도커 강의에서 들은 내용이 특히 인상 깊었다.
Redis는 메모리 기반이라 빠르지만, 기본적으로 “사라져도 되는 데이터”에 어울린다.
Kafka는 디스크 기반이라 상대적으로 느리지만, 데이터를 다시 읽고 재처리할 수 있다.
결국 기준은 단순하다.
이 데이터가 사라져도 되는가?
아니면 반드시 남아 있어야 하는가?
캐시는 사라져도 큰 문제가 없어야 한다.
하지만 로그, 이벤트 흐름, 결제 내역 같은 것들은 사라지면 안 된다.
'장애 상황'
Elastic Beanstalk 서버가 죽을 수도 있다.
문제는 여기서 끝이 아니다.
서버가 죽으면, 그 순간 무슨 일이 발생했는지 기록조차 남지 않는다.
그래서 실무에서는 애플리케이션 안에 로그를 두지 않고,
Kafka 같은 큐 시스템으로 로그를 외부에 모아 둔다.
서버가 죽어도 로그는 남는다.
재처리도 가능하다.
이걸 보며 알게 되었다.
“잘 동작하게 만드는 것”보다
“망가졌을 때 추적 가능하게 만드는 것”이 훨씬 중요할 때가 많다는 것.
Trade-off
빠를수록 좋은 것도 아니고,
안전할수록 좋은 것도 아니다.
비용, 운영 난이도, 유지보수, 확장성.
이 모든 걸 놓고 판단해야 한다.
상사가 1초마다 새 일을 던지면 결국 아무 것도 못하듯,
시스템도 한 곳에 책임을 몰아주면 결국 무너진다.
그래서 역할을 나누고, 필요하면 다른 계층으로 빼는 것이다.
컨테이너, 볼륨, 쿠버네티스까지
실습 중 네트워크 설정을 바꾸려고 컨테이너를 내렸다가 올렸는데
로그가 모두 사라진 경험이 있었다.
그때 볼륨의 중요성을 체감할 수 있었다.
컨테이너는 언제든 삭제될 수 있는 존재다.
데이터는 컨테이너 바깥에 두어야 한다.
쿠버네티스도 같은 맥락이었다.
장애가 나면 자동으로 다시 띄우고,
트래픽이 증가하면 자동으로 늘리고,
배포 과정에서 서비스가 멈추지 않게 제어한다.
이 모든 것이 결국 “살아남도록 설계하는 일”이었다.
프록시를 이용한 인증 분리
DB 비밀번호, API 키 같은 민감 정보는
애플리케이션이 직접 들고 있지 않도록 프록시에서 처리한다.
이렇게 되면,
키 공유 문제,
비밀번호 변경,
타팀 협업 이슈가 훨씬 단순해진다.
https://docs.cloud.google.com/sql/docs/mysql/connect-auth-proxy?hl=ko
구글 Cloud SQL Proxy 문서를 보면서,
AWS는 방식이 다르지만 목적은 동일하다는 것도 이해됐다.
인증은 가능한 한 애플리케이션 바깥으로 빼는 게 중요하다.
이번 프로젝트를 통해 느낀 점
처음엔 그냥 “Redis vs Memcached” 정도의 고민이었다.
하지만 점점 커지더니 이렇게 확장되었다.
캐시 → 영속 메시지 큐 → 장애 상황 → 로그 수집 → 인프라 안정성 → 컨테이너와 쿠버네티스 → 프록시 인증 구조
도구 하나 선택하던 문제에서,
“시스템 전체를 어떻게 설계할 것인가”로 바뀌었다.
INSK 프로젝트에서 Redis를 쓰면서 배운 건 단순했다.
기술은 기능으로만 선택하면 안 되고,
“이 서비스가 앞으로 어떻게 커질지”까지 보고 선택해야 한다는 것.
그리고 장애, 데이터 유실, 확장, 운영이라는 현실적인 문제 앞에서
도구의 의미가 완전히 달라진다는 것.
개발이 단순 기능 구현에서,
엔지니어링으로 넘어가는 지점이었다.
