본문 바로가기
Project/Tech_review

캐시 그리고 세션

by 스타트업_디벨로퍼 2021. 2. 26.

기본 이론

메모리 계층 구조

💡
데이터를 저장하는 공간의 속도와 용량은 반비례 관계 - 속도가 빠른 메모리일수록 용량이 적음 - 용량이 큰 저장장치는 속도가 느림 - 둘다 잡기에는 비용이 너무 많이 든다. - 그래서 데이터 저장공간은 속도와 용량에 따라 특성에 맞게 역할을 나누어서 사용한다. 데이터 저장공간을 속도-용량 순서대로 쌓으면 마치 피라미드와 같은 현상이 나타난다. (Memory Hierarchy)!

파레토의 법칙

💡
이탈리아의 경제학자 빌프레도 파레토가 발견한 현상 - 원인 중 상위 20%가 전체 결과의 80%를 만든다는 법칙 - 2대 8 법칙이라고도 한다. - 여러 곳에 관찰할 수가 있다.

데이터 지역성의 원리

💡
자주 쓰이는 데이터는 시간적 혹은 공간적으로 한 곳에 몰려 있을 가능성이 높다. - 시간 지역성 : 예를 들어 for 문에서 조건변수를 선언했을때 해당 변수는 for문이 끝나기 전까지 계속 쓰일 확률이 높은 것 - 공간 지역성 :for 문에서 어떤 배열에 접근했을 떄, 해당 배열이 위치한 메모리 공간의 내용은 for 문이 끝나기 전까지 계속 쓰일 확률이 높은 것! → for문에서 array[0] ~ array[n] 과 같이 배열에 접근할 때, 다음 번에는 array[n+1]이 접근할 확률이 높은 것을 따로 분류하여 순차 지역성이라고 부르기도 한다. 각 지역성 별로 메모리와 실행시간의 영역이 다른 것을 확인할 수 가 있다!

💡
하나의 작업을 하기 위해서 계속해서 옮기고 다시 옮기는 작업이 매우 비효율적이다! 그래서 캐시라는 개념이 탄생했다. 캐시 : 나중에 필요할 수 도 있는 무언가를 저장하였다가 신속하게 회수할 수 있는 보관 장소로, 어떤식으로든 보호되거나 숨겨진다.

💡
캐시의 작동 방식 - 원본데이터(System of Record) 와는 별개로 자주 쓰인 데이터(Hot Data)들을 복사해둘 캐시 공간을 마련한다. 캐시 공간은 상수 시간등 낮은 시간 복잡도로 접근 가능한 곳을 주로 사용한다. - 데이터를 달라는 요청이 들어오면, 원본 데이터가 담긴 곳에 접근하기 전에 먼저 캐시 내부부터 찾는다. - 캐시에 원하는 데이터가 없거(Cache miss)나 너무 오래되어 최신성을 잃었으면(Expiration) 그때서야 원본 데이터가 있는 곳에 접근하여 데이터를 가져온다. 이때 데이터를 가져오면서 캐시에도 해당 데이터를 복사하거나 혹은 갱신한다. - 캐시에 원하는 데이터가 있으면 원본 데이터가 이쓴 공간에 접근하지 않고 캐시에서 바로 해당 데이터를 제공한다. (Cache hit) - 캐시 공간은 작으므로, 공간이 모자라게 되면 안 쓰는 데이터부터 삭제하여 공간을 확보한다.(Eviction)

💡
CPU의 캐시 메모리 - 한대의 CPU는 1초에 최고 수십억번 작동 가능 → 아무리 빠른 주기억 장치라도 CPU를 따라가기 어려움 → 그래서 SRAM이라는 특수한 메모리를 CPU에 넣어 캐시메모리로 사용 - 최근 출시된 AMD의 3세대 RYZEN은 L3 캐시 메모리의 용량을 기존의 2배로 늘려 게이밍 성능을 인텔 제품과 동등한 수준으로 끌어올림. → 이름 자체를 게임 캐시라 지음

💡
하드디스크, 데이터베이스 - 하드디스크는 주기억장치에 비해 10만배 이상 느린 장치 - 처리 효율을 올리려면 자주 쓰이는 데이터를 캐싱해주는 것이 좋다. - 데이터베이스 또한 쿼리를 실행하여 하드디스크에서 데이터를 읽고 쓰는 것은 시간이 오래 걸리는작업 - 대개 데이터베이스는 쓰기보다는 읽기가 있으므로 자주 요청받는 쿼리의 결과를 캐싱해두면 효율이 오른다. - 따라서 데이터베이스 자체에서 별도의 캐시를 운영한다. - JPA의 영속성 컨텍스트도 실은 캐시의 일종이다

💡
구글 유투브의 경우는 세계 각지에 통신사와 제휴하여 캐시 서버를 두어서 미국 서버까지 접근할 필요없이 국내 서버에서 처리하도록 하였다.

💡
웹 캐시 - 네트워크를 통해 데이터를 가져오는 것은 하드디스크보다 느릴 때가 있다. - 웹 브라우저는 웹 페이지에 접속 할 때 HTML, CSS, JavaScript, 이미지 등을 하드디스크나 메모리에 캐싱해 뒀다가 다음 번에 다시 접속할 떄 이를 재활용한다. - 웹 서버 또한 상당수의 경우 동적 웹 페이지라 할 지라도 매번 내용이 바뀌지 않는 경우가 더 많으므로, 서버에서 생성한 HTML을 캐싱해 뒀다가 다음 번 요청에 이를 재활용한다.(응답 캐시) - 이와 유사하게, 클라이언트에서 자주 요청받는 내용은 웹 서버로 전달하지 않고, 웹 서버 앞단의 프록시 서버에서 캐싱해둔 데이터를 바로 제공하기도 한다. (프록시 캐시)

💡
브라우저 캐시 - 웹 서버에서 클라이언트에 보내는 HTTP 헤더에 캐시 지시자를 삽입하면 클라이언트 웹 브라우저에서는 해당 지시자에 명시된 캐시 정책에 따라 캐싱을 실시한다. (각 파일별로 캐싱 정책이 달라져야 한다!) - 캐새의 유효 시간이 지나도 캐시된 제이터가 바뀌지 않은 경우를 확인하기 위해 ETag라는 유효성 검사 토큰을 사용한다. - 때로는 캐시 유효 시간을 최대한 길게 잡으면서도 정적 파일의 업데이트를 신속히 적용하기 위해 정적 파일의 이름 뒤에 별도의 토큰이나 버전 번호를 붙여야 하는 경우도 있다. - 캐시 정책은 해당 웹페이지의 전반적인 상황에 따라 각 파일마다 다르게 적용되어야 한다. 적어도 정적 파일과 동적인 부분의 브라우저 캐싱 정책은 달라야 한다. 비공개 정보가 담긴 페이지는 보안상 아예 캐싱을 막아야 할수 도 있다.

💡
Redis - 메모리 기반 오픈소스 NoSQL DBMS의 일종으로 웹 서비스에서 캐싱을 위해 유용함. - Redis라는 이름은 Remote Dictionary Server의 약자임 - 여기서 Dictionary는 Java의 HashMap<Key, Value>를 생각하면 된다. - 기본적으로 모든 데이터를 메모리에 저장하여 처리하므로 속도가 빠르다. - 서버 재부팅때 메모리의 데이터가 휘발되지 않게끔 데이터를 하드디스크에 기록 할 수 있다. - DBMS의 일종이므로, 명시적으로 삭제하지 않는 한 메모리에서 데이터를 삭제하지 않는다. - 자체적으로 여러가 지 자료형을 지원한다.

💡
EHcache → 자바에서 주로 쓰임 - Java의 표준 캐싱 API 명세인 JSR-107을 따르는 오픈소스 캐시 구현체 - Spring Framework나 Hibernate ORM 등에서 바로 사용 가능 - Java 진영에서 가장 널리 쓰임. - 캐시 저장공간을 속도에 다라 여러 등급으로 나누어 메모리 계츠 구조를 적용 가능! - 메모리에 캐시된 내용을 하드디스크에 기록 가능 - 대규모 서비스에서 캐시 서버 여럿을 클러스터로 묶을 수 있는 기능을 제공함!

출처

[10분 테코톡] 🐻큰곰의 Cache
💡 우아한테크코스의 크루들이 진행하는 10분 테코톡입니다. 💡'큰곰'이 캐시(Cache) 주제에 대해서 공유해주었습니다. 백엔드 프로그래밍을 하면서 성능을 위해 반드시 알아야 할 캐시에 대한 개념을 예제를 통해 위트있게 이야기해주었습니다 :) 발표에 사용된 슬라이드는 아래 링크...
https://youtu.be/c33ojJ7kE7M
메모리 계층 구조 - Register, Cache, Ram, HDD, SSD
1. register (32 bit , 64 bit) 레지스터는 CPU 안에 존재하는 저장 공간을 의미한다. 레지스터는 1bit의 정보를 저장할 수 있는 flip-flop의 집합이다. 레지스터는 데이터와 명령어를 저장하는 역할을 하며, 가장 빠른 속도로 접근 가능한 메모리이다.
https://m.blog.naver.com/sjc02183/221998493348
[번역] 웹 캐싱의 숨겨진 요소들
The hidden components of Web Caching 을 번역한 글입니다. 캐싱(Caching)은 애플리케이션의 처리 속도를 높여준다. 이미 가져온 데이터나 계산된 결과값의 복사본을 저장함으로써 처리 속도를 향상시키며, 이를 통해 향후 요청을 더 빠르게 처리할 수 있다. 대부분의 프로그램이 동일한 데이터나 명령어에 반복해서 엑세스하기 때문에 캐싱은 효율적인 아키텍처 패턴이다.
https://mingrammer.com/translation-the-hidden-components-of-web-caching/

반응형

'Project > Tech_review' 카테고리의 다른 글

빌드와 배포  (0) 2021.02.26
스프링 배치  (0) 2021.02.26