APM은 Application Performance Management/Monitoring의 줄임말로써, 말 그대로 애플리케이션(시스템, 응용 소프트웨어)의 성능과 서비스 안정성을 감시하고 관리하는 솔루션을 말한다. 이러한 솔루션들은 실시간으로 서비스의 상태를 파악할 수 있도록 하며, 제대로 잘 활용한다면 서비스의 이슈를 재빠르게 확인하고 분석할 수 있도록 도움을 준다. APM은 통신 프로토콜을 확인하여 성능을 모니터링하는 1세대와 타깃 서비스에 Agent를 설치하여 모니터링을 수행하는 2세대, 그리고 클라우드/마이크로 서비스 환경에서 모니터링 외 오토스케일링, 에이전트 자동 삽입, AI 등의 기술 등을 접목한 3세대로 나뉜다.
[APM의 종류]
더 많은 오픈소스 APM을 확인하려면 >> stackify.com/top-10-open-source-apm-tools/
| 구분 | 솔루션명 | 사이트 | 비고 |
| 상용 | Jennifer | jennifersoft.com/ko/ | container-based 지원 |
| Pharos | www.dabomsoft.com/ | ||
| DATADOG | www.datadoghq.com/ | ||
| dynatrace | www.dynatrace.com/ | microservices 지원 | |
| 오픈소스 | Scouter | github.com/scouter-project/scouter | |
| PinPoint | github.com/pinpoint-apm/pinpoint | ||
| Skywalking | skywalking.apache.org/ | microservices, container-based 지원 |
APM은 안정적인 시스템 운영을 위해 애플리케이션의 성능 및 장애를 관리해준다. 최근에는 웹 서비스가 과거와 달리 오랜 기간 지속적으로 구동되어야 하거나, 짧은 시간 내 과도하게 주어지는 트랜젝션을 버텨내는 것이 중요해졌고, 이에 따라 대부분의 시스템에서 APM을 차용하는 추세가 되고 있다. 지금처럼 서비스의 업데이트가 빠르지 않을 시절 APM은 주로 오픈 기간에 적용되어 서비스를 안정화시킨 후에는 사용하지 않는 것이 보편화되어있었다. 하지만 애자일(Agile), 데브옵스(DevOps) 등의 방법론의 등장으로 애플리케이션 업데이트 주기가 빨라지자 APM 또한 오픈 시기뿐만 아니라 개발 기간부터 항시 사용해야 하는 솔루션으로 자리 잡게 되었다.
서비스의 품질은 응답 시간에서 출발한다. 이러한 응답 시간은 각 서비스에서 주고받는 신호가 얼마나 빠르게 응답하느냐에 걸려있다. 이는 통신하는 서비스의 어느 하나의 구간에만 문제가 생긴다고 하더라도 전체가 영향을 받을 수 있다는 것을 뜻한다. 대부분의 서비스 응답 지연 문제는 문제가 되는 구간을 찾는 데 거의 모든 시간을 소요하게 되는데, APM을 적용한 시스템은 이러한 문제가 생긴 지점을 신속하게 찾을 수 있게 된다. 한마디로 APM은 서비스의 어느 구간에서, 어느 사용자가, 어떠한 애플리케이션을 사용 중에, 어느 과정에서 문제가 생긴 것인지를 빠르게 찾게 도움을 주는 솔루션이다(또는 빠르게 찾아 그것을 튜닝하게도 할 수 있다).
하드웨어의 경우 장비를 늘리거나 교체하여 성능을 향상시킬 수 있지만, 웹 서비스에 사용하는 소프트웨어는 보통 WAS(웹 애플리케이션 서버)의 응답 시간과 사용되는 리소스를 분석하여 문제 되는 부분을 찾아내어 개선하게 된다. 또한 APM은 실시간성을 띄기 때문에 전체 서비스가 현재 시점에서 정상적으로 운영되는지를 상시 모니터링이 가능하다. 또한 APM의 경우 개발 언어에 대한 의존성이 높아 언어 별로 매우 다양한 솔루션이 존재하는데, 대부분의 솔루션이 Java를 기본으로 제공하며, 추가적으로 PHP나 .NET에 대한 APM을 제공한다.
APM 모니터링에는 다양한 방법이 있지만, 간단한 몇 가지 사례를 소개한다.
1) 응답 시간 모니터링
- 대부분의 APM툴에서 응답 시간이 느려질 경우 붉은 색상으로 이를 표기한다. 단순하게 몇 가지 요청에 대해 응답이 늦었다고 해서 시스템이 이상한 것은 아니니 민감하게 보지 않아도 되지만, 아래와 같이 동일한 패턴으로 응답 시간 그래프가 확인된다면 가이드에 따라 서비스가 어떤 상황에 놓여있는지를 파악한다(해당 절은 Jennifer 매뉴얼을 참고하였다 - Reference 확인).
1-1) 단순 폭주 현상
이벤트/행사 등의 원인으로 순간적으로 사용자가 폭발적으로 증가하였을 때 볼 수 있는 패턴이며, 단발성으로 발생하는 경우에는 추가적으로 모니터링을 하며 안정적으로 운영되는지 지켜보면 되지만, 대부분의 경우 해당 현상이 발생하면 WAS Hang이 발생하여 재기동하여야 하는 경우가 비일비재하다. 해당 현상이 발생하면 WAS가 정상적인 상태로 작동하고 있는지 꼭 확인하여 큰 장애로 이어지지 않도록 대비한다.
1-2) 폭포수 현상
반복적인 세로선이 발생하면 특정 자원의 응답이 한계에 도달하였다가 순간적으로 해소되고 있는 상태이며, 관련된 트랜젝션이 동시에 종료되는 현상이 반복되어 발생한다. 어떤 자원이 공통적으로 사용되고 있는지를 파악한다.
1-3) 물방울 현상
시스템에 병목구간이 존재하지만 그 부하량이 적어 미미하게 표현되는 것으로, 해당 서비스에 큰 부하가 발생할 경우 해당 구간은 치명적인 오류로 변할 가능성이 있다. 응답 시간이 유의미하게 커지는 경우 눈여겨보고 튜닝을 진행하는 것이 좋다.
1-4) 파도치기 현상
시스템 성능 문제와는 관련 없이 요청이 점점 더 많아질 경우 발생하지만, 특정 자원이 부족하거나 연동하는 시스템 측에 부하가 있는 경우 발생할 수 있다. 운영하는 시스템에 문제가 없는 경우 외부 연동 시스템을 점검할 필요가 있다.
2) 트랜젝션 트리 확인
- APM툴에서는 대부분 트렌젝션 상세조회 기능을 제공한다. 실시간 모니터링 구간을 드래그할 경우 사용자가 선택한 구간에 발생한 모든 트렌젝션의 상세 트레이스를 확인할 수 있다. 해당 자료를 이용하여 1) 항목에서 확인한 패턴의 원인을 추적해 나간다.
- 이 기능을 통해 어느 구간에서 시간이 많이 소요되었는지 파악이 가능하며, 해당 APM이 지원하는 DBMS를 사용하는 경우 애플리케이션이 사용한 쿼리와 변수 값을 얻을 수도 있다. 쿼리 수행 자체가 느렸던 것인지, DB서버와의 연동 자체가 느렸는지는 APM에서 지원하는 GAP Time(이전 수행 구간과의 응답 시간 차이 값)을 통해 확인한다.
2-1) 요청 Client IP가 동일한 경우
동일 사용자의 과다 호출을 의심한다. 시스템을 향한 해킹 시도이거나, 조회 시스템에서 1회 클릭 후 버튼을 차단하지 않는 경우 발생한다. 응답 시간이 늦어질 경우 고객이 동일 버튼을 과도하게 누르는 경우가 있을 수 있으니, 자료를 조회하는 버튼의 경우에는 일정 시간 동안 재조회가 불가능하도록 버튼에 적절한 처리를 해 두는 것이 좋다.
2-2) 요청 Application 명이 동일한 경우
해당 Application이 사용하는 자원, 연동하는 시스템에 문제가 있는 경우일 수 있다. 서비스 트레이스를 확인하여 어느 구간에서 응답 시간이 오래 걸리는지를 파악하여 해당 구간에서 문제를 해소하도록 한다. 만약의 경우에는 해당 부분의 소스가 개발자의 실수로 인해 변경되거나 재 배포가 되었을지 모르니 배포 파일을 확인하는 것도 좋다.
2-3) 응답 시간 지표가 HTTP보다 SQL이 높을 경우(또는 REMOTE가 높을 경우)
DB서버 또는 연동하는 시스템의 이슈를 파악한다. 특정 쿼리만 느린 경우나 특정 연동 서비스가 느린 경우에는 요청 Application이 일관적으로 나타나지만 DB서버 자체에 이슈가 있는 경우 서비스 전체의 응답 시간이 지연되고 있을 가능성이 높다.
2-4) 어느 것도 일관되지 않을 경우
서비스 자체에 문제가 발생했다. 서버 리소스 사용률을 확인한다(대부분 이 경우에는 트렌젝션 트리를 확인하기 전에 이미 대시보드에서 CPU/MEM이 요동치고 있거나 다른 그래프가 이상한 패턴을 보이고 있을 가능성이 높다).
3) Active Thread 확인
- 대부분의 APM은 상단에 실시간 요청이 한눈에 보이는 BAR형태의 모니터링 항목을 제공한다. 해당 항목에서는 전체 서버의 부하가 어느 정도인지 가늠할 수 있으며, 정상적인 응답과 지연되는 응답의 비율을 파악할 수 있다.
- 엑셀 업/다운로드 기능이 있는 애플리케이셔는 해당 BAR에서 응답시간이 오래 걸려있는 경우가 많다. 인스턴스가 오래 처리하는 스레드가 많을 수록 서비스 과부하 영향도가 커지므로, 업/다운로드 크기를 제한하여 응답시간을 조절하는 것이 좋다.
- 또한 각각의 인스턴스 별로도 Active Thread를 확인할 수 있도록 되어있는데, 해당 항목에서는 각 인스턴스 당 얼마나 처리하고 있는지를 한눈에 확인할 수 있다. 로드밸런싱이 적절하지 않은 경우 한 인스턴스로의 요청이 많은 것을 확인할 수 있으며, 이 경우 앞단의 로드밸런서를 확인하도록 한다.
- 간혹 인스턴스가 중단된 것처럼 보였다 복구되는 경우가 있는데, 이때에는 Full GC가 발생한 경우일 가능성이 높다. 2/3세대 APM의, 경우 JVM 옵션으로 Agent가 동작하는 경우가 흔하므로, JVM이 멈추는 동안 Agent도 자연스레 통신이 멈추기 때문이다.
[Reference]
m.blog.naver.com/shakey7/221913007126
stackify.com/top-10-open-source-apm-tools/
docs.jennifersoft.com/4.5manual#dc04ab433356fb92
모니터링 방법은 생각나는 대로 또 추가하도록 하겠다.