Amazon CloudWatch를 활용한 RDS 모니터링

예시 RDS 환경은 아래와 같다.

https://aws.amazon.com/ko/cloudwatch/

Amazon 모니터링 및 관찰성 - Amazon CloudWatch - AWS

 

* 참조한 문서 

Amazon CloudWatch Doc : https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html

1. 기본 정보 소개

Amazon CloudWatch는 Amazon Web Services(AWS) 리소스 및 AWS에서 실행되는 애플리케이션을 실시간으로 모니터링하며, 이를 활용해 리소스 및 애플리케이션에 대해 측정할 수 있는 변수인 지표를 수집하고 추적할 수 있다.

 

 

CloudWatch는 AWS Console에서 "CloudWatch"를 검색 하거나 AWS Cli를 활용하여 원하는 서비스들을 찾아 모니터링 가능하다.

여기에선 "Aurora and RDS" 의 특정 RDS의 CloudWatch를 확인 하는 방법을 알아보자.

Aurora and RDS 서비스 조회 및 접속

 

RDS 목록에서 특정 데이터베이스에 접근하면 DB의 요약 정보를 볼 수 있으며

하단의 "모니터링" 탭 에서는 실시간으로 사용량 지표를 제공 받을 수 있다.

 

각 지표 별로 마우스 토글 시 아래와 같이 최대화 버튼이 활성화 되며 클릭하면 더 상세한 정보를 조회 할 수 있다.

 

기본적으로 제공되는 지표 외에 CloudWatch 서비스에서는 더 다양하게 생성 할 수 있다.

위에서 최대화된 지표 우측 하단에 "지표에서 보기" 를 클릭 하면 쉽게 CloudWatch에 접근 가능하다.

 

 

아래 이미지 처럼 특정 리소스에 대한 지표를 볼 수 있으며, 더 다양한 작업(csv 다운로드, 대시보드 추가 등)이 가능하다.

"지표에서 보기"를 클릭하여 조회 된 CPU 사용량 그래프

 

 

또한, 필요에 따라 지표를 추가하고 표현하는 축을 나누어 복합 그래프로 표현 가능하다.

CPU 사용량과 FreeableMemory 지표를 추가한 이미지

 

 

위에서 표시된 그래프를 "소스"로 관리가 가능하고 같은 작업을 반복 해야하는 경우 "DB 식별자"와 "region" 을 변경 하며 필요한 그래프를 쉽게 작성 할 수 있다.

 

 

2. CloudWatch 지표 활용

DBMS 종류, 구성 상태, 서비스 특성에 따라 모니터링 해야 할 주요 지표가 다르겠지만 운영을 하면서 가장 많이 봤던 지표는 CPUUtilizaion, FreeableMemory, TotalIOPS(Write + Read IOPS) 3개 인 듯 하다. 앞의 3개의 지표를 통해 RDS가 사용중인 Spec Type(r, m또는 large, 16xlarge등), Storage Type(gp2, gp3 등) 이 적합한지 판단의 근거로 사용되었기 때문이다.

 

- CPUUtilizaion

아래 예시 이미지 처럼 CPU 사용량이 매순간 100%에 도달 하는 데이터베이스가 있다.

 

문제를 파악하기위해 대부분은 데이터베이스에 직접 접속하여 현상을 조회하는 쿼리들을 수행 할 것이다.

하지만 AWS는 Performance Insights(성능 개선도우미) 라는 강력한 모니터링 도구를 제공한다.

(Performance Insights DOC : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)

성능 개선 도우미를 통한 Amazon RDS 모니터링 - Amazon Relational Database Service

 

아래 이미지 처럼 데이터베이스 로드, 대기 이벤트 현황과 TOP SQL 목록을 볼 수 있다.(Oracle, SQL-Server의 경우 Plan도 함께 제공)

 

부하를 발생시키는 SQL을 빠르게 식별하고 대처(위의 경우는 적절한 Index의 부재) 하여 아래 이미지처럼 CPU 사용량이 100% -> 12% 로 개선 할 수 있었다.

 

 

- FreeableMemory

여유 메모리가 0이 되면 Instance가 재기동 되어 버리기 때문에 중요한 모니터링 지표 중에 하나다.

아래 예시 이미지 처럼 여유 메모리가 감소하는 경우의 원인은 여러가지가 있겠으나, 

 

위의 지표와 함께 눈여겨 봐야 할 지표는 "DatabaseConnections" 이다.

 

이벤트를 앞두고 사전에 WAS Scale out을 하여 DB Connection 수가 500 -> 2.5k로 5배 증가 되었기 때문에 증가 된 Session 수 만큼 여유메모리가 감소 한 것이다.

"DatabaseConnections" 지표 또한 CloudWatch 에서 제공되므로 쉽게 모니터링 가능하다.

 

 

- TotalIOPS(Write + Read IOPS) 

Storage Concepts DOC : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/CHAP_Storage.html#Concepts.Storage.GeneralSSD

Amazon RDS DB 인스턴스 스토리지 - Amazon Relational Database Service

 

TotalIOPS를 모니터링 해야 하는 이유는 RDS는 기본적으로 Storage Type, Size에 따라 기준 IOPS, 버스트 IOPS가 달라진다.

 

Performance Insights(성능 개선도우미) 를 사용해 모니터링 하던 도중 시스템 전체적인 성능 저하를 경험한 적이 있다.

아래 이미지의  SQL이 문제를 발생 시킨 원인과, 파생효과, 해결 경험을 공유 하려고한다.

 

예시 RDS 환경은 아래와 같다.

구분	값
Storage Type	gp2
Allocate Size	1  TB

 

위의 구성 환경을 토대로 DoC에서 가이드 된 공식에 따르면 기준 처리량은 3,000(1024 GiB * 3 IOPS) IOPS 이며 버스트 IOPS는 12,000IOPS 에 속한다.

gp2 볼륨 스토리지 성능 표

 

아래 TotalIOPS 지표에서 처럼 장시간 기준IOPS+버스트IOPS를 초과하는 구간이 발생 했다.

 

아래 지표에서 보이는 것 처럼 버스트밸런스(credit)를 모두 소비한 순간 해당시점의 모든 SQL의 성능이 급격하게 떨어 졌다. 

 

 

부하의 원인은 SQL Plan 변화에 따른 성능 저하로 바로 찾아 낼 수 있었는데  Performance Insights(성능 개선도우미)의 가장 처음 화면에서 보인 것 처럼 SQL의 우측에 "Plans count (unqiue)" 값이 "2 플랜" 으로 표기 되어 있었기 때문에 원인을 바로 유추 할 수 있었다.

 

위의 Plan 비교 기능을 활용하여 더 유리한 Plan으로 SQL이 수행 되도록 Plan을 고정 하였고 문제는 바로 해결 할 수 있었다.

 

3. 결론

 Amazon CloudWatch와 Performance Insights(성능 개선 도우미)의 사용은 RDS를 보다 효과적으로 모니터링 하고, 문제를 신속하게 해결하는데 매우 유용 합니다. 지금 까지 공유한 내용 처럼 효과적으로 활용 하여 고객에게 안정적인 서비스를 제공 하는데 도움이 되었으면 좋겠습니다.

감사합니다.

 

 

본 글은 MegazoneCloud의 AWS Ambassador 활동으로 작성된 글입니다.