KR20220091487A - 분산형 에지 클라우드 컴퓨팅을 위한 방법 및 시스템 - Google Patents

분산형 에지 클라우드 컴퓨팅을 위한 방법 및 시스템 Download PDF

Info

Publication number
KR20220091487A
KR20220091487A KR1020227014140A KR20227014140A KR20220091487A KR 20220091487 A KR20220091487 A KR 20220091487A KR 1020227014140 A KR1020227014140 A KR 1020227014140A KR 20227014140 A KR20227014140 A KR 20227014140A KR 20220091487 A KR20220091487 A KR 20220091487A
Authority
KR
South Korea
Prior art keywords
cloud computing
edge
computing device
edge cloud
microservices
Prior art date
Application number
KR1020227014140A
Other languages
English (en)
Inventor
시아바시 엠. 알라무티
페이 아르주만디
마이클 버거
Original Assignee
미믹 테크놀러지 아이엔씨.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US16/841,380 external-priority patent/US20200322225A1/en
Application filed by 미믹 테크놀러지 아이엔씨. filed Critical 미믹 테크놀러지 아이엔씨.
Publication of KR20220091487A publication Critical patent/KR20220091487A/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5055—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering software capabilities, i.e. software resources associated or available to the machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5072—Grid computing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/509—Offload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1859—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast adapted to provide push services, e.g. data channels
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

에지 클라우드 컴퓨팅 기기의 실시예가 개시된다. 일 실시예에서, 에지 클라우드 컴퓨팅 기기는, 상기 에지 클라우드 컴퓨팅 기기에서 실행 중인 애플리케이션으로부터 요청을 수신하고, 수신된 요청을 서비스하는 데 필요한 하나 이상의 마이크로서비스의 유형을 결정하도록 구성된 에지 노드 활성화 모듈을 포함한다. 상기 에지 노드 활성화 모듈은 결정된 유형이 상기 에지 클라우드 컴퓨팅 기기에서 국부적으로 호스팅되는 하나 이상의 마이크로서비스에 대응하는 경우 상기 요청을 상기 에지 클라우드 컴퓨팅 기기에서 국부적으로 처리하도록 구성된다.

Description

분산형 에지 클라우드 컴퓨팅을 위한 방법 및 시스템
본 개시는 일반적으로 클라우드 컴퓨팅에 관한 것이다. 특히, 본 개시는 분산형 에지 클라우드 컴퓨팅(distributed edge cloud computing)을 위한 방법 및 시스템에 관한 것이다.
일반적으로, 가장 인기 있는 소비자 및 기업 애플리케이션과 솔루션 중 일부는 일반적으로 "클라우드(cloud)"라고 하는 데이터 센터에서 호스팅된다. 클라우드 컴퓨팅은 Facebook®, YouTube®, Instagram®, DropBox® 등과 같은 애플리케이션을 가능하게 하는 데 필수적이었다. 기본 아키텍처는 특정 노드 또는 컴퓨팅 기기가 "서버" 역할을 하고 다른 노드 또는 컴퓨팅 기기는 "클라이언트" 역할을 한다. 오늘날 대다수의 컴퓨팅 기기 또는 노드는 대부분의 서버가 전 세계에 흩어져 있는 서버 팜(server farm)으로 구성된 데이터 센터에 있는 클라이언트-서버 모드로 동작한다. 이러한 고정된 계층적 클라이언트-서버 아키텍처는 원격 서버에서 다수의 클라이언트 기기로 콘텐츠 및 정보에의 액세스를 제공하는 애플리케이션을 호스팅하는 데 효율적일 수 있다. 보통, 솔루션의 백엔드(solutions' backend)는 컴퓨팅 집약적 태스크(compute intensive task)를 처리하는 서버에서 호스팅되고 솔루션의 클라이언트 애플리케이션 소프트웨어(프론트엔드(frontend))는 커맨드 입력, 콘텐츠 캐싱 및 최종 사용자를 위한 정보 렌더링과 같은, 더 간단한 기능에 사용되는 "에지 기기"에서 호스팅된다.
이 아키텍처의 장점 중 하나는 가상화 및 오케스트레이션(virtualization and orchestration) 기술의 도움으로 많은 애플리케이션 간에 공유되는 일반 서버에 (컴퓨팅 및/또는 저장 집약적) 애플리케이션을 빠르고 저렴하게 배치할 수 있다는 것이다. 그러나 지난 10년 동안, 계층적 클라이언트-서버 아키텍처를 덜 효율적으로 만드는 다양한 경향이 목격되었다. 현재의 계층적 아키텍처 구조에 있어 중앙 클라우드 자원과 네트워크 연결성(network connectivity)은 미래 성장의 잠재적인 장애물(bottleneck)이다. 수천억 대의 클라이언트 기기에서 수천만 대의 중앙 집중식 클라우드 서버로 데이터를 전송하는 것은 대역폭과 에너지의 낭비로 이어지고 심각한 사회적, 경제적 영향을 미친다.
중앙 클라우드 아키텍처(central cloud architecture)의 또 다른 단점은 서버에 저장되거나 서버에서 처리되는 애플리케이션과 데이터에 액세스할 수 있는 클라우드 서비스 제공자에 개발자가 의존한다는 것이다. 결과적으로, 오늘날, 소수의 매우 큰 기업이 대다수의 소비자 및 기업 데이터를 통제한다. 또한, 모든 정교한 보안 대책에도 불구하고, 제3자의 자원에 데이터를 저장하고 애플리케이션을 호스팅하면 정보 소유자는 여러 위험에 노출된다. 클라우드 자원은 수백만 명의 개발자와 애플리케이션 서비스 제공자가 쉽게 액세스할 수 있도록 설계되어 취약성과 보안 허점이 증가하고 있다. 어떤 경우에는 이로 인해 소비자 및 기업 데이터 데이터 프라이버시(data privacy, 개인 정보 보호) 및 보안이 심하게 남용되었다.
적어도 위에서 강조된 과제 및 단점을 해결하기 위해 효과적이고 실현 가능한 접근법을 구현하는 시스템 및 방법이 개시된다. 일 실시예에서, 시스템은 임의의 컴퓨팅 기기 또는 에지 노드를 클라우드 서버로 전환함으로써 클라우드의 탈집중화(decentralization)를 구현한다. 에지 컴퓨팅 기기를 클라우드 서버로 전환함으로써, 중앙 호스팅 서비스가 많은 애플리케이션에 필요하지 않기 때문에 디지털 중개인 및 제3자 신뢰 요소의 역할을 줄이는 것이 가능하다. 이러한 방식으로, 현재 "중앙 클라우드" 패브릭보다 잠재적으로 수십 배 더 큰 물리적 "에지 클라우드 패브릭(edge cloud fabric)"이 생성된다.
에지 클라우드 컴퓨팅 기기의 실시예가 개시된다. 일 실시예에서, 상기 에지 클라우드 컴퓨팅 기기는, 상기 에지 클라우드 컴퓨팅 기기에서 실행 중인 애플리케이션으로부터 요청을 수신하고, 수신된 요청을 서비스하는 데 필요한 하나 이상의 마이크로서비스의 유형을 결정하도록 구성된 에지 노드 활성화 모듈(edge node activation module)을 포함한다. 상기 에지 노드 활성화 모듈은 추가로, 결정된 유형이 상기 에지 클라우드 컴퓨팅 기기에서 국부적으로 호스팅되는(locally hosted) 하나 이상의 마이크로서비스에 대응하는 경우 상기 요청을 상기 에지 클라우드 컴퓨팅 기기에서 국부적으로 처리하도록 구성된다. 일 실시예에서, 상기 에지 노드 활성화 모듈은 추가로, 상기 국부적으로 호스팅되는 하나 이상의 마이크로서비스를 실행하기 위한 마이크로서비스 런타임 환경(microservice runtime environment)을 제공하도록 구성된다. 일부 가능한 실시예에서, 상기 에지 노드 활성화 모듈은 추가로, 상기 국부적으로 호스팅되는 하나 이상의 마이크로서비스에 요청을 전송하기 위한 국부적으로 호스팅되는 API 게이트웨이를 제공하도록 구성된다. 상기 하나 이상의 마이크로서비스는 상기 요청을 서비스하고 상기 애플리케이션에 대한 응답을 돌려주도록 구성된다.
일 실시예에서, 상기 에지 노드 활성화 모듈은 추가로, 상기 수신된 요청을 서비스하는 데 필요한, 상기 결정된 유형의 하나 이상의 마이크로서비스가 중앙 클라우드 컴퓨팅 기기에서 전역적으로 호스팅되는(globally hosted) 하나 이상의 마이크로서비스에 대응하는 경우, 상기 애플리케이션으로부터 수신된 요청에 대응하는 http/https 요청을 상기 중앙 클라우드 컴퓨팅 기기에서 호스팅되는 API 게이트웨이에 전송하도록 구성된다. 상기 에지 노드 활성화 모듈은 추가로, 상기 중앙 클라우드 컴퓨팅 기기에서 호스팅되는 API 게이트웨이로부터 상기 http/https 요청에 대한 http/https 응답을 수신하도록 구성되고, 상기 http/https 요청은 상기 중앙 클라우드 컴퓨팅 기기에서 전역적으로 호스팅되는 하나 이상의 마이크로서비스에 의해 서비스된다.
일 실시예에서, 상기 에지 노드 활성화 모듈은 추가로, 상기 http/https 요청을 상기 중앙 클라우드 컴퓨팅 기기에서 호스팅되는 API 게이트웨이에 전송하기 위한 국부적으로 호스팅되는 API 게이트웨이를 제공하도록 구성된다. 일 실시예에서, 상기 에지 노드 활성화 모듈은 추가로, 상기 수신된 요청을 서비스하는 데 필요한, 상기 결정된 유형의 하나 이상의 마이크로서비스가 다른 에지 클라우드 컴퓨팅 기기에서 호스팅되는 하나 이상의 마이크로서비스에 대응하는 경우, 상기 요청을 상기 다른 에지 클라우드 컴퓨팅 기기에서 호스팅되는 하나 이상의 마이크로서비스에 직접 전송하도록 구성된다. 일 실시예에서, 상기 에지 노드 활성화 모듈은 추가로, 상기 에지 클라우드 컴퓨팅 기기에서 국부적으로 호스팅되는 하나 이상의 마이크로서비스 및 상기 다른 에지 클라우드 컴퓨팅 기기에서 호스팅되는 하나 이상의 마이크로서비스에 대응하는 서비스 메시(sidecar pattern)를 형성하기 위한 사이드카 패턴을 구현하도록 구성된다.
일 실시예에서, 상기 에지 노드 활성화 모듈은 추가로, 제1 파라미터 세트에 기초하여 하나 이상의 다른 에지 클라우드 컴퓨팅 기기를 탐색하여 그 사이에 연결을 확립하고; 하나 이상의 에지 클라우드 컴퓨팅 기기 사이에 확립된 연결과 연관된 상기 국부적으로 호스팅되는 하나 이상의 마이크로서비스를 실행하기 위한 마이크로서비스 런타임 환경을 제공하도록 구성된다.
상기 제1 파라미터 세트는, 상기 하나 이상의 에지 클라우드 컴퓨팅 기기 각각과 연관된 사용자 계정, 상기 하나 이상의 에지 클라우드 컴퓨팅 기기와 연관된 네트워크, 및 상기 하나 이상의 에지 클라우드 컴퓨팅 기기의 근접성(proximity)을 포함한다. 일 실시예에서, 상기 에지 노드 활성화 모듈은 추가로, 상기 하나 이상의 에지 클라우드 컴퓨팅 기기에 의해 지원되는 하나 이상의 마이크로서비스를 탐색하도록 구성된다.
일 실시예에서, 상기 에지 노드 활성화 모듈은 추가로, 상기 하나 이상의 에지 클라우드 컴퓨팅 기기로 하나 이상의 클러스터를 동적으로 형성하고; 마이크로서비스 레벨에서 상기 하나 이상의 에지 클라우드 컴퓨팅 기기와 직접 또는 상기 하나 이상의 클러스터에 걸쳐 다른 에지 클라우드 컴퓨팅 기기를 통해 통신하도록 구성된다. 일 실시예에서, 상기 에지 노드 활성화 모듈은 추가로, 공통의 내장형 웹 서버(common embedded web server)를 통해 하나 이상의 에지 클라우드 컴퓨팅 기기에 상기 국부적으로 호스팅되는 하나 이상의 마이크로서비스 서비스를 노출하도록 구성된다. 일 실시예에서, 상기 에지 노드 활성화 모듈은 내부에 내장된 웹서버를 포함하고, 상기 웹서버는 상기 에지 클라우드 컴퓨팅 기기와 연관된 운영 체제를 기반으로 하는 특정 언어를 사용하여 컨테이너 관리(container management) API를 제공하도록 구성된다.
본 명세서에 설명된 다양한 기술을 구현하는 명령어를 갖는 컴퓨팅 기기 및 컴퓨터로 판독 가능한 매체가 또한 개시된다. 예시적인 컴퓨터로 판독 가능한 매체는 프로세서에 의해 실행 가능한, 컴퓨터로 실행 가능한 명령어를 갖는 유형의(tangible), 컴퓨터로 판독 가능한 비일시적(non-transitory) 저장 매체를 포함할 수 있으며, 상기 명령어는 상기 프로세서에 의해 실행될 때, 상기 프로세서로 하여금 본 명세서에 제공된 다양한 방법 및 접근법의 임의의 조합을 수행하게 한다. 예시적인 컴퓨팅 기기는 프로세서, 메모리, 클라이언트 애플리케이션 및/또는 본 명세서에 설명된 방법을 수행하도록 구성된 네트워크 서비스를 포함하는 서버 또는 클라이언트 기기를 포함할 수 있다.
전술한 요약 내용은 설명을 위한 것이며 어떤 식으로든 한정하려는 의도는 아니다. 위에서 설명된 예시적인 측면, 실시예 및 특징에 더하여, 추가적인 측면, 실시예 및 특징은 도면 및 이하의 상세한 설명을 참조함으로써 명백해질 것이다.
도 1은 마이크로서비스(microservice)를 사용하는 예시적인 클라우드 아키텍처(100)를 도시한다.
도 2는 마이크로서비스를 사용하는 클라우드 아키텍처(200)의 다른 예를 보여준다.
도 3은 에지 클라우드 컴퓨팅 네트워크의 예시적인 실시예(300)를 도시한다.
도 4는 일 실시예에 따른 에지 클라우드 아키텍처(400)의 기본적인 구성 요소를 도시한다.
도 5는 일 실시예에 따른 에지 클라우드 컴퓨팅 기기(500)를 도시한다.
도 6은 일 실시예에 따른 예시적인 백엔드 마이크로서비스 분포(600)를 도시한다.
도 7은 일 실시예에 따른 예시적인 에지 클라우드 컴퓨팅 아키텍처(700)를 도시한다.
도 8은 일 실시예에 따른 에지 클라우드 아키텍처(800)에서 동일한 사용자 ID에 속하는 2개의 에지 클라우드 컴퓨팅 기기에 대한 발견, 연결 및 통신의 예시적인 실시예를 도시한다.
도 9는 일 실시예에 따른 사이드카 패턴(sidecar pattern)의 서버리스 마이크로서비스(serverless microservice)를 사용하여 구현된 예시적인 에지 클라우드 아키텍처(900)를 도시한다.
도 10은 일 실시예에 따라 국부 및 전역적으로 호스팅되는 마이크로서비스를 이용하는 애플리케이션을 위한 예시적인 서버리스 마이크로서비스(1000)를 도시한다.
도 11은 클라우드 컴퓨팅 인프라(cloud computing infrastructure)를 제공하는 방법(1100)의 예시적인 실시예를 도시한다.
도 12는 클라우드 컴퓨팅 인프라를 제공하는 방법(1200)의 다른 실시예를 도시한다.
이하의 상세한 설명은 당업자가 본 발명을 실시 및 사용할 수 있도록 제공된다. 설명을 위해, 본 발명의 완전한 이해를 제공하기 위해 특정 세부사항이 제시된다. 그러나 이러한 특정 세부사항은 본 발명을 실시하는 데 필요하지 않다는 것이 당업자에게 명백할 것이다. 특정 애플리케이션에 대한 설명은 대표적인 예로만 제공된다. 바람직한 실시예에 대한 다양한 수정은 당업자에게 용이하게 명백할 것이며, 여기에 정의된 일반적인 원리는 본 발명의 범위를 벗어남이 없이 다른 실시예 및 응용에 적용될 수 있다. 본 발명은 도시된 실시예에 한정되도록 의도되지 않고 여기에 개시된 원리 및 특징과 일치하는 가능한 한 가장 넓은 범위가 부여되어야 한다.
클라우드 컴퓨팅 아키텍처의 최신 진화는 모놀리식 백엔드 솔루션을 API 게이트웨이 뒤에 있을 때 동적으로 인스턴스화되는(서버리스) 마이크로서비스의 모음(collection)으로 분해하는 마이크로서비스로의 이동이다. 이러한 진화는 특히 클라우드 컴퓨팅 환경의 맥락에서 마이크로서비스 통신 및 클러스터 관리에 대해 마이크로서비스에 새로운 복잡성을 초래한다. 예를 들어, 도 1은 마이크로서비스를 사용하는 예시적인 클라우드 아키텍처(100)를 도시한다. 도시된 바와 같이, 컴퓨팅 기기(클라이언트 기기 또는 노드)(102)는 API 게이트웨이(108)에 http/https 요청(106)을 전송하는 클라이언트 애플리케이션(104)을 실행한다. API 게이트웨이(108)는 중앙 클라우드 컴퓨팅 기기(114)에서 호스팅되는 클라우드 벡엔트(112)로부터의 http/https 응답(120)을 전송한다. 또한, 클라우드 백엔드(112)에서 호스팅되는 것은 전역적으로 호스팅되는 마이크로서비스(116, 118, 120)의 모음이다. http/https 응답(110)은 http/https 요청(106)에 대한 응답으로 기동되었던(launched) 마이크로서비스(예: 120) 중 하나에 대응할 수 있다. 이러한 아키텍처에는 대개 컴퓨팅 기기(예: 102)상의 클라이언트 애플리케이션(예: 104)과 대개 일련의 마이크로서비스(예: 116, 118, 120)로 구성되는 솔루션의 백엔드 호스팅을 지원하는 중앙 클라우드 기능의 모음이 포함된다. API 게이트웨이(예: 108)를 통해 연결할 수 있는 마이크로서비스(예: 116, 118, 120). 이러한 시나리오에서 모든 http 요청은 일반적인 서버-클라이언트 아키텍처의 경우와 같이 "클라이언트 기기"에서 중앙 클라우드의 서버(예: 114)로 전송된다.
클라이언트 간(client to client) 통신을 위한 클라우드 아키텍처(200)의 또 다른 예가 도 2에 도시되어 있다. 클라이언트 애플리케이션(204)을 실행하는 제1 클라이언트 기기(202)가 클라이언트 애플리케이션(232)을 실행하는 제2 클라이언트 기기(230)에 정보를 전송하기를 원하는 시나리오를 고려한다. 클라이언트 애플리케이션(204)은 중앙 클라우드(212)에서 호스팅되는 API 게이트웨이(208)에서 끝나는 http 요청(206)을 전송한다. https 요청(206)은 요청(230)에 의해 응답으로 시작되는 중앙 클라우드(212)에서 호스팅되는 적절한 마이크로서비스(예: 216, 218, 220)에 대응한다. 시작된 마이크로서비스(예: 216)는 트리거(214)를 푸시 알림 서비스(push notification service)(222)로 전송하여 제1 클라이언트 기기(228)에서 제2 클라이언트 기기(230)로 이용 가능한 정보를 전달한다. 다음으로, 제2 클라이언트 기기(230)에서 실행 중인 클라이언트 애플리케이션(232)은 중앙 클라우드에서 호스팅되는 마이크로서비스(예: 216)에 의해 다시 서비스되는 API 게이트웨이(208)에 대한 (get info) 요청(224)으로 응답한다. 다음으로, 서비스를 제공하는(servicing) 마이크로서비스(예: 216)는 제1 클라이언트 기기(226)에서 제2 클라이언트 기기(230)로 정보를 전송한다. 따라서, 두 클라이언트 기기(제1 클라이언트 기기와 제2 클라이언트 기기)가 가까인 근접해 있고 동일한 국부 네트워크에 있더라도, 모든 통신 및 데이터는 100마일 떨어져 있을 수 있는 데이터 센터의 서버를 통과해야 할 것이고, 이는 차선책이고 바람직하지 않을 수 있다.
이 문제를 해결하기 위한 효과적이고 실현 가능한 접근법은 임의의 주어진 컴퓨팅 기기가 클라우드 서버로서의 역할을 할 수 있게 하는 것이다. 컴퓨팅 기기가 클라우드 서버로서의 역할을 할 수 있게 하면 애플리케이션에 필요하지 않은 타사 클라우드 서비스에 대한 의존도를 잠재적으로 줄일 수 있다. 또한, 이 접근법은 마이크로서비스를 백엔드에서 컴퓨팅 기기(현재는 서버로서의 역할을 함)로 동적으로 이동함으로써 마이크로서비스 기반 솔루션을 보다 유연하게 만들 수도 있다. 중앙 클라우드에서 수행되는 많은 기능은 서버로서 "역할"을 하거나 "구성"된 에지 기기에서 수행될 수 있다. 컴퓨팅 기기가 서버로서의 역할을 하도록 구성되면, 기존 중앙 클라우드보다 수십 배 더 큰 탈집중화된 에지 클라우드 컴퓨팅(아키텍처)이 제공될 수 있다. 이러한 아키텍처에는 다음을 포함하는 수많은 이점이 있다: 클라우드 호스팅 비용 감소, 통신 대역폭 및 네트워크 효율 감소, 에너지 소비 및 탄소 배출 감소, 대기 시간(latency) 감소, 애플리케이션 개발 시간 감소, 마이크로서비스 트렌드 수용의 이점, 소비자와 기업이 자신들의 데이터를 더 잘 통제할 수 있는 데이터 프라이버시 및 프로비저닝 강화.
일 실시예에서, 이를을 달성하기 위한 첫 번째 단계는 서버가 데이터 센터에만 존재할 수 있다는 제약을 없애는 것이다. 이것은 오늘날 인터넷에 대한 지배적인 고정 및 계층적 클라이언트-서버 인프라를 정의하는 근본적인 제약이다. 임의의 컴퓨팅 기기가 애플리케이션의 실시간 요구에 기초하여 클라이언트 및/또는 서버로서의 역할을 할 수 있게 함으로써 실용적인 접근법을 따르는 대안적인 아키텍처가 여기에 개시된다.
앞서 언급했듯이, 기존의 계층적 클라이언트-서버 아키텍처를 덜 효율적으로 만드는 다양한 경향이 목격되었다. 예를 들어, 첫 번째 추세는 모든 사물에 컴퓨팅 기기와 내장형 컴퓨팅(embedded computing)이 폭발적으로 증가하고, 에지 기기의 기능이 증대하는 것이다. 예를 들어, 10년 전의 강력한 서버에서보다 오늘날의 스마트폰에서 이용할 수 있는 컴퓨팅 능력(computing power), 메모리 및 스토리지가 더 많다. 예를 들어, 두 번째 추세는 이러한 (에지) 기기에서 생성되는 엄청난 양의 데이터이다. 모바일 기기라고도 하는 이동 기기상에 소셜 미디어가 출현하면서, 클라우드 내의 중앙 서버에서 호스팅되는 주요 스튜디오 및 방송사의 프리미엄 콘텐츠보다 훨씬 더 많은 개인 멀티미디어 콘텐츠(사진, 비디오, 센서 데이터 등)가 기기에서 생성된다. 오늘날, (에지) 기기에서 생성되는 대부분의 데이터는 처리 및 공유를 용이하게 하기 위해 중앙 클라우드로 다시 전송된다. 세 번째 추세는 볼륨 또는 지리적 수요에 엄밀하게 맞는 확장성을 가진 백엔드 솔루션을 훨씬 더 동적으로(서버리스) 만드는 마이크로서비스 모음에서의 솔루션의 분해와 배포의 자동화이다.
일례로서, 현재 가정에는 8천만 대 이상의 Sony PlayStation 4(PS4™) 콘솔이 있다. 이는 6억 개 이상의 프로세서 코어와 약 40,000페타바이트의 스토리지를 나타낸다. 이에 비해, 이는 Amazon Web Services(AWS®) 인프라 전체보다 훨씬 더 큰 컴퓨팅, 스토리지 및 메모리 자원을 종합적으로 나타낸다. 수십억 대의 PC, 셋톱박스, 게임 콘솔, 스트리밍 플레이어, 라우터, 스마트폰, 태블릿, 및 잠재적으로 클라우드 서버 역할을 할 수 있고 집합적으로 기존의 "중앙 클라우드"보다 컴퓨팅 능력이 수십 배 더 클 수 있는 기타 컴퓨팅 기기가 있다. 본 개시는 수십억 개의 에지 클라우드 컴퓨팅 기기(또는 노드 또는 에지 노드)로 구성된 클라우드 패브릭을 생성하기 위한 시스템 및 방법을 제공한다.
탈집중화된 클라우드 아키텍처의 개시된 실시예는 전용 하드웨어를 가진 새로운 네트워크 노드를 생성할 필요가 없다. 그 대신, 개시된 아키텍처는 PC, 태블릿, 셋톱박스(set-top-boxe, STB) 또는 홈 라우터와 같은 기존 컴퓨팅 기기가 가장 그럴듯할 때 클라우드 네트워크의 에지에서 클라우드 서버 노드로서의 역할을 할 수 있도록 한다.
개시된 접근법은 이러한 기기의 저 레벨 설계에 대해 변경을 요구하지 않는다. 하드웨어나 기존 기기의 OS 커널을 변경하지 않고 기존 운영 체제 위에서 실행되는 다운로드 가능한 애플리케이션(예: 에지 노드 활성화 모듈)만 있으면 된다. 개발자가 기존 클라우드 인프라를 탈집중화할 수 있는 강력한 무기고를 제공하는 것 외에도, 공개된 아키텍처는 소비자에게 그들의 개인 데이터에 대한 더 많은 제어 권한을 제공한다. 또한, 무엇보다도, 개시된 접근법은 애플리케이션의 전달 및 호스팅 비용을 최소화하고, 네트워크 성능을 향상시키고 대기 시간을 최소화한다.
에지 클라우드 컴퓨팅 플랫폼의 실시예가 개시된다. 개시된 클라우드 플랫폼은 클라우드 컴퓨팅의 차세대 혁명으로서 탈집중화를 가속화한다. 클라우드 탈집중화의 주요 단계는 서버가 데이터 센터에만 존재할 수 있다는 제약을 없애는 것이다. 이것은 오늘날 인터넷에 대해 지배적인 클라이언트-서버 인프라를 정의하는 근본적인 제약이다. 본 개시는 애플리케이션의 실시간 요구에 기초하여 임의의 컴퓨팅 기기가 클라이언트 또는 서버로서의 역할을 할 수 있게 함으로써 이를 달성하기 위한 대안적 아키텍처/플랫폼 및 실용적인 접근법을 제공한다. 또한, 에지 노드 활성화 모듈 및 하나 이상의 백엔드 서비스를 사용하여 에지 클라우드 패브릭을 생성하기 위한 클라우드 플랫폼이 개시된다.
개시된 아키텍처 및 플랫폼의 이점과 장점으로는 클라우드 호스팅 비용 감소, 통신 대역폭 감소, 네트워크 효율 증가, 에너지 소비 및 탄소 배출 감소, 대기 시간 감소, 개인정보보호 증가 및 소비자와 기업 데이터에 대한 데이터 프라이버시 및 더 나은 제어를 포함한다.
통신 네트워크에서 에지 클라우드 컴퓨팅 인프라를 제공하는 방법의 실시예가 개시된다. 통신 네트워크는 적어도 하나의 서버 컴퓨팅 기기와 통신하는 하나 이상의 에지 클라우드 컴퓨팅 기기를 포함한다. 일 실시예에서, 이 방법은 제1 에지 클라우드 컴퓨팅 기기가, 제1 에지 클라우드 컴퓨팅 기기에서 실행 중인 애플리케이션으로부터의 요청에 대응하는 하나 이상의 마이크로서비스의 유형을 결정하는 단계를 포함한다. 이 방법은 제1 에지 클라우드 컴퓨팅 기기가, 결정된 유형이 제1 에지 클라우드 컴퓨팅 기기에서 국부적으로 호스팅되는 하나 이상의 마이크로서비스에 대응하는 경우 제1 에지 클라우드 컴퓨팅 기기에서 요청을 국부적으로 처리하는 단계를 더 포함한다. 이 방법은 제1 에지 클라우드 컴퓨팅 기기가, 국부적으로 호스팅되는 하나 이상의 마이크로서비스를 실행하기 위한 마이크로서비스 런타임 환경을 제공하는 단계를 더 포함한다.
일 실시예에서, 이 방법은, 제1 에지 클라우드 컴퓨팅 기기가, 국부적으로 호스팅되는 하나 이상의 마이크로서비스에 요청을 전송하기 위한 국부적으로 호스팅되는 API 게이트웨이를 제공하는 단계를 더 포함한다. 일 실시예에서, 이 방법은, 제1 에지 클라우드 컴퓨팅 기기가, 애플리케이션으로부터의 요청에 대응하는 http/https 요청을, 결정된 유형의 하나 이상의 마이크로서비스가 중앙 클라우드 컴퓨팅 기기에서 전역적으로 호스팅되는 하나 이상의 마이크로서비스에 대응하는 경우 중앙 클라우드 컴퓨팅 기기에서 호스팅되는 API 게이트웨이에 전송하는 단계를 더 포함한다. 일 실시예에서, 이 방법은, 제1 에지 클라우드 컴퓨팅 기기가 http/https 요청에 대한 http/https 응답을, 중앙 클라우드 컴퓨팅 기기에서 호스팅되는 API 게이트웨이로부터 수신하는 단계를 더 포함하고, http/https 요청은 중앙 클라우드 컴퓨팅 기기에서 전역적으로 호스팅되는 하나 이상의 마이크로서비스에 의해 서비스된다. 일 실시예에서, 이 방법은, 제1 에지 클라우드 컴퓨팅 기기가 http/https 요청을 중앙 클라우드 컴퓨팅 기기에서 호스팅되는 API 게이트웨이로 전송하기 위한 국부적으로 호스팅되는 API 게이트웨이를 제공하는 단계를 더 포함한다.
일 실시예에서, 이 방법은 제1 에지 클라우드 컴퓨팅 기기가, 애플리케이션으로부터의 요청의 결정된 유형이 제2 에지 클라우드 컴퓨터 기기에 대한 데이터 요청에 대응하는 경우 데이터 요청을, 국부적으로 호스팅되는 하나 이상의 마이크로서비스에서 제2 에지 클라우드 컴퓨터 기기에서 호스팅되는 하나 이상의 마이크로서비스로 직접 전송하는 단계를 더 포함한다. 또 다른 실시예에서, 이 방법은 제1 에지 클라우드 컴퓨팅 기기가, 제1 에지 클라우드 컴퓨팅 기기에서 실행 중인 애플리케이션을 지원하기 위해 서비스 메시를 형성하기 위한 사이드카 패턴을 제공하는 단계를 더 포함한다. 이 방법은, 제1 에지 클라우드 컴퓨팅 기기가 공통 내장형 웹 서버를 통해 하나 이상의 에지 클라우드 컴퓨팅 기기에 국부적으로 호스팅되는 하나 이상의 마이크로서비스 서비스를 노출하는 단계를 더 포함한다. 일 실시예에서, 이 방법은, 제1 에지 클라우드 컴퓨팅 기기가 에지 클라우드 컴퓨팅 기기와 연관된 운영 체제를 기반으로 하는 특정 언어를 사용하는 컨테이너 관리 API를 제공하는 단계를 더 포함한다.
일 실시예에서, 상기 방법은, 제1 에지 클라우드 컴퓨팅 기기가 하나 이상의 다른 에지 클라우드 컴퓨팅 기기를 탐색하여 그 사이의 연결을 확립하는 단계; 및 제1 에지 클라우드 컴퓨팅 기기가, 하나 이상의 에지 클라우드 컴퓨팅 기기 사이에 확립된 연결과 연관된 국부적으로 호스팅되는 하나 이상의 마이크로서비스를 실행하기 위한 마이크로서비스 런타임 환경을 제공하는 단계를 더 포함한다. 일 실시예에서, 상기 방법은, 제1 에지 클라우드 컴퓨팅 기기가 탐색된 하나 이상의 다른 에지 클라우드 컴퓨팅 기기에서 호스팅되는 하나 이상의 마이크로서비스를 탐색하는 단계, 및 제1 에지 클라우드 컴퓨팅 기기가, 하나 이상의 에지 클라우드 컴퓨팅 기기에서 국부적으로 호스팅되는 하나 이상의 마이크로서비스와 탐색된 하나 이상의 마이크로서비스 사이에 직접 마이크로서비스 레벨 연결을 확립하는 단계를 더 포함한다. 일 실시예에서, 제1 에지 클라우드 컴퓨팅 기기가 애플리케이션으로부터의 요청을 서비스하는 데 필요한 하나 이상의 마이크로서비스를 로드하고 실행하는 단계를 더 포함한다. 이 방법은 또한 제1 에지 클라우드 컴퓨팅 기기가, 애플리케이션으로부터의 요청이 서비스되었으면 로드된 하나 이상의 마이크로서비스를 중지하는 단계를 더 포함한다.
도 3은 에지 클라우드 컴퓨팅 네트워크(300)의 일 실시예를 도시한다. 기존의 "중앙 클라우드" 모델에서, 더 많은 기기가 추가되거나 더 많은 콘텐츠가 기기에 의해 생성됨에 따라, 데이터 센터에 더 많은 서버를 추가하여 이를 지원해야 한다. 도 3에 도시된 바와 같은 분산형 에지 클라우드 컴퓨팅 네트워크(300)를 사용하여, 에지 기기의 수에 따라 확장되는 클라우드 패브릭이 생성될 수 있다. 이로써 에지 기기 및 에지 기기에 의해 생성되는 콘텐츠의 수가 늘어남에 따른 데이터 센터에서의 추가 서버의 필요성이 감소한다.
진행 중인 설명에서, "에지 기기"는 "노드" 또는 "에지 노드" 또는 "에지 컴퓨팅 기기" 또는 "에지 클라우드 컴퓨팅 기기"로 상호교환적으로 지칭된다. 따라서 에지 클라우드 컴퓨팅 기기의 수가 증가함에 따라 "클라우드" 용량이 증가한다. 또한 대부분의 데이터가 에지에서 생성되기 때문에 애플리케이션에 대한 전송 비용 및 대기 시간이 최소화된다. 개시된 접근법에서, 대부분의 처리는 에지에서 수행되고, 통신은 가능한 한 국부적으로 유지되며, 에지 클라우드 컴퓨팅 기기는 컴퓨팅 및 기타 자원을 협력하고 공유한다. 계속되는 설명을 위해, "중앙 클라우드" 또는 "중앙 클라우드 컴퓨팅 기기"는 중앙 저장 또는 처리가 필요한 많은 애플리케이션에 없어서는 안 될 귀중한 자원으로 남아 있는 데이터 센터 내의 하나 이상의 서버를 말한다. 그러나 제안된 에지 클라우드 플랫폼 및 아키텍처에서, 중앙 클라우드는 더 이상 장애물이나 "필요한" 신뢰 요소가 아니며, 에지 노드에 비례하여 늘어 날 필요가 없다. 데이터 센터 자원은 증가해야 하지만 중앙 처리만의 필요를 수용할 수 있을만한 적절한 속도로 증가해야 할 수 있다. 다른 모든 가능한 태스크와 기능은 오늘날 대부분의 데이터가 생성되는 에지 노드로 이관될 수 있다.
도 3에 도시된 바와 같이, 에지 클라우드 컴퓨팅 네트워크(300)는 랩톱(302), 태블릿 PC(304), 중앙 "클라우드"(306), 자동차 인포테인먼트 시스템(308), 보안 카메라(310), 서버 컴퓨팅 기기(312), 이동 기기(314), 및 게이밍 콘솔(316)과 같은, 복수의 에지 클라우드 컴퓨팅 기기를 포함한다. 예시적인 실시예에서, 각각의 에지 클라우드 컴퓨팅 기기는 에지 클라우드 컴퓨팅 네트워크(300)의 필요에 따라 클라이언트 또는 서버의 역할을 하도록 구성될 수 있다. 또한, 도 3은 에지 클라우드 컴퓨팅 기기 간의 연결 또는 통신 경로를 파선으로 도시한다. 당업자라면 알 수 있는 바와 같이, 아키텍처는 하나 이상의 기기가 항상 "서버"의 역할을 하도록 지정되고 다른 기기가 항상 "클라이언트"의 역할을 하도록 지정되는 기존의 클라이언트-서버 모드를 따르지 않는다.
에지 클라우드 컴퓨팅 네트워크(300)의 제안된 아키텍처에는 제안된 아키텍처를 실현 가능하게 만드는 데 어려울 수 있는 운영 체제 및 네트워크의 단편화(fragmentation)가 존재한다. 예를 들어, 각각의 에지 클라우드 컴퓨팅 기기는 Linux®, android, iOS®, macOS®, Windows®, Fedora™ 등의 여러 변형과 같은, 서로 다른 운영 체제를 사용할 수 있다. 또한, 에지 클라우드 컴퓨팅 기기는 고정형(이더넷, 광섬유, xDSL, DOCSIS®, USB 등), 모바일 WAN(2G, 3G, 4G 등), 무선 LAN(WiFi® 등), 무선 PAN(Bluetooth®, WiGig, ZWave®, ZigBee®, IrDA 등), 및 기계 네트워크(SigFox®, LoRa®, RPMA 등)과 같은, 여러 다른 네트워킹 기술을 사용하여 동작하도록 구성될 수 있다. 이 문제를 해결하기 위해, 제안된 클라우드 아키텍처는 "활성화"될 때 여러 단편화된 운영 체제 및 네트워크 기술 전반에 걸쳐 다른 에지 클라우드 컴퓨팅 기기와 연결, 통신 및 협력하도록 구성된 에지 클라우드 컴퓨팅 기기(예: 314)를 포함된다.
본 개시의 다른 측면에서, 네트워크 자원의 가용성은 에지 클라우드 컴퓨팅 네트워크(300)에서 도전 과제일 수 있다. 따라서, 에지 클라우드 컴퓨팅 기기(예: 312, 314)가 서버로서의 역할을 하면, 이들은 업링크 네트워크 자원을 사용하여 다른 에지 노드와 연결 및 통신할 수 있다. 네트워크 연결성(network connectivity)이 점차 대칭이 되고 있지만, 보통 이용 가능한 업링크 자원보다 다운링크가 더 많다. 예시적인 예로서, 에지 노드에서 중앙 클라우드로 비디오를 포스팅하여 3개의 다른 에지 노드에서 소비하는 것은 근원지에서 목적지 노드로 비디오를 (직접) 스트리밍하는 것과 비교하여 다른 업링크/다운링크 자원이 직접 필요하다. 중앙 집중식 클라우드 네트워크에는 업링크의 인스턴스가 1개 있고 다운링크 인스턴스가 3개 있으며, 제안된 탈중심화된 에지 클라우드 컴퓨팅 네트워크(300)에는 업링크 인스턴스가 세 개 있다(방화벽 뒤에 아무것도 없다고 가정). 따라서 네트워크 자원의 가용성은 분산형 에지 클라우드 플랫폼을 실현하기 위한 중요한 측면이 될 것이다. 이에 대한 해결방안을 "능력주의(meritocracy)" 원칙과 관련하여 설명한다.
본 개시의 또 다른 측면에서, 데이터 센터의 서버와 달리, 대부분의 에지 노드는 본질적으로 비영구적일 수 있다. 특히 배터리로 작동되는 이동 기기에서, 가용성과 신뢰성에 대한 통제가 덜 할 수 있다. 제안된 에지 클라우드 컴퓨팅 아키텍처는 아래에 설명된 "마이크로서비스" 접근법을 통해 이러한 과제를 극복한다. 일 실시예에서, 에지 노드의 비영구적 특성은 영구 노드가 필수적인 특정 애플리케이션을 구축할 때 고려된다. 영구 노드는 항상 다른 협력 에지 노드를 사용하여 프로비저닝할 수 있으며, 최악의 경우, 중앙 클라우드가 사용될 수 있다.
극복해야 할 또 다른 과제는 배포 관리(distribution management)이다. 데이터 센터에서, 배포 관리는 CPU 로드, 메모리 제약 및 IO와 같은, 더 간단한 기준을 기반으로 자원 가용성을 처리한다. 배포 관리의 범위는 솔루션(백엔드)이 실행되고 있는 특정 데이터 센터이다. 에지 클라우드를 사용하면, 배전 관리에 대한 기준이 훨씬 더 다양해지며 전력 가용성 및 소비, 신뢰성 그리고 기기 능력을 포함한다. 후술하는 바와 같이, 에지 클라우드 컴퓨팅 아키텍처를 사용하면, 대부분의 기기가 특정 사용자에게 속하기 때문에, 배포 범위가 네트워크, 근접성 및 계정으로 확장된다.
기존 중앙 클라우드 아키텍처는 정보가 중앙 장소/기기에서 생성 및/또는 그곳에 저장되고 대부분의 에지 노드가 (http를 통해 도달할 수 있는 일련의 전용 서버를 통해) 월드와이드웹으로부터 정보를 수신하는 데 사용되는 경우 효율적일 수 있다. 그러나 소셜 미디어, 사용자 생성형 콘텐츠, 사물 인터넷(internet of things, IoT) 및 기계 생성형 데이터의 급속한 성장으로 인해, 오늘날 대부분의 데이터는 에지 노드에서 생성된다. 따라서 중요한 고려사항 중 하나는 진행 중인 개시에 제안되어 있는 바와 같이 데이터 생성 및 사용에 있어 근본적인 변환에 가장 적합한 아키텍처(들)이다.
탈집중화된 에지 클라우드를 사용하면, "중앙 클라우드"(예: 도 3의 306)를 포함한 모든 노드가 클라우드 서버의 역할을 할 수 있으며 지정된 영구 신뢰 요소가 없다. 에지 노드 또는 에지 클라우드 컴퓨팅 기기는 필요한 경우가 아니면 제3자 신뢰 (중앙) 요소에 의존하지 않고 직접 통신하고, 협력하고, 자원을 공유하도록 구성된다. 이 접근법을 사용하면, 중앙 클라우드 자원은, 예를 들어, 전역적인 스토리지, 아카이빙(archiving), 중앙 집중식 데이터베이스의 업데이트, 중앙 집중식 등록 등이 필요한 경우에만 필요할 때만 사용된다. 에지 노드에 의해 처리될 수 있는 다른 모든 기능은, 예를 들어, 기기 간의 메시징, 또는 기계 간의 제어 신호의 핸드셰이킹, 또는 소규모 클러스터 내의 노드 간의 데이터 송신에 할당될 수 있다.
또한, 소프트웨어 산업의 현재 진행중인 추세는 제안된 탈집중화를 매우 실현 가능하게 만든다. 과거에는 수많은 구성요소로 구성된 소프트웨어 솔루션을 관리하는 복잡성이 단일 솔루션에 이르게 하였다. 그러나 Docker® 및 CoreOS®와 같은 더 가벼운 컨테이너 관리 플랫폼을 향한 가상화 기술의 진화, 온디맨드(on-demand) IT의 소비화(consumerization) 및 풍부한 통신(API)의 용이성은 복잡도를 크게 줄였다. 우수한 소프트웨어 설계 방법은 단일 목적의 잘 정의된 구성요소의 여러 인스턴스의 모음으로 솔루션을 개발하는 것이다.
이러한 방식으로 클라우드 시스템을 설계할 경우의 결과는, 수요 곡선을 엄밀하게 따르는 인프라 자원의 더 세밀한 활용, 복잡한 속성(세션, 테넌시) 설계의 단순화, 데이터 센터 내 또는 데이터 센터 간 컴퓨팅 자원의 더 나은 배포 및 활용, 그리고 애플리케이션 개발 시간을 단축하고 소프트웨어 업그레이드 및 유지관리를 더 용이하게 하기 위해 솔루션의 클라이언트를 모놀리식에서 마이크로서비스 아키텍처로 추가 분해하는 것이다. 제안된 아키텍처에서 소프트웨어 솔루션의 더 높은 효율성을 달성하기 위해, "서버리스(server-less or serverless)" 아키텍처라고도 하는 일시적인(ephemeral) 마이크로서비스를 사용한 프로그래밍이 구현되며, 여기서 마이크로서비스는 마이크로서비스 자체에 대한 API 호출에 기초하여 인스턴스화(기동 및 실행)된다.
예시적인 실시예에서, 클라우드는 컴퓨팅 자원을 인식 및 노출하고 이용 가능한 경우 기회주의적 방식(opportunistic way)으로 그것들을 활용함으로써 에지로 확장된다. 또한, 가용성, 정책 및 컨텍스트(소셜 및 기타 애플리케이션 레벨 이벤트 포함)에 기초한 일시적인 마이크로서비스가 배치되는 방식에 분석을 추가하면, 에지 클라우드 컴퓨팅 네트워크(300)에서의 애플리케이션의 최적 배치를 가능하게 한다.
개시된 아키텍처는, 기존 에지 클라우드 컴퓨팅 기기가 에지 클라우드 서버(또는 에지 클라우드 서버 컴퓨팅 기기)로 쉽게 전환될 수 있다고 가정한다. 개발자는 가능한 한 적은 노력으로 (에지 클라우드에 의해 지원되는) 애플리케이션을 구축할 수 있어야 한다고 설명 범위 내에서 예상된다. 에지 클라우드 컴퓨팅 기기의 이질성(heterogeneous nature)을 감안할 때, 개시된 접근법은 기기 능력에 기초하여 기능적 역할을 할당한다. 개발자가 애플리케이션을 쉽게 개발할 수 있도록, 예를 들어, Amazon Web Services®(AWS) 또는 Microsoft Azure®와 같은, 중앙 클라우드와 유사한 API 시맨틱스를 구현하고 따른다. 또한, 에지 노드에서 마이크로서비스를 실행하기 위한 가벼운 컨테이너와, Docker® 또는 CoreOS®와 같은 기존 컨테이너 기술의 시맨틱스가 구현된다.
개시된 접근법에서, 에지 노드 또는 에지 클라우드 컴퓨팅 기기는 잠재적인 에지 클라우드 서버 또는 에지 클라우드 서버 컴퓨팅 기기가 되기 위한 복수의 능력을 입증하도록 구성된다. 이 복수의 능력(capability)은 다른 에지 노드 또는 에지 클라우드 컴퓨팅 기기의 존재를 운영 체제(OS) 또는 그것들과 관련된 네트워크에 관계없이 탐색하는 역량(ability)을 포함한다. 복수의 능력은 또한 다른 노드의 능력 및 거동(예: 하드웨어 사양, OS, 지속성 등)을 탐색하는 역량도 포함한다. 복수의 능력은 다른 에지 노드 또는 에지 클라우드 컴퓨팅 기기에 의해 지원되는 하나 이상의 마이크로서비스를 탐색하고 다른 에지 노드 또는 에지 클라우드 컴퓨팅 기기, 특히 네트워크, 근접성 및 사용자 계정 주변의 네트워크와 함께 클러스터를 동적으로 형성하는 역량을 더 포함한다.
다른 실시예에서, 복수의 능력은 직접적으로 또는 상이한 클러스터에 걸쳐 다른 노드를 통해 마이크로서비스 레벨에서 다른 노드와 통신하고 다른 노드가 데이터, 서비스 및/또는 자원을 공유하기로 선택한 경우 다른 노드와 연결하는 역량을 더 포함한다. 또 다른 실시예에서, 복수의 능력은 자원 및 능력에 기초하여 할당된 기능 및 역할에 적응하고 데이터를 국부적으로 처리 및 분석하는 역량을 더 포함한다. 또한, 복수의 능력은 중앙 클라우드만큼 안전하고 신뢰할 수 있는 열량을 더 포함된다.
일 실시예에서, 복수의 능력을 입증하기 위한 에지 노드 또는 에지 클라우드 컴퓨팅 기기의 구성은 플랫폼에 구애받지 않는 접근법(platform-agnostic approach)으로 달성된다. 일 실시예에서, 임의의 에지 클라우드 컴퓨팅 기기를 에지 클라우드 서버로 전환하고 결과적으로 종단 간(end-to-end) 에지 클라우드 플랫폼을 구축하는 다운로드 가능한 애플리케이션 레벨 소프트웨어(예: 에지 노드 활성화 모듈)가 제공된다. 제안된 접근법은 기기 하드웨어, OS 커널 또는 드라이버를 변경할 필요가 없으며 대부분의 최신 하드웨어(PC, STB, 라우터 태블릿, 스마트폰 등)에서 작동한다는 점에 당업자는 유의해야 한다. 또한, 제안된 소프트웨어 수준 애플리케이션은 매우 작은 메모리 풋프린트(memory footprint)를 가지며 에지 클라우드 컴퓨팅 기기에 걸쳐 쉽게 로드, 실행 및 중지할 수 있는 마이크로서비스를 지원한다.
또한, 개시된 접근법은 다수의 고객을 지원하기 위해 소프트웨어의 단일 인스턴스로 다중 테넌시, 다수의 애플리케이션 및 마이크로서비스를 지원한다. 개시된 클라우드 플랫폼은 "중앙 클라우드"(예: 도 3의 306)에서 호스팅되는 가볍지만 확장성이 뛰어난 백엔드(서비스)를 가지고 있으며 노드 또는 기타 에지 클라우드 컴퓨팅 기기의 등록을 위해 부트스트랩 메커니즘을 사용한다. 개시된 클라우드 플랫폼은 동일한 네트워크, 근접성 및 (사용자) 계정 내에서 에지 노드의 동적 클러스터를 생성하고 클러스터 간 및 클러스터 내 노드의 (나타나고 사라지는) 이동성 특성을 관리하는 역량을 제공한다.
일 실시예에서, 에지 클라우드 컴퓨팅 네트워크(300)는 직접적으로 또는 중간 노드를 통한 에지 노드 또는 에지 클라우드 컴퓨팅 기기 간의 통신의 관리 및 에지 노드로부터의 요구에 기초하여 백엔드 자원 또는 서비스의 동적 인스턴스화를 제공한다. 또, 에지 클라우드 컴퓨팅 네트워크(300)는 협력하는 에지 노드 및/또는 자원을 동적으로 견인함으로써 효과적인 지속성을 생성한다.
에지 노드의 힘(power)을 활용하고 대규모 탈집중화된 에지 클라우드를 생성하기 위해, 개시된 접근법은 에지 클라우드 아키텍처에서 다양한 원칙을 고려하고 구현한다. 개시된 접근법에 의해 구현된 탈집중화의 첫 번째 원칙은 "능력주의(meritocracy)"이다. 모든 노드는 에지 클라우드 컴퓨팅 네트워크(300)에 참여할 기회를 동등하게 갖는다. 노드는 자신의 능력에 기초하여 어떤 역할이든 맡을 수 있다. 노드 소유자가 인에이블된 능력은 노드 프로파일(node profile)에 저장된다. 예를 들어, 대용량 스토리지가 있는 노드는 "캐시 노드" 또는 "백업 스토리지 노드"가 될 수 있고, 네트워크 연결성(network connectivity)이 뛰어난 노드는 "프록시 노드"가 될 수 있으며, 영구 노드는 노드의 클러스터 등에 대한 지식(예: 기기 및 기능/역할 프로파일)의 보유자가 될 수 있다. 능력주의는 노드의 계층적 구조를 초래하는 미리 정의된 역할을 가진 중앙 요소를 프로비저닝할 필요를 방지한다.
일 실시예에서, 능력주의가 작용하는 데 필요한 "투명성"과 같은, 다른 원칙도 개시된 접근법에서 구현된다. 예를 들어 노드는 자신의 프로파일에 대한 진실을 투명하게 알려야 하며 그렇지 않으면 능력주의 원칙이 효과적으로 적용될 수 없다. 개시된 아키텍처는 거짓말을 할 동기를 없앤다(예: 어떠한 노드 특정(node-specific) 특권 또는 권리도 제공하지 않음). 거짓말을 할(예: 잘못된 정보, 오해의 소지가 있는 정보 또는 허위 정보를 제공할) 명백한 동기가 없는 경우, 개시된 아키텍처는 에지 클라우드 컴퓨팅 네트워크(100)에서 클러스터의 운영에 해를 끼치기 위해 프로파일에 대해 거짓말을 하는 노드를 블랙리스트에 올리는 메커니즘을 구현한다. 또, 능력주의는 시간이 지남에 따라 변경될 수 있으며 노드는 능fir 및 프로파일을 업그레이드하거나 다운그레이드할 수 있다. 개시된 아키텍처는 실시간으로 노드에 대한 이러한 변경을 수용한다.
"능력주의" 원칙과 관련된 중요한 고려 사항 중 하나는 제안된 아키텍처에서 중앙 클라우드 자원의 장점이다. 중앙 클라우드 아키텍처는, 에지 노드가 클라이언트로만 사용되는 에지 클라우드 컴퓨팅 아키텍처의 특수한 경우라고 볼 수 있다. 따라서 호스팅 비용, 대기 시간 및 개인 정보 보호를 희생하면서 개발 속도를 높이려면 기존의 나쁜 관행을 중단하거나 중앙 클라우드에서 쉽게 사용할 수 있는 자원에 의지하는 것이 바람직할 수 있다. 능력주의 원칙이 효과적으로 작용하려면, 모든 노드가 다른 노드에 대한 잠재적인 "서버"로 간주되며 모든 요청은 노드가 활성 상태인 클러스터에 대해 국부적으로 유지되어야 한다.
개시된 접근법에 의해 구현된 탈집중화의 두 번째 원칙은 "분산된 탐색"이다. 에지 클라우드 컴퓨팅 네트워크(100)에 있는 노드는 다른 노드를 탐색해야 한다. 현재 진행중인 개시에서, 탐색은 범위에 기초한 "필터링된 검색" 동작이 되도록 의도된다. 범위의 예시적이고 비한정적인 예로는 사용자 계정(동일한 계정 ID로 등록된 노드), 네트워크(동일한 링크-국부 클러스터 네트워크의 구성원인 노드), 근접성(자신을 지리적 위치에 또는 지리 공간적 조회에 정의된 영역 내에 물리적으로 존재하는 것으로 보고하는 노드)을 포함한다. 일 실시예에서, 탐색 프로세스는 전용 중앙 노드, 예를 들어 프레즌스 서버(presence server)의 역할을 하는 중앙 노드 없이 이들 또는 다른 범위의 임의의 조합을 사용한다. 노드가 방화벽 뒤에 있고 외부에서 도달할 수 없는 경우, 탐색할 수 있으려면 도달할 수 있는 임의의 노드에 의존해야 한다. 노드는 절대적으로 필요한 경우가 아니면 중앙 엔터티에 의존해서는 안 된다. 일 실시예에서, 탐색 프로세스는 기기와 연결하고 통신하는 방법, 중요한 특성, 역할 및 에지 노드가 채택할 수 있는 페르소나(persona)에 대한 정보를 포함한다. 역할로는 캐시 노드(예비(spare) 스토리지가 있는 노드), 프록시 노드(인터넷에의 우수한 연결성), CPU 자원(마이크로서비스를 실행하기 위한 예비 CPU가 있는 노드) 등이 포함될 수 있다.
개시된 접근법에 의해 구현된 탈집중화의 세 번째 원칙은 "클러스터링"이다. 인간과 기계는 클러스터에서 통신한다. 인류학자 로버트 던바(Robert Dunbar)는 인간이 안정적인 관계를 가질 수 있는 사람들의 인지 한계를 150으로 제안했다. 다시 말해, 인간은 제약된 클러스터에서 통신한다. 또한, 인간은 좀처럼 친밀한 관계에 있는 모든 사람과 정기적으로 또는 자주 의사소통을 하지 않는다. 사실, 일상적인 의사소통은 소수의 매우 가까운 관계로 한정될 수 있다. 따라서, 에지 클라우드 컴퓨팅 아키텍처에 대해 제안된 통신 프레임워크가 클러스터 내의 노드에 역할과 책임을 할당할 때 이를 고려하는 것이 논리적으로 이치에 맞다.
그러나 위의 의사소통의 특성은 인간에게만 한정되지 않는다. 기계 간의 통신은 매우 유사하며 대부분의 통신이 임의 주어진 시간의 인스턴스에서 클러스터에 있는 매우 작은 노드 세트 간에 이루어진다. 따라서, 모든 통신은 가능한 한 클러스터에 대해 국부적으로 발생하도록 최적화될 수 있다. 임의의 노드가 다른 모든 노드와 핸드셰이크해야 하는 요건을 없애기 위해, 제안된 아키텍처에서는 클러스터 내의 하나의 노드(수퍼노드)에 클러스터의 지식 보유자로서의 특별한 역할을 부여한다. 슈퍼노드는 전역적인 탐색 또는 다른 클러스터의 노드를 위해/이에 대해 이 지식을 전달하는 역할을 할당받는다. 제안된 접근법은, 노드가 앞에서 설명한 세 가지 주어진 범위에 기초하여 자신의 애드혹(ad-hoc) 클러스터를 동적으로 형성할 수 있도록 해준다. 노드는 노드 및 규칙의 일련의 특성에 기초하여 다른 노드의 선정(election) 또는 선택(selection)을 통해 동적으로 역할을 수행한다. 이렇게 하면, 노드가 에지 클라우드의 패브릭(즉, 소프트웨어 정의형 클라우드 인프라)을 동적으로 형성한다. 노드가 클러스터에 들어오고 나감에 따라, 역할이 동적으로 재할당된다.
노드는 대부분 (제약된) 클러스터에서 통신한다. 따라서, 에지 클라우드에서 개시된 통신 프레임워크는 클러스터 내의 노드에 역할과 책임을 할당할 때 이를 고려한다. 클러스터는 주어진 범위에 기초하여 제1 활성 노드(또는 제1 에지 클라우드 컴퓨팅 기기)에 의해 형성된다. 노드가 "활성화"되는 경우, 먼저 "수퍼노드"(진행 중인 설명에서 "수퍼 에지 클라우드 컴퓨팅 기기"라고도 함)를 찾는다. 슈퍼노드는 전역적 탐색(global discovery)을 감독하고 에지 클라우드에 대한 지식을 보유한다. 슈퍼노드가 발견되지 않으면, 첫 번째 노드(또는 첫 번째 에지 클라우드 컴퓨팅 기기)는 자신을 슈퍼노드로 선언하거나 지정한다. 통신 네트워크를 사용할 수 있으면, 슈퍼노드는 전역적 탐색에 자신의 존재를 알리고 정의된 범위 내의 노드 목록을 수신한다. 효율을 유지하기 위해, 수퍼노드는 그 범위 내의 다른 노드에 알린다. 그 후, 더 나은 슈퍼노드가 식별될 수 있으며, 그 더 나은 슈퍼노드는 자신 존재를 전역적 탐색에 알린 다음 슈퍼노드로서의 역할을 할 수 있다.
클러스터가 슈퍼노드에 의해 생성되었으면, 클러스터에 진입하는 후속 노드는 기존 슈퍼노드를 탐색하고, 슈퍼노드에 자신을 등록하고, 자신의 범위 내의 노드 목록을 수신하도록 구성된다. 새 노드는 자신의 존재를 자신의 범위 내에서 다른 노드에 알린다. 개시된 에지 클라우드는 이 부트스트랩 모델을 구현하여 전역적이든 국부적이든, 임의의 노드의 과부하를 방지하고 트래픽과 채티니스(chattiness)를 줄이고 가볍고 확장 가능한 아키텍처를 만든다. 노드의 잠재적인 이동성을 감안할 때, 프레즌스 통지(presence notification)는 통지를 원하는 다른 노드를 결정하는 책임과 함께 노드 자체의 기능이다. 따라서, 개시된 에지 클라우드 아키텍처는 단일의 전역 프레즌스 서버 또는 개시된 에지 클라우드 컴퓨팅 네트워크에서의 등록 포인트(point of registration)를 구현하지 않는다. 유사하게, 개시된 아키텍처는 노드 사이의 인프라 레벨에서 "킵얼라이브(keep alive)" 메커니즘을 갖지 않는다. 일 실시예에서, 이러한 메커니즘은 특정 시나리오에서 필요한 경우 마이크로서비스에 위임될 수 있다.
개시된 접근법에 의해 구현되는 탈집중화의 네 번째 원칙은 "마이크로서비스 간 통신"이다. 분산형 에지 클라우드 패브릭을 생성하기 위해, 에지 클라우드 컴퓨팅 기기 또는 노드상의 애플리케이션은 절대적으로 필요한 경우가 아니면 제3자 신뢰 요소 없이 직접 통신할 수 있다. 이는 기기가 네트워크 레벨에서 에지 노드를 함께 연결할 수 있도록 해준다. 그러나 물리 네트워크 레벨에서 기기 또는 에지 노드를 연결하는 것만으로는 충분하지 않다. 에지 노드에서 실행 중인 마이크로서비스는 직접 통신해야 한다. 일 실시예에서, 에지 노드의 에지 노드 활성화 모듈은 형성된 에지 "클라우드 패브릭"을 활용하여 다른 마이크로서비스와 직접 통신함으로써 "서비스 메시"를 생성하도록 에지 노드에 마이크로서비스를 배치 및 호스팅할 수 있게 해주는 가벼운 컨테이너를 제공한다. 또한, 에지 노드는 에지 클라우드 컴퓨팅 네트워크(100)의 다른 에지 노드에서 마이크로서비스를 로드, 시작 및 중지하도록 구성된다. 이러한 구성은 개시된 클라우드 플랫폼에 걸쳐 마이크로서비스 관리가 중앙 엔티티를 필요로 하지 않고 분산된 상태로 유지되도록 보장한다.
일 실시예에서, 에지 노드에서 인에이블된 마이크로서비스는 공통의 내장된 웹서버를 통해 자신의 서비스를 노출한다. 각각의 서비스에 대한 API 엔드포인트는 에지 클러스터 내의 다른 모든 에지 노드로부터 액세스 가능하다. 일 실시예에서, 에지 클라우드는 에지 노드에 걸쳐 마이크로서비스의 끊김 없는 도달 가능성(seamless reachability)을 가능하게 하여 직접적 또는 나중에 더 자세히 설명되는 "사이드카 패턴"을 통해 서비스 메시를 형성한다. 컨테이너 데몬(container daemon)을 실행할 수 있는 환경(예: Linux)에서, 개시된 에지 클라우드 플랫폼은 에지 노드의 애드혹 클러스터를 관리하는 기능(functionality)을 제공한다. 컨테이너 데몬을 실행할 수 없는 환경(예: 스마트폰)에서, 개시된 에지 클라우드 플랫폼은 마이크로서비스를 다운로드, 배치 및 운영할 수 있는 역량을 가진 추가적인 "가벼운" 컨테이너 능력을 제공한다.
개시된 접근법에 의해 구현되는 탈집중화의 다섯 번째 원칙은 "동적 자원 인스턴스화(dynamic resource instantiation)"이다. 탈집중화가 효율적이려면, 클러스터에 가입하거나, 클러스터를 떠나거나, 할당된 자원을 얻기 위해 노드와 연관된 오버헤드가 거의 없는 것이 바람직하다. 진행중인 설명을 위해, 개시된 에지 클라우드 아키텍처에 의해 구현되는 솔루션은 "동적 자원 인스턴스화"라고 지칭한다. 이 원칙에 따라, 신호 및 데이터 자원은 네트워크의 상태와 하나 이상의 클러스터 내의 에지 노드로부터의 요구에 따라 동적으로(백엔드 서비스에 의해) 배치되므로, 컴퓨팅 자원을 예약할 필요를 없앤다. 이는 필요할 때만 인스턴스화되는 엔드포인트(예: SEP, BEP)를 동적으로 배치함으로써 효율을 높이고 비용을 절감한다. 개시된 클라우드 플랫폼은 시그널링 및 데이터 대역폭 효율성을 증가시키기 위해 에지 노드가 기회주의적으로 터널링을 설정하도록 돕는다. 자원은 네트워크 토폴로지 및 에지 노드에서 실행 중인 애플리케이션의 요구에 기초한 파라미터에 기초하여 배치된다. 일 실시예에서, 파라미터로는 라이브 시작 시간(time to go-live), 동시 연결의 수, 및 통신 프로토콜(HTTP, SSH, 웹 소켓 또는 UDP 터널링)을 포함한다. 원하는 경우, 지정된 클러스터에서 가장 가까이 있는 이용 가능한 컴퓨팅 자원에 엔드포인트를 배치할 수 있다.
개시된 접근법에 의해 구현되는 탈집중화의 여섯 번째 원칙은 "협력(collaboration)"이다. 탈집중화된 에지 클라우드 네트워크에서 에지 노드의 집합적인 힘을 활용하기 위해서, 에지 노드들이 협력하고 자원을 공유하는 것이 바람직하다. 탈집중화된 클라우드 자원의 공유는 중앙 클라우드의 경우만큼 끊김이 없는 것이 바람직하다. 첫 번째 단계로서, 개시된 클라우드 아키텍처는 모든 에지 클라우드 컴퓨팅 기기의 집합적 자원을 사용할 수 있다. 예를 들어, 비디오는 휴대폰(314)에서 HD 형식으로 녹화되고 녹화된 콘텐츠는 랩톱(302) 또는 연결된 스토리지 동글(storage dongle)에도 끊김 없게 저장된다. 다음 단계로서, 개시된 아키텍처는 친구 및 가족과 자원을 공유할 수 있게 한다. 예를 들어, 가족 구성원이 NAS(Network Attached Storage)를 가족 자원으로서 공유할 수 있도록 해준다. 일 실시예에서, 개시된 아키텍처는 또한 모르는 사람에게 컴퓨팅 자원을 임대하고 훨씬 더 큰 에지 클라우드를 생성하는 역량을 제공한다. 이러한 방식으로, 클라우드 패브릭은 중앙 클라우드보다 수십 배 더 큰 수많은 에지 노드에서 생성된다.
개시된 접근법은 에지 클라우드를 협력에 엄밀하게 결부시키려는 의도가 아님을 알 수 있다. 에지 클라우드는 에지 노드 간에 협력하고 에지 노드에 걸친 자원 공유를 활용할 기회를 제공한다. 그러나 협력이 없더라도, 에지 클라우드는 위에서 설명한 많은 이점을 제공할 수 있다. 기본 단계로서, 임의의 에지 기기에 구축된 임의의 애플리케이션은 애플리케이션의 요건에 기초하여 클러스터 내의 다른 노드에 서비스하기 위한 마이크로서비스를 호스팅하기 위해 (중앙 또는 전역 자원 대신) 국부 자원을 사용하는 우선순위를 지정한다. 예를 들어 Jack의 기기는 Jack의 앱을 호스팅하는 서버로 사용되어야 한다. 그러나 협력을 통해, 접근법은 더 확장되어 다른 노드의 자원을 사용할 수 있다. 예를 들어, Jill의 전화는 Jack의 애플리케이션을 위한 마이크로서비스를 실행할 수 있는데, 그들이 활성 세션이 아닐 때에도 실행할 수 있다. 또는 Jack은 Jill의 비디오를 위해 예비 스토리지를 자신의 기기에서 제공할 수 있다. 또는 Jill은 당시 열악한 셀룰러 연결 대신 Jack의 광섬유 연결을 사용할 수 있다. 다시 말해, 협력은 효율성과 확장성을 크게 향상시킬 수 있지만, 에지 클라우드를 유용하게 하는 데는 필요하지 않을 수 있다.
개시된 접근법에 의해 구현되는 탈집중화의 일곱 번째 원칙은 "인프라 독립성(infrastructure independence)"이다. 앞서 설명한 바와 같이, 클라우드 탈집중화를 위해, 개시된 클라우드 플랫폼은 운영 체제, 네트워크(유형 및 기술) 및 위치에 구애받지 않는(agnostic) 것이 바람직하다. 여러 가지 이유로 인해, 노드 간의 탈집중화된 통신을 표준화하려는 업계의 많은 시도가 실패했다. 따라서 제안된 탈집중화된 클라우드 플랫폼은 운영 체제 및 네트워크의 진화와 무관하다. 다시 말해, 개시된 클라우드 플랫폼은 애플리케이션 계층에서 기존 운영 체제 및 네트워킹 표준 위에서 동작한다. 이 원칙은 개시된 클라우드 플랫폼이 종속성이 최소이거나 전혀 없이 장기적으로 배치 및 유지되도록 보장한다. 개시된 클라우드 플랫폼은 또한 레거시 프로토콜, 모듈, 라이브러리, 데이터 등의 문제도 방지한다.
도 4는 분산형 에지 클라우드 플랫폼(400)의 실시예에 따른 에지 클라우드 컴퓨팅 아키텍처의 기본 구성 블록(fundamental building block)을 나타낸다. 전술한 원리에 기초하여, 개시된 분산형 에지 클라우드 플랫폼(400)이 설계 및 개발된다. 모든 에지 클라우드 컴퓨팅 기기를 에지 클라우드 서버로서 기능하도록 구성함으로써 에지 클라우드를 인에이블하는 실용적인 방법이 될 것으로 예상된다. 앞에서 설명한 것처럼, 이러한 구성은 하드웨어 플랫폼, 운영 체제 및 기본 네트워킹 기술에 구애받지 않는 완전히 분산된 방식으로 수행된다. 개시된 클라우드 플랫폼, 마이크로서비스, 에지 노드(또는 에지 클라우드 컴퓨팅 기기) 및 클라우드 클러스터는 임의의 운영 체제에서 실행되고 임의의 네트워크를 통해 통신하도록 구성된다. 또한, 개시된 클라우드 플랫폼 및 분산형 클라우드 서비스는 인프라와 무관하다.
도 4에 도시된 바와 같이, 분산형 에지 클라우드 플랫폼(400)은 그 기본 구성 블록인 중앙 요소 및 에지 요소를 포함하는 종단 간 시스템이다. 중앙 요소는 서버 컴퓨팅 기기에 의해 제공되는 백엔드 서비스 모듈(402)을 포함하고, 에지 요소는 에지 노드 활성화 모듈(426), 및 하나 이상의 마이크로서비스(예: 도 5를 참조하여 후술하는 518, 520, 522)를 포함한다. 개시된 아키텍처가 분산되도록 의도되고 요소(중앙 또는 에지)가 도달 가능한 에지 클라우드 컴퓨팅 기기(예: 302, 304, 306, 312)의 어느 곳에나 상주할 수 있음을 당업자는 이해할 것이다.
분산형 에지 클라우드 플랫폼(400)의 중앙 요소를 참조하면, 백엔드 서비스 모듈(402)은 인터넷을 통해 도달할 수 있는 서버에서 호스팅되며 에지 클라우드에 걸쳐 에지 노드 또는 에지 클라우드 컴퓨팅 기기를 지원하는 데 필요한 서비스를 제공한다. 현재 진행 중인 설명을 위해, 에지 클라우드는 컨텍스트 또는 특정 기기의 능력의 범위에 기초하여,각각이 전역적으로 유일한 ID를 가진, 노드의 모음(예: 203, 304)으로서 정의된다. 일 실시예에서, 주어진 노드는 다수의 클러스터의 구성원일 수 있다(예: 들어, 도 7의 노드(730) 참조). 예를 들어, 제1 클러스터는 사용자 계정 클러스터에 대응할 수 있으며, 이는 그 클러스터를 등록한 사용자에게 속한 노드의 클러스터이다. 제2 클러스터는 물리적으로 연결되어 있는 링크-국부 네트워크 클러스터(link-local network cluster)인 네트워크 클러스터(예: 726)에 대응할 수 있다. 제3 클러스터는 특정 주변 영역 내의 노드 클러스터인 근접 클러스터(예: 736)에 대응할 수 있다.
일 실시예에서, 백엔드 서비스 모듈(402)은 탐색 서비스(406), 시그널링 서비스(408), 신원확인 서비스(410)를 포함하는 하나 이상의 백엔드 서비스를 제공하도록 구성된다. 시그널링 서비스(408)는 시그널링 엔드포인트(signaling endpoint, SEP)와 같은 자원을 더 제공한다. 일 실시예에서, 하나 이상의 백엔드 서비스는 서버 토큰 서비스(416) 및 등록 서비스(418)를 더 포함한다. 서버 토큰 서비스(416)는 서비스에 대한 보안 토큰 인증/권한부여 기능과 연관될 수 있다. 백엔드 서비스 모듈(402)은 서버 컴퓨팅 기기(예: 312) 또는 클라우드(306)에서의 Amazon Web Services®(AWS)와 같은, 클라우드 웹 서비스(420)를 사용하여 호스팅되지만 이에 한정되지 않는다.
일 실시예에서, 탐색 서비스(406) 및 시그널링 서비스(408)의 단편(fragment) 또는 부분은 백엔드 서버(예: 312) 및 에지 노드(예: 302) 모두에서 구현된다. 예를 들어, 각각의 클러스터의 네트워크 프록시(또는 노드)는 시그널링 서비스(408)의 일부이고, 각각의 클러스터의 슈퍼노드(또는 슈퍼 에지 클라우드 컴퓨팅 기기)는 탐색 서비스(406)의 일부이다. 당업자가 이해할 수 있는 바와 같이, 개시된 클라우드 아키텍처는 "에지상의 클라우드-클라이언트에서의 서비스"의 기존 개념에서 벗어나다. 그 가치는 중앙 클라우드(예: 306)에서 에지 노드(도 7을 참조하여 나중에 설명됨)에 이르는 전 범위에 걸친 서비스 배포에서 비롯된다.
탐색 서비스(406)는 하나 이상의 클러스터, 클러스터의 전체 상태, 및 클러스터 내의 노드를 형성하기 위한 지식을 보유하고 제공하도록 구성된다. 일단 클러스터가 형성되면, 임의의 새로운 노드는 슈퍼노드를 통해 후속적으로 탐색 서비스(406)에 알리는 슈퍼노드에 등록한다. 확장성을 위한 트래픽을 줄이기 위해, 수퍼노드에서 탐색 서비스(406)로의 업데이트는 하나 이상의 클러스터에서 변경이 발생할 때만 기회주의적 방식으로 발생한다.
일 실시예에서, 탐색 서비스(406)는 슈퍼노드에의 도달 가능성 테스트를 수행하도록 구성된다. 슈퍼노드가 자신을 등록하는 경우, 탐색 서비스(406)는 도달 가능성을 테스트한다. 슈퍼노드는 방화벽 뒤에 있을 수 있고 탐색 서비스(406)에 대한 호출을 시작할 수 있지만, 탐색 서비스 또는 다른 외부 노드는 슈퍼노드에 대한 호출을 모방하지 못할 수 있다. 그러한 경우, 탐색 서비스(406)는 클러스터에 대한 시그널링 엔드포인트(SEP)(예: 412)를 동적으로 배치하기 위해 시그널링 서비스(408)를 요청할 것이다. 후속적으로, 탐색 서비스(406)는 SEP 주소를 슈퍼노드에 회신한다.
또 다른 실시예에서, 탐색 서비스(406)는 노드 및 클러스터 프로파일의 완전한 인벤토리(inventory)를 저장하도록 구성된다. 이 인벤토리는 모든 노드의 컴퓨팅 자원, 각각의 노드의 상태, 각각의 노드의 위치 및 각각의 노드에서 이용 가능한 서비스에 대한 세부사항을 포함한다. 인벤토리는 각각의 노드와 클러스터에 도달하기 위한 종단 간 네트워크 토폴로지(end-to-end network topology), 클러스터의 도달 가능성, 자원 및 기타 관련 정보의 가용성을 포함한다. 다시 말해, 탐색 서비스(406)는 에지 클라우드 컴퓨팅 네트워크(300)에 걸친 모든 자원에 대한 완전한 가시성을 가지며 실시간으로 네트워크 내의 임의의 이용 가능한 자원에 서비스를 동적으로 배치하기 위해 이 정보를 제공할 수 있다. 일 실시예에서, 개시된 아키텍처는 표준 아마존 시맨틱스를 사용하여 개발자가 중앙 클라우드 자원의 경우와 유사한 방식으로 자원을 더 쉽게 노출할 수 있게 한다.
일 실시예에서, 신원확인 서비스(410)는 예를 들어 OAuth2.0을 기반으로 하는, 공용 클라우드에 상주하고 노드의 인증 프로파일을 생성 및 유지하는 제3자 신원확인 SaaS(Software as a Service)에 대응한다. 일 실시예에서, 개시된 클라우드 플랫폼은 하나 이상의 토큰 보유자에 대한 토큰 생성 및 관리에 의한 노드의 권한부여를 위해 (서버 토큰 서비스(416)와 함께) 신원확인 서비스(410)를 사용한다. 토큰 보유자는 에지 노드 활성화 모듈(예: 426, 508), 에지 노드 활성화 모듈을 사용하는 마이크로서비스(예: 518, 520, 522), 에지 노드 활성화 모듈을 사용하는 애플리케이션 개발자 및 애플리케이션의 최종 사용자일 수 있다. 개시된 클라우드 플랫폼은 토큰을 사용하여 자격, 토큰 소유자의 정당성(legitimacy)을 검증하고 백엔드 서비스 모듈(402)에 의해 제공되는 하나 이상의 백엔드 서비스에 대한 액세스를 승인한다. 일 실시예에서 승인은 JWT(Jason Web Tokens)을 통해 수행된다. 토큰 보유자의 신원을 검증하기 위한 표준 "클레임(claim)"의 서브세트이다.
일 실시예에서, 시그널링 엔드포인트(SEP)(412) 및 베어러 엔드포인트(bearer endpoint, BEP)(414)는 둘 다, 예를 들어, 탐색 서비스(406) 또는 시그널링 서비스(408)로부터 수신된 요청에 기초하여 동적으로 그리고 요구에 따라(on demand) 배치되는 자원이다. 그 결과, 컴퓨팅 자원을 예약할 필요가 없다. 이는 필요할 때만 엔드포인트를 배치하여 효율성을 높이고 비용을 줄인다. SEP는 시그널링 통신에 사용되는 반면 BEP는 데이터 통신에 사용되며 함께 노드가 신호 및 데이터 대역폭 효율성을 높이기 위해 기회주의적으로 터널링을 설정하도록 돕는다. SEP와 BEP는 라이브 시작 시간, 동시 연결의 수, 및 통신 프로토콜(HTTP, SSH, 웹 소켓 또는 UDP 터널링)과 같은 파라미터에 기초하여 배치되지만, 이에 한정되지 않는다. 원하는 경우, 엔드 포인트는 클러스터의 가장 가까운 곳에 있는 이용 가능한 컴퓨팅 자원에 배치될 수 있다.
일 실시예에서, 서버 토큰 서비스(416)는 OAuth2.0에 기반한 SaaS 기반 솔루션이다. 일 실시예에서, 서버 토큰 서비스(416)는 다른 서비스에 요청을 하는 서비스에 토큰을 전달한다. 일 실시예에서, 서버 토큰 서비스(416)는 공용 클라우드에 상주하고 시스템 맵에 따라 서비스 토큰을 발행한다. 또한, 서버 토큰 서비스(416)는 "client_credentails" 및 "refresh_tokens" 흐름을 구현한다. 마이크로서비스가 다른 마이크로서비스를 호출해야 하는 경우, 이미 유효한 토큰이 있으므로 직접 요청할 수 있거나 허가 목록(또는 범위)이 포함된 토큰을 요청할 수 있다. 일 실시예에서, 수신 서비스는 들어오는/수신된 요청을 이행하기 위해 토큰 서명 및 범위를 검증할 것이다. 일 실시예에서, 서비스 토큰에 대한 이러한 서비스는 수명이 짧다.
일 실시예에서, 등록 서비스(418)(IT 저장소라고도 함)는 공용 클라우드에 상주하고 모든 백엔드 마이크로서비스 및 이들이 속한 클러스터의 목록을 유지관리하는 SaaS 솔루션이다. 주로 관리 목적으로 사용되는, 등록 서비스(418)는 클러스터 지식을 유지하고 클러스터가 구성 목적으로 자체 관리될 수 있도록 한다. 일 실시예에서, 등록 서비스(418)는 필요한 경우 SEP(412) 또는 BEP(414)를 호출하기 위한 시그널링 서비스를 식별하기 위해 다른 서비스(예: 탐색 서비스(406))에 의해 사용될 수 있는 클러스터(또는 도 6을 참조하여 나중에 설명되는 구성)의 지리적 위치 목록(geo-located list)을 제공한다.
이제 분산형 에지 클라우드 플랫폼의 에지 요소로 돌아가면, 에지 클라우드 컴퓨팅 기기(404)는 에지 노드 활성화 모듈(426)을 포함한다. 앞서 설명한 바와 같이 에지 노드 활성화 모듈(426)은 OS 계층(428)의 상단에 위치하며 마이크로서비스 런타임 환경 모듈(424)을 사용하여 하나 이상의 마이크로서비스를 실행하기 위한 마이크로서비스 런타임 환경을 제공한다. 하나 이상의 제3자 애플리케이션(앱)(422)은 또한 에지 노드 활성화 모듈(426)에 의해 서비스되는 에지 클라우드 컴퓨팅 기기(404)에서 호스팅된다. 일 실시예에서, 개발자는 에지 노드 활성화 모듈(426)에 의해 제공하는 컨테이너 관리자를 사용하여 에지 기기 또는 노드에서 호스팅될 수 있는 자체 마이크로서비스를 개발할 수 있다.
일 실시예에서, 에지 노드 활성화 모듈(426)은 임의의 에지 기기(또는 에지 클라우드 컴퓨팅 기기)를 클라우드 서버로 전환하여 클라우드 컴퓨팅 인프라를 새로운 에지로 확장한다. 에지 기기는 랩톱(예: 302), 셋톱박스, 주거용 및 IoT 게이트웨이, 게임 콘솔 커넥티드(connected) TV, 자동차 인포테인먼트 시스템(예: 308), 스마트폰(예: 314)과 같은, 기본 컴퓨팅 능력을 가진 모든 기기일 수 있다.
임의의 에지 기기는 에지 노드 활성화 모듈(426)을 다운로드하고 이를 실행하여 클라우드 서버가 "될" 수 있다. 진행중인 설명을 위해, 에지 노드 활성화 모듈(426)을 실행한 에지 기기를 "노드"라고 지칭한다. 이러한 노드는 개시된 에지 클라우드 플랫폼 및 아키텍처를 위한 의도되는 하나 이상의 특성이 있다. 하나 이상의 특성으로는 OS 및 네트워크와 서로 독립적인(또는 다른 노드)를 동적으로 참색하는 역량을 포함하고, 서로에게 컴퓨팅 및 이용 가능한 능력 및 기능을 노출하는 역량을 포함된다. 하나 이상의 특성으로는 클러스터(에지 클러스터)로 형성 및 조직하고 인터넷 가용성이 없는 경우에도 클러스터 내에서 그리고 클러스터에 걸쳐 통신하는 역량을 포함한다.
개시된 에지 클라우드 플랫폼은 전술한 바와 같이 클러스터링의 세 번째 원리에 따라 클러스터 노드를 형성함으로써 동작한다. 하나 이상의 클러스터는 특정 범위에 기초하여 제1 활성 노드(또는 제1 에지 클라우드 컴퓨팅 기기)에 의해 형성된다. 노드(예: 제1 에지 클라우드 컴퓨팅 기기)가 활성화되는 경우(에지 노드 활성화 모듈(426)이 인에이블됨), 전역 탐색을 감독하고 에지 클라우드에 대한 지식을 보유하는 슈퍼노드를 찾는다. 슈퍼노드가 발견되지 않으면 첫 번째 노드가 자신을 슈퍼노드로 선언한다. 인터넷을 이용할 수 있으면, 슈퍼노드는 자신의 존재를 전역 탐색에 알리고 정의된 범위 내의 노드 목록을 수신한다. 효율성을 유지하기 위해, 슈퍼노드는 그 범위 내의 다른 노드에 알린다.
슈퍼노드가 클러스터를 생성한 후, 클러스터에 진입하는 후속 노드는 기존 슈퍼노드를 탐색하고, 자신을 슈퍼노드에 등록하고, 자신의 범위 내의 노드 목록을 수신한다. 새로운 노드는 자신의 존재 범위 내에서 다른 노드에 알린다. 이 부트스트랩 모델은 전역적이든 국부적이든, 임의의 노드의 과부하를 방지하고 그에 따라 트래픽과 채티니스를 줄이기 위해 개시된 클라우드 아키텍처에 의해 사용된다. 노드의 잠재적인 비영구성을 감안할 때, 프레즌스 통지는 통지를 원하는 다른 노드를 결정하는 책임과 함께 노드 자체의 기능이다.
위에서 설명된 바와 같이, 에지 노드 활성화 모듈(426)은 임의의 에지 클라우드 컴퓨팅 기기 또는 서버에 상주할 수 있고 다양한 하드웨어 플랫폼 및 운영 체제에 이용 가능하게 될 수 있다. 일 실시예에서, 에지 노드 활성화 모듈(426)은 애플리케이션 레벨 소프트웨어에 대응하고 따라서 많은 유형의 에지 클라우드 컴퓨팅 기기에 다운로드될 수 있다. 백엔드 서비스 모듈(402)은 충분한 컴퓨팅 및 메모리를 가진 중앙 클라우드(예: 306) 또는 도달 가능하고 신뢰성 있는 컴퓨팅 자원에서 호스팅되는 하나 이상의 백엔드 서비스를 제공하고 에지 노드를 지원하는 데 필요한 서비스를 제공한다.
도 5는 일 실시예에 따른 에지 클라우드 컴퓨팅 기기(500)를 도시한다. 도시된 바와 같이, 에지 클라우드 컴퓨팅 기기(500)는 메모리(504)에 연결된 프로세서(502)를 포함한다. 메모리는 여기에 설명된 다양한 기술을 구현하는 명령어를 갖는, 컴퓨터로 판독 가능한 매체 비일시적인 매체에 대응한다. 예시적인 컴퓨터로 판독 가능한 매체로는 프로세서(502)에 의해 실행 가능한, 컴퓨터로 실행 가능한 명령어를 갖는 유형의, 컴퓨터로 판독 가능한 비일시적인 저장 매체를 포함할 수 있으며, 명령어는 프로세서에 의해 실행될 때, 프로세서로 하여금 여기에 제공된 다양한 방법 및 접근법의 임의의 조합을 수행할 수 있게 한다. 도시되지는 않았지만, 모든 에지 클라우드 컴퓨팅 기기(302, 304, 308, 310, 312, 314, 316, 404) 및 중앙 클라우드(예: 306)는 적어도 프로세서(예: 502)를 포함하고, 메모리(예: 504), 및/또는 프로세서(들)에 의해 실행될 때 여기에 설명된 방법 및 접근법을 수행하는 메모리에 저장된 다양한 다른 애플리케이션 또는 모듈을 포함하는 것으로 이해될 수 있다.
메모리(504)는 OS 계층(506) 및 에지 노드 활성화 모듈(508)을 포함한다. 에지 노드 활성화 모듈(508)은 API 게이트웨이를 갖는 넷 모듈(Net module)(510)을 더 포함한다. 에지 노드 활성화 모듈(508)은 또한 컨테이너 관리자 마이크로서비스(microservice, μS) 이미지 저장소(512), HTTP 요청 래퍼(라이브러리, lib.)(514) 및 내장된 웹서버(516)를 포함한다. 앞서 설명한 바와 같이, 에지 노드 활성화 모듈(508)은 하나 또는 하나 이상의 에지 노드에 하나 이상의 마이크로서비스를 노출한다. 일 실시예에서, 에지 노드 활성화 모듈(508)은 에지 클라우드에서 임의의 서비스를 시작/중지, 다운로드, 배치하고 API 게이트웨이를 사용하여 서비스를 노출하도록 구성된다. 이를 위해, 에지 노드 활성화 모듈(508)은 하나 이상의 클러스터(내부 또는 전체)에서 다른 에지 노드를 탐색, 연결 및 통신하도록 구성된다. 메모리(504)는 또한 도 5에서 518, 520 및 522로 포시된 하나 이상의 마이크로서비스(μS)를 포함한다. 마이크로서비스(522)는 사용자 인터페이스(user interface, UI) 앱(524)의 일부인 것으로 표시된다. 메모리(504)는 또한 내부에 마이크로서비스가 없는 다른 UI 앱(526)을 포함한다. 모든 마이크로서비스(518, 520 & 522)와 UI 앱(524 & 526)은 도 5에서 528로 표시된 제3자의 노출된 API를 통해 액세스할 수 있다.
일 실시예에서, 에지 노드 활성화 모듈(508)은 소프트웨어 라이브러리 및 대응하는 API의 모음에 대응한다. 또한, 개발자가 소프트웨어 라이브러리 및 API를 사용하여 새로운 초연결(hyper-connected) 고도의 이동 분산형 에지 컴퓨팅 세계에서 네트워킹 노드의 기본적인 문제를 효율적으로 해결할 수 있도록 의도된다. 에지 노드 활성화 모듈(308)은 OS, 제조업체 및 임의의 에지 클라우드 컴퓨팅 기기와 연관된 커넥티드 네트워크에 관계없이, 이종 환경에서 전달될 수 있다. 또한, 에지 노드 활성화 모듈(508)은 애플리케이션 사용 사례에 따라, 임의의 PC, 서버, 이동 기기, 고정 게이트웨이, 자율주행 차량 게이트웨이, 커넥티드 TV 또는 클라우드에서도 운행(실행)될 수 있다. 앞서 설명된 바와 같이, 에지 노드 활성화 모듈(508)이 에지 기기에 로드되면, 에지 클라우드 노드가 된다.
도 5에 도시된 바와 같이, 에지 노드 활성화 모듈(508)은 운영 체제 계층(506)과 최종 사용자 애플리케이션(예: 524, 526) 사이에 위치한다. 에지 노드(500)에서 이용 가능한 여러 마이크로서비스(예: 518, 520, 522)가 있으며 에지 노드 활성화 모듈(508)은 제3자가 자체 마이크로서비스를 개발할 수 있는 역량을 제공한다. 에지 노드 활성화 모듈(508)은 또한 마이크로서비스 런타임 환경을 제공한다. 앞서 설명된 바와 같이, 에지 노드 활성화 모듈(508)을 통합함으로써, 컴퓨팅 기기는 하나 이상의 클러스터를 형성할 수 있는 지능형 네트워크 노드 또는 에지 노드로 변환된다. 에지 노드 활성화 모듈(508)은 분산형 에지 클라우드 노드 간의 네트워킹 복잡성을 제거하여 개발자가 소형 이동 기기(예: 314)에서도 마이크로서비스 모델의 솔루션에 집중할 수 있도록 한다.
클러스터에서의 노드는 물리적 하드웨어 능력, OS, 부착된(attached) 연결된 네트워크 연결성, 각각의 노드에서 실행되는 마이크로서비스 유형 및 사용/개인정보보호 정책 설정에 따라 특정 역할 또는 역할 조합을 취하도록 구성된다. 어떤 역할은 주어진 시간에 클러스터 내의 다른 노드를 고려하여, 선정 프로세스를 통해 할당되고, 다른 역할은 선택 프로세스를 통해 할당된다. 앞서 설명한 바와 같이, 클러스터에서 가장 중요한 역할 중 하나는 슈퍼노드(또는 슈퍼 에지 클라우드 컴퓨팅 기기)의 역할로, 노드가 모든 구성원 노드에 의해 선택된다. 단일 노드 클러스터의 사소한 경우, 노드는 자체 슈퍼노드 역할을 한다. 슈퍼노드는 클러스터와 클러스터 및 그 모든 구성원 노드에 대한 정보의 베어러가 되도록 구성된다. 이는 클러스터의 "진실의 단일 소스"이다. 슈퍼노드는 다른 노드, 각각의 노드에 배치된 마이크로서비스, 에지 노드 활성화 모듈(508)의 동작으로 인한 역사적 아티팩트와 관련된 정보를 유지하도록 구성된다. 슈퍼노드는 클러스터의 다른 노드에 링크-국부 프록시 및 링크-국부 캐시와 같은 역할을 할당하도록 구성된다. 링크 국부 프록시 노드는 클러스터 노드가 방화벽 뒤에 있는 경우 통신을 지원한다. 반면에, 대량의 물리 스토리지를 가진 노드에는 클러스터에 대한 링크-국부 캐시 역할이 할당될 수 있다.
각각의 노드에 대해, 에지 노드 활성화 모듈(508)은 유일한 사용자와 다수의 마이크로서비스 및 애플리케이션 제공자("테넌트"라고도 함)를 지원한다. 다시 말해서, 사용자가 모두 에지 노드 활성화 모듈(508)을 채용하는 다수의 애플리케이션을 이동 기기에 로드하였더라도, 기능 및 능력은 그 사용자에 관련(및 권한 부여)된다.
일 실시예에서, 에지 노드 활성화 모듈(508)은 물리적 및 마이크로서비스 레벨 모두에서 에지 기기들 간의 탐색, 연결 및 통신을 제공한다. 예를 들어, 에지 노드 활성화 모듈(508)은 국부 및 전역 네트워크(들)에서 에지 노드 활성화 모듈의 인스턴스를 가진 모든 노드에 대한 자동 탐색 및 자동 라우팅에 의한 노드 및 서비스 탐색을 제공한다. 유사하게, 에지 노드 활성화 모듈(508)은 자체 조직 클러스터를 형성하는 노드의 애드혹 에지 클라우드에서 노드 및 서비스 연결을 제공한다. 일 실시예에서, 에지 노드 활성화 모듈(508)은 마이크로서비스 인스턴스를 (원격으로/국부적으로) 로드, 실행 및 관리함으로써 하나 이상의 마이크로서비스를 관리하기 위한 가벼운 컨테이너를 제공하도록 구성된다. 앞서 설명된 바와 같이, 에지 노드 활성화 모듈(508)은 마이크로서비스 런타임 환경을 제공하기 위한 에지 웹 서버를 포함한다.
앞서 설명한 바와 같이. 에지 노드 활성화 모듈(508)을 가진 노드는 서로 탐색, 연결 및 통신하도록 구성된다. 일 실시예에서, 탐색은 사용자 계정, 즉 동일한 계정 ID 하에 등록된 노드에 대응하는 하나 이상의 범위에 기초한, "필터링된 검색" 동작이다. 일 실시예에서, 에지 노드 활성화 모듈(508)은 (백엔드 서비스 모듈(402)에 의해 제공되는 신원확인 서비스(410)로서 사용되는) 제3자 신원확인 SaaS 제공자를 통해 OAuth 2.0 기반 OpenID 표준을 채용한다. 범위는 동일한 링크-국부 클러스터 네트워크의 구성원인 노드와 같은, 네트워크에 대응할 수도 있다. 이 경우 링크-국부 식별자는 공용 IP 주소와 링크-국부 네트워크 주소를 결합하여 구성된다. 범위는 또한 지리적 위치 또는 지리적 공간 조회에 의해 정의된 영역 내에 물리적으로 존재한다고 스스로 보고하는 노드와 같은 근접성에 대응할 수도 있다. 에지 노드 활성화 모듈(508)에 의해 실행되는 탐색 프로세스는 위에서 설명된 범위의 임의의 조합을 사용할 수 있다. 이러한 노드 각각과 클러스터에 걸친 마이크로서비스는 API를 통해 서로를 호출하여 에지 클라우드를 사용하여 자체 서비스 메시를 형성할 수 있다. 또한, 노드 및 노드에서 실행되는 마이크로서비스는, 특정 노드의 특정 마이크로서비스(예: 드라이브)가 유일하게, 국부적으로, 그리고 전역적으로 주소를 지정할 수 있는 것과 같은, .유일한 식별자를 갖는다.
또, 에지 노드 활성화 모듈(508)은 마이크로서비스 런타임 환경(가벼운 컨테이너)을 제공하여 공통 내장된 웹서버를 통해 마이크로서비스와 관련된 서비스를 노출한다. 각각의 서비스에 대한 API 엔드포인트는 넷 모듈(510)의 일부인 API 게이트웨이를 통해 에지 클러스터 내의 다른 모든 노드로부터 액세스할 수 있다. 에지 노드 활성화 모듈(508)은 두 가지 다른 방식으로 컨테이너 데몬(또는 Docker®)을 보완한다. 컨테이너 데몬을 실행할 수 있는 환경(예: Linux®)에서, 에지 노드 활성화 모듈(508)은 앞서 설명한 대로 에지 노드의 애드혹 클러스터를 관리하는 기능을 제공한다. 컨테이너 데몬(예: 스마트폰)을 실행할 수 없는 환경에서, 에지 노드 활성화 모듈(508)은 마이크로서비스를 다운로드, 배치 및 동작시킬 수 있는 역량을 가진 추가적인 "가벼운" 컨테이너 능력을 제공한다. 내장된 웹서버(예: 516)는 하나 이상의 제약 조건이 있는 컨테이너 관리(예: Docker®) API의 서브세트를 제공한다. 하나 이상의 제약 조건에는 기본 OS(Android의 경우 Java, iOS®의 경우 Objective c 등)를 기반으로 하는 특정 언어의 사용이 포함된다. 하나 이상의 제약은 "가벼운" 컨테이너 환경(에지 노드 활성화 모듈(508)에 의해 제공됨)에서 실행되는 마이크로서비스에 의해 에지 노드 활성화 모듈(508)에 의해 제공되는 웹 서버의 사용을 포함하여 기본 플랫폼에서 네트워크 상의 한정된 자원의 사용을 최적화한다.
에지 노드 활성화 모듈(508)은 개발자가 임의의 노드에서 마이크로서비스를 구축하고 호스팅할 수 있도록 해준다. 개시된 클라우드 아키텍처는 또한 애플리케이션 개발 속도를 높이고 개발자가 분산형 에지 클라우드 플랫폼을 즉시 이용할 수 있도록 에지 노드 활성화 모듈(508)을 활용하는 다양한 마이크로서비스를 제공한다. 예를 들어 드라이브 마이크로서비스의 경우, 에지 노드에서 이용 가능한 스토리지에 대한 추상 액세스(abstracts access)와 인기 있는 API를 통한 분산형 파일 관리가 제공될 수 있다. 다른 예시적인 예에서, 피어투피어, 일대일 및 일대다 방식으로 노드에서 노드(들) 및/또는 서비스(들)로 빔 콘텐츠를 전송하는 빔 마이크로서비스가 제공된다.
일 실시예에서, 에지 노드 활성화 모듈(508)은 애플리케이션이 상이한 기술을 사용하여 구축된 구성요소로 분해되도록 하는 사이드카 패턴을 구현한다. 사이드카 패턴을 사용하면, 애플리케이션의 임의의 구성 요소는 개별로 구축되고 배치될 수 있다. 사이드카와 애플리케이션, 및 구성요소의 근접성으로 인해 대기 시간이 감소되며, 애플리케이션 자체를 변경하지 않고도 기능이 추가할 수 있다. 사이드카 패턴은 서비스 메시 처리의 많은 복잡성을 추상화한다. 이러한 복잡성의 대부분이 에지 클라우드에 걸쳐 배치된 마이크로서비스 유형과 무관하기 때문에, 이는 개시된 에지 클라우드 컴퓨팅 아키텍처에서 가능하다. 그러나 사이드카 패턴은 네트워크의 분산된 특성을 숨길 수 없다. 일례로서, API 게이트웨이 또는 보안 토큰 관리는 사이드카 패턴을 사용하여 구축될 수 있다. 일 실시예에서, API 게이트웨이는 에지 노드 활성화 모듈(508) 내의 넷 모듈(510)의 일부이다. API 게이트웨이는 클러스터 내의 다른 모든 노드로부터 액세스 가능한 각각의 서비스에 대한 API 엔드포인트를 만든다. 이 API 게이트웨이를 제공함으로써, 에지 노드 활성화 모듈(508)은 다른 클러스터에서 다른 마이크로서비스를 다루는 복잡성을 추상화하는 기능을 제공한다.
에지 노드에서 보안은 마이크로서비스가 통신하는 방식의 중요한 측면이 된다. 방화벽 및 네트워크 파티셔닝과 같은 특정 요소는 중앙 클라우드에서는 매우 일반적이지만 일반적으로 에지에는 존재하지 않을 수 있다. 따라서 여러 레벨의 보안을 처리해야 할 수 있다. 예를 들어, 링크-국부 클러스터에서는 이 클러스터 내의 노드에 도메인 이름이 없기 때문에 https를 사용할 수 없다. 따라서 동일한 링크-국부 네트워크 내의 노드 간의 통신은 암호화된다. 또, 각각의 마이크로서비스의 API는 토큰을 통해 보호된다. 일반적으로, 에지 노드 활성화 모듈(508)은 무신뢰 네트워크 환경에서 실행된다. 따라서 방화벽이 에지 노드에서 실행되는 마이크로서비스를 보호한다고 가정할 수 없다. 일 실시예에서, 유효하고 만료되지 않은 토큰을 갖는 것을 처리하는 것은 사이드카 패턴에 의해 추상화된다. 다른 노드(예: 캐시 노드 또는 링크-국부 프록시 노드)의 데이터를 관리할 수 있는 일부 특수 노드가 있기 때문에, 사용자 페이로드는 승인된 당사자만 볼 수 있도록 암호화되어야 할 수 있다. 일 실시예에서, 키 취득, 사용자 페이로드의 암호화 및 복호화도 사이드카에 의해 추상화된다.
근접 및 사용자 계정 클러스터의 경우, 적절한 노드로의 라우팅은 슈퍼노드 및 링크-국부 프록시 노드의 처리를 필요로 하는 복잡한 작업이다. 일 실시예에서, 사이드카는 마이크로서비스의 개발자로부터 이러한 복잡성을 숨기고 개발자는 클러스터 내에서 적절한 마이크로서비스를 호출하기만 하면 된다. 분산형 시스템은 내결함성(fault tolerance)을 보장하기 위해 재시도 메커니즘가 필요하다. 일 실시예에서, 사이드카는 재시도 호출 및 재시도 전략을 처리한다. 개발자는 분산형 시스템의 복잡성보다는 마이크로서비스 개발에 집중할 수 있다. 개발자가 서비스 메시를 처리하는 데 도움이 되는 Istio와 같은 백엔드 기술과 유사하게, 에지 노드 활성화 모듈(508)은 에지에서 서비스 메시를 처리하고 에지 기기를 서버로 사용하는 모든 제약을 처리한다.
도 6은 일 실시예에 따른 예시적인 백엔드 마이크로서비스 분포(600)를 도시한다. 일 실시예에서, 에지 클라우드 컴퓨팅 플랫폼의 백엔드 시스템은 도 6에 도시된 바와 같은 마이크로서비스 기반 아키텍처를 사용하여 설계 및 배치된다. 도 6을 참조하면, 각각의 요소는 지리적으로 분산된(geo-distribute) 데이터 저장소(614)에 링크되는 마이크로서비스(604, 606, 608, 610, 612)의 지지적으로 배치된(geo-deployed) 클러스터의 그룹(602)으로 구성된다. 일 실시예에서, 동일 또는 상이한 클러스터에서 하나 이상의 마이크로서비스가 동일한 뷰를 갖도록 보장하기 위해, 탐색 서비스(예: 406), 등록 서비스(예: 418), 서버 토큰 서비스(예: 416) 및 ID 서비스(예: 410)에 대한 데이터 자장(예: 612)은 일관된 방식으로 동기화되어야 한다.
일 실시예에서, 시그널링 서비스, SEP(예: 412) 및 BEP(예: 414)의 경우, 각각의 마이크로서비스 클러스터는 지리적으로 독립적이다. 시그널링 서비스(예: 408)는 SEP(예: 412) 및 BEP(예: 414) 구성요소를 기동하기 위한 API를 제공하는 데 사용된다. 시그널링 서비스(408)는 시그널링 서비스(408)의 클러스터에서 기존 BEP(414) 및 SEP(412)를 추적하고 BEP와 SEP를 적절히 로드 밸런싱하는 데 필요한 정보를 제공한다. BEP 및 SEP가 필요한 곳에 기초하여 최적의 대기 시간을 제공하기 위해, 시그널링 서비스(408)는 독립적으로 지리적으로 분산된다.
일 실시예에서, 마이크로서비스의 지리적으로 배치된 클러스터는 에지 클라우드 컴퓨팅 기기의 각각의 클러스터에 대응할 수 있다. 다시 말해, 최상의 시나리오의 경우, 클러스터의 에지 클라우드 컴퓨팅 기기에서 호스팅되는 마이크로서비스는 클러스터의 에지 노드에서 이용할 수 있는 마이크로서비스의 클러스터를 형성할 수 있다. 일 실시예에서, 마이크로서비스의 지리적으로 배치된 클러스터는 에지 클라우드 컴퓨팅 기기의 다수의 클러스터에 대응할 수 있다. 다시 말해, 차선의 시나리오의 경우, 서로 다른 클러스터(예: 2개의 클러스터)의 에지 클라우드 컴퓨팅 기기에서 호스팅되는 마이크로서비스는 그 (2) 클러스터의 에지 노드에서 사용할 수 있는 마이크로서비스의 클러스터를 형성할 수 있다.
도 7은 일 실시예에 따른 예시적인 에지 클라우드 아키텍처(700)를 도시한다. 앞서 설명한 것처럼, 탈집중화된 클라우드의 가치는 중앙 클라우드(예: 306)에서 에지 노드까지 전체 범위에 걸쳐 서비스를 배포하는 데 있다. 도 7은 탐색 서비스(704), 시그널링 서비스(706), 신원확인 서비스(712), 서버 토큰 서비스(714) 및 등록 서비스(716)를 포함하는 하나 이상의 백엔드 서비스를 제공하도록 구성된 백엔드 서비스 모듈(702)을 도시한다. 시그널링 서비스(706)는 시그널링 엔드포인트(SEP)(708) 및 베어러 엔드포인트(BEP)(710)를 제공하도록 구성된다. 하나 이상의 백엔드 서비스는 클라우드 웹 서비스(718)에서 호스팅된다. 개시된 클라우드 아키텍처는 하나 이상의 클러스터를 형성하기 위한 백엔드 서비스 모듈(702)과 클라우드의 하나 이상의 노드 사이의 협력을 허용한다.
예를 들어, 도 7은 3개의 클러스터: 네트워크 클러스터 1(726), 네트워크 클러스터 2(732) 및 근접 클러스터 3(736)을 도시한다. 네트워크 클러스터 1(726)은 3개의 노드, 즉 슈퍼노드(720)인 노드 1, 노드 2(722) 및 네트워크 프록시 노드(724)인 노드 3을 포함한다. 네트워크 클러스터 2(732)는 2개의 노드, 즉 슈퍼노드인 노드 5와 네트워크 프록시 노드(728)와 캐시 프록시 노드(730)인 노드 6을 포함한다. 근접 클러스터 3(736)은 노드 4(734) 및 노드 캐시 프록시 노드(730)인 6을 포함한다. 앞서 설명한 바와 같이, 이러한 노드 각각은 에지 노드 활성화 모듈(예: 426, 508), 하나 이상의 마이크로서비스(예: 518, 520) 및 하나 이상의 제3자 앱(예: 422, 524, 526)을 포함한다. 위에서 언급한 클러스터는 앞서 설명한 바와 같이 하나 이상의 범위에 기초하여 형성되었다. 예를 들어, 네트워크 클러스터 1과 2(722, 728)는 네트워크를 범위로 하여 형성되었고, 근접 클러스터 3은 근접성을 범위로 하여 형성되었다. 또한, 도 7에 도시된 바와 같이, 주어진 노드는 2개의 클러스터의 일부일 수 있으며, 예를 들어 캐시 프록시 노드(726)인 노드 6은 네트워크 클러스터 2(728) 및 근접 클러스터 3(732)의 일부이다. 앞에서 설명한 고려 사항에 기초하여 다양한 노드에 다양한 역할이 할당되었다.
시그널링 엔드포인트(SEP) 및 베어러 엔드포인트(BEP)의 역학은 도 8에 도시된 예를 통해 가장 잘 설명될 수 있다. 도 8은 동일한 사용자 ID에 속하는 2개의 에지 클라우드 컴퓨팅 기기에 대한 탐색, 연결 및 통신을 갖는 시스템(800)의 예시적인 실시예를 도시한다. 도 7과 유사하게, 도 8은 클라우드 웹 서비스(818)에서 호스팅되는 탐색 서비스(804), 시그널링 서비스(806), 신원확인 서비스(812), 서버 토큰 서비스(814), 등록 서비스(816)를 포함하는 하나 이상의 백엔드 서비스를 제공하도록 구성된 백엔드 서비스 모듈(802)을 도시한다. 시그널링 서비스(806)는 시그널링 엔드포인트(SEP)(808) 및 베어러 엔드포인트(BEP)(810)와 같은 자원을 동적으로 배치하도록 구성된다.
도 8은 또한 2개의 클러스터, 즉 네트워크 클러스터 1(826) 및 네트워크 클러스터 2(832)를 도시한다. 네트워크 클러스터 1(826)은 3개의 노드, 즉 슈퍼노드(820)인 노드 1, 노드 2(822) 및 네트워크 프록시 노드인 노드 3(824)을 포함한다. 네트워크 클러스터 2(832)는 2개의 노드, 즉 슈퍼노드인 노드 5와 네트워크 프록시 노드(828)와 캐시 프록시 노드(830)인 노드 6을 포함한다.
계속되는 설명을 위해, 2개의 노드(네트워크 클러스터 1에서 822로 도시된 노드 2 및 네트워크 클러스터 2에서 830으로 도시된 노드 6)가 동일한 사용자(계정)에 속하고 이미 각각 링크-국부 네트워크 클러스터에 등록된 것으로 가정한다. 이 2개의 노드는 동일한 사용자 계정에 속하지만 2개의 서로 다른 클러스터의 일부임에 유의해야 한다. 개시된 에지 아키텍처는 노드 6(830)에 대한 도달 가능한 엔드포인트로서 SEP(808)를 제공하며, 이는 마치 직접 액세스 가능한 것처럼 노드 2(822)와 통신하는 데 사용할 수 있다. 이 두 노드 간의 통신은 SEP(808)를 사용하여 클러스터 간 방식(inter-cluster fashion)으로 수행된다. 시그널링이 확립된 후, BEP(810)는 두 노드(822)와 노드(830) 사이의 교환의 대부분에 제공된다. 시그널링을 분리하는 유연성(flexibility), 및 베어러 채널은 HTTP 기반 서비스 전달에 제한되지 않는 "서비스 특정(service-specific)" BEP를 생성할 수 있다.
앞서 설명한 바와 같이, 노드 간의 탐색, 연결 및 통신의 프로세스는 범위(예: 네트워크)에 속하는 노드에 대한 탐색 요청(새 노드에 의함)을 슈퍼노드(예: 820)에 전송하는 첫 번째 단계를 포함한다. 이 프로세스는 수퍼노드로부터 적절한 시그널링 정보와 함께 노드 목록을 획득하는 단계를 더 포함한다. 이 프로세스는 SEP(예: 806)를 통해 원격 노드(다른 클러스터에 있음)에 요청을 전송하는 단계를 더 포함한다. 이 프로세스는 또한 원격 노드가 서비스를 제공하기 위해 BEP(예: 810)를 요청하도록 하는 것을 포함한다. 이 프로세스는, 프로비저닝된 BEP를 통해 서비스를 소비하기 위해 연결하고 통신하는 단계로 종료된다.
앞서 설명된 바와 같이, 에지 노드 활성화 모듈(426)의 주요 이점 중 하나는 마이크로서비스 개념 및 아키텍처를 사용하여 전형적인 클라이언트 기기에서 프론트엔드 애플리케이션을 개발할 수 있다는 것이다. 마이크로서비스로의 이동은 세 가지 주요 추세에 의해 트리거된다. 첫째, 마이크로서비스는 RESTful API(HTTP REST 기반)를 구현하고 노출한다. 사용하기 쉬운 API 세트는 내부 복잡성을 숨기고 시스템 내의 마이크로서비스 간의 통신을 용이하게 할 수 있다. 둘째, 파이프라인 인프라(예: Jenkins)에 의해 제어되는 배치 스크립트(예: Ansible)를 사용하여 마이크로서비스를 자동으로 배치으로써 잠재적으로 많은 수의 시스템 요소로 구성된 복잡한 시스템을 구축할 수 있다. 또한 자동화된 배치는 배치가 일어나는 곳을 결정할 수 있는 역량을 제공함으로써 유연한 시스템을 구축하는 데 도움이 될 수 있다. 셋째, 간단한 API를 통해 IT 자원(예: CPU, 스토리지 및 네트워크)를 요청하고, 이러한 자원을 거의 실시간으로 얻을 수 있는 역량은 대규모의 확장 가능한 시스템 생성을 더욱 실현 가능하게 한다.
그러나 마이크로서비스 및 에지 클라우드로의 이행은 서로 다른 지식과 전문 지식을 함께 혼합하기 때문에 개발팀이 더 긴밀하게 작업해야 할 수 있다. 예를 들어, 백엔드 개발자의 기술이 필요할 수 있다. 수십억 개의 소규모 클라이언트(예: IoT)를 지원하려면, 중앙 클라우드에 상당한 부담이 있다. 한편으로, 너무 많은 자원이 에지에서 클라이언트의 신호를 기다리는 유휴 상태로 남아 있을 수 있다. 반면에, 때때로, 애플리케이션의 성능 요구를 충족하는 것이 실현 가능하지 않을 수 있다. 예를 들어, 유럽의 클라이언트를 지원하기 위해 미국에서 백엔드 시스템을 배치하면 많은 애플리케이션의 대기 시간 제약 조건을 충족하지 못할 수 있다. 따라서 백엔드 개발자는 이러한 새로운 요구를 지원하는 데 도움이 되도록 클라이언트 자원을 더 잘 활용해야 한다. 애플리케이션을 실행 중인 "클라이언트" 기기에 백엔드 시스템의 일부를 배치해야 하는 경우에도 애플리케이션에 더 가까운 많은 기능을 없애야(offload) 할 수 있다.
이행 구현(transition implementation)에 필요한 또 다른 전문 지식은 IT/DevOps이다. 오랫동안, IT 팀은 솔루션이 배치될 인프라를 파악하고 관리하는 일을 담당해 왔다. 그들은 배치 및 운영 비용, 확장성 및 탄력성과 같은 많은 제약 조건과 파라미터를 고려해야 한다. 대부분의 애플리케이션의 경우, 클라우드 인프라의 범위는 단일 데이터 센터이며, 주요 태스크는 컴퓨팅 및 네트워킹 자원 제약을 해결하는 것이다. 에지에서 폭발적으로 증가하는 기기와 데이터를 지원하려면, IT 자원을 적시에 적절한 장소에 배치하는 것으로 범위를 확장해야 한다(일반적으로 데이터 센터의 범위를 벗어남). 효율적인 배치 및 운영을 보장하기 위해 근접성, 계정 및 링크-국부 프레즌스(link-local presence)와 같은 새로운 범위를 고려해야 한다.
이행 구현에 필요한 또 다른 전문 지식은 프론트엔드 개발자의 전문성이다: 프론트엔드 애플리케이션은 정보를 백엔드에 입력 및 전송하고/하거나 백엔드에서 오는 정보를 렌더링하는 것과 같은, 간단한 태스크를 수행하는 데 사용된다. 복잡한 기능의 대부분은 일반적으로 백엔드 서버로 위임된다. 그러나 에지에서 생성되는 데이터의 폭발적인 증가로 인해, 캐싱, 증강 현실(augmented reality, AR), 이미지 인식, 권한부여 및 인증과 같은 "클라이언트 기기"에서 많은 새로운 기능을 지원해야 한다. 결과적으로, 프론트엔드 애플리케이션은 점점 더 커지고 복잡해지고 있다(예: iOS®의 Facebook® 앱은 2년도 안되어서 300MB 이상으로 크기가 3배 증가했다). 따라서 모놀리식 프론트엔드 앱 설계에서 마이크로서비스 아키텍처로 전환하고 프론트엔드 앱 서브시스템을 마이크로서비스로 분해할 수 있는 기회가 있다. 그러면 앱은 백엔드(중앙 클라우드에서 호스팅됨)에서 실행되는 마이크로서비스와 함께 기기에 국부적인 마이크로서비스를 끊김 없이(seamlessly) 호출할 수 있다.
마이크로서비스 기반 시스템의 많은 결과 중 하나는 다중 테넌시와 단일 테넌시 사이의 선택이다. 공용 클라우드의 주요 이점은, 다수의 애플리케이션이 배치된 공용 클라우드 자원과 마이크로서비스를 공유할 수 있는 멀티 테넌시이다. 그러나 특정 애플리케이션은 보안 또는 데이터 프라이버시와 같은 다양한 이유로 단일 테넌트로 유지해야 하는 마이크로서비스를 배치해야 할 수 있다. 따라서 마이크로서비스가 다중 테넌트인지 단일 테넌트인지를 선택할 수 있는 하이브리드 접근법이 더 나은 접근법일 수 있다.
또 다른 중요한 측면은 마이크로서비스가 단일 사용자인지 다중 사용자인지 여부이다. 언뜻 보기에는 다중 사용자 마이크로서비스가 더 바람직한 것처럼 보일 수 있다. 그러나 항상 그런 것은 아니다. 예를 들어, 마이크로서비스가 "클라이언트 기기" 또는 하나는 클라이언트로서, 다른 하나는 서버로서의 역할하는 한 쌍의 "클라이언트 기기" 내에서 항상 단일 사용자에게 서비스를 제공하는 것이라면, 다중 사용자 플랫폼은 비효율적일 수 있다. 따라서, 마이크로서비스가 다중 사용자인지 단일 사용자인지를 선택할 수 있는 하이브리드 접근법이 더 나은 접근법일 수 있다.
시스템의 복잡성이 증가함에 따라, 이러한 두 가지 측면에 대한 하이브리드 접근법의 이점이 가장 중요해진다. 일 실시예에서, 에지 노드 활성화 모듈(예: 426)은 백엔드, 프론트엔드 및 DevOps에 이익이 되는 하이브리드 접근법의 구현의 용이성과 유연성을 제공하기 위해 처음부터 개발될 수 있다. 이점은 도 9 및 도 10을 참조하여 설명될 것인 바와 같이 개발의 단순성, 유연성, 반복적인 배치 역량 및 확장성을 포함할 수 있다.
도 9는 일 실시예에 따른 사이드카 패턴의 서버리스 마이크로서비스를 사용하여 구현된 예시적인 에지 클라우드 아키텍처(900)를 도시한다. 도시된 바와 같이, 아키텍처(900)는 제3자 애플리케이션 또는 클라이언트 애플리케이션(904)을 실행하는 클라이언트 기기(902)를 포함한다. 클라이언트 기기(902)는 에지 노드 활성화 모듈(922) 및 하나 이상의 국부적으로 호스팅되는 마이크로서비스(926, 928, 930)를 포함한다. 에지 노드 활성화 모듈(922)은 중앙(912) 또는 클라우드 컴퓨팅 기기(914)에서 호스팅되는 API 게이트웨이(908)와 통신하는 API 게이트웨이(924)를 포함한다. 일 실시예에서, 에지 노드 활성화 모듈(922)은 클라이언트 애플리케이션(904)으로부터 요청을 수신하고, 요청을 서비스하는 데 필요한 하나 이상의 마이크로서비스의 유형을 결정한다. 요청이 국부적으로 호스팅돠는 마이크로서비스(예: 926, 928, 930)에 의해 서비스될 수 있으면, API 게이트웨이(924)는 인스턴스화되거나 기동되는 적절한 마이크로서비스에 요청을 전송한다. 국부적으로 호스팅되는 마이크로서비스는 원격 기기로부터 로드되거나 클라이언트 애플리케이션(904)의 요구에 기초하여 동적으로 인스턴스화(런타임으로)될 수 있다. 기동된 마이크로서비스(예: 926)는 요청을 서비스하고 응답을 API 게이트웨이(924)를 통해 클라이언트 애플리케이션(904)에 전송한다.
그러나 요청을 서비스하는 데 필요한 결정된 유형의 마이크로서비스가 전역 성질(global nature)이거나 전역적으로 호스팅되는 마이크로서비스에 대응하는 경우, API 게이트웨이(924)는 API 게이트웨이(908)에 http/https 요청(906)을 전송한다. API 게이트웨이(908)는 http/https 요청(906)을 서비스하기 위해 중앙 클라우드(912)에서 전역적으로 또는 중앙에서 호스팅되는 적절한 마이크로서비스(예: 916, 918, 920)를 기동한다. API 게이트웨이(908)는 API 게이트웨이(924)에 http/https 응답(910)을 전송한다. 도 1과는 대조적으로, 클라이언트 애플리케이션(904)은 에지 노드 활성화 모듈(922)에 의해 노출되는 국부적으로 호스팅된 마이크로서비스와 API 게이트웨이(908)에 의해 노출되는 전역적으로 호스팅된 마이크로서비스를 이용할 수 있다.
일 실시예에서, 백엔드 개발자는 가능한 경우, 다중 사용자 마이크로서비스에서 애플리케이션에 가장 가까운 자원, 즉 프론트엔드 애플리케이션이 실행 중인 동일한 자원에 상주하는 단일 사용자 마이크로서비스로 쉽게 이행할 수 있다. 일 실시예에서, 자원은 애플리케이션이 존재할 때 존재하고 마이크로서비스는 애플리케이션이 에지 노드 활성화 모듈에 의해 제공되는 API 게이트웨이를 통해 요청을 하는 경우에만 존재한다. 이는 다중 사용자 마이크로서비스 개발의 복잡성을 줄이고 중앙 클라우드를 넘어 모든 종류의 에지 자원에 서버리스 마이크로서비스 모델을 가져다준다. 서버리스 마이크로서비스(예: 926)가 RESTful API를 노출하는 한, 마이크로서비스는 도메인 전반에 걸쳐(cross-domain) 활용될 수 있다.
반면 IT/DevOps는 중앙 클라우드에서 관리할 마이크로서비스 수가 적어 복잡성과 운영 비용을 줄이는 데 도움이 된다. 마이크로서비스가 필요한 애플리케이션에 더 가까이 있는 경우(예를 들어 클라이언트 기기(902)에서), 호스팅 비용이 최소화되거나 아예 없는 수평 확장성이 달성된다. 에지의 자원이 중앙 클라우드의 자원와 동일하게(제약 조건은 다르지만) 동일하게 보여서 다른 인프라 지식이 필요하지 않기 때문에 복잡성도 감소한다.
또한, 프론트엔드 애플리케이션 개발자는 백엔드 개발 방법론을 따르고, 도 9에 나타낸 바와 같이, 프론트엔드 애플리케이션의 복잡성을 서버리스 마이크로서비스, 및 사이드카 패턴로 분해할 수 있다. 에지 노드 활성화 모듈(예: 426, 508, 922)을 사용한 애플리케이션 개발은, 개발자가 애플리케이션이 활성 상태인 위치를 결정하고 노드의 클러스터, 즉 클러스터 내의 중앙 클라우드, 국부 기기 또는 클러스터 내의 다른 기기 내에서, 실행해야 하는 마이크로서비스를 결정할 수 있는 유연성을 제공한다. 결과적으로, 개발자는 일반적으로 모놀리식 블록으로 작성되는 클라이언트 애플리케이션을 마이크로서비스로 나누고 백엔드 개발에서 일반적인 마이크로서비스 아키텍처의 모든 이점, 즉, 확장성, 유연성, 기술의 선택, 다른 모듈 또는 기능에 미치는 격리된 영향, 배치의 용이성 등을 즐길 수 있는 더 많은 옵션을 갖게 된다.
도 10은 일 실시예에 따라 국부적으로 및 전역적으로 호스팅되는 마이크로서비스를 이용하는 애플리케이션을 위한 예시적인 서버리스 마이크로서비스(1000)를 도시한다. 도 1 및 도 2에 도시된 중앙 클라우드 접근법과 달리, 클라이언트 애플리케이션은 중앙 클라우드의 API 게이트웨이에 요청을 할 수 있을 뿐만 아니라 동일한 기기에 국부적으로 요청할 수 있다. 다시 말해, 애플리케이션은 국부적인 기능을 위해 국부적으로 호스팅되고 국부적으로 호스팅될 수 없는 기능을 위해 중앙 클라우드에서 전역적으로 호스팅되는 마이크로서비스를 활용할 수 있다. 이 개념은 클라이언트 간 통신의 예의 경우, 도 10에 도시된 바와 같이 다수의 기기와 에지 노드로 확장될 수 있다.
도시된 바와 같이, 아키텍처(1000)는 제3자 애플리케이션 또는 클라이언트 애플리케이션(1004 및 1040)을 각각 실행하는 2개의 클라이언트 기기(1002, 1038)를 포함한다. 클라이언트 기기(1002, 1038)는 각각 에지 노드 활성화 모듈(1022, 1042)을 포함한다. 각각의 클라이언트 기기는 하나 이상의 마이크로서비스를 국부적으로 호스팅한다. 예를 들어, 클라이언트 기기(1002)는 마이크로서비스(1026, 1028, 1030)를 호스팅한다. 마찬가지로, 클라이언트 기기(1038)는 마이크로서비스(1046, 1048, 1050)를 호스팅한다. 에지 노드 활성화 모듈(1022)은 중앙(1012)에 호스팅되는 API 게이트웨이(1008)와 통신하도록 구성된 API 게이트웨이(1024)를 포함한다. 일 실시예에서, 에지 노드 활성화 모듈(1022)은 클라이언트 애플리케이션(1004)로부터 요청(1020)을 수신하고 요청을 처리하는 데 필요한 하나 이상의 마이크로서비스 유형을 결정한다. 결정된 유형이 하나 이상의 국부적으로 호스팅되는 마이크로서비스(예: 1026, 1028, 1030)에 대응하면, API 게이트웨이(1024)는 서비스 요청(1032)을 인스턴스화되거나 기동되는 적절한 마이크로서비스에 전송한다. 일 실시예에서, 국부적으로 호스팅되는 마이크로서비스는 원격 기기로부터 로드될 수 있거나 클라이언트 애플리케이션(1004)으로부터의 요구에 기초하여 인스턴스화될 수 있다. 마이크로서비스(예를 들어, 1026)는 요청을 서비스하고, API 게이트웨이 1024.
그러나 요청을 서비스하는 데 필요한 결정된 유형의 마이크로서비스가 전역적 성격이거나 전역적으로 호스팅된 마이크로서비스에 대응하면, API 게이트웨이(1024)는 API 게이트웨이(1008)에 http/https 요청(1006)을 전송한다. API 게이트웨이(1008)는 요청을 서비스하기 위해 중앙 클라우드(1012)에서 전역적으로 또는 집중적으로 호스팅되는 적절한 마이크로서비스(예: 1014, 1016, 1018)를 기동할 수 있다. API 게이트웨이(1008)는 API 게이트웨이(1024)에 http/https 응답(1010)을 전송한다.
일 실시예에서, 에지 노드 활성화 모듈(1022)은 요청(1020)을 서비스하는 데 필요한 하나 이상의 마이크로서비스의 유형이 다른 클라이언트 기기(예: 1038)에서 호스팅되는 마이크로서비스에 대응한다고 결정한다. 에지 노드 활성화 모듈(1022)은 API 게이트웨이(1042)와의 직접 통신을 가능하게 한다. 또 다른 실시예에서, 에지 노드 활성화 모듈(1022)은 1030과 1046 사이의 마이크로서비스 간 직접적인 마이크로서비스 통신을 가능하게 한다. 예를 들어, 마이크로서비스(1030)는 데이터 요청(1034)을 마이크로서비스(1046)에 전송한다. 마이크로서비스(1046)는 데이터 요청을 서비스하고 응답(1036)을 마이크로서비스(1030)에 전송한다. 에지 기기가 클라이언트로만 작동하는 도 2에 도시된 중앙 클라우드 접근법과 달리, 위에서 설명한 바와 같이 에지 기기/클라이언트 기기 간에 직접(또는 중앙 클라우드의 서버를 통해) 클라이언트 간 통신이 발생할 수 있다. 이를 통해 개발자는 클라우드 호스팅 비용, 대기 시간, 대역폭 사용량, 데이터 프라이버시 및 전형적인 백엔드 기능을 위한 마이크로서비스 아키텍처와 함께 제공되는 기타 모든 이점과 같은, 배치의 모든 측면을 최적화할 기회를 얻을 수 있다.
결과적으로, 에지 노드 활성화 모듈의 개시된 실시예는 동일한 모델 및 API를 사용하여 온디맨드 IT 자원의 개념을 에지까지 끊김 없이(seamlessly) 확장함으로써 개발자에게 이익이 된다. 클러스터링의 개념은 사용자 계정, 근접성 및 네트워크와 같은 새로운 클러스터 범위를 추가함으로써 더욱 확장된다. 에지에서 국부적인지 중앙 클라우드에서 전역적인지를 API 게이트웨이, 보안 및 다른 마이크로서비스와의 통신을 위한 라우팅을 에지에 사이드카 패턴을 제공함으로써 서비스 메시의 개념을 더욱 확장한다.
일 실시예에서, 에지 노드 활성화 모듈(예: 426, 508, 922, 1022)을 사용하여 애플리케이션을 개발하면 개발자가 더 많은 옵션, 단순성 및 유연성을 가질 수 있다. 솔루션 개발자는 솔루션 비즈니스 로직을 기반으로 데이터가 있는 위치를 결정할 수 있다. 결과적으로, 여기에 개시되는 것은 현재 사용되지 않거나 심각하게 활용되지 않는 에지 자원을 활용하는 수십 배 이상의 처리 능력, 스토리지 및 메모리로 에지 클라우드를 구축하는 실용적인 접근법이다. 이를 통해 수십 배 더 크고 저렴하며 더 빠르고 모든 소비자 및 기업 애플리케이션에 더 나은 데이터 프라이버시를 제공할 수 있는 클라우드 패브릭을 생성할 수 있다.
도 11은 클라우드 컴퓨팅 인프라 또는 플랫폼을 제공하는 방법(1100)의 예시적인 실시예를 도시한다. 도 1 내지 도 10을 참조하면, 에지 클라우드 컴퓨팅 인프라는 서버 컴퓨팅 기기(예: 312)와 통신하는 하나 이상의 에지 클라우드 컴퓨팅 기기(예: 302, 304)를 포함하는 통신 네트워크(예: 에지 클라우드 컴퓨팅 네트워크(300))에서 구현된다.
이 방법은 단계 1102에서와 같이, 제1 에지 클라우드 컴퓨팅 기기(예: 404, 500)가, 에지 노드 활성화 모듈(예: 422, 508)을 실행하는 단계를 포함한다. 일 실시예에서, 에지 노드 활성화 모듈은 제1 에지 클라우드 컴퓨팅 기기에 의해 다운로드 가능한 소프트웨어 레벨 애플리케이션이다. 이 방법은 단계 1104에서와 같이, 제1 에지 클라우드 컴퓨팅 기기가, 다른 에지 클라우드 컴퓨팅 기기와 연관된 운영 체제 및 네트워크에 독립적인 다른 에지 클라우드 컴퓨팅 기기(예: 310)를 동적으로 탐색하는 단계를 더 포함한다. 이 방법은 단계 1106에서와 같이, 제1 에지 클라우드 컴퓨팅 기기가 탐색된 다른 에지 클라우드 컴퓨팅 기기(예: 310)의 자원 가용성, 능력 및 기능을 노출하는 단계를 더 포함한다. 이 방법은 단계 1108에서와 같이, 제1 에지 클라우드 컴퓨팅 기기가, 탐색된 다른 에지 클라우드 컴퓨팅 기기의 하나 이상의 클러스터(예: 722, 732)를 형성 및 조직하는 단계를 더 포함한다. 이 방법은 또한 단계 1110에서와 같이, 제1 에지 클라우드 컴퓨팅 기기가, 하나 이상의 클러스터 내에서 그리고 하나 이상의 클러스터에 걸쳐 통신하는 단계를 포함한다.
일 실시예에서, 이 방법은 에지 노드 활성화 모듈(예: 422)을 실행한 후에, 제1 에지 클라우드 컴퓨팅 기기가, 슈퍼 에지 클라우드 컴퓨팅 기기(또는 슈퍼노드)를 검색하는 단계를 더 포함한다. 앞서 설명한 것처럼 슈퍼 에지 클라우드 컴퓨팅 기기는 전역적 탐색을 관리하도록 구성된다. 이 방법은 검색하는 동안 슈퍼 에지 클라우드 컴퓨팅 기기를 발견하지 못하는 경우, 제1 에지 클라우드 컴퓨팅 기기가 자신을 슈퍼 에지 클라우드 컴퓨팅 기기로 지정하는 단계를 더 포함한다. 다른 실시예에서, 이 방법은 제1 에지 클라우드 컴퓨팅 기기가, 그 존재의 전역적 탐색을 통신하는 단계 및 제1 에지 클라우드 컴퓨팅 기기가, 제1 에지 클라우드 컴퓨팅 기기의 범위 내에서 하나 이상의 에지 클라우드 컴퓨팅 기기의 목록을 수신하는 단계를 포함한다.
또 다른 실시예에서, 이 방법은 제1 에지 클라우드 컴퓨팅 기기가, 하나 이상의 클러스터에 후속적으로 진입하는 하나 이상의 에지 클라우드 컴퓨팅 기기로부터 등록 요청을 수신하는 단계를 더 포함한다. 이 방법은 또한 제1 에지 클라우드 컴퓨팅 기기가, 등록된 하나 이상의 에지 클라우드 컴퓨팅 기기에 제1 에지 클라우드 컴퓨팅 기기의 범위 내에서 하나 이상의 다른 에지 클라우드 컴퓨팅 기기의 목록을 전송하는 단계를 포함한다.
도 12는 클라우드 컴퓨팅 인프라 또는 플랫폼을 제공하는 방법(1200)의 예시적인 실시예를 도시한다. 도 1∼도 11을 참조하면, 에지 클라우드 컴퓨팅 인프라는 서버 컴퓨팅 기기(예: 312)와 통신하는 하나 이상의 에지 클라우드 컴퓨팅 기기(예: 302, 304, 500, 902, 1002)를 포함하는 통신 네트워크(예: 에지 클라우드 컴퓨팅 네트워크(300))에서 구현된다.
이 방법은 제1 에지 클라우드 컴퓨팅 기기(예: 902, 1002)에 의해 수행되며, 단계 1202에서와 같이, 제1 에지 클라우드 컴퓨팅 기기에서 실행 중인 클라이언트 애플리케이션(예: 904, 1004)의 요청에 대응하는 마이크로서비스 유형을 결정하는 단계를 포함한다. 이 방법은 단계 1204에서와 같이, 마이크로서비스의 유형이 전역적인지를 판정하는 단계를 더 포함한다. 다시 말해, 클라이언트 애플리케이션의 요청은 전역적으로 또는 집중적으로 호스팅되는 마이크로서비스(예: 916, 918, 920, 1014, 1016)에 의해서만 서비스될 수 있다. 단계 1204의 긍정적인 결정에 대해, 제1 에지 클라우드 컴퓨팅 기기는 단계 1206에서와 같이, http/https 요청(예: 906,1006)을 중앙 클라우드(912, 1012)의 API 게이트웨이(예: 908, 1008)로 전송한다. 이 방법은 단계 1208에서와 같이, 전역적으로 호스팅되는 마이크로서비스(예: 916, 1014)를 기동하고 응답(예: http/https 응답(910, 1010))을 제1 에지 클라우드 컴퓨팅 기기에 회신하는 단계를 더 포함한다.
단계 1204의 부정적인 결정에 대해, 이 방법은 단계 1210에서와 같이, 클라이언트 애플리케이션의 요청에 대응하는 마이크로서비스의 유형이 국부적인지 여부를 판정하는 단계를 더 포함한다. 그렇다면(국부적이면), 이 방법은 단계 1212에서와 같이, 국부적으로 호스팅되는 마이크로서비스(예: 1026, 926)를 기동하여 요청을 처리하는 단계를 더 포함한다. 그렇지 않으면, 이 방법은 단계 1214에서와 같이, 다른 (제2) 에지 클라우드 컴퓨팅 기기(예: 1038)에서 호스팅되는 마이크로서비스에 직접 요청을 전송하는 단계를 포함한다. 이 방법은 다른(제2) 에지 클라우드 컴퓨팅 기기(1038)에서 호스팅되는 마이크로서비스(예: 1046)를 기동하고 요청에 대한 응답을 회신하는 단계를 더 포함한다.
여기에 설명된 바와 같이, 에지 노드 활성화 모듈은 에지 클라우드 컴퓨팅 기기 또는 클라이언트 기기가 마이크로서비스를 동적으로 생성하거나 국부적으로 인스턴스화할 수 있게 한다. 에지 노드 활성화 모듈은 또한 주어진 클러스터 또는 클러스터에 걸쳐 존재하는 다른 에지 노드를 검색하고 검색된 에지 노드에서 호스팅되는 하나 이상의 마이크로서비스를 노출한다. 이러한 방식으로 임의의 에지 노드는 "서버" 또는 "클라이언트"의 역할을 할 수 있으며 클라이언트 애플리케이션으로부터의 주어진 요청은 서비스 요청의 요구(유형)에 따라 국부적으로 또는 전역적으로 또는 다른 에지 노드에 의해 서비스될 수 있다.
일 실시예에서, 이 서버 컴퓨팅 기기는, 하나 이상의 에지 클라우드 컴퓨팅 기기를 지원하기 위한 하나 이상의 백엔드 서비스를 제공하도록 구성된 백엔드 서비스 모듈을 포함한다. 하나 이상의 백엔드 서비스는, 하나 이상의 에지 클라우드 컴퓨팅 기기의 하나 이상의 클러스터를 형성하기 위한 지식을 제공하도록 구성된 탐색 서비스를 포함하며, 하나 이상의 클러스터 각각은 적어도 하나의 슈퍼 에지 클라우드 컴퓨팅 기기를 포함한다. 백엔드 서비스는 탐색 서비스로부터 요청을 수신하면 하나 이상의 클러스터에 대한 시그널링 엔드포인트(SEP) 및 베어러 엔드포인트(BEP)를 동적으로 배치하도록 구성된 시그널링 서비스를 더 포함한다. 백엔드 서비스는 하나 이상의 클러스터 내의 제1 에지 클라우드 컴퓨팅 기기에서 마이크로서비스에 토큰을 전달하고, 하나 이상의 클러스터 내의 제2 에지 클라우드 컴퓨팅 기기에서 다른 마이크로서비스에 요청을 하도록 구성된 서버 토큰 서비스를 더 포함한다.
일 실시예에서, 하나 이상의 백엔드 서비스는, 하나 이상의 에지 클라우드 컴퓨팅 기기의 인증 프로파일을 생성 및 유지하도록 구성된 신원확인 서비스를 더 포함한다. 하나 이상의 백엔드 서비스는, 하나 이상의 클러스터에서 제공되는 모든 마이크로서비스의 목록 및 연관된 클러스터 정보를 유지하도록 구성된 등록 서비스를 더 포함한다. 일 실시예에서, 등록 서비스는 추가로, 하나 이상의 클러스터가 구성 목적으로 자체 관리될 수 있도록 하나 이상의 클러스터의 클러스터 지식을 유지하도록 구성된다. 일 실시예에서, 등록 서비스는 추가로, 하나 이상의 백엔드 서비스에 의해 사용될 클러스터의 지리적 위치 목록 및 연관된 구성 세부사항을 제공하도록 구성된다.
일 실시예에서, 하나 이상의 클러스터를 형성하기 위한 지식은, 하나 이상의 클러스터의 프로파일, 하나 이상의 클러스터를 형성하는 하나 이상의 에지 클라우드 컴퓨팅 기기와 연관된 컴퓨팅 자원의 세부사항, 하나 이상의 클러스터를 형성하는 하나 이상의 에지 클라우드 컴퓨팅 기기의 상태 및/또는 위치, 하나 이상의 클러스터를 형성하는 하나 이상의 에지 클라우드 컴퓨팅 기기에서 이용 가능한 하나 이상의 마이크로서비스, 하나 이상의 클러스터를 형성하는 각각의 에지 클라우드 컴퓨팅 기기에 도달하기 위한 종단 간 네트워크 토폴로지, 및 하나 이상의 클러스터의 도달 가능성을 포함한다. 일 실시예에서, 탐색 서비스는 추가로, 통신 네트워크에서 이용 가능한 자원과 연관된 정보를 제공하여 실시간으로 통신 네트워크 내의 임의의 이용 가능한 에지 클라우드 컴퓨팅 기기에 하나 이상의 마이크로서비스를 동적으로 배치하도록 구성된다. 일 실시예에서, 신원확인 서비스는, 각각의 에지 클라우드 컴퓨팅 기기의 에지 노드 활성화 모듈, 에지 노드 활성화 모듈을 사용하는 마이크로서비스, 에지 노드 활성화 모듈을 사용하는 애플리케이션 개발자, 및 에지 노드 활성화 모듈에 의해 지원되는 애플리케이션의 최종 사용자 중 하나 이상에 대한 토큰을 생성 및 유지하도록 구성된다.
에지 노드 컴퓨팅 기기의 실시예가 개시된다. 일 실시예에서, 에지 노드 컴퓨팅 기기는, 제1 파라미터 세트에 기초하여 하나 이상의 다른 에지 클라우드 컴퓨팅 기기를 탐색하여 그 사이에 연결을 확립하도록 구성된 에지 노드 활성화 모듈을 포함한다. 에지 노드 활성화 모듈은 추가로, 하나 이상의 에지 클라우드 컴퓨팅 기기 사이에 확립된 연결과 연관된 하나 이상의 마이크로서비스를 실행하기 위한 마이크로서비스 런타임 환경을 제공하도록 구성된다. 일 실시예에서, 에지 노드 활성화 모듈은 하나 이상의 에지 클라우드 컴퓨팅 기기와 연관된 운영 체제 및/또는 네트워크 유형에 관계없이 하나 이상의 에지 클라우드 컴퓨팅 기기의 존재를 탐색하도록 구성된다. 에지 노드 활성화 모듈은 추가로, 하나 이상의 에지 클라우드 컴퓨팅 기기와 연관된 능력 및 거동을 탐색하고 하나 이상의 에지 클라우드 컴퓨팅 기기에 의해 지원되는 하나 이상의 마이크로서비스를 탐색하도록 구성된다. 일 실시예에서, 제1 파라미터 세트는, 하나 이상의 에지 클라우드 컴퓨팅 기기 각각과 연관된 사용자 계정, 하나 이상의 에지 클라우드 컴퓨팅 기기와 연관된 네트워크, 및 하나 이상의 에지 클라우드 컴퓨팅 기기의 근접성을 포함한다.
에지 노드 활성화 모듈은 하나 이상의 에지 클라우드 컴퓨팅 기기와 함께 하나 이상의 클러스터를 동적으로 형성하고 마이크로서비스 레벨에서 하나 이상의 에지 클라우드 컴퓨팅 기기와 직접 또는 다른 에지 클라우드 컴퓨팅 기기를 통해 통신하도록 추가로 구성된다.
에지 노드 활성화 모듈은 추가로, 하나 이상의 에지 클라우드 컴퓨팅 기기로 하나 이상의 클러스터를 동적으로 형성하고, 마이크로서비스 레벨에서 하나 이상의 에지 클라우드 컴퓨팅 기기와 직접 또는 하나 이상의 클러스터에 걸쳐 다른 에지 클라우드 컴퓨팅 기기를 통해 통신하도록 구성된다. 일 실시에에서, 에지 노드 활성화 모듈은 추가로, 탐색된 하나 이상의 에지 클라우드 컴퓨팅 기기가 데이터, 서비스, 및/또는 자원을 공유하기로 선택한 경우 탐색된 하나 이상의 에지 클라우드 컴퓨팅 기기와 연결하도록 구성된다. 에지 노드 활성화 모듈은 추가로, 공통의 내장형 웹 서버를 통해 하나 이상의 마이크로서비스 서비스를 노출하도록 구성된다. 일 실시예에서, 각각의 마이크로서비스에 대한 하나 이상의 API 엔드포인트는 API 게이트웨이를 통해 클러스터의 하나 이상의 에지 클라우드 컴퓨팅 기기로부터 액세스할 수 있다. 에지 노드 활성화 모듈은 추가로, 하나 이상의 에지 클라우드 컴퓨팅 기기와 연관된 각각의 컴퓨팅 환경에 적어도 부분적으로 기초하여 유연한 컨테이너 능력(flexible container capability)을 제공하도록 추가로 구성된다. 각각의 컴퓨팅 환경은 컨테이너 데몬을 실행하여 하나 이상의 마이크로서비스를 다운로드, 배치 및 운영한다.
일 실시예에서, 컴퓨팅 환경은 하나 이상의 에지 클라우드 컴퓨팅 기기의 애드혹 클러스터를 관리하기 위해 컨테이너 데몬을 실행한다. 에지 노드 활성화 모듈은 내부에 내장된 웹 서버를 더 포함한다. 웹 서버는 에지 클라우드 컴퓨팅 기기와 연관된 운영 체제를 기반으로 특정 언어를 사용하여 컨테이너 관리 API를 제공하도록 구성된다. 에지 노드 활성화 모듈은 하나 이상의 소프트웨어 라이브러리 및 대응하는 API를 더 포함한다.
서버 컴퓨팅 기기의 실시예가 개시된다. 실시예는 서버 컴퓨팅 기기와 통신하는 하나 이상의 에지 클라우드 컴퓨팅 기기를 포함하는 통신 네트워크에 관한 것이다. 일 실시예에서, 서버 컴퓨팅 기기는 하나 이상의 에지 클라우드 컴퓨팅 기기를 지원하기 위한 하나 이상의 서비스를 제공하도록 구성된 백엔드 서비스 모듈을 포함한다. 하나 이상의 백엔드 서비스는, 하나 이상의 에지 클라우드 컴퓨팅 기기의 하나 이상의 클러스터를 형성하기 위한 지식을 제공하도록 구성된 탐색 서비스를 포함하며, 하나 이상의 클러스터 각각은 적어도 하나의 슈퍼 에지 클라우드 컴퓨팅 기기(또는 슈퍼 노드)를 포함한다. 하나 이상의 백엔드 서비스는 탐색 서비스로부터 요청을 수신하면 하나 이상의 클러스터에 대한 시그널링 엔드포인트(SEP) 및 베어러 엔드포인트(BEP)를 동적으로 배치하도록 구성된 시그널링 서비스를 더 포함한다. 하나 이상의 백엔드 서비스는 하나 이상의 클러스터의 인증 프로파일을 생성 및 유지하도록 구성된다. 제1 에지 클라우드 컴퓨팅 기기에서 마이크로서비스에 토큰을 전달하고, 하나 이상의 클러스터 내의 제2 에지 클라우드 컴퓨팅 기기에서 다른 마이크로서비스에 요청을 하도록 구성된 서버 토큰 서비스를 더 포함한다.
일단 제1 클러스터가 형성되면, 탐색 서비스는 제1 클러스터의 일부가 아닌 새로운 에지 클라우드 컴퓨팅 기기가 제1 클러스터에 대응하는 슈퍼 에지 클라우드 컴퓨팅 기기에 등록하는 것을 허용하도록 구성된다. 일 실시예에서, 탐색 서비스는 추가로, 각각의 슈퍼 에지 클라우드 컴퓨팅 기기가 자신을 등록하는 것을 허용하도록 구성된다. 일 실시예에서, 하나 이상의 클러스터를 형성하기 위한 지식은 하나 이상의 클러스터의 프로파일, 하나 이상의 클러스터를 형성하는 하나 이상의 에지 클라우드 컴퓨팅 기기와 연관된 컴퓨팅 자원의 세부사항, 하나 이상의 클러스터를 형성하는 하나 이상의 에지 클라우드 컴퓨팅 기기의 상태 & 위치, 하나 이상의 클러스터를 형성하는 하나 이상의 에지 클라우드 컴퓨팅 기기에서 이용 가능한 하나 이상의 서비스, 하나 이상의 클러스터를 형성하는 각각의 에지 클라우드 컴퓨팅 기기에 도달하기 위한 종단 간 네트워크 토폴로지, 및 하나 이상의 클러스터에 대한 도달 가능성을 포함한다.
다른 실시예에서, 탐색 서비스는 추가로, 실시간으로 통신 네트워크 내의 임의의 이용 가능한 에지 클라우드 컴퓨팅 기기에 하나 이상의 서비스를 동적으로 배치하기 위해 통신 네트워크에서 이용 가능한 자원과 연관된 정보를 제공하도록 구성된다. 또 다른 실시예에서, 시그널링 서비스는 하나 이상의 클러스터 내의 컴퓨팅 자원에 대한 요구에 기초하여 시그널링 엔드포인트(SEP) 및 베어러 엔드포인트(BEP)를 동적으로 배치하도록 구성된다.
또 다른 실시예에서, 시그널링 엔드포인트(SEP)는 시그널링 통신에 사용되고 베어러 엔드포인트(BEP)는 데이터 통신에 사용된다. 시그널링 엔드포인트(SEP) 및 베어러 엔드포인트(BEP)의 동적 배치는 하나 이상의 클러스터에 있는 하나 이상의 에지 클라우드 컴퓨팅 기기에 대한 시그널링 대역폭 및 데이터 대역폭을 증가시킨다. 시그널링 서비스는 추가로, 하나 이상의 파라미터에 기초하여 시그널링 엔드포인트(SEP) 및 베어러 엔드포인트(BEP)를 동적으로 배치하도록 구성된다. 하나 이상의 파라미터는 하나 이상의 서비스에 대한 라이브 시작 시간, 하나 이상의 클러스터에서의 동시 연결의 수, 및 하나 이상의 클러스터에서 하나 이상의 에지 클라우드 컴퓨팅 기기와 연관된 하나 이상의 통신 프로토콜을 포함한다.
일 실시예에서, 시그널링 서비스는 추가로, 하나 이상의 클러스터의 가장 근접성 내에서 이용 가능한 에지 클라우드 컴퓨팅 기기에 시그널링 엔드포인트(SEP) 및 베어러 엔드포인트(BEP)를 동적으로 배치하도록 성된다. 신원확인 서비스는, 신원확인 서비스는, 각각의 에지 클라우드 컴퓨팅 기기의 에지 노드 활성화 모듈, 에지 노드 활성화 모듈을 사용하는 마이크로서비스, 에지 노드 활성화 모듈을 사용하는 애플리케이션 개발자, 및 에지 노드 활성화 모듈에 의해 지원되는 애플리케이션의 최종 사용자 중 하나 이상에 대한 토큰을 생성 및 유지하도록 구성된다. 또 다른 실시예에서, 신원확인 서비스는 토큰 보유자의 자격 증명 및 합법성을 검증하고 백엔드 서비스 모듈에 의해 제공되는 하나 이상의 서비스에 대한 토큰 보유자의 액세스를 승인하도록 구성된다.
에지 클라우드 컴퓨팅 인프라(또는 플랫폼)를 제공하는 방법의 실시예가 개시된다. 이 방법은 서버 컴퓨팅 기기 또는 중앙 클라우드와 통신하는 하나 이상의 에지 클라우드 컴퓨팅 기기를 포함하는 통신 네트워크에서 구현된다. 이 방법은 제1 에지 클라우드 컴퓨팅 기기가, 에지 노드 활성화 모듈을 실행하는 단계를 포함한다. 이 방법은 제1 에지 클라우드 컴퓨팅 기기가, 다른 에지 클라우드 컴퓨팅 기기와 연관된 네트워크 및 운영 체제와 무관한 다른 에지 클라우드 컴퓨팅 기기를 동적으로 탐색하는 단계를 더 포함한다. 이 방법은 제1 에지 클라우드 컴퓨팅 기기에 의해 탐색된 다른 에지 클라우드 컴퓨팅 기기의 자원 가용성, 능력 및 기능을 노출하는 단계를 더 포함한다. 이 방법은 제1 에지 클라우드 컴퓨팅 기기가, 탐색된 다른 에지 클라우드 컴퓨팅 기기의 하나 이상의 클러스터를 형성 및 조직하는 단계를 더 포함한다. 이 방법은 또한 제1 에지 클라우드 컴퓨팅 기기가, 하나 이상의 클러스터 내에서 그리고 하나 이상의 클러스터에 걸쳐 통신하는 단계를 포함한다.
일 실시예에서, 이 방법은 에지 노드 활성화 모듈을 실행하는 것에 후속하여, 제1 에지 클라우드 컴퓨팅 기기가, 슈퍼 에지 클라우드 컴퓨팅 기기(진행 중인 설명에서 "수퍼노드"로도 지칭됨)를 검색하는 단계를 포함한다. 슈퍼 에지 클라우드 컴퓨팅 기기는 노드 또는 에지 클라우드 컴퓨팅 기기의 전역적 탐색을 관리하도록 구성된다.
검색하는 동안 슈퍼 에지 클라우드 컴퓨팅 기기를 찾지 못한 경우, 이 방법은 제1 에지 클라우드 컴퓨팅 기기가, 자신을 슈퍼 에지 클라우드 컴퓨팅 기기로 지정하는 단계를 더 포함한다. 이 방법은 제1 에지 클라우드 컴퓨팅 기기가, 그 존재의 전역적 탐색을 통신(전달)하고 제1 에지 클라우드 컴퓨팅 기기가, 제1 에지 클라우드 컴퓨팅 기기의 범위 내에서 하나 이상의 에지 클라우드 컴퓨팅 기기의 목록을 수신하는 단계를 더 포함한다. .
이 방법은 제1 에지 클라우드 컴퓨팅 기기가, 하나 이상의 클러스터에 후속적으로 진입하는 하나 이상의 에지 클라우드 컴퓨팅 기기로부터 등록 요청을 수신하고, 제1 에지 클라우드 컴퓨팅 기기가, 등록된 하나 이상의 에지 클라우드 컴퓨팅 기기에 제1 에지 클라우드 컴퓨팅 기기의 범위 내에서 및/또는 등록된 하나 이상의 에지 클라우드 컴퓨팅 기기의 범위 내에서 하나 이상의 다른 에지 클라우드 컴퓨팅 기기의 목록 송신하는 단계를 더 포함한다.
여기서 청구범위 및 명세서에서 사용된 용어 "포함하는(comprising, including)", 및 "갖는(having)"은 지정되지 않은 다른 요소를 포함할 수 있는 열린 그룹을 나타내는 것으로 간주되어야 한다. "일(영어의 관사 a, an)"이라는 용어 및 단수 형태의 단어는 동일한 단어의 복수 형태를 포함하는 것으로 간주되어, 용그 용어가 하나 이상의 무언가가 제공됨을 의미한다. "하나(one)" 또는 "단일(single)"이라는 용어는 하나 및 어떤 것 중 하나만이 의도되었음을 나타내는 데 사용할 수 있다. 유사하게, "두 개(two)"와 같은 다른 특정 정수 값은 특정 수의 사물이 의도될 때 사용될 수 있다. "바람직하게(preferably)", "바람직한(preferred)", "선호하는(prefer)", "선택적으로(optionally)", "할 수 있는(may)"이라는 용어 및 유사한 용어는 참조되는 항목, 조건 또는 단계가 본 발명의 선택적(필수 아님) 특징임을 나타내는 데 사용된다.
본 발명은 다양한 특징 및 바람직한 실시예 및 기술을 참조하여 설명되었다. 그러나 본 발명의 사상 및 범위 내에서 많은 변형 및 수정이 이루어질 수 있음을 이해해야 한다. 여기에 구체적으로 기재된 것 이외의 방법, 기기, 기기 요소, 재료, 절차 및 기술이 과도한 실험에 의존하지 않고 여기에 광범위하게 개시된 바와 같은 본 발명의 실시에 적용될 수 있음이 당업자에게 명백할 것이다. 여기에 기재된 방법, 기기, 기기 요소, 재료, 절차 및 기술의 모든 공지된 기능적 등가물은 본 발명에 포함되는 것으로 의도된다. 범위가 공개될 때마다, 모든 하위 범위와 개별 값이 포함되는 것으로 의도된다. 본 발명은 도면에 도시되거나 명세서에 예시된 것을 포함하는 개시된 실시예에 의해 한정되지 않으며, 이는 한정이 아닌 예시로서 제공된다.
본 발명은 본 개시의 이점을 갖는 한정된 수의 실시예와 관련하여 설명되었지만, 당업자는 여기에 개시된 바와 같은 발명의 범위를 벗어나지 않는 다른 실시예가 고안될 수 있음을 이해할 것이다. 따라서, 본 발명의 범위는 첨부된 청구범위에 의해서만 제한되어야 한다.
본 출원 전반에 걸친 모든 참조, 예를 들어 발행되거나 부여된 특허 또는 등가물을 포함하는 특허 문서, 특허 출원 간행물, 비특허 문헌 또는 기타 소스 자료는 각 참조가 본 출원의 개시 내용과 적어도 부분적으로 일치하지 않는 한, 참조에 의해 개별적으로 포함되는 것처럼, 그 전체가 참조에 의해 여기에 포함된(예를 들어, 부분적으로 일치하지 않는 참조는 참조의 부분적으로 일치하지 않는 부분을 제외하고 참조에 의해 통합됨).

Claims (37)

  1. 에지 클라우드 컴퓨팅 기기로서,
    에지 노드 활성화 모듈(edge node activation module)을 포함하고,
    상기 에지 노드 활성화 모듈은,
    상기 에지 클라우드 컴퓨팅 기기에서 실행 중인 애플리케이션으로부터 요청을 수신하고;
    수신된 요청을 서비스하는 데 필요한 하나 이상의 마이크로서비스의 유형을 결정하고;
    결정된 유형이 상기 에지 클라우드 컴퓨팅 기기에서 국부적으로 호스팅되는(locally hosted) 하나 이상의 마이크로서비스에 대응하는 경우 상기 요청을 상기 에지 클라우드 컴퓨팅 기기에서 국부적으로 처리하도록 구성되는,
    에지 클라우드 컴퓨팅 기기.
  2. 제1항에 있어서,
    상기 에지 노드 활성화 모듈은 추가로, 상기 국부적으로 호스팅되는 하나 이상의 마이크로서비스를 실행하기 위한 마이크로서비스 런타임 환경(microservice runtime environment)을 제공하도록 구성되는, 에지 클라우드 컴퓨팅 기기.
  3. 제1항에 있어서,
    상기 에지 노드 활성화 모듈은 추가로, 상기 국부적으로 호스팅되는 하나 이상의 마이크로서비스에 요청을 전송하기 위한 국부적으로 호스팅되는 API 게이트웨이를 제공하도록 구성되는, 에지 클라우드 컴퓨팅 기기.
  4. 제1항에 있어서,
    상기 하나 이상의 마이크로서비스는 상기 요청을 서비스하고 상기 애플리케이션에 대한 응답을 돌려주도록 구성되는, 에지 클라우드 컴퓨팅 기기.
  5. 제1항에 있어서,
    상기 에지 노드 활성화 모듈은 추가로, 상기 수신된 요청을 서비스하는 데 필요한, 상기 결정된 유형의 하나 이상의 마이크로서비스가 중앙 클라우드 컴퓨팅 기기에서 전역적으로 호스팅되는(globally hosted) 하나 이상의 마이크로서비스에 대응하는 경우, 상기 애플리케이션으로부터 수신된 요청에 대응하는 http/https 요청을 상기 중앙 클라우드 컴퓨팅 기기에서 호스팅되는 API 게이트웨이에 전송하도록 구성되는, 에지 클라우드 컴퓨팅 기기.
  6. 제5항에 있어서,
    상기 에지 노드 활성화 모듈은 추가로, 상기 중앙 클라우드 컴퓨팅 기기에서 호스팅되는 API 게이트웨이로부터 상기 http/https 요청에 대한 http/https 응답을 수신하도록 구성되고, 상기 http/https 요청은 상기 중앙 클라우드 컴퓨팅 기기에서 전역적으로 호스팅되는 하나 이상의 마이크로서비스에 의해 서비스되는, 에지 클라우드 컴퓨팅 기기.
  7. 제5항에 있어서,
    상기 에지 노드 활성화 모듈은 추가로, 상기 http/https 요청을 상기 중앙 클라우드 컴퓨팅 기기에서 호스팅되는 API 게이트웨이에 전송하기 위한 국부적으로 호스팅되는 API 게이트웨이를 제공하도록 구성되는, 에지 클라우드 컴퓨팅 기기.
  8. 제1항에 있어서,
    상기 에지 노드 활성화 모듈은 추가로, 상기 수신된 요청을 서비스하는 데 필요한, 상기 결정된 유형의 하나 이상의 마이크로서비스가 다른 에지 클라우드 컴퓨팅 기기에서 호스팅되는 하나 이상의 마이크로서비스에 대응하는 경우, 상기 요청을 상기 다른 에지 클라우드 컴퓨팅 기기에서 호스팅되는 하나 이상의 마이크로서비스에 직접 전송하도록 구성되는, 에지 클라우드 컴퓨팅 기기.
  9. 제8항에 있어서,
    상기 에지 노드 활성화 모듈은 추가로, 상기 에지 클라우드 컴퓨팅 기기에서 국부적으로 호스팅되는 하나 이상의 마이크로서비스 및 상기 다른 에지 클라우드 컴퓨팅 기기에서 호스팅되는 하나 이상의 마이크로서비스에 대응하는 서비스 메시(service mesh)를 형성하기 위한 사이드카 패턴(sidecar pattern)을 구현하도록 구성되는, 에지 클라우드 컴퓨팅 기기.
  10. 제1항에 있어서,
    상기 에지 노드 활성화 모듈은 추가로,
    제1 파라미터 세트에 기초하여 하나 이상의 다른 에지 클라우드 컴퓨팅 기기를 탐색하여 그 사이에 연결을 확립하고;
    하나 이상의 에지 클라우드 컴퓨팅 기기 사이에 확립된 연결과 연관된 상기 국부적으로 호스팅되는 하나 이상의 마이크로서비스를 실행하기 위한 마이크로서비스 런타임 환경을 제공하도록 구성되는, 에지 클라우드 컴퓨팅 기기.
  11. 제10항에 있어서,
    상기 에지 노드 활성화 모듈은 추가로, 상기 하나 이상의 에지 클라우드 컴퓨팅 기기에 의해 지원되는 하나 이상의 마이크로서비스를 탐색하도록 구성되는, 에지 클라우드 컴퓨팅 기기.
  12. 제10항에 있어서,
    상기 제1 파라미터 세트는,
    상기 하나 이상의 에지 클라우드 컴퓨팅 기기 각각과 연관된 사용자 계정, 상기 하나 이상의 에지 클라우드 컴퓨팅 기기와 연관된 네트워크, 및 상기 하나 이상의 에지 클라우드 컴퓨팅 기기의 근접성을 포함하는, 에지 클라우드 컴퓨팅 기기.
  13. 제10항에 있어서,
    상기 에지 노드 활성화 모듈은 추가로,
    상기 하나 이상의 에지 클라우드 컴퓨팅 기기로 하나 이상의 클러스터를 동적으로 형성하고;
    마이크로서비스 레벨에서 상기 하나 이상의 에지 클라우드 컴퓨팅 기기와 직접 또는 상기 하나 이상의 클러스터에 걸쳐 다른 에지 클라우드 컴퓨팅 기기를 통해 통신하도록 구성되는, 에지 클라우드 컴퓨팅 기기.
  14. 제1항에 있어서,
    상기 에지 노드 활성화 모듈은 추가로, 공통의 내장형 웹 서버(common embedded web server)를 통해 하나 이상의 에지 클라우드 컴퓨팅 기기에 상기 국부적으로 호스팅되는 하나 이상의 마이크로서비스 서비스를 노출하도록 구성되는, 에지 클라우드 컴퓨팅 기기.
  15. 제1항에 있어서,
    상기 에지 노드 활성화 모듈은 내부에 내장된 웹서버를 포함하고, 상기 웹서버는 상기 에지 클라우드 컴퓨팅 기기와 연관된 운영 체제를 기반으로 하는 특정 언어를 사용하여 컨테이너 관리(container management) API를 제공하도록 구성되는, 에지 클라우드 컴퓨팅 기기.
  16. 서버 컴퓨팅 기기와 통신하는 하나 이상의 에지 클라우드 컴퓨팅 기기를 포함하는 통신 네트워크에서 동작하도록 구성된 상기 서버 컴퓨팅 기기로서,
    상기 하나 이상의 에지 클라우드 컴퓨팅 기기를 지원하기 위한 하나 이상의 백엔드 서비스를 제공하도록 구성된 백엔드 서비스 모듈(backend services module)을 포함하고,
    상기 하나 이상의 백엔드 서비스는,
    상기 하나 이상의 에지 클라우드 컴퓨팅 기기의 하나 이상의 클러스터를 형성하기 위한 지식을 제공하도록 구성된 탐색 서비스(discovery service) - 상기 하나 이상의 클러스터 각각은 적어도 하나의 슈퍼 에지 클라우드 컴퓨팅 기기(super edge cloud computing device)를 포함함 -;
    상기 탐색 서비스로부터 요청을 수신하면 상기 하나 이상의 클러스터에 대한 시그널링 엔드포인트(Signaling Endpoint, SEP) 및 베어러 엔드포인트(Bearer Endpoint, BEP)를 동적으로 배치하도록 구성된 시그널링 서비스(signaling service); 및
    상기 하나 이상의 클러스터 내의 제1 에지 클라우드 컴퓨팅 기기에서 마이크로서비스에 토큰을 전달하고, 상기 하나 이상의 클러스터 내의 제2 에지 클라우드 컴퓨팅 기기에서 다른 마이크로서비스에 요청을 하도록 구성된 서버 토큰 서비스(server token service)를 포함하는
    서버 컴퓨팅 기기.
  17. 제16항에 있어서,
    상기 하나 이상의 백엔드 서비스는, 상기 하나 이상의 에지 클라우드 컴퓨팅 기기의 인증 프로파일(backend services module)을 생성 및 유지하도록 구성된 신원확인 서비스(identity service)를 더 포함하는, 서버 컴퓨팅 기기.
  18. 제16항에 있어서,
    상기 하나 이상의 백엔드 서비스는, 상기 하나 이상의 클러스터에서 제공되는 모든 마이크로서비스의 목록 및 연관된 클러스터 정보를 유지하도록 구성된 등록 서비스(registry service)를 더 포함하는, 서버 컴퓨팅 기기.
  19. 제18항에 있어서,
    상기 등록 서비스는 추가로, 상기 하나 이상의 클러스터가 구성 목적으로 자체 관리될 수 있도록 상기 하나 이상의 클러스터의 클러스터 지식을 유지하도록 구성되는, 서버 컴퓨팅 기기.
  20. 제18항에 있어서,
    상기 등록 서비스는 추가로, 상기 하나 이상의 백엔드 서비스에 의해 사용될 클러스터의 지리적 위치 목록 및 연관된 구성 세부사항을 제공하도록 구성되는, 서버 컴퓨팅 기기.
  21. 제16항에 있어서,
    상기 하나 이상의 클러스터를 형성하기 위한 지식은,
    상기 하나 이상의 클러스터의 프로파일, 상기 하나 이상의 클러스터를 형성하는 하나 이상의 에지 클라우드 컴퓨팅 기기와 연관된 컴퓨팅 자원의 세부사항, 상기 하나 이상의 클러스터를 형성하는 하나 이상의 에지 클라우드 컴퓨팅 기기의 상태 및/또는 위치, 상기 하나 이상의 클러스터를 형성하는 하나 이상의 에지 클라우드 컴퓨팅 기기에서 이용 가능한 하나 이상의 마이크로서비스, 상기 하나 이상의 클러스터를 형성하는 각각의 에지 클라우드 컴퓨팅 기기에 도달하기 위한 종단 간 네트워크 토폴로지(end-to-end network topology), 및 상기 하나 이상의 클러스터의 도달 가능성(reachability)을 포함하는, 서버 컴퓨팅 기기.
  22. 제16항에 있어서,
    상기 탐색 서비스는 추가로,
    상기 통신 네트워크에서 이용 가능한 자원과 연관된 정보를 제공하여 실시간으로 상기 통신 네트워크 내의 임의의 이용 가능한 에지 클라우드 컴퓨팅 기기에 상기 하나 이상의 마이크로서비스를 동적으로 배치하도록 구성되는, 서버 컴퓨팅 기기.
  23. 제17항에 있어서,
    상기 신원확인 서비스는, 각각의 에지 클라우드 컴퓨팅 기기의 에지 노드 활성화 모듈, 상기 에지 노드 활성화 모듈을 사용하는 마이크로서비스, 상기 에지 노드 활성화 모듈을 사용하는 애플리케이션 개발자, 및 상기 에지 노드 활성화 모듈에 의해 지원되는 애플리케이션의 최종 사용자 중 하나 이상에 대한 토큰을 생성 및 유지하도록 구성되는, 서버 컴퓨팅 기기.
  24. 적어도 하나의 서버 컴퓨팅 기기와 통신하는 하나 이상의 에지 클라우드 컴퓨팅 기기를 포함하는 통신 네트워크에서 에지 클라우드 컴퓨팅 인프라를 제공하는 방법으로서,
    제1 에지 클라우드 컴퓨팅 기기가, 상기 제1 에지 클라우드 컴퓨팅 기기에서 실행 중인 애플리케이션으로부터의 요청에 대응하는 하나 이상의 마이크로서비스의 유형을 결정하는 단계; 및
    상기 제1 에지 클라우드 컴퓨팅 기기가, 결정된 유형이 상기 제1 에지 클라우드 컴퓨팅 기기에서 국부적으로 호스팅되는 하나 이상의 마이크로서비스에 대응하는 경우 상기 제1 에지 클라우드 컴퓨팅 기기에서 상기 요청을 국부적으로 처리하는 단계
    를 포함하는 방법.
  25. 제24항에 있어서,
    상기 제1 에지 클라우드 컴퓨팅 기기가 상기 국부적으로 호스팅되는 하나 이상의 마이크로서비스를 실행하기 위한 마이크로서비스 런타임 환경을 제공하는 단계를 더 포함하는 방법.
  26. 제24항에 있어서,
    상기 제1 에지 클라우드 컴퓨팅 기기가 상기 국부적으로 호스팅되는 하나 이상의 마이크로서비스에 요청을 전송하기 위한 국부적으로 호스팅되는 API 게이트웨이를 제공하는 단계를 더 포함하는 방법.
  27. 제24항에 있어서,
    상기 제1 에지 클라우드 컴퓨팅 기기가 상기 애플리케이션으로부터의 요청에 대응하는 http/https 요청을, 상기 결정된 유형의 하나 이상의 마이크로서비스가 중앙 클라우드 컴퓨팅 기기에서 전역적으로 호스팅되는 하나 이상의 마이크로서비스에 대응하는 경우 상기 중앙 클라우드 컴퓨팅 기기에서 호스팅되는 API 게이트웨이에 전송하는 단계를 더 포함하는 방법.
  28. 제27항에 있어서,
    상기 제1 에지 클라우드 컴퓨팅 기기가 상기 http/https 요청에 대한 http/https 응답을, 상기 중앙 클라우드 컴퓨팅 기기에서 호스팅되는 상기 API 게이트웨이로부터 수신하는 단계를 더 포함하고, 상기 http/https 요청은 상기 중앙 클라우드 컴퓨팅 기기에서 전역적으로 호스팅되는 하나 이상의 마이크로서비스에 의해 서비스되는, 방법.
  29. 제27항에 있어서,
    상기 제1 에지 클라우드 컴퓨팅 기기가 상기 http/https 요청을 상기 중앙 클라우드 컴퓨팅 기기에서 호스팅되는 API 게이트웨이로 전송하기 위한 국부적으로 호스팅되는 API 게이트웨이를 제공하는 단계를 더 포함하는 방법.
  30. 제24항에 있어서,
    상기 제1 에지 클라우드 컴퓨팅 기기가, 상기 애플리케이션으로부터의 요청의 결정된 유형이 제2 에지 클라우드 컴퓨터 기기에 대한 데이터 요청에 대응하는 경우 데이터 요청을, 상기 국부적으로 호스팅되는 하나 이상의 마이크로서비스에서 상기 제2 에지 클라우드 컴퓨터 기기에서 호스팅되는 하나 이상의 마이크로서비스로 직접 전송하는 단계를 더 포함하는 방법.
  31. 제24항에 있어서,
    상기 제1 에지 클라우드 컴퓨팅 기기가, 상기 제1 에지 클라우드 컴퓨팅 기기에서 실행 중인 애플리케이션을 지원하기 위해 서비스 메시를 형성하기 위한 사이드카 패턴을 제공하는 단계를 더 포함하는 방법.
  32. 제24항에 있어서,
    상기 제1 에지 클라우드 컴퓨팅 기기가 공통 내장형 웹 서버를 통해 하나 이상의 에지 클라우드 컴퓨팅 기기에 상기 국부적으로 호스팅되는 하나 이상의 마이크로서비스 서비스를 노출하는 단계를 더 포함하는 방법.
  33. 제24항에 있어서,
    상기 제1 에지 클라우드 컴퓨팅 기기가 상기 에지 클라우드 컴퓨팅 기기와 연관된 운영 체제를 기반으로 하는 특정 언어를 사용하는 컨테이너 관리 API를 제공하는 단계를 더 포함하는 방법.
  34. 제24항에 있어서,
    상기 제1 에지 클라우드 컴퓨팅 기기가 하나 이상의 다른 에지 클라우드 컴퓨팅 기기를 탐색하여 그 사이의 연결을 확립하는 단계; 및
    상기 제1 에지 클라우드 컴퓨팅 기기가, 상기 하나 이상의 에지 클라우드 컴퓨팅 기기 사이에 확립된 연결과 연관된 상기 국부적으로 호스팅되는 하나 이상의 마이크로서비스를 실행하기 위한 마이크로서비스 런타임 환경을 제공하는 단계를 더 포함하는 방법.
  35. 제34항에 있어서,
    상기 제1 에지 클라우드 컴퓨팅 기기가 탐색된 하나 이상의 다른 에지 클라우드 컴퓨팅 기기에서 호스팅되는 하나 이상의 마이크로서비스를 탐색하는 단계; 및
    상기 제1 에지 클라우드 컴퓨팅 기기가, 상기 하나 이상의 에지 클라우드 컴퓨팅 기기에서 상기 국부적으로 호스팅되는 하나 이상의 마이크로서비스와 탐색된 하나 이상의 마이크로서비스 사이에 직접 마이크로서비스 레벨 연결을 확립하는 단계를 더 포함하는 방법.
  36. 제24항에 있어서,
    상기 제1 에지 클라우드 컴퓨팅 기기가 상기 애플리케이션으로부터의 요청을 서비스하는 데 필요한 하나 이상의 마이크로서비스를 로드하고 실행하는 단계를 더 포함하는 방법.
  37. 제36항에 있어서,
    상기 제1 에지 클라우드 컴퓨팅 기기가, 상기 애플리케이션으로부터의 요청이 서비스되었으면 로드된 하나 이상의 마이크로서비스를 중지하는 단계를 더 포함하는 방법.
KR1020227014140A 2019-10-26 2020-10-26 분산형 에지 클라우드 컴퓨팅을 위한 방법 및 시스템 KR20220091487A (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201962926455P 2019-10-26 2019-10-26
US62/926,455 2019-10-26
US16/841,380 US20200322225A1 (en) 2019-04-05 2020-04-06 Method and system for distributed edge cloud computing
US16/841,380 2020-04-06
PCT/IB2020/060038 WO2021079357A1 (en) 2019-10-26 2020-10-26 Method and system for distributed edge cloud computing

Publications (1)

Publication Number Publication Date
KR20220091487A true KR20220091487A (ko) 2022-06-30

Family

ID=75619946

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020227014140A KR20220091487A (ko) 2019-10-26 2020-10-26 분산형 에지 클라우드 컴퓨팅을 위한 방법 및 시스템

Country Status (5)

Country Link
EP (1) EP4049413A4 (ko)
JP (1) JP7426636B2 (ko)
KR (1) KR20220091487A (ko)
CA (1) CA3152892A1 (ko)
WO (1) WO2021079357A1 (ko)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113556390A (zh) * 2021-07-15 2021-10-26 深圳市高德信通信股份有限公司 一种分布式边缘计算系统
WO2023035147A1 (en) * 2021-09-08 2023-03-16 Siemens Aktiengesellschaft Data processing method of industry edge product and distributed computing protocol engine thereof
KR102553079B1 (ko) * 2021-10-19 2023-07-10 아콘소프트 주식회사 운영 자동화 기능을 가진 엣지 클라우드 기반 컴퓨팅 시스템
WO2023115522A1 (en) * 2021-12-24 2023-06-29 Huawei Technologies Co., Ltd. Systems and methods for enabling network-based reusable computing
CN114024967B (zh) * 2022-01-10 2022-03-25 广东电力信息科技有限公司 一种基于云边和边边协同架构的iaas数据处理系统及方法
KR20230136458A (ko) * 2022-03-18 2023-09-26 한국과학기술원 영상 분석을 위한 마이크로서비스 기반 엣지 디바이스 아키텍처
WO2024086008A1 (en) * 2022-10-20 2024-04-25 Fisher-Rosemount Systems, Inc. Authentication/authorization framework for a process control or automation system

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010191482A (ja) 2009-02-13 2010-09-02 Fujitsu Ltd クライアントサーバシステム、クライアント装置および業務処理振分プログラム
JP2016519812A (ja) 2013-03-15 2016-07-07 メンター・グラフィクス・コーポレーション クラウドサービスプラットフォーム
US10893100B2 (en) 2015-03-12 2021-01-12 International Business Machines Corporation Providing agentless application performance monitoring (APM) to tenant applications by leveraging software-defined networking (SDN)
WO2016192866A1 (en) 2015-06-03 2016-12-08 Telefonaktiebolaget Lm Ericsson (Publ) Implanted agent within a first service container for enabling a reverse proxy on a second container
US10516672B2 (en) 2016-08-05 2019-12-24 Oracle International Corporation Service discovery for a multi-tenant identity and data security management cloud service
US10489275B2 (en) 2016-10-20 2019-11-26 Cisco Technology, Inc. Agentless distributed monitoring of microservices through a virtual switch
WO2018089417A1 (en) 2016-11-09 2018-05-17 Interdigital Patent Holdings, Inc. Systems and methods to create slices at a cell edge to provide computing services
US10574736B2 (en) 2017-01-09 2020-02-25 International Business Machines Corporation Local microservice development for remote deployment
WO2018144060A1 (en) 2017-02-05 2018-08-09 Intel Corporation Microservice provision and management
CN110832808B (zh) * 2017-06-09 2023-06-20 环球互连及数据中心公司 用于消息传递服务的方法、存储介质和计算系统
US10303450B2 (en) 2017-09-14 2019-05-28 Cisco Technology, Inc. Systems and methods for a policy-driven orchestration of deployment of distributed applications
JP7095094B2 (ja) 2018-01-08 2022-07-04 ヘーレ グローバル ベスローテン フェンノートシャップ 位置情報サービスの提供ための分散処理システムと方法
US10735509B2 (en) * 2018-01-31 2020-08-04 Ca, Inc. Systems and methods for synchronizing microservice data stores
US11423254B2 (en) * 2019-03-28 2022-08-23 Intel Corporation Technologies for distributing iterative computations in heterogeneous computing environments

Also Published As

Publication number Publication date
CA3152892A1 (en) 2021-04-29
EP4049413A1 (en) 2022-08-31
CN114731296A (zh) 2022-07-08
EP4049413A4 (en) 2023-07-05
JP7426636B2 (ja) 2024-02-02
JP2022554220A (ja) 2022-12-28
WO2021079357A1 (en) 2021-04-29

Similar Documents

Publication Publication Date Title
US20210042160A1 (en) Method and system for distributed edge cloud computing
JP7466156B2 (ja) 分散型エッジクラウドコンピューティングのための方法およびシステム
KR20220091487A (ko) 분산형 에지 클라우드 컴퓨팅을 위한 방법 및 시스템
US10812345B2 (en) Automated service profiling and orchestration
US10805104B2 (en) Virtual network endpoints for internet of things (IOT) devices
KR102084104B1 (ko) 종단간 m2m 서비스 계층 세션
US9507630B2 (en) Application context transfer for distributed computing resources
KR101984413B1 (ko) 서비스 레이어를 통해 제3자 서비스들에 대한 액세스를 가능하게 하는 시스템들 및 방법들
US10318550B2 (en) Systems and methods for autonomous resource discovery, management, and stitching
Petrolo et al. The design of the gateway for the cloud of things
US10645172B1 (en) Socket tunneling connections in a service provider environment
US20220116335A1 (en) End-to-end network slicing (ens) from ran to core network for next generation (ng) communications
Alamouti et al. Hybrid edge cloud: A pragmatic approach for decentralized cloud computing
Drost et al. Zorilla: a peer‐to‐peer middleware for real‐world distributed systems
Pal Extending mobile cloud platforms using opportunistic networks: survey, classification and open issues
CN114731296B (zh) 用于分布式边缘云计算的方法和系统
WO2023081202A1 (en) Mec dual edge apr registration on behalf of edge platform in dual edge deployments
CN113515392B (zh) Rpc调用方法、装置、设备及存储介质
Li A Coordination Model and Framework for Developing Distributed Mobile Applications
CN115378993A (zh) 支持命名空间感知的服务注册与发现的方法和系统
Janovic Integrating ACI with Virtualization and Container Platforms

Legal Events

Date Code Title Description
A201 Request for examination