KR20190002280A

KR20190002280A - 5g 분산 클라우드 시스템의 빅 데이터를 이용하여 장애를 관리하는 장치 및 방법

Info

Publication number: KR20190002280A
Application number: KR1020180038420A
Authority: KR
Inventors: 이진구; 김범수; 김재우; 임형묵
Original assignee: 주식회사 케이티
Priority date: 2017-06-29
Filing date: 2018-04-03
Publication date: 2019-01-08
Also published as: KR102580916B1; KR102473637B1; KR20220166760A

Abstract

본 발명은 5G 분산 클라우드 시스템에서 빅 데이터의 로그를 분석하여 장애를 관리하는 장치 및 방법에 관한 것이다. 본 발명에 따르는 장애 관리의 장치는 클라우드 시스템의 인프라에서 발생되는 빅 데이터의 로그를 장애에 관련된 메시지로 변환하는 메시지 변환부; 변환된 메시지에 룰 엔진을 적용하여 장애를 검출하는 장애 검출부; 검출된 각 장애의 화면 출력을 위해, 장애가 발생된 인프라 객체를 토폴로지 기반의 그래픽 정보로 생성하여 운용자 단말로 제공하는 장애 그래픽 제공부; 및 검출된 장애의 장애 복구 정보를 생성하여 운용자 단말로 제공하는 장애 복구부를 포함한다.

Description

5G 분산 클라우드 시스템의 빅 데이터를 이용하여 장애를 관리하는 장치 및 방법{Apparatus and method for managing trouble using big data of 5G distributed cloud system}

본 발명은 장애 관리 기술로서, 5G 분산 클라우드 시스템에서 발생되는 빅 데이터를 이용하여 데이터의 수집 및 분석, 장애의 표현 및 복구가 수반되는 장애 관리를 제공하는 장치 및 방법에 관한 것이다.

도 1은 5G 서비스를 위한 종래의 분산 클라우드 시스템(100)을 구성하는 클라우드 인프라(infrastructure)의 계층 구조이다. 첫번째 하드웨어 계층(110)은 서버, 스토리지, 네트워크(스위치) 등 여러 종류의 물리 장비들로 구성된다. 두번째 OS 계층(130)은 하부 하드웨어들을 운영 관리하는 소프트웨어(예 : 리눅스)로 구성된다. 세번째 가상화 계층(150)은 물리적인 자원을 논리적인 자원으로 나누어서 고객의 요구가 있을 때 동적으로 컴퓨팅, 네트워킹, 스토리지 자원을 할당한다. 네번째 클라우드 계층(170)은 상위 3개 계층(110~150)의 모든 자원들을 총괄 제어하는 역할을 수행하는 플랫폼으로 상위 계층(110~150)이 요구하는 다양한 명령을 수행하고 그에 대한 응답을 제공한다. 또한, 클라우드 계층(170)은 서비스 및 자동화 계층(180)에 정의된 서비스 및 상품 등의 어플리케이션을 실행하여 가입자들에게 클라우드 서비스를 제공한다. 마지막으로 우측의 관리 계층(190)은 이런 다층 구조의 클라우드 시스템(100)을 효율적으로 운용 관리하기 위해 필요한 리소스 관리, 구성 및 제어, 장애 모니터링 및 복구 등의 기능을 수행한다.

이러한 클라우드 시스템(100)의 인프라 계층 구조에서, 어느 한 계층에서 발생된 장애는 상위 계층 및 하위 계층에 영향을 미친다. 즉, 장애가 어느 계층에서 발생하고, 장애의 영향이 어느 상위 계층 또는 하위 계층까지 미치고, 장애의 복구는 어느 계층을 통해 접근해야 하는지 파악해야 하므로, 효율적인 운용 관리를 위해서는 하드웨어와 소프트웨어 분야의 다양한 전문가들이 필요하다.

도 2는 도 1의 분산 클라우드 시스템(100)에서 클라우드 계층(170)의 소프트웨어인 클라우드 플랫폼(200)의 개략적 구성도이다. 상기 분산 클라우드 시스템(100)을 구성하는 핵심 소프트웨어인 클라우드 플랫폼(200)은 독립적으로 발전된 서브 시스템(210~270)들이 여러개 모여 하나의 클라우드를 구성하는 분산 아키텍처를 사용하고 있다. 최근 가장 많이 사용되는 오픈 스택의 클라우드 플랫폼(200)의 경우, 7개의 서브 시스템(210~270)으로 구성된 아키텍처가 클라우드를 구성하는 최소의 단위이다.

이 클라우드 플랫폼(200)은, 고객이 웹을 통해서 클라우드에 접속하는 포탈 서브 시스템(210), 고객이 요청하는 컴퓨팅 리소스를 제공하는 가상 컴퓨팅 서브 시스템(220), 네트워크 리소스를 제공하는 가상 네트워킹 서브 시스템(230), 스토리지 리소스를 제공하는 가상 스토리지 서브 시스템(240), 이미지(운영체제) 리소스를 제공하는 이미지 서브 시스템(250), 보안 서비스를 제공하는 인증 관리 서브 시스템(260) 및 객체 형식의 스토리지 서비스를 제공하는 객체 스토리지 서브 시스템(270)으로 구성되어 있다.

이러한 다수의 서브 시스템(210~270)으로 구성된 분산 아키텍처의 클라우드 플랫폼(200)에서 장애가 발생하면, 어느 서브 시스템(210~270)에서 발생된 장애인지 추적이 필요하고, 주변 서브 시스템에 대한 장애 영향 및 타 인프라 계층에 대한 영향의 분석이 필요하다. 때문에, 오랜 기간의 숙련된 IT 전문 인력이 아니면, 전체 클라우드 시스템의 운용 감시, 장애 원인 분석 및 복구에 오랜 시간이 소요되어 시스템의 신뢰성을 크게 떨어뜨릴 수 있어 개선 대책이 필요하다. 오랜 기간의 숙련된 IT 전문 인력이 아니면, 전체 클라우드 시스템의 운용 감시, 장애 원인 분석 및 복구에 오랜 시간이 소요되어 시스템의 신뢰성을 크게 떨어뜨릴 수 있어 개선 대책이 필요하다.

도 3은 도 1의 분산 클라우드 시스템(100)의 종래 운용 관리 처리의 개략적 흐름도이다. 도 3에서, 종래의 운용 관리의 처리 흐름은 수집(310), 필터(330), 표현(350) 및 장애 복구(370)의 처리 과정을 갖는다. 수집(310) 처리에서, 클라우드 시스템(100)은 전체 클라우드의 장애 상태를 감시하기 위해서 중앙 처리 장치(CPU)의 부하율, 메모리 사용률, 하드디스크 사용률과 같은 수치 정보나 클라우드 플랫폼(200)의 중요 프로세스와 서비스들의 동작 상태와 같이 직관적으로 이해할 수 있는 일정한 포맷을 가지는 정형 데이터를 수집한다. 필터(330) 처리에서, 클라우드 시스템(100)은 수집된 정형 데이터들을 특정 기준치를 기준으로 비교하거나, 상태가 동작 중인지 아닌지 판별하는 단순한 기준으로 필터링하여 장애 여부를 판단한다. 표현(350) 처리에서, 필터링에 의해 발견된 장애 이벤트를 웹과 같은 그래픽 환경의 테이블 화면에 가시적으로 표현하거나 가청 정보를 제공하여 운용자에게 알린다.

장애 복구(370)의 처리에서, 장애 이벤트를 확인한 운용자는 장애 처리의 표준 문서나 자신의 역량에 의존하여 시스템 오류를 해결함으로써 장애를 복구한다. 이러한 종래의 클라우드 운용 관리 방법은 다음과 같은 3가지 문제점을 가지고 있다.

제 1문제점은 도 1과 같은 다양한 클라우드 인프라 계층(110~190) 및 도 2와 같은 서브 시스템(210~270)으로 구성된 클라우드 플랫폼(200)의 장애 여부를 판단하기 위해서는 단순한 상태 정보의 수집과 필터링으로는 시스템 내부에서 발생하는 논리적인 에러를 발견하지 못한다. 논리적 에러의 경우, 실제로 고객으로부터 장애 문의(VoC)를 받았음에도, 모니터링 시스템에는 전혀 장애 정보가 표시되지 않는다. 따라서, 운용자가 장애를 파악하고 복구하기 위해 인프라 계층(110~190) 및 서브 시스템(210~280)을 기반으로 모든 시스템의 상태, 구성파일 그리고 로그 파일을 검색하는 경우, 운용자의 기량에 따라 수시간에서 수분이 장애 복구 시간이 소요될 수 있다.

제 2문제점은 장애가 발생하여 운용 관리 시스템의 웹 화면에 표시된다고 하더라도 단순한 테이블 GUI에 표현되기 때문에, 이 장애 이벤트가 도 3과 같은 복잡한 클라우드 플랫폼의 어느 곳에서 발생된 것인지 위치 파악이 어렵고, 그 위치를 파악하더라도 전체 인프라 계층(110~190) 및 서브 시스템(210~270)의 차원에서 어떤 영향과 고객의 장애 피해 여부를 파악하는 것도 어렵다.

제 3문제점은 현재 발생하는 클라우드 플랫폼의 로그 파일은 개발자 관점의 프로그램 에러 정보가 대부분이기 때문에 소프트웨어와 IT의 전문 지식이 없는 운용자는 그 메시지가 의미하는 바를 이해하고 그에 대한 조치를 취하는 것이 어렵다. 이러한 문제를 해결하기 위해서는 IT, Network, Software 분야의 전문가를 교육하고 양성함이 시급하지만 이는 오랜 시간과 비용이 소요되는 단점이 있다.

한국등록특허 10-1636796(2016.06.30.)

본 발명은 상기와 같은 종래 문제점들을 해결하기 위한 것으로서, 5G 분산 클라우드 시스템에서 발생되는 빅 데이터의 로그를 수집하여 메시지로 분석하고, 룰 엔진을 통해 상기 분석된 메시지로부터 장애를 검출하고, 검출된 장애의 위치와 영향을 관리자에게 알리고, 장애 복구를 실행하는 장치 및 방법 제공하는데 목적이 있다.

상기 장치는 클라우드 시스템에서 하드웨어, 운영체제, 클라우드 플랫폼 및 네트워크 트래픽을 포함한 각종 로그 정보의 빅 데이터를 장애 검출을 위한 메시지로 변환하는데 다른 목적이 있다.

상기 장치는 변환된 메시지를 룰 엔진에 적용하여 장애 검출을 위한 and/or 조건을 비교하는 분석 처리를 통해 물리적 및 논리적 장애를 검출하는데 다른 목적이 있다.

상기 장치는 검출된 장애를 하드웨어, 운영체제, 클라우드 플랫폼 및 네트워크 트래픽을 기반으로 그래픽 토폴로지로 표시하여, 운용자에게 장애 발생의 위치와 영향을 즉시 알리고, 장애 복구의 자동 처리 결과 및 장애 수동 복구의 가이드를 제공하는데 다른 목적이 있다.

일 측면에 따른, 5G 분산 클라우드 시스템의 빅 데이터를 이용하여 장애를 관리하는 장치는, 상기 시스템의 인프라에서 발생되는 빅 데이터의 로그를 장애에 관련된 메시지로 변환하는 메시지 변환부; 변환된 메시지에 룰 엔진을 적용하여 장애를 검출하는 장애 검출부; 검출된 각 장애의 화면 출력을 위해, 장애가 발생된 인프라 객체를 토폴로지 기반의 그래픽 정보로 생성하여 운용자 단말로 제공하는 장애 그래픽 제공부; 및 검출된 장애의 장애 복구 정보를 생성하여 상기 운용자 단말로 제공하는 장애 복구부를 포함한다.

상기 메시지 변환부는, 하드웨어, 운영체제, 클라우드 플랫폼 및 네트워크 플랫폼의 객체를 포함하는 클라우드 인프라의 각 객체별 로그를 수집하여 저장한다.

상기 메시지 변환부는, 각 로그 파일에서 적어도 하나 이상의 로그 라인을 장애 검출을 위한 메시지로 변환한다.

상기 메시지 변환부는, 상기 로그가 수집된 서버의 서버 이름; 상기 로그가 기록된 파일 이름; 상기 로그에서 적어도 하나 이상의 로그 라인이 분석되어 변환된 메시지를 식별하는 라인 아이디; 상기 메시지의 상기 서버 이름, 상기 파일 이름 및 상기 라인 아이디로 구성된 메시지 키; 및 상기 메시지로 분석된 각 로그 라인이 저장되는 라인 버퍼를 포함하는 구조체를 이용하여 로그 라인 및 변환된 메시지를 저장한다.

상기 장애 검출부는, 적어도 하나 이상의 필터링 룰을 포함하는 룰 그룹 이름; 상기 필터링 룰; 상기 필터링 룰에서 처리되는 필터 조건; 및 상기 메시지로부터 검출되어 상기 필터 조건이 적용되는 필터링 키를 포함하는 상기 룰 엔진의 구조체를 이용하여 메시지로부터 필터링 키를 검출하고, 검출된 필터링 키에 적용된 필터 조건이 상기 메시지에서 만족되면 장애의 발생으로 검출한다.

상기 장애 검출부는, 장애가 검출된 상기 인프라의 계층 구조 정보를 포함하는 룰 이름; 상기 장애를 설명하는 룰 설명; 상기 장애가 검출되는 로그 파일 이름; 로그의 등급을 정의하는 로그 등급; 로그의 키워드에서 대문자 및 소문자의 구분을 정의하는 케이스; 상기 메시지에 대응되는 로그 라인으로부터 상기 장애를 검출하기 위해, AND 와 OR의 필터 조건 및 상기 필터 조건이 적용되는 적어도 하나 이상의 키워드를 포함하는 적어도 하나 이상의 필터링 룰; 및 상기 필터링 룰을 만족하여 검출된 상기 장애의 복구를 위해 실행되는 자동 복구, 운용자 매뉴얼 복구 및 제 3전문가 복구의 복구 처리 정보; 상기 장애의 장애 등급을 정의하는 장애 등급을 포함하는 상기 룰 엔진의 구조체를 이용한다.

상기 장치는 화면 표시를 위해 상기 인프라의 객체 및 객체들간의 계층적 연결 정보가 저장된 그래픽 DB를 더 포함하고, 상기 장애 그래픽 제공부는, 운용자 단말이 요청한 인프라에 대응되는 객체 및 계층적 연결 정보를 상기 그래픽 DB로부터 조회하고, 조회된 객체들간의 계층적 연결 정보를 그래픽 정보로 생성하고, 생성된 그래픽 정보를 상기 운용자 단말로 제공한다.

상기 장애 그래픽 제공부는, 상기 운용자 단말에서 표시된 상기 그래픽 정보에 포함된 객체에서 장애가 존재하면, 화면 표시를 위해 상기 운용자 단말로 장애 정보를 전송한다.

상기 장애 복구부는, 운용자 단말로 상기 장애 복구 정보를 제공하고, 운용자의 요청에 따라 자동 복구 처리, 운용자 매뉴얼 복구 처리 및 제 3전문가 복구 처리를 실행하여 장애를 복구한다.

상기 장애 복구부는, 자동 실행 또는 운용자의 요청에 따라, 장애가 발생된 상기 인프라로 자동 복구의 명령을 전송하고, 명령이 처리된 결과를 운용자 단말로 제공한다.

상기 장애 복구부는, 상기 자동 복구가 실패될 경우, 운용자의 요청에 따라 운용자 매뉴얼 복구의 명령을 장애가 발생된 상기 인프라로 전송하고, 명령이 처리된 결과를 상기 운용자 단말로 제공하고, 상기 자동 복구 또는 상기 운용자 매뉴얼 복구가 실패될 경우, 제 3전문가 복구를 위해 장애 정보를 전문가 단말로 통보한다.

다른 측면에 따른 5G 분산 클라우드 시스템의 빅 데이터를 이용하여 장애를 관리하는 장치가 실행하는 방법은, 상기 시스템의 인프라에서 발생되는 빅 데이터의 로그를 장애에 관련된 메시지로 변환하는 단계; 변환된 메시지에 룰 엔진을 적용하여 장애를 검출하는 단계; 검출된 각 장애의 화면 출력을 위해, 장애가 발생된 인프라 객체를 토폴로지 기반의 그래픽 정보로 생성하여 운용자 단말로 제공하는 단계; 및 검출된 장애의 장애 복구 정보를 생성하고 상기 운용자 단말로 제공하여 장애를 복구하는 단계를 포함한다.

본 발명의 일 측면에 따르면, 빅 데이터의 로그를 이용한 메시지 분석 및 룰 엔진 기반의 장애 분석을 통해 클라우드 시스템의 계층 구조 및 클라우드 플랫폼의 서브 시스템에서 발생되는 물리적 장애 및 논리적 장애를 검출할 수 있다.

검출된 장애는 클라우드 시스템의 인프라를 구성하는 객체가 배치된 그래픽 토폴로지 상에서 표시하여, 운영자가 클라우드 시스템의 계층 구조 및 클라우드 플랫폼의 서브 시스템에 의해 상호 연결된 객체를 이동하는 과정에서 장애 발생의 위치 및 영향을 즉시 파악할 수 있다.

상기 장애 표시 화면에서, 검출된 장애의 복구를 위해, 자동 복구 실행, 운용자 수동 복구 실행 및 제 3의 전문가 복구 실행 등으로 구분하여 장애 복구의 가이드를 동시에 제공할 수 있다.

본 명세서에 첨부되는 다음의 도면들은 본 발명의 바람직한 실시예를 예시하는 것이며, 후술한 발명의 상세한 설명과 함께 본 발명의 기술사상을 더욱 이해시키는 역할을 하는 것이므로, 본 발명은 그러한 도면에 기재된 사항에만 한정되어 해석되지 않아야 한다.
도 1은 5G 서비스를 위한 종래의 분산 클라우드 시스템의 개략적 계층 구조도이다.
도 2는 도 1의 분산 클라우드 시스템의 소프트웨어인 클라우드 플랫폼의 개략적 구성도이다.
도 3은 도 1의 분산 클라우드 시스템의 종래 운용 관리 처리의 개략적 흐름도이다.
도 4는 본 발명의 일 실시예에 따른 장애를 관리하는 5G 분산 클라우드 시스템의 개략적 구성도이다.
도 5는 도 4의 중앙 매니저가 제공하는 장애 관리 서비스의 개략적 흐름도이다.
도 6은 도 4의 중앙 클라우드에서 로그 수집 및 저장을 위한 코드의 예시도이다.
도 7은 도 4의 중앙 매니저가 수집된 로그 파일의 로그 라인을 분석하여 메시지로 변환하는 구조체의 예시도이다.
도 8은 도 4의 중앙 매니저가 메시지를 분석하여 장애를 검출하는 룰 엔진 포맷의 예시도이다.
도 9는 도 4의 중앙 매니저가 룰 엔진의 필터링 룰을 처리하는 트리의 예시도이다.
도 10은 도 4의 중앙 매니저가 클라우드 플랫폼의 서비스 토폴로지를 기반으로 생성한 장애 관리 화면의 예시도이다.
도 11은 본 발명의 일 실시예에 따른 5G 분산 클라우드 시스템에서 장애를 관리하는 방법의 개략적 순서도이다.
도 12는 도 11에서 로그를 분석하여 메시지로 변환하는 단계의 상세 순서도이다.
도 13은 도 11에서 장애 관리를 위해 그래픽 정보를 생성하여 제공하는 단계의 상세 순서도이다.
도 14는 도 11에서 장애를 복구하여 처리 결과를 제공하는 단계의 상세 순서도이다.

이하, 첨부된 도면을 참조하여 본 발명의 바람직한 실시예를 상세히 설명하기로 한다. 이에 앞서, 본 명세서 및 청구 범위에 사용된 용어나 단어는 통상적이거나 사전적인 의미로 한정해서 해석되어서는 아니되며, 발명자는 그 자신의 발명을 가장 최선의 방법으로 설명하기 위해 용어의 개념을 적절하게 정의할 수 있다는 원칙에 입각하여 본 발명의 기술적 사상에 부합하는 의미와 개념으로 해석되어야만 한다. 따라서, 본 명세서에 기재된 실시예와 도면에 도시된 구성은 본 발명의 가장 바람직한 일 실시예에 불과할 뿐이고 본 발명의 기술적 사상에 모두 대변하는 것은 아니므로, 본 출원 시점에 있어서 이들을 대체할 수 있는 다양한 균등물과 변형예들이 있을 수 있음을 이해하여야 한다.

도 4는 본 발명의 일 실시예에 따른 장애를 관리하는 5G 분산 클라우드 시스템(400)의 개략적 구성도이다.

본 발명의 일 실시예에 따른 장애 관리 서비스를 제공하는 5G 분산 클라우드 시스템(400)은 중앙 클라우드(410)와 복수개의 엣지 클라우드(430)를 포함하여 구성된다.

상기 중앙 클라우드(410)는 본 발명의 장치로서 각 지역의 광역 국사에 설치된 각 엣지 클라우드(430)들을 중앙에서 관리하는 역할을 수행한다. 중앙 클라우드(410)가 장애 관리 기능을 갖는 서버 장치로 구축될 경우, 각 엣지 클라우드(430)들로 장애 관리 서비스를 제공할 수 있다.

중앙 클라우드(410)에 설치된 중앙 매니저(411)는 엣지 클라우드(430)의 엣지 매니저 에이전트(431)와 데이터 통신을 수행하여 장애 관리 서비스를 제공한다. 또한, 중앙 클라우드(410)는 웹 UI를 운용자 단말로 제공하여 상기 장애 관리 서비스를 제공한다. 상기 장애 관리 서비스는 로그 데이터의 분석 및 메시지 변환, 변환된 메시지로부터 장애 검출, 검출된 장애 이벤트의 토폴로지 그래픽 화면의 생성 및 제공, 화면 GUI 기반의 처리를 포함한다.

상기 엣지 클라우드(430)는 엣지 매니저 에이전트(431), 엣지 클라우드 제어기(432), 하드웨어(433), 운영체제(434), 클라우드 플랫폼(435), NFV 존(436) 및 IT 존(437)을 포함하여 구성된다.

상기 엣지 매니저 에이전트(431)는 중앙 매니저(411)와 통신하여 가입자들에게 클라우드 서비스를 제공하는 과정에서 본 발명에 따른 장애 관리 서비스를 중앙 매니저(411)로부터 제공받는다. 상기 장애 관리 서비스에서, 엣지 매니저 에이전트(431)는 클라우드의 로그를 수집하여 중앙 클라우드(410)로 전송하고, 장애가 발생되면 중앙 클라우드(410)로부터 장애 복구 명령을 수신하여 실행하고, 실행 결과를 중앙 클라우드(410)로 보고한다.

상기 엣지 클라우드 제어기(432)는 하드웨어(433), 운영체제(434) 및 클라우드 플랫폼(435)을 제어하여 클라우드 서비스를 제공한다. 하드웨어(433)는 서버, 스토리지 및 네트워크 장비들을 포함한다. 운영체제(434)는 하드웨어(433)에 로딩되어 클라우드 플랫폼(435)의 실행을 지원한다.

클라우드 플랫폼(435)의 실행에 의해, 5G 서비스의 인프라를 제공하는 자원 그룹에 해당되는 NFV 존(436) 및 IT 존(437)이 생성되어 5G 클라우드 서비스가 가입자들에게 제공된다. 클라우드 서비스에서, NFV 존(436)은 가입자들에게 네트워크 통신 서비스를 제공하기 위한 인프라를 제공하고, IT 존(437)은 가입자들에게 어플리케이션 서비스를 제공하기 위한 인프라를 제공한다.

도 5는 도 4의 중앙 매니저(411)가 제공하는 장애 관리 서비스의 개략적 흐름도이다. 도 6은 도 4의 중앙 클라우드(410)에서 로그 수집 및 저장을 위한 코드의 예시도이다. 도 7은 도 4의 중앙 매니저(411)가 수집된 로그 파일의 로그 라인을 분석하여 메시지로 변환하는 구조체의 예시도이다. 도 8은 도 4의 중앙 매니저(411)가 메시지를 분석하여 장애를 검출하는 룰 엔진 포맷의 예시도이다. 도 9는 도 4의 중앙 매니저(411)가 룰 엔진의 필터링 룰을 처리하는 트리의 예시도이다. 도 10은 검출된 장애의 표시를 위해 도 4의 중앙 매니저(411)가 클라우드 플랫폼의 서비스 토폴로지를 기반으로 생성한 장애 관리 화면의 예시도이다. 이하에서는 도 5 내지 도 10을 참조하여 설명한다.

도 5를 참조하면, 중앙 매니저(411)는 메시지 변환부(511), 장애 검출부(513), 장애 그래픽 제공부(515) 및 장애 복구부(517)를 포함하여 구성된다.

중앙 클라우드(410)가 저장 매체, 메모리(예 : RAM) 및 프로세서를 포함하는 서버 장치라고 가정하면, 각 구성부(511~517)들은 프로그램의 형태로 저장 매체에 설치되고, 실행된 프로그램은 메모리에 로딩되어 프로세서를 통해 처리된다.

이하에서는 상기에서 설명된 제 1~3문제점을 해결하기 위한 각 구성부(511~517)들이 처리하는 장애 관리 서비스의 운용 관리 흐름(①~⑧)을 설명한다.

상기 메시지 변환부(511)는 분산 클라우드 시스템(400)의 인프라를 구성하는 각 엣지 클라우드(430)의 객체들로부터 발생되는 빅 데이터의 로그를 수집하고(①), 수집된 로그를 장애 분석을 위한 메시지로 변환한다(②).

여기서, 메시지 변환부(511)는 각 엣지 클라우드(430)를 구성하는 하드웨어, 운영체제, 클라우드 플랫폼의 모든 로그 정보 및 네트워크 플랫폼의 모든 네트워크 트래픽 정보를 실시간으로 수집하여 스토리지 기반의 대용량 메시지 큐에 저장한다. 중앙 클라우드(41)는 스토리지 서버로서 메시지 변환부(511)가 네트워크를 통해 수집한 로그를 저장할 수 있다.

도 6을 참조하면, 데이터 수집 및 스토리지 저장을 위해, 일반적으로 널리 사용되는 오픈 소스가 사용될 수 있다. 최근에 널리 사용되는 logstash를 예로 들면, 로그 파일의 입력 파일 경로(610) 및 스토리지 서버에 해당되는 출력 부트스트랩 서버(630)가 정의된 config 파일이 생성된 후 실행된다. 각 엣지 클라우드(430)에서 config 파일이 실행되면, 감시 대상의 입력 로그 파일에서 변경이 발생되면, 중앙 클라우드(410)의 스토리지 메시지 큐에 해당 로그가 저장된다.

본 발명에서, 일반적으로 사용하는 메모리 기반의 메시지 큐가 아니라 스토리지 기반의 메시지 큐를 사용하는 것은 "apache kafka"과 같은 스토리지 기반의 대용량 메시지 큐는 빅 데이터를 저장하고 읽을 때 적정한 속도를 보장하면서 충분한 확장성을 제공하기 때문이다. 메모리 기반의 메시지 큐는 성능은 더 뛰어나지만 장애시 데이터가 소실될 수 있으며 대용량의 데이터를 적용하기에는 확장성에 문제가 발생할 수 있다.

도 7을 참조하면, 중앙 매니저(411)의 메시지 변환부(511)는 수집된 로그 파일의 로그 라인을 분석하여 메시지로 변환하고, 변환된 메시지를 메시지 구조체(700)를 통해 저장한다.

상기 로그 파일은 복수개의 로그 라인을 포함한다. 일반적으로 단순 라인으로 표시되는 로그 파일에서 하나의 라인을 읽어서 분석하는 경우 의미있는 분석 결과를 도출하기 쉽지 않다. 때문에, 개별 라인을 의미있는 메시지 형태로 변환시켜주는 과정이 필요하고, 이를 위해 메시지 변환부(511)는 아래와 같은 3가지 메시지 변환 규칙을 사용한다.

제 1메시지 변환 규칙은 로그 라인과 메시지가 1:1로 변환되는 경우로 하나의 라인이 자체적으로 장애 분석의 의미가 있는 메시지인 경우이다. 제 2메시지 변환 규칙은 로그 라인과 메시지가 n:1로 변환되는 경우로 여러 개의 라인이 하나의 장애 분석의 의미가 있는 메시지를 형성하는 경우이다. 제 3메시지 변환 규칙은 제 2메시지 변환 규칙과 동일하게 로그 라인과 메시지가 n:1로 변환되는 경우이지만, 개별 로그 라인마다 동일한 메시지 헤더(2017-05-15 15:48:43.768 2097 ERROR nova.compute.manager)를 갖는다.

도 7에 도시된 자료 구조의 메시지 구조체(700)는 서버 이름(hostname), 로그 파일 이름(logname), 라인 아이디(line_id), 메시지 키(msg_key) 및 라인 버퍼(msg_line_buf)의 필드를 포함한다.

상기 서버 이름은 로그를 발생시키는 엣지 클라우드(430)의 인프라를 구성하는 물리 서버를 고유하게 식별하는 서버명이다. 예를 들면, "cnode-01.dj-01-01.kt."로서 'kt':사업자, 'dj-01-01':대전 집중국에 설치된 01번 클라우드의 01번 랙, 'cnode-01':특정 랙(01)에 설치된 01번 컴퓨팅 서버와 같은 서버명을 의미한다. 상기 로그 파일 이름은 분석 대상의 로그 파일명에 해당된다. 상기 라인 아이디는 로그 파일에서 로그 라인을 분석할 때 동일한 장애 메시지임을 식별하기 위해 사용하는 식별자로서, 대부분의 소프트웨어에서 사용되는 로그 포맷(날짜, 시간, 등급, 모듈명)의 헤더를 이용하는데 이는 로그 파일의 종류에 따라 달라질 수 있다. 즉, 라인 아이디는 메시지 아이디에 해당된다. 상기 메시지 키는 전체 엣지 클라우드(430)에서 발생된 모든 로그 파일에서 현재 분석 중인 라인의 메시지를 고유하게 식별하기 위해 서버 이름, 로그 파일 이름 및 라인 아이디(hostname+logname+line_id)을 조합한 식별자(식별 키)이다. 그리고 상기 라인 버퍼는 메시지 키가 동일한 로그 라인들의 모음으로 메시지가 완성되면, 각 로그 라인들이 저장된 집합체에 해당된다.

그러면, 메시지 변환부(511)는 스토리지 서버의 DB로부터 각 로그 파일의 로그 라인을 하나씩 읽어들이고, 로그 라인에 제 1~3메시지 변환 규칙을 적용하여 메시지 구조체(700)에 라인 아이디로 식별되는 메시지 및 라인 버퍼에 저장되는 로그 라인 등의 정보를 저장하는 것으로 메시지 변환을 처리한다.

도 5에서, 상기 장애 검출부(513)는 메시지 구조체(700)를 이용하여 상기 변환된 메시지를 참조하고, 메시지에 룰 엔진을 적용하고(③), 룰 엔진의 처리에 의해 장애를 검출한다(④).

도 8을 참조하면, 중앙 매니저(411)의 장애 검출부(513)가 적용하는 룰 엔진의 포맷이 도시된다. 룰 엔진의 포맷은 [filter_rule_group->filter_rule->filter_condition->filter_key]로 구성된 계층 구조를 이용하여 룰 엔진의 구조체(800)를 정의한다. 룰 엔진의 계층 구조에서, filter_rule_group은 룰 그룹 이름에 해당되는 제 1계층이다. filter_rule은 제 1계층의 하위 계층이고, 상위의 제 1계층의 룰 그룹에 소속된 필터링 룰에 해당되는 제 2계층이다. filter_condition은 제 2계층의 하위 계층이고, 상위의 제 2계층의 필터링 룰에서 비교 처리되는 필터 조건에 해당되는 제 3계층이다. filter_key는 제 3계층의 하위 계층이고, 상위의 제 3계층의 필터 조건에 의해 비교 처리되는 필터링 키에 해당되는 제 4계층이다.

상기 룰 엔진 구조체(800)는 룰 이름(name), 룰 설명(desc), 로그 파일 이름(logfile), 로그 등급(loglevel), 케이스(case), 필터 조건(cond) 및 키워드(keyword)를 포함하는 필터링 룰(body), 복구 처리 정보(shooter) 및 장애 등급(fltlevel)의 필드를 포함한다.

상기 룰 이름(name) "cloud.openstack.system.quota_exceed"는 룰 엔진의 장애 분석 룰을 설명하는 이름으로 '.'에 의해 분리되는 계층 구조를 사용하여 체계적이고 이해가 쉽도록 하였다. 상기 룰 설명(desc)은 룰 엔진에 의해 검출된 장애를 운용자가 쉽게 이해할 수 있도록 간략하게 설명한 내용이다. 룰 설명은 운용자 단말(530)로 제공될 수 있다. 상기 로그 파일 이름(logfile)은 룰 엔진의 장애 분석 처리가 적용되는 메시지가 변환된 로그 파일의 이름이다. 즉, 장애 검출부(513)는 변환된 메시지의 로그 파일 이름과 일치되는 로그 파일 이름을 갖는 룰 엔진 구조체(800)의 필터링 룰을 메시지에 적용한다. 상기 로그 등급(loglevel)은 관리자에 의해 정의된 로그 등급이다. 최상위 로그 등급은 장애 분석을 위해 중요한 로그임을 나타낸다. 상기 케이스(case)는 메시지로부터 키워드(keyword)를 검색할 때, 대, 소문자 구분을 사용할지 여부를 나타낸다. 룰 엔진에 의해 메시지를 필터링할 때, 로그 파일, 로그 레벨 및 케이스의 3가지 항목이 기본적인 조건으로 사용된다.

상기 룰 엔진의 구조체(800)에서 제 1계층의 룰 그룹 이름은 "openstack_expert_trouble_map"이다. 이 제 1계층의 룰 그룹은 "cloud.openstack.system.quota_exceed" 및 "cloud.openstack.system.no_valid_host" 라는 이름을 갖는 2개의 제 2계층의 필터링 룰을 갖는다.

여기서, 제 2계층의 필터링 룰 "cloud.openstack.system.quota_exceed"는 "01" 및 "02"로 정의된 2개의 제 3계층 필터 조건이 존재한다. 이 필터 조건은 순차적으로 적용되고 앞에 적용된 "01" 필터 조건이 만족되는 경우에만, 다음의 "02" 필터 조건이 적용된다. 그리고 '01' 필터 조건은 "exception" 및 "quota"라는 2개의 제 4계층 필터링 키를 케이스 "ignore"로 사용하고, "and" 필터 조건으로 연산한다. 즉, 장애 검출부(513)의 룰 엔진은 로그 메시지로부터 "exception" 및 "quota" 키워드를 검출하면, "01" 필터 조건을 성공으로 판단한다. "exception" 및 "quota"의 키워드가 검출되지 않으면, "01" 필터 조건은 실패이고, '02' 조건의 처리는 생략된다. 만약, "01" 및 "02"의 필터 조건이 모두 성공되면, 룰 엔진의 메시지 분석 처리를 통해 장애가 검출된 것이다.

상기 복구 처리 정보(shooter)는 분석 대상의 메시지가 필터 조건의 필터링 룰을 만족시켰을 때, 장애 복구를 위해 실행되는 프로그램의 주소 정보이다. 만약, 복구 처리 정보가 없는 장애가 발생되면, 제 3전문가에 연락하여 협조를 구하여야 한다. 상기 장애 등급(fltlevel)은 필터링 룰을 정의한 관리자가 판단한 장애 등급이다. 예를 들면, WR(Warning)/ ER(Error)/CR(Critical) 등으로 장애 등급이 분류될 수 있다.

장애 검출부(513)는 메시지의 분석 처리를 통해, 메시지에 포함된 모든 수치, 상태 등의 로그 데이터를 읽고, 관리자가 정의한 다양한 필터링 규칙을 실시간으로 적용하여 장애 이벤트를 검출하고, 그 결과를 메시지 큐에 저장한다. 이러한 장애 분석의 필터링 규칙은 지속적으로 갱신하고 추가할 수 있도록 지식 관리 시스템으로 만들어 중요한 운용 관리 자산이 될 수 있도록 한다.

도 9를 참조하면, 장애 검출부(513)가 처리하는 룰 엔진의 필터링 룰이 트리 구조로 도시된다. 메시지 변환부(511)가 로그 파일의 분석을 통해 메시지를 생성할 때마다, 장애 검출부(513)는 메시지 큐로부터 생성된 메시지를 읽어온다. 장애 검출부(513)는 메시지의 로그 파일 이름과 일치되는 로그 파일 이름을 갖는 룰 엔진 구조체(800)의 필터링 룰 그룹을 로딩한다. 로딩된 필터링 룰 그룹은 트리 구조로 표시될 수 있다. 여기서, 필터링 룰 그룹의 변경이 있으면, 새로 읽어서 동적으로 적용하고, 변경이 없으면 초기에 로딩한 내용을 사용할 수 있다.

상기 트리 구조에서, 제 1계층의 롤 그룹은 루트 노트가 되어 제 2계층의 필터링 룰을 자식 노드로 갖는다. 제 2계층의 필터링 룰 노드는 부모 노드가 되어 제 3계층의 필터 조건을 자식 노드로 갖는다. 또한, 제 3계층의 필터 조건 노드는 부모 노드가 되어 제 4계층의 필터링 키를 자식 노드로 갖는다. 트리 순회는 룰 엔진의 필터링 처리에 해당한다.

트리 순회에서, 필터링 룰 그룹의 노드(901)가 방문된다. 필터링 룰 그룹의 노드(901)는 제 1, 2필터링 룰 노드(902, 910)을 갖는다. 먼저, 제 1필터링 룰 노드(902)부터 방문되어 제 1필터링 룰이 로그 메시지에 적용된다. 필터링 룰 노드(902)는 제 1, 2필터 조건 노드(903, 907)를 갖는데 첫번째 필터 조건 노드(903)부터 하나씩 적용된다. 제 1필터 조건 노드(903)의 'and' 나 'or'조건이 자식 노드인 제 1~3 필터링 키 노드(904, 905, 906)의 키워드에 적용되어 로그 메시지가 판단된다. 즉, 로그 메시지에서 3개의 키워드에 대한 필터 조건이 성공되는지 판단된다. 제 1필터 조건 노드(903)에서 필터링 처리가 성공되면, 제 2필터 조건 노드(907)의 필터 조건이 자식 노드인 제 1~2 필터링 키 노드(908, 909)의 키워드에 적용되어 로그 메시지가 판단된다. 제 1, 2필터 조건 노드(903, 907)에서 모두 필터링 처리가 성공되면, 제 1필터링 룰 노드(902)에서 제 1필터링 룰에 의해 장애가 검출된 것이다. 제 1필터링 룰 노드(902)의 필터링 처리가 완료되면, 제 2필터링 룰 노드(910)의 방문에 의해, 각 노드(911~918)의 필터링 처리가 적용된다.

도 5에서, 상기 장애 그래픽 제공부(515)는 운용자 단말(530)로부터 장애 관리 화면을 요청받고(⑤), 요청된 화면을 표시하기 위해 클라우드 인프라를 구성하는 각 객체들을 토폴로지 기반의 그래픽 정보를 생성하고(⑥), 장애 관리 화면의 표시하기 위한 그래픽 정보를 운용자 단말(530)로 제공한다(⑦).

도 10을 참조하면, 운용자 단말(530)에서 클라우드 인프라의 토폴로지에 기반하여 9개의 인프라 객체 및 이들의 연결 정보로 생성된 장애 관리 화면(1000)이 표시된다.

장애 그래픽 제공부(515)는 운용자가 요청하는 화면 생성을 위해, 클라우드 인프라의 객체 및 객체들간의 계층적 연결 정보가 저장된 그래픽 DB를 참조한다. 그러면, 장애 그래픽 제공부(51)는 그래픽 DB로부터 조회된 객체들간의 계층적 연결 정보 및 장애 정보를 토폴로지 기반의 그래픽 정보로 생성하고, 생성된 그래픽 정보를 화면 표시 정보로써 운용자 단말(530)로 제공한다. 상기 토폴로지 기반의 그래픽 정보는 도 1에서 도시된 분산 클라우드 시스템(100)의 인프라 계층 구조를 구성하는 각 구성 객체들간의 연결을 표시하는 정보이다.

여기서, 장애 그래픽 제공부(515)는 발생된 장애가 인프라 객체의 어느 위치인지 정확히 파악하고 쉽게 원인을 분석할 수 있도록 인프라, 플랫폼, 고객 서비스의 상세 다이어그램을 그래픽 정보로 제공한다. 그러면, 운용자 단말(530)은 그래픽 정보의 GUI를 기반으로 장애 관리 화면을 생성한다. 장애 관리 화면에서는 각 객체의 요약 정보가 표시되고, 장애 이벤트 관련 상세 로그 및 과거 이력 데이터가 쉽게 조회될 수 있는 통합 운용 환경이 제공된다.

운용자 단말(530)에서 수신된 그래픽 정보에 의해 생성된 장애 관리 화면(1000)이 표시된 이후로, 운용자는 화면에 표시된 객체를 선택하여 상위 객체 및 하위 객체의 화면을 장애 그래픽 제공부(515)로 요청하고, 장애 그래픽 제공부(515)로부터 대응되는 화면 표시 정보를 제공받아 화면을 생성하여 표시한다. 또한, 장애 그래픽 제공부(515)는 장애가 발생될 때마다, 발생된 장애를 표시하는 장애 정보 및 화면 표시 정보를 생성하여 운용자 단말(530)에 실시간으로 전송한다. 즉, 화면에 표시된 객체에서 장애가 검출될 때마다, 운용자 단말(530)의 장애 관리 화면에 실시간 표시된다. 그러면, 운용자 단말(530)에서 운용자는 화면에 표시된 장애 정보에 대해 상세 정보, 복구 정보를 요청하고, 운용자 단말(530)은 상기 운용자의 요청을 수신한 장애 그래픽 제공부(515)로부터 대응되는 화면 정보를 응답받아 화면에 표시한다.

도 5에서, 상기 장애 복구부(517)는 검출된 장애의 복구 가이드 정보를 생성하여 운용자 단말(530)로 제공한다(⑧). 운용자는 수신된 장애 복구의 가이드 정보를 참조하여 복구 명령을 내리고, 장애 복구부(517)는 복구 명령을 장애가 발생된 엣지 클라우드(430)의 엣지 매니저 에이전트(431)로 전송한다. 장애 복구부(517)는 엣지 매니저 에이전트(431)로부터 복구 처리 결과를 수신하여 운용자 단말(530)로 전송한다.

여기서, 장애 복구부(517)는 발생된 장애에 대해 상기 구조체(800)의 룰 설명과 상세 로그의 데이터 등을 운용자 단말(530)의 장애 복구 전용 창으로 제공할 수 있다. 장애 복구 처리는 관리자의 장애 복구 정책에 따라서 다양할 수 있다. 예를 들면, 1차 자동 복구, 2차 운용자 매뉴얼 복구, 3차 제 3전문가 복구가 순차적으로 진행될 수 있다. 정의된 장애 복구 정책에 따라, 자동으로 복구가 가능한 경우, 그 절차에 따라 장애 복구부(517)는 운용자 단말(530)과 양방향으로 통신하며 자동 복구 명령을 수행하고 운용자 단말(530)은 장애 복구 결과를 화면에 표시한다. 발생된 장애를 자동으로 복구하는 것이 불가능한 경우, 장애 복구 가이드를 화면에 단계적으로 표시하여 운용자가 스스로 장애를 복구할 수 있도록 지원한다. 마지막으로 발생된 장애의 자동 복구 및 운용자 복구가 실패될 경우 또는 전문가 복구로 기 설정된 경우, 제 3전문가에게 복구를 통보한다.

도 11은 본 발명의 일 실시예에 따른 5G 분산 클라우드 시스템(400)에서 장애를 관리하는 방법의 개략적 순서도이다. 장애 관리의 방법을 위해, 도 5 내지 도 10를 참조하여 상기에서 설명된 기재가 이하에서 원용될 수 있다.

중앙 클라우드(410)는 시스템(400)의 인프라를 구성하는 각 객체에서 발생되는 빅 데이터의 로그를 수집한다(S1111). 로그가 스토리지 서버에서 수집되면, 중앙 클라우드(410)는 스토리지 서버에 저장된 로그를 분석하여 메시지로 변환한다(S1113).

로그 분석에 의해 변환된 메시지가 생성되면, 중앙 클라우드(410)는 룰 엔진의 필터링 규칙을 처리하여 장애를 검출한다(S1121). 빅 데이터의 로그로부터 변환된 메시지 및 룰 엔진의 필터링 규칙에 의해, 시스템(400)의 물리적인 에러뿐만이 아니라 논리적인 에러를 장애로 검출하는 것이 가능하다.

이후, 운용자 단말(530)에서 운용자가 장애 관리 화면을 요청하면, 중앙 클라우드(410)가 운용자의 화면 요청을 수신한다(S1131), 중앙 클라우드(410)는 요청된 화면을 위해 클라우드 인프라의 토폴로지를 기반으로 화면 표시 정보를 생성하고, 발생된 장애 정보를 추가하여 운용자 단말(530)로 제공한다(S1133). 또한, 시스템(400)에서 장애가 발생하면, 중앙 클라우드(410)는 발생된 장애 정보의 실시간 표시를 위해 운용자 단말(530)로 장애 정보를 제공한다(S1135).

여기서, 운용자 단말(530)이 중앙 클라우드(410)로부터 제공받은 화면 표시 정보를 기반으로 장애 관리 화면을 생성하여 표시한다. 이 장애 관리 화면에서 시스템(400)을 구성하는 각 인프라 객체 및 객체들 간의 연결 정보가 계층적 연관 구조로 표시된다. 즉, 운용자는 화면에서 각 객체의 상위 객체, 하위 객체, 연결 객체로 이동하면서 상세 장애 정보를 요청하고 제공받을 수 있다.

운용자가 장애 관리 화면에서 복구를 요청하면, 중앙 클라우드(410)는 운용자 단말(530)로부터 운용자의 복구 요청을 수신한다(S1137). 운용자는 자동 복구를 요청하거나, 운용자의 매뉴얼 명령을 전송하여 복구를 요청하거나, 제 3전문가에 의한 복구를 요청할 수 있다. 복구 요청이 수신되면, 중앙 클라우드(410)는 엣지 클라우드(430)로 대응되는 복구 명령을 전송하여 복구 처리하고, 엣지 클라우드(430)로부터 수신된 복구 처리 결과를 운용자 단말(530)로 전송한다(S1139). 만약, 제 3전문가 복구가 요청되면, 중앙 클라우드(410)는 전문가 단말로 장애 정보를 통보하여 장애 복구를 요청한다.

도 12는 도 11에서 로그를 분석하여 메시지로 변환하는 단계(S1113)의 상세 순서도이다.

먼저, 클라우드 시스템(400)의 기본적인 로그 파일은 하드웨어 관련된 로그를 제공하는 인프라 로그, 하드웨어의 운영체제에서 제공하는 시스템 로그, 그리고 클라우드 관련해서 가장 많은 정보를 제공하는 플랫폼 로그 등으로 분류할 수 있다. 중앙 클라우드(410)는 스토리지 서버에 저장된 각 로그 파일에서 전체 로그 라인들을 로그 분석을 위해 메시지 큐에 저장한다.

중앙 클라우드(410)는 메시지 큐로부터 로그 라인을 읽어 분석 대상의 로그 라인이 존재하는지 판단한다(S1211). 로그 라인이 존재하면, 중앙 클라우드(410)는 서버 이름(hostname) 및 로그 파일 이름(logname)을 이용하여 로그 라인의 발생 위치를 식별하고(S1212), 로그 라인에 대해 공백, 불필요한 라인의 제거 등과 같은 파싱 처리를 하고(S1213), 해당 라인에 유효한 라인 아이디(line_id)가 존재하는지 판단한다(1214).

유효한 라인 아이디가 존재할 경우, 변환 프로그램의 시작 후 최초의 로그 라인이면(S1215), 중앙 클라우드(410)는 메시지 구조체(700)의 항목을 초기화하여 라인 버퍼(msg_line__buf)에 해당 라인을 추가하고(S1225), 메시지 큐에서 다음 라인을 읽어들인다(S1211).

만약, 로그 라인이 유효한 라인 아이디가 존재하지 않으면, 로그 메시지 헤더가 없이 선행 로그 라인에 추가적인 내용만 제공하는 경우이므로, 선행 라인의 메시지 키(msg_key)로 생성된 라인 버퍼(msg_line_buf)에 라인을 추가하고(S1224), 메시지 큐에서 다음 라인을 읽어들인다(1211).

만약, 로그 라인이 유효한 라인 아이디를 가지고 있고, 이 라인 아이디로 구성된 동일 메시지 키가 이미 존재하면(S1216), 로그 라인의 메시지 키를 키로 사용하는 라인 버퍼에 추가한다(S1224).

로그 라인이 유효한 라인 아이디를 가지고 있고, 이 라인 아이디로 구성된 메시지 키가 존재하지 않으면, 이전 메시지 키를 이용한 로그 라인들의 메시지가 완성된 것으로 판단하고, 라인 버퍼에 저장된 각 라인들을 합쳐서 하나의 메시지로 완성하고, 생성된 메시지를 큐(log_message)에 저장한다(S1217). 하나의 메시지가 저장되면, 상기 단계(S1225)에서와 같이, 메시지 구조체(700)를 초기화하고, 라인 버퍼에 해당 라인을 추가한다. 그리고 메시지 큐(log_line)에서 다음 라인을 읽어들인다(S1211).

또한, 동일 메시지 그룹은 보통 짧은 시간에 여러 개의 로그 라인으로 생성된다. 이전에 하나의 로그 라인을 읽어서 메시지 구조체(700)에 값을 저장하였으나, 오랜 시간 동안 신규 로그 라인이 읽어지지 않으면 메시지 구조체(700)에 있는 내용은 신속히 처리되지 못하고 오랜 시간 대기 상태에 빠질 수 있는 문제점이 있다. 이에 로그 라인의 메시지 큐를 3번 연속 읽었으나, 로그 라인이 없는 경우(S1221), 이전 메시지 구조체(700)에 저장하는 데이터를 이미 완성된 메시지라고 판단하고, 상기 단계(S1217)의 메시지 완성 및 저장을 처리한다.

도 13은 도 11에서 장애 관리를 위해 그래픽 정보를 생성하여 제공하는 단계(S1133)의 상세 순서도이다.

운용자 단말(530)은 중앙 클라우드(410)에 웹 접속하고, 웹 접속을 통해 클라우드 시스템(400)을 모니터링하기 위해, 장애 관리 화면의 표시를 중앙 클라우드(410)에 요청한다(1301).

요청을 받은 중앙 클라우드(410)는 운용자가 요청한 화면의 토폴로지(인프라, 플랫폼, 고객 서비스)에 맞는 그래픽 자료 구조를 자동으로 생성할 클래스를 로딩한다(1311). 중앙 클라우드(410)는 그래픽 토폴로지를 표현하는데 필요한 그래픽 객체와 그 객체들을 연결할 링크 정보를 생성한다(1312). 그래픽 토폴로지의 그래픽 객체 및 링크의 정보가 생성되면, 중앙 클라우드(410)는 생성된 정보를 기반으로 화면 크기를 결정하고, 결정된 화면 크기의 정보가 저장된 화면 크기 자료 구조를 생성한다(1313). 즉, 사용자가 요구하는 장애 관리 화면에 따라 표시될 객체의 수 및 연결 링크가 다르기 때문에, DB로부터 화면에 표시될 객체 정보 및 링크 정보를 조회하고, 조회된 정보를 기반으로 화면의 크기가 결정된다.

화면 아이디(id) 및 화면 크기(width/height)를 포함하는 화면 크기 정보가 화면 크기 자료 구조에 저장되면, 중앙 클라우드(410)는 결정된 화면을 구성하는 그래픽 객체들의 배치 정보를 객체의 아이디, 타이틀, 그래픽 객체 종류, 화면에 표시할 제약 조건 등으로 구성된 화면 객체 자료 구조를 생성한다(S1314). 그리고 이러한 화면 객체들을 연결하기 위한 연결 링크의 화면 링크 식별자, 링크 시작 식별자, 링크 종료 식별자 및 링크의 화살표 방향, 링크 선의 종류의 값이 저장된 링크 자료 구조를 생성한다(S1315). 여기서, 화면 크기 자료 구조, 화면 객체 자료 구조 및 화면 링크 자료 구조에서 사용되는 아이디는 장애 정보에서도 동일한 이름으로 사용되어 토폴로지에 장애를 표현할 수 있다. 중앙 클라우드(410)는 각각 생성된 화면 크기, 화면 객체, 화면 링크의 화면 자료 구조들의 그래픽 정보를 운용자 단말(530)로 전송한다(S1316).

상기 화면 자료 구조를 도 10을 참조하여 설명하면, 도 10의 장애 안내 화면에서 상기 화면 크기 자료 구조의 크기를 기반으로 화면이 표시되고, 화면 객체 자료 구조에 따라 9개의 그래픽 객체 노드가 표시되고, 화면 링크 자료 구조에 따라 9개 객체들 간의 연결 선이 표시된다.

운용자 단말(530)은 중앙 클라우드(41)로부터 수신된 화면 자료 구조를 이용하여 장애 관리 화면을 생성하고 표시한다(S1321). 운용자 단말(530)은 정해진 주기마다 장애 정보를 중앙 클라우드(410)로 요청한다(S1322).

장애 정보의 제공을 요청받은 중앙 클라우드(410)는 장애 정보가 존재할 경우(S1331), 실시간으로 화면 정보를 기반으로 표시될 수 있는 장애 정보를 전송한다(1332). 운용자 단말(530)은 중앙 클라우드(410)로부터 전송받은 장애 정보를 장애 관리 화면에서 표시한다(S1341).

도 14는 도 11에서 장애를 복구하여 처리 결과를 제공하는 단계(S1139)의 상세 순서도이다.

도 13의 장애 정보 표시 단계(S1314) 이후로, 운용자가 화면에 표시된 장애를 복구하기 위해 장애 복구 버튼을 누르면, 운용자 단말(530)은 해당 장애를 손쉽게 파악할 수 있는 장애 요약 설명을 화면에 출력하고, 중앙 클라우드(510)로 장애 복구의 안내를 요청한다.

운용자의 장애 복구 요청에 의해, 중앙 클라우드(410)는 운용자 단말(530)로부터 장애 복구의 안내 요청을 수신한다(S1411). 안내 요청을 수신한 중앙 클라우드(410)는 요청된 장애에 대해 룰 엔진 구조체(800)의 상기 복구 처리 정보의 필드를 참조한다(S1412). 참조된 복구 처리 정보는 자동 복구, 운용자 매뉴얼 복구 및 제 3전문가 복구 중 어느 하나일 수 있다. 참조된 복구 처리 정보에서, 자동 복구가 참조될 경우(S1413), 중앙 클라우드(410)는 운용자 단말(530)로 자동 복구 화면을 전송하여 운용자에게 자동 복구의 실행을 선택할 것을 요청하고(S1414), 운용자 단말(530)로부터 자동 복구 실행의 요청을 수신한다(S1415).

장애 복구의 명령이 접속 상태가 아닌 엣지 클라우드(430)에서 맨 처음 시작되는 경우(S1421), 중앙 클라우드(410)는 엣지 클라우드(430)에 접속하고(S1422), 엣지 매니저 에이전트(431)로 자동 복구 명령을 전송한다(S1423). 이미 접속된 상태의 엣지 클라우드(430)에서 장애 복구가 실행될 경우, 상기 접속 처리 단계(S1422)는 생략된다.

중앙 클라우드(410)로부터 자동 복구 명령이 전송되면, 엣지 매니저 에이전트(431)는 자동 복구 명령을 수신하여 실행한다. 엣지 매니저 에이전트(431)는 장애 복구 명령의 실행 결과를 중앙 클라우드(410)로 전송한다.

중앙 클라우드(410)는 엣지 매니저 에이전트(431)로부터 상기 실행 결과를 수신하여 운용자 단말(530)로 전송한다(S1424). 그러면, 운용자 단말(530)은 중앙 클라우드(410)로부터 수신된 실행 결과를 화면에 표시한다.

상기 실행 결과가 성공일 경우(S1431), 장애 복구의 다음 단계가 있는지 검사하고(S1432), 다음 작업이 존재하면, 사용자가 실행을 선택하는 단계로 돌아간다(S1415). 다음 작업이 존재하지 않으면, 당해 장애의 복구 처리가 종료된다.

만약, 자동 복구 명령의 처리 결과가 3회 연속된 실패로 판단될 경우(S1441), 관리자에 의해 설정된 장애 복구 정책에 따라, 해당 장애의 상기 복구 처리 정보는 3회 연속 실패된 자동 복구 명령 대신에 운용자 매뉴얼 복구 또는 제 3전문가 복구로 변경되어, 해당 장애의 복구 처리는 상기 단계(S1413)로 복귀한다.

또한, 상기 단계(1413)에서 자동 복구가 아닌 장애는 운용자 매뉴얼 복구인지 판단되고(S1451), 운용자 매뉴얼 복구의 장애이면, 중앙 클라우드(410)는 운용자가 내리는 매뉴얼 명령에 따라 장애 복구를 처리한다(S1453). 여기서, 중앙 클라우드(410)는 운용자 단말(530)로 장애 복구를 위한 운용자 매뉴얼을 제공하고, 운용자의 내린 명령을 엣지 클라우드(430)에서 실행하고, 명령의 실행 결과를 운용자 단말(530)로 전송한다. 물론, 운용자의 매뉴얼 복구가 실패되면, 실패된 장애의 상기 장애 복구 정보가 제 3전문가 복구로 변경될 수 있다.

또한, 장애의 장애 복구 정보가 제 3전문가 복구이면, 중앙 클라우드(410)는 제 3전문가 정보를 참조하여 장애 복구를 통보한다(S1461)

본 발명은 비록 한정된 실시예와 도면에 의해 설명되었으나, 본 발명은 이것에 의해 한정되지 않으며 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 본 발명의 기술사상과 아래에 기재될 특허청구범위의 균등범위 내에서 다양한 수정 및 변형이 가능함은 물론이다.

100 : 클라우드 시스템

Claims

5G 분산 클라우드 시스템의 빅 데이터를 이용하여 장애를 관리하는 장치에 있어서,
상기 시스템의 인프라에서 발생되는 빅 데이터의 로그를 장애에 관련된 메시지로 변환하는 메시지 변환부;
변환된 메시지에 룰 엔진을 적용하여 장애를 검출하는 장애 검출부;
검출된 각 장애의 화면 출력을 위해, 장애가 발생된 인프라 객체를 토폴로지 기반의 그래픽 정보로 생성하여 운용자 단말로 제공하는 장애 그래픽 제공부; 및
검출된 장애의 장애 복구 정보를 생성하여 상기 운용자 단말로 제공하는 장애 복구부
를 포함하는 장치.
제 1항에 있어서,
상기 메시지 변환부는,
하드웨어, 운영체제, 클라우드 플랫폼 및 네트워크 플랫폼의 객체를 포함하는 클라우드 인프라의 각 객체별 로그를 수집하여 저장하는 것을 특징으로 하는 장치.
제 1항에 있어서,
상기 메시지 변환부는,
각 로그 파일에서 적어도 하나 이상의 로그 라인을 장애 검출을 위한 메시지로 변환하는 것을 특징으로 하는 장치.
제 1항에 있어서,
상기 메시지 변환부는,
상기 로그가 수집된 서버의 서버 이름;
상기 로그가 기록된 파일 이름;
상기 로그에서 적어도 하나 이상의 로그 라인이 분석되어 변환된 메시지를 식별하는 라인 아이디;
상기 메시지의 상기 서버 이름, 상기 파일 이름 및 상기 라인 아이디로 구성된 메시지 키; 및
상기 메시지로 분석된 각 로그 라인이 저장되는 라인 버퍼
를 포함하는 구조체를 이용하여 로그 라인 및 변환된 메시지를 저장하는 것을 특징으로 하는 장치.
제 1항에 있어서,
상기 장애 검출부는,
적어도 하나 이상의 필터링 룰을 포함하는 룰 그룹 이름;
상기 필터링 룰;
상기 필터링 룰에서 처리되는 필터 조건; 및
상기 메시지로부터 검출되어 상기 필터 조건이 적용되는 필터링 키
를 포함하는 상기 룰 엔진의 구조체를 이용하여 메시지로부터 필터링 키를 검출하고, 검출된 필터링 키에 적용된 필터 조건이 상기 메시지에서 만족되면 장애의 발생으로 검출하는 것을 특징으로 하는 장치.
제 1항에 있어서,
상기 장애 검출부는,
장애가 검출된 상기 인프라의 계층 구조 정보를 포함하는 룰 이름;
상기 장애를 설명하는 룰 설명;
상기 장애가 검출되는 로그 파일 이름;
로그의 등급을 정의하는 로그 등급;
로그의 키워드에서 대문자 및 소문자의 구분을 정의하는 케이스;
상기 메시지에 대응되는 로그 라인으로부터 상기 장애를 검출하기 위해, AND 와 OR의 필터 조건 및 상기 필터 조건이 적용되는 적어도 하나 이상의 키워드를 포함하는 적어도 하나 이상의 필터링 룰; 및
상기 필터링 룰을 만족하여 검출된 상기 장애의 복구를 위해 실행되는 자동 복구, 운용자 매뉴얼 복구 및 제 3전문가 복구의 복구 처리 정보;
상기 장애의 장애 등급을 정의하는 장애 등급
을 포함하는 상기 룰 엔진의 구조체를 이용하는 것을 특징으로 하는 장치.
제 1항에 있어서,
화면 표시를 위해 상기 인프라의 객체 및 객체들간의 계층적 연결 정보가 저장된 그래픽 DB를 더 포함하고,
상기 장애 그래픽 제공부는, 운용자 단말이 요청한 인프라에 대응되는 객체 및 계층적 연결 정보를 상기 그래픽 DB로부터 조회하고, 조회된 객체들간의 계층적 연결 정보를 그래픽 정보로 생성하고, 생성된 그래픽 정보를 상기 운용자 단말로 제공하는 것을 특징으로 하는 장치.
제 1항에 있어서,
상기 장애 그래픽 제공부는,
상기 운용자 단말에서 표시된 상기 그래픽 정보에 포함된 객체에서 장애가 존재하면, 화면 표시를 위해 상기 운용자 단말로 장애 정보를 전송하는 것을 특징으로 하는 장치.
제 1항에 있어서,
상기 장애 복구부는,
운용자 단말로 상기 장애 복구 정보를 제공하고, 운용자의 요청에 따라 자동 복구 처리, 운용자 매뉴얼 복구 처리 및 제 3전문가 복구 처리를 실행하여 장애를 복구하는 것을 특징으로 하는 장치.
제 1항에 있어서,
상기 장애 복구부는,
자동 실행 또는 운용자의 요청에 따라, 장애가 발생된 상기 인프라로 자동 복구의 명령을 전송하고, 명령이 처리된 결과를 운용자 단말로 제공하는 것을 특징으로 하는 장치.
제 1항에 있어서,
상기 장애 복구부는,
상기 자동 복구가 실패될 경우, 운용자의 요청에 따라 운용자 매뉴얼 복구의 명령을 장애가 발생된 상기 인프라로 전송하고, 명령이 처리된 결과를 상기 운용자 단말로 제공하고,
상기 자동 복구 또는 상기 운용자 매뉴얼 복구가 실패될 경우, 제 3전문가 복구를 위해 장애 정보를 전문가 단말로 통보하는 것을 특징으로 하는 장치.
5G 분산 클라우드 시스템의 빅 데이터를 이용하여 장애를 관리하는 장치가 실행하는 방법에 있어서,
상기 시스템의 인프라에서 발생되는 빅 데이터의 로그를 장애에 관련된 메시지로 변환하는 단계;
변환된 메시지에 룰 엔진을 적용하여 장애를 검출하는 단계;
검출된 각 장애의 화면 출력을 위해, 장애가 발생된 인프라 객체를 토폴로지 기반의 그래픽 정보로 생성하여 운용자 단말로 제공하는 단계; 및
검출된 장애의 장애 복구 정보를 생성하고 상기 운용자 단말로 제공하여 장애를 복구하는 단계
를 포함하는 방법.
제 12항에 있어서,
상기 메시지로 변환하는 단계는,
하드웨어, 운영체제, 클라우드 플랫폼 및 네트워크 플랫폼의 객체를 포함하는 클라우드 인프라의 각 객체별 로그를 수집하여 저장하는 단계인 것을 특징으로 하는 방법.
제 12항에 있어서,
상기 메시지로 변환하는 단계는,
각 로그 파일에서 적어도 하나 이상의 로그 라인을 장애 검출을 위한 메시지로 변환하는 단계인 것을 특징으로 하는 방법.
제 12항에 있어서,
상기 메시지로 변환하는 단계는,
상기 로그가 수집된 서버의 서버 이름;
상기 로그가 기록된 파일 이름;
상기 로그에서 적어도 하나 이상의 로그 라인이 분석되어 변환된 메시지를 식별하는 라인 아이디;
상기 메시지의 상기 서버 이름, 상기 파일 이름 및 상기 라인 아이디로 구성된 메시지 키; 및
상기 메시지로 분석된 각 로그 라인이 저장되는 라인 버퍼
를 포함하는 구조체를 이용하여 로그 라인 및 변환된 메시지를 저장하는 단계인 것을 특징으로 하는 방법.
제 12항에 있어서,
상기 장애를 검출하는 단계는,
적어도 하나 이상의 필터링 룰을 포함하는 룰 그룹 이름;
상기 필터링 룰;
상기 필터링 룰에서 처리되는 필터 조건; 및
상기 메시지로부터 검출되어 상기 필터 조건이 적용되는 필터링 키
를 포함하는 상기 룰 엔진의 구조체를 이용하여 메시지로부터 필터링 키를 검출하고, 검출된 필터링 키에 적용된 필터 조건이 상기 메시지에서 만족되면 장애의 발생으로 검출하는 단계인 것을 특징으로 하는 방법.
제 12항에 있어서,
상기 장애를 검출하는 단계는,
장애가 검출된 상기 인프라의 계층 구조 정보를 포함하는 룰 이름;
상기 장애를 설명하는 룰 설명;
상기 장애가 검출되는 로그 파일 이름;
로그의 등급을 정의하는 로그 등급;
로그의 키워드에서 대문자 및 소문자의 구분을 정의하는 케이스;
상기 메시지에 대응되는 로그 라인으로부터 상기 장애를 검출하기 위해, AND 와 OR의 필터 조건 및 상기 필터 조건이 적용되는 적어도 하나 이상의 키워드를 포함하는 적어도 하나 이상의 필터링 룰; 및
상기 필터링 룰을 만족하여 검출된 상기 장애의 복구를 위해 실행되는 자동 복구, 운용자 매뉴얼 복구 및 제 3전문가 복구의 복구 처리 정보;
상기 장애의 장애 등급을 정의하는 장애 등급
을 포함하는 상기 룰 엔진의 구조체를 이용하는 단계인 것을 특징으로 하는 방법.
제 12항에 있어서,
상기 장치는 화면 표시를 위해 상기 인프라의 객체 및 객체들간의 계층적 연결 정보가 저장된 그래픽 DB를 포함하고,
상기 제공하는 단계는, 운용자의 요청에 대응되는 객체 및 계층적 연결 정보를 상기 그래픽 DB로부터 조회하고, 조회된 객체들간의 계층적 연결 정보를 그래픽 정보로 생성하고, 생성된 그래픽 정보를 상기 운용자 단말로 제공하는 단계인 것을 특징으로 하는 방법.
제 12항에 있어서,
상기 제공하는 단계는,
상기 운용자 단말에서 표시된 상기 그래픽 정보에 포함된 객체에서 장애가 존재하면, 화면 표시를 위해 상기 운용자 단말로 장애 정보를 전송하는 단계인 것을 특징으로 하는 방법.
제 12항에 있어서,
상기 복구하는 단계는,
운용자 단말로 상기 장애 복구 정보를 제공하고, 운용자의 요청에 따라 자동 복구 처리, 운용자 매뉴얼 복구 처리 및 제 3전문가 복구 처리를 실행하여 장애를 복구하는 단계인 것을 특징으로 하는 방법.
제 12항에 있어서,
상기 복구하는 단계는,
자동 실행 또는 운용자의 요청에 따라, 장애가 발생된 상기 인프라로 자동 복구의 명령을 전송하고, 명령이 처리된 결과를 운용자 단말로 제공하는 단계인 것을 특징으로 하는 방법.
제 12항에 있어서,
상기 복구하는 단계는,
상기 자동 복구가 실패될 경우, 운용자의 요청에 따라 운용자 매뉴얼 복구의 명령을 장애가 발생된 상기 인프라로 전송하고, 명령이 처리된 결과를 상기 운용자 단말로 제공하는 단계; 및
상기 자동 복구 또는 상기 운용자 매뉴얼 복구가 실패될 경우, 제 3전문가 복구를 위해 장애 정보를 전문가 단말로 통보하는 단계를 포함하는 것을 특징으로 하는 방법.