랄프 왈도 에머슨(Ralph Waldo Emerson)의 말을 믿는다면 어리석은 일관성은 어리석은 생각의 도깨비일 수 있지만 확장 가능하고 성공적인 엔터프라이즈 수준 캐싱 전략을 구현하는 경우 일관성에 대해 어리석은 것은 없습니다. 실제로 엔터프라이즈 데이터베이스 운영 관리의 가장 큰 문제 중 하나는 캐시 일관성을 유지하는 것입니다.
처음에 캐시에 신경을 쓰는 이유는 무엇입니까? 엔터프라이즈 캐시의 주요 이점은 데이터에 액세스할 수 있는 속도와 효율성입니다. 기본 데이터베이스에 대한 각 호출은 시간과 처리 능력 면에서 비용이 많이 들 수 있지만 캐시에 대한 호출은 번개처럼 빠르며 기본 데이터베이스에 영향을 미치지 않습니다.
캐시 일관성에 대한 세 가지 장애물
물론 이러한 이점은 캐시(또는 캐시)의 데이터가 항상 원본 데이터와 동일한 값을 유지한다는 기본적인 가정에 기반합니다. 이것은 단순한 목표처럼 보일 수 있지만 실제로는 이론상 더 쉽습니다. 사실, 이를 탈선시킬 수 있는 세 가지 함정이 있습니다.
1. 기본 데이터베이스의 변경 사항이 캐시에 반영되지 않는 경우
캐시를 통해 데이터에 액세스하는 것은 기본 데이터베이스를 통해 데이터에 액세스하는 것보다 기본적으로 빠르기 때문에 특정 항목이 요청되면 캐시가 먼저 참조됩니다. 항목이 캐시에 있다고 가정하면 기본 데이터베이스에서보다 훨씬 빠르게 반환됩니다. 이 전략을 캐시 제외 패턴이라고 합니다. . 기본적으로 캐시가 먼저 확인됩니다. 데이터가 캐시에 없으면 애플리케이션은 기본 데이터베이스를 쿼리하고 사용자에게 돌아오는 도중에 결과를 캐시에 저장합니다.
문제는 기본 데이터베이스의 데이터가 변경되는 시점과 해당 변경 사항을 반영하도록 캐시가 조정되는 시점 사이의 간격 동안 발생합니다. 이는 애플리케이션이 캐시를 확인하는 빈도에 영향을 받습니다. 그러나 각 검사에는 프로세서 리소스 비용이 발생합니다. 동일한 프로세서가 동시에 수많은 다른 기능이나 트랜잭션을 처리할 수 있으며 그 중 일부는 캐시 업데이트보다 중요하지는 않지만 중요합니다.
문제는 업데이트를 너무 자주 확인하거나 충분하지 않은 것 사이에 있는 일종의 Goldilocks 영역인 스위트 스팟을 찾는 데 있습니다. 물론 사용자가 이 간격 동안 사용되지 않는 데이터에 액세스하려고 하면 해당 도박은 손실됩니다.
2. 캐시된 결과 업데이트가 지연되는 경우
이 문제는 이전 문제와 약간 겹칩니다. 기본 데이터베이스에서 값이 업데이트될 때마다 변경된 값을 업데이트하거나 완전히 제거하도록 지시하는 메시지가 캐시로 전송됩니다. (후자의 경우 다음에 값을 요청하면 기본 데이터베이스에서 액세스한 다음 캐시에서 액세스합니다.) 일반적인 상황에서 이 통신은 비교적 빠르게 발생하며 캐시된 항목은 순서대로 업데이트되거나 제거됩니다. 캐시 일관성을 유지하기 위해
그러나 다시 한 번 이 변경에는 처리 능력이 필요하고 시간이 걸립니다. 지연은 사용 가능한 처리 속도와 네트워크 처리량 모두에 영향을 받을 수 있습니다. 사용자가 캐시를 업데이트하기 위해 서버에서 메시지를 보낸 시간과 캐시에서 해당 메시지를 수신하고 조치를 취한 시간 사이에 쓸모 없는 데이터에 액세스하도록 선택하는 불행이 있는 경우 결과는 쓸모 없는 데이터가 될 수 있습니다. , 부정확하거나 둘 다입니다.
3. 캐시된 노드 간에 불일치가 있는 경우
물론 웹사이트나 애플리케이션이 클수록 캐시가 하나가 아닌 여러 노드에 저장될 가능성이 더 큽니다. 기본 외에도 노드에는 복제본이 여러 개 있을 수 있습니다. 이상적으로는 동일한 데이터를 저장하는 노드입니다. 로드 밸런싱 및 성능의 관점에서 이것은 종종 의미가 있습니다.
그러나 데이터 무결성의 관점에서 보면 캐시 불일치의 또 다른 잠재적 원인이 됩니다. 기본 데이터베이스에서 데이터가 업데이트될 때마다 이 변경 사항이 모든 복제본에도 반영되어야 합니다. 이러한 노드의 지리적 위치와 노드 수에 따라 업데이트 프로세스에 상당한 시간이 소요될 수 있습니다. 업데이트 프로세스가 진행 중일 수 있지만 사용자가 아직 변경 사항이 적용되지 않은 노드에 액세스할 가능성이 있습니다. 다시 한번 말하지만 결과는 캐시 불일치일 수 있습니다.
캐시 불일치 비용
캐시된 데이터베이스의 모든 이점에 대해 캐시 불일치 가능성이 가장 눈에 띄는 단점일 것입니다. 그러나 문제가 얼마나 큰가? 궁극적으로 캐시 불일치 비용은 컨텍스트에 따라 다릅니다.
일부 캐시 불일치는 큰 결과 없이 발생할 수 있습니다. 예를 들어 캐시의 총 "좋아요"가 기본 데이터베이스의 실제 총계와 일시적으로 동기화되지 않은 경우 짧은 불일치가 문제를 일으키거나 알아차리지 못할 것입니다.
반면에 캐시에 특정 제품의 남은 품목 중 하나가 아직 재고가 있다고 나열되어 있지만 기본 데이터베이스의 실제 재고에는 아무 것도 남지 않았다고 표시되어 있으면 충돌로 인해 고객이 혼란스러워지고 소외되어 브랜드 평판이 손상될 수 있습니다. 신뢰성을 위해 회사의 거래 및 회계를 혼란에 빠뜨리고 극단적인 경우 법적 위험에 빠뜨릴 수도 있습니다.
불일치에 대응하는 세 가지 방법
운 좋게도 위의 캐시 불일치의 잠재적 원인 각각에 대해 해당하는 수의 솔루션이 있습니다.
1. 캐시 무효화
캐시 무효화를 사용하면 기본 데이터베이스에서 값이 업데이트될 때마다 해당 키가 있는 각 캐시 항목이 캐시에서 자동으로 삭제됩니다. 캐시 무효화는 "무차별 대입 방식"으로 볼 수 있지만 두 개 이상이 아닌 기본 데이터베이스 자체에 한 번만 비용이 많이 들고 시간이 많이 소요되는 쓰기 작업이 필요하다는 장점이 있습니다.
2. 연속 기입 캐싱
이 경우 연속 기입 전략을 사용하여 기본 데이터베이스를 업데이트하고 캐시를 제거하는 대신 응용 프로그램이 캐시를 업데이트한 다음 캐시가 기본 데이터베이스를 동기적으로 업데이트합니다. 즉, 업데이트를 시작하기 위해 기본 데이터베이스에 의존하는 대신 캐시는 자체 일관성을 유지하고 기본 데이터베이스에 변경 사항을 전달하는 역할을 합니다.
3. 후기 작성 캐싱
불행히도 두 번 쓰기가 실제로 잘못될 수 있는 경우가 있습니다. 연속 기입 캐시 전략의 단점 중 하나는 캐시와 기본 데이터베이스를 모두 업데이트하려면 먼저 캐시를 변경한 다음 기본 데이터베이스를 변경하는 데 시간이 많이 걸리고 프로세서를 많이 사용하는 변경이 필요하다는 것입니다.
비하인드 쓰기라고 하는 또 다른 전략 , 처음에는 캐시만 업데이트한 다음 나중에 기본 데이터베이스를 업데이트하여 이 문제를 방지합니다. 물론 기본 데이터베이스도 업데이트해야 하고 빠르면 빠를수록 좋지만 이 경우 사용자는 두 쓰기의 "비용"을 지불할 필요가 없습니다. 기본 데이터베이스에 대한 두 번째 쓰기는 성능을 저하시킬 가능성이 적은 시간에 비동기식으로 뒤에서(따라서 이름, write-behind) 발생합니다.
Redis Enterprise를 구출
캐시 무효화 외에도 연속 기입 및 기입 비하인드 캐싱은 캐시 일관성을 달성하는 데 도움이 되는 많은 시나리오를 해결할 수 있습니다. 그러나 문제에 대한 답을 찾는 것은 그것을 실행하는 것과는 다릅니다.
Redis Enterprise의 활성-활성 지역 복제는 다중 기본을 허용하고 점점 더 무거워지는 로드를 능숙하게 처리할 수 있도록 합니다. 활성-활성이라는 이름은 데이터베이스의 각 인스턴스가 모든 키에 대한 읽기 및 쓰기 작업을 모두 허용할 수 있다는 사실을 나타냅니다. 각 데이터베이스 인스턴스는 멀리 떨어져 있더라도 네트워크의 피어입니다. 즉, 어떤 인스턴스에 쓰기가 발생하면 해당 노드가 자동으로 네트워크의 다른 모든 인스턴스에 메시지를 보내 캐시의 내용이 변경되었음을 알리고 모든 인스턴스가 캐시된 데이터의 일관된 세트를 유지하도록 합니다.
Redis Enterprise의 고유한 활성-활성 지역 중복은 캐시 불일치로 이어질 수 있는 잠재적인 쓰기 충돌을 처리하도록 설계된 정교한 알고리즘을 사용합니다. 이러한 알고리즘은 충돌 없는 복제 데이터 유형(CRDT)을 기반으로 하므로 일관성을 효과적으로 유지하는 방식으로 여러 복제본의 쓰기를 병합할 수 있습니다.
홉고블린 만세!
캐시 일관성을 유지하는 문제는 아키텍처가 성장함에 따라 더욱 복잡해지고 더욱 중요해지기 때문에 비즈니스에 필요하고 고객이 기대하는 일관성을 안정적으로 제공하려면 엔터프라이즈 수준의 캐싱 솔루션이 필요합니다.
일관성은 Emerson에 관한 한 헛된 문제였을 수 있지만 엔터프라이즈 수준 데이터베이스 캐싱에 관해서는 절대적으로 중요합니다. 그렇기 때문에 Redis Enterprise를 선택하는 것이 현명합니다. 그렇게 하지 않는 것은 어리석은 일입니다.
캐싱의 전체 스토리를 확인하세요. Redis를 사용한 대규모 캐싱 읽기 , 리 애치슨 작성.