데이터베이스 특히 RDBMS 를 사용하는 서비스에 대량의 트래픽이 몰린다면 어떻게 대응해야할까요?

데이터베이스로 집중되는 트래픽을 분산시키기 위한 다양한 전략을 고민할 수 있는데

간단한 방법 중 하나가 바로 Redis 나 Memcached 와 같은 캐시 시스템을 도입하는 것입니다.

당연한 얘기겠지만 이러한 캐시 시스템을 도입한다고 해서 대량의 트래픽을 무조건 처리 가능하게 되는것은 아닙니다.

오히려 캐시를 도입한것 때문에 기존에 생각하지 못했던 다양한 이슈를 체험할 수 있는데요,

토스 개발 블로그에 이러한 케이스들을 정리한 글이 있어 공유드립니다.

캐시로 인해 발생할 수 있는 장애 유형으로는 다음과 같습니다.

📌 캐시 쇄도 (Cache Stampede)

캐시 시스템에 저장되어있던 다량의 캐시가 만료되어 순간적으로 데이터베이스에 트래픽이 몰리는 케이스를 뜻합니다.

이를 해결하기 위해서 동시에 대량의 캐시가 만료되지 않게 각 캐시 만료 시간을 무작위로 약간씩 지연시키는 지터(jitter) 개념을 활용할 수 있습니다.

📌 캐시 관통 (Cache Penetration)

조회한 캐시 데이터가 Null 값일 경우 자연스럽게 데이터베이스를 조회해서 캐시를 채우는 전략을 많이 사용하는데요,

만약 데이터베이스에도 해당 데이터가 Null 값일 경우 지속적으로 데이터베이스를 계속 조회하는 결과가 발생하게 되는데 이를 캐시 관통이라고 부릅니다.

이를 해결하기 위해서는 '값이 없음' 을 명시적으로 뜻하는 Null Object Pattern 을 사용할 수 있습니다.

📌 캐시 시스템 장애

당연하게도 캐시 시스템도 경우에 따라 장애가 발생할 수 있습니다.

이럴 경우 기존에 캐시 시스템이 감당했던 트래픽이 한순간에 데이터베이스로 몰릴 수 있습니다.

이러한 상황을 해결하기 위해서는 캐시 시스템에 장애가 발생함을 감지하고 Fail Over 를 어떻게 수행할지 정해야합니다.

예를 들어 서비스의 핵심 기능은 기존과 동일하게 데이터베이스 조회를 통해 트래픽을 처리하지만,

서비스의 핵심 기능이 아닌 부가적인 기능은 Fast Fail 혹은 대체할 수 있는 UI 를 통해 데이터베이스로 향하는 트래픽을 줄이는 전략을 취할 수 있습니다.

📌 핫키 (hotkey) 만료

동시에 하나의 캐시 데이터 혹은 키로 많은 요청이 집중되는 것을 핫키라고 하는데요,

핫키가 만료되거나 데이터가 바뀌는 순간, 여러 요청이 동시에 동일한 데이터를 데이터베이스로 조회 요청할 수 있어 불필요한 트래픽이 유발되게 됩니다.

이를 해결할 수 있는 방법으로 분산 락(Distributed Lock) 을 사용하여 단 한번의 쓰기 작업만 허용하는 방법을 사용할 수 있습니다.

이에 대한 좀더 자세한 내용은 공유드린 원문 내용을 참고해주세요.

📚 원문

https://toss.tech/article/cache-traffic-tip