DAX 모니터링

캐시 적중률 - DAX가 캐시된 데이터를 얼마나 효과적으로 처리하는지 보여 주므로, 기본 DynamoDB 테이블에 액세스할 필요성이 줄어듭니다. 클러스터의 캐시 누락이 거의 없다는 것은 캐싱 효율성이 양호하다는 사실을 나타냅니다. 하지만 캐시 적중률이 줄면 캐싱 TTL 설정을 다시 검토해야 할 수도 있고, 워크로드가 캐싱에 적합하지 않을 수도 있음을 시사합니다.

Amazon CloudWatch를 사용하여 DAX 클러스터의 캐시 적중률을 계산할 수 있습니다. ItemCacheHits, ItemCacheMisses, QueryCacheHits, QueryCacheMisses 지표를 비교하여 이 비율을 구하세요. 다음 공식은 캐시 적중률 계산 방법을 보여줍니다. 이 공식을 사용하여 비율을 계산하려면 캐시 적중률을 캐시 적중률과 누락의 합계로 나누세요.

Cache hit ratio = Cache hits / (Cache hits + Cache misses)

캐시 적중률은 0에서 1 사이의 숫자이며 백분율로 표시됩니다. 백분율이 높을수록 전체 캐시 사용률이 높아집니다.

ErrorRequestCount - 노드 또는 클러스터에서 보고한 사용자 오류로 이어진 요청 수입니다. ErrorRequestCount에는 노드 또는 클러스터에서 제한이 발생한 요청이 포함됩니다. 사용자 오류를 모니터링하면 애플리케이션의 규모 조정 구성 오류 또는 핫 항목/파티션 패턴을 식별하는 데 도움이 될 수 있습니다.

작동 지연 - DAX 클러스터와의 읽기 및 쓰기 작업 지연 시간을 모니터링하면 성능 병목 현상을 식별하는 데 도움이 될 수 있습니다. 지연 시간이 증가하면 DAX 클러스터 구성, 네트워크 또는 규모 조정 필요성에 문제가 있는 것일 수 있습니다.

네트워크 소비 - NetworkBytesIn 및 NetworkBytesOut 지표를 주시하여 DAX 클러스터의 네트워크 트래픽을 모니터링하세요. 네트워크 처리량이 예기치 않게 증가하면 클라이언트 요청이 늘어나거나 쿼리 패턴이 비효율적이라는 의미여서 더 많은 데이터가 전송될 수 있습니다.

네트워크 소비를 모니터링하면 DAX 클러스터의 비용을 관리하는 데 도움이 됩니다. 또한, 네트워크가 클러스터 성능의 병목 현상으로 작용하지 않도록 합니다.

제거율 - 새 항목을 위한 공간을 확보하려고 캐시에서 항목을 제거하는 빈도를 보여줍니다. 시간이 지나면서 제거율이 증가하면 캐시가 너무 작거나 캐싱 전략이 효과적이지 않게 될 수 있습니다.

CloudWatch의 EvictedSize 지표를 모니터링하여 캐시 크기가 워크로드에 적합한지 확인하세요. 제거된 총 크기가 계속 증가하면 더 큰 캐시를 수용할 수 있도록 DAX 클러스터를 스케일 업해야 할 수 있습니다.

CPU 사용률 – 노드 또는 클러스터의 CPU 사용률 백분율입니다. 이는 모든 데이터베이스 또는 캐싱 시스템에서 모니터링해야 하는 중요한 지표입니다. CPU 사용률이 높으면 DAX 클러스터에 과부하가 걸리고 늘어난 수요를 처리하기 위해 규모를 조정해야 할 수 있습니다.

DAX 클러스터에 대한 CPUUtilization 지표를 모니터링하세요. CPU 사용률이 지속적으로 70~80%에 근접하거나 이를 초과하는 경우 다음 섹션에 설명된 대로 DAX 클러스터를 스케일 업해 보세요.

DAX로 전송된 요청 수가 노드의 용량을 초과하는 경우 DAX는 추가 요청을 수락하는 속도를 제한합니다. ThrottlingException을 반환하여 이 작업을 수행합니다. DAX는 클러스터의 CPU 사용률을 지속적으로 평가하여 정상적인 클러스터 상태를 유지하면서 처리할 수 있는 요청 볼륨을 결정합니다.

DAX가 CloudWatch에 게시하는 ThrottledRequestCount 지표를 모니터링할 수 있습니다. 이러한 예외가 정기적으로 표시되는 경우 클러스터를 확장하는 것이 좋습니다.

스케일 업 또는 스케일 아웃 - DAX 클러스터의 CPU 사용률이 높거나 캐시 적중률이 낮거나(캐싱 전략을 최적화한 후) 작동 지연 시간이 길면 클러스터를 스케일 업해야 합니다. 노드를 더 추가하면(스케일 아웃이라고도 함) 로드를 더 균등하게 분산하는 데 도움이 될 수 있습니다. 초당 쓰기 수가 증가하는 워크로드의 경우 더 강력한 노드를 선택(스케일 업)해야 할 수 있습니다.

스케일 다운 - CPU 사용률이 꾸준히 낮고 작동 지연 시간이 임계값 이하로 계속 유지되면 리소스가 과도하게 프로비저닝된 것일 수 있습니다. 이러한 경우에는 노드를 스케일 다운하여 비용을 절감하세요. 사용률이 낮은 기간에는 노드 수를 1개로 줄일 수는 있어도 클러스터를 완전히 종료할 수는 없습니다.