캐시, 캐싱이라는 개념은 광범위하게 사용됩니다.
1. 크게 보면 웹 서비스를 생각할 수 있습니다. 전 세계 사람들이 유튜브 영상을 요청하는데 그 데이터들을 매번 저장소에서 꺼내오려면 굉장히 많은 부하(=돈+시간)가 걸릴 겁니다.
그래서 구글은 각국 통신사마다 캐시 서버를 두어서 요청이 구글 데이터 센터로 몰려오지 않게 합니다. 나라마다 자주 요청하는 영상은 캐시 서버에서 바로 전달할 수 있게 되고, 캐시 서버에 없는 영상만 저장소에 요청하겠죠.
2. 반대로 아주 작게는 CPU가 데이터를 처리할 때가 있습니다. 데이터를 읽을 때 L1, L2, L3 cache 에 저장된 데이터가 있는지 확인하고, 없는 경우에만 Memory나 Disk에 접근합니다. 가져온 데이터는 다음에 찾을 걸 대비해서 캐시에 넣어둡니다.
3. 다시, 조금 크게 생각해보면 데이터베이스(주로 RDBMS)에 쿼리 요청이 무수히 쏟아지는 상황을 생각해 볼 수 있습니다. DB는 데이터 요청이 들어오면 디스크를 뒤지기 전에 임시 저장소인 버퍼 캐시에 가서 최근에 요청된 데이터가 있는지 확인합니다. 찾는 데이터가 위치한 블록이 버퍼 캐시에 없으면 디스크로 가서 찾아야 합니다. 다만, 전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상을 설명하는 파레토 법칙과 같이 대부분의 요청은 버퍼 캐시에서 해결됩니다.
Redis는 DB의 버퍼 캐시로는 해결이 되지 않을 때 등장하는 외부 캐시 서버로 사용할 수 있습니다. DB 내부의 버퍼 캐시를 크-게 만들어서 외부에 두는 격이라고 보면 되겠습니다.
key-value 형태의 데이터 저장소인 레디스는 그 자체로 DBMS(비 관계형 데이터베이스 관리 시스템)입니다.
같은 얘기를 상황만 다르게 여러 번 했는데요, 이렇듯 캐시는 여기저기서 쓰입니다.
LRU(Least recently used)는 캐시 안에 어떤 데이터를 남기고, 지울지에 대해 선택하는 알고리즘 중 하나입니다. 제한된 용량 안의 cache에 데이터를 올리고, 용량이 가득 찬 경우 '가장 오랫동안 사용되지 않은 값'부터 버리는 방법입니다. 데이터베이스의 버퍼 캐시도, redis도 이 방식을 지원합니다. 선입선출 등의 방법도 있지만 효율성 면에서 좋지 않기 때문에 LRU를 많이 사용하는데요, 전에 개념을 공부하면서 썼던 글을 공유합니다.