Redis 캐시 사용법에 대해 더 자세히 알고 싶어요

안녕하세요!

Discourse 인스턴스에서 로드 테스트를 수행하던 중, 동일한 댓글 스레드를 반복적으로 가져올 때 Redis 캐시 히트율이 오히려 낮아지는 것을 발견했습니다. 이는 다소 예상 밖의 결과였습니다(읽기/쓰기 혼합 작업에서는 최대 85%까지 캐시 히트율을 확인했지만, 100% 읽기 작업에서는 22%까지 떨어지는 경우도 있었습니다).

코드베이스와 이 포럼을 검색해 보았지만, Redis 캐시가 정확히 어떻게 사용되는지 제게는 다소 불분명합니다. README에는 다음과 같이 나와 있습니다:

우리는 Redis를 캐시 및 일시적 데이터 저장에 사용합니다.

redis-cli를 사용하여 aforementioned 로드 테스트 동안 Redis 캐시로 전송된 명령어를 덤프한 결과, 주로 예약된 작업과 “__mb_backlog_id_n_” 접두사가 붙은 키에 대한 “get” 명령어(이것이 MessageBus 관련 사항이라고 생각합니다)를 확인했습니다.

다음과 같은 질문이 있습니다:

  • Redis에 캐시되는 데이터가 코드베이스의 어느 부분에 해당하는지 찾을 수 있는 “쉬운” 방법이 있을까요? 이 질문들에 스스로 답할 수 있으면 좋겠지만, 불행히도 Ruby on Rails 애플리케이션(또는 Ruby 자체)에 대해 아주 익숙하지 않습니다. :slight_smile:
  • 로그인/로그아웃 상태가 캐시 히트율에 영향을 미칠까요? 참고로, 위에서 언급한 로드 테스트는 관리자 API 키를 사용했습니다.
  • 게시글 내용처럼 자주 조회되는 비교적 정적인 데이터도 Redis에 캐시되는가요? 아니면 Redis는 주로 Sidekiq 등을 통한 작업 스케줄링 및 백그라운드 처리에만 사용되는가요?

미리 감사드립니다!

여기서 가장 중요한 부분입니다. 가장 공격적인 캐싱은 익명 요청에 대해 이루어지므로, 익명 봇을 사용하여 로드 테스트를 다시 실행해 보시는 것을 권장합니다.

Discourse.cache.fetch와 DistributedCache.new와 같이 grep으로 찾을 수 있는 메서드가 몇 개 있습니다.

우리는 일부 비자주적인 설정 블롭을 캐시하지만, 토픽에 대한 접근 방식은 주로 익명 사용자를 위해 전체 응답을 캐시하여 애플리케이션이 DB를 거의 건드리지 않고 응답을 구성할 수 있도록 하는 것입니다.

Redis는 Sidekiq와 MessageBus에 널리 사용됩니다.

완벽해요, 정말 유용한 답변 감사드립니다!

이번에는 익명 요청으로 로드 테스트를 다시 실행해 보았는데, 성능이 크게 향상되었습니다! 이전에는 단일 호스트에서 초당 약 25건의 요청밖에 처리할 수 없었지만, 지금은 380건까지 처리할 수 있습니다. Redis 캐시 히트율도 약 22%에서 약 66%로 상승했습니다. :slight_smile:

혹시 궁금해하시는 분이 있을까 봐 결과를 공유합니다.

도와주셔서 다시 한번 감사합니다!