갱동구리

Be brave.

[cloudwatch] Aurora 모니터링

업데이트:     Updated:

카테고리:

태그:

🎯Amazon Aurora 모니터링을 위한 주요 지표

  • Query throughput
  • Query performance
  • Resource utilization
  • Connections
  • Read replica metrics

Query throughput

데이터베이스 작업은 쿼리를 실행하는 것이므로 모니터링 전략의 첫 번째 우선 순위는 쿼리가 실행되고 있는지 확인하는 것입니다.

또한 데이터베이스의 읽기/쓰기 균형을 더 잘 이해하고 잠재적인 병목 현상을 식별하기 위해 읽기 및 쓰기 명령의 분석을 모니터링할 수 있습니다.

Metric description         CloudWatch name MySQL name
Queries Queries(per second) Queries(count)
Reads SelectThroughput(per second)             Com_select + Qcache_hits(count)
Writes DMLThroughput(per second) Com_insert + Com_update + Com_delete(count)                  

경고할 메트릭: Queries

Query performance

latency 또한 쿼리 볼륨을 모니터링 하는데 있어 가장 중요한 메트릭 중 하나입니다. CloudWatch 에서는 Aurora에 대한 SELECT 및 DML(Insert, Update, Delete) latency를 캡쳐합니다.

Metric description         CloudWatch name MySQL name
Read query latency, in milliseconds SelectLatency -
Write query latency, in milliseconds DMLLatency             -
Queries exceeding long_query_time limit                   - Slow_queries                  
Query errors - (Only available via database query)                  

경고할 메트릭:

  • latency
  • slow_queries
  • query_errors

Resource utilization

데이터베이스 인스턴스에 성능 문제가 발생할 때마다 CPU, Memory, Disk, Network의 네 가지 기본 리소스와 관련된 지표를 확인하여 병목 현상을 찾아야 합니다.

Metric description         CloudWatch name Enhanced monitoring name
Read I/O operations per second ReadIOPS diskIO.readIosPS
Write I/O operations per second WriteIOPS diskIO.writeIOsPS
I/O operations waiting for disk access               DiskQueueDepth diskIO.diskQueueDepth             
Milliseconds per read I/O operation ReadLatency diskIO.readLatency
Milliseconds per write I/O operation WriteLatency diskIO.writeLatency
Percent CPU utilized CPUUtilization cpuUtilization.total
Available RAM in gigabytes FreeableMemory memory.free
Network traffic to the Aurora instance NetworkReceive Throuhgput (MB/s) network.rx(packets)
Network traffic from the Aurora instance NetworkTransmit Throughput(MB/s)                   network.tx(packets)
  • 2015년 12월부터 RDS 사용자는 RDS 인스턴스에 대한 자세한 시스템 수준 메트릭을 표시하는 Enhanced Monitoring 기능에 액세스할 수 있습니다.
  • 스토리지 볼륨이 읽기 및 쓰기 요청을 따라갈 수 없는 경우 큐에 대기 중인 I/O 작업이 표시되기 시작합니다. DiskQueueDepth은 주어진 순간에 이 대기열의 길이를 측정합니다.
  • ReadLatency 와 WriteLatency 메트릭은 전체 query latency을 캡처하지 않으며 디스크 수준에서 I/O 작업이 소요되는 시간만 측정합니다.
  • 데이터베이스는 대부분의 작업 데이터를 메모리에 저장할 수 있을 때 최상의 성능을 발휘합니다. 이러한 이유로 FreeableMemory를 모니터링하고 ReadIOPS 지표를 추적하여 작업 데이터가 주로 메모리에 있는지 여부를 확인해야 합니다.
  • 다른 RDS 데이터베이스 엔진과 달리 Aurora의 네트워크 처리량 메트릭에는 데이터베이스 인스턴스에서 스토리지 볼륨으로의 네트워크 트래픽이 포함되지 않습니다. 따라서 메트릭은 클라이언트에서 들어오고 나가는 네트워크 트래픽만 추적합니다.

경고할 메트릭: DiskQueueDepth

Connection metrics

사용 중인 클라이언트 연결 수를 모니터링하는 것은 데이터베이스의 활동과 용량을 이해하는데 중요합니다.

Aurora에는 구성 가능한 연결 제한이 있고 기본값은 다음 공식에 따라 데이터베이스의 인스턴스 클래스 메모리에 따라 다릅니다.

log(DBInstanceClassMemory/8187281408)*1000
Metric description         CloudWatch name MySQL name
Open database connections DatabaseConnections          Threads_connected
Currently running connections - Threads_running
Failed connection attempts LoginFailures(per second) Aborted_connects(count)
Count of connections refused due to server error - Connection_errors_internal
Count of connections refused due to max_connections limit        - Connection_errors_max_connections            
  • 사용 중인 연결 수를 모니터링하기 위해 CloudWatch는 DatabaseConnections 열린 연결을 추적하는 지표를 노출합니다.
  • Threads_running 메트릭은 쿼리를 능동적으로 처리하는 스레드를 격리하여 추가적인 가시성을 제공합니다.
  • 서버가 max_connections 제한에 도달하여 연결을 거부하기 시작하면 Connection_error_max_connections 지표가 증가합니다.
  • LoginFailures 지표를 통해 실패한 연결을 추적합니다.
  • Connections_errors_internal 메트릭은 오류가 서버 자체에서 발생할 때 증가합니다. 내부 오류는 메모리 부족 상태 또는 서버가 새 스레드를 시작할 수 없음을 의미할 수 있습니다.

경고할 메트릭:

  • DatabaseConnections
  • Connection_errors_max_connections
  • Connection_errors_internal

Read replica metrics

Aurora는 소스 인스턴스에서 최대 15개의 읽기 전용 복제본 생성을 지원합니다. 이러한 복제본에는 별도의 엔드포인트가 할당되므로 소스 인스턴스가 아닌 복제본에서 읽도록 클라이언트 애플리케이션을 가리킬 수 있습니다. 일반 RDS 인스턴스와 마찬가지로 복제본의 연결, 처리량 및 쿼리 성능을 모니터링할 수 있습니다.

Name Desription
AuroraReplicaLag              Number of milliseconds by which replica trails source instance                            
  • 모든 읽기 복제본의 지연 시간은 CloudWatch의 AuroraReplicaLag 지표에 의해 캡처됩니다.
  • 이것은 다른 데이터베이스 엔진에 적용되는 ReplicaLag 메트릭과는 상당히 다른 메트릭입니다.
  • Aurora 인스턴스는 모두 동일한 가상 스토리지 볼륨에서 읽기 때문에 AuroraReplicaLag는 원본 인스턴스에서 복제본으로 모든 쓰기 작업을 적용하는 지연이 아니라 원본에서 복제본으로의 페이지 캐시 업데이트 지연을 추적합니다.

📖출처

DataDog Blog

👍 개인 공부 기록용 블로그입니다. 오류나 조언이 있으시면 언제든지 댓글 혹은 메일로 남겨주시면 감사하겠습니다! 😄

맨 위로 이동하기

cloudwatch 카테고리 내 다른 글 보러가기

댓글남기기

최근 글 10 개 :)