← 전체 목록
⚡
Google Memorystore
데이터베이스관리형 Redis/Memcached 캐시
▶아키텍처 다이어그램
🚀Application
⚡Redis Cache
📋Replica
🗄️Primary DB
⏱️TTL
🔒Private VPC
Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.
Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.
점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다
왜 필요한가요?
트래픽이 늘면 동일한 데이터를 반복 조회하는 요청이 원본 데이터베이스를 압박합니다. 응답은 느려지고, DB는 실제로 중요한 쓰기 작업보다 캐시 가능한 읽기 요청에 시간을 쓰게 됩니다.
안에서 어떻게 동작하나요?
애플리케이션은 먼저 Memorystore에서 키를 조회하고, 히트하면 메모리 값을 바로 반환합니다. 미스일 때만 원본 DB를 읽고, 그 결과를 TTL과 함께 캐시에 적재합니다. 고가용성 구성을 쓰면 복제본이 장애 시 승격됩니다.
무엇과 헷갈리나요?
Memorystore와 Firestore는 둘 다 빠른 응답을 기대할 수 있지만, Memorystore는 휘발성 캐시 계층이고 Firestore는 영구 저장되는 시스템 오브 레코드입니다. 캐시 일관성과 만료를 감수할 수 있으면 Memorystore, 원본 데이터를 안전하게 저장해야 하면 Firestore가 맞습니다.
왜 이런 방식이 등장했나요?
웹 애플리케이션이 커지면서 관계형 DB 한 대가 모든 읽기를 감당하던 구조는 빠르게 병목이 되었습니다. 그래서 원본 DB 앞에 메모리 캐시를 두는 패턴이 성능 최적화의 기본으로 자리 잡았습니다.
언제 쓰나요?
세션, 카운터, 핫 데이터 조회 가속에 적합합니다. 트랜잭션 일관성이 중요한 영구 데이터나 장기 보관 데이터의 본 저장소로 쓰기에는 맞지 않습니다.
세션 저장읽기 캐시레이트 리미팅실시간 랭킹
Official Docs
GCP더 깊게 보기
현재 페이지의 개념 설명을 본 뒤 공식 문서로 바로 이동합니다.