왜 서비스 응답시간을 측정하는가?

Web Application Server(이하 WAS)에서 서비스의 응답시간은 사용자의 요구수준을 만족하는 척도라고 할 수 있다. 시스템에 일부 오류가 존재하더라도 정상적인 응답시간내에 요청이 오류없이 처리된다면 문제라 할 수 없다. 반대로 시스템에 어떠한 오류나 문제를 발견하지 못했을 지라도 사용자가 만족 할만한 시간내에 응답을 받지 못한다면 정상이라 할수 없다.

이렇듯 서비스의 응답시간은 시스템의 정상여부를 판별하는 가장 중요한 기준이다 그래서 SLA에서도 사용자 응답시간을 가장 중요한 지표로 사용하는게 대체적인 추세이다. 본 문서는 장애 해결을 위한 서비스 응답시간 모니터링 방안에 대해서 설명한다.

장애 해결을 위한 응답시간의 가치는 사실 성능 지표들의 특성에서 기인하다 할 수 있다. 예를 들어 유닉 장비에서 vmstat로 CPU사용량을 모니터링 하고 있다고 가정해 보자. CPU의 사용량이 95% 이상을 사용하고 있다. 심지어 순간적으로 100%에 이를 때도있다. 이것을 문제로 볼 수있는가? 대부분의 시스템 담당자는 이것을 문제로 지적하지 못한다. 현재 운영환경에서 단지 CPU를 잘 사용하고 있다는 정도의 말만 되풀이 하게 된다. 이러한 현상은 자원 사용량이 100%를 초과하는 요청에 대해 알려줄 수 없기 때문이다. 아무리 많은 요청이 들어와도 CPU사용량은 100%를 초과하지 못한다. 이것이 자원 모니터링의 한계이다.

자원 사용량은 100%를 초과하지 못한다.

자원 모니터링의 또다른 한계는 모든 자원을 모니터링할 수 없다는 것이다. 시스템 내에서 수많은 H/W적 혹은 S/W적 자원이 존재한다. CPU,MEM,NET등을 시작으로 HEAP MEM, Connection Pool, 세마포어 등등 무수히 많은 자원이 존재하며 운영자는 이 모든 자원의 사용량을 모니터링 할수도 할 필요도 없다. 단지 운영시 의심되는 혹은 중요한 자원을 적절히 지정하여 모니터링 하는 것이 필요하다

시스템의 모든 자원을 모니터링 할 수는 없다

이러한 두가지 한계를 극복하는 방법은 응답시간을 적절히 모니터링 함으로써 가능할 것이다. 자원의 용량을 초과하는 요청이 발생하며 응답시간은 지연된다. 요청이 많으면 많을수록 응답시간을 무한히 증가하기 때문에 자원의 요청이 용량을 초과했음을 쉽게 감지할 수 있으며, 모든 자원의 사용량을 모니터링 하지 않더라도 서비스가 사용하는 어떠한 자원이든지 용량을 초과하면 서비스의 처리시간은 지연된다. 따라서 장애 해결을 위한 응답시간 모니터링은 필수이다.

자원을 초과하는 요청은 응답시간 지연으로 나타난다.

응답시간은 개별로 모니터링해야 한다

장애해결 관점에서 응답시간 모니터링은 어떠한 방법으로 이루어져야 하는가? 이것을 이야기 하기 전에 서비스와 자원과의 관계를 먼저 생각해보자. 웹 시스템에서 서비스는 통상 HttpServlet.service()에서 시작하여 종료된다(WAS에 따라 약간 다름). 서비스가 수행될때는 수만은 클래스와 때로는 DB를 접근하고 LDAP과 연결되기도 하고 파일을 Access하기도 한다. 서비스가 사용하는 자원은 정의하기 어려울정도로 많을 것이다. 그런데 이러한 자원은 특정 URL요청에 대해서만 사용되기도 하고 CPU나 HEAP MEM처럼 모든 서비스에서 사용되기도 한다. 결과적으로 서비스와 자원은 N:M관계를 형성하게된다.

서비스와 자원은 N:M 관계이며 명확히 정의할 수 없다

일반적인 응답시간 모니터링은 평균라인으로 대표된다. 전체 서비스에 대한 평균응답시간을 라인 그래표로 표현하는 방식을 의미한다. 그런데 전체 평균은 시스템의 상황( 다시 말하면 자원의 상황)을 관찰하는데 효과적이지 않아 서비스의 그룹을 만들고 이 그룹들의 응답 평균라인을 모니터링하게 된다. 그룹핑의 일반적인 방법은 업무단위로 그룹핑하는 것이다. 입금업무, 출금업무 등등.. 그러나 이것은 모니터링 시 약간의 혼란을 야기하기 된다. 특정 업무 그룹의 응답시간이 지연되기도 하지만 여러 개의 업무 그룹의 응답시간이 지연되기도 한다. 어떤형태이든 응답의 지연이 발생하면 원인을 찾고자 한다. 사실 응답시간을 모니터링하는 근본 목적은 서비스 수준을 개선하자는데 있는 것이지 단순히 응답시간 자체를 알기 위한 것이 아니기 때문이다. 그런데 업무 중심의 그룹핑은 서비스와 자원과의 관계를 기반하지 않기 때문에 응답시간 지연시 근본원인을 쉽게 반영하지 못하는 특성이 있다. 입금 업무가 지연되었을 때 입금업무의 특정 서비스가 특정시점에만 지연되었는지 아니면 그때 입금 업무만 수행되었기 때문인지 등을 반영하지 않음으로 해서 개선 포인트에 접근하는데 한계를 노출하게 되고 이것은 응답시간이 단순한하나의 서비스 수준을 나타내는 지표정도로만 활용되고 더 이상의 가치를 나타내지 못하는 원인이 된다.

서비스 수준 개선을 목적으로 한 서비스 응답시간 모니터링은 개별로 수행되어야 한다.

결론적으로 서비스 수준의 개선을 목적으로 한 서비스 응답시간 모니터링은 그룹핑이 아니라 개별로 수행되어야 한다. 여기서 개별 요청에 대한 개별 서비스의 응답을 별도록 포괄적으로 모니터링 할 수있어야 한다는 것이다. 그렇게 되면 어느 순간에 응답시간의 지연이 발생할 때 관련된 Transaction 에 대해서만 집중적으로 분석함으로써 쉽게 수행된 서비스들 간의 공통점을 찾아낼 수 있고 근본문제에 빠르게 접근할 수 있게 된다.

서비스 수준 개선을 목적으로한 서비스 응답시간 모니터링에서 서비스의 구분을 정확하고 상세하게 하는 것은 매우 중요하다. 만약 서비스명을 HttpServlet.service()로 한다면 시스템에는 하나의 서비스만이 존재하게된다. 따라서 웹시스템에서는 URL을 서비스명으로 사용하는 것이 일반적이나 최근에 들어 single gate servlet을 사용하고 파라미터를 이용하여 실제 서비스로 분기되도록 하는 구조를 사용하는 시스템들이 있는데 이런 경우에는 URL만으로는 서비스의 구분이 어렵다 이런 경우에는 서비스명을 의미하는 특별한 Request 파라미터를 서비스 명으로 사용해야 한다.

만약 서비스명의 구분이 모호하면 서비스 기반의 각종 통계 또한 모호해지는 문제가 발생한다. 또한 프로파일 내용을 보고 서비스를 구분해야 하기 때문에 튜닝 또한 어려워지는 문제가 발생하게 된다.따라서 서비스명이 상세하게 구분된다는 것은 이후 통계나 장애 혹은 성능개선에 중요한 의미를 갖는다.

제니퍼는 개별 Transaction에 대한 응답시간을 한눈에 볼 수 있다.

서비스와 자원은 분석적으로 정의하고 관계를 규정할 수 없다 하지만 개별 트렌젝션의 응답시간을 모니터링 한다면 응답시간이 지연된 서비스들의 공통점을 분석하여 문제의 자원을 판별하고 효과적으로 개선할 수 있다.

제니퍼는 XView를 통해 개별 트렌젝션의 응답시간과 해당 트렌젝션의 상세 흐름을 모니터링 할 수있도록 제공하고있다. XView상에서 의심되는 트렌젝션들만을 선택하여 분석함으로써 장애 원인을 효과적으로 판별 할 수있다.

서비스 : 사용자의 요청을 처리하기 위한 응용프로그램
트랜젝션: 서비스가 수행된 개별 건