AppDynamics Cognition Engine을 통한 이상징후와 근본원인 분석

by NeO posted Jul 09, 2019
?

단축키

Prev이전 문서

Next다음 문서

ESC닫기

크게 작게 위로 아래로 댓글로 가기 인쇄
Anomaly Detection and Root Cause Analysis with AppDynamics Cognition Engine

Summary

AIOps와 어플리케이션 인텔리전스를 결합하여 AppDynamics Cognition Engine은 시스템에서 발생하는 막대한 양의 메트릭을 분석하고 인사이트를 얻을 수 있습니다.

AppDynamics Cognition Engine에 대해 이야기할 때 빼놓을 수 없는 것은 anomaly detection입니다. Cognition Engine은 어플리케이션 성능 차이를 구분하고 문제의 원인이 되는 부분을 적절한 조치를 취할 수 있게 도와줍니다. Machine Learning 모델을 활용하여 AppDynamics는 실시간으로 전체 어플리케이션에 대한 anomaly detection이 가능합니다. 따라서 전통적인 임계치 방식으로 전통적인 시스템의 문제점을 찾는 방법보다 훨씬 더 빠르게 문제를 감지할 수 있습니다.

Anomaly Detection and Root Cause Analysis : A Step By Step Guide

그럼 자세히 살펴볼까요. 이 문서에서는 다음 주제에 대해 다루고 있습니다.
  • 어플리케이션의 이슈를 빠르게 검출합니다.
  • 이슈의 근본 원인(Root Cause)을 찾기 위해 드릴다운 합니다.
  • Anomaly detection과 Root Cause analysis를 활용합니다.

ERetail-Pass라는 샘플 어플리케이션을 예로 들겠습니다. AppDynamics가 익숙하지 않은 분들을 위해 설명드리자면, 가운데 보이는 다이어그램은 AppDynamics agent를 설치하면 자동으로 그려지는 Application Flow Map입니다. 

 cog1.png


AppDynamics agent는 자동으로 다양한 컴포넌트를 발견하고 그들 간의 호출관계를 보여줍니다. 이 샘플 어플리케이션은 다양한 종류의 Java 서비스가 있고, 호출을 위해 queue와 Redis cache를 사용하고 있음을 알 숭 ㅣㅆ습니다.

아래 그림을 보면 방금 일어난 성능이슈를 보여줍니다. 오전 10시 30분을 기점으로 응답속도가 증가하고 로드가 줄어들고 있음을 알 수 있습니다.

cog2.png


이 시점에서 아직 원인은 알 수 없지만, 일부 KPI에 문제가 발생한 것을 확인할 수 있습니다. 스크린의 오른쪽에서는 health rule violation이 일어난 횟수를 확인할 수 있습니다.

cog3.png


그리고 오늘의 주인공 Anomalies started 타입의 anomaly event가 있습니다.

cog4.png


위의 그림은 AppDynamics가 Critical 레벨의 이상징후를 Checkout 비즈니스 트랜잭션에서 발견했음을 보여줍니다. 이제 문제상황을 드릴다운 하여 왜 이런 알람이 발생했는지 확인해보겠습니다.

다음 그림은 Anomaly Detection과 Root Cause Analysis 화면입니다. 왼쪽 상단에 해당 이상징후가 Resolved상태입을 알 수 있습니다. 오전 10시 39분 경 상황이 시작되었으며 11시 9분에 critical에서 warning으로 변경되었고 11시 13분에 완전히 해소되었습니다. 이 타임라인은 변경가능하기 때문에 원하는 시점으로 변경하여 확인해 볼 수 있습니다. 예를 들어, 빨간색으로 표시된 critical 시점과 노란색의 warning시점을 오가며 자세한 변동사항을 볼 수 있습니다.

cog5.png


/r/Checkout 밑에 있는 화면 왼쪽부분에서 왜 이상징후(anomaly event)가 발생한 이유를 보여줍니다. 
이 이벤트는 95th Percentile과 평균 응답속도의 편차에 의해 발생했음을 알 수 있습니다.
그 아래쪽을 살펴보면 두 지표에 편차가 발생한 두가지 원인을 볼 수 있습니다.

cog6.png


AppDynamics에서는 policy에 따라 action을 연계시킬 수 있습니다. 
여기에서는 Slack채널으로 관계자들에게 비즈니스 트랜잭션 정보를 HTTP notification액션을 통해 전달했습니다.
 
cog7.png



AppDynamics에는 다양한 종류의 action이 있습니다. 예를 들어 이메일이나 SMS 메시지를 보낸다거나, ServiceNow나 Jira등 써드파티 툴과의 연계도 가능합니다. 비즈니스 트랜잭션의 스냅샷 정보를 전달하면, 전달받은 담당자들은 해당 이슈의 근본 원인이 포함된 자세한 정보인 개별 스냅샷을 확인하고 문제를 해결할 수 있습니다.

 cog8.png

이제 의심스러운 원인을 파악해보겠습니다. 다음 Flow map에서 몇 가지 컴포넌트가 빨간색으로 표시된 것을 알 수 있습니다.

cog9.png



빨간 색 아이템에 마우스를 대면 이 root cause가 Payment service 티어와 연관되어 있음을 알 수 있습니다.


cog10.png


Top Suspected Causes 아래에서 우리는 process CPU 사용량을 볼 수 있습니다. Payment service 티어의 CPU 문제로 해당 비즈니스 트랜잭션인 /r/Checkout의 성능에 영향을 미치고 있음을 알 수 있습니다.
 
cog11.png


다음으로 수상한 요소는 order service로 이 티어는 payment service티어에서 호출하는 컴포넌트이므로 영향을 받을 수 있음을 알 수 있습니다.

cog12.png


Payment service가 주요한 원인임을 확인했으므로 우리가 알 수 있는 보다 더 자세한 정보를 확인해보겠습니다.

cog13.png


Top Deviating Metrics 타임라인에서는 비즈니스 트랜잭션에서 해당 메트릭이 어떻게 변화했는지 보여줍니다. 위에서 95th percentile, average response time 메트릭은 회색으로 표시된 예상치보다 훨씬 높은 수준을 보입니다. 둘 모두 500에서 700 ms가 예상되었으나 실제로는 1600ms를 기록했습니다.

오전 11시 5분 경 두 메트릭은 normal 상태로 전환됩니다. 이 시점이 이상징후가 종료된 시점입니다. 즉, 두 메트릭 모두 문제가 해결되었고 특히 급격한 수치 상승이 해소된 시점입니다.

cog14.png


Suspected Cause Metrics를 내려보면 해당 노드의 Process CPU Used와 Process CPU Burnt 메트릭이 있습니다. 이 메트릭들이 비즈니스 트랜잭션 메트릭과 밀접한 관계가 있음은 명확합니다. 이제 우리는 CPU 사용량이 특정 티어의 성능을 저해하고 결과적으로 전체 비즈니스 트랜잭션의 성능저하를 가져왔음을 알 수 있습니다.

Recap

95th percentile response time과 average response time 지표에 의해 발견된 이 이슈는 확인결과 payment service의 CPU이슈였음을 알 수 있었습니다. 구체적으로는 CPU 사용량이 매우 높은 수준이었으므로 payment service와 연계된 order service에도 영향을 미쳤으며 결과적으로 비즈니스 트랜잭션의 성능저하로 이어짐을 알 수 있습니다.

How to Enable Anomaly Detection in AppDynamics

그렇다면 어플리케이션의 이슈와 근본 원인을 찾는 AppDynamics의 Anomaly Detection 기능을 사용하려면 어디서 무엇을 해야 할까요?

cog16.png


Anomaly Detection을 활성화하는 것은 매우 쉽습니다. Alert & Respond 스크린에서 Anomaly Detection을 클릭하십시오. 그리고 다음 그림과 같이 활성화하면 선택한 어플리케이션의 모든 비즈니스 트랜잭션에 대해 Anomaly Detection을 사용할 수 있습니다.

Anomaly Detection은 어플리케이션에 따라 활성화가능합니다. 활성화되면, 24시간에서 48시간동안의 머신러닝기간을 거쳐 지속적으로 비즈니스 트랜잭션의 성능을 관리해줍니다.
Anomaly event는 기존에 AppDynamics가 가지고 있던 health rule violation과 동일하게 policy에 따라 action을 정의하고 담당자들에게 정확한 정보를 전달할 수 있습니다.

Who's NeO

ALM, SW 모델링, SW 정적분석, Devops 특히 CI/CD, APM을 통한 Shiftleft에 관심이 많습니다. 

차세대 APM Cisco AppDynamics와 모바일 앱 모니터링 VMware Apteligent를 소개합니다.

http://www.solulink.co.kr