애플리케이션 모니터링
웹 서비스 운영 중에 장애가 발생하게 되면 많은 경우 WAS 재기동 후 서비스 정상 여부를 파악합니다. 운이 나쁘다면 재기동 후에도 서비스는 동작하지 않을 것이지만 운이 좋다면 서비스는 정상적으로 동작하기 시작합니다. 이런 상황에서 운이 아니라 데이터에 기반한 행동을 하려면 우리는 어떤 정보가 필요한지 알아보겠습니다.
가장 먼저 우리가 알아야 할 정보는 서비스를 사용하는 방문자 숫자입니다. 조금 더 정확하게 말하면 동시 사용자를 알아야 합니다. 웹 서비스에 동시 사용자가 많아 졌다면 성능 과부하로 인해 문제가 생겼을 수 있습니다. 예를 들어 동시사용자가 어제와 비교해서 월등히 높아졌다면 이로 인해 TPS와 평균응답시간이 높아지게 됩니다. 또한 특정 SQL의 응답시간을 늦어졌을 가능성을 예상해 볼 수 있습니다. 때문에 웹 서비스 운영을 하기 위해서는 항상 얼마나 많은 방문자를 받을 수 있는지 알고 있어야 합니다.
초당 몇건의 트랜잭션이 일어났는지 확인해야 합니다. 방문자와 마찬가지로 서비스가 초당 몇개의 트랜잭션을 받아 들일 수 있는지 알고 있어야 합니다. TPS가 기존 한계치를 초과하는 경우 서비스의 물리적 용량을 늘려서 해결하는 방법과 애플리케이션의 효율을 높여서 해결하는 방법을 모두 고민해야 합니다.
평균 응답 시간은 어플리케이션 서버가 사용자에게 요청 결과를 반환하는 데 걸리는 시간을 말합니다. 어플리케이션 서버의 응답시간은 일반적으로 1초 이하로 진행되지만 장애 시점에서는 3초 이상의 시간이 걸리기도 합니다. 실제 장애가 발생하기 시작하면 TPS는 일정 값 이상 오르지 않으며 평균 응답 시간이 증가하기 시작합니다. 이렇듯 응답시간, TPS, 방문자수(사용자수), CPU, 메모리의 정보는 장애 시점에 알아야하는 핵심정보 입니다.
CPU와 메모리 정보를 통해 인프라스트럭쳐에 여유가 있는지 판단할 수 있습니다. TPS와 평균 응답시간이 높아져 가는데 CPU와 메모리 사용률에 변화가 없다면 WAS와 애플리케이션을 살펴 봐야 합니다. WAS와 애플리케이션은 인프라스트럭쳐 위에서 동작하기 때문에 CPU와 메모리 정보는 항상 체크해야 합니다.
웹 서비스를 운영하고 있다면 항상 "방문자", "TPS", "평균 응답 시간", "CPU", "메모리" 5가지 정보에 신경을 써야 합니다. 이 5가지 정보를 직접 수집한다고 하더라도 장애 상황에서 문제 분석을 위해 덤프를 일일이 확인하는 것은 쉬운 일이 아닙니다. 이런 경우를 대비하기 위해 와탭 애플리케이션 모니터링 서비스를 비롯한 다양한 애플리케이션 모니터링 도구를 사용하면 좋습니다. 와탭 뿐만이 아니라 어떤 애플리케이션 모니터링 도구를 사용하더라도 평소 로그나 덤프를 이용하는 것보다 더 효과 높은 데이터를 수집할 수 있습니다. 애플리케이션 도구들은 수행된 SQL의 수행 시간을 비롯한 서비스의 성능과 장애 분석이 도움이 되는 수많은 정보를 제공하고 있습니다.