AIOps에 대해 들어보셨나요?
이번 포스팅에서는 데이터사이언티스트 관점에서 AIOps의 소개를 간단하게 다뤄보고자 합니다. 혹시라도 관심이 있으시거나 추가로 궁금한 점이 있는 독자분들께서는 댓글로 편하게 질문 주시면 좋을 것 같습니다!
AIOps란 무엇일까요?
AIOps에 대해 들어보셨나요? AIOps는 AI for IT Operations의 약자로 2016년 가트너에서 제안한 용어입니다. AIOps는 빅데이터, 분석 및 머신러닝을 활용해서 IT운영을 자동화하고 개선하는 목표를 가지는 분야입니다. 필자가 현재 개발하고 있는 분야이기도 하죠.
최근 네트워크가 점점 더 커지고 복잡해짐에 따라 IT 운영 관리가 점점 어려워지고 있습니다. 특히, 마이크로서비스, 멀티클라우드 등 데이터 환경의 복잡성과 대량의 로그 및 성능 데이터가 발생하여 기존의 작업관리자들은 장애 대응에 시간과 비용을 많이 투자할 수 밖에 없겠죠.
AIOps는 이런 IT 문제를 작업관리자들의 개입 없이 빠르게 해결하는 것을 목표로 합니다. 가트너가 정의한 AIOps 플랫폼의 핵심 기능은 다음과 같습니다.
- 소스 또는 공급업체에 관계없이 여러 소스에서 데이터 수집
- 수집 시점에서 실시간 분석 수행
- 머신러닝의 활용
- 인사이트와 분석을 기반으로 한 조치
제가 생각하는 AIOps의 주요 작업은 다음 네가지입니다.
- 데이터의 이상감지
- 장애 예측
- 근본 원인 분석
- 자동화된 조치
그럼 본격적으로 위의 주요 작업을 중심으로 AIOps에 대해 알아보도록 하겠습니다!
1. AIOps의 목표
DevOps의 운영 부분은 위 그림과 같이 Observe, Detect, Engage 및 ACT 등 네가지 주요 단계로 세분화할 수 있다고 합니다.
- Observe 단계에서는 다양한 원격 측정 데이터(성능 지표, 로그, trace등) 수집, 인덱싱 및 쿼리, 시각화가 포함되는데, 이 단계의 성능은 Time-to-observe(TTO)지표로 측정됩니다.
- Detect 단계에서는 이상 감지, 장애 예측, 상관 이벤트 찾기 등과 같은 작업이 포함되는데, 이 단계의 성능은 일반적으로 분류성능인 precision, recall 외에도 Time-to-Detect(TTD)지표로 측정됩니다.
- Engage 단계에서는 문제 분류, localization, RCA 등과 같은 작업이 포함되는데, 이 단계의 성과는 보통 Time-to-Triage(TTT) 지표로 측정됩니다. 여기서 RCA는 root cause analysis의 약자로 장애가 발생했을 때 무엇이 이 장애의 근본 원인인지 분석하는 task를 의미합니다.
- ACT 단계에서는 서버 재부팅, 리소스 확장 또는 축소 등과 같은 문제 해결 조치가 포함되는데, 이 단계에서 측정되는 주요 지표는 Time-to-Resolve(TTR)입니다.
이러한 DevOps의 운영을 수동에서 자동화된 운영으로 전환하는 것이 AIOps라고 볼 수 있습니다. 하지만 굉장히 어려운 Task임에는 분명합니다. 저희 팀에서도 이 문제를 해결하기 위해 노력하고 있지만 빠른 시일내에 달성할 수 있는 문제는 확실히 아닌 것 같습니다..
2. AIOps의 Data
먼저 AIOps에서 활용하는 데이터부터 알아보도록 하겠습니다. 위에서 Observe 단계에서는 성능 지표, 로그, trace등의 데이터를 수집한다고 했었는데, 바로 이 데이터들이 AIOps에서 활용할 수 있는 데이터라고 볼 수 있습니다.
2.1 성능 지표
성능 지표는 보통 Metric이라고 표현합니다. 성능 지표는 시간이 지남에 따라 측정되어 시스템 동작의 스냅샷을 제공하는 수치 데이터입니다. 보통 시계열 데이터이죠. 이 데이터는 크게 compute metrics와 service metrics 두 종류로 분류를 할 수 있습니다.
- Compute metrics : 서버, 가상 머신과 같은 컴퓨팅 노드의 상태를 나타내는 지표입니다. 예를 들어 CPU 사용률, 메모리 사용량, 디스크 I/O등이 있습니다.
- Service metrics : 고객 대면 애플리케이션의 서비스 품질과 수준을 측정한 지표입니다. 예로는 요청 수, 페이지 방문 수, 에러 수 등이 있을 수 있습니다.
이러한 성능 지표들은 양이 굉장히 많습니다. 떄문에 저장 및 분석이 어렵습니다. 또한 정확한 분석을 위해서는 frequency의 단위가 작아야하는데(ex. 1분단위 데이터보단 1초단위 데이터가 정확한 분석을 하기에 용이합니다.), 그렇게 되면 데이터의 용량은 점점 더 커지게 됩니다. 이러한 물리적 한계점이 있지만 성능 지표를 통해 전체 IT 운영의 상태를 한눈에 파악할 수 있기 때문에 장애 또는 잠재적 문제를 발견하고 사전 조치를 취할 수 있습니다.
성능 지표 데이터를 통해 우리는 이상 감지, 장애 예측 등의 task를 진행할 수 있습니다. 하지만 시계열 데이터의 주기적 패턴, 간헐적인 스파이크, 노이즈가 있는 신호 등 다양한 패턴을 나타낼 수 있기 때문에 실제로는 어려운 task라고 생각합니다. 특히 이상 또는 장애라는 label을 구하기 굉장히 힘들고, 몇천, 몇만의 다른 성격과 scale을 가진 데이터들을 통합해야하기 때문에 개인적으로 굉장히 도전적인 task라고 느끼고 있습니다. 아래 그림은 성능 지표의 예시를 보여주는 그림입니다.
2.2 로그
로그는 소프트웨어 개발자가 유지 관리 목적으로 설계한 시스템 내 프로세스에 대한 런타임 정보의 기록입니다. 개발자들에게 익숙한 이 로그 데이터도 AIOps에서 분석의 대상이 됩니다.
로그 데이터를 통해 AIOps에서는 로그 이상감지를 진행할 수 있습니다. 하지만 이 task를 진행하기 위해서는 로그의 전처리는 필수입니다. 로그는 일반적으로 반정형데이터입니다. 다시 말해 텍스트 데이터입니다. 이 텍스트 데이터를 분석하기 용이하게 패턴화하는 작업이 필요합니다. 여기서 어려움이 발생하는데, 각 로그라인은 일반적으로 개발자가 설계한 템플릿인 고정 부분과 시스템에 대한 런타임 정보를 챕쳐하는 가변 부분으로 구성되지만, 이 템플릿이 소프트웨어마다 다를 수 있습니다(실제로 많이 다릅니다ㅠㅠ).
저희 팀에서는 Drain이라는 로그패턴을 추출하는 알고리즘을 통해 로그데이터를 분석합니다. 하지만 정형화된 템플릿을 가지고 있는 로그파일에 대해서는 Logstach와 grok을 통해 패턴화하고 있습니다. 아래 그림은 로그에 대한 예시그림입니다.
2.3 Traces
trace data(추적 데이터)는 저에게는 다소 생소한 데이터입니다. 아직 다뤄보지 못했지만 내년 KPI로 잡혀있어 기대가 많이 되는 데이터이기도 합니다.
trace data는 시스템에서 요청 또는 실행의 진행 상황에 대해 수집된 정보를 말합니다. 이 데이터는 일반적으로 반구조화된 로그 형태로 표시되며, 여기에는 요청 대상의 어플리케이션 및 네트워크 흐름의 토폴로지 맵을 재구성하는 데 사용할 수 있는 식별자가 포함됩니다.
이 데이터를 사용하면 어떤 점이 유용할까요? trace data는 추적에 용이합니다. 데이터를 추적하면 다앙한 데이터 양식을 동일한 context에 넣을 수 있기 때문에 유용할 수 있습니다. 요청이 여러 서비스 및 어플리케이션을 통해 이동하는 경우가 많으며 각 서비스 및 어플리케이션마다 동작이 다를 수 있기 때문에 trace data는 굉장히 중요합니다.
아래는 trace data를 통해 그린 trace graph의 스냅샷입니다.
3. AIOps의 구성
위 그림은 AIOps의 전체적인 파이프라인을 보여주고 있습니다.
AIOps는 크게 이상감지, 장애 예측, RCA, 조치 네 단계로 구성되어 있는데 본 포스팅에서는 데이터 관점에서 이상감지, 장애 예측, RCA에 대해 간단하게 다뤄보도록 하겠습니다.
3.1 이상 감지
이상감지는 말 그대로 비정상적인 것을 식별하고 탐지하는 과정을 의미합니다. 이 task의 주요 목표는 이상 발생 시점부터 이상을 탐지하는 데 걸리는 시간인 MTTD(mean-time-to-detect)를 줄이는 것이라고 할 수 있습니다.
성능 데이터의 이상감지, 로그 데이터의 이상감지, trace 데이터의 이상감지 등의 유형이 있는데 각각에 대한 자세한 설명은 이후 포스팅에서 다룰 기회가 있을 것 같습니다.
3.2 장애 예측
장애 예측은 AIOps에서 중요한 작업입니다. 장애 예측의 주요 목적은 잠재적인 문제가 발생하기 전에 장애를 예측하여 사전 조치를 취해 영향을 최소화하는 것입니다. 최근 정부망 마비사태로 인해 수많은 경제적 피해가 발생했는데 이러한 사례를 통해 사전 조치를 취하는 것이 얼마나 중요한지 확인할 수 있습니다.
장애 예측은 성능 데이터를 통한 예측, 로그 데이터를 통한 예측 등의 유형이 있을 수 있습니다. 하지만 장애예측은 주식예측과 마찬가지로 수많은 변수들이 있기 때문에 아직까지는 굉장히 도전적인 과제인 것 같습니다.
3.3 RCA (Root Cause Analysis)
RCA란 이상이 발생했을 때 이 이상현상이 무엇때문에 발생했는지 분석하는 task입니다. RCA를 통해 다운타임을 줄이고 운영 효율성을 개선하며 수고를 줄일 수 있기 때문에 굉장히 중요한 작업인데 그만큼 어려운 분야이기도 합니다.
실제로 저희 팀에서는 RCA 연구에서 초기에는 성능 데이터를 이용한 시계열 인과그래프를 추론하고 이를 통해 원인을 찾으려 노력했습니다. 하지만 수집한 데이터의 frequency가 높을 경우 각각이 다른 초에 발생했더라도 데이터에는 같은 분에 발생했다라고밖에 판단할 수 없습니다. 이는 인과그래프의 정확도를 현저하게 낮춰 한계점으로 나타났습니다.
하지만 도전적인 분야임에도 불구하고 AIOps에서 매우 필수적인 요소이기 때문에 연구에 투자를 많이 해야하는 분야라고 개인적으로 생각합니다.
3.4 자동조치
자동조치는 AIOps에서 최종적인 단계로 시스템이 문제를 해결하거나 성능을 개선하기 위해 자동으로 조치를 취하는 단계를 뜻합니다. 이를 위해서는 도메인 전문가들과의 소통이 필수적이라고 생각합니다. 데이터만 보고 조치를 취하는 것은 한계가 분명이 있을테니까요.
또한 최근 크게 발전한 LLM의 적용을 자동조치에 하는 것도 좋은 접근방법 같습니다. 장애조치를 정리한 문서를 fine tuning하여 사용자에게 제안한다면 AIOps의 최종적인 output으로 손색이 없을 것 같다는 개인적인 생각이 드네요.
정리
AIOps는 데이터사이언스 분야에서 주요 분야는 아닙니다. 이미지나 텍스트와 같이 활발한 연구가 진행되는 분야도 아닙니다. 또한 미리 정의된 장애 등의 label도 없어 연구하기 굉장히 어렵기도 합니다.
하지만 그 필요성과 성장가능성을 보았을 때 충분히 매력적인 분야라고 생각합니다.
댓글남기기