DynamoDB Accelerator(DAX) 클러스터에서 긴 지연 시간 문제를 해결하려면 어떻게 해야 하나요?

해결 방법

요청에 지연 시간이 발생할 수 있는 이유는 여러 가지가 있습니다. 지연 시간 문제를 해결하려면 아래의 각 잠재적 문제를 참조하세요.

클러스터 또는 노드에 과부하 발생

지연 시간은 많은 경우 DAX 클러스터에서 클러스터 또는 노드에 과부하가 생겨 발생합니다. 클라이언트가 클러스터 URL 대신 단일 노드 URL로 구성된 경우 이 지연 시간에 더 많은 영향을 미칠 수 있습니다. 이 경우 과부하 중에 노드에 문제가 발생하면 클라이언트 요청에 지연 시간 또는 제한이 발생합니다.

단일 클러스터 또는 노드의 과부하로 인해 발생하는 지연 시간 및 제한을 해결하려면 수평적 조정 또는 세로 크기 조정을 사용하세요.

DAX 클라이언트의 잘못된 구성

withMinIdleConnectionSize 파라미터를 낮추면 DAX 클러스터 전체의 지연 시간이 증가할 수 있습니다. 이 파라미터는 DAX 클러스터와의 유휴 연결의 최소 수를 설정합니다. 모든 요청에 대해 클라이언트는 사용 가능한 유휴 연결을 사용합니다. 연결을 사용할 수 없으면 클라이언트가 새 연결을 설정합니다. 예를 들어 파라미터가 20으로 설정된 경우 DAX 클러스터와의 유휴 연결이 최소 20개 있습니다.

클라이언트는 연결 풀을 유지 관리합니다. 애플리케이션이 DynamoDB 또는 DAX에 대한 API 호출을 수행하면 클라이언트는 연결 풀에서 연결을 임대합니다. 그런 다음 클라이언트는 API를 호출하고 연결을 풀에 반환합니다. 그러나 연결 풀에는 상한이 있습니다. 한 번에 DAX에 대한 API 호출을 많이 하면 연결 풀 한도를 초과할 수 있습니다. 이 경우 일부 요청은 연결 풀에서 임대를 얻기 전에 다른 요청이 완료될 때까지 기다려야 합니다. 이로 인해 요청이 연결 풀 수준에서 대기열에 추가됩니다. 결과적으로 애플리케이션의 왕복 지연 시간이 증가합니다.

따라서 애플리케이션에서 주기적인 트래픽 급증을 줄이려면 setMinIdleConnectionSize, getMinIdleConnectionSize 및 withMinIdleConnectionSize 파라미터를 조정하세요. 이러한 파라미터는 DAX 클러스터의 지연 시간에서 중요한 역할을 합니다. DAX가 새 연결을 다시 설정할 필요 없이 적절한 수의 유휴 연결을 사용하도록 해당 파라미터를 API 호출에 대해 구성합니다.

캐시에서 누락된 항목

읽기 요청에서 항목이 누락된 경우 DAX는 해당 요청을 DynamoDB로 보냅니다. DynamoDB는 최종 읽기 일관성을 사용하여 요청을 처리한 다음 항목을 DAX로 반환합니다. DAX는 이를 항목 캐시에 저장한 다음 애플리케이션에 반환합니다. 기본 DynamoDB 테이블의 지연 시간으로 인해 요청에서 지연 시간이 발생할 수 있습니다.

캐시 누락은 일반적으로 다음과 같은 두 가지 이유로 발생합니다.

1.    강력한 일관된 읽기: 동일한 항목에 대한 강력히 일관된 읽기는 DAX에서 캐시되지 않습니다. 항목이 DAX를 우회하고 DynamoDB 테이블 자체에서 검색되기 때문에 캐시 누락이 발생합니다. 최종 읽기 일관성을 사용하여 이 문제를 해결할 수 있지만 DynamoDB는 먼저 데이터를 캐시할 데이터를 읽어야 합니다.

2.    DAX의 제거 정책: 캐시에서 이미 제거되어진 쿼리된 데이터는 누락됩니다. DAX는 세 가지 다른 값을 사용하여 캐시 제거를 결정합니다.

• DAX 클러스터는 LRU(Least Recently Used) 알고리즘을 사용하여 항목의 우선 순위를 지정합니다. 우선 순위가 가장 낮은 항목은 캐시가 가득 차면 제거됩니다.
• DAX는 캐시에서 항목을 사용할 수 있는 기간 동안 유지 시간(TTL) 값을 사용합니다. 항목의 TTL 값을 초과하면 항목이 제거됩니다.
  참고: 기본 TTL 값인 5분을 사용하는 경우 TTL 시간 이후에 데이터를 쿼리하고 있는지 확인하세요.
• DAX는 라이트-스루(write-through) 기능을 사용하여 새 값이 기록될 때 이전 값을 제거합니다. 이는 단일 API 호출을 사용하여 DAX 항목 캐시를 기본 데이터 스토어와 일관되게 유지하는 데 도움이 됩니다.

항목의 TTL 값을 확장하려면 TTL 설정 구성을 참조하세요.
참고: 실행 중인 DAX 인스턴스에서 사용 중인 파라미터 그룹은 수정할 수 없습니다.

유지 관리 패치가 DAX 클러스터에 적용될 때도 캐시 누락이 발생할 수 있습니다. 이 가동 중지 시간을 줄이려면 여러 노드 클러스터를 사용하세요.

유지 관리 기간

특히 소프트웨어 업그레이드, 패치 또는 클러스터 노드에 대한 시스템 변경이 있는 경우 주간 유지 관리 기간 동안 지연 시간이 발생할 수 있습니다. 대부분의 경우 유지 관리가 진행되지 않는 다른 사용 가능한 노드에서 요청을 성공적으로 처리합니다. 많은 유지 관리 기간 동안 요청 수가 많은 클러스터는 실패할 수 있습니다.

지연 시간이나 실패 가능성을 줄이려면 사용량이 적은 시간으로 유지 관리 기간을 구성하세요. 이렇게 하면 요청 로드가 적은 기간 동안 클러스터가 업그레이드될 수 있습니다.

DynamoDB 테이블의 지연 시간

쓰기 작업을 통해 데이터는 먼저 DynamoDB 테이블에 쓰여진 다음 DAX 클러스터에 쓰여집니다. 데이터가 테이블과 DAX 모두에 성공적으로 기록된 경우에만 작업이 성공한 것입니다. 기본 DynamoDB 테이블의 지연 시간으로 인해 요청에서 지연 시간이 발생할 수 있습니다. 이 지연 시간을 줄이려면 Amazon DynamoDB 테이블에서 발생하는 긴 대기 시간 문제를 해결하려면 어떻게 해야 합니까?를 참조하세요.

애플리케이션의 지연 시간 요구 사항에 맞게 DynamoDB를 추가로 구성하려면 Tuning AWS Java SDK HTTP request settings for latency-aware Amazon DynamoDB applications를 참조하세요.

요청 제한 시간

파라미터 setIdleConnectionTimeout은 유휴 연결에 대한 제한 시간을 결정하고 setConnectTimeout은 DAX 클러스터와의 연결에 대한 제한 시간을 결정합니다. 이 두 파라미터는 클러스터의 지연 시간에 영향을 줄 수 있는 연결 풀의 시간 초과를 처리합니다.

setRequestTimeout 파라미터를 조정하여 DAX 클러스터와의 연결에 대한 요청 제한 시간을 구성합니다. 자세한 내용은 DAX 설명서의 setRequestTimeout을 참조하세요.

또한 요청 오류와 운영 비용을 줄이는 지수 백오프 재시도를 사용하는 것이 좋습니다.

참고: DAX는 CloudWatch 지표에서 클러스터의 지연 시간을 지원하지 않습니다.

---