KR102612312B1 - 전자 장치 및 이의 제어방법 - Google Patents

전자 장치 및 이의 제어방법 Download PDF

Info

Publication number
KR102612312B1
KR102612312B1 KR1020180134699A KR20180134699A KR102612312B1 KR 102612312 B1 KR102612312 B1 KR 102612312B1 KR 1020180134699 A KR1020180134699 A KR 1020180134699A KR 20180134699 A KR20180134699 A KR 20180134699A KR 102612312 B1 KR102612312 B1 KR 102612312B1
Authority
KR
South Korea
Prior art keywords
function
functions
service level
information
priority
Prior art date
Application number
KR1020180134699A
Other languages
English (en)
Other versions
KR20200054368A (ko
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 삼성전자주식회사
Priority to KR1020180134699A priority Critical patent/KR102612312B1/ko
Priority to US16/670,495 priority patent/US11095531B2/en
Priority to EP19883059.8A priority patent/EP3861443B1/en
Priority to PCT/KR2019/014684 priority patent/WO2020096282A1/en
Priority to CN201980083234.8A priority patent/CN113196238B/zh
Publication of KR20200054368A publication Critical patent/KR20200054368A/ko
Application granted granted Critical
Publication of KR102612312B1 publication Critical patent/KR102612312B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H04L41/5025—Ensuring fulfilment of SLA by proactively reacting to service quality change, e.g. by reconfiguration after service quality degradation or upgrade
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H04L41/5022—Ensuring fulfilment of SLA by giving priorities, e.g. assigning classes of service
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0866—Checking the configuration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/085—Retrieval of network configuration; Tracking network configuration history
    • H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/508—Network service management, e.g. ensuring proper service fulfilment according to agreements based on type of value added network service under agreement
    • H04L41/5096—Network service management, e.g. ensuring proper service fulfilment according to agreements based on type of value added network service under agreement wherein the managed service relates to distributed or central networked applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer And Data Communications (AREA)
  • Telephonic Communication Services (AREA)

Abstract

전자 장치가 개시된다. 본 전자 장치는, 통신부, 적어도 하나의 명령어를 저장하는 메모리 및 적어도 하나의 명령어를 실행하는 프로세서를 포함하며, 프로세서는, 통신부를 통해 함수의 실행 요청을 복수 개 수신하고, 복수 개의 요청에 대응하는 복수의 함수 각각에 대한 서비스 수준 계약(Service-Level Agreement(SLA))을 식별하며, 식별된 서비스 수준 계약을 바탕으로 복수의 함수에 우선순위를 결정하고, 결정된 우선순위에 따라 상기 복수의 함수를 실행한다.

Description

전자 장치 및 이의 제어방법 { ELECTRONIC APPARATUS AND CONTROLLING METHOD THEREOF }
본 개시는 전자 장치 및 그의 제어방법에 관한 것으로, 더욱 상세하게는 서버리스 컴퓨팅 시스템 환경에서 서비스 수준 계약(Service Level agreement)을 보장하기 위해, 함수에 대한 요청을 처리하는 순서를 조절하는 전자 장치 및 이의 제어방법에 대한 것이다.
최근 서버리스 컴퓨팅(Serverless Computing) 기술에 대한 관심이 높아지고 있었다. 서버리스 컴퓨팅이란, 클라우드 컴퓨팅(Cloud Computing) 실행 모델의 하나로, 개발자는 서버의 프로비저닝이나 운영을 신경 쓸 필요 없이, 애플리케이션의 소스 코드(또는 함수(Function))만 작성해서 등록하면 플랫폼이 알아서 해당 코드를 실행해주고, 결과를 반환해주는 시스템을 말한다.
서버리스 컴퓨팅이란 단어 자체로 보면 서버가 없다고 생각할 수 있지만 물리적으로 서버가 존재하지 않다는 것을 의미하지는 않는다. 서버리스 컴퓨팅은 이벤트 기반으로 필요할 때만 리소스를 사용하는 방식을 제공하는 것으로서, 해당 이벤트에 대해 별도로 할당된 전용 서버가 없다는 의미에서 서버리스라고 부른다.
서버리스 컴퓨팅은 동적으로 머신 자원의 할당을 관리한다. 가격은 미리 구매한 컴퓨팅 리소스의 용량 단위가 아닌 애플리케이션이 소비한 리소스의 실제 양에 기반하여 책정된다.
본 개시의 목적은 서버리스 컴퓨팅 시스템 환경에서 서비스 수준 계약(Service Level agreement)을 보장하기 위해, 함수에 대한 요청을 처리하는 순서를 조절하는 전자 장치 및 이의 제어방법을 제공함에 있다.
본 개시의 일 실시 예에 따른 전자 장치는, 통신부, 적어도 하나의 명령어를 저장하는 메모리 및 상기 적어도 하나의 명령어를 실행하는 프로세서를 포함하며, 상기 프로세서는, 상기 통신부를 통해 함수의 실행 요청을 복수 개 수신하고, 상기 복수 개의 요청에 대응하는 복수의 함수 각각에 대한 서비스 수준 계약(Service-Level Agreement(SLA))을 식별하며, 상기 식별된 서비스 수준 계약을 바탕으로 상기 복수의 함수에 우선순위를 결정하고, 상기 결정된 우선순위에 따라 상기 복수의 함수를 실행한다.
이 경우, 상기 프로세서는, 상기 복수의 함수 각각에 대한 서비스 수준 계약 및 함수 토폴로지 정보에 기초하여 상기 복수의 함수에 우선순위를 결정할 수 있다.
이 경우, 상기 프로세서는, 특정 함수가 다른 함수를 내부 호출(internal call)하는 것을 바탕으로 함수들의 연쇄 실행에 관한 정보를 획득하고, 상기 획득한 함수들의 연쇄 실행에 관한 정보를 바탕으로 상기 함수 토폴로지 정보를 생성할 수 있다.
한편, 상기 프로세서는, 새로운 함수의 등록 및 기 등록된 함수의 수정에 따라 상기 함수 토폴로지 정보를 변경할 수 있다.
한편, 상기 프로세서는, 상기 복수의 함수 각각에 대해서, 서비스 수준 계약에 정해진 허용 지연 시간에서 상기 함수 토폴리지 정보를 기초로 산출된 예측 실행 시간을 뺀 남은 시간을 산출하고, 상기 복수의 함수 각각에 대해 산출된 남은 시간이 적은 순서대로 상기 복수의 함수에 우선순위를 결정할 수 있다.
한편, 상기 프로세서는, 상기 복수 개의 요청의 HTTP 헤더에 포함된 서비스 수준 계약에 대한 정보를 확인하여 상기 복수의 함수 각각에 대한 상기 서비스 수준 계약을 식별할 수 있다.
한편, 상기 프로세서는, 상기 복수 개의 요청을 메시지 포맷으로 변환하며, 상기 복수의 함수 각각에 결정된 우선순위에 따라, 상기 변환에 의해 생성된 복수의 메시지 각각을 제1 메시지 큐 또는 제2 메시지 큐에 삽입하고, 상기 제1 메시지 큐에 삽입된 메시지를 상기 제2 메시지 큐에 삽입된 메시지보다 우선하여 디큐(dequeue)하고, 상기 디큐된 메시지에 대응하는 함수를 실행할 수 있다.
한편, 상기 프로세서는, 기 등록된 함수의 수정에 따라 상기 기 등록된 함수에 대한 복수의 버전을 저장하며, 상기 기 등록된 함수에 대해서 서비스 레벨 계약이 지켜질 수 없는 수정이 발생하고 상기 기 등록된 함수에 대한 실행 요청이 수신되면, 상기 서비스 레벨 계약이 지켜질 수 없는 수정이 발생하기 이전 버전으로 상기 기등록된 함수를 실행시킬 수 있다.
한편, 상기 프로세서는, 새로운 함수가 등록되면, 기 설정된 기간 동안 상기 새로운 함수의 실행 시간에 대한 정보를 획득하고, 상기 획득된 실행 시간에 대한 정보를 바탕으로 상기 새로운 함수에 대해 서로 다른 등급의 복수의 서비스 레벨 계약을 결정하고, 상기 결정된 복수의 서비스 레벨 계약 중 어느 하나를 선택받기 위한 UI(User Interface)를 제공할 수 있다.
이 경우, 상기 프로세서는, 상기 제공된 UI를 통해 상기 새로운 함수에 대한 서비스 레벨 계약이 설정되면, 상기 설정된 서비스 레벨 계약에 대한 정보와 상기 새로운 함수를 연관하여 상기 메모리에 저장할 수 있다.
한편, 본 개시의 일 실시 예에 따른 전자 장치를 제어하는 방법은, 함수의 실행 요청을 복수 개 수신하는 단계, 상기 복수 개의 요청에 대응하는 복수의 함수 각각에 대한 서비스 수준 계약(Service-Level Agreement(SLA))을 식별하는 단계, 상기 식별된 서비스 수준 계약을 바탕으로 상기 복수의 함수에 우선순위를 결정하는 단계 및 상기 결정된 우선순위에 따라 상기 복수의 함수를 실행하는 단계를 포함한다.
이 경우, 상기 우선순위를 결정하는 단계는, 상기 복수의 함수 각각에 대한 서비스 수준 계약 및 함수 토폴로지 정보에 기초하여 상기 복수의 함수에 우선순위를 결정할 수 있다.
이 경우, 본 실시 예에 따른 방법은, 특정 함수가 다른 함수를 내부 호출(internal call)하는 것을 바탕으로 함수들의 연쇄 실행에 관한 정보를 획득하고, 상기 획득한 함수들의 연쇄 실행에 관한 정보를 바탕으로 상기 함수 토폴로지 정보를 생성하는 단계를 더 포함할 수 있다.
한편, 본 실시 예에 따른 방법은, 새로운 함수의 등록 및 기 등록된 함수의 수정에 따라 상기 함수 토폴로지 정보를 변경하는 단계를 더 포함할 수 있다.
한편, 상기 우선순위를 결정하는 단계는, 상기 복수의 함수 각각에 대해서, 서비스 수준 계약에 정해진 허용 지연 시간에서 상기 함수 토폴리지 정보를 기초로 산출된 예측 실행 시간을 뺀 남은 시간을 산출하고, 상기 복수의 함수 각각에 대해 산출된 남은 시간이 적은 순서대로 상기 복수의 함수에 우선순위를 결정할 수 있다.
한편, 상기 식별하는 단계는, 상기 복수 개의 요청의 HTTP 헤더에 포함된 서비스 수준 계약에 대한 정보를 확인하여 상기 복수의 함수 각각에 대한 상기 서비스 수준 계약을 식별할 수 있다.
한편, 본 실시 예에 따른 방법은, 상기 복수 개의 요청을 메시지 포맷으로 변환하는 단계를 더 포함하고, 상기 복수의 함수를 실행하는 단계는, 상기 복수의 함수 각각에 결정된 우선순위에 따라, 상기 변환에 의해 생성된 복수의 메시지 각각을 제1 메시지 큐 또는 제2 메시지 큐에 삽입하고, 상기 제1 메시지 큐에 삽입된 메시지를 상기 제2 메시지 큐에 삽입된 메시지보다 우선하여 디큐(dequeue)하고, 상기 디큐된 메시지에 대응하는 함수를 실행할 수 있다.
한편, 본 실시 예에 따른 방법은, 기 등록된 함수의 수정에 따라 상기 기 등록된 함수에 대한 복수의 버전을 저장하는 단계 및 상기 기 등록된 함수에 대해서 서비스 레벨 계약이 지켜질 수 없는 수정이 발생하고 상기 기 등록된 함수에 대한 실행 요청이 수신되면, 상기 서비스 레벨 계약이 지켜질 수 없는 수정이 발생하기 이전 버전으로 상기 기등록된 함수를 실행시키는 단계를 더 포함할 수 있다.
한편, 본 실시 예에 따른 방법은, 새로운 함수가 등록되면, 기 설정된 기간 동안 상기 새로운 함수의 실행 시간에 대한 정보를 획득하는 단계, 상기 획득된 실행 시간에 대한 정보를 바탕으로 상기 새로운 함수에 대해 서로 다른 등급의 복수의 서비스 레벨 계약을 결정하는 단계 및 상기 결정된 복수의 서비스 레벨 계약 중 어느 하나를 선택받기 위한 UI(User Interface)를 제공하는 단계를 더 포함할 수 있다.
이 경우, 본 실시 예에 따른 방법은, 상기 제공된 UI를 통해 상기 새로운 함수에 대한 서비스 레벨 계약이 설정되면, 상기 설정된 서비스 레벨 계약에 대한 정보와 상기 새로운 함수를 연관하여 저장하는 단계를 더 포함할 수 있다.
도 1은 일 실시 예에 따른, 함수 수준 계약(FLA)과 서비스 수준 계약(SLA)에 대한 개념을 설명하기 위한 도면,
도 2는 종래의 방식과 일 실시 예에 따른 본 개시에 따른 방식을 비교하여 설명하기 위한 도면,
도 3 내지 도 4는 다양한 실시 예에 따른 서버리스 컴퓨팅 시스템을 설명하기 위한 도면,
도 5는 일 실시 예에 따른, API 게이트 웨이의 동작을 설명하기 위한 도면,
도 6은 일 실시 예에 따른, 컴퓨팅 장치의 동작을 설명하기 위한 도면,
도 7은 일 실시 예에 따른, 함수 버저닝(versioning)을 설명하기 위한 도면,
도 8은 일 실시 예에 따른 전자 장치의 구성을 설명하기 위한 블럭도,
도 9 내지 도 10은 서비스 수준 계약(SLA)의 등급을 사용자로부터 선택받기 위한 UI(User interface)의 다양한 예를 설명하기 위한 도면, 그리고
도 11은 일 실시 예에 따른 전자 장치를 제어하는 방법을 설명하기 위한 흐름도이다.
이하, 본 개시의 다양한 실시 예가 기재된다. 그러나, 이는 본 개시의 기술을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 개시의 실시 예들의 다양한 변경(modifications), 균등물(equivalents), 및/또는 대체물(alternatives)을 포함하는 것으로 이해되어야 한다.
본 문서에서, "가진다," "가질 수 있다," "포함한다," 또는 "포함할 수 있다" 등의 표현은 해당 특징(예: 수치, 기능, 동작, 또는 부품 등의 구성요소)의 존재를 가리키며, 추가적인 특징의 존재를 배제하지 않는다.
본 문서에서, "A 또는 B," "A 또는/및 B 중 적어도 하나," 또는 "A 또는/및 B 중 하나 또는 그 이상"등의 표현은 함께 나열된 항목들의 모든 가능한 조합을 포함할 수 있다. 예를 들면, "A 또는 B," "A 및 B 중 적어도 하나," 또는 "A 또는 B 중 적어도 하나"는, (1) 적어도 하나의 A를 포함, (2) 적어도 하나의 B를 포함, 또는 (3) 적어도 하나의 A 및 적어도 하나의 B 모두를 포함하는 경우를 모두 지칭할 수 있다.
본 문서에서 사용된 "제1," "제2," "첫째," 또는 "둘째," 등의 표현들은 다양한 구성요소들을, 순서 및/또는 중요도에 상관없이 수식할 수 있고, 한 구성요소를 다른 구성요소와 구분하기 위해 사용될 뿐 해당 구성요소들을 한정하지 않는다. 예를 들면, 제1 사용자 기기와 제2 사용자 기기는, 순서 또는 중요도와 무관하게, 서로 다른 사용자 기기를 나타낼 수 있다. 예를 들면, 본 문서에 기재된 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 바꾸어 명명될 수 있다.
본 문서에서 사용된 "모듈", "유닛", "부(part)" 등과 같은 용어는 적어도 하나의 기능이나 동작을 수행하는 구성요소를 지칭하기 위한 용어이며, 이러한 구성요소는 하드웨어 또는 소프트웨어로 구현되거나 하드웨어 및 소프트웨어의 결합으로 구현될 수 있다. 또한, 복수의 "모듈", "유닛", "부(part)" 등은 각각이 개별적인 특정한 하드웨어로 구현될 필요가 있는 경우를 제외하고는, 적어도 하나의 모듈이나 칩으로 일체화되어 적어도 하나의 프로세서로 구현될 수 있다.
어떤 구성요소(예: 제1 구성요소)가 다른 구성요소(예: 제2 구성요소)에 "(기능적으로 또는 통신적으로) 연결되어((operatively or communicatively) coupled with/to)" 있다거나 "접속되어(connected to)" 있다고 언급된 때에는, 상기 어떤 구성요소가 상기 다른 구성요소에 직접적으로 연결되거나, 다른 구성요소(예: 제 3 구성요소)를 통하여 연결될 수 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소(예: 제1 구성요소)가 다른 구성요소(예: 제2 구성요소)에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 상기 어떤 구성요소와 상기 다른 구성요소 사이에 다른 구성요소(예: 제3 구성요소)가 존재하지 않는 것으로 이해될 수 있다.
본 문서에서 사용된 표현 "~하도록 구성된(또는 설정된)(configured to)"은 상황에 따라, 예를 들면, "~에 적합한(suitable for)," "~하는 능력을 가지는(having the capacity to)," "~하도록 설계된(designed to)," "~하도록 변경된(adapted to)," "~하도록 만들어진(made to)," 또는 "~를 할 수 있는(capable of)"과 바꾸어 사용될 수 있다. 용어 "~하도록 구성된(또는 설정된)"은 하드웨어적으로 "특별히 설계된(specifically designed to)" 것만을 반드시 의미하지 않을 수 있다. 대신, 어떤 상황에서는, "~하도록 구성된 장치"라는 표현은, 그 장치가 다른 장치 또는 부품들과 함께 "~할 수 있는" 것을 의미할 수 있다. 예를 들면, 문구 "A, B, 및 C를 수행하도록 구성된(또는 설정된) 프로세서"는 해당 동작을 수행하기 위한 전용 프로세서(예: 임베디드 프로세서), 또는 메모리 장치에 저장된 하나 이상의 소프트웨어 프로그램들을 실행함으로써, 해당 동작들을 수행할 수 있는 범용 프로세서(generic-purpose processor)(예: CPU 또는 application processor)를 의미할 수 있다.
본 문서에서 사용된 용어들은 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 다른 실시예의 범위를 한정하려는 의도가 아닐 수 있다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함할 수 있다. 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 용어들은 본 문서에 기재된 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가질 수 있다. 본 문서에 사용된 용어들 중 일반적인 사전에 정의된 용어들은, 관련 기술의 문맥상 가지는 의미와 동일 또는 유사한 의미로 해석될 수 있으며, 본 문서에서 명백하게 정의되지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다. 경우에 따라서, 본 문서에서 정의된 용어일지라도 본 문서의 실시예들을 배제하도록 해석될 수 없다.
이하에서는 도면을 참조하여 본 개시에 대해 더욱 상세히 설명하도록 한다. 다만, 본 개시를 설명함에 있어서, 관련된 공지 기능 혹은 구성에 대한 구체적인 설명이 본 개시의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우 그에 대한 상세한 설명은 생략한다. 도면의 설명과 관련하여, 유사한 구성요소에 대해서는 유사한 참조 부호가 사용될 수 있다.
본 개시의 실시 예들을 서버리스 컴퓨팅 시스템과 관련된다. 서버리스 컴퓨팅 시스템은 이벤트에 대해 코드를 실행하여 응답하는 클라우드 컴퓨팅 방식을 제공할 수 있다. 여기서 서버리스, 서버가 없다는 표현은 해당 이벤트에 대해 별도로 할당된 서버가 없어, 개발자가 인프라 및 플랫폼 관리를 할 필요가 없다는 의미이다. 서버리스 컴퓨팅 시스템에서는, 서버리스 컴퓨팅의 처리 단위인 함수(Function)를 실행하여 응답을 제공할 수 있다. 함수는 특정 작업을 수행하는 코드들의 집합을 의미한다.
서버리스 컴퓨팅 시스템의 공급자는, 공급자가 제공하는 서비스에 대한 측정 지표와 목표에 대한 협약인 계약(agreement)에 따라 개발자(사용자)에게 과금할 수 있다. 여기서 계약은, 목표 수치(일반적으로, 함수의 실행 요청으로부터 응답까지 걸리는 시간(예컨대, Round Trip Time))를 달성하지 못할 경우 환불하겠다는 약속에 해당할 수 있다. 계약은 함수 하나에 대해서 존재할 수 있고 총 서비스에 대해 존재할 수 있다. 함수 하나에 대한 계약은 함수 수준 계약(Function-Level Agreement(FLA))라고 칭하고, 총 서비스에 대한 계약은 서비스 수준 계약(Service-Level Agreement(SLA))으로 칭한다. SLA은 QoS(Quality of Service)로 명명될 수도 있다. 서버리스 컴퓨팅에서의 컴퓨팅 단위인 함수가 항상 서비스를 의미하진 않는다. 하나의 서비스는 일련의 함수들이 모두 불리고 나서야 완료될 수 있다. 도 1은 함수 수준 계약(FLA)과 서비스 수준 계약(SLA)에 대한 개념을 설명하기 위한 도면이다. 예컨대, SLA에는 허용 지연 시간(allowed latency) 내에서 함수가 실행되도록 하고, 허용 지연 시간을 넘길 시에는 환불하겠다는 약속이 정해질 수 있다.
종래엔, 예컨대 마이크로소프트 사의 Azure®라는 서버리스 컴퓨팅 시스템에서는 FLA만을 명시한다. 그리고 아마존 웹 서비스(Amazon Web Services(AWS))의 Lambda®라는 서버리스 컴퓨팅 시스템에서는 FLA과 SLA 모두가 명시되어 있지 않다. SLA를 명시하지 않는 이유는, 서버리스 컴퓨팅 시스템에서 모든 함수는 독립적으로 개발, 수정될 수 있기 때문일 것이다. 예컨대, 함수 내에 내부 호출 함수가 추가될 수 있고, 내부 호출 함수의 내용도 변경될 수 있다. 다시 말해, 함수에 대한 실행 요청 시점과 응답 시점 사이의 지연(latency)은 함수가 동적으로 수정됨에 따라 언제든지 변경될 수 있기 때문에 SLA를 명시하는 것이 어려웠다. 또한 서비스 수행을 위한 함수의 수와 관계 복잡도의 증가 때문에 SLA을 명시하는 것이 어려웠다.
이러한 종래의 서버리스 컴퓨팅 시스템에서의 단점을 해결하고자, 본 실시 예에 따른 서버리스 컴퓨팅 시스템에서는 SLA를 명시하고, SLA를 완벽하게 충족시키진 못하더라도 최선의 노력(Best Effort)으로 보장하는 것을 목적으로 한다.
도 2를 참고하여 종래의 방식과 본 개시에 따른 방식을 비교하여 설명하자면, 도 2의 (a)는 종래의 방식을 설명하는 것으로서, FLA가 지켜지지 않은 함수들(빗금으로 표시) 때문에 서비스 A와 서비스 B 모두에 대해 SLA가 지켜지지 못한다(계약이 지켜지지 않음을 0%로 표현). 반면에, 도 2의 (b)는 본 개시의 방식을 설명하는 것으로서, 서비스 A에 대해선 FLA가 지켜지지 않은 함수들(빗금으로 표시) 때문에 SLA가 지켜지지 못하지만, 서비스 B에 대해선 SLA가 지켜질 수 있다. 즉, FLA가 지켜지지 않는 확률은 종래와 동일할지라도, 어떤 서비스의 함수에 우선순위를 두어서 실행시키느냐에 따라, SLA는 어느 정도 지켜질 수 있는 것이다.
도 3은 본 개시의 일 실시 예에 따른 서버리스 컴퓨팅 시스템을 설명하기 위한 도면이다.
시스템(100)은 클라이언트(200)로부터 함수의 실행 요청을 받는 API 게이트웨이(110)와 함수들을 실행하여 응답을 제공하는 컴퓨팅 장치(120)를 포함한다.
API 게이트웨이(110)는 여러 클라이언트(200)의 단일 진입점 역할을 한다. API 게이트웨이(110)는 모든 클라이언트(200) 요청에 대한 엔드 포인트(end point)를 통합하는 서버로서 구현될 수 있다. API 게이트웨이(110)는 여러 클라이언트(200)로부터 함수의 실행 요청들을 수신하고, 요청들을 컴퓨팅 장치(120)로 넘겨줄 수 있다.
클라이언트(200)는 하드웨어 클라이언트, 소프트웨어 클라이언트, 애플리케이션 등일 수 있다. 일 실시 예에 따르면, 클라이언트(200)는 휴대폰, 태블릿 PC, 데스크탑, 디지털 방송용 단말기, IoT 디바이스, 착용형 기기(wearable device), CE(Consumer Electronics) 기기 등과 같은 전자 장치로 구현될 수 있다.
클라이언트(200)는 함수 호출(function call)을 API 게이트웨이(110)로 전송할 수 있다. 일 실시 예에 따르면, 함수 호출은 API 게이트웨이(110)와 연관된 엔드 포인트에 대한 RESTful API 호출을 수행함으로써 구현될 수 있다. RESTful API는 HTTP(Hypertext Transfer Protocol) 및 URL(Uniform Resource Locator)를 바탕으로 URL 에 의해 식별되는 함수를 특정할 수 있다.
컴퓨팅 장치(120)는 API 게이트웨이(110)로부터 수신된 함수 호출에 기초하여 함수들을 실행할 수 있다.
컴퓨팅 장치(120)는 클라우드 서버, 인공지능 서버 등과 같은 서버로 구현될 수 있다. 다만 이에 한정되는 것은 아니고 어떠한 전자 장치로도 구현될 수 있다.
컴퓨팅 장치(120)는 리소스를 효과적으로 사용하기 위해 가상화 기술을 이용할 수 있다. 일 실시 예에 따르면 컴퓨팅 장치(120)는 컨테이너(Container) 기술을 이용할 수 있다. 예컨대, LXC Linux Containers, Windows 운영 시스템용 Docker, 표준 기반 응용 프로그램 컨테이너 기술인 Rocket과 같은 기술이 있다. 컴퓨팅 장치(120)는 하나 이상의 컨테이너 상에서 소프트웨어를 실행할 수 있다.
본 개시의 실시 예들에 따른 시스템(100)은, SLA를 바탕으로, 함수의 실행의 우선순위를 조절할 수 있고, 우선순위에 따라 함수들을 실행함으로써, SLA가 최대한 보장될 수 있도록 할 수 있다.
우선순위는 API 게이트웨이(110)에서 지정될 수 있고, 또한 컴퓨팅 장치(120)에서 지정될 수도 있다. API 게이트웨이(110)는 실행 요청된 함수에 대한 SLA에 따라 우선순위를 지정할 수 있고, 컴퓨팅 장치(120)는 SLA뿐만 아니라 함수 토폴로지(topology) 정보를 고려해서 우선순위를 지정할 수 있다. 우선순위를 지정과 관련하여 API 게이트웨이(110) 및 컴퓨팅 장치(120)에 대해서 도 4를 참고해 자세히 설명하도록 한다.
도 4는 본 개시의 일 실시 예에 따른 서버리스 컴퓨팅 시스템을 설명하기 위한 도면이다.
도 4를 참고하면, 시스템(100)은 API 게이트웨이(110) 및 컴퓨팅 장치(120)를 포함할 수 있다.
API 게이트웨이(110)는, 수신된 함수의 실행 요청 각각에 대해서 우선순위 등급을 지정하는 API 우선순위 관리 모듈(410)를 포함할 수 있다.
API 우선순위 관리 모듈(410)은 시스템(100)에 등록된 함수들에 대한 SLA를 저장한 데이터베이스를 포함할 수 있다. API 우선순위 관리 모듈(410)은 데이터베이스를 참고하여, 수신된 함수의 실행 요청에 대응하는 함수에 대한 SLA를 확인하고, 확인된 SLA에 대한 정보를 바탕으로 해당 요청에 우선순위 등급을 지정할 수 있다. 우선순위 등급이 지정된 요청은 컴퓨팅 장치(120)로 전달될 수 있다. API 우선순위 관리 모듈(410)과 관련하여선 도 5에서 좀 더 자세히 설명하도록 한다.
컴퓨팅 장치(120)는 컨트롤러(430), 메시지 큐(450), 인보커(470)를 포함할 수 있다.
컨트롤러(430)는 API 게이트웨이(110)로부터 수신된 요청을 실행 가능한 메시지 형태로 변환하고, 메시지를 메시지 큐(450)에 인큐(enqueue)할 수 있다.
일 실시 예에 따르면, 컨트롤러(430)는 API 게이트웨이(110)에서 지정된 우선순위 등급 및/또는 함수 간 토폴로지 구조에 대한 정보(함수 토폴로지 정보) 중 적어도 하나를 바탕으로 최종적으로, 요청들의 우선순위를 결정할 수 있다. 함수 토폴로지 정보는 함수 토폴로지 관리 모듈(421)에서 생성될 수 있다. 함수 토폴로지 관리 모듈(421)과 관련하여선 도 6에서 좀 더 자세히 설명하도록 한다.
그리고 컨트롤러(430)는 결정된 우선순위에 따라 메시지를, 서로 다른 우선순위를 가지는 복수의 메시지 큐(450)에 인큐할 수 있다. 예컨대, 도 4에 도시한 것처럼 메시지 큐(450)는 높은 우선순위를 가지는 메시지 큐와 낮은 우선순위를 가지는 메시지 큐를 포함할 수 있고, 컨트롤러(430)는 우선순위가 높은 메시지는 높은 우선순위를 가지는 메시지 큐에, 우선순위가 낮은 메시지는 낮은 우선순위를 가지는 메시지 큐에 각각 인큐할 수 있다. 즉 이와 같이 본 시스템(100)은 복수 개의 메시지 큐를 운영하고, 각 메시지 큐마다 우선순위를 할당해서 요청을 처리할 수 있다.
인보커(470)는 메시지 큐(450)로부터 메시지를 디큐(dequeue)하고, 디큐된 메시지에 대응하는 함수를 실행할 수 있다. 컨트롤러(430)는 현재 사용 가능한 인보커 목록을 받아 실행할 대상을 결정할 수 있다. 일 실시 예에 따르면 인보커(470)는 컨테이너 상에서 함수에 대응하는 코드를 실행할 수 있다. 함수의 실행 결과는 클라이언트(200)로 전달될 수 있다.
도 5는 일 실시 예에 따른 API 게이트 웨이(110)에서의 동작을 설명하기 위한 도면이다.
도 5를 참고하면, API 게이트 웨이(110)는 API 우선순위 관리모듈(410)과 커스텀 필터(custom filter)(420)를 포함할 수 있다.
클라이언트(200)로부터 함수의 실행 요청, 예컨대 RESTful API 요청이 수신되면, 커스텀 필터(420)는 해당 요청에 대응하는 함수에 대한 SLA를 API 우선순위 관리모듈(410)에 문의하여, HTTP 헤더 필드에 SLA 정보를 입력할 수 있다. 입력된 SLA 정보를 바탕으로 API 우선순위 관리모듈(410)에서 SLA를 지키기 위한 우선순위 등급을 결정할 수 있다.
컨트롤러(430)에서는 API 게이트웨이(110)로부터 수신한 요청을 메시지 포맷으로 변환할 수 있다. 메시지는 실행할 때 필요한 리소스 등을 정해 놓은 데이터 구조이다. 컨트롤러(430)는 API 우선순위 관리모듈(410)에서 결정된 우선순위 등급을 반영해서 요청들에 대한 우선순위를 결정할 수 있다. 우선순위가 정해지면, 컨트롤러(430)는 우선순위가 높을수록 먼저 실행될 수 있도록, 메시지 큐에 인큐할 수 있다. 일 실시 예에 따르면, 메시지 큐는 복수 개 존재하며 예컨대 높은 우선순위를 가지는 메시지 큐(451)와 낮은 우선순위를 가지는 메시지 큐(453)가 존재할 수 있다. 컨트롤러(430)는 우선순위가 높은 메시지는 높은 우선순위를 가지는 메시지 큐(451)에 인큐(enqueue)할 수 있다.
인보커(470)는 높은 우선순위를 가지는 메시지 큐에서부터 메시지를 디큐하여 실행할 수 있다. 일 실시 예에 다르면 인보커(470)는 메시지 큐의 우선순위에 따라 디큐 가중치를 달리할 수 있다. 이에 따라 SAL를 최대한 지키는 방향으로 함수 처리 순서가 결정될 수 있다.
인보커(470)는 메시지 스팩에 따라 다른 가상 머신을 할당하고, 다른 OS를 설치하고, 라이브러리를 설치하는 등의 작업을 수행해서 메시지에 해당하는 함수의 코드를 실행할 수 있다.
도 7은 일 실시 예에 따른 컨트롤러(430)에서의 동작을 설명하기 위한 도면이다.
함수 토폴로지 관리 모듈(431)은 함수 토폴로지 정보를 생성할 수 있다. 함수 토폴로지 정보는 함수들 간의 연결 관계를 나타낼 수 있다. 예컨대, 제1 함수가 제2 함수를 실행시키고, 제2 함수는 제3 함수를 실행시킨다면, 이러한 함수들의 연쇄 실행에 대한 정보가 함수 토폴로지 정보에 포함될 수 있다. 또한 함수 토폴로지 정보는 각 함수들의 실행 시간에 대한 정보도 포함할 수 있어, 특정 함수가 실행될 경우 연속하여 실행될 다른 함수들에 대한 실행 시간을 예측할 수 있게 한다.
사용자(개발자)가 새로운 함수를 등록하는 경우, 컨트롤러(430)를 거쳐 등록되므로, 함수 토폴로지 관리 모듈(431)은 함수 토폴로지 정보에 새로운 노드(node)(새로운 함수)를 추가할 수 있다.
함수 토폴로지 관리 모듈(431)은 어떤 함수가 추가되었는지, 어떤 함수가 어떤 함수를 호출했는지를 모니터링 하면서 함수 토폴로지 정보의 데이터를 축적해나갈 수 있다.
이러한 함수 토폴로지 정보는, 함수의 개수, 연결 복잡성 때문에 데이터 크기가 클 수 있다. 따라서 빅데이터 기술이 이용될 수 있다. 예컨대, 데이터베이스 샤딩(Database Sharding), 맵리듀스®(MapReduce), 스파크®(Spark) 등을 통한 빅데이터 분산 처리 기술이 이용될 수 있다.
한편, 서버리스 컴퓨팅에서는 함수의 내용과 요구 사양이 동적으로 변경될 수 있기 때문에 함수가 중간에 변경되는 경우 함수에 대한 실행 요청 시점과 응답 시점 사이의 지연(latency)에 변화가 생긴다. 함수 토폴로지 관리 모듈(431)은 이러한 변경에 대해서 지속적으로 기록할 수 있으며, 함수 변경에 따라 버저닝(versioning)을 할 수 있다. 이에 관해선 도 7을 참고하여 설명하도록 한다.
도 7의 (a)를 참고하면, 최초에 foo 라는 함수가 있었고, 이 함수의 지연(latency)은 10ms였다. 함수 토폴로지 관리 모듈(431)은 이 때의 버전을 0.1 버전으로 기록할 수 있다. 이후 도 7의 (b)를 참고하면, foo 함수에 수정이 발생되어서, 내부 호출 함수로서 bar 함수가 추가되는 경우, 지연(latency)은 20ms으로 증가될 수 있다. 함수 토폴로지 관리 모듈(431)은 이 때의 버전을 0.2 버전으로 기록할 수 있다. 이후 도 7의 (c)를 참고하면 내부 호출 함수인 bar의 내용이 변경되어 bar의 연결 함수가 baz에서 quz로 변경될 수 있고, 지연(latency)은 25ms으로 증가될 수 있다. 함수 토폴로지 관리 모듈(431)은 이 때의 버전을 0.3 버전으로 기록할 수 있다.
함수가 SLA를 지킬 수 없게 변경될 경우에는, 컨트롤러(430)는 이전 버전의 함수를 호출할 수 있다. 예컨대, 도 7의 예에서, 0.3버전으로는 SLA에서 정하는 허용 지연 시간을 넘을 수 밖에 없는 경우에는 0.2버전의 함수를 호출할 수 있다. 즉, 이와 같은 버저닝을 통해 SLA가 지켜질 수 있는 것이다.
함수의 추가 및 버전 업데이트로 인한 함수 토폴로지 정보의 변경은 Runtime 중 동적으로 반영될 수 있다.
제1 함수가 내부에서 다른 제2 함수를 호출하는 경우, 그 호출을 위한 요청이 컨트롤러(430)로 전달되고, 컨트롤러(430)는, 제2 함수가 또 다른 어떤 함수를 호출할 것인지를 함수 토폴로지 정보를 바탕으로 예상할 수 있고, 다 실행되는데 걸리는 시간을 예측할 수 있다. 예측된 시간과 SLA 정보를 바탕으로 남은 시간을 산출할 수 있고, 남은 시간에 기초해서 함수의 우선순위를 결정할 수 있다.
예컨대, 도 6을 참고하면, 함수 1이 함수 2를 내부 호출하는 요청(제1 요청)이 수신되고, 함수 5가 함수 6을 내부 호출하는 요청(제2 요청)이 수신된 경우, 컨트롤러(430)는 SLA를 지키는 한도에서 남은 실행 시간을 기초로, 제1 요청과 제2 요청에 우선순위를 결정할 수 있다.
도 6을 참고하면, 컨트롤러(430)는 함수 2가 실행될 경우 이어서 실행될 함수 3, 4에 대한 실행 시간까지 포함해서, 예측 실행 시간이 25ms임을 함수 토폴로지 정보에 기초해서 산출할 수 있고, API 게이트웨이(110)로부터 수신한 함수 1의 실행 요청에 포함된 SLA 정보로부터 허용 지연 시간이 40ms임을 확인하여, 이를 바탕으로 제1 요청에 대하여 아직 15ms의 잔여 시간이 남아있음을 확인할 수 있다. 마찬가지 방식으로, 컨트롤러(430)는 함수 6이 실행될 경우 예측되는 실행 시간이 25ms임을 함수 토폴로지 정보에 기초해서 산출할 수 있고, API 게이트웨이(110)로부터 수신한 함수 5의 실행 요청에 포함된 SLA 정보로부터 허용 지연 시간이 20ms임을 확인하여, 이를 바탕으로 제2 요청에 대하여 아직 잔여 시간이 남아있음을 확인할 수 있다. 정리하자면 제1 요청에 대해선 15ms의 잔여 시간이 남아있고, 제2 요청에 대해선 5ms의 잔여 시간이 남아 있는 상황이므로, 컨트롤러(430)는 잔여 시간이 더 적게 남아 있는 제2 요청을 우선적으로 처리하게 된다. 즉, 컨트롤러(430)는 남은 시간에 반비례하게 다음 함수의 우선순위를 결정할 수 있다.
본 개시의 일 실시 예에 따르면, 함수 토폴로지 관리 모듈(431)은 특정 함수에 대해 남은 시간을 산출하고 우선순위를 결정하는 API를 제공할 수 있다. 컨트롤러(430)는 이 API를 호출해서 남은 시간을 산출하고 우선순위를 결정할 수 있다. 그런데 함수의 수와 복잡도에 따라 이 API의 응답 시간(response time)이 Real Time이 아닌 경우, 예컨대 10ms가 넘어갈 경우에는, 컨트롤러(430)는 함수 토폴로지 정보는 적용하지 않고 SLA만 고려해서 우선순위를 정할 수 있다. 한편, 이러한 API의 응답 시간을 최소화하기 위해, 그래프 기반 지식 표현 방식, 온톨로지(Ontology) 기반 지식 표현 방식 등이 사용되어 데이터 사이즈 효율화 및 구조화가 이루어질 수 있다.
이와 같이 SLA 정보와 서비스를 구성하는 함수들의 예측 실행 시간을 바탕으로 요청들에 대한 우선순위가 정해질 수 있다. 즉, 서비스 단위로 함수의 호출의 순서가 정해질 수 있는 것이다.
도 3 내지 도 6의 API 게이트웨이(110), 컴퓨팅 장치(120), API 우선순위 관리 모듈(410), 커스텀 필터(420), 컨트롤러(430), 함수 토폴로지 관리 모듈(431), 메시지 큐(450), 인보커(470) 중 적어도 하나는 하드웨어 형태로 제작되어 하나의 장치에 탑재될 수도 있으며, 또는 별개의 장치들에 각각 탑재될 수도 있다. 또한, 게이트웨이(110), 컴퓨팅 장치(120), API 우선순위 관리 모듈(410), 커스텀 필터(420), 컨트롤러(430), 함수 토폴로지 관리 모듈(431), 메시지 큐(450), 인보커(470) 중 적어도 하나는 소프트웨어 모듈로 구현될 수 있다. 게이트웨이(110), 컴퓨팅 장치(120), API 우선순위 관리 모듈(410), 커스텀 필터(420), 컨트롤러(430), 함수 토폴로지 관리 모듈(431), 메시지 큐(450), 인보커(470) 중 적어도 하나가 소프트웨어 모듈(또는, 인스터력션(instruction) 포함하는 프로그램 모듈)로 구현되는 경우, 소프트웨어 모듈은 컴퓨터로 읽을 수 있는 판독 가능한 비일시적 판독 가능 기록매체(non-transitory computer readable media)에 저장될 수 있다. 또한, 이 경우, 적어도 하나의 소프트웨어 모듈은 OS(Operating System)에 의해 제공되거나, 소정의 애플리케이션에 의해 제공될 수 있다. 또는, 적어도 하나의 소프트웨어 모듈 중 일부는 OS(Operating System)에 의해 제공되고, 나머지 일부는 소정의 애플리케이션에 의해 제공될 수 있다.
도 8은 본 개시의 일 실시 예에 따른 전자 장치의 구성을 나타내는 블럭도이다. 전자 장치(700)는 예를 들면 클라우드 서버, 인공지능 서버 등과 같은 서버로 구현될 수 있다. 전자 장치(700)는 하나 이상의 서버로 구성될 수 있다. 다만 이에 한정되는 것은 아니고 전자 장치(700)는 어떠한 전자 장치로도 구현될 수 있다.
도 8을 참고하면, 일 실시 예에 따른 전자 장치(700)는 프로세서(710), 메모리(720) 및 통신부(730)를 포함할 수 있다.
프로세서(710)는 전자 장치(700)의 전반적인 동작을 제어하기 위한 구성이다. 예를 들면, 프로세서(710)는 운영 체제, 애플리케이션을 구동하여 프로세서(710)에 연결된 다수의 하드웨어 또는 소프트웨어 구성요소들을 제어할 수 있고, 각종 데이터 처리 및 연산을 수행할 수 있다. 프로세서(710)는 CPU(central processing unit) 또는 GPU(graphics-processing unit)이거나 둘 다일 수 있다. 프로세서(710)는 적어도 하나의 범용 프로세서(general processor), 디지털 신호 프로세서(digital signal processor), ASIC(Application specific integrated circuit), SoC(system on chip), MICOM(Microcomputer) 등으로 구현될 수 있다.
프로세서(710)는 메모리(720)에 저장되는 컴퓨터 실행 가능한 적어도 하나의 명령어(instructions)를 실행할 수 있다.
메모리(720)는 전자 장치(700)을 구동하고 제어하기 위한 다양한 데이터, 프로그램 또는 어플리케이션을 저장할 수 있다. 메모리(720)에 저장되는 프로그램은 하나 이상의 명령어들을 포함할 수 있다. 메모리(720)에 저장된 프로그램(하나 이상의 명령어들) 또는 어플리케이션은 프로세서(710)에 의해 실행될 수 있다.
통신부(730)는 프로세서(710)의 제어에 의해 외부 장치와 데이터 또는 신호를 송수신할 수 있다. 예를 들어 통신부(730)는 근거리 통신망(Local Area Network; LAN), 광역 통신망(Wide Area Network; WAN), 부가가치 통신망(Value Added Network; VAN), 이동통신망(mobile radio communication network), 위성 통신망 및 이들의 상호 조합을 통하여 통신을 하게 하는 하나 이상의 구성요소를 포함할 수 있다. 또한, 통신부(730)는 외부 장치 또는 외부 서버와 직접 무선랜(예를 들어, 와이-파이(Wi-Fi)) 등을 이용하여 무선으로 데이터 또는 신호를 송수신할 수 있다.
전자 장치(700)는 도 3 내지 도 6에서 설명한 API 게이트웨이(110) 및 컴퓨팅 장치(120) 중 적어도 하나의 동작을 수행할 수 있다. 예를 들어, 전자 장치(700)는 API 게이트웨이(110) 및 컴퓨팅 장치(120)의 동작을 수행할 수 있다. 또 다른 예로, 전자 장치(700)는 컴퓨팅 장치(120)의 동작을 수행하며, 외부의 API 게이트웨이(110)의 동작을 수행하는 장치와 통신할 수 있도록 구현될 수 있다.
일 실시 예에 따르면 전자 장치(700)는 도 3 내지 도 6에서 설명한 API 우선순위 관리 모듈(410), 커스텀 필터(420), 컨트롤러(430), 함수 토폴로지 관리 모듈(431), 메시지 큐(450), 인보커(470)의 동작들 중 적어도 하나를 수행할 수 있다.
예를 들어, 프로세서(710)는 통신부(730)를 통해 함수의 실행 요청을 수신할 수 있다. 전자 장치(700)가 API 게이트웨이(110)의 동작을 수행하는 장치로 구현된 경우, 프로세서(710)는 통신부(730)를 통해 클라이언트(200)로부터의 함수의 실행 요청을 수신할 수 있다. 또 다른 예로, 전자 장치(700)가 컴퓨팅 장치(120)의 동작을 수행하며, 외부의 API 게이트웨이(110)의 동작을 수행하는 장치와 통신할 수 있도록 구현된 경우, 프로세서(710)는 통신부(730)를 통해 API 게이트웨이(110)의 동작을 수행하는 외부 장치로부터 함수의 실행 요청을 수신할 수 있다.
프로세서(710)는 수신된 함수의 실행 요청에 대응하는 함수에 대한 서비스 수준 계약(Service-Level Agreement(SLA))을 식별할 수 있다.
일 실시 예에 따르면, 전자 장치(700)가 API 게이트웨이(110)의 동작을 수행하는 장치로 구현된 경우, 메모리(720)에는 함수에 대한 SLA 정보가 저장되어 있을 수 있다. 프로세서(710)는 클라이언트로부터 수신된 요청에 대응하는 함수에 대한 SLA 정보를 메모리(720)에서 검색하여 해당 함수에 대한 SLA를 식별할 수 있다. 그리고 프로세서(710)는 식별된 SLA 정보를 요청에 포함시킬 수 있다. 예컨대 프로세서(710)는 요청의 HTTP 헤더 필드에 SLA 정보를 입력할 수 있다. 일 실시 예에 따르면, 프로세서(710)는 SLA 정보를 기초로 요청의 SLA 등급을 결정할 수 있다. SLA 등급은 복수개 존재 할 수 있는데, 예컨대 복수의 등급은 프리미엄(Premium), 높음(High), 표준(Default), 절약(Economy) 등급을 포함할 수 있다. SLA 등급은 사용자(개발자)가 선택할 수 있다. SLA 등급 선택과 관련해선 도 9 및 도 10을 참고하여 좀 더 자세히 설명하도록 한다.
또 다른 실시 예에 따르면, 전자 장치(700)가 컴퓨팅 장치(120)의 동작을 수행하며, 외부의 API 게이트웨이(110)의 동작을 수행하는 장치와 통신할 수 있도록 구현된 경우, 프로세서(710)는 수신된 요청에 포함된 SLA 정보로부터 해당 요청에 대응하는 함수에 대한 SLA를 식별할 수 있다. 예컨대 프로세서(710)는 요청의 HTTP 헤더에 포함된 SLA에 대한 정보를 확인하여 함수에 대한 SLA를 식별할 수 있다. SLA를 식별한다는 의미는 SLA의 등급을 식별하는 것을 포함할 수 있다.
그리고 프로세서(710)는 요청이 복수개 있는 경우, 복수의 요청에 대응하는 복수의 함수에 대해서 식별된 SLA를 바탕으로, 복수의 함수에 우선순위를 결정할 수 있다.
예컨대 프로세서(710)는 복수의 함수 각각에 대한 SLA 및 함수 토폴로지 정보에 기초하여 복수의 함수에 우선순위를 결정할 수 있다.
함수 토폴로지 정보는 외부 장치로부터 제공될 수 있고, 또는 전자 장치(700) 자체적으로 생성할 수 있다. 후자의 경우, 프로세서(710)는 특정 함수가 다른 함수를 내부 호출(internal call)하는 것을 바탕으로 함수들의 연쇄 실행에 관한 정보를 획득하고, 획득한 함수들의 연쇄 실행에 관한 정보를 바탕으로 함수 토폴로지 정보를 생성할 수 있다.
프로세서(710)는 새로운 함수의 등록 및 기 등록된 함수의 수정에 따라 함수 토폴로지 정보를 변경할 수 있다.
또한, 프로세서(710)는 기 등록된 함수의 수정에 따라 기 등록된 함수에 대한 복수의 버전을 저장할 수 있으며, 기 등록된 함수에 대해서 SLA가 지켜질 수 없는 수정이 발생하고 기 등록된 함수에 대한 실행 요청이 수신되면, SLA이 지켜질 수 없는 수정이 발생하기 이전 버전으로 기등록된 함수를 실행킬 수 있다. 즉, 상술한 바와 같이 프로세서(710)는 함수 변경에 따라 버저닝을 수행할 수 있다.
프로세서(710)는 실행 요청이 있는 복수의 함수 각각에 대해서, SLA에 정해진 허용 지연 시간에서 함수 토폴리지 정보를 기초로 산출된 예측 실행 시간을 뺀 남은 시간을 산출하고, 복수의 함수 각각에 대해 산출된 남은 시간이 적은 순서대로 복수의 함수에 우선순위를 결정할 수 있다. 즉, 예컨대 앞서 도 6을 참고해 설명한 바와 같이, 남은 시간에 반비례하게 우선순위를 정할 수 있다.
그리고 프로세서(710)는 결정된 우선순위에 따라 복수의 함수를 실행할 수 있다. 메모리(720)에는 등록된 함수에 대응하는 코드, 함수를 실행시키기 위해 필요한 데이터, 파일, 라이브러리 등이 저장될 수 있고, 이를 바탕으로 프로세서(710)는 함수를 실행할 수 있다.
일 실시 예에 따르면, 프로세서(710)는 복수 개의 요청을 메시지 포맷으로 변환하며, 복수의 함수 각각에 결정된 우선순위에 따라, 변환에 의해 생성된 복수의 메시지 각각을 제1 메시지 큐 또는 제2 메시지 큐에 삽입하고, 제1 메시지 큐에 삽입된 메시지를 제2 메시지 큐에 삽입된 메시지보다 우선하여 디큐(dequeue)하고, 디큐된 메시지에 대응하는 함수를 실행할 수 있다. 여기서 제1 메시지 큐는 예컨대 도 6에서 설명한 높은 우선순위 메시지 큐(451)에 해당하고 제2 메시지 큐는 낮은 우선순위 메시지 큐(453)에 해당할 수 있다.
그리고 프로세서(710)는 함수의 실행에 의한 결과, 즉 응답을 클라이언트로 전송하도록 통신부(730)를 제어할 수 있다.
한편, 함수를 실제로 실행해 보기 전에는, 해당 함수의 실행에 얼마나 시간이 걸릴지 알 수 없으므로, SAL의 허용 지연 시간을 정할 수 없다. 따라서, 함수가 처음에 등록되었을 때에는 SLA를 정하지 않고, 대신 사용자(개발자)에게 시험 기간(트라이얼 기간)이 주어질 수 있다. 시험 기간 동안에는 전자 장치(100)는 모든 SLA 등급(예컨대, 프리미엄, 높음, 표준, 절약 등급들)에 대해서 학습을 한다. 학습이 끝났을 때 사용자에게 선택을 할 수 있게 한다. 전자 장치(100)는 사용자가 SLA 등급을 선택할 수 있도록 하는 UI(User interface)를 제공할 수 있다.
전자 장치(100)가 제공하는 UI의 예시들에 대해 도 9 및 도 10을 참고하여 설명하도록 한다.
도 9는 본 개시의 일 실시 예에 따른, 시험 기간 동안 제공될 수 있는 UI를 설명하기 위한 도면이다.
사용자가 함수 생성 시, 예컨대, 프리미엄, 높음, 표준, 절약 등급에 해당하는 SLA를 선택할 수 있는데, 처음에는 이를 특정할 수 없으므로, 도 9를 참고하면, 사용자에게 시험 기간을 경험할 수 있도록 하는 UI가 제공될 수 있다.
시험 기간 동안 프로세서(710)는 모든 SLA 등급에 대해 함수가 실행되며, 메모리(720)에 등급 별 정보가 등록될 수 있다. 일 실시 예에 따르면, 등급 별 정보는 API 우선순위 관리 모듈(410)의 데이터 베이스에 등록될 수 있다. 즉, 등급 별로, 함수에 대한 실행 요청 시점과 응답 시점 사이의 지연(latency) 시간을 얼마나 보장해줄 것인지에 대한 기준이 생성될 수 있다. 등급 별 정보 등록이 완료되면, 등급 설정이 활성화될 수 있다.
시험 기간 동안에는 가장 낮은 등급에 해당하는 과금율로 사용자에게 과금될 수 있다.
도 10은 등급 설정이 활성화되었을 때 사용자에게 제공될 수 있는 UI의 일 예를 설명하기 위한 도면이다.
도 10을 참고하면, UI를 통해 사용자는 함수에 대한 SLA 등급을 선택할 수 있다. 예컨대, 도 10을 참고하면 프리미엄(Premium) 등급은 허용 지연 시간이 3초이고, 높음(High) 등급은 허용 지연 시간이 6초이고, 표준(Default) 등급은 허용 지연 시간이 5초이고, 절약(Economy) 등급은 허용 지연 시간이 20초이다. 이들 중에서 사용자가 선택할 수 있다.
도 9 및 도 10을 참고하여 상술한 실시 예와 같이, 프로세서(710)는 새로운 함수가 등록되면, 기 설정된 기간(예컨대, 시험 기간) 동안 상기 새로운 함수의 실행 시간에 대한 정보를 획득하고, 상기 획득된 실행 시간에 대한 정보를 바탕으로 새로운 함수에 대해 서로 다른 등급의 복수의 서비스 레벨 계약(SLA)을 결정하고, 결정된 복수의 서비스 레벨 계약 중 어느 하나를 선택받기 위한 UI(User Interface)를 제공할 수 있다.
프로세서(710)는 통신부(730)를 통해 UI에 대한 정보를 외부 장치로 전달함으로써 외부 장치에서 UI를 제공할 수 있다.
그리고 프로세서(710)는, UI를 통해 새로운 함수에 대한 서비스 레벨 계약이 설정되면, 이에 대한 정보를 통신부(730)를 통해 수신하여, 설정된 서비스 레벨 계약에 대한 정보와 새로운 함수를 연관하여 메모리(720)에 저장할 수 있다. 이와 같이 메모리(720)에 저장된 정보를 바탕으로 함수 실행에 대한 요청 수신 시, 해당 함수에 대한 서비스 레벨 계약을 식별할 수 있게 된다.
도 11은 본 개시의 일 실시 예에 따른 전자 장치의 제어방법을 설명하기 위한 흐름도이다. 도 11에 도시된 흐름도는 본 명세서에서 설명되는 전자 장치(700)에서 처리되는 동작들로 구성될 수 있다. 따라서, 이하에서 생략된 내용이라 하더라도 전자 장치(700)에 관하여 기술된 내용은 도 11에 도시된 흐름도에도 적용될 수 있다.
도 11을 참고하면, 전자 장치에서, 함수의 실행 요청을 복수 개 수신할 수 있다(S1110).
그리고, 전자 장치에서, 복수 개의 요청에 대응하는 복수의 함수 각각에 대한 서비스 수준 계약(Service-Level Agreement(SLA))을 식별할 수 있다(S1120).
이 경우, 전자 장치에서, 복수 개의 요청의 HTTP 헤더에 포함된 서비스 수준 계약에 대한 정보를 확인하여 복수의 함수 각각에 대한 상기 서비스 수준 계약을 식별할 수 있다.
그리고 전자 장치에서, 식별된 SLA를 바탕으로 복수의 함수에 우선순위를 결정할 수 있다(S1130).
이 경우, 전자 장치에서, 복수의 함수 각각에 대한 SLA 및 함수 토폴로지 정보에 기초하여 복수의 함수에 우선순위를 결정할 수 있다.
토폴로지 정보 생성을 위해, 전자 장치는 특정 함수가 다른 함수를 내부 호출(internal call)하는 것을 바탕으로 함수들의 연쇄 실행에 관한 정보를 획득할 수 있다. 또한 전자 장치는 새로운 함수의 등록 및 기 등록된 함수의 수정에 따라 상기 함수 토폴로지 정보를 변경할 수 있다.
한편, SLA에는 허용 지연 시간이 정해져 있을 수 있다. 허용 지연 시간 내에 함수의 실행을 보장하되, 이것이 지켜지지 않을 시에는 환불하겠다는 약속이 SLA에 명시될 수 있다.
전자 장치는, 실행 요청이 있는 복수의 함수 각각에 대해서, SLA에 정해진 허용 지연 시간에서 함수 토폴리지 정보를 기초로 산출된 예측 실행 시간을 뺀 남은 시간을 산출하고, 복수의 함수 각각에 대해 산출된 남은 시간이 적은 순서대로 복수의 함수에 우선순위를 결정할 수 있다.
그리고 전자 장치에서, 결정된 우선순위에 따라 복수의 함수를 실행할 수 있다(S1140).
일 실시 예에 따르면, 전자 장치에서, 복수 개의 요청을 메시지 포맷으로 변환하고, 복수의 함수 각각에 결정된 우선순위에 따라, 변환에 의해 생성된 복수의 메시지 각각을 제1 메시지 큐 또는 제2 메시지 큐에 삽입하고, 제1 메시지 큐에 삽입된 메시지를 제2 메시지 큐에 삽입된 메시지보다 우선하여 디큐(dequeue)하고, 디큐된 메시지에 대응하는 함수를 실행할 수 있다. 이로써, 결정된 우선 순위에 따라 복수의 함수를 실행할 수 있다.
한편, 전자 장치에서, 기 등록된 함수의 수정에 따라 상기 기 등록된 함수에 대한 복수의 버전을 저장할 수 있고, 기 등록된 함수에 대해서 SLA가 지켜질 수 없는 수정이 발생하고 기 등록된 함수에 대한 실행 요청이 수신되면, SLA가 지켜질 수 없는 수정이 발생하기 이전 버전으로 기등록된 함수를 실행시킬 수 있다.
또한, 전자 장치에서, 새로운 함수가 등록되면, 기 설정된 기간 동안 상기 새로운 함수의 실행 시간에 대한 정보를 획득할 수 있다. 이 기 설정된 기간은 트라이얼 기간에 해당된다. 그리고 전자 장치에서, 획득된 실행 시간에 대한 정보를 바탕으로 새로운 함수에 대해 서로 다른 등급의 복수의 SLA를 결정할 수 있다. 그리고 전자 장치에서, 결정된 복수의 SLA 중 어느 하나를 선택받기 위한 UI(User Interface)를 제공할 수 있다. 일 실시 예에 따르면, 전자 장치는 UI에 대한 정보를 외부 장치로 전송할 수 있고, 이에 따라 UI는 외부 장치의 디스플레이에서 표시될 수 있다.
이 경우, 제공된 UI를 통해 새로운 함수에 대한 서비스 레벨 계약이 설정되면, 설정된 서비스 레벨 계약에 대한 정보와 상기 새로운 함수를 연관하여 전자 장치에서 저장할 수 있다.
상술한 본 개시의 다양한 실시 예들에 따르면, 함수 토폴로지에 기초하여, 함수에 대한 요청을 처리하는 순서를 결정할 수 있으므로, 서버리스 컴퓨팅 시스템에서 SLA가 최대한 보장될 수 있다.
이상에서 설명된 다양한 실시 예들은 소프트웨어(software), 하드웨어(hardware) 또는 이들의 조합으로 구현될 수 있다. 하드웨어적인 구현에 의하면, 본 개시에서 설명되는 실시 예들은 ASICs(Application Specific Integrated Circuits), DSPs(digital signal processors), DSPDs(digital signal processing devices), PLDs(programmable logic devices), FPGAs(field programmable gate arrays), 프로세서(processors), 제어기(controllers), 마이크로 컨트롤러(micro-controllers), 마이크로 프로세서(microprocessors), 기타 기능 수행을 위한 전기적인 유닛(unit) 중 적어도 하나를 이용하여 구현될 수 있다. 특히, 이상에서 설명된 다양한 실시 예들은 전자 장치(700)의 프로세서(710)에 의해 구현될 수 있다. 소프트웨어적인 구현에 의하면, 본 명세서에서 설명되는 절차 및 기능과 같은 실시 예들은 별도의 소프트웨어 모듈들로 구현될 수 있다. 상기 소프트웨어 모듈들 각각은 본 명세서에서 설명되는 하나 이상의 기능 및 작동을 수행할 수 있다.
본 개시의 다양한 실시 예들은 기기(machine)(예: 컴퓨터)로 읽을 수 있는 저장 매체(machine-readable storage media)에 저장될 수 있는 명령어를 포함하는 소프트웨어로 구현될 수 있다. 기기(machine)는, 저장 매체로부터 저장된 명령어를 호출하고, 호출된 명령어에 따라 동작이 가능한 장치로서, 개시된 실시 예들의 전자 장치(700)를 포함할 수 있다.
이러한 명령어가 프로세서에 의해 실행될 경우, 프로세서가 직접, 또는 상기 프로세서의 제어 하에 다른 구성요소들을 이용하여 명령어에 해당하는 기능을 수행할 수 있다. 명령어는 컴파일러 또는 인터프리터에 의해 생성 또는 실행되는 코드를 포함할 수 있다. 예컨대, 저장매체에 저장된 명령어가 프로세서에 의해 실행됨으로써, 상술한 전자 장치의 제어방법이 실행될 수 있다. 일 예로, 저장매체에 저장된 명령어가 기기(또는 전자 장치)의 프로세서에 의해 실행됨으로써, 함수의 실행 요청을 복수 개 수신하는 단계, 상기 복수 개의 요청에 대응하는 복수의 함수 각각에 대한 서비스 수준 계약(Service-Level Agreement(SLA))을 식별하는 단계, 상기 식별된 서비스 수준 계약을 바탕으로 상기 복수의 함수에 우선순위를 결정하는 단계 및 상기 결정된 우선순위에 따라 상기 복수의 함수를 실행하는 단계를 포함하는 전자 장치의 제어방법이 수행될 수 있다.
기기로 읽을 수 있는 저장매체는, 비일시적(non-transitory) 저장매체의 형태로 제공될 수 있다. 여기서, '비일시적'은 저장매체가 신호(signal)를 포함하지 않으며 실재(tangible)한다는 것을 의미할 뿐 데이터가 저장매체에 반영구적 또는 임시적으로 저장됨을 구분하지 않는다.
일 실시 예에 따르면, 본 문서에 개시된 다양한 실시 예들에 따른 방법은 컴퓨터 프로그램 제품(computer program product)에 포함되어 제공될 수 있다. 컴퓨터 프로그램 제품은 상품으로서 판매자 및 구매자 간에 거래될 수 있다. 컴퓨터 프로그램 제품은 기기로 읽을 수 있는 저장 매체(예: compact disc read only memory (CD-ROM))의 형태로, 또는 어플리케이션 스토어(예: 플레이 스토어™, 앱스토어™)를 통해 온라인으로 배포될 수 있다. 온라인 배포의 경우에, 컴퓨터 프로그램 제품의 적어도 일부는 제조사의 서버, 어플리케이션 스토어의 서버, 또는 중계 서버의 메모리와 같은 저장 매체에 적어도 일시 저장되거나, 임시적으로 생성될 수 있다.
다양한 실시 예들에 따른 구성 요소(예: 모듈 또는 프로그램) 각각은 단수 또는 복수의 개체로 구성될 수 있으며, 전술한 해당 서브 구성 요소들 중 일부 서브 구성 요소가 생략되거나, 또는 다른 서브 구성 요소가 다양한 실시 예에 더 포함될 수 있다. 대체적으로 또는 추가적으로, 일부 구성 요소들(예: 모듈 또는 프로그램)은 하나의 개체로 통합되어, 통합되기 이전의 각각의 해당 구성 요소에 의해 수행되는 기능을 동일 또는 유사하게 수행할 수 있다. 다양한 실시 예들에 따른, 모듈, 프로그램 또는 다른 구성 요소에 의해 수행되는 동작들은 순차적, 병렬적, 반복적 또는 휴리스틱하게 실행되거나, 적어도 일부 동작이 다른 순서로 실행되거나, 생략되거나, 또는 다른 동작이 추가될 수 있다.
이상에서는 본 개시의 바람직한 실시 예에 대하여 도시하고 설명하였지만, 본 개시는 상술한 특정의 실시 예에 한정되지 아니하며, 청구범위에서 청구하는 본 개시의 요지를 벗어남이 없이 당해 개시에 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 본 개시의 기술적 사상이나 전망으로부터 개별적으로 이해되어서는 안될 것이다.
700: 전자 장치
710: 프로세서
720: 메모리
730: 통신부

Claims (20)

  1. 전자 장치에 있어서,
    통신부;
    적어도 하나의 명령어를 저장하는 메모리; 및
    상기 적어도 하나의 명령어를 실행하는 프로세서;를 포함하며,
    상기 프로세서는,
    상기 통신부를 통해 함수의 실행 요청을 복수 개 수신하고,
    상기 복수 개의 요청에 대응하는 복수의 함수 각각에 대한 서비스 수준 계약(Service-Level Agreement(SLA))을 식별하며,
    특정 함수가 다른 함수를 내부 호출(internal call)하는 것에 기초하여 함수들의 연쇄 실행에 관한 정보를 획득하고,
    상기 획득된 함수들의 연쇄 실행에 관한 정보에 기초하여 함수 토폴로지 정보를 획득하고,
    상기 식별된 서비스 수준 계약 및 상기 함수 토폴로지 정보에 기초하여 상기 복수의 함수에 우선순위를 결정하고,
    상기 결정된 우선순위에 따라 상기 복수의 함수를 실행하는 전자 장치.
  2. 삭제
  3. 삭제
  4. 제1항에 있어서,
    상기 프로세서는,
    새로운 함수의 등록 및 기 등록된 함수의 수정에 따라 상기 함수 토폴로지 정보를 변경하는 전자 장치.
  5. 제1항에 있어서,
    상기 프로세서는,
    상기 복수의 함수 각각에 대해서, 서비스 수준 계약에 정해진 허용 지연 시간에서 상기 함수 토폴로지 정보를 기초로 산출된 예측 실행 시간을 뺀 남은 시간을 산출하고, 상기 복수의 함수 각각에 대해 산출된 남은 시간이 적은 순서대로 상기 복수의 함수에 우선순위를 결정하는 전자 장치.
  6. 제1항에 있어서,
    상기 프로세서는,
    상기 복수 개의 요청의 HTTP 헤더에 포함된 서비스 수준 계약에 대한 정보를 확인하여 상기 복수의 함수 각각에 대한 상기 서비스 수준 계약을 식별하는 전자 장치.
  7. 제1항에 있어서,
    상기 프로세서는,
    상기 복수 개의 요청을 메시지 포맷으로 변환하며,
    상기 복수의 함수 각각에 결정된 우선순위에 따라, 상기 변환에 의해 생성된 복수의 메시지 각각을 제1 메시지 큐 또는 제2 메시지 큐에 삽입하고, 상기 제1 메시지 큐에 삽입된 메시지를 상기 제2 메시지 큐에 삽입된 메시지보다 우선하여 디큐(dequeue)하고, 상기 디큐된 메시지에 대응하는 함수를 실행하는 전자 장치.
  8. 제1항에 있어서,
    상기 프로세서는,
    기 등록된 함수의 수정에 따라 상기 기 등록된 함수에 대한 복수의 버전을 저장하며, 상기 기 등록된 함수에 대해서 서비스 레벨 계약이 지켜질 수 없는 수정이 발생하고 상기 기 등록된 함수에 대한 실행 요청이 수신되면, 상기 서비스 레벨 계약이 지켜질 수 없는 수정이 발생하기 이전 버전으로 상기 기등록된 함수를 실행시키는 전자 장치.
  9. 제1항에 있어서,
    상기 프로세서는,
    새로운 함수가 등록되면, 기 설정된 기간 동안 상기 새로운 함수의 실행 시간에 대한 정보를 획득하고, 상기 획득된 실행 시간에 대한 정보를 바탕으로 상기 새로운 함수에 대해 서로 다른 등급의 복수의 서비스 레벨 계약을 결정하고, 상기 결정된 복수의 서비스 레벨 계약 중 어느 하나를 선택받기 위한 UI(User Interface)를 제공하는 전자 장치.
  10. 제9항에 있어서,
    상기 프로세서는,
    상기 제공된 UI를 통해 상기 새로운 함수에 대한 서비스 레벨 계약이 설정되면, 상기 설정된 서비스 레벨 계약에 대한 정보와 상기 새로운 함수를 연관하여 상기 메모리에 저장하는 전자 장치.
  11. 전자 장치를 제어하는 방법에 있어서,
    함수의 실행 요청을 복수 개 수신하는 단계;
    상기 복수 개의 요청에 대응하는 복수의 함수 각각에 대한 서비스 수준 계약(Service-Level Agreement(SLA))을 식별하는 단계;
    특정 함수가 다른 함수를 내부 호출(internal call)하는 것에 기초하여 함수들의 연쇄 실행에 관한 정보를 획득하는 단계;
    상기 획득된 함수들의 연쇄 실행에 관한 정보에 기초하여 함수 토폴로지 정보를 획득하는 단계;
    상기 식별된 서비스 수준 계약 및 상기 함수 토폴로지 정보에 기초하여 상기 복수의 함수에 우선순위를 결정하는 단계; 및
    상기 결정된 우선순위에 따라 상기 복수의 함수를 실행하는 단계;를 포함하는, 방법.
  12. 삭제
  13. 삭제
  14. 제11항에 있어서,
    새로운 함수의 등록 및 기 등록된 함수의 수정에 따라 상기 함수 토폴로지 정보를 변경하는 단계를 더 포함하는, 방법.
  15. ◈청구항 15은(는) 설정등록료 납부시 포기되었습니다.◈
    제11항에 있어서,
    상기 우선순위를 결정하는 단계는,
    상기 복수의 함수 각각에 대해서, 서비스 수준 계약에 정해진 허용 지연 시간에서 상기 함수 토폴로지 정보를 기초로 산출된 예측 실행 시간을 뺀 남은 시간을 산출하고, 상기 복수의 함수 각각에 대해 산출된 남은 시간이 적은 순서대로 상기 복수의 함수에 우선순위를 결정하는, 방법.
  16. ◈청구항 16은(는) 설정등록료 납부시 포기되었습니다.◈
    제11항에 있어서,
    상기 식별하는 단계는,
    상기 복수 개의 요청의 HTTP 헤더에 포함된 서비스 수준 계약에 대한 정보를 확인하여 상기 복수의 함수 각각에 대한 상기 서비스 수준 계약을 식별하는, 방법.
  17. ◈청구항 17은(는) 설정등록료 납부시 포기되었습니다.◈
    제11항에 있어서,
    상기 복수 개의 요청을 메시지 포맷으로 변환하는 단계;를 더 포함하고,
    상기 복수의 함수를 실행하는 단계는,
    상기 복수의 함수 각각에 결정된 우선순위에 따라, 상기 변환에 의해 생성된 복수의 메시지 각각을 제1 메시지 큐 또는 제2 메시지 큐에 삽입하고, 상기 제1 메시지 큐에 삽입된 메시지를 상기 제2 메시지 큐에 삽입된 메시지보다 우선하여 디큐(dequeue)하고, 상기 디큐된 메시지에 대응하는 함수를 실행하는, 방법.
  18. ◈청구항 18은(는) 설정등록료 납부시 포기되었습니다.◈
    제11항에 있어서,
    기 등록된 함수의 수정에 따라 상기 기 등록된 함수에 대한 복수의 버전을 저장하는 단계; 및
    상기 기 등록된 함수에 대해서 서비스 레벨 계약이 지켜질 수 없는 수정이 발생하고 상기 기 등록된 함수에 대한 실행 요청이 수신되면, 상기 서비스 레벨 계약이 지켜질 수 없는 수정이 발생하기 이전 버전으로 상기 기등록된 함수를 실행시키는 단계;를 더 포함하는, 방법.
  19. ◈청구항 19은(는) 설정등록료 납부시 포기되었습니다.◈
    제11항에 있어서,
    새로운 함수가 등록되면, 기 설정된 기간 동안 상기 새로운 함수의 실행 시간에 대한 정보를 획득하는 단계;
    상기 획득된 실행 시간에 대한 정보를 바탕으로 상기 새로운 함수에 대해 서로 다른 등급의 복수의 서비스 레벨 계약을 결정하는 단계; 및
    상기 결정된 복수의 서비스 레벨 계약 중 어느 하나를 선택받기 위한 UI(User Interface)를 제공하는 단계;를 더 포함하는, 방법.
  20. ◈청구항 20은(는) 설정등록료 납부시 포기되었습니다.◈
    제19항에 있어서,
    상기 제공된 UI를 통해 상기 새로운 함수에 대한 서비스 레벨 계약이 설정되면, 상기 설정된 서비스 레벨 계약에 대한 정보와 상기 새로운 함수를 연관하여 저장하는 단계;를 더 포함하는, 방법.
KR1020180134699A 2018-11-05 2018-11-05 전자 장치 및 이의 제어방법 KR102612312B1 (ko)

Priority Applications (5)

Application Number Priority Date Filing Date Title
KR1020180134699A KR102612312B1 (ko) 2018-11-05 2018-11-05 전자 장치 및 이의 제어방법
US16/670,495 US11095531B2 (en) 2018-11-05 2019-10-31 Service-aware serverless cloud computing system
EP19883059.8A EP3861443B1 (en) 2018-11-05 2019-11-01 Service-aware serverless cloud computing system
PCT/KR2019/014684 WO2020096282A1 (en) 2018-11-05 2019-11-01 Service-aware serverless cloud computing system
CN201980083234.8A CN113196238B (zh) 2018-11-05 2019-11-01 服务感知的无服务器云计算系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020180134699A KR102612312B1 (ko) 2018-11-05 2018-11-05 전자 장치 및 이의 제어방법

Publications (2)

Publication Number Publication Date
KR20200054368A KR20200054368A (ko) 2020-05-20
KR102612312B1 true KR102612312B1 (ko) 2023-12-12

Family

ID=70458174

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020180134699A KR102612312B1 (ko) 2018-11-05 2018-11-05 전자 장치 및 이의 제어방법

Country Status (5)

Country Link
US (1) US11095531B2 (ko)
EP (1) EP3861443B1 (ko)
KR (1) KR102612312B1 (ko)
CN (1) CN113196238B (ko)
WO (1) WO2020096282A1 (ko)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11018965B1 (en) * 2020-01-24 2021-05-25 Red Hat, Inc. Serverless function scaling
KR102278185B1 (ko) * 2020-09-14 2021-07-19 주식회사 아이콘루프 블록체인 노드를 이용한 서버리스 서비스 시스템 및 방법
CN113067890B (zh) * 2021-04-07 2022-08-19 武汉光庭信息技术股份有限公司 一种适用于智能座舱的动态注册服务方法及智能座舱
CN113238853B (zh) * 2021-06-15 2021-11-12 上海交通大学 基于函数中间表达的无服务器计算调度系统及方法
WO2023123022A1 (zh) * 2021-12-29 2023-07-06 深圳晶泰科技有限公司 获取分子性质的方法、装置及存储介质
KR102521744B1 (ko) * 2022-12-30 2023-04-14 주식회사 에스티씨랩 디지털 서비스 기반 유량 제어 서버, 방법 및 api 유량 제어 시스템

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6073175A (en) * 1998-04-27 2000-06-06 International Business Machines Corporation Method for supporting different service levels in a network using web page content information
JP2004531780A (ja) * 2000-06-22 2004-10-14 マイクロソフト コーポレーション 分散型コンピューティングサービスプラットフォーム
GB0425860D0 (en) 2004-11-25 2004-12-29 Ibm A method for ensuring the quality of a service in a distributed computing environment
KR20060114146A (ko) * 2005-04-29 2006-11-06 중앙대학교 산학협력단 웹 서비스 차별화를 위한 웹 서버에서의 우선순위 할당방법
US8036871B1 (en) * 2006-09-11 2011-10-11 The Mathworks, Inc. Generating and delaying function calls in a discrete event modeling environment
US7720990B2 (en) * 2007-01-10 2010-05-18 International Business Machines Corporation Method and apparatus for handling service requests in a data processing system
US8904394B2 (en) * 2009-06-04 2014-12-02 International Business Machines Corporation System and method for controlling heat dissipation through service level agreement analysis by modifying scheduled processing jobs
JP4939594B2 (ja) * 2009-11-30 2012-05-30 インターナショナル・ビジネス・マシーンズ・コーポレーション プライマリクラウドが提供したサービスレベルの実績値又は更新されたプリファレンス情報に基づいて、サービスレベルアグリーメントを動的に決定してサービスを提供することができるクラウドシステムを構成する装置、方法及びコンピュータプログラム
US8776076B2 (en) * 2010-07-20 2014-07-08 Nec Laboratories America, Inc. Highly scalable cost based SLA-aware scheduling for cloud services
US9363312B2 (en) * 2010-07-28 2016-06-07 International Business Machines Corporation Transparent header modification for reducing serving load based on current and projected usage
US8429659B2 (en) 2010-10-19 2013-04-23 International Business Machines Corporation Scheduling jobs within a cloud computing environment
KR101350755B1 (ko) 2011-01-14 2014-01-10 대전대학교 산학협력단 클라우드 컴퓨팅에서 다중 워크플로우를 위한 비용기반 스케줄링 방법 및 그 시스템
US8892708B2 (en) * 2011-07-11 2014-11-18 Cisco Technology, Inc. Placement of service delivery locations of a distributed computing service based on logical topology
US9128763B2 (en) 2011-08-23 2015-09-08 Infosys Limited System and method for job scheduling optimization
KR101795333B1 (ko) 2012-08-22 2017-11-07 엠파이어 테크놀로지 디벨롭먼트 엘엘씨 클라우드 프로세스 관리
US20140200947A1 (en) * 2013-01-15 2014-07-17 Xerox Corporation Methods and systems for regulating service layer agreements for multiple cloud service requests
US10102240B2 (en) 2014-11-11 2018-10-16 Inernational Business Machines Corporation Managing event metrics for service management analytics
KR101630125B1 (ko) 2015-04-27 2016-06-13 수원대학교산학협력단 클라우드 컴퓨팅 자원관리 시스템에서의 자원 요구량 예측 방법
JP6577235B2 (ja) * 2015-05-15 2019-09-18 アズビル株式会社 照明制御システムおよび照明制御方法
US9852035B2 (en) * 2015-08-25 2017-12-26 International Business Machines Corporation High availability dynamic restart priority calculator
US10733591B2 (en) 2016-10-11 2020-08-04 International Business Machines Corporation Tiered model for event-based serverless computing
US10505791B2 (en) 2016-12-16 2019-12-10 Futurewei Technologies, Inc. System and method to handle events using historical data in serverless systems
US10120669B2 (en) * 2017-03-09 2018-11-06 Nec Corporation System and method for deploying application components on distributed it resources
US20190036835A1 (en) * 2017-07-27 2019-01-31 International Business Machines Corporation Client side information to influence service level for client system

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
미국공개특허 제2013-0191843호(2013.07.25.) 1부.*
미국공개특허 제2016-0134490호(2016.05.12.) 1부.*
미국공개특허 제2016-0162823호(2016.06.09.) 1부.*
한국공개특허 제10-2006-0114146호(2006.11.06.) 1부.*

Also Published As

Publication number Publication date
EP3861443A1 (en) 2021-08-11
CN113196238B (zh) 2024-05-31
EP3861443A4 (en) 2021-11-17
KR20200054368A (ko) 2020-05-20
US20200145300A1 (en) 2020-05-07
EP3861443B1 (en) 2024-07-17
WO2020096282A1 (en) 2020-05-14
US11095531B2 (en) 2021-08-17
CN113196238A (zh) 2021-07-30

Similar Documents

Publication Publication Date Title
KR102612312B1 (ko) 전자 장치 및 이의 제어방법
US10282229B2 (en) Asynchronous task management in an on-demand network code execution environment
US20210004273A1 (en) Methods, apparatuses and computer readable mediums for network based media processing
US10771533B2 (en) Adaptive communication control device
US20170083381A1 (en) System and method for processing task resources
US20140245319A1 (en) Method for enabling an application to run on a cloud computing system
US9417913B2 (en) Tunable computerized job scheduling
US10810038B2 (en) Accounting and enforcing non-process execution by container-based software receiving data over a network
JP2017534107A (ja) 動的コードデプロイメント及びバージョニング
CN109067890A (zh) 一种基于docker容器的CDN节点边缘计算系统
US9729610B2 (en) Method for intercepting an instruction produced by an application on a computer
CN113051053A (zh) 异构资源调度方法、装置、设备和计算机可读存储介质
CN115794262A (zh) 任务处理方法、装置、设备、存储介质以及程序产品
US10009420B2 (en) Balancing work of tasks at a sending node of a transaction server
EP3398304B1 (en) Network service requests
CN110716809B (zh) 用于调度云资源的方法和装置
US10241827B1 (en) Accounting and enforcing non-process execution by container-based software transmitting data over a network
US20230273813A1 (en) Schedule management for machine learning model-based processing in computing environment
US20230007102A1 (en) Request scheduling
CN117130786A (zh) 资源分配方法、装置、设备和可读介质
CN118312319A (zh) 代码处理内存分配方法、装置、电子设备和可读介质

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant