읽기 위주 시스템

핵심은 자주 읽는 데이터를 DB보다 앞에서 끝내는 것입니다.

읽기 최적화는 DB 하나를 빠르게 만드는 일이 아니라, 요청이 내려가는 깊이를 줄여서 RDB는 꼭 필요한 조회만 맡게 만드는 계층 설계입니다.

공유 전제

읽기 요청이 계속 몰린다 같은 데이터를 반복 조회하는 비율이 높아지면 DB가 가장 먼저 병목이 됩니다.

↓

앞단에서 먼저 흡수한다 캐시가 1차 관문이 되어 대부분의 조회를 메모리에서 끝냅니다.

↓

DB는 예외 경로가 된다 캐시 미스나 최신 데이터처럼 꼭 필요한 경우에만 RDB까지 내려갑니다.

즉, 읽기 위주 시스템의 성능은 DB 직접 접근 비율을 얼마나 낮추느냐에 크게 좌우됩니다.

요청별 처리 경로

조회 상황

먼저 처리하는 곳

왜 효과적인가

반복 조회 상품 상세, 인기 게시글, 세션 데이터

1차 관문

Redis 캐시 자주 읽는 값을 메모리에 두고 즉시 응답

가장 빠른 응답 경로 대부분의 조회가 DB 왕복 없이 끝나므로 지연 시간과 DB 부하가 함께 줄어듭니다.

캐시 미스 처음 조회하거나 최신성이 필요한 데이터

2차 처리

RDB + 인덱스 필요한 행만 빠르게 찾고, 결과를 다시 캐시에 올림

DB 접근을 짧게 끝냄 모든 요청이 풀스캔으로 내려가지 않으므로 남은 조회도 비교적 안정적으로 처리합니다.

계속 커지는 읽기 부하 캐시만으로 흡수되지 않는 조회가 많아짐

보조 분산

읽기 분산 계층 읽기 레플리카 같은 구조로 남은 조회를 여러 노드에 분산

병목이 한 지점에 몰리지 않음 캐시가 1차로 막고, 남은 읽기는 분산시켜 전체 시스템의 안정성을 높입니다.

요점: 읽기 위주 시스템은 캐시로 대부분을 앞단에서 처리하고, 남은 조회만 인덱스와 읽기 분산으로 받쳐서 DB를 항상 직접 두드리지 않게 설계합니다.