기술이야기 | 브레인즈컴퍼니

주메뉴 바로가기 본문 바로가기

메인 페이지로 이동
블로그
기술이야기

블로그

기술이야기

기술이야기 Zenius EMS 솔루션으로 IT 인프라를 통합 모니터링 해야하는 4가지 이유 기술이야기 Zenius EMS 솔루션으로 IT 인프라를 통합 모니터링 해야하는 4가지 이유 최근 IT 인프라는 과거보다 훨씬 복잡하고 빠르게 변화하고 있습니다. 예전에는 서버, 네트워크 장비, 데이터베이스, 몇 가지 핵심 애플리케이션만 관리하면 되었지만, 이제는 VMware·Hyper-V 같은 가상화 플랫폼과 Kubernetes 기반의 컨테이너 환경이 기본이 되었고, AWS·Azure·NCP 등 퍼블릭 클라우드까지 결합되며 온프레미스와 클라우드가 혼합된 하이브리드 클라우드 환경이 일반화되었습니다. 이처럼 다양한 요소로 구성된 인프라를 개별 도구로 관리하면, 장애 발생 시 원인 파악과 해결에 많은 시간과 노력이 필요합니다. 운영자는 수많은 로그와 모니터링 화면을 오가며 원인을 추적해야 하고, 복구 역시 수작업에 의존하는 경우가 많습니다. 작은 장애 하나도 전체 서비스 가용성에 영향을 미칠 수 있는 환경에서, 통합적이고 지능적인 IT 인프라 관리 체계가 꼭 필요합니다. 브레인즈컴퍼니의 Zenius EMS는 이러한 복잡한 환경에서 안정성과 효율성을 동시에 확보할 수 있도록 설계된 통합 IT 인프라 관리 솔루션입니다. 서버, 네트워크, 데이터베이스, 애플리케이션, 가상화, 컨테이너, 클라우드를 한 화면에서 관리할 수 있으며, AI·SIEM·OAM 등 다양한 모듈을 연계하면 운영 자동화, 예측 분석, 보안, 규제 준수까지 한 번에 대응할 수 있습니다. 이제, Zenius EMS로 IT 인프라를 통합 관리해야 하는 네 가지 핵심 이유를 살펴보겠습니다. 1. 모든 IT 인프라를 아우르는 진정한 통합 모니터링 기업의 IT 환경은 온프레미스 서버, 스토리지, 네트워크 장비, 데이터베이스, 애플리케이션을 비롯해 가상화와 컨테이너, 퍼블릭 클라우드까지 다층적으로 구성됩니다. 이렇게 다양한 구성 요소가 혼재된 환경에서는 개별 도구만으로 전체 상태를 파악하기 어렵고, 장애 발생 시 원인 분석에 많은 시간이 소요됩니다. 예를 들어 웹 애플리케이션의 응답이 느려지면, 서버의 CPU·메모리, 네트워크 트래픽, 데이터베이스 세션, 컨테이너 Pod 상태를 각각 확인해야 하며, 이 과정에서 근본 원인 파악이 늦어질 수 있습니다. Zenius EMS는 이러한 복잡한 환경을 단일 플랫폼에서 완전히 통합해 관리할 수 있도록 설계되었습니다. 단순히 서버와 네트워크 상태를 나열하는 수준이 아니라, 모든 인프라 데이터를 연관 관계 기반으로 실시간 시각화합니다. 토폴로지 맵과 서비스 맵은 각 구성 요소 간의 연결 상태와 서비스 흐름을 직관적으로 보여주어, 장애나 성능 저하가 발생했을 때 어느 구간에서 문제가 시작되었는지를 빠르게 파악할 수 있습니다. 또한 다차원 대시보드와 Top N 현황을 통해 자원 사용률, 트래픽, 세션 수, 이벤트 발생 빈도 같은 핵심 지표를 종합적으로 살펴볼 수 있습니다. [ Zenius EMS 솔루션 예시화면_ 대시보드/오버뷰 구성 ] 이를 통해 운영자는 한 화면에서 전체 인프라의 상태와 성능을 동시에 확인할 수 있으며, 필요한 경우 특정 서비스나 장비까지 드릴다운하여 상세 정보를 확인할 수 있습니다. 예를 들어 웹 서비스 응답 지연이 발생하면, 대시보드에서 서버 부하, 네트워크 트래픽, DB 세션, 컨테이너 Pod 상태까지 유기적으로 연결된 데이터를 기반으로 근본 원인을 신속하게 도출할 수 있습니다. 이처럼 통합 관제 환경이 제공하는 가장 큰 장점은 운영 효율성의 향상입니다. 더 이상 여러 모니터링 도구를 전환하며 데이터를 수집하고 조합할 필요가 없고, 이벤트 발생과 분석, 원인 파악, 대응까지의 시간이 크게 단축됩니다. 2. 장애 예방과 신속한 대응 지원 Zenius EMS는 IT 인프라 운영에서 중요한 과제인 장애 예방과 신속한 대응을 위해 설계되었습니다. AI 모듈과 연계해 서버, 네트워크, 데이터베이스, 컨테이너 등에서 발생하는 성능 지표를 분석하며, CPU·메모리 사용률, 네트워크 트래픽, DB 세션 등 핵심 지표를 기반으로 병목이나 이상 징후를 사전에 감지합니다. 또한 임계치에 도달하기 전 알림을 제공해 운영자가 미리 조치를 준비할 수 있어 서비스 중단 위험을 크게 줄일 수 있습니다. [ Zenius EMS 솔루션 예시화면_ AI 연계 ] Zenius EMS는 인프라 전반에서 발생하는 이벤트를 실시간으로 수집·연계해 비정상 패턴을 탐지하며, 문제 발생 시 통합 대시보드와 서비스 맵을 통해 상태 변화를 직관적으로 확인할 수 있습니다. 장애가 실제로 발생하면 OAM(운영 자동화) 모듈과 연계해 탐지부터 복구, 정상화 확인, 결과 통보까지 전 과정을 자동화하고, 모든 조치 이력은 기록으로 남아 추후 분석과 정책 개선에 활용됩니다. 또한 SIEM 모듈과 함께 사용하면 로그 수집·저장·분석·시각화를 한 곳에서 처리해 서비스 이상 징후를 보다 정밀하게 파악할 수 있으며, 장애 재발 방지와 사후 분석에도 효과적입니다. 이렇게 Zenius EMS는 사전 예방과 신속 대응을 하나의 체계로 연결하여 운영자는 반복적인 긴급 대응에서 벗어나 전략적 운영에 집중할 수 있고, 기업은 서비스 가용성과 안정성을 높이며 운영 효율성까지 함께 확보할 수 있습니다. 3. 대규모·클라우드 환경에서도 안정적인 확장성과 성능 대규모 환경과 멀티 클라우드 아키텍처에서는 서버, 네트워크, 데이터베이스, 가상화, 컨테이너, 클라우드 리소스를 동시에 안정적으로 관리할 수 있는 능력이 필요합니다. 관리 범위가 넓어질수록 이벤트 발생량과 성능 데이터의 양은 급격히 증가하며, 이를 제때 수집하고 분석하지 못하면 장애 징후를 놓치거나 대응이 늦어질 수 있습니다. Zenius EMS는 이러한 환경을 안정적으로 운영할 수 있도록 설계되었습니다. 다양한 인프라에서 발생하는 이벤트와 성능 지표를 실시간으로 수집하고, 이를 기반으로 상태 변화를 빠르게 감지합니다. CPU·메모리·스토리지 사용률, 네트워크 트래픽, 세션 수 등 주요 지표를 통합 대시보드에서 한눈에 확인할 수 있어, 대규모 환경에서도 일관된 관제 체계를 유지할 수 있습니다. 또한 SIEM 모듈과 연계하면 대용량 로그까지 함께 수집·분석할 수 있어, 방대한 환경에서도 통합 모니터링과 실시간 관제를 강화할 수 있습니다. [ Zenius EMS 솔루션 예시화면_ K8s] Zenius EMS는 컨테이너와 멀티 클라우드 환경에도 최적화되어 있습니다. Docker와 Kubernetes 기반 환경에서는 Pod, Node, Container 단위까지 세밀하게 모니터링할 수 있으며, AWS·Azure·NCP 같은 퍼블릭 클라우드와 온프레미스를 유기적으로 연결해 하이브리드 환경 전반을 일관성 있게 관리할 수 있습니다. 이와 같은 구조를 통해 Zenius EMS는 서버 수가 많고 복잡도가 높은 환경에서도 안정적인 서비스 운영을 지원합니다. 운영자는 인프라 전반의 상태를 명확하게 파악하고, 문제 발생 시 빠르게 대응할 수 있어 서비스 가용성과 안정성을 유지할 수 있습니다. 4. 보안·컴플라이언스까지 통합 지원하는 플랫폼 Zenius EMS는 운영 효율화를 넘어 보안과 규제 준수까지 한 번에 대응할 수 있는 통합 플랫폼입니다. 서버와 네트워크 장비의 보안 취약점은 SMS·NMS·GPM 모듈과 연계해 행정안전부 권고 기준으로 자동 점검하며, 점검 결과를 기반으로 한 보안 조치 가이드도 제공합니다. 이를 통해 운영자는 복잡한 점검 업무를 간소화하고, 인프라 전반의 보안 수준을 체계적으로 유지할 수 있습니다. 접근 제어와 감사 기능 역시 강화되어 있습니다. 비인가 사용자의 접근은 IP·기간·시간 단위로 제한할 수 있으며, 금지 명령어 실행을 차단하고, 모든 세션 수행 이력을 녹화해 감사 추적이 가능합니다. 공공기관이나 금융권처럼 높은 수준의 보안이 요구되는 환경에서도 안정적으로 운영할 수 있는 이유입니다. 또한 SIEM 모듈을 통해 로그 수집·저장·분석·시각화를 일원화하고, Zenius AI 모듈과 결합하면 잠재적 보안 위협과 서비스 이상 징후를 사전에 식별할 수 있습니다. 모니터링, 보안, 규제 준수를 통합적으로 제공하는 Zenius EMS는 IT 운영 리스크를 최소화하고, 기업의 IT 거버넌스를 한 단계 높여줍니다. [ Zenius EMS 솔루션 예시화면_ DBMS ] Zenius EMS 솔루션은 국내외 약 1,500여 고객사에서 활용되고 있으며, 공공기관, 금융권, 의료기관, 대기업, 국방, 해외 사업장 등 다양한 환경에서 안정성과 확장성을 이미 검증받았습니다. 하이브리드와 멀티 클라우드가 혼재된 복잡한 인프라에서도 예측 가능한 운영과 높은 효율성, 그리고 보안 신뢰성을 확보해 서비스 품질을 안정적으로 유지할 수 있습니다. 이러한 검증된 경험과 성능을 기반으로 Zenius EMS는 운영자에게는 일관되고 편리한 관리 환경을, 기업에는 안정성과 경쟁력을 제공하며, 현재도 여러 산업 현장에서 안정적인 IT 인프라 운영을 지원하고 있습니다. 2025.08.07
기술이야기 시련이 많았던 경험자의 CI/CD 간략 소개 기술이야기 시련이 많았던 경험자의 CI/CD 간략 소개 과거에는 근로자 1명이 기획/설계/구현 테스트까지 진행이 가능했다고 합니다. 하지만 최근에는 근로자 1명이 기획부터 테스트까지 진행하는 일은 거의 드물다고 볼 수 있습니다. OLD SCHOOL 지금 이 시간에도 많은 회사 내의 개발자들은 자신에게 주어진 기능 구현을 훌륭하게 완수하기 위해서 모니터를 째려보고 있습니다. 모니터를 째려보다가 자신이 작성한 내용을 다른 팀원에게 공유하고자 혹은 반대로 다른 팀원이 작성한 내용을 공유받고자 '형상 관리 시스템'을 사용하고 있습니다. CVS와 SVN으로 대표되는 이 시스템은 최근들어 Git을 많이 사용하는 추세라고 합니다. 필자 역시 여러 프로젝트에서 해당 시스템을 사용도 해보았고, 연동하여 다른 시스템을 구현한 경험이 있습니다. 하지만 프로젝트 마다 해당 시스템 사용에 있어서 몇몇 시련이 있었습니다. "차주에 전체 기능 리뷰가 있습니다. 각 파트 별로 코드 커밋해주세요." 라고 PM(Project Manager) 또는 PL(Project Leader)이 요청을 하면, 각 하위 PL(Part Leader)은 파트(Part)에 돌아가 파트원들에게 이 내용을 공유하고, 개별 개발자들은 자신이 작성한 코드를 관리 시스템에 커밋하게 됩니다. 잠시 후 형상 관리 시스템에서 작성 코드를 내려 받은 PL(Part Leader)은 아래와 같은 상황에 직면하게 됩니다. - 동료의 작성 코드에는 관심 없이, 본인의 작성물만 커밋하는 경우 - 별도의 공지 없이 이미 작성된 파일 등을 삭제하여 커밋하는 경우 - 약속되지 않은 환경이나 lib으로 작성한 코드를 커밋하는 경우 프로젝트에 따라 기간이 길어지거나 다른 여러 상황이 발생하면 위의 문제보다 더 많은 문제를 경험하게 됩니다. 각 파트 단위로 위와 같은 문제가 해결되고 정상적으로 컴파일, 빌드까지 완료되면, PL(Part Leader)들은 파트별로 단위테스트를 완료하고 결과가 정상적이면 결과를 품질관리자에게 통보합니다. 각 파트별로 완료 통보를 받은 품질관리자는 다시 관리 시스템에서 전체 작성물을 수동으로 내려받아 통합테스트를 진행합니다. 통합테스트까지 완료되었다면 해당 내용을 릴리즈관리자에게 통보합니다. 릴리즈관리자는 바뀐 부분만 찾아서 변경하면 시간적으로 적용이 빠르겠지만 '바뀐 부분만 변경하면 될까?'라는 의심으로 전체 작성물을 수작업으로 전처리(컴파일 & 빌드)하고 다시 수작업으로 릴리즈하게 됩니다. 만약 진행상의 이슈가 없다면 이제 기능 리뷰 준비가 완료됩니다. 단계별로 문제 없이 진행되고 모든 기능을 확인하였다고 하지만 기능 리뷰 혹은 데모만하면 꼭! 오류가 발생하여 난처한 상황이 종종 발생하곤 합니다. 필자 역시 이런 경우가 많았으며 그때마다 문제 부분을 찾기 위해 많이 고생했습니다. 아래의 개념은 아마도 저 같은 경험을 하고 있는 많은 사람들을 위한 것이 아닌가 싶습니다. CI (Continuous Integration, 지속적인 통합) '지속적인 통합'이란 개발 과정에서 생산되는 코드의 관리와 코드의 문법적인 오류 확인 및 기능 점검(=테스트)을 특정한 일정에 진행하는 것이 아니라 날마다 혹은 특정 시간마다 진행하여 코드 및 기능에 대한 품질을 유지하는 개념이라고 말할 수 있을 것입니다. 앞에서 언급했던 과거 모습을 개선하는 노력은 CI 라는 개념이 나오기 이전부터 많은 개발사 혹은 팀에서 그들만의 문화나 관습으로 처리하는 경우가 있었을 것입니다. 하지만 문제는 새로운 구성원이 생겼을 때 입니다. 조직 문화를 새로이 접하는 이들에게는 이를 설명하고 이해시키는 일은 시간과 노력이 드는 일이니까요. 하지만 이젠 일반적인 Java 개발팀에서는 SVN(or GitHub)+Jenkins+Maven+JUnit으로 구성하는 개발 환경을 사용하고 있습니다. 다만, 프로젝트 목표나 목적되는 환경에 따라 약간씩 다른 환경을 구성하기도 합니다. 그러나 대부분의 경우 Open Source 기반으로 CI 개념을 구성하는 경우가 많습니다. 이는 일단 무료라는 큰 장점과 많은 레퍼런스가 있어 구성하기 편리하고 "우린 Open Source인 SVN과 Jenkins를 사용합니다. 일단 자세한 개념과 동작 원리는 너트뷰 선생님께..." 라고 하며 짧은 노력으로 교육을 끝낼 수 있어 그런 것이 아닌가 합니다. CI 개념을 활용하는 개발 프로젝트에서는 UI 메뉴 혹은 구현 단위 기준으로 구분하여 개발파트나 개발자를 할당하고는 합니다. 각각의 개발자는 할당받은 구현 범위에 대한 문제를 개별적으로 개발 도구를 활용하여 구현하고 구현 내용을 형상 관리 시스템에 커밋합니다. 이런 과정을 다른 개발자들도 같이 수행한 후에 빌드 자동화 환경에서 컴파일 및 빌드 스크립트에 맞춰서 문법적으로 확인된 결과물을 만들고 이를 다시 기능이 확인이 가능한 테스트 스크립트에 맞춰서 테스까지 진행합니다. 만약 테스트 과정에서 비정상적인 결과가 발생할 경우, 해당 내용 수정 후 위의 작업을 다시 진행하게 됩니다. 이런 일련의 절차는 일정 시간 준위 단위로 수행되어 구현하고 있는 기능을 주기적으로 확인하는 과정을 수행합니다. 올바른 진행을 위하여 개발자 개개인에게 분장되는 업무의 크기가 비슷해야 한다고 생각됩니다. 개발자별로 업무의 크기가 서로 다른 겨우, 결과물이 정상적이라고 볼 수 없게 될 것이고 그렇게 된다면 테스트 결과 역시 믿을 수 없는 경우가 발생할 것입니다. CD (Continuous Delivery/Deploy, 지속적 제공/배포) 지속적인 통합(CI)을 사용하던, 기존의 개발 환경을 사용하던, 결국 작성된 결과물은 최종적으로 운영환경에 적용되어 사용작 혹은 타 시스템과 연결되어야 합니다. 그래야 제품 개발 또는 프로젝트가 완료됩니다. CD는 결과물을 운영환경에 적용하는 방식을 나타내는 환경으로써 결과물 적용 여부를 판단하는 행위를 담당하는 주체가 누구냐에 따라, Continuous Delivery와 Continuous Deploy로 구분됩니다. Continuous Delivery는 CI 환경을 통하여 자동으로 컴파일 및 빌드가 되고, 테스트된 결과물에 대해서 릴리즈 관리자가 적용 시점마다 테스트 결과 및 서비스 영향도를 판단하여 수동으로 적용하는 방식이며, Continuous Deploy는 결과물은 항상 옳고 서비스 영향도는 없다고 미리 판단하여 자동으로 적용하는 방식입니다. 아마도 대부분의 개발 환경에서는 Continuous Delivery로 적용하고 있기에 CD라고 표기되는 경우 Continuous Delivery를 의미하는 경우가 많을 것입니다. 소프트웨어 솔루션을 제작하는 개발팀에서는 아마도 Continuous Delivery로 또한 MSA 기반의 서비스를 제공하는 개발팀에서는 Continuous Deploy를 사용하는 편이 여러 관계를 보았을 때 유리하다고 판단합니다. 하지만, 개발팀의 업무 성격과 제품 혹은 서비스의 출시 시기 등이 CD 방식을 결정하는 가장 중요한 요소가 될 것입니다. 지금까지 CI/CD 도입 배경과 내용을 필자의 경험을 바탕으로 간략하게 정리하였습니다. 개발자들이 자기가 맡은 기능 혹은 프로세스에만 전념할 수 있는 훌륭하고 편리한 개발 환경 및 적용 환경이 언제 어떻게 나타나게 될지 궁금합니다. 가능하다면, 많이 바꿔서 따라가기 귀찮은 시니어들과 새롭게 따라가야하는 주니어 개발자 모두에게 즐거운 환경이 등장했으면 합니다. 감사합니다. 2023.08.22
기술이야기 머신러닝 기반 메트릭 데이터 이상탐지 기술이야기 머신러닝 기반 메트릭 데이터 이상탐지 개요 이상탐지(Anomaly Detection)는 시계열 데이터에서 과거 또는 비슷한 시점의 다른 데이터의 보편적인 패턴에서 벗어나거나, 벗어나려는 징후가 있는 드문 패턴이나 사실, 대상 개체를 찾아내는 데이터 분석의 한 분야입니다. 시계열이 아닌 것 중에 이상한 것을 찾는 것은 대부분 아웃라이어 탐지에서 다루고 있으나, 아웃라이어 탐지와 이상탐지를 구분하지 않고 넓은 의미에서 이상탐지로 취급합니다. 기존에는 이상탐지를 위해 통계학 기술을 많이 사용해 왔으나, 최근에는 머신러닝 기술을 이상탐지에 적용하는 사례가 늘어가고 있습니다. 당사의 ITIM 제품인 Zenius EMS는 과거 성능 패턴에 대해서 통계 기반의 상∙하한 동적임계치를 구한 뒤, 임계치를 벗어날 가능성이 있는 성능치에 대한 장애 발생가능성을 선제적으로 통보해주는 Proactive(사전장애예측-이상탐지) 기능이 이미 구현돼 있습니다. 필자는 최근에 주목받고 있는 AI 기술을 접목해 단일 성능치가 아닌 메트릭 데이터 셋에 대한 이상탐지 기능을 구현하기 위한 연구를 진행했고 그 결과에 대해 기술하고자 합니다. 이상탐지와 머신러닝 머신러닝으로 이상탐지를 구현하는 학습법은 ▲지도학습 ▲비지도학습 ▲반지도학습으로 구분할 수 있습니다. 지도학습 기반으로 머신러닝을 구현하기 위해서는 기존에 수집된 데이터 중 정상적인 데이터 셋과 이상한 것으로 판별된 데이터 셋을 적절히 섞어서 학습데이터 셋을 만들어야 합니다. 그러나 실제 수집되는 데이터에서 이상 사례로 판별된 학습 데이터를 확보화는 것은 상당히 어렵습니다. 소량의 정답데이터를 이용해서 비슷한 것을 찾아 내거나 학습데이터를 확장시키는 반지도학습을 고려할 수도 있지만, 이 경우도 고객사에 제품을 납품한 이후 일정 시간동안 이상사례에 대한 학습 데이터를 수집해야 하고, 좋은 모델을 만드는데 시간이 너무 오래 소요됩니다. 따라서, 고객사에 제품 납품 후 머신러닝을 빠르게 적용할 수 있도록 비지도학습을 통해 이상탐지를 구현할 수 있는 방법을 중점적으로 고려하게 됐습니다. 비지도학습 이상탐지 ITIM 제품인 Zenius EMS가 수집하는 메트릭 데이터는 대부분 정상 데이터이므로 수집된 데이터 중 일부 비정상 데이터(감시설정에 의해 이벤트가 발생된 데이터)를 자동으로 제거해서 비지도학습을 수행했습니다. 학습에 사용되는 데이터는 모두 정상 데이터이므로 PCA(Principal Component Analysis)를 이용해 차원을 축소하고 복원하는 과정을 통해 비정상 데이터를 검출할 수도 있으나 이번 연구에서는 Neural Network의 Autoencoder 기반의 머신러닝 기법을 사용했습니다. Autoencoder는 입력을 Latent Variable로 압축하는 Encoding과, 이를 다시 원본에 가깝게 복원해내는 Decoding 과정으로 진행되며 이를 통해 데이터의 중요한 정보들만 압축적으로 학습할 수 있습니다. <그림 설명: Autoencoder 개요> 위 그림은 Autoencoder의 기본적인 원리를 나타내고 있습니다. 정상 데이터셋을 통해 학습된 Autoencoder에 정상 샘플을 입력하게 되면 Decoder를 통해 나온 출력이 정상 샘플과 유사하게 잘 복원되지만 비정상적인 샘플을 입력하게 되면, 입력과 출력 값의 차이가 도드라지게 발생하게 되므로 비정상 샘플을 검출할 수 있습니다. 다만, Autoencoder의 Code Size(Latent Variable의 Dimension) 같은 Hyper-Parameter에 따라 전반적인 복원 성능이 좌우되기 때문에 판정 정확도가 지도학습에 비해 다소 불안정하다는 단점이 존재합니다. 또, Autoencoder의 입력과 출력의 차이를 어떻게 정의할 것인지, 어떤 Loss Function을 사용해서 Autoencoder를 학습시킬지 등 여러가지 요인에 따라 성능이 크게 달라질 수 있습니다. 이를 보완하기 위해 ICLE 2018 Conference에서 발표된 Deep Autoencoding Gaussian Mixture Model for Unsupervised Anomaly Detection을 이용했습니다. (https://iclr.cc/Conferences/2018/Schedule?showEvent=126) DAGMM DAGMM은 축소된 차원과 복원 오차에 대한 특성을 유지하여 입력 값의 중요 정보를 저차원상에서도 보존합니다. DAGMM에서는 차원 축소를 위한 Compression Network에 Autoencoder를 사용해 저차원상의 자료와 축소된 저차원상에서 original data 공간으로의 복원 에러에 대한 특성 정보를 계산할 수 있습니다. DAGMM은 학습된 저차원 공간에서 GMM(Gaussian Mixture Model)을 활용해 복잡한 구조를 가진 입력 자료에 대한 밀도 함수 추정을 수행합니다. 차원 축소와 밀도 함수 추정을 동시에 최적화하기 위해, DAGMM은 저차원 입력을 계산한 뒤, 혼합 밀도 함수를 추정하는 Estimation Network를 사용하고, 입력 자료를 저차원으로 축소시킨 뒤 에너지/가능도 평가 가능하게 해 GMM의 모수를 직접 추정합니다. <그림 설명: DAGMM 개요> DAGMM은 위 그림과 같이 두개의 주요 요소인 Compression Network와 Estimation Network로 구성돼 있습니다. Compression Network는 Deep Autoencoder를 사용해 입력 자료의 차원을 축소하고, Estimation Network는 차원이 축소된 자료를 입력 값으로 해, GMM의 가능도/에너지를 예측합니다. DAGMM에 대한 자세한 내용을 원하시는 경우, ICLR 2018 Conference 홈페이지의 논문 및 자료를 참조해 주십시오. DAGMM 기반 이상탐지 ITIM 제품인 Zenius EMS의 이상탐지를 위해 입력 데이터 셋은 메트릭 데이터로 구성합니다. 연관관계가 있다고 판단되는 메트릭 데이터 중 CPU Usage, Memory Usage, Disk Busy Rate, Network In bps 값을 4차원 데이터셋으로 구성한 후, DAGMM의 Compression Network를 통해 차원 축소를 진행하고 Estimation Network를 통해 가능도 및 에너지 예측을 진행했습니다. 입력 데이터셋은 실제 장비의 메트릭 데이터 중 최근 1000개의 데이터를 사용해 구성했으며, 모델의 정확성을 확인하기 위해 2개의 이상치 데이터를 혼합했습니다. 입력 데이터셋으로 사용된 4차원 데이터를 도식화하기 위해 3차원 Scatter 차트를 사용해서 데이터를 출력하면 아래와 같습니다. <그림 설명: 입력 데이터셋(1)> 위의 그림으로 CPU Usage, Memory Usage, Disk Busy Rate의 관계를 확인할 수 있으며, 이상치 데이터는 붉은 점으로 표시됐습니다. <그림 설명: 입력 데이터셋(2)> 위의 그림으로 CPU Usage, Memory Usage, Network Input bps의 관계를 확인할 수 있으며, 이상치 데이터는 역시 붉은 점으로 표시됐습니다. 입력 데이터셋에 대해 DAGMM epoch 횟수를 1000번으로 학습하여 모델을 생성할 경우 아래와 같은 Energy 밀도와 값을 얻을 수 있습니다. <그림 설명: DAGMM Energy 밀도(1)> <그림 설명: DAGMM Energy 밀도(2)> 생성될 모델에 대해 Energy 값의 99%를 초과할 경우를 이상치 데이터 셋으로 정의할 경우 아래와 같이 입력 데이터셋에서 이상치 데이터로 입력한 값들에 대해 정확하게 이상 징후를 탐지합니다. 이상과 같이 ITIM 제품인 Zenius EMS의 메트릭 데이터에 대한 이상 징후 탐지를 수행하는 방법에 대한 개괄적인 내용을 설명했으며, 이 모델은 당사의 Zenius EMS 시스템의 실시간 이상징후 탐지에 적용할 예정입니다. 2022.08.04

1