대규모 트래픽에서 Cache Miss 폭발을 막는 전략 | 멤버십 영상

Video: 대규모 트래픽에서 Cache Miss 폭발을 막는 전략 | 멤버십 영상
Channel: 코딩하는기술사
Duration: 10m 22s
Source: subtitle (auto, ko)
Transcript:
안녕하세요, 사랑하는 멤버 여러분. 어, 일전에 우리는 캐시 무효화에 대해서 살펴봤는데요.이 대규모 트래픽 환경에서는 캐시를 잘 비우는 것만큼이나 중요한 것이 있습니다. 바로 비워진 캐시를 어떻게 안전하게 다시 채울 것인가인데요. 우리가 캐시를 사용하는 이유는 분명합니다. 원본 데이터베이스를 보호하고이 조회 성능을 극적으로 향상시키기 위함이죠. 하지만 캐시 설계를 잘못하면 캐시가 만료되는 그 짧은 순간에이 수천 수만 개의 요청이 동시에 DV로 쏟아질 수 있습니다. 그리고 그 순간에 성능을 지켜주던 캐시는 오히려 장애를 정폭시키는 장치가 될 수 있는 것이죠. 오늘은 이캐시 스탠피드 이캐시 스탠피드 현상이 무엇인지 살펴보고이를 방어하기 위한네 가지 아키텍 전략을 알아보겠습니다. 자 먼저 용어부터 정의하고 가겠습니다. 자 캐시 스탠피드 다른 말로는 썬더링 허드라고도 합니다.이 이 가축대가 갑자기 놀라서 한꺼번에 우르르 달려가는 현상을 말하는데요.이 시스템에서는 캐시가 만료되는 순간이 수천수만 개의 요청이 동시에 온본 데이터베이스로 쇠도하는 현상을 읽었습니다.

자, 여기 다이어그램을 보시면 수많은 클라이언트들이 있습니다. 평소에는 레디스 캐시로 요청을 빠르게 처리할 수 있습니다. 그런데 캐시가 어느 순간 익스파ire 만료되고 캐시 미스가 발생하면이 수많은 요청은 원본 데이터베이스로 요청이 동시에 몰리게 됩니다. 이렇게 되면 DB의 CPU가 점진적으로 오르는게 아니라 단 0.1초 1초 만에 CPU가 100%를 치고이 커넥션 풀이 고갈되어서 DB가 뻗어 버릴 수 있는 거죠. 즉 평소엔 캐시 덕분에 잠잠하던 DB가 어 0.1조에 1조에 사망할 수 있다는 것입니다. 자, 시나리오를 한번 보겠습니다. 어, 실무에서 발생할 수 있는 하키 이슈인데요. 아이폰 16 사전 예약이라고 하 가정해 보겠습니다.이 타겟은이 캐시키 예를 들어서 프로덕 아이폰 16이라는이 캐시키 하나의 전체 요청이 몰릴 예정입니다. 트래픽은 초당 수천에서 수만 요청이 들어온다고 가정합니다. 이때 캐시의 만료 시간은 60초입니다. 먼저 60초가 되기 전에는 캐시 히트로 DB 부하가 제로에 가깝습니다.

아주 병원하죠. 그런데 캐시가 60초에 만료되면 캐시 미스가 발생하면서 60초를 넘어서서는 캐시 갱신 요청이 동시에 DB로 모두 몰려가게 됩니다. 이렇게 되면 DB의 커넥션 풀이 고갈되고 타임아웃이 발생하고이 서비스는 전면 장애 상태로 빠질 수 있는 것이죠. 이것이 우리가 막아야 할 시나리오입니다.이 문제를 해결하기 위해서이 다음과 같이네 가지 방어 전략을 사용할 수 있습니다. 오늘 우리는이네 가지의 큰 그림을 이해하고 어떤 상황에서 무엇을 선택해야 할지 배울 것입니다. 첫 번째 락킹입니다. 정합성이 중요할 때이 번호표를 뽑아서 줄을 세우는 전략입니다. 두 번째 PR입니다. prob빌리스틱 recuut테이션의 약자입니다. 확률적 조기 재개산이라는 뜻으로이 캐시가 만료되기 전에 일부 요청이 확률적으로 캐시를 미리 갱신하는 방식입니다. 세 번째 싱글 브라이트입니다.이 요청을 하나로 뭉쳐서 처리하는 기법입니다.네 번째 SWR 스테일와일 리밸리 데이터입니다. 어, UX 즉 사용자 경험을 위해서이 낡은 데이터를 먼저 보여주고 백그라운드에서 캐시를 갱신하는 전략입니다.

하나씩 살펴보겠습니다. 자, 첫 번째 라킹 즉 뮤텍스를 활용한 전략입니다. 컨셉은 간단합니다.이 번호표를 뽑고 한 명만 들어가 하는 것입니다. 여기 다이그램을 보시면 캐시가 없다는 걸 확인하는 순간이 수많은 요청들 중에 특정 요청 하나만 락을 획득합니다.이 락을 획득한 요청이 실제 데이터베이스로 가서 데이터를 가져오고 캐시을 캐시를 갱신하게 됩니다. 나머지 락을 획득하지 못한 요청들은 락이 풀릴 때까지 혹은 캐시가 채워질 때까지 블로킹 상태로 대기하게 됩니다. 다시 말해 위너는 DV를 조회하고 캐시를 경생을 하고 락을 해제합니다. 루저들은 대기하고 캐시를 제조 하게 됩니다.이 방식의 핵심은 컨시스턴 즉 데이터의 정압성입니다. 중복 계산 없이 딱 한 번만 DB를 조회하게 됩니다. 그런데이 방식의 단점도 있습니다.이 이 위너 위너를 제외한 나머지이 요청들은 대기를 해야 함므로 레이턴시가 질 수 있다는 거죠. 두 번째 전략은 PRtic early recuutation 즉 확률적 조기 재계산이라는 뜻입니다.

어 이건 그 인스타그램 그리고 위키피디아 같은이 초고대 트래픽 시스템에서 사용하는 방식이기도 합니다. 여기 다이그램을 보시면 캐시가 만료될 때까지 기다리지 않는다는 점입니다.이 이 그래프를 보시면 만료 시점에 가까워질수록이 재계산 확률이 점점 증가합니다. 요청이 들어올 때마다 현재 남은 TTL을 기준으로 확률을 계산하고 그 확률에 선택된 특정 요청이이 TTL이 끝나기 전에 DB를 한번 다녀와서 게시를 갱신하는 전략인 것이죠. 어이 방식은이 락을 쓰지 않기 때문에 아무도 기다리지 않습니다. 그리고 캐시가 만료되기 전에 미리 캐시를 갱신하는 거죠. 다만이 확률 계산 로직과 TTL 설계가 필요하기 때문에 구현의 난이도는 다소 있는 편입니다. 어 자세한 내용은 다음번 영상에서 설명드리겠습니다. 첫 번째는 싱글 플라이트 또는 리퀘스트 코알리싱이라고 부르는이 요청 뭉치기 전략입니다.이 다이그램 보시면이 전략은 주로 어플리케이션 서버 내부에서 동작하는 최적기법입니다.이 이 동일한 캐시키에 대해서 동시에이 100개의 요청이 들어왔다고 가정해 보겠습니다.

이때 서버는이 100개의 요청을 모두 디비로 보내지 않습니다. 대신 이미 천의 중인이 한 개에 하나의 요청 즉 인플라이트 현재 진행 중인 호출에 나머지 요청들을 묶어 둡니다. 그리고 단 한 번에 TV 호출이 완료되면 그 결과를 기다리던 모든 요청에게 동시에 전달하게 됩니다. 즉 100번의 DB 호출을 단 한 번으로 줄이는 방식인 거죠.이 이 방식은 락을 외부에 두는 것이 아니라 어플리케이션 레벨에서 요청을 먹는 방식이기 때문에 매우 효율적입니다. 그래서 고의 싱글 브라이트 패키지나 자바의 캐시어블 같은 기능들이이 패턴을 기본으로 기본적으로 제공합니다. 마지막네 번째 SWR 스테일와일 리밸리데이트입니다. 이건 UX 즉 사용자 경험이 최후선일 때 사용합니다. 자,이 다이그램을 보시면이 캐시가 만료되더라도 일단 그 낡은 데이터를이 낡은 데이터 스테일 데이터를 사용자에게 일단 반환합니다. 그리고 캐시 갱신은 백그라운드에서 몰래 하는 거죠. 이렇게함으로써 사용자 대기 시간은 아주 짧아집니다. 하지만이 잠깐 동안이 사용자는 과거 데이터를 볼 수 있다는 단점이 있습니다.

자, 오늘 배운 내용을 기반으로이 아키텍트 의사 결정 매트릭스를 정리해 보겠습니다.이 시스템을 설계할 때이 상황에 따라서 전략을 선택해야 합니다.이 기준을 하나의 가이드라인으로 참고하시기 바랍니다. 자, 먼저 금융 결제 제고. 데이터가 단 이론이라도 틀리면 안 되는 이런 영역이라면 락킹 전략을 사용하십시오. 사용자를 잠시 블라킹 대기시키더라도이 강한 일관성을 보장하는 것이 우선입니다.이 경우 핵심 가치는 컨시스턴시 즉 일관성입니다. 두 번째 SNS, 피드, 뉴스, 이벤트 메인처럼 트래픽이 아주 높고이 가용성이 최후선이라면 PR 전략을 고려하십시오. 락 없이 확률적으로 미리 캐시를 갱신해서 어 만료 시점의 부활을 분산시킵니다.이 경우 핵심 가치는 가용성입니다. 세 번째 일반적인 조회 API를 효율적으로 최적화하고 싶다면 싱글 플라이트를 기본 전략으로 적용하십시오. 동일 요청을 하나로 병합해서이 불필요한 중보을 제거합니다.이 경우 핵심 가치는 효율성입니다. 마지막으로 쇼핑몰 목록 콘텐츠 페이지처럼이 사용자의 응답 속도가 무엇보다 중요하다면 SWR 전략을 사용하십시오.

일단 기존 데이터를 반환하고 백그라운드에서 캐시를 갱신하십시오.이 이 경우 핵심 가치는 사용자 경우입니다. 어 아키텍처는 어떤 전략이 오른가의 문제가 아니라이 상황에서 무엇을 우선할 것인가의 문제입니다. 자 오늘은 이렇게 캐시 스탠피드를 방어하는네 가지 아키텍처 전략에 대해서 알아봤습니다. 어 오늘은 큰틀에서 전략들을 살펴봤는데요. 구체적인 구현 관점은 별도의 영상으로 따로 설명드리도록 하겠습니다. 오늘도 수고했습니다.