Thundering Herd, Hot Key: 대용량 트래픽 관리 시 발생할 수 있는 이슈

Thundering Herd?

• 특정 이벤트로 인해 많은 프로세스가 동작하는데, 그 중 하나의 프로세스만 이벤트를 처리할 수 많은 프로세스가 특정 리소스를 가지고 경쟁하면서 많은 리소스를 낭비하게 되는 경우
• 웹서비스에서는 Cache miss로 인해서, 많은 프로세스가 같은 Key를 DB에서 읽으려고 시도하면서, 특정 서버(DB)에 부하를 극도로 증가시키는 경의를 의미한다. 

이렇게 될 때 서버에서 처리를 못하고 문제가 생기면 = Thundering Herd

 

 

Thundering Herd 의 원인

• 캐시가 없을 때 발생
  • 캐시가 없는 이유
    • 캐시 서버의 추가/ 삭제
    • 해당 키의  TTL 에 의한 데이터 삭제
    • 캐시 서버 메모리 부족으로 해당 키 Eviction

Cache Stampede

• Cache 의 Expire Time 설정으로 인해(cache miss로 인) 대규모의 중복된 DB 쿼리와 중복된 Cache 쓰기가 발생하는 현상 (Thundering Herd)

 

 

해결 방법

 

Probabilistic Early Recomputation

• Cache Stampled를 해결하기 위한 방법 중 하나
• 키의 TTL이 완료되기전에 Random 한 가상의 Expire Time 을 설정해서 미리 키의 내용을 갱신하는 방qjq

 

---

Hot Key

• 과도하게 읽기/ 쓰기 요청이 집중되게 되는 Key
• 해당 Key 의 접근으로 인해 Storage(DB, Cache) 성능 저하가 발생하는 Key 를Hot Key 라고 한다. 

캐시 서버는 최대 10만TPS이기에 DB 서버로 요청이 돌아간다. 이렇게 양쪽 모두 문제가 생김

해결 방법

• Query Off (Read From Secondry) 리드 분리
  • 보통 Hot Key라고 해도 읽기 가 대부분.
• Local Cache
  • API 서버에 특정 서버를 캐시해두고 이 키 값이 아예 서버로 안가게 한다.
  • 이렇게 하면 로컬에서 다 처리가 되어 캐시 서버 수 만큼 키가 분산 처리 되는 효과가 생긴다.
  • 하지만 로컬 캐시는 언제는 값이 바뀔 수 있기에 로컬 캐시가 서버와 통신해 값을 업데이트 하는 방법이 있어야 함
    • coupon 프로젝트에서 생성한 Event 발생 -> cache update 가 적절한 방법 같다.
• Multiple Write And Read From One

 

Query Off

• redis 의 경우 Replication 기능을 제공.
• write 는 primary, Read 는 Secondary 를 이용해 read 부하를 줄일 수 있다.
• Aws Elastic Cache redis 의 경우 최대 5개의 읽기 전용 복사본을 추가할 수 있다.

 

Local Cache

• api 서버에서 직접 특정 key 들을 cache 해서 cache 서버에 가지 않고 api 서버에서 바로 처리한다.
• api 서버 수만큼 cache 처리량이 나눠진다.
• 단점
  • cache 가 공유되지 않고 api서버에만 존재
  • 데이터가 변경되었을 떄 이를 통지 받는 프로세스가 필요하다
    • 변경 통지가 없다면 TTl이 끝날 때까지 데이터 불일치 발생
  • 이런 문제의 해결점으로 Client-Side Caching 을 제공하는 Cache 솔루션들이 있다. 

 

Multi Write Read One

• cache 를 써야 할 때 하나의 key 를 남기는 것이 아니라, 여러 개의 키로 남기고 읽을 때는 하나의 key 만 읽어서 부하를 분산 시키는 방식
• Api 서버에서 여러 cache 를 write 한다.
• Wirte (A) -> Write(A1), Write(A2), Write(A3)
• Read(A) -> Read(A1) or Read(A2) or Read(A3)
• 단점
  • 조금 더 많은 cache 장비를 사용해야 한다.