Explanation

복잡한 연산이나 시간이 오래 걸리는 연산을 미리 수행, 저장해서 빨리 가져와서 쓸 수 있게 하는 것

DB가 버틸 수 있는 최대 요청수보다 많은 작업이 요청되면 느려질 수 있다. 이때 캐시를 사용하면 DB부하를 줄일수 있고 빠르게 응답가능

• 데이터가 변경에 민감한가?
• 연산이 비싼가?
• 데이터 변경이 전파가 되나?예) 페이스북에서 글이 안보이거나 데이터 싱크가 안맞아도 영향은 별로 없다. 하지만 항공권 예매에서 티켓예매 내역 또는 입금내역 같은 것들은 데이터 싱크가 서비스 전체 신뢰도에 영향을 줄수 잇다

• 로컬캐시 (EHcache, ConcurrentHashMap)
• DB 내부 캐시
• CDN
• in-memory 캐시 (redis, memcached)

쓰기 캐시

디스크 i/o에 한계가 있기 때문에 메모리에 담아두고 정기적으로 디스크에 싱크하겠다는 개념. 하지만 메모리에 있는 데이터는 유실 가능성이 높아 리플리케이션에 대한 고민이 필요

레벨 별 동기화

캐시 구현에따라 다르다. DB는 acid 지켜야 되지만 보통 오픈소스 인메모리 캐시는 dirty read를 무시하고 요청시점에 데이터 상태만 반환한다. 만약 transaction이 필요하다면 다른 솔루션을 도입해야 하고 데이터 정합성에 민감한 금용권은 레디스 사용을 권장하지 않는다

Q

캐시가 유실되면?

캐시서버가 날라가면 트래픽이 디비로 몰린다. 보통 캐시가 죽었을때 DB에 부하가 몰려 죽는경우도 많이 발생한다. 캐시가 죽더라도 DB가 버틸 수 있도록 구축이 필요하다.thundering herd issue라고 자주 참조되는 캐시 키하나가 없어지더라도 DB에 부하가 몰려 죽을 수 도 있다.그래서 계층형 구조로 구성하는 곳도 있다.예를 들면 트위터는 1차,2차,3차,디스크 형태로 구성한다.이는 돈이 많이 필요함으로 파레토의 법칙을 적용해서 구성해야 한다.파레토의 법칙은 - 80%의 서비스는 20%의 데이터로 운영

차세대 캐시 기술?

데이터 그리드라는 기술로 데이터 리플리케이션이 더 잘 구현된 기술이다. data cache를 storage 처럼 쓸 수 있다.

예) 이피니 스팬, 헤이즐 케스트

어떤 데이터를 캐싱해야 할까?

잘안바뀌는데 자구 접근하는 데이터가 가장 좋다.

예) 로그인 정보. 변화가 많으면 wrtie cache가 필요할 수 있다

캐시 모니터링 방법

별도에 테이블이나 캐시에 빈번하게 읽어지를 기록 또는 디비에서 얼마나 자주 가져와서 채워주는지를 기록할 수있다.

레디스를 서버동기화 목적으로 사용가능?

메서지 큐(pub/sub) 구조로 활용 가능하다. 그리고 가볍다. 이외에도 api limiter, sorted set을 활용한 랭킹 처리에 활용

VS

로컬 캐싱 vs 글로벌 캐싱

로컬 캐싱은 서버 내부 저장소에 캐시 데이터를 저장하는 것이다. 따라서, 속도는 빠르지만 서버 간의 데이터 공유가 안된다는 단점이 있다. 예를 들어, 사용자가 같은 리소스에 대한 요청을 반복해서 보내더라도 A 서버에서는 이전 데이터를, B 서버에서는 최신 데이터를 반환하여 각 캐시가 서로 다른 상태를 가질 수도 있다. 즉, 일관성 문제가 발생할 수 있다는 것이다. 이외에도 서버 별 중복된 캐시 데이터로 인한 서버 자원 낭비, 힙 영역에 저장된 데이터로 발생하는 GC에 대한 문제 등을 고려해야 한다.

반면에 글로벌 캐싱은 서버 내부 저장소가 아닌 별도의 캐시 서버를 두어 각 서버에서 캐시 서버를 참조하는 것이다. 캐시 데이터를 얻으려 할 때마다 캐시 서버로의 네트워크 트래픽이 발생하기 때문에 로컬 캐싱보다 속도는 느리다. 하지만 서버 간에 캐시 데이터를 쉽게 공유할 수 있기 때문에 위에서 언급한 로컬 캐싱의 문제를 해결할 수 있다. 따라서, 글로벌 캐싱 전략을 선택하고 현재 세션 스토리지로 사용하고 있는 Redis를 캐시 저장소로도 활용

EHcache vs redis

EHcache는 로컬캐시로써 특정 서버에 종속된다. 그렇게 되면 멀티 서버 환경에서는 데이터 싱크가 필요하다. 세션 클레스터링과 비슷하다.그리고 동기화가 속도에 영향을 줄 수 있고 데이터 유실 가능성이 있다. 하지만 데이터 접근은 빠르다.레디스는 독립적인 서버로 구축되어 네트워크 통신으로 서버들이 데이터에 접근하다. 속도는 로컬보다 느리다 하지만 데이터 동기화 이슈가 없다.

redis vs memcached

기술적으로는 memcached는 구현은 더욱 단순하지만 멀티 스레딩과 같은 기술 적용으로 코드는 더 어렵다. 기본 get/set 기능을 안정적으로 지원하는게 목표이다.redis는 collection 구조를 포함한 다양한 데이터 구조를 지원한다.redis는 인메모리에서 성능차이가 별로 없기 때문에 코드 복잡도를 줄여 디버깅 그리고 빠른 기능추가에 초점을 맞추었다

맴캐쉬드는 명료하고 단순함을 위하여 개발된 반면, 레디스는 다양한 용도에 효과적으로 사용할 수 있도록 많은 특징

클라우드 서비스에서 지원하는 레디스 vs 직접 설치하는 redis

관리에 차이가 크다 클라우드로 지원하는 경우 장애에 transparent하다. 자동으로 replicate로 endpoint가 변경된다.

couchbase vs redis

couchbase 경우 메모리랑 디스크에 저장하는 시간차이가 있어 동기화 이슈가 있을 수 있다. 하지만 데이터 센터 리플리케이션을 지원한다. 이렇듯 캐시 솔루션마다 특성이 다름으로 반드시 이해하고 사용해야 한다.

예) 레디스는 싱글쓰레드라 긴 작업이 들어가면 장애가 발생할 수 있음

캐시 vs 버퍼

버퍼는 데이터가 차기 까지 기다렸다가 쓰거니 읽는데 활용 캐시는 복잡한 연산이나 오래걸리는 연산을 미리 수행하여 결과 값을 저장해놓고 빠르게 사용하는 것이다.

캐시 사용으로 인한 다양한 이슈

• Look-Aside caching(값이 없을때 원본 데이터를 DB와 같은 곳에서 읽어와서 채우는것)으로 인한 race condition 발생 가능.
• thundering herd 이슈 -> expire time보다 조금더 빨리 재계산해줘서 해당 값을 남아있게 한다. 또는 캐시 락킹 방법사용 가능
• 캐시서버들 간에 데이터가 고루 분배되지 않아 특정 서버에만 캐시가 많이 쌓이는 이슈 -> adpative consistency개념 적용 가능
• 메모리는 비싸다는 단점 -> SDS와 같은 좋은 장비에 cold 데이터를 보관하고 hot한 데이터만 메모리에 두는 방법으로도 해결가능