설계 고려 사항

오류 처리: 어떤 이유로든 캐시를 사용할 수 없게 되는 경우 애플리케이션은 모든 항목이 캐시 누락인 것처럼 진행해야 합니다. 캐시 계층의 존재로 인해 애플리케이션에 취약성이 추가되어서는 안 됩니다.

TTL: 모든 캐시 항목에 대해 단일 TTL 값을 구성하거나 항목에 따라 다른 TTL 값을 사용할 수 있습니다(예: , get_item query또는 scan 캐시). 음의 캐시 항목(항목을 반환하지 않은 요청)에 대해 다른 TTL 값을 가질 수도 있습니다.

사용된 용량: 캐시된 응답을 반환할 때 응답의 ConsumedCapacity 지표를 조정하여 읽기 소비가 0임을 나타내는 것이 좋습니다.

응답 메타데이터 제거: 응답에서 ResponseMetadata 섹션도 제거해야 합니다. 이렇게 하면 누군가가를 보고 실제로 몇 시간 전의 최신 상태라고 RequestId 생각할 위험을 피할 수 있습니다.

캐시 메타데이터 추가: 응답에 CacheMetadata 섹션을 추가하는 것이 좋습니다. 이 섹션에서는 값이 저장된 시간(부실성 측정에 유용)과 값을 저장한 클라이언트 라이브러리 및 버전(형식이 변경되는 한 버전에서 다른 버전으로 원활한 업그레이드를 수행할 때 유용할 수 있음)을 보고할 수 있습니다.

테이블 스키마 결정: 캐시 무효화를 위한 쓰기 작업에서 기본 키를 확인하려면 테이블의 스키마를 알아야 합니다. 각 테이블에 대해 처음 사용할 때(한 번만) ElastiCache에서 describe_table 호출 및 장기 캐시를 사용하여이 정보를 얻을 수 있습니다.

클라이언트를 구성하는 대신 수락: 생성자에서 DynamoDB 및 Redis 클라이언트 인스턴스를 수락하면(전달된 파라미터를 기반으로 심 내에 인스턴스를 빌드하는 대신) 생성자의 호출자가 설정 여부와 같은 세부 정보를 결정할 수 있다는 이점이 read_from_replicas=True 있습니다.

네임스페이스 기능: 생성자에서 모든 캐시 읽기 및 쓰기를 해당 네임스페이스에 격리하는 선택적 네임스페이스를 지원하는 것이 편리할 수 있습니다. 네임스페이스를 사용하는 것은 테스트에 이상적입니다. 네임스페이스가 다른 각 실행은 빈 캐시로 시작하는 것으로 보이며 이전 실행으로 인한 부작용이 없기 때문입니다. 네임스페이스를 변경하기만 하면 프로덕션 환경에서 전체 캐시 비우기를 시뮬레이션할 수도 있습니다. 이는 각 조회 키에 접두사를 자동으로 추가하여 구현할 수 있습니다.

스캔 캐싱: scan 호출을 캐싱해야 하는지 여부를 알기 어렵습니다. 일회성 전체 테이블 스캔을 수행할 때 캐시를 두 번째로 읽지 않을 스캔된 데이터의 큰 페이지로 채우지 않으려고 합니다. 반면, 많은 워크로드는 특히 작은 테이블에 대해 반복 스캔을 수행하여 여러 다운스트림 소비자에게 최신 전체 테이블 데이터를 제공합니다. 한 가지 타협은 두 번의 호출을 받고 각 호출이 동일한 서명(TL 기간 내)을 갖는 시스템을 구현하여 결과 스캔 응답을 캐시하는 것입니다. 이렇게 하면 긴밀한 스캔 루프를 활성화하여 캐싱의 이점을 얻는 동시에 일회성 전체 테이블 스캔 중에 캐시를 채우지 않아도 됩니다. 첫 번째 스캔은 캐시에 작은 자리 표시자를 넣어 요청이 한 번 수행된 것으로 표시합니다. 두 번째 스캔은 토큰 값을 최대 1MB 크기의 실제 페이로드로 대체합니다.