효과적인 응답시간 모니터링

응답시간 모니터링

서비스의 응답시간은 사용자의 성능적 만족을 판별하는 중요한 기준이다. 시스템의 서비스 중단을 막는 것은 물론 중요하지만 그것만으로 현재의 웹시스템을 관리하기는 부족하다. 응답시간이 느린 웹시스템은 사용자를 짜증나게 만들고 나아가 회사의 고객을 떠나 보내는 중요한 요인으로 작용할 수있다. 따라서 시스템에 대한 사용자 만족을 고민할 때도 응답시간은 필수적이며. 느리고 빈도가 높은 서비스를 우선으로 하여 끊임없이 응답시간을 개선해가야 한다.

응답시간을 모니터링 하는 방법은 전통적으로 평균에 의한 라인 그래프를 사용하였다.

그런데 응답시간에 대한 평균라인 그래프는 응답시간외의 정보를 표현하지 못한다. 그래서 평균라인 그래프는 관찰자에게 매세지를 전달하지 못한다. 즉 장애가 있는지 전체응답시간이 증가하는지 아니면 일부 서비스가 급격히 증가 했는지 등을 표현하지 못한다. 또한 어떤 서비스가 느려졌는지 파악하는데 어렵게 할 뿐만 아니라 응답시간이 느려진 근본 원인을 파악하기 어렵게 한다

응답시간 모니터링은 점 그래프로

그래서 응답시간은 개별 서비스에 대해서 하나의 그래프로 모니터링 되어야 해야한다. 개별 서비스(트랜잭션)의 응답시간을 하나의 그래프로 표현하려면 당연히 라인 그래프로는 불가능하게 되며 점그래프로 표현할 수 밖에 없다

세로 축을 응답시간으로 가로축을 종료시간으로 하여 점그래프로 모든 트랜잭션의 응답시간을 표현한다. 각점은 개별 트랜잭션을 의미한다. 이러한 그래프를 응답시간 분포도(Response Time Scatter Diagram)라 한다. 전체 서비스 수행 현황을 응답시간 관점에서 직관적으로 모니터링 할 수있으며 여기에 개별 점을 선택하면 해당 트랜젝션의 상세한 수행 내역(Method Call Path, SQL, Socket 등)을 확인할 수있도록 하게 되면 현상을 파워풀하게 제어할 수 있게 된다.

응답시간 분포도는 단순히 응답시간이 늦는 어플리케이션에 대해서 상세 수행정보를 볼수 있다는 장점은 넘어서, 응답시간은 병목 유형에 따라 패턴이 형성된다. 운영 혹은 테스팅 시에 다양한 형태의 패턴 볼 수있으며 이러한 패턴을 기반으로한 시스템의 현황을 직감할 수있다는 것은 응답시간 분포도가 주는 큰 매력 중 하나이다.

본문서는 필자가 발견한 응답분포 패턴에 대한 유형과 해석방법을 제시하고자 한다.

응답 분포 패턴(Response Time Scatter Pattern) 운영혹은 성능 테스트 시점에 서비스의 응답시간을 모니터링하면 다양한 형태의 응답 분포 패턴을 접하게 된다. 비정상적인 상황에서 응답분포패턴을 통해 시스템의 상황을 해석할 수 있다.

♣패턴은 세 분야의 규정을 정의하는 것인데, 이것은 특정한 상황(context)와 문제점 그리고 이에 대한 해결 방법 사이의 관계를 표현하는 것이다. - Christopher Alexander

♣패턴은 특정상황(context)에서 발생한 문제에 대한 검증된 해결 방법이다 - Gang-of-Four

♣패턴이란 특정 상황(context)에 대해 유용한 대처 방안이 다른 곳에서도 유용하게 적용 가능한 경우를 말한다 - Martin Fowler

물기둥(pouring) 패턴

주전자에서 물을을 따르듯이 물방울이 한곳으로 쏟아지는 형상을 하는 점의 패턴이다.

이러한 현상은 호출 시점이 다르면서 동일 시점에 종료된 트랜잭션이 밀집할 때 만들어 지는 패턴이다. 기둥에 속하는 트랜잭션이 사용하는 공통의 자원에 일시적인 병목이 발생할 경우에 형성된다. 유사하게 여러 트랜잭션이 하나의 DB락에 영향을 받을 때도 발생한다. DB 락과 같이 병목해제가 명확한 상황에서는 점들이 거의 일직선을 형성하지만 어떤 자원이 일시적으로만 부족하였을때는 약간 두꺼운 기둥이 형성된다.

물기둥 패턴에서는 점들간의 공통점을 찾아내기가 상대적으로 쉽다. 만약 점들이 여러 WAS 인스턴스에 의해 수행된 트랜잭션일 경우에는 WAS 외적인 자원이 병목이며, 그 점들이 하나의 WAS 인스턴스에서 수행된 트랜잭션이라면 WAS 내부의 자원에 의한 병목일 가능성이 높다. 그리고 만약 동일한 서비스에 대한 요청이라면 해당 어플리케이션의 공통 요소(경험적으로는 DB가 많음)가 병목의 원인을 제공하는 경우로 해석할 수 있다.

튜닝을 한다면 최상단에 걸려 있는 느린 트랜잭션 보다는 세로로 기둥을 형성하는 트랜잭션이 먼저 고려해야 한다. 하나의 느린 어플리케이션은 자신만의 문제로 끝나겠지만 줄을 형성한 어플리케이션은 시스템 전체에 보다 치명적인 장애를 유발할수 있다.

시루떡(Layering) 패턴

부하량이 증가함에 따라 가로라인의 수가 증가하는 패턴이다. 만약 부하량이 증가하여 전체적인 응답시간이 증가하는것과 라인 수와 연관성이 없을 때는 이 패턴에 해당되지 않는다. 단순히 호출 빈도가 높은 어플리케이션이 여러 개 존재하는 경우에도 가로 라인을 형성하지만, 이 경우는 부하량이 많아져도 라인의 수는 증가하지 않는다.

여러 트랜잭션이 수행되는 과정에서 동일 자원에 대한 고정시간 대기가 반복될 때 나타나는 현상이다. 부하량이 증가할수록 대기할 확률이 높아지기 때문에 응답시간이 길어지고, 이렇게 지연되는 응답시간의 변화가 일정 시간단위로 증가되기 때문에 그림과 같이 반복적인 가로 라인이 형성된다.

이런 경우에도 기본적으로 라인에 참여하는 트랜잭션이 동일한 인스턴스에서 수행되었는지등을 파악하는 것만으로도 중요한 단서를 얻을 수 있다. 그리고 추가로 모든 자원중에서 그림에서 보여주는 라인간의 편차와 같은 값의 시간 설정값을 갖는 파라미터를 찾아보는 것도 우선적으로 필요하다.

매트릭스 패턴

영화 매트릭스의 오프닝 화면을 연상한다고 해서 이름이 붙여 졌다. 작은 줄들이 화면 전체에 어지럽게 형성되는 패턴이다. 이것은 하나의 병목(통상 락)이 몇 개의 어플리케이션에만 영향을 미치며 이러한 성격의 병목이 전체 어플리케이션에서 고루 발생할 때 나타난다.

DataBase에서 DirtyRead가 허용되지 않는 상태 즉 최소한 READ_COMMITTED 이상의 락 Level이 설정되어 있으면 나타날 수 있다.

매트릭스 현상은 단순 자원하나가 형성하기는 어렵기 때문에 일반적인 H/W 자원이 원인이 된 경우는 보지 못했다. 사이베이스, MS-SQL데이터베이스를 사용하는 시스템에서 관찰한 경험이 있다. 일단 DB에 의한 매트릭스 패턴이 발생하면 데이터베이스 전체의 LOCK LEVEL을 조정하지 않고는 해결하기 어렵다. 근본적으로 LOCK LEVEL 조정과 그에 따른 어플리케이션의 수정이 불가피하다.

폭포수 패턴

점의 분포가 폭포처럼 형성된다. 폭포수 패턴은 현상적으로 특정 자원이 급격히 부족해 졌다가 혹은 락이 걸렸다가 해제되고 이것이 다시 반복될 때 나타난다.

폭포수 패턴이 발생하는 시점에 부하량이 갑자기 늘거나 응답시간이 증가되는 현상 없어 보인다. 하지만 폭포수를 유발하는 자원에 대한 요청은 분명 증가하였을 것이다. 다만 해당 자원의 사용량이 전체 응답시간과 비례하지 않다가 해당 자원이 부족해지는 시점에 현상이 발생하였다 또다른 특징은 폭포수가 발생하는 중에도 3초이하의 짧은 트랜잭션들이 무수히 진행되었다. 이점은 폭포수현상을 일으키는 자원이 전체 어플리이션에서 사용하는 자원이 아니라는 것을 나타낸다.

폭포수 패턴은 두번째 그림처럼 고정높이를 형성하는 특징을 가진다. 폭포수는 매우 짧게 사용되는 자원이 순간적으로 부족(Full, Overflow)현상에 빠지고, 이때 일정시간 대기하다가 자원이 Refresh되면서 전체가 해제될 때 나타날 수 있다.

마치며

응답 분포도는 직관적이며 강력하다. 운영시스템의 응답시간을 분포도로 관찰하는 것은 라인그래프 몇 개를 합한 것 보다 효과적이라는 것을 느낄 것이다.

마지막으로 아래의 그림은 운영 시스템에서 켑쳐하였다. 동일 시점에 만든 두가지 형태의 그래프이다.

그림에서 빨간색 부분이 뭔가 문제처럼 느껴지는가? 분석해야겠다는 생각이 드는가?

그럼 다음 그래프에서는 어떤가? 점이 무슨 트랜젝션인지 확인하고 싶지 않은가?

이것이 응답시간 분포도의 강점이다