2. Service Endpoint를 활용한 Database 성능 모니터링

by NeO posted Jun 21, 2018
?

단축키

Prev이전 문서

Next다음 문서

ESC닫기

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

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


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

https://blog.appdynamics.com/product/the-appd-approach-database-monitoring-with-service-endpoints/


미션크리티컬한 DB쿼리의 성능을 보장하는 Service Endpoint 활용법

 

APM을 통한 SW 최적화를 가이드하면서 저는 파레토 법칙으로 알려진 80/20의 법칙이 일의 우선순위를 매기는 데에도 잘 들어맞는다는 것을 알았습니다. 고쳐야하는 문제 중 80%는 매우 간단히 고칠 수 있고 일단 고치기만 하면 다시 정상적으로 돌아오는 문제였습니다. 반면에 20%의 문제는 지속적인 관리가 필요했습니다. 그리고 이 20% 문제 중에 미션크리티컬한 이슈가 포함된다면 일은 더 힘들어집니다. 이런 예로 여러 개의 테이블을 조회하는 쿼리라든가 스키마와 인덱싱, 테이블 row 카운트 변경으로 인한 역-최적화현상이 일어나는 것이 있을 수 있겠습니다. 또는 데이터베이스 외부에서도 예를 들어 개발자가 정기적으로 접근하는 핵심 코드의 시퀀스에 문제가 있을 수 있으며 이것이 문제를 완벽히 파악하는 데에 어려움을 줍니다. 만일 이런 문제를 가지고 계시다면, 쿼리나 코드의 성능을 지속적으로 주시하고 있을 필요가 있으며 과거의 성능과 대비해 현재 어떻게 동작하고 있는지 쉽게 비교가능해야 합니다. 또한 여러분은 성능이 저하되었음이 감지되었을 때 AppDhealth rule을 통해 즉각적으로 알람을 받고 싶을 수도 있습니다. 이 포스트에서는 Service Endpoint를 어떻게 사용할지에 대해 이야기 해 보겠습니다.

 

우선 가장 최근에 문제가 발생한 트랜잭션에 대해 수집된 스냅샷의 리스트를 보아야 합니다. 데이터베이스 모니터링에서 “Slow Response Times” 화면을 보는 것이 좋은 시작점입니다.

 

1. 왼쪽 네비게이션 바에서 Troubleshoot을 확장합니다.

2. 왼쪽 네비게이션 바에서 “Slow Response Times”를 선택합니다.

3. “Slowest DB & Remote Query Times”탭을 선택합니다.

4. JDBC 타입의 호출을 필터링합니다.

5. 리스트에서 쿼리를 선택하고 “View Snapshots”를 클릭합니다.


DB2-01.png


파란색 파일 모양이 있는 전체 콜 그래프 데이터가 포함된 스냅샷을 선택합니다.


DB2-02.png


쿼리를 호출하는 스냅샷 세그먼트를 찾고, 쿼리를 수행하는 메소드를 콜그래프에서 찾아 우클릭하면 “Configure Instrumentation for this Class/Method”를 선택할 수 있습니다.


DB2-03.png


Service Endpoint 다이얼로그에서 엔드포인트의 이름을 지정합니다.


DB2-04.png


만일 데이터에 접근하는 클래스가 단일 클래스라면 이 작업이 전부입니다. Data Access Object 클래스에서 각 쿼리에 접근하는 클래스와 메소드가 하나뿐인 경우입니다. 여기에서 우리는 다음과 같이 어떤 타입의 쿼리에서도 사용가능한 쿼리 클래스가 있습니다.


DB2-05.png


이 경우 AppDService Endpoint를 분할하여 처리할 수 있습니다. Service Endpoint 다이얼로그로 되돌아가 “Transaction Splitting” 탭을 변경하십시오. 체크박스를 선택하고 object 인스턴스와 getter chain을 사용하여 분할합니다. Getter 스트링을 넣어 쿼리 스트링의 첫번째 부분에 접근가능하게 설정하고 Create Service Endpoint Definition을 누릅니다.


DB2-06.png


이제부터 여러분은 Service Endpoint에서 해당 쿼리의 퍼포먼스를 추적하고 UI에서 health rule을 만들 수 있게 되었습니다.


일련의 작업은 Service Endpoints리스트에서 확인할 수 있는 새로운 아이템을 저장하는 방법입니다. Service Endpoint는 여러분으로 하여금 쿼리 호출과 평균 응답속도, 에러 카운트를 실시간으로 볼 수 있게 해주고 지정한 이 순간부터 과거와의 성능 비교를 가능하게 해줍니다.


DB2-07.png


또한 메트릭 브라우저에서 메트릭의 그룹을 새로 만들어 health rule의 데이터소스로 사용할 수도 있습니다. 예를 들어 만일 이 이후에 쿼리에 연관된 메소드의 평균 응답속도가 100ms(또는 쿼리에 기대되는 특정 수치)를 넘는다면 이를 알려주는 health rule을 만들 수도 있을 것입니다


DB2-08.png


DB2-09.png


다음부터 쿼리에 문제가 발생하면, AppD는 쿼리시간이 느려진 현상을 능동적으로 알려줄 것입니다. 일차 응답자는 상태 규칙 위반(health-rule violation)을 우측상단의 이벤트 리스트에서 볼 수 있습니다. 쿼리 시간에 대한이 정보가 문제의 근본 원인과 결정적인 연관성이 있는 것으로 밝혀지면 상태 규칙 위반을 쿼리 담당 팀에게 직접 보내는 정책을 만들 수도 있습니다. 이 방식의 자동화 프로세스는 근본 원인에 대한 논의가 시작되기도 전에 해결책으로 이어지게 도와줄 수 있습니다.

 

본 포스트에서 설명한 바와 같이 Service Endpoints를 사용하면 업무상 중요한 데이터베이스 쿼리를 훨씬 쉽게 모니터링 할 수 있습니다. 이전에 기고한 "How to Identify Problematic Database Queries with Business Transactions"에서 설명한 바와 같이 데이터베이스 모니터링 중에 나타날 수 있는 문제의 우선 순위를 정하는 데 도움이 되므로 어플리케이션에서 가장 중요한 코드 최적화에 집중할 수 있습니다. 비즈니스 트랜잭션과 서비스 엔드 포인트는 함께 어플리케이션 성능을 보장하는 두 가지 훌륭한 도구입니다.