Local,Remote Cache

목표 D-day : 46 일 오늘은 캐시에 대해서 학습하려고 합니다.

캐시 정리Permalink

캐시에 대해서 먼저 질문을 하고 대답하면서 학습을 하려고 합니다.

캐시(Cache)란 무엇이며, 웹 애플리케이션에서 왜 중요한가요?Permalink

캐시는 데이터나 계산 결과를 임시 저장하는 매커니즘입니다. 주로 데이터의 재사용을 통해 1)시스템의 응답속도를 높이고 2)자원의 효율적인 사용을 돕기 위해 사용됩니다. 캐시는 서버 측 메모리, 클라이언트의 브라우저, 혹은 로컬 디스크(persistent cache) 등 다양한 위치에 저장될 수 있습니다.

웹 어플리케이션에서는 제한된 자원을 사용하기 때문에 자주 요청되는 데이터를 캐시로 관리함으로써 !)응답 시간을 줄이고 2)서버의 부하를 줄여 성능을 향상 시킬 수 있습니다. 또한, 클라우드 데이터베이스나 유료 API를 사용하는 경우 캐시를 활용하여 요청 빈도를 줄임으로써 3)비용 절감 효과도 얻을 수 있습니다.

캐시를 사용할 때 성능과 비용 측면에서 이점도 있지만, 캐시 데이터가 오래되어 잘못된 정보를 제공할 수 있는 캐시 불일치(Cache Inconsistency) 문제나 캐시 갱신 전략(Cache Evicion Policy)에 고민이 필요합니다.

LocalCache와 RemoteCache의 차이점은 무엇이며, 각각 어떤 상황에서 사용하는 것이 적절한가요?Permalink

LocalCache는 웹 애플리케이션 서버의 메모리에 데이터를 저장하는 방식이며, RemoteCache는 중앙 집권식 캐시를 사용하는 방식입니다.

LocalCache는 구현이 간단하고, 데이터가 동일한 서버에 있으므로 빠른 성능을 제공합니다. 그러나 분산 서버나 MSA 구조에서 각 서버의 캐시 데이터가 일관성을 유지하지 못하는 문제가 있을 수 있으며, 캐시 무효화 전략을 통해 데이터 일관성을 어느 정도 유지할 수 있지만, 분산 환경의 복잡성을 고려해야 합니다.

반면, RemoteCache는 캐시 데이터를 별도의 서버에서 관리하므로, 분산 환경에서도 데이터 일관성을 유지할 수 있습니다. 하지만 네트워크를 통해서 접근해야 하므로 네트워크 지연이 발생할 수 있으며, 별도 서버 구축 및 모니터링 관리 비용이 필요합니다.

LocalCache는 자주 접근해야 하는 데이터나 실시간으로 빠르게 보여줘야하는 데이터를 캐싱하는 경우 유리합니다. 특히, 서버가 단일 서버로 구성되어 데이터 일관성을 관리해야 하는 경우 적합합니다.

RemoteCache는 분산 서버에서 데이터 일관성이 중요한 경우나 서버 확장이 필요한 환경과 캐시 영속성이 중요한 경우에 적합합니다. 모든 서버에서 일관된 캐시를 유지하는 경우나 서버 재배포 시에도 캐시가 유지되어야 하는 경우에 적합합니다. 추가로 별도 서버에 모니터링을 구축하는 불편함도 있지만 반대로 별도 서버에서 관리할 수 있다는 것도 장점이 됩니다.

LocalCache와 RemoteCache를 혼합하여 사용하는 경우도 있습니다. 빈번히 조회되는 데이터는 LocalCache에 저장하고, 모든 서버의 일관성과 영속성이 중요한 경우에는 RemoteCache에 저장하여 성능과 일관성 , 영속성을 모두 보장할 수 있습니다.

캐시 무효화Permalink

캐시된 데이터가 더 이상 최신의 데이터를 반영하지 않거나 특정 조건에 의해 더 이상 신뢰할 수 없는 상태가 되었을 때, 해당 캐시를 무효화(삭제 또는 갱신 필요 상태로 변경)하여 이후 요청 시 최신 데이터를 가져오도록 하는 과정을 말합니다. 이는 데이터 일관성을 유지하기 위해 필수적인 작업입니다.

1. 원본 데이터가 변경되어 캐시된 데이터가 오래되었거나 정확하지 않은 경우
2. 사전에 설정된 TTL(Time to Live)이 만료된 경우
3. 명시적인 캐시 무효화 정책이나 이벤트에 따라 무효화가 필요할 때

MSA에서 LocalCache 사용 시 발생할 수 있는 문제와 해결책은?Permalink

각 서비스 인스턴스마다 LocalCache가 존재하므로 데이터 일관성 문제가 발생할 수 있습니다. 이를 해결하기 위해서는 RemoteCache를 사용하여 별도 서버에서 관리하는 방법과 캐시 무효화 전략을 통해 LocalCache를 주기적으로 갱신합니다.

캐시 히트Permalink

요청된 데이터가 캐시에 이미 존재하고, 해당 데이터를 빠르게 반환할 수 잇는 경우를 말합니다.

캐시 히트가 발생하면 데이터베이스나 원본 데이터 소스에 접근할 필요가 없어, 응답 속도와 성능이 크게 향상됩니다. 캐시 히트율을 높이는 것이 애플리케이션 성능 최적화의 중요한 목표 중 하나입니다.

캐시 미스Permalink

요청된 데이터가 캐시에 존재하지 않아 원본 데이터 소스로부터 데이터를 가져오는 경우를 말합니다.

이 경우, 추가적인 지연(latency)이 발생하여, 원본 데이터에서 데이터를 가져온 후 이를 캐시에 저장함으로써 향후 동일한 요청이 있을 때 캐시 히트를 발생시킬 수 있도록 준비합니다. 캐시 미스를 줄이는 것이 시스템의 효율성을 높이는 데 중요합니다.

캐시 히트율(Cache Hit Ratio), 캐시 크기, 데이터 최신성 간의 트레이드오프Permalink

캐시 히트율이 높을 수록 빠른 응답 속도와 성능을 크게 향상 시킬 수 있습니다. 캐시 히트율이 높다는 것은 대부분의 요청이 캐시 히트로, 즉 캐시에 저장된 데이터로 처리할 수 있다는 의미입니다.

하지만 캐시 히트율을 높이기 위해서 캐시에 저장된 데이터가 많다는 의미이며 충분한 캐시 크기가 필요하게 됩니다.

메모리 비용과 운영 비용도 증가할 수있습니다

캐시 히트율 높이기 > 캐시에 저장된 데이터가 많아야함 > 캐시 크기가 커짐 > 돈 따따블

캐시 크기는 제한된다.Permalink

저장할 수 있는 데이터 양이 정해집니다. 캐시 크기에 맞춰 효율적으로 관리하기 위해 적절한 캐시 무효화 전략이 중요합니다. 예를 들어 LRU(Least Recently Used: 최근에 사용됨), LFU(Least Frequently Used: 자주 사용됨)와 같은 전략을 통해 캐시에 오래된 데이터나 자주사용하지 않은 데이터를 제거하여 중요한 데이터를 캐시에 유지할 수 있습니다.

데이터 최신화Permalink

캐시 유효화가 되려면, 데이터가 변경될 때마다 캐시된 데이터를 업데이트하여 일관성을 유지하는 것이 중요합니다. 하지만 캐시와 원본 데이터의 동기화 작업이 빈번히 이루어지면 쓰기 성능이 저하될 수 있으며, 이는 쓰기 지연을 초래할 수 있습니다. 특히, 자주 변경되는 데이터를 캐시에 유지하려고 한다면 이러한 쓰기 지연 문제는 더 고려해야합니다. 따라서 쓰기 빈도가 높은 데이터는 캐시에 적합하지 않거나, 일관성이 중요하지 않은 경우에만 캐시해야합니다.

서버 장애Permalink

캐시 서버의 장애가 발생하는 경우 캐시에 의존하던 대량의 요청 작업이 원본 데이터 소스(DB 혹은 다른 저장소)로 몰리게 되어 서버 과부하가 발생할 수 있습니다. 이러한 위험을 줄이기 위해 다중 캐시 서버(예: Redis 클러스터) 나 캐싱 관리 전략을 적용하여 안전성을 높이는 방법도 고려해야합니다.

정리Permalink

캐시 히트율을 높이는 것은 성능 최적화에 중요한 요소이지만, 캐시 크기, 데이터 최신성 유지, 그리고 비용간의 트레이드 오프를 고려해야합니다.

왜 자주 변경되는 건 캐시에 적합하지 않을까?Permalink

동기화 비용 증가

쓰기 빈도가 높다는 것은 원본 데이터의 변경이 매우 빈번하다는 의미입니다. 레디스 같은 캐시 시스템에서 쓰기 전략을 사용하더라도 매번 데이터가 변경될 때마다 캐시를 업데이트하거나 동기화하는 작업이 필요합니다. 이러한 동기화 과정에서 네트워크 오버헤드와 추가적인 쓰기 작업이 발새앟여, 결국 쓰기 성능에 좋지 않습니다.

캐시의 목적과 다름

캐시는 기본적으로 자주 읽는 데이터를 빠르게 제공하는 것이 목적입니다. 쓰기 성능 최적화보다 읽기 성능 최적화에 적합합니다. 쓰기 빈도가 높은 데이터를 캐시에 유지하려고 하면 캐시 히트율도 낮아지기 쉽고, 데이터 일관성을 유지하는 데 오버헤드가 크게 증가합니다.

오히려 메모리 사용량과 CPU 사용량을 증가시켜 효율성을 떨어뜨립니다.