Introduction
성능테스트를 해보면서, 성능 향상을 위해 캐시라는 것에 대해 공부하는 글입니다.
아주 기본적인 개념부터, 캐시라는 개념이 어디에서 사용되는지, 사용할 때, 어떤 것들을 생각해봐야하는지에 대해서 작성해보도록 하겠습니다.
또 캐싱을 어플리케이션 단에서 적용시키고, 성능적으로 얼만큼 효과가 있는지, 어떤 점들을 고려해야할지 시리즈 형태로 작성해보도록 하겠습니다.
캐시란?
캐시라는 개념은 굉장히 범용적으로 사용되고 있습니다.
하드웨어부터 소프트웨어 어플리케이션까지 다양한 곳에서 캐시라는 개념이 사용됩니다.
그렇다면 캐시란 무엇일까요?
캐시란 자주 필요한 데이터나 값의 복사본을 일시적으로 저장하는 것을 "캐싱한다" 라고 표현합니다.
캐시가 사용되는 곳 예시
우선 캐시가 사용되는 곳의 예시를 보면서, 감을 잡아보도록 하겠습니다.
1 컴퓨터 하드웨어에서의 캐시
CPU와 메인 메모리(보통 DRAM)의 성능차이 때문에 나타나는 병목현상을 해결하기 위해, CPU에 캐시(SRAM)를 위치시키므로써 연산을 빠르게 하도록 돕는 역할을 합니다.
2 웹 브라우저 캐시
Web Broswer가 한번 받은 파일들을 캐싱해서 데이터를 들고 있고 똑같은 요청이 있을 떄, 브라우저 캐시를 통해 데이터를 제공합니다.
(HTTP Reseponse에 헤더에 캐시 지시자를 삽입하면 클라이언트 웹 브라우저에서는해당 지시자에 명시된 캐시 정책에 따라 캐싱을 하게 됩니다.)
3 Redis
인-메모리 DBMS로, RDBMS에 읽고 쓰는 것보다 빠르기 때문에, 캐싱DB로써 사용된다.
4 JPA
Java를 통해 DB와 통신하기 위한 ORM 중 하나인 JPA 내부에도 영속성 컨텍스트라는 개념에 캐싱이 들어가서 DB Query를 최소화하는역할을 한다.
위의 예처럼 굉장히 많은 곳에서 캐싱을 사용하게 되고, 이 캐싱을 사용하는 이유는 속도를 빠르게하기 위함이다.(리소스 낭비가 적다는 뜻..)
지역성의 원리
그러면 캐시를 쓰면 상대적으로 빠르니, 전부 캐싱해두면 되는거 아니야 라고 말할 수 있지만, 캐시 메모리는 용량이 적고, 가격이 비싸기 때문에, 캐시에 데이터를 올려둘 때는 지역성의 원리를 고려해서 캐싱을 해야한다.
지역성의 원리란
- 한번 참조된 데이터는 잠시 후에 또 참조될 가능성이 높다.
- 참조된 데이터 근처에 있는 데이터가 잠시 후에 사용될 가능성이 높다.
이런 점을 고려해서 캐싱한다고 한다.
#cf) 나는 어플리케이션 단에서 캐싱을 처리하고 성능을 측정해야하기 때문에, 자주 사용되지만 자주 변하지 않는 것들에 대해 캐싱처리를 해서 성능을 올려본 생각이다.
Global Cache vs Local Cache 차이점
Local Cache
- 로컬 장비 내에서만 사용되는 캐시
- 로컬 장비의 Resource를 이용한다 (Memory, Disk)
장점
- local에서작동 되기 때문에 속도가 global 에비해 빠르다
- 네트워크 지연, 단절 이슈에 자유롭다.
- 서버어플리케이션과 라이프 사이클을 같이 하므로 사용하기 간편
단점
-
만약 여러 서버가 존재하는 상황에서는 캐시 동기화에 대한 문제가 생길 수 있음.
(캐시 동기화 이슈 -> ehcache 같은 경우 분산캐시 활용해야함) -
어플리케이션이 다운되면, 메모리 데이터는 사라짐
-
어플리케이션의 메모리가 부족할 경우, 서버를 스케일업 해야함..
Global Cache
- 여러 서버에서 Cache Server에 접근하여 사용하는 캐시
장점
- 데이터를 분산하여 저장할 수 있다.
- 별도의 Cache Server를 이용하기 때문에 공유가 쉽다.
단점
- 네트워크 트래픽으로 인해 local cache에 비해 상대적으로 느리다.
- 네트워크 단절 될 경우 이슈가 존재.
정리
Local Cache와 Global Cache는 서로간의 Trade Off가 존재하기 때문에, 상황에 맞춰서 사용하는 것이 중요하다.
