Caching: the single most helpful strategy for improving app performances

시스템 아키텍처에서 캐싱은 자주 액세스하는 데이터를 더 빠르고 쉽게 액세스할 수 있는 위치에 저장합니다. 이 기술을 사용하면 매번 원래의 잠재적으로 느린 소스를 건드리지 않고 빠르게 검색할 수 있습니다. 핵심 이점은 향상된 성능과 효율성 입니다 . 캐싱은 자주 액세스하는 데이터의 복사본을 쉽게 액세스할 수 있는 위치에 저장하여 액세스 시간을 줄이고 기본 데이터 소스를 오프로드합니다. 캐싱은 모든 구성 요소가 긴밀하게 통합되어 단일 서비스로 실행되는 모놀리식 시스템에서 특히 중요하며 캐싱은 성능과 확장성을 향상시키는 데 중요한 역할을 합니다. 캐싱 캐싱의 장점은 다음과 같습니다. 대기 시간 감소: 자주 사용하는 데이터를 가까이에 유지함으로써 캐시는 해당 데이터에 액세스하는 데 걸리는 시간을 크게 줄여 결과적으로 더 빠르고 응답성이 뛰어난 사용자 경험을 제공합니다. 낮은 부하: 캐싱은 빈번한 요청을 처리함으로써 원본 데이터 원본(데이터베이스, 서버)에 대한 부담을 줄입니다. 이를 통해 다른 작업을 위한 리소스를 확보하고 전반적인 시스템 확장성을 향상시킵니다. 향상된 확장성: 잘 설계된 캐시는 원래 데이터 소스보다 더 많은 요청을 처리할 수 있으므로 시스템 확장성이 향상됩니다. 캐싱의 일상적인 사용 사례는 다음 과 같습니다. 자주 액세스되는 데이터: 사용자 또는 애플리케이션이 반복적으로 액세스하는 모든 데이터는 캐싱의 주요 후보입니다. 캐시 읽기는 API 호출보다 훨씬 빠르므로 데이터베이스 쿼리만 캐시하지 마세요. 읽기가 많은 워크로드: 쓰기에 비해 읽기 볼륨이 높은 시스템은 캐싱의 이점을 가장 많이 얻습니다. 캐시는 읽기 요청의 정면을 흡수하여 기본 데이터 소스의 로드를 최소화합니다. 네트워크 트래픽 감소: 캐싱은 데이터가 원격 서버에 상주하는 분산 시스템에서 특히 유용할 수 있습니다. 로컬 복사본을 저장하면 잦은 네트워크 호출을 방지하고 특히 지리적으로 분산된 사용자의 성능을 향상시킬 수 있습니다. 성능이 중요함: 캐싱은 짧은 대기 시간과 높은 처리량이 중요한 시나리오에서 성능을 크게 향상시킬 수 있습니다. 하지만 무언가를 캐시하는 방법을 어떻게 결정합니까? 캐시를 추가하면 비용이 발생하므로 각 후보에 대해 다음을 평가 해야 합니다 . 캐시에 도달하는 것이 더 빠르나요? 보관할 가치가 있나요? 얼마나 자주 검증해야 합니까? 캐시 항목당 몇 번의 적중률을 얻게 됩니까? 로컬 캐시인가요 아니면 공유 캐시인가요? 하지만 캐시된 데이터는 오래되었으므로 부적절할 수 있는 상황이 있을 수 있습니다. 캐싱 전략 캐싱을 사용하면 자주 액세스하는 데이터 읽기가 향상되지만 캐시를 채우고 업데이트하는 것은 쉽지 않습니다. 이에 대해 우리는 다음과 같은 전략을 가지고 있습니다. 읽기 전략 읽기 전략에는 다음과 같은 두 가지 주요 전략이 있습니다. 1. 캐시 배제 애플리케이션은 캐시에서 데이터 저장 및 검색을 수동으로 관리합니다. 캐시 누락이 발생하면 기본 스토리지에서 데이터를 가져온 다음 캐시에 추가합니다. 캐시 누락이 드물고 DB 읽기가 허용될 때 사용해야 합니다. 장점: 구현이 더 간단해졌습니다. 애플리케이션 로직이 캐시 업데이트를 처리합니다. 캐시된 내용을 더욱 세부적으로 제어할 수 있습니다. 캐시는 적극적으로 요청된 데이터만 보유합니다. 단점: 캐시 누락 시 추가 데이터베이스 액세스(3회 왕복 가능) 캐시를 통해 원본이 업데이트되지 않으면 데이터가 오래될 수 있습니다. 2. 읽어보기 캐시 누락이 발생하면 캐시는 자동으로 기본 스토리지에서 데이터를 로드합니다. 이는 캐시 누락을 내부적으로 처리하여 데이터 검색을 단순화합니다. 우리는 이를 애플리케이션 코드에서 DB 로직을 추상화하는 데 사용합니다. 장점: 더 간단한 애플리케이션 코드, 캐시가 데이터 검색을 처리합니다. 데이터 일관성을 보장합니다(캐시와 원본은 항상 동일함). 단점: 읽기 시 더 많은 데이터베이스 로드(캐시는 매번 적중되지 않을 수 있으며 불필요한 데이터베이스 액세스). 캐시와 원본의 복잡성 증가로 인해 데이터 형식이 달라집니다(데이터 변환이 필요할 수 있음). 쓰기 전략 다음과 같은 세 가지 주요 글쓰기 전략이 있습니다. 1. 주위에 쓰기 데이터는 캐시를 우회하여 기본 스토리지에 직접 기록됩니다. 이 전략은 쓰기가 빈번하고 읽기가 덜 일반적인 경우에 효과적입니다. 기록된 데이터를 캐시에서 즉시 읽을 필요가 없을 때 사용해야 합니다. 장점: 유일한 캐시가 업데이트되므로 쓰기 속도가 가장 빠릅니다(오리진의 로드 감소). 데이터베이스는 항상 최신 상태이며 단일 정보 소스 역할을 합니다. 단점: 데이터가 불일치하게 됩니다(캐시는 원본에 반영되지 않은 데이터를 보유합니다). 데이터 발산(캐시의 오래된 데이터) 위험이 높기 때문에 거의 사용되지 않습니다. 2. 후기입 데이터는 먼저 캐시에 기록되고 나중에 기본 스토리지와 동기화됩니다. 이렇게 하면 쓰기 작업 수가 줄어들지만 동기화 전에 재고가 실패하면 데이터가 손실될 위험이 있습니다. 약간의 데이터 손실이 허용되는 쓰기 작업이 많은 장소에서 사용해야 합니다. 장점 : 캐시 업데이트가 원본에서 분리되어 쓰기 속도가 빨라집니다(쓰기 성능 향상). 쓰기에 대한 원본 데이터베이스의 부하를 줄입니다. 단점 : 오류 발생 시 잠재적인 데이터 불일치(데이터는 캐시에 있지만 원본에는 없을 수 있음) 재시도를 처리하고 최종 일관성을 보장하려면 추가 논리가 필요합니다(데이터는 결국 원본에 기록됩니다). 3. 연속 기입 데이터는 캐시와 기본 스토리지 모두에 동시에 기록되므로 일관성이 보장되지만 쓰기 대기 시간이 늘어날 수 있습니다. 이는 데이터 무결성이 중요한 시나리오에 이상적입니다. 장점 : 데이터 일관성을 보장합니다(캐시와 원본은 항상 동일함). 구현이 더 간단해지고 업데이트도 함께 이루어집니다. 단점 : 이중 업데이트(캐시 및 원본)로 인해 쓰기 속도가 느려집니다. 쓰기에 대한 원본 데이터베이스의 부하가 증가했습니다(병목 현상이 발생할 수 있음). 캐시 전략 이 외에도 캐시 시스템에는 다음과 같은 문제가 발생할 수 있습니다. Thundering Herd 문제. 캐시가 만료되면 수많은 요청이 동시에 백엔드에 쏟아져 압도됩니다. 시차적 캐시 만료를 구현하고 잠금 또는 메시지 대기열을 사용하여 요청 흐름을 관리함으로써 이 문제를 해결할 수 있습니다. 이렇게 하면 과부하를 방지하고 원활한 백엔드 작업이 보장됩니다. 또한 모든 캐시 키가 동시에 만료되도록 설정해서는 안 됩니다. 부하를 분산시키기 위해 약간의 임의성을 추가합니다. 캐시 분석. 집중적인 로드 중에는 캐시에 오류가 발생하여 모든 트래픽이 데이터베이스로 전달되고 성능 병목 현상이 발생합니다. 최적의 캐시 만료 시간을 설정하고, 속도 제한을 사용하고, 계층 캐싱 메커니즘(예: 인메모리 및 분산 캐시)을 사용하여 로드를 분산하고 백엔드를 보호함으로써 이 문제를 해결할 수 있습니다. 캐시 충돌. 캐싱 서비스가 충돌하여 캐시된 데이터가 완전히 손실되고 데이터베이스 쿼리가 직접 수행됩니다. 이를 해결하기 위해 정기적인 백업과 보조 장애 조치 캐시를 갖춘 탄력적인 캐싱 아키텍처(캐시 클러스터)를 설계하여 연속성과 성능 안정성을 보장할 수 있습니다. 회로 차단기 메커니즘을 구현할 수도 있습니다. 캐시가 반복적으로 실패하면 애플리케이션은 데이터베이스 과부하를 방지하기 위해 일시적으로 캐시를 우회합니다. 캐시 침투는 존재하지 않는 데이터에 대한 쿼리가 캐시를 우회하여 데이터베이스 부하를 불필요하게 증가시킬 때 발생합니다. 모든 데이터 요청이 캐시를 먼저 확인하는 캐시 배제 패턴을 채택하여 이 문제를 해결할 수 있습니다. 우리는 누락된 데이터를 효율적으로 처리하고 불필요한 데이터베이스 적중을 줄이기 위해 네거티브 캐싱을 사용합니다. 또한 캐시에 존재하지 않는 키에 대한 자리 표시자(예: "null")를 저장하여 불필요한 데이터베이스 쿼리를 방지할 수 있습니다.