토비님과 강대명님의 캐시의 모든 것 정리

EhCache와 Redis를 언제 사용하는 것이 적절한지에 대해 알아보던 중 토비님이 본인의 유튜브 채널에서 레디스 커미터인 강대명님과 함께 촬영한 캐시의 모든 것 영상을 시청하고 저를 위해 정리한 글입니다.

 

 

 

1. 용어 정리

 

Buffer : 저장 시 일정 공간을 채울 때까지 대기하고 한 번에 저장함으로써 효율을 높이기 위한 목적

Cache : 복잡한 연산이 필요한 데이터 등을 미리 저장해놓고 바로 불러와 사용하기 위한 목적

 

 

2. 흔히 볼 수 있는 캐시의 종류

 

Eh Cache

Redis

Application 내부의 Variable

Web Cache (brower cache, proxy cache, gateway cache..)

 

 

3. 캐시 적용 판단 기준

 

(1) 데이터 변경이 자주 일어나는지?

(2) 데이터의 싱크가 서비스에 얼마나 중요한지?

: 페이스북, 인스타그램의 경우 글의 싱크가 별로 맞지 않아도 큰 문제가 없다.

그러나 은행 같은 금융 서비스에서 계좌 잔고가 실제와 차이가 난다면 서비스의 신뢰도가 크게 저하될 것이다.

 

 

4. Write Back Cache (입력 캐시)

 

(1) 디스크의 입력 속도가 느리기 때문에 메모리에 우선 데이터를 저장하고, 정기적으로 DB와 Sync를 맞추는 방식.

(2) 서버의 전원이 꺼지면 데이터도 함께 유실되는 것이 문제점.

: 만약 별로 중요하지 않은 데이터라면 유실되어도 상관 없으나 중요한 데이터라면 클러스터를 여러개 준비하여 Replication하는 방식으로 해결해야 한다. (비용 상승)

(3) 디스크가 SSD여도 입력 속도가 최소 10배 이상 차이나므로 캐시를 write back 방식을 활용하는 것이 효율적이다.

 

 

5. 어플리케이션 메모리 / 외부 인메모리 캐시를 사용하는 것의 차이점

= ehCache, Redis cache 차이와 같다.

 

(1) 속도면에서는 어플리케이션에서 캐시를 저장하는 것이 가장 빠르다.

: 어플리케이션에서 사용하는 변수 혹은 EhCache가 대표적인 예.

(2) 그러나 서버가 꺼지는 경우 데이터도 유실된다는 문제가 있으며, 서버가 여러대일 경우 동기화를 위해 Clustering 과정이 필요하다.

: 특히 동기화 문제로 인메모리 캐시를 Redis, Memcahced 같은 것들을 이용해 따로 사용하고 여러 서버에서 공유하는 방식을 주로 채택한다.

(3) 인메모리 캐시는 DB와는 관점이 전혀 다르기 때문에 ACID 같은 건 없다.

 

 

6. 캐시와 데이터베이스의 관계

 

(1) 디스크는 데이터를 영속적으로 저장하며 속도가 느리다.

(2) 캐시는 메모리에 휘발성으로 저장하며 속도가 빠르다.

(3) 이 때, 캐시 서버가 갑자기 다운될 경우 데이터베이스에 과부하가 걸리면서 같이 다운될 수 있다.

(4) 이런 문제 때문에 캐시를 계층형으로 구현하는 경우도 있다. 대표적으로 트위터의 경우 캐시를 1차, 2차, 3차로 나누어 구성하고 있다. 단, 늘 그렇듯 비용이 많이 든다.

 

 

7. Memcached와 Redis

 

(1) Memcached에서 지원하는 기능은 get, set 밖에 없으며 자료구조는 Hash table 뿐이다.

(2) Redis는 Lists, Hashes, Sets, Sorted Sets, Strings로 다양한 자료구조를 지원하며 디버깅이 빠르다.

 

 

8. ElasticCache와 Redis

 

(1) ElasticCache 같이 Cloud 시스템에서 제공하는 서비스 캐시는 별도의 설정 없이도 바로 사용할 수 있게 되어 있다.

(2) Redis를 직접 설치해서 사용할 경우 별도의 설정 없이 바로 적용하면 문제가 생길 수 있다.

(3) EleasticCache는 실 서비스에서 어려운 부분인 FaileOver를 비용만 지불하면 알아서 해결해준다.

 

 

9.  Redis를 어떻게 배우는 게 좋을까

 

(1) 당연한 얘기지만 직접 설치하고 사용해보는 게 제일 좋다.

(2) 내부 소스가 그렇게 어렵지 않으니 소스코드를 보면 도움이 될 것이다.

(3) Busy save 같은 설정들을 변경하는 것에 유의해야 한다.

: 5분에 일정 횟수 이상 업데이트되면 디스크 입력으로 넘기는데, 로컬 테스트에서는 문제가 되지 않으나 실 서버에서는 한 번에 엄청난 요청들이 몰려오기 때문에 장애 유발 가능성이 있다.

강대명님께서는 이는 사실상 테스트 서버용 설정이며 무조건적으로 off할 것을 권장함.

 

 

10. 캐시 적합성 판단 기준

 

(1) 어떤 데이터가 많이 잡히는지 빈번도로 판단한다. (Cache Hit / Cache Miss)

(2) Look aside cache 방식을 사용할 경우 데이터를 DB에서 캐시로 찾아온 회수를 저장해서 해당 카운트를 기준으로 판단 가능.

 

 

11. Redis를 메세지 큐 목적으로 사용하는 것은 어떤지?

 

(1) Redis는 현재 채널에 가입한 Subscriber에게 이벤트를 전달하는 Pub/Sub System 역할은 할 수 있으나 Message Queue와는 다르다.

(2) 이벤트가 도착했을 때 Subscriber가 존재하지 않는다면 이벤트가 사라진다. 우선순위와 이벤트 도착 여부가 보장되지 않는다.

(3) 가볍다.

 

 

12. 이외에도 Redis를 활용할만한 곳이 있다면

 

(1) API Limiter로 활용 가능하다.

(2) Ranking Data 등의 관리에 용이하다.

 

 

13. 캐시를 사용함으로써 발생할 수 있는 문제들

 

(1) Look Aside Caching시 데이터를 읽는 과정에서 Race condition(경쟁 조건) 문제가 발생한다.

(2) 캐시되지 않은 자원을 필요로하는 요청을 동시에 발생시킬 경우 Thundering herd 상황 발생 가능.

expire time 전에 캐실르 갱신시키는 방법으로 완화할 수 있다.

(3) 캐시 서버 동기화 문제