메뉴 건너뛰기

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

?

 


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

    Anomaly Detection and Root Cause Analysis with AppDynamics Cognition Engine Summary AIOps와 어플리케이션 인텔리전스를 결합하여 AppDynamics Cognition Engine은 시스템에서 발생하는 막대한 양의 메트릭을 분석하고 인사이트를 얻을 수 있습니다. AppD...
    Date2019.07.09 ByNeO Reply0 Views40
    Read More
  2. 코드 인스펙션 룰을 작성하는 과정

    훌륭한 Code Inspection 도구가 많고, 도구의 완성도와 빌트인 룰의 효용성이 좋아지고 있지만 여전히 프로젝트에서는 커스텀 룰을 필요로 합니다. 이것은 시큐어코딩이나 보안감사, 데이터 관리평가와 같은 외적 요인에 의한 동기와, 코드의 가독성 향상, 유...
    Date2018.07.31 ByNeO Reply1 Views744
    Read More
  3. 버그는 줄이고 릴리즈는 빠르게 : APM이 Software Development Life Cycle을 개선하는 법

    요약 소프트웨어 개발 라이프사이클(SDLC)에 연관된 모든 사람들의 작업은 어플리케이션과 비즈니스 성능 정보를 쉽게 확보할 수 있도록 함으로써 개선될 수 있다.   시작하며 일련의 상호의존적 절차를 분리된 행동으로 ...
    Date2018.07.25 ByNeO Reply0 Views452
    Read More
  4. 2. Service Endpoint를 활용한 Database 성능 모니터링

    본 문서는 다음 문서를 번역한 글입니다. 총 2개의 글로 이루어진 이번 연재는 AppDynamics Global Services team의 John Aronson이 작성한 글로, Database 성능 개선을 위한 AppDynamics 활용법이 설명되어 있습니다. https://blog.appdynamics.com/p...
    Date2018.06.21 ByNeO Reply0 Views453
    Read More
  5. 1. Business Transaction을 통해 문제가 되는 Database Query 찾아내기

    본 문서는 다음 문서를 번역한 글입니다. 총 2개의 글로 이루어진 이번 연재는 AppDynamics Global Services team의 John Aronson이 작성한 글로, Database 성능 개선을 위한 AppDynamics 활용법이 설명되어 있습니다. 글이 조금 깁니다. https://blog...
    Date2018.05.02 ByNeO Reply0 Views558
    Read More
  6. DevOps 시작을 위한 가이드

    데브옵스(DevOps)의 인기는 몇 년동안 지속되고 있다. 데브옵스는 문화의 변화, 자동화, 변경 관리, 지속적인 배포 등을 설명하는데 사용된다. 본질적으로 데브옵스는 개발(Dev)팀과 운영(Ops)팀이 협업하여, 더 빠른고 신뢰성있는 릴리즈 파이프라인 구축하는...
    Date2018.04.13 ByTom Reply0 Views1000
    Read More
  7. 7. 릴리즈와 시간의 흐름에 따른 모바일 메트릭을 관리하자

    7. 릴리즈와 시간의 흐름에 따른 모바일 메트릭을 관리하자 올바른 메트릭 관리하기 다양한 앱 사용자의 요구사항에 대응하는 성공적인 앱의 공통적인 요소는 바로 데이터를 지속적으로 측정하고 모니터링하는 데에 중점을 두고 있다는 것입니다. 성능메...
    Date2018.03.12 ByNeO Reply0 Views752
    Read More
  8. 6. 배터리 광탈과 데이터 과소비를 막자

    6. 배터리 광탈과 데이터 과소비를 막자 배터리 광탈이나 데이터 과소비는 사용자가 중요시 여기는 항목이지만, 앱을 제공하는 회사에서는 종종 잊어버리기 쉬운 메트릭입니다. 연구조사 업체인 IDC1의 조사에 따르면 대다수의 사용자들이 새로운 핸드폰을 ...
    Date2018.03.08 ByNeO Reply0 Views475
    Read More
  9. 5. 주요 Flow에서 네트워크 호출을 모니터링하자

    5. 주요 Flow에서 네트워크 호출을 모니터링하자 주요 Flow의 속도를 빠르게 하는 3가지 방법 1. 상위 3개의 인터랙션을 측정하라 앱의 속도를 빠르게 하기 위한 첫 걸음은 인터랙션을 완수하는 데 걸리는 시간을 측정하는 것입니다. Userflow 기...
    Date2018.03.06 ByNeO Reply0 Views457
    Read More
  10. 4. 인터랙션 타임을 최적화하여 사용자 경험을 개선하자

    4. 인터랙션 타임을 최적화하여 사용자 경험을 개선하자 우리 앱이 사용자를 당혹스럽게 만들고 있지는 않은지? App load time과 더불어 느린 트랜잭션은 사용자를 당혹스럽게 합니다. Jakob Nielsen의 UI디자인에 관한 powers of 10 연구결과에 의하...
    Date2018.02.27 ByNeO Reply0 Views403
    Read More
Board Pagination Prev 1 2 3 Next
/ 3