[AWS] AWS RDS 성능개선도우미를 도입

 

ㅁ 개요

 DB 부하지표가 발생하여 원인을 분석하였다. 현재 APM으로 사용 중인 Whatap은 라이센스 문제로 slowquery를 보는데에는 한계가 있 다. 부하를 주는 롱쿼리에 대한 분석과정을 개선하고자 AWS RDS 성능개선도우미를 도입하기로 하였고 그 과정을 정리하였다.

 

 

ㅁ Cloud Watch RDS 부하 지표 확인

 ㅇ 현재 RDS 라이트 인스턴스와 리더 인스턴스로 구성되어 있다.

 ㅇ 리더 인스턴스에서 롱쿼리가 발생하여 CPU 사용량이 증가 되었고 지표상 롱쿼리라 판단을 하였다.

 ㅇ 물론 운영상 통계를 추출하면서 롱쿼리가 발생할 수 있지만 이런 경우 모니터링 상 문제가 될 수 있기 때문에 전체 공유를 한다.

 

 

ㅁ Whatap RDS 지표 확인

 ㅇ 와탭 > RDS > 인스턴스 모니터링을 확인하면, 현재의 DB 프로세스 정보와 성능지표를 확인할 수 있다.

 ㅇ 하지만 부하가 되는 SQL 정보를 확인 할 수 없었고, 결국 디비에 접속하여 process를 확인해야 했다.

 

 

ㅁ RDS 프로세스 확인

SELECT *
FROM information_schema.processlist
WHERE command <> 'Sleep'

 ㅇ 프로세스를 확인하여 롱쿼리를 확인하였고, 데이터 확인 과정에서 인덱스가 타지 않는 조건에 의해 롱쿼리가 발생함을 확인하였다.

 ㅇ 해당 프로세스를 킬하는 과정에서 문제가 발생하였다. kill 명령어가 차단되었다.

 

 

ㅁ DBSafer 우회방법하여 Kill 하기

 ㅇ 사내에서 DBSafer라는 디비접근제어 시스템을 갖추고 있다. 그래서 보안상의 이유로 특정쿼리에 대해서 방어를 하고 있었다.

 ㅇ 문제는 프로세스에서 확인되었지만, 툴에서 kill 명령어를 사용할 경우 디비 보안프로그램에 의해 방화벽을 뚫지 못하는 상황이 되었다.

 ㅇ 그래서 DBSafer를 우회할 수 있는 방법을 모색하였다.

 ㅇ 방법은 서버에서 디비로 접속하는 방법이었다.

 

 

ㅁ mysql cli를 통한 Kill 쿼리 실행

mysql -h prd-***-db.cluster-ro-***.ap-northeast-2.rds.amazonaws.com -u *** -p

 ㅇ 일단 kill 처리하여 급한 불은 끈 상태였다.

 ㅇ 이후 롱쿼리에 대해 분석 시

     CloudWatch의 RDS CPU 부하와 Whatap의 지표가 상이해서 다른 방법이 없는 지 개선점을 찾아보았다.

 

 

ㅁ CloudWatch slowquery 확인 방법

 ㅇ CloudWatch > 로그 그룹 으로 이동한다.

 

 

 ㅇ 롱쿼리의 상세 정보를 확인할 수 있었다.

 ㅇ 시간이 UTC여서 계산이 필요하였지만, 그래도 확인이 가능하였다.

 ㅇ 출발 IP를  확인한 결과, 시스템이 아닌 운영자 중 한명이 테이터 확인 과정에서 롱쿼리를 발생한 것이다.

 

 

ㅁ RDS 성능 개선 도우미 도입 시 요금 확인

 ㅇ AWS에서는 RDS를 모니터링하는 방법으로 RDS 성능개선 도우미를 제공하고 있다.

 ㅇ 문제는 요금인데 조사한 결과 7일 동안의 성능 데이터 기록은 무료였다. 

 ㅇ 사용하지 않을 이유가 없어서 도입하기로 하였다. 

 ㅇ 성능 개선 도우미 요금 페이지는 여기

 

 

ㅁ RDS 성능 개선 도우미 도입 시 서비스 영향도 분석

 ㅇ 도입 시 서비스에 영향을 주어서는 안되었기 때문에 도입 과정에 대해서 알아보았다.

 ㅇ 성능 개선 도우미 설정 및 해제 페이지는 여기

DB 인스턴스 또는 다중 AZ DB 클러스터를 만들 때 성능 개선 도우미를 활성화할 수 있습니다. 필요한 경우 나중에 에서 비활성화할 수 있습니다. 성능 개선 도우미를 활성화하거나 비활성화해도 가동 중지, 재부팅 또는 장애 조치가 발생하지 않습니다.
성능 개선 도우미 에이전트는 DB 호스트에서 제한된 CPU 및 메모리를 사용합니다. DB 로드가 높을 경우 에이전트는 데이터 수집 빈도를 줄여 성능에 미치는 영향을 제한합니다.

 

 ㅇ AWS 페이지에서 인용한 부분인데, 적용 시 재부팅 또는 장애조치가 필요하지 않다고 한다.

 ㅇ 그리고 시스템 부하 시 자동적으로 데이터 수집 빈도를 줄여 시스템에 영향을 최소화하도록 설계되어 있었다.

 

 

ㅁ RDS 성능 개선 도우미 적용

 ㅇ 적용 대상이 되는 RDS 인스턴스의 수정 페이지로 들어갔다.

 

 

 ㅇ 7일로 보존기간을 설정하면, 프리 티어 곧 무료임을 안내하고 있다.

 ㅇ 현재 에러 로그, 느린 쿼리 로그를 보고 있고 이전에 보았던 slowQuery가 바로 느린 쿼리 로그를 체크해 두었기 때문이다.

 ㅇ 적용하기까지 시간은 10분정도 소요되었다.

 

 

 

ㅁ 성능개선 도우미 지표 들어가는 방법

 ㅇ 성능개선 도우미 적용 완료를 기다리는 중에 현재 활동이 바뀐 것을 확인하였다. 

 ㅇ 못보던 지표여서 잠시 당황했었지만, 클릭하니 성능개선 도무미로 이동하였다.

 

 

 

 ㅇ 카운터 지표를 통해 시스템 전체 부하에 대한 지표를 얻을 수 있었다.

 ㅇ 초당 리드하는 Row의 비율을 통해 시간이 지나면서 통계 쿼리로 인해 부하가 증가하는 것을 알 수 있었다.

 ㅇ 슬라이스 기준에서 SQL를 선택하면 전체 시간에서 부하가 발생하는 쿼리를 가시적으로 볼 수 있었다.

 

 

 

 ㅇ 상위 SQL의 지표를 통해 쿼리에 대한 상세정보를 얻을 수 있었다.

 ㅇ가장 부하가 발생하는 쿼리를 분석하여 투닝을 할 경우 RDS성능을 개선할 수 있는 것이다.

 

 

ㅁ 함께 보면 좋은 사이트

 ㅇ Amazon RDS의 성능 개선 도우미 개요

Amazon RDS의 성능 개선 도우미 개요 - Amazon Relational Database Service

ㅇ 성능개선 도우미 설정 방법

성능 개선 도우미 설정 및 해제 - Amazon Relational Database Service

ㅇ 성능개선 도우미 요금 

Amazon RDS 성능 개선 도우미 요금 | 클라우드 관계형 데이터베이스 | Amazon Web Services