설계 고려 사항

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

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 크기의 실제 페이로드로 대체합니다.