고객센터 오픈소스 모니터링 구축기

퍼플아이오에서 처음 맡아 보는 고객센터 솔루션 운영과 관련해서 직접 모니터링 툴을 붙여본 후기를 적어보았습니다

시작은 상담업무의 장애를 반복해서 겪으면서 시작되었습니다

현재 코오롱FnC의 상담 시스템은 네X티X 에서 개발된 솔루션을 사용하고 있습니다

• IVR(Interactive Voice Response) : 대화식 음성 응답(interactive voice response)은 음성과 키패드를 통한 입력을 통해 컴퓨터와 인간이 상호작용하게 하는 기술
• CTI(Computer Telephony Integration) : 컴퓨터와 전화시스템을 통합해 컴퓨터의 컨트롤과 기능을 전화기에 적용시킨 것으로 사용자에게 구내로 들어오는 호출에 대해 더 많은 정보를 제공하고 정보를 분산시키는 기술
• REC(Record) : 고객 센터의 상담원과 고객 사이 통화 내용을 녹음하는 기술

크게 시스템은 3개로 구분되며 2011년도부터 사용된 걸로 보입니다 (REC-DB 생성일시)

위 3개 기술에 대한 정의를 간단히 하면 Interactive 즉 상호작용 부분이 전화기의 키패드를 통해 이루어지며 사람의 Input에 따라 정해진 제어동작 시나리오와 지정된 녹음 멘트로 응답합니다

이후 시스템에 발생하는 다량의 상담 요청 Request가 분산되어 설정된 상담원에게 연결되고 있습니다 (여기에 녹취도 포함됩니다)

시스템 설명을 하려는게 아니어서 ㅎㅎ.. 이쯤 하고 최근에 IVR 쪽에서 문제가 발생되었습니다

여기서 장애가 발생되면 전화가 먹통이 되는 (interactive가 안되는) 증상으로 서비스 중단이 됩니다.

사실 재화를 창출하는(돈을 벌어들이는) 시스템은 아니기 때문에 상대적인 중요도는 다른 것보다 낮을 수는 있지만 커머스 관점에서는 필수로 갖추어야 하는 시스템이기도 합니다

문제는 자체개발 부분이 아니기 때문에 장애 현상 발생시 강제적인 재시작말고는 조치가 어렵습니다

시스템 로그도 info 레벨만 남게되면 솔루션 업체에 전달되어도 해결이 어려울 수 있고 그렇다고 debug 성 로그를 마구 남기기는 것도 어려울 것으로 보입니다

현재 MFC(C++)로 만든 프로세스 모니터를 하는 프로그램이 있어 IVR 프로세스가 죽으면 자동 재시작은 가능하나 그 모니터링 프로그램까지 문제가 되면 어떤 장애 파악도 어렵습니다(사고 후 조치 밖에 없음)

실제로 한번은 모니터링 프로그램이 죽어서 나중에 장애가 인지되었고 한번은 프로세스는 정상인데 원인모를? 이유에 의해 프로세스를 강제로 죽이고 재시작해서 복구되었습니다

이런 상황이라면 가장 중요한 부분은 장애 인지시 제 3의 시스템에 의해 알람이 발생되거나 의심되는 부분을 확인 할 수 있는 (메모리 누수 / TCP 소켓 연결 이상) Application Performance Management 시스템에 의해 관리되어야 합니다 (제니퍼, 핀포인트, 스카우터 등이 있습니다)

현재로는 알람 발생이 가장 필요한 부분이었고 APM의 역할은 부수적인 부분이었습니다

그래서 한번 모니터링을 할 수 있는 툴을 붙여보았습니다

커스터마이징 경험이 있는 오픈소스라 사실 다른 툴에 대한 리서치는 하지 않았고 Windows 라는 플랫폼의 제한도 있기 때문에 쉽게 선택되었습니다.

일단 제가 생각한 제약 사항은 아래와 같습니다.

• Windows 기반의 application 모니터링이 가능한 툴
  • WMI(Windows Management Instrumentation)
  • SNMP(Simple Network Management Protocol)
• 따로 Agent 설치가 필요없는 Polling 방식의 간단한 툴
  • Server에서 직접 Query
• 너무 듣보잡이라고 하기에는 그래도 나름 검증된 이름값이 있어야 하는 툴
  • Stack Exchange's team (stack overflow)
• 프레임워크나 언어에 있어 다룰 줄 알아 따로 공부없이 바로 코딩이 가능한 툴
  • C# / .NET Framework

Stack overflow Tech Stack을 알아보면 Microsoft 기술 기반에서 개발을 주로 하는 것으로 검색됩니다 (https://stackshare.io/stack-exchange/stack-overflow)

현재 운영하고 있는 IVR 환경도 Windows 기반에서 동작하고 있습니다 (CTI / REC는 Linux)

큰 고민 없이 간단하게 사용하기는 적합한 것으로 보여 일단 GitHub를 들여다봤습니다

아래 그림이 해당 시스템을 간단하게 표현해 주는 것 같습니다 (큰 시스템에서는 Poller를 여러개로 묶어 Clustering 되어 보이는데 모니터링 대상이 적어 단일 Poller로 가능합니다)

Monitoring 주제에 따라 각각 Dashboard 가 연결되어 있고 모니터링 기능은 아래와 같습니다

• Dashboard
  • WMI Moritoring
  • etc : Bosun, Orion
• Exception Log Store
  • Jira issue reporting
• SQL Server Instance
• Redis
• Elasticsearch
• Haproxy(Load balancer)
• PageDuty
• CloudFlare

사용된 웹 기술은 기술은 ASP.NET MVC5 or Core 로 가능합니다

배포 방법은 Core일 떄는 Windows / MacOS / Linux 모두 가능하고 MVC일 때는 IIS를 이용할 수 있습니다

Exceptional 이라고 Error 들에 대한 로그를 쌓을 수 있는 DB를 생성할 수 있는데 MS-Sql이 기본이고 MySql 까지 지원합니다

설정에 따라 보고자하는 Web Dashboard를 상단 메뉴에서 선택할 수 있고 설정파일은 json 형태로 되어 있습니다

모니터링 모듈을 추가하고자 하면 설정파일만 추가하면 인식되고 File Watcher 가 동작하기 때문에 실시간 수정도 가능합니다

요즘 트렌드에 맞게 Docker 로도 구축 및 배포가 가능합니다

이런 형태로 대시보드에서 차트로 보는 것이 가능합니다

내부에는 디자인패턴으로 공통 Interface와 객체지향적 개발로 되어있는데 기본 개념은 Provider로 되어 있습니다

이 Provider 하나가 특정 모니터링을 주관하고 각각의 Dashboard를 가지고 있습니다

즉 WMI-Provider : Base-Provider 를 가지고 있는 형태 입니다

Configuration도 디자인 패턴으로 되어 있습니다

WMI-Settings : Base-Settings 로 되어 있어 확장이나 수정시에는 구현 클래스와 기본 클래스의 차이를 구분해야 합니다

객체지향적으로 보면 추상 클래스를 기본으로 Provider 를 통해 확장 된 패턴을 가지고 있습니다

각각의 Provider는 Module 클래스를 포함 관계로 가지고 있고 이는 Settings 가 제네릭으로 구성되어 있습니다

Effective Java에 추상 클래스와 인터페이스를 비교하는 글들이 있는데 추상 골격 즉 기본 뼈대는 추상 클래스로 되어 있고 기능 확장에 대한 부분은 인터페이스를 통해 Module과 Provider 가 분리되어 있는 패턴입니다

내부에는 Poll Engine이 동작해서 주기적으로 설정된 data 를 수집할 수 있습니다

Cache 클래스를 추상화시키고 자료구조화 해두어 누적데이터를 메모리상에 일정기간 가지고 있습니다

기간이 길어지면 모니터링 툴의 자원 점유가 늘어납니다.

이 부분은 agent가 따로 없고 DB화 된 data 체계가 없어 생기는 단점이지만 그 대신 Agent 없이 설치만 하면 독립적으로 운영이 가능합니다

Security 부분도 Active Directory 인증도 가능하고 단순 뷰어로도 가능합니다 (로그인 부분에 권한을 추가해서 커스터마이징도 가능합니다)

아래와 같은 형태 입니다

그리고 제가 원하는 부분은 아래와 같습니다

• CPU(Process 포함) / Memory 에 대한 추이 파악으로 메모리 상 누수 문제나 프로세스 상태 파악을 할 수 있다
• 프로세스 상태 파악을 하면서 프로세스가 죽어 있으면 알람을 보낸다

먼저 Opserver 현재 버전부터 보았습니다 제가 원하는 기능이 모두 있으면 제가 따로 해야할 게 없습니다

확인해 보니 HW 적인 리소스는 모니터링이 가능한데 프로세스에 대한 모니터링이 없어 해당 부분은 추가해야 했습니다

알람 부분은 Exception 대상으로만 되어 있었고 Opserver 내부에서 사용되고 있지 않았습니다 결국 제가 원하는 부분은 모두 추가 구현이 필요했습니다

다행인 것은 코드를 과거에 본적이 있기 때문에 어느 부분에서 WMI Query를 하는지 알고 있었고 Email 발송 부분도 Template을 커스텀 하게 사용한 적이 있어 큰 고민 없이 코드를 고쳐나갔습니다

WMI에서 Process의 CPU 사용량을 알아오는 Query는 검색해서 찾았고 기존 구조를 망치지 않는 형태로 추가해두었습니다

Process name은 설정에서 가져왔으며 data가 null 이 되면 프로세스가 죽은 상태이므로 email 발송하는 부분을 두었습니다 Email 발송은 원래 바로 보낼 수 없는 부분인데 나중에 다시 설명하겠습니다

Process Query 값과 작업관리자 사용 상태를 보니 값이 안 맞는 것 같아 검색해보니 Processor 개수로 나누고 있었습니다 Processor 각각이 아닌 평균치로 봐야 겠습니다

그리고 옛날 버전에도 있던 부분인데 WMI 버그인지 최초1회에는 100%을 치는 부분이 있어 해당 부분은 예외 처리 했습니다 (HW CPU도 마찬가지로 100%을 침)

대부분의 클래스나 로직은 기존 구조를 따라갔고 설정에서 프로세스 리스트를 가져오는 부분만 따로 추가했습니다

제가 서두에 json 설정 파일이 있다고 했었죠

이렇게 processMonitor 라고 한줄을 추가하면 설정에 적용됩니다

예시로 chrome이랑 visual studio를 두었습니다

Process 에 대한 알람을 추가하니 Process memory 추이도 알면 좋겠다 싶었습니다.

작년에도 고객센터 전화가 먹통이 된적이 있는데 그 때 메모리 누수에 대한 추측을 들은적이 있습니다 그리고 해당 시스템이 오래전에 만들어진 것이라 c++로 만들어진 서버라면 직접 메모리 관리상 가능성이 있다고 생각되었습니다

찾아보니 Process memory는 WMI 말고 .NET에 Process 클래스가 제공되었습니다

해당 부분은 동일 Process name으로 수집하기 때문에 동시에 수집하도록 CPU Query 쪽 아래에 두었습니다

이로서 Process cpu와 memory 사용에 대해 수집해 주는 polling 코드가 추가되었습니다

해당 매소드는 다른 수집 주기와 동일하게 적용되도록 기존 코드에 추가했습니다

내부에서 사용하는 데이터는 CPU / Memory가 구분되어 각각의 자료구조를 가지고 있는 부분이 있어 추가할 부분이 더 있으나 이 정도로 핵심기능인 Query 부분은 끝나게 됩니다

다만 이걸로 끝이 아닌게 UI에 반영 되려면 화면에서 Data를 갱신하고 차트에 반영해야 합니다

기본 구조는 MVC 형태이기 때문에 화면에서 어떻게 REST를 쓰는지 크롬의 네트워크 탭에서 확인했습니다

Opserver 의 Chart 라이브러리는 D3.js 를 사용하고 있는데 많이 쓰이는 라이브러리로 알고 있습니다

D3.js 를 사용하고 script 부분에서 ajax 로 호출하게 되어 있습니다

그리고 .NET framework의 MVC는 view template engine 을 Razor View라는 것을 사용하는데 이건 JSP나 Thymeleaf 랑 비슷합니다

HTML 안에 java 코드를 쓰듯이 c# 코드를 쓰면 됩니다

여기도 Process name을 사용하게 때문에 설정에서 가져온 이름으로 foreach 돌면서 차트를 그리게 했고 내부에서 스크립트를 호출하게 두었습니다

이렇게 해서 화면이 갱신될 때 차트를 다시 그리도록 불러와 집니다

(따로 웹소켓이 연결되어 실시간 갱신하는 부분은 없습니다 )

일반적인 Client/Server 구조가 아닌 UI 기반의 Web Dashboard이고 어플리케이션 내부에서 Thread로 동작하는 Poll Engine 이 있습니다

여기서 하나 애먹었던 부분이 있는데 기존 구현된 script에서 params 를 추가로 보내서 Polling 된 data의 key(Process name)를 보낼 수 있었는데 차트를 시간으로 Zoom을 하면 데이터가 보이지 않았습니다.

이부분은 REST나 Controller 상으로 처리하는 부분이 없어 어쩔 수 없이 script.js 파일까지 까보게되었고 여기에 하나 분기문을 추가하게 되었습니다

다행히 테스트를 해보니 기존 기능들에 영향은 없었습니다만 기능추가를 하는데 있어 if 한줄을 넣었다는것은 추후에 또 if가 추가될 여지가 있다는 부분이라 매우 맘에 안들었지만 chart zoom이 구현된 부분이 여기 밖에 없어 params 유무에 따라 처리되도록 했습니다

이 걸로 프로세스 모니터링 부분은 끝낼 수 있었습니다

두 번째는 이메일 발송 부분인데 앞에서 언급되었듯이 해당 부분도 코드를 추가해야 하는 상황이었고 발송까지 연결하는 부분이 없어 그것도 이어주어야 했습니다

Exceptional 의 main 기능은 Error에 대한 로그 수집이었기 때문에 email 발송은 부가 기능이었습니다 exception 이 발생하면 email send에 대한 부분이 선택이라 그 선택 코드를 붙이면 된다고 생각하고 원본 코드에서 필요한 부분만 가져다 사용했습니다

• SMTPClient
  • SMTP Server 설정은 json으로 지정
  • 현재 내부에서 사용하는 SMTP 서버가 없는 상황이라 gmail 설정을 통해 메일 발송
• Email Template는 동적 HTML 생성

client 설정은 설정파일로 지정하고 mail template는 고정이지만 하고자 하면 변경은 가능합니다

즉 기존에는 ErrorStore 구조를 가지고 있어 Error 가 쌓이는 형태인데 이걸 사용안하고 Notify 하는 부분만 사용해서 구조적인 변경없이 Email Sender 구현이 됩니다

3줄만 추가해서 Email Send 기능을 완료했습니다

 

그러면 이제 실제로 구축해서 어떻게 보이는지 보겠습니다

일부터 .NET Core로 진행했습니다 그러면 IIS라는 Apache 같은 웹 서버 위에서 동작하기 위해서 복잡한 Hosting 설정이 없어도 됩니다

Kestrel 이라는 것이 내장되어 있어 Spring boot 처럼 내장 Tomcat이 있는 것처럼 쉽게 구동할 수 있습니다

이런 부분을 보면 .NET Framework는 Spring 처럼 Web Framework 로서 유사점이 많은 것 같습니다

자 이제 Publish를 해보면

제가 원하는 그림은 나왔네요 Y축이 고정이라 그래프가 작아 보이긴 하지만 마우스를 가져가면 수치가 보입니다 그리고 메모리 누수가 생긴다면 이상 추이가 보일 것으로 예상됩니다

글로벌 오픈소스이기 때문에 기본시간은 UTC 시간이라 +9시를 고려해야 합니다

그리고 제일 중요한 알람발송이 되야 하는데요 테스트를 해보면 아래와 같은 메일이 오게 됩니다

메일 템플릿이 기본 Exception 기반이라 마음에 들지 않지만 보여지는건 변경이 가능하긴 합니다 현재 필요한건 장애 발생 즉시의 알람 뿐이라 이쁜 Template은 중요도가 떨어집니다

하지만 더 중요한건 현재 서버의 네트워크 구조인데요

이메일이 발송되려면 외부의 Gmail로 연결이 필요하기 때문에 인터넷이 되는 환경이 필요합니다 아니면 내부의 SMTP 서버가 있으면 되겠죠

Mail-gun이라고 제한된 무료서비스가 있었으나 현재는 유료로 전환된 것으로 알고있습니다

어쨌든 현재 고객센터 IVR 서버는 내부망으로 되어있고 내부망의 제 인터넷 PC와는 격리되어 있습니다 HITAM 이라는 원격 접속 툴을 이용해 들어가게 되어 있는데 이 부분은 간과한 것 같습니다

인터넷 되는 내부망 PC <- HITAM -> 격리된 과천 IDC 내부망 IVR Server

모니터링 툴이 데이터를 수집하고 이메일 발송까지 네트워크 상 불가능 합니다

그래서 결국 제일 중요한 장애 알람 발송은 포기하게 되었습니다

HITAM 없이도 http 연결은 되어서 중간에 중계서버를 만들어야 하나 고민도 되었지만 그렇게 되면 처음 목적에 없던 agent 같은게 필요한 상황이 됩니다

즉 사용가능한 내부 SMTP만 있다면 좋았을 텐데 그 부분이 아쉬운 부분입니다

결국 장애 모니터링은 되지만 자동 알람발생은 어려운 상태이며 솔루션 업체의 말 처럼 메모리 누수가 발생되는지 그리고 프로세스가 이상이 있는지 정도만 확인이 가능한 상황입니다

솔루션 업체에서 패치를 해주기로 해서 일단 연락을 기다리고 있지만 내부에서 프로세스 재시작을 Windows Job Scheduler를 통해 강제로 kill 하고 start 하는 것도 시스템에 문제가 안된다면 적용할 예정입니다 (이 경우 근본적인 해결이 아닌 임시 방편입니다)

 

이왕 개발한 기능이기에 Stack Exchange 쪽에 Contributing을 해보기로 했습니다

리소스 모니터링에 의한 이메일 발송은 임의로 넣은 것이기에 범용적인 사용처가 없어 해당 부분은 제외 했습니다

제대로 개발하려면 ErrorStore가 구성된 상태에서 Error 형태나 확장 된 class 로 원하는 메일 템플릿으로 적용해볼 수는 있는데 그 부분까지 사용할 용도는 아니어서 여기서 마무리하기로 했습니다

띄워 본 김에 SQL Server 와 Redis Server에 대해 모니터링도 추가해 봤습니다

WMS-DAS 쪽 SQL-Server가 Express 버전을 사용 중인데 Embulk과 Connection이 안되어서 PILS 연동 작업이 몇달 째 지연중인데 일단 툴에서는 연결이 되는 것을 확인했습니다

Embulk 에서 연결하는 Redis 도 모니터링에 추가해 봤습니다

세부 내용은 잘 모르지만 내용은 잘 가져오는 것으로 보입니다

알람 발송이 안되는게 아쉬운데 나중에 SMTP 를 쉽게 쓸 수 있는 방법이 있는지 혹은 사용하기 쉬운 오픈소스가 있는지 한번 찾아봐야겠습니다

현재 알람은 Telegram or Workplace chat으로 받고 있는 부분이 있어 email에 한정된 게 아닌 여러 매체를 통한 발송 서버를 구현해볼 수 있을까? 고민은 드네요

IVR 장애로 인해 프로세스 모니터링을 붙이게 되었는데 내용이 많이 길어졌습니다

해당 부분은 Pull Request로 올려보았고 반영될지는 미지수이지만...

Open Source로 다양한 구현이나 활용을 응용할 수 있고 다른 사람과 공통으로 개발하는 부분에서 유연한 확장을 고려해야 하니 Abstract Class와 Interface이용한 추상화에 대해서도 배워볼 수 있는 부분도 장점인 것 같습니다

내가 혼자서 다 만들면 매우 힘들텐데 기본 뼈대가 있고 필요한 부분만 커스터마이징 하면 금방 끝낼 수 있습니다 물론 코딩도 잘해야 겠지요

오픈소스를 건드리면 회사에서만 코딩하는 것이 아닌 각국 각지의 개발자들과 같이 코딩한다는 느낌이려나.. 어쨌든 회사에서 하게 되면 일 성격이 강한데 이런 오픈소스는 일 보다는 공부하는 것 같습니다

PR을 끝으로 해당 작업을 마칩니다

Opserver: https://github.com/opserver/Opserver

Exceptional: https://github.com/NickCraver/StackExchange.Exceptional