Amazon DynamoDB의 지연 시간 문제 해결 - Amazon DynamoDB

Amazon DynamoDB의 지연 시간 문제 해결

워크로드의 지연 시간이 길면 CloudWatch SuccessfulRequestLatency 지표를 분석하고 평균 지연 시간을 확인하여 DynamoDB와 관련이 있는지 확인할 수 있습니다. 보고된 SuccessfulRequestLatency의 일부 변동성은 정상이며, 가끔 발생하는 급증(특히 Maximum 통계)은 걱정할 필요가 없습니다. 그러나 Average 통계가 급격히 증가했는데도 계속 유지되는 경우에는 AWS 서비스 상태 대시보드와 Personal Health Dashboard에서 자세한 내용을 확인해야 합니다. 가능한 원인으로는 테이블의 항목 크기(1KB 항목과 400KB 항목은 지연 시간이 다를 수 있음) 또는 쿼리 크기(항목 10개 대 100개)가 있습니다.

필요한 경우 AWS Support를 통해 지원 사례를 개설하고 런북에 따라 애플리케이션에 사용할 수 있는 대체 옵션(예: 다중 리전 아키텍처를 사용하는 경우 리전 철수)을 계속 평가해 보세요. 지원 사례를 열 때 이러한 ID를 제공하는 느린 요청에 대해 AWS Support에 요청 ID를 로깅해야 합니다.

SuccessfulRequestLatency 지표는 DynamoDB 서비스 내부의 지연 시간만 측정하며 클라이언트 측 활동 및 네트워크 이동 시간은 포함되지 않습니다. 클라이언트에서 DynamoDB 서비스로의 호출에 대한 전체 지연 시간에 대해 자세히 알아보려면 AWS SDK에서 지연 시간 지표 로깅을 활성화하면 됩니다.

참고

대부분의 싱글톤 작업(프라이머리 키의 값을 완전히 지정하여 단일 항목에 적용되는 작업)의 경우 DynamoDB는 한 자릿수 밀리초의 Average SuccessfulRequestLatency를 제공합니다. 이 값에는 DynamoDB 엔드포인트에 액세스하는 호출자 코드에 대한 전송 오버헤드가 포함되지 않습니다. 다중 항목 데이터 작업의 경우 지연 시간은 결과 세트의 크기, 반환된 데이터 구조의 복잡성, 적용된 조건 표현식 및 필터 표현식과 같은 요인에 따라 달라집니다. 동일한 파라미터로 동일한 데이터 세트에 대한 다중 항목 작업을 반복하는 경우 DynamoDB의 Average SuccessfulRequestLatency는 일관성이 매우 뛰어납니다.

지연 시간을 줄이려면 다음 중 하나 이상의 전략을 고려하세요.

  • 요청 제한 시간 및 재시도 동작 조정: 클라이언트에서 DynamoDB로 가는 경로는 여러 구성 요소를 통과하며, 각 구성 요소는 중복성을 염두에 두고 설계되었습니다. 네트워크 복원력의 범위, TCP 패킷 제한 시간, DynamoDB 자체의 분산 아키텍처를 생각해 보세요. 기본 SDK 동작은 대부분의 애플리케이션에 적합한 균형을 찾도록 설계되었습니다. 가능한 최상의 지연 시간을 최우선으로 고려한다면 SDK의 기본 요청 제한 시간 및 재시도 설정을 조정하여 클라이언트가 측정한 성공적인 요청의 일반적인 지연 시간을 면밀히 추적하는 것이 좋습니다. 평소보다 훨씬 오래 걸리는 요청은 궁극적으로 성공할 가능성이 낮습니다. 빠르게 실패하고 새로 요청하면 다른 경로를 택하여 빠르게 성공할 수 있습니다. 너무 공격적으로 설정하면 단점이 있을 수 있다는 점을 명심하세요. 이 주제에 대한 유용한 설명은 지연 시간을 인식하는 Amazon DynamoDB 애플리케이션을 위한 AWS Java SDK HTTP 요청 설정 조정에서 확인할 수 있습니다.

  • 클라이언트와 DynamoDB 엔드포인트 간 거리 줄이기: 사용자가 전 세계에 분산되어 있는 경우 글로벌 테이블 - DynamoDB의 다중 리전 복제 사용을 고려해 보세요. 글로벌 테이블에서는 테이블을 사용할 수 있는 AWS 리전을 지정할 수 있습니다. 로컬 글로벌 테이블 복제본에서 데이터를 읽으면 사용자의 지연 시간을 크게 줄일 수 있습니다. 또한 DynamoDB 게이트웨이 엔드포인트를 사용하여 VPC 내에서 클라이언트 트래픽을 유지하는 것도 고려해 보세요.

  • 캐싱 사용: 트래픽에 읽기가 많은 경우 캐싱 서비스(예: DynamoDB Accelerator(DAX)를 통한 인 메모리 가속화)를 사용해 보세요. DAX는 DynamoDB를 위한 완전관리형, 고가용성, 인 메모리 캐시로, 초당 요청 수가 몇 백만 개인 경우에도 몇 밀리초에서 몇 마이크로초까지 최대 10배의 성능 개선을 제공합니다.

  • 연결 재사용: DynamoDB 요청은 기본적으로 HTTPS로 설정된 인증된 세션을 통해 이루어집니다. 연결을 시작하는 데 시간이 걸리므로 첫 번째 요청의 지연 시간이 일반적인 요청보다 깁니다. 이미 초기화된 연결을 통한 요청은 DynamoDB의 일관되고 짧은 지연 시간을 제공합니다. 따라서 다른 요청이 없을 경우 30초마다 '연결 유지' GetItem을 요청하여 새 연결을 설정하는 데 따른 지연을 방지하는 것이 좋습니다.

  • 최종 읽기 일관성 사용: 애플리케이션에서 강력히 일관된 읽기를 요구하지 않는 경우 기본값인 최종 읽기 일관성을 사용하는 것이 좋습니다. 최종 읽기 일관성을 사용하면 비용이 절감되고 일시적인 지연 시간 증가를 경험할 가능성도 적습니다. 자세한 내용은 DynamoDB 읽기 일관성 단원을 참조하십시오.