[한승민]Top down 방식이 아닌 Thread 단위의 트랜잭션 개별 분석 방법

인터맥스 팀에 합류하면서 WAS 성능관리 영역에 들어선지도 벌써 8개월이라는 시간이 흘렀다. 뭣도 모른 채 성능관리의 영역을 넓혀 보자는 막연한 생각만을 가지고 시작한 WAS 성능관리를 접하며 느낀 Oracle 성능 분석과 WAS 성능 분석의 차이점에 대해서 이야기 해 보려고 한다. 어디까지나 짧은 경험과 지식에 의한 견해이므로 잘못된 부분이나 오류가 있으면 가차없이 질타를 가해 주시기 바란다.

“Top down 방식이 아닌 Thread 단위의 트랜잭션 개별 분석 방법”

 위의 한 줄이 WAS 성능 분석 방법과 Oracle성능 분석 방법의 가장 큰 차이점을 가장 잘 표현하는 문장이 아닐까 싶다. Oracle 성능 분석 방법에 Top down 방식을 적용할 수 있는 가장 큰 이유는 DB의 상태를 보여주는 각종 stat 정보와 수 년간 발전해온 wait interface 덕분이라 해도 과언이 아닐 것이다. 그리고 Oracle 성능 이슈의 대부분이 트랜잭션 간의 동기화 문제로 인해 발생한다는 것도 Top down 성능 분석을 가능케 한 원인이라고 할 수 있겠다. DB의 전체 상태를 보여주는 stat 정보를 통해 어느 부분에 성능 이슈가 있는지 찾아내어 파고 들어가는 방식은 이제 DB 성능 분석을 약간이라도 접해 본 사람이라면 누구나 공감하는 이야기 일 것이다.

이에 반해 WAS 성능 분석 방법은 Top down 방식이 아닌 thread 단위의 트랜잭션 개별 분석 방법을 사용해야 한다. 이러한 차이는 JVM 상에서 동작하는 thread 들이 특별한 몇 경우를 제외하고는 개별적으로 자원을 할당 받고 서로에게 영향을 주지 않으면서 자기에게 주어진 트랜잭션 만을 수행하는 데에서 발생한다.

Oracle DB는 Data Storage 라는 목적에 맞추어 저장되어 있는 데이터를 여러 사용자들이 공유하며 사용할 수 있도록 데이터 동기화에 중점을 두어 모든 작업이 수행 되는 것에 비해 WAS 는 자원을 이용하는 개별 application의 집합체 이기 때문에 각각의 application 은 서로에게 영향을 미치지 않으면서 각각 원하는 결과만을 도출 하면 되는 방식으로 운영되는 것이다. 따라서 WAS 성능 분석 방법은 thread 단위의 트랜잭션 각각에 대해서 접근이 이루어 저야 하는 것이 옳다고 볼 수 있다. 대부분의 트랜잭션이 빠른 응답시간을 보인다 하더라도 한 두 개의 잘못 작성된 어플리케이션에 의해 장시간 수행되는 트랜잭션이 존재한다면, 그리고 해당 트랜잭션이 사용자가 빈번하게 수행하는 업무에 해당한다면 트랜잭션 개별 분석 방법이 아니고서는 문제를 해결하는 데에 많은 시간과 노력을 필요로 할 것이고 제대로 된 결론을 도출 할 수 있을지 여부도 장담 할 수 없을 것이다.

이러한 DB와 WAS 구동 방식의 차이점과 성능 분석 방법의 차이점을 모두 알고 전체적인 서비스 관점에서의 성능 관리를 수행할 수 있다면 이는 3-tier 웹 서비스 환경에서 그 동안의 DB, WAS 개별 성능 관리를 하는 데서 오는 비 효율성 및 한계점을 극복할 수 있는 좋은 대안이 될 것이다. 인터맥스를 통해 이러한 성능분석 방법이 널리 전파되고 실제 운영 환경에 보다 나은 성능을 제공하는 토대가 될 수 있다면 그것 만으로도 우리의 새로운 도전은 성공한 것이라고 생각한다. 그리고 하루빨리 그 결실을 보고 싶은 마음 또한 간절하다. 진정한 웹 서비스 성능 개선을 위해..