🧧 캐시와 캐싱
성능을 좋게 만드는 방법을 대표하는 것들은 정말 다양하다. 오늘은 그 중 성능 향상에서 빠지지 않는 주제인 캐싱에 대해서 얘기를 해보려고 한다.
캐시란?
캐시는 컴퓨터의 성능을 향상 시키기 위해 데이터를 임시로 저장해두는 장소를 뜻한다.
캐싱은 캐시 영역로 데이터를 가져와서 해당 메모리에서 읽고 쓰는 작업하는 방식 그자체를 말한다.
다른 의미는 메모리상에 있는 데이터를 연산하고, 이 연산을 더 빠른 CPU 메모리 영역으로 가져와 처리를 수행하는 것도 캐싱이다.
♬캐싱의 이점
1. 어플리케이션 성능 개선
In-Memory는 디스크보다 데이터를 읽는 속도가 훨씬 빠르기 때문에 훨씬 더 빠른 데이터 액세스는 어플리케이션의 전반적인 성능을 개선한다
2. DB 비용 절감
단일 캐시 인스턴스는 수십만 입출력 작업을 제공하기때문에 수많은 DB 인스턴스를 대체할 수 있으므로 총 비용이 절감된다. 비용 절감은 기본 DB의 요금과 직접적으로 연결되고 그 영향은 나아가 수십퍼센트의 비용이 절감된다.
3. BackEnd의 로드 감소
캐싱은 읽기 로드의 상당 부분을 백엔드 DB에서 In-Memory로 리다이렉션함으로써 DB의 로드를 줄이고 로드 시에 성능이 저하되거나 작업 급증 시에 서버의 다운을 방지한다.
3. 예측 가능한 성능
어플리케이션 사용량이 급증하는 시기에 대응하는 것이 중요한데 특정 타임에 서버가 다운 될 경우가 발생하면 DB에 대한 로드로 인해 데이터를 가져오는데 지연시간은 예상이 불가능할 정도로 늘어나고 그에대한 성능 저하로 인해 전체적인 서비스의 저하로까지 이어질 수 있다. 때문에 In-Memory의 캐시를 활용하면서 문제를 방지 할 수 있다.
🧧 캐시 전략
캐시 전략은 웹 서비스 환경에서 시스템 성능 향상을 기대할 수 있는 중요한 기술이다.
어느 종류의 데이터를 캐시에 저장할지, 얼만큼 데이터를 캐시에 저장할지, 얼마동안 오래된 데이터를 캐시에서 제거하는지에 대한 전략을 세워야한다.
♪ 데이터 정합성
캐시를 이용하게 되면 반드시 닥쳐오는 문제점이 바로 데이터의 정합성 문제다
데이터 정합성은 바로 캐시에 저장 되어 있는 데이터와 실제 DB에 저장된 데이터가 일치하지 않으면서 발생하는 현상이다. 때문에 적절하게 캐시를 읽고 쓰는 전략을 세워 데이터 불일치를 극복하려고 한다.
♬ 읽기 전략 (Read Cache)
1. Look Aside 전략
순서
1. Cache에 검색한 데이터가 존재하는지 확인
- 만약 있다면 해당 데이터를 가져온다. ( Cache Hit )
2. 없다면 DB로 들어가서 데이터를 조회해서 가져온다 ( Cache Miss )
3. 조회한 데이터는 캐시에 저장한다
장점
- 데이터를 찾을때 우선 캐시에 저장된 데이터가 있는지 우선적으로 확인 없다면 DB에서 확인
- 반복적인 읽기가 많은 호출에 적합
- 원하는 데이터만 별도로 구성하여 캐시에 저장한다
- 캐시와 DB가 분리되어 있기 때문에 캐시 장애에 대비되어 구성되어 있다
단점
- Cache Miss 가 된 순간 많은 요청이 오면 모두 Cache Miss 가 되면서 순간적으로 DB에 부하가 발생할 수 있다
2. Read Through 전략
1. Cache에 검색한 데이터 확인
2. 없다면 DB에서 데이터를 자체적으로 조회하여 업데이트
3. Cache에 데이터를 가져온다
장점
- Look Aside와 비슷한 방식이지만 데이터 동기화를 라이브러리 또는 캐시 제공자에게 위임하는 방식이라는 차이가 있다 즉, 저장된 데이터를 불러오는 곳이 Server 냐 캐시냐의 차이다.
- 캐시가 DB와의 동기화가 항상 이루어지기 때문에 정합성 문제에서 벗어날 수 있다.
단점
- 데이터를 조회하는데 전체적으로 속도 저하 발생
- 데이터를 캐시에만 의존하게 되면서 캐시가 다운되면 서비스 이용에 차질이 발생
♬ 쓰기 전략 (Write Cache)
1. Write Back 전략
1. 모든 데이터를 cache에 저장
2. 일정 시간이 지나면 DB에 저장한다
장점
- 캐시와 DB동기화를 비동기하기 때문에 동기화 과정이 생략되었다
- 데이터를 저장할때 DB에 바로 쿼리하는 것이 아니라, 캐시에 모아서 일정 주기 배치 작업을 통해 DB에 반영
- 쓰기 쿼리 회수 비용과 부하를 줄일 수 있다
- Write가 빈번하게 이뤄지면서 Read를 하는데 많은 양의 Resource가 소모되는 서비스에 적합하다
- 데이터 정합성을 확보 할 수 있다
단점
- 자주 사용되지 않는 불필요한 리소스 저장
- 캐시에서 오류가 발생하면 데이터를 영구적으로 소실한다.
2. Write Through 전략
1. DB에 저장할 데이터가 있다면 우선 Cache에 저장한다
2. 그리고 바로 Cache에서 DB로 바로 저장한다.
장점
- 데이터를 저장할 때 먼저 캐시에 저장한 다음 DB에 바로 저장한다
- DB 동기화 작업은 캐시를 통해 하기 때문에 문제가 발생하지 않는다
- 마찬가지로 항상 동기화 되어 있기 때문에 캐시의 데이터는 자연스럽게 최신 상태이다.
- 캐시와 백업 저장소에 업데이트를 같이 하여 데이터 일관성을 유지할 수 있다.
- 데이터 유실이 발생하면 안되는 상황에서 적합하다
단점
- 자주 사용되지 않는 불필요한 리소스를 저장한다
- 매 요청마다 두번의 Write(캐시, DB)가 발생하면서 데이터의 수정이 너무 자주 발생하면 서비스의 성능에 문제가 발생한다
- 기억장치 속도가 느리다면 데이터를 기록할 때 CPU가 대기하는 시간이 필요하기 때문에 성능이 감소된다.
3. Write Around 전략
장점
- Write Through보다 훨씬 빠르다
- 모든 데이터는 DB에 저장 (캐시를 갱신하지 않는다)
- Cache miss가 발생하는 경우에만 DB와 캐시에도 데이터를 저장한다
단점
- 캐시와 DB내의 데이터가 다른 데이터 불일치가 발생할 확률이 높다.
♬ read와 write 의 조합
1. Look Aside + Write Around
가장 많이 사용되는 환경이다.
1. 데이터는 DB에 가장 먼저 저장
2. 이후 데이터를 요청하면 캐시에서 먼저 가져온다
3. cache miss가 발생하면 Server에서 DB에 있는 데이터를 가져온 후 캐시에 다시 저장한다.
2. Read Through + Write Around
항상 DB에 쓰고, 캐시에서 읽을때 항상 DB에서 먼저 읽어오면서 데이터 정합성 이슈에 대한 완벽한 안전 장치를 구성한다
1. 데이터를 저장하는 것은 바로 DB에 저장한다
2. 데이터를 읽을때는 캐시에 접근하고 캐시는 DB를 읽어서 데이터를 가져오기 때문에 데이터의 정합성 이슈를 완벽하게 보안
2. Read Through + Write Through
데이터를 쓸때 항상 캐시에 먼저 쓰기때문에, 읽어올때 최신 캐시 데이터를 보장한다.
데이터를 쓸때 항상 캐시에서 DB로 보내므로, 데이터 정합성이 보장된다.
