AWS RDS Aurora모니터링 지표

Intro

트래픽 증가로 인해서 피크 시간에 서비스가 중단되거나, 느려지는 이슈를 경험한 후 모니터링 시스템의 중요성을 다시금 느꼈다. 사건 후 서비스들의 주요 지표에 모니터링 및 알람을 걸어두기 시작했다. 그 과정에서 RDS Aurora Mysql에서 어떠한 지표를 설정하는 게 이슈를 사전에 감지하거나 발 빠르게 대응할 수 있을지 고민했다. 하나씩 알아보자. (CloudWatch Log 내보내기를 설정이 돼 있어야 한다.)

 

지표 변화 요인

아래의 지표들에 영향을 미치는 것들은 다음과 같이 거의 비슷하다.

 

1. 트래픽의 증가

2. 장기 실행 트랜잭션

3. 많은 커넥션 (커넥션 또한 메모리를 점유하기 때문에)
4. 슬로우 쿼리

특별한 언급이 없다면, 위의 이유들이다.

 

CPU Utilization

 

CPU 사용률을 나타내는 지표다. CPU 사용률이 과도하게 높아지면 성능에 문제가 발생할 수 있다. 그래서 CPU 사용률이 과도하게 높아지기 전에 알람을 받아 조치할 수 있도록 한다. 단계적으로 알람을 받을 수 있도록 하자.

 

1. 55%이상 Warning

2. 75%이상 Critical

 

반대로 55% 미만으로 넘어갔을 때는 다시 안정화 됐다는 알람 설정해 주면 좋다.

 

DML Latency

 

삽입, 업데이트 및 삭제의 평균 소요시간을 나타내는 지표다. 해당 지표가 증가하면 락을 거는 시간이 증가하기 때문에 설정이 중요하다.

단계적으로 알람을 받을 수 있도록 하자.

 

1. 200 밀리세컨드 이상 Warning

2. 500 밀리세컨드 이상 Critical

 

DatabaseConnections

 

데이터베이스의 클라이언트 네트워크 연결 수다. 위에서 언급 했듯이 데이터베이스 커넥션은 메모리를 점유하기에, 과도하게 생성되지 않도록 한다.

 

해당 지표는 인스턴스 사양에 따라 다르기 때문에 문서를 참고해서 설정하면 된다. 

 

SelectLatency

 

select 동작에 걸리는 시간이다. 서비스에서 조회는 빠질 수 없으니 반드시 설정하자.

 

1. 200 밀리세컨드 이상 Warning

2. 500 밀리세컨드 이상 Critical

 

CommitLatency

 

Commit을 요청하고, 받아들여지는 평균 시간이다. 주로 스토리지 시스템이 물리적으로 쓰고, 플러시 할 수 있는 속도에 따라 결정된다.

 

1. 20 밀리세컨드 이상 critical

 

스토리지 혹은 엔진에 문제가 생겼을 수 있기 때문에 반드시 설정하자. 

 

BufferCacheHitRatio

 

디스크에 접근하지 않고 캐시로 요청을 얼마나 처리하고 있는지에 대한 지표다. 해당 지표가 낮다고 해서 항상 문제가 되는 건 아니다. 고려해야 할 점은 히트 비율이 내려간 상태에서 SelectLatency가 증가한 상황이다. 캐시를 히트하지 못해서 디스크에 액세스 하는 쿼리가 많다는 것을 의미한다.

 

1. BufferCacheHitRatio 90% 이하 Warning

 

Slow Query

 

Slow Query의 대한 정보를 CloudWatch Log에 저장할 수 있다. 데이터베이스 파라미터에 long_query_time으로 설정돼있다. 기본값은 10초이고, 각 환경에 맞게 변경하면 된다.