강의 주소

https://www.youtube.com/live/zkbvFOwJFgA?feature=share

Summary

db에 붙어서 풀스캔한다고 하면, db자체의 캐시를 통해 호출한다해도 느려질 수 밖에 없다.

db가 느려지면, web/was 모두 느려지게 되기 때문에

이럴 때 캐시를 적용하면 연산자체를 빠르게 할 수 있다.

언제 캐시를 쓰는가?

데이터가 자주 변경되는가
연산이 얼마나 비싼가
서비스 신뢰도가 영향이 있을 수 있다.
read보단 write할때 캐시를 써도 되나 안되나 고민필요
쓰기를 위한 캐시
- write back
  - disk가 젤 느리고, 메모리가 그보단 빠르긴 하지만 일단 둘다 io가 발생하고 io는 한계치가 있는데 엄청나게 쓰게 되면 디스크가 나갈 수도 있고, 디스크가 한계가 있어서 메모리에 담아뒀다가 디스크로 싱크를 하게 되는데,
  - 전원이 커지면 메모리에 저장되었던 데이터가 날라가므로, replication에 대한 설계가 필요하다.
disk보다 네트워크가 빠른가?
- 어떤 회선을 사용하는가에 따라 다르고
- disk는 일정시점 전달하다 실패해버리면, 데이터 유실이 발생할 수 있다. 하지만 네트워크는 다중화 구성을 통해 예방할 수 있긴하다
- 하지만 100% 데이터를 유실없이 빠르게 하는 것은 없기 때문에, 어떤게 비용이 저렴하고 커버가 가능한가를 봐서 결정해야한다. 즉, 데이터 유실해도 상관없다거나
어플리케이션에 저장하는 로컬 캐시 = 메모리에 저장하는 것
- ehcache같은 라이브러리를 쓰거나, 변수에 저장하거나
- 없어졌을 경우 대책 필요하고, 동기화를 어떻게 할지 정책 필요
  - 한쪽이 바뀌면 통보가 필요하다. 이 통보를 완벽히 할 수 있나. 그래서 redis같은 인메모리 디비를 쓰면 빠르게 할 수 있다.
  - 동기화를 얼마나 맞춰서 해야하는지
    - jpa의 트랜잭션과 캐시를 맞춰서 dirty read가 없어야 한다는 의견도 있고 트랜잭션은 고려안핸다고 의견도 있고
인메모리 디비를 쓰는 것
- 요청했을 때의 시점으로 저장되기 때문에 트랜잭션 개념이 없다.
- redis는 ehcache와 다르게 클러스터링이 필요없고 웹서비와 분리되어 관리되기 때문에 외부에 쓰고 읽는 개념으로 보면 된다. 동기화에 대한 부담이 없다.
- db는 디스크를 쓰게되지만 redis는 메모리에 쓰기 때문에 한계치 더 크지만 유실될 수 있다.
- 캐시는 캐시 데이터가 날라가면, 모든 요청에 대한 트래픽이 db에 요청하게 된다.
  - 트래픽이 많으면 캐시가 죽으면 db가 죽을 수도 있다.
  - thundering cause : 한개의 캐시키를 여러군데에서 참조하고 있는데, 이걸 여러군데에서 한번에 10만개 요청했다고 하면 유실되었을 때 캐시가 없으니 db로 요청이 가서 죽을 수 있다.
  - 트위터의 경우 1차 캐시, 2차 캐시, 3차 캐시를 갖고 있어서, 3차까지 없으면 그때 db에서 조회하도록 하고 있다 —> 이건 비싼 비용을 감수하고 한 설계
  - 파레토 법칙 현상 발생
redis vs memcached
redis를 message queue로 사용하게 될 경우
- list 자료구조로 되어있고
- pub-sub보단 notification으로 호출하게 된다.
redis 활용예
- 랭킹 구현
- api limiter : 초당 api 몇개만 호출하게 한다든지
cache vs buffer

Reference

[Cache] Write Through과 Write Back의 차이