1. Business Transaction을 통해 문제가 되는 Database Query 찾아내기

by NeO posted May 02, 2018
?

단축키

Prev이전 문서

Next다음 문서

ESC닫기

크게 작게 위로 아래로 댓글로 가기 인쇄

본 문서는 다음 문서를 번역한 글입니다.


총 2개의 글로 이루어진 이번 연재는 AppDynamics Global Services team의 John Aronson이 작성한 글로, Database 성능 개선을 위한 AppDynamics 활용법이 설명되어 있습니다. 글이 조금 깁니다.

https://blog.appdynamics.com/product/the-appd-approach-how-to-identify-problematic-database-queries-with-business-transactions/


The AppD Approach: How to Identify Problematic Database Queries with Business Transactions

 

Business Transaction을 사용하여 가장 중요한 어플리케이션 기능의 성능 최적화에 집중하자

 

항상 그러하듯이, 어플리케이션의 성능 저하를 알려주는 health rule이 경고 알람을 엔지니어에게 전달하는 것으로부터 시작합니다. 이제 우리는 사용자가 문제상황을 인지하기도 전에 문제를 해결하기 위한 시간싸움이 시작됩니다.

 

한가지 검증된 방법은 바로 데이터베이스 쿼리 최적화입니다. 그렇다면 어떤 쿼리를 최적화해야 하는지 어떻게 알 수 있을까요? 그리고 최적화변경이 이슈에 어떤 영향을 미쳤는지 어떻게 알 수 있을까요? 2개의 포스트로 이루어진 이 글은 모든 개발자가 알아야 할 쿼리 최적화에 대한 몇 가지 이야기를 다룰 것입니다. 오늘은 AppDynamics Database Visibility 라이선스 없이 Business Transaction만을 사용하여 도움이 될 수 있는 내용에 대해 이야기 합니다.

 

Business Transaction의 장점은 어플리케이션을 기능별로 검토할 수 있게 해준다는 점입니다. 따라서 어플리케이션의 주요 기능을 최적화하는 데 주력하고 다른 부분에 허비하지 않아도 된다는 장점이 있습니다. 또한 Business Transaction의 성능은 동적인 베이스라인(Dynamic baseline)에 의해 구분되므로 최적화 전후의 응답시간을 비교할 수 있어 사후 평가에 대한 노력을 절감할 수 있습니다.

 

아래 예에서 eCommerce 앱의 Checkout 기능에 속도 저하가 발생한 것을 볼 수 있습니다. 여기서부터 문제를 파악해 봅시다. Flow map에서 여러분은 평균 응답시간이 평소보다 많이 느리다는 것을 알 수 있습니다. 응답시간은 일반적으로 0.5초였던 데에 반해 현재는 10초에 이르고 있고, 최근 1분의 평균 응답속도는 4.6초로 기록되어 있습니다.


DB1-1.png


또한 Transaction Performance health rule 역시 위반되었음을 알 수 있습니다.


DB1-2.png


Transaction Scorecard에서 응답속도 증가와 더불어 느린 트랜잭션의 수가 함께 증가하는 것을 볼 수 있습니다.


DB1-3.png


주의: 여기에서 에러를 볼 수 있지만, 이 에러가 고객에게 영향을 미치는 에러가 아님이 미리 확인되었습니다.


모든 확인 과정은 성능에 문제가 있음을 명확하게 하기 위함입니다. 이제 우리는 이 트랜잭션에 문제를 일으키는 부분을 찾아 고쳐야합니다. 다시 flow map으로 돌아와 potential 영역을 보면 문제의 잠재적 원인인 데이터베이스 호출시간이 전체 트랜잭션시간의 많은 부분을 차지하고 있음을 알 수 있습니다.


DB1-4.png


JDBC 호출을 드릴다운하면 이 트랜잭션에서 40%의 호출이 특정 데이터베이스를 호출하고 있음을 알 수 있고, 평균 8.1초가 소요되고 있음을 알 수 있습니다. 이것은 다시 말하자면, 86%Checkout Business Transaction XE-Oracle 데이터베이스를 호출하는 데에 소요됨을 말합니다.


DB1-5.png


다음으로 생각해볼 내용은 쿼리 최적화입니다. 이상적인 최적화를 위해 가장 오래 걸리는 호출/SQL 문에 집중해보겠습니다. AppDynamics에서 스냅샷 창을 열어 오류가 없는 트랜잭션을 선택하고 우클릭하여 팝업창을 띄워 “Identify the most expensive calls / SQL statements in a group of snapshots”를 선택합니다.


DB1-6.png


AppDynamics는 모든 스냅샷을 비교하여 그룹에서 가장 느린 쿼리와 메소드를 비교합니다. 이제 데이터베이스를 기다리는 동안 어플리케이션이 어떻게 동작했는지 볼 수 있습니다.


AppD는 쿼리문 전체와 느린 쿼리에 대한 응답속도를 보여줍니다. 그리고 어플리케이션의 중요한 기능에서 쿼리가 반복 호출되어 어플리케이션을 느리게하는 원인이 되었음을 보여줍니다.


DB1-7.png


만일 AppDynamics Database Visibility license를 가지고 계시고, DB agent를 설정했다면 AppD는 데이터베이스 관점에서 쿼리 성능을 보여줍니다. 먼저 1과 같이 Databases로 이동하고 2Queries탭을 눌러 데이터베이스의 쿼리 성능을 봅니다.


DB1-8.png


이 화면은 데이터베이스 system table에서 직접 가져온 메트릭으로 스냅샷 데이터에 국한된 데이터는 아닙니다. 여기서 여러분은 해당 쿼리에 대한 데이터베이스에서의 전체 호출에 대해 볼 수 있으며 여기에는 스냅샷형태로는 저장되지 않은 빠른 트랜잭션의 호출도 포함되어 있습니다. 더 자세한 내용을 살펴보기 위해 쿼리를 드릴다운 할 수 있습니다.

DB1-9.png


마지막으로 Cached plan을 더블클릭하면 execution plan을 볼 수도 있습니다. 이제 여러분은 성능을 저하시키는 것이 쿼리의 어떤 부분인지 알 수 있습니다.


DB1-010.png



일부 개발자들은 Database Queries 화면을 통해 쿼리 최적화를 시작하고자 합니다. 비록 이 화면만으로는 특정 쿼리가 일으키는 비즈니스 영향에 대한 모든 내용을 파악할 수 없지만 데이터베이스에 미치는 영향을 알 수 있는 좋은 방법입니다.

 

만일 이 접근 방법을 선호하는 경우, 여러분은 지금 보고 계시는 쿼리 성능이 Metric Browser에 저장되지 않는다는 점을 유의해야합니다. 변경을 적용하기 전의 시간범위를 설정하고 작업 | 내보내기 기능을 사용하여 쿼리의 이전 동작에 대한 보고서를 가져옵니다. 변경 사항이 적용된 후 다시 내보내기와 조회기능을 통해 최적화 작업의 영향을 측정할 수 있습니다.

 

여러분의 database의 메트릭을 수집하는 DB에이전트가 구성되지 않았다고 하더라도 여러분은 Business Transaction성능을 관찰하여 최적화 작업의 영향을 판단해볼 수 있습니다. 변경 전후의 응답시간은 6-21초에서 0.5초대로 감소하였으며 평균 응답시간이 3.3초 감소함을 알 수 있습니다.


DB1-011.png


이 글에서 우리는 트랜잭션의 성능에 영향을 미치는 단일 데이터베이스 쿼리를 격리하고 복잡한 트랜잭션을 분석했습니다. 다음 글에서는 Service End Point를 사용하여 중요한 데이터베이스 쿼리를 모니터링하는 방법을 모색해보겠습니다.


Who's NeO

ALM, SW 모델링, SW 정적분석, Devops 특히 CI/CD, APM을 통한 Shiftleft에 관심이 많습니다. 

차세대 APM Cisco AppDynamics와 모바일 앱 모니터링 VMware Apteligent를 소개합니다.

http://www.solulink.co.kr