Amazon DynamoDB 테이블의 높은 지연 시간 문제를 해결하려면 어떻게 해야 합니까?
Amazon DynamoDB 요청에 대한 응답 시간이 길어졌지만 그 이유를 모르겠습니다.
간략한 설명
엔드투엔드 지연 시간에는 DynamoDB 서비스 측 지연 시간과 사용자 클라이언트 측 지연 시간 사이의 공동 책임이 포함됩니다.
SuccessfulRequestLatency Amazon CloudWatch 지표는 DynamoDB가 API 요청을 완전히 처리하는 데 걸리는 시간만 측정합니다. DynamoDB는 애플리케이션이 DynamoDB 엔드포인트에 연결하거나 엔드포인트에서 결과를 다운로드하는 데 걸리는 시간은 측정하지 않습니다.
해결 방법
지연 시간을 분석할 때는 최대 지연 시간 값이 아닌 평균 지연 시간을 확인하는 것이 좋습니다. 가끔 지연 시간이 급증하는 것은 정상입니다. 평균 지연 시간이 길면 근본적인 문제가 있을 수 있습니다.
GetItem 및 PutItem과 같은 대부분의 기초 작업의 평균 지연 시간은 한 자리 밀리초입니다. Query, Scan, BatchGetItem 및 BatchWriteItem과 같은 기초적이지 않은 작업의 지연 시간은 여러 요인에 따라 달라집니다. 이러한 요인에는 결과 집합의 크기, 삽입된 레코드 수, 쿼리 조건 및 필터의 복잡성이 포함됩니다.
지연 시간이 길어지는 일반적인 이유
낮은 액세스 빈도
지연 시간을 방지하기 위해 DynamoDB의 모든 프론트엔드 호스트는 로컬 캐시를 유지합니다. 요청 비율이 낮으면 프론트엔드 플릿이 한동안 요청을 받지 못해 캐시 TTL(Time to Live)이 만료될 수 있습니다. 캐시가 만료된 후 요청이 호스트에 도착하면 호스트는 내부 DynamoDB 구성 요소에서 데이터를 가져와야 합니다. 호스트가 캐시를 채우면 호스트가 응답할 수 있습니다. 데이터를 가져오고 채우는 데 걸리는 시간으로 인해 지연 시간이 증가할 수 있습니다.
파티션이 분할되거나 리더십이 바뀌면 캐시가 오래되어 처음 몇 번의 호출에 대한 지연 시간이 길어질 수 있습니다. DynamoDB는 여러 캐시를 참조하여 파티션 정보, 서명 검증, 각 요청에 대한 기타 정보를 검색합니다. 요청 비율이 낮으면 캐시가 최신으로 유지되지 않으므로 일반적으로 처음 몇 번의 요청은 지연 시간이 더 깁니다.
요청 비율이 높고 수신 트래픽이 일정하면 각 요청이 프론트엔드 플릿에 지속적으로 도달하므로 지연 시간 급증이 발생하지 않습니다. 액세스 빈도가 낮아 발생하는 문제를 방지하려면 클라이언트가 DynamoDB 테이블로 더미 트래픽을 전송하도록 하십시오.
강력하게 일관된 읽기
GetItem, Query, Scan과 같은 읽기 작업은 선택적인 ConsistentRead 파라미터를 제공합니다. ConsistentRead를 true로 설정하면 DynamoDB는 최신 데이터가 포함된 응답을 반환합니다. 이 데이터는 이전에 성공한 모든 쓰기 작업의 업데이트를 반영하지만 지연 시간이 길어질 수 있습니다.
DynamoDB 아키텍처에는 파티션에 리더 노드 1개와 복제본 노드 2개가 있습니다. DynamoDB는 리더 노드를 사용하여 강력하게 일관된 읽기 요청을 처리하지만 읽기 복제본은 서비스하지 않습니다. DynamoDB는 리더 노드를 찾은 다음 요청을 서비스로 리디렉션해야 하므로 약간의 지연 시간이 발생할 수 있습니다.
애플리케이션에 강력하게 일관된 읽기가 필요하지 않은 경우 최종적으로 일관된 읽기를 사용하십시오.
지연 시간을 줄이는 방법
요청 시간 초과 설정 줄이기
requestTimeOut 및 clientExecutionTimeout 클라이언트 SDK 파라미터를 50밀리초 정도로 조정하여 시간 초과로 인한 실패가 훨씬 빨라지도록 합니다. 이렇게 제한 시간이 빨라지면 클라이언트는 지정된 시간 이후에 지연 시간이 긴 요청을 포기하게 됩니다. 그런 다음 클라이언트는 일반적으로 첫 번째 요청보다 훨씬 빠르게 완료되는 두 번째 요청을 보냅니다. 제한 시간에 대한 자세한 내용은 대기 시간에 맞는 Amazon DynamoDB 애플리케이션을 구성하기 위해 AWS Java SDK HTTP 요청 설정 조정을 참조하십시오.
클라이언트와 DynamoDB 엔드포인트 간의 거리 줄이기
사용자가 전 세계에 분산되어 있는 경우 글로벌 테이블을 사용하여 테이블을 사용할 AWS 리전을 지정하십시오. 또한 DynamoDB 게이트웨이 엔드포인트를 사용하여 인터넷을 통한 트래픽을 방지할 수 있습니다.
캐싱 사용
읽기 트래픽이 많으면 Amazon DynamoDB Accelerator(DAX)와 같은 캐싱 서비스를 사용하여 지연 시간을 줄이십시오.
연결 재사용
새 연결을 설정할 때는 연결을 인증하고 검증해야 합니다. 또한 DynamoDB는 요청을 처리하기 전에 내부 시스템에서 테이블의 메타데이터를 가져와야 합니다. DynamoDB 프론트엔드 플릿은 이 정보를 저장하는 데 사용되는 캐시를 유지 관리합니다. 연결을 재사용하는 경우 캐시는 요청을 처리하는 데 사용됩니다.
AWS Key Management Service(AWS KMS) 사용자에 대한 DynamoDB 요청을 인증하려면 추가 홉이 필요하므로 지연 시간이 증가할 수 있습니다.AWS KMS 키는 5분마다 새로 고쳐집니다. 클라이언트 연결을 재사용하지 않는 경우 모든 요청에 대해 새 TCP 연결을 설정해야 합니다. 이러한 요청의 연결에는 TCP 핸드셰이크 및 확인과 같은 프로세스가 포함되며, 이는 클라이언트 측 지연 시간이 길어지는 요인이 됩니다.
모든 새 연결에는 인증이 필요하기 때문에 캐시가 사용되지 않고 서버 측 지연 시간이 발생합니다. 연결을 재사용하려면 TCP keep-alive 파라미터를 사용하십시오. 또한 연결 객체의 단일 인스턴스를 보장하는 디자인 패턴을 사용하십시오. 자세한 내용은 Amazon CloudGuru 웹 사이트의 ](https://docs.aws.amazon.com/codeguru/detector-library/python/lambda-client-reuse/)Lambda 함수에서 재사용되지 않는 AWS 클라이언트[를 참조하십시오.
