와탭 딥러닝 적용기

장애를 예측할 수 있을까?

먼저 고객 또는 이용자들에게 가장 많이 들은 말은 장애를 예측할 수 없는가? 또는 장애를 인지하고 알려줄 수 있는가? 입니다. 결론부터 말씀드리면 아직은 어렵다 입니다. 왜냐하면, 장애가 무언가에 대한 답을 정확히 내릴 수 없기 때문입니다. 만약 평상시 CPU 사용률이 30% 정도인 서버가 있다고 할 때 어느 날 CPU 사용률이 60%가 되었다고 하면 이것은 장애인가? 에 대한 답을 내리기가 모호합니다.

이상치 징후 감지(Anomaly detection) 기능은 도입하기 쉽지만 이 상치에 대한 기준이 다를 뿐 더러 이상치가 감지되었다고 할 때 장애라고 판단할 근거가 무엇인가에 대한 명확한 답을 내릴 수가 없습니다. 그럼 몇 % 이상으로 설정할 수 있게 하면 되는 거 아니야 라고 한다면 기존 임계치 기반 방식과 다른것이 없다는 한계점을 가지고 있습니다. 이것은 우리가 추구하는 딥러닝이 아니라는 것 입니다..

딥러닝(Deep Learning)

다시 딥러닝으로 돌아와서 딥러닝은 수집한 데이터를 학습을 시켜 판단을 내리게 할 수 있다는 장점이 있습니다. 그럼 이제 학습을 시킨다고 가정해 봅시다. 데이터는 준비되어 있습니다. 엄청나게 많은 양의 데이터(빅데이터)가 있습니다. 무엇을 학습 시킬 것인가요? 판단을 내리기 위한 데이터는 많으나 판단된 결과가 부족합니다. 다시 말해 분류된 데이터는 없다는 게 현재의 한계입니다.

딥러닝을 적용하기 위한 과정

1. 데이터를 모은다.
2. 모아진 데이터를 분류(Classification)한다.
3. 데이터를 학습시켜 모델(Model)을 만든다.
4. API를 붙이고 서비스에 적용 시킨다.

딥러닝으로 알아서 분류되게 할 수 있을까?

예를 들어 보겠습니다. 1대의 서버를 10년 동안 관리해왔습니다. 10년 치의 서버의 CPU, 메모리 등 동작에 대한 모든 자료를 수집하고 저장해 왔다고 했을 때 학습을 한다고 하면, 누적된 데이터를 넣는 것 이 아니라 상황에 대한 분류가 있어야 합니다. 문제가 있었던 상황, 이벤트를 해서 부하량이 늘었던 상황, 갑자기 서버가 다운되었던 상황 등 이러한 상황을 분류할 수 있을 때 기계에 학습을 시킬 수 있고, 이러한 학습을 바탕으로 판단까지 내릴 수 있습니다.

지금까지 적용하면서 느꼈던 고민, 한계점들을 설명 드렸고 그럼 어떻게 해결했느냐에 대해 이야기 해 보겠습니다. 앞서 말씀드린 것처럼 모든 케이스에 대한 분류를 하기에는 시간이 너무 많이 소요됩니다. 불가능한건 아니지만 현재의 단계에서 할 수 있는 방법은 먼저 문제가 되었던, 또는 문제가 될 수 있는 패턴을 찾는 것 입니다. 이러한 패턴을 찾았다면 그와 유사한 데이터를 모으고, 모아진 데이터를 바탕으로 그 패턴이 맞는지, 아닌지만 확인해 패턴별 데이터를 분류하는 것입니다.

다행이도 SaaS(사스)로 모니터링을 제공한다는 장점으로 특정 서비스만 데이터를 수집하는 것이 아니라 다양한 고객과 서비스, 환경에 대한 데이터를 수집하고 있어 패턴별로 여러가지 케이스를 수집할 수 있었습니다. 만약 개별적인 서비스에서 이러한 케이스를 수집하려고 한다면 문제 상황의 발생 빈도가 적을 뿐더러 특정 패턴이 발생 하기 위한 여러가지 상황에 대한 데이터를 수집하는 것이 상당히 어려웠을 것입니다.

와탭에서의 딥러닝

그러면 실제로 어떻게 적용 되었는지를 살펴 보도록 하겠습니다.

히트맵이란

히트맵은 응답 시간 분포도입니다. 애플리케이션(WAS)에서 발생한 트랜젝션이 종료시간에 대해 x축으로 응답시간에 대해 y 축으로 표기 되며 각각의 x, y축에 대한 각각의 구간이 정해져 있습니다. 또한 해당 구간별 트랜젝션의 개수가 누적되며 누적된 개수만큼 색상이 진하게 표시 되는 형태입니다.

일반적인 히트맵

히트맵 패턴 종류

1. 가로라인 패턴

   여러 트랜젝션이 일정한 시간 내에 종료되는 패턴.
   자원을 획득하거나 외부 HTTS Call을 할 때 타임아웃 이나 지연이 발생할 경우 발생

2. 세로라인 패턴

   호출 시점이 다르지만 동일 시점에 트랜잭션이 종료되는 패턴.
   트랜잭션이 사용하는 공통의 자원에 일시적인 병목이 발생할 경우에 발생

3. 플라잉 패턴

   특정 리소스나 로그와 같은 공통 자원 부족현상으로 간격을 두고 파도 치는것과 같은 패턴으로 발생

4. 과부하 패턴

   전체 또는 일부 응답에 일시적으로 문제가 발생되는 일시적으로 트랜젝션이 밀집되는 패턴으로 발생

5. 폭주 패턴

   과도한 트렌잭션의 요청이나 부하가 발생한경우 응답시간이 전체적으로 증가하는 패턴으로 발생

히트맵 가로라인, 세로라인, 플라잉, 과부하, 폭주 패턴에 대해 각각 수많은 케이스 들이 학습되어 있으며 실시간으로 수집되는 데이터에서 학습된 패턴과 유사한 패턴이 발생하면 알림을 받아 볼수 있는 형태로 되어 있습니다.

마무리

개발자로서 이것저것 조사를(구글링) 해봐도 어떻게 구현한 것인지 어떻게 해야하는 건지 코드는 거의 찾을 수도 없어 초반엔 답답하기만 했습니다. 그러나 결과적으로 제가 한건 데이터를 분류하고 모델을 학습 시키는 것이 전부이며 코드도 몇 줄 되지 않습니다. 심지어 가장 많은 시간을 할애한 부분은 데이터 분류 하는 부분이고 이 분류를 기계가 알아서 하게 하기 위한 과정 이였습니다.

클라우드화, 마이크로서비스로 구조화 되며 각각의 서버나 애플리케이션의 크기는 작아지지만 개수는 늘어나고 있습니다. 개인이 관리 하는 서버, 애플리케이션도 수십대에서 수백대 많게는 천대까지 늘어나고 있습니다. 이러한 관리 요소가 늘어나면서 앞으로 모니터링은 보다 많은 보다 다양한 데이터를 제공하는 것을 넘어 당장 필요한 데이터만, 문제 상황만 바로 확인할 수 있는 서비스로 발전되어야 할 것 입니다.