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

Amazon DynamoDB의 지연 시간 문제 해결

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

백분위수 지표(p99, p90 등)는 지연 시간 분포를 더 잘 이해하는 데 도움이 될 수 있습니다. 예시:

  • p50(중앙값)은 워크로드의 일반적인 지연 시간을 보여줍니다.

  • p90은 요청의 90%가 이 값보다 빠르다는 것을 보여줍니다.

  • p99는 요청의 1%에 영향을 미치는 최악의 지연 시간을 식별하는 데 도움이 됩니다.

정상인 p50 값과 높은 p99 값은 요청의 작은 부분에 영향을 미치는 산발적인 문제를 나타낼 수 있지만, 지속적으로 높은 p50 값은 성능 저하를 의미할 수 있습니다.

참고

사용자 지정 백분위수 값(예: p99.9)을 분석하려면 CloudWatch 지표 통계 필드에 원하는 백분위수(예: p99.9)를 수동으로 입력합니다. 이를 통해 드롭다운에 나열된 기본 백분위수를 초과하는 지연 시간 분포를 평가할 수 있습니다.

지연 시간 지표의 일부 변동, 특히 높은 백분위수는 정상입니다. 이는 DynamoDB 테이블에 저장된 데이터의 고가용성 및 내구성을 유지하는 데 도움이 되는 DynamoDB 기반 백그라운드 작업 또는 일시적인 인프라 문제의 결과로 볼 수 있습니다.

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

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

참고

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

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

  • 연결 재사용: DynamoDB 요청은 기본적으로 HTTPS를 사용하여 인증된 세션을 통해 이루어집니다. 연결을 시작하려면 여러 번의 왕복이 필요하고 시간도 오래 걸리므로 첫 번째 요청의 지연 시간이 연결을 재사용하는 후속 요청의 지연 시간보다 더 깁니다. 이미 초기화된 연결을 통한 요청은 DynamoDB의 일관되고 짧은 지연 시간을 제공합니다. 새 연결을 설정하는 데 따른 지연 시간 오버헤드를 피하기 위해 다른 요청이 없을 경우 30초마다 GetItem 요청을 전송하여 ‘연결 유지’ 메커니즘을 구현하는 것이 좋습니다.

  • 최종 읽기 일관성 사용: 애플리케이션에서 강력히 일관된 읽기를 요구하지 않는 경우 기본값인 최종 읽기 일관성을 사용하는 것이 좋습니다. 최종적으로 일관된 읽기는 비용이 더 낮고 여러 가용 영역에서 발생할 수 있으므로 요청자에게 공동 배치된 가용 영역을 선택하여 지연 시간을 줄일 수 있습니다. 자세한 내용은 DynamoDB 읽기 일관성 섹션을 참조하세요.

  • 요청 해징 구현: 매우 짧은 p99 지연 시간 요구 사항의 경우 요청 해징 구현을 고려하세요. 요청 헤징을 사용하면 초기 요청이 응답을 충분히 빠르게 수신하지 못하는 경우 동등한 요청을 한 번 더 보내고 두 요청이 경합하도록 합니다. 먼저 응답을 받은 요청이 처리됩니다. 이렇게 하면 일부 추가 요청의 비용으로 최악의 지연 시간이 개선됩니다. 두 번째 요청을 보내기 전에 대기할 시간을 결정할 수 있습니다. 헤징은 읽기의 경우 더 쉽습니다. 쓰기의 경우 타임스탬프 기반 순서를 사용하여 헤징된 요청을 첫 번째 시도 시 발생하는 것으로 처리하여 순서가 잘못된 업데이트를 방지합니다. 이 접근 방식은 Timestamp writes for write hedging in Amazon DynamoDB에서 설명되었습니다.

  • 요청 제한 시간 및 재시도 동작 조정: 클라이언트에서 DynamoDB로 가는 경로는 여러 구성 요소를 통과하며, 각 구성 요소는 중복성을 염두에 두고 설계되었습니다. 다음 측면을 고려합니다.

    • 네트워크 복원력

    • TCP 패킷 제한 시간

    • DynamoDB의 분산 아키텍처

    기본 SDK 동작은 대부분의 애플리케이션에 최적화되어 있습니다. 하지만 빠른 실패 전략을 구현하고 제한 시간 설정을 조정할 수 있습니다. 평소보다 훨씬 오래 걸리는 요청은 궁극적으로 성공할 가능성이 낮습니다. 빠른 실패 후 재시도하면 다른 경로를 통해 빠르게 성공할 수 있습니다. 이는 요청 헤징과 유사하지만 첫 번째 요청을 진행하는 대신 종료합니다.

    제한 시간 값을 너무 낮게 설정하면 안 됩니다. 제한 시간이 너무 짧으면 클라이언트로 인한 가용성 문제가 발생할 수 있습니다. 예를 들어 소켓 제한 시간이 50밀리초이면 네트워크 지연 시간이 급증할 때(예: 단일 흐름 트래픽에 대한 Amazon EC2 인스턴스 대역폭 제한에 도달하는 경우) 연결 오류가 발생할 수 있습니다. 제한 시간을 줄이는 것의 이점과 애플리케이션 가용성에 대한 잠재적 위험을 신중하게 비교하고 짧은 제한 시간보다는 헤징을 선택하세요.

    이 주제에 대한 유용한 논의는 Tuning AWS Java SDK HTTP request settings for latency-aware Amazon DynamoDB applications를 참조하세요.

  • 클라이언트와 DynamoDB 엔드포인트 간 거리 줄이기: 사용자가 전 세계에 분산되어 있는 경우 글로벌 테이블 - DynamoDB의 다중 리전 복제 사용을 고려해 보세요. 글로벌 테이블에서는 테이블을 사용할 수 있는 지정된 AWS 리전으로 테이블을 복제할 수 있습니다. 데이터 사본을 최종 사용자 가까이 두어 읽기 및 쓰기 작업 중 네트워크 지연 시간을 줄일 수 있습니다. DynamoDB 글로벌 테이블을 효과적으로 사용하는 방법에 대한 자세한 내용은 AWS 권장 가이드의 Amazon DynamoDB 글로벌 테이블 사용을 참조하세요.

  • 캐싱 사용: 트래픽에 읽기가 많은 경우 다음과 같은 캐싱 서비스 중 하나를 사용해 보세요.