[일반] 데이터 특성에 따라 다르겠지만

[착해진웃스음(112.168)]

현업에서는 레디스 캐시 히트율을 몇퍼센트 정도로 잡고 튜닝함?

만약 캐시히트율이 낮지만 외부 API 호출이 깊어서 속도가 안나올때는 어떤 방식으로 해결함??

사이즈는 어떤식으로 책정함? 아까 내가 새벽에 쓴 글에 욕만 달려서 내가 틀렸나 싶네

나는 데이터 개수 * 데이터 크기  + 여유공간 정도로 계산했는데 이렇게 책정하는게 아님??

[익명(106.101)]

jvm oom같은 개소리댓글이나 달리는 곳에 답변을 원하는구나

[착해진웃스음(112.168)]

웅 맞아

[착해진웃스음(112.168)]

저 문제 자체에서는 레디스를 사용할 필요가 없겠지 근데 내가 궁금한건 레디스를 사용했을때 현업에서는 캐시측정 oom 어떻게 하는지가 궁금해

[백갤러 1(39.123)]

저 댓글에서 oom이 왜 개소리임 ㅋㅋㅋ 당연히 고려해야지

[백갤러 1(39.123)]

로컬 캐시를 쓴다는건 항상 oom 염두를 두고 사이즈를 책정해야해

[착해진웃스음(112.168)]

oom을 고려하는건 맞는데 내가 답변한 TTL이나 캐시 제거정책으로는 부족한거야??

[백갤러 1(39.123)]

ttl로만 로컬 캐시 메모리 사용량을 관리한다는건가 + 캐시 제거정책은 어떤걸 말하는거야

[착해진웃스음(112.168)]

기본적으로는 TTL을 N분 단위로 설정해(날씨 데이터는 이전 데이터가 필요 없으니까) 최신 데이터만 유지해주고 + 가용 공간을 넘어가면 LRU같은 알고리즘을 사용해 evic 시키는 방법

[백갤러 1(39.123)]

ttl에 의존하는건 현업에서는 보통 안전하지 않고, 결국 캐시 사이즈를 정해야 lru 캐시제거 알고리즘을 트리거 하든 하겟지. 저 댓글 51개달린 댓쓴이 말보면 이걸 물어본듯

[착해진웃스음(112.168)]

아까 새벽에 캐시 사이즈를 어떻게 정하는지도 고민해서 작성했는데 욕만 달려서 지웠어 근데 기본적인 방법이 데이터량 * 예상되는 데이터 row + 임시공간으로 정했거든(실제 서비스에서는 저 기능에서만 레디스를 사용하는게 아니기 때문에 이렇게 책정하면 안되겠지만) 근데 욕만 달려서 현업에서는 어떻게 책정해??

[백갤러 1(39.123)]

캐시하려는 데이터가 한 서버 인스턴스에 어느정도 들어가는지 트래픽추이를 보고, 그 개수정도 만큼 mock 데이터를 캐시에 쫘락 담고 힙덤프떠서 그 사이즈가 총 가용한 힙 메모리의 몇%를 차지하는지 확인함

[착해진웃스음(112.168)]

근데 결국 캐시히트율에 따라 적절한 크기를 정할거 같은데 아무리 많은 데이터를 넣어도 캐시히트율 자체에 변화가 없다면 의미가 없잖아? 결국 높은 캐시히트율에서 적절하게 트레이드 오프해서 정할거 같아 이게 이론적으로 정할수는 없는거 아냐?

[백갤러 1(39.123)]

적절한 사이즈를 책정햇으면 보통 안전계수를 곱해서 사이즈를 정함

[착해진웃스음(112.168)]

사용자의 Query 패턴에 따라 캐시 히트율이 정해지고 그 캐싱할때 이익을 볼수있는 손익분기점을 정해야 하는데 이건 이론적으로 정하기 너무 애매할거 같은데

[백갤러 1(39.123)]

비즈니스 요구사항에 따라 트레이드오프를 산정해야겟지 그럼

[착해진웃스음(112.168)]

흠 오키 답변해줘서 고마워 관련 기술블로그좀 찾아봐야겠네

[딘퐁(gunwoo7193)]

평소엔 캐시 자체를 잘 안씀 select 쿼리 인덱스 잘걸면 10ms 이하로 나와서 진짜 사람 몰리는 쿠폰 이벤트 타임 이런거만 제한적으로 하지 - dc App

[착해진웃스음(112.168)]

캐시를 써야하는 상황에서의 답변이 궁금함

[익명(118.235)]

히트율 이런거보다도 update 빈도수부터 보지않나 서버가 나누어져있을때 자주 조회되는데 잘 안바뀌는 데이터를 가져오려고 api 계속쏠때 캐시에 넣는다정도로만 이해함

[백갤러 2(222.111)]

글 모두 읽어봤는데 왜 해결방법은 제시해주지 않고 욕만하는 건가요?

[착해진웃스음(112.168)]

모르겠어 나도

[착해진웃스음(112.168)]

알려주면서 욕하면 좋을텐데 그래도 211.36한테는 고맙다고 생각해

[백갤러 4(211.36)]

굿 ㅋㅋ

[백갤러 3(124.53)]

애초에 캐시를 쓴다는 선택 자체를 굉장히 보수적으로 취해야함. 말하는거보니까 걍 캐시는 거의 무조건 이득이다 라는 스탠스인것같은데, 캐시를 추가한다는것도 장애포인트로 연결될수있다는 생각을 해야지

[백갤러 3(124.53)]

캐시를 추가한다는 의미를 가볍게만 생각해봐도 여러가지가 나올수있음. 1. 니가말한 메모리문제도 있고 2. 기본적으로 싱글 애플리케이션으로 운영할일은 거의없으니 로컬 인메모리 캐시가 아니라 레디스같은 상용 툴을 쓰겠지? 3. 레디스를 썼을때도 싱글인스턴스면 spof 가 될테니 이중화로 구성해야하고 4. 클러스터 레디스를 썼을때 트랜잭션을 어떻게 맥일건지?

[백갤러 3(124.53)]

5. 캐시 이빅션 전략은 어떻게 가져가야하는지? 예를들어 날씨데이터가 미래데이터까지 가져온다면, 1시에 예측한 5시날씨와 실제5시 데이터가 다를수있겠지? 그러면 언제 어느타이밍에 eviction 시켜야할까? 이런 고민거리들이 줄줄이 나옴

[백갤러 3(124.53)]

물론 그런것들 다 고려하면서 어쩔수없이 캐시가없으면 디비가 부하를 못버티는경우에는 캐시를 쓰겠지만, 그게 아니면 비즈니스 개발자로써 레디스를 굳이 추가해야할 이유가있을까? 심지어 같이 일하는 동료,신입들의 러닝커브와 유지보수관점, 레디스 장비의 비용 관점들도 마이너하긴하지만 한번쯤 생각해볼이슈임