세션명
Diagnose & resolve performance issues with Amazon RDS
강연자
Maxym Kharchenko, Pini Dibask
핵심 내용 요약
- Overview of monitoring in Amazon RDS
- Performance Monitoring
- Performance troubleshooting
세션 요약자
베스핀글로벌 PS 본부 D&A실 반지현 님
Overview of monitoring in Amazon RDS
Amazon RDS는 크게 세 가지 레벨에서 모니터링을 합니다.
1) Instance Level
인스턴스 레벨에서 주요하게 사용하는 모니터링 솔루션은 Amazon Cloudwatch입니다. 이를 통해 인스턴스 수준의 CPU 사용량, 스토리지 IOPS, 네트워크 사용률 등을 파악할 수 있습니다.
2) Operating system Level
인스턴스 레벨보다 한층 os 레벨에 가까운 모니터링이 필요할 수 있습니다. aws에서는 Amazon RDS Enhanced Monitoring을 활용할 수 있습니다. 예를 들어, 리눅스의 HugePage 스왑량, 프로세스 / 스레드 모니터링 등이 있습니다.
3) Database Engine Level
Database 내부의 SQL 분석, SQL 사용량, Wait Event 및 통계정보 등에 대한 모니터링이 해당 수준입니다. AWS에서는 Amazon RDS Performance Insight를 메인으로 사용하고, 부수적으로 DevOps Guru for Amazon RDS를 활용할 수 있습니다. 특히, DevOps Guru 의 경우 ML을 활용해 성능 업데이트를 위한 권장사항, 필요한 내용에 대해 내용을 받을 수 있으며, 더 능동적으로 관리할 수 있습니다.
각 Monitoring Service에 대한 설명
1) Cloud Watch
클라우드워치에서는 임곗값을 설정하고, 특정 임값을 넘어설 경우 이를 알람으로 받을 수 있는 wizard가 따로 있습니다. 임곗값을 설정할 때는 그동안의 Min/Max 값, Count값, Sum값 등의 통계자료를 바탕으로 설정할 수 있습니다.
ML을 사용하여 그동안의 값들을 능동적으로 체크하여 해당하는 임계값 또한 정적이 아니라 동적으로 바꿔서 설정할 수 있습니다. 그동안의 수치들을 시간별, 일 별, 주 별 패턴을 토대로 능동적으로 학습하고, 이를 토대로 예상 범위를 산정합니다.
아래 Read IOPS 패턴을 예시로 보면, 그동안의 학습내용을 토대로, 예상되는 Read IOPS의 값을 밴드 형태로 보여주는 것을 확인할 수 있습니다.
2) Enahanced Monitoring
Process List, swap 양, 프로세스 / 스레드를 분석하는 데 용이하며, Amazon RDS에 최적화되어 있는 솔루션입니다. 하이퍼바이저 레벨이 아니라 인스턴스 레벨에서 직접 데이터를 Local 에이전트로 가져옵니다. 디폴트 수집 기간은 1분이며, 최대 1초 단위로 변경이 가능합니다.
3) Performance Insight
DB Engine 레벨에서 쿼리, 워크로드 등 한층 깊게 더 들여다 볼 수 있는 솔루션은 Performance Insight 입니다. 개발자와 DevOps 엔지니어 등 얕은 DB 기술 지식을 가지고 있는 사람들도 충분히 PI를 통해 wait event, lock 정보 등 상태를 쉽게 파악할 수 있습니다.
What is database load?
db의 워크로드는 현재 db에 물려있는 세션(active sessions)들이 sql을 수행할 때 발생하는 부하를 말합니다. 그중에서도 명확히 이들을 파악할 수 있는 것은 Wait event입니다. 이 wait event는 성능의 병목현상의 근본적인 원인을 명확하게 파악할 수 있는 것입니다.
단적으로 이 wait event를 파악함으로써 다른 sql들이 왜 기다리고 있는지(waiting) 파악할 수 있습니다. I/O Latency일 수도 있고, 다른 서브 시스템으로부터 발생하는 Commit Latency일 수도 있고, 보편적으로 Lock에 의해 대기가 발생할 수도 있습니다. Performance Insight는 이런 wait event를 찾게 도움을 줍니다.
Performance Insight는 초마다 찍힌 내용을 바탕으로 일관성 있는 db 워크로드를 보여주며, 그 사이에 데이터 정보를 누락할 확률은 매우 낮고 정확도는 매우 높습니다.
다음의 사진을 보면, vCPU는 점선으로 표기된 8인데, 병목(Bottleneck)과 여타 다른 wait event들에 의해 평균 active session이 8 이상인 10으로 표기된 것으로 보입니다. 이는 인스턴스 타입을 vCPU가 10인 타입으로 맞출 필요가 있습니다.
Amazon RDS performance monitoring을 통해 인스턴스 타입 조정 가능
아래 사진의 두 사례는 모두 vCPU의 크기 조정이 필요한 사례입니다. 위 사진의 경우, vCPU 16인 경우보다 실제 사용하는 양이 현저히 낮아 인스턴스 타입을 Downsizing 해야 합니다.
반대로 아래 사진의 경우, 실제 vCPU 2인 상황보다 훨씬 더 많은 워크로드가 발생하므로, db performance가 제대로 나오지 않습니다. 따라서, 더 높은 인스턴스 타입으로 변경이 필요합니다.
What’s new in Amazon RDS performance monitoring?
가장 큰 PI의 특징은 기존 Cloudwatch, Enhanced Monitoring, Performance Insight의 모든 정보들을 하나의 콘솔창에서 볼 수 있다는 점입니다. 다른 창으로 넘어갈 필요 없이 모든 차원에서의 DB 정보를 PI 창에서 한 번에 볼 수 있습니다.
100여 개가 넘는 측정 항목들을 하나의 PI로 모아 출력할 수 있으며, 거의 모든 항목들에 대해서 자세하게 파악해 볼 수 있습니다. 또한, 사용자가 보고자 하는 항목들만 묶어서 커스텀하여 대시보드를 만들어낼 수 있습니다.
거기에 특정 항목에 임곗값을 체크할 수 있고, 실제로 그 임곗값을 그려내서 더 정교한 분석을 가능케 합니다.
그리고 계산식을 실제로 집어넣고, 그 계산식에 따른 메트릭을 측정할 수도 있습니다. 예를들어 Cache hit율의 경우, 계산식을 실제로 만들어 Cache hit 율이 얼마나 되는지 다음그림과 같이 실제로 expression 을 넣고 편집해서 그려내고 성능적인 문제들을 파악할 수 있습니다.
그리고 커스텀으로 만든 대시보드를 팀 내 다른 사람들과 공유하기를 눌러 공유해 볼 수 있습니다. 기존까지는 Cloudwatch에서만 알람을 설정하고, 특정 알람을 핸드폰을 받아볼 수 있었지만, 이제는 Performance Insight에서도 알람 설정이 가능합니다.
Performance Insight Report라는 기능이 새로 생겼고, 특정 기간 동안 이 DB가 정상인지 비정상인지 뿐만 아니라 비정상인 상태에서도 어느 정도의 심각성으로 비정상인 상태인지까지 해당 Report 를 통해 한눈에 볼 수 있습니다.
그리고 그러한 특정 상황에서도 문제가 되는 Wait event가 어떤 것이고, 어떠한 상태인지 정말 자세하게 출력해서 보여줍니다.
CPU에 문제가 있거나, 메모리가 문제가 있는지, 아니면 세션이 전체적으로 많이 몰렸는지 등을 볼 수 있고, 해당 Wait event에 연관된 document로 링크로 바로 접속해서 조치할 수 있는 방법을 바로 파악해 볼 수 있습니다.
DevOps Guru 또한 하나의 aws 솔루션이며, 여기서도 Report 를 보고 어느 wait event에 문제가 발생했는지, 자세하게 보여주며 해당 wait event 에 필요한 troubleshooting 문서를 링크로 바로 연결해 필요한 조치를 취할 수 있습니다.
웹사이트 주문 목록 조회 쿼리가 느려지는 현상 Troubleshooting
Online Webstore를 운영하는 곳에서 고객이 웹사이트에 최근 주문한 목록을 보기 위해 클릭을 했고 그에 해당하는 쿼리는 아래와 같습니다. 해당 쿼리를 수행하자 클라이언트 단에서는 굉장히 느린 쿼리로 수행이 되었고, Performance Insight에서는 아래와 같은 비정상적인 그래프가 그려져 전체적으로 비정상적인 상황임을 파악했습니다.
Analyze Performance 화면
PI 화면에서 우측 상단에 Analyze Performance를 클릭하게 되면 다음과 같이 이슈가 되고 있는지를 한 번에 파악할 수 있으며 총 몇 개의 이슈가 있고, 그 wait event는 무엇인지 한 번에 파악할 수 있습니다.
첫 번째로 현재 해당 DB에 몇 개의 이슈가 있는지를 확인하게 됩니다. 그러고 나서 두 번째로 그 문제인 Wait event는 무엇인지를 인지하게 됩니다. 또한, 문제의 원인으로 인해 어떠한 다른 영향(현재의 예시에서는 세션이 밀리는 현상)이 어떻게 되고 있는지 전체적인 문제를 한눈에 파악할 수 있습니다.
그러고 나서 I/O와 관계된 그래프들, 특히 EBS 볼륨과 관계된 I/O를 보면 초기 프로비저닝한 1000 IOPS를 모두 사용하여 더 이상 이 IOPS를 넘지 못하였고, 이로 인해 IOPS로 인한 wait event가 발생하였음을 확인할 수 있습니다.
또한, 비정상적인 그래프들을 추가적으로 확인해 보면 먼저 세션은 급작스러운 Spike가 발생하였고, 이로 인해 Read 하게 되는 Tuples 또한 증가하게 되었으며, 전체적인 트랜잭션과 워크로드 또한 급증했음을 알 수 있습니다.
그러고 나서 다시 Performance Insight를 확인하게 되면, 어떤 쿼리에 문제가 있는지 확인할 수 있습니다. 해당 쿼리는 새로고침하는 쿼리도 아니고, 단순히 최근 주문 목록을 조회하는 쿼리입니다.
Performance Insight에서는 애플리케이션 별로 워크로드를 볼 수 있는 카테고리가 있습니다. 해당 카테고리를 통해 애플리케이션 별로 진행되고 있는 쿼리 및 문제가 발생되고 있는 쿼리를 함께 파악할 수 있습니다.
애플리케이션 별로 모니터링을 진행하면 현재 문제가 되고 있는 쿼리가 무엇인지 바로 확인할 수 있습니다. 그리고 아래 그림과 같이 새로 유입된 call center 라는 애플리케이션의 워크로드 과부하로 문제가 되는 원인 또한 확인할 수 있습니다.
요약하자면, 현재 이슈는 증가한 워크로드 때문에 EBS 볼륨 IOPS 이슈가 발생하였고, 커버할 수 있는 수치를 넘어서게 되었습니다. 그리고 그 원인은 새로 유입된 call center 애플리케이션으로 워크로드가 증가함을 확인할 수 있었습니다. 이에 대한 해결책으로는 총 세 가지의 방법이 있습니다.
첫 번째로, 쿼리를 튜닝해서 바꿔낼 수 있을지 여부입니다. Performance Insight를 통해 확인하면, 해당 쿼리는 모든 수치가 낮습니다. 초당 0.04의 Call과 호출하는 데 1.79 Block만을 Read합니다. 따라서 쿼리를 튜닝해서 얻을 수 있는 효과는 없습니다.
플랜을 보더라도 해당 쿼리에서 튜닝을 통해 드라마틱한 결과를 얻을 수는 없습니다. 거의 모든 수치가 완벽하고, 수정의 여지를 발견할 수가 없습니다.
두 번째로 시도해 볼 수 있는 점은 시스템의 변화입니다. 현재 시스템의 I/O 할당량을 모두 소진한 게 명확하게 보임을 아까의 그래프에서 확인했습니다. 추가적으로 볼륨과 I/O Capacity를 추가함으로써 해결할 수 있을 것입니다. 또한, 클라우드의 가장 큰 매력은 이 작업을 유연하게 수행할 수 있다는 점입니다.
또한, 다른 해결책으로 새로운 데이터베이스(Replica)를 생성하고 쿼리를 분리하는 것입니다. 해당 쿼리는 select 쿼리이고, 따라서 Replica에서 새로 수행할 수 있을 것입니다. 따로 떼어서 별도의 Replica에 select 쿼리를 수행할 수 있도록 조치할 수 있습니다. 아니면 추가적으로 elasticache를 도입하여 전체적인 select가 메모리에서 수행될 수 있도록 조치할 수 있습니다.