오늘 우리는 캐싱의 세계로 뛰어들고 있습니다. 캐싱은 확장 가능한 고성능 시스템을 구축하기 위한 비밀 무기입니다. 캐싱에는 여러 유형이 있지만 이 문서에서는 백엔드 개체 캐싱(백엔드 캐싱)에 중점을 두겠습니다. 이를 마스터하면 고성능의 안정적인 소프트웨어를 구축하는 데 도움이 됩니다. 이 기사에서는 다음 사항을 살펴보겠습니다. 캐싱을 살펴보고 더 빠른 액세스를 위해 데이터를 임시로 저장하는 방법을 설명하겠습니다. 캐싱이란 무엇입니까? : 캐싱이 어떻게 속도를 높이고, 서버 로드를 줄이고, 사용자 경험을 개선하고, 비용도 절감할 수 있는지 알아보세요. 캐싱의 이점 : 이 섹션에서는 캐시를 사용하는 다양한 방법을 살펴보겠습니다. 각 접근 방식에는 장단점이 있으므로 필요에 맞는 올바른 패턴을 선택하십시오! 캐싱 패턴 : 이제 캐시된 데이터를 저장하고 검색하는 방법을 알았습니다. 하지만 캐시된 데이터를 최신 상태로 유지하려면 어떻게 해야 할까요? 캐시가 용량에 도달하면 어떻게 되나요? 캐싱 모범 사례 : 캐싱은 많은 이점을 제공하지만 피하는 것이 가장 좋은 경우도 있습니다. 잘못된 시스템에 캐싱을 구현하면 복잡성이 증가하고 잠재적으로 성능이 저하될 수도 있습니다. 캐시하지 않는 경우 캐싱이란 무엇입니까? 확장 가능한 고성능 애플리케이션을 만드는 것은 병목 현상을 제거하고 시스템을 더욱 효율적으로 만드는 것입니다. 데이터베이스는 저장 및 처리 요구 사항으로 인해 시스템 성능에 병목 현상을 일으키는 경우가 많습니다. 자주 확장해야 하기 때문에 비용이 많이 드는 구성 요소가 됩니다. 다행히도 데이터 검색 속도를 향상시키면서 데이터베이스 리소스 사용량을 줄이는 데 도움이 되는 구성 요소가 있습니다. 해당 구성 요소를 라고 합니다. 캐시 캐시는 데이터의 빠른 쓰기 및 읽기를 위해 설계된 임시 저장소입니다. 빠른 작업을 위해 대기 시간이 짧은 메모리 스토리지와 최적화된 데이터 구조를 사용합니다. 이미 Redis나 Memcached를 사용해 보셨거나 적어도 그들의 이름을 들어보셨을 것입니다. 이는 백엔드 서비스에 가장 널리 사용되는 분산 캐싱 시스템 중 두 가지입니다. Redis는 기본 데이터베이스 역할도 할 수 있지만 이는 다른 기사의 주제입니다! 캐싱의 이점 캐싱의 주요 이점은 속도입니다. 캐시에서 데이터를 읽는 것이 데이터베이스(예: SQL 또는 Mongo)에서 검색하는 것보다 훨씬 빠릅니다. 이러한 속도는 빠른 작업을 위해 사전(또는 HashMap) 데이터 구조를 사용하고 디스크 대신 고속 메모리에 데이터를 저장하는 캐시에서 비롯됩니다. 둘째, 캐싱은 데이터베이스의 로드를 줄여줍니다. 이를 통해 애플리케이션은 지속적으로 데이터베이스에 접속하는 대신 캐시에서 필요한 데이터를 얻을 수 있습니다. 이는 하드웨어 리소스 사용량을 크게 줄입니다. 디스크에서 데이터를 검색하는 대신 시스템은 단순히 빠른 메모리에서 해당 데이터에 액세스합니다. 이러한 이점은 사용자 경험을 직접적으로 향상시키고 비용 절감으로 이어질 수 있습니다. 귀하의 애플리케이션은 훨씬 빠르게 반응하여 사용자에게 더욱 원활하고 만족스러운 경험을 제공합니다. 캐싱을 사용하면 인프라 비용이 절감됩니다. Redis와 같은 분산 시스템에는 자체 리소스가 필요하지만 전체적인 절감 효과는 상당한 경우가 많습니다. 애플리케이션이 데이터에 보다 효율적으로 액세스하므로 잠재적으로 데이터베이스 규모를 축소할 수 있습니다. 그러나 여기에는 균형이 필요합니다. 캐시 시스템이 실패하는 경우 데이터베이스가 증가된 로드를 처리할 준비가 되어 있는지 확인하세요. 캐시 패턴 이제 캐싱의 강력한 기능을 이해했으므로 캐싱을 사용하는 가장 좋은 방법을 살펴보겠습니다. 이 섹션에서는 패턴의 두 가지 필수 범주인 과 살펴보겠습니다. 이러한 패턴은 캐시 업데이트를 관리하고 필요한 데이터가 아직 캐시에 없는 상황을 처리하기 위한 전략을 제공합니다. 캐시 쓰기 패턴 캐시 누락 패턴을 쓰기 패턴 쓰기 패턴은 애플리케이션이 캐시 및 데이터베이스와 상호 작용하는 방식을 결정합니다. 세 가지 일반적인 전략인 , 및 살펴보겠습니다. 각각은 고유한 장점과 장단점을 제공합니다. Write-back Write-through Write-around를 다시 쓰기 작동 방식: 애플리케이션은 캐시하고만 상호 작용합니다. 캐시는 쓰기를 즉시 확인합니다. 그러면 백그라운드 프로세스가 새로 작성된 데이터를 데이터베이스에 복사합니다. 속도가 중요하고 성능을 위해 일부 불일치가 허용되는 쓰기 작업이 많은 애플리케이션. 예로는 측정항목 및 분석 애플리케이션이 있습니다. 이상적인 대상: 장점: 데이터는 데이터베이스를 완전히 우회하여 빠른 액세스를 위해 항상 캐시에 있습니다. 더 빠른 읽기: 애플리케이션은 데이터베이스 쓰기를 기다리지 않으므로 응답 시간이 더 빨라집니다. 더 빠른 쓰기: 일괄 쓰기는 데이터베이스 로드를 줄이고 잠재적으로 데이터베이스 하드웨어의 수명을 연장할 수 있습니다. 데이터베이스 부담 감소: 단점: 데이터가 데이터베이스에 저장되기 전에 캐시에 오류가 발생하면 정보가 손실될 수 있습니다. Redis는 영구 스토리지를 통해 이러한 위험을 완화하지만 이로 인해 복잡성이 가중됩니다. 데이터 손실 위험: 캐시와 데이터베이스가 결국 동기화 상태를 유지하도록 하려면 미들웨어가 필요합니다. 복잡성 증가: 데이터를 자주 읽지 않더라도 모든 쓰기는 먼저 캐시로 이동합니다. 이로 인해 스토리지 소비가 높아질 수 있습니다. 높은 캐시 사용량 가능성: 쓰다 작동 방식: 애플리케이션은 캐시와 데이터베이스에 동시에 씁니다. 대기 시간을 줄이기 위해 캐시에 비동기적으로 쓸 수 있습니다. 이를 통해 애플리케이션은 캐시 작업이 완전히 완료되기 전에 성공적인 쓰기 신호를 보낼 수 있습니다. 장점: Write-Back과 마찬가지로 데이터는 항상 캐시에 있으므로 데이터베이스를 읽을 필요가 없습니다. 더 빠른 읽기: 애플리케이션은 데이터베이스에 저장된 후에만 쓰기를 확인하므로 직후에 충돌이 발생하더라도 데이터 지속성을 보장합니다. 신뢰성: 단점: 후기입에 비해 이 정책은 애플리케이션이 데이터베이스와 캐시 모두 쓰기를 기다리기 때문에 약간의 오버헤드가 있습니다. 비동기 쓰기는 이를 개선하지만 항상 데이터베이스 대기 시간이 있다는 점을 기억하십시오. 느린 쓰기: 모든 쓰기는 캐시로 이동하므로 데이터에 자주 액세스하지 않더라도 스토리지를 소비할 가능성이 있습니다. 높은 캐시 사용량: 주위에 쓰기 Write-Around를 사용하면 애플리케이션이 쓰기 프로세스 중에 캐시를 우회하여 데이터를 데이터베이스에 직접 씁니다. 캐시를 채우기 위해 이라는 전략을 사용합니다. 캐시 배제 패턴 애플리케이션이 캐시를 확인합니다. 읽기 요청 도착: 캐시에서 데이터를 찾을 수 없으면 애플리케이션은 해당 데이터를 데이터베이스에서 가져온 다음 나중에 사용할 수 있도록 캐시에 저장합니다. 캐시 누락: 장점: 데이터가 데이터베이스에 직접 기록되어 일관성이 보장됩니다. 안정적인 쓰기: 자주 액세스하는 데이터만 캐시되므로 메모리 소비가 줄어듭니다. 효율적인 캐시 사용: 단점: 데이터가 캐시에 없으면 애플리케이션은 데이터베이스에서 해당 데이터를 가져와야 하므로 캐시가 항상 미리 채워져 있는 정책에 비해 왕복 시간이 추가됩니다. 더 높은 읽기 대기 시간(일부 경우): 캐시 미스 패턴 캐시 누락은 애플리케이션에 필요한 데이터가 캐시에서 발견되지 않을 때 발생합니다. 이 문제를 해결하기 위한 두 가지 일반적인 전략은 다음과 같습니다. 캐시 제외 애플리케이션이 캐시를 확인합니다. 실수가 발생하면 데이터베이스에서 데이터를 가져온 다음 캐시를 업데이트합니다. 애플리케이션은 캐시 관리를 담당합니다. 요점: Cache-Aside 패턴을 사용한다는 것은 애플리케이션이 캐시를 관리한다는 것을 의미합니다. 이 접근 방식은 간단하고 애플리케이션 이외의 곳에서 개발이 필요하지 않기 때문에 가장 일반적으로 사용됩니다. 연속 읽기 애플리케이션은 캐시를 인식하지 못한 채 요청합니다. 특수 메커니즘은 캐시를 확인하고 필요한 경우 데이터베이스에서 데이터를 가져옵니다. 캐시는 투명하게 업데이트됩니다. 읽기 패턴은 애플리케이션 복잡성을 줄여주지만 인프라 복잡성을 증가시킵니다. 대신 애플리케이션 리소스를 미들웨어로 오프로드하는 데 도움이 됩니다. 전반적으로 캐시 배제를 사용한 write-around 패턴은 구현이 용이하기 때문에 가장 일반적으로 사용됩니다. 그러나 캐시된 후 즉시 사용할 데이터가 있는 경우 연속 쓰기 패턴도 포함하는 것이 좋습니다. 이는 읽기 성능에 약간의 이점을 제공합니다. 캐싱 모범 사례 이 섹션에서는 캐시 사용에 대한 모범 사례를 살펴보겠습니다. 이러한 관행을 따르면 캐시가 최신 데이터를 유지하고 스토리지를 효과적으로 관리할 수 있습니다. 캐시 무효화 캐시에 데이터를 저장한 다음 데이터베이스가 업데이트된다고 가정해 보세요. 이로 인해 캐시의 데이터가 데이터베이스 버전과 달라집니다. 이러한 유형의 캐시 데이터를 "부실"이라고 부릅니다. 캐시 무효화 기술이 없으면 데이터베이스 업데이트 후에도 캐시된 데이터가 오래된 상태로 유지될 수 있습니다. 데이터를 최신 상태로 유지하려면 다음 기술을 사용할 수 있습니다. 데이터베이스의 데이터를 업데이트할 때 해당 캐시 항목도 업데이트됩니다. Write-through 및 Write-back 패턴은 본질적으로 이를 처리하지만 write around/cache-aside에는 캐시된 데이터를 명시적으로 삭제해야 합니다. 이 전략은 애플리케이션이 오래된 데이터를 검색하는 것을 방지합니다. 업데이트 시 캐시 무효화: TTL은 캐시에 데이터를 저장할 때 설정할 수 있는 정책입니다. TTL을 사용하면 지정된 시간이 지나면 데이터가 자동으로 삭제됩니다. 이는 사용되지 않는 데이터를 지우는 데 도움이 되며 무효화가 누락된 경우 오래된 데이터에 대한 안전 장치를 제공합니다. TTL(Time To Live): 캐시 교체 정책 많은 양의 데이터를 캐시하면 캐시 저장 공간이 가득 찰 수 있습니다. 캐시 시스템은 일반적으로 기본 데이터베이스 스토리지보다 작은 메모리를 사용합니다. 캐시가 가득 차면 공간을 확보하기 위해 일부 데이터를 삭제해야 합니다. 캐시 교체 정책에 따라 제거할 데이터가 결정됩니다. 이 공통 정책은 가장 오랫동안 사용(읽기 또는 쓰기)되지 않은 데이터를 제거합니다. LRU는 대부분의 실제 사용 사례에 적합합니다. LRU(Least Recent Used): LRU와 유사하지만 액세스 빈도에 중점을 둡니다. 새로 작성된 데이터는 삭제될 수 있으므로 데이터를 삭제할 수 없는 준비 기간을 추가하는 것이 좋습니다. LFU(최소 자주 사용): FIFO(선입선출), 무작위 교체 등과 같은 다른 교체 정책이 존재하지만 덜 일반적입니다. 캐시하지 않을 때 캐시 구현을 시작하기 전에 캐시 구현이 가장 적합 수 있는 시기를 아는 것이 중요합니다. 캐싱은 속도를 향상시키고 데이터베이스 로드를 줄이는 경우가 많지만 다음과 같은 경우에는 의미가 없을 수 있습니다. 하지 않을 애플리케이션의 트래픽이 낮고 응답 시간이 여전히 허용 가능한 경우 아직 캐싱이 필요하지 않을 가능성이 높습니다. 캐시를 추가하면 복잡성이 증가하므로 성능 병목 현상이 발생하거나 트래픽이 크게 증가할 것으로 예상되는 경우 구현하는 것이 가장 좋습니다. 낮은 트래픽: 캐싱은 읽기가 많은 애플리케이션에 가장 유용합니다. 이는 데이터베이스의 데이터가 자주 업데이트되지 않거나 업데이트 사이에 여러 번 읽힌다는 것을 의미합니다. 애플리케이션에 쓰기량이 많은 경우 캐싱으로 인해 잠재적으로 오버헤드가 추가되고 속도가 느려질 수 있습니다. 쓰기가 많은 시스템: 테이크아웃 이 기사에서는 캐싱의 기본 사항과 이를 효과적으로 사용하는 방법을 다루었습니다. 주요 내용을 요약하면 다음과 같습니다. 시스템이 읽기 중심이고 대기 시간 감소 캐싱 기능이 필요한지 확인하십시오. 필요성 확인: 애플리케이션이 데이터를 사용하는 방식에 맞는 캐시 쓰기 및 캐시 부적중 패턴을 선택하십시오. 패턴을 현명하게 선택하십시오. 오래된 데이터 제공을 방지하기 위해 캐시 무효화 전략을 구현합니다. 데이터 신선도: 캐시가 용량에 도달하면 삭제를 처리하는 캐시 교체 정책(예: LRU)을 선택합니다. 교체 정책 관리: 참고자료 https://gist.github.com/jboner/2841832 https://www.byteizedpieces.com/posts/cache-types https://www.techtarget.com/searchstorage/definition/cache https://www.youtube.com/watch?v=dGAgxozNWFE
