회원이 500만명이고
회원등급이 브론즈 실버 골드 플래 등 있음
어드민 페이지에
select group_name , count(*) from user group by group_name
where 탈퇴회원 제외 휴먼회원 제외 차단회원제외 등등
어떤 개발자가 이건 캐싱이 답이다!!
라고 생각하여 SpringCache를 도입함
관리자 서버는 1개라 다중인스턴스 아니라 레디스는 고려하지 않음
어드민페이지 트래픽은 거의 없음
사용자 직원 30명쯤
회원 등급은 DB에 실시간으로 계속 변경됨
TTL은 1시간으로 잡았음(최대 1시간까지는 반영지연됨을 안내완료)
근데 자꾸 1시간마다 회원 등급 로딩이 느려짐
약 5초 지연된다고 가정
로딩바
1..2..3..4...5.. 후에 회원등급별 개수가 뜸
개발자에게 1시간마다 로딩이 느리다고 항의가 옴
이슈를 해결하세요
@Scheduled를 사용하여 캐시 만료 전(예: 55분마다)에 미리 쿼리를 실행해 캐시를 업데이트
@딘퐁 사실 글 안읽고 ai 딸깍하고 가장 비용 적게드는 솔루션 가져옴
@ㅇㅇ(211.206) 근데 맞는거보면 보안문제만 안되면 상황만 글로 잘 쓸수있으면 어느정도 하급 이슈들은 대처 가능하겠네
캐싱보다는 구체화된 뷰를 만들어주고 유저 변동이 생길때마다 변경로그를 받아와서 그룹별 카운팅 데이터에 반영해주는 별도의 cqrs 구조를 만드는게 좋을거같긴 한데 굳이 저거 하나 하자고 카프카니 cdc니 하는건 뇌절이겠지?
과함 - dc App
캐싱을 하는 판단이 조트급 아닌가 그리고 미리 스케줄로 안될정도의 데이터라면 예를들어 구글급 계정풀
쿼리로 집계가 오래걸려서 어떤 형태로든 캐싱을 하긴 해야할텐데.. - dc App
일단 회원 규모는 주어진 상황에서만 생각하셈 - dc App
이건 진짜 고민거리도 안되는거같은데 집계쿼리대신 집계컬럼두고 업데이트하다 일정시간마다 정합성 맞춰주면 끝인데
집계테이블을 만들어서 일정주기로 등급별 개수를 업데이트한다는거지? 그게 가장 정석적인 방법임 - dc App
마지막 PK도 캐싱해두고 증분만 COUNT 돌리면 안되나 삭제 회원 있으면 뭐 새벽이나 스케줄링으로 보정해줘야되고
넘 복잡해ㅠ - dc App
그럼 그냥 10, 15분전 만료 전 업데이트 해주는게 베스트일듯...?
나도 비정규화 컬럼 하나 둘듯
쿼리 실행 시간이 너무 오래걸리니까 몇분전에 미리 계산해두고 캐싱 갱신때 바로 갖다주는 식이 제일 간단한거죠? - dc App