캐시(Cache)란 무엇일까?

개발 방향성이 "DB 메모리를 최소화 하자!" 정해진 이후로, 

캐시에 대한 관심이 상당히 커졌습니다. 

기존에는 데이터 연산과 ORM을 하기 위한 준비를 모두 DB 쿼리에서 소화했는데, 

그렇게 되면 DB 메모리를 상당히 많이 사용하게 됩니다. 

그래서 입출력을 최소화하고 캐시 데이터를 기반으로,

애플리케이션 단계에서 연산과 데이터 매핑을 진행하려고 합니다. 

이렇게 되면 애플리케이션 메모리 즉 서버 메모리가 올라가는데, 

확인 결과 서버 메모리를 배짱이 수준으로 놀고 있었습니다. 

이게 대부분이 그런지는 확인해 봐야겠지만, 

기본적으로 DB 자원보다는 서버 자원을 사용하는게 맞다고 생각됩니다. 

 

캐시란?

캐시는 데이터를 메모리에 올려 놓고,

필요할 때 마다 메모리에서 꺼내서 사용 합니다. 

메모리에 올라가져 있기 때문에 DB에 다녀올 필요 없이, 

엄청나게 빠른 속도로 데이터를 가져올 수 있습니다. 

예를 들면 자주 사용하는 물건을 가까운 서랍에 두는 것과 같습니다.

물건을 필요할 때마다 멀리 떨어진 창고까지 가는 대신,

가까운 서랍에서 빠르게 꺼내 쓰는 원리입니다.

 

캐시 라이프 사이클

먼저 현재 캐시가 있는지 확인 합니다. 

캐시는 "키" 를 통해서 데이터를 컨트롤 할 수 있습니다. 

만약 캐시 데이터가 존재한다면 즉시 그 데이터를 가져 옵니다. 

이 경우를 "캐시 히트" 라고 합니다. 

반대로 캐시 데이터가 없다면, 

DB에서 데이터를 가져와서 데이터를 캐싱 합니다. 

캐시 데이터가 없는 상황을 "캐시 미스" 라고 표현 합니다. 

아래 처럼 캐시는 2가지 라이프 사이클을 가지고 있습니다. 

 

캐시 데이터 확인 -> 캐시 히트 

캐시 데이터 확인 -> 캐시 미스 -> DB 조회 -> 데이터 캐싱

 

캐시에는 얼마동안 데이터를 유지할 것인지 설정하는 기능이 있습니다. 

해당 시간에는 정답이 없으며 데이터 성질과 비즈니스에 따라서 변하게 됩니다. 

 

캐시 종류

캐시에도 종류가 있는데, 

로컬 캐시와 분산 캐시가 있습니다. 

로컬 캐시는 앞전에 설명한 케이스로 서버 자체의 메모리에 데이터를 캐싱하는 방식입니다. 

장점으로는 네트워크 통신 없이 서버 내부에서 직접 데이터를 읽기 때문에 속도가 매우매우 빠릅니다. 

서버 자원을 사용하기에 추가 비용도 없습니다. 

단점으로는 서버가 여러 대일 때, 

각각의 서버마다 캐시 데이터가 다를 수 있습니다. 

A서버는 캐싱이 되었는데, 

B서버 C서버는 캐싱이 안되어있을 수 있습니다. 

이는 각각의 서버 메모리를 사용하기 때문에 발생하는 단점 입니다. 

좀 더 자세히 들어가면 단일 서버를 사용해도 캐싱 데이터 동기화가 안될 수 있습니다. 

애플리케이션 풀에서 워커 프로세스들이 동작할 때, 

각 프로세스들은 자원을 공유하지 않기 때문에 단일 서버여도 캐싱 데이터가 다를 수 있습니다. 

간단하고 성능이 좋은 대신 데이터의 일관성을 보장하지 않는 것이 로컬 캐시 입니다. 

 

반대로 분산 캐시는 여러 서버가 공유하는 별도의 캐시 서버 입니다. 

앞에 설명한 로컬 캐시의 단점을 모두 커버한 캐시 방식 입니다. 

분산 캐시는 데이터가 필요할 때,

네트워크를 통해 캐시 서버에 접속하여 데이터를 요청 합니다. 

모든 서버가 같은 캐시 서버를 바라보기 때문에 데이터의 일관성이 보장 됩니다. 

이렇게 되면 10대의 서버에서 각각 저장해야 했던 캐시 데이터를 단 1대에만 저장하면 된다는 메모리적 장점이 있습니다. 

단점으로는 일단 느립니다. 

네트워크 통신이 필요하므로 로컬 캐시보다 접근 속도가 느립니다. 

하지만 DB 조회 보다는 훨씬 빠르기 때문에, 

요즘에는 대부분 분산 캐시 Redis 많이 사용하는 것 같습니다. 

 

요즘 개발이 대용량 데이터를 처리해야하는 방향으로 흘러가고 있는데, 

캐싱을 통한 빠른 처리는 더 중요해질 것 같습니다.