관리 메뉴

개발캡슐

[CS] - [OS] - 캐시(Cache) 본문

CS

[CS] - [OS] - 캐시(Cache)

DevGreeny 2023. 3. 29. 11:17

캐시(Cache)

 

캐시(Cache)


- 자주 사용하는 데이터나 값을 미리 복사해 놓는 임시 장소를 말해.
- 문서의 사본을 자동으로 보관하는 HTTP 장치라고도 할 수 있지.
ex) 웹 요청이 캐시에 도착했을 때, 캐시된 로컬 사본이 존재한다면,
그 문서는 원서버가 아니라 앞서 미리 저장된 캐시로부터 제공되는 거야.

- 웹 프론트엔드에선 응답 데이터의 사본을 저장하는 공간이라고 해.

- 속도를 위해 용량을 절충하는 캐시는 일반적으로 데이터의 하위 집합을 일시적으로 저장해.
보통 완전하고 영구적인 데이터가 있는 데이터베이스와는 대조적이야.

- 웹 브라우저는 크게 2가지 방법으로 캐싱을 해.
거기엔 메모리 캐시디스크 캐시가 있어. 
=> 둘 중에 어떤 방식이 사용되는 가는 파일 사이즈에 따라 브라우저 자체의 알고리즘으로 알아서 처리해.

- 메모리 캐시 : RAM에 데이터를 저장해두고 읽는 방식.
- 디스크 캐시 : 파일에 데이터를 저장해두고 읽는 방식.

- js 및 css 적용시 클라이언트 캐시 비울때 주의사항이 있어.

 

캐시는 왜 필요하게 됐을까? (캐시의 등장 배경)


- 무어의 법칙(Moore's law)에 의해 CPU의 처리속도가 급격히 증가했지만,
메모리 접근 속도는 늘어나지 못했어.
- 메모리보다는 빠르고 CPU보다는 느린 cache를 메모리와 CPU사이에 위치시켜서
CPU의 데이터 접근 시간줄였지.
- 결과가 나올 때마다 메모리에 저장하기보다 cache에 미리 복사해 저장하면서
한 번에 메모리를 최신화하는 게 효율적이었던 거지.

위의 그래프는 Long Tail 법칙의 그래프인데, Long Tail 법칙은 20%의 요구가
시스템 리소스의 대부분을 사용한다는 법칙이야. 그렇기 때문에  20%의 기능에 Cache를 이용함으로써
리소스 사용량은 대폭 줄이고, 성능은 대폭 향상시킬 수 있어.

 

 

캐시의 주요 목적


더 느린 기본 스토리지 계층에 액세스해야하는 필요를 줄여서 데이터 검색 성능을 높이는 거야.

출처 : https://mangkyu.tistory.com/69

- 위와 같이, 저장공간 계층 구조에서 확인할 수 있듯이, 
캐시는 저장공간이 작고 비용이 비싼 대신에 빠른 성능을 제공해.

- 캐시를 쓰면(데이터를 미리 복사하기), 해당 데이터에 대한 요청이 있을 경우, 데이터의 기본 스토리지 위치에 액세스 할 때보다 더 빠르게 요청을 처리할 수 있어. 
EX) 이전에 검색하거나 계산한 데이터를 효율적으로 재사용할 수 있어. 

 

 

캐시의 작동방식


캐시의 데이터는 일반적으로 RAM(Random Access Memory)과 같이 빠르게 액세스할 수 있는
하드웨어에 저장되고, 소프트웨어 구성 요소와 함께 사용될 수 있어.

1 - 데이터 요청이 들어오면, 먼저 캐시에서 데이터 탐색을 해.
2 - 캐시가 없거나(Cache miss), 오래된(expiration)경우 원본 데이터가 저장된 곳에서 
데이터 조회 후, 캐시에도 데이터를 복사/갱신 해.
3 - 캐시에 데이터가 있으면(Cache hit) 캐시의 저장된 데이터를 제공해.
4 - 오래된 데이터는 삭제(eviction)해.

 

캐시의 지역성


캐시가 효율적으로 동작하려면, 캐시에 저장할 데이터가 지역성을 가져야 해. 

모든 데이터를 캐시에 담기에는 저장 공간이 그리 크지않기 때문에 힘들어.
그래서 보통 캐시는 지역성을 나누어 분류해.

- 지역성 : 데이터 접근이 시간적, 혹은 공간적으로 가깝게 일어나는 것.

 

시간적 지역성

특정 데이터가 한 번 접근되었을 경우, 가까운 미래에 또 한 번 데이터에 접근할 가능성이 높은 것을
시간적 지역성이라고 해.

메모리 상의 같은 주소에 여러 차례 읽기 쓰기를 수행할 경우 상대적으로 작은 크기의 캐시를 사용해도
효율성을 꾀할 수 있어.

즉, 한 번 가져왔던 데이터를 또 쓸 일이 있다는 의미를 말해.
이런 경우엔, 캐시에 한 번 가져와서 여러 번 사용하게 되면, 메모리에 접근하는 횟수가 줄어들어.
그래서 캐시는 반복적으로 사용되는 데이터가 많을수록 높은 효율성을 낼 수 있어.

 

공간적 지역성

특정 데이터와 가까운 주소가 순서대로 접근되었을 경우를 공간적 지역성이라고 해.
CPU캐시나 디스크 캐시의 경우 메모리 주소에 접근할 때, 그 주소뿐만 아니라 해당 블록을 전부 캐시에 가져오게 돼.

이때 메모리 주소를 오름차순이나 내림차순으로 접근한다면, 캐시에 이미 저장된 같은 블록의 데이터를 접근하게 되서
캐시의 효율성이 크게 향상돼.

즉, 앞으로 사용할 데이터들이 가져올 블록안에 모여있는 것을 말하는 거야.
필요한 데이터가 모여있다면 한번만 메모리에 접근해도 필요한 데이터들을 가져올 수 있다는 거지.

만약 데이터가 모여있지 않다면 Cache Miss가 날 확률이 높아지고 메모리에 여러번 접근하게 되서
효율성이 떨어지는 거지.

 

캐시(Cache)의 장점과 단점


😊캐시(Cache)의 장점

- 캐시데이터를 미리 복사해 놓으면, 계산이나 접근 시간 없이 더 빠른 속도로 데이터에 접근할 수 있어.
- 접근 시간에 비해 원래 데이터에 접근하는 시간이 오래 걸리는 경우나 값을 다시 계산할 때 시간을 절약할 수 있어.

즉, 트래픽 절감과 빠른 로딩 속도에 도움을 줘.

ex)
- 불필요한 데이터 전송을 줄여서, 네트워크 요금으로 인한 비용을 줄여주고.
- 네트워크 병목을 줄여줘. 대역폭을 늘리지 않고도 페이지를 빨리 불러올 수 있게 되지.
- 원서버에 대한 요청을 줄여줘. 서버는 부하를 줄 일 수 있고 더 빨리 응답할 수 있게 돼.
- 거리로 인한 지연을 줄여줘. 페이지를 먼 곳에서 불러올 수록 시간이 많이 걸리거든.
-  인터넷에서 사이트에 방문했을 때 다운로드한 파일들이 캐시에 저장되는데,
사이트를 방문할 때 시스템이 모든 정보를 다시 로드하지 않아도 돼.
그럼 브라우저가 사이트를 더 빠르게 로드할 수 있어.

 

🤔캐시(Cache)의 단점

- 캐시(Cache)는 캐시(Cash)라고 부를 정도로 비싸.
메모리 저장공간은 속도가 빠를수록 용량이 작고, 가격이 높거든.
cf) HDD의 GB당 가격 = 52~56원 / RAM의 GB당 가격 = 6900~7000원

- 개인 정보 보호 측면에서는 프라이버시 침해가 될 수 있어.
(그래서 주기적으로 삭제를 하는 게 도움이 되고, VPN을 사용하면 IP 주소 자체가 숨겨지기 때문에
캐시로 인한 프라이버시 침해를 방지할 수 있어.)

- 소스가 바뀐 걸 사용자가 바로 확인이 불가능해.(왜 이런지 더 알아봐야할 것 같아)

 

캐시의 활용


- 접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸리는 경우(서버의 균일한 API 데이터)

- 반복정으로 동일한 결과를 돌려주는 경우(이미지나 섬네일 등)

ex) 대부분의 게시판의 조회수, 추천수 등을 기준으로 게시글을 조회하는 기능

 

프론트엔드에서 캐시를 사용할 수 있는 영역


캐시 메모리는 하드디스크와 메모리 사이에만 있는 게 아니고, CPU와 메모리 사이에도 있고,
하드디스크와 케이블 사이에도 있고, CD-ROM과 메모리 사이에도 있어.
속도차이가 나는 모든 장치에 있다고 생각하면 돼.

그 영역은 3가지가 있어.

1. 브라우저 캐싱
2. 프록시 캐싱
3. DNS 캐싱


1. 웹 캐싱 - 브라우저 캐싱

가장 쉽게 생각할 수 있고, 많이 접하는 게 브라우저의  캐싱이야.
이전에 방문했던 페이지, 제목의 썸네일 등을 서버로 요청하지 않고,
브라우저에 캐싱을 해두면 사용자는 자신의 요청을 서버로부터 기다리지 않고
바로 캐시메모리로 응답받을 수 있어서 웹 서핑이 빠르다고 느끼고,
서버는 불필요한 요청을 받지않아 과부하를 피할 수 있어.

출처 : http://www.inven.co.kr/webzine/news/?news=172478&site=bangdream

 

2. 웹 캐싱 - 프록시(proxy)

웹 페이지를 캐싱하는 다른 방식으로 웹 브라우저와 서버 사이에 proxy라는 것을 두는 방식이야.
proxy는 "대리인"이라는 뜻의 영어단어인데,

중간에서 뭔가를 대신해주는 것을 프록시

라고 해. 중간에 있으면서 바이러스 체크나 보안 규정 위반 확인 등 해줄 수 있는 것들이 많이 있어.
그 중에서 간단한 형태로 "대신 웹페이지를 긁어다 주는 일을 해줄 수 있어".
그리고 이 과정에서 자신이 긁어다 건네주는 페이지나 그림 등을 캐싱할 수 있어.

같은 데이터가 자주 접근될 확률이 높으면 캐시 성능이 좋아진다고 해.
앞의 브라우저 캐싱은 각각의 컴퓨터 단위로 캐싱을 하기 때문에 이 확률이 높지 않을 수 있어.
하지만, 프록시의 경우 여러 컴퓨터로부터 요청을 받고 처리하다 보니 이 확률을 높일 수 있게 돼.

 

출처 : http://www.inven.co.kr/webzine/news/?news=172478&site=bangdream

 

EX) 구글 글로벌 캐시(GGC) , 클라우드 프레어, AWS의 클라우드 프론트

 

3.  DNS 캐싱

현재 인터넷은 캐싱 덕분에 돌아간다고 해도 과언이 아니야. 이건 DNS를 염두에 두고 한 말이야.
주소창에 www.inven.co.kr  라는 이름을 치면 IP주소라는 것으로 변환되어 통신 돼.
이처럼 사람이 읽을 수 있는 주소를 IP로 바꿔주는 걸 DNS라고 해. 

(마치 자바파일을 클래스파일로 바꿔주는 컴파일러 같은 느낌이라고 봐도 돼)

이 DNS는 주소를 변환하기 위해 맨 오른쪽부터 마침표 단위로 끊어서 
그것을 관리하는 서버로 두게 돼.
그리고 그 순서대로 계속해서 담당 서버의 IP를 물어보는 방식으로 동작해.

1 - 최상위 도메인 서버로부터 kr을 담당하는 서버의 IP를 알아내. 그걸 A라고 하자.
2 - A 서버에 co.kr을 누가 담당하는지 IP를 물어봐. 그걸 B라고 하자.
3 - B 서버에 inven.co.kr을 누가 담당하는지 IP를 물어봐. 그걸 C라고 하자.
4 - C 서버에 www.inven.co.kr  의 IP를 물어봐. 이걸 D라고 하자.
5 - 이제 브라우저는 D라는 IP주소로 패킷을 보내.

생각보다 이처럼 상당히 많은 단계를 거치고, 모든 단계에서 캐싱이 일어나.

예를 들어
1단계에서는 매번 kr을 담당하는 서버의 IP을 알아내지 않고 그걸 캐싱한 후 다음에 활용해.
2단계에서는 co.kr을 담담하는 서버의 IP를 캐싱해둬. 이런 방식으로 맨 마지막 단계인 5단계에서는
우리 컴퓨터에서도 www.inven.co.kr  의 IP를 캐싱해두는 식이야.

만일 DNS에 이런 캐싱이 없다면 어떤 일이 발생할까.
IP를 가지고 웹 페이지를 여는 사람들이 거의 없다는 가정하에 대부분 www.inven.co.kr  같은 이름을 쓸 거야.
그러니 한국의 모든 트래픽은 1단계에서 모두 같은 서버를 찾아가게 돼.
그리고 그 서버는 부하를 감당하지 못하고 죽게 될 거야.

 

4. API 캐싱
- 서버로 저장하는 데이터를
- 동일한 API를 요청하면 API캐시에 저장한 데이터를 반환

 

axios.get("",{
 headers : {
	content-type: "json",
	cache-control max-age=3600,
} 
})
//axios를 사용할 때 cache-control를 

캐시컨트롤 사용 x => 
같은 내용에 변하지 않는 내용인데도 불구하고 새로 계속 불러오니까
로딩 속도를 느려지게 만들고 서버에 부하가 일어날 수 있어.
서버 전송속도를 제어할 수 있어.

캐시를 사용하지 x => 보안에도 문제가 발생할 수 있어.

 

 

 

-참고자료-

더보기

'CS' 카테고리의 다른 글

[CSS] Position  (0) 2023.03.30
[CS] HTTP  (0) 2023.03.30
[CS] 프레임워크와 라이브러리, 그 차이점  (0) 2023.03.29
[CS]웹페이지가 브라우저에 렌더링되는 과정  (0) 2023.03.27
[CS] Restful API?  (0) 2023.03.27