해당 포스팅은 토비님의 캐시의 모든것을 기반으로 내용을 바탕으로 정리한 글입니다.
캐시란?
복잡한 연산이나 시간이 오래 걸리는 연산을 미리 수행/저장해서 빨리 가져와서 쓸수 있게 하는것
캐시의 종류
- 로컬캐시 (EHcache)
- DB 내부 캐시
- CDN
- in-memory 캐시 (redis, memcached)
어떻게 활용될 수 있을까?
DB가 버틸 수 있는 최대 요청수보다 많은 작업이 요청되면 느려질 수 있다. 이때 캐시를 사용하면 DB부하를 줄일수 있고 빠르게 응답가능하다.
캐시를 사용하기에 적절한 데이터를 판단하는 기준?
- 데이터가 변경에 민감한가?
- 연산이 비싼가?
- 데이터 변경이 전파가 되나?
예) 페이스북에서 글이 안보이거나 데이터 싱크가 안맞아도 영향은 별로 없다. 하지만 항공권 예매에서 티켓예매 내역 또는 입금내역 같은 것들은 데이터 싱크가 서비스 전체 신뢰도에 영향을 줄수 잇다.
쓰기 캐시란?
디스크 i/o에 한계가 있기 때문에 메모리에 담아두고 정기적으로 디스크에 싱크하겠다는 개념. 하지만 메모리에 있는 데이터는 유실 가능성이 높아 리플리케이션에 대한 고민이 필요하다.
어느정도로 레벨의 동기화가 필요할까?
캐시 구현에따라 다르다. DB는 acid 지켜야 되지만 보통 오픈소스 인메모리 캐시는 dirty read를 무시하고 요청시점에 데이터 상태만 반환한다. 만약 transaction이 필요하다면 다른 솔루션을 도입해야 하고 데이터 정합성에 민감한 금용권은 레디스 사용을 권장하지 않는다.
EHcache vs redis
EHcache는 로컬캐시로써 특정 서버에 종속된다. 그렇게 되면 멀티 서버 환경에서는 데이터 싱크가 필요하다. 세션 클레스터링과 비슷하다.그리고 동기화가 속도에 영향을 줄 수 있고 데이터 유실 가능성이 있다. 하지만 데이터 접근은 빠르다.
레디스는 독립적인 서버로 구축되어 네트워크 통신으로 서버들이 데이터에 접근하다. 속도는 로컬보다 느리다 하지만 데이터 동기화 이슈가 없다.
캐시가 유실되면?
캐시서버가 날라가면 트래픽이 디비로 몰린다. 보통 캐시가 죽었을때 DB에 부하가 몰려 죽는경우도 많이 발생한다. 캐시가 죽더라도 DB가 버틸 수 있도록 구축이 필요하다.
thundering herd issue라고 자주 참조되는 캐시 키하나가 없어지더라도 DB에 부하가 몰려 죽을 수 도 있다.
그래서 계층형 구조로 구성하는 곳도 있다.예를 들면 트위터는 1차,2차,3차,디스크 형태로 구성한다.이는 돈이 많이 필요함으로 파레토의 법칙을 적용해서 구성해야 한다.
파레토의 법칙은 - 80%의 서비스는 20%의 데이터로 운영된다.
reis vs memcached
기술적으로는 memcached는 기이은 더욱 단순하지만 멀티 스레딩과 같은 기술 적용으로 코드는 더 어렵다. 기본 get/set 기능을 안정적으로 지원하는게 목표이다.
redis는 collection 구조를 포함한 다양한 데이터 구조를 지원한다.redis는 인메모리에서 성능차이가 별로 없기 때문에 코드 복잡도를 줄여 디버깅 그리고 빠른 기능추가에 초점을 맞추었다.
차세대 캐시 기술?
데이터 그리드라는 기술로 데이터 리플리케이션이 더 잘 구현된 기술이다. data cache를 storage 처럼 쓸 수 있다. 예) 이피니 스팬, 헤이즐 케스트
클라우드 서비스에서 지원하는 레디스 vs 직접 설치하는 redis
관리에 차이가 크다 클라우드로 지원하는 경우 장애에 transparent하다. 자동으로 replicate로 endpoint가 변경된다.
couchbase vs redis
couchbase 경우 메모리랑 디스크에 저장하는 시간차이가 있어 동기화 이슈가 있을 수 있다. 하지만 데이터 센터 리프리케이션을 지원한다. 이렇듯 캐시 솔루션마다 특성이 다름으로 반드시 이해하고 사용해야 한다.예) 레디스는 싱글쓰레드라 긴 작업이 들어가면 장애가 발생할 수 있음
어떤 데이터를 캐싱해야 할까?
잘안바뀌는데 자구 접근하는 데이터가 가장 좋다.예) 로그인 정보. 변화가 많으면 wrtie cache가 필요할 수 있다.
캐시 모니터링 방법
별도에 테이블이나 캐시에 빈번하게 읽어지를 기록 또는 디비에서 얼마나 자주 가져와서 채워주는지를 기록할 수있다.
레디스를 서버동기화 목적으로 사용가능?
메서지 큐(pub/sub) 구조로 활용 가능하다. 그리고 가볍다. 이외에도 api limiter, sorted set을 활용한 랭킹 처리에 활용 할 수있다.
캐시 vs 버퍼
버퍼는 데이터가 차기 까지 기다렸다가 쓰거니 읽는데 활용 캐시는 복잡한 연산이나 오래걸리는 연산을 미리 수행하여 결과 값을 저장해놓고 빠르게 사용하는 것이다.
캐시 사용으로 인한 다양한 이슈
- Look-Aside caching(값이 없을때 원본 데이터를 DB와 같은 곳에서 읽어와서 채우는것)으로 인한 race condition 발생 가능.
- thundering herd 이슈 -> expire time보다 조금더 빨리 재계산해줘서 해당 값을 남아있게 한다. 또는 캐시 락킹 방법사용 가능
- 캐시서버들 간에 데이터가 고루 분배되지 않아 특정 서버에만 캐시가 많이 쌓이는 이슈 -> adpative consistency개념 적용 가능
- 메모리는 비싸다는 단점 -> SDS와 같은 좋은 장비에 cold 데이터를 보관하고 hot한 데이터만 메모리에 두는 방법으로도 해결가능
