KR20200027783A - 분산 지능모듈의 통합관리 시스템 - Google Patents

Abstract

본 발명은 사용자를 이해하고 적절한 도움을 주는 동반자 관점에서의 통합관리 기술에 관한 것으로서, 일실시예에 따른 분산 지능모듈의 통합관리 시스템은 외부 기기와의 연결을 위한 라우팅 처리부, 상기 외부기기로부터의 복수의 입력을 수집하여 기계 학습하고, 무정지 운영을 위한 스토리지 및 컴퓨팅, 모듈 분산 환경구성, 통합관리시스템 및 모니터링 및 디버깅 기술을 제공하되, 복수의 호스트 노드를 그룹핑하여 클러스터를 구성하고, 상기 구성된 클러스터를 컨테이너가 요구되는 위치에 배포(auto-placement)하며, 상기 컨테이너가 동작하지 않는 경우 자동으로 복구되도록 제어하고(auto-restart), 시스템 요구에 따라 컨테이너를 추가(scaling), 복제(replication), 업데이트(rolling update), 및 롤백(rollback) 하는 컨테이너 오케스트레이션 툴을 제어하는 컨테이너 오케스트레이션 툴 처리부, 및 상기 구성된 클러스터를 이용해서 통합관리 모니터링을 위한 서비스를 제공하는 서비스 처리부를 포함할 수 있다.

Description

분산 지능모듈의 통합관리 시스템{INTEGRATED MANAGEMENT SYSTEM OF DISTRIBUTED INTELLIGENCE MODULE}

본 발명은 사용자를 이해하고 적절한 도움을 주는 동반자 관점에서의 통합관리 기술에 관한 것으로서, 다양한 입력을 수집하여 학습하는 적응형 기계학습을 기반으로 하여 디지털 동반자 통합시스템의 무정지 운영을 위한 스토리지 및 컴퓨팅, 모듈 분산 환경구성, 통합관리시스템 및 모니터링/디버깅 기술을 제공하는 기술적 사상에 관한 것이다.

쿠버네티스(Kubernetes)는 디플로이 자동화, 스케일링, 컨테이너화된 애플리케이션의 관리를 위한 오픈 소스 시스템으로서 원래 구글에 의해 설계되었고 현재 리눅스 재단에 의해 관리되고 있다. 쿠버네티스의 목적은 여러 클러스터의 호스트 간에 애플리케이션 컨테이너의 배치, 스케일링, 운영을 자동화하기 위한 플랫폼을 제공하기 위함이다. 도커를 포함하여 일련의 컨테이너 도구들과 함께 동작한다.

근래에는 이러한 쿠버네티스를 활용하는 다양한 시스템이 개발되고 있는 추세이다.

한편, 컴퓨팅 하드웨어의 고도화는 중소형 디바이스의 성능을 향상시키고 있으며, 클라우드 서버에서 전담으로 처리하던 지능 기능이 에지 서버로 이동하는 비집중화(Decentralization) 현상으로 이어진다. 이는 더 작은 규모의 사물에도 지능이 존재할 수 있는 흐름이 진행되고 있다는 것이다. 이러한 추세로 인해, 문제 해결을 위해 기존의 중앙 집중형 지능보다는 분산형 지능을 활용하는 경향으로 바뀌어가고 있다. 인공지능의 다음 진화 방향은 분산되고 자율적인 분산지능이 힘을 합쳐서 고도의 지능을 발휘하는 협력 지능이 될 것으로 예측된다.

분산 지능은 한 곳에서 풀기 어려운 복잡계 문제를 지능을 가지고 있는 에이전트를 분산시켜서 해결하는 기술로서, 국지적인 정보를 통해 국지적 최적화를 수행하고, 이러한 결과들이 전역적인 최적화 효과를 달성하는 형태로 문제를 해결할 수 있다.

한국공개특허 제2017-0053023호 "지능형 분산처리 시스템 및 방법" 한국출원특허 제1999-0051066호 "분산기능 구조 중심의 지능망 서비스 검증 방법"

본 발명은 사용자를 이해하고 적절한 도움을 주는 동반자 관점에서 다양한 입력을 수집하여 학습하는 적응형 기계학습 기반 자율지능 디지털 동반자 프로젝트를 제공하는 것을 목적으로 한다.

본 발명은 디지털 동반자 통합시스템의 무정지 운영을 위한 스토리지 및 컴퓨팅, 모듈 분산 환경구성, 통합관리시스템 및 모니터링/디버깅 기술을 제공하는 것을 목적으로 한다.

본 발명은 여러 호스트 노드를 묶어 클러스터를 구성하여 컨테이너를 적절한 위치에 배포하고(auto-placement) 컨테이너가 동작하지 않으면 자동으로 복구하며(auto-restart), 필요에 따라 컨테이너를 매끄럽게 추가(scaling), 복제(replication), 업데이트(rolling update), 롤백(rollback) 할 수 있게 하는 것을 목적으로 한다.

일실시예에 따른 분산 지능모듈의 통합관리 시스템은 외부 기기와의 연결을 위한 라우팅 처리부, 상기 외부기기로부터의 복수의 입력을 수집하여 기계 학습하고, 무정지 운영을 위한 스토리지 및 컴퓨팅, 모듈 분산 환경구성, 통합관리시스템 및 모니터링 및 디버깅 기술을 제공하되, 복수의 호스트 노드를 그룹핑하여 클러스터를 구성하고, 상기 구성된 클러스터를 컨테이너가 요구되는 위치에 배포(auto-placement)하며, 상기 컨테이너가 동작하지 않는 경우 자동으로 복구되도록 제어하고(auto-restart), 시스템 요구에 따라 컨테이너를 추가(scaling), 복제(replication), 업데이트(rolling update), 및 롤백(rollback) 하는 컨테이너 오케스트레이션 툴을 제어하는 컨테이너 오케스트레이션 툴 처리부, 및 상기 구성된 클러스터를 이용해서 통합관리 모니터링을 위한 서비스를 제공하는 서비스 처리부를 포함할 수 있다.

일실시예에 따른 상기 컨테이너 오케스트레이션 툴은 하나의 마스터(master)와 복수 개의 노드를 포함하고, 상기 마스터를 이용해서 개발자로부터의 명령을 수집하고, 상기 수집된 명령을 노드를 이용해서 관리하며, 상기 노드를 이용해서 접속되는 사용자에게 서비스를 제공하며, 상기 마스터는 작업을 위한 API 서버, 상태(state)를 관리하기 위한 분산저장소, 분산키 저장소(etcd), 스케줄러(scheduler), 콘트롤러 매니져(controller manager)를 포함하고, 상기 노드는 상기 마스터와 통신하는 kubelet과 외부의 요청을 처리하는 kube-proxy, 및 컨테이너(container) 리소스 모니터링을 위한 cAdviser를 포함하고, 상기 컨테이너 오케스트레이션 툴은 클러스터에서 실행중인 프로세서인 포드(POD)를 이용해서 애플리케이션 컨테이너 스토리지 리소스, 고유 한 네트워크 IP 및 컨테이너 실행 방법을 관리하는 옵션을 캡슐화하는 것을 특징으로 한다.

일실시예에 따른 상기 컨테이너 오케스트레이션 툴 처리부는, 상기 컨테이너 오케스트레이션 툴을 이용해서, 호스트 전체에서 컨테이너를 오케스트레이션 하되, 하드웨어를 활용하여 엔터프라이즈 앱을 실행하는데 필요한 리소스를 제공하고, 애플리케이션 배포 및 업데이트를 제어하거나 자동화하며, 장착된 스토리지를 이용하여 스테이트풀(stateful) 앱을 실행하고, 컨테이너화된 애플리케이션과 해당 리소스를 확장시키며, 자동 배치, 자동 재시작, 자동 복제 및 자동 확장을 사용해 앱 상태를 확인하거나 셀프 복구를 수행하며, 조건과 제약사항을 고려하여 컨테이너를 자동으로 배치, 반응이 없는 컨테이너를 재시작 하며, CPU 사용율을 기준으로 컨테이너를 확장하거나 축소하고, IP 주소와 DNS을 이용해 검색, 로드밸런싱을 수행할 수 있다.

일실시예에 따르면, 사용자를 이해하고 적절한 도움을 주는 동반자 관점에서 다양한 입력을 수집하여 학습하는 적응형 기계학습 기반 자율지능 디지털 동반자 프로젝트를 제공할 수 있다.

일실시예에 따르면, 디지털 동반자 통합시스템의 무정지 운영을 위한 스토리지 및 컴퓨팅, 모듈 분산 환경구성, 통합관리시스템 및 모니터링/디버깅 기술을 제공할 수 있다.

일실시예에 따르면, 여러 호스트 노드를 묶어 클러스터를 구성하여 컨테이너를 적절한 위치에 배포하고(auto-placement) 컨테이너가 동작하지 않으면 자동으로 복구하며(auto-restart), 필요에 따라 컨테이너를 매끄럽게 추가(scaling), 복제(replication), 업데이트(rolling update), 롤백(rollback) 할 수 있다.

도 1은 일실시예에 따른 분산 지능모듈의 통합관리 시스템을 설명하는 도면이다.
도 2는 일실시예에 따른 통합 관리 시스템 구성도를 설명하는 도면이다.
도 3은 일실시예에 따른 Kubernetes 아키텍처를 설명하는 도면이다.
도 4는 포드를 활용하는 Kubernetes 아키텍처를 설명하는 도면이다.
도 5는 일실시예에 따른 K8s Horizontal Pod Autoscaler 구조를 설명하는 도면이다.
도 6은 일실시예에 따른 K8s 롤링 업데이트를 설명하는 도면이다.
도 7은 일실시예에 따른 K8s 대쉬보드 화면을 나타내는 도면이다.
도 8은 일실시예에 따른 K8s 네트워크 구성도를 설명하는 도면이다.

본 명세서에 개시되어 있는 본 발명의 개념에 따른 실시예들에 대해서 특정한 구조적 또는 기능적 설명들은 단지 본 발명의 개념에 따른 실시예들을 설명하기 위한 목적으로 예시된 것으로서, 본 발명의 개념에 따른 실시예들은 다양한 형태로 실시될 수 있으며 본 명세서에 설명된 실시예들에 한정되지 않는다.

본 발명의 개념에 따른 실시예들은 다양한 변경들을 가할 수 있고 여러 가지 형태들을 가질 수 있으므로 실시예들을 도면에 예시하고 본 명세서에 상세하게 설명하고자 한다. 그러나, 이는 본 발명의 개념에 따른 실시예들을 특정한 개시형태들에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 변경, 균등물, 또는 대체물을 포함한다.

제1 또는 제2 등의 용어를 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만, 예를 들어 본 발명의 개념에 따른 권리 범위로부터 이탈되지 않은 채, 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소는 제1 구성요소로도 명명될 수 있다.

어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다. 구성요소들 간의 관계를 설명하는 표현들, 예를 들어 "~사이에"와 "바로~사이에" 또는 "~에 직접 이웃하는" 등도 마찬가지로 해석되어야 한다.

본 명세서에서 사용한 용어는 단지 특정한 실시예들을 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 명세서에서, "포함하다" 또는 "가지다" 등의 용어는 설시된 특징, 숫자, 단계, 동작, 구성요소, 부분품 또는 이들을 조합한 것이 존재함으로 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부분품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.

다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가진다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥상 가지는 의미와 일치하는 의미를 갖는 것으로 해석되어야 하며, 본 명세서에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.

이하, 실시예들을 첨부된 도면을 참조하여 상세하게 설명한다. 그러나, 특허출원의 범위가 이러한 실시예들에 의해 제한되거나 한정되는 것은 아니다. 각 도면에 제시된 동일한 참조 부호는 동일한 부재를 나타낸다.

도 1은 일실시예에 따른 분산 지능모듈의 통합관리 시스템(100)을 설명하는 도면이다.

일실시예에 따른 분산 지능모듈의 통합관리 시스템(100)은 사용자를 이해하고 적절한 도움을 주는 동반자 관점에서 다양한 입력을 수집하여 학습하는 적응형 기계학습 기반 자율지능 디지털 동반자 프로젝트를 제공할 수 있다. 또한, 디지털 동반자 통합시스템의 무정지 운영을 위한 스토리지 및 컴퓨팅, 모듈 분산 환경구성, 통합관리시스템 및 모니터링/디버깅 기술을 제공할 수 있다. 뿐만 아니라, 여러 호스트 노드를 묶어 클러스터를 구성하여 컨테이너를 적절한 위치에 배포하고(auto-placement) 컨테이너가 동작하지 않으면 자동으로 복구하며(auto-restart), 필요에 따라 컨테이너를 매끄럽게 추가(scaling), 복제(replication), 업데이트(rolling update), 롤백(rollback) 할 수 있다.

이를 위해, 일실시예에 따른 분산 지능모듈의 통합관리 시스템(100)은 라우팅 처리부(110), 컨테이너 오케스트레이션 툴 처리부(120), 및 서비스 처리부(130)를 포함할 수 있다.

먼저, 일실시예에 따른 라우팅 처리부(110)는 외부 기기와의 연결 기능을 처리할 수 있다. 외부 기기라 함은, 컴퓨터, 스마트폰 등의 통신 가능 기기를 포함할 수 있다.

한편, 컨테이너 오케스트레이션 툴 처리부(120)는 외부기기로부터의 복수의 입력을 수집하여 기계 학습할 수 있다. 또한, 컨테이너 오케스트레이션 툴 처리부(120)는 무정지 운영을 위한 스토리지 및 컴퓨팅, 모듈 분산 환경구성, 통합관리시스템 및 모니터링 및 디버깅 기술을 제공할 수 있다. 이때, 컨테이너 오케스트레이션 툴 처리부(120)는 복수의 호스트 노드를 그룹핑하여 클러스터를 구성하고, 구성된 클러스터를 컨테이너가 요구되는 위치에 배포(auto-placement)할 수 있다. 뿐만 아니라, 컨테이너가 동작하지 않는 경우에 자동으로 복구되도록 제어하고(auto-restart), 시스템 요구에 따라 컨테이너를 추가(scaling)하거나, 복제(replication), 업데이트(rolling update), 및 롤백(rollback) 할 수 있도록 컨테이너 오케스트레이션 툴을 제어할 수 있다.

일실시예에 따른 컨테이너 오케스트레이션 툴은 하나의 마스터(master)와 복수 개의 노드를 포함할 수 있다.

마스터를 이용해서 개발자로부터의 명령을 수집하고, 수집된 명령을 노드를 이용해서 관리할 수 있다. 또한, 컨테이너 오케스트레이션 툴은 노드를 이용해서 접속되는 사용자에게 서비스를 제공할 수 있다.

이 과정에서 마스터는 작업을 위한 API 서버, 상태(state)를 관리할 수 있으며, 이를 위해 마스터는 분산저장소, 분산키 저장소(etcd), 스케줄러(scheduler), 콘트롤러 매니져(controller manager)를 포함할 수 있다.

또한, 노드는 마스터와 통신하는 kubelet과 외부의 요청을 처리하는 kube-proxy, 및 컨테이너(container) 리소스 모니터링을 위한 cAdviser를 포함할 수 있다.

또한, 컨테이너 오케스트레이션 툴은 클러스터에서 실행중인 프로세서인 포드(POD)를 이용해서 애플리케이션 컨테이너 스토리지 리소스, 고유한 네트워크 IP 및 컨테이너 실행 방법을 관리하는 옵션을 캡슐화할 수 있다.

다음으로, 서비스 처리부(130)는 구성된 클러스터를 이용해서 통합관리 모니터링을 위한 서비스를 제공할 수 있다.

일실시예에 따른 컨테이너 오케스트레이션 툴 처리부(120)는 컨테이너 오케스트레이션 툴을 이용해서, 호스트 전체에서 컨테이너를 오케스트레이션 할 수 있다. 이때, 컨테이너 오케스트레이션 툴 처리부(120)는 하드웨어를 활용하여 엔터프라이즈 앱을 실행하는데 필요한 리소스를 제공하고, 애플리케이션 배포 및 업데이트를 제어하거나 자동화할 수 있다. 또한, 컨테이너 오케스트레이션 툴 처리부(120)는 장착된 스토리지를 이용하여 스테이트풀(stateful) 앱을 실행하고, 컨테이너화된 애플리케이션과 해당 리소스를 확장시키며, 자동 배치, 자동 재시작, 자동 복제 및 자동 확장을 사용해 앱 상태를 확인하거나 셀프 복구를 수행할 수 있다. 또한, 컨테이너 오케스트레이션 툴 처리부(120)는 조건과 제약사항을 고려하여 컨테이너를 자동으로 배치하고, 이 과정에서 반응이 없는 컨테이너를 재시작 하며, CPU 사용율을 기준으로 컨테이너를 확장하거나 축소하고, IP 주소와 DNS을 이용해 검색, 로드밸런싱을 수행할 수 있다.

도 2는 일실시예에 따른 통합 관리 시스템(200) 구성도를 설명하는 도면이다.

일실시예에 따른 통합 관리 시스템(200)은 라우팅 계층(210), Kubernetes(220) 계층, 서비스 계층(230) 등을 포함할 수 있다.

Kubernetes(220) 계층은 마스터(221) 및 복수의 노드(222)와 스토리지를 포함할 수 있다.

Kubernetes(220) 계층은 쿠버네티스(Kubernetes)를 제공하는 계층으로서, 쿠버네티스(Kubernetes)를 이해하기 위해서는 먼저 컨테이너를 이해해야 한다. 컨테이너는 어디에서나 실행할 수 있는 소형의 독립 운영 체제로서, 공용 리포지터리 또는 개인 리포지토리에서 호스팅되는 일련의 명령에 따라 몇 초 만에 생성이 가능하다.

컨테이너는 애플리케이션을 실행할 수 있으며, 애플리케이션의 시스템 수준 요구 사항에 맞게 특별히 설계되어 실행 시 사용할 JVM(Java Virtual Machine) 버전을 정의한다. 즉, 컨테이너를 사용하면 로컬 개발 환경이 프로덕션 환경과 동일하게 유지될 수 있다.

Kubernetes(220) 계층에서는 노드를 통해 여러 컨테이너를 관리하고 예약할 수 있다. 이는 선언형 프로그래밍 형식으로서, Kubernetes 컨트롤 플레인을 통해 특정 구성을 지정하면 Kubernetes가 그 상태를 자동으로 유지할 수 있다. Kubernetes(220) 계층은 AWS, GKE 등과 같은 여러 클라우드 플랫폼에서 실행 가능하지만, 하드드라이브 또는 노트북 VM에서도 실행이 가능하다.

컨테이너를 배포할 경우 Kubernetes(220) 계층이 필요한 이유는　오케스트레이션 때문이다. 오케스트레이션을 통해 컨테이너 그룹과 동시에 상호작용하고 컨테이너 레지스트리, 네트워킹, 스토리지, 보안 및 텔레메트리 서비스를 예약하고 구현할 수 있다.

사용자의 환경에서 Kubernetes(220) 계층을 사용할 경우 얻을 수 있는 주요 이점은 Kubernetes(220) 계층을 통해 물리 또는 가상 머신의 클러스트에서 컨테이너를 예약하고 실행할 수 있는 플랫폼이 확보된다는 것이다. 더 넓게 보면, 운영 환경에 컨테이너 기반 인프라를 완전히 구현해서 사용할 수 있다. 또한 Kubernetes(220) 계층은 운영 작업 태스크와 관련이 있으므로 다른 애플리케이션 플랫폼 또는 관리 시스템에서 가능한 작업의 상당수를 컨테이너를 사용해 수행할 수 있다.

Kubernetes(220) 계층을 사용하여 수행할 수 있는 작업으로, 여러 호스트 전체에서 컨테이너를 오케스트레이션할 수 있다. 또한, 하드웨어를 더 효과적으로 활용하여 엔터프라이즈 앱을 실행하는 데 필요한 리소스를 극대화시킬 수 있고, 애플리케이션 배포 및 업데이트를 제어하고 자동화할 수 있다. 뿐만 아니라, 스토리지를 장착 및 추가해 스테이트풀(stateful) 앱을 실행하고, 컨테이너화된 애플리케이션과 해당 리소스를 즉시 확장할 수 있다. 또한, 자동 배치, 자동 재시작, 자동 복제 및 자동 확장을 사용해 앱 상태 확인 및 셀프 복구를 수행할 수 있고, 블루-그린 배포를 사용해 새로운 기능을 자연스럽게 도입하고 테스트할 수 있다.

도 3은 일실시예에 따른 Kubernetes 아키텍처(300)를 설명하는 도면이다.

일실시예에 따른 Kubernetes 아키텍처(300)는 하나의 마스터(310)와 여러 개의 노드(320, 330, 340)로 구성되어 있다. 개발자는 kubectl　을 이용해서 마스터에 명령을 내리고, 노드들(320, 330, 340)을 관리하는　반면, 사용자는 노드들(320, 330, 340) 중에서 어느 하나의 노드에 접속해 서비스를 이용할 수 있다. 참고로, kubectl 명령어는 로컬 환경에서 kubernetes를 사용하기 위해 사용되는 명령어로 해석될 수 있다.

마스터(310)에는 작업을 위한 api server, state를 관리하기 위한 분산저장소 etcd, scheduler, controller manager등이 기본으로 있다. 노드들(320, 330, 340)에는 마스터(310)와 통신하는 kubelet과 외부의 요청을 처리하는 kube-proxy, container 리소스 모니터링을 위한 cAdviser 등이 있다.

보다 구체적으로, 도커는 노드의 기본 요구 사항 중 하나로서, 도커 이미지에서 컨테이너를 가져오고 실행하는 작업을 담당한다.

클러스터의 모든 노드가 간단한 네트워크 proxy를 실행하는데, Kube-Proxy는 클러스터 경로에서 proxy 노드를 사용하여 노드의 올바른 컨테이너에 요청할 수 있다.

Kubelet은 각 노드에서 실행되는 에이전트 프로세스로서, pod와 컨테이너를 관리할 수 있고, YAML 또는 JSON 형식으로 정의된 포드 사양을 처리할 수 있다. 또한, Kubelet은 포드 사양을 취하여 pod가 정상적으로 작동하는지 여부를 확인할 수 있다.

Flannel은 서브넷 주소의 범위를 할당 할 때 작동하는 오버레이 네트워크로서, 클러스터에서 실행되는 각 창의 IP를 지정하고 pod-to-pod 및 pod-to-services 통신을 수행하는 데 사용될 수 있다.

도 4는 포드를 활용하는 Kubernetes 아키텍처(400)를 설명하는 도면이다.

이하에서 설명하는, K8s는 일반적으로 양식화된 것으로서, Kubernetes의 변형 예로 볼 수 있다.

Kubernetes 아키텍처(400)에서 마스터(410)는 k8s　클러스터를 관리하는 머신에 해당한다. 노드(420)는 k8s　클러스터를 구성하는 머신에 해당하며, 도커 및 컨테이너를 포함하는 포드(Pod)를 포함할 수 있다. 도커는 컨테이너 실행을 담당하고, 포드는 서로 관련된 컨테이너들을 묶어 놓은 집합으로 해석될 수 있고, k8s의 배포/운영/관리의 단위이다.

본 명세서에서 언급되는 서비스라 함은 같은 일을 하는　포드들의 집합이고, k8s　클러스터 내에서 고유한 또는 고정된　IP　주소가 부여될 수 있다. 참고로, 동일한 서비스에 소속된 멤버　포드들에 대해 로드밸런싱 기능을 수행할 수 있다.

구체적으로, 포드는 Kubernetes의 기본 구성 요소로서, Kubernetes는 사용자가 생성하거나 배포하는 Kubernetes 객체 모델에서 가장 작고 간단한 단위이다. 따라서, 포드는 클러스터에서 실행중인 프로세스를 나타낼 수 있다.

포드는 애플리케이션 컨테이너(또는 경우에 따라 여러 컨테이너), 스토리지 리소스, 고유 한 네트워크 IP 및 컨테이너 실행 방법을 관리하는 옵션을 캡슐화할 수 있다. 즉, 포드는 하나의 컨테이너 또는 단단히 결합되어 리소스를 공유하는 소수의 컨테이너로 구성된 Kubernetes의 단일 응용 프로그램 인스턴스이다.

일실시예에 따른 Kubernetes 클러스터의 포드는 두 가지 주요 방법으로 사용될 수 있다.

단일 컨테이너를 실행하는 포드의 경우, Pod 당 하나의 컨테이너 모델이 가장 일반적인 Kubernetes 유스 케이스이다. 이 경우 포드는 단일 컨테이너를 둘러싼 래퍼로 생각할 수 있으며 Kubernetes는 컨테이너가 아닌 포드를 직접 관리할 수 있다.

함께 사용해야 하는 여러 컨테이너를 실행하는 포드의 경우, 포드 (Pod)는 밀접하게 결합되어 있고 자원을 공유해야 하는 여러 위치에 있는 컨테이너로 구성된 애플리케이션을 캡슐화 할 수 있다.

이렇게 공동 배치된 컨테이너는 공유 볼륨에서 공용으로 파일을 제공하는 하나의 단일 응집 서비스 단위를 형성 할 수 있으며 별도의 사이드카 컨테이너는 해당 파일을 새로 고치거나 업데이트할 수 있다. 한편, 포드는 이러한 컨테이너와 저장소 리소스를 하나의 관리 가능한 엔터티로 함께 그룹핑될 수 있다.

도 5는 일실시예에 따른 호리즌탈 Pod 오토스케일러의 구조(500)를 설명하는 도면이다.

호리즌탈 Pod 오토스케일러의 구조(500)는 복수의 포드들(510), 스케일을 포함하는 RC/디플로이먼트(520), 호리즌탈 Pod 오토스케일러(530)를 포함할 수 있다.

RC/디플로이먼트(520)에서의 배포는 응용 프로그램의 인스턴스를 만들고 업데이트하는 역할을 한다. 만약, Kubernetes 클러스터가 실행되면 컨테이너 응용 프로그램을 그 위에 배치 할 수 있다. 이렇게 하려면 Kubernetes 배포 구성을 만들 수 있다.

호리즌탈 Pod 오토스케일러(530)를 사용하면 Kubernetes는 관찰된 CPU 사용률을 기반으로 복제 컨트롤러, 배포 또는 복제본 집합의 포드 수를 자동으로 조정할 수 있다.

관찰된 CPU 사용률 대신, 알파 지원으로 다른 응용 프로그램에서 제공하는 메트릭을 기반으로 복제 컨트롤러, 배포 또는 복제본 집합의 포드 수를 자동으로 조정할 수도 있다.

호리즌탈 Pod 오토스케일러(530)는 크기를 조정할 수 없는 객체에는 적용되지 않으며, Kubernetes API 리소스 및 컨트롤러로 구현될 수 있다. 자원은 컨트롤러의 동작을 결정할 수 있으며, 컨트롤러는 관찰된 평균 CPU 사용률이 사용자가 지정한 대상과 일치하도록 복제 컨트롤러 또는 배포에서 복제본 수를 주기적으로 조정할 수 있다.

도 6은 일실시예에 따른 K8s 롤링 업데이트(600)를 설명하는 도면이다.

업데이트 롤링은 다음 작업을 허용할 수 있다.

컨테이너 이미지 업데이트를 통해 한 환경에서 다른 환경으로 응용 프로그램 수준 올릴 수 있다.

또한, 이전 버전으로 롤백다운 타임 없이 애플리케이션을 지속적으로 통합 및 지속적으로 제공할 수 있다.

또한, 배포가 공개적으로 공개되면 서비스는 업데이트 중에 사용 가능한 포드로만 트래픽을 로드 밸런싱할 수 있다.

포드는 스스로 치유되지 않는다. 즉, 실패한 노드에 대해 스케줄 된 경우 또는 스케줄링 조작 자체가 실패하면 포드는 삭제될 수 있다.

마찬가지로, 포드는 자원 부족이나 노드 유지 관리로 인해 퇴거에서 살아남지 못한다.

Kubernetes는 상대적으로 일회용 Pod 인스턴스를 관리하는 작업을 처리하는 컨트롤러라는 더 높은 수준의 추상화를 사용한다. 따라서 Pod를 직접 사용할 수도 있지만 컨트롤러를 사용하여 Pod를 관리하는 것이 Kubernetes에서 훨씬 더 일반적이다.

혼합 버전을 나란히 실행하는 애플리케이션에 이상적인 업데이트 방식이다. 롤링 업데이트를 사용하면 포드 인스턴스를 새 인스턴스로 점차적으로 업데이트하여 가동 중지 시간 없이 배포의 업데이트를 수행 할 수 있다.

사용자는 항상 응용 프로그램을 사용할 수 있기를 기대하며 개발자는 하루에 여러 번 새로운 버전을 배포해야 한다. Kubernetes에서는 롤링 업데이트를 수행할 수 있는데, 롤링 업데이트를 사용하면 포드 인스턴스를 새 인스턴스로 점차적으로 업데이트하여 가동 중지 시간 없이 배포의 업데이트를 수행 할 수 있다.

Horizontal Autoscaling이나 pod 복제로 여러 인스턴스를 실행하기 위해 응용 프로그램을 확장하는 것은 응용 프로그램 가용성에 영향을 미치지 않고 업데이트를 수행하기 위한 요구 사항이다. 기본적으로 업데이트 중에 사용할 수 없는 최대 포드 수와 생성 할 수 있는 새 포드의 최대 수는 하나이며, 두 옵션 모두 포드의 숫자 또는 백분율로 구성 할 수 있다. 또한, Kubernetes에서는 업데이트가 버전 관리되고 모든 배포 업데이트를 이전 (안정적인) 버전으로 되돌릴 수 있다.

도 7은 일실시예에 따른 K8s 대쉬보드(700)의 화면을 나타내는 도면이다.

대쉬보드(700)는 웹 기반 Kubernetes 사용자 인터페이스로서, 대쉬보드(700)를 사용하여 Kubernetes 클러스터에 컨테이너화된 응용 프로그램을 배포하고, 컨테이너 화된 응용 프로그램의 문제를 해결할 수 있다.

또한, 대쉬보드(700)를 통해 수행자 리소스와 함께 클러스터 자체를 관리 할 수 있다. 뿐만 아니라, 대쉬보드(700)를 사용하여 클러스터에서 실행중인 응용 프로그램의 개요를 얻거나 개별 Kubernetes 자원(예 : 배포, 작업, DaemonSets 등)을 만들거나 수정할 수 있다. 예를 들어 배포 마법사를 사용하여 배포를 확장하거나, 롤링 업데이트를 시작하거나, 포드를 다시 시작하거나, 새 응용 프로그램을 배포 할 수 있다.

도 8은 일실시예에 따른 K8s 네트워크 구성도(800)를 설명하는 도면이다.

K8s 네트워크 구성도(800)를 살펴보면, 도커 데몬이 실행되면 호스트 머신에　docker0　(가상 네트워크 브릿지)가 생성될 수 있다. 도커 컨테이너를 실행하면 해당 컨테이너를 위한　veth　(가상 네트워크 장치) pair　가 생성되고, 생성된　veth　pair의 한쪽 끝은 컨테이너 안으로 격리되어　eth0로 이름이 바뀔 수 있다. 다만, 이는 컨테이너 안에서만 보여진다.

한편, 다른 쪽 끝은 호스트 머신에　vethXXXX　이름으로 존재하며　docker0　브릿지에 연결될 수 있다. 같은 호스트 머신에서 실행되는 컨테이너들은　docker0　브릿지를 매개로 서로 연결이 가능하다.

K8s 네트워크 구성도(800)에서는 K8s의 네트워크 아키텍처에서 K8s 클라이언트가 컨테이너 Nginx-0에서 172.1.0.7 ping을 실행하여 pong이 되는 과정을 쉽게 알아볼 수 있다.

각 포드에는 고유 한 IP 주소가 할당된다.

이때, 포드의 모든 컨테이너는 IP 주소 및 네트워크 포트를 포함하여 네트워크 네임 스페이스를 공유할 수 있다.

포드 안에 있는 컨테이너는 로컬 호스트를 사용하여 서로 통신 할 수 있다. 포드의 컨테이너가 포드 외부의 엔티티와 통신하는 경우 포트와 같은 공유 네트워크 리소스를 사용하는 방법을 조정할 수 있다.

K8s 네트워크 구성도(800)에서 도커는 컨테이너 기반 가상화 도구이다. 기존에 사용하던 가상 머신(VM)은 사용하기 위해서 항상 OS를 설치해야 했고, 이미지 안에 OS가 포함되어 있기 때문에 용량이 매우 크고 속도도 느리다. 이에 비해 도커는 반가상화보다 더 경량화된 방식을 사용할 수 있다.

도커는 OS 전체를 가상화하지 않고 컨테이너라는 리눅스 커널 레벨에서 제공하는 격리된 가상 공간을 사용한다. 게스트 OS를 설치하지 않기 때문에 호스트와 속도 차이도 거의 없으며 기존의 VM에 비해서는 월등한 속도로 동작한다.

도커는 리눅스 컨테이너를 기반으로 이미지를 편리하게 관리하고 배포할 수 있다. 또한, 도커를 사용할 수 있는 환경만 있다면 어플리케이션에 대한 이미지를 pull 받아서 바로 사용할 수 있다. 이는 악성코드 분석 등의 보안 분석 어플리케이션에도 해당되는데, 이런 이유로 도커는 악성코드 분석에 있어서 큰 장점을 지닌다. 또한 도커 이미지에 실행을 위한 구성들과 종속관계가 포함 되어 있기 때문에 사용자가 직접 패키지를 인스톨하고 트러블슈팅 할 필요가 없다.

도커 이미지(Image)는 필요한 프로그램, 라이브러리, 소스 등을 설치한 뒤에 이를 파일로 만든 것이다. 이렇게 만든 이미지를 레파지토리에 올리고, 레파지토리에 올라와 있는 다른 이미지를 받을 수도 있다. 이렇게 받은 이미지를 도커에서 실행시킨 뒤 사용할 수 있다.

이 때 이미지가 실행된 상태가　컨테이너(Container)이며, 이미지를 여러 번 실행시키면 하나의 여러 개의 컨테이너가 만들어질 수 있다.

운영체제로 본다면 이미지는 일종의 실행파일, 컨테이너는 프로세스와 유사한 개념으로 해석될 수 있다.

결국, 본 발명을 활용하면 사용자를 이해하고 적절한 도움을 주는 동반자 관점에서 다양한 입력을 수집하여 학습하는 적응형 기계학습 기반 자율지능 디지털 동반자 프로젝트를 제공할 수 있다.

또한, 디지털 동반자 통합시스템의 무정지 운영을 위한 스토리지 및 컴퓨팅, 모듈 분산 환경구성, 통합관리시스템 및 모니터링/디버깅 기술을 제공할 수 있다.

또한, 여러 호스트 노드를 묶어 클러스터를 구성하여 컨테이너를 적절한 위치에 배포하고(auto-placement) 컨테이너가 동작하지 않으면 자동으로 복구하며(auto-restart), 필요에 따라 컨테이너를 매끄럽게 추가(scaling), 복제(replication), 업데이트(rolling update), 롤백(rollback) 할 수 있다.

이상에서 설명된 장치는 하드웨어 구성요소, 소프트웨어 구성요소, 및/또는 하드웨어 구성요소 및 소프트웨어 구성요소의 조합으로 구현될 수 있다. 예를 들어, 실시예들에서 설명된 장치 및 구성요소는, 예를 들어, 프로세서, 콘트롤러, ALU(arithmetic logic unit), 디지털 신호 프로세서(digital signal processor), 마이크로컴퓨터, FPA(field programmable array), PLU(programmable logic unit), 마이크로프로세서, 또는 명령(instruction)을 실행하고 응답할 수 있는 다른 어떠한 장치와 같이, 하나 이상의 범용 컴퓨터 또는 특수 목적 컴퓨터를 이용하여 구현될 수 있다. 처리 장치는 운영 체제(OS) 및 상기 운영 체제 상에서 수행되는 하나 이상의 소프트웨어 애플리케이션을 수행할 수 있다. 또한, 처리 장치는 소프트웨어의 실행에 응답하여, 데이터를 접근, 저장, 조작, 처리 및 생성할 수도 있다. 이해의 편의를 위하여, 처리 장치는 하나가 사용되는 것으로 설명된 경우도 있지만, 해당 기술분야에서 통상의 지식을 가진 자는, 처리 장치가 복수 개의 처리 요소(processing element) 및/또는 복수 유형의 처리 요소를 포함할 수 있음을 알 수 있다. 예를 들어, 처리 장치는 복수 개의 프로세서 또는 하나의 프로세서 및 하나의 콘트롤러를 포함할 수 있다. 또한, 병렬 프로세서(parallel processor)와 같은, 다른 처리 구성(processing configuration)도 가능하다.

소프트웨어는 컴퓨터 프로그램(computer program), 코드(code), 명령(instruction), 또는 이들 중 하나 이상의 조합을 포함할 수 있으며, 원하는 대로 동작하도록 처리 장치를 구성하거나 독립적으로 또는 결합적으로(collectively) 처리 장치를 명령할 수 있다. 소프트웨어 및/또는 데이터는, 처리 장치에 의하여 해석되거나 처리 장치에 명령 또는 데이터를 제공하기 위하여, 어떤 유형의 기계, 구성요소(component), 물리적 장치, 가상 장치(virtual equipment), 컴퓨터 저장 매체 또는 장치, 또는 전송되는 신호 파(signal wave)에 영구적으로, 또는 일시적으로 구체화(embody)될 수 있다. 소프트웨어는 네트워크로 연결된 컴퓨터 시스템 상에 분산되어서, 분산된 방법으로 저장되거나 실행될 수도 있다. 소프트웨어 및 데이터는 하나 이상의 컴퓨터 판독 가능 기록 매체에 저장될 수 있다.

실시예에 따른 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체에 기록되는 프로그램 명령은 실시예를 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다. 상기된 하드웨어 장치는 실시예의 동작을 수행하기 위해 하나 이상의 소프트웨어 모듈로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.

이상과 같이 실시예들이 비록 한정된 도면에 의해 설명되었으나, 해당 기술분야에서 통상의 지식을 가진 자라면 상기의 기재로부터 다양한 수정 및 변형이 가능하다. 예를 들어, 설명된 기술들이 설명된 방법과 다른 순서로 수행되거나, 및/또는 설명된 시스템, 구조, 장치, 회로 등의 구성요소들이 설명된 방법과 다른 형태로 결합 또는 조합되거나, 다른 구성요소 또는 균등물에 의하여 대치되거나 치환되더라도 적절한 결과가 달성될 수 있다.

그러므로, 다른 구현들, 다른 실시예들 및 특허청구범위와 균등한 것들도 후술하는 특허청구범위의 범위에 속한다.

Claims (3)

1. 외부 기기와의 연결을 위한 라우팅 처리부;
   상기 외부기기로부터의 복수의 입력을 수집하여 기계 학습하고, 무정지 운영을 위한 스토리지 및 컴퓨팅, 모듈 분산 환경구성, 통합관리시스템 및 모니터링 및 디버깅 기술을 제공하되, 복수의 호스트 노드를 그룹핑하여 클러스터를 구성하고, 상기 구성된 클러스터를 컨테이너가 요구되는 위치에 배포(auto-placement)하며, 상기 컨테이너가 동작하지 않는 경우 자동으로 복구되도록 제어하고(auto-restart), 시스템 요구에 따라 컨테이너를 추가(scaling), 복제(replication), 업데이트(rolling update), 및 롤백(rollback) 하는 컨테이너 오케스트레이션 툴을 제어하는 컨테이너 오케스트레이션 툴 처리부; 및
   상기 구성된 클러스터를 이용해서 통합관리 모니터링을 위한 서비스를 제공하는 서비스 처리부
   를 포함하는 분산 지능모듈의 통합관리 시스템.
2. 제1항에 있어서,
   상기 컨테이너 오케스트레이션 툴은 하나의 마스터(master)와 복수 개의 노드를 포함하고,
   상기 마스터를 이용해서 개발자로부터의 명령을 수집하고, 상기 수집된 명령을 노드를 이용해서 관리하며, 상기 노드를 이용해서 접속되는 사용자에게 서비스를 제공하며,
   상기 마스터는 작업을 위한 API 서버, 상태(state)를 관리하기 위한 분산저장소, 분산키 저장소(etcd), 스케줄러(scheduler), 콘트롤러 매니져(controller manager)를 포함하고, 상기 노드는 상기 마스터와 통신하는 kubelet과 외부의 요청을 처리하는 kube-proxy, 및 컨테이너(container) 리소스 모니터링을 위한 cAdviser를 포함하고,
   상기 컨테이너 오케스트레이션 툴은 클러스터에서 실행중인 프로세서인 포드(POD)를 이용해서 애플리케이션 컨테이너 스토리지 리소스, 고유 한 네트워크 IP 및 컨테이너 실행 방법을 관리하는 옵션을 캡슐화하는 것을 특징으로 하는 분산 지능모듈의 통합관리 시스템.
3. 제1항에 있어서,
   상기 컨테이너 오케스트레이션 툴 처리부는,
   상기 컨테이너 오케스트레이션 툴을 이용해서, 호스트 전체에서 컨테이너를 오케스트레이션 하되, 하드웨어를 활용하여 엔터프라이즈 앱을 실행하는데 필요한 리소스를 제공하고, 애플리케이션 배포 및 업데이트를 제어하거나 자동화하며, 장착된 스토리지를 이용하여 스테이트풀(stateful) 앱을 실행하고, 컨테이너화된 애플리케이션과 해당 리소스를 확장시키며, 자동 배치, 자동 재시작, 자동 복제 및 자동 확장을 사용해 앱 상태를 확인하거나 셀프 복구를 수행하며,
   조건과 제약사항을 고려하여 컨테이너를 자동으로 배치, 반응이 없는 컨테이너를 재시작 하며, CPU 사용율을 기준으로 컨테이너를 확장하거나 축소하고, IP 주소와 DNS을 이용해 검색, 로드밸런싱을 수행하는 분산 지능모듈의 통합관리 시스템.

Images