Question
본사에서 사용하고 있는 Amazon RDS DB 인스턴스 중,
특정 인스턴스가 CPU 사용률이 지속적으로 다른 DB 인스턴스보다 높고, 활성 세션 또한 높습니다.
평상시에도 CPU 사용률이 40~90% 정도이고, 활성 세션도 경계선을 자주 넘어가고 있습니다.
현재 사용하고 있는 DB 인스턴스 타입을 t3.medium에서 t3.large로 변경하였음에도 불구하고
큰 변화가 보이지 않고 있어서 원인이 무엇인지, 어떻게 조치해야 하는지 조언이 필요합니다.
Answer
활성 세션이란?
"활성 세션"이란 현재 DB 인스턴스와 연결되어 있는 connection 수 입니다.
(DB 엔진 작업을 제출하여 현재 응답 대기 중인 연결 세션)
예를 들어, DB 엔진에 SQL 쿼리를 제출하면 엔진에서 이 쿼리를 처리하는 동안 해당하는 데이터베이스 세션이 활성화됩니다.
해당 connection은 DB 인스턴스로부터 쿼리 결과를 전달 받으면 connection을 끊습니다.
따라서, 활성 세션은 DB 인스턴스로부터 쿼리 결과를 전달 받기 위해 대기 중인 connection입니다.
성능 개선 도우미에서 볼 수 있는 AAS(평균 활성 세션)이란 단위 시간 동안의 평균 connection을 의미합니다.
짧은 시간 동안 connection의 생성과 끊어짐이 여러 번 일어나기 때문에 성능 개선 도우미에서는 단위 시간 동안의 평균 connection 수를 측정하여 제공합니다.
DB 인스턴스의 vCPU
DB 인스턴스는 타입 별로 할당된 최대 vCPU 개수만큼 활성 세션을 동시에 처리할 수 있습니다.
즉 말씀하여 주신 변경한 DB 인스턴스 타입인 t3.large의 vCPU 최대 개수는 2개이므로
활성 세션이 2개가 넘어가면 큐에 쌓이고 대기하게 됩니다.
트래픽이 증가하면 connection이 증가하기 때문에 하나의 connection이 처리되는 데 오랜 시간이 걸린다면
활성 세션의 수가 늘어나 그 만큼 시스템이 느려집니다.
활성 세션의 수를 낮게 유지하려면 DB 인스턴스에 생기는 connection의 수를 낮추고
하나의 connection의 처리 시간을 짧게 유지하는 것이 중요합니다.
캐시 서버를 이용하면 DB에 걸리는 부하 자체를 줄여 connection의 수를 낮출 수 있습니다.
그리고 상위 SQL 차트에서 상위에 표시되는 SQL 쿼리 문에 적절한 index를 걸어 쿼리 실행 시간을 단축시켜 connection의 처리 시간을 짧게 할 수 있습니다.
DB 인스턴스 타입 변경
t3.medium 에서 t3.large로 변경하였다고 말씀하여 주셨는데,
아래와 같이 두 모델의 최대 vCPU가 동일하기 때문에 활성 세션 수치에 변화가 보이지 않는 것입니다.
참조 링크:
[1] Amazon RDS 인스턴스 유형 -
https://aws.amazon.com/ko/rds/instance-types/
권고 사항
1. m5로 DB 인스턴스 타입 변경
현재 평균 CPU 사용량 또한 높기 때문에 하드웨어적으로 커버를 할 수 있도록 DB 인스턴스 타입을 m5로 바꾸시는 방법이 있을 수 있습니다.
2. 스토리지 유형 변경
해당 DB 인스턴스의 스토리지 유형이 범용 SSD(gp2)라면
스토리지 유형을 Provisioned IOPS로 변경하시거나 스토리지 용량을 늘리는 방법이 있을 수 있습니다.
빠르고 일관적인 I/O 성능이 필요한 프로덕션 애플리케이션의 경우에는
프로비저닝된 IOPS 스토리지를 권장합니다.
프로비저닝된 IOPS 스토리지는 성능이 예측 가능하며,
일관적으로 지연 시간이 짧은 스토리지 유형입니다.
이는 일관적인 성능이 필요한 온라인 트랜잭션 프로세싱(OLTP) 워크로드에 이상적일 뿐만 아니라
해당 워크로드의 성능 튜닝에도 효과적입니다.
참조 링크:
[2] 프로비저닝된 IOPS SSD 스토리지 -
https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/CHAP_Storage.html#USER_PIOPS
위 내용 관련하여 궁금증이 해결되지 않으셨거나,
추가 문의 사항이 있으시면 저희 고객 지원 포털에 문의 남겨주시기 바랍니다.
