Google Memorystore

같은 값을 여러 요청이 반복해서 읽으면 원본 DB가 먼저 병목이 됩니다. 응답 속도도 느려지고, DB는 바뀌지 않은 데이터를 계속 다시 읽는 데 자원을 씁니다.

웹 애플리케이션이 커지면서 관계형 DB 한 대가 모든 읽기를 감당하던 구조는 빠르게 병목이 되었습니다. 그래서 원본 DB 앞에 메모리 캐시를 두는 패턴이 성능 최적화의 기본으로 자리 잡았습니다.

애플리케이션이 먼저 캐시 키를 조회하고, 값이 있으면 메모리에서 바로 반환합니다. 미스가 나면 원본 저장소를 읽어 채우고, TTL로 오래된 값을 자연스럽게 비웁니다. 복제 구성을 쓰면 장애 시 대기 인스턴스로 넘길 수 있습니다.

Memorystore와 Cloud SQL은 둘 다 앱이 읽는 데이터를 받지만, Cloud SQL은 원본 데이터를 보관하는 데이터베이스이고 Memorystore는 그 앞에서 읽기를 줄이는 캐시 계층입니다. 최신성과 영속성이 중요하면 Cloud SQL, 잠깐 늦어져도 되는 핫 데이터면 Memorystore가 맞습니다.

세션, 카운터, 핫 데이터 조회 가속에 적합합니다. 트랜잭션 일관성이 중요한 영구 데이터나 장기 보관 데이터의 본 저장소로 쓰기에는 맞지 않습니다.