캐시의 이용
캐시는 cost의 비용이 높은 결과값 이나 자주 참조하는 데이터를 메모리 안에 두어 빨리 처리가 가능하도록 하는 저장소 이다.
웹페이지를 새로고침 할 때마다 표시할 데이터를 가져오기 위해 한 번 이상의 데이터베이스 호출이 발생하게 되는데, 캐시는 이런 데이터 베이스로의 호출을 줄여준다.
(DB와의 요청/반환은 어플리케이션의 성능을 좌우하는 요소 중 하나이다.)
캐시계층
캐시 계층은 데이터가 잠시 보관되는 곳으로, 데이터베이스보다 훨씬 빠르다는 장점을 갖는다. 별도의 캐시계층을 두면 성능이 개선될 뿐 아니라 DB의 부하를 줄일 수 있다.
위 그림은 <읽기 주도형 캐시 전략> 이라고 부르는 전략의 다이어그램이다.
- 요청을 받은 웹 서버는 캐시에 해당 응답을 요청한다.
- 캐시서버는 캐시에 저장되어 있는 데이터가 존재한다면 클라이언트에게 반환한다.
-1) 존재하지 않는다면 DB로부터 데이터를 캐시에 저장 및 반환한다.
이 외에도 다양한 캐시 전략이 있다. 캐시할 데이터의 종류, 크기, 액세스 패턴에 맞는 캐시 전략을 선택하면 된다. More : 다양한 캐시전략
캐시 사용시 유의할 점
캐시를 사용할 때는 다음과 같은 점들을 유의해야 한다.
-
캐시는 어떤 상황에 바람직 한가?
캐시된 데이터들은 수시로 dirty-check 를 통해서 데이터의 일관성을 체크해야 한다. 따라서 캐시에 자주 변하는 데이터를 캐싱할 경우, 결국 DB로의 update 로직이 추가되어 더 나쁜 성능을 줄 수 있다.
-> 데이터 갱신은 자주 일어나지 않지만 참조는 빈번하게 일어나는 data 에 적합. -
어떤 데이터를 캐시에 두어야 하는가?
캐시는 데이터를 휘발성 메모리(전원이 차단되면 데이터가 날아가는)에 저장한다는 특징을 갖는다. 따라서 영구적으로 보관해야할 데이터는 캐시에 두지 않는 것이 좋다. -
캐시에 보관될 데이터는 어떻게 만료되는가?
캐시의 만료정책을 정하는 것은 매우 중요하다. 만약, 만료정책이 없다면 데이터는 캐시에 계속 남게 된다.
만료기한이 너무 짧을 경우 DB 에서 자주 읽어오게 될 것이고
만료기한이 너무 길 경우 캐시의 데이터와 DB의 데이터가 다를 확률이 높아진다. -
일관성은 어떻게 유지되는가?
일관성이란 DB 저장소의 원본과 캐시 내의 사본이 같은지 여부를 뜻한다. 사실 위의 캐시의 만료 정책과 연관된 부분이다.
저장소의 원본을 갱신하는 연산과 캐시를 갱신하는 연산이 단일 트랜잭션으로 처리되지 않는 경우 이 일관성은 깨질 수 있다. -
장애 발생시에는 어떻게 대처할 것인가?
캐시 서버를 한 대만 두는 경우 해당 서버는 단일 장애 지점(Single Point Of Failure, SPOF) 이 되버릴 가능성이 있다. > SPOF
결국 위의 문제를 해결하기 위해서는 여러 지역에 걸쳐 캐시서버를 분산시켜야 한다. -
캐시 메모리의 크기에 관한 전략
한정된 서버의 메모리 내에서 캐시 메모리 크기 전략은 중요하다. 캐시 메모리가 너무 작으면 캐싱된 데이터들이 자주 밀려나게 되어(Eviction) 캐시서버의 성능이 떨어진다.
이를 막을 한가지 방법은 캐시 메모리를 많이 할당(Overprovision) 하는 것이다. 이렇게 하면 캐시에 보관될 데이터가 갑자기 늘어났을 때 생길 문제도 방지할 수 있게 된다. -
데이터 방출하는 정책 (Eviction strategy)
캐시가 꽉 찰 경우(full), 기존의 데이터를 내보내야 한다. 이 방출할 데이터를 선택하는 정책을 Eviction strategy 라고 한다.
이에 대한 전략은 여러가지가 있다. 그 가운데 가장 널리 쓰이는 것은 LRU(Least Recently Used), LFU(Least Frequently Used), FIFO(First In First Out) 등 상황에 맞는 다양한 정책을 선택해야 할 것이다.
