탑 스택 분석
애플리케이션 모니터링
Java 웹 애플리케이션의 성능을 최적화 할때 우리는 어떤 메소드에 집중해야 할까요? 1초 걸리는 A 메소드를 0.1초로 줄이는 것과 0.5초 걸리는 B메소드를 0.4초로 줄이는 일 중 우리가 집중해야 하는 일은 무엇일까요? 메소드의 개선 속도만 생각한다면 A 메소드를 살펴봐야 합니다. 하지만 하루에 A 메소드가 100번 호출되고 B 메소드는 100,000번 호출된다면 A 메소드를 개선하면 하루에 90초(0.9초 x 100회)를 아낄 수 있고 B 메소드를 개선하면 하루에 10,000초(0.1초 x 100,000)를 아낄 수 있습니다. 이렇게 메소드의 호출 빈도는 애플리케이션 속도 개선작업의 핵심이라 할 수 있습니다.
탑 스택 확인
애플리케이션 모니터링 서비스에서 제공하는 탑 스택 분석 기능을 사용하면 쉽게 Java 웹 애플리케이션에서 사용되는 메소드의 사용량을 확인할 수 있습니다. 탑 스택 분석은 트랜잭션의 스택 정보를 수집하여 실행중인 메소드의 사용량 통계를 제공합니다. 스택의 최상단의 사용량 통계를 통해 서비스에 가장 많은 영향을 주는 메소드를 확인을 통해 CPU 또는 메모리에 부하가 걸리는 원인을 분석할 수 있습니다. 우선 탑 스택 분석은 A 메소드가 15회 호출되고 D 메소드가 5회 호출되었다면 아래와 같이 보여줍니다.
위에 예시는 설명상 간단하게 이야기 했지만 실제 서비스에서는 좀더 복잡한 구조로 나타나게 됩니다.
와탭 애플리케이션 모니터링 > 분석 > 탑스택메소드 호출자 확인
실행중인 메소드를 호출한 상위 메소드를 보고 싶다면 해당 메소드를 클릭하면 됩니다. 해당 메소드를 실제 호출한 메소드를 비율로 분류하여 보여줍니다. 예를 들어 A 메소드가 실행중이고 B 메소드가 A 메소드를 3번 호출했고 C 메소드가 A 메소드를 2번 호출했다면 B 메소드는 60% C 메소드는 40%를 점유한 것으로 표시됩니다.
메소드를 호출한 하위 스택들을 비율 순서로 살펴볼 수 있습니다
와탭 애플리케이션 모니터링 > 분석 > 탑스택 > 스택 클릭통계 기반의 스택 분석의 정확성
와탭 애플리케이션 모니터링 서비스는 매 10초마다 트랜잭션의 스택정보를 수집합니다. 예를 들어 초당 트랜잭션이 1tps인 서비스라면 하루에 8,640번(24시간*60분*6회)의 스택 정보가 수집된다고 생각할 수 있습니다. 초당 100tps인 경우 10초 마다 100개의 트랜잭션을 분석할 수 있습니다. 그렇다면 와탭 애플리케이션 모니터링 서비스는 하루 864,000개의 스택을 분석하게 됩니다. 실제로 초당 100건의 트랜잭션을 발생시키는 와탭 데모 사이트의 경우 하루 쌓이는 스택의 개수는 약 100만건입니다.
모수가 충분한 상황에서 99% 신뢰수준일 경우를 구하는 식은 아래와 같습니다.
2.54 × 루트(0.25/n) × 100
엑셀에서는 아래와 같은 식으로 나옵니다. n은 표본수입니다.
2.54*SQRT(0.25/n)*100
위 식에서 와탭의 데모사이트에서 보여주는 표본수 1,000만건일때 허용오차는 0.04%입니다. 10초마다 하나의 스택만 검사하는 것을 가정해서 표본수가 8,460개일 경우에도 허용오차는 1.3%에 불과합니다. 그러므로 표본수가 10,000개이상 쌓이는 서비스인 경우 탑스택의 사용율 정보는 99% 이상 정확합니다.
탑 스택을 통한 서비스 성능 튜닝
위에서 이야기 했듯이 탑 스택 통계는 충분히 많은 데이터를 가지고 판단하는 것이 좋습니다. 따라서 하루 단위의 스택을 조회하는 것을 추천합니다. 탑 스택은 튜닝 시 인지 하기 힘들었던 부분의 튜닝 포인트를 찾아내는 것에 유용합니다. 가장 빈번하게 나타난 스택은 현재 애플리케이션 서버에서 가장 많은 부하를 발생하는 것이라고 판단 할 수 있습니다. 안정적인 애플리케이션 서버일지라도 빈번하게 나타난 스택은 성능 저하를 일으킬 수 있으므로 탑스택에 나타나는 메소드 순위에 변화가 있다면 해당 메소드에 대한 최적화를 고민하는 것이 좋습니다.
데이터 기반의 리팩토링
리팩토링은 가독성을 높이고 디자인을 변경함으로써 향유 유지 보수 비용을 절약할 수 있지만 비지니스와 분리되어 있는 KPI로 인해 많은 개발자들이 리팩토링을 시간 외 작업으로 진행하기도 합니다. 하지만 탑 스택을 통해 서비스 성능에 연관된 메소드를 리팩토링 해보는건 어떨까요. 내부 코드 효율화 뿐만 아니라 서비스 성능 개선이라는 비지니스에 연관된 성과도 만들어 낼 수 있습니다.
