<오라클 성능 고도화 원리와 해법1> Ch03-11 End-To-End 성능 관리

오라클 성능 고도화 원리와 해법 1 - Ch03-11 End-To-End 성능 관리

지금까지 설명한 방법들은 모두 오라클 내부에서 발생하는 일량과 시간, 병목 현상만을 측정한다. Elapsed Time으로 대변되는 Response Time도 데이터베이스에 던져진 Call 내에서의 소요 시간만을 측정해 이를 더하는 방식이므로 사용자가 느끼는 Response Time과는 동떨어질 수 있다.

하지만 시스템은 점차 3-Tier 이상의 n-Tier 환경으로 새롭게 구축되어 가는 실정이어서 DB 구간에 대한 분석만으로는 문제를 신속하게 해결하기 어려워졌다. 물론 DB 관리자 입장에서는 DB 문제가 아니라는 사실만 객관적으로 증명해낼 수 있으면 되므로 앞에서 설명한 방법만으로도 충분하다고 느낄 수 있다. 하지만 시스템 전체를 관장하는 입장에서는 전체적인 시각에서 시스템을 바라볼 수 있는 도구가 필요하다.

이러한 요구사항에 발맞춰 End-To-End 방식의 애플리케이션 성능 관리(APM, Application Performance Management) 툴이 많이 도입되고 있는 추세다. 이들 툴을 사용하면 Web, AP, DB Zone으로 나눠 어느 구간에서 병목이 발생하는지를 실시간으로 모니터링할 수 있다. 이미 대규모 SI 프로젝트를 통해 몇몇 툴들이 그 효용성을 검증받았고 점점 활용 범위를 넓혀가고 있다.

데이터베이스 튜닝을 전문으로 하는 컨설턴트 입장에서도 이들 툴을 잘 활용해 업무 효과를 높일 수 있는데, 특히 튜닝 대상 서비스와 SQL 목록을 식별하는 데에 매우 유용하게 사용할 수 있다.

예를 들어, Web, AP, DB 구간을 분석해 성능 저하 요인이 DB로 판명되면, 그림 3-14처럼 시간이 오래 걸린 트랜잭션을 확인하고 해당 트랜잭션에서 수행된 서비스들을 상세 분석한다. 서비스별 수행 시간과 서비스 내에서 수행된 SQL의 수행 시간, 그리고 각각이 전체에서 차지하는 점유율을 함께 보여주기 때문에 성능 저하를 유발한 SQL을 쉽게 찾아낼 수 있다. 그림 3-14 우측 상단 패널에 하이라이트된 DBIO를 보면 전체 일량의 99%를 차지함을 보여주고 있다.

그뿐만 아니라 수집된 성능 자료들이 DB화 되어 있기 때문에 쿼리를 통해 수행 통계를 내고, 집중 튜닝이 필요한 업무 영역과 튜닝 대상 프로그램을 선정하는 데 유용하게 활용할 수 있다.