KR20230073372A - 평판 관리 및 의도 기반 보안 메커니즘 - Google Patents

평판 관리 및 의도 기반 보안 메커니즘 Download PDF

Info

Publication number
KR20230073372A
KR20230073372A KR1020220132147A KR20220132147A KR20230073372A KR 20230073372 A KR20230073372 A KR 20230073372A KR 1020220132147 A KR1020220132147 A KR 1020220132147A KR 20220132147 A KR20220132147 A KR 20220132147A KR 20230073372 A KR20230073372 A KR 20230073372A
Authority
KR
South Korea
Prior art keywords
reputation score
software
operator
execution
implemented operator
Prior art date
Application number
KR1020220132147A
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
Application filed by 인텔 코포레이션 filed Critical 인텔 코포레이션
Publication of KR20230073372A publication Critical patent/KR20230073372A/ko

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26Power supply means, e.g. regulation thereof
    • G06F1/32Means for saving power
    • G06F1/3203Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3206Monitoring of events, devices or parameters that trigger a change in power modality
    • G06F1/3228Monitoring task completion, e.g. by use of idle timers, stop commands or wait commands
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26Power supply means, e.g. regulation thereof
    • G06F1/32Means for saving power
    • G06F1/3203Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3234Power saving characterised by the action undertaken
    • G06F1/3296Power saving characterised by the action undertaken by lowering the supply or operating voltage
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3433Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment for load management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466Performance evaluation by tracing or monitoring
    • G06F11/3495Performance evaluation by tracing or monitoring for systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577Assessing vulnerabilities and evaluating computer system security
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3867Concurrent instruction execution, e.g. pipeline or look ahead using instruction pipelines
    • G06F9/3875Pipelining a single stage, e.g. superpipelining
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating
    • G06F9/44505Configuring for program initiating, e.g. using registry, configuration files
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/08Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/087Inventory or stock management, e.g. order filling, procurement or balancing against orders
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003Managing SLA; Interaction between SLA and QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003Managing SLA; Interaction between SLA and QoS
    • H04L41/5009Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003Managing SLA; Interaction between SLA and QoS
    • H04L41/5019Ensuring fulfilment of SLA
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003Managing SLA; Interaction between SLA and QoS
    • H04L41/5019Ensuring fulfilment of SLA
    • H04L41/5025Ensuring fulfilment of SLA by proactively reacting to service quality change, e.g. by reconfiguration after service quality degradation or upgrade
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5054Automatic deployment of services triggered by the service manager, e.g. service implementation by automatic configuration of network components
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823Errors, e.g. transmission errors
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/72Admission control; Resource allocation using reservation actions during connection setup
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/82Miscellaneous aspects
    • H04L47/821Prioritising resource allocation or reservation requests
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/82Miscellaneous aspects
    • H04L47/822Collecting or measuring resource availability data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/83Admission control; Resource allocation based on usage prediction
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083Network architectures or network communication protocols for network security for authentication of entities using passwords
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1433Vulnerability analysis
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1097Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • H04L67/146Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/52Network services specially adapted for the location of the user terminal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/875Monitoring of systems including the internet
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/50Indexing scheme relating to G06F9/50
    • G06F2209/503Resource availability
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/033Test or assess software
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2135Metering
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06NCOMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00Machine learning

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Business, Economics & Management (AREA)
  • Environmental & Geological Engineering (AREA)
  • Quality & Reliability (AREA)
  • Economics (AREA)
  • Data Mining & Analysis (AREA)
  • Mathematical Physics (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Finance (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • Accounting & Taxation (AREA)
  • Artificial Intelligence (AREA)
  • Development Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Evolutionary Computation (AREA)
  • Medical Informatics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Multi Processors (AREA)

Abstract

평판 관리 및 의도 기반 보안 메커니즘들을 구현하기 위한 다양한 시스템들 및 방법들이 본 명세서에서 설명된다. 의도 주도 보안 메커니즘들(intent-driven security mechanisms)을 구현하기 위한 시스템으로서, 컴퓨팅 노드 상에서의 애플리케이션의 실행과 관련된 위험 감수 의도(risk tolerance intent)에 기초하여, 소프트웨어 구현된 운영자의 실행이 신뢰 평가를 요구하는지를 결정하고; 및 소프트웨어 구현된 운영자가 신뢰 평가를 요구한다는 결정에 응답하여: 소프트웨어 구현된 운영자의 평판 점수를 획득하고; 위험 감수 의도로부터 최소 평판 점수를 결정하고; 소프트웨어 구현된 운영자의 평판 점수를 최소 평판 점수와 비교하고; 및 비교에 기초하여 소프트웨어 구현된 운영자의 실행을 거부 또는 허용하도록 구성된다.

Description

평판 관리 및 의도 기반 보안 메커니즘{REPUTATION MANAGEMENT AND INTENT-BASED SECURITY MECHANISMS}
[우선권]
본 출원은 2021년 11월 16일자로 출원된 미국 가특허 출원 제63/280,001호를 기초로 우선권을 주장하며, 이 미국 출원은 참조에 의해 그 전체 내용이 본 명세서에 포함된다.
[기술분야]
본 명세서에 설명된 실시예들은 일반적으로 네트워크 모니터링 및 튜닝에 관한 것으로, 특히 평판 관리 및 의도 기반 보안 메커니즘(reputation management and intent-based security mechanism)들을 구현하기 위한 시스템 및 방법에 관한 것이다.
일반적인 레벨에서, 에지 컴퓨팅(edge computing)은 총 소유 비용을 최적화하고, 애플리케이션 레이턴시를 감소시키고, 서비스 능력을 개선하고, 보안 또는 데이터 프라이버시 요건들의 준수를 개선하기 위해서 엔드포인트 디바이스들(예를 들어, 소비자 컴퓨팅 디바이스들, 사용자 장비 등)에 더 가깝게 컴퓨팅 및 스토리지 리소스들을 전이(transition)하는 것을 지칭한다. 일부 시나리오들에서, 에지 컴퓨팅은 많은 타입들의 스토리지 및 컴퓨팅 리소스들 사이에서 애플리케이션들에 대한 오케스트레이션 및 관리를 제공하는 클라우드 유사 분산형 서비스(cloud-like distributed service)를 제공할 수 있다. 그 결과, 이전에 대규모 원격 데이터 센터들에서만 이용가능했던 강력한 컴퓨팅 리소스들이 엔드포인트들에 더 가깝게 이동되고 네트워크의 "에지"에 있는 소비자들에 의한 사용을 위해 이용가능하게 됨에 따라, 에지 컴퓨팅의 일부 구현들은 "에지 클라우드(edge cloud)" 또는 "포그(fog)"라고 지칭된다.
모바일 네트워크 설정에서의 에지 컴퓨팅 사용 사례들이, "모바일 에지 컴퓨팅"으로도 알려진, 멀티 액세스 에지 컴퓨팅(multi-access edge computing, MEC) 접근법들과의 통합을 위해 개발되었다. MEC 접근법들은 애플리케이션 개발자들 및 콘텐츠 제공자들이 네트워크의 에지에서의 동적 모바일 네트워크 설정으로 컴퓨팅 능력들 및 정보 기술(IT) 서비스 환경에 액세스하게 허용하도록 설계된다. MEC 시스템들, 플랫폼들, 호스트들, 서비스들, 및 애플리케이션들의 동작을 위한 공통 인터페이스들을 정의하기 위해 ETSI(European Telecommunications Standards Institute) ISG(industry specification group)에 의해 제한된 표준들이 개발되었다.
에지 컴퓨팅, MEC, 및 관련 기술들은 전통적인 클라우드 네트워크 서비스들 및 광역 네트워크 접속들에서 제공되는 것보다 감소된 레이턴시, 증가된 응답성, 및 더 많은 이용가능한 컴퓨팅 능력을 제공하려고 시도한다. 그러나, 이동성 및 동적으로 론칭되는 서비스들의 일부 모바일 사용 및 디바이스 처리 사용 사례들로의 통합은, 특히 많은 참여자들(디바이스들, 호스트들, 테넌트(tenant)들, 서비스 제공자들, 운영자들)이 수반되는 복잡한 이동성 설정에서, 오케스트레이션, 기능적 조정, 및 리소스 관리에 대한 한계 및 우려로 이어졌다. 유사한 방식으로, 사물 인터넷(Internet of Things, IoT) 네트워크들 및 디바이스들이 다양한 엔드포인트들로부터 분산형 컴퓨팅 배열(distributed compute arrangement)을 제공하도록 설계된다. IoT 디바이스들은 네트워크 상에서 통신할 수 있는 물리적인 또는 가상화된 객체들이고, 데이터를 수집하거나 실세계 환경에서 액션들을 수행하기 위해 사용될 수 있는 센서들, 액추에이터들, 및 다른 입력/출력 컴포넌트들을 포함할 수 있다. 예를 들어, IoT 디바이스들은, 건물들, 차량들, 패키지들 등과 같은, 매일의 사물들에 임베드되거나 부착되어 그러한 사물들의 추가 레벨의 인공 감각 인식을 제공하는 저전력 엔드포인트 디바이스들을 포함할 수 있다. 최근에, IoT 디바이스들이 더 대중화되었고 따라서 이들 디바이스를 사용하는 애플리케이션들이 급증하였다.
다양한 에지(Edge), 포그(Fog), MEC, 및 IoT 네트워크들, 디바이스들, 및 서비스들의 배치는 네트워크의 에지에서 그리고 네트워크의 에지를 향해 발생하는 몇몇 진보된 사용 사례들 및 시나리오들을 도입하였다. 그렇지만, 이 진보된 사용 사례들은 또한, 많은 다른 문제들 중에서도, 특히 보다 많은 타입들의 컴퓨팅 시스템들 및 구성들이 배치됨에 따라, 오케스트레이션, 보안, 처리 및 네트워크 리소스들, 서비스 가용성 및 효율성, 서비스 품질 보장에 관련된 몇 가지 대응하는 기술적 도전 과제들을 끌어들였다.
반드시 실제 축척(scale)으로 그려진 것은 아닌 도면에서, 유사한 도면 번호가 상이한 뷰들 내의 유사한 컴포넌트를 기술할 수 있다. 상이한 문자 접미사를 갖는 유사한 도면 번호가 유사한 컴포넌트의 상이한 경우를 표현할 수 있다. 일부 실시예들은 첨부 도면들의 그림들에서 제한이 아닌 예로서 도시된다.
반드시 실제 축척(scale)으로 그려진 것은 아닌 도면에서, 유사한 도면 번호가 상이한 뷰들 내의 유사한 컴포넌트를 기술할 수 있다. 상이한 문자 접미사를 갖는 유사한 도면 번호가 유사한 컴포넌트의 상이한 경우를 표현할 수 있다. 일부 실시예들은 첨부 도면들의 그림들에서 제한이 아닌 예로서 도시된다.
도 1은 실시예에 따른, 에지 컴퓨팅을 위한 에지 클라우드 구성의 개관을 도시한다.
도 2는 실시예에 따른, 엔드포인트들, 에지 클라우드, 및 클라우드 컴퓨팅 환경들 간의 동작 계층들을 도시한다.
도 3은 실시예에 따른, 에지 컴퓨팅 시스템에서의 네트워킹 및 서비스들을 위한 예시적인 접근법을 도시한다.
도 4는 실시예에 따른, 다중의 에지 노드 및 다중의 테넌트 사이에서 동작되는 에지 컴퓨팅 시스템에서의 가상 에지 구성의 배치를 도시한다.
도 5는 실시예에 따른, 에지 컴퓨팅 시스템에서 컨테이너들을 배치하는 다양한 컴퓨팅 배열들을 도시한다.
도 6a는 실시예에 따른, 에지 컴퓨팅 시스템에서의 컴퓨팅 노드에 배치된 컴퓨팅을 위한 예시적인 컴포넌트들의 개관을 제공한다.
도 6b는 실시예에 따른, 에지 컴퓨팅 시스템에서의 컴퓨팅 디바이스 내에서의 예시적인 컴포넌트들의 추가 개관을 제공한다.
도 7은 실시예에 따른, 도 6b의 예시적인 컴퓨터 판독가능 명령어와 같은 소프트웨어를 하나 이상의 디바이스에 배포하는 예시적인 소프트웨어 배포 플랫폼을 도시한다.
도 8은 실시예에 따른, 서버리스 데이터 센터를 도시하는 블록도이다.
도 9는 실시예에 따른, 다중의 하드웨어 시스템을 갖는 운영 환경을 도시하는 블록도이다.
도 10은 실시예에 따른, 오케스트레이션 제어 평면을 도시하는 블록도이다.
도 11은 실시예에 따른, 오케스트레이션 시스템에서의 데이터 및 제어 흐름을 도시하는 블록도이다.
도 12는 실시예에 따른, 의도 기반 오케스트레이션을 구현하는 방법을 도시하는 흐름도이다.
도 13은 실시예에 따른, 위험 감수 의도(risk tolerance intent)를 사용하여 오케스트레이션하는 데이터 및 제어 흐름을 도시하는 블록도이다.
도 14는 실시예에 따른, 위험 감수 의도를 사용하여 오케스트레이션하는 방법을 도시하는 흐름도이다.
도 15는 실시예에 따른, 의도 주도 보안 메커니즘을 구현하는 방법을 도시하는 흐름도이다.
도 16은 실시예에 따른, 플랫폼 상의 엔티티들 간의 리소스 공유를 구현하는 데이터 및 제어 흐름을 도시하는 블록도이다.
도 17은 실시예에 따른, 플랫폼 상의 리소스 공유를 위한 방법을 도시하는 흐름도이다.
도 18은 실시예에 따른, 의도 주도 보안의 전체적인 흐름을 도시하는 도면이다.
도 19는 실시예에 따른, 보안 관리자의 컴포넌트들을 도시하는 블록도이다.
도 20은 실시예에 따른, 평판 관리 및 의도 기반 보안 메커니즘을 위한 방법을 도시하는 흐름도이다.
본 명세서에 설명된 시스템들 및 방법들은 평판 관리 및 의도 기반 보안 메커니즘을 제공한다. 현행의 오케스트레이션 솔루션들은 QoS(quality of service) 관리를 달성하는 데 매우 임페러티브(imperative)한 방식을 사용한다. QoS 관리는 리소스들의 정확한 양(예를 들어, vCPU(virtual central processing unit)들의 수), 또는 클라우드 및 에지에서 작업부하들을 지원하기 위한 하드웨어 피처들을 요청하는 것에 관하여 주로 구축된다. 이러한 방식으로 오케스트레이션을 수행하는 것은 몇 가지 문제들을 갖는다. 이것은, 어느 한 벤더에 의해 특정된 특정한 피처 세트들이 또 다른 벤더에 의해 제공된 장비에 의해 이용가능하지 않을 수 있기 때문에, 원치않는 벤더-록 인(vendor-lock in)을 생성한다. 또한, 경험은 부정확한 정보가 QoS 요청에서 선언되고 따라서 차선의 성능으로 이어진다는 것을 보여준다. 마지막으로, 이러한 선언들은 QoS 관리 스킴에 포함되지 않는 정황을 갖는다. 예를 들어, 애플리케이션이 실행되고 있는 플랫폼의 타입(예를 들어, Xeon 타입 코어 대 Atom 기반 코어 프로세서들)이 특정 QoS 요청을 만족시키기 위한 프로비저닝 판정들에 영향을 미칠 수 있다.
더욱이, 작업부하가 모놀리식 스타일로부터 마이크로서비스 스타일로 이동함에 따라, 고객들이 작업부하들에 대한 정확한 리소스 할당들을 스스로 선택하는 것이 더 어려워진다. 이는 고객들이 리소스들을 오버프로비저닝하는 것으로 이끌 수 있고, 이는 더 높은 비용을 초래한다.
하드웨어 플랫폼들이 (예컨대, 단일 CPU 대신에 다중의 XPU를 사용하여) 보다 이질적이 됨에 따라, 사용자가 오케스트레이션 요청에서 다수의 정황 상세 사항들을 정의할 필요가 있는 것으로부터 추상화되어야 하고, 대신에 플레이 중인 서비스들에 대한 특정 목표 세트를 달성하고자 자신이 원하는 것에 집중할 수 있어야 하는 것이 중요하다. 의도 주도 모델(intent-driven model)이 이 추상화를 사용자에게 제공하고, 그 결과로 서비스 소유자에 대한 양호한 성능은 물론이고 리소스 소유자에 대한 양호한 투자 수익(return on investment)을 가져온다. 따라서, 요구되는 레벨의 서비스 품질을 달성하기 위해 한 세트의 시스템들과 그들의 리소스들에 걸쳐 (서비스 레벨 목표로서 정의되는) 의도를 매핑하는 방법이 필요하다.
SLA(service level agreement)는 서비스 제공자와 클라이언트 사이의 계약이다. SLA들은 서비스 타겟들 또는 다른 비즈니스 목표들을 약술하는 제3자들 사이의 계약들이다. SLA들은 타겟을 만족시키는데 실패한 당사자들에 대한 페널티들을 약술할 수 있다. 예를 들어, 서비스가 90일 기간에 걸쳐 어떤 임계 백분율보다 많은 동안 이용 가능하지 않을 때 수수료의 부분 환급이 시행될 수 있다.
SLO(service level objective)들은 다양한 시스템 능력들에 대한 정확한 수치적 타겟들을 제공한다. 전형적인 SLO들은 서비스 가용성 또는 가동 시간, 서비스 레이턴시, 서비스 대역폭 프로비저닝 등을 중심에 둔다. SLO들은 "30일 기간에 걸쳐 99.9% 가동 시간" 또는 "수신된 요청들의 적어도 95%에 대해 100ms 미만의 응답 시간"을 요구하는 것과 같이, 백분율들로서 종종 표현된다.
KPI(key performance indicator)들은 특정 목표에 대한 시간 경과에 따른 성능의 정량화가능한 척도들이다. SLO 정책들을 측정하기 위해 KPI 메트릭들이 수집된다. 예시적인 KPI들은 서비스 에러들의 수, 가동 휴지 시간, 캐시 미스들, FPS(frames per second), 레이턴시, IPC(instructions per cycle), 보안 장애들, 실패한 로그인들 등을 포함하지만, 이에 제한되지는 않는다. KPI들은 도출된 값들(예를 들어, 이동하는 30초 윈도우에 걸친 평균 레이턴시)일 수 있다. KPI들은 또한 비교들(예를 들어, 이력 평균과 상이한 퍼센트)에 기초할 수 있다.
서비스 품질 목표들은 계층화된 하향식(top-down) 구조를 형성하지만 트리 또는 DAG 패턴에 있는 것으로 제약되지는 않는 통계적 및 결정론적 사양들로서 표현될 수 있다. 예를 들어, KPI(key performance indicator)들 및 이들이 전체 QoS(quality of service) 또는 SLO(Service Level Objective)를 평가하기 위하여 어떻게 조합되는지를 표현하기 위하여 메타 언어가 이용될 수 있다. KPI들에 대한 다양한 범위들, 비교들, 임계값들, 제약들, 또는 그와 유사한 것이 메타 언어를 이용하여 표현될 수 있다. 대부분의 실세계 소프트웨어 솔루션들은 성능, 스케일, 정확도 및 가용성에 대한 많은 미묘한 요구들을 충족시켜야 하며, 이러한 요구들은 항상 또는 모든 상황들에 대해 반드시 고정되지는 않는다. C 또는 파이썬(Python)과 같은 언어로 된 프로그램이 무엇이 계산될 지를 표현할 시에 프로그래머에게 높은 정도의 유연성을 허용하는 것처럼, 리소스의 스케줄러에 의해 충족될 필요가 있는 동적 요건을 표현하는 메타 언어가 사용될 수 있다. 이러한 메타 언어로 작성된 메타 프로그램은, 예를 들어, 프로그램들, 런타임들, 운영 체제들, 인프라스트럭처 서비스들, 네트워킹 기어(networking gear), 및 등등의 거동들에 대해 수행되는 다양한 캘리브레이션들을 반영하는 변수들을 도입할 수 있다. 그 후, 이러한 변수들은 메타프로그램들의 더 높은 레벨의 변수들 및 결과들이 되도록 짜여지고, 다음 차례로 메타프로그램들로부터의 정정 액션, 반응 액션, 경고 액션, 및 다른 액션을 구동한다. 메타 프로그램들이 상세 사항의 추상화 및 축소를 위해 그리고 더 높은 레벨들에서 특정된 목표에의 수렴을 위해 설계되도록 구조화가 계층화된다.
정책들, 휴리스틱들(heuristics) 등의 계층화가 로직 단독의 규칙들에 의해 제한되지 않고, 신경망들, SVM(support vector machine)들, 결정 트리들 등과 같은 데이터 프로그래밍된 지능을 플러그인(plug-in)하는 능력을 허용하도록 개방형 아키텍처가 제공된다. 전체적인 목표는 컴퓨팅의 일부분을 이러한 메타 프로그램들로 리디렉션(redirection)하고 애플리케이션의 구조의 일부인 계산과 애플리케이션의 실행 동안 서비스 품질 목표를 충족시키도록 설계되는 계산 간에 엄격한 분할을 짓는 것을 피하는 것이다. 따라서, 쿠버네티스(Kubernetes)와 같은 제어/관리 평면과 그것이 그 하에서 실행되는 컨테이너화된 애플리케이션 사이의 보통의 구별은 흐릿해지고, 의도에 관한 정보 및 그 의도에 대한 성능이 상이한 깊이 계층들에서 양방향으로 흐르도록 허용된다. 따라서, 자동 정정 및 자동 표시 능력들이 서비스 목표들 및 서비스 품질 목표들에서의 흐름들 사이에서 공동 엔지니어링될 수 있다. 이점은 소프트웨어가 그것이 활성화되는 환경들과의 자기 적응형 또는 공동 적응형 수용을 달성하기 시작한다는 점이다.
SLA(Service Level Agreements) 만족도를 최대화하려고 시도하는 통계적 승인 제어 정책들이 이용가능하고 지터 민감 네트워크 시스템들에 관련된다. 그러나, 추상화가 상향으로 이동하고 서버리스 시스템들 또는 고도로 가상화된 것에서의 스케줄링이 구현되고 컨테이너들을 통한 리소스들의 적시(just-in-time) 할당들이 요구 시에 생성됨에 따라, 리소스들을 스케줄링하는 복잡성이 계속 증가한다. 매우 큰 데이터 센터들은 반응성 로드 밸런싱을 수행하기 위한 상당한 양의 용량을 준비할 수 있고, 가장 극단적인 요구 버스트들을 제외한 모든 것들에의 승인 거절들을 연기할 수 있지만, 컷오프(cutoff)가 아웃라이어 테일 레이턴시(outlier tail latency)에 대한 것이기 때문에, 인프라스트럭처의 보다 덜 탄력적인 제공자들은 통계적 정책들 하에서도 어려운 호출들을 해야만 한다. 레이턴시 푸시아웃(latency pushout)들의 캐스케이드를 야기할 수 있는 큰 버스트들을 요구 시에 존중하는 것은 극히 어렵다. 대안으로서, 본 명세서에 설명된 시스템들 및 방법들은 네스팅되고 서서히 변화되는 SLA들을 구현하고 따라서 버스트 수용적이다.
레이트 제한된 서버에서 단일 큐를 갖는 토큰 버킷 모델(token-bucket model)을 상상해보자: 가장 새로운 도착에 대한 통계적 투사(statistical projection)는 새로운 도착에 의해 보이는 큐 길이에 비례하는 평균 응답 시간을 갖는다. 순진한 정책(naive policy)은 이 투사된 응답 시간이 테일 레이턴시 제약조건(tail latency constraint)을 위반하는 경우 새로운 도착을 거부하는 것일 것이다; 약간 덜 순진한 정책은 큐 길이 및 이미 발생한 위반들의 수에 좌우되어 새로운 도착을 확률적으로 거절하는 것일 것이다. 이제 기준선 단일 큐, 단일 레이트 서버가 가장 새로운 도착이, 더 낮은 서비스 레이트가 보장되지만 더 완화된 테일 레이턴시가 허용되는 제2 큐에 배치되는 2 레벨 정책이 되도록 스플릿되는 일반화를 상상해보자. 따라서, 예를 들어, 제1 큐가 10ms의 P99 레이턴시를 갖는 경우, 제2 큐는 10ms의 P95 레이턴시와 20ms의 P99 레이턴시를 갖는 조합 SLO를 가질 수 있다. 극단적인 버스트들이 드물기 때문에, 제2 큐에 전용되는 분수 용량은 그 평균 큐 길이가 작기 때문에 높을 필요가 없다. 데이터 센터에서, 제2 큐로의 이동은 한계 요청(엄격한 레이턴시 경계를 위반할 가능성이 있는 것)을, 대응하여 더 완화된 SLO를 갖는 덜 활용되지만 리소스가 덜 주어지는 오버플로우 클러스터에 효과적으로 재할당한다. 이러한 스킴은 제2 큐가 응답 시간 동안 그의 포화에 접근함에 따라 훨씬 더 자유로운 SLO를 갖는 제3 큐가 오버플로우를 흡수하도록 일반화될 수 있다. 이러한 방식으로, 버스트들에 적응적인 SLA 내에서의 복합 네스팅된 SLO들이 제작될 수 있다. 제공자는 비탄력적 SLA를 충족시키기 위해 많은 피크 용량을 프로비저닝해야 할 필요가 없는 것으로부터 생기는 절감이 네스팅된 SLA를 수락하는 고객들에게 되돌려 넘겨지는 유사하게 서서히 변화되는 비용 모델을 협상할 수 있다.
계층적 서비스 레벨 협약들과는 대조적으로, 여기서 설명된 시스템들 및 방법들은 네스팅되고 또한 서서히 변화되는 SLA들을 도입한다. 고전적인 임계화에 의존하는 대신에, 그리고 검사할 굳게 설정된 "단일" 절 규칙(hard set “single” clause rule)들을 갖는 대신에, SLA의 네스팅된 하위 절은 전체 SLA를 평가하기 위해 다른 하위 절들과 조합되어 평가될 수 있다. 이는 더 복잡한 규칙들을 허용한다. 또한, 하위 절들의 "파싱(parsing)"은 각각의 절의 결과들이 미사용 리소스들의 공유를 생성하도록 허용한다. 이 접근법은 SLA 규칙들에서의 더 많은 유연성 및 클러스터 리소스들의 더 나은 사용을 허용한다. 이 유연성은 리소스 사양이 아닌 "의도(intent)"로서 도입될 수 있고, 이것은 그 후 네스팅된/서서히 변화되는 SLA 규칙들에 매핑되고, 이것들은 그 후 모니터링되고 시행된다.
생산 배치들에서, 공통 패턴은 환경의 일부분에 애플리케이션의 새로운 인스턴스들을 배치하고 더 넓은 모집단으로 롤 아웃하기 전에 사용자 베이스의 작은 서브세트로 테스트하는 것이다(즉, 카나리 롤 아웃(Canary roll-out)). 서비스 레벨 목표들의 점점 더 낮은 레벨들로의 SLA 매핑이 (최적화 및 교정 둘 다의 목적을 위해) 반복적 접근법을 요구한다는 것을 인정하면, 이 SLA 분해에 대한 새로운 워크플로우는 SLA 준수에 대한 영향을 결정하기 위해 제한된 엔드-투-엔드(end-to-end) 방식으로 또는 E2E 솔루션의 서브 컴포넌트들로서 부분적으로 배치할 잠재성을 또한 포함한다.
요약하면, 본 명세서에 기술되는 시스템들 및 방법들은, 현행의 모델로부터, 고객이 의도(예컨대, 레이턴시, 스루풋, 및 신뢰성 속성들)만을 표현하고 오케스트레이션 스택 자체가 그 의도를 달성하기 위해 플랫폼을 셋업하는 목표 주도 접근법으로 이동하여, 오케스트레이션을 달성하는 새로운 방식을 제공한다. 서버리스 인프라스트럭처가 보다 일반화됨에 따라, 클라우드 네이티브(마이크로서비스) 스타일 작업부하들은 결국에는 의도 주도 오케스트레이션 방식을 요구할 것이다. 이러한 함수들 및 다른 것들이 아래에 더 상세히 설명된다.
도 1은 다음의 예들 중 다수에서 "에지 클라우드"라고 지칭되는 처리의 계층을 포함하는, 에지 컴퓨팅을 위한 구성의 개관을 보여주는 블록도(100)이다. 도시된 바와 같이, 에지 클라우드(110)가 액세스 포인트 또는 기지국(140), 로컬 처리 허브(150), 또는 중앙 오피스(120)와 같은 에지 로케이션에 공동 배치되고, 따라서 다중의 엔티티, 디바이스, 및 장비 인스턴스를 포함할 수 있다. 에지 클라우드(110)는 클라우드 데이터 센터(130)보다 엔드포인트(소비자 및 생산자) 데이터 소스들(160)(예를 들어, 자율 차량들(161), 사용자 장비(162), 비즈니스 및 산업 장비(163), 비디오 캡처 디바이스들(164), 드론들(165), 스마트 도시들 및 빌딩 디바이스들(166), 센서들 및 IoT 디바이스들(167) 등)에 훨씬 더 가깝게 위치된다. 에지 클라우드(110) 내의 에지들에 제공되는 컴퓨팅, 메모리, 및 스토리지 리소스들은 엔드포인트 데이터 소스들(160)에 의해 사용되는 서비스들 및 함수들에 대한 초저 레이턴시 응답 시간들을 제공할 뿐만 아니라 에지 클라우드(110)로부터 클라우드 데이터 센터(130)를 향하는 네트워크 백홀 트래픽을 감소시키는 데에 중요하고, 따라서 여러 이점들 중에서도 특히 에너지 소비 및 전체 네트워크 사용을 개선한다.
컴퓨팅, 메모리, 및 스토리지는 부족한 리소스들이고, 일반적으로 에지 로케이션에 좌우되어 감소한다(예를 들어, 기지국에서보다, 중앙 오피스에서보다 소비자 엔드포인트 디바이스에서 이용가능한 처리 리소스가 더 적다). 그러나, 에지 로케이션이 엔드포인트(예를 들어, UE(user equipment))에 더 가까울수록, 그 공간 및 전력이 종종 더 많이 제약된다. 따라서, 에지 컴퓨팅은 지리적으로 그리고 네트워크 액세스 시간 둘 모두에서 더 가깝게 위치되는 더 많은 리소스들의 분포를 통해, 네트워크 서비스들을 위해 필요한 리소스들의 양을 감소시키려고 시도한다. 이러한 방식으로, 에지 컴퓨팅은 적절한 경우 컴퓨팅 리소스들을 작업부하 데이터로 가져오거나, 또는 작업부하 데이터를 컴퓨팅 리소스들로 가져오려고 시도한다.
이하에서는 다중의 잠재적 배치를 커버하고 그리고 일부 네트워크 운영자들 또는 서비스 제공자들이 그들 자신의 인프라스트럭처들에서 가질 수 있는 제한들을 해결하는 에지 클라우드 아키텍처의 양태들을 설명한다. 이것들은 (기지국 레벨에서의 에지들이 예를 들어 멀티 테넌트 시나리오에서 더 제약된 성능 및 능력을 가질 수 있기 때문에) 에지 로케이션에 기초한 구성들의 변형; 에지 로케이션들, 로케이션들의 티어(tier)들, 또는 로케이션들의 그룹들에 이용가능한 컴퓨팅, 메모리, 스토리지, 패브릭, 가속, 또는 유사한 리소스들의 타입에 기초한 구성들; 서비스, 보안, 및 관리 및 오케스트레이션 능력들; 및 최종 서비스들의 유용성 및 성능을 달성하기 위한 관련 목표들을 포함한다. 이들 배치들은 레이턴시, 거리, 및 타이밍 특성들에 좌우되어, "근거리 에지(near edge)", "가까운 에지(close edge)", "로컬 에지(local edge)", "중간 에지(middle edge)", 또는 "원거리 에지(far edge)" 계층들로 간주될 수 있는 네트워크 계층들에서의 처리를 달성할 수 있다.
에지 컴퓨팅은 네트워크의 "에지(Edge)"에서 또는 그에 더 가까운 곳에서, 전형적으로, 데이터를 생산하고 소비하는 엔드포인트 디바이스들에 훨씬 더 가까운 기지국들, 게이트웨이들, 네트워크 라우터들, 또는 다른 디바이스들에서 구현되는 컴퓨팅 플랫폼(예를 들어, x86 또는 ARM 컴퓨팅 하드웨어 아키텍처)의 사용을 통해 컴퓨팅이 수행되는 개발 패러다임이다. 예를 들어, 에지 게이트웨이 서버들은 접속된 클라이언트 디바이스들에 대한 저 레이턴시 사용 사례들(예를 들어, 자율 주행 또는 비디오 감시)에 대해 실시간으로 계산을 수행하기 위해 메모리 및 스토리지 리소스들의 풀을 갖출 수 있다. 또는 예로서, 기지국들은 백홀 네트워크들을 통해 데이터를 추가로 통신하지 않고서, 접속된 사용자 장비에 대한 서비스 작업부하들을 직접 처리하기 위해 컴퓨팅 및 가속 리소스들로 증강될 수 있다. 또는 또 다른 예로서, 중앙 오피스 네트워크 관리 하드웨어는 가상화된 네트워크 함수들을 수행하고 접속된 디바이스들에 대한 서비스들 및 소비자 함수들의 실행을 위한 컴퓨팅 리소스들을 제공하는 표준화된 컴퓨팅 하드웨어로 대체될 수 있다. 에지 컴퓨팅 네트워크들 내에서는, 컴퓨팅 리소스가 데이터로 "이동될(moved)" 서비스들에서의 시나리오들뿐만 아니라, 데이터가 컴퓨팅 리소스로 "이동될(moved)" 시나리오들이 있을 수 있다. 또는 예로서, 기지국 컴퓨팅, 가속 및 네트워크 리소스들은 코너 경우(corner case)들, 긴급 상황들을 관리하기 위해 또는 상당히 더 길게 구현된 라이프사이클에 걸쳐 배치된 리소스들에 대한 오랜 수명(longevity)을 제공하기 위해 휴면 중인 용량(가입, 요구에 따른 용량(capacity on demand))을 활성화함으로써 필요에 따른 기준으로 작업부하 요구들에 스케일링하기 위해 서비스들을 제공할 수 있다.
도 2는 엔드포인트들, 에지 클라우드, 및 클라우드 컴퓨팅 환경들 사이의 동작 계층들을 도시한다. 구체적으로, 도 2는 네트워크 컴퓨팅의 다중의 예시적인 계층 중에서 에지 클라우드(110)를 활용하는 계산 사용 사례들(205)의 예들을 묘사한다. 계층들은 데이터 생성, 분석, 및 데이터 소비 활동들을 수행하기 위해 에지 클라우드(110)에 액세스하는 엔드포인트(디바이스들 및 사물들) 계층(200)에서 시작한다. 에지 클라우드(110)는 게이트웨이를 갖는 에지 디바이스 계층(210), 구내(on-premise) 서버, 또는 물리적으로 근접한 에지 시스템들에 위치되는 네트워크 장비(노드(215)); 기지국들, 무선 처리 유닛들, 네트워크 허브들, 지역 데이터 센터들(DC), 또는 로컬 네트워크 장비(장비(225))를 포함하는 네트워크 액세스 계층(220); 및 그 사이에 위치된 임의의 장비, 디바이스들, 또는 노드들(계층(212)에서, 상세히 예시되지 않음)과 같은 다중의 네트워크 계층에 걸쳐 있을 수 있다. 에지 클라우드(110) 내에서의 그리고 다양한 계층들 중에서의 네트워크 통신들은 묘사되지 않은 커넥티비티(connectivity) 아키텍처들 및 기술들을 통해 발생하는 것을 포함하여, 임의의 수의 유선 또는 무선 매체들을 통해 발생할 수 있다.
네트워크 통신 거리 및 처리 시간 제약들에서 비롯되는 레이턴시의 예들은 엔드포인트 계층(200) 중에 있을 때의 밀리초(ms) 미만으로부터, 에지 디바이스들 계층(210)에서의 5ms 아래, 심지어 네트워크 액세스 계층(220)에서의 노드들과 통신할 때의 10 내지 40ms까지의 범위일 수 있다. 에지 클라우드(110) 너머에는 코어 네트워크(230) 및 클라우드 데이터 센터(240) 계층들이 있고, 각각은 증가하는 레이턴시를 갖는다(예를 들어, 코어 네트워크 계층(230)에서의 50-60ms 사이에서부터 클라우드 데이터 센터 계층에서의 100ms 이상). 그 결과, 적어도 50 내지 100ms 이상의 레이턴시들을 갖는, 코어 네트워크 데이터 센터(235) 또는 클라우드 데이터 센터(245)에서의 동작들은 사용 사례들(205)의 대다수의 시간 임계적 함수들을 달성하지 못할 것이다. 이들 레이턴시 값들 각각은 예시 및 대비 목적을 위해 제공된다; 다른 액세스 네트워크 매체들 및 기술들의 사용이 레이턴시들을 추가로 감소시킬 수 있다는 것이 이해될 것이다. 일부 예들에서, 네트워크의 각자의 부분들은, 네트워크 소스 및 목적지에 대해, "근접 에지(close edge)", "로컬 에지", "근거리 에지(near edge)", "중간 에지", 또는 "원거리 에지" 계층들로서 카테고리화될 수 있다. 예를 들어, 코어 네트워크 데이터 센터(235) 또는 클라우드 데이터 센터(245)의 관점에서 보면, 중앙 오피스 또는 콘텐츠 데이터 네트워크는 "근거리 에지" 계층(클라우드에 "근거리", 사용 사례들(205)의 디바이스들 및 엔드포인트들과 통신할 때 높은 레이턴시 값들을 가짐) 내에 위치되는 것으로 간주될 수 있는 반면, 액세스 포인트, 기지국, 구내 서버, 또는 네트워크 게이트웨이는 "원거리 에지" 계층(클라우드로부터 "원거리", 사용 사례들(205)의 디바이스들 및 엔드포인트들과 통신할 때 저 레이턴시 값들을 가짐) 내에 위치되는 것으로 간주될 수 있다. "가까운", "로컬", "근거리", "중간", 또는 "원거리" 에지를 구성하는 것으로서의 특정 네트워크 계층의 다른 카테고리화들은 네트워크 계층들(200-240) 중 임의의 것에서의 소스로부터 측정되는, 레이턴시, 거리, 네트워크 홉들의 수, 또는 다른 측정가능한 특성들에 기초할 수 있다는 것이 이해될 것이다.
다양한 사용 사례들(205)은 에지 클라우드를 활용하는 다중의 서비스로 인해, 인커밍 스트림들로부터의 사용 압박 하에서 리소스들에 액세스할 수 있다. 저 레이턴시를 갖는 결과들을 달성하기 위해, 에지 클라우드(110) 내에서 실행되는 서비스들은 (a) 우선순위(스루풋 또는 레이턴시) 및 서비스 품질(QoS)(예를 들어, 자율 주행차에 대한 트래픽은 응답 시간 요건의 관점에서 온도 센서보다 더 높은 우선순위를 가질 수 있음; 또는, 응용에 좌우되어, 컴퓨팅/가속기, 메모리, 스토리지, 또는 네트워크 리소스에 성능 민감도/병목이 존재할 수 있음); (b) 신뢰성 및 복원력(예를 들어, 일부 입력 스트림들은 액션을 받을 필요가 있고 트래픽은 미션 크리티컬 신뢰성으로 라우팅될 필요가 있는 한편, 일부 다른 입력 스트림들은 응용에 좌우되어 가끔의 실패를 허용할 수 있음); 및 (c) 물리적 제약들(예를 들어, 전력, 냉각 및 폼 팩터)의 면에서 변하는 요건들을 밸런싱한다.
이러한 사용 사례들에 대한 엔드-투-엔드 서비스 뷰는 서비스 흐름의 개념을 수반하고 트랜잭션과 연관된다. 트랜잭션은 서비스를 소비하는 엔티티에 대한 전체 서비스 요구뿐만 아니라, 리소스들, 작업부하들, 작업 흐름들, 및 비즈니스 함수 및 비즈니스 레벨 요건들에 대한 연관된 서비스들을 상세화한다. 설명된 "조건(terms)"으로 실행되는 서비스들은 서비스의 라이프사이클 동안 트랜잭션에 대한 실시간 및 런타임 계약 준수를 보장하는 방식으로 각각의 계층에서 관리될 수 있다. 트랜잭션 내의 컴포넌트가 SLA에 합의된 것을 놓치고 있을 때, 시스템 전체(트랜잭션 내의 컴포넌트들)는 (1) SLA 위반의 영향을 이해하고, (2) 전체 트랜잭션 SLA를 재개하기 위해 시스템 내의 다른 컴포넌트들을 증강하고, (3) 교정하는 조치들을 구현하는 능력을 제공할 수 있다.
따라서, 이들 변화 및 서비스 특징을 염두에 두고서, 에지 클라우드(110) 내의 에지 컴퓨팅은 사용 사례들(205)의 다중의 애플리케이션(예를 들어, 물체 추적, 비디오 감시, 커넥티드 카(connected car)들 등)을 실시간으로 또는 거의 실시간으로 서빙하고 그에 응답하는 능력을 제공하고, 이들 다중의 애플리케이션에 대한 초저 레이턴시 요건들을 충족시킬 수 있다. 이러한 이점들은, 레이턴시 또는 다른 제한들로 인해 클라우드 컴퓨팅을 활용할 수 없는, 완전히 새로운 클래스의 애플리케이션들(VNF들(Virtual Network Functions), FaaS(Function as a Service), EaaS(Edge as a Service), 표준 프로세스들 등)을 가능하게 한다.
그러나, 에지 컴퓨팅의 이점들과 함께 다음의 주의사항들(caveats)이 따라온다. 에지에 위치된 디바이스들은 종종 리소스 제약되고 따라서 에지 리소스들의 사용에 대한 압박이 있다. 전형적으로, 이는 다중의 사용자(테넌트들) 및 디바이스들에 의한 사용을 위한 메모리 및 스토리지 리소스들의 풀링(pooling)을 통해 해결된다. 에지는 전력 및 냉각 제약될 수 있고 따라서 전력 사용은 가장 많은 전력을 소비하고 있는 애플리케이션들에 의해 고려될 필요가 있다. 이들 풀링된 메모리 리소스에는 내재된 전력 성능 절충들이 있을 수 있는데, 그 이유는 이들 중 다수가 더 많은 전력이 더 큰 메모리 대역폭을 요구하는 신생 메모리 기술들을 사용할 가능성이 있기 때문이다. 마찬가지로, 에지 로케이션들이 무인(unmanned)일 수 있고 심지어 허가된 액세스를 필요로 할 수 있기 때문에(예를 들어, 제3자 로케이션에 하우징될 때), 하드웨어의 개선된 보안과 신뢰 루트의 신뢰된 함수들(root of trust trusted functions)이 또한 요구된다. 이러한 이슈들은 멀티 테넌트, 멀티 오너, 또는 멀티 액세스 설정에서의 에지 클라우드(110)에서 심화되고, 여기서 서비스들 및 애플리케이션들은, 특히 네트워크 사용이 동적으로 요동하고 다중의 이해관계자, 사용 사례들, 및 서비스들의 구성(composition)이 변화함에 따라, 많은 사용자들에 의해 요청된다.
보다 일반적인 레벨에서, 에지 컴퓨팅 시스템은, 클라이언트 및 분산 컴퓨팅 디바이스들로부터 조정을 제공하는, 에지 클라우드(110)에서 동작하는 이전에 논의된 계층들(네트워크 계층들(200-240))에서의 임의의 수의 배치들을 포괄하는 것으로 설명될 수 있다. 하나 이상의 에지 게이트웨이 노드, 하나 이상의 에지 애그리게이션 노드(edge aggregation node), 및 하나 이상의 코어 데이터 센터가 네트워크의 계층들에 걸쳐 분산되어 전기통신 서비스 제공자(telecommunication service provider)("telco", 또는 "TSP"), 사물 인터넷 서비스 제공자, 클라우드 서비스 제공자(cloud service provider, CSP), 엔터프라이즈 엔티티, 또는 임의의 다른 수의 엔티티들에 의해 또는 그를 대신하여 에지 컴퓨팅 시스템의 구현을 제공할 수 있다. 에지 컴퓨팅 시스템의 다양한 구현들 및 구성들은, 예컨대 서비스 목표들을 충족시키도록 오케스트레이션될 때, 동적으로 제공될 수 있다.
본 명세서에 제공된 예들과 일관되게, 클라이언트 컴퓨팅 노드는 데이터의 생산자 또는 소비자로서 통신할 수 있는 임의 타입의 엔드포인트 컴포넌트, 디바이스, 기기, 또는 다른 것으로서 구체화될 수 있다. 또한, 에지 컴퓨팅 시스템에서 사용되는 라벨 "노드" 또는 "디바이스"는 그러한 노드 또는 디바이스가 클라이언트 또는 에이전트/미니온/팔로워 역할에서 동작하는 것을 반드시 의미하지는 않는다; 오히려, 에지 컴퓨팅 시스템 내의 노드들 또는 디바이스들 중 임의의 것은 에지 클라우드(110)를 용이하게 하거나 사용하기 위한 이산 또는 접속된 하드웨어 또는 소프트웨어 구성들을 포함하는 개별 엔티티들, 노드들, 또는 서브시스템들을 지칭한다.
이와 같이, 에지 클라우드(110)는 네트워크 계층들(210-230) 중에서 에지 게이트웨이 노드들, 에지 애그리게이션 노드들, 또는 다른 에지 컴퓨팅 노드들에 의해 그리고 그 내에서 동작되는 네트워크 컴포넌트들 및 함수 피처들로부터 형성된다. 따라서 에지 클라우드(110)는, 본 명세서에서 논의되는, 라디오 액세스 네트워크(radio access network, RAN) 가능 엔드포인트 디바이스들(예를 들어, 모바일 컴퓨팅 디바이스들, IoT 디바이스들, 스마트 디바이스들 등)에 근접하게 위치되는 에지 컴퓨팅 및/또는 스토리지 리소스들을 제공하는 임의 타입의 네트워크로서 구체화될 수 있다. 다시 말해서, 에지 클라우드(110)는, 모바일 캐리어 네트워크들(예를 들어, GSM(Global System for Mobile Communications) 네트워크들, LTE(Long-Term Evolution) 네트워크들, 5G/6G 네트워크들 등)을 포함하는, 서비스 제공자 코어 네트워크들 내로의 입구 포인트의 역할을 하는 전통적인 네트워크 액세스 포인트들과 엔드포인트 디바이스들을 접속하면서, 또한 스토리지 및/또는 컴퓨팅 능력들을 제공하는 "에지"로서 구상될 수 있다. 다른 타입들 및 형식들의 네트워크 액세스(예를 들어, Wi-Fi, 장거리 무선, 광학 네트워크들을 포함하는 유선 네트워크들)가 또한 그러한 3GPP 캐리어 네트워크들 대신에 또는 그와 조합되어 활용될 수 있다.
에지 클라우드(110)의 네트워크 컴포넌트들은 서버들, 멀티 테넌트 서버들, 기기 컴퓨팅 디바이스들, 및/또는 임의의 다른 타입의 컴퓨팅 디바이스들일 수 있다. 예를 들어, 에지 클라우드(110)는 하우징, 섀시, 케이스 또는 쉘(shell)을 포함하는 자족적인 전자 디바이스인 기기 컴퓨팅 디바이스를 포함할 수 있다. 일부 상황들에서, 하우징은 휴대성을 위해 치수가 정해져서 인간에 의해 휴대되고 및/또는 선적될 수 있도록 할 수 있다. 예시적인 하우징들은 기기의 콘텐츠를 부분적으로 또는 완전히 보호하는 하나 이상의 외부 표면을 형성하는 재료들을 포함할 수 있고, 여기서 보호는 내기후성, 위험한 환경 보호(예를 들어, EMI, 진동, 극한 온도들)를 포함할 수 있고 및/또는 수중 사용(submergibility)을 가능하게 할 수 있다. 예시적인 하우징들은, AC 전력 입력들, DC 전력 입력들, AC/DC 또는 DC/AC 컨버터(들), 전력 조정기들, 변압기들, 충전 회로, 배터리들, 유선 입력들 및/또는 무선 전력 입력들과 같은, 고정식 및/또는 휴대용 구현들을 위한 전력을 제공하는 전력 회로를 포함할 수 있다. 예시적인 하우징들 및/또는 그것의 표면들은 빌딩들, 전기통신 구조물들(예를 들어, 기둥들, 안테나 구조물들 등) 및/또는 랙들(예를 들어, 서버 랙들, 블레이드 마운트들 등)과 같은 구조물들에의 부착을 가능하게 하기 위해 장착 하드웨어에 연결되거나 이를 포함할 수 있다. 예시적인 하우징들 및/또는 그것의 표면들은 하나 이상의 센서(예를 들어, 온도 센서들, 진동 센서들, 광 센서들, 음향 센서들, 용량성 센서들, 근접 센서들 등)를 지지할 수 있다. 하나 이상의 그러한 센서는 표면에 포함되거나, 표면에 의해 휴대되거나, 또는 달리 표면에 임베드되고 및/또는 기기의 표면에 장착될 수 있다. 예시적인 하우징들 및/또는 그것의 표면들은 추진 하드웨어(예를 들어, 바퀴들, 프로펠러들 등) 및/또는 관절식 하드웨어(예를 들어, 로봇 암들, 피봇 가능한 부속물들 등)와 같은 기계적 연결을 지원할 수 있다. 일부 상황들에서, 센서들은 사용자 인터페이스 하드웨어(예를 들어, 버튼, 스위치, 다이얼, 슬라이더 등)와 같은 임의 타입의 입력 디바이스들을 포함할 수 있다. 일부 상황들에서, 예시적인 하우징들은 그 안에 포함되거나, 그에 의해 휴대되거나, 그 안에 임베드되고 및/또는 그것에 부착된 출력 디바이스들을 포함한다. 출력 디바이스들은 디스플레이들, 터치스크린들, 라이트들, LED들, 스피커들, I/O 포트들(예를 들어, USB) 등을 포함할 수 있다. 일부 상황들에서, 에지 디바이스들은 특정 목적(예를 들어, 교통 신호등)을 위해 네트워크에서 제시되는 디바이스들이지만, 다른 목적들을 위해 활용될 수 있는 처리 및/또는 다른 능력들을 가질 수 있다. 그러한 에지 디바이스들은 다른 네트워킹된 디바이스들과 독립적일 수 있으며, 그의 주요 목적에 적합한 폼 팩터를 갖는 하우징을 구비할 수 있고; 그렇지만 그의 주 태스크를 방해하지 않는 다른 컴퓨팅 태스크들을 위해 이용가능할 수 있다. 에지 디바이스들은 사물 인터넷 디바이스들을 포함한다. 기기 컴퓨팅 디바이스는 디바이스 온도, 진동, 리소스 활용, 업데이트, 전력 문제, 물리적 및 네트워크 보안 등과 같은 로컬 문제들을 관리하기 위한 하드웨어 및 소프트웨어 컴포넌트들을 포함할 수 있다. 기기 컴퓨팅 디바이스를 구현하기 위한 예시적인 하드웨어가 도 6b와 관련하여 기술된다. 에지 클라우드(110)는 하나 이상의 서버 및/또는 하나 이상의 멀티 테넌트 서버를 또한 포함할 수 있다. 이러한 서버는 운영 체제를 포함하고 가상 컴퓨팅 환경을 구현할 수 있다. 가상 컴퓨팅 환경은 하나 이상의 가상 머신, 하나 이상의 컨테이너 등을 관리하는(예를 들어, 생성(spawning), 배치, 파괴하는 등) 하이퍼바이저를 포함할 수 있다. 그러한 가상 컴퓨팅 환경들은 하나 이상의 애플리케이션 및/또는 다른 소프트웨어, 코드 또는 스크립트가 하나 이상의 다른 애플리케이션, 소프트웨어, 코드 또는 스크립트로부터 격리되면서 실행될 수 있는 실행 환경을 제공한다.
도 3에서는, 다양한 클라이언트 엔드포인트들(310)(모바일 디바이스들, 컴퓨터들, 자율 차량들, 비즈니스 컴퓨팅 장비, 산업 처리 장비의 형식임)이 엔드포인트 네트워크 애그리게이션의 타입에 특정적인 요청들 및 응답들을 교환한다. 예를 들어, 클라이언트 엔드포인트들(310)은 구내 네트워크 시스템(332)을 통해 요청들 및 응답들(322)을 교환함으로써, 유선 광대역 네트워크를 통해 네트워크 액세스를 획득할 수 있다. 모바일 컴퓨팅 디바이스들과 같은 일부 클라이언트 엔드포인트들(310)은 액세스 포인트(예를 들어, 셀룰러 네트워크 타워)(334)를 통해 요청들 및 응답들(324)을 교환함으로써, 무선 광대역 네트워크를 통해 네트워크 액세스를 획득할 수 있다. 자율 차량들과 같은 일부 클라이언트 엔드포인트들(310)은 거리 위치 네트워크 시스템(336)을 통해 무선 차량 네트워크를 통해 요청들 및 응답들(326)에 대한 네트워크 액세스를 획득할 수 있다. 그러나, 네트워크 액세스의 타입에 관계없이, TSP는 트래픽 및 요청들을 애그리게이션하기 위해 에지 클라우드(110) 내에 애그리게이션 포인트들(342, 344)을 배치할 수 있다. 따라서, 에지 클라우드(110) 내에서, TSP는 요청된 콘텐츠를 제공하기 위해, 예컨대 에지 애그리게이션 노드들(340)에서, 다양한 컴퓨팅 및 스토리지 리소스들을 배치할 수 있다. 에지 클라우드(110)의 에지 애그리게이션 노드들(340) 및 다른 시스템들은 클라우드 또는 데이터 센터(360)에 접속되고, 이것은 백홀 네트워크(350)를 사용하여 웹사이트들, 애플리케이션들, 데이터베이스 서버들 등에 대한 클라우드/데이터 센터로부터의 더 높은 레이턴시 요청들을 충족시킨다. 단일 서버 프레임워크 상에 배치된 것들을 포함하여, 에지 애그리게이션 노드들(340) 및 애그리게이션 포인트들(342, 344)의 추가적인 또는 통합된 인스턴스들이 또한 에지 클라우드(110) 또는 TSP 인프라스트럭처의 다른 영역들 내에 존재할 수 있다.
도 4는 다중의 에지 노드 및 이러한 에지 노드들을 사용하는 다중의 테넌트(예컨대, 사용자들, 제공자들) 간에 동작되는 에지 컴퓨팅 시스템에 걸친 가상화된 및 컨테이너 기반 에지 구성들에 대한 배치 및 오케스트레이션을 도시하고 있다. 구체적으로, 도 4는 다양한 가상 에지 인스턴스들에 액세스하는, 다양한 클라이언트 엔드포인트들(410)(예를 들어, 스마트 도시들/빌딩 시스템들, 모바일 디바이스들, 컴퓨팅 디바이스들, 비즈니스/물류 시스템들, 산업 시스템들 등)에 대한 요청들 및 응답들을 충족시키기 위한, 에지 컴퓨팅 시스템(400)에서의 제1 에지 노드(422) 및 제2 에지 노드(424)의 조정을 묘사한다. 여기서, 가상 에지 인스턴스들(432, 434)은 에지 클라우드에서의 처리 및 에지 컴퓨팅 능력들을 제공하고, 웹사이트들, 애플리케이션들, 데이터베이스 서버들 등에 대한 더 높은 레이턴시 요청들을 위해 클라우드/데이터 센터(440)에 액세스한다. 그러나, 에지 클라우드는 다중의 테넌트 또는 엔티티에 대한 다중의 에지 노드 간의 처리의 조정을 가능하게 한다.
도 4의 예에서, 이러한 가상 에지 인스턴스들은 다음을 포함한다: 에지 스토리지, 컴퓨팅, 및 서비스들의 제1 조합을 제공하는, 제1 테넌트(테넌트 1)에게 제공되는 제1 가상 에지(432); 및 에지 스토리지, 컴퓨팅 및 서비스들의 제2 조합을 제공하는 제2 가상 에지(434). 가상 에지 인스턴스들(432, 434)은 에지 노드들(422, 424) 사이에 분산되고, 요청 및 응답이 동일한 또는 상이한 에지 노드들로부터 충족되는 시나리오들을 포함할 수 있다. 분산되지만 조정된 방식으로 동작하는 에지 노드들(422, 424)의 구성은 에지 프로비저닝 함수들(450)에 기초하여 발생한다. 다중의 테넌트 사이에서, 애플리케이션들 및 서비스들에 대한 조정된 동작을 제공하는 에지 노드들(422, 424)의 기능성은 오케스트레이션 함수들(460)에 기초하여 발생한다.
(410)에서의 디바이스들 중 일부는 테넌트 1이 테넌트1 '슬라이스' 내에서 기능할 수 있는 한편 테넌트 2가 테넌트2 슬라이스 내에서 기능할 수 있는 (그리고, 추가 예들에서, 추가적인 또는 서브 테넌트들이 존재할 수 있고; 및 각각의 테넌트는 심지어 특정 하드웨어 피처들에 대해 하루 종일 특정의 피처들의 세트에 구체적으로 자격이 주어지고 트랜잭션적으로 결부될 수 있음) 멀티 테넌트 디바이스들이라는 것을 이해해야 한다. 신뢰된 멀티 테넌트 디바이스는 키와 슬라이스의 조합이 "RoT(root of trust)" 또는 테넌트 특정적 RoT로 고려될 수 있도록 테넌트 특정적 암호 키를 추가로 포함할 수 있다. RoT는 DICE(Device Identity Composition Engine) 아키텍처를 사용하여 동적으로 구성되도록 추가로 계산될 수 있으며, 따라서 단일 DICE 하드웨어 빌딩 블록이 (FPGA(Field Programmable Gate Array)와 같은) 디바이스 능력들의 계층화를 위한 계층화된 신뢰 컴퓨팅 베이스 컨텍스트들을 구성하기 위해 사용될 수 있다. RoT는 멀티 테넌시(multi-tenancy)를 지원하기 위해 유용한 "팬 아웃(fan-out)"을 가능하게 하기 위해 신뢰 컴퓨팅 컨텍스트를 위해 추가로 사용될 수 있다. 멀티 테넌트 환경 내에서, 각자의 에지 노드들(422, 424)은 노드당 다중의 테넌트에 할당된 로컬 리소스들에 대한 보안 피처 시행 포인트들로서 동작할 수 있다. 추가적으로, 테넌트 런타임 및 애플리케이션 실행(예를 들어, 인스턴스들(432, 434)에서)은 잠재적으로 다중의 물리적 호스팅 플랫폼에 걸쳐 있는 리소스들의 가상 에지 추상화를 생성하는 보안 피처에 대한 시행 포인트로서 역할을 할 수 있다. 마지막으로, 오케스트레이션 엔티티에서의 오케스트레이션 함수들(460)은 테넌트 경계들을 따라 리소스들을 집결시키기 위한 보안 피처 시행 포인트로서 동작할 수 있다.
에지 컴퓨팅 노드들은 리소스들(메모리, CPU(central processing unit), GPU(graphics processing unit), 인터럽트 컨트롤러, 입력/출력 I/O 컨트롤러, 메모리 컨트롤러, 버스 컨트롤러 등)을 파티셔닝할 수 있고, 여기서 각자의 파티셔닝은 RoT 능력을 포함할 수 있고, 여기서 DICE 모델에 따른 팬 아웃 및 계층화가 에지 노드들에 추가로 적용될 수 있다. 클라우드 컴퓨팅 노드들은 종종 컨테이너들, FaaS 엔진들, 서블릿들, 서버들, 또는 각각에 대한 RoT 컨텍스트를 지원하기 위해 DICE 계층화 및 팬 아웃 구조에 따라 파티셔닝될 수 있는 다른 계산 추상화를 사용한다. 따라서, 디바이스들(410, 422, 및 440)에 걸쳐 있는 각자의 RoT들은 DTCB(distributed trusted computing base)의 확립을 조정할 수 있어서, 모든 요소들을 엔드 투 엔드(end to end)로 링크하는 테넌트 특정적 가상 신뢰 보안 채널이 확립될 수 있도록 한다.
또한, 컨테이너는 이전의 에지 노드로부터 그것의 콘텐츠를 보호하는 데이터 또는 작업부하 특정적 키들을 가질 수 있다는 것이 이해될 것이다. 컨테이너의 마이그레이션의 일환으로서, 소스 에지 노드에서의 포드 컨트롤러(pod controller)는 타겟 에지 노드 포드 컨트롤러로부터 마이그레이션 키를 획득할 수 있고, 여기서 마이그레이션 키는 컨테이너 특정적 키들을 랩핑(wrap)하기 위해 사용된다. 컨테이너/포드가 타겟 에지 노드로 마이그레이션될 때, 언랩핑 키는 포드 컨트롤러에 노출되고 포드 컨트롤러는 그 후 랩핑된 키들을 암호 해제한다. 키들은 이제 컨테이너 특정적 데이터에 대한 동작들을 수행하기 위해 사용될 수 있다. 마이그레이션 함수들은 적절히 증명된 에지 노드들 및 포드 관리자들에 의해 게이팅될 수 있다(위에 설명된 바와 같이).
추가 예들에서, 에지 컴퓨팅 시스템은 다중 소유자, 멀티 테넌트 환경에서 컨테이너들(코드 및 필요한 의존성들을 제공하는 컨테이닝된, 배치가능한 소프트웨어의 유닛)의 사용을 통해 다중의 애플리케이션의 오케스트레이션을 제공하도록 확장된다. 도 4에서 신뢰 '슬라이스' 개념의 프로비저닝 및 라이프사이클과 관련된 키 관리, 신뢰 앵커 관리, 및 다른 보안 함수들을 수행하기 위해 멀티 테넌트 오케스트레이터가 사용될 수 있다. 예를 들어, 에지 컴퓨팅 시스템은 다중의 가상 에지 인스턴스로부터(그리고, 클라우드 또는 원격 데이터 센터로부터) 다양한 클라이언트 엔드포인트들에 대한 요청들 및 응답들을 충족시키도록 구성될 수 있다. 이들 가상 에지 인스턴스들의 사용은 다중의 테넌트 및 다중의 애플리케이션(예를 들어, AR(augmented reality)/VR(virtual reality), 기업 애플리케이션들, 콘텐츠 전달(content delivery), 게이밍, 컴퓨팅 오프로드)을 동시에 지원할 수 있다. 또한, 가상 에지 인스턴스들 내에 다중 타입의 애플리케이션들(예를 들어, 정상 애플리케이션들; 레이턴시 민감 애플리케이션들; 레이턴시 중요 애플리케이션들; 사용자 평면 애플리케이션들; 네트워킹 애플리케이션들; 등)이 있을 수 있다. 가상 에지 인스턴스들은 또한 상이한 지리적 로케이션들에 있는 다중의 소유자의 시스템들(또는, 다중의 소유자에 의해 공동 소유되거나 공동 관리되는 각자의 컴퓨팅 시스템들 및 리소스들)에 걸쳐 있을 수 있다.
예를 들어, 각각의 에지 노드(422, 424)는 하나 이상의 컨테이너의 그룹을 제공하는 컨테이너 "포드"(426, 428)의 사용에 의한 것과 같은 컨테이너들의 사용을 구현할 수 있다. 하나 이상의 컨테이너 포드를 사용하는 설정에서, 포드 컨트롤러 또는 오케스트레이터가 포드 내의 컨테이너들의 로컬 제어 및 오케스트레이션을 담당한다. 각자의 에지 슬라이스들(432, 434)에 대해 제공되는 다양한 에지 노드 리소스들(예를 들어, 6각형으로 묘사된, 스토리지, 컴퓨팅, 서비스들)은 각각의 컨테이너의 필요에 따라 파티셔닝된다.
컨테이너 포드들의 사용으로, 포드 컨트롤러가 컨테이너들 및 리소스들의 파티셔닝 및 할당을 감독한다. 포드 컨트롤러는, 예컨대 SLA 계약들에 기초하여 KPI(key performance indicator) 타겟들을 수신함으로써, 물리 리소스들을 어떻게 최상으로 파티셔닝할지에 대해 그리고 어떤 지속기간 동안 컨트롤러에게 지시하는 지시들을 오케스트레이터(예를 들어, 오케스트레이터(460))로부터 수신한다. 포드 컨트롤러는 작업부하를 완료하고 SLA를 만족시키기 위해 어느 컨테이너가 어느 리소스들을 그리고 얼마나 오랫동안 필요로 하는지를 결정한다. 포드 컨트롤러는 또한: 컨테이너를 생성하는 것, 그것에 리소스들 및 애플리케이션들을 프로비저닝하는 것, 분산된 애플리케이션 상에서 함께 작업하는 다중의 컨테이너 사이의 중간 결과들을 조정하는 것, 작업부하가 완료될 때 컨테이너들을 해체하는 것, 및 그와 유사한 것과 같은 컨테이너 라이프사이클 동작들을 관리한다. 추가적으로, 포드 컨트롤러는 올바른 테넌트가 인증할 때까지 리소스들의 할당을 방지하거나 또는 증명 결과가 만족될 때까지 컨테이너에 데이터 또는 작업부하를 프로비저닝하는 것을 방지하는 보안 역할을 서빙할 수 있다.
또한, 컨테이너 포드들의 사용으로, 테넌트 경계들이 여전히 그러나 컨테이너들의 각각의 포드의 컨텍스트에서 존재할 수 있다. 각각의 테넌트 특정적 포드가 테넌트 특정적 포드 컨트롤러를 갖는 경우, 전형적인 리소스 고갈 상황들을 회피하기 위해 리소스 할당 요청들을 통합하는 공유 포드 컨트롤러가 있을 것이다. 포드 및 포드 컨트롤러의 증명 및 신뢰성을 보장하기 위해 추가 제어들이 제공될 수 있다. 예를 들어, 오케스트레이터(460)는 증명 검증을 수행하는 로컬 포드 컨트롤러들에게 증명 검증 정책을 프로비저닝할 수 있다. 증명이 제2 테넌트 포드 컨트롤러가 아니라 제1 테넌트 포드 컨트롤러에 대한 정책을 만족시키는 경우, 제2 포드는 그것을 만족시키는 상이한 에지 노드로 마이그레이션될 수 있다. 대안적으로, 제1 포드는 실행하도록 허용될 수 있고 상이한 공유 포드 컨트롤러가 제2 포드가 실행하기 전에 설치되고 기동된다.
도 5는 에지 컴퓨팅 시스템에서 컨테이너들을 배치하는 추가적인 컴퓨팅 배열들을 도시한다. 단순화된 예로서, 시스템 배열들(510, 520)은 포드 컨트롤러(예를 들어, 컨테이너 관리자들(511, 521), 및 컨테이너 오케스트레이터(531))가 컴퓨팅 노드들(배열(510) 내의 (515))을 통한 실행을 통해 컨테이너화된 포드들, 함수들, 및 FaaS(functions-as-a-service) 인스턴스들을 론칭하도록, 또는 컴퓨팅 노드들(배열(520) 내의 (523))을 통한 실행을 통해 컨테이너화된 가상화된 네트워크 함수들을 개별적으로 실행하도록 적응되는 설정들을 묘사한다. 이 배열은 (컴퓨팅 노드들(537)을 사용하는) 시스템 배열(530)에서 다중의 테넌트의 사용을 위해 적응되는데, 여기서 컨테이너화된 포드들(예를 들어, 포드들(512)), 함수들(예를 들어, 함수들(513), VNF들(522, 536)), 및 FaaS(functions-as-a-service) 인스턴스들(예를 들어, FaaS 인스턴스(514))은 각자의 테넌트들에 특정적인 가상 머신들(예를 들어, 테넌트들(532, 533)에 대한 VM들(534, 535)) 내에서 론칭된다(가상화된 네트워크 함수들의 실행 이외에). 이 배열은 컨테이너들(542, 543)을 제공하는 시스템 배열(540)에서의 사용, 또는 컨테이너 기반 오케스트레이션 시스템(541)에 의해 조정되는 바와 같은, 컴퓨팅 노드들(544) 상에서의 다양한 함수들, 애플리케이션들, 및 함수들의 실행을 위해 추가로 적응된다.
도 5에 묘사된 시스템 배열들은 애플리케이션 구성(application composition)의 면에서 VM들, 컨테이너들, 및 함수들을 동등하게 취급하는 아키텍처를 제공할 수 있다(그리고 결과적인 애플리케이션들은 이들 3개의 구성 요소의 조합들이다). 각각의 구성 요소는 로컬 백엔드로서 하나 이상의 가속기(FPGA, ASIC) 컴포넌트의 사용을 수반할 수 있다. 이러한 방식으로, 애플리케이션들은, 오케스트레이터에 의해 조정된, 다중의 에지 소유자에 걸쳐 스플릿될 수 있다.
도 5의 컨텍스트에서, 포드 컨트롤러/컨테이너 관리자, 컨테이너 오케스트레이터, 및 개별 노드들은 보안 시행 포인트를 제공할 수 있다. 그러나, 어느 한 테넌트에 할당된 리소스들이 제2 테넌트에 할당된 리소스들과 구별되는 테넌트 격리가 오케스트레이션될 수 있지만, 에지 소유자들은 리소스 할당들이 테넌트 경계들에 걸쳐 공유되지 않도록 보장하기 위해 협력한다. 또는, 테넌트 경계들에 걸쳐 리소스 할당들이 격리될 수 있는데, 이는 테넌트들이 가입 또는 트랜잭션/계약 기준을 통해 "사용"을 허용할 수 있기 때문이다. 이들 컨텍스트에서, 테넌시(tenancy)를 시행하기 위해 에지 소유자들에 의해 가상화, 컨테이너화, 인클레이브들(enclaves) 및 하드웨어 파티셔닝 스킴들이 사용될 수 있다. 다른 격리 환경들은: 베어 메탈(bare metal)(전용) 장비, 가상 머신들, 컨테이너들, 컨테이너들 상의 가상 머신들, 또는 이들의 조합들을 포함할 수 있다.
추가 예들에서, 소프트웨어 정의된 또는 제어된 실리콘 하드웨어, 및 다른 구성 가능 하드웨어의 양태들이 에지 컴퓨팅 시스템의 애플리케이션들, 함수들, 및 서비스들과 통합될 수 있다. SDSi(software defined silicon)가 (예를 들어, 하드웨어 구성 자체 내에서의 새로운 피처들의 업그레이드, 재구성, 또는 프로비저닝에 의해) 자체의 일부분 또는 작업부하를 교정하는 구성 요소의 능력에 기초하여, 일부 리소스 또는 하드웨어 구성 요소가 계약 또는 서비스 레벨 협약을 충족하는 능력을 보장하기 위해 사용될 수 있다.
추가 예들에서, 본 에지 컴퓨팅 시스템들 및 환경을 참조하여 논의된 컴퓨팅 노드들 또는 디바이스들 중 임의의 것이 도 6a 및 도 6b에 묘사된 컴포넌트들에 기초하여 이행될 수 있다. 각자의 에지 컴퓨팅 노드들은 다른 에지, 네트워킹, 또는 엔드포인트 컴포넌트들과 통신할 수 있는 어느 한 타입의 디바이스, 기기, 컴퓨터, 또는 다른 "사물(thing)"로서 구체화될 수 있다. 예를 들어, 에지 컴퓨팅 디바이스는 개인 컴퓨터, 서버, 스마트폰, 모바일 컴퓨팅 디바이스, 스마트 기기, 차량내 컴퓨팅 시스템(예를 들어, 내비게이션 시스템), 외부 케이스, 쉘 등을 갖는 자족적인(self-contained) 디바이스, 또는 설명된 함수들을 수행 가능한 다른 디바이스 또는 시스템으로서 구체화될 수 있다.
도 6a에 묘사된 단순화된 예에서, 에지 컴퓨팅 노드(600)는 컴퓨팅 엔진(본 명세서에서 "컴퓨팅 회로"로서 또한 지칭됨)(602), 입력/출력(I/O) 서브시스템(본 명세서에서 "I/O 회로"라고도 지칭됨)(608), 데이터 스토리지(본 명세서에서 "데이터 스토리지 회로"로서 또한 지칭됨)(610), 통신 회로 서브시스템(612), 및, 선택적으로 하나 이상의 주변 디바이스(본 명세서에서 "주변 디바이스 회로"로서 또한 지칭됨)(614)를 포함한다. 다른 예들에서, 각자의 컴퓨팅 디바이스들은 컴퓨터에서 전형적으로 발견되는 것들(예를 들어, 디스플레이, 주변 디바이스들 등)과 같은 다른 또는 추가적인 컴포넌트들을 포함할 수 있다. 추가적으로, 일부 예들에서, 예시적인 컴포넌트들 중 하나 이상은 또 다른 컴포넌트에 통합되거나 다른 경우에는 또 다른 컴포넌트의 일부분을 형성할 수 있다.
컴퓨팅 노드(600)는 다양한 컴퓨팅 함수들을 수행할 수 있는 임의 타입의 엔진, 디바이스, 또는 디바이스들의 컬렉션으로서 구체화될 수 있다. 일부 예들에서, 컴퓨팅 노드(600)는 집적 회로, 임베디드 시스템, FPGA(field-programmable gate array), SOC(system-on-a-chip), 또는 다른 통합 시스템 또는 디바이스와 같은 단일 디바이스로서 구체화될 수 있다. 예시적인 예에서, 컴퓨팅 노드(600)는 프로세서(본 명세서에서 "프로세서 회로"로서 또한 지칭됨)(604) 및 메모리(본 명세서에서 "메모리 회로"로서 또한 지칭됨)(606)를 포함하거나 이로서 구체화된다. 프로세서(604)는 본 명세서에 설명된 함수들을 수행할 수 있는(예를 들어, 애플리케이션을 실행할 수 있는) 임의 타입의 프로세서(들)로서 구체화될 수 있다. 예를 들어, 프로세서(604)는 멀티 코어 프로세서(들), 마이크로컨트롤러, 처리 유닛, 특수화된 또는 특수 목적 처리 유닛, 또는 다른 프로세서 또는 처리/제어 회로로서 구체화될 수 있다.
일부 예들에서, 프로세서(604)는 FPGA, ASIC(application specific integrated circuit), 재구성 가능 하드웨어 또는 하드웨어 회로, 또는 본 명세서에서 설명된 함수들의 수행을 용이하게 하기 위한 다른 특수화된 하드웨어로서 구체화되거나, 이들을 포함하거나, 이들에 결합될 수 있다. 또한 일부 예들에서, 프로세서(604)는 DPU(data processing unit), IPU(infrastructure processing unit), 또는 NPU(network processing unit)라고도 알려진 특수화된 x-처리 유닛(x-PU)으로서 구체화될 수 있다. 이러한 xPU는 SOC 내에 통합되거나, 네트워킹 회로(예를 들어, SmartNIC, 또는 개선된 SmartNIC), 가속 회로, 스토리지 디바이스들, 스토리지 디스크들, 또는 AI 하드웨어(예를 들어, GPU들 또는 프로그래밍된 FPGA들)와 통합되는 독립형 회로 또는 회로 패키지로서 구체화될 수 있다. 그러한 x-PU는 하나 이상의 데이터 스트림을 처리하기 위해 프로그래밍을 수신하고, 검색하고 및/또는 다른 경우에는 획득하고 및 CPU 또는 범용 처리 하드웨어 밖에서 (마이크로서비스들을 호스팅하는 것, 서비스 관리 또는 오케스트레이션을 수행하는 것, 서버 또는 데이터 센터 하드웨어를 조직 또는 관리하는 것, 서비스 메시들을 관리하는 것, 또는 텔레메트리를 수집 및 분배하는 것과 같은) 데이터 스트림들에 대한 특정 태스크들 및 액션들을 수행하도록 설계될 수 있다. 그렇지만, x-PU, SOC, CPU, 및 프로세서(604)의 다른 변형들이 컴퓨팅 노드(600) 내에서 그리고 그를 대신하여 많은 타입의 동작들 및 명령어들을 실행하기 위해 서로 협력하여 동작할 수 있다는 것을 이해할 것이다.
메모리(606)는 본 명세서에서 설명된 함수들을 수행할 수 있는 임의 타입의 휘발성(예를 들어, DRAM(dynamic random access memory) 등) 또는 비휘발성 메모리 또는 데이터 스토리지로서 구체화될 수 있다. 휘발성 메모리(volatile memory)는 매체에 의해 저장된 데이터의 상태를 유지하기 위해 전력을 요구하는 스토리지 매체일 수 있다. 휘발성 메모리의 비제한적인 예들은 다양한 타입의 RAM(random access memory), 예컨대 DRAM 또는 SRAM(static random access memory)을 포함할 수 있다. 메모리 모듈에서 사용될 수 있는 하나의 특정 타입의 DRAM은 SDRAM(Synchronous Dynamic Random Access Memory)이다.
예에서, 메모리 디바이스(예를 들어, 메모리 회로)는 NAND 또는 NOR 기술들(예를 들어, SLC(Single-Level Cell), MLC(Multi-Level Cell), QLC(Quad-Level Cell), TLC(Tri-Level Cell), 또는 일부 다른 NAND)에 기초하는 것들과 같은, 임의의 수의 블록 어드레싱가능 메모리 디바이스들이다. 일부 예들에서, 메모리 디바이스(들)는 바이트 어드레싱가능 라이트-인-플레이스(write-in-place) 3차원 크로스포인트 메모리 디바이스, 또는 다른 바이트 어드레싱가능 라이트-인-플레이스 NVM(non-volatile memory) 디바이스들, 예컨대 단일 또는 멀티-레벨 PCM(Phase Change Memory) 또는 PCMS(phase change memory with a switch), 칼코게나이드 상 변화 재료(예를 들어, 칼코게나이드 유리)를 사용하는 NVM 디바이스들, 금속 산화물 베이스(metal oxide base), 산소 베이컨시 베이스(oxygen vacancy base) 및 CB-RAM(Conductive Bridge Random Access Memory)을 포함하는 저항성 메모리, 나노와이어 메모리, FeTRAM(ferroelectric transistor random access memory), 멤리스터 기술을 포함하는 MRAM(magneto resistive random access memory), STT(spin transfer torque)-MRAM, 스핀트로닉 자기 접합 메모리 기반 디바이스, MTJ(magnetic tunneling junction) 기반 디바이스, DW(Domain Wall) 및 SOT(Spin Orbit Transfer) 기반 디바이스, 사이리스터 기반 메모리 디바이스, 상기 중 어느 것의 조합, 또는 다른 적합한 메모리를 포함한다. 메모리 디바이스는 3차원 크로스포인트 메모리 디바이스(예를 들어, Intel® 3D XPoint™ 메모리), 또는 다른 바이트 어드레싱가능 라이트-인 플레이스 비휘발성 메모리 디바이스들을 또한 포함할 수 있다. 메모리 디바이스는 다이 자체 및/또는 패키징된 메모리 제품을 지칭할 수 있다. 일부 예들에서, 3D 크로스포인트 메모리(예를 들어, Intel® 3D XPoint™ 메모리)는 메모리 셀들이 워드 라인들과 비트 라인들의 교차점에 놓이고 개별적으로 어드레싱가능하며 비트 스토리지가 벌크 저항(bulk resistance)의 변화에 기초하는 무트랜지스터 적층가능 크로스 포인트 아키텍처(transistor-less stackable cross point architecture)를 포함할 수 있다. 일부 예들에서, 메모리(606)의 전부 또는 일부는 프로세서(604)에 통합될 수 있다. 메모리(606)는 하나 이상의 애플리케이션, 애플리케이션(들)에 의해 조작되는 데이터, 라이브러리들, 및 드라이버들과 같은 동작 동안 사용되는 다양한 소프트웨어 및 데이터를 저장할 수 있다.
일부 예들에서, 저항기 기반 및/또는 무트랜지스터 메모리 아키텍처들이 상변화 재료의 볼륨이 적어도 2개의 전극 사이에 존재하는 나노미터 스케일 PCM(phase-change memory) 디바이스들을 포함한다. 예시적인 상변화 재료의 부분들은 결정질 상들 및 비정질 상들의 변화하는 정도들을 드러내는데, 여기서 적어도 2개의 전극 사이의 저항의 변화하는 정도들이 측정될 수 있다. 일부 예들에서, 상변화 재료는 칼코게나이드 기반 유리 재료이다. 그러한 저항성 메모리 디바이스들은 때때로 이전에 그들을 통해 흐른 전류의 이력을 기억하는 멤리스티브 디바이스(memristive device)들로서 지칭된다. 저장된 데이터는 전기 저항을 측정함으로써 예시적인 PCM 디바이스들로부터 검색되며, 여기서 결정질 상들은 비교적 높은 저항 값(들)(예로서, 논리 "1")을 갖는 비정질 상들과 비교할 때 비교적 낮은 저항 값(들)(예로서, 논리 "0")을 드러낸다.
예시적인 PCM 디바이스들은 장기간(예를 들어, 실온에서 대략 10년) 동안 데이터를 저장한다. 예시적인 PCM 디바이스들에 대한 기입 동작들(예를 들어, 논리 "0"에 설정, 논리 "1"에 설정, 중간 저항 값에 설정)은 적어도 2개의 전극에 하나 이상의 전류 펄스를 인가함으로써 달성되며, 여기서 펄스들은 특정 전류 크기 및 지속 기간을 갖는다. 예를 들어, 적어도 2개의 전극에 인가된 긴 저전류 펄스(SET)는 예시적인 PCM 디바이스로 하여금 저저항 결정질 상태에 있도록 야기하는 한편, 적어도 2개의 전극에 인가된 비교적 짧은 고전류 펄스(RESET)는 예시적인 PCM 디바이스가 고저항 비정질 상태에 있도록 야기한다.
일부 예들에서, PCM 디바이스들의 구현은 인메모리(in-memory) 컴퓨팅 능력들을 가능하게 하는 비-폰 노이만 컴퓨팅 아키텍처들을 용이하게 한다. 일반적으로 말하면, 전통적인 컴퓨팅 아키텍처들은 버스를 통해 하나 이상의 메모리 디바이스에 통신가능하게 접속된 CPU(central processing unit)를 포함한다. 이와 같이, CPU와 메모리 사이에서 데이터를 전송하기 위해 유한한 양의 에너지 및 시간이 소비되는데, 이는 폰 노이만 컴퓨팅 아키텍처의 알려진 병목 현상이다. 그러나, PCM 디바이스들은 인메모리로 일부 컴퓨팅 동작들을 수행함으로써 CPU와 메모리 사이의 데이터 전송들을 최소화하고, 일부 경우들에서는 제거한다. 달리 말하면, PCM 디바이스들은 정보를 저장하고 계산 태스크들을 실행한다. 이러한 비-폰 노이만 컴퓨팅 아키텍처들은 10,000 비트를 갖는 벡터들과 같이, 초차원 컴퓨팅을 용이하게 하기 위해 비교적 높은 차원수를 갖는 벡터들을 구현할 수 있다. 비교적 큰 비트 폭 벡터들은 넓은 비트 벡터들과 유사한 정보를 또한 처리하는, 인간의 두뇌를 모방해 모델링된 컴퓨팅 패러다임들을 가능하게 한다.
컴퓨팅 회로(602)는 컴퓨팅 회로(602)(예를 들어, 프로세서(604) 및/또는 메인 메모리(606)를 가짐) 및 컴퓨팅 회로(602)의 다른 컴포넌트들과의 입력/출력 동작들을 용이하게 하는 회로 및/또는 컴포넌트들로서 구체화될 수 있는 I/O 서브시스템(608)을 통해 컴퓨팅 노드(600)의 다른 컴포넌트들에 통신가능하게 결합된다. 예를 들어, I/O 서브시스템(608)은 메모리 컨트롤러 허브들, 입력/출력 제어 허브들, 통합된 센서 허브들, 펌웨어 디바이스들, 통신 링크들(예를 들어, 포인트-투-포인트 링크들, 버스 링크들, 와이어들, 케이블들, 도광체들(light guides), 인쇄 회로 보드 트레이스들 등), 및/또는 입력/출력 동작들을 용이하게 하기 위한 다른 컴포넌트들 및 서브시스템들로서 구체화되거나 그렇지 않으면 이들을 포함할 수 있다. 일부 예들에서, I/O 서브시스템(608)은 SoC(system-on-a-chip)의 일부분을 형성할 수 있고, 컴퓨팅 회로(602)의 프로세서(604), 메모리(606), 및 다른 컴포넌트들 중 하나 이상과 함께 컴퓨팅 회로(602)에 통합될 수 있다.
하나 이상의 예시적인 데이터 스토리지 디바이스들/디스크들(610)은, 예를 들어, 메모리 디바이스들, 메모리, 회로, 메모리 카드들, 플래시 메모리, 하드 디스크 드라이브들, SSD(solid-state drive)들, 및/또는 다른 데이터 스토리지 디바이스들/디스크들과 같은, 데이터의 단기 또는 장기 저장을 위해 구성된 임의 타입(들)의 물리적 디바이스(들) 중 하나 이상으로서 구체화될 수 있다. 개별 데이터 스토리지 디바이스들/디스크들(610)은 데이터 스토리지 디바이스/디스크(610)에 대한 데이터 및 펌웨어 코드를 저장하는 시스템 파티션을 포함할 수 있다. 개별 데이터 스토리지 디바이스들/디스크들(610)은 또한, 예를 들어, 컴퓨팅 노드(600)의 타입에 좌우되어 운영 체제들에 대한 데이터 파일들 및 실행파일들을 저장하는 하나 이상의 운영 체제 파티션을 포함할 수 있다.
통신 회로(612)는 컴퓨팅 회로(602)와 또 다른 컴퓨팅 디바이스(예를 들어, 구현 에지 컴퓨팅 시스템의 에지 게이트웨이) 사이에서 네트워크를 통한 통신을 가능하게 할 수 있는 임의의 통신 회로, 디바이스, 또는 이들의 컬렉션으로서 구체화될 수 있다. 통신 회로(612)는 이러한 통신을 달성하기 위해 임의의 하나 이상의 통신 기술(예를 들어, 유선 또는 무선 통신) 및 연관된 프로토콜들(예를 들어, 3GPP 4G 또는 5G 표준과 같은 셀룰러 네트워킹 프로토콜, IEEE 802.11/Wi-Fi®와 같은 무선 로컬 영역 네트워크 프로토콜, 무선 광역 네트워크 프로토콜, 이더넷, Bluetooth®, Bluetooth Low Energy, IEEE 802.15.4 또는 ZigBee®와 같은 IoT 프로토콜, LPWAN(low-power wide-area network) 또는 LPWA(low-power wide-area) 프로토콜 등)을 사용하도록 구성될 수 있다.
예시적인 통신 회로(612)는 HFI(host fabric interface)로도 지칭될 수 있는 NIC(network interface controller)(620)를 포함한다. NIC(620)는 또 다른 컴퓨팅 디바이스(예를 들어, 에지 게이트웨이 노드)와 접속하기 위해 컴퓨팅 노드(600)에 의해 사용될 수 있는 하나 이상의 애드-인-보드(add-in-board), 도터 카드(daughter card), 네트워크 인터페이스 카드, 컨트롤러 칩, 칩셋, 또는 다른 디바이스들로서 구체화될 수 있다. 일부 예들에서, NIC(620)는 하나 이상의 프로세서를 포함하는 SoC(system-on-a-chip)의 일부로서 구체화되거나, 또는 하나 이상의 프로세서를 또한 포함하는 멀티칩 패키지 상에 포함될 수 있다. 일부 예들에서, NIC(620)는 둘 다 NIC(620)에 로컬인 로컬 프로세서(도시되지 않음) 및/또는 로컬 메모리(도시되지 않음)를 포함할 수 있다. 그러한 예들에서, NIC(620)의 로컬 프로세서는 본 명세서에 설명된 컴퓨팅 회로(602)의 함수들 중 하나 이상을 수행할 수 있다. 그에 부가하여 또는 대안적으로, 이러한 예들에서, NIC(620)의 로컬 메모리는 보드 레벨, 소켓 레벨, 칩 레벨, 및/또는 다른 레벨들에서 클라이언트 컴퓨팅 노드의 하나 이상의 컴포넌트에 통합될 수 있다.
추가적으로, 일부 예들에서, 각자의 컴퓨팅 노드(600)는 하나 이상의 주변 디바이스(614)를 포함할 수 있다. 그러한 주변 디바이스들(614)은 컴퓨팅 노드(600)의 특정 타입에 좌우되어, 오디오 입력 디바이스, 디스플레이, 다른 입력/출력 디바이스, 인터페이스 디바이스, 및/또는 다른 주변 디바이스와 같은 컴퓨팅 디바이스 또는 서버에서 발견되는 임의 타입의 주변 디바이스를 포함할 수 있다. 추가 예들에서, 컴퓨팅 노드(600)는 에지 컴퓨팅 시스템 또는 유사한 형식들의 기기들, 컴퓨터들, 서브시스템들, 회로, 또는 다른 컴포넌트들에서 각자의 에지 컴퓨팅 노드(클라이언트, 게이트웨이, 또는 애그리게이션 노드이든 간에)에 의해 구체화될 수 있다.
보다 상세한 예에서, 도 6b는 본 명세서에 설명된 기법들(예를 들어, 동작들, 프로세스들, 방법들, 및 방법론들)을 구현하기 위해 에지 컴퓨팅 노드(650)에 존재할 수 있는 컴포넌트들의 예의 블록도를 도시한다. 이 에지 컴퓨팅 노드(650)는 컴퓨팅 디바이스로서 또는 그의 일부로서(예컨대, 모바일 디바이스, 기지국, 서버, 게이트웨이 등으로서) 구현될 때 노드(600)의 각자의 컴포넌트들의 보다 가까운 뷰를 제공한다. 에지 컴퓨팅 노드(650)는 본 명세서에서 참조된 하드웨어 또는 논리 컴포넌트들의 임의의 조합을 포함할 수 있고, 에지 통신 네트워크 또는 그러한 네트워크들의 조합과 함께 사용 가능한 임의의 디바이스를 포함하거나 그와 결합될 수 있다. 컴포넌트들은 집적 회로(IC)들, 그의 부분들, 이산 전자 디바이스들, 또는 다른 모듈들, 명령어 세트들, 프로그래머블 로직 또는 알고리즘들, 하드웨어, 하드웨어 가속기들, 소프트웨어, 펌웨어, 또는 에지 컴퓨팅 노드(650) 내에서 적응된 이들의 조합으로서, 또는 보다 큰 시스템의 섀시 내에 다른 방식으로 포함된 컴포넌트들로서 구현될 수 있다.
에지 컴퓨팅 디바이스(650)는 마이크로프로세서, 멀티코어 프로세서, 멀티스레드 프로세서, 초저 전압 프로세서, 임베디드 프로세서, x-PU/DPU/IPU/NPU, 특수 목적 처리 유닛, 특수화된 처리 유닛, 또는 다른 공지된 처리 요소들일 수 있는, 프로세서(652) 형식의 처리 회로를 포함할 수 있다. 프로세서(652)는 프로세서(652) 및 다른 컴포넌트들이 단일 집적 회로, 또는 단일 패키지, 예컨대 캘리포니아주 산타 클라라 소재의 인텔 코포레이션으로부터의 EdisonTM 또는 GalileoTM SoC 보드들이 되도록 형성되는 SoC(system on a chip)의 일부일 수 있다. 예로서, 프로세서(652)는 QuarkTM, AtomTM, i3, i5, i7, i9, 또는 MCU 클래스 프로세서와 같은 Intel® Architecture CoreTM 기반 CPU 프로세서, 또는 Intel®로부터 이용가능한 또 다른 이러한 프로세서를 포함할 수 있다. 그러나, 예를 들어, 캘리포니아주 서니베일의 Advanced Micro Devices, Inc.(AMD®)로부터 입수가능한 것, 캘리포니아주 서니베일의 MIPS Technologies, Inc.로부터의 MIPS® 기반 설계, ARM Holdings, Ltd. 또는 그의 고객, 또는 그들의 실시권자들 또는 채택자들로부터 라이센싱된 ARM® 기반 설계와 같은 임의 수의 다른 프로세서들이 사용될 수 있다. 프로세서들은 Apple® Inc.의 A5-A13 프로세서, Qualcomm® Technologies, Inc.의 SnapdragonTM 프로세서, 또는 Texas Instruments, Inc.의 OMAPTM 프로세서와 같은 유닛들을 포함할 수 있다. 프로세서(652) 및 부속 회로는 도 6b에 도시된 모든 요소들보다 적은 요소들을 포함하는 제한된 하드웨어 구성들 또는 구성들을 포함하여, 단일 소켓 폼 팩터, 다중 소켓 폼 팩터, 또는 다양한 다른 포맷들로 제공될 수 있다.
프로세서(652)는 인터커넥트(656)(예를 들어, 버스)를 통해 시스템 메모리(654)와 통신할 수 있다. 주어진 양의 시스템 메모리를 제공하기 위해 임의 수의 메모리 디바이스들이 사용될 수 있다. 예들로서, 메모리(654)는 DDR 또는 모바일 DDR 표준들(예를 들어, LPDDR, LPDDR2, LPDDR3, 또는 LPDDR4)과 같은 JEDEC(Joint Electron Devices Engineering Council) 설계에 따른 RAM(random access memory)일 수 있다. 특정 예들에서, 메모리 컴포넌트는, DDR SDRAM에 대한 JESD79F, DDR2 SDRAM에 대한 JESD79-2F, DDR3 SDRAM에 대한 JESD79-3F, DDR4 SDRAM에 대한 JESD79-4A, LPDDR(Low Power DDR)에 대한 JESD209, LPDDR2에 대한 JESD209-2, LPDDR3에 대한 JESD209-3, 및 LPDDR4에 대한 JESD209-4와 같은, JEDEC에 의해 공표된 DRAM 표준을 준수할 수 있다. 이러한 표준들(및 유사한 표준들)은 DDR 기반 표준들이라고 지칭될 수 있고, 이러한 표준들을 구현하는 스토리지 디바이스들의 통신 인터페이스들은 DDR 기반 인터페이스들이라고 지칭될 수 있다. 다양한 구현들에서, 개별 메모리 디바이스들은 SDP(single die package), DDP(dual die package) 또는 쿼드 다이 패키지(QDP)와 같은 임의 수의 상이한 패키지 타입들의 것일 수 있다. 이 디바이스들은, 일부 예들에서, 보다 낮은 프로필의 솔루션을 제공하기 위해 마더보드 상에 직접 납땜될 수 있는 한편, 다른 예들에서, 디바이스들은 주어진 커넥터에 의해 마더보드에 다음 차례로 결합되는 하나 이상의 메모리 모듈로서 구성된다. 다른 타입들의 메모리 모듈들, 예컨대, microDIMM들 또는 MiniDIMM들을 포함하지만 이들로 제한되지는 않는 상이한 각종의 DIMM(dual inline memory module)들과 같은 임의 수의 다른 메모리 구현들이 사용될 수 있다.
데이터, 애플리케이션들, 운영 체제들 및 등등과 같은 정보의 영구 스토리지를 제공하기 위해, 스토리지(658)는 또한 인터커넥트(656)를 통해 프로세서(652)에 결합될 수 있다. 예에서, 스토리지(658)는 SSDD(solid-state disk drive)를 통해 구현될 수 있다. 스토리지(658)에 대해 사용될 수 있는 다른 디바이스들은 SD(Secure Digital) 카드들, microSD 카드들, XD(eXtreme Digital) 픽처 카드들, 및 그와 유사한 것과 같은 플래시 메모리 카드들, 및 USB(Universal Serial Bus) 플래시 드라이브들을 포함한다. 예에서, 메모리 디바이스는 칼코게나이드 유리를 사용하는 메모리 디바이스들, 멀티 임계 레벨 NAND 플래시 메모리, NOR 플래시 메모리, 단일 또는 멀티 레벨 PCM(Phase Change Memory), 저항성 메모리, 나노와이어 메모리, FeTRAM(ferroelectric transistor random access memory), 반-강유전성 메모리, 멤리스터 기술을 포함하는 MRAM(magnetoresistive random access memory) 메모리, 금속 산화물 베이스, 산소 베이컨시 베이스 및 CB-RAM(conductive bridge Random Access Memory)를 포함하는 저항성 메모리, 또는 STT(spin transfer torque)-MRAM, 스핀트로닉 자기 접합 메모리 기반 디바이스, MTJ(magnetic tunneling junction) 기반 디바이스, DW(Domain Wall) 및 SOT(Spin Orbit Transfer) 기반 디바이스, 사이리스터 기반 메모리 디바이스, 또는 상기 중 임의의 것의 조합, 또는 다른 메모리일 수 있거나 이들을 포함할 수 있다.
저전력 구현들에서, 스토리지(658)는 프로세서(652)와 연관된 온다이(on-die) 메모리 또는 레지스터들일 수 있다. 그러나, 일부 예에서, 스토리지(658)는 마이크로 HDD(hard disk drive)를 이용하여 구현될 수 있다. 게다가, 기술된 기술들에 부가하여 또는 그 대신에, 그 중에서도 특히, 저항 변화 메모리들, 상 변화 메모리들, 홀로그래픽 메모리들, 또는 화학 메모리들과 같은, 임의 수의 새로운 기술들이 스토리지(658)에 대해 사용될 수 있다.
컴포넌트들은 인터커넥트(656)를 통해 통신할 수 있다. 인터커넥트(656)는 ISA(industry standard architecture), EISA(extended ISA), PCI(peripheral component interconnect), PCIx(peripheral component interconnect extended), PCIe(PCI express), 또는 임의 수의 다른 기술들을 포함하여, 임의 수의 기술들을 포함할 수 있다. 인터커넥트(656)는, 예를 들어, SoC 기반 시스템에서 사용되는 독점적 버스일 수 있다. 그 중에서도 특히, I2C(Inter-Integrated Circuit) 인터페이스, SPI(Serial Peripheral Interface) 인터페이스, 포인트 투 포인트 인터페이스들, 및 전력 버스와 같은 다른 버스 시스템들이 포함될 수 있다.
인터커넥트(656)는 접속된 에지 디바이스들(662)과의 통신을 위해, 프로세서(652)를 송수신기(666)에 결합할 수 있다. 송수신기(666)는, 그 중에서도 특히, Bluetooth® Special Interest Group에 의해 정의된 바와 같은 BLE(Bluetooth® low energy) 표준, 또는 ZigBee® 표준을 사용하는, IEEE 802.15.4 표준 하에서의 2.4 GHz(Gigahertz) 송신들과 같은 임의 수의 주파수들 및 프로토콜들을 사용할 수 있다. 특정 무선 통신 프로토콜을 위해 구성된 임의 수의 라디오들이 접속된 에지 디바이스들(662)에 대한 접속들을 위해 사용될 수 있다. 예를 들어, WLAN(wireless local area network) 유닛은 IEEE(Institute of Electrical and Electronics Engineers) 802.11 표준에 따라 Wi-Fi® 통신을 구현하기 위해 사용될 수 있다. 또한, 예를 들어, 셀룰러 또는 다른 무선 광역 프로토콜에 따른 무선 광역 통신은 WWAN(wireless wide area network) 유닛을 통해 발생할 수 있다.
무선 네트워크 송수신기(666)(또는 다중의 송수신기)는 상이한 범위에서의 통신을 위해 다중의 표준 또는 라디오를 이용하여 통신할 수 있다. 예를 들어, 에지 컴퓨팅 노드(650)는 전력을 절감하기 위해, BLE(Bluetooth Low Energy)에 기초한 로컬 송수신기, 또는 또 다른 저전력 라디오를 사용하여, 예컨대, 약 10 미터 내의 가까운 디바이스들과 통신할 수 있다. 예를 들어, 약 50 미터 내의 더 멀리 떨어진 접속된 에지 디바이스들(662)은 ZigBee® 또는 다른 중간 전력 라디오들을 통해 도달될 수 있다. 양 통신 기법들은 상이한 전력 레벨들에서 단일 라디오를 통해 발생할 수 있거나, 또는 개별 송수신기들, 예를 들어, BLE를 사용하는 로컬 송수신기 및 ZigBee®를 사용하는 별개의 메시 송수신기를 통해 발생할 수 있다.
로컬 또는 광역 네트워크 프로토콜을 통해 클라우드(예를 들어, Edge 클라우드(695)) 내의 디바이스들 또는 서비스들과 통신하기 위해 무선 네트워크 송수신기(666)(예를 들어, 라디오 송수신기)가 포함될 수 있다. 무선 네트워크 송수신기(666)는, 그 중에서도 특히, IEEE 802.15.4, 또는 IEEE 802.15.4g 표준들을 따르는 LPWA(low-power wide-area) 송수신기일 수 있다. 에지 컴퓨팅 노드(650)는 Semtech 및 LoRa Alliance에 의해 개발된 LoRaWANTM(Long Range Wide Area Network)을 사용하여 광역에 걸쳐 통신할 수 있다. 본 명세서에 설명된 기법들은 이러한 기술들로 제한되지는 않고, Sigfox와 같은 장거리 저 대역폭 통신, 및 다른 기술들을 구현하는 임의 수의 다른 클라우드 송수신기들과 함께 사용될 수 있다. 또한, IEEE 802.15.4e 사양에 기술된 시간 슬롯 채널 호핑과 같은 다른 통신 기법들이 이용될 수 있다.
본 명세서에 설명된 바와 같이, 무선 네트워크 송수신기(666)에 대해 언급된 시스템들에 부가하여 임의 수의 다른 라디오 통신들 및 프로토콜들이 사용될 수 있다. 예를 들어, 송수신기(666)는 고속 통신을 구현하기 위해 확산 스펙트럼(SPA/SAS) 통신을 이용하는 셀룰러 송수신기를 포함할 수 있다. 또한, 중속 통신 및 네트워크 통신의 제공을 위한 Wi-Fi® 네트워크들과 같은 임의 수의 다른 프로토콜들이 사용될 수 있다. 송수신기(666)는 본 개시내용의 끝에서 더 상세히 논의되는, LTE(Long Term Evolution) 및 5세대(5G) 통신 시스템들과 같은 임의 수의 3GPP(Third Generation Partnership Project) 사양들과 호환가능한 라디오들을 포함할 수 있다. 에지 클라우드(695)의 노드들에 또는 (예를 들어, 메시에서 동작하는) 접속된 에지 디바이스들(662)과 같은 다른 디바이스들에 유선 통신을 제공하기 위해 NIC(network interface controller)(668)가 포함될 수 있다. 유선 통신은 이더넷 접속을 제공할 수 있거나, 또는 많은 것들 중에서도 특히, CAN(Controller Area Network), LIN(Local Interconnect Network), DeviceNet, ControlNet, Data Highway+, PROFIBUS, 또는 PROFINET와 같은 다른 타입의 네트워크들에 기초할 수 있다. 추가적인 NIC(668), 예를 들어, 이더넷을 통해 클라우드에 통신을 제공하는 제1 NIC(668), 및 또 다른 타입의 네트워크를 통해 다른 디바이스들에 통신을 제공하는 제2 NIC(668)가 제2 네트워크에 대한 접속을 가능하게 하기 위해 포함될 수 있다.
디바이스로부터 또 다른 컴포넌트 또는 네트워크로의 다양한 타입의 적용가능한 통신이 주어지면, 디바이스에 의해 사용되는 적용가능한 통신 회로는 컴포넌트들(664, 666, 668, 또는 670) 중 임의의 하나 이상을 포함하거나 이에 의해 구체화될 수 있다. 따라서, 다양한 예들에서, 통신(예를 들어, 수신, 송신 등)을 위한 적용가능한 수단은 그러한 통신 회로에 의해 구체화될 수 있다.
에지 컴퓨팅 노드(650)는, 하나 이상의 AI(artificial intelligence) 가속기, 신경 컴퓨팅 스틱, 뉴로모픽 하드웨어, FPGA, GPU들의 배열, x-PU들/DPU들/IPU/NPU들의 배열, 하나 이상의 SoC, 하나 이상의 CPU, 하나 이상의 디지털 신호 프로세서, 전용 ASIC들, 또는 하나 이상의 특수화된 태스크를 달성하도록 설계된 다른 형식들의 특수화된 프로세서 또는 회로에 의해 구체화될 수 있는 가속 회로(664)를 포함하거나 이에 결합될 수 있다. 이들 태스크는 AI 처리(머신 러닝, 훈련, 추론, 및 분류 동작들을 포함함), 시각 데이터 처리, 네트워크 데이터 처리, 객체 검출, 규칙 분석, 또는 그와 유사한 것을 포함할 수 있다. 이들 태스크는 또한 본 문서의 다른 곳에서 논의된 서비스 관리 및 서비스 동작들을 위한 특정 에지 컴퓨팅 태스크들을 포함할 수 있다.
인터커넥트(656)는 추가적인 디바이스들 또는 서브시스템들을 접속하기 위해 사용되는 센서 허브 또는 외부 인터페이스(670)에 프로세서(652)를 결합할 수 있다. 디바이스들은 가속도계들, 레벨 센서들, 흐름 센서들, 광학 광 센서들, 카메라 센서들, 온도 센서들, 글로벌 내비게이션 시스템(예를 들어, GPS) 센서들, 압력 센서들, 기압 센서들, 및 그와 유사한 것과 같은 센서들(672)을 포함할 수 있다. 허브 또는 인터페이스(670)는 추가로 에지 컴퓨팅 노드(650)를, 전력 스위치들, 밸브 액추에이터들, 가청 사운드 발생기, 시각적 경고 디바이스, 및 이와 유사한 것과 같은 액추에이터들(674)에 접속시키기 위해 사용될 수 있다.
일부 선택적 예들에서, 다양한 입력/출력(I/O) 디바이스들이 에지 컴퓨팅 노드(650) 내에 존재하거나 그에 접속될 수 있다. 예를 들어, 센서 판독값들 또는 액추에이터 위치와 같은 정보를 보여주기 위해 디스플레이 또는 다른 출력 디바이스(684)가 포함될 수 있다. 입력을 수용하기 위해 터치 스크린 또는 키패드와 같은 입력 디바이스(686)가 포함될 수 있다. 출력 디바이스(684)는, 바이너리 상태 표시기들(예를 들어, 발광 다이오드(LED)들) 및 다중 문자 시각적 출력들과 같은 단순한 시각적 출력들, 또는 디스플레이 스크린들(예를 들어, 액정 디스플레이(LCD) 스크린들)과 같은 더 복잡한 출력들을 포함하는 임의 수의 형식의 오디오 또는 시각적 디스플레이를 포함할 수 있고, 문자들, 그래픽들, 멀티미디어 객체들, 및 그와 유사한 것의 출력이 에지 컴퓨팅 노드(650)의 동작으로부터 발생되거나 생성된다. 디스플레이 또는 콘솔 하드웨어는, 본 시스템의 맥락에서, 에지 컴퓨팅 시스템의 출력을 제공하고 입력을 수신하기 위해; 에지 컴퓨팅 시스템의 컴포넌트들 또는 서비스들을 관리하기 위해; 에지 컴퓨팅 컴포넌트 또는 서비스의 상태를 식별하기 위해; 또는 임의의 다른 수의 관리 또는 운영 함수들 또는 서비스 사용 사례들을 수행하기 위해 사용될 수 있다.
배터리(676)가 에지 컴퓨팅 노드(650)에 전력을 공급할 수 있지만, 에지 컴퓨팅 노드(650)가 고정된 로케이션에 장착되는 예들에서, 그것은 전기 그리드에 결합된 전원을 가질 수 있거나, 또는 배터리는 백업으로서 또는 일시적 능력들을 위해 사용될 수 있다. 배터리(676)는 리튬 이온 배터리, 또는, 아연-공기 배터리, 알루미늄-공기 배터리, 리튬-공기 배터리, 및 그와 유사한 것과 같은 금속-공기 배터리일 수 있다.
배터리 모니터/충전기(678)는, 포함된 경우, 배터리(676)의 충전 상태(SoCh)를 추적하기 위해 에지 컴퓨팅 노드(650)에 포함될 수 있다. 배터리 모니터/충전기(678)는, 배터리(676)의 SoH(state of health) 및 SoF(state of function)와 같은, 장애 예측들을 제공하기 위해 배터리(676)의 다른 파라미터들을 모니터링하기 위해 사용될 수 있다. 배터리 모니터/충전기(678)는, Linear Technologies로부터의 LTC4020 또는 LTC2990, 아리조나주 푀닉스의 ON Semiconductor로부터의 ADT7488A, 또는 텍사스주 달라스의 Texas Instruments의 UCD90xxx 계열로부터의 IC와 같은 배터리 모니터링 집적 회로를 포함할 수 있다. 배터리 모니터/충전기(678)는 배터리(676)에 대한 정보를 인터커넥트(656)를 통해 프로세서(652)에 통신할 수 있다. 배터리 모니터/충전기(678)는 프로세서(652)가 배터리(676)의 전압 또는 배터리(676)로부터의 전류 흐름을 직접 모니터링할 수 있게 하는 아날로그-투-디지털(ADC) 컨버터를 또한 포함할 수 있다. 배터리 파라미터들은 송신 주파수, 메시 네트워크 동작, 주파수 감지, 및 그와 유사한 것과 같은, 에지 컴퓨팅 노드(650)가 수행할 수 있는 액션들을 결정하기 위해 사용될 수 있다.
전력 블록(680), 또는 그리드에 결합된 다른 전원이 배터리(676)를 충전하기 위해 배터리 모니터/충전기(678)와 결합될 수 있다. 일부 예들에서, 전력 블록(680)은, 예를 들어, 에지 컴퓨팅 노드(650) 내의 루프 안테나를 통해 무선으로 전력을 획득하기 위해 무선 전력 수신기로 대체될 수 있다. 그 중에서도 특히, 캘리포니아주 밀피타스 소재의 Linear Technologies의 LTC4020 칩과 같은 무선 배터리 충전 회로가 배터리 모니터/충전기(678)에 포함될 수 있다. 특정 충전 회로들은 배터리(676)의 크기, 및 따라서 요구되는 전류에 기초하여 선택될 수 있다. 충전은, 그 중에서도 특히, Airfuel Alliance에 의해 공표된 Airfuel 표준, Wireless Power Consortium에 의해 공표된 Qi 무선 충전 표준, 또는 Alliance for Wireless Power에 의해 공표된 Rezence 충전 표준을 사용하여 수행될 수 있다.
스토리지(658)는 본 명세서에 설명된 기법들을 구현하기 위해 소프트웨어, 펌웨어, 또는 하드웨어 커맨드들의 형식의 명령어들(682)을 포함할 수 있다. 이러한 명령어들(682)이 메모리(654) 및 스토리지(658)에 포함된 코드 블록들로서 도시되어 있지만, 코드 블록들 중 임의의 것이, 예를 들어, ASIC(application specific integrated circuit) 내에 구축된 하드와이어드 회로들로 대체될 수 있다는 것이 이해될 수 있다.
예에서, 메모리(654), 스토리지(658), 또는 프로세서(652)를 통해 제공되는 명령어들(682)은 에지 컴퓨팅 노드(650)에서 전자적 동작들을 수행하라고 프로세서(652)에 지시하는 코드를 포함하는 비일시적 머신 판독가능 매체(660)로서 구체화될 수 있다. 프로세서(652)는 인터커넥트(656)를 통해 비일시적 머신 판독가능 매체(660)에 액세스할 수 있다. 예를 들어, 비일시적 머신 판독가능 매체(660)는 스토리지(658)에 대해 설명된 디바이스들에 의해 구체화될 수 있거나, 광학 디스크들(예를 들어, DVD(digital versatile disk), CD(compact disk), CD-ROM, 블루레이 디스크), 플래시 드라이브들, 플로피 디스크들, 하드 드라이브들(예를 들어, SSD들), 또는 정보가 임의의 지속기간 동안 (예를 들어, 연장된 시간 기간들 동안, 영구적으로, 짧은 인스턴스들 동안, 일시적으로 버퍼링하는 동안, 및/또는 캐싱하는 동안) 저장되는 임의 수의 다른 하드웨어 디바이스들을 포함하는 스토리지 디바이스들 및/또는 스토리지 디스크들과 같은 특정 스토리지 유닛들을 포함할 수 있다. 비일시적 머신 판독가능 매체(660)는, 예를 들어, 위에 묘사된 동작들 및 기능성의 흐름도(들) 및 블록도(들)에 관하여 설명된 바와 같이, 액션들의 특정 시퀀스 또는 흐름을 수행하도록 프로세서(652)에 지시하는 명령어들을 포함할 수 있다. 본 명세서에 사용되는 바와 같이, 용어들 "머신 판독가능 매체(machine-readable medium)" 및 "컴퓨터 판독가능 매체(computer-readable medium)"는 교환가능하다. 본 명세서에서 사용될 때, "비일시적 컴퓨터 판독가능 매체"라는 용어는 임의 타입의 컴퓨터 판독가능 스토리지 디바이스 및/또는 스토리지 디스크를 포함하고, 전파 신호들을 배제하고, 송신 매체를 배제하는 것으로 명확히 정의된다.
또한 특정 예에서, 프로세서(652) 상의 명령어들(682)은 (머신 판독가능 매체(660)의 명령어들(682)과 별개로, 또는 그와 조합되어) TEE(trusted execution environment)(690)의 실행 또는 동작을 구성할 수 있다. 예에서, TEE(690)는 명령어들의 보안 실행 및 데이터에 대한 보안 액세스를 위해 프로세서(652)가 액세스가능한 보호된 영역으로서 동작한다. TEE(690), 및 프로세서(652) 또는 메모리(654)에서의 수반되는 보안 영역의 다양한 구현들은, 예를 들어, Intel® SGX(Software Guard Extensions) 또는 ARM® TrustZone® 하드웨어 보안 확장들, Intel® ME(Management Engine), 또는 Intel® CSME(Converged Security Manageability Engine)의 사용을 통해 제공될 수 있다. 보안 강화(security hardening), 하드웨어 신뢰 루트들(roots-of-trust), 및 신뢰된 또는 보호된 동작들의 다른 양태들이 TEE(690) 및 프로세서(652)를 통해 디바이스(650)에서 구현될 수 있다.
도 6a 및 도 6b의 예시된 예들이 제각기 컴퓨팅 노드 및 컴퓨팅 디바이스에 대한 예시적인 컴포넌트들을 포함하지만, 본 명세서에 개시된 예들은 이것들에만 제한되지는 않는다. 본 명세서에서 사용될 때, "컴퓨터"는 상이한 타입의 컴퓨팅 환경들에서 도 6a 및/또는 도 6b의 예시적인 컴포넌트들의 일부 또는 전부를 포함할 수 있다. 예시적인 컴퓨팅 환경들은, 참여하는 에지 컴퓨팅 디바이스들 중 특정의 것들이 이종(heterogenous) 또는 동종(homogeneous) 디바이스들이도록, 분산 네트워킹 배열로 된 에지 컴퓨팅 디바이스들(예컨대, 에지 컴퓨터들)을 포함한다. 본 명세서에서 사용될 때, "컴퓨터"는 개인용 컴퓨터, 서버, 사용자 장비, 가속기 등을 포함할 수 있으며, 이들의 임의의 조합들을 포함할 수 있다. 일부 예들에서, 분산 네트워킹 및/또는 분산 컴퓨팅은 도 6a 및/또는 도 6b에 예시된 바와 같은 임의의 수의 그러한 에지 컴퓨팅 디바이스들을 포함하며, 이들 각각은 상이한 서브컴포넌트들, 상이한 메모리 용량들, I/O 능력들 등을 포함할 수 있다. 예를 들어, 분산 네트워킹 및/또는 분산 컴퓨팅의 일부 구현들이 특정의 원하는 기능성과 연관되기 때문에, 본 명세서에 개시된 예들은 분산 컴퓨팅 태스크들의 기능적 목표를 만족시키기 위해 도 6a 및/또는 도 6b에 나타낸 컴포넌트들의 상이한 조합들을 포함한다. 일부 예들에서, "컴퓨팅 노드" 또는 "컴퓨터"라는 용어는 도 6a의 예시적인 프로세서(604), 메모리(606) 및 I/O 서브시스템(608)만을 포함한다. 일부 예들에서, 분산 컴퓨팅 태스크(들)의 하나 이상의 목표 함수는, 데이터 스토리지(예컨대, 예시적인 데이터 스토리지(610)), 입력/출력 능력들(예컨대, 예시적인 주변 디바이스(들)(614)), 및/또는 네트워크 통신 능력들(예컨대, 예시적인 NIC(620))를 수용하기 위한 디바이스들과 같은, 에지 네트워킹 환경의 상이한 부분들에 위치된 하나 이상의 대안 디바이스/구조물에 의존한다.
일부 예들에서, 분산 컴퓨팅 및/또는 분산 네트워킹 환경(예컨대, 에지 네트워크)에서 동작하는 컴퓨터들은 계산 낭비를 감소시키는 방식으로 특정의 목표 기능성을 수용하도록 구조화되어 있다. 예를 들어, 컴퓨터가 도 6a 및 도 6b에 개시된 컴포넌트들의 서브세트를 포함하기 때문에, 이러한 컴퓨터들은, 그렇지 않았더라면 사용되지 않고 및/또는 충분히 이용되지 않을 컴퓨팅 구조를 포함하지 않고서, 분산 컴퓨팅 목표 함수들의 실행을 충족시킨다. 이와 같이, 본 명세서에서 사용되는 "컴퓨터"라는 용어는 분산 컴퓨팅 태스크들의 목표 함수들을 충족시키고 및/또는 그렇지 않으면 실행할 수 있는 도 6a 및/또는 도 6b의 구조의 임의의 조합을 포함한다. 일부 예들에서, 컴퓨터들은 동적 수요와 관련하여 다운스케일링 또는 업스케일링하는 방식으로 대응하는 분산 컴퓨팅 목표 함수들에 부합하는 방식으로 구조화된다. 일부 예들에서, 분산 컴퓨팅 요청(들)의 하나 이상의 태스크를 처리하는 그들의 능력을 고려하여 상이한 컴퓨터들이 기동되고 및/또는 그렇지 않은 경우에는 인스턴스화되어, 태스크들을 만족시킬 수 있는 임의의 컴퓨터가 그러한 컴퓨팅 활동으로 진행하도록 한다.
도 6a 및 도 6b의 예시된 예들에서, 컴퓨팅 디바이스들은 운영 체제들을 포함한다. 본 명세서에서 사용되는 바와 같이, "운영 체제"는 도 6a의 예시적인 에지 컴퓨팅 노드(600) 및/또는 도 6b의 예시적인 에지 컴퓨팅 노드(650)와 같은 예시적인 컴퓨팅 디바이스들을 제어하기 위한 소프트웨어이다. 예시적인 운영 체제들은 소비자 기반 운영 체제들(예를 들어, Microsoft® Windows® 10, Google® Android® OS, Apple® Mac® OS 등)을 포함하지만, 이에 제한되지는 않는다. 예시적인 운영 체제들은 또한 실시간 운영 체제들, 하이퍼바이저들 등과 같은 산업에 초점을 맞춘 운영 체제들을 포함하지만, 이에 제한되지는 않는다. 제1 에지 컴퓨팅 노드 상의 예시적인 운영 체제는 제2 에지 컴퓨팅 노드 상의 예시적인 운영 체제와 동일하거나 상이할 수 있다. 일부 예들에서, 운영 체제는 특정 통신 프로토콜들 및/또는 인터프리터들과 같은, 운영 체제에 고유하지 않은 하나 이상의 함수 및/또는 동작을 용이하게 하기 위한 대안 소프트웨어를 기동한다. 일부 예들에서, 운영 체제는 운영 체제에 고유하지 않은 다양한 기능성들을 인스턴스화한다. 일부 예에서, 운영 체제는 변하는 정도의 복잡성 및/또는 능력을 포함한다. 예를 들어, 제1 에지 컴퓨팅 노드에 대응하는 제1 운영 체제는 동적 입력 조건들에 대한 응답성의 특정 성능 예상들을 갖는 실시간 운영 체제를 포함하고, 제2 에지 컴퓨팅 노드에 대응하는 제2 운영 체제는 최종 사용자 I/O를 용이하게 하는 그래픽 사용자 인터페이스 능력들을 포함한다.
명령어들(682)은 또한 다수의 WLAN(wireless local area network) 전송 프로토콜(예를 들어, 프레임 릴레이, IP(internet protocol), TCP(transmission control protocol), UDP(user datagram protocol), HTTP(hypertext transfer protocol) 등) 중 어느 하나를 활용하여 무선 네트워크 송수신기(466)를 통해 송신 매체를 이용하여 통신 네트워크를 통해 송신 또는 수신될 수 있다. 예시적인 통신 네트워크들은 LAN(local area network), WAN(wide area network), 패킷 데이터 네트워크(예를 들어, 인터넷), 모바일 폰 네트워크들(예를 들어, 셀룰러 네트워크들), POTS(Plain Old Telephone) 네트워크들, 및 무선 데이터 네트워크들을 포함할 수 있다. 네트워크들을 통한 통신은, 그 중에서도 특히, Wi-Fi라고 알려진 IEEE(Institute of Electrical and Electronics Engineers) 802.11 표준들의 계열, IEEE 802.16 표준들의 계열, IEEE 802.15.4 표준들의 계열, LTE(Long Term Evolution) 표준들의 계열, UMTS(Universal Mobile Telecommunications System) 표준들의 계열, P2P(peer-to-peer) 네트워크들, NG(next generation)/5G(5th generation) 표준들과 같은, 하나 이상의 상이한 프로토콜을 포함할 수 있다.
본 명세서에서 사용되는 바와 같은 "회로(circuitry)"라는 용어는, 설명된 기능성을 제공하도록 구성되는, 전자 회로, 로직 회로, 프로세서(공유, 전용, 또는 그룹) 및/또는 메모리(공유, 전용, 또는 그룹), ASIC(Application Specific Integrated Circuit), FPD(field-programmable device)(예를 들어, FPGA(field-programmable gate array), PLD(programmable logic device), CPLD(complex PLD), HCPLD(high-capacity PLD), 구조화된 ASIC, 또는 프로그래머블 SoC), DSP들(digital signal processors) 등과 같은 하드웨어 컴포넌트들을 지칭하거나, 이들의 일부이거나, 또는 이들을 포함한다는 점에 유의한다. 일부 실시예들에서, 회로는 설명된 기능성의 적어도 일부를 제공하기 위해 하나 이상의 소프트웨어 또는 펌웨어 프로그램을 실행할 수 있다. "회로"라는 용어는 또한 하나 이상의 하드웨어 요소와 그 프로그램 코드의 기능성을 수행하기 위해 사용되는 프로그램 코드의 조합(또는 전기 또는 전자 시스템에서 사용되는 회로들의 조합)을 지칭할 수 있다. 이러한 실시예들에서, 하드웨어 요소들과 프로그램 코드의 조합은 특정 타입의 회로라고 지칭될 수 있다.
따라서, 본 명세서에서 사용되는 바와 같은 "프로세서 회로" 또는 "프로세서"라는 용어는 산술 또는 논리 연산들의 시퀀스를 순차적으로 그리고 자동으로 수행하거나, 또는 디지털 데이터를 기록, 저장 및/또는 전송할 수 있는 회로를 지칭하거나, 그의 일부이거나, 그를 포함할 수 있다. 용어 "프로세서 회로" 또는 "프로세서"는, 하나 이상의 애플리케이션 프로세서, 하나 이상의 기저대역 프로세서, 물리적 CPU(central processing unit), 단일 또는 멀티 코어 프로세서, 및/또는 프로그램 코드, 소프트웨어 모듈들, 및/또는 함수 프로세스들과 같은 컴퓨터 실행가능 명령어들을 실행하거나 다른 경우에는 동작시킬 수 있는 임의의 다른 디바이스를 지칭할 수 있다.
본 명세서에 설명되는 라디오 링크들 중 임의의 것은 이하의 것들을 포함하지만 이에 제한되지는 않는 이하의 라디오 통신 기술들 및/또는 표준들 중 임의의 하나 이상의 것에 따라 동작할 수 있다: GSM(Global System for Mobile Communications) 라디오 통신 기술, GPRS(General Packet Radio Service) 라디오 통신 기술, EDGE(Enhanced Data Rates for GSM Evolution) 라디오 통신 기술, 및/또는 3GPP(Third Generation Partnership Project) 라디오 통신 기술, 예를 들어, UMTS(Universal Mobile Telecommunications System), FOMA(Freedom of Multimedia Access), 3GPP LTE(Long Term Evolution), 3GPP LTE 어드밴스드(Advanced), CDMA2000(Code division multiple access 2000), CDPD(Cellular Digital Packet Data), 모비텍스(Mobitex), 3G(Third Generation), CSD(Circuit Switched Data), HSCSD(High-Speed Circuit-Switched Data), UMTS(3G)(Universal Mobile Telecommunications System), W-CDMA(UMTS)(Wideband Code Division Multiple Access(Universal Mobile Telecommunications System)), HSPA(High Speed Packet Access), HSDPA(High-Speed Downlink Packet Access), HSUPA(High-Speed Uplink Packet Access), HSPA+(High Speed Packet Access Plus), UMTS-TDD(Universal Mobile Telecommunications System-Time-Division Duplex), TD-CDMA(Time Division-Code Division Multiple Access), TD-CDMA(Time Division-Synchronous Code Division Multiple Access), 3세대 파트너십 프로젝트 릴리스 8(Pre-4th Generation)(3GPP Rel. 8(Pre-4G)), 3GPP Rel. 9(3rd Generation Partnership Project Release9), 3GPP Rel. 10(3rd Generation Partnership Project Release10), 3GPP Rel. 11(3rd Generation Partnership Project Release11), 3GPP Rel. 12(3rd Generation Partnership Project Release12), 3GPP Rel. 13(3rd Generation Partnership Project Release13), 3GPP Rel. 14(3rd Generation Partnership Project Release14), 3GPP Rel. 15(3rd Generation Partnership Project Release15), 3GPP Rel. 16(3rd Generation Partnership Project Release16), 3GPP Rel. 17(3rd Generation Partnership Project Release17) 및 후속 릴리스들(예컨대 Rel. 18, Rel. 19 등), 3GPP5G, 5G, 5G NR(5G New Radio), 3GPP 5G New Radio, 3GPP LTE Extra, LTE-Advanced Pro, LTE LAA(Licensed-Assisted Access), MuLTEfire, UTRA(UMTS Terrestrial Radio Access), E-UTRA(Evolved UMTS Terrestrial Radio Access), LTE 어드밴스드(4G)(Long Term Evolution Advanced(4th generation)), cdmaOne(2G), CDMA 2000(3G)(Code division multiple access 2000(Third generation)), EV-DO(Evolution-Data Optimized or Evolution-Data Only), AMPS(1G)(Advanced Mobile Phone System(1st generation)), TACS/ETACS(Total Access Communication System/Extended Total Access Communication System), D-AMPS (2G)(Digital AMPS (2nd Generation)), PTT(Push-to-talk), MTS(Mobile Telephone System), IMTS(Improved Mobile Telephone System), AMTS(Advanced Mobile Telephone System), OLT(Norwegian for Offentlig Landmobil Telefoni, Public Land Mobile Telephony), MTD(Swedish abbreviation for Mobiltelefonisystem D, or Mobile telephony system D), Autotel/PALM(Public Automated Land Mobile), ARP(Finnish for Autoradiopuhelin, “car radio phone”), NMT(Nordic Mobile Telephony), Hicap(High capacity version of NTT(Nippon Telegraph and Telephone)), CDPD(Cellular Digital Packet Data), 모비텍스(Mobitex), DataTAC, iDEN(Integrated Digital Enhanced Network), PDC(Personal Digital Cellular), CSD(Circuit Switched Data), PHS(Personal Handy-phone System), WiDEN(Wideband Integrated Digital Enhanced Network), iBurst, 3GPP 일반 액세스 네트워크 또는 GAN 표준으로 또한 지칭되는 UMA(Unlicensed Mobile Access), Zigbee, Bluetooth(r), WiGig(Wireless Gigabit Alliance) 표준, 일반적인 mmWave 표준들(WiGig, IEEE 802.11ad, IEEE 802.11ay 등과 같이 10-300 GHz 이상에서 동작하는 무선 시스템들), 300 GHz 이상 및 THz 대역에서 동작하는 기술들, (3GPP/LTE 기반 또는 IEEE 802.11p 또는 IEEE 802.11bd 및 기타) V2V(Vehicle-to-Vehicle) 및 V2X(Vehicle-to-X) 및 V2I(Vehicle-to-Infrastructure) 및 I2V(Infrastructure-to-Vehicle) 통신 기술들, 3GPP 셀룰러 V2X, DSRC(Dedicated Short Range Communications) 통신 시스템들, 예컨대 지능형 전송 시스템들(Intelligent-Transport-Systems) 및 기타(전형적으로 5850 MHz 내지 5925 MHz 이상에서 동작함(전형적으로 CEPT Report 71에서의 변경 제안들에 따르면 최대 5935 MHz까지)), 유럽 ITS-G5 시스템(즉, IEEE 802.11p 기반 DSRC의 유럽 변형, ITS-G5A(즉, 주파수 범위 5,875 GHz 내지 5,905 GHz에서 안전성 관련 응용들을 위해 ITS에 전용되는 유럽 ITS 주파수 대역들에서의 ITS-G5의 동작), ITS-G5B(즉, 주파수 범위 5,855 GHz 내지 5,875 GHz에서의 ITS 비-안정성 응용들에 전용되는 유럽 ITS 주파수 대역들에서의 동작), ITS-G5C(즉, 주파수 범위 5,470 GHz 내지 5,725 GHz에서의 ITS 응용들의 동작)를 포함함), 700 MHz(715 MHz 내지 725 MHz 포함함) 대역에서의 일본의 DSRC, IEEE 802.11bd 기반 시스템들, 등.
본 명세서에 기술되는 양태들은 전용 면허 스펙트럼, 비면허 스펙트럼, 면허 면제 스펙트럼, (면허) 공유 스펙트럼(예컨대, LSA = 2.3 내지 2.4GHz, 3.4 내지 3.6GHz, 3.6 내지 3.8GHz 및 추가의 주파수들에서의 면허 공유 액세스(Licensed Shared Access) 및 SAS = 3.55 내지 3.7GHz 및 추가의 주파수들에서의 스펙트럼 액세스 시스템/CBRS = 민간 광대역 라디오 시스템(Citizen Broadband Radio System))을 포함하는 임의의 스펙트럼 관리 스킴의 맥락에서 사용될 수 있다. 적용가능한 스펙트럼 대역들은 IMT(International Mobile Telecommunications) 스펙트럼뿐만 아니라 국가 할당에 의한 대역들과 같은 다른 타입들의 스펙트럼/대역들을 포함한다(국가 할당은 450-470MHz, 902-928MHz(주: 예를 들어, 미국에 할당됨(FCC 파트 15)), 863-868.6MHz(주: 예를 들어, 유럽 연합에 할당됨(ETSI EN300 220)), 915.9-929.7MHz(주: 예를 들어, 일본에 할당됨), 917-923.5MHz(주: 예를 들어, 한국에 할당됨), 755-779MHz 및 779-787MHz(주: 예를 들어, 중국에 할당됨), 790-960MHz, 1710-2025MHz, 2110-2200MHz, 2300-2400MHz, 2.4-2.4835GHz(주: 글로벌 가용성을 갖는 ISM 대역이고, 이것은 Wi-Fi 기술 계열(11b/g/n/ax)에 의해 그리고 또한 블루투스에 의해 사용됨), 2500-2690MHz, 698-790MHz, 610-790MHz, 3400-3600MHz, 3400-3800MHz, 3800-4200MHz, 3.55-3.7GHz(주: 예를 들어, 민간 광대역 라디오 서비스를 위해 미국에 할당됨), 5.15-5.25GHz 및 5.25-5.35GHz 및 5.47-5.725GHz 및 5.725-5.85GHz 대역들(주: 예를 들어, 미국에 할당됨(FCC 파트 15), 총 500MHz 스펙트럼에서 4개의 U-NII 대역들로 구성됨), 5.725-5.875GHz(주: 예를 들어, EU에 할당됨(ETSI EN301 893)), 5.47-5.65GHz(주: 예를 들어, 한국에 할당됨), 5925-7085MHz 및 5925-6425MHz 대역(주: 제각기 미국 및 EU에서 고려 중임). 차세대 Wi-Fi 시스템은 동작 대역으로서 6GHz 스펙트럼을 포함할 것으로 예상되지만, 2017년 12월부로, Wi-Fi 시스템은 이 대역에서 아직 허용되지 않는다는 점이 주목된다. 2019-2020 기간에서 규정이 완료될 것으로 예상됨), IMT-어드밴스드 스펙트럼, IMT-2020 스펙트럼(3600-3800MHz, 3800-4200MHz, 3.5GHz 대역들, 700MHz 대역들, 24.25-86GHz 범위 내의 대역들 등을 포함할 것으로 예상됨), FCC의 "스펙트럼 프론티어(Spectrum Frontier)" 5G 이니셔티브 하에서 이용가능하게 되는 스펙트럼(27.5-28.35GHz, 29.1-29.25GHz, 31-31.3GHz, 37-38.6GHz, 38.6-40GHz, 42-42.5GHz, 57-64GHz, 71-76GHz, 81-86GHz 및 92-94GHz 등을 포함함), 5.9GHz(전형적으로 5.85-5.925GHz) 및 63-64GHz의 ITS(Intelligent Transport Systems) 대역, WiGig Band 1(57.24-59.40GHz), WiGig Band 2(59.40-61.56GHz) 및 WiGig Band 3(61.56-63.72GHz) 및 WiGig Band 4(63.72-65.88GHz)와 같은 WiGig에 현재 할당된 대역들, 57-64/66GHz(주: 이 대역은 MGWS(Multi-Gigabit Wireless Systems)/WiGig에 대한 거의 글로벌 지정을 갖는다. 미국(FCC 파트 15)에서 총 14 GHz를 할당하는 한편, EU(고정된 P2P에 대한 ETSI EN 302 567 및 ETSI EN 301 217-2)는 총 9GHz 스펙트럼을 할당함), 70.2GHz-71GHz 대역, 65.88GHz와 71GHz 사이의 임의의 대역, 76-81GHz와 같은 자동차 레이더 응용들에 현재 할당된 대역들, 및 94-300GHz 및 그 이상을 포함하는 미래의 대역들). 더욱이, 이 스킴은 특히 400MHz 및 700MHz 대역들이 유망한 후보들인 TV 화이트 스페이스 대역들(전형적으로 790MHz 아래)과 같은 대역들에 대해 2차적으로 사용될 수 있다. 셀룰러 응용들 외에, PMSE(Program Making and Special Events), 의료, 건강, 수술, 자동차, 저 레이턴시, 드론 등의 응용들과 같은 수직 시장(vertical market)들에 대한 특정 응용들이 다루어질 수 있다.
도 7은 도 6b의 예시적인 컴퓨터 판독가능 명령어들(682)과 같은 소프트웨어를 예시적인 프로세서 플랫폼(들)(710) 및/또는 예시적인 접속된 에지 디바이스들과 같은 하나 이상의 디바이스에 배포하는 예시적인 소프트웨어 배포 플랫폼(705)을 도시한다. 예시적인 소프트웨어 배포 플랫폼(705)은 소프트웨어를 저장하고 다른 컴퓨팅 디바이스들(예컨대, 제3자들, 예시적인 접속된 에지 디바이스들)에 송신할 수 있는 임의의 컴퓨터 서버, 데이터 설비, 클라우드 서비스 등에 의해 구현될 수 있다. 예시적인 접속된 에지 디바이스들은 고객들, 클라이언트들, 관리 디바이스들(예를 들어, 서버들), 제3자들(예를 들어, 소프트웨어 배포 플랫폼(705)을 소유 및/또는 운영하는 엔티티의 고객들)일 수 있다. 예시적인 접속된 에지 디바이스들은 상업 및/또는 가정 자동화 환경들에서 동작할 수 있다. 일부 예들에서, 제3자는 개발자, 판매자, 및/또는 도 6b의 예시적인 컴퓨터 판독가능 명령어들(682)과 같은 소프트웨어의 라이센서이다. 제3자는 사용 및/또는 재판매 및/또는 서브라이센싱을 위해 소프트웨어를 구매 및/또는 라이센싱하는 소비자, 사용자, 소매업자, OEM 등일 수 있다. 일부 예들에서, 분산 소프트웨어는 하나 이상의 UI(user interfaces) 및/또는 GUI(graphical user interfaces)의 디스플레이로 하여금 서로 지리적으로 및/또는 논리적으로 분리된 하나 이상의 디바이스(예를 들어, 접속된 에지 디바이스들)(예를 들어, 물 분포 제어(예를 들어, 펌프들), 전기 분포 제어(예를 들어, 릴레이들) 등의 책임을 전담하는 물리적으로 분리된 IoT 디바이스들)를 식별하게 야기한다.
도 7의 도시된 예에서, 소프트웨어 배포 플랫폼(705)은 하나 이상의 서버 및 하나 이상의 스토리지 디바이스를 포함한다. 스토리지 디바이스들은 컴퓨터 판독가능 명령어들(682)을 저장한다. 예시적인 소프트웨어 배포 플랫폼(705)의 하나 이상의 서버는 위에서 설명된 예시적인 네트워크들 중 임의의 것 및/또는 인터넷 중 임의의 하나 이상의 것에 대응할 수 있는 네트워크(715)와 통신 상태에 있다. 일부 예들에서, 하나 이상의 서버는 상업적 트랜잭션의 일환으로서 요청 측 당사자에게 소프트웨어를 송신하라는 요청들에 응답한다. 소프트웨어의 전달, 판매 및/또는 라이센스에 대한 지불은 소프트웨어 배포 플랫폼의 하나 이상의 서버에 의해 및/또는 제3자 지불 엔티티를 통해 취급될 수 있다. 서버들은 구매자들 및/또는 라이센서들이 소프트웨어 배포 플랫폼(605)으로부터 컴퓨터 판독가능 명령어들(682)을 다운로드하는 것을 가능하게 한다. 예를 들어, 예시적인 컴퓨터 판독가능 명령어들에 대응할 수 있는 소프트웨어는 예시적인 프로세서 플랫폼(들)(700)(예를 들어, 예시적인 접속된 에지 디바이스들)에 다운로드될 수 있고, 이 프로세서 플랫폼(들)(700)은 스위치에서 콘텐츠 삽입을 구현하기 위해 컴퓨터 판독가능 명령어들(682)을 실행한다. 일부 예들에서, 소프트웨어 배포 플랫폼(705)의 하나 이상의 서버는 예시적인 컴퓨터 판독가능 명령어들(682)의 요청들 및 송신들이 통과해야만 하는 하나 이상의 보안 도메인 및/또는 보안 디바이스에 통신가능하게 접속된다. 일부 예들에서, 소프트웨어 배포 플랫폼(705)의 하나 이상의 서버는 개선, 패치, 업데이트 등이 최종 사용자 디바이스들의 소프트웨어에 배포되고 적용될 것을 보장하기 위해 소프트웨어(예를 들어, 도 6b의 예시적인 컴퓨터 판독가능 명령어들(682))에 대한 업데이트를 주기적으로 제공, 송신, 및/또는 강제한다.
도 7의 예시된 예에서, 컴퓨터 판독가능 명령어들(682)은 소프트웨어 배포 플랫폼(705)의 스토리지 디바이스들 상에 특정 포맷으로 저장된다. 컴퓨터 판독가능 명령어들의 포맷은 특정 코드 언어(예를 들어, 자바, 자바스크립트, 파이썬, C, C#, SQL, HTML 등), 및/또는 특정 코드 상태(예를 들어, 컴파일되지 않은 코드(예를 들어, ASCII), 인터프리팅된 코드, 링크된 코드, 실행가능 코드(예를 들어, 바이너리) 등)를 포함하지만, 이에 제한되지는 않는다. 일부 예들에서, 소프트웨어 배포 플랫폼(705)에 저장된 컴퓨터 판독가능 명령어들(682)은 예시적인 프로세서 플랫폼(들)(710)에 송신될 때, 제1 포맷으로 되어 있다. 일부 예들에서, 제1 포맷은 특정 타입들의 프로세서 플랫폼(들)(710)이 실행할 수 있는 실행가능 바이너리이다. 그러나, 일부 예들에서, 제1 포맷은 예시적인 프로세서 플랫폼(들)(710) 상에서의 실행을 가능하게 하기 위해 제1 포맷을 제2 포맷으로 변환할 하나 이상의 준비 태스크를 필요로 하는 컴파일되지 않은 코드이다. 예를 들어, 수신 측 프로세서 플랫폼(들)(710)은 프로세서 플랫폼(들)(710) 상에서 실행될 수 있는 제2 포맷의 실행가능 코드를 발생시키기 위해 컴퓨터 판독가능 명령어들(682)을 제1 포맷으로 컴파일할 필요가 있을 수 있다. 또 다른 예들에서, 제1 포맷은, 프로세서 플랫폼(들)(710)에 도달할 시에, 명령어들의 실행을 용이하게 하기 위해 인터프리터에 의해 인터프리팅되는 인터프리팅된 코드이다.
도 8은 실시예에 따른 서버리스(serverless) 데이터 센터(800)를 나타내는 블록도이다. 데이터 센터(800)는 논리적 서비스 블록들로 구성된다. 도 8에 예시된 서비스 블록들은 범용 컴퓨팅 서비스들(802), ML(Machine Learning) 및 AI(Artificial Intelligence) 서비스들(804), 계산 스토리지 서비스들(806), 및 가속 서비스들(808)을 포함한다. 서비스 블록들은 지능형 네트워크 패브릭(810)과 결합된다.
이 타입의 서버리스 데이터 센터(800)에 의해, 오케스트레이션을 수행하는 새로운 방식이 달성될 수 있고, 이는 현재의 관행들로부터, 고객이 의도만을 표현하고 오케스트레이션 스택 자체가 그 의도를 달성하기 위해 플랫폼을 설정하는 목표 주도 접근법으로 이동한다.
일부 기존의 SaaS(Software as a Service) 모델들은 전형적으로 그들의 소비자들에게 SLO(Service Level Objectives)의 서비스 특정적 세트를 프로모션한다. 예를 들어, 데이터 분석 플랫폼은 계산될 수 있는 시간당 다수의 작업을 프로모션할 수 있다. 이는 사용자 관점에서는 크지만, 여전히 SaaS 제공자가 요청들을 리소스 오케스트레이터에 전송하기 전에 필요한 리소스들에게 SLO들을 선제적으로 매핑할 것을 요구한다. 서비스 제공자들은 SLO들에 기초하여 리소스 타입들을 자동으로 선택할 수 없다.
본 명세서에 설명된 시스템들 및 방법들은 의도들(목표들)이 플랫폼 설정들에 자동으로, 동적으로, 그리고 직접적으로 매핑될 수 있는 방법을 예시한다. 의도들이 상위 레벨 목표들로서 수신되고 오케스트레이션 스택 전체에 걸쳐 하위 레벨 설정들에 매핑된다.
예를 들어, 어떤 것이 본 명세서에서 "P50 레이턴시"라고 지칭되는 시간 윈도우에서 완료되는 특정 비율이 존재한다는 애플리케이션 요건을 고려한다. 태스크들, 프로젝트들, 요청들, 또는 그와 유사한 것이 시간의 적어도 50%에서 제때에 완료할 필요가 있다는 것, 또는 태스크가 제때에 완료할 적어도 50%의 확률이 있다는 것을 나타내기 위해 "P50 타겟" 또는 "P50 완료들"과 같은, 유사할 수 있는 다른 용어들이 또한 사용될 수 있다. 이 의도는, 스레드 레벨 우선 순위를 표시하기 위해 그런 것처럼 그리고 그로부터 CPU 캐시 웨이/프로필 할당/리소스 할당으로, 하위 레벨 설정들에 매핑된다. 입력/출력(I/O) 측에서, 요청 및 응답을 송신 및 수신하기에 충분한 통신 리소스들이 이용가능하도록 보장하기 위해 의도가 네트워크 설정들에 매핑될 수 있다.
변하는 조건들에 동적으로 적응하기 위해, 시스템들 및 방법들은 아키텍처 내의 다양한 레벨들에서 제어 루프들을 이용한다. 제어 루프들은 신용 시스템, 유틸리티/비용 함수, 계획 및 해결기(solver) 등을 채택할 수 있다. 제어 루프들은 모니터링되는 시스템이 얼마나 빨리 적응할 필요가 있는지에 좌우되어 상이한 속도들로 실행될 수 있다. 이러한 제어 루프들은 컴퓨팅 시스템들의 역동성을 고려할 때 특히 중요하고 유용하다. 예를 들어, 네트워크 트래픽은 매일 달라질 수 있다. 고객들이 리소스 요건들 자체를 변경해야만 하는 경우, 서비스 제공자를 사용하는 데 그들에게 추가적인 부담이 있다. 덧붙여, 이러한 결정을 내리는 데 필요한 정보가 고객에게 노출되지 않을 수 있기 때문에, 이러한 변경이 어려울 수 있다. 그 대신에, 본 명세서에 기술된 시스템 및 방법을 사용하여, 고객은 의도를 지정하기만 하면 되고, 시스템은 리소스들을 자동으로 조절한다. 이는 고객과 서비스 제공자 둘 모두에 대한 비용 절감으로 이어질 수 있다.
시스템에서의 역동성은 생성되는 계획들에도 적용된다. 이러한 계획들은 시간적 요소를 갖는다. 예를 들어, 계획은 일시적으로(예를 들어, 수 분 정도) 고속 제어 루프의 감독 하에서 SLA를 따라잡기 위해 작업부하에게 풍부한 리소스들을 할당하는 것을 목표로 할 수 있고, 그 후 더 긴 기간(예를 들어, 월별)에 걸쳐 더 느린 제어 루프의 감독에 의해 수용 가능하고 알맞은 리소스 할당 패턴을 달성하려고 기대할 수 있다. 계획은, 자동으로 트리거될 수 있거나 또는 예를 들어, 인간 안내를 가능하게 하기 위해 계획을 인간 운영자에게 추천으로서 먼저 전송함으로써 부분적으로 수동으로 트리거될 수 있다.
덧붙여, 계획의 시간적 양태는 또한 연속적인 개선 관점에서 유용할 수 있다. 시스템-오브-시스템들(system-of-systems)에서 모든 SLO들을 만족시키는 계획은 모든 SLO들을 또한 만족시키지만 상이한 셋업, 구성, 또는 정책들의 세트를 트리거하는 또 다른 계획으로 대체될 수 있다. 예를 들어, 유지보수를 준비하기 위해, SLO는 리소스를 더 효율적으로 사용하거나, 인커밍 작업부하들/서비스들을 위한 공간을 만드는 것, 또는 그와 유사한 것을 할 수 있다.
분산형 서비스 지향 플랫폼에서, 오케스트레이션의 복잡도가 훨씬 더 증가한다. 여기 기술되는 시스템들 및 방법들은 상이한 이해 관계자들에 의해 소유될 수 있는 다중의 사이트에 걸친 오케스트레이션을 다룬다. 개개의 부분들이 무엇보다 중요한 의도를 달성하기 위해 협상 및 조정을 구현할 수 있으며, 이는 어떤 중앙집중식 오케스트레이션도 없을 때 가장 중요하다.
구현에서, 서비스 제공자는 애플리케이션 컨텍스트 메타데이터를 갖는 컴퓨팅 유닛(예를 들어, 포드(pod))을 배치할 수 있어서, 노드가, 빠른 제어 루프에서, 보다 적절한 애플리케이션 결정들을 행하고 가능하게는 그의 엔드-투-엔드 영향 속성으로 인해 낮은 우선순위 작업부하를 탈우선순위화(deprioritize)하지 않기로 선택할 수 있도록 한다. 그러나, 이는 E2E 뷰를 요구하고, 그것은 스택의 상위 계층들에서 동작들을 수행하는 다른 계산 노드들과 함께 데이터(데이터 출처, 준수, 및 기록을 포함함)에 대한 보안 함수들을 제공해야만 하는 노드들의 공동-스케줄링 및 공동-우선순위화의 개념들을 포함한다. 쿠버네티스(Kubernetes)에서, 포드(Pod)는 당신이 생성하고 관리할 수 있는 컴퓨팅의 최소 배치가능 단위이다. 포드는 공유된 스토리지 및 네트워크 리소스들, 및 컨테이너들을 실행하는 방법에 대한 사양을 갖는 하나 이상의 컨테이너의 그룹이다. 포드의 콘텐츠들은 항상 동일 장소에 위치되고 공동-스케줄링되며, 공유된 컨텍스트에서 실행된다.
의도 기반 시스템들로의 전환에 의해, 시스템은 배포 기능으로부터 리소스들이 잠재적으로 이용가능하게 될 수 있는지 및 리소스들을 이용가능하게 만들기 위해 시스템을 재구성하는 방법으로의 전환에 중점을 둔다. 리소스들은 동일한 카테고리에 있으면서 상이한 타입들의 것일 수 있다: 예컨대, 고성능 프로세서들(예컨대, Intel® Xeon CPU들) 대 몇 개의 감소된 계산 프로세서들(예컨대, Xeon-D들), 또는 단일의 대형 XPU 대 몇 개의 소형 XPU들. 게다가, 리소스 자체는 상이한 타입들의 서브리소스들/컴포넌트들, 예를 들어, 효율적이고 성능 좋은 코어들 등을 포함할 수 있다.
일부 구현들에서, 시스템은 클러스터 및 인프라스트럭처 관리자들의 수중에 서비스 레벨 목표 지향 제어들을 두고 또한 가능하게는 잘못된 저레벨 구성 상세 사항들을 지정해야만 하는 부담을 제거함으로써 복잡하고 분산된 인프라스트럭처를 관리 통제해야 하는 도전 과제를 해결한다. 관리 정책 컨트롤러(Admin Policy Controller) 및 관리 정책 변환 모듈(Admin Policy Translation module)이 오케스트레이션 아키텍처에서 구현될 수 있고, 다중의 티어의 의도 주도 관리 정책들을 관리하는 워크플로가 작업부하 분배 워크플로에서 사용될 수 있다. 임페러티브 구성들에 대한 다중의 반복으로 관리 정책들을 달성하는 방법을 포함하여 관리 정책들의 폐루프 제어가 사용될 수 있다. 이는 정책들 또는 정책 비준수(policy non-compliance)를 변경하는 것에 직면하여 작업부하 배치 및 재배치에 영향을 미칠 수 있다.
시스템은 쿠버네티스 관리자의 가정(assumption)들보다는 애플리케이션의 필요들을 반영하기 위해 쿠버네티스의 LCM(life-cycle management)을 실행하기 위한 새로운 모델을 구현할 수 있다. 애플리케이션은 (빠른 시작을 지원하기 위해) 일시적으로 배치되고, 후속하여 쿠버네티스의 새로운 인스턴스가 애플리케이션의 필요를 더 잘 반영하는 클러스터 및 노드 레벨 정책들과 함께 배치된다. 작업부하는 후속하여 새로운 클러스터로 이동된다.
CAT(Cache Allocation Technology) 및 MBA(Memory Bandwidth Allocation), 및 전력과 같은 공동 리소스들을 공유하는 현재의 방법들은 애플리케이션의 KPI들이 특정 동적 컨트롤러(예를 들어, RMD(Resource Management Daemon), DRC(Dynamic Resource Controller), Appqos 등)에 의해 모니터링되거나 또는 소진(exhaustion)을 다루기 위해 텔레메트리 인식 스케줄링(Telemetry Aware Scheduling)을 사용하는 것에 의존한다. "리소스 요청 브로커"를 오케스트레이션에 통합시키는 것은 애플리케이션 KPI(이것은 애플리케이션 자체에 의해 모니터링됨)와 독립적으로, 메시지 기반 시스템을 가질 수 있다. 브로커는 시간이 공유에서의 인자이기 때문에 플랫폼 상에 로컬 에이전트를 가질 수 있으며, 클러스터 "공유" 정책에 기초하여 로컬 판정들을 할 수 있다. 개별 포드들은 정적 계약들, "보장된 리소스 계약들", 동등한 공유 계약들, 또는 동적(입찰) 계약들에 가입할 수 있다. 경쟁 요청들이 매수/매도(bid/offer) 방식, 예를 들어, "나는 기간 N동안 리소스 Y를 위해 리소스 X를 기꺼이 포기하려고 한다"를 운영할 수 있는 로컬 브로커 에이전트에 의해 중재된다.
컴포넌트들이 여러 리소스들에 걸쳐 분산될 때 보안 위험이 발생한다. 의도 기반 오케스트레이션에서 그리고 QoS 클래스들과 유사하게, 시스템은 사용자들이 환경에서의 보안 또는 신뢰의 특정 양태들에 대해 그들이 얼마나 "민감"한지 또는 그들이 얼마나 많은 위험을 기꺼이 수락할지를 정의하도록 허용할 수 있다. 시스템은 위험을 모니터링, 분석, 및 액세스하기 위한 오케스트레이션 제어 평면에 대한 부가의 컴포넌트들의 세트는 물론이고 평가를 정책들, 리소스 할당들 등의 세트로 변환할 수 있는 컴포넌트를 포함할 수 있다.
도 9는 실시예에 따른, 다중의 하드웨어 시스템(902A 및 902B)을 갖는 운영 환경(900)을 예시하는 블록도이다. 운영 환경(900)은 북남쪽(예컨대, 전체 스택) 및 동서쪽(예컨대, E2E)으로 뻗어 있는 "시스템들의 시스템(system of systems)"으로 간주될 수 있다. 시스템(902A 또는 902B) 내의 각각의 계층에서, 상이한 종류의 의도가 북쪽에서 남쪽으로 또는 동쪽에서 서쪽으로 SLO들에 매핑될 수 있다. 스택 내의 다양한 계층들에서의 SLO들은 FPS(frames per second), 레이턴시, IPC(instructions per cycle) 등으로 기술될 수 있다. 기업들 또는 시스템들 사이의 SLO들은 서비스를 구성하는 개별 애플리케이션들이 전체 의도 목표들을 달성하기 위해 어떻게 상호작용할 필요가 있는지의 관점에서 기술될 수 있다. 예를 들어, E2E SLO들은 P99 레이턴시 < 100ms 요건, 프론트엔드 최대 10ms, 백엔드 5ms, 캐싱 최대 10ms 등을 포함할 수 있다. 풀 스택 SLO들 및 E2E SLO들의 목표를 달성하기 위해, 시스템은 상위 계층들로부터 하위 계층들로 정책들을 시행하고, 시스템들에 걸쳐 계층 내에서의 컴포넌트들 사이에서 조정하거나 협상한다.
SLO들, 풀 스택 또는 E2E(예를 들어, 시스템 대 시스템)는 시간에 따라 변화될 수 있고, 범위(예를 들어, 최소 및 최대 허용가능 값)로 표현될 수 있고, 특정 시간 기간 동안 범위들 밖으로의 편차 또는 분산을 허용할 수 있고, 선호되는 것으로서 또는 다른 우선순위화 방식들을 사용하여 표현될 수 있고, 또는 등등과 같이 된다. 예는 태스크가 10ms를 초과하지 않고 5ms의 바람직한 준수 레벨에서 실행되면서 60분 동안 시간의 99%를 P99 준수해야만 한다는 것일 수 있다.
일부 구현들에서, 그들의 작업부하와 연관된 사이드카(sidecar)들의 세트가 노드 상에서 사용된다. 사이드카들은 노드, 플랫폼, 설비들 등이 정확하게 셋업되고 따라서 그들의 작업부하의 목표들이 충족될 수 있도록 확실하게 하기 위해 조정한다. 사이드카들은 특정의 설정을 모니터링하고 올바른 정책들을 시행하며, 올바른 리소스들을 할당하고, 설정들을 튜닝하여, 포드들의 의도들이 충족될 수 있도록 할 수 있고, 등등이다.
일부 설치들에서, 작업부하에 대한 서비스 레벨 목표(Service Level Objective) 기반 입력 파라미터들이 제시될 때 오케스트레이션 시스템에 의해 판정되는 리소스 할당에 대해 차징/빌링(charging/billing) 제약조건들을 부여하는 도전 과제가 존재한다. 2개의 새로운 컴포넌트가 의도 기반 차징 및 의도 기반 빌링을 가능하게 한다: 1) 차징 가드레일 함수 및 2) SLO 계획 함수. 차징 가드레일 함수(Charging Guardrails Function)의 개념은 오케스트레이션 아키텍처에서 논리적으로 중심 점인 배치 워크플로에 도입된다. 그것은 할당된 리소스들이 사용자에게 알맞게 되도록 확실히 하기 위해 SLO 지향 리소스 계획 컴포넌트를 제어하고 안내하는 것을 담당하는 엔티티로서 작용한다. SLO 계획 함수는, 작업부하 SLA에 대한 알맞은 준수를 위한 그들의 적합성만이 아니라, 할당된 리소스에 대한 비용 기반을 고려할 필요가 있다.
도 10은 실시예에 따른 오케스트레이션 제어 평면(1000)을 도시하는 블록도이다. 오케스트레이션 제어 평면(1000)은 API(application programming interface)(1002)를 사용하여 액세스가능하거나 구성가능하다. 설정들, 데이터, 또는 다른 정보가 데이터베이스(1004)에 저장될 수 있다. 오케스트레이션 제어 평면(1000)은 리소스 관리자들(1006), 컨트롤러들(1008), 스케줄러들(1010), 플래너(1012), 모니터(1014), CIM(continuous improvement module)(1016), 및 관측가능성 스택(1018)을 포함한다. 플래너(1012), CIM(1016), 모니터(1014), 또는 오케스트레이션 제어 평면(1000)의 다른 컴포넌트들은 지식 데이터베이스(1020) 내의 데이터에 액세스하거나 지식 데이터베이스(1020)에 데이터를 저장할 수 있다. 지식 데이터베이스(1020)는, 예를 들어, 플래너 또는 스케줄러들에 대한 입력으로서 사용되는 다양한 데이터를 포함할 수 있다. 지식 데이터베이스(1020)는 태스크들의 배치 및 리소스들의 활용을 결정하기 위해 사용될 수 있는 네트워크 토폴로지 정보를 포함할 수 있다.
플래너(1012)는 하드와이어드 회로, 프로그래머블 하드웨어 디바이스(예를 들어, ASIC), 또는 하드웨어 플랫폼 상에서(예를 들어, 일반 CPU 상에서) 실행되는 명령어들을 사용하여 구현될 수 있다. 플래너(1012)는 의도들 또는 목표들을 SLO들에 매핑하도록 구성, 설계, 프로그래밍, 또는 달리 적응될 수 있다. 플래너(1012)는 또한 SLO들을 액션가능 계획들로 분해(break down)할 수 있다. 플래너(1012)는 SLO 요건들을 적절한 포드 사양들로 자동으로 번역 또는 매핑하기 위해 사용될 수 있는데, 이 포드 사양들은 컴퓨팅, 네트워크, 스토리지, 및 설비(예를 들어, 전력) 도메인들에 걸친 리소스 요건들, 플랫폼 피처들, 또는 정책들을 포함할 수 있다. 정책들 및 하위 레벨 목표 설정들에 대한 목표들의 매핑은 휴리스틱, ML(machine learning) 또는 AI(artificial intelligence) 메커니즘들, 작업부하 특성화들(예를 들어, 온라인 데이터로부터 또는 오프라인 실험을 통해 또는 샌드박싱을 통해 도출됨), 또는 소유자의 시스템을 어떻게 사용할지를 안내하는 리소스 소유자들로부터의 정책들을 구현할 수 있다.
플래너(1012)는 또 다른 플래너(1022)와 시스템-대-시스템(예를 들어, E2E)을 조정하고 잠재적으로 상이한 이해 관계자들에 속하는 다중의 PoP들(points-of-presence)을 매핑하기 위해 추가로 사용될 수 있다. 다양한 타입들의 조정 및 협상 방식들이 사용될 수 있다. 예를 들어, MAUT(multiple attribute utility theory) 모델이 리소스 할당을 협상하기 위해 사용될 수 있다.
플래너(1012)는 의도들을 액션 정책들, 시스템 설정들, 리소스 요건들, 및 그와 유사한 것으로 변환하는 것을 감독한다. 이것은 지식 데이터베이스(1020)에 저장된 통찰에 기초하여 이를 행한다. 일단 계획이 이용가능하면, 이것은 스케줄러(1010)에 의해 구현되고 시행된다.
계획은 오케스트레이션 제어 평면(1000) 내의 다양한 레벨들에서 다중의 SLO를 사용하여 정의될 수 있다. 예를 들어, 오케스트레이션 제어 평면(1000)의 상위 레벨들 상의 SLO들은 FPS를 레귤레이트(regulate) 및 제어하기 위해 사용될 수 있고, 오케스트레이션 제어 평면(1000)의 하위 레벨들 상의 SLO들은 IPC를 레귤레이트 및 제어하기 위해 사용될 수 있다. 벤더들, 사용자들, 및 서비스 제공자들은 표준화된 포맷을 사용하여 SLO들을 정의할 수 있다. SLO들은 또한 타겟 또는 한계 값들로부터 일부 변동을 제공하는 가드레일(guardrail)들을 포함할 수 있다. 예를 들어, 가드레일은 최대 10분 동안 P95의 10% 위반을 허용할 수 있다. 가드레일들은 또한 조건부일 수 있다. 예를 들어, 가드레일은 시스템이 그 후에 P99 준수를 보증할 경우 최대 10분 동안 P95의 10% 위반을 허용할 수 있다.
이종 컴퓨팅 셋업들 및 XPU 환경들이 증가함에 따라, 하위 레벨 오케스트레이션 및 리소스 관리자들은 아주 세분화된 레벨에서 작업부하들의 공동 스케줄링 및 공동 우선순위화를 지원하도록 구성될 수 있다.
태스크들을 리소스들에 할당할 때, 배치 문제는 해결하기 어렵다. 클러스터 기반 스케줄링과는 달리, 이 시스템은 필요한 완료 기한에 대한 동작의 근접성에 기초하여 로컬 리소스들이 재우선순위화되는 것을 허용한다. 부하 균형 및 자동 스케일 액션들은 중앙 집중식 스케줄러로부터 구동되어야만 할 필요 없이 그래프 병목들에서 국소적으로 개시된다. 이러한 액션들은 또한 중앙 집중식 또는 계층적 스케줄러로부터의 지속성 있는 명령어들과 비교하여 시간 제한된다.
프로세서들과 같은 일부 리소스들은 전력 사용을 최적화하는 방식으로 오케스트레이션될 수 있다. 프로세서 전력 레벨들(예를 들어, PL1, PL2, PL3 등)은 임계 전력 인출(threshold power draw)을 정의하기 위해 사용된다. 시스템 플랫폼은 이러한 PL 값들 및 다른 전력 값들(캡핑, P 상태, 언코어 주파수)을 파인 그레인드(fine-grained) 방식으로 계속 조절한다. 그러나, 이것은 성능 대 전력(performance to power)을 SLA들에 링크하는 전달 함수의 매우 시변적인 상황적 성질이 주어지면 복잡한 매핑이기 때문에, 조절들은 사전 훈련된 모델들을 통해 주도된다. 사전 훈련된 모델들은 활용들 및 전력에 걸쳐 다양한 시계열 도출된 트렌드 신호들을 입력들로서 취하는데, 이들은 일반적으로 코스 그레인드(coarse-grained) 타입들의 작업부하 믹스들(예를 들어, "AI", "gRPC 헤비", "미디어" 등)에 대해 훈련되는 모델들일 수 있다.
고객이 함수들을 등록할 때 스토리지 액세스 의도들을 표현할 때, 이러한 등록 의도들은 스토리지 계층으로부터 함수로의 효율적인 데이터 이동을 가능하게 하기에 충분한 컨텍스트를 인프라스트럭처 계층에 제공한다. 이는 데이터를 보유하는 서버들 상에서 컴퓨팅 가속기들을 사용하여 데이터 바로 옆에서 함수를 스케줄링하거나 또는 서버들 내에서 또는 서버들에 걸쳐 효율적인 데이터 전송 메커니즘들을 활용함으로써 행해진다. 중요한 점은 이것이 서버 로케이션에 대한 특정 지식을 필요로 하거나 또는 특정 컴퓨팅 리소스들 또는 전송 메커니즘들을 프로그래밍해야 하는 함수 없이 달성된다는 것이다. 스케줄링/배치는 프로세스의 시작에서의 함수이다. 액세스 패턴들이 배치 시간에 명확하지 않을 수 있으므로, 이 시스템은 또한 데이터 국소성 및 전송률들의 런타임 평가를 구현하고, 그러한 통찰력을 이용하여 자동 리스케줄링 이벤트들, 예를 들어, 어느 함수/마이크로서비스가 어떤 종류의 데이터를 처리하는 데 양호한지를 나타내는 히스토그램들을 트리거한다.
CIM(1016)은 정책에서의 절충들 또는 변경들을 분석하면서, 현재 동작들을 보다 효율적으로 만들기 위한 옵션들을 스카우트(scout)하고, 시스템이 가까운 미래에 어떻게 거동할지를 예측하는 것을 담당한다. 이 예측은 사전적 계획을 가능하게 하는 핵심이다. 반응적(reactive) 또는 사전적(proactive) 계획은 (다양한 고속/저속 루프들을 만족시키기 위해) 다양한 시간 스케일로 사용될 수 있다.
모니터(1014)는 관측가능성 스택(1018)으로부터 입력들을 취하고, 플래너(1012) 및 CIM(1016)을 피드(feed) 또는 트리거하기 위해 이 정보를 사용한다. 게다가, 관측가능성 스택(1018)은 지식 데이터베이스(1020)에서의 통찰, 휴리스틱 등이 온라인 및 오프라인 학습 프로세스들을 사용하여 정확한 것을 보증하는 것을 담당한다. 오프라인 학습은 실험 기반 작업부하 특성화를 통해 달성될 수 있다. 관측가능성 스택(1018)은 수집된 데이터를 사용하는 분석을 통해 아키텍처를 자체 진화시키기 위해 훈련 데이터를 수집할 수 있다. 훈련 데이터는 모니터들에 의해 캡처된 실세계 데이터로부터 도출될 수 있다. 대안적으로, 훈련 데이터는 오프라인으로 준비되어 관측가능성 스택(1018)에게 제공될 수 있다. CIM(1016)의 사용은 연속 개선 능력들을 갖고 시스템에서 자가 적응, 자가 치유, 및 최적화를 가능하게 하는 이점을 제공한다.
연속 개선을 제공하기 위해, 다중의 제어 루프가 구현될 수 있다. 도 11은 실시예에 따른, 오케스트레이션 시스템에서의 데이터 및 제어 흐름을 예시하는 블록도이다. 의도 기반 SLO들이 SLO 변환기(1102)에서 수신되고, SLO 변환기(1102)는 변환된 SLO들을 서비스 모니터(1104)에 피드한다. SLO 변환기(1102)는 플래너(1012)의 인스턴스이거나, 그것의 컴포넌트이거나, 또는 그것을 포함할 수 있다. 서비스 모니터(1104)는 모니터(1014)의 인스턴스이거나, 그것의 컴포넌트이거나, 그것을 포함할 수 있다.
SLO 변환기(1102)는 규칙들 및 사전들의 데이터베이스(예를 들어, 지식 데이터베이스(1020))를 사용하여 의도 기반 SLO를 3개의 양태: 1) 모니터링 파라미터들, 2) 구성 파라미터들, 및 3) 시간 도메인 파라미터들에 매핑할 수 있다.
모니터링 파라미터들은 서비스들, 태스크들, 또는 작업들을 모니터링할 때 서비스 모니터(1104)에 의해 사용된다. 모니터링 파라미터들은 서비스 모니터(1104)가 동작들을 능동적으로 모니터링하기 위한 일련의 유연한 가드레일들 및 요구되는 텔레메트리를 포함할 수 있다.
가드레일들은 시간 제한적(time-bounded) 및 범위 제한적(range-bounded) 유연성을 제공할 수 있으며, 따라서 이들은 컨텍스트에 민감하고 상황 적응적이 된다. 따라서, 오케스트레이터의 함수에 대해 적용되는 가드레일들은 매우 느리게 그러나 매끄럽게 시프트하여, 일련의 국소화된 여유를 이룸으로써 바람직한 엔드-투-엔드 목표를 최대화하는 것을 허용할 수 있다. 이 아이디어는 3가지 중요한 유연성을 달성한다: a) P99.9 레이턴시와 같은 가장 강한 제약조건을 취하고, 그 제약조건이 고정된 임계값으로부터 임계값 범위(즉, 시간상 짧은 지속기간 동안 +10 퍼센트)로 이동하여, 나중에 연장된 시간 기간 동안 훨씬 더 나은 P99.9 레이턴시만큼 보상되도록 허용하는 것, b) 한 번에 리소스 할당에서 가능하게는 비용이 많이 드는 조절을 취하고, 그것을 제한된 양의 시간만큼 벗어나게 이동시키며, 그 사이에, 만족스러운 해결책들이 계속 실행될 수 있도록 가드레일들을 부드럽게 해주는 것, 및 c) 수리 및 후속 정상 동작들이 픽업할 수 있을 때까지 리소스들이 보다 유연하게 공유될 것을 필요로 하는 데이터 센터의 다른 부분들에서 과도적 장애들을 다루기 위해 응급 요구, 수요 등에 대한 보다 풍부한 시스템 응답을 허용하는 것.
가드레일들에 대한 현재의 방법들은 가드레일 크로싱(guardrail crossing) 및 후속 교정을 평가하기 위해 사전 정의된 기간에 걸쳐 임계화 및 통합을 이용하는 것을 수반한다. 가드레일들이 "상태유지(stateful)" 또는 "컨텍스트(context)" 기반이 되도록 허용하는 것은 강한 제약들이 특정 조건들 동안 부드럽게 되도록 허용한다. 예를 들어, CPU 활용은 작업부하가 데이터를 캐싱함에 따라 작업부하의 제1 배치에서 최고가 되도록 허용될 수 있지만, 그 시간 후에, 정상 동작에서, 과도한 CPU 활용은 가드레일 크로싱을 트리거할 수 있다. 시스템은 가드레일들을 구현하기 위한 컨텍스트 정보로서 라이프 사이클 스테이징, 인서비스 업그레이드, HA 장애 조치, 서비스 메시 재시작 등을 포함하는 컨텍스트 지식을 추가한다.
구성 파라미터들은 오케스트레이터들 및 리소스 관리자들에 의해 컴퓨팅, 네트워크, 메모리, 및 기타 리소스들을 구성하기 위해 사용된다. 구성 파라미터들은 일련의 오케스트레이션 목표들로서 표현될 수 있는데, 이것들은 최고 레벨 오케스트레이션 시스템에 피드되고 오케스트레이션 스택의 각각의 하위 계층에 의해 일련의 서브목표들로 전환된다. 오케스트레이션 스택의 하단에는 파인 그레인드 제어로 튜닝될 수 있는 물리적 하드웨어 컴포넌트들이 있다. 이와 같이, 일련의 리소스 컨트롤러들이 컴퓨팅 플랫폼 상에서 정책들을 시행할 수 있다. 컴퓨팅 플랫폼은 CPU, GPU, FPGA, 가속기, IPU, 또는 다른 타입의 처리 디바이스일 수 있다.
시간 도메인 파라미터들이 모니터링 사이클들 및 구성 파라미터들에 대한 변경들이 얼마나 자주 이루어지는지를 설정하도록 제어 루프들을 구성하기 위해 사용된다. SLO 변환기(1102)는 비실시간 모니터링으로부터 실시간 모니터링까지의 범위에 있는, SLO 모니터링을 위한 시간 도메인들을 생성한다. 시간 도메인들은 대응하는 SLO에 대한 엄격한 모니터링 및 오케스트레이션 피드백 응답 시간들을 지정한다. 시간 도메인들은 도 11에서 주관적인 용어로 "더 느린", "느린", 및 "더 빠른" 것으로서 도시되지만, SLO 변환기(1102)에 의해 시간 도메인에 매핑되는 요건들에 좌우되어, 마이크로초, 시간, 일, 또는 그와 유사한 것과 같은 임의의 시간 측정으로 특정될 수 있다. 이들 시간 도메인 파라미터들은 고정되거나, 자동으로 업데이트되거나, 또는 별개로 구성가능할 수 있다.
서비스 모니터(1104)는 E2E 텔레메트리(1106), 비실시간 텔레메트리(1108), 거의 실시간 텔레메트리 또는 실시간 텔레메트리(1110)를 모니터링하는 계층들을 갖는다. 각각의 계층은 상이한 시간 도메인 파라미터들을 가질 수 있는 대응하는 제어 루프를 갖는다.
SLO 변환기(1102)는 의도들을 E2E에 대한 "서비스 레벨 모니터링", 느린 리소스 모니터링, 및 빠른 리소스 모니터링으로 변환한다. 규칙, 정책, 및 학습된 통찰에 기초하여, SLO 변환기(1102)는 의도의 타입, 요구되는 반응 속도, 또는 기타의 요건에 기초하여 인스턴스화될 수 있는 하나 이상의 서비스 모니터에 의도를 매핑한다. SLO 변환기(1102)는 "물리적 SLA들" 또는 "물리적 SLO들"이 경계들을 벗어날 때 오케스트레이션 스택 내의 엔티티들에게 통지들을 제공하도록 서비스 모니터들을 구성한다. 서비스 모니터들은 수동 또는 능동 프로브들, SDN(software defined networking) 컨트롤러들, 또는 SDN 분석 시스템들을 이용하여 E2E SLA들을 모니터링하는 고전적인 서비스 보증 솔루션들을 포함할 수 있다. 매핑된 SLO에 의해 요구되는 응답 시간을 달성하기 위해, 필요에 따라, 더 빠른 서비스 모니터들이 플랫폼들 상에 함께 위치될 수 있다.
시스템은, 예를 들어, 컴포넌트들의 배치에 대한 스마트 관측가능성, 및 정확한 로케이션에서 모니터링을 자동 주입하는 방법을 주입하는 방법들을 채택할 수 있다. 컴포넌트들의 배치 후에, 시스템은 자동 SLW 교정을 달성하는 제어 루프의 일부를 형성할 수 있다. 교정을 위한 경우가 있을 때, 시스템은 효과적이고 또한 부주의로 다른 서비스들에 영향을 주지 않는 정정 조치를 제공하기 위해 충분한 제어들이 준비되도록 보장한다.
도 11에 도시된 바와 같이, 의도 기반 오케스트레이션은 오케스트레이터들(1112-1114)의 계층 구조를 이용하여 구현될 수 있다. 표준 오케스트레이터는 사용자가 애플리케이션을 컴포넌트들의 세트 및 그 컴포넌트들을 플랫폼들 상에 랜딩시키기 위한 요건들로서 기술하도록 허용한다. 계층적 오케스트레이션은 문제가 분해되고 부분들로 분산되는 것을 허용하기 위해 사용될 수 있으며, 여기서 서브 오케스트레이터는 하나의 노드들의 서브세트 상에서 애플리케이션의 서브세트를 스케줄링하는 것을 담당하고, 또 다른 서브 오케스트레이터는 상이한 노드들의 서브세트 상에서 상이한 애플리케이션의 서브세트를 스케줄링하는 것을 담당한다.
표준 임페러티브 오케스트레이션과는 대조적으로, 사용자가, 컴포넌트의 요건들의 일부로서, 의도를 기술할 수 있게 함으로써 의도 기반 오케스트레이션이 가능하게 될 수 있다. 이것은 사용자가 원하는 결과를 선언하고 있는 선언 메커니즘이다. 따라서, (임페러티브 메커니즘에서와 같이) 특정 규칙들 또는 파라미터들을 표현하는 대신에, 사용자는 원하는 결과를 표현할 수 있다. 한 예는 어떤 주어진 레벨의 가용성 또는 최대 처리 레이턴시를 달성하는 것일 수 있고, 이를 위해 다중 인스턴스가 그 의도를 달성하기 위해 특정한 특성들을 갖는 노드들 상에 배치될 수 있다. 의도는 선언적 표현이다.
의도 기반 오케스트레이션을 표준 오케스트레이터의 스케줄러에 깊게 통합하기보다는, 의도 기반 스케줄링 알고리즘이 서브 오케스트레이터에 배치될 수 있다. 이 경우, 최상위 레벨 표준 오케스트레이터가 애플리케이션 기술을 수신할 때, 이것은 애플리케이션의 하나 이상의 컴포넌트에 대해 지정된 의도를 볼 수 있다. 이것은 이들 컴포넌트들의 스케줄링을 행하기 위해 의도 기반 서브 오케스트레이터에게 요청하는 것을 선택할 수 있다. 각각의 의도 기반 오케스트레이터 또는 서브 오케스트레이터는 특정 종류의 의도를 충족시키는데 전문화될 수 있다. 의도 기반 서브 오케스트레이터는 문제를 다른 서브 오케스트레이터들로 더 분해할 수 있다.
예를 들어, 인제스트(ingest) 단계, 처리 단계, 및 액추에이션 단계로 구성되는 비디오 분석 파이프라인을 고려한다. 전체적 응용은 각각의 카메라에 대한 인제스트 컴포넌트, 100ms 이하의 레이턴시의 의도를 갖는 처리 단계, 및 각각의 액추에이터에 대한 액추에이션 컴포넌트로서 기술될 수 있다. 최상위 레벨 오케스트레이터는 인제스천(ingestion) 및 액추에이션 컴포넌트 배치들을 취급할 수 있다. 처리는 부하 균형을 맞추고 원하는 레이턴시를 달성하기 위해 얼마나 많은 처리 컴포넌트들이 필요한지를 결정할 수 있는 의도 기반 오케스트레이터에 넘겨질 수 있다. 의도 기반 오케스트레이터는 심지어 태스크를 추가적인 서브 오케스트레이터들로 세분할 수 있으며, 따라서 다중의 노드들의 클러스터가 의도를 달성하는 데 (또는 아마도 클러스터 레벨에서 높은 가용성의 추가적인 의도를 가능하게 하는 데) 사용된다.
이 접근법의 몇 가지 이점이 있다. 첫째, 기존의 오케스트레이터들에서의 기존의 스케줄링 알고리즘들의 복잡한 의사 결정을 의도 기반 오케스트레이션의 똑같이 복잡한 의사 결정과 병합할 필요가 없다. 각각은 문제의 핵심 부분들에 대해 사용될 수 있다. 그에 부가하여, 분산 결정을 하는 것은 결정이 처리에 가깝게 푸시되도록 허용한다. 이는 더 빠른 반응성을 허용할 수 있으며, 이는 산업적 사용 사례들에서 빠른 제어 루프들과 같은 것들을 가능하게 하는 것을 도울 것이다.
다양한 실시예에서, 최상위 레벨 오케스트레이터는 고객으로부터 의도들을 수신하고, 의도 기반 서브 오케스트레이션이 요구되는 때를 식별하고, 최상위 레벨 오케스트레이터와 서브 오케스트레이터들 사이의 상호작용들을 정의하도록 구성, 프로그래밍, 또는 달리 적응된다. 최상위 레벨 오케스트레이터는 표준 오케스트레이터일 수 있고, 서브 오케스트레이터들은 도 10에 설명된 것과 같은 의도 기반 오케스트레이터일 수 있다. 오케스트레이터들의 계층 구조를 사용함으로써, SLA가 상위 레벨 오케스트레이터와 서브 오케스트레이터 사이에 합의된 경우 문제가 해결된다. 서브 오케스트레이터는 그것이 더 이상 SLA를 충족시킬 수 없을 때를 요청 측 오케스트레이터에 표시할 수 있다.
이러한 오케스트레이터들의 조직을 달성하기 위해, 의도들은 표준 오케스트레이터들과 호환되는 방식으로 표현되어야 하며, 이러한 표준 오케스트레이터들은 의도 기반 서브 오케스트레이션이 요구될 때를 식별할 수 있어야 한다. 요청 측 오케스트레이터와 요청 측 오케스트레이터를 충족시키기 위해 사용되는 서브 오케스트레이터들 사이에 프로토콜이 사용될 수 있다.
게다가, 애플리케이션이, 개별적으로 오케스트레이션되는 컴포넌트들로 스플릿될 때, 이들은 전체적인 오케스트레이션에 영향을 미치는 순서화 의존관계들을 가질 수 있다. 이러한 순서화 의존관계들이 존재하는 경우, 이들은 추상적 용어로 기술될 수 있다. 예를 들어, 생산자-소비자 흐름의 사용 사례에서, 생산 컴포넌트는 바람직하게는 X 단위의 데이터, 이벤트들, 프레임들 등을 소비 컴포넌트의 앞에 유지하는 것으로서 지정될 수 있다. 따라서, 각각의 컴포넌트에 대한 서브 오케스트레이터들은 리소스들의 할당에 대한 조건부 책임들을 질 수 있다(소비자는 시간 T0+delta에서보다 시간 T0에서 더 적은 리소스들을 필요로 하는 한편, 생산자는 시간 T0에서보다 시간 T0-delta에서 더 많은 리소스들을 필요로 한다). 이러한 "리소스 흐름들"은 서브 오케스트레이터들 사이에서 타이트하게 조정되게 되며, 따라서 본 예에서의 생산자 및 소비자는 집합적으로 CPU, 캐시, 메모리 대역폭 등의 X 분수(X-fraction)를 얻지만, 여기서 리소스들은 그들 사이의 막후 조종된 공유(choreographed sharing)에 따라 끊김 없이 흐른다. 유사하게, 우선순위 반전들이 방지될 필요가 있다; 따라서, 예를 들어, 소비자가 생산자가 그만큼 자신의 앞에 있는 거리를 따라잡고 감소시키려고 열심히 시도하고 있기 때문에, 생산자가 더 낮은 우선 순위를 가질 수 있지만, 소비자가 거리를 너무 빠르게 계속해서 줄여서 생산자가 이제 앞에 머무르려고 노력해야만 하는 경우, 스케줄링 소프트웨어의 끼어드는 튜닝을 요구하는 것 대신에, 우선 순위들이 거리의 함수로서 그들 사이에 빠르게 흐르게 하는 것이 합리적이다.
요청된 의도/목표들을 달성하기 위해, 가속 기술(FPGA들, GPU들 등)뿐만 아니라 전체 셋업(예를 들어, DRC)을 지원하는 하드웨어 피처들에 대한 요구가 구현될 수 있다. 종종, 가속기들 및 XPU들은 CPU 코드 개발자가 명령어들을 통해 직접적으로 제어하지는 않는 동작들을 실행한다. 따라서, 가속기 또는 XPU에서의 특정 하드웨어 특권으로, 또는 스택의 상위 레벨들에서의 통상의 소프트웨어에 불투명한 일부 방식으로 수행되는 민감한 동작들은, 그렇지 않았더라면 보안 필터링 동작들의 공동 스케줄링을 요구했을 보안 경계 제약들을 단순화할 수 있다. 게다가, 하위 레벨 피처들은 고속 제어 루프들에서 발생하고 있는 것을 다양한 제어 루프들에게 알릴 필요가 있다. 이러한 타입의 보고는 추적, 로깅, 및 모니터링을 위해 관측가능성 프레임워크의 확장/사용을 필요로 한다.
도 12는 실시예에 따른, 의도 기반 오케스트레이션을 구현하는 방법(1200)을 예시하는 흐름도이다. (1202)에서, 태스크의 실행을 위한 의도 기반 SLO(service level objective)가 오케스트레이터에서 수신된다.
(1204)에서, SLO는 복수의 정책에 매핑된다. 매핑은 정적 맵에 기초할 수 있다. 대안적으로, 매핑은 휴리스틱 또는 다른 지능적 메커니즘들을 사용하여 수행될 수 있다.
(1206)에서, 복수의 정책이 복수의 서브 오케스트레이터에 분배되고, 복수의 서브 오케스트레이터 각각은 태스크의 일부분의 실행을 관리한다. 정책들은 타입별로, 리소스별로, 또는 다른 인자들별로 그룹화되거나 분리될 수 있다. 서브 오케스트레이터들은 리소스들의 그룹, 리소스의 타입, 특정 노드 또는 노드들의 세트, 또는 그와 유사한 것을 담당할 수 있다.
(1208)에서, 태스크의 실행이 모니터링된다. 태스크 모니터링은 관심 있는 KPI들을 정의하고 그 후 그 KPI들에 대해 데이터를 되풀이해서 획득함으로써 수행될 수 있다.
(1210)에서, 모니터링에 기초하여 교정 동작이 개시된다. 교정 동작들은 마이그레이션, 리소스 할당 또는 할당 해제, 프로세스의 재시작 또는 중단, 컨테이너, 포드, 또는 마이크로서비스, 또는 그와 유사한 것과 같은 동작들을 포함할 수 있다.
기존의 오케스트레이션된 분산 컴퓨팅 환경들에서, 수백 또는 심지어 수천의 마이크로서비스들이 배치될 수 있다. 소프트웨어 기반 또는 소프트웨어 구현된 운영자들은 분산형 리소스들 및 실행가능 컴포넌트들을 관리하는데 이용된다. 운영자는 SLO/SLA 정책들에 기초하여 하드웨어 또는 소프트웨어를 구성할 수 있다. 하드웨어를 관리하는 대부분의 운영자들은 플랫폼 제공자에 의해 소유되거나 제공되지만, 소프트웨어를 관리하는 일부 운영자들은 고객에 의해 제공될 수 있다. 일반적으로, 운영자는, 데이터센터 레벨에서 동작들을 셋업, 모니터링, 구성, 및 수행하는데 이용되는 소프트웨어 구조물이다. 소프트웨어 구현된 운영자는 컨테이너 또는 작업부하와 함께 배치될 수 있다. 쿠버네티스에서, 운영자는 당신이 쿠버네티스 애플리케이션을 패키징, 배치, 및 관리하는 것을 도울 수 있는 애플리케이션 특정적 컨트롤러이다. 운영자들은 쿠버네티스의 기능성을 확장하고 자동화를 제공한다. 소프트웨어 에이전트들, 설비들, 및 유틸리티들은 운영자들과 동일하거나 유사한 서비스를 제공할 수 있다.
플랫폼들을 증명하고 검증하기 위해 다양한 메커니즘들이 사용된다. 예를 들어, TPM(Trusted Platform Module)은 하드웨어 기반 보안 관련 함수들을 제공하기 위해 사용될 수 있다. TPM 칩은 변조 방지(tamper-resistant)를 이루기 위해 물리적 보안 메커니즘을 제공하는 보안 암호 프로세서이다. TPM은 종종 하드웨어 플랫폼의 무결성을 보장하기 위해 사용된다. 대조적으로, 운영자는 그의 신뢰성을 증명하는 유사한 증명 메커니즘을 갖지 않는다. 또한, 운영자들은 평판 또는 신뢰성을 증명하는 메커니즘들을 갖지 않는다.
클라우드 서비스 제공자들이 대개는 데이터센터를 제어하지만, 공급자들은 펌웨어 또는 마이크로코드 업데이트들과 같이 그들이 생산, 판매 또는 지원하는 제품들에 대한 소정의 제어를 보유할 수 있다. 각각의 컴포넌트 또는 서브 컴포넌트는 (재귀적으로) 펌웨어 업데이트들, 설정들, 및 프로비저닝 인터페이스들에 대한 제어를 보유하는 하나 이상의 공급자를 가질 수 있다. 따라서, 데이터센터 및 관리 아웃소스 서비스 제공자들은 관리 제어를 완전히 위임하지 못할 수 있다.
결과적으로, 하드웨어 메커니즘들(이것들은 신뢰의 루트들을 포함함)은 제어를 보유하는 각각의 공급 체인 엔티티에 대한 것은 물론이고, 라이프사이클 관리 및 온보딩의 일부로서 위임된 제어일 수 있는 임의의 "소유자" 엔티티 또는 MSP(management service provider)에 대한 보안 스토리지에 아이덴티티들, 비밀들, 및 신뢰 앵커들을 가질 수 있다.
TPM, DICE(Device Identity Composition Engine), DPM(DICE Protection Module), 및 RPMB(Replay Protected Memory Block)는 신뢰 루트(root-of-trust) 기술들의 예들이다. 이들은 제조, 공급 동안 및 배치를 통하여 각각의 생태계 이해 관계자/소유자에 대한 아이덴티티들, 평판들, 증명들, 및 신뢰 정책들을 확립하는 데 이용될 수 있다.
오케스트레이터 시스템은 적법한 공급자들/소유권/서비스 제공자 관계들을 확립하는 정책에 대해 증명, 소유권 및 아이덴티티 값들을 추가로 검증할 수 있다. 후속 오케스트레이션 동작들은 이 정책이 먼저 충족되는 것에 의존할 수 있다.
본 시스템들 및 방법들은 고객이 위험 감수(risk tolerance) SLA를 공급하기 위한 메커니즘을 제공한다. 위험 감수 SLA는 여러 목적을 위해 사용될 수 있다. 예를 들어, 실행 동안, 운영자들은 신뢰성 또는 평판에 대해 평가될 수 있고, 위험 감수 SLA를 고려하여 임계 등급을 만족시키는 것들만이 사용될 수 있다. 또 다른 예로서, 플랫폼 능력들은 위험 감수 SLA를 고려하여 평가될 수 있고, 특정 플랫폼들 또는 구성들은 SLA에 표시된 위험 감수 또는 그로부터 도출된 정책들에 기초하여 필터링되거나 선택될 수 있다. 덧붙여, 태스크들이 리소스들을 공유하거나 차용할 수 있는 구현들에서, 운영자 평판은 태스크간 협상들의 일환으로서 이용될 수 있다.
데이터 센터 아키텍처들은 노드들의 신속한 프로비저닝, 서비스들의 자율 라이프사이클 관리, 및 필요할 때 끊김없는 업데이트들을 허용할 수 있기 위해 진화하고 있다. 생태계 제공자들은 전체 데이터 센터 및 관련 서비스들의 자동화, 강건성 및 라이프사이클 관리를 구현하기 위해서 운영자들과 같은 구조물들을 이용하는 방법들을 개발하는 쪽으로 이동하고 있다. 이러한 운영자들은 다중 타입의 기술들 및 언어들 위에서 개발될 수 있다. 운영자들은 운영자들의 성질에 좌우되어 시스템 구성 및 애플리케이션 배치, 및 라이프사이클 관리의 상이한 국면들에 수반될 수 있다.
여기 기술되는 시스템들 및 방법들은 운영자들이 상이한 상황들에서 어떻게 거동하는지를 모니터링하기 위한 오케스트레이션 및 인프라스트럭처를 제공한다. 예를 들어, 운영자들은 상이한 부하들, 상이한 타입의 서비스들 등으로 인해 장애나거나, 원하지 않는 방식으로 시스템들 또는 애플리케이션들의 거동을 변경하거나, 등을 할 수 있다. 시간이 지남에 따라, 시스템은 고객이 요청하는 동작을 적용하기 전에 운영자 거동과 시스템 조건들을 상관시킬 수 있다. 현재 상황이 주어지면, 시스템은 하나의 운영자에 의한 문제를 가질 가능성을 체크하고 또 다른 운영자를 선택하기로 결정할 수 있다.
도 13은 실시예에 따른, 위험 감수 의도들을 이용하여 오케스트레이션하는 데이터 및 제어 흐름을 예시하는 블록도이다. 위험 감수 의도(1300)가 운영자 선택 컨트롤러(1302)에서 액세스되거나 수신된다. 전술한 바와 같이, 의도 기반 SLO를 3개의 양태: 1) 모니터링 파라미터들, 2) 구성 파라미터들, 및 3) 시간 도메인 파라미터들에 매핑하기 위해 의도 기반 SLA들 또는 SLO들은 규칙들 및 사전들의 데이터베이스를 이용하여 변환될 수 있다. 여기서, 위험 감수 의도 SLA는 "나는 매우 신뢰성 있고 보장된 배치들을 원한다" 또는 "나는 가장 효율적인 배치들을 원하고 실험적 방법들을 사용하기를 기꺼이 원한다"로서 표현될 수 있다. 운영자 선택 컨트롤러(1302)가 프로그래머블 하드웨어(예를 들어, FPGA), 하드와이어드 하드웨어, 또는 그와 유사한 것으로서 플랫폼에 통합되거나 포함될 수 있다.
운영자 선택 컨트롤러(1302)는 위험 감수 의도 SLA로부터 도출되거나 그로부터 추출될 수 있는 위험 감수 등급에 액세스한다. 위험 감수 등급은 예를 들어, 특정 범위(예를 들어, 0 내지 7)의 수치 값일 수 있다. 규칙 데이터베이스는 위험 감수 등급 및 위험 감수 의도 SLA를 충족시키는 최소 평판 점수를 결정하기 위해 사용된다.
그 다음, 최소 평판 점수로부터 운영자들의 세트가 식별된다. 플랫폼에 이용가능한 운영자들은 운영자 데이터베이스(1312)에 저장될 수 있다. 운영자 데이터베이스(1312)는 운영자 식별자, 운영자의 타입, 성능 메트릭들, 또는 운영자의 다른 관련된 데이터와 같은 운영자 정보를 저장하기 위해 사용될 수 있다. 운영자 평판 점수들은 운영자 데이터베이스(1312)에 저장될 수 있다. 운영자 선택 컨트롤러(1302)는 최소 평판 점수에 기초하여 자격을 갖춘 운영자들을 선택한다.
평판 점수들이 안전하게 저장되도록 보장하기 위해 운영자 평판 점수들의 데이터베이스가 또한 블록체인(1308)에 저장될 수 있다. 블록체인 관리 로직(1310)은 운영자들에 대한 현재 평판들을 검색하고, 평판들을 업데이트하고, 및 그와 유사한 것을 하기 위해 블록체인(1308)에 액세스할 수 있다. 운영자 선택 컨트롤러(1302) 및 블록체인 관리 로직(1310)은 소비자의 위험 감수를 충분한 평판 점수를 갖는 운영자들과 효과적으로 매칭시킨다.
블록체인 또는 DLT(distributed ledger technology) 또는 분산형 컨센서스 알고리즘(distributed consensus algorithm)(예를 들어, 비잔틴 장군들(byzantine generals))은 평판 데이터를 평가하고 평판 점수들을 설정하는 다중의 엔티티 사이에서 사용될 수 있다. 컨센서스 알고리즘들은 소수 컨센서스가 평판에 영향을 주는 데 적용될 수 없도록 합의하는 다양한 커뮤니티가 존재하는 것을 보장한다.
블록체인 또는 DLT는 사실들을 위조하기 위해 쉽게 재작성될 수 없는 로그된 또는 이력 정보를 유지하기 위해 추가적으로 사용될 수 있다. 컨센서스 알고리즘은 또한 사실의 진실성을 확립할 뿐만 아니라 기록된 사실에 대한 손실 또는 수정을 방지할 수 있다.
평판은 신뢰성(예를 들어, 배치 후의 후속 인프라스트럭처 장애들의 수), 서비스 메시 중단 텔레메트리, 애플리케이션 SLA 위반들, 트리거된 라이프사이클 이벤트들의 수, 및 보안 위반들의 수를 포함하지만 이에 제한되지는 않는 많은 인자들로 구성될 수 있다. 이러한 타입들의 피드백은 인프라스트럭처 텔레메트리, 오케스트레이션 텔레메트리, 또는 서비스 텔레메트리에 의해 제공될 수 있다.
운영자 선택 컨트롤러(1302)는 운영자 모니터 로직(1304)에 모니터 규칙들을 제공한다. 운영자 모니터 로직(1304)은 인프라스트럭처 텔레메트리 및 다른 소스들로부터의 텔레메트리를 모니터링함으로써 운영자의 영향을 점수 매기기 위해 사용된다. 모니터 규칙들은 운영자의 시작 시간, 수정된 리소스들, 인프라스트럭처 엔드포인트들, 평가 윈도우, 텔레메트리 수집기들, 및 텔레메트리 KPI들에 대한 가드레일 값들을 포함할 수 있는 파라미터들을 포함할 수 있다.
운영자 분석 로직(1306)은 평가 윈도우 동안 일어나는 탈선들에 대한 경보들을 운영자 모니터 로직(1304)으로부터 수집할 수 있다. 이 탈선들은 운영자를 점수 매기기 위해 사용된다. 점수는 운영자 데이터베이스(1312)에 피드백되고, 운영자 선택 컨트롤러(1302)에 의한 미래의 선택들을 위해 사용된다. 운영자는 보안, 신뢰성, 프라이버시, 격리/멀티 테넌시(isolation/multi-tenancy), 또는 비용을 포함하는 다중의 차원에서 점수 매겨질 수 있다.
도 14는 실시예에 따른, 위험 감수 의도들을 사용하여 오케스트레이션하는 방법(1400)을 예시하는 흐름도이다. (1402)에서, 운영자를 실행하라는 커맨드가 수신된다. 커맨드는 운영자 식별자 및 최소 평판 점수를 포함할 수 있다. 커맨드는 또한 선택적인 평판 선택기 함수를 포함할 수 있다. (1404)에서, 운영자의 실행이 신뢰 평가를 요구하는지가 결정된다. 만일 그러한 경우, (1406)에서, 운영자 식별자를 사용하여 운영자의 평판을 검색하기 위해 블록체인이 액세스된다.
(1408)에서, 운영자의 평판은, 커맨드에서 제공되는 경우, 평판 선택기 함수에 기초하여 필터링된다. 운영자의 평판은 운영자의 이력 운영, 운영자의 소스, 운영자가 실행할 타겟 플랫폼 등을 포함하지만 이에 제한되지는 않는 다양한 인자들에 의해 영향을 받을 수 있다.
(1410)에서, 평판 점수가 요청 커맨드에서의 최소 평판 점수보다 높은지가 결정된다. 만일 그렇지 않은 경우, 방법(1400)은 종료되고, 운영자를 실행하라는 요청이 거절된다(동작(1412)). 실행이 거절될 때, 호스트는 디바이스를 구성하지 않을 것이다. 디바이스 소유자에게 통지하거나, 운영자 소유자에게 통지하고, 또는 그와 유사한 것을 하기 위해 통지가 생성될 수 있다. 디바이스가 더 낮은 값을 갖는 것인 경우(예를 들어, 미션 중요 디바이스가 아니라면) 호스트가 계산된 위험을 취하고 운영자를 실행할 수 있는 일부 상황들이 있을 수 있다.
평판 점수가 최소 평판 점수보다 높은 경우, 방법(1400)이 계속된다. (1414)에서, 운영자가 실행된다. 실행 결과가 체크되고(동작(1416)), 결과들이 블록체인에 전송된다(동작(1418)). 실행 결과들은 동작이 그 상에서 실행되는 플랫폼에 의해 증명될 수 있다. (1420)에서, 이력 점수에 기초하여 새로운 평판 점수가 계산된다. 새로운 평판 점수가 블록체인에 기입된다(동작(1422)).
도 15는 일 실시예에 따른, 의도 주도 보안 메커니즘을 구현하는 방법(1500)을 도시하는 흐름도이다. (1502)에서, 방법(1500)은, 컴퓨팅 노드 상에서의 애플리케이션의 실행과 관련된 위험 감수 의도에 기초하여, 소프트웨어 구현된 운영자의 실행이 신뢰 평가를 요구하는지를 결정하는 단계를 포함한다.
소프트웨어 구현된 운영자가 신뢰 평가를 요구한다는 결정에 응답하여, 이하의 동작들을 수행한다.
(1504)에서, 방법(1500)은 소프트웨어 구현된 운영자의 평판 점수를 획득하는 단계를 포함한다. 실시예에서, 평판 점수는 소프트웨어 구현된 운영자의 배치 이후의 후속 장애의 수에 기초한다. 관련 실시예에서, 평판 점수는 소프트웨어 구현된 운영자에 의해 야기되는 서비스 메시 중단을 나타내는 텔레메트리에 기초한다. 관련 실시예에서, 평판 점수는 소프트웨어 구현된 운영자에 의해 야기되는 애플리케이션 SLA(service level agreement) 위반에 기초한다. 관련 실시예에서, 평판 점수는 소프트웨어 구현된 운영자에 의해 야기되는 라이프 사이클 이벤트들의 수에 기초한다. 관련 실시예에서, 평판 점수는 소프트웨어 구현된 운영자에 의해 야기되는 보안 위반의 수에 기초한다.
(1506)에서, 방법(1500)은 위험 감수 의도로부터 최소 평판 점수를 결정하는 단계를 포함한다.
(1508)에서, 방법(1500)은 소프트웨어 구현된 운영자의 평판 점수를 최소 평판 점수와 비교하는 단계를 포함한다.
(1510)에서, 방법(1500)은 비교에 기초하여 소프트웨어 구현된 운영자의 실행을 거절하거나 허용하는 단계를 포함한다.
실시예에서, 방법(1500)은 소프트웨어 구현된 운영자의 실행을 모니터링하고, 실행 결과를 예상 실행 결과에 대해 체크하는 단계를 포함한다. 추가 실시예에서, 실행 결과는 컴퓨팅 노드에 의해 증명된다. 관련 실시예에서, 방법(1500)은 실행 결과를 블록체인에 저장하는 단계를 포함한다. 추가 실시예에서, 방법(1500)은 실행 결과에 기초하여 수정된 평판 점수를 계산하고 수정된 평판 점수를 블록체인에 저장하는 단계를 포함한다.
실시예에서, 수정된 평판 점수를 계산하는 것은 소프트웨어 구현된 운영자의 이력 운영, 소프트웨어 구현된 운영자의 소스, 또는 소프트웨어 구현된 운영자가 실행한 컴퓨팅 노드를 평가하는 것을 수반한다.
실시예에서, 방법(1500)은 태스크가 보안 위험에 의해 위협받는지에 대한 분석에 기초하여 결정하는 단계 및 위험 감수 의도와 부합하는 응답 액션을 개시하는 단계를 포함한다.
기존의 배치 모델들은 VM(virtual machine) 내부의 클라우드 네이티브 배치들 또는 순수 클라우드 네이티브 접근법들을 사용한다. 전자의 모델에서, 테넌트들은 상이한 VM들에서 격리되고 서비스들로부터의 포드들은 동일한 가상 공간을 공유한다. 후자의 모델에서, 테넌트들은 동일한 환경을 공유한다. 그러나, 어느 경우든지, 엔티티들이 분리되어 있다 - VM당 다중의 포드를 갖는 다중의 VM이 있거나, 또는 다중의 포드가 있다 -. 이러한 엔티티들(VM들 또는 포드들)은 리소스들을 공유하는 것을 제공하기 위해 서로 통신할 수 없다.
본 명세서에 기술되는 시스템들 및 방법들은 오케스트레이션 시스템에 통합되는 리소스 요청 브로커를 제공한다. 리소스 요청 브로커는 (애플리케이션 자체에 의해 모니터링되는) 애플리케이션 KPI와 독립적으로 메시지 기반 시스템을 유지할 수 있다. 브로커는 공유 정책들에 기초하여 로컬 판정들을 할 수 있는 로컬 에이전트를 플랫폼 상에 가질 수 있다. 공유 정책들은 호스트 레벨, 클러스터 레벨, 또는 다른 배열들에서 설정될 수 있다.
개별 포드들은 정적 계약들, "보장된 리소스 계약들", 동등한 공유 계약들, 또는 동적(입찰) 계약들에 가입할 수 있다. 경쟁 요청들은 로컬 브로커 에이전트에 의해 중재되며, 이는 매수-매도 방식(bid-offer scheme)을 동작시킬 수 있다. 예를 들어, 엔티티는 "나는 기간 N동안 너의 리소스 Y를 위해 나의 리소스 X를 기꺼이 포기하려고 한다"를 표시할 수 있다. 또 다른 예로서, 포드는 "내가 중요한 것을 하지 않을 때 또는 내가 내 SLA를 감소시킬 수 있을 때 일부 시간 동안 일부 계산 용량을 감소 또는 해제할 수 있다"를 표시할 수 있다. 이는 포드들 또는 VM들이 또 다른 피어가 어떤 리소스를 공유할 의향이 있다는 것을 알고, 그 후 어떤 시간 동안 주어진 피크 부하를 흡수하기 위해 이를 차용하는 메커니즘을 제공한다.
이는 또한 하나의 VM 또는 포드가 피크에 대해 더 많은 마력을 필요로 하는 다른 방식으로 작업할 수 있다. 포드 또는 VM은 "내가 어떤 시간 동안 더 많은 컴퓨팅을 그로부터 차용할 수 있는 임의의 피어가 있는가?"를 요청할 수 있다. 또한, 요청은 그러한 서비스에 대해 지불할 의향을 나타낼 수 있다, "이봐, 어느 누구라도 내게 일부 컴퓨팅을 빌려줄 수 있나? 나는 X를 기꺼이 지불하고자 한다." 계약들이 충족될 때, 계약들을 마감하기 위해 이들이 오케스트레이션 엔티티에 제공될 수 있다.
도 16은 실시예에 따른, 플랫폼(1600) 상의 엔티티들 간의 리소스 공유를 구현하기 위한 데이터 및 제어 흐름을 도시하는 블록도이다. 엔티티들은 애플리케이션 A(1602A) 및 애플리케이션 B(1602B)를 포함한다. 각각의 애플리케이션(1602A 및 1602B)은 미리 정의된 KPI들을 이용하여 플랫폼(1600) 및 SLA 범위 상에서 이용가능한 리소스들을 측정하는 공동 배치된 로컬 SLA 리소스 모니터(1604A, 1604B)를 갖는다. 애플리케이션들(1602A 및 1602B)은 하나 이상의 컨테이너, 하나 이상의 VM, 하나 이상의 컨테이너 내의 하나 이상의 VM, 또는 하나 이상의 VM 내의 하나 이상의 컨테이너를 실행하기 위한 컨테이너들 또는 하이퍼바이저들(1606A, 1606B)을 갖는다.
애플리케이션(1602A, 1602B)에 대해, 요구가 애플리케이션(1602A, 1602B)이 사용하고 있는 리소스에 대한 미리 정의된 임계값을 초과할 때, 리소스 요구 요청이 생성된다. 리소스 요구 요청은 시간 제약될 수 있다(예를 들어, 요청을 만족시키기 위한 유효 시간 기간을 가질 수 있다). 반대로, 대응하는 SLA가 지정된 허용가능 범위에 있는 동안, 리소스 활용이 미리 정의된 범위에 걸쳐 임계값 아래로 떨어질 때, 리소스 이용가능 통지가 생성된다. 리소스 이용가능 통지는 리소스들을 재할당할 때 SLA의 중단에 대한 허용오차(예를 들어, 재할당가능 리소스들의 최대 할당이며 그래서 애플리케이션이 SLA를 위반하지 않음)를 포함할 수 있다.
리소스 요구 요청들 및 리소스 이용가능 통지들은 SLA 중재기(1610)에 송신된다. SLA 중재기(1610)가 요청들 및 통지들을 집계하고 규칙들에 기초하여 어느 요청들/통지들이 충족될 수 있는지를 평가한다. 요청들 및 통지들을 처리할 때, SLA 중재기(1610)는 SLA 리소스 모니터(1618)로부터의 리소스 사용 텔레메트리, 엔티티들의 평판들, 엔티티들과 연관된 운영자들 등을 사용하여, 요청을 만족시키려고 시도할지 또는 통지를 처리할지를 결정할 수 있다. 리소스 재할당이 승인된 후에, 리소스 운영자(1612)는 런타임에서 특정 리소스들의 할당을 조절한다. 리소스 운영자(1612)는 변경의 기록을 유지하고, 요청 또는 통지에 표시된 시간 기간 이후에 이것을 복귀시킨다.
SLA 중재기(1610)가 애플리케이션을 상이한 플랫폼으로 이동시키기로 결정하는 경우, SLA 중재기(1610)는 애플리케이션을 재위치시키기 위한 커맨드를 리소스 운영자(1612)를 통해 오케스트레이션 스케줄러(1614)에 전송한다. SLA 중재기(1610)가 공유 플랫폼 상에서 리소스들을 재할당하기로 결정하는 경우, 리소스 할당들을 조절하기 위한 커맨드가 리소스 운영자(1612)를 통해 리소스 제어 에이전트(1616)에 전송된다.
도 17은 실시예에 따른, 플랫폼 상에서의 리소스 공유를 위한 방법(1700)을 도시하는 흐름도이다. (1702)에서, 플랫폼 상에서 실행되는 제1 애플리케이션으로부터의 통신이 수신된다. 통신은 제1 애플리케이션의 추가 리소스들에 대한 요청 또는 제1 애플리케이션이 필요로 하지 않는 이용가능 리소스들의 통지 중 하나이다.
(1704)에서, 통신이 추가 리소스들에 대한 요청인 것에 응답하여, 플랫폼에서 리소스이 이용가능한지가 결정되고, 만일 그러한 경우, 리소스들이 애플리케이션에 할당된다.
(1706)에서, 통신이 추가 리소스들에 대한 요청인 것에 응답하여, 리소스들이 플랫폼에서 이용가능한지가 결정되고, 만일 그렇지 않은 경우, 애플리케이션을 상이한 플랫폼으로 이동시키기 위한 마이그레이션이 개시된다.
(1708)에서, 통신이 이용가능 리소스들의 통지인 것에 응답하여, 플랫폼 상에서 실행되는 제2 애플리케이션이 이용가능 리소스들과 매칭되는 리소스들을 요청했는지가 결정되고, 만일 그렇다면, 이용가능 리소스들의 대출이 제2 애플리케이션에 대해 용이하게 된다.
일반적으로, 위험 감수는 신뢰의 면 및 또한 보안의 면 모두를 포괄한다. 평판을 이용하여 신뢰가 반영된다. 기존 시스템들에서, 보안은 바이너리 판정으로서 취급된다 - 클라이언트가 보안 환경을 요구하는가 요구하지 않는가? 멀티 테넌트 배치 환경에서, 보안 문제는 더 복잡해진다. 예를 들어, 작업부하가 단일 테넌트 XPU 상에서 실행된다고 가정하면, 전송 레벨 보안이 인에이블되는 한, 서비스 소유자가 공동 위치된 테넌트를 허용하는 것이 좋을 수 있다. 그러나, 보안에 더 민감한 테넌트는 배타적 환경(즉, 환경이 임의의 다른 테넌트와 공유되지 않는 환경)을 요구할 수 있거나, 또는 아마도 신뢰된 이웃들과만 공유될 수 있다. 이러한 타입의 보안 튜닝은 바이너리 판정기를 사용하여서는 가능하지 않다. 그 대신에, 보다 효율적이고 비용 효과적인 배치 구성을 제공하기 위해 필요한 것은 보다 정량적인 보안 메커니즘이다.
위험 감수 의도의 일부분은 보안 의도일 수 있다. 보안 의도는 이것이 요구하는 보안 특징 또는 목적의 테넌트 또는 테넌트 소유자에 의한 표현일 수 있다. 테넌트 또는 고객은 작업부하에 대한 보안 의도를 프라이버시 및 보안 위험 진술문으로서 표현할 수 있다. 예를 들어, 이 표현은 다음과 같은 형식의 것일 수 있다:
- 내 서비스는 프라이버시 정보를 안전하게 할 필요가 있고 영향은 적은 수의 사용자들에게만 영향을 줄 것이다.
- 내 서비스는 나의 비즈니스에 필수적이고, 보안 위반 또는 프라이버시는 100M 달러까지 비즈니스에 영향을 줄 것이다.
- 나는 내 작업부하가 연방 보안 및 프라이버시 요건들을 준수하기를 원한다.
- 나는 내 작업부하가 유럽 프라이버시 요건들을 준수하기를 원한다.
- 나는 나의 작업부하 데이터가 이러한 로케이션들 및 비즈니스들과만 공유되기를 원한다.
- 나의 작업부하는 다음과 같은 프라이버시 진술문에 따라 취급되는 개인 데이터를 포함한다.
본 명세서에 설명된 시스템들 및 방법들은 보안 관련 의도 선언들의 세트의 정의를 가능하게 한다. 고객들 또는 서비스 소유자들은 그들의 서비스들 또는 애플리케이션들의 실행 동안 만족될 것을 요구하는 위험 및 위협 프로필들을 정의할 수 있다. 위협은 발생할 수 있는 이벤트이다. 위험은 하나 이상의 위협이 발생할 확률이다. 위험들은 높은, 중간, 및 낮은 확률 구역으로 나누어질 수 있다. 각각의 확률 구역은 수치 값(예컨대, 최고 위험은 1.0이고 최저 위험은 0인 [0, 1]의 범위에 있는 숫자)을 할당받을 수 있다.
정책 시행으로 완화된 오구성들, 자동적 안티-어피니티(anti-affinity) 설정들을 통해 완화된 부채널(side channel) 공격, 패스워드 스캐닝을 통해 완화된 손상된 크리덴셜들 또는 중복 공유 크리덴셜들, 적용된 공지된 취약점 픽스(fix)들에 대한 스캔을 통해 완화된 제로 데이 취약점(zero-day vulnerability)들, 또는 소프트웨어 스택 증명을 통해 완화된 스파이/랜섬웨어 공격들을 포함하지만 이들로 제한되지는 않는 다양한 위협들이 고려될 수 있다.
서비스들이 상이하게 셋업되기 때문에, 이들에 대한 위험들이 또한 상이하게 해결될 필요가 있다. 예를 들어, 드물게 통신하는 2개의 컴포넌트로 구성되는 서비스는 상시 통신 중인 많은 컴포넌트들로 구성되는 서비스와는 상이하게 해결될 필요가 있다. 본 명세서에 기술되는 시스템들 및 방법들은 위험을 모니터링, 분석, 및 평가하기 위해 컴포넌트들의 세트를 오케스트레이션 제어 평면에 추가한다. 또 다른 새로운 컴포넌트가 평가를 일련의 정책들, 리소스 할당들 등으로 변환할 수 있다.
도 18은 실시예에 따른, 의도 주도 보안의 전체 흐름을 도시하는 도면이다. 테넌트는 테넌트 의도(1802) 및 대응하는 테넌트 작업부하(1804)를 오케스트레이터(1806)에 제공한다. 오케스트레이터(1806)는 플랫폼(1808)(예를 들어, 프로세서, 코어, XPU, IPU 등) 상에서 작업부하(1804)를 스케줄링한다. 플랫폼(1808)은 이종 리소스 풀(예를 들어, 컴퓨팅 클러스터)에서의 많은 것들 중 하나일 수 있다. 텔레메트리, 증명, 및 다른 데이터가 실시간 보안 분석 시스템(1810)에 제공되는데, 이것은 다양한 위협들을 모니터링하기 위해 사용된다. 실시간 보안 분석 시스템(1810)은 오케스트레이터(1806)에 피드백을 제공하고, 오케스트레이터(1806)는 다음 차례로 플랫폼(1808)의 동작 파라미터들을 조절하거나, 작업부하(1804)를 상이한 플랫폼에 마이그레이션하거나, 또는 다른 교정 동작들을 수행할 수 있다.
도 19는 실시예에 따른, 보안 관리자(1900)의 컴포넌트들을 도시하는 블록도이다. 보안 관리자(1900)는 오케스트레이션 제어 평면(1902)의 컴포넌트이다. 오케스트레이션 제어 평면(1902)은 API, 리소스 관리자들, 컨트롤러들, 스케줄러들, 및 모니터링 설비들과 같은, 도 10에서 앞서 논의되었던 다른 컴포넌트들을 포함한다. 도 19에 도시된 구현에서, 보안 관리자(1900)는 모니터링 설비(1904)로부터 정보를 수신하고 이 정보를 처리하여 검출된 위협에 어떻게 반응할지를 판정한다.
API(1906)는 보안 관리자(1900)를 구성하기 위해 사용된다. API(1906)는 또한 보안 관리자(1900)에 의해 모니터링되는 각각의 컨텍스트에서 실행되는 앱들에 대한 보안 레벨, 위험 요인들, 또는 위협들을 검사하기 위해 사용될 수 있다.
보안 관리자(1900)는 위험 평가 엔진(1908), 위협 평가 엔진(1910), 위험 완화 엔진(1912), 및 위협 완화 엔진(1914)을 포함한다. 보안 관리자(1900)는 정책 데이터베이스(1916)를 사용하여 검출된 위험들 및 위협들에 대한 응답 액션들을 결정한다.
위협 평가 엔진(1910)은 잠재적인 위협들을 식별하기 위해 모니터링 설비(1904)로부터의 실시간 보안 분석을 처리한다. 유사하게, 위험 평가 엔진(1908)은 잠재적 위협들(즉, 위험들)의 확률을 식별하기 위해 모니터링 설비(1904)로부터의 실시간 보안 분석을 처리한다.
위험 평가 엔진(1908) 및 위협 평가 엔진(1910)의 주요 태스크들은, 주어진 작업부하에 대해, 서비스 소유자에 의해 선언된 위험 의도 및 위협 완화를 이행하기 위한 최상의 가능한 보안 메커니즘을 결정하는 것이다. 이것은 각각의 서비스, 고객, 및 플레이 중인 하드웨어 플랫폼에 대해 상이할 것이다.
예를 들어, 작업부하가 매우 기밀적이고 지오펜싱된 데이터세트에 액세스하는 경우, 작업부하는 데이터세트의 지오펜싱과 일치하는 클러스터에 배치될 수 있다. 또한, 데이터세트는 위협 완화 정책들을 만족시키기 위해, 전송(transport) 등을 위한 TLS를 이용하여 암호화될 수 있다. 초기 보안 구성은, 예를 들어, 쿠버네티스 클러스터에서의 배치/포드 사양 레벨에 대해 주석이 달릴 수 있다. 런타임 시에, 초기 평가 및 도출된 보안 메커니즘들은 위험 완화 엔진(1912) 또는 위협 완화 엔진(1914)에 의해 필요한 경우 모니터링되고 적응된다. 실행 상태에 좌우되어, 위험 완화 엔진(1912) 또는 위협 완화 엔진(1914)은 설정들 및 정책들을 적소에 조작할 수 있다. 위험 완화 엔진(1912) 또는 위협 완화 엔진(1914)은 그것이 더 양호한 효율로 귀결될 경우에 설정들 또는 정책들을 선행적으로 변경할 수 있다. 메커니즘들은 런타임 동안 조절될 수 있는데, 예를 들어, 일부 서브태스크들이 완료됨에 따라, 다른 서브태스크들이 상이한 보안 정책으로 실행되고 있을 수 있다. 또한, 테넌트 작업부하가 불량하게 거동하고 있는 경우, 보안 정책들이 더 엄격해질 수 있거나 또는 위험 완화 엔진(1912) 또는 위협 완화 엔진(1914)이 작업부하를 또 다른 플랫폼으로 이동시킬 수 있다.
다음은 위험 완화 엔진(1912) 또는 위협 완화 엔진(1914)에 의해 채택될 수 있는 보안 메커니즘들의 리스트이다. 언어 레벨 격리, 프로세스 레벨 격리, 가상화, 신뢰된 실행 환경들(예를 들어, SGX, TDX, ARM Trustzone, Realms 등)의 이용, 또는 전용 코어 상에서의 실행을 포함한, 다양한 격리 메커니즘들이 이용될 수 있다. IPSec, TLS, 보안 전송들, 링크 레벨 보안, 암호화 알고리즘들, 포스트 퀀텀 암호화(post-quantum crypto), 또는 다양한 암호 강도들의 사용을 포함하는 다양한 통신 보안 메커니즘들이 사용될 수 있다. 데이터가 휴지 상태에 있을 때, 스토리지 암호화가 사용될 수 있다. 어피니티 또는 안티-어피니티 설정들을 다루기 위해, 오케스트레이션은 특정 태스크들의 동일 로케이션을 피할 수 있다. 다른 보안 메커니즘들 또는 인자들은 이미지(예를 들어, 컨테이너 이미지) 보안, 역할 기반 액세스 제어 시행, 루트 액세스 요건들, 및 사후 배치 클린업(post-deployment clean up)(예를 들어, 스크래치패드들/드라이브들에 랜덤 데이터를 기입하는 것)을 포함한다.
보안 정책들은 공간적 배치 정책들 및 시간적 배치 정책들을 포함할 수 있다. 공간적 배치 정책들은 배치의 지오-로킹(geo-locking) 로케이션들, 하나의 작업부하가 특정 특성들을 갖는 또 다른 작업부하와 공동 위치될 수 없는 작업부하 배제들, 및 리소스 풀에서 작업부하들의 랜덤 배치를 요구하는 것과 같은 양태들을 포함한다. 시간적 배치 정책들은 작업부하가 (예를 들어, 이동 타겟 방어를 채택하기 위해) 지정된 간격으로 리소스 풀 내의 랜덤 로케이션으로 마이그레이션되어야만 하는 것을 요구하는 것과 같은 양태들을 포함한다.
보안 관리자(1900)는 테넌트 의도 및 실시간 보안 분석에 기초하여 리소스 할당 판정들을 하기 위해 의도 주도 오케스트레이션 함수를 제공한다. 위험 평가 엔진(1908) 및 위협 평가 엔진(1910)은 보안 분석 함수를 제공한다. 위험 평가 엔진(1908) 및 위협 평가 엔진(1910)은 리소스 풀 텔레메트리를 소비한다. 예를 들어, 성능 카운터들을 사용하여 작업부하들이 악성 거동들을 나타내는지를 평가하기 위해 리소스 풀 텔레메트리가 처리된다. 플래깅되는 작업부하들은, 예를 들어, 프로세스 격리를 이용하는 환경으로부터 가상화된 환경으로, 더 강한 보안 보장을 갖는 실행 환경으로 종료되거나 그것에 마이그레이션될 수 있다. 위험 평가 엔진(1908) 및 위협 평가 엔진(1910)은 또한 증명 측정들을 고려할 수 있다. 증명 메커니즘들은 분석 함수가 그것의 구성요소들, 예를 들어, 실행 환경 무결성, 플랫폼 무결성, 및 플랫폼 아이덴티티의 관점에서 리소스 풀에서의 신뢰를 확립할 수 있게 한다.
증명은 특정 리소스들 또는 POP(point-of-presence)가 얼마나 잘 수행되는지를 확립하기 위해 신뢰도 점수 또는 평판 점수를 제공할 수 있다. 이것은 위험 완화 엔진(1912) 또는 위협 완화 엔진(1914)에 의해 제공되는 완화 및 교정을 위한 핵심 입력일 수 있다. 신뢰/진실성이 제3자를 통해 확립되는 다른 방법이 없을 때 블록체인 기반 결정이 사용될 수 있다. 초기에, 플랫폼 또는 노드는 그의 성능의 어떤 이력도 갖지 않을 수 있다. 램프 업 스테이지(ramp up stage)는 노드가 특정 신뢰 기록을 구축할 때이다. 노드는 새로운 노드를 사용할 의향이 있는 클라이언트들로부터 임의의 작업부하를 취할 수 있다. 제3자 브로커 서비스들은 (시동 관성(startup inertia)을 다루기 위해) 그들의 클라이언트 스트림들 점프 스타트하기 위해 그러한 초기 노드들에 대한 테스트 및 증명 서비스(test-and-attestation service)들을 제공할 수 있다. 덜 민감한 데이터 또는 더 낮은 서비스 품질 레벨들을 갖는 클라이언트들은 더 낮은 전체적 위험을 제시하기 때문에 노드를 사용할 수 있다. 시간이 지남에 따라, 노드는 그 자신에 대한 평판을 구축할 수 있고, 그것을 신뢰할 의향이 있는 다른 클라이언트들을 점진적으로 끌어들일 수 있다. 노드와 상호작용한 후에, 노드 및 고객(즉, 애플리케이션, 가상 머신, 컨테이너 등) 각각은 블록체인에서의 노드의 평판 점수에 평판 조절을 추가할 수 있다. 정상 상태에서, 블록체인은 노드의 신뢰 충족 또는 신뢰 위반 이력의 전체 기록을 제공한다. 무엇이 협상되었는지, 무엇이 위반되었는지 등의 공개적이고 불변의 기록이 있도록 소비자 및 제공자 둘 다가 자신의 트랜잭션들을 블록체인에 입력할 책임이 있다. 평판 점수 또는 프로필은 다중의 PoP(points-of-presence)(클라우드, 에지 등)를 가로지르는 셋업들에 대해 유용하다.
도 20은 실시예에 따른, 평판 관리 및 의도 기반 보안 메커니즘을 위한 방법(2000)을 도시하는 흐름도이다. (2002)에서, 위험 감수 의도 기반 SLA가 플랫폼의 보안 관리자에서 수신되고, 위험 감수 의도 기반 SLA는 플랫폼 상에서 실행되는 태스크와 관련된다. 위험 감수 의도 기반 SLA는 태스크 실행 동안 시행할 하나 이상의 SLO를 결정하기 위해 엔진에 의해 파싱될 수 있다.
(2004)에서, 실행 동안의 태스크의 분석이 수신된다. 분석은 환경 설정, 컨텍스트 설정, 동작 메트릭, 및 그와 유사한 것을 포함할 수 있다.
(2006)에서, 분석이 평가되어 보안 위협이 존재하는지를 식별한다.
(2008)에서, 보안 위협이 존재한다는 것을 식별한 것에 응답하여, 정책 데이터베이스에 액세스하여 응답 액션을 결정한다. 응답 액션은 태스크에 리소스 할당들을 추가 또는 제거하는 것, 태스크의 언어 레벨 격리를 개시하는 것, 태스크의 프로세스 레벨 격리를 개시하는 것, 태스크의 가상화를 개시하는 것, 신뢰된 실행 환경에서 태스크를 실행하는 것, 또는 전용 코어 상에서 태스크를 실행하는 것과 같은 다양한 동작들을 포함할 수 있다. 응답 액션은 태스크에 의한 통신을 보안 처리하기 위해 통신 보안 메커니즘을 구현하는 것을 포함할 수 있다. 응답 액션은 태스크에 의해 액세스되는 데이터를 암호화하는 것을 포함할 수 있다.
(2010)에서, 응답 액션이 개시된다. 이것은 리소스 할당 운영자, 오케스트레이터, 또는 그와 유사한 것에 의해 수행될 수 있다.
본 문서에 기술된 오케스트레이터 또는 오케스트레이션 시스템들은 기기, 엔드포인트 컴포넌트, 디바이스, 클라이언트 디바이스, 컴퓨팅 디바이스, 노드, 서버, 개별적으로 판매되고 상이한 시스템에 통합되는 독립형 노드 등에서 구현될 수 있다. 시스템 아키텍처는 임의의 설치에서 오케스트레이션 시스템을 구현할 수 있다.
실시예들은 하드웨어, 펌웨어 및 소프트웨어 중 하나 또는 조합으로 구현될 수 있다. 실시예들은 또한 본 명세서에서 설명된 동작을 수행하기 위해 적어도 하나의 프로세서에 의해 판독 및 실행될 수 있는 머신 판독가능 스토리지 디바이스 상에 저장된 명령어들로서 구현될 수 있다. 머신 판독가능 스토리지 디바이스는 머신(예컨대, 컴퓨터)에 의해 판독가능한 형식으로 정보를 저장하기 위한 임의의 비일시적인 메커니즘을 포함할 수 있다. 예를 들어, 컴퓨터 판독가능 스토리지 디바이스는 ROM(read-only memory), RAM(random-access memory), 자기 디스크 스토리지 매체, 광 스토리지 매체, 플래시 메모리(flash-memory) 디바이스들, 및 다른 스토리지 디바이스들 및 매체를 포함할 수 있다.
예들은, 본 명세서에 설명되는 바와 같이, 모듈들, IP(intellectual property) 블록들 또는 코어들, 엔진들, 또는 메커니즘들과 같은, 로직 또는 다수의 컴포넌트를 포함할 수 있거나, 또는 이들 상에서 동작할 수 있다. 이러한 로직 또는 컴포넌트들은 본 명세서에 설명된 동작들을 수행하기 위해 하나 이상의 프로세서에 통신가능하게 결합된 하드웨어, 소프트웨어 구성된 하드웨어, 또는 펌웨어일 수 있다. 로직 또는 컴포넌트들은 하드웨어 모듈들(예를 들어, IP 블록)일 수 있고, 이와 같이 특정된 동작들을 수행할 수 있는 유형의 엔티티들로 간주될 수 있고 특정 방식으로 구성되거나 배열될 수 있다. 예에서, 회로들은 IP 블록, IP 코어, SoC(system-on-chip), 또는 그와 유사한 것으로서 특정된 방식으로 (예를 들어, 내부적으로 또는 다른 회로들과 같은 외부 엔티티들에 대해) 배열될 수 있다.
예에서, 하나 이상의 컴퓨터 시스템(예를 들어, 독립적인, 클라이언트 또는 서버 컴퓨터 시스템) 또는 하나 이상의 하드웨어 프로세서의 전부 또는 일부는 특정된 동작들을 수행하도록 동작하는 모듈로서 펌웨어 또는 소프트웨어(예를 들어, 명령러들, 애플리케이션 부분, 또는 애플리케이션)에 의해 구성될 수 있다. 예에서, 소프트웨어는 머신 판독가능 매체 상에 상주할 수 있다. 예에서, 소프트웨어는, 모듈의 기반 하드웨어에 의해 실행될 때, 하드웨어가 특정된 동작들을 수행하도록 야기한다. 따라서, 용어 하드웨어 모듈은 유형의 엔티티를 포괄하며, 특정 방식으로 동작하거나, 또는 본 명세서에서 설명된 임의의 동작의 일부 또는 전부를 수행하도록 물리적으로 구성되거나, 구체적으로 구성되거나(예를 들어, 하드와이어링되거나), 또는 임시로(예를 들어, 일시적으로) 구성되는 (예를 들어, 프로그래밍되는) 엔티티인 것으로 이해된다.
모듈들이 임시로 구성되는 예들을 고려하면, 모듈들 각각이 시간 상 임의의 한 순간에 인스턴트화될 필요는 없다. 예를 들어, 모듈들이 소프트웨어를 사용하여 구성된 범용 하드웨어 프로세서를 포함하는 경우에; 범용 하드웨어 프로세서는 상이한 시간들에 각자의 상이한 모듈들로서 구성될 수 있다. 따라서, 소프트웨어는, 예를 들어, 하나의 시간 인스턴스에서 특정 모듈을 구성하고, 상이한 시간 인스턴스에서 상이한 모듈을 구성하도록 하드웨어 프로세서를 구성할 수 있다. 모듈들은 또한 소프트웨어 또는 펌웨어 모듈들일 수 있으며, 이것들은 본 명세서에서 설명된 방법론들을 수행하도록 동작한다.
IP 블록(IP 코어라고도 지칭됨)은 로직, 셀, 또는 집적 회로의 재사용가능 유닛이다. IP 블록은 FPGA(field programmable gate array), ASIC(application-specific integrated circuit), PLD(programmable logic device), SoC(system on a chip), 또는 그와 유사한 것의 일부로서 사용될 수 있다. 그것은 디지털 신호 처리 또는 이미지 처리와 같은 특정 목적을 위해 구성될 수 있다. 예시적인 IP 코어들은 CPU(central processing unit) 코어들, 통합된 그래픽들, 보안, 입력/출력(I/O) 제어, 시스템 에이전트, GPU(graphics processing unit), 인공 지능, 신경 프로세서들, 이미지 처리 유닛, 통신 인터페이스들, 메모리 컨트롤러, 주변 디바이스 제어, 플랫폼 컨트롤러 허브, 또는 그와 유사한 것을 포함한다.
추가적인 유의사항들 & 예들:
예 1은 의도 주도 보안 메커니즘들을 구현하는 시스템이고, 이 시스템은: 프로세서; 및 명령어들을 저장하는 메모리를 포함하고, 명령어들은, 프로세서에 의해 실행될 때, 시스템으로 하여금: 컴퓨팅 노드 상에서의 애플리케이션의 실행에 관련된 위험 감수 의도에 기초하여, 소프트웨어 구현된 운영자의 실행이 신뢰 평가를 요구하는지를 결정하고; 및 소프트웨어 구현된 운영자가 신뢰 평가를 요구한다는 결정에 응답하여: 소프트웨어 구현된 운영자의 평판 점수를 획득하고; 위험 감수 의도로부터 최소 평판 점수를 결정하고; 소프트웨어 구현된 운영자의 평판 점수를 최소 평판 점수와 비교하고; 및 비교에 기초하여 소프트웨어 구현된 운영자의 실행을 거절 또는 허용하게 야기한다.
예 2에서, 예 1의 주제는, 평판 점수가 소프트웨어 구현된 운영자의 배치 후의 후속 장애들의 수에 기초하는 것을 포함한다.
예 3에서, 예 1 또는 예 2의 주제는, 평판 점수가 소프트웨어 구현된 운영자에 의해 야기되는 서비스 메시 중단을 나타내는 텔레메트리에 기초하는 것을 포함한다.
예 4에서, 예들 1-3의 주제는, 평판 점수가 소프트웨어 구현된 운영자에 의해 야기되는 애플리케이션 SLA(service level agreement) 위반에 기초하는 것을 포함한다.
예 5에서, 예들 1-4의 주제는, 평판 점수가 소프트웨어 구현된 운영자에 의해 야기되는 라이프 사이클 이벤트들의 수에 기초하는 것을 포함한다.
예 6에서, 예들 1-5의 주제는, 평판 점수가 소프트웨어 구현된 운영자에 의해 야기되는 보안 위반들의 수에 기초하는 것을 포함한다.
예 7에서, 예들 1-6의 주제는, 시스템이 소프트웨어 구현된 운영자의 실행을 모니터링하고; 및 실행 결과를 예상된 실행 결과에 대해 체크하는 것을 포함한다.
예 8에서, 예 7의 주제는, 실행 결과가 계산 노드에 의해 증명되는 것을 포함한다.
예 9에서, 예 7 또는 예 8의 주제는, 시스템이 실행 결과를 블록체인에 저장하는 것을 포함한다.
예 10에서, 예 9의 주제는, 시스템이 실행 결과에 기초하여 수정된 평판 점수를 계산하고; 및 수정된 평판 점수를 블록체인에 저장하는 것을 포함한다.
예 11에서, 예 10의 주제는, 수정된 평판 점수를 계산하기 위해, 시스템이 소프트웨어 구현된 운영자의 이력 운영, 소프트웨어 구현된 운영자의 소스, 또는 소프트웨어 구현된 운영자가 실행한 컴퓨팅 노드를 평가하는 것을 포함한다.
예 12에서, 예들 1-11의 주제는, 시스템이 분석에 기초하여 태스크가 보안 위험에 의해 위협되는지를 결정하고; 및 위험 감수 의도와 부합하는 응답 액션을 개시하는 것을 포함한다.
예 13은 의도 주도 보안 메커니즘들을 구현하기 위한 방법이며, 방법은: 컴퓨팅 노드 상의 애플리케이션의 실행과 관련된 위험 감수 의도에 기초하여, 소프트웨어 구현된 운영자의 실행이 신뢰 평가를 요구하는지를 결정하는 단계; 및 소프트웨어 구현된 운영자가 신뢰 평가를 요구한다는 결정에 응답하여: 소프트웨어 구현된 운영자의 평판 점수를 획득하는 단계; 위험 감수 의도로부터 최소 평판 점수를 결정하는 단계; 소프트웨어 구현된 운영자의 평판 점수를 최소 평판 점수와 비교하는 단계; 및 비교에 기초하여 소프트웨어 구현된 운영자의 실행을 거절하거나 허용하는 단계를 포함한다.
예 14에서, 예 13의 주제는, 평판 점수가 소프트웨어 구현된 운영자의 배치 이후의 후속 장애들의 수에 기초하는 것을 포함한다.
예 15에서, 예 13 또는 예 14의 주제는, 평판 점수가 소프트웨어 구현된 운영자에 의해 야기되는 서비스 메시 중단을 나타내는 텔레메트리에 기초하는 것을 포함한다
예 16에서, 예들 13-15의 주제는, 평판 점수가 소프트웨어 구현된 운영자에 의해 야기되는 애플리케이션 SLA(service level agreement) 위반에 기초하는 것을 포함한다.
예 17에서, 예들 13-16의 주제는, 평판 점수가 소프트웨어 구현된 운영자에 의해 야기되는 라이프 사이클 이벤트들의 수에 기초하는 것을 포함한다.
예 18에서, 예들 13-17의 주제는, 평판 점수가 소프트웨어 구현된 운영자에 의해 야기되는 보안 위반들의 수에 기초하는 것을 포함한다.
예 19에서, 예들 13-18의 주제는, 소프트웨어 구현된 운영자의 실행을 모니터링하는 단계; 및 실행 결과를 예상된 실행 결과에 대해 체크하는 단계를 포함한다.
예 20에서, 예 19의 주제는, 실행 결과가 컴퓨팅 노드에 의해 증명되는 것을 포함한다.
예 21에서, 예 19 또는 예 20의 주제는 실행 결과를 블록체인에 저장하는 단계를 포함한다.
예 22에서, 예 21의 주제는, 실행 결과에 기초하여 수정된 평판 점수를 계산하는 단계; 및 수정된 평판 점수를 블록체인에 저장하는 단계를 포함한다.
예 23에서, 예 22의 주제는, 수정된 평판 점수를 계산하는 단계가, 소프트웨어 구현된 운영자의 이력 운영, 소프트웨어 구현된 운영자의 소스, 또는 소프트웨어 구현된 운영자가 실행한 컴퓨팅 노드를 평가하는 단계를 포함하는 것을 포함한다.
예 24에서, 예들 13-23의 주제는, 분석에 기초하여 태스크가 보안 위험에 의해 위협되는지를 결정하는 단계; 및 위험 감수 의도와 부합하는 응답 액션을 개시하는 단계를 포함한다.
예 25는, 머신에 의해 실행될 때, 머신으로 하여금, 예들 13-24의 방법들 중 임의의 것의 동작들을 수행하게 야기하는 명령어들을 포함하는 적어도 하나의 머신 판독가능 매체이다.
예 26은 예들 13-24의 방법들 중 임의의 것을 수행하기 위한 수단을 포함하는 장치이다.
예 27은 의도 주도 보안 메커니즘들(intent-driven security mechanisms)을 구현하기 위한 명령어들을 포함하는 적어도 하나의 머신 판독가능 매체이고, 명령어들은, 머신에 의해 실행될 때, 머신으로 하여금 동작들을 수행하게 하고, 동작들은: 컴퓨팅 노드 상에서의 애플리케이션의 실행에 관련된 위험 감수 의도(risk tolerance intent)에 기초하여, 소프트웨어 구현된 운영자의 실행이 신뢰 평가를 요구하는지를 결정하는 동작; 및 소프트웨어 구현된 운영자가 신뢰 평가를 요구한다는 결정에 응답하여: 소프트웨어 구현된 운영자의 평판 점수를 획득하는 동작; 위험 감수 의도로부터 최소 평판 점수를 결정하는 동작; 소프트웨어 구현된 운영자의 평판 점수를 최소 평판 점수와 비교하는 동작; 및 비교에 기초하여 소프트웨어 구현된 운영자의 실행을 거절하거나 허용하는 동작을 포함한다.
예 28에서, 예 27의 주제는, 평판 점수가 소프트웨어 구현된 운영자의 배치 이후의 후속 장애들의 수에 기초하는 것을 포함한다.
예 29에서, 예 27 또는 예 28의 주제는, 평판 점수가 소프트웨어 구현된 운영자에 의해 야기되는 서비스 메시 중단을 나타내는 텔레메트리에 기초하는 것을 포함한다.
예 30에서, 예들 27-29의 주제는, 평판 점수가 소프트웨어 구현된 운영자에 의해 야기되는 애플리케이션 SLA(service level agreement) 위반에 기초하는 것을 포함한다.
예 31에서, 예들 27-30의 주제는, 평판 점수가 소프트웨어 구현된 운영자에 의해 야기되는 라이프 사이클 이벤트들의 수에 기초하는 것을 포함한다.
예 32에서, 예들 27-31의 주제는, 평판 점수가 소프트웨어 구현된 운영자에 의해 야기되는 보안 위반들의 수에 기초하는 것을 포함한다.
예 33에서, 예들 27-32의 주제는, 소프트웨어 구현된 운영자의 실행을 모니터링하고; 및 실행 결과를 예상된 실행 결과에 대해 체크하기 위한 명령어들을 포함한다.
예 34에서, 예 33의 주제는, 실행 결과가 컴퓨팅 노드에 의해 증명되는 것을 포함한다.
예 35에서, 예 33 또는 예 34의 주제는, 실행 결과를 블록체인에 저장하는 것을 포함한다.
예 36에서, 예 35의 주제는, 실행 결과에 기초하여 개정된 평판 점수를 계산하고; 및 수정된 평판 점수를 블록체인에 저장하기 위한 명령어들을 포함한다.
예 37에서, 예 36의 주제는, 수정된 평판 점수를 계산하는 것은 소프트웨어 구현된 운영자의 이력 운영, 소프트웨어 구현된 운영자의 소스, 또는 소프트웨어 구현된 운영자가 실행한 컴퓨팅 노드를 평가하는 것을 포함하는 것을 포함한다.
예 38에서, 예들 27-37의 주제는, 분석에 기초하여 태스크가 보안 위험에 의해 위협되는지를 결정하고; 및 위험 감수 의도와 부합하는 응답 액션을 개시하기 위한 명령어들을 포함한다.
예 39는 의도 주도 보안 메커니즘들(intent-driven security mechanisms)을 구현하기 위한 장치이며, 장치는: 컴퓨팅 노드 상에서의 애플리케이션의 실행에 관련된 위험 감수 의도(risk tolerance intent)에 기초하여, 소프트웨어 구현된 운영자의 실행이 신뢰 평가를 요구하는지를 결정하기 위한 수단; 및 소프트웨어 구현된 운영자가 신뢰 평가를 요구한다는 결정에 응답하여: 소프트웨어 구현된 운영자의 평판 점수를 획득하기 위한 수단; 위험 감수 의도로부터 최소 평판 점수를 결정하기 위한 수단; 소프트웨어 구현된 운영자의 평판 점수를 최소 평판 점수와 비교하기 위한 수단; 및 비교에 기초하여 소프트웨어 구현된 운영자의 실행을 거부하거나 허용하기 위한 수단을 포함한다.
예 40에서, 예 39의 주제는, 평판 점수가 소프트웨어 구현된 운영자의 배치 후의 후속 장애들의 수에 기초하는 것을 포함한다.
예 41에서, 예 39 또는 예40의 주제는, 평판 점수가 소프트웨어 구현된 운영자에 의해 야기되는 서비스 메시 중단을 나타내는 텔레메트리에 기초하는 것을 포함한다.
예 42에서, 예들 39-41의 주제는, 평판 점수가 소프트웨어 구현된 운영자에 의해 야기되는 애플리케이션 SLA(service level agreement) 위반에 기초하는 것을 포함한다.
예 43에서, 예들 39-42의 주제는, 평판 점수가 소프트웨어 구현된 운영자에 의해 야기되는 라이프 사이클 이벤트들의 수에 기초하는 것을 포함한다.
예 44에서, 예들 39-43의 주제는, 평판 점수가 소프트웨어 구현된 운영자에 의해 야기되는 보안 위반들의 수에 기초하는 것을 포함한다.
예 45에서, 예들 39-44의 주제는, 소프트웨어 구현된 운영자의 실행을 모니터링하기 위한 수단; 및 실행 결과를 예상된 실행 결과에 대해 체크하기 위한 수단을 포함한다.
예 46에서, 예 45의 주제는, 실행 결과가 컴퓨팅 노드에 의해 증명되는 것을 포함한다.
예 47에서, 예 45 또는 예 46의 주제는 실행 결과를 블록체인에 저장하는 것을 포함한다.
예 48에서, 예 47의 주제는, 실행 결과에 기초하여 수정된 평판 점수를 계산하기 위한 수단; 및 수정된 평판 점수를 블록체인에 저장하기 위한 수단을 포함한다.
예 49에서, 예 48의 주제는, 수정된 평판 점수를 계산하는 것은 소프트웨어 구현된 운영자의 이력 운영, 소프트웨어 구현된 운영자의 소스, 또는 소프트웨어 구현된 운영자가 실행한 컴퓨팅 노드를 평가하는 것을 포함하는 것을 포함한다.
예 50에서, 예들 39-49의 주제는, 분석에 기초하여 태스크가 보안 위험에 의해 위협되는지를 결정하기 위한 수단; 및 위험 감수 의도와 부합하는 응답 액션을 개시하기 위한 수단을 포함한다.
예 51은, 처리 회로에 의해 실행될 때, 처리 회로로 하여금 예 1 내지 예 50 중 임의의 것을 구현하는 동작들을 수행하게 야기하는 명령어들을 포함하는 적어도 하나의 머신 판독가능 매체이다.
예 52는 예 1 내지 예 50 중 임의의 것을 구현하는 수단을 포함하는 장치이다.
예 53은 예 1 내지 예 50 중 임의의 것을 구현하는 시스템이다.
예 54는 예 1 내지 예 50 중 임의의 것을 구현하는 방법이다.
위의 상세한 설명은 상세한 설명의 일부를 형성하는 첨부 도면들에 대한 참조들을 포함한다. 도면들은, 예시로서, 실시될 수 있는 특정 실시예들을 보여준다. 이러한 실시예들은 본 명세서에서 "예들(examples)"이라고 또한 지칭된다. 이러한 예들은 도시되거나 설명된 것 이외의 요소들을 포함할 수 있다. 그러나, 도시되거나 설명되는 요소들을 포함하는 예들이 또한 고려된다. 더욱이, 특정한 예(또는 그의 하나 이상의 양태)에 관련하여, 또는 본 명세서에 도시되거나 설명된 다른 예들(또는 그의 하나 이상의 양태)에 관련하여, 도시되거나 설명된 해당 요소들(또는 그의 하나 이상의 양태)의 임의의 조합 또는 치환을 사용하는 예들이 또한 고려된다.
본 문서에서 참조되는 간행물, 특허, 및 특허 문서는, 참조 문헌으로서 개별적으로 포함되기나 한 것처럼, 그 전체가 참조 문헌으로서 본 명세서에 포함된다. 이 문서와 참조로 그렇게 포함된 문서들 사이의 불일치한 사용들의 경우에, 포함된 참조문헌(들)에서의 사용은 이 문서의 사용에 대해 보충적이다; 양립할 수 없는 불일치들에 대해서는, 이 문서에서의 사용이 우선한다.
이 문서에서, "하나(a 또는 an)"라는 용어는, 특허 문헌들에서 흔한 것처럼, "적어도 하나" 또는 "하나 이상"의 임의의 다른 경우들 또는 사용들에 독립적인, 하나 또는 하나보다 많은 것을 포함하기 위해 사용된다. 이 문서에서, 용어 "또는"은, 달리 표시되지 않는 한, "A 또는 B"가 "B가 아닌 A", "A가 아닌 B", 및 "A 및 B"를 포함하도록, 비배타적 또는을 지칭하기 위해 사용된다. 첨부된 청구범위에서, 용어 "포함하는(including)" 및 "여기서(in which)"는 각자의 용어 "포함하는(comprising)" 및 "여기서(wherein)"의 평이한 동등어(plain-English equivalents)로서 사용된다. 또한, 다음의 청구항들에서, 용어 "포함하는(including)" 및 "포함하는(comprising)"은 개방적인데(open-ended), 즉, 청구항에서 그러한 용어 이후에 나열된 것들에 추가하여 요소들을 포함하는 시스템, 디바이스, 물품, 또는 프로세스는 여전히 그 청구항의 범위 내에 드는 것으로 간주된다. 더욱이, 다음의 청구항들에서, "제1(first)", "제2(second)", 및 "제3(third)" 등의 용어들은 단지 레이블들로서 사용되고, 그것들의 대상들에 수치적 순서를 제안하려고 의도되는 것은 아니다.
이상의 설명은 제한이 아니라 예시를 위한 것이다. 예를 들어, 위에 설명된 예들(또는 그의 하나 이상의 양태)은 다른 것들과 조합되어 사용될 수 있다. 다른 실시예들이, 위의 설명의 검토시에 본 기술분야의 통상의 기술자에 의해 그런 것처럼 사용될 수 있다. 요약서는 독자가 기술적 개시내용의 본질을 신속하게 확인하게 하는 것이다. 그것이 청구항들의 범위 또는 의미를 해석하거나 제한하는 데 이용되지는 않을 것이라는 이해 하에서 제출된다. 또한, 위의 상세한 설명에서, 본 개시내용을 간소화하기 위해 다양한 특징들이 함께 그룹화될 수 있다. 그러나, 실시예들이 상기 특징들의 서브세트를 특징으로 할 수 있기 때문에, 청구항들은 본 명세서에 개시된 모든 특징을 제시하지 않을 수 있다. 또한, 실시예들은 특정 예에서 개시되는 것보다 더 적은 특징들을 포함할 수 있다. 따라서, 이하의 청구항들은 이에 의해 상세한 설명에 포함되고, 청구항은 그 자체로 별도의 실시예로서 성립한다. 본 명세서에 개시되는 실시예들의 범위는, 첨부된 청구항들에 부여되는 등가물들의 전체 범위와 함께, 이러한 청구항들을 참조하여 결정되어야 한다.

Claims (25)

  1. 의도 주도 보안 메커니즘들(intent-driven security mechanisms)을 구현하는 시스템으로서:
    프로세서; 및
    명령어들을 저장하는 메모리를 포함하고, 상기 명령어들은, 상기 프로세서에 의해 실행될 때, 상기 시스템으로 하여금:
    컴퓨팅 노드 상에서의 애플리케이션의 실행과 관련된 위험 감수 의도(risk tolerance intent)에 기초하여, 소프트웨어 구현된 운영자의 실행이 신뢰 평가를 요구하는지를 결정하고; 및
    상기 소프트웨어 구현된 운영자가 상기 신뢰 평가를 요구한다는 결정에 응답하여:
    상기 소프트웨어 구현된 운영자의 평판 점수를 획득하고;
    상기 위험 감수 의도로부터 최소 평판 점수를 결정하고;
    상기 소프트웨어 구현된 운영자의 평판 점수를 상기 최소 평판 점수와 비교하고; 및
    상기 비교에 기초하여 상기 소프트웨어 구현된 운영자의 실행을 거절 또는 허용하도록 야기하는 시스템.
  2. 제1항에 있어서, 상기 평판 점수는 상기 소프트웨어 구현된 운영자의 배치 이후의 후속 장애들의 수에 기초하는 시스템.
  3. 제1항에 있어서, 상기 평판 점수는 상기 소프트웨어 구현된 운영자에 의해 야기되는 서비스 메시 중단을 나타내는 텔레메트리에 기초하는 시스템.
  4. 제1항에 있어서, 상기 평판 점수는 상기 소프트웨어 구현된 운영자에 의해 야기되는 애플리케이션 SLA(service level agreement) 위반에 기초하는 시스템.
  5. 제1항에 있어서, 상기 평판 점수는 상기 소프트웨어 구현된 운영자에 의해 야기되는 라이프 사이클 이벤트들의 수에 기초하는 시스템.
  6. 제1항에 있어서, 상기 평판 점수는 상기 소프트웨어 구현된 운영자에 의해 야기되는 보안 위반들의 수에 기초하는 시스템.
  7. 제1항 내지 제6항 중 어느 한 항에 있어서, 상기 시스템은:
    상기 소프트웨어 구현된 운영자의 실행을 모니터링하고; 및
    실행 결과를 예상된 실행 결과에 대해 체크하는 시스템.
  8. 제7항에 있어서, 상기 실행 결과는 상기 컴퓨팅 노드에 의해 증명되는 시스템.
  9. 제7항에 있어서, 상기 시스템은 상기 실행 결과를 블록체인에 저장하는 시스템.
  10. 제9항에 있어서, 상기 시스템은:
    상기 실행 결과에 기초하여 수정된 평판 점수를 계산하고; 및
    상기 수정된 평판 점수를 상기 블록체인에 저장하는 시스템.
  11. 제10항에 있어서, 상기 수정된 평판 점수를 계산하기 위해, 상기 시스템은 상기 소프트웨어 구현된 운영자의 이력 운영, 상기 소프트웨어 구현된 운영자의 소스, 또는 상기 소프트웨어 구현된 운영자가 실행한 상기 컴퓨팅 노드를 평가하는 시스템.
  12. 제1항 내지 제6항 중 어느 한 항에 있어서, 상기 시스템은:
    분석에 기초하여 태스크가 보안 위험에 의해 위협되는지를 결정하고; 및
    상기 위험 감수 의도와 부합하는 응답 액션을 개시하는 시스템.
  13. 의도 주도 보안 메커니즘들을 구현하는 방법으로서:
    컴퓨팅 노드 상에서의 애플리케이션의 실행과 관련된 위험 감수 의도에 기초하여, 소프트웨어 구현된 운영자의 실행이 신뢰 평가를 요구하는지를 결정하는 단계; 및
    상기 소프트웨어 구현된 운영자가 상기 신뢰 평가를 요구한다는 결정에 응답하여:
    상기 소프트웨어 구현된 운영자의 평판 점수를 획득하는 단계;
    위험 감수 의도로부터 최소 평판 점수를 결정하는 단계;
    소프트웨어 구현된 운영자의 평판 점수를 최소 평판 점수와 비교하는 단계; 및
    상기 비교에 기초하여 상기 소프트웨어 구현된 운영자의 실행을 거절하거나 허용하는 단계를 포함하는 방법.
  14. 제13항에 있어서, 상기 평판 점수는 상기 소프트웨어 구현된 운영자의 배치 이후의 후속 장애들의 수에 기초하는 방법.
  15. 제13항에 있어서, 상기 평판 점수는 상기 소프트웨어 구현된 운영자에 의해 야기되는 서비스 메시 중단을 나타내는 텔레메트리에 기초하는 방법.
  16. 제13항에 있어서, 상기 평판 점수는 상기 소프트웨어 구현된 운영자에 의해 야기되는 애플리케이션 SLA(service level agreement) 위반에 기초하는 방법.
  17. 제13항에 있어서, 상기 평판 점수는 상기 소프트웨어 구현된 운영자에 의해 야기되는 라이프 사이클 이벤트들의 수에 기초하는 방법.
  18. 제13항에 있어서, 상기 평판 점수는 상기 소프트웨어 구현된 운영자에 의해 야기되는 보안 위반들의 수에 기초하는 방법.
  19. 제13항 내지 제18항 중 어느 한 항에 있어서,
    상기 소프트웨어 구현된 운영자의 실행을 모니터링하는 단계; 및
    실행 결과를 예상된 실행 결과에 대해 체크하는 단계를 포함하는 방법.
  20. 제19항에 있어서, 상기 실행 결과는 상기 컴퓨팅 노드에 의해 증명되는 방법.
  21. 제19항에 있어서, 상기 실행 결과를 블록체인에 저장하는 단계를 포함하는 방법.
  22. 제21항에 있어서,
    상기 실행 결과에 기초하여 수정된 평판 점수를 계산하는 단계; 및
    상기 수정된 평판 점수를 상기 블록체인에 저장하는 단계를 포함하는 방법.
  23. 제22항에 있어서, 상기 수정된 평판 점수를 계산하는 단계는 상기 소프트웨어 구현된 운영자의 이력 운영, 상기 소프트웨어 구현된 운영자의 소스, 또는 상기 소프트웨어 구현된 운영자가 실행한 상기 컴퓨팅 노드를 평가하는 단계를 포함하는 방법.
  24. 의도 주도 보안 메커니즘들을 구현하기 위한 명령어들을 포함하는 적어도 하나의 머신 판독가능 매체로서, 상기 명령어들은, 머신에 의해 실행될 때, 상기 머신으로 하여금 동작들을 수행하게 야기하고, 상기 동작들은:
    컴퓨팅 노드 상에서의 애플리케이션의 실행과 관련된 위험 감수 의도에 기초하여, 소프트웨어 구현된 운영자의 실행이 신뢰 평가를 요구하는지를 결정하는 동작; 및
    상기 소프트웨어 구현된 운영자가 상기 신뢰 평가를 요구한다는 결정에 응답하여:
    상기 소프트웨어 구현된 운영자의 평판 점수를 획득하는 동작;
    상기 위험 감수 의도로부터 최소 평판 점수를 결정하는 동작;
    상기 소프트웨어 구현된 운영자의 평판 점수를 상기 최소 평판 점수와 비교하는 동작; 및
    상기 비교에 기초하여 상기 소프트웨어 구현된 운영자의 실행을 거절하거나 허용하는 동작을 포함하는 적어도 하나의 머신 판독가능 매체.
  25. 의도 주도 보안 메커니즘들을 구현하는 장치로서:
    컴퓨팅 노드 상에서의 애플리케이션의 실행과 관련된 위험 감수 의도에 기초하여, 소프트웨어 구현된 운영자의 실행이 신뢰 평가를 요구하는지를 결정하기 위한 수단; 및
    상기 소프트웨어 구현된 운영자가 상기 신뢰 평가를 요구한다는 결정에 응답하여:
    상기 소프트웨어 구현된 운영자의 평판 점수를 획득하기 위한 수단;
    상기 위험 감수 의도로부터 최소 평판 점수를 결정하기 위한 수단;
    상기 소프트웨어 구현된 운영자의 평판 점수를 상기 최소 평판 점수와 비교하기 위한 수단; 및
    상기 비교에 기초하여 상기 소프트웨어 구현된 운영자의 실행을 거부하거나 허용하기 위한 수단을 포함하는 장치.
KR1020220132147A 2021-11-16 2022-10-14 평판 관리 및 의도 기반 보안 메커니즘 KR20230073372A (ko)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US202163280001P 2021-11-16 2021-11-16
US63/280,001 2021-11-16
US17/561,134 2021-12-23
US17/561,134 US20220114251A1 (en) 2021-11-16 2021-12-23 Reputation management and intent-based security mechanisms

Publications (1)

Publication Number Publication Date
KR20230073372A true KR20230073372A (ko) 2023-05-25

Family

ID=80122872

Family Applications (2)

Application Number Title Priority Date Filing Date
KR1020220132131A KR20230073371A (ko) 2021-11-16 2022-10-14 Faas(function-as-a-service) 아키텍처에서의 계산 스토리지
KR1020220132147A KR20230073372A (ko) 2021-11-16 2022-10-14 평판 관리 및 의도 기반 보안 메커니즘

Family Applications Before (1)

Application Number Title Priority Date Filing Date
KR1020220132131A KR20230073371A (ko) 2021-11-16 2022-10-14 Faas(function-as-a-service) 아키텍처에서의 계산 스토리지

Country Status (5)

Country Link
US (6) US20220113790A1 (ko)
KR (2) KR20230073371A (ko)
CN (1) CN117501246A (ko)
DE (2) DE102022212115A1 (ko)
WO (1) WO2023091036A1 (ko)

Families Citing this family (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020091573A1 (ko) * 2018-11-02 2020-05-07 엘지전자 주식회사 방송 송신 장치, 방송 송신 방법, 방송 수신 장치 및 방송 수신 방법
US11966788B2 (en) * 2019-06-12 2024-04-23 Snyk Limited Predictive autoscaling and resource optimization
CN110618871B (zh) * 2019-09-21 2022-07-22 苏州浪潮智能科技有限公司 一种fpga云平台加速资源的分配方法与系统
US11544113B2 (en) * 2019-11-20 2023-01-03 Google Llc Task scheduling for machine-learning workloads
EP4078363B1 (en) * 2019-12-19 2024-05-01 Koninklijke Philips N.V. Dynamic personalized platform generation based on on-the-fly requirements
US11570638B2 (en) * 2020-06-26 2023-01-31 Intel Corporation Automated network control systems that adapt network configurations based on the local network environment
US11770377B1 (en) * 2020-06-29 2023-09-26 Cyral Inc. Non-in line data monitoring and security services
EP4193302A1 (en) * 2020-08-05 2023-06-14 Avesha, Inc. Performing load balancing self adjustment within an application environment
US20210081271A1 (en) * 2020-09-25 2021-03-18 Intel Corporation Dynamic tracing control
US11671484B2 (en) * 2020-09-25 2023-06-06 Verizon Patent And Licensing Inc. Methods and systems for orchestrating a distributed computing service based on latency performance levels
US11972193B1 (en) * 2020-10-01 2024-04-30 Synopsys, Inc. Automatic elastic CPU for physical verification
KR102650892B1 (ko) * 2021-04-12 2024-03-26 한국전자통신연구원 지역적으로 분산된 다중 클라우드 환경에서의 컨테이너 오케스트레이션 장치 및 이를 이용한 방법
WO2022235651A1 (en) 2021-05-03 2022-11-10 Avesha, Inc. Distributed computing system with multi tenancy based on application slices
US11916951B2 (en) * 2021-06-14 2024-02-27 Jamf Software, Llc Mobile device management for detecting and remediating common vulnerabilities and exposures
US11726894B2 (en) * 2021-08-12 2023-08-15 Sap Se Runtime entropy-based software operators
US11575696B1 (en) 2021-09-20 2023-02-07 Normalyze, Inc. Cloud data attack detection based on cloud security posture and resource network path tracing
US11971990B2 (en) 2022-01-13 2024-04-30 Dell Products L.P. System and method for container validation
US20230222045A1 (en) * 2022-01-13 2023-07-13 Dell Products L.P. System and method for enhanced container deployment
US20220245903A1 (en) * 2022-03-14 2022-08-04 Facebook Technologies, Llc Selective Offload of Workloads to Edge Devices
US11880950B2 (en) * 2022-03-14 2024-01-23 Meta Platforms Technologies, Llc Selective offload of workloads to edge devices
US11743108B1 (en) * 2022-03-15 2023-08-29 Cisco Technology, Inc. Dynamic customization of network controller data path based on controller internal state awareness
US20230344714A1 (en) * 2022-04-22 2023-10-26 Microsoft Technology Licensing, Llc Global intent-based configuration to local intent targets
US11989200B2 (en) * 2022-05-25 2024-05-21 Nutanix, Inc. System and method for lambda buckets
US11853176B1 (en) * 2022-06-09 2023-12-26 Sap Se Service-compatible fault tolerance and acclimation
US20230409307A1 (en) * 2022-06-15 2023-12-21 Harness Inc. Automatic progressive rollout of software update
WO2023247042A1 (en) * 2022-06-23 2023-12-28 Telefonaktiebolaget Lm Ericsson (Publ) Detection of host container monitoring
US11886864B1 (en) * 2022-07-18 2024-01-30 International Business Machines Corporation Enhanced edge application deployment and processing in a network
US11915059B2 (en) * 2022-07-27 2024-02-27 Oracle International Corporation Virtual edge devices
CN115412609B (zh) * 2022-08-16 2023-07-28 中国联合网络通信集团有限公司 一种业务处理方法、装置、服务器及存储介质
US11863404B1 (en) * 2022-08-23 2024-01-02 Verizon Patent And Licensing Inc. Systems and methods for calculating optimum customer access paths for applications provided by multi-cloud providers through private networks
CN117724764A (zh) * 2022-09-09 2024-03-19 达发科技(苏州)有限公司 网络处理单元的算法分析方法及装置和存储介质
US11929891B1 (en) * 2023-01-10 2024-03-12 Dell Products L.P. System and method for distributed management of hardware through relationship management
US11907230B1 (en) 2023-01-10 2024-02-20 Dell Products L.P. System and method for distributed management of hardware based on intent
US11874934B1 (en) 2023-01-19 2024-01-16 Citibank, N.A. Providing user-induced variable identification of end-to-end computing system security impact information systems and methods
US11748491B1 (en) * 2023-01-19 2023-09-05 Citibank, N.A. Determining platform-specific end-to-end security vulnerabilities for a software application via a graphical user interface (GUI) systems and methods
US11763006B1 (en) * 2023-01-19 2023-09-19 Citibank, N.A. Comparative real-time end-to-end security vulnerabilities determination and visualization
CN116467068B (zh) * 2023-03-14 2024-06-18 浙江大学 资源调度方法、设备及存储介质
US12009974B1 (en) * 2023-05-05 2024-06-11 Dish Wireless L.L.C. Self-optimizing networks
US12001312B1 (en) * 2023-07-26 2024-06-04 Dell Products L.P. Data center monitoring and management operation for provisioning a data center asset using unstructured data
CN117349034B (zh) * 2023-12-05 2024-02-23 创意信息技术股份有限公司 一种大语言模型分层加载方法及装置

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09179235A (ja) 1995-12-27 1997-07-11 Konica Corp ハロゲン化銀写真感光材料及びその処理方法
US11824784B2 (en) * 2019-12-20 2023-11-21 Intel Corporation Automated platform resource management in edge computing environments
CN112073531B (zh) * 2020-09-15 2021-10-19 常熟理工学院 一种基于边缘计算的物联网实时监测系统的实现方法
US20210014133A1 (en) * 2020-09-25 2021-01-14 Intel Corporation Methods and apparatus to coordinate edge platforms

Also Published As

Publication number Publication date
US20220114251A1 (en) 2022-04-14
US20220121455A1 (en) 2022-04-21
US20220113790A1 (en) 2022-04-14
WO2023091036A1 (en) 2023-05-25
US20220124009A1 (en) 2022-04-21
US20220124005A1 (en) 2022-04-21
DE102022212115A1 (de) 2023-05-17
DE102022212157A1 (de) 2023-05-17
KR20230073371A (ko) 2023-05-25
CN117501246A (zh) 2024-02-02
US20220116455A1 (en) 2022-04-14

Similar Documents

Publication Publication Date Title
US20220114251A1 (en) Reputation management and intent-based security mechanisms
EP3975476A1 (en) Trust-based orchestration of an edge node
EP3998720A2 (en) Orchestrator execution planning using a distributed ledger
US20230086899A1 (en) Unlicensed spectrum harvesting with collaborative spectrum sensing in next generation networks
US20210011823A1 (en) Continuous testing, integration, and deployment management for edge computing
US20210328933A1 (en) Network flow-based hardware allocation
NL2033580B1 (en) End-to-end network slicing (ens) from ran to core network for nextgeneration (ng) communications
US20220014947A1 (en) Dynamic slice reconfiguration during fault-attack-failure-outage (fafo) events
EP4156651A1 (en) Content injection using a network appliance
US11996992B2 (en) Opportunistic placement of compute in an edge network
US20220012042A1 (en) Mechanism for secure and resilient configuration upgrades
US20230119552A1 (en) Resource management mechanisms for stateful serverless clusters in edge computing
NL2033544B1 (en) Methods and apparatus to implement edge scalable adaptive-grained monitoring and telemetry processing for multi-qos services
US20220231964A1 (en) Nondominant resource management for edge multi-tenant applications
US20230319141A1 (en) Consensus-based named function execution
US20230020732A1 (en) Adaptable sensor data collection
US20230014064A1 (en) Decentralized reputation management in a named-function network
WO2022271042A1 (en) Automated node configuration tuning in edge systems
NL2033285B1 (en) Intent-based orchestration in heterogenous compute platforms
EP4180958A1 (en) Computational storage in a function-as-a-service architecture
EP4180957A1 (en) Intent-driven power management
WO2024065816A1 (en) High fidelity attestation-based artificial intelligence inference system
US20230027152A1 (en) Upgrade of network objects using security islands
US20210119935A1 (en) Objective driven orchestration
US20210318911A1 (en) Distributed telemetry platform