캐시란 무엇입니까?

모든 소스에서 데이터를 요청할 때 항상 약간의 지연이 있습니다. 웹 서버에 대한 핑은 밀리초 단위로 측정되며, 스토리지 액세스 시간은 마이크로초 단위로 대기 시간이 있을 수 있으며 RAM 대기 시간은 CPU 클록 주기로 측정됩니다. 물론 이러한 종류의 속도는 불과 수십 년 전만 해도 상상조차 할 수 없었지만 현재에는 결코 충분히 빠르지 않습니다. 액세스 속도는 일반적으로 어떤 형태의 성능 병목 현상입니다. 이를 해결할 수 있는 방법 중 하나는 캐싱입니다.

캐싱은 평소보다 빠르게 액세스할 수 있는 방식으로 리소스의 임시 복사본을 저장하는 프로세스입니다. 소프트웨어와 하드웨어 모두에서 광범위한 구현이 있습니다. 캐시는 읽기 캐시, 쓰기 캐시 또는 둘 다의 역할을 할 수 있습니다.

캐시 읽기

읽기 캐시에서 이전에 요청된 데이터는 빠른 액세스를 위해 캐시에 저장됩니다. 일부 시나리오에서는 캐시가 선제적으로 데이터로 로드되어 후속 요청이 아닌 첫 번째 요청이 캐시에서 제공되도록 할 수도 있습니다.

가장 친숙한 읽기 캐시는 브라우저 캐시입니다. 여기에서 브라우저는 요청된 리소스의 로컬 복사본을 저장합니다. 즉, 웹 페이지가 다시 로드되거나 동일한 콘텐츠를 많이 사용하는 유사한 페이지가 로드되면 해당 콘텐츠는 웹 서버가 아닌 캐시에서 제공될 수 있습니다. 이것은 웹 페이지가 더 빨리 로드될 수 있음을 의미할 뿐만 아니라 웹 서버의 로드를 줄이고 사용자가 다운로드해야 하는 데이터의 양을 줄여서 측정 연결에서 중요할 수 있습니다.

RAM 자체도 하드 드라이브의 데이터에 대한 읽기 캐시 역할을 합니다. 이 경우 실행 중인 프로그램의 데이터는 CPU가 더 빠르게 액세스할 수 있도록 RAM에 선제적으로 로드됩니다. 그런 다음 RAM의 데이터는 CPU 캐시에 추가로 캐시되지만 CPU 캐시는 기가바이트가 아닌 메가바이트 단위로 측정되기 때문에 이를 위한 프로세스가 훨씬 더 복잡합니다.

쓰기 캐시

쓰기 캐시는 더 느린 장치에 기록되는 데이터를 흡수할 수 있는 캐시입니다. 이에 대한 일반적인 예는 최신 SSD의 SLC 캐시입니다. 이 캐시는 데이터를 더 빨리 읽을 수는 없지만 나머지 SSD를 구성하는 TLC 또는 QLC 플래시에 쓰는 것보다 쓰는 것이 훨씬 빠릅니다. SLC 캐시는 고속 쓰기 작업을 흡수한 다음 가능한 한 빨리 해당 데이터를 훨씬 더 나은 스토리지 밀도를 제공하지만 쓰기 속도가 훨씬 느린 TLC 플래시로 오프로드할 수 있습니다. 이러한 방식으로 플래시 메모리를 사용하면 빠른 쓰기 속도와 높은 저장 밀도 모두에 최적화됩니다.

하이브리드 캐시

읽기 및 쓰기 캐시 역할을 모두 수행할 수 있도록 캐시를 처리하는 방법에는 여러 가지가 있습니다. 이러한 각 방법은 쓰기 작업을 다르게 처리하며 장점과 단점이 있습니다. 세 가지 옵션은 write-around, write-through 및 write-back입니다. write-around 캐시는 쓸 때 캐시를 완전히 건너뛰고 write-through 캐시는 캐시에 쓰지만 스토리지에 쓰여질 때만 작업이 완료된 것으로 간주합니다. 후기입 캐시는 캐시에 쓴 다음 작업이 완료된 것으로 간주하여 필요한 경우 캐시를 사용하여 스토리지로 전송합니다.

Write-around는 캐시 변동을 최소화하므로 많은 양의 쓰기가 예상되는 경우에 유용할 수 있습니다. 그러나 이는 기록된 데이터를 읽는 작업이 처음에 적어도 하나의 캐시 미스가 발생한다는 것을 의미합니다. Write-through 캐시는 쓰기 작업을 즉시 캐시하므로 결과가 처음 요청될 때 캐시에서 제공될 수 있습니다. 하지만 완전한 것으로 간주되려면 쓰기 작업에서 디스크에도 데이터를 써야 하므로 대기 시간이 추가됩니다. 후기입 캐시는 후기입과 동일한 이점이 있으므로 작성된 데이터를 캐시에서 즉시 제공할 수 있습니다. 그래도 완료된 것으로 간주하기 위해 디스크에 쓰기 위해 쓰기 작업이 필요하지 않습니다. 이렇게 하면 쓰기 대기 시간이 줄어들지만 캐시가 휘발성인 경우 데이터 손실 위험이 있으며 전원이 끊기기 전에 스토리지에 데이터 쓰기가 완료되지 않습니다.

캐시에서 데이터를 제거하는 방법은 무엇입니까?

모든 캐시의 제한 요소 중 하나는 용량입니다. 캐시가 크면 검색하는 데 오랜 시간이 걸리므로 애초에 캐시를 사용하는 이점이 상당 부분 무효화됩니다. 캐싱에 사용되는 메모리 기술은 캐싱하는 메모리보다 더 비싼 경향이 있습니다. 그렇지 않은 경우 메모리 계층이 성능 향상을 위해 메모리 기술을 전환했을 가능성이 높습니다. 이 두 가지 요인은 캐시가 상대적으로 작은 경향이 있음을 의미하며, 특히 캐시가 저장되는 저장 매체와 비교할 때 더욱 그렇습니다. RAM은 스토리지보다 용량이 적고 CPU 캐시는 RAM보다 용량이 적습니다. SLC 캐시는 TLC 메모리보다 용량이 적습니다.

이 모든 것은 캐시해야 하는 새 데이터를 위한 공간을 확보하기 위해 캐시에서 데이터를 순환해야 하는 경우가 많다는 것을 의미합니다. 이에 대한 다양한 접근 방식이 있습니다. "가장 적게 사용됨"은 액세스 횟수가 가장 적은 캐시 항목을 제거하는 것을 선호합니다. 이것은 어떤 항목이 향후 캐시 미스에 가장 적은 영향을 미칠지 예측하는 데 유용할 수 있지만 매우 최근에 추가된 항목이 적은 수의 액세스를 가진 것으로 계산하여 캐시 변동으로 이어질 수 있습니다.

"최소 최근 사용"은 한동안 사용되지 않은 캐시 항목을 제거하는 것을 선호합니다. 이것은 현재 사용되고 있지 않다고 가정하지만 얼마 전에 많이 사용되었는지는 고려하지 않습니다. "가장 최근에 사용됨"은 가장 최근에 사용된 캐시 항목을 제거하는 것을 선호하며 캐시 항목이 사용되었고 다시 사용할 필요가 없다고 가정합니다. 가장 좋은 접근 방식은 일반적으로 사용 통계를 통해 알 수 있는 세 가지를 모두 조합하는 것입니다.

오래된 정보 및 보안 위험

캐시의 주요 위험은 캐시에 포함된 정보가 오래될 수 있다��� 것입니다. 원래 데이터가 업데이트되어 캐시 항목이 오래된 경우 캐시 항목이 오래된 것으로 간주됩니다. 제공되는 Live Copy가 여전히 캐시된 복사본과 일치하는지 정기적으로 확인하는 것이 중요합니다.

특히 웹 사이트에서는 캐시할 수 있는 데이터와 캐시할 수 없는 데이터를 식별하는 것도 매우 중요합니다. 예를 들어, 변경되지 않는 큰 JavaScript 파일을 캐시해도 괜찮습니다. 이렇게 하면 사용자가 매번 다운로드하지 않아도 되며 동일한 캐시에서 제공되는 다른 사용자에게도 도움이 될 수 있습니다. 그러나 세션별 데이터는 캐시할 수 없습니다. 자신으로 로그인한 상태에서 메시징 앱을 탐색했는데 다른 사용자의 메시지가 캐시된 버전으로 제공되었다는 사실을 알게 된다면 어떤 일이 벌어질지 상상해 보십시오. 고맙게도 웹 서버는 어떤 리소스를 캐시할 수 있고 없는지 지정할 수 있으며 이러한 문제는 일반적으로 잘 알려져 있으므로 이와 같은 문제는 거의 없습니다.

결론

캐시는 정상적인 데이터 액세스 프로세스를 다시 완료하는 것보다 액세스가 더 빠른 저장 방법에 최근에 사용된 일부 데이터를 저장할 수 있는 메모리의 일부입니다. 캐시는 일반적으로 용량이 제한되어 있으므로 가득 차면 항목을 제거해야 합니다. 캐시는 일반적으로 사용자에게 투명합니다. 즉, 대기 시간은 결과가 캐시를 통해 제공되었음을 나타내는 유일한 표시입니다.