인프런 커뮤니티 질문&답변
작성한 질문수
hot key 문제를 방지하기 위해 적용한 DCL의 재시도 횟수와 랜덤 지터에 대한 질문입니다
해결된 질문
작성
·
36
·
수정됨
0
1. 현재 학습 진도
6챕터를 모두 끝낸 후 해당 내용을 직접 프로젝트에 적용하고 있습니다.
hot key 문제를 해결하기 위해 DCL을 적용하여 중복 DB 접근을 방지할 수 있습니다.
2. 어려움을 겪는 부분
현재 프로젝트는 외부 API인 LLM을 통해 경제 요약 리포트를 만들어주는 서비스입니다.
이때 리포트 생성 시 60s~120s가 소요되어 만들어진 리포트들을 캐싱해놓고 사용하려 합니다.
레디스 리모트 캐시를 적용하려 하는데, hot key 문제를 방지하기 위해 락을 획득한 후에도 반드시 캐시를 한 번 더 확인하는 방식을 적용 즉 DCL 을 적용하려 하는데, 이때 락을 획득하지 못한 애들은 일정 시간후에 다시 락 획득을 시도해야 합니다. 그런데 지금 디비에 접근하고 LLM을 통해 리포트를 생성하는 task가 넉넉하게 1-2분정도 걸리는데, 이 때문에 락 획득 재시도 간격을 너무 길게 잡아버리면 ux가 저하되고 그렇다고 너무 짧게 잡으면 요청 실패가 빈번하게 발생하게 됩니다. 그렇다고 또 시도횟수를 늘리면 또 서비스에 부하가 발생할 수 있을 것 같고 또 시도횟수를 짧게 하면 데이터를 받아오지 못하는 상황이 빈번하게 발생하여 고민중입니다.
3. 시도해보신 내용
현재는 재시도 횟수 1000번에 랜덤 지터 200~300ms로 잡았는데 혹시 이런 경우에는 어떻게 해결하면 좋을지 인사이트 부탁드립니다.
작성한 코드 깃허브 링크를 첨부해드립니다. 감사합니다.
답변 2
1
안녕하세요 도등어님!! 좋은 질문 감사합니다
1~2 분 동안의 작업을 레디스 락을 이용해서 잡고자 하는게 유저들의 공통 데이터인가요? 혹은 특정 유저만의 데이터인가요?
이를 통해 유저들이 과도한 LLM 호출을 줄여주고 싶은게 목적인가요?
혹은 특정 유저의 중복 호출을 막아주기 위함인가요?
위의 요구사항에 따라서 구현하는 방식이 갈릴 것 같습니다
만약 전자가 목적이라면 배치를 통해 미리 생성한 값을 노출시키는 구조가 더 낫지 않을까 싶습니다!
0
안녕하세요, 인프런 AI 인턴입니다.
도등어님께서 레디스를 이용한 캐싱과 DCL(Double-Checked Locking) 적용에 대해 고민하고 계신 것 같습니다. hot key 문제와 관련하여 몇 가지 조언을 드리겠습니다.
최적의 재시도 간격 설정: 재시도 간격을 랜덤 지터와 함께 설정하여 락 획득을 동시에 시도하는 것을 어느 정도 방지하고 계신 것으로 보입니다. 재시도 간격을 200~300ms로 설정하셨는데, 요청 실패가 빈번하다면 재시도 간격을 늘리거나 시도 횟수를 조절하여 시스템의 부하를 줄이도록 밸런스를 잘 맞춰야 합니다. 이를 위해 사용자 경험(UX)과 시스템 안정성을 고려하여 다른 구성 요소의 퍼포먼스를 모니터링하며 조절할 수 있습니다.
락 경합 줄이기: 락 경합이 빈번하다면 락을 얻기 위한 경쟁을 줄이기 위해 지역적으로 분산된 캐시나, 캐싱 책략을 변경해 볼 수 있습니다. hot key에 대한 요청 빈도나 패턴을 분석하여 해당 키에 대한 접근을 분산하거나, 임의의 키로 분리해볼 수도 있습니다.
백오프 전략 사용: 지터 기반의 백오프(backoff) 전략을 적용하여 재시도를 점진적으로 길게 할 수도 있습니다. 예를 들어, 지수적 백오프를 사용하여 재시도 횟수가 늘어날수록 시간을 늘려가는 방식으로 부하를 조절할 수 있습니다.
서비스 아키텍처 개편: 더 근본적인 해결책을 원하신다면 서비스 아키텍처 측면에서 비동기 처리를 지원하도록 구조를 개편하는 것도 하나의 방법입니다. 예를 들어, 메시지 큐를 사용하여 요구 처리 시간 동안 비동기적으로 작업을 처리하도록 하여 병목을 줄이는 방법도 고려해 볼 수 있습니다.
추가적인 코드나 설정에 대한 피드백을 원하신다면, 깃허브 링크를 통해 동료 개발자들과 더 깊이 있는 논의를 진행하는 것도 좋습니다.
도움이 되셨기를 바랍니다.
Image:
Doc Source: Spring Boot Hot Swapping