캐시전략 - Write-behind

Question

안녕하세요. 강사님

캐시전략 - Write-behind 전략을 설명해주셨는데,
인스타라이브나 유튜브라이브에서 좋아요를 한 사용자가 여러번 누를 수 있는데, 이때가 아마 Write-behind 전략을 적용할 수 있을 거 같습니다.

1. 좋아요를 레디스 캐시에 카운트 증가
2. 좋아요 누른 개수를 몇 초마다 flush로 카프카 큐에 발행
3. 카프카 consumer에서 db저장

이런 방식으로 설계가 가능할 거 같습니다. 강의에서는 Write-behind DB에 나중에 저장한다고 말씀하셨는데 그럼 이런 라이브 상황에서 DB에 좋아요를 언제 저장하는 것이 바람직할까요? 그 기준을 어떤 식으로 잡으면 좋을지도 선생님의 고견이 듣고 싶습니다.

좋은 강의 감사합니다.

성장랜턴 · Answer

안녕하세요 gunsung53님. 말씀하신 상황은 일반적인 좋아요/싫어요 기능보다는 사용자가 좋아요를 연속해서 누를 수 있는 리액션 기능에 가까운 것으로 이해했습니다. 이런 경우에는 짧은 시간 동안 많은 쓰기 요청이 발생할 수 있고, 사용자는 현재 수치를 준실시간으로 확인하길 원하기 때문에 말씀해주신 것처럼 Write-behind 전략이 잘 어울리는 사례로 보입니다. “DB에는 언제 저장하는 게 좋을까?”에 대한 기준은 결국 서비스가 어느 정도 데이터 유실을 감당할 수 있느냐에 따라 달라질 것 같습니다. 예를 들어 말씀해주신 인스타 라이브 같은 케이스는 정확한 숫자 자체보다는 “실시간으로 좋아요 수가 올라가는 느낌”이 더 중요할 수 있습니다. 그래서 장애가 발생하더라도 “1~2초 정도의 유실은 감당 가능하다” 혹은 “몇백 건 정도의 좋아요 수 차이는 감안한다” 정도로 기준을 정하고 운영할 수 있습니다. (어디까지 허용할지는 비즈니스적으로 결정해야 하는 부분인 것 같습니다. 만약 인프라적인 제약이 있다면 Kafka 지연이나 DB 부하 상황을 보면서 정책을 조정하기도 합니다.) Kafka에 어떤 메시지를 보내는지에 따라 DB에 flush 하는 전략은 달라질 수 있겠지만, 이벤트가 1000건 이상 쌓이거나 최대 2초가 지나면 좋아요 증가량(delta)이 일정 수준 이상 차이나면 flush 하는 전략을 사용할 수 있습니다. (보통은 batch size 조건과 flush timeout 조건을 OR로 조합해서 많이 사용합니다) 좋은 질문 감사합니다 😊

인프런 AI 인턴 · Answer

안녕하세요, 인프런 AI 인턴입니다. gunsung53님. Write-behind 캐시 전략을 인스타라이브나 유튜브라이브와 같은 실시간 앱에서 적용하는 방법에 대해 궁금해 하셨군요. 이러한 상황에서 캐시의 사용은 시스템의 효율성을 높이는 데 매우 유용합니다. 캐시를 통해 즉각적인 피드백을 제공할 수 있으며, 동시에 토탈 성능을 관리하는데 많은 도움이 됩니다. Write-behind 전략 간단 설명: Write-behind 캐시 전략은 데이터를 캐시에 먼저 기록한 후 일정 주기마다 DB로 비동기적으로 저장하는 방식입니다. 이렇게 하면 사용자의 요청에 대한 반응 시간을 줄이는 동시에, 데이터베이스 쓰기 작업을 한꺼번에 처리하여 효율성을 높일 수 있습니다. 실시간 앱에서 Write-behind 방법 적용 시 고려사항: 캐시 적중률 및 성능 : 캐시가 잘 동작하는지, 충분히 많은 요청을 빠르게 처리할 수 있는지 모니터링이 필요합니다. 캐시 운영 상태를 주기적으로 점검하여 요구사항을 충족하는지 확인해야 합니다. 데이터 일관성 : Write-behind는 본질적으로 데이터 일관성에 일정한 시간을 요구합니다. 따라서 사용자가 실제로 보는 데이터와 DB의 데이터 간 시간차를 인지해야 합니다. 이를 위한 타협점 설정이 중요합니다. 플러쉬 주기 설정 : 플러쉬 주기를 얼마나 짧게 혹은 길게 설정할지는 시스템의 요구 사항과 데이터 처리 부하를 고려해 결정해야 합니다. 일반적으로는 사용자가 보고 있는 데이터가 즉각적일 필요가 없는 경우에는 주기를 조금 늘립니다. 실시간 데이터 분석 : 좋아요 수와 같은 데이터를 실시간으로 분석해야 하는지 여부입니다. 만약 실시간 분석이 필요하다면, 카프카와 같은 실시간 처리 엔진을 활용하여 배치 주기조차 줄일 수 있을지 검토해야 합니다. 적용 방안 제안: - 사용자가 실시간 피드백을 원할 경우 캐시에서의 읽기 속도를 최적화하면서 데이터베이스와의 eventual consistency를 유지하는 방식이 좋습니다. 이 경우 아마 1초에서 5초 간격의 싱크를 밀어주는 것도 하나의 방법이 될 수 있습니다. - DB의 쓰기 부하가 중요한 경우, 수십 초에서 분 단위로 싱크를 조정할 수 있습니다. 관련된 질문이나 사례들도 관련 URL을 통해 더 깊이 탐구해 보시면 좋습니다: 멱등성. ‘같은 요청’의 기준? 저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.