캐시는 빠르다! 근데 터지면 진짜 다 같이 죽는다!

 

☠️ 캐시 서버가 터졌다

그날 진짜... 아무 생각 없이 평소처럼 일하고 있었는데
갑자기 “사이트 접속이 안 된다”는 연락이 여기저기서 쏟아졌다.

 

싸늘하다.
팀장급들과 윗분들 다 모여서 한 화면만 보고 있다.

그 화면 = 접속 불가된 우리 서비스.

 

커머스 회사에서…
사이트 접속이 안 됐다.

그게 가능하냐고?

가능했다.

 

 

원인?

캐시 서버 터짐.
진짜로. 그 한 놈 때문에 전체가 무너졌다.

 

 

---

 

🧨 터진 이유는? 솔직히 아직도 잘 모른다

지금 생각해보면…

원인은 이 중 하나거나 전부였을지도 모른다..

• 🧠 메모리 초과 (OOM)
  → 캐시 TTL 안 걸려 있던 거 다 모여서 메모리 꽉 찼을 가능성 있음

 

• 🧱 동시에 대량 캐시 MISS
  → 한 타이밍에 요청 몰려서 캐시 못 받고 DB로 몰렸을 수도 있음

 

• ❌ 캐시 삭제 실수?
  → 배치든, 코드든, 누가 잘못해서 TTL 싹 날렸을 수도 있음

 

• 🔥 그냥 캐시 구조가 엉망이라?
  → 캐시 키 관리도 없고, 갱신 로직도 없고…
  그냥 다들 막 썼다. 진짜로.

 

사실 로그도 제대로 안 남았고, 추적도 힘들었다.
근데 분위기로는 다들 알았다.

“이건… 캐시를 너무 아무렇게나 썼던 거다.”

 

오만 개발자들이
가이드도 없이, 기준도 없이, 상황도 모르고
그냥 "느리다" → "캐시 써요~" 해서 붙였고..

결국 그렇게 누적된 것들이
한날한시에… 팡.

 

---

 

🛠 그런데 왜 그렇게 썼냐고?

 

우리 회사는 커머스 회사다.
고객이 원하는 건 지금, 바로, 눈앞에서 처리되는 서비스.

 

근데 현실은?

현업은 이렇게 온다:

“기능 만들어줘잉~ 화면 만들어줘잉~”
그리고 1분 뒤엔 결재 올라가 있다.
오픈일자까지 다 정해져 있음.
개발자한테 말도 안 하고.

 

 

그럼 개발은 어떻게 되냐?

💥 그냥 막 한다.

• 시니어, 주니어 가릴 것 없이
• 일단 만들고 → 바로 붙이고 → 테스트는 내일
• 그리고 오늘 오픈

 

---

 

그러다 어느 날
현업이 이렇게 말한다:

“상품 사진 느려요! 빨리 뜨게 해주세요!”
"상품이 안 뜨잖아요!!"

그리고 개발자는 고민한다:

“그럼… 캐시 써야겠네요…”

그리고 그냥 막… 막… 쓴다.

 

그 결과는?

터진다.

 

 

👨‍🔧 그 이후 우리 팀장은 이렇게 말했다

“캐시 쓸 거면 나한테 먼저 말하고 써.
그냥 붙이지 마.
또 그날처럼 되는 수 있어.”

 

---

 

✅ 캐시는 빠르다, 하지만 위험하다

 

캐시 장점	캐시 단점
빠르다 (메모리 기반)	휘발성, 데이터 유실 가능
DB 부하 줄임	캐시 MISS 몰리면 오리혀 DB 터짐
실시간 UX 개선	TLT/갱신 잘못 잡으면 장애 발생
응답속도 향상	모니터링 없으면 터질 때까지 모름

 

 

 

---

 

🔚 마무리

캐시는 칼이다.
잘 쓰면 빠르고 멋지다.

근데 잘못 쓰면…
진짜 다 같이 죽는다.

 

그리고 그날 이후

모두가 마음속으로 인정했다.

“캐시를 너무 난발해서 쓴 게 문제였다.”

 

 

터진 서버는…
알고 보니 엄청 오래된 캐시 서버였다.

• 물리 장비는 낡았고
• 증설도 안 됐고
• 모니터링도 없었다

 

결국 우리는 중요한 캐시들은
하나씩 Redis로 옮기는 작업을 시작했다.

그리고 그 이후로
우리의 캐시에 대한 태도는 완전히 달라졌다.

 

“빠르니까 쓴다”
→
“책임질 수 있을 때만 쓴다”