KR20150005547A - 분산 협약 프로토콜에서의 crud형 프로토콜 바인딩 기법 - Google Patents

분산 협약 프로토콜에서의 crud형 프로토콜 바인딩 기법 Download PDF

Info

Publication number
KR20150005547A
KR20150005547A KR1020147029229A KR20147029229A KR20150005547A KR 20150005547 A KR20150005547 A KR 20150005547A KR 1020147029229 A KR1020147029229 A KR 1020147029229A KR 20147029229 A KR20147029229 A KR 20147029229A KR 20150005547 A KR20150005547 A KR 20150005547A
Authority
KR
South Korea
Prior art keywords
protocol
distributed
proposal
value
server
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
KR1020147029229A
Other languages
English (en)
Other versions
KR101996624B1 (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 마이크로소프트 코포레이션
Publication of KR20150005547A publication Critical patent/KR20150005547A/ko
Application granted granted Critical
Publication of KR101996624B1 publication Critical patent/KR101996624B1/ko
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/323—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the physical layer [OSI layer 1]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/18—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits
    • G06F11/182—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits based on mutual exchange of the output between redundant processing components

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Computer And Data Communications (AREA)
  • Hardware Redundancy (AREA)

Abstract

다양한 실시예가 예비 또는 복제 서비스, 가령, "클라우드" 서비스가 지리적으로 분산된 위치에서 실행되는 것을 가능하게 한다. 각각의 복제가 모든 복제들 간에 일반적으로 동일하게 수행되는 작업을 수행할 수 있다. 하나의 위치에서의 인터럽션이 발생한 경우, 나머지 위치에서의 서비스가 작업을 신속하고 자동적으로 넘겨받을 수 있다. 하나 이상의 실시예에서, 분산 협약 프로토콜이 사용되어 CRUD형 프로토콜을 상태 머신으로서 바인딩할 수 있다. 바인딩은 서비스가 분산되는 위치 각각에 위치하는 역방향 프록시의 사용을 통해 발생한다. 적어도 일부 실시예에서, 분산 협약 프로토콜이 팍소스 프로토콜 또는 이의 변형으로서 구현되거나, 및/또는 CRUD형 프로토콜이 HTTP 프로토콜을 포함한다.

Description

분산 협약 프로토콜에서의 CRUD형 프로토콜 바인딩 기법{BINDING CRUD-TYPE PROTOCOLS IN DISTRIBUTED AGREEMENT PROTOCOLS}
인터넷을 통해 제공되는 서비스, 가령, 이른바 "클라우드" 서비스는 사용자 경험을 저하시킬 수 있는 인터럽션에 시달릴 수 있다. 사용자 경험의 저하에 추가로, 이러한 인터럽션은 사업 비용, 가령, 실제 자금 손실뿐 아니라 영업권(goodwill)의 손실과 관련하여 큰 조직 영향(organizational impact)을 가질 수 있다.
개요
이 개요는 이하의 상세한 설명에서 더 기재될 개념들의 모음을 단순화된 형태로 소개하기 위해 제공된다. 이 개요는 청구되는 발명의 핵심 특징 또는 필수 특징을 식별하려는 의도는 갖지 않는다.
다양한 실시예가 예비 또는 복제 서비스(redundant or replica service), 가령, "클라우드" 서비스는 지리적으로 분산된 위치에서 실행되는 것을 가능하게 한다. 각각의 복제는 모든 복제들 간에 일반적으로 동일하게 수행되는 작업을 수행할 수 있다. 하나의 위치에서 인터럽션이 발생한 경우, 나머지 위치에서의 서비스가 작업을 신속하고 자동적으로 넘겨받을 수 있다.
하나 이상의 실시예에서, 분산 협약 프로토콜이 사용되어 CRUD형 프로토콜을 상태 머신으로서 바인딩할 수 있다. 바인딩은 서비스가 분산되는 위치 각각에 위치하는 역방향 프록시의 사용을 통해 발생한다. 적어도 일부 실시예에서, 분산 협약 프로토콜이 팍소스 프로토콜(Paxos protocol) 또는 이의 변형으로서 구현되거나, 및/또는 CRUD형 프로토콜이 HTTP(Hypertext Transport Protocol) 프로토콜을 포함한다.
도면 전체에서 유사한 특징부를 참조하기 위해 동일한 번호가 사용된다.
도 1은 하나 이상의 실시예에 따르는 예시적 동작 환경을 도시한다.
도 2는 하나 이상의 실시예에 따르는 예시적 동작 환경을 도시한다.
도 3은 하나 이상의 실시예에 따르는 방법의 단계들을 기술하는 흐름도이다.
도 4는 하나 이상의 실시예에 따르는 예시적 시스템을 도시한다.
도 5는 하나 이상의 실시예에 따르는 예시적 장치를 도시한다.
서문
다양한 실시예에 의해 예비 또는 복제 서비스, 가령, "클라우드" 서비스는 지리적으로 분산된 위치에서 실행될 수 있다. 각각의 복제(replica)는 모든 복제들 간에 일반적으로 동일한 작업을 수행할 수 있다. 하나의 위치에서 인터럽션이 발생한 경우, 나머지 위치에서의 서비스가 작업을 신속하고 자동으로 넘겨받을 수 있다.
하나 이상의 실시예에서, 분산 협약 프로토콜(Distributed Agreement Protocol)이 CRUD-유형 프로토콜을 상태 머신(state machine)으로서 바인딩(bind)하기 위해 사용된다. 바인딩은 서비스가 분산되어 있는 위치 각각에 위치하는 역방향 프록시(reverse proxy)의 사용을 통해 이뤄진다. 적어도 일부 실시예에서, 분산 협약 프로토콜은 팍소스 프로토콜(Paxos protocol) 또는 이의 변형으로서 구현되며/또는 CRUD형 프로토콜은 하이퍼텍스트 전송 프로토콜(Hypertext Transport Protocol)(HTTP)을 포함한다. 그러나 본 명세서에 기재되는 기법은 임의의 적합한 무상태(stateless) REST(Representational State Transfer) 프로토콜과 함께 사용될 수 있음을 이해해야 한다. 당업자라면 알 수 있듯이, REST는 시스템의 자원에 초점을 맞추도록 웹 서비스가 지정될 수 있게 하는 아키텍처 원리의 세트, 가령, 다른 언어로 써진 다양한 클라이언트에 의해 자원 상태가 HTTP를 통해 어드레싱 및 전송되는 방식을 정의한다. 당업자라면, REST형 아키텍처는 클라이언트 및 서버와 함께 사용됨을 알 것이다. 클라이언트는 서버로의 요청을 개시하고, 그 후 서버는 요청을 프로세싱하고 적절한 응답을 반환한다. 요청 및 응답이 자원들의 표현(representation)을 중심으로 구축된다. 자원은 어드레싱될 수 있는 임의의 일관성 있고 유의미한 개념을 포함할 수 있다. 일반적으로 자원의 표현은 자원의 현재 또는 의도된 상태를 캡처한 문서이다. 클라이언트는 새 상태로 전이될 준비가 될 때 요청을 전송함으로써 통신을 개시한다. 하나 이상의 요청이 미해결인 동안, 클라이언트는 전이 중인 것으로 여겨진다. 각각의 상태의 표현은 클라이언트가 새 상태 전이를 개시하도록 선택한 다음 번에 사용될 수 있는 링크를 포함할 수 있다.
이하의 논의에서, 먼저 본 명세서에 기재된 기법을 사용할 수 있는 예시적 환경을 설명한다. 그 후 예시적 환경뿐 아니라 그 밖의 다른 환경에서도 수행될 수 있는 예시적 절차를 설명한다. 따라서, 예시적 절차의 수행이 예시적 환경에 의해 한정되지 않고, 예시적 환경은 예시적 절차의 수행에 의해 한정되지 않는다.
예시적 환경
도 1은 전체적으로 100으로 지칭되는, 하나 이상의 실시예에 따르는 동작 환경을 도시한다. 환경(100)은 하나 이상의 프로세서(104), 하나 이상의 컴퓨터 판독형 저장 매체(106), 컴퓨터 판독형 저장 매체 상에 위치하고 프로세서(104)에 의해 실행될 수 있는 하나 이상의 애플리케이션(108)을 갖는 로컬 클라이언트 머신의 형태로 된 컴퓨팅 장치(102)를 포함한다. 컴퓨팅 장치(102)는 이하에서 기재되는 바와 같이 동작하는 웹 브라우저(110) 및 운영 체제(111)를 더 포함한다.
컴퓨팅 장치(102)는 임의의 적합한 컴퓨팅 장치, 비-제한적 예를 들면, 데스크톱 컴퓨터, 휴대용 컴퓨터, 핸드헬드 컴퓨터, 가령, 개인 디지털 보조기(PDA), 모바일 전화기, 텔레비전, 태블릿 컴퓨터 등으로서 구현될 수 있다. 컴퓨팅 장치(102)의 다양한 여러 다른 예시들 중 하나가 도 4 및 5에 도시되어 있고 이하에서 기재된다.
애플리케이션(108)은 임의의 적합한 유형의 애플리케이션을 포함할 수 있다. 웹 브라우저(110)는 네트워크(112)를 통해 내비게이트하도록 구성된다. 네트워크(112)가 인터넷으로 도시되어 있지만, 상기 네트워크는 다양한 구성을 가정할 수 있다. 예를 들어, 네트워크(112)는 광역 네트워크(WAN), 로컬 영역 네트워크(LAN), 무선 네트워크, 공중 전화 네트워크, 인트라넷 등을 포함할 수 있다. 추가로, 단일 네트워크(112)가 도시되어 있지만, 네트워크(112)는 복수의 네트워크를 포함하도록 구성될 수 있다.
브라우저는 하나 이상의 서버(114), 가령, 웹 서버로부터 이용 가능한 콘텐츠와 대화하고 데이터를 하나 이상의 서버(114)로 통신하기 위해, 가령, 다운로드 및 업로드를 수행하기 위해 네트워크(112)를 통해 내비게이트하도록 구성될 수 있다. 상기 서버(114)는 네트워크(112)를 통해 액세스 가능하고 컴퓨팅 장치(102)에 의해 소비될 수 있는 하나 이상의 서비스, 가령, 웹 서비스("클라우드 서비스"라고도 지칭됨)를 제공하도록 구성될 수 있다. 이러한 서비스의 예시는 맵 서비스, 전자메일, 웹 페이지, 사진 공유 사이트, 소셜 네트워크, 콘텐츠 공유 서비스, 미디어 스트리밍 서비스, 데이터 불러오기 및/또는 서비스 디스플레이 등을 포함한다.
애플리케이션(108) 중 하나 이상은 가령, 직접 및/또는 브라우저를 통해 네트워크(112)를 액세스하도록 더 구성될 수 있다. 예를 들어, 애플리케이션(108) 중 하나 이상은 메시지, 가령, 전자메일, 즉석 메시지 등을 통신하도록 구성될 수 있다. 추가 예를 들면, 애플리케이션(108)은 소셜 네트워크를 액세스, 날씨 업데이트를 획득, 웹 서버(114) 중 하나 이상에 의해 구현되는 서점 서비스와 대화, 워드 프로세싱을 지원, 스프레드시트 기능을 제공, 프리젠테이션(presentation)의 생성 및 출력을 지원 등을 하도록 구성될 수 있다.
따라서 또한 애플리케이션(108)은 직접 또는 간접 네트워크(112) 액세스를 포함할 수 있는 다양한 기능에 대해 구성될 수 있다. 예를 들어, 애플리케이션(108)은 애플리케이션(108)에 의해 로컬하게 활용될 수 있고 또 다른 컴퓨팅 장치 상에서 실행되는 애플리케이션과 동기화될 수 있는 구성 설정 및 그 밖의 다른 데이터를 포함할 수 있다. 이러한 방식으로, 이들 설정이 장치들에 의해 공유될 수 있다. 다양한 그 밖의 다른 예시도 제공된다. 따라서 컴퓨팅 장치(102)는 다양한 방식으로 다양한 소스로부터의 콘텐츠와 대화할 수 있다.
도시되고 기재된 실시예에서, 서버(114)는 각각 예비 웹 서비스인 웹 서비스를 지원할 수 있다. 즉, 각각의 예비 웹 서비스는 서로의 복사(copy) 또는 복제(replica)이다. 이들 웹 서비스는 일반적으로 지리적으로 분산된 위치에서 실행될 수 있다. 각각의 복제 서비스는 모든 복제에서 일반적으로 동일하게 수행되는 작업을 수행할 수 있다. 하나의 위치에서 인터럽션이 발생한 경우, 그 밖의 다른 위치에서의 서비스가 신속하고 자동적으로 작업을 넘겨 받는다.
하나 이상의 실시예에서, 분산 협약 프로토콜이 CRUD형 프로토콜을 상태 머신으로서 바인딩하도록 사용된다. 서비스가 분산되어 있는 위치 각각에 위치하는 역방향 프록시의 사용을 통해 바인딩이 발생한다. 적어도 일부 실시예에서, 이하에서 자명해지겠지만, 분산 협약 프로토콜이 팍소스 프로토콜(Paxos protocol) 또는 이의 변형으로서 구현되며/또는 CRUD형 프로토콜은 HTTP 프로토콜을 포함한다.
일반적으로, 소프트웨어, 펌웨어, 하드웨어(가령, 고정 로직 회로), 또는 이들 구현의 조합을 이용해 본 명세서에 기재된 기능들 중 임의의 기능이 구현될 수 있다. "모듈", "기능부", 및 "로직"이라는 용어는 본 명세서에서 사용될 때 일반적으로 소프트웨어, 펌웨어, 하드웨어, 또는 이들의 조합을 나타낸다. 소프트웨어 구현의 경우, 모듈, 기능부, 또는 로직은 프로세서(가령, CPU 또는 CPU들) 상에서 실행될 때 특정된 작업을 수행하는 프로그램 코드를 나타낸다. 프로그램 코드는 하나 이상의 컴퓨터 판독형 메모리 장치에 저장될 수 있다. 이하에서 기재되는 기법의 특징은 플랫폼-독립적이며, 이는 기법이 다양한 프로세서를 갖는 다양한 상업적 컴퓨팅 플랫폼 상에서 구현될 수 있음을 의미한다.
예를 들어, 컴퓨팅 장치(102)는 컴퓨팅 장치(102)의 하드웨어 또는 가상 머신이 작업을 수행할 수 있게 하는 개체(가령, 소프트웨어), 가령, 프로세서, 기능 블록 등을 더 포함할 수 있다. 예를 들어, 컴퓨팅 장치(102)는 컴퓨팅 장치 및 더 구체적으로 상기 컴퓨팅 장치(102)의 운영 체제 및 연관된 하드웨어가 작업을 수행하도록 하는 명령을 유지하도록 구성될 수 있는 컴퓨터-판독형 매체를 포함할 수 있다. 따라서 명령은 운영 체제 및 연관된 하드웨어가 작업을 수행하도록 구성하는 역할을 하며, 이러한 방식으로 기능을 수행하도록 하는 운영 체제 및 연관된 하드웨어의 변환을 야기한다. 여러 가지 구성을 통해 명령은 컴퓨터 판독형 매체에 의해 컴퓨팅 장치(102)로 제공될 수 있다.
컴퓨터-판독형 매체의 한 가지 이러한 구성은 신호를 포함하는 매체이며, 따라서 가령 네트워크를 통해 명령을 컴퓨팅 장치로 전송하도록 구성된다. 또한 컴퓨터 판독형 매체는 컴퓨터 판독형 저장 매체로서 구성될 수 있고 신호 포함 매체가 아니다. 컴퓨터 판독형 저장 매체의 예시로는 랜덤-액세스 메모리(RAM), 리드-온리 메모리(ROM), 광학 디스크, 플래시 메모리, 하드 디스크 메모리, 및 자기, 광학, 및 명령 및 그 밖의 다른 데이터를 저장하기 위해 그 밖의 다른 기법을 사용할 수 있는 그 밖의 다른 메모리 장치를 포함한다.
예시적 환경을 기재하였고, 지금부터 분산 협약 프로토콜(Distributed Agreement Protocol)(DAP) 및 CRUD형 프로토콜을 상태 머신으로서 바인딩(bind)하기 위해 이러한 DAP가 CRUD형 프로토콜, 가령, HTTP 프로토콜과 함께 사용될 수 있는 방식이 제공된다.
분산 협약 프로토콜
분산 시스템의 본질에서 암시하는 확장성(scalability), 자율성(autonomy), 및 내장애성(fault-tolerance) 같은 이점들로 인해 정보 시스템이 점점 분산 아키텍처로 이동하고 있기 때문에, 이러한 분산 시스템 내에서의 조직 유지 및 동기화에 대한 과제가 점점 더 대두되고 있다. 분산 시스템의 한 가지 목표는 특정 협약 조건을 만족하는 한 가지 공통 값에 대한 협약을 효율적이고 유연하게 만들기 위해 피어(peer)로서 기능하는 각각의 프로세서 또는 노드를 갖는 것이다.
분산 협약 프로토콜은 분산 시스템 내 노드가 이러한 공통 값에 효율적인 방식으로 동의하도록 하기 위해 사용될 수 있다. 한 가지 이러한 분산 협약 프로토콜로는 후술하는 팍소스 프로토콜(Paxos protocol)이 있다. 이 팍소스 프로토콜은 본 명세서에 기재되는 다양한 실시예에서 사용될 수 있다. 그러나 본 발명의 사상 및 범위 내에서 그 밖의 다른 분산 협약 프로토콜이 사용될 수 있다. 예를 들어, 한 가지 이러한 분산 협약 프로토콜로는 해당 분야의 통상의 기술자라면 알 수 있는 질의/업데이트(Query/Update)(Q/U) 프로토콜이 있다.
팍소스 프로토콜
이하에서는 일반적으로 CRUD형 프로토콜, 가령, HTTP를 팍소스 프로토콜 내 상태 머신으로 바인딩하기 위해 사용될 수 있는 분산 협약 프로토콜의 한 가지 예시로서 팍소스 프로토콜을 설명한다.
상기 팍소스 프로토콜은 내장애성(fault-tolerant) 분산 시스템을 구현하도록 사용된다. 다음은 분산 시스템을 구축하기 위한 상태 머신 방식에 합의(consensus)를 적용함으로써 얻어지는 팍소스 알고리즘 또는 프로토콜을 설명한다. 우선 문제의 맥락에서 합의 알고리즘(consensus algorithm)이 제공된다. 값(value)을 제안할 수 있는 프로세스의 모음을 가정한다. 합의 알고리즘은 제안된 값들 중 하나의 값이 선택됨을 보장한다. 어떠한 값도 제안되지 않은 경우, 어떠한 값도 선택되지 않아야 한다. 하나의 값이 선택된 경우, 프로세스는 선택된 값을 학습(learn)할 수 있어야 한다. 합의에 대한 안전 고려사항(safety consideration)은 (1) 제안된 값만 선택될 수 있고, (2) 단 하나의 값만 선택되며, (3) 프로세스는 값이 실제로 선택되지 않는 한 그 값이 선택됐다고 절대로 학습하지 않는다는 것이다. 목표는 최종적으로 일부 제안된 값이 선택되고, 값이 선택됐다면, 프로세스가 최종적으로 상기 값을 학습할 수 있음을 보장하는 것이다.
세 가지 클래스의 에이전트, 즉, 제안자(proposer), 수락자(acceptor), 및 학습자(learner)에 의해 합의 알고리즘에서 세 가지 역할이 수행된다. 하나의 구현에서, 단일 프로세스가 둘 이상의 에이전트 역할을 할 수도 있다. 또한 에이전트는 메시지를 전송함으로써 서로 통신할 수 있다고 가정해보자. 본 논의에서는, 통상의 비동기식인 비-비잔틴 모델이 사용되는데, 여기서 (1) 에이전트는 임의의 속도(arbitrary speed)로 동작하며, 중단 장애를 일으키고 재시작할 수 있으며, 모든 에이전트가 값이 선택된 후 실패하고 재시작할 수 있기 때문에, 장애를 일으키고 재시작한 에이전트에 의해 일부 정보가 기억될 수 있지 않는 한 솔루션이 불가능하며, (2) 메시지는 전달되는 데 임의의 긴 시간이 걸릴 수 있으며 중복될 수 있고 소실될 수 있지만, 손상되지는 않는다.
이하에서 값 선택 개념을 살펴본다. 하나의 값을 선택하는 가장 쉬운 방식은 단일 수락자 에이전트를 갖는 것이다. 제안자는 수락자에게 제안을 전송하고, 상기 수락자는 자신이 수신한 처음 제안된 값을 선택한다. 수락자의 장애가 어떠한 추가적인 진행도 불가능하게 만들기 때문에, 이 솔루션은 간단하지만 불만족스럽다. 단일 수락자 대신, 복수의 수락자 에이전트를 사용할 수 있다. 제안자는 제안된 값을 수락자들의 집합으로 전송한다. 수락자는 제안된 값을 수락할 수 있다. 상기 값은 수락자들 중 충분히 큰 집합이 수락했을 때 선택된다. 얼마나 큰 것이 충분히 큰 것인가? 단 하나의 값이 선택됨을 보장하기 위해, 충분히 큰 집합을 수락자들 중 임의의 과반수로 구성된 것으로 간주할 수 있다. 임의의 2개의 과반수 집합이 공통된 적어도 하나의 수락자를 갖기 때문에, 한 명의 수락자가 최대 하나의 값을 수락할 수 있는 경우 효과가 있다. 장애나 메시지 손실이 없는 경우, 하나의 제안자에 의해 단 하나의 값이 제안된 경우 값이 선택되기를 원한다. 이는 다음의 요건을 암시한다:
P1. 수락자는 자신의 수신한 첫 번째 제안을 수락해야 한다.
그러나, 이 요건은 문제를 야기한다. 여러 다른 제안자에 의해 거의 동시에 몇 개의 값이 제안될 수 있고, 이는 모든 수락자들이 하나의 값을 수락하지만 수락자들의 과반수에 의해 어떠한 하나의 값도 수락되지 않는 상황을 초래한다. 단 2개의 제안된 값의 경우라도, 각각의 값이 약 절반의 수락자들에 의해 수락된 경우, 단일 수락자의 장애가 값들 중 어느 것이 선택됐는지 학습하는 것을 불가능하게 만들 수 있다.
P1 및 값이 수락자들의 과반수에 의해 수락될 때만 상기 값이 선택된다는 요건은 수락자가 둘 이상의 제안을 수락하도록 허용되어야 함을 의미한다. 이를 허용하기 위해, 우리는 수락자가 수락할 수 있는 여러 다른 제안 각각에 번호(자연수)를 할당함으로써 상기 제안을 계속 주시하고, 따라서 제안은 제안 번호와 값으로 구성된다. 혼란을 피하기 위해, 우리는 서로 다른 제안이 서로 다른 번호를 가질 것을 요구한다. 이를 이루는 방식은 구현예에 따라 다르며, 이하는 설명 목적으로 가정한 것에 불과하다. 값은, 상기 값을 갖는 단일 제안이 과반수의 수락자에 의해 수락됐을 때 선택된다. 이 경우, 제안(뿐 아니라 이의 값까지)이 선택됐다고 할 수 있다.
복수의 제안이 선택되게 할 수 있지만, 모든 선택된 제안이 동일한 값을 가짐을 보장해야 한다. 제안 번호에 대한 귀납법(induction)에 의해, 다음을 보장하는 것이 충분하다:
P2. 값 v를 갖는 제안이 선택된 경우, 모든 더 큰 번호의 선택된 제안이 값 v를 가진다.
번호들이 완전히 정렬되기 때문에, 조건 P2는 단 하나의 값만 선택된다는 안전 속성을 보장한다.
선택되도록, 제안은 적어도 하나의 수락자에 의해 수락되어야 한다. 따라서 다음을 만족시킴으로써 P2를 만족시킬 수 있다:
P2a. 값 v를 갖는 제안이 선택된 경우, 임의의 수락자에 의해 수락된 모든 더 큰 번호를 갖는 제안이 값 v를 가진다.
일부 제안이 선택됨을 보장하기 위해 P1을 여전히 유지한다. 통신이 비동기식이기 때문에, 임의의 제안을 수신한 적 없는 일부 특정 수락자 c에 의해 제안이 선택될 수 있다. 새로운 제안자가 "각성(wake up)"되고 상이한 값을 갖는 더 큰 번호의 제안을 발행한다고 가정하자. P1은 c가 P2a를 위반하면서 제안을 수락할 것을 요구한다. P1과 P2a 모두를 유지하는 것은 P2a를 다음으로 강화시키는 것을 필요로 한다:
P2b. 값 v를 갖는 제안이 선택된 경우, 임의의 제안자에 의해 발행된 모든 더 큰 번호의 제안이 값 v를 가진다.
제안은 수락자에 의해 수락될 수 있기 전에 제안자에 의해 발행되어야 하기 때문에, P2b는 P2a를 의미하고, 이는 다시 P2를 의미한다.
P2b를 만족시키는 방식을 발견하기 위해, 이것이 지속됨을 증명할 방식을 가정한다. 우리는 번호 m과 값 v를 갖는 일부 제안이 선택됨을 가정하고 번호 n > m을 갖고 발행된 임의의 제안도 역시 값 v를 가짐을 보일 것이다. 우리는 n에 대한 귀납법을 이용함으로써 증명을 더 쉽게 할 것이며, 따라서 번호 m...(n-1)를 갖고 발행된 모든 제안이 값 v를 가지며, 여기서 i...j가 i에서 j까지의 번호들의 집합을 나타낸다는 추가 가정 하에서 제안 번호 n이 값 v를 가짐을 증명할 수 있다. 번호 m의 제안이 선택되도록 하기 위해, C 내의 모든 수락자가 이를 수락하도록 하는 과반수의 수락자로 구성된 일부 집합 C가 있어야 한다. 이를 귀납 가정과 조합하면, m이 선택된다는 가설은 다음을 의미한다:
C 내 모든 수락자가 번호 m...(n-1)를 갖는 제안을 수락했고, 임의의 수락자에 의해 수락된 m...(n-1)의 번호를 갖는 모든 제안이 값 v를 가진다.
수락자의 과반수로 구성된 임의의 집합 S가 C의 적어도 하나의 구성원을 포함하기 때문에, 다음의 불변 상태가 유지됨을 보장함으로써 번호 n의 제안은 값 v를 가진다고 결론내릴 수 있다:
P2c. 임의의 v와 n에 대해, 값 v와 번호 n을 갖는 제안이 발행된 경우, (a) S 내 어떠한 수락자도 n보다 작은 번호의 제안을 수락하지 않거나, (b) v가 S 내 수락자에 의해 수락된 n보다 작은 번호의 모든 제안들 중에서 가장 큰 번호의 제안의 값인, 집합 S가 존재한다.
P2c의 불변상태(invariant)를 유지함으로써 P2b를 만족시킬 수 있다.
P2c의 불변상태를 유지하기 위해, 번호 n의 제안을 발행하기 원하는 제안자는, 존재한다면 수락자들 중 일부 과반수에 속하는 수락자 각각에 의해 수락되거나 수락될 n보다 작은 번호를 갖는 가장 큰 번호의 제안을 학습해야 한다. 이미 수락된 제안에 대해 학습하는 것은 충분히 쉬우며, 미래의 수락을 예측하는 것이 어렵다. 미래를 예측하려 시도하는 대신, 제안자는 이러한 수락이 존재하지 않을 것이라는 약속을 추출함으로써 이를 제어한다. 다시 말하면, 제안자는 수락자가 n보다 작은 번호의 제안을 더 이상 수락하지 않도록 요청한다. 이는 제안을 발행하기 위한 다음의 알고리즘을 야기한다.
1. 제안자는 새로운 제안 번호 n을 선택하고 일부 수락자 집합의 각각의 구성원에게 다음을 이용해 응답할 것을 요구하는 요청을 전송한다:
(a) n보다 작은 번호의 제안을 다시 수락하지 않겠다는 약속, 및
(b) 존재한다면, 수락한 n보다 작은 가장 큰 번호를 갖는 제안.
이러한 요청은 번호 n을 갖는 "준비 요청(prepare request)"이라고 지칭된다.
2. 제안자가 수락자의 과반수로부터 요청된 응답을 수신한 경우, 번호 n과 값 v를 갖는 제안을 발행할 수 있으며, 여기서 v는 응답들 중 가장 큰 번호의 제안의 값이거나, 응답자가 어떠한 제안도 보고하지 않았을 경우 제안자에 의해 선택된 임의의 값이다.
제안자가 일부 수락자 집합으로 제안을 수락하도록 하는 요청을 전송함으로써 제안을 발행한다. (이는 초기 요청에 응답한 수락자 집합과 동일할 필요는 없다.) 이는 수락 요청이라고 지칭될 것이다.
수락자는 제안자로부터 두 종류의 요청, 즉 준비 요청 및 수락 요청을 수신할 수 있다. 수락자는 안전을 위태롭게 만들지 않으면서 임의의 요청을 무시할 수 있다. 따라서 우리는 요청에 응답하도록 허용될 때만 말할 필요가 있다. 수락자는 항상 준비 요청에 응답할 수 있다. 수락자는 그렇게 하지 않도록 약속하지 않은 경우 제안을 수락하기 위해 수락 요청에 응답할 수 있다. 다시 말하면:
P1a. 수락자는 n보다 큰 번호를 갖는 준비 요청에 응답하지 않은 경우 번호 n의 제안을 수락할 수 있다.
P1a는 P1에 포함되는 것으로 관측된다. 이제 우리는 필요한 안전 속성을 만족시키는 값을 선택하기 위한 완전한 알고리즘 - 고유 제안 번호를 가정하는 것 - 을 가진다. 하나의 작은 최적화를 만듦으로써 최종 알고리즘이 획득된다. 수락자가 번호 n의 준비 요청을 수신하지만, n보다 큰 번호의 준비 요청에 이미 응답했고 따라서 번호 n의 어떠한 새로운 제안도 수락하지 않도록 약속했다고 추측한다. 그렇다면 수락자는 제안자가 발행하기 원하는 번호 n의 제안을 수락하지 않을 것이기 때문에 새로운 준비 요청에 응답할 어떠한 이유도 없다. 따라서 우리는 수락자가 이러한 준비 요청을 무시하게 한다. 또한 우리는 수락자가 이미 수락한 제안에 대해 준비 요청을 무시하게 한다.
이러한 최적화를 이용해 수락자는 자신이 수락한 가장 큰 번호의 제안과 자신이 응답한 가장 큰 번호의 준비 요청의 번호만 기억할 필요가 있다. P2c는 장애에 무관하게 불변상태를 유지해야 하기 때문에, 수락자는 장애가 발생하고 그 후 재시작하는 경우라도 이 정보를 기억해야 한다. 제안자는 항상 제안을 포기할 수 있고 동일한 번호를 갖는 또 다른 제안을 발행하려 시도하지 않는 한 이에 대해 모두 잊을 수 있다.
제안자와 수락자의 동작을 함께 둠으로써, 우리는 알고리즘이 다음의 2개의 단계(phase)에서 동작함을 안다.
단계 1
(a) 제안자가 제안 번호 n을 선택하고 번호 n의 준비 요청을 수락자의 과반수에게 전송한다.
(b) 수락자가 자신이 이미 응답한 어떠한 준비 요청의 번호보다 큰 번호 n의 준비 요청을 수신한 경우, n보다 작은 번호의 제안은 더 이상 수락하지 않겠다는 약속과 (존재한다면) 자신이 수락했던 가장 큰 번호의 제안으로 요청에 응답한다.
단계 2
(a) 제안자가 수락자의 과반수로부터 (번호 n의) 자신의 준비 요청에 대한 응답을 수신한 경우, 이들 수락자 각각에게 값 v와 함께 번호 n의 제안에 대한 수락 요청을 전송하며, 여기서 v는 응답들 중 가장 큰 번호의 제안의 값이거나 응답이 어떠한 제안도 보고하지 않은 경우 임의의 값이다.
(b) 수락자가 번호 n의 제안에 대한 수락 요청을 수신한 경우, n보다 큰 번호를 갖는 준비 요청에 이미 응답한 것이 아닌 한 제안을 수락한다.
제안자는 각각에 대해 알고리즘을 따르는 한 복수의 제안을 만들 수 있다. 제안자는 프로토콜 중에 임의의 때에 제안을 포기할 수 있다. 제안이 포기되고 긴 시간 후에 제안에 대한 요청 및/또는 응답이 도착지에 도달할 수 있더라도, 정확성(correctness)이 유지된다. 일부 제안자가 더 큰 번호의 제안을 발행하려 시도하기 시작한 경우 제안을 포기하는 것이 훌륭한 아이디어일 수 있다. 따라서 수락자가 더 큰 번호를 갖는 준비 요청을 이미 수신했기 때문에 준비 또는 수락 요청을 무시한 경우, 다음에 자신의 제안을 포기해야 할 제안자에게 알려줘야 할 것이다. 이는 정확성에 영향을 미치지 않는 성능 최적화이다.
이제 선택된 값을 학습하는 개념을 살펴본다. 값이 선택됐다고 학습하기 위해, 학습자는 제안이 수락자의 과반수에 의해 수락됐었음을 발견한다. 이를 위한 한 가지 방식은 각각의 수락자가, 제안을 수락할 때마다 모든 학습자에게 응답하게 하여 그들에게 제안을 전송하는 것이다. 이는 학습자가 선택된 값에 대해 가능한 빨리 발견할 수 있게 하지만, 각각의 수락자가 각각의 학습자에게 응답할 것을 요구한다 - 응답의 수는 수락자의 개수와 학습자의 개수의 곱과 동일하다 - .
비-비잔틴 장애의 가정에 의해 하나의 학습자가 다른 학습자로부터 값이 수락됐음을 발견하는 것이 용이해진다. 우리는 수락자가 특별한 학습자(distinguished learner)에게 그들의 수락을 갖고 응답하게 할 수 있으며, 상기 특별한 학습자는 다른 학습자에게 값이 선택됐던 때를 알려준다. 이 방식에 의해 모든 학습자가 선택된 값을 발견하기 위한 가외적 라운드를 필요로 한다. 또한 상기 특별한 학습자 장애를 일으킬 수 있기 때문에 덜 신뢰할만하다. 그러나 이는 수락자의 개수와 학습자의 개수의 합과 동일한 응답의 수만 필요로 한다.
더 일반적으로, 수락자는 일부 특별한 학습자 집합에 그들의 수락으로 응답할 수 있으며, 그 후 각각의 특별한 학습자는 모든 학습자에게 값이 선택된 때를 알릴 수 있다. 특별한 학습자의 큰 집합을 이용할수록, 더 높은 신뢰성이 제공되지만, 대신 통신 복잡도가 더 커진다.
메시지 손실 때문에, 어떠한 학습자도 발견한 적 없는 상태로 값이 선택될 수 있다. 학습자는 수락자에게 그들이 수락했던 제안이 무엇인지를 문의할 수 있지만, 수락자의 장애가 과반수가 특정 제안을 수락했는지 여부를 아는 것을 불가능하게 만들 수 있다. 이러한 경우, 학습자는 새로운 제안이 선택될 때만 어떤 값이 선택되는지를 발견할 것이다. 학습자가 값이 선택됐는지 여부를 알 필요가 있을 경우, 앞서 기재된 알고리즘을 이용해 제안자가 제안을 발행하게 할 수 있다.
이하에서 진행(progress) 문제와 알고리즘의 진행이 생산적인 방향으로 진행함을 어떻게 보장하는지를 살펴본다. 2개의 제안자 각각이 번호가 증가하는 제안들의 시퀀스를 계속 발행하며 이들 중 어느 것도 선택된 적 없는 시나리오를 살펴본다. 제안자 p가 제안 번호 n1에 대해 단계 1을 완료한다. 그 후 또 다른 제안자 q가 제안 번호 n2 > n1에 대해 단계 1을 완료한다. 수락자가 n2보다 작은 번호의 어떠한 새로운 제안도 수락하지 않겠다고 약속했기 때문에, 제안자 p의 단계 2의 번호 n2의 제안에 대한 수락 요청이 무시된다. 따라서 제안자 p는 새로운 제안 번호 n3 > n2에 대해 단계 1을 시작하고 완료하여, 두 번째 단계 2가 제안자 q의 수락 요청이 무시되게 하는 등이다.
진행을 보장하기 위해, 특별한 제안자(distinguished proposer)가 제안을 발행하려 시도하는 유일한 제안자로서 선택된다. 상기 특별한 제안자가 수락자들 중 과반수와 성공적으로 통신한 경우, 그리고 이미 사용된 어떠한 것보다 큰 번호를 갖는 제안을 사용한 경우, 수락된 제안을 발행하는 데 성공할 것이다. 제안을 포기하고 더 큰 제안 번호를 갖는 일부 요청에 대해 학습한 경우 다시 시도함으로써, 상기 특별한 제안자는 결국 충분히 큰 제안 번호를 선택할 것이다.
시스템(제안자, 수락자, 및 통신 네트워크)의 충분한 부분이 적절하게 동작한다면, 따라서 하나의 특별한 제안자를 선택함으로써 생존성(liveness)이 얻어질 수 있다. 하나의 제안자를 선택하기 위한 신뢰할만한 알고리즘이 랜덤성 또는 실시간 - 가령 타임아웃을 이용함으로써 - 을 사용할 수 있다. 그러나 선택의 성공 또는 실패에 무관하게 안전이 보장된다.
이하에서 일부 구현(implementation) 문제를 살펴본다. 팍소스 알고리즘은 프로세스의 네트워크를 가정한다. 이의 합의 알고리즘에서, 각각의 프로세스는 제안자, 수락자 및 학습자의 역할을 수행한다. 알고리즘은 특별한 제안자와 특별한 학습자의 역할을 수행하는 리더(leader)를 선택한다. 팍소스 합의 알고리즘은 앞서 기재된 바와 같으며, 여기서 요청 및 응답이 보통의 메시지로서 전송된다. 응답 메시지에 혼란을 방지하기 위해 대응하는 제안 번호가 태깅된다. 수락자가 기억해야 할 정보를 유지하기 위해 장애 중에 보존되는 안정적인 스토리지가 사용된다. 응답을 실제로 전송하기 전에 안정적인 스토리지에 수락자가 자신의 의도된 응답을 기록한다.
동일한 번호를 갖는 어떠한 2개의 제안도 발행된 적 없음을 보장하기 위한 메커니즘을 기술하는 것만 남았다. 서로 다른 제안자가 서로소인 번호 집합에서 번호를 선택하고, 따라서 2개의 서로 다른 제안자가 동일한 번호를 갖는 제안을 절대로 발행하지 않는다. 각각의 제안자는 자신이 발행하려 시도했던 가장 큰 번호의 제안을 안정적인 스토리지에 기억하고, 이미 사용된 적 있는 것보다 큰 제안 번호를 갖고 단계 1을 시작한다.
이하에서 팍소스 알고리즘을 배경으로 하는 상태 머신의 구현을 살펴본다.
한 가지 방식으로서 분산 시스템은 중앙 서버로 명령어(command)를 발행하는 클라이언트의 모음으로서 구현된다. 서버는 임의의 시퀀스로 클라이언트 명령어를 수행하는 결정성 상태 머신(deterministic state machine)으로서 기재될 수 있다. 상기 상태 머신은 현재 상태를 가지며, 입력을 명령어로서 취하고 출력 및 새 상태를 생성함으로써 한 단계 나아간다. 예를 들어, 분산 뱅킹 시스템(distributed banking system)의 클라이언트가 은행직원(teller)일 수 있고, 상태-머신의 상태는 모든 사용자의 계좌 잔고로 구성될 수 있다. 잔고가 출금액보다 많을 경우에만 계좌의 잔고를 감소시키는 상태 머신 명령어를 실행시키고, 출력으로 구 잔고와 새 잔고를 생성함으로써 출금이 수행될 것이다. 단일 중앙 서버를 이용하는 구현은 상기 서버가 장애 중일 때 장애를 겪는다. 따라서 우리는 대신 서버의 모음(collection of servers)을 사용하며, 각각의 서버는 상태 머신을 독립적으로 구현한다. 상기 상태 머신은 결정성이기 때문에, 모든 서버는 모두가 동일한 명령어 시퀀스를 실행할 경우 상태 및 출력의 동일한 시퀀스를 생성할 것이다. 그 후 명령어를 발행하는 클라이언트가 임의의 서버에 의해 자신을 위해 생성된 출력을 이용할 수 있다.
모든 서버가 상태 머신 명령어의 동일한 시퀀스를 실행함을 보장하기 위해, 우리는 팍소스 합의 알고리즘의 개별 인스턴스들의 시퀀스를 구현하며, 여기서 i번째 인스턴스에 의해 선택된 값이 시퀀스 내 i번째 상태 머신 명령어가 된다. 각각의 서버는 알고리즘의 각각의 인스턴스에서 자신의 역할(제안자, 수락자 및 학습자)를 수행한다. 이러한 예시를 위해, 서버의 집합이 고정됨을 가정함으로써, 합의 알고리즘의 모든 인스턴스가 에이전트의 동일한 집합을 이용한다.
보통의 동작에서, 합의 알고리즘의 모든 인스턴스에서 하나의 서버가 특별한 제안자(즉, 제안을 발행하기 위한 시도를 하는 유일한 제안자)로서 동작하는 리더이도록 선택된다. 클라이언트는 리더로 명령어를 전송하며, 리더는 시퀀스 중 어디에서 각각의 명령어가 나타나야 하는지를 결정한다. 리더가 특정 클라이언트 명령어가 135번째 명령어여야 한다고 결정한 경우, 상기 명령어가 합의 알고리즘의 135번째 인스턴스의 값으로 선택되게 하도록 시도한다. 이는 보통은 성공적일 것이다. 장애 때문에 또는 또 다른 서버가 자신도 리더라고 여겨서 135번째 명령어여야 할 것이 무엇인지에 대해 서로 다른 생각을 갖기 때문에 실패할 수 있다. 그러나 합의 알고리즘은 최대 하나의 명령어가 135번째 명령어로 선택될 수 있음을 보장한다.
제안될 값이 단계 2 전까지는 선택되지 않기 때문에 이 방식의 효율이 팍소스 합의 알고리즘에서 향상된다. 제안자의 알고리즘의 단계 1을 완료한 후, 제안될 값이 결정되거나 제안자가 임의의 값을 자유롭게 제안한다.
이하에서 팍소스 상태 머신 구현이 보통의 작업 동안 어떻게 동작하는지를 살펴본다. 이전 리더가 막 장애를 일으키고 새 리더가 선택된 때 발생하는 일을 살펴본다. 합의 알고리즘의 모든 인스턴스에서 학습자인 새 리더는 이미 선택된 명령어의 대부분을 알아야 한다. 상기 새 리더는 1-134, 138, 및 139 - 즉, 합의 알고리즘의 인스턴스 1-134, 138, 및 139에서 선택된 값 - 를 안다고 추측한다. 그 후 139보다 큰 모든 인스턴스 중 인스턴스 135-137의 단계 1을 실행한다. 이들 실행의 결과가 인스턴스 135 및 140에서 제안될 값을 결정한다고 추측하지만, 나머지 인스턴스에서 제안된 값을 비제한적(unconstrained)으로 둔다. 그 후 리더는 인스턴스 135 및 140에 대해 단계 2를 실행함으로써, 명령어 135 및 140를 선택한다.
이제 리더뿐 아니라 상기 리더가 아는 모든 명령어를 학습하는 그 밖의 다른 임의의 서버가 명령어 1-135를 실행시킬 수 있다. 그러나 명령어 136 및 137이 아직 선택 전이기 때문에 이들은 이들이 역시 알고 있는 명령어 138-140는 실행시킬 수 없다. 리더는 클라이언트에 의해 요청된 다음 2개의 명령어를 명령어 136 및 137이도록 취할 수 있다. 대신 우리는 명령어 136 및 137로서 상태를 변경되지 않은 채로 두는 특수 "noop" 명령어를 제안함으로써 틈새를 즉시 채우게 한다. 합의 알고리즘의 인스턴스 136 및 137의 단계 2를 실행함으로써 이를 이룬다. 이들 "noop" 명령어가 선택되면, 명령어 138-140가 실행될 수 있다.
이제 명령어 1-140가 선택됐다. 또한 리더는 합의 알고리즘의 140보다 큰 모든 인스턴스에 대해 단계 1을 완료했고 이들 인스턴스의 단계 2에서 임의의 값을 자유롭게 제안한다. 리더는 명령어 번호 141을 클라이언트에 의해 요청된 다음 명령어에 할당하여, 합의 알고리즘의 인스턴스 141의 단계 2에서의 값으로 이를 제안한다. 리더는 자신이 수신한 다음 클라이언트 명령어를 명령어 142로서 제안하는 등이다.
리더는 자신의 제안된 명령어 141가 선택됐음을 학습하기 전에 명령어 142를 제안할 수 있다. 명령어 141를 제안할 때 전송한 모든 메시지가 소실되는 것이 가능하며, 임의의 다른 서버가 리더가 명령어 141로서 제안한 것이 무엇인지 학습하기 전에 명령어 142가 선택되는 것이 가능하다. 리더가 인스턴스 141에서 자신의 단계 2 메시지에 대한 예상 응답을 수신하지 못할 때, 이들 메시지를 재전송할 것이다. 모두 잘 된 경우, 이의 제안된 명령어가 선택될 것이다. 그러나 이는 먼저 실패해서 선택된 명령어의 시퀀스에 틈새를 둘 수 있다. 일반적으로 리더는
Figure pct00001
개 앞의 명령어를 얻을 수 있다고 추측된다 - 즉, 리더는 명령어 1 내지
Figure pct00002
가 선택된 후 명령어 i+1 내지 i+
Figure pct00003
를 제안할 수 있다. 그 후 최대
Figure pct00004
-1개 명령어의 틈새가 발생할 수 있다.
새롭게 선택된 리더가 합의 알고리즘의 무한히 많은 인스턴스에 대해 - 앞서 언급된 시나리오의 경우, 인스턴스 135-137과 139보다 큰 모든 인스턴스에 대해 -단계 1을 실행시킨다. 모든 인스턴스에 대해 동일한 제안 번호를 이용해, 하나의 합리적으로 짧은 메시지를 다른 서버에게 전송함으로써 이를 이룰 수 있다. 단계 1에서, 수락자는 일부 제안자로부터 단계 2 메시지를 이미 수신했던 경우에만 단순한 OK 이상의 것으로 응답한다. 시나리오에서, 이는 인스턴스 135 및 140의 경우에만 해당한다. 따라서 수락자로서 기능하는 서버가 하나의 합리적으로 짧은 메시지를 이용해 모든 인스턴스에 대해 응답할 수 있다. 따라서 단계 1의 무한히 많은 인스턴스를 실행시키는 것이 어떠한 문제도 발생시키지 않는다.
리더의 장애 및 새로운 리더의 선출이 드문 이벤트여야 하기 때문에, 상태 머신 명령어를 실행하는 - 즉, 명령어/값에 대한 합의를 획득하는 - 효율적인 비용이 합의 알고리즘의 유일한 단계 2를 실행하는 비용이다. 팍소스 합의 알고리즘의 단계 2가 장애의 경우 협약에 도달하기 위한 임의의 알고리즘의 가능한 최소 비용을 가짐이 나타날 수 있다. 따라서 팍소스 알고리즘은 실질적으로 최적이다.
시스템의 보통의 동작에 대한 이러한 설명은 현재 리더의 장애와 새로운 리더의 선출 사이의 짧은 시간을 제외하고 항상 하나의 리더가 존재함을 가정한다. 비정상적인 환경에서, 리더 선출이 실패할 수 있다. 어떠한 서버도 리더로서 행동하지 않는 경우, 어떠한 새로운 명령어도 제안되지 않을 것이다. 복수의 서버가 자신들이 리더라고 생각하는 경우, 이들은 모두 합의 알고리즘의 동일한 인스턴스에서 값을 제안할 수 있고, 이는 임의의 값이 선택되는 것을 막을 수 있다. 그러나 안전은 유지된다 - 2개의 서로 다른 서버가 i번째 상태 머신 명령어로서 선택된 값에 대해 결코 반대하지 않을 것이다. 오직 진행을 보장하기 위해서 단일 리더의 선출이 요구된다.
서버들의 집합이 변경될 수 있는 경우, 어느 서버가 합의 알고리즘의 어느 인스턴스를 구현할지를 결정하는 임의의 방식이 존재해야 한다. 이를 위한 가장 용이한 방식은 상태 머신 자체를 통하는 것이다. 현재의 서버 집합은 상태의 일부로 만들어질 수 있고 보통의 상태-머신 명령어에 의해 변경될 수 있다. 우리는 리더가 합의 알고리즘의 인스턴스 i+
Figure pct00005
를 실행시키는 서버 집합을 i번째 상태 머신 명령어의 실행 후 상태에 의해 특정되게 함으로써 미리 명령어를 얻게 할 수 있다. 이는 무작위적으로 정교한 재구성 알고리즘의 단순한 구현을 가능하게 한다.
상기의 기재는 내장애성 분산 시스템을 구현하기 위해 팍소스 알고리즘이 어떻게 사용될 수 있는지에 대한 설명이 된다. 팍소스 프로토콜은 본 명세서에 기재된 실시예와 관련하여 사용될 수 있는 그 밖의 다른 패밀리 구성원 또는 변형을 포함한다. 이들 그 밖의 다른 패밀리 구성원의 비-제한적 예를 들면, 이른바 멀티-팍소스(Multi-Paxos), 칩 팍소스(Cheap Paxos), 패스트 팍소스(Fast Paxos), 및 비잔틴 팍소스(Byzantine Paxos)가 있다. 이들 그 밖의 다른 패밀리 구성원은 이하에서 기재되는 다양한 실시예에서 사용될 수 있다.
분산 협약 프로토콜에 대해 기재하였고 특정 프로토콜, 즉, 팍소스 프로토콜 및 이의 관련 패밀리 구성원의 예시가 주어졌으며, 지금부터 CRUD(Create, Read, Update, Delete) 프로토콜 및 특히 HTTP(Hypertext Transport Protocol)에 대한 간략한 설명이 제공된다.
HTTP 를 포함하는 CRUD 프로토콜
CRUD(Create, Read, Update, Delete) 프로토콜은 자원의 생성(creation), 판독(reading), 업데이트(updating) 및 삭제(deletion)를 가능하게 하는 프로토콜의 패밀리를 일컫는다. CRUD 프로토콜의 한 가지 유형은 HTTP(Hypertext Transfer Protocol)가 있다. HTTP(Hypertext Transfer Protocol)는 분산, 협업, 하이퍼미디어 정보 시스템을 위한 애플리케이션 프로토콜이고 월드 와이드 웹을 위한 데이터 통신의 기초이다.
HTTP는 클라이언트-서버 컴퓨팅 모델에서 요청-응답 프로토콜로서 기능한다. HTTP에서, 웹 브라우저는 가령 클라이언트로서 기능하며 웹 사이트를 호스팅하는 컴퓨터 상에서 실행되는 애플리케이션이 서버로서 기능한다. 클라이언트는 HTTP 요청 메시지를 서버로 제출한다. 콘텐츠를 저장하거나 자원, 가령, HTML 파일을 제공하거나 클라이언트를 대신하여 수행하는 서버는 클라이언트로 응답 메시지를 반환한다. 응답은 요청에 대한 완결 상태 정보를 포함하고 이의 메시지 바디에 클라이언트에 의해 요청된 임의의 콘텐츠를 포함할 수 있다.
웹 브라우저(또는 클라이언트)가 종종 사용자 에이전트(UA)라고 지칭된다. 그 밖의 다른 사용자 에이전트는 검색 제공자에 의해 사용되는, 웹 크롤러(web crawler)라고 알려진 인덱싱 소프트웨어(indexing software) 또는 웹 브라우저의 변형, 가령, 대화형 음성 사용자 인터페이스를 제공하는 음성 브라우저를 포함할 수 있다.
HTTP는 인터넷 프로토콜 슈트(Internet Protocol Suite)의 프레임워크 내에서 설계된 애플리케이션 레이어 프로토콜이다. 프로토콜 정의는 호스트 대 호스트 데이터 전송을 위한 신뢰할만한 전송 레이어 프로토콜을 추정한다. TCP(Transmission Control Protocol)가 이러한 목적으로 지배적으로 사용 중인 프로토콜이다. 그러나 HTTP는 그 밖의 다른 프로토콜, 가령, UDP(User Datagram Protocol) 및 메소드, 가령, SSDP(Simple Service Discovery Protocol)과 함께 사용될 수 있다.
http 또는 http URI 스킴을 이용하는 URI(Uniform Resource Identifier) - 또는 더 구체적으로 URL(Uniform Resource Locator) - 에 의해 HTTP 자원이 네트워크 상에서 식별되고 찾아진다. URI 및 하이퍼텍스트 마크업 언어(HTML)가 인터넷 상에 인터-링크된 자원, 이른바 하이퍼텍스트 문서를 형성한다.
HTTP 세션이 네트워크 요청-응답 트랜잭션의 시퀀스이다. HTTP 클라이언트가 서버 상의 특정 포트로의 TCP(Transmission Control Protocol) 연결을 확립함으로써 요청을 개시한다. 상기 포트에서 청취(listen)하는 HTTP 서버는 클라이언트의 요청 메시지에 대해 대기한다. 요청을 수신하면, 서버는 상태 라인, 가령, HTTP/200 "OK" 및 자신 고유의 메시지를 되돌려 전송한다. 일반적으로 이 메시지의 바디는 요청된 자원이며, 에러 메시지 또는 또 다른 정보가 또한 반환될 수 있다.
HTTP는 식별된 자원에 대해 수행될 바람직한 동작을 가리키는 9개의 메소드(가끔, "동사(verb)"라고 지칭됨)를 정의한다. 이미 존재하는 데이터인지 또는 동적으로 생성되는 데이터인지에 무관하게 이러한 자원이 나타내는 것은 서버의 구현에 따라 달라진다. 종종, 자원은 서버 상에 위치하는 익스큐터블(executable)의 파일 또는 출력에 대응한다.
Figure pct00006
HTTP 프로토콜의 다양한 양태에 대해 언급되었고, 이하에서 분산 협약 프로토콜을 이용해 CRUD형 프로토콜이 상태 머신에 바인딩되는 방식에 대해 설명된다.
CRUD 형 프로토콜을 상태 머신으로서 바인딩하기
도 2는 전체적으로 200으로 표시되는 시스템을 도시하며, 여기서 하나 이상의 실시예에 따라 CRUD형 프로토콜이 분산 협약 프로토콜을 이용해 상태 머신으로서 바인딩될 수 있다. 이하의 설명에서, 유사한 구성요소를 나타내기 위해 도 1 실시예의 유사한 도면부호가 사용된다. 그러나 본 명세서에 기재된 기법이 임의의 적합한 무상태(stateless) REST(Representational State Transfer) 프로토콜과 함께 사용될 수 있음을 알고 이해해야 한다.
이 예시에서, 컴퓨팅 장치(102)는 네트워크(112)를 통해 하나 이상의 서버(114)와 통신한다. 임의의 적합한 프로토콜이 컴퓨팅 장치(120)가 서버(114)와 통신할 수 있도록 하기 위해 사용될 수 있다. 도시되고 기재되는 실시예에서, CRUD형 프로토콜을 이용해 통신이 발생할 수 있다. 특정 구현에서, CRUD형 프로토콜이 HTTP를 포함한다.
각각의 서버는, 이러한 특정 예시에서, 역방향 프록시(202)를 포함한다. 상기 역방향 프록시는 분산 협약 프로토콜((Distributed Agreement Protocol)(DAP) 모듈(204)의 형태로 존재하는 분산 협약 프로토콜(Distributed Agreement Protocol)(DAP)의 인스턴스를 구현한다. 덧붙여, 각각의 서버(114)는 하나 이상의 웹 서비스 - 여기서 서비스(206)로 표현됨 - , 가령, 웹 또는 "클라우드" 서비스를 구현한다. 개별 서버에 의해 구현되는 각각의 서비스(206)는 복제(replica) 또는 예비(redundant) 서비스가 된다.
동작 중에, 각각의 서버(114)는 서비스(206)가 제안되는 분산 시스템 내 하나의 노드가 된다. 항상은 아닐지라도 일반적으로, 서버는 서로 다른 물리적 위치에 지리적으로 분산되어 있다. 예를 들어, 개별 서버들이 특정 국가 상의 데이터 센터에 위치하거나 전세계에 걸쳐 분산된 서버를 포함할 수 있다. 대안적으로 서버는 단일 랙(rack) 내 개별 블레이드 서버(blade server)일 수 있다. 각각의 서버는 자신의 DAP 모듈(204)을 통해 분산 협약 프로토콜의 인스턴스에서 실행된다. 적어도 일부 실시예에서, 분산 협약 프로토콜은 팍소스 프로토콜을 포함한다.
CRUD형 프로토콜, 가령, HTTP를 이용해, 컴퓨팅 장치(102)가 예를 들어 특정 프로토콜과 연관된 동사를 이용하는 작업을 발행한다. HTTP의 맥락에서, 이러한 동사는 GET, PUT, POST, PATCH, DELETE, 등을 포함할 수 있다. 클라이언트 컴퓨팅 장치(102)는 분산 시스템 내 임의의 노드, 즉, 서버(114)와 통신할 수 있다. 서버(114)가 컴퓨팅 장치(102)로부터 작업을 수신할 때, 상기 작업을 캡처하고 DAP 모듈(204)을 이용해 작업들에 대한 순서화(ordering)를 선택한다. 구체적으로 분산 협약 프로토콜을 이용해 각각의 서버 상의 역방향 프록시(202)들 간 통신이 발생한다. 서버들 간 통신을 통해, 수행될 작업들의 순서화에 대한 합의에 이르도록 분산 협약 프로토콜이 사용된다.
예를 들어 앞서 기재된 팍소스 프로토콜을 이용해 작업들의 순서가 동의되면, 각각의 노드, 즉, 서버가 서비스(206)의 맥락에서 동의된 순서로 작업들을 실행시킬 수 있다. 이러한 방식으로 분산 협약 프로토콜을 이용해 이 인스턴스에서 HTTP인 CRUD형 프로토콜이 상태 머신으로서 바인딩된다.
그 후 본질적으로, 분산 협약 프로토콜에 의해 넓게 분산되어 있을 수 있는 다양한 클라이언트로부터의 작업의 수신이 가능해진다. 작업들은 임의의 순서로 도착할 수 있고 임의의 서비스, 즉, "클라우드 서비스"와 연관될 수 있다. 서버는 분산 협약 프로토콜을 이용하여 모든 서버 또는 노드에 걸친 동일한 순차 순서가 동일함을 보장하도록 복수의 서로 다른 서버 사이에서 작업들의 순차적인 순서를 구성할 수 있다. 따라서 각각의 노드는 수행될 또는 수행된 작업과 관련하여 동일한 상태에 있을 것이다.
CRUD형 프로토콜을 이용하여 구현되는 웹 서비스와 관련된 분산 협약 프로토콜이 예를 들어 분산 시스템 내 개별 노드 또는 서버가 동작하지 않는 상태가 될 수 있을 때 동작을 촉진시킬 수 있다.
앞서 기재된 기법을 이용해 구현될 수 있는 웹 서비스의 하나의 예를 들면, 개별 사용자에 대한 연락처 리스트를 유지하는 웹 서비스를 고려할 수 있다. 이러한 특정 연락처 리스트 서비스에서, 사용자는 새 연락처를 삽입, 연락처를 보기, 연락처를 업데이트, 및 연락처를 삭제할 수 있다. 또한 연락처 리스트 서비스는 서버, 가령, 앞서 기재된 서버를 이용해 분산 방식으로 구현된다. 또한 사용자는 복수의 여러 다른 유형의 클라이언트 장치를 이용해 연락처 리스트 서비스와 대화할 수 있다고 가정된다. 예를 들어, 사용자는 개인 컴퓨터, 전화기, 웹 브라우저, 또는 임의의 유형의 클라이언트로의 연락처 리스트 서비스와 대화하기를 원할 수 있다.
이들의 특정 연락처 리스트와 대화하기 위해, 클라이언트 장치는 HTTP 동사의 형태로 된 작업을 발행한다. 예를 들어, 사용자가 자신의 연락처 모두를 보기를 원하는 경우, 적절하게 구성된 사용자 인터페이스를 통해, 사용자는 HTTP GET 작업이 발행되게 할 것이다. 마찬가지로, 연락처를 업데이트하기 위해 HTTP MERGE 작업이 발행될 것이다. 연락처를 삭제하는 것은 HTTP DELETE 작업을 통해 이뤄질 것이고 새 연락처를 삽입하는 것은 POST 작업의 발행을 통해 이뤄질 것이다.
연락처 리스트 서비스가 복수의 여러 다른 서버 상에서 분산 방식으로 구현되기 때문에, 작업이 클라이언트 장치에 의해 발행될 때, 각각의 서버 또는 더 정확히는, 각각의 서버 상의 역방향 프록시에 의해 실행되는 분산 협약 프로토콜이 각각의 서버에서 동의된 순서의 작업이 발생함을 보장한다. 이러한 방식으로, 사용자의 연락처 리스트는 분산 시스템 내 노드, 즉, 서버들 간 동기화를 유지할 수 있다.
CRUD형 프로토콜이 분산 협약 프로토콜을 이용해 상태 머신으로서 바인딩될 수 있는 방식에 대해 살펴보았고, 이하에서 하나 이상의 실시예에 따르는 예시적 방법을 살펴보겠다.
예시적 방법
도 3은 하나 이상의 실시예에 따라 방법의 단계들을 기술하는 흐름도이다. 상기 방법은 임의의 적절한 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 조합과 함께 구현될 수 있다. 적어도 일부 실시예에서, 상기 방법은, 적어도 부분적으로, 적절하게 구성된 클라이언트 장치 및 하나 이상의 적절하게 구성된 서버에 의해 구현될 수 있다. 이러한 목적으로, 도시된 흐름도의 일부분이 클라이언트 장치에 의해 수행되는 동작들을 도시하는 "클라이언트 장치"라고 지정된다. 마찬가지로, 흐름도의 또 다른 일부분이 역방향 프록시, 가령, 앞서 기재된 역방향 프록시에 의해 또는 대리하여 수행될 수 있는 동작들 또는 동작들의 적어도 일부를 지정하기 위해 "역방향 프록시"라고 지정된다.
단계(300)는 웹 서비스와 연관된 작업을 발행한다. 임의의 적합한 웹 서비스와 관련하여 임의의 적합한 작업이 발행될 수 있다. 적어도 일부 실시예에서, 상기 작업은 CRUD형 작업과 연관된다. 특정 구현예에서, 작업은 HTTP 작업, 가령, 앞서 기재된 것과 연관된다. 단계(302)는 작업을 RESTful 웹 서버(RESTful Web server) - 즉, RESTful 프로토콜, 가령, CRUD형 프로토콜에 따르거나 상기 프로토콜을 이용하는 것 - 로 작업을 통신한다. 도시되고 기재된 실시예에서, 상기 웹 서버는 웹 서비스를 구현하고 하나 이상의 다른 웹 서버가 웹 서비스의 예비 또는 복제를 구현하는 분산 시스템의 일부를 포함한다.
단계(304)는 RESTful 웹 서버로의 통신을 인터셉트 또는 수신한다. 앞서 언급된 바와 같이, 이 단계는 적절하게 구성된 역방향 프록시에 의해 수행될 수 있다. 도시되고 기재된 실시예에서, 상기 역방향 프록시는 분산 협약 프로토콜, 가령, 앞서 언급된 것을 지원 또는 그 밖의 다른 방식으로 사용하도록 구성된다. 특정 구현예에서, 상기 분산 협약 프로토콜은 팍소스 프로토콜을 포함한다. 단계(306)는 하나 이상의 노드와의 분산 협약 프로토콜을 개시한다. 이 단계는 임의의 적절한 방식으로 수행될 수 있다. 도시되고 기재된 실시예에서, 각각의 노드는 앞서 언급된 예비 웹 서비스를 구현하는 또 다른 RESTful 웹 서버에 대응한다. 단계(308)는 작업에 대한 합의에 도달하도록 분산 협약 프로토콜을 이용한다. 분산 협약 프로토콜의 사용은 예비 웹 서비스를 지원 또는 노출시키는 다양한 서버들 간 인트라-통신(intra-communication)을 통해 발생할 수 있다. 이러한 인트라-통신의 예시가 앞서 제공되었다. 분산 협약 프로토콜을 이용해 합의에 도달했으면, 단계(310)가 연관된 작업을 수행 또는 수행을 가능하게 한다. 작업의 수행은 RESTful 웹 서버, 또는 더 정확히는 각각의 웹 서버에 의해 사용되는 역방향 프록시들 간 합의를 통해 확정된 순서로 발생한다. 작업을 수행하면, 단계(312)가 적절한 응답을 클라이언트 장치로 반환한다. 임의의 적합한 응답이 반환될 수 있다. 적어도 일부 실시예에서, 반환되는 응답은 HTTP 응답의 형태로 존재한다.
단계(314)는 클라이언트 장치에서 응답을 수신하고 상기 응답을 정규 방식으로 프로세싱한다.
앞서 기재된 방법을 이용하여, 예비 웹 서비스를 구현하는 복수의 서로 다른 서버 간에 상태가 유지될 수 있다. RESTful형 프로토콜, 가령, CRUD형 프로토콜과 함께 분산 협약 프로토콜의 사용함으로써, RESTful 웹 서버는 상태를 보존하고 웹 서버들 간에 수행되는 작업과 관련하여 동기화를 유지하도록 고정된 단계로 동작될 수 있다.
다양한 실시예를 살펴봤으며, 이하에서 앞서 기재된 실시예를 구현하도록 사용될 수 있는 예시적 시스템 및 장치를 살펴본다.
예시적 시스템 및 장치
도 4는 도 1을 참조하여 기재되는 바와 같은 컴퓨팅 장치(102)를 포함하는 예시적 시스템(400)을 도시한다. 예시적 시스템(400)은 개인 컴퓨터(PC), 텔레비전 장치, 및/또는 모바일 장치 상에서 애플리케이션을 실행시킬 때 매끄러운 사용자 경험을 위한 유비쿼토스 환경을 가능하게 한다. 애플리케이션을 이용하고, 비디오 게임을 하며, 비디오를 시청하는 등을 하면서, 하나의 장치에서 다음 장치로 전화될 때 공통 사용자 경험을 위해 3개의 모든 환경에서 서비스 및 애플리케이션은 실질적으로 유시하게 운영된다.
예시적 시스템(400)에서, 복수의 장치가 중앙 컴퓨팅 장치를 통해 상호연결된다. 상기 중앙 컴퓨팅 장치는 복수의 장치에 로컬이거나 복수의 장치로부터 원격지에 위치할 수 있다. 하나의 실시예에서, 상기 중앙 컴퓨팅 장치는 네트워크, 인터넷, 또는 그 밖의 다른 데이터 통신 링크를 통해 복수의 장치로 연결되는 하나 이상의 서버 컴퓨터의 클라우드일 수 있다. 하나의 실시예에서, 이 상호연결 아키텍처에 의해 기능이 복수의 장치에 걸쳐 전달되어 공통의 매끄러운 경험을 복수의 장치의 사용자에게 제공할 수 있다. 복수의 장치 각각은 서로 다른 물리적 요건 및 능력을 가질 수 있고 중앙 컴퓨팅 장치는 장치에 맞춤 구성되지만 여전히 모든 장치에 공통인 장치로의 경험의 전달을 가능하게 하기 위한 플랫폼을 사용한다. 하나의 실시예에서, 타깃 장치의 클래스가 생성되고 경험이 일반 장치 클래스에 맞춤 구성된다. 장치의 클래스는 물리적 특징, 사용성 유형, 또는 장치의 또 다른 공통 특성에 의해 정의될 수 있다.
다양한 구현에서, 컴퓨팅 장치(102)는 다양한 여러 다른 구성, 가령, 컴퓨터(402), 모바일(404), 및 텔레비전(406) 용도를 위한 구성을 가정할 수 있다. 이들 구성 각각은 일반적으로 서로 다른 구성 및 능력을 가질 수 있는 장치를 포함하며, 따라서 컴퓨팅 장치(102)는 서로 다른 장치 클래스 중 하나 이상에 따라 구성될 수 있다. 예를 들어, 컴퓨팅 장치(102)는 개인 컴퓨터, 데스크톱 컴퓨터, 멀티-스크린 컴퓨터, 랩톱 컴퓨터, 넷북 등을 포함하는 장치의 컴퓨터(402) 클래스로서 구현될 수 있다. 이들 서로 다른 구성 각각은 애플리케이션(들)(108), 웹 브라우저(110), 및 운영 체제(111)를 포함하여 본 명세서에 기재된 기법을 사용할 수 있다.
상기 컴퓨팅 장치(102)는 또한 모바일 장치, 가령, 모바일 전화기, 휴대용 뮤직 플레이어, 휴대용 게임 장치, 태블릿 컴퓨터, 멀티-스크린 컴퓨터 등을 포함하는 장치의 모바일(404) 클래스로서 구현될 수 있다. 또한 상기 컴퓨팅 장치(102)는 일반적인 시청 환경에서 일반적으로 더 큰 스크린을 갖거나 여기로 연결되는 장치를 포함하는 장치의 텔레비전(406) 클래스로서 구현될 수 있다. 이들 장치는 텔레비전, 셋-톱 박스, 게임 콘솔 등을 포함한다. 본 명세서에 기재된 기법은 컴퓨팅 장치(102)의 이들 다양한 구성에 의해 지원될 수 있으며, 본 명세서에 기재된 특정 예시적 기법에 한정되지 않는다.
클라우드(408)는 콘텐츠 서비스(412)를 위한 플랫폼(410)을 포함 및/또는 대표한다. 상기 플랫폼(410)은 클라우드(408)의 하드웨어(가령, 서버) 및 소프트웨어 자원의 기저 기능부를 추상화한다. 상기 콘텐츠 서비스(412)는 컴퓨터 프로세싱이 컴퓨팅 장치(102)로부터 원격에 위치하는 서버 상에서 실행되는 동안 사용될 수 있는 애플리케이션 및/또는 데이터를 포함할 수 있다. 콘텐츠 서비스(412)(가령, 클라우드 서비스 또는 웹 서비스)가 인터넷 및/또는 가입자 네트워크, 가령, 셀룰러 또는 Wi-Fi 네트워크를 통한 서비스로서 제공될 수 있다.
플랫폼(410)은 컴퓨팅 장치(102)를 다른 컴퓨팅 장치로 연결하기 위한 자원 및 기능을 추상화할 수 있다. 상기 플랫폼(410)은 또한 플랫폼(410)을 통해 구현되는 콘텐츠 서비스(412)에 대한 발생된 수요로 대응하는 확장 레벨을 제공하도록 자원의 확장(scaling)을 추상화하는 역할을 할 수 있다. 따라서 상호연결된 장치 실시예에서, 본 명세서에 기재된 기능의 구현은 시스템(400) 전체에 걸쳐 분산될 수 있다. 예를 들어, 기능은 부분적으로 컴퓨팅 장치(102) 상에서, 그리고 클라우드(408)의 상기 기능을 추상화하는 플랫폼(410)을 통해서도 구현될 수 있다.
도 5는 본 명세서에 기재된 기법의 실시예를 구현하기 위해 앞서 기재된 바와 같은 컴퓨팅 장치의 임의의 유형으로서 구현될 수 있는 예시적 장치(500)의 다양한 구성요소를 도시한다. 상기 장치(500)는 장치 데이터(504)(가령, 수신된 데이터, 수신 중인 데이터, 브로드캐스팅되기 위해 스케줄링된 데이터, 데이터의 데이터 패킷 등)의 유선 및/또는 무선 통신을 가능하게 하는 통신 장치(502)를 포함한다. 상기 장치 데이터(504) 또는 또 다른 장치 콘텐츠는 상기 장치의 구성 설정, 장치에 저장되는 미디어 콘텐츠, 및/또는 장치의 사용자와 연관된 정보를 포함할 수 있다. 장치(500) 상에 저장되는 미디어 콘텐츠는 임의의 유형의 오디오, 비디오, 및/또는 이미지 데이터를 포함할 수 있다. 장치(500)는 임의의 유형의 데이터, 미디어 콘텐츠, 및/또는 입력, 가령, 사용자 선택형 입력, 메시지, 음악, 텔레비전 미디어 콘텐츠, 녹음된 비디오 콘텐츠, 및 임의의 콘텐츠 및/또는 데이터 소스로부터 수신된 그 밖의 다른 임의의 유형의 오디오, 비디오, 및/또는 이미지 데이터가 수신될 때 거칠 수 있는 하나 이상의 데이터 입력(506)를 포함한다.
장치(500)는 또한 직렬 및/또는 병렬 인터페이스, 무선 인터페이스, 임의의 유형의 네트워크 인터페이스, 모뎀, 및 그 밖의 다른 임의의 유형의 통신 인터페이스 중 임의의 하나 이상으로 구현될 수 있는 통신 인터페이스(508)를 포함한다. 통신 인터페이스(508)는 장치(500)와 통신 네트워크 사이에 연결 및/또는 통신 링크를 제공하며 이를 통해 그 밖의 다른 전자, 컴퓨팅, 및 통신 장치가 장치(500)와 데이터를 통신한다.
장치(500)는 장치(500)의 작업을 제어하고 본 명세서에 기재된 기법의 실시예를 구현하기 위해 다양한 컴퓨터 실행형 명령을 처리하는 하나 이상의 프로세서(510)(마이크로프로세서, 제어기 등 중 임의의 것)를 포함한다. 대안적으로 또는 추가적으로, 장치(500)는 일반적으로 (512)로 지시되는 프로세싱 및 제어 회로와 함께 구현되는 하드웨어, 펌웨어, 또는 고정 로직 회로 중 임의의 하나 또는 조합과 함게 구현될 수 있다. 도시되지 않았지만, 장치(500)는 장치 내 다양한 구성요소를 연결하는 시스템 버스 또는 데이터 전송 시스템을 포함할 수 있다. 시스템 버스는 다양한 버스 아키텍처 중 임의의 것을 이용하는 서로 다른 버스 구조, 가령, 메모리 버스 또는 메모리 제어기, 주변장치 버스, 전역 직렬 버스, 및/또는 프로세서 또는 로컬 버스 중 임의의 하나 또는 조합을 포함할 수 있다.
또한 장치(500)는 컴퓨터 판독형 매체(514), 가령, 하나 이상의 메모리 구성요소를 포함하며, 이들의 예시로는, 랜덤 액세스 메모리(RAM), 비휘발성 메모리(가령, 리드 온리 메모리(ROM), 플래시 메모리, EPROM, EEPROM 등 중 임의의 하나 이상), 및 디스크 저장 장치가 있다. 디스크 저장 장치는 임의의 유형의 자기 또는 광학 저장 장치, 가령, 하드 디스크 드라이브, 기록 가능한 및/또는 다시 쓰기 가능한 컴팩트 디스크(CD), 임의의 유형의 디지털 다목적 디스크(DVD) 등으로서 구현될 수 있다. 또한 장치(500)는 대용량 저장 매체 장치(516)를 포함할 수 있다.
컴퓨터 판독형 매체(514)는 장치 데이터(504)뿐 아니라 다양한 장치 애플리케이션(518) 및 장치(500)의 동작 양태와 관련된 그 밖의 다른 임의의 유형의 정보 및/또는 데이터를 저장하기 위한 데이터 저장 메커니즘을 제공한다. 예를 들어, 운영 체제(520)는 컴퓨터 판독형 매체(514)에 의해 컴퓨터 애플리케이션으로서 구현될 수 있고 프로세서(510) 상에서 실행될 수 있다. 장치 애플리케이션(518)은 장치 관리자(가령, 제어 애플리케이션, 소프트웨어 애플리케이션, 신호 프로세싱 및 제어 모듈, 특정 장치에 네이티브인 코드, 특정 장치를 위한 하드웨어 추상화 레이어 등)를 포함할 수 있다. 상기 장치 애플리케이션(518)은 또한 본 명세서에 기재된 기법의 실시예를 구현하기 위해 임의의 시스템 구성요소 또는 모듈을 포함한다. 이 예시에서, 장치 애플리케이션(518)은 인터페이스 애플리케이션(522) 및 소프트웨어 모듈 및/또는 컴퓨터 애플리케이션으로서 나타나는 입/출력 모듈(524)을 포함한다. 상기 입/출력 모듈(524)은 입력을 캡처하기 위해 구성된 장치, 가령, 터치스크린, 트랙 패드, 카메라, 마이크로폰 등과의 인터페이스를 제공하도록 사용되는 소프트웨어를 나타낸다. 대안적으로 또는 추가적으로, 인터페이스 애플리케이션(522) 및 입/출력 모듈(524)은 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 임의의 조합으로서 구현될 수 있다. 덧붙여, 입/출력 모듈(524)은 복수의 입력 장치, 가령, 시각 및 청각 입력을 각각 캡처하기 위한 개별 장치를 지원하도록 구성될 수 있다.
또한 장치(500)는 오디오 데이터를 오디오 시스템(528)으로 제공하고 및/또는 비디오 데이터를 디스플레이 시스템(530)으로 제공하는 오디오 및/또는 비디오 입-출력 시스템(526)을 포함한다. 상기 오디오 시스템(528) 및/또는 디스플레이 시스템(530)은 오디오, 비디오, 및 이미지 데이터를 프로세싱, 디스플레이, 및/또는 그 밖의 다른 방식으로 렌더링하는 임의의 장치를 포함할 수 있다. 비디오 신호 및 오디오 신호는 RF(라디오 주파수) 링크, S-비디오 링크, 복합 비디오 링크, 컴포넌트 비디오 링크, DVI(digital video interface), 아날로그 오디오 연결, 또는 그 밖의 다른 유사한 연결 링크를 통해 장치(500)로부터 오디오 장치 및/또는 디스플레이 장치로 통신될 수 있다. 하나의 실시예에서, 오디오 시스템(528) 및/또는 디스플레이 시스템(530)이 장치(500)의 외부 구성요소로서 구현된다. 대안적으로, 상기 오디오 시스템(528) 및/또는 디스플레이 시스템(530)은 예시적 장치(500)의 일체 구성요소로서 구현된다.
결론
다양한 실시예가 예비 또는 복제 서비스, 가령, "클라우드" 서비스가 지리적으로 분산된 위치에서 실행되는 것을 가능하게 한다. 각각의 복제가 모든 복제들 간에 일반적으로 동일하게 수행되는 작업을 수행할 수 있다. 하나의 위치에서의 인터럽션이 발생한 경우, 나머지 위치에서의 서비스가 작업을 신속하고 자동적으로 넘겨받을 수 있다.
하나 이상의 실시예에서, 분산 협약 프로토콜이 사용되어 CRUD형 프로토콜을 상태 머신으로서 바인딩할 수 있다. 바인딩은 서비스가 분산되는 위치 각각에 위치하는 역방향 프록시의 사용을 통해 발생한다. 적어도 일부 실시예에서, 분산 협약 프로토콜이 팍소스 프로토콜 또는 이의 변형으로서 구현되거나, 및/또는 CRUD형 프로토콜이 HTTP 프로토콜을 포함한다.
본 발명이 구조적 특징부 및/또는 방법적 동작에 특정된 언어로 기재되었지만, 이하의 특허청구범위에서 정의되는 본 발명은 앞서 기재된 특정 특징부 또는 동작에 반드시 한정되는 것은 아니다. 오히려 앞서 기재된 특정 특징부 및 동작은 특허청구범위를 구현하는 예시적 형태로서 개시된 것이다.

Claims (10)

  1. 컴퓨터로 구현되는 방법으로서,
    RESTful 웹 서버에 대해 의도된 통신을 수신하는 단계 - 상기 통신은 RESTful 웹 서버에 의해 구현되는 웹 서비스에 의해 수행될 동작과 연관됨 - ,
    상기 수신에 응답하여, 하나 이상의 노드와의 분산 협약 프로토콜을 개시하는 단계,
    상기 동작에 대해 노드들 간에 합의에 도달하도록 분산 협약 프로토콜을 이용하는 단계, 및
    상기 동작의 수행을 활성화하는 단계를 포함하는
    컴퓨터로 구현되는 방법.
  2. 제1항에 있어서,
    각각의 노드는 상기 웹 서비스를 구현하는 서로 다른 RESTful 웹 서버에 대응하는
    컴퓨터로 구현되는 방법.
  3. 제1항에 있어서,
    각각의 노드는 상기 웹 서비스를 구현하는 서로 다른 지리적 위치를 갖는 RESTful 웹 서버에 대응하는
    컴퓨터로 구현되는 방법.
  4. 제1항에 있어서,
    상기 동작은 CRUD형 동작 또는 HTTP 동작 중 하나를 포함하는
    컴퓨터로 구현되는 방법.
  5. 제1항에 있어서,
    상기 분산 협약 프로토콜은 팍소스 프로토콜(Paxos protocol)을 포함하는
    컴퓨터로 구현되는 방법.
  6. 제1항에 있어서,
    상기 수신하는 단계는 역방향 프록시 구성요소에 의해 수행되는
    컴퓨터로 구현되는 방법.
  7. 제1항에 있어서,
    상기 동작은 HTTP 동작을 포함하고 분산 협약 프로토콜은 팍소스 프로토콜을 포함하는
    컴퓨터로 구현되는 방법.
  8. 실행될 때 방법을 구현하는 컴퓨터 판독형 명령어들을 포함하는 하나 이상의 컴퓨터 판독형 저장 매체로서,
    상기 방법은
    RESTful 웹 서버에 대해 의도된 통신을 수신하는 단계 - 상기 통신은 상기 RESTful 웹 서버에 의해 구현되는 웹 서비스에 의해 수행될 동작과 연관됨 - ,
    상기 수신에 응답하여, 하나 이상의 노드와의 분산 협약 프로토콜을 개시하는 단계 - 각각의 노드는 상기 웹 서비스를 구현하는 서로 다른 RESTful 웹 서버에 대응함 - , 및
    상기 동작에 대해 노드들 간에 합의에 도달하도록 분산 협약 프로토콜을 이용하는 단계, 및
    상기 동작의 수행을 활성화하는 단계를 포함하는
    컴퓨터 판독형 저장 매체.
  9. 제8항에 있어서,
    상기 동작은 CRUD형 동작을 포함하고 상기 분산 협약 프로토콜은 팍소스 프로토콜을 포함하는
    컴퓨터 판독형 저장 매체.
  10. 제8항에 있어서,
    상기 동작은 HTTP 동작을 포함하고, 상기 분산 협약 프로토콜은 팍소스 프로토콜을 포함하는
    컴퓨터 판독형 저장 매체.
KR1020147029229A 2012-04-20 2013-04-15 분산 협약 프로토콜에서의 crud형 프로토콜 바인딩 기법 Active KR101996624B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13/452,433 2012-04-20
US13/452,433 US9313252B2 (en) 2012-04-20 2012-04-20 Binding crud-type protocols in distributed agreement protocols
PCT/US2013/036519 WO2013158514A1 (en) 2012-04-20 2013-04-15 Binding crud-type protocols in distributed agreement protocols

Publications (2)

Publication Number Publication Date
KR20150005547A true KR20150005547A (ko) 2015-01-14
KR101996624B1 KR101996624B1 (ko) 2019-07-04

Family

ID=48184522

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020147029229A Active KR101996624B1 (ko) 2012-04-20 2013-04-15 분산 협약 프로토콜에서의 crud형 프로토콜 바인딩 기법

Country Status (6)

Country Link
US (2) US9313252B2 (ko)
EP (2) EP3624426B1 (ko)
JP (1) JP6275693B2 (ko)
KR (1) KR101996624B1 (ko)
CN (1) CN104247380B (ko)
WO (1) WO2013158514A1 (ko)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9313252B2 (en) * 2012-04-20 2016-04-12 Microsoft Technology Licensing, Llc Binding crud-type protocols in distributed agreement protocols
US9215131B2 (en) 2012-06-29 2015-12-15 Cisco Technology, Inc. Methods for exchanging network management messages using UDP over HTTP protocol
US9329950B2 (en) * 2014-01-01 2016-05-03 International Business Machines Corporation Efficient fail-over in replicated systems
US10369461B2 (en) * 2014-01-24 2019-08-06 Nvidia Corporation Cloud gaming system and method of initiating a gaming session
US10362059B2 (en) * 2014-09-24 2019-07-23 Oracle International Corporation Proxy servers within computer subnetworks
CN105577711B (zh) 2014-10-08 2019-05-03 华为技术有限公司 消息处理方法、装置及消息处理系统
EP3062260B1 (en) * 2015-02-27 2017-05-31 Sap Se A method for controlling access to electronic documents using locks
US9934092B2 (en) * 2016-07-12 2018-04-03 International Business Machines Corporation Manipulating a distributed agreement protocol to identify a desired set of storage units
US11100086B2 (en) * 2018-09-25 2021-08-24 Wandisco, Inc. Methods, devices and systems for real-time checking of data consistency in a distributed heterogenous storage system
FR3088159A1 (fr) * 2018-11-05 2020-05-08 Orange Gestion d'une communication entre un terminal de communication appelant, disposant d'un identifiant d'appel principal et d'un identifiant d'appel secondaire, et un terminal de communication appele.
US11909528B2 (en) 2021-03-04 2024-02-20 Cisco Technology, Inc. Safely overwriting decided slots
US11451465B1 (en) 2021-03-04 2022-09-20 Cisco Technology, Inc. In-order fault tolerant consensus logs for replicated services
JP7225298B2 (ja) * 2021-04-07 2023-02-20 株式会社日立製作所 分散合意方法、分散システム及び分散合意プログラム

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010122773A (ja) * 2008-11-18 2010-06-03 Hitachi Ltd 分散処理システム、処理割当方法、および情報処理装置
JP2010191706A (ja) * 2009-02-18 2010-09-02 Nippon Telegr & Teleph Corp <Ntt> Ｗｅｂシステムにおける分散処理方法およびｗｅｂシステムにおける分散処理システム
JP2011164719A (ja) * 2010-02-04 2011-08-25 Tritech Inc 分散コンピューティングシステム、分散コンピューティング方法及び分散コンピューティング用プログラム

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7409431B2 (en) * 2002-09-13 2008-08-05 Canon Kabushiki Kaisha Server apparatus, communications method, program for making computer execute the communications method, and computer-readable storage medium containing the program
US20150088982A1 (en) * 2006-09-25 2015-03-26 Weaved, Inc. Load balanced inter-device messaging
US7987471B2 (en) 2007-01-26 2011-07-26 Microsoft Corporation Mobile device management proxy system
US8234518B2 (en) 2009-07-21 2012-07-31 Vmware, Inc. Method for voting with secret shares in a distributed system
US8352482B2 (en) 2009-07-21 2013-01-08 Vmware, Inc. System and method for replicating disk images in a cloud computing based virtual machine file system
US8335765B2 (en) 2009-10-26 2012-12-18 Amazon Technologies, Inc. Provisioning and managing replicated data instances
US20110225495A1 (en) 2010-03-12 2011-09-15 Salesforce.Com, Inc. Service Cloud Console
JP5488349B2 (ja) * 2010-08-30 2014-05-14 富士通株式会社 中継装置、中継方法及び中継プログラム
US9483570B2 (en) * 2010-12-30 2016-11-01 International Business Machines Corporation Driving a user experience of a web application using rules that establish or change requests based on user behavior
US20120331038A1 (en) * 2011-06-23 2012-12-27 Lin Yang Systems and methods for processing web service piped network requests
US9313252B2 (en) * 2012-04-20 2016-04-12 Microsoft Technology Licensing, Llc Binding crud-type protocols in distributed agreement protocols

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010122773A (ja) * 2008-11-18 2010-06-03 Hitachi Ltd 分散処理システム、処理割当方法、および情報処理装置
JP2010191706A (ja) * 2009-02-18 2010-09-02 Nippon Telegr & Teleph Corp <Ntt> Ｗｅｂシステムにおける分散処理方法およびｗｅｂシステムにおける分散処理システム
JP2011164719A (ja) * 2010-02-04 2011-08-25 Tritech Inc 分散コンピューティングシステム、分散コンピューティング方法及び分散コンピューティング用プログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Luiz E. Buzato et al., "Dynamic ContentWeb Applications: Crash, Failover, and Recovery Analysis", 2009 IEEE/IFIP International Conference on Dependable Systems & Networks (2009.07.02.) *

Also Published As

Publication number Publication date
JP6275693B2 (ja) 2018-02-07
EP3624426A1 (en) 2020-03-18
EP2839629A1 (en) 2015-02-25
US20160197976A1 (en) 2016-07-07
JP2015520440A (ja) 2015-07-16
US20130282789A1 (en) 2013-10-24
US9313252B2 (en) 2016-04-12
EP2839629B1 (en) 2019-06-26
CN104247380A (zh) 2014-12-24
CN104247380B (zh) 2018-02-06
US10193951B2 (en) 2019-01-29
EP3624426B1 (en) 2021-05-26
KR101996624B1 (ko) 2019-07-04
WO2013158514A1 (en) 2013-10-24

Similar Documents

Publication Publication Date Title
KR101996624B1 (ko) 분산 협약 프로토콜에서의 crud형 프로토콜 바인딩 기법
US10491523B2 (en) Load distribution in data networks
JP6220338B2 (ja) フォールトトレラント外部アプリケーションサーバ
CN101821993B (zh) 故障恢复进行处理的方法和系统
JP6159338B2 (ja) 汎用サービスを通してのリアル・タイムのドキュメント・プレゼンテーション・データの同期
US20200053168A1 (en) Session transfer between resources
EP3103023B1 (en) Private cloud connected device cluster architecture
US20160042014A1 (en) Distributed database in software driven networks
US8082351B1 (en) Software load balancing for session requests that maintain state information
JP2014535085A (ja) ロケーションニュートラルソフトウェアの需要増大に伴う展開に対するシステム及び方法
JP6275860B2 (ja) チャット情報伝送方法および装置、ならびにチャット情報プッシュ方法およびサーバ
CN101009567A (zh) 一种利用对等网络实体提供网络服务的方法及系统
Sedivy et al. Mcsync-distributed, decentralized database for mobile devices
CN114461424A (zh) 单元化部署架构下的单元间服务发现方法、装置及系统
CN108733805B (zh) 文件交互方法、系统、计算机设备和存储介质
US8271623B2 (en) Performing configuration in a multimachine environment
CN116012565A (zh) 虚拟房间状态修改方法、装置、电子设备及存储介质
CN112988170A (zh) 应用显示的方法及装置
Nayyeri Developing SignalR Applications Using Persistent Connections

Legal Events

Date Code Title Description
PA0105 International application

Patent event date: 20141017

Patent event code: PA01051R01D

Comment text: International Patent Application

PG1501 Laying open of application
N231 Notification of change of applicant
PN2301 Change of applicant

Patent event date: 20150331

Comment text: Notification of Change of Applicant

Patent event code: PN23011R01D

A201 Request for examination
PA0201 Request for examination

Patent event code: PA02012R01D

Patent event date: 20180312

Comment text: Request for Examination of Application

E701 Decision to grant or registration of patent right
PE0701 Decision of registration

Patent event code: PE07011S01D

Comment text: Decision to Grant Registration

Patent event date: 20190328

PR0701 Registration of establishment

Comment text: Registration of Establishment

Patent event date: 20190628

Patent event code: PR07011E01D

PR1002 Payment of registration fee

Payment date: 20190701

End annual number: 3

Start annual number: 1

PG1601 Publication of registration
PR1001 Payment of annual fee

Payment date: 20220517

Start annual number: 4

End annual number: 4

PR1001 Payment of annual fee

Payment date: 20240527

Start annual number: 6

End annual number: 6