스택트레이스샘플링을 이용한 성능 분석 _개발자

 IDC 어딘가에 설치되어 있어 기기의 노후화를 잘 알고 있었지만 하드웨어 단위로 할당된 라이선스 정책 때문에 업그레이드도 새로운 장소에 설치하기도 어려운 상황입니다.

가끔 너무 느려지는 응답속도에 속을 끓이는 Y씨(도대체 왜 늦은거야!)회사에서 개발하고 있는 APM을 설치해서 메서드 프로파일을 시도하려고 하지만 곧 좌절하게 됩니다

'어떤 패키지를 설정해야 하지?' '일단 모니터링 해보자!

Y씨는 설치한 APM의 핵심 기능인 X-View 차트에서 Y축 상단에 위치한 트랜잭션을 확인할 수 있었습니다.

X-View 차트의 Y축 상단에 있는 트랜잭션, 기대에 찬 마음으로 차트의 천장을 뚫을 듯한 점을 드래그합니다.

12초 이상의 Not Profiled 영역이 존재합니다.

트랜잭션 끝날 때쯤이면 12초 이상 걸리네. 그 원인은 무엇인가?지연되는 영역이 SQL, HTTP 호출 등의 전통적인 병목 지점이 아니어서 불안합니다. Jira라는 제품이 아트라시안이라는 회사에서 개발된 것을 알고 있기 때문에 com.atlassian 패키지를 대상으로 프로파일을 설정해보겠습니다.

앗...설정을 하는 순간 시스템 CPU사용률이 52%를 넘었어요!조마조마한 마음을 가라앉히고 잠시 후 X-View 차트를 드래그합니다Y씨, 과연 원인을 파악할 수 있을까요?

아, 무수한 메서드가 프로파일링이 되었지만 안타깝게도 거의 0ms, 1ms가 필요한 메서드를 볼 수 있습니다. 그래서 X-View차트를 보면 응답시간이 매우 느려져 있습니다.

와이 형 이제 부장님한테 혼날 수도 있어요 힘내!그렇다면 프로파일링을 시도한 것이 잘못된 것일까요?만약 지연의 원인이 설정한 패키지 내의 어떤 클래스의 메서드라면 원인을 찾을 수 있을지도 모릅니다.

그러나 현대의 응용 프로그램은 사용자가 개발한 특정 메서드의 성능이 매우 나빠 응답 시간에 큰 영향을 주지 않습니다.

대부분의 환경에서는 이미 준비된 프레임워크를 이용해서 개발하기 때문입니다. 실제로 com.atlassian 패키지를 프로파일링하면 눈에 띄는 프로파일 정보를 확인할 수 없습니다. 내부적으로 현금을 준비해 놓고 성능 문제로 이어질 가능성은 낮습니다.

오래 걸린 SQL이나 HTTP의 호출이 있으면 원격지의 대상을 대상으로 튜닝을 시도하셔도 되는데 관련 정보가 없으면 원인 파악이 어렵습니다. 로드된 클래스에 해당하는 패키지를 모두 설정하시면 찾을 수 있습니다. 하지만 어플리케이션에 드는 추가적인 부하와 데이터 양으로 상당한 비용을 지불해야 할 것입니다.

그럼 이런 상황에서는 어떻게 분석을 해야 할까요?성능분석방법은 크게 프로파일링과 샘플링의 2가지 분류방법이 있습니다.

1. 프로파일링 실행되는 각 메서드에서 성능 정보를 수집하고 장시간 실행된 메서드를 찾아 개선하는 방법

각 메서드의 시작과 끝을 추적하여 응답 시간을 측정합니다.Transaction 1, Transaction 2의 가장 느린 메소드는 각각 Method 2, Method 4입니다.2. 샘플링 어플리케이션의 메서드 호출 여부를 주기적으로 수집하여 호출 빈도가 높은 메서드를 찾아서 개선하는 방법입니다.

Thread 실행 중 Mehtod 스냅샷을 주기적으로 수집하여 응답시간을 측정합니다.그림에서는 Method 1이 지연의 원인이라고 볼 수 있습니다.

프로파일링은 전통적인 성능분석 방법이기 때문에 오랜 역사를 자랑합니다.그만큼 대다수의 모니터링 제품이 프로파일링 중점 기능을 기본적으로 제공합니다.

하지만 완벽함 같은 이 프로파일링에도 다음과 같은 한계가 존재합니다.

모니터링 하는 대상 메서드를 사용자가 알아야 한다. 개발자라면 아직까지도…높은 트래픽을 받는 운영환경의 어플리케이션에 사용시 성능에 영향을 준다. (실수로 클래스가 많은 패키지라도 설정하는 날에는…?)

하지만 진정한 성능 개선을 위한 트래픽은 운영 환경에서만 발생하는 것!

어떠한 상황에서도 모니터링 할 수 있는 방법이 있다면 프로파일링의 한계를 보완할 수 있습니다. 그 방법 중 하나가 앞서 소개한 샘플링입니다.

샘플링은 개별 메서드를 직접 추적하지 않고 메서드의 호출원인 각 스레드에서 스택 트레이스를 주기적으로 수집하여 등장 빈도수를 바탕으로 병목 지점을 찾는 방법입니다. (스택 트레이스를 100ms 주가로 3번 수집했을 때 a라는 메서드가 3번 모두 등장했다면 a 메서드는 300ms 동안 실행되었다고 간주하게 됩니다.)

프로파일링 방법에 비해 다소 정확도는 떨어지지만 상대적으로 성능에 작은 영향을 미쳐 데이터를 수집할 수 있습니다.

처리 지연을 유발하는 주요 원인으로 어떤 것이 있는지 알려 주시겠습니까?

CPU 자원을 많이 소모하는 메서드 I/O를 동기로 처리하는 메서드 크기가 큰 컬렉션 객체를 이터레이션하는 메서드가 필요 없이 스레드 동기화 처리된 메서드

스택 트레이스를 이용한 샘플링 방법을 이용하면 특별한 설정 없이 상기 항목에 해당하는 메서드를 쉽게 찾을 수 있습니다. CPU를 많이 소모해도, I/O 처리해도, 결국 장시간 실행되는 메서드는 스택 트레이스에 반복적으로 나타나기 때문입니다.

물론 샘플링도 새로운 분석방법은 아니므로 기존에 사용하기 쉬운 다양한 툴이 존재합니다. 나는 Visual VM을 주로 사용하지만, 스레드별 스택 트레이스를 주기적으로 수집하여 호출 빈도를 알아보기 쉽게 표시함으로써 병목 지점을 쉽게 찾을 수 있습니다.성능에 미치는 영향이 매우 적기 때문에 트래픽이 높은 운영환경에서도 쉽게 이용이 가능합니다. (실제로 제가 담당하고 있는 APM 수집서버의 성능개선에도 여러 번 유용하게 사용되었습니다.)

그렇게 시간이 흐르고 있어 문득 이런 생각이 들었습니다.

이러한 도구는 고객사 내에서는 쉽게 사용할 수 없지만… (보안에는 여러 가지 이유가 있다고 합니다.) 샘플링 분석 방법으로 얻은 이 효과를 우리 제품 사용자들이 느꼈으면 합니다.'하아... 정말 좋은데 어떻게 설명할 방법이 없네..."에잇. 그냥 우리 회사에서 이런 방법을 제공하면 안 되는 건가?"스택 트레이스 선플링을 이용한 성능 분석, 개발자 Y의 성능이슈 추적, 고군분투기는 2편에 계속됩니다...