KR20160083941A - 대규모 데이터 스트림들의 획득, 저장, 및 소비를 위한 관리 서비스 - Google Patents

Abstract

멀티-테넌트 스트림 관리 서비스의 제어 노드는 복수의 데이터 레코드로 구성될 데이터 스트림을 초기화하기 위한 요청을 수신한다. 제어 노드는 분할 정책에 기초하여, 레코드들의 수집, 저장 및 검색을 위한 서브 시스템들을 구성하기 위해 사용될 파라미터들을 결정한다. 제어 노드는 검색 서브 시스템의 노드를 위해 사용될 자원들을 식별한다. 검색 노드는 비-순차적 및 순차적 액세스 패턴들을 구현하기 위한 각각의 인터페이스들을 포함하여, 프로그램 레코드 검색 인터페이스를 구현하도록 구성된다. 제어 노드는 선택된 자원들을 사용하여 검색 노드를 구성한다.

Description

대규모 데이터 스트림들의 획득, 저장, 및 소비를 위한 관리 서비스{MANAGED SERVICE FOR ACQUISITION, STORAGE AND CONSUMPTION OF LARGE-SCALE DATA STREAMS}

데이터 저장 비용이 수 년 간 감소하고, 컴퓨팅 인프라스트럭처의 다양한 요소를 상호연결하는 능력이 개선됨에 따라, 광범위한 애플리케이션에 관계된 점점 더 많은 데이터가 가능성 있게 수집되고 분석될 수 있다. 예를 들어, 이동 전화기들은 이들의 위치들, 전화기 사용자들에 의해 사용된 애플리케이션들 등을 나타내는 데이터를 생성할 수 있으며, 이 중 적어도 몇몇은 사용자들에게 맞춤형 쿠폰들, 광고들 등을 제공하기 위해 수집되고 분석될 수 있다. 감시 카메라에 의해 수집되는 데이터의 분석은 범죄를 방지하고/하거나 해결하는데 유용할 수 있고, 항공기 엔진들, 자동차들 또는 복잡한 기계 내 다양한 위치에 내장되는 센서들로부터 수집되는 데이터는 예방 정비, 효율 개선 및 비용 감소와 같은 다양한 목적을 위해 사용될 수 있다.

데이터를 스트리밍하는 볼륨들의 증가는 물품 하드웨어 사용의 증가를 동반해왔다(그리고 몇몇 경우에서 이에 의해 실현 가능했다). 상품 하드웨어에 대한 가상화 기술들의 도래는 다양한 컴퓨팅 자원이 다수의 소비자에 의해 효율적으로 그리고 안전하게 공유되는 것을 허용하면서, 많은 유형의 애플리케이션들에 대규모 컴퓨팅 자원을 관리하는 것에 대한 혜택들을 제공해왔다. 예를 들어, 가상화 기술들은 각 사용자에게 단일의 물리 컴퓨팅 기계에 의해 호스팅되는 하나 이상의 가상 기계를 제공함으로써 단일의 물리 컴퓨팅 기계가 다수의 사용자 사이에서 공유되는 것을 허용할 수 있으며, 그러한 각 가상 기계는 사용자들에게 그들이 소정의 하드웨어 컴퓨팅 자원의 유일한 운영자들 및 관리자들이라는 착각을 제공하는 별개의 논리 컴퓨팅 시스템으로서 동작하는 한편, 또한 다양한 가상 기계 중에 애플리케이션 분리 및 보안을 제공하는 소프트웨어 시뮬레이션이다. 게다가, 몇몇 가상화 기술은 둘 이상의 물리 자원에 걸치는 가상 자원들, 이를테면 다수의 별개의 물리 컴퓨팅 시스템에 걸치는 다수의 가상 프로세서를 갖는 단일 가상 기계를 제공할 수 있다. 컴퓨팅 플랫폼들에 추가하여, 몇몇 큰 조직은 또한 가상화 기술들을 사용하여 구축되는 다양한 유형의 저장 서비스들을 제공한다. 그러한 저장 서비스들을 사용하여, 대량 데이터가 원하는 내구성 레벨들로 저장될 수 있다.

다양한 제공자로부터 상대적으로 낮은 비용으로 가상화된 컴퓨팅 및/또는 저장 자원들을 이용 가능함에도 불구하고, 그러나, 대규모의 동적으로 변동을 거듭하는 데이터 스트림들의 수집, 저장 및 프로세싱의 관리 및 조정은 다양한 이유로 인해 도전적인 일로 남아 있다. 보다 많은 자원이 대규모 데이터 스트림을 핸들링하기 위해 셋 업되는 시스템에 추가됨에 따라, 예를 들어, 시스템의 상이한 부품들 간 작업 부하의 불균형이 발생할 수 있다. 그러한 불균형이 해결되지 않으면, 이는 몇몇 자원에 심각한 문제들, 뿐만 아니라 다른 자원들의 충분히 이용하지 않음(따라서 낭비)을 초래할 수 있다. 그러한 데이터 또는 결과들이 클라이언트들이 제어하지 않는 설비들에 저장되는 경우, 클라이언트들은 그들의 스트리밍 데이터의 보안, 또는 스트리밍 데이터를 분석하는 것의 결과들에 관해 우려할 수 있다. 분산 시스템들의 크기가 증가함에 따라 증가하는 주파수와 함께 자연히 발생하는 경향이 있는 고장들, 이를테면 연결성의 부차적 손실 및/또는 하드웨어 고장은 또한 스트림 데이터 수집, 저장 또는 분석의 손실이 큰 혼란들을 방지하기 위해 효율적으로 처리되어야 할 수 있다.

도 1은 적어도 몇몇 실시예에 따른, 데이터 스트림 개념들의 간략화된 개요를 제공한다.
도 2는 적어도 몇몇 실시예에 따른, 스트림 관리 시스템(SMS) 및 스트림 프로세싱 스테이지들의 집합을 포함하는 스트림 프로세싱 시스템(SPS)의 다양한 서브 구성요소 간 데이터의 흐름의 개요를 제공한다.
도 3은 적어도 몇몇 실시예에 따른, SMS 및 SPS에서 구현될 수 있는 프로그램 인터페이스들의 각각의 세트들의 예들을 예시한다.
도 4는 적어도 몇몇 실시예에 따른, SPS 클라이언트들이 스트림 프로세싱 스테이지들의 그래프들을 생성하게 하도록 구현될 수 있는 예시적인 웹-기반 인터페이스를 예시한다.
도 5는 적어도 몇몇 실시예에 따른, SMS에서 구현될 수 있는 프로그램 레코드 제출 인터페이스들 및 레코드 검색 인터페이스들의 예들을 예시한다.
도 6은 적어도 몇몇 실시예에 따른, SMS의 수집 서브 시스템의 예시적인 요소들을 예시한다.
도 7은 적어도 몇몇 실시예에 따른, SMS의 저장 서브시스템의 예시적인 요소들을 예시한다.
도 8은 적어도 몇몇 실시예에 따른, SMS의 검색 서브 시스템의 예시적인 요소들 및 검색 서브 시스템의 SPS과의 상호 작용들의 예들을 예시한다.
도 9는 적어도 몇몇 실시예에 따른, SMS 또는 SPS의 노드들을 위해 셋 업될 수 있는 리던던시 그룹들의 예들을 예시한다.
도 10은 적어도 몇몇 실시예에 따른, 소정의 리던던시 그룹의 노드들이 복수의 데이터 센터 간에 분산될 수 있는 제공자 네트워크 환경을 예시한다.
도 11은 적어도 몇몇 실시예에 따른, SMS 또는 SPS의 노드들을 위해 선택될 수 있는 복수의 설치 목적지를 예시한다.
도 12a 및 도 12b는 적어도 몇몇 실시예에 따른, 각각, SPS 클라이언트들 및 SMS 클라이언트들에 의해 제출될 수 있는 보안 옵션 요청들의 예들을 예시한다.
도 13a는 적어도 몇몇 실시예에 따른, 스트림 데이터 생성자 및 SMS의 수집 노드 간 예시적인 상호 작용들을 예시한다.
도 13b는 적어도 몇몇 실시예에 따른, SMS에서 수집된 데이터 레코드에 대해 생성될 수 있는 시퀀스 번호의 예시적인 요소들을 예시한다.
도 14는 적어도 몇몇 실시예에 따른, SMS에서 스트림 데이터 레코드들의 정리된 저장 및 검색의 예들을 예시한다.
도 15는 적어도 몇몇 실시예에 따른, SMS 및 SPS 노드들에 대해 이루어질 수 있는 스트림 분할 매핑 및 대응하는 구성 결정들의 예를 예시한다.
도 16은 적어도 몇몇 실시예에 따른, 동적 스트림 재분할의 예를 예시한다.
도 17은 적어도 몇몇 실시예에 따른, 스트림 레코드 수집 및 스트림 레코드 검색을 위한 프로그램 인터페이스들의 각각의 세트들을 지원하기 위해 수행될 수 있는 동작들의 측면들을 예시하는 흐름도이다.
도 18a는 적어도 몇몇 실시예에 따른, 스트림 프로세싱 스테이지들을 구성하기 위해 수행될 수 있는 동작들의 측면들을 예시하는 흐름도이다.
도 18b는 적어도 몇몇 실시예에 따른, 스트림 프로세싱 작업자 노드들의 구성을 위한 클라이언트 라이브러리의 구성요소들의 호출들에 응답하여 수행될 수 있는 동작들의 측면들을 예시하는 흐름도이다.
도 19는 적어도 몇몇 실시예에 따른, 스트리밍 프로세싱을 위한 하나 이상의 복구 정책을 구현하기 위해 수행될 수 있는 동작들의 측면들을 예시하는 흐름도이다.
도 20은 적어도 몇몇 실시예에 따른, 데이터 스트림들을 위한 복수의 보안 동작을 구현하기 위해 수행될 수 있는 동작들의 측면들을 예시하는 흐름도이다.
도 21은 적어도 몇몇 실시예에 따른, 데이터 스트림들에 대한 분할 정책을 구현하기 위해 수행될 수 있는 동작들의 측면들을 예시하는 흐름도이다.
도 22는 적어도 몇몇 실시예에 따른, 데이터 스트림들의 동적 재분할을 구현하기 위해 수행될 수 있는 동작들의 측면들을 예시하는 흐름도이다.
도 23은 적어도 몇몇 실시예에 따른, 데이터 스트림 레코드들에 대한 최소-한 번의 레코드 수집 정책을 구현하기 위해 수행될 수 있는 동작들의 측면들을 예시하는 흐름도이다.
도 24는 적어도 몇몇 실시예에 따른, 데이터 스트림들에 대한 복수의 지속 정책을 구현하기 위해 수행될 수 있는 동작들의 측면들을 예시하는 흐름도이다.
도 25는 적어도 몇몇 실시예에 따른, 프로세싱 스테이지의 작업자 노드들이 데이터베이스 테이블을 사용하여 이들의 작업 부하들을 조정하는 스트림 프로세싱 시스템의 예를 예시한다.
도 26은 적어도 몇몇 실시예에 따른, 작업 부하 조정을 위해 사용되는 분할 할당 테이블에 저장될 수 있는 예시적인 엔트리들을 예시한다.
도 27은 적어도 몇몇 실시예에 따른, 프로세싱 동작들을 수행하기 위한 분할들을 선택하기 위해 스트림 프로세싱 스테이지의 작업자 노드들에 의해 수행될 수 있는 동작들의 측면들을 예시한다.
도 28은 적어도 몇몇 실시예에 따른, 스트림 관리 서비스 제어 서브 시스템으로부터 획득되는 정보에 기초하여 분할 할당 데이블을 업데이트하기 위해 스트림 스테이지 스테이지의 작업자 노드들에 의해 수행될 수 있는 동작들의 측면들을 예시한다.
도 29는 적어도 몇몇 실시예에 따른, 스트림 프로세싱 스테이지의 작업자 노드들에 의해 수행될 수 있는 부하 균형 동작들의 측면들을 예시한다.
도 30은 적어도 몇몇 실시예에서 사용될 수 있는 예시적인 컴퓨팅 디바이스를 예시하는 블록도이다.
실시예들이 수 개의 실시예 및 예시적인 도면에 대한 예로서 본 출원에 설명되지만, 해당 기술분야의 통상의 기술자들은 실시예들이 설명되는 실시예들 또는 도면들에 제한되지 않는다는 것을 인식할 것이다. 도면들 및 그것들에 대한 상세한 설명이 실시예들을 개시된 특정한 형태로 제한하는 것으로 의도되지 않으나, 이와 반대로, 첨부된 청구항들에 의해 정의된 바와 같은 사상 및 범위 내에 들어가는 모든 변형물들, 등가물들, 및 대안물들을 망라하도록 의도된다는 것이 이해되어야 한다. 본 출원에 사용된 머릿말들은 단지 조직상의 목적들을 위함이고 본 설명 또는 청구항들의 범위를 제한하는 것으로 사용되도록 의도되지 않는다. 본 출원 전체에 걸쳐 사용될 바와 같이, 단어 "할 수 있다"는 필수적 의미(즉, 해야한다의 의미)가 아니라, 관대한 의미(즉, 가능성을 갖는 의미)로 사용된다. 유사하게, 단어들 "포함한다", "포함하는", 및 "포함하다"는 이에 제한되지 않으나, 포함하는 것을 의미한다.

수백 또는 심지어 수천 개의 동시 데이터 생성자들 및 데이터 소비자들을 핸들링하도록 설계되는 대규모 데이터 스트림들의 생성, 저장, 검색, 및 프로세싱을 관리하기 위한 방법들 및 장치의 다양한 실시예들이 설명된다. 용어 "데이터 스트림"은 본 출원에서 사용될 때, 하나 이상의 데이터 생성자에 의해 생성되고 하나 이상의 데이터 소비자에 의해 액세스될 수 있는 데이터 레코드들의 시퀀스를 나타내며, 여기서 각 데이터 레코드는 바이트들의 변경할 수 없는 시퀀스인 것으로 가정된다. 스트림 관리 서비스(SMS)는 스트림들의 생성, 구성 및 삭제, 뿐만 아니라 몇몇 실시예에서 스트림 데이터 레코드들의 제출, 저장 및 검색을 가능하게 하기 위해 프로그램 인터페이스들(예를 들어, 애플리케이션 프로그래밍 인터페이스들(API들), 웹 페이지들 또는 웹 사이트들, 그래픽 사용자 인터페이스들, 또는 명령어-라인 도구들)을 제공할 수 있다. SMS 제어 구성요소들과의 상호 작용들을 수반하는 몇몇 유형의 스트림 동작(스트림 생성 또는 삭제, 또는 아래에서 설명될 각종 동적 재분할 동작과 같은)은 본 출원에서 "제어-영역" 동작들로서 지칭될 수 있는 한편, 통상적으로(예를 들어, 정상 작동 상태들 하) 제어 구성요소들과의 상호 작용들을 필요로 하지 않는 데이터 레코드 제출들, 저장 및 검색들과 같은 동작들은 "데이터-영역" 동작들로서 지칭될 수 있다. 컴퓨트, 저장 및 네트워킹 자원들의 동적으로 제공된 세트들은 아래에서 더 상세하게 설명될 바와 같이, 예를 들어 스트림 관리 작업 부하가 많은 서비스 구성요소 중에 스케일러블 방식으로 분산되게 하는 다양한 분할 정책에 기초하여, 몇몇 그러한 실시예에서 서비스를 구현하는데 사용될 수 있다. 두문자어 SMS는 본 출원에서 스트림 관리 서비스를, 그리고 또한 스트림 관리 서비스를 구현하는데 사용되는 가상 및/또는 물리적 자원들의 집합을 포함하는 스트림 관리 서비스를 지칭하기 위해 사용될 수 있다.

SMS의 몇몇 소비자는 다양한 실시예에서 SMS 프로그램 인터페이스들을 직접적으로 호출하는 애플리케이션들을 개발할 수 있다. 그러나, 적어도 몇몇 실시예에서, SMS 인터페이스들에 추가하여, 보다 상위-레벨 추상화 또는 애플리케이션-레벨 프로세싱 프레임워크가 소비자들을 위해 제공될 수 있으며, 이는 SMS에 의해 직접적으로 지원되는 보다 하위-레벨 스트림 관리 기능들을 사용하여 애플리케이션들을 개발하기를 바라지 않는 클라이언트들을 위해 스트림 프로세싱의 다양한 측면을 간략화할 수 있다. 그러한 프레임워크는 그 자체의 프로그램 인터페이스들(예를 들어, SMS 인터페이스들 외에 구축되는)을 제공하여, 소비자들이 보다 하위-레벨 스트림 관리 동작들에보다 스트림 레코드들을 사용하여 구현될 비즈니스 로직에 보다 집중하게 할 수 있다. 상위-레벨 프레임워크는 몇몇 실시예에서 그 자체의 제어-영역 및 데이터-영역을 갖는 스트림 프로세싱 서비스(SPS)로서 구현될 수 있으며, 이는 스트림 프로세싱에 대해 제공하는 자동화된 자원, 프로세싱 노드들의 자동화된 시스템 대체 작동들(failovers), 임의의 스트림 프로세싱 작업 흐름 그래프들 구성하는 능력, 단기 스트림들에 대한 지원, 작업 부하 변경들 또는 다른 트리거 조건에 기초한 동적 분할 등과 같은 진화된 기능을 제공할 수 있다. 적어도 몇몇 실시예에서, 스트림 관리 서비스, 스트림 프로세싱 서비스 중 어느 하나, 또는 양자의 서비스들은 가상화 환경에서 멀티-테넌트 관리 네트워크-액세스 가능 서비스들로서 구현될 수 있다. 즉, 다양한 물리적 자원(컴퓨터 서버 또는 호스트, 저장 디바이스, 네트워킹 디바이스 등과 같은)은 적어도 몇몇 경우에서 소비자들이 자원들이 정확하게 어떻게 공유되고 있는지를 인식하게 하거나, 또는 심지어 소비자가 소정의 자원이 공유되고 있다는 것을 전혀 인식하게 하지 않고, 그러한 실시예들에서 상이한 소비자들의 스트림들 중에 공유될 수 있다. 관리 멀티-테넌트 스트림 관리 및/또는 프로세싱 관리 서비스들의 제어 구성요소들은 이들 중 몇몇이 클라이언트-선택 가능할 수 있는, 다양한 적용 가능한 정책에 기초하여 특정한 스트림을 위해 사용되고 있는 노드들 또는 자원들을 동적으로 추가, 제거, 또는 재구성할 수 있다. 또한, 제어 구성요소들은 또한 다양한 유형의 보안 프로토콜들을 투명하게 구현하는 것(예를 들어, 적어도 하드웨어 또는 소프트웨어가 클라이언트들 양자에 의해 공유될 수 있더라도, 한 클라이언트의 스트림 애플리케이션이 다른 클라이언트의 데이터에 액세스할 수 없다는 것을 보장하기 위해), 과금을 위해 자원 이용을 모니터링하는 것, 감사 또는 디버깅을 위해 사용될 수 있는 로깅 정보를 생성하는 것 등에 대해 책임이 있을 수 있다. 관리 멀티-테넌트 서비스(들)의 클라이언트들의 관정에서, 서비스(들)에 의해 구현되는 제어/관리 기능 은 대규모 스트리밍 애플리케이션들을 지원하는 것에 수반되는 많은 복잡도를 제거할 수 있다. 몇몇 시나리오에서, 그러한 멀티-테넌트 서비스들의 소비자들은 그들이 적어도 몇몇 유형의 스트림-관련 동작들에 대한 자원들을 공유하기를 바라지 않는다는 것을 나타낼 수 있을 수 있으며, 이 경우 몇몇 물리적 자원은 그러한 유형의 동작들(즉, 단일 소비자 또는 클라이언트를 대신하여 수행되는 동작들로 제한되는)에 대해 적어도 일시적으로 싱글-테넌트인 것으로 지정될 수 있다.

다수의 상이한 접근법이 다양한 실시예에서 SMS 및/또는 SPS 제어-영역 및 데이터-영역 동작들의 구현을 위해 취해질 수 있다. 예를 들어, 제어-영역 동작들에 대해, 몇몇 구현예에서 제어 서버들 또는 노드들의 리던던시 그룹이 셋 업될 수 있다. 리던던시 그룹은 복수의 제어 서버를 포함할 수 있으며, 이 중 하나의 서버는 다양한 스트림에 관한 관리 요청들에 응답하는 것에 대해 책임이 있는 주요 서버로서 지정되는 한편, 다른 서버는 현재 주요 서버에서(또는 이에 대한 연결의 끊김) 고장과 같은 트리거 조건이 발생할 경우 주요 서버를 맡도록 지정될 수 있다. 다른 구현예에서, 네트워크-액세스 가능한 데이터베이스 서비스에서 생성되는 하나 이상의 테이블은 다양한 스트림에 대한 제어-영역 메타데이터(분할 맵들과 같은)를 저장하는데 사용될 수 있으며, 다양한 수집, 저장 또는 검색 노드들은 데이터-영역 동작들에 대해 요구되는 메타데이터의 서브 세트들을 획득하기 위해 필요 시 테이블들에 액세스할 수 있을 수 있다. 상이한 실시예들에서의 SPS 및 SMS 데이터-영역 및 제어-영역 기능의 다양한 측면에 관한 세부 사항들이 아래에 제공된다. 스트림 관리 서비스가 구현되는 몇몇 실시예에서, 보다 상위-레벨 기초 요소를 제공하는 스트림 프로세싱 서비스는 반드시 구현될 필요가 없을 수 있다. 다른 실시예들에서, 스트림 프로세싱 서비스의 단지 상위-레벨 프로그램 인터페이스들이 소비자들에게 노출될 수 있고, 그것들에 의해 사용되는 하위-레벨 스트림 관리 인터페이스들은 클라이언트들에게 이용 가능하게 되지 않을 수 있다.

몇몇 실시예에 따라, 스트림 관리 시스템은 데이터 레코드들을 획득 또는 수집하는 것에 대해 주로 책임이 있는 레코드 수집 서브 시스템, 적용 가능한 지속성 또는 내구성 정책들에 따라 데이터 레코드 콘텐츠를 저장하는 것에 대해 주로 책임이 있는 레코드 저장 서브 시스템, 및 저장된 레코드들에 지시되는 판독 요청들에 응답하는 것에 대해 주로 책임이 있는 레코드 검색 서브 시스템을 포함하여, 복수의 독립적으로 구성 가능한 서브 시스템을 포함할 수 있다. 제어 서브 시스템은 또한 예를 들어, 가상 또는 물리적 서버들과 같은 선택된 자원들에서 수집, 저장 및 검색 서브 시스템들의 각각에 대해 필요한 수의 노드를 동적으로 결정하고/하거나 초기화함으로써, 나머지 서브 시스템들을 구성하는 것에 대해 책임이 있는 하나 이상의 관리 또는 제어 구성요소를 포함하여, 몇몇 실시예에서 구현될 수 있다. 수집, 저장, 검색, 및 제어 서브 시스템들의 각각은 서브 시스템들의 "노드들" 또는 "서버들"로서 총괄적으로 지칭될 수 있는 각각의 복수의 하드웨어 및/또는 소프트웨어 구성요소를 사용하여 구현될 수 있다. SMS의 다양한 자원은 그에 따라 논리적으로 네 개의 기능 카테고리 중 하나에 속한다라고 한다: 수집, 저장, 검색 또는 제어. 몇몇 구현예에서, 제어 구성요소들의 각각의 세트들이 다른 서브 시스템들의 각각에 대해 설정될 수 있다, 예를 들어, 독립적인 수집 제어 서브 시스템들, 저장 제어 서브시스템들 및/또는 검색 제어 서브 시스템들이 구현될 수 있다. 각각의 그러한 제어 서브 시스템은 대응하는 서브 시스템의 다른 노드들에 대해 시용될 자원들을 식별하는 것 및/또는 클라이언트들로부터의 또는 다른 서브 시스템들로부터의 관리 질의들에 응답하는 것에 대해 책임이 있을 수 있다. 몇몇 구현예에서, 다양한 유형의 SMS 또는 SPS 기능들을 수행할 수 있는 노드들의 풀들이 미리 셋 업될 수 있고, 그것들의 풀들의 선택된 멤버들이 필요 시 새로운 스트림들 또는 새로운 프로세싱 스테이지들에 할당될 수 있다.

스트림 분할 정책들 및 관련 매핑들이 예를 들어, 수집, 저장, 검색 및/또는 제어 노드들의 상이한 세트들 간에 데이터 레코드들의 서브 세트들을 분산하기 위해, 적어도 몇몇 실시예에서 구현될 수 있다. 예를 들어, 특정한 데이터 스트림들에 대해 선택되는 분할 정책뿐만 아니라 레코드 수집 속도들 및/또는 검색 속도들의 예상들과 같은 다른 팩터들에 기초하여, 제어 구성요소는 수집, 저장 및 검색을 위해 얼마나 많은 노드(예를 들어, 프로세스 또는 스레드)가 초기에(즉, 스트림 생성 시에) 설정되어야 하는지, 그리고 그러한 노드들이 가상 및/또는 물리적 기계들에 어떻게 매핑되어야 하는지를 결정할 수 있다. 시간 경과에 따라, 소정의 스트림과 연관된 작업 부하는 증가되거나 감소될 수 있으며, (다른 트리거 조건 중) 이는 스트림의 분할을 초래할 수 있다. 그러한 재-분할은 레코드들의 분할을 결정하는데 사용될 기능, 사용되는 분할 키들, 분할들의 총 수, 수집 노드들, 저장 노드들 또는 검색 노드들의 총 수, 또는 상이한 물리적 또는 가상 자원들 상의 노드들의 설치와 같은, 다양한 파라미터로의 변화들을 수반할 수 있다. 적어도 몇몇 실시예에서, 재분할은 아래에서 더 자세하게 설명될 기술들을 사용하여, 데이터 레코드들의 흐름을 방해하지 않고 동적으로 구현될 수 있다. 상이한 분할 기법들 및 재분할-트리거 기준들이 예를 들어, 클라이언트-제공 파라미터들에 또는 SMS 제어 노드들의 휴리스틱스(heuristics)에 기초하여, 몇몇 실시예에서 상이한 데이터 스트림들에 대해 사용될 수 있다. 몇몇 실시예에서, 예를 들어, 클라이언트 선호도들, 스트림의 예상되는 수명, 또는 다른 팩터들에 기초하여, 재분할들의 수 및/또는 주파수를 제한하는 것이 가능할 수 있다.

다수의 상이한 레코드 수집 정책 및 인터페이스가 상이한 실시예들에 구현될 수 있다. 예를 들어, 몇몇 실시예에서, 클라이언트들(예를 들어, SMS의 소비자들을 대신하여 SMS의 프로그램 인터페이스들을 호출하도록 구성되는 실행 가능한 구성요소들 또는 모듈들)은 인-라인 제출 인터페이스들, 또는 참조에 의한 제출 인터페이스들 중 어느 하나를 이용할 수 있다. 인-라인 제출들에 대해, 데이터 레코드의 바디 또는 콘텐츠는 그러한 실시예들에서 제출 요청의 부분으로서 포함될 수 있다. 그에 반해, 참조에 의한 제출 요청에서, 데이터 레코드의 바디 또는 콘텐츠가 획득될 수 있는 어드레스(저장 디바이스 어드레스, 데이터베이스 레코드 어드레스, 또는 URL(유일 레코드 지시기)과 같은)가 제공될 수 있다. 몇몇 구현예에서, 데이터 레코드의 처음 N 바이트까지 인-라인으로 포함될 수 있는 한편, 나머지 바이트들(만약에 있다면)은 참조에 의해 제공되는, 하이브리드 제출 인터페이스가 또한 또는 대신 지원될 수 있다. 그러한 시나리오에서, 짧은 레코드들(이의 바디들은 N 바이트 길이보다 짧다)은 제출 요청에 의해 완전히 지정될 수 있는 한편, 보다 긴 레코드들의 부분들은 대응하는 어드레스로부터 획득되어야 할 수 있다.

수집 동안 레코드 콘텐츠를 지정하기 위한 상이한 대안예들에 추가하여, 몇몇 실시예에서 다양한 지식 또는 중복-제거 관련 수집 정책이 또한 구현될 수 있다. 예를 들어, 몇몇 스트림 애플리케이션에 대해, 클라이언트들은 각각의 그리고 모든 데이터 레코드가 SMS에 의해 확실하게 수집된다는 것이 보장되기를 바랄 수 있다. 대규모 분산 스트림 관리 환경들에서, 패킷들이 손실될 수 있거나, 다양한 고장이 데이터 생성자들 및 수집 노드들 간 경로를 따라 때때로 발생할 수 있으며, 이는 어쩌면 몇몇 제출된 데이터 손실을 야기할 수 있다. 따라서, 몇몇 실시예에서, SMS는 최소-한 번 수집 정책을 구현할 수 있으며, 이에 따라 레코드 제출기는 긍정 응답이 수집 서브 시스템으로부터 수신될 때까지 일 회 이상 동일한 레코드를 제출할 수 있다. 정상 작동 상태들 하에서, 레코드는 한 번 제출될 수 있고, 제출기는 수신 수집 노드가 레코드를 획득하고 저장한 후 확인 응답을 수신할 수 있다. 확인 응답이 손실되거나 지연되는 경우, 또는 레코드 제출 요청 그 자체가 손실된 경우, 제출기는 결국에는 확인 응답이 수신될 때까지, 일 회 이상 동일한 데이터 레코드를 다시 제출할 수 있다. 수집 노드는 예를 들어, 확인 응답이 제출기에 의해 이미 수신된 경우 레코드가 다시 제출되지 않을 것이라는 예상에 기초하여, 그것이 중복이든 아니든 관계없이, 각 제출에 대한 확인 응답을 생성할 수 있다. 그러나, 수집 노드는 적어도 몇몇 실시예에서 동일한 데이터 레코드가 다수회 제출되었다는 것을 인식하는 것에 대해, 그리고 중복 데이터의 새로운 카피들을 불필요하게 저장하는 것을 회피하는 것에 대해 책임이 있을 수 있다. 일 실시예에서, 최소-한 번 수집 정책의 적어도 두 개의 버전 - SMS가 데이터 레코드들의 중복을 제거하는 것에 대해 책임이 있는(즉, 데이터가 두 개 이상의 제출의 세트 중 단지 하나에 응답하여 SMS 저장 서브 시스템에 저장된다는 것을 보장하는) 하나의 버전("최소-한 번 수집, 비-중복"이라 칭해질 수 있음), 및 SMS에 의한 데이터 레코드 저장의 중복이 허용되는 하나의 버전("최소-한 번, 중복-허용"이라 칭해질 수 있음) -이 지원될 수 있다. 최소-한 번, 중복-허용 접근법은 데이터 레코드 중복의 몇몇 부정적인 결과가 존재하거나 어떤 부정적인 결과도 존재하지 않는 스트림 애플리케이션들에, 그리고/또는 그것들 자체의 중복 제거를 수행하는 스트림 애플리케이션들에 유용할 수 있다. 확인 응답들이 제출되는 모든 데이터 레코드에 대해 요구되지 않는 최선-노력 수집과 같은, 다른 수집 정책들이 또한 지원될 수 있다. 적어도 몇몇 실시예에서 최선-노력 정책이 시행 중인 경우 몇몇 데이터 레코드의 손실이 수용 가능할 수 있다. 클라이언트들은 어느 수집 정책들이 그들이 다양한 실시예에서 다양한 스트림에 대해 사용하기 바라는 것인지를 선택할 수 있다.

스트림 레코드들의 저장에 대해, 다수의 대안적인 정책이 또한 적어도 몇몇 실시예에서 지원될 수 있다. 예를 들어, 클라이언트는 저장되어야 하는 소정의 데이터 레코드의 카피들의 수, 카피들을 위해 사용될 저장 기술의 유형(예를 들어, 휘발성 또는 비-휘발성 RAM, 회전 디스크-기반 저장장치, 고체 상태 디바이스들(SSD들), 네트워크 연결형 저장 디바이스들, 등) 등으로서 레코드 저장의 그러한 측면들을 통제하는, SMS에 의해 지원되는 몇몇 정책 중으로부터 지속 정책을 선택할 수 있을 수 있다. 예를 들어, 클라이언트가 디스크-기반 저장장치에 대해 N-복제 지속 정책을 선택하는 경우, 데이터 레코드 제출은 레코드의 N개의 카피가 N 개 각각의 디스크 디바이스에 안전하게 기록될 때까지 완전한 것으로 고려되지 않을 수 있다. 디스크-기반 저장 디바이스들이 사용되는 적어도 몇몇 실시예에서, SMS 저장 서브 시스템은 예를 들어, 디스크 시크들(disk seeks)에 미치는 수행 영향을 회피하기 위해, 주어진 분할의 착신 데이터 레코드들을 순차적으로 디스크에 기록하려고 시도할 수 있다. 시퀀스 번호들이 수집 시간들에 기초하여 순서화된 기록 검색을 가능하게 하는 예를 들어 타임 스탬프-기반 기술들을 포함하여, 아래에서 설명될 바와 같은 다양한 기술을 사용하여 데이터 기록들에 대해 생성(그리고 이와 함께 저장)될 수 있다. 소정의 분할의 데이터 레코드들은 함께 예를 들어, 디스크 상에서 연접하여, 그리고 적어도 몇몇 실시예에서 다른 분할들의 데이터 레코드들과 별도로 저장될 수 있다. 몇몇 구현예에서, 보유 정책(클라이언트에 의해 또는 SMS에 의해 선택되는) 또는 중복-제거 시간 윈도우 정책(임의의 소정의 데이터 레코드의 제출에 다음에, 몇몇 복제본이 제출되더라도, 해당 소정의 데이터 레코드의 어떤 복제본도 SMS 저장 서브 시스템에 저장되지 않는다는 것을 보장하도록 SMS가 요구될 수 있는 시간 기간을 나타내는)에 따라, 적어도 몇몇 데이터 레코드는 저장 서비스의 상이한 유형들로 아카이브(archive)되고/되거나 시간 기간 이후 SMS에서 삭제될 수 있다. 그러한 제거 동작들은 스트림 "트리밍"으로서 본 출원에서 지칭될 수 있다. 클라이언트들은 몇몇 실시예에서 스트림 트리밍 요청들을 제출하여, 예를 들어, SMS에 지정된 데이터 레코드들이 더 이상 요구되지 않고 따라서 트리밍 요청을 제출하거나, 또는 지정된 데이터 레코드들의 삭제를 명백하게 요청하는 클라이언트의 관점에서 삭제될 수 있다는 것을 통지할 수 있다. 소정의 스트림의 데이터 레코드들을 소비하는 다수의 클라이언트가 존재할 수 있는 시나리오에서, SMS는 소정의 레코드가 그것이 모든 관심 있어 하는 소비자에 의해 액세스 되기 전, 너무 이르게 삭제되거나 트리밍되지 않는다는 것을 보장하는 것에 대해 책임이 있을 수 있다. 몇몇 구현예에서, 소정의 스트림의 N의 데이터 소비자가 존재하는 경우, 스트림의 소정의 레코드(R)를 삭제하기 전, SMS는 그것이 모든 N의 데이터 소비자가 R을 판독하거나 프로세싱했다는 것을 결정할 때까지 대기할 수 있다. SMS는 예를 들어, 소비자들로부터의 각각의 트리밍 요청들에 기초하여, 또는 스트림 내에서 데이터 소비자들이 얼마나 멀리 진행했는지에 대한 각각의 표시들에 기초하여 R이 모든 소비자에 의해 판독되었음을 결정할 수 있다. 몇몇 실시예에서, 몇몇 유형의 데이터 소비자(테스팅-관련 애플리케이션들과 같은)는 그들이 액세스하기 전 데이터 레코드들의 적어도 작은 서브 세트의 삭제를 수용할 수 있다. 따라서, 애플리케이션들은 적어도 몇몇 실시예에서 검색 전 데이터 삭제의 수용 가능성에 관해 SMS에 통지할 수 있을 수 있고, SMS는 통지들에 따라 삭제들을 스케줄링할 수 있다. 몇몇 실시예에서, 아카이브 정책은 예를 들어, 예를 들어 스트림 데이터 레코드들이 카피되어야 하는 저장 디바이스들의 유형들을 나타내는 데이터 보유 정책, 및 그러한 카피들에 대해 사용될 스케줄링 정책들의 부분으로서 구현될 수 있다.

적어도 몇몇 실시예에서, 복수의 프로그램 인터페이스는 또한 기록 검색을 위해 지원될 수 있다. 일 실시예에서, 하나의 프로그램 인터페이스(예를 들어, getIterator)가 스트림의 분할 내 지정된 논리적 오프셋(예를 들어, 시퀀스 번호 또는 타임 스탬프에 기초한)에 반복자 또는 커서를 인스턴스화하고 위치시키는데 사용될 수 있는 반복자-기반 접근법이 사용될 수 있다. 그 다음 상이한 프로그램 인터페이스(getNextRecords과 같은)가 반복자의 현재 위치에서 시작하여 순차적으로 지정된 수의 데이터 레코드를 판독하는데 사용될 수 있다. 반복자의 인스턴스화는 사실상 클라이언트가 스트림 분할 내 레코드 검색을 위해 임의의 또는 랜덤 시작 위치를 지정하게 할 수 있다. 클라이언트가 그러한 실시예에서 랜덤 액세스 패턴으로 데이터 기록들을 판독하기 바라는 경우, 클라이언트는 새로운 반복자들을 반복적으로 생성해야 할 수 있다. 회전 디스크 기반 저장 시스템들에서, 빈번한 랜덤 액세스들에 대해 요구되는 디스크 시크들은 I/O 응답 시간들에 유의미하게 영향을 미칠 수 있다. 따라서, 랜덤으로보다는 순차적으로 스트림 데이터 레코드들을 판독하는 클라이언트들에 대한 장려책으로서, 순차적인 판독 액세스들에 적용되는 것과 상이한(예를 들어, 보다 높은) 과금 비율들이 적어도 몇몇 실시예에서 랜덤 판독 액세스들에 적용될 수 있다. 그에 따라, 예를 들어, 각 getIterator 호출당 X 통화 단위들, 및 getNextRecords를 통해 검색되는 각 레코드당 Y 통화 단위들이 과금될 수 있으며, 몇몇 구현예에서 X>Y이다. 대안적인 클라이언트 인터페이스들이 다른 동작 카테고리들(수집과 같은)에 대해 지원될 때, 적어도 몇몇 실시예에서 대안들에 대한 과금 비율들 또는 가격들이 또한 상이할 수 있다 - 예를 들어, 클라이언트에게 순차적 판독들에 대한 값보다 많은 랜덤 판독들에 대한 값이 청구될 수 있는 것과 같이, 온-라인 제출 요청에 대한 값보다 많은 참조에 의한 제출 요청에 대한 값이 청구될 수 있다. 데이터 레코드들의 크기들, 시간 경과에 따른 기록 대 판독 요청들의 분산, 선택되는 지속 정책들 등과 같은, 다른 팩터들이 또한 다양한 실시예에서 과금에 영향을 미칠 수 있다.

몇몇 실시예에 따르면, 스트림 프로세싱 서비스(SPS)는 클라이언트들이 많은 프로세싱 스테이지를 포함하는 임의의 복합 프로세싱 작업 흐름들을 지정하게 할 수 있으며, 여기서 소정의 스테이지에서 수행되는 프로세싱의 출력은 제로 이상의 다른 스테이지에 대한 입력으로서 사용될 수 있다. 분할 정책들(데이터 레코드들을 수집, 저장 및 검색하기 위해 SMS에 대해 설명되는 것들과 유사한 )은 몇몇 실시예에서 다양한 스테이지에서 복수의 작업자 노드 중에 프로세싱 작업 부하를 분할하기 위해 사용될 수 있다. 하나의 그러한 실시예에서, 프로그램 SPS 인터페이스들은 클라이언트들이 예를 들어 스테이지에 대한 입력 데이터 소스(들)(예를 들어, 스트림들에 대한 분할 정책들과 함께, 데이터 레코드들이 검색될 하나 이상의 스트림), 스테이지에서 수행될 프로세싱 동작들, 및 스테이지로부터의 출력 또는 결과 분산에 대한 기술자 또는 명세(예를 들어, 출력이 저장 위치들에 저장되어야 할지, 네트워크 종단점에 송신되어야 할지, 또는 상이한 스트림의 형태로 하나 이상의 다른 프로세싱 스테이지 내로 공급되어야 할지)를 포함하여, 임의의 소정의 스테이지에 대한 다양한 구성 설정을 지정하게 하여 구현될 수 있다. 적어도 몇몇 실시예에서, SPS 스테이지에 대해 지정되는 프로세싱 동작들이 멱등성(idempotent)일 수 있다: 즉, 소정의 프로세싱 동작이 동일한 입력 데이터에 대해 다수 회 수행되는 경우, 동작들의 결과는 동작이 단지 한 번만 수행되었을 경우 획득되었을 결과와 상이할 수 있다. 고장들(예를 들어, SPS 스테이지에서의 작업자 노드 고장)에서의 복구는 아래에서 더 상세하게 설명될 바와 같이, 프로세싱 동작들이 멱등성인 경우 간략화될 수 있다. 몇몇 실시예에 따라, 비-멱등성 프로세싱 동작들이 몇몇 또는 모든 SPS 스테이지에서 허용될 수 있다.

입력 스트림 분할 정책들과 같은 구성 정보, 및 그 다음 SPS 프로그램 인터페이스들을 통해 수신되는 프로세싱 동작들의 성질에 적어도 부분적으로 기초하여, 다양한 실시예에서 SPS 제어 서버들은 얼마나 많은 작업자 노드가 프로세싱 작업 흐름의 다양한 스테이지를 위해 초기에 셋 업되어야 하는지를 결정할 수 있다. 작업자 노드들(예를 들어, 사용된 가상 또는 물리적 기계들)을 위해 사용될 자원들의 수행 능력들이 또한 작업자 노드들의 초기 수 및 설치를 결정할 때 고려될 수 있다. 선택된 수의 작업자 노드(몇몇 구현예에서 각각이 실행 가능한 스레드 또는 실행 가능한 프로세스를 포함할 수 있는)가 인스턴스화될 수 있다. 각 작업자 노드는 예를 들어, 적절한 입력 소스들로부터(예를 들어, 하나 이상의 스트림 분할의 검색 노드들로부터) 데이터 레코드들을 획득하고, 데이터 레코드들에 대해 지정된 프로세싱 동작들을 수행하며, 프로세싱의 결과들을 지정된 출력 목적지(들)에 전송하도록 구성될 수 있다. 또한, 적어도 몇몇 실시예에서, 체크포인트 기법이 구현될 수 있으며, 이에 따라 분할 레코드들이 순차적으로 프로세싱되고 있다는 것을 가정할 때, 소정의 작업자 노드가 해당 작업자 노드에서 프로세싱되었던 분할의 부분을 나타내는 체크포인트들 또는 경과 레코드들을 저장하도록 구성될 수 있다. 작업자 노드는 예를 들어, 몇몇 구현예에서 주기적으로(예를 들어, N초마다 한 번씩 또는 R 데이터 레코드가 프로세싱될 때마다 한 번씩) 그리고/또는 SPS 제어 서버로부터의 체크포인트 요청들에 응답하여 영속적 저장장치에 경과 레코드를 기록할 수 있다.

경과 레코드들은 몇몇 실시예에서 작업자 노드 고장들에서의 빠른 복구를 위해 사용될 수 있다. 예를 들어, SPS 제어 서버는 예를 들어, 하트비트 메커니즘(heartbeat mechanism)을 사용하여 그리고/또는 자원 이용 레벨들(CPU 이용, I/O 디바이스 이용, 또는 네트워크 이용 레벨들)을 모니터링함으로써, 시간 경과에 따른 다양한 작업자 노드의 동작 상태를 모니터링할 수 있다. 특정한 작업자 노드가 바람직하지 않거나 이상이 있는 상태(예를 들어, 그것이 무반응이거나 과부하 상태인 경우)라는 SPS 제어 서버에 의한 결정에 응답하여, 대체 작업자 노드가 특정한 작업자 노드의 책임들을 인계하기 위해 인스턴스화될 수 있다. 대체 작업자 노드는 대체 작업자 노드가 프로세싱해야하는 데이터 레코드들의 세트를 식별하기 위해 대체된 작업자 노드에 의해 저장된 가장 최근 경과 레코드에 액세스할 수 있다. 프로세싱 동작들이 멱등성인 실시예들에서, 몇몇 동작이 반복되더라도(예를 들어, 가장 최근 경과 레코드가 대체 작업자의 인스턴스화 전 언젠가 기록되었기 때문에), 프로세싱의 전반적인 결과들은 고장 및 교체에 의해 영향을 받지 않을 수 있다. 몇몇 구현예에서, 주어진 스트림의 서브 세트 또는 이에 의해 프로세싱되었던 분할을 나타내는 경과 레코드들을 저장하는 것에 추가하여, 작업자 노드는 또한 누적된 애플리케이션 상태 정보를 저장하도록 구성될 수 있다. 예를 들어, 스트림 프로세싱 작업 흐름이 서비스 사용량 메트릭스를 나타내는 스트리밍 데이터 레코드들을 분석하는 것에 기초하여 특정한 서비스에 대한 클라이언트 과금액을 결정하는 것에 대해 책임이 있는 경우, 작업자 노드는 다양한 클라이언트에 대해 결정되는 누적 과금액을 주기적으로 저장할 수 있다.

적어도 몇몇 실시예에서, SPS 제어 서버들은 또한 다양한 스테이지에 대한 입력 스트림들의 동적 재분할을 요청하는 것과 같은, 다른 액션들을 초기화하거나, 소정의 스테이지에서 소정의 분할에 할당되는 작업자 노드들의 수를 변경하거나, 몇몇 스테이지에 보다 높은-성능의 작업자 노드들을 할당하거나, 또는 작업자 노드들을 하나의 물리적 자원으로부터 상이한 수행 능력을 갖는 다른 물리적 자원으로 전달함으로써 작업 부하 레벨들 또는 검출된 작업 부하 불균형들(예를 들어, 하나의 분할에 대한 수집 비율들이 다른 분할들의 수집 비율들보다 불균형적으로 높게 되는 경우)을 변경하는 것과 같은 다양한 다른 트리거에 응답하도록 구성될 수 있다. 몇몇 실시예에서, 예를 들어, 체크포인트-기반 복구 정책보다는 최선-노력 복구 정책이 소정의 스테이지를 위해 구현되어야 한다는 SPS 제어 서버에 의한 결정에 응답하여, 위에서 설명된 유형의 경과 레코드들은 적어도 몇몇 SPS 스테이지의 작업자 노드들에 의해 저장되지 않을 수 있다. 그러한 최선-노력 복구 정책의 몇몇 구현예에서, 대체 작업자 노드는 경과 레코드들에의 액세스를 필요로 하지 않고, 새로운 데이터 레코드들이 수신됨에 따라 그것들을 간략하게 프로세싱할 수 있다. 몇몇 실시예에서, 클라이언트가 SPS 스테이지에서 최선-노력 복구 정책을 구현하기를 바라는 경우, 스테이지에서 수행되는 스트림 프로세싱 동작들은 반드시 멱등성일 필요는 없다. 비-멱등성 프로세싱 동작들이 SPS 스테이지에서 스트림 레코드들에 대해 수행되어야 하는 몇몇 실시예에서, 체크포인트-기반 복구는 지원되지 않을 수 있고, 최선-노력 복구와 같은 상이한 복구 기법이 사용될 수 있다. 적어도 일 실시예에서, 단지 멱등성 스트림 프로세싱 동작들이 SPS 스테이지에서 허용될 수 있다.

몇몇 스트림의 데이터 레코드들은 민감한 또는 기밀의 정보를 포함할 수 있거나, 또는 SPS 스테이지들에서 수행되는 프로세싱 동작들은 경쟁자들에 의한 이의 발견이 문제가 될 수 있는 전용 알고리즘들의 사용을 포함할 수 있다. 그에 따라 클라이언트들은 특히 동작들이 클라이언트들 그들 자신에 의해 완전히 제어되지 않는 제공자 네트워크 데이터 센터들에 위치되는 자원들을 사용하여 수행되는 경우, 다양한 카테고리의 스트림 관리 및 프로세싱 동작들에 대하여 우려할 수 있다. 인터넷을 통해 액세스 가능한 하나 이상의 네트워크-액세스 가능 서비스(다양한 유형의 클라우드-기반 데이터베이스, 컴퓨팅 또는 저장 서비스들과 같은)를 제공하기 위해 회사 또는 공공 부문 조직과 같은 엔티티에 의해 셋 업되는 네트워크들 및/또는 클라이언트들의 분산된 세트에 대한 다른 네트워크들이 본 출원에서 제공자 제트워크들로 지칭될 수 있다. 몇몇 실시예에서, 클라이언트들은 이들의 데이터 스트림들에 대해 복수의 보안-관련 옵션 중에서 선택할 수 있을 수 있다. 위에서 설명된 바와 같이, 조합된 SPS 및 SMS 구성은 SMS 및/또는 SPS를 위한 제어 노드들, SMS 수집 노드들, SMS 저장 노드들, SMS 검색 노드들, 및 SPS 프로세싱 또는 작업자 노드들과 같은, 다수의 상이한 기능 카테고리에 속하는 노드들을 포함할 수 있다. 클라이언트들이 이용 가능한 보안-관련 선택들은 몇몇 실시예에서 다양한 유형의 노드들의 설치 또는 위치들에 대한 옵션들을 포함할 수 있다. 예를 들어, 일 실시예에서, 클라이언트는 스트림 레코드들이 제공자 네트워크에 위치되는 자원들을 사용하여 초기에 수집되고/되거나 저장되더라도, 스트림 작업 흐름의 하나 이상의 프로세싱 스테이지에 대한 SPS 작업자 노드들이 클라이언트가 소유하는 설비들 상에 위치되는 컴퓨팅 디바이스들에서 구현될 것을 요청할 수 있을 수 있다. 그러한 설치 요청들에 응답하여, 소정의 스트림에 대한 상이한 기능 카테고리들의 노드들이 상이한 보안 특성들 또는 프로파일들을 갖는 각각의 자원 세트들에서 인스턴스화될 수 있다.

자원 세트들은 예를 들어 물리적 위치, 사용되고 있는 물리적 보안 프로토콜들(예를 들어, 자원들에 물리적으로 액세스할 수 있는), 네트워크 분리 레벨들(예를 들어, 자원들의 네트워크 어드레스들이 다양한 엔티티에 보이는 정도), 멀티-테넌시 대 싱글-테넌시 등을 포함하여, 상이한 실시예들에서의 다양한 보안-관련 특성이 서로 상이할 수 있다. 몇몇 실시예에서, 클라이언트들은 제공자 네트워크 내에 분리된 가상 네트워크들(IVN들)을 설정할 수 있을 수 있으며, 소정의 클라이언트는 해당 클라이언트의 IVN 내에 포함되는 다양한 디바이스의 네트워킹 구성들에 대한 실질적 제어를 갖춘다. 특히, 클라이언트들은 그들의 IVN들 내 다양한 서버 또는 컴퓨트 인스턴스에 할당되는 네트워크 어드레스들(예를 들어, 인터넷 프로토콜 또는 IP 어드레스들)에의 액세스를 한정할 수 있을 수 있다 . 그러한 실시예들에서, 클라이언트들은 이들의 SMS 또는 SPS 노드들의 특정한 서브 세트들이 지정된 IVN들 내에 인스턴스화될 것을 요청할 수 있다. (통상적으로 멀티-테넌트 호스트들로서 구성될 수 있는) 가상화 인스턴스 호스트들과 같은 제공자 네트워크 자원들이 SMS 또는 SPS 노드들의 다양한 카테고리에 대해 사용되고 있는 실시예들에서, 클라이언트는 노드들의 어떤 세트가 해당 클라이언트에 단독으로 속하는 인스턴스들을 구현하는 것에 한정되는 인스턴스 호스트들 상에 인스턴스화될 것을 요청할 수 있다(즉, 몇몇 SMS 또는 SPS 노드가 싱글-테넌트 호스트들로서 구성되는 인스턴스 호스트들에서 구현될 수 있다).

몇몇 실시예에서, 다른 보안-관련 옵션으로서, 클라이언트들은 특정한 스트림의 데이터 레코드들이 그것들이 수집 및 저장 서브 시스템들 간, 저장 및 검색 서브 시스템들 간, 검색 서브 시스템들 및 SPS 작업자 노드들 간, 및/또는 작업자 노드들 및 SPS 출력 목적지들 간 네트워크 링크를 거쳐 전송되기 전 - 예를 들어, SMS에서 수집되기 전 - 암호화될 것을 요청할 수 있다. 클라이언트들은 몇몇 실시예에서 사용될 암호화 알고리즘들을 지정할 수 있다. 일 실시예에서, TLS(전송 계층 보안) 또는 SSL(보안 소켓 계층) 프로토콜들과 같은 보안 네트워킹 프로토콜들은 데이터 레코드 전송들을 위해 그리고/또는 SPS 프로세싱 결과들을 전송하는 것에 위해 사용될 수 있다.

데이터 스트림 개념들 및 개요

도 1은 적어도 몇몇 실시예에 따른, 데이터 스트림 개념들의 간략화된 개요를 제공한다. 도시된 바와 같이, 스트림(100)은 DR 110A, 110B, 110C, 110D 및 110E와 같은, 복수의 데이터 레코드(DR)(110)를 포함할 수 있다. 데이터 생성자들(120A 및 120B)과 같은, 하나 이상의 데이터 생성자(120)(또한 데이터 소스들로서 지칭될 수 있는)는 스트림(100)의 데이터 레코드들의 콘텐츠를 생성하기 위해 기록 동작들(151)을 수행할 수 있다. 다수의 상이한 유형의 데이터 생성자는 예를 들어, 이동 전화 또는 태블릿 애플리케이션들, 센서 어레이들, 소셜 미디어 플랫폼들, 로깅 애플리케이션들 또는 시스템 로깅 구성요소들, 다양한 종류의 모니터링 에이전트들 등과 같은, 상이한 실시예들에서의 데이터의 스트림들을 생성할 수 있다. 하나 이상의 데이터 소비자(130)(데이터 소비자들(130A 및 130B))는 데이터 생성자들(120)에 의해 생성되는 데이터 레코드들의 콘텐츠에 액세스하기 위해 판독 동작들(152)을 수행할 수 있다. 데이터 소비자들(130)은 몇몇 실시예에서 예를 들어, 스트림 프로세싱 스테이지의 작업자 노드들을 포함할 수 있다.

적어도 몇몇 실시예에서, SMS에 저장되는 바와 같은 소정의 데이터 레코드(110)는 데이터 부분(101)(예를 들어, 각각 DR들(110A, 110B, 110C, 110D 및 110E)의 데이터 부분들(101A, 101B, 101C, 101D 및 101E)) 및 시퀀스 번호 SN(102)(예를 들어, 각각 DR들(110A, 110B, 110C, 110D 및 110E)의 SN들(102A, 102B, 102C, 102D 및 102E))을 포함할 수 있다. 시퀀스 번호(102)는 도시된 실시예에서 DR들이 스트림 관리 시스템에(또는 스트림 관리 시스템의 특정한 노드에) 수신되는 순서를 나타낼 수 있다. 데이터 부분들(101)은 몇몇 구현예에서 변경할 수 없는 해석되지 않은 바이트 시퀀스들을 포함할 수 있다: 즉, 기록 동작(152)이 완료될 때, 기록의 결과로서 생성되는 DR의 콘텐츠는 SMS에 의해 변경되지 않을 수 있고, 일반적으로 SMS는 데이터의 시맨틱스를 인식하지 않을 수 있다. 몇몇 구현예에서, 소정의 스트림(100)의 상이한 데이터 레코드들은 상이한 양의 데이터를 포함할 수 있는 한편, 다른 구현예들에서, 소정의 스트림의 모든 데이터 레코드는 동일한 크기일 수 있다. 적어도 몇몇 구현예에서, SMS의 노드들(예를 들어, 수집 서브 시스템 노드들 및/또는 저장 서브 시스템 노드들)은 SN들(102)을 생성하는 것에 책임이 있을 수 있다. 아래에서 더 상세하게 설명될 바와 같이, 데이터 레코드들의 시퀀스 번호들은 항상 연속적일 필요는 없다. 일 구현예에서, 클라이언트들 또는 데이터 생성자들(120)은 기록 요청의 부분으로서, 대응하는 데이터 레코드에 대해 사용될 최소 시퀀스 번호의 표시를 제공할 수 있다. 몇몇 실시예에서, 데이터 생성자들(120)은 예를 들어, 데이터 부분이 획득될 수 있는 저장 디바이스 어드레스(디바이스 명칭 및 디바이스 내 오프셋과 같은) 또는 네트워크 어드레스(URL과 같은)를 제공함으로써, 데이터 레코드들의 데이터 부분들에 대한 포인터들(또는 데이터 부분들의 어드레스들)을 포함하는 기록 요청들을 제출할 수 있다.

스트림 관리 서비스는 데이터 생성자들(120)로부터 데이터를 수신하는 것, 데이터를 저장하는 것, 및 데이터 소비자들(130)이 다양한 실시예에서 하나 이상의 액세스 패턴으로 데이터에 액세스하게 하는 것에 대한 책임이 있을 수 있다. 적어도 몇몇 실시예에서, 스트림(100)은 데이터 레코드들을 수신, 저장, 및 검색하는 것의 작업 부하를 분산하기 위해 분할되거나 "분리(shard)"될 수 있다. 그러한 실시예들에서, 분할 또는 조각은 데이터 레코드의 하나 이상의 속성에 기초하여 착신 데이터 레코드(110)에 대해 선택될 수 있고, 데이터 레코드를 수집, 저장 또는 검색할 특정한 노드들이 분할에 기초하여 식별될 수 있다. 몇몇 구현예에서, 데이터 생성자들(120)은 각 기록 동작에 분할 속성들로서의 역할을 할 수 있는 명백한 분할 키들을 제공할 수 있고, 그러한 키들은 분할 식별자들에 매핑될 수 있다. 다른 구현예들에서, SMS는 데이터 생성자(120)의 아이디, 데이터 생성자들의 IP 어드레스들과 같은 팩터들에 기초하여, 또는 심지어 제출되는 데이터의 콘텐츠에 기초하여 분할 ID를 추론할 수 있다. 데이터 스트림들이 분할되는 몇몇 구현예에서, 시퀀스 번호들은 분할마다를 기초로 할당될 수 있다 - 예를 들어, 시퀀스 번호들이 특정한 분할의 데이터 레코드들이 수신되는 순서를 나타낼 수 있더라도, 두 개의 상이한 분할에서의 데이터 레코드들(DR1 및 DR2)의 시퀀스 번호들은 반드시 DR1 및 DR2가 수신된 상대적 순서를 나타내지는 않을 수 있다. 다른 구현예들에서, 시퀀스 번호들은 분할마다 보다는 스트림-범위를 기초로 할당될 수 있고, 따라서 데이터 레코드(DR1)에 할당되는 시퀀스 번호 SN1이 데이터 레코드(DR2)에 할당되는 시퀀스 번호 SN2보다 낮은 경우, 이는 DR1이 DR1 및 DR2가 속하는 분할들에 관계없이, SMS에 의해 DR2보다 이전에 수신되었다는 것을 암시할 수 있다.

SMS에 의해 지원되는 검색 또는 판독 인터페이스들은 데이터 소비자들(130)이 다양한 실시예에서 순차적으로 그리고/또는 랜덤한 순서로 데이터 레코드들에 액세스하게 할 수 있다. 일 실시예에서, 판독 애플리케이션 프로그래밍 인터페이스들(API들)의 반복자-기반 세트가 지원될 수 있다. 데이터 소비자(130)는 데이터 스트림에 대한 반복자를 획득하기 위한 요청을 제출할 수 있으며, 반복자의 초기 위치는 지정된 시퀀스 번호 및/또는 분할 식별자에 의해 표시된다. 개시자가 인스턴스화된 후, 데이터 소비자는 스트림 또는 분할 내의 해당 초기 위치에서 시작하여 순차적인 순서로 데이터 레코드들 판독하기 위한 요청들을 제출할 수 있다. 데이터 소비자가 어떤 랜덤한 순서로 데이터 레코드들을 판독하기를 바라는 경우, 새로운 반복자가 그러한 실시예들에서 각 판독에 대해 인스턴스화되어야 할 수 있다. 적어도 몇몇 구현예에서, 소정의 분할 또는 스트림의 데이터 레코드들은 통상적으로 디스크 시크들을 회피하는 순차적인 기록 동작들을 사용하여, 시퀀스 번호 순서로 디스크-기반 저장장치에 기록될 수 있다. 순차적 판독 동작들은 또한 디스크 시크들의 오버헤드를 회피할 수 있다. 따라서, 몇몇 실시예에서, 데이터 소비자들은 가격 결정 장려책들을 사용하여 랜덤한 판독들보다 순차적 판독들을 수행하도록 권장될 수 있다: 예를 들어, 반복자 인스턴스화들과 같은 랜덤-액세스 판독 동작들은 순차-액세스 판독 동작들보다 높은 관련 과금 비율들을 가질 수 있다.

예시적인 시스템 환경

도 2는 적어도 몇몇 실시예에 따른, 스트림 관리 시스템(SMS) 및 스트림 프로세싱 스테이지들의 집합을 포함하는 스트림 프로세싱 시스템(SPS)의 다양한 서브 구성요소 간 데이터의 흐름의 개요를 제공한다. 도시된 바와 같이, SMS(208)는 수집 서브 시스템(204), 저장 서브 시스템(206), 검색 서브 시스템(208), 및 SMS 제어 서브 시스템(210)을 포함할 수 있다. SMS 서브 시스템들의 각각은 예를 들어 아래에 설명될 바와 같이 제공자 네트워크(또는 클라이언트가 소유한 또는 서드-파티 시설)의 다양한 자원에서 인스턴스화되는 각각의 실행 가능한 스레드들 또는 프로세스들을 사용하여 구현되는, 하나 이상의 노드 또는 구성요소를 포함할 수 있다. 수집 서브 시스템(204)의 노드들은 스트림에 대한 사용 시 분할 정책에 기초하여 데이터 생성자들(120)(120A, 120B, 및 120C와 같은)로부터 특정한 데이터 스트림의 데이터 레코드들을 획득하도록 구성될 수 있고(예를 들어, SMS 제어 서브 시스템(210)에 의해), 각 수집 노드는 저장 서브 시스템(206)의 대응하는 노드들로 수신된 데이터 레코드들을 전달할 수 있다. 저장 서브 시스템 노드들은 스트림에 대해 선택되는 지속 정책에 따라 다양한 유형의 저장 디바이스 중 임의의 저장 디바이스 상에 데이터 레코드들을 저장할 수 있다. 검색 서브 시스템(208)의 노드들은 SPS(290)의 작업자 노드들과 같은, 데이터 소비자들로부터의 판독 요청들에 응답할 수 있다. SPS(290)의 스테이지들(215A, 215B, 1215C 및 215D)과 같은, 스트림 프로세싱 스테이지들(215)은 SPS 제어 서브 시스템(220)의 도움으로 설정될 수 있다. 각 스테이지(215)는 수신된 데이터 레코드들에 대해 프로세싱 동작들의 세트를 수행하기 위해 SPS 제어 서브 시스템(220)에 의해 구성되는 하나 이상의 작업자 노드를 포함할 수 있다. 도시된 바와 같이, 몇몇 스테이지(215)(215A 및 215B와 같은)는 SMS(280)로부터 직접적으로 데이터 레코드들을 획득할 수 있는 한편, 다른 스테이지들(215C 및 215D)은 다른 스테이지들로부터 이들의 입력들을 수신할 수 있다. 다수의 SPS 스테이지(215)는 몇몇 실시예에서 병렬로 작동할 수 있다, 예를 들어, 상이한 프로세싱 동작들이 스테이지들(215A 및 215B)에서 동일한 스트림으로부터 수신되는 데이터 레코드들에 대해 동시에 수행될 수 있다. 특정한 스트림에 대해 도 2에 예시되는 각각의 서브 시스템들 및 그것들과 유사한 프로세싱 스테이지들이 다른 스트림들에 대해서도 또한 인스턴스화될 수 있다는 것이 주목된다.

적어도 몇몇 실시예에서, 도 2에 도시되는 서브 시스템들 및 프로세싱 스테이지들의 노드들의 적어도 몇몇은 제공자 네트워크 자원들을 사용하여 구현될 수 있다. 이전에 언급된 바와 같이, 인터넷을 통해 액세스 가능한 하나 이상의 네트워크-액세스 가능 서비스(다양한 유형의 클라우드-기반 데이터베이스, 컴퓨팅 또는 저장 서비스들과 같은)를 제공하기 위해 회사 또는 공공 부문 조직과 같은 엔티티에 의해 셋 업되는 네트워크들 및/또는 클라이언트들의 분산된 세트에 대한 다른 네트워크들이 본 출원에서 제공자 제트워크들로 지칭될 수 있다. 서비스들 중 몇몇은 보다 상위-레벨 서비스들을 구축하기 위해 사용될 수 있다: 예를 들어, 컴퓨팅, 저장 또는 데이터베이스 서비스들은 스트림 관리 서비스 또는 스트림 프로세싱 서비스를 위한 빌딩 블록들로서 사용될 수 있다. 제공자 네트워크의 코어 서비스들 중 적어도 몇몇은 서비스 유닛들 소위 "인스턴스들"에 클라이언트 사용을 위해 패키징될 수 있다: 예를 들어, 가상화된 컴퓨팅 서비스에 의해 인스턴스화되는 가상 기계는 "컴퓨트 인스턴스"를 나타낼 수 있고, 저장 서비스에 의해 인스턴스화되는 블록-레벨 볼륨과 같은 저장 디바이스는 "저장 인스턴스"로서 지칭될 수 있거나, 또는 데이터 관리 서버는 "데이터베이스 인스턴스"로서 지칭될 수 있다. 제공자 네트워크의 다양한 네트워크-액세스 가능한 서비스들의 그러한 유닛들이 구현되는 서버들과 같은 컴퓨팅 디바이스들은 본 출원에서 "인스턴스 호스트들"로서 또는 보다 간략하게 "호스트들"로서 지칭될 수 있다. 수집 서브 시스템(204), 저장 서브 시스템(206), 검색 서브 시스템(208), SMS 제어 시스템(210), 프로세싱 스테이지들(215), 및/또는 SPS 제어 서브시스템(220)은 몇몇 실시예에서 복수의 인스턴스 호스트 상의 다양한 컴퓨트 인스턴스들에서 실행하는 스레드들 또는 프로세스들을 포함할 수 있다. 소정의 인스턴스 호스트는 몇몇 컴퓨트 인스턴스를 포함할 수 있고, 특정한 인스턴스 호스트에서의 컴퓨트 인스턴스들의 집합은 하나 이상의 클라이언트의 다양한 상이한 스트림을 위한 노드들을 구현하기 위해 사용될 수 있다. 저장 인스턴스들은 몇몇 실시예에서 다양한 스트림의 데이터 레코드들을 저장하기 위해, 또는 스트림 프로세싱 스테이지들의 결과들의 목적지들로서 사용될 수 있다. 시간 경과에 따라, 제어 서브 시스템 노드들은 예를 들어, 노드들을 추가 또는 제거하거나, 프로세스들 또는 컴퓨트 인스턴스 또는 인스턴스 호스트들에의 노드들의 매핑들을 변경하거나, 또는 도 15 및 도 16을 참조하여 아래에서 설명될 바와 같이 데이터 레코드들을 여전히 계속해서 수신, 저장 및 프로세싱하면서 소정의 스트림을 재-분할함으로써, 다양한 트리거 조건에 응답하여 동적으로 다른 서브 시스템들의 파퓰레이션들을 변형할 수 있다.

제공자 네트워크 자원들이 스트림-관련 동작들에 대해 사용되는 실시예들의 맥락에서, 용어 "클라이언트"는 소정의 전달의 소스 또는 목적지로서 사용될 때, 제공자 네트워크의 적어도 하나의 네트워크-액세스 가능한 서비스에 액세스하고 이를 이용할 수 있는 엔티티(조직, 다수의 사용자를 갖는 그룹 또는 단일 사용자와 같은)에 의해 소유되거나, 관리되거나, 또는 이에 할당되는 컴퓨팅 디바이스들, 프로세스들, 하드웨어 모듈들 또는 소프트웨어 모듈들 중 임의의 것을 나타낼 수 있다. 하나의 서비스의 클라이언트들은 다른 서비스의 자원들을 사용하여 그들 스스로 구현될 수 있다 - 예를 들어, 스트림 데이터 소비자(스트림 관리 서비스의 클라이언트)는 컴퓨트 인스턴스(가상화된 컴퓨팅 서비스에 의해 제공되는 자원)를 포함할 수 있다.

소정의 제공자 네트워크는 제공자에 의해 제공되는 인프라스트럭처 및 서비스들을 구현, 구성 및 분산하기 위해 요구되는, 물리적 및/또는 가상화된 컴퓨터 서버들, 각각 하나 이상의 저장 디바이스들을 갖는 저장 서버들, 네트워킹 장치 등과 같은, 다양한 자원 풀을 호스팅하여 많은 데이터 센터(상이한 지리학적 영역들에 걸쳐 분산될 수 있는)를 포함할 수 있다. 다수의 상이한 하드웨어 및/또는 소프트웨어 구성요소(이 중 몇몇은 상이한 데이터 센터들에서 또는 상이한 지리학적 영역들에서 인스턴스화되거나 실행될 수 있는)는 다양한 실시예에서 서비스들의 각각을 구현하기 위해 총괄적으로 사용될 수 있다. 클라이언트들은 제공자 네트워크 내의 디바이스들로부터의, 그리고/또는 제공자 네트워크 외부의 클라이언트가 소유하거나 클라이언트가 관리하는 부지들 또는 데이터 센터들에 위치되는 디바이스들로부터의 자원들 및 서비스들과 제공자 네트워크에서 상호 작용할 수 있다. 제공자 네트워크들이 본 출원에서 설명되는 스트림 관리 및 스트림 프로세싱 기술들 중 많은 기술이 구현될 수 있는 하나의 예시적인 맥락으로서의 역할을 하더라도, 그것들의 기술들은 또한 제공자 네트워크들과 다른 유형들의 분산 시스템들에, 예를 들어, 그 자체 애플리케이션들에 대한 단일 기업체에 의해 운영되는 대규모 분산 환경들에 적용될 수 있다는 것이 주목된다.

프로그램 인터페이스 예들

위에서 표시된 바와 같이, 적어도 몇몇 실시예에서 SPS는 다양한 스트림-기반 애플리케이션에 대한 원하는 비즈니스 로직을 구현하기 위해 SPS 클라이언트들에 의해 보다 용이하게 사용될 수 있는 보다 상위-레벨 기능을 구축하기 위해 SMS 프로그램 인터페이스들을 이용할 수 있다. SPS 및 SMS 기능 간 차이들을 고려할 때, 유사점이 도움이 될 수 있다: SPS 기능들은 일반적으로 C++과 같은 보다 상위-레벨 언어들로의 프로그래밍 언어 구성소들과 비교될 수 있는 한편, SMS 기능들은 일반적으로 프로그래밍 언어 구성소들이 컴파일러에 의해 변환되는 어셈블리어 명령어들에 비교될 수 있다. 직접 어셈블리어 명령어들을 사용하여 동일한 동작들을 구현하는 것이 가능할 수 있으나, 보다 상위-레벨 언어로 프로그래밍하는 것은 통상적으로 소비자들 또는 사용자들의 많은 카테고리에 대해 보다 용이할 수 있다. 유사하게, SMS에 의해 제공되는 기초 요소들을 사용하여 다양한 애플리케이션들을 구현하는 것이 가능할 수 있으나, SPS 피처들을 사용하여 그렇게 하는 것이 보다 용이할 수 있다. SPS 프로세싱 동작들(데이터 레코드들에 대해 수행되는 멱등성 프로세싱 동작들과 같은)은 스트림 레코드들의 데이터 콘텐츠에 대해 구현될 수 있는 한편, SMS 동작들은 보통 레코드들의 콘텐츠를 고려하지 않고, 레코드들 자체를 획득, 저장 및 검색하기 위해 수행된다. 도 3은 적어도 몇몇 실시예에 따른, SMS 및 SPS에서 구현될 수 있는 프로그램 인터페이스들의 각각의 세트들의 예들을 예시한다. 다수의 상이한 애플리케이션 프로그래밍 인터페이스(API)는 예로서 SMS 및 SPS 양자에 대해 표시된다. 예시되는 API들은 임의의 소정의 구현예에서 지원되는 것들의 완전한 리스트들인 것으로 의도되지 않고, 예시된 API들 중 몇몇이 임의의 소정의 구현예에서 지원되지 않을 수 있다.

화살표(350)에 의해 표시된 바와 같이, SPS 클라이언트들(375)은 프로세싱 스테이지들을 구현하기 위해 SPS 프로그램 인터페이스들(305)을 호출할 수 있다. 다양한 유형의 SPS 프로그램 인터페이스들(305)이 상이한 실시예들에서 구현될 수 있다. 예를 들어, createStreamProcessingStage API는 클라이언트들이 지정된 입력 스트림에 대해 새로운 프로세싱 스테이지(215)의 구성을 요청하게 할 수 있고, 따라서 스테이지의 작업자 노드들이 각각 인터페이스 호출에서 지정되는 멱등성 동작들의 세트를 수행하도록, 그리고 출력 분산 기술자 또는 정책에 의해 표시되는 목적지들로 결과들을 분산하도록 구성된다. createStreamProcessingStage API 또는 이의 균등물의 몇몇 버전에서, 클라이언트는 입력 스트림의 생성을 또한 요청할 수 있는 한편, 다른 버전들에서, 입력 스트림은 프로세싱 스테이지가 생성되기 전 생성되어야 할 수 있다. 복구 정책은 예를 들어 체크포인트-기반 복구 기술이 사용되어야 하는지 또는 최선-노력 복구 기술이 선호되는지를 표시하여, 작업자 노드들에 대해 지정될 수 있다. 몇몇 실시예에서 initializeWorkerNode API는 지정된 스테이지에서 작업자 노드들의 명백한 인스턴스화를 요청하기 위해 지원될 수 있다. 체크포인트-기반 복구가 구현되는 실시예들에서, saveCheckpoint API는 클라이언트들이 경과 레코드들이 작업자 노드에 의해 생성되기를 요청하게 하기 위해 지원될 수 있다.

클라이언트가 지정된 스테이지에서 수행되는 프로세싱 동작들의 결과들을 사용하여 생성될 하나 이상의 스트림, 및 새롭게 생성된 스트림들에 대해 사용될 특정한 분할 정책들을 나타낼 수 있는 setOutputDistribution API와 같은, 다양한 유형의 SPS 출력 관리 API가 상이한 실시예들에서 지원될 수 있다. 몇몇 프로세싱 스테이지는 주로 재분할을 위해 구성될 수 있다 - 예를 들어, 레코드 속성 세트(A1)에 기초하여 N1 분할들에 데이터 레코드들을 매핑하는 하나의 분할 기능(PF1)은 입력 스트림(S1)에 대해 사용 중일 수 있고, (상이한 속성 세트(A2), 또는 동일한 속성 세트(A1) 중 어느 하나를 사용하여) N2 분할들에 그것들의 동일한 데이터 레코드들을 매핑하기 위한 상이한 분할 기능(PF2)을 구현하기 위해 사용될 수 있다. linkStages와 같은 몇몇 SPS API는 복수의 스테이지를 포함하여 임의의 그래프들(예를 들어, 방향성 비주기적 그래프들)을 구성하기 위해 사용될 수 있다. 몇몇 실시예에서, 서드-파티 또는 오픈-소스 스트림 프로세싱 프레임워크들 또는 서비스들에의 연결자들이 지원될 수 있다. 하나의 그러한 실시예에서, SPS 스테이지는 기존의 서드 파티 또는 오픈-소스 시스템들에 의해 소비를 위한 데이터 레코드들(예를 들어, 스테이지에서 수행되는 프로세싱 동작들의 적절한 포맷팅 결과들에 의해)을 준비하기 위해 사용될 수 있다. createThirdPartyConnector와 같은 API가 도시된 실시예에서 그러한 연결자들을 셋 업하기 위해 사용될 수 있고, SPS 스테이지의 결과들의 서드 파티 시스템과 호환 가능한 포맷으로의 적절한 변환들이 createThirdPartyConnector 호출의 결과로서 인스턴스화되는 하나 이상의 연결자 모듈에 의해 수행될 수 있다.

SPS는 화살표(352)에 의해 표시된 바와 같이, 이의 기능들 중 적어도 몇몇 기능을 수행하기 위해 SMS API들(307)을 호출할 수 있다. SMS API들(307)은 예를 들어, 도시된 실시예에서 createStream 및 deleteStream(각각, 스트림을 생성 및 삭제하기 위한) 및 getStreamInfo(소정의 분할에 대한 책임이 있는 다양한 유형의 노드의 네트워크 어드레스와 같은, 스트림에 대한 메타데이터를 획득하기 위한)를 포함할 수 있다. putRecord 인터페이스는 데이터 레코드들을 기록하기 위해 사용될 수 있는 한편, getIterator 및 getNextRecords 인터페이스들은 각각 비-순차적 및 순차적 판독들을 위해 사용될 수 있다. repartitionStream 인터페이스는 몇몇 실시예에서 지정된 스트림의 동적 재분할을 요청하기 위해 사용될 수 있다. 그렇게 하기를 바라는 클라이언트들(370)은 화살표(354)에 의해 표시된 바와 같이, 직접 SMS API들(307)을 호출할 수 있다. 이전에 나타낸 바와 같이, 다양한 다른 SMS 및 SPS API는 또한 다른 실시예들에서 구현될 수 있고, 도 3에 나열되는 API들 중 몇몇은 몇몇 실시예에서 구현되지 않을 수 있다.

다양한 실시예에서, API들와 다른 프로그램 인터페이스들이 또한 또는 대신 SPS 또는 SMS 중 어느 하나를 위해 구현될 수 있다. 그러한 인터페이스들은 그래픽 유저 인터페이스들, 웹 페이지들 또는 웹 사이트, 명령어-라인 인터페이스들 등을 포함할 수 있다. 몇몇 경우에서, 웹-기반 인터페이스들 또는 GUI들은 API들을 빌딩 블록들로서 사용할 수 있다 - 예를 들어, 웹-기반 상호 작용은 SMS 또는 SPS의 제어 구성요소들에서 하나 이상의 API의 호출을 야기할 수 있다. 도 4는 적어도 몇몇 실시예에 따른, SPS 클라이언트들이 스트림 프로세싱 스테이지들의 그래프들을 생성하게 하도록 구현될 수 있는 예시적인 웹-기반 인터페이스를 예시한다. 도시된 바와 같이, 인터페이스는 메시지 영역(402), 그래프 메뉴 영역(404) 및 그래프 설계 영역(403)을 갖는 웹 페이지(400)를 포함한다.

사용자들은 메시지 영역(402)에 스트림 프로세싱 그래프들의 구성, 뿐만 아니라 스트림 개념들 및 기초 요소들에 대해 보다 많이 학습하기 위해 사용되게 하기 위한 링크들에 관한 일반적인 명령어들을 갖출 수 있다. 다수의 그래픽 아이콘은 메뉴 영역(404)에서의 스트림 프로세싱 그래프 도구 세트의 부분으로서 제공될 수 있다. 예를 들어, 클라이언트들은 다양한 SPS 프로세싱 스테이지의 입력들 또는 출력들로서, 서드 파티 프로세싱 환경들에 지속 스트림들(451), 단기 스트림들(452), 또는 연결자들(453)을 표시하게 허용될 수 있다. 웹-기반 인터페이스가 구현되는 SPS/SMS에 대해, 지속 스트림(451)은 이의 데이터 레코드들이 디스크들, 비-휘발성 RAM들, 또는 SSD들과 같은 영속적 저장 디바이스들 상에 저장되는 스트림으로서 정의될 수 있고, 단기 스트림(452)은 이의 데이터 레코드들이 영속적 저장 디바이스들에 저장될 필요는 없는 스트림으로서 정의될 수 있다. 단기 스트림은 예를 들어, 최선-노력 복구 정책이 구현될 상이한 SPS 스테이지에 의해 입력으로서 소비되도록 기대되는 SPS 스테이지의 출력으로부터 생성될 수 있다.

두 가지 유형의 프로세싱 스테이지가 예시적인 SPS 그래프 구성 웹 페이지(400)에서 지원된다: 체크포인트-기반 작업자 노드 복구(예를 들어, 각 작업자 노드는 간격을 두고 경과 레코드들을 저장하고, 특정한 작업자 노드의 고장이 발생할 경우 대체 노드가 프로세싱을 시작할 데이터 레코드들을 결정하기 위해 고장난 노드의 경과 레코드들을 나타낸다)가 사용되는 스테이지들(455), 및 최선-노력 복구가(예를 들어, 대체 작업자 노드들은 경과 레코드들을 나타내지 않으나, 새로운 데이터 레코드들이 수신됨에 따라 단순히 그것들의 프로세싱을 시작한다) 사용되는 스테이지들(456). 각 스테이지에서 수행될 프로세싱 동작들에 관한 세부 사항들이 메시지 영역(402)에서의 명령어들에 의해 표시된 바와 같이, 그래프 구성 영역(403)에서의 대응하는 아이콘을 클릭함으로써 입력될 수 있다. 스트림들, 연결자들, 및 프로세싱 스테이지들에 대한 아이콘에 추가하여, 메뉴 영역(404)은 또한 서드 파티 또는 외부 스트림 프로세싱 시스템들을 나타내는 아이콘 유형(459), 이의 자원들이 프로세싱 스테이지들에 대해 사용되고 있는 제공자 네트워크에서 구현될 수 있는 저장 서비스의 노드들을 나타내는 아이콘 유형(460)을 포함한다.

도 4에 도시된 예시적인 시나리오에서, 클라이언트는 그래프 설계 영역(403) 내에 세 개의 프로세싱 스테이지(412, 415 및 416)를 포함하는 그래프(405)를 구성했다. 체크포인트-기반 복구를 사용하도록 구성되는, 프로세싱 스테이지(412)는 입력으로서 지속적 스트림(411)을 사용한다. 스테이지(412)에서의 출력 또는 프로세싱의 결과들은 두 개의 목적지로 송신된다: 스테이지(415)의 입력을 형성하는 상이한 지속적 스트림(413)의 형태, 및 스테이지(416)의 입력을 형성하는 단지 스트림(414)의 형태. 스테이지들(415 및 416) 양자는 이들의 작업자 노드들을 위해 최선-노력 복구 정책들을 사용한다. 스테이지(415)의 출력은 단기 스트림의 형태로 저장 서비스 노드(419)에 송신된다. 스테이지(415)의 출력은 연결자(417)를 통해 서드 파티 프로세싱 시스템(418)에 송신된다. "그래프를 저장" 버튼(420)은 예를 들어, JSON(자바스크립트 객체 표기법), XML(확장성 마크업 언어) 또는 YAML과 같은 임의의 적절한 포맷으로, 프로세싱 스테이지 그래프의 표현을 저장하기 위해 사용될 수 있다. 임의로 복합한 프로세싱 작업 흐름들은 다양한 실시예에서 도 4에 도시된 것들과 유사한 도구들을 사용하여 구성될 수 있다. 그러한 도구들을 사용하여 생성되는 작업 흐름들은 이어서 활성화될 수 있고, 그러한 활성화들은 SMS API들의 호출들을 야기할 수 있다 - 예를 들어, 도 4의 스테이지(412)와 같은 프로세싱 스테이지를 위한 데이터 레코드들을 획득하기 위해, getIterator 및/또는 getNextRecords 인터페이스들이 스트림(411)에 대해 호출될 수 있다.

도 5는 적어도 몇몇 실시예에 따른, SMS에서 구현될 수 있는 프로그램 레코드 제출 인터페이스들 및 레코드 검색 인터페이스들의 예들을 예시한다. 예시된 DR들(110K 및 110Q)과 같은, 데이터 레코드들은 도시된 실시예에서 다양한 유형의 프로그램 수집 인터페이스들(510)을 통해 SMS에 제출될 수 있다. DR(110)은 몇몇 실시예에서 네 개의 유형의 요소들을 포함할 수 있다: 501A(스트림("S1")에 대한) 또는 501B(스트림("S2")에 대한)와 같은 스트림 식별자, 레코드의 데이터 또는 바디의 표시, 선택적 분할 키(504)(504A 또는 504B와 같은), 및 선택적 시퀀싱 선호 표시자(506)(시퀀싱 선호 표시자들(506A 및 506B)과 같은). 몇몇 데이터 레코드에서 데이터 그 자체는 인-라인으로 제공될 수 있는 한편(예를 들어, DR(110K)의 인라인 데이터(502)), 다른 데이터 레코드들에 대해 포인터 또는 어드레스(503)가 제공되어, 네트워크-액세스 가능한 위치(또는 네트워크 전달들을 필요로 하지 않는 지역적 디바이스에서의 어드레스)를 SMS에 나타낼 수 있다. 몇몇 실시예에서, 소정의 스트림은 인라인 및 참조에 의한(어드레스-기반) 데이터 레코드 제출들 양자를 지원할 수 있다. 다른 실시예들에서, 소정의 스트림은 모든 데이터를 인라인으로 또는 모든 데이터를 참조에 의해 제공하기 위해 데이터 생성자들을 필요로 할 수 있다. 몇몇 구현예에서, 데이터 레코드 제출은 레코드에 대해 사용될 분할 식별자를 포함할 수 있다.

착신 데이터 레코드들(110)은 도시된 실시예에서 분할 정책에 기초하여 각각의 수집 및/또는 저장 노드들로 지향될 수 있다. 유사하게, 레코드 검색은 또한 분할-기반일 수 있다 - 예를 들어, 하나 이상의 검색 노드는 소정의 분할의 레코드들에 지시되는 판독 요청들에 응답하기 위해 지정될 수 있다. 몇몇 스트림에 대해, 데이터 생성자들은 각 데이터 레코드 기록 요청에 명백한 분할 키를 제공하도록 요구될 수 있다. 다른 스트림들에 대해, SMS는 명백하게 제공된 분할 키들과 다른 메타데이터 또는 속성들에 의존하는 분할 기법을 따라 데이터 레코드들을 분산할 수 있을 수 있다 - 예를 들어, 제출 데이터 생성자에 관계된 식별 정보가 분할 키로서 사될 수 있거나, 제출 데이터 생성자의 IP 어드레스의 부분 또는 전부가 사용될 수 있거나, 또는 제출된 데이터의 부분이 사용될 수 있다. 몇몇 구현예에서, 예를 들어, 해시 함수가 128-비트 정수와 같은, 특정한 크기의 정수 값을 획득하기 위해 분할 키에 적용될 수 있다. 해당 크기의 양의 정수들의 전체 범위(예를 들어, 0 내지 2^128-1)는 N개의 연접한 서브-범위로 분할될 수 있으며, 각 서브-범위는 각각의 분할을 나타낸다. 따라서, 그러한 예에서, 데이터 레코드에 대해 결정되거나 제공되는 임의의 소정의 분할 키는 대응하는 128-비트 정수에 해싱될 수 있고, 해당 정수가 속하는 128-비트 정수들의 연접한 서브-범위는 데이터 레코드가 속하는 분할을 나타낼 수 있다. 분할 정책들 및 이들의 사용에 대한 추가 세부 사항들이 도 15에 대해 아래에서 제공된다.

특정한 분할의 데이터 레코드들을 수집 또는 수용하는 것, 데이터 레코드들을 저장하는 것, 및 특정한 분할에 대한 판독 요청들에 응답하는 것에 대한 책임이 있는 노드들의 세트는 도 5에서의 분할에 대한 ISR(수집, 저장 및 검색) 노드들로서 총괄적으로 지칭된다. 표기(Sj-Pk)는 스트림(Si)의 k번째 분할을 나타내기 위해 사용된다. 예시된 실시예에서, ISR 노드들(520A)은 분할(S1-P1)의 레코드들을 수집, 저장 및 검색하기 위해 구성되고, ISR 노드들(520B)은 분할(S1-P2)의 레코드들을 위해 셋 업되고, ISR 노드들(520C)은 분할(S1-P3)의 레코드들을 위해 셋 업되고, ISR 노드들(520K)은 분할(S2-P1)의 레코드들을 위해 셋 업되며, 그리고 ISR 노드들(520L)은 분할(S2-P2)의 레코드들을 위해 셋 업된다. 몇몇 실시예에서, 수집 서브 시스템, 저장 서브 시스템, 또는 검색 서브 시스템의 소정의 노드는 하나보다 많은 분할(또는 하나보다 많은 스트림의 하나보다 많은 분할)의 데이터 레코드들을 핸들링하도록 구성될 수 있다. 몇몇 실시예에서, 소정의 스트림의 단일 분할의 레코드들이 하나보다 많은 노드에 의해 수집, 저장 또는 검색될 수 있다. 소정의 분할(Sj-Pk)에 대해 지정되는 수집 노드들의 수는 적어도 몇몇 경우에서 상이한 분할(Sj-Pl)에 대해 지정되는 수집 노드들의 수와 상이할 수 있고, 또한 상이한 분할(Sj-Pk)에 대해 지정되는 저장 노드들의 수 및/또는 Sj-Pk에 대해 지정되는 검색 노드들의 수와 상이할 수 있다. 수집 및/또는 검색에 대하여, SMS 제어 노드들은 클라이언트들이 어떤 노드들이 어떤 분할들에 대해 책임이 있는지를 결정하게 하기 위해 몇몇 실시예에서 AIP들(getStreamInfo와 같은)을 구현할 수 있다. 데이터 레코드들 및 분할들 간, 그리고 분할들 및 ISR 노드들(또는 제어 노드들) 간 매핑들은 동적 재분할에 관한 논의에서의 아래에서 설명될 바와 같이, 시간 경과에 따라 변형될 수 있다.

몇몇 실시예에서, 몇몇 상이한 프로그램 인터페이스(580)는 소정의 분할로부터의 스트림 데이터 레코드들을 검색 또는 판독하기 위해 구현될 수 있다. 도 5에 도시된 바와 같이, 몇몇 검색 인터페이스(581)는 getIterator(지정된 시퀀스 번호를 갖는 데이터 레코드에서 또는 그 이후에 반복자 또는 판독 커서를 인스턴스화하기 위한) 또는 getRecord(지정된 시퀀스 번호를 갖는 데이터 레코드를 판독하기 위한)와 같은, 비-순차적 액세스들을 위해 구현될 수 있다. 다른 검색 인터페이스들(582)은 getNextRecords(N개의 레코드가 증가하는 시퀀스 번호 순으로, 반복자의 현재 위치로부터 판독될 것을 요청하는 인터페이스)와 같은, 순차적 검색을 위해 구현될 수 있다. 회전 디스크-기반 저장 시스템들에서, 이전에 언급된 바와 같이, I/O 당 평균적으로 요구되는 디스크 헤드 시크들의 수가 랜덤 I/O에 대해서보다 순차적 I/O에 대해서 통상적으로 훨씬 더 낮을 수 있기 때문에, 순차적 I/O는 많은 경우에서 랜덤 I/O보다 훨씬 더 효율적일 수 있다. 많은 실시예에서, 소정의 분할의 데이터 레코드들이 시퀀스 번호 순으로 기록될 수 있고, 결과적으로 시퀀스 번호 순서에 기초한 순차적 판독 요청들(예를 들어, getNextRecords 또는 유사한 인터페이스를 사용하는)은 랜덤 판독 요청들보다 훨씬 더 효율적일 수 있다. 따라서, 적어도 몇몇 실시예에서, 상이한 과금 비율들이 순차적 대 비-순차적 검색 인터페이스들에 대해 설정될 수 있다 - 예를 들어, 클라이언트들은 비-순차적 판독들에 대한 값보다 더 청구될 수 있다.

수집 서브 시스템

도 6은 적어도 몇몇 실시예에 따른, SMS의 수집 서브 시스템(204)의 예시적인 요소들을 예시한다. 도시된 실시예에서, 수집 동작들은 프론트-엔드 및 백-엔드로 논리적으로 분할되며, 프론트-엔드 기능들은 데이터 생성자들(120)(예를 들어, 120A, 120B 또는 120C)과의 상호 작용들을 수반하고, 백-엔드 기능들은 SMS 저장 서브 시스템과의 상호 작용들을 수반한다. 그러한 프론트-엔드/백-엔드 분할은 저장 서브 시스템의 보안을 향상하는 것 및 데이터 생성자들에 대해 분할 정책 세부 사항들을 제공해야 하는 것을 회피하는 것과 같은, 몇몇 이점을 가질 수 있다. SMS 클라이언트 라이브러리들(602)은 다양한 데이터 생성자(120)에 설비를 구비할 수 있고, 데이터 생성자들은 수집을 위한 데이터를 제출하기 위해 라이브러리들(602)에 포함되는 프로그램 인터페이스들을 호출할 수 있다. 예를 들어, 일 실시예에서 데이터 생성자들(120)은 제공자 네트워크의 수백 또는 수천 개의 물리적 및/또는 가상 서버에 인스턴스화되는 로깅 또는 모니터링 에이전트들을 포함할 수 있다. 그러한 에이전트들은 이들의 각각의 서버들에 다양한 로그 메시지 및/또는 메트릭스를 수집할 수 있고 수집된 메시지들 및/또는 메트릭스를 SMS의 하나 이상의 수집 제어 노드(660)에 의해 인스턴스화되는 프론트-엔드 부하 분산기(604) 종단점에 주기적으로 제출할 수 있다. 몇몇 실시예에서, 하나 이상의 가상 IP 어드레스(VIP)는 데이터 생성자들이 스트림 데이터를 제출할 수 있는, 부하 분산기들을 위해 설정될 수 있다. 일 구현예에서, 라운드-로빈 DNS(도메인 네임 시스템) 기술은 데이터가 데이터 생성자들(120)에 의해 송신되어야 할 몇몇 동등하게 구성된 부하 분산기들 중으로부터 특정한 부하 분산기를 선택하기 위해 VIP에 대해 사용될 수 있다.

수신된 데이터 레코드들은 도시된 실시예에서 몇몇 프론트-엔드 노드(606)(예를 들어, 606A, 606B 또는 606C) 중 임의의 노드에 지향될 수 있다. 적어도 몇몇 실시예에서, 부하 분산기(604)는 데이터 레코드들에 대해 사용 시 분할 정책(650)을 인식하지 않을 수 있고, 따라서 프론트-엔드 노드(606)기 분할-기반 부하 균형보다는 라운드-로빈 분할 균형(또는 몇몇 다른 범용 부하 균형 알고리즘)을 사용하여 소정의 데이터 레코드를 위해 선택될 수 있다. 프론트-엔드 노드들(606)은 다양한 스트림에 대한 분할 정책들(650)을 인식하지 않을 수 있고, 소정의 분할의 데이터 레코드들을 위해 구성되는, 특정한 백-엔드 수집 노드(608)(예를 들어, 608A, 608B 또는 608C)의 식별자들을 획득하기 위해 수집 제어 노드들(660)과 상호 작용할 수 있다. 그에 따라, 도시된 실시예에서, 프론트-엔드 노드들(604)은 데이터 레코드들이 속하는 각각의 분할들에 기초하여, 복수의 백-엔드 노드(606)에 데이터 레코드들을 각각 전송할 수 있다. 이전에 언급된 바와 같이, 데이터 레코드가 속하는 분할은 데이터 생성자에 의해 제공되는 분할 키, 데이터 생성자의 아이디 또는 어드레스와 같은 하나 이상의 다른 속성, 또는 데이터의 콘텐츠와 같은, 다양한 팩터의 임의의 조합에 기초하여 결정될 수 있다.

백-엔드 노드들(606)은 하나 이상의 스트림의 하나 이상의 분할에 속하는 데이터 레코드들을 각각 수신할 수 있고, 데이터 레코드들을 저장 서브 시스템의 하나 이상의 노드에 전송할 수 있다. 백-엔드 노드들은 데이터가 HTTP(하이퍼텍스트 전송 프로토콜) "PUT" 웹 서비스 API들을 통해 제출되는 몇몇 실시예에서 "PUT 서버들"로서 지칭될 수 있다. 소정의 백-엔드 노드는 이의 데이터 레코드들이 제어 노드(660)에 질의를 제출(결과적으로 상이한 서브 시스템들에 대한 제어 기능들이 노드들의 개별 세트들에 의해 핸들링되는 실시예들에서 저장 서브 시스템의 제어 노드에 대응하는 질의를 제출할 수 있는)함으로써 전송되어야 할 저장 서브 시스템 노드들의 세트를 결정할 수 있다.

적어도 몇몇 실시예에서, 최소-한 번 수집 정책 또는 최선-노력 수집 정책과 같은, 다수의 상이한 수집 확인 응답 정책(652)이 지원될 수 있다. 최소-한 번 정책에서, 데이터 생성자들(120)은 제출되는 각 데이터 레코드에 대한 긍정적 확인 응답을 필요로 할 수 있고, 확인 응답이 결국에는 수신될 때까지 동일한 데이터 레코드(제1 제출의 확인 응답이 수신되지 않은 경우)를 반복적으로 제출할 수 있다. 최선-노력 수집 정책에서, 긍정적 확인 응답들이 제출되는 적어도 몇몇 데이터 레코드에 대해 요구되지 않을 수 있다(수집 서브 시스템이 간헐적 확인 응답들을 여전히 제공할 수 있거나, 데이터 생성자들로부터의 확인 응답들에 대한 명백한 요청들에 응답할 수 있더라도). 수집 서브 시스템(204)이 데이터 생성자들에 확인 응답들을 제공하도록 요구되는 몇몇 실시예에서, 소정의 데이터 레코드에 대해 책임이 있는 백-엔드 수집 노드(608)는 확인 응답을 생성하기 전, (예를 들어, 스트림에 대해 설정되는 지속 정책에 따라) 데이터 레코드들의 요구된 수의 복제본이 저장 서브 시스템에서 성공적으로 생성될 때까지 대기할 수 있다. 다양한 실시예에서, 예를 들어, 해당 레코드가 동일한 분할 또는 스트림의 다른 레코드들에 관하여 수집된 순서를 나타내는, 시퀀스 번호가 수신되는 각 데이터 레코드에 대한 수집 서브 시스템에 의해 생성될 수 있고, 그러한 시퀀스 번호는 확인 응답으로서, 또는 확인 응답의 부분으로서 데이터 생성자에 리턴될 수 있다. 시퀀스 번호들에 관한 추가 세부 사항들이 도 13a 및 도 13b를 참조하여 아래에서 제공된다. 확인 응답 및/또는 시퀀스 번호는 몇몇 구현예에서 프론트-엔드 노드(606)를 통해 데이터 생성자에 다시 전송될 수 있다. 적어도 일 구현예에서, 최소-한 번 정책은 수집 서브 시스템 그 자체의 프론트-엔드 및 백-엔드 노드들 사이에서 구현될 수 있다 - 예를 들어, 소정의 프론트-엔드 노드(606)는 백-엔드 노드가 확인 응답을 제공할 때까지 적절한 백-엔드 노드(608)에 데이터 레코드를 반복적으로 제출할 수 있다.

수집 제어 노드들(660)은 다른 기능들 중에서도, 스트림들의 동적 재분할에서 기인하는 수집-관련 구성 동작들을 위해, 프론트-엔드 및 백-엔드 노드들을 인스턴스화하는 것, 노드들의 상태 및 작업 부하 레벨들을 모니터링하는 것, 필요 시 시스템 대체 작동들을 조정하는 것, 어떤 노드들이 소정의 분할에 대해 책임이 있는지에 관한 질의들에 대한 또는 정책-관련 질의들에 대한 응답들을 제공하는 것에 대해 책임이 있을 수 있다. 하나 이상의 스트림의 소정의 세트를 위해 지정되는 수집 제어 노드의 수는 몇몇 실시예에서 시간 경과에 따라 그 자체로 변경될 수 있다, 예를 들어, 하나 이상의 마스터 제어 노드는 필요 시 제어 노드 풀을 재구성하는 것에 책임이 있을 수 있다. 도 9 및 도 10에 대하여 더 상세하게 아래에서 설명될 바와 같이, 리던던시 그룹들이 수집 프론트-엔드 또는 백-엔드 노드들을 위해 셋 업되는 몇몇 실시예에서, 제어 노드들(660)은 어떤 노드들이 주요 노드들인지 또는 비-주요한지에 대해 추적하는 것에 대해, 시스템 대체 작동을 위한 트리거 조건을 검출하는 것에 대해, 그리고 시스템 대체 작동들이 쵸구될 때 대체 작동들을 선택하는 것에 대해 책임이 있을 수 있다. 도 6에 예시되는 다수의 층으로 이루어진 수집 서브 시스템 아키텍처가 몇몇 실시예에서 구현되지 않을 수 있다는 것, 예를 들어, 단지 수집 노드들의 단일 세트가 몇몇 시나리오에서 구성될 수 있다는 것이 주목된다.

저장 서브 시스템

도 7은 적어도 몇몇 실시예에 따른 SMS의 저장 서브시스템의 예시적인 요소들을 예시한다. 도시된 바와 같이, 수집 노드들(608)(예를 들어, 프론트-엔드 및 백-엔드 수집 책임들이 노드들의 상이한 세트들에 의해 핸들링되는 실시예들에서 백-엔드 수집 노드들)은 스트림의 하나 이상의 분할의 데이터 레코드들을 그것들의 분할들을 위해 구성되는 각각의 저장 노드들(702)에 전송할 수 있다. 예를 들어, 분할(S1-P1)의 데이터 레코드(110A)는 저장 노드(702A)에 송신되고, 분할(S2-P3)의 데이터 레코드(110B)는 저장 노드들(702B 및 702C)에 송신되고, 분할(S3-P7)의 데이터 레코드(110C)는 저장 노드(702D)에 송신되며, 분할(S4-P5)의 데이터 레코드(110D)는 저장 노드(702E)에 초기에 송신된다. 저장 제어 노드들(780)은 상이한 스트림들의 데이터 레코드들에 적용되는 지속 정책들(750)을 시행하는 것, 필요 시 저장 노드들을 구성 및 재구성하는 것, 저장 노드 상태들을 모니터링하는 것, 시스템 대체 작동들을 관리하는 것, 저장 구성 질의들 또는 저장 정책 질의들에 응답하는 것, 및 도시된 실시예에서의 다양한 다른 관리 작업에 대해 책임이 있을 수 있다.

지속 정책들(750)은 상이한 실시예들에서 다양한 방식으로 서로 상이할 수 있다. 예를 들어, 스트림(Sj)에 적용되는 지속 정책(P1)은 스트림(Sk)에 적용되는 지속 정책(P2)과 (a) 저장될 각 데이터 레코드의 복제본들의 수, (b) 복제본들이 저장되어야 할 저장 디바이스 또는 시스템의 유형(예를 들어, 복제본들이 제공자 네트워크에 의해 구현되는 저장 서비스의 노드들에서의, 데이터베이스 관리 시스템들에서, 휘발성 메모리에 저장되어야 할지, 비-휘발성 캐시들에 저장되어야 할지, 회전 디스크-기반 저장장치에 저장되어야 할지, 고체-상태 드라이브들(SSD들)에 저장되어야 할지, 다양한 종류의 저장 기기들에 저장되어야 할지, 다양한 종류의 RAID(값이 싼 디스크들의 리던던트 어레이들)에 저장되어야 할지 등), (c) 복제본들의 지리학적 분산(예를 들어, 스트림 데이터가 상이한 데이터 센터들에서 복제본들을 둠으로써 대규모 고장들에 회복력을 가져야 할지 또는 재난들의 특정한 유형들에 회복력을 가져야 할지), (d) 기록 확인 응답 프로토콜(예를 들어, N개의 복제본이 저장되어야 하는 경우, N개의 카피 중 얼마나 많은 카피가 확인 응답이 수집 노드에 대해 제공되어야 하기 전 성공적으로 기록되어야 할지), 및/또는 (e) 데이터 레코드들의 다수의 복제본이 저장되어야 하는 경우, 복제본들이 병렬로 생성되어야 하는지 또는 순차적으로 생성되어야 하는지에 있어서 상이할 수 있다. 다수의 복제본이 저장되어야 하는 몇몇 경우에서, 데이터 레코드(110D)의 경우에서와 같이, 소정의 저장 노드는 다른 저장 노드에 데이터 레코드를 전송할 수 있다(예를 들어, 저장 노드(702E)는 저장 노드(702F)에 추가 복제를 위한 데이터 레코드(110D)를 송신하고, 저장 노드(702F)는 저장 노드(702G)에 이를 송신한다). 다수의 복제본 지속 정책이 사용되는 다른 경우들에서, 두 개의 인-메모리 복제본이 저장되어야 할 데이터 레코드(110B)의 경우에서와 같이, 수집 노드는 다수의 복제를 병렬로 개시할 수 있다. 적어도 몇몇 실시예에서, 클라이언트가 선택한 지속 정책은 스트림 데이터 레코드들을 위해 사용될 저장 위치의 유형을 지정하지 않을 수 있다; 대신, SMS는 비용, 성능, 데이터 소스들에 대한 접근성, 내구성 요건 등과 같은, 다양한 기준에 기초하여 적절한 유형들의 저장 기술 및/또는 위치들을 선택할 수 있다. 일 실시예에서, 클라이언트 또는 SMS 중 어느 하나는 소정의 스트림의 상이한 분할들을 위해, 또는 상이한 스트림들을 위해 상이한 저장 기술들 또는 저장 위치 유형들을 사용하기로 결정할 수 있다.

도 7에 도시된 예에서, 스트림(S1)(또는 스트림(S1)의 적어도 분할(S1-P1))에 적용되는 지속 정책은 단일-복제본 인-메모리 정책인 한편, 스트림(S2)에 대해서는 두-병렬-복제본 인-메모리 정책이 적용된다. 따라서, 데이터 레코드(110A)의 인-메모리 복제본(704A)이 저장 노드(702A)에 생성되는 한편, 데이터 레코드(110B)에 대응하는 두 개의 인-메모리 복제본(705A 및 705B)은 저장 노드들(702B 및 702C)에서 병렬로 생성된다. 스트림(S3)의 데이터 레코드(110C)에 대해서는, 단일 온-디스크 복제본(706A)이 생성된다. 스트림(S4)에 대해서는, 순차적 세-복제본-온-디스크 정책이 적용 가능하고, 결과적으로 각각의 온-디스크 복제본들(707A, 707B 및 707C)이 저장 노드들(702E, 702F 및 702G)에서 순차적으로 생성된다. 다양한 다른 유형의 지속 정책이 상이한 실시예들에서의 데이터 스트림들에 적용될 수 있다. 검색 서브 시스템의 노드들은 데이터 소비자들에 의한 다양한 유형의 검색 API들의 호출들에 응답하여 적절한 저장 노드들로부터 데이터 레코드들을 획득할 수 있다.

검색 서브 시스템 및 프로세싱 스테이지들

도 8은 적어도 몇몇 실시예에 따른, SMS의 검색 서브 시스템의 예시적인 요소들 및 검색 서브 시스템의 SPS와의 상호 작용들의 예들을 예시한다. 도시된 바와 같이, 검색 서브 시스템(206)은 검색 노드(802A, 802B 및 802C)와 같은, 복수의 검색 노드(802), 뿐만 아니라 검색 제어 노드들의 집합(880)을 포함할 수 있다. 검색 노드들(802)의 각각은 아래에서 설명될 바와 같이 SPS의 작업자 노드들(840)과 같은, 다양한 클라이언트 또는 데이터 소비자(130)로부터의 스트림 데이터 검색 요청들에 응답하도록 구성될 수 있다. 다양한 프로그램 검색 인터페이스(802)가 이전에 설명된 비-순차적 및 순차적 검색 인터페이스들과 같은, 상이한 실시예들에서의 검색 노드들에 의해 구현될 수 있다. 몇몇 실시예에서, 웹 서비스들(API들) 이를테면 HTTP GET 요청들은 데이터 레코드 검색을 위해 사용될 수 있고, 따라서 검색 노드들(802)은 GET 서버들로서 지칭될 수 있다. 소정의 검색 노드(802)는 저장 노드들(702A 및 702B)과 같은, 저장 서브 시스템 노드들(702)의 적절한 세트로부터 도시된 실시예에서 하나 이상의 스트림 분할의 데이터 레코드들을 획득하도록, 예를 들어, 검색 제어 노드(880)에 의해 구성될 수 있다.

도시된 실시예에서, 검색 노드(802)는 하나 이상의 저장 노드(702)와 상호 작용하고, 또한 하나 이상의 SPS 작업자 노드(840)로부터 수신되는 검색 요청들에 응답할 수 있다. 예를 들어, 분할들(S4-P5)의 데이터 레코드들(예를 들어, 데이터 레코드(110K)) 및 분할들(S5-P8)의 데이터 레코드들(예를 들어, 데이터 레코드(110L))는 검색 노드(802A)에 의해 저장 노드(702A)로부터 판독되고, 각각 작업자 노드들(840A 및 840K)에 제공된다. 110M과 같은, 분할(S6-P7)의 데이터 레코드들은 저장 노드(702A)로부터 검색 노드(802B)에 의해 판독되고 작업자 노드(840K)에 제공된다. 분할(S4-P7)의 데이터 레코드들은 저장 노드(702B)로부터 검색 노드(802C)에 의해 판독되고 작업자 노드(840B)에, 그리고 또한 다른 데이터 소비자들(130)(예를 들어, SPS를 통해 SMS와 상호 작용하는 대신 SMS 검색 API들을 직접적으로 호출하는 데이터 소비자들)에 제공된다.

적어도 몇몇 실시예에서, 검색 노드들(802)의 몇몇 또는 전부는 다양한 분할들의 데이터 레코드들이 장차 검색 요청들을 예상하고 일시적으로 보존될 수 있는 각각의 캐시들(804)(검색 노드(802A)에서의 캐시(804A), 검색 노드(802B)에서의 캐시(804B), 및 검색 노드(802C)에서의 캐시(804C))을 구현할 수 있다. 검색 제어 노드들(880)은 예를 들어 캐싱 정책들(예를 들어, 얼마나 큰 캐시가 소정의 분할을 위해 구성되어야 하는지), 저장 노드 선택 정책들(예를 들어, 데이터 레코드들의 다수의 복제본이 저장되는 시나리오들에서, 어떤 특정한 저장 노드가 먼저 소정의 데이터 레코드를 획득하기 위해 접속되어야 하는지) 등을 포함하여, 다수의 검색 정책(882)을 구현하는 것에 대해 책임이 있을 수 있다. 또한, 검색 제어 노드들은 검색 노드들(802)을 인스턴스화 및 모니터링하는 것, 어떤 검색 노드들이 어떤 분할들에 대해 책임이 있는지에 관한 질의들에 응답하는 것, 재-분할 동작들을 개시 또는 이들에 응답하는 것 등에 대한 책임이 있을 수 있다.

예시된 예에서, SPS(290)는 두 개의 및 스테이지, 215A 및 215B를 포함한다. SPS 제어 노드들(885)은 분할(S4-P5)의 레코드들을 프로세싱하기 위한 작업자 노드(840A), 분할(S4-P7)의 레코드들을 프로세싱하기 위한 작업자 노드(840B), 및 분할들(S5-P8 및 S6-P7)의 레코드들을 프로세싱하기 위한 작업자 노드(840K)와 같은, 다양한 프로세싱 스테이지(215)에 작업자 노드들(804)을 인스턴스화하는 것에 대해 책임이 있을 수 있다. SPS 제어 노드들(885)은 SPS 클라이언트들이 프로세싱 작업 흐름들을 설계하게 하는 프로그램 인터페이스들(도 3 및 도 4에 예시된 것들과 같은)을 구현할 수 있다. 다양한 체크포인트 정책(850)은 작업자 노드들이 이들이 이들의 각각의 분할들을 얼만큼 프로세싱하고 있는지를 표시하는 경과 레코드들을 저장해야 할 때 또는 그러한 경우, 경과 레코드들을 위해 사용될 저장 디바이스들의 유형들 등을 표시하여, 상이한 프로세싱 스테이지들 또는 작업 흐름들에 대해 구현될 수 있다. 시스템 대체 작동/복구 정책들(852)은 작업자 노드를 상이한 노드로 대체하는 것을 초래할 트리거 조건 또는 임계, 및 소정의 프로세싱 스테이지에 대해 최선-노력 복구가 사용될지 또는 체크포인트-기반 복구가 사용될지를 나타낼 수 있다. 적어도 몇몇 실시예에서, SPS 제어 노드들(885)은 예를 들어, 소정의 스트림의 데이터 레코드들이 획득될 검색 노드들을 식별하기 위해, 특정한 프로세싱 작업 흐름에 대해 요구될 수 있는 새로운 단기 또는 지속적 스트림들을 설정하는 등을 위해, 다양한 유형의 SMS 제어 노드들과 상호 작용할 수 있다. 적어도 일 실시예에서, 클라이언트들은 스트림들을 인스턴스화하기 위해 SPS 제어 노드들과 상호 작용할 수 있다 - 예를 들어, SMS 제어 노드들을 이용하는 대신, 몇몇 클라이언트가 단지 보다 상위-레벨 SPS 인터페이스들을 호출하기를 바랄 수 있다. 제어 노드들의 별개의 세트들이 SMS 수집, 저장, 및 검색 서브 시스템들에 대해, 및 SPS 스테이지들에 대해 도 6, 도 7 및 도 8에 도시되더라도, 적어도 몇몇 실시예에서 소정의 제어 노드는 서브 시스템들 및/또는 SPS 중 몇몇에 대해 사용될 수 있다.

노드 리던던시 그룹들

적어도 몇몇 실시예에서, 노드들의 리던던트 그룹들은 SMS의 하나 이상의 서브 시스템을 위해 구성될 수 있다. 즉, 예를 들어 스트림 분할(Sj-Pk)에 대한 데이터 레코드들을 검색하기 위해 하나의 검색 노드를 구성하는 대신, 두 개 이상의 노드가 그러한 검색들을 위해 설정될 수 있으며, 하나의 노드에는 소정의 시점에 "주요" 또는 활동 중(active) 중 역할이 주어지는 한편, 다른 노드 또는 노드들는 "비-주요" 노드들로서 지정된다. 현재 주요 노드는 요청들, 예를 들어, 다른 서브 시스템들의 노드들로부터 또는 클라이언트들로부터 중 어느 하나로부터 수신되는 요청들을 작업하는 것에 대해 책임이 있을 수 있다. 비-주요 노드 또는 노드들은 시스템 대체 작동이 예를 들어, 고장, 주요 노드에 대한 연결의 끊김, 또는 다른 트리거 조건으로 인해 트리거될 때까지 휴면 상태로 남아있을 수 있으며, 이 트리거 지점에서 선택된 비-주요 노드는 이전의 주요 노드의 책임들을 인계하도록 제어 노드에 의해 통지될 수 있다. 따라서 주요 역할이 시스템 대체 작동 동안 현재 현직 주요 노드에서 취소되고, 현재 비-주요 노드에 주어질 수 있다. 몇몇 실시예에서, 비-주요 노드들은 시스템 대체 작동이 발생할 것이라는 결정이 이루어질 때 그들 스스로 주요 노드를 맡을 수 있다, 예를 들어, 명백한 통지들이 요구되지 않을 수 있다. 다양한 실시예에서 노드들의 그러한 리던던트 그룹들은 SMS에서의 수집, 저장, 검색 및/또는 제어 기능들에 대해 셋 업될 수 있고, 적어도 몇몇 실시예에서 유사한 접근법이 SPS에의 작업자 노드들을 위해 또한 취해질 수 있다. 소정의 기능을 위한 적어도 하나의 주요 노드 및 적어도 하나의 비-주요 노드를 포함하는 그러한 그룹들은 몇몇 실시예에서 "리던던시 그룹들" 또는 "복제 그룹들"로서 지칭될 수 있다. 저장 노드들의 리던던시 그룹들이 저장되는 데이터 레코드들의 물리적 카피들의 수와 관계없이 구현될 수 있다는 것이 주목된다 - 예를 들어, 데이터 레코드의 저장될 복제본들의 수는 지속 정책에 의해 결정될 수 있는 한편, 대응하는 분할을 위해 구성되는 저장 노드들의 수는 리던던시 그룹 정책들에 기초하여 결정될 수 있다.

도 9는 적어도 몇몇 실시예에 따른, SMS 또는 SPS의 노드들을 위해 셋 업될 수 있는 리던던시 그룹들의 예들을 예시한다. 도시된 실시예에서, 소정의 스트림 분할(Sj-Pk)에 대해, 각각의 리던던시 그룹들(RG들)(905, 915, 925 및 935)이 수집 노드들, 저장 노드들, 검색 노드들, 및 제어 노드들을 위해 셋 업된다. 몇몇 실시예에서 수집 제어 노드들, 저장 제어 노드들, 또는 검색 제어 노드들을 위한 개별 RG들이 구현될 수 있더라도, 예시된 실시예에서 제어 노드들을 위한 공통 RG(935)가 구현된다. 각 RG 는 주요 노드(예를 들어, 주요 수집 노드(910A), 주요 저장 노드(920A), 주요 검색 노드(930A), 및 주요 제어 노드(940A)) 및 적어도 하나의 비-주요 노드(예를 들어, 비-주요 수집 노드(910B), 비-주요 저장 노드(920B), 비-주요 검색 노드(920C), 및 비-주요 검색 노드(920D))를 포함한다. 각각의 시스템 대체 작동 정책들(912)(수집 노드들을 위한), 922(저장 노드들을 위한), 932(검색 노드들을 위한) 및 942(제어 노드들을 위한)에 따라 주요 역할이 취소되고 현재 비-주요 노드에 주어질 수 있다. 시스템 대체 작동 정책들은 예를 들어, 주요 상태의 변경을 초래할 트리거 조건, 주요 노드들 또는 비-주요 노드들의 동작 상태가 모니터링되어야 할지 여부 그리고 어떻게 모니터링될지, 소정의 리던던시 그룹으로 구성될 비-주요들의 수를 관리할 수 있다. 적어도 몇몇 실시예에서, 단일 RG가 다수의 분할에 대해 설정될 수 있다 - 예를 들어, RG(905)가 분할(Sj-Pk)뿐만 아니라 분할(Sp-Pq)의 레코드들의 수집을 핸들링하는 것에도 책임이 있을 수 있다. 몇몇 구현예에서, 하나의 분할을 위한 주요 노드로서 지정되는 노드가 다른 분할을 위한 비-주요 노드로서 동시에 지정될 수 있다. 일 실시예에서, 다수의 노드가 소정의 RG 내 주요 노드들로서 동시에 지정될 수 있다 - 예를 들어, 소정의 분할의 수집-관련 작업 부하가 두 개의 주요 노드 중에 분산될 수 있으며, 하나의 노드는 어느 하나의 주요 노드에서 고장의 경우 비-주요 노드로서 지정된다. 소정의 RG에 인스턴스화되는 노드들의 수는 이용 가능성 또는 대응하는 기능들을 위해 원하는 회복 레벨에(예를 들어, 그룹이 견딜 수 있도록 의도되는 동시 또는 중첩 고장들이 얼마나 많은지에) 의존할 수 있다. 몇몇 실시예에서, SMS 노드들을 위해 사용되는 것에 추가하여 또는 그 대신, 리던던시 그룹들이 SPS 프로세싱 스테이지들의 작업자 노드들을 위해 셋 업될 수 있다. 소정의 RG의 멤버들은 때때로 지리적으로, 예를 들어, 도 10에 예시된 바와 같이, 몇몇 데이터 센터에 걸쳐 분산될 수 있다. 선택된 제어 노드들은 몇몇 실시예에서, 예를 들어, 하트비트 메커니즘들 또는 다른 상태 모니터링 기술들을 사용하여 시스템 대체 작동-트리거 조건을 검출하도록 구성될 수 있고, 그러한 제어 노드들은 고장난 주요 노드에 대한 대체로서 적절한 비-주요 노드를 선택함으로써, 선택된 대체 노드를 통지/활성화함으로써, 그리고 기타 등등에 의해 시스템 대체 작동을 조정할 수 있다.

몇몇 실시예에서 제공자 네트워크는 복수의 지리적 영역들 내로 조직될 수 있고, 각 영역은 하나 이상의 이용 가능 컨테이너를 포함할 수 있으며, 이는 또한 본 출원에서 "이용 가능 구역들"로 지칭될 수 있다. 이용 가능 컨테이너는 결과적으로 소정의 이용 가능 컨테이너에서의 자원들이 다른 이용 가능 컨테이너들에서의 고장들로부터 보호되는 것과 같은 방식으로(예를 들어, 전력-관련 장비, 냉각 장비, 물리적 보안 구성요소들과 같은 독립적인 인프라스트럭처 구성요소들을 가지고) 제작되는, 하나 이상의 별개의 위치 또는 데이터 센터를 포함할 수 있다. 하나의 이용 가능 컨테이너에서의 고장은 임의의 다른 이용 가능 컨테이너에서의 고장을 야기하는 것으로 예상되지 않을 수 있다; 따라서, 자원 인스턴스 또는 제어 서버의 이용 가능 프로파일은 상이한 이용 가능 컨테이너에서의 자원 인스턴스들 또는 제어 서버들의 이용 가능 프로파일과 관계가 없는 것으로 의도된다. 다양한 유형의 애플리케이션들은 각각의 이용 가능 컨테이너들에서의 다수의 애플리케이션 인스턴스를 개시함으로써, 또는 (몇몇 SMS 및 SPS의 경우) 다수의 이용 가능 컨테이너에 걸쳐 소정의 리던던시 리던던시의 노드들을 분산함으로써 단일 위치에서의 고장들로부터 보호될 수 있다. 동시에, 몇몇 구현예에서, 값이 싸고 낮은 레이턴시 네트워크 연결이 동일한 지리적 영역 내에 존재하는 자원들(SMS 및 SPS 노드들에 대해 사용되는 호스트들 또는 컴퓨터 인스턴스들과 같은) 사이에 제공될 수 있고, 동일한 이용 가능 컨테이터의 자원들 간 네트워크 전송들은 훨씬 더 빠를 수 있다. 몇몇 클라이언트는 정확하게 이들의 애플리케이션들의 다양한 구성요소가 실행되는 경우에 대한 제어의 원하는 정도를 유지하기 위해, 이들의 스트림 관리 또는 스트림 프로세싱 자원들이 예약 할당되고/되거나 인스턴스화되는 위치들을 예를 들어, 영역 레벨, 이용 가능 켄터이너 레벨, 또는 데이터 센터 레벨에, 지정하기를 바랄 수 있다. 다른 클라이언트들은 자원들이 클라이언트 요건, 예를 들어, 성능을 위한, 높은 이용 가능성 등을 충족하는 한, 이들의 자원들이 예약 할당되거나 인스턴스화되는 정확한 위치에 덜 관심이 있을 수 있다. 하나의 이용 가능 컨테이너(또는 데이터 센터)에 위치되는 제어 노드들은 몇몇 실시예에서 다른 이용 가능 컨테이너들(또는 데이터 센터들)에 다른 SMS 또는 SPS 노드들을 원격으로 구성할 수 있을 수 있다 - 즉, 특정한 이용 가능 컨테이너 또는 데이터 센터는 SMS/SPS 노드들을 관리하기 위한 지역적 제어 노드들을 가질 필요가 없을 수 있다.

도 10은 적어도 몇몇 실시예에 따른, 소정의 리던던시 그룹의 노드들이 복수의 데이터 센터 간에 분산될 수 있는 제공자 네트워크 환경을 예시한다. 제공자 네트워크(1002)는 도시된 실시예에서 세 개의 이용 가능 컨테이너(1003A, 1003B 및 1003C)를 포함한다. 각 이용 가능 컨테이너는 하나 이상의 데이터 센터의 부분들 또는 전부를 포함한다 - 예를 들어, 이용 가능 컨테이너(1003A)는 데이터 센터들(1005A 및 1005B)을 포함하고, 이용 가능 컨테이너(1003B)는 데이터 센터(1005C)를 포함하며, 이용 가능 컨테이너(1003C)는 데이터 센터(1005D)를 포함한다. SMS 및/또는 SPS의 다수의 상이한 리던던시 그룹(1012)이 도시된다. 몇몇 RG(1012)는 데이터 센터(1005A) 내에 위치되는 RG(1012A)의 경우에서와 같이, 단일 데이터 센터 내에 전체적으로 구현될 수 있다. 이용 가능 컨테이너(1003A)의 데이터 센터들(1005A 및 1005B)에 걸쳐 이어지는, RG(1012B)와 같은, 다른 RG들은 소정의 이용 가능 컨테이너 내 다수의 데이터 센터의 자원들을 사용할 수 있다. 그러나 다른 RG들은 상이한 이용 가능 컨테이너들에 걸쳐 분산되는 자원들을 사용하여 구현될 수 있다. 예를 들어, RG(1012C)는 각각 이용 가능 컨테이너들(1003A 및 1003B)의 데이터 센터들(1005B 및 1005C)에 위치되는 자원들을 사용하고, RG(1012D)는 각각 이용 가능 컨테이너들(1003A, 1003B 및 1003C)에서의 데이터 센터들(1005B, 1005C 및 1005D)에서의 자원들을 이용한다. 하나의 예시적인 배치에서, RG(1012)가 하나의 주요 노드 및 두 개의 비-주요 노드를 포함하는 경우, 세 개의 노드의 각각은 상이한 이용 가능 컨테이너에 위치되고, 그에 따라 대규모 고장 이벤트들이 두 개의 상이한 이용 가능 컨테이너에서 동시에 발생하더라도 적어도 하나의 노드가 기능적으로 남아있을 가능성이 높다는 것을 보장할 수 있다.

각각 SMS 및 SPS와 연관된, 콘솔 서비스들(1078 및 1076)은 도시된 실시예에서 제공자 네트워크(1002)에 스트림-관련 설정들을 구성하기 위해 사용하기 쉬운 웹-기반 인터페이스들을 제공할 수 있다. 다수의 추가적인 서비스(이 중 적어도 몇몇이 SMS 및/또는 SPS에 의해 사용될 수 있음)는 하나 이상의 데이터 센터에 걸쳐 또는 하나 이상의 이용 가능 컨테이너에 걸쳐 분산되는 자원들을 사용하여 제공자 네트워크(1002)에서 구현될 수 있다. 예를 들어, 가상 컴퓨팅 서비스(1072)가 클라이언트들이 다양한 상이한 역량 레벨의 컴퓨트 인스턴스들로서 패키징되는 컴퓨팅 전력의 선택된 양을 이용하게 하여, 구현될 수 있고, 그러한 컴퓨트 인스턴스들은 SMS 및/또는 SPS 노드들을 구현하기 위해 사용될 수 있다. 하나 이상의 저장 서비스(1070)는 클라이언트들이 예를 들어, 블록-디바이스 볼륨 인터페이스를 통해 또는 웹-서비스 인터페이스를 통해, 원하는 데이터 내구성 레벨들을 갖는 데이터 객체들을 저장하고 이들에 액세스하게 하여, 구현될 수 있다. 저장 객체들은 서비스(1072)의 컴퓨트 인스턴스들에 연결 가능하거나, 이들로부터 액세스 가능할 수 있고, 몇몇 실시예에서 SMS 저장 서브 시스템들에 다양한 스트림 지속 정책들을 구현하기 위해 사용될 수 있다. 일 실시예에서, 고-성능 키-값 데이터베이스 관리 서비스(1074) 또는 관계형 데이터베이스 서비스와 같은 하나 이상의 데이터 서비스가 제공자 네트워크(1002)에 구현될 수 있고, 그러한 데이터베이스 서비스는 SMNS 저장 서브 시스템들에 의해 스트림 데이터 레코드들을 저장하기 위해, 그리고/또는 제어 서브 시스템들, 수집 서브 시스템들, 저장 서브 시스템들, 검색 서브 시스템들, 또는 프로세싱 스테이지들의 메타데이터를 저장하기 위해 사용될 수 있다.

스트림 보안 옵션들

적어도 몇몇 실시예에서, SMS 및/또는 SPS의 사용자들은 클라이언트들이 수집, 저장, 검색, 프로세싱 및/또는 제어와 같은 다양한 기능 카테고리를 위해 사용될 자원들(예를 들어, 가상 또는 물리적 기계들)의 보안 프로파일들을 선택하게 하여, 데이터 스트림들을 위한 다수의 보안-관련 옵션을 구비할 수 있다. 그러한 옵션들은 예를 들어, 다양한 노드를 위해 사용되는 자원들의 물리적 위치들의 유형에 관한 선택들(예를 들어, 제공자 네트워크 설비들이 사용될지, 또는 제공자 네트워크 설비들과 상이한 보안 특성들을 가질 수 있는, 클라이언트가 소유한 설비들이 사용될지), 스트림 데이터의 암호화에 관한 선택들, 및/또는 스트림-핸들링 인프라스트럭처의 다양한 부분에서의 네트워크 분리 선택들을 포함할 수 있다. 몇몇 클라이언트는 예를 들어, 가치 있는 사유 비즈니스 로직 또는 알고리즘들에의 액세스를 획득할 침입자들 또는 공격자들의 가능성에 대해 우려할 수 있고, 클라이언트가 소유한 부지들 내 컴퓨팅 디바이스들을 사용하여 스트림 프로세싱 작업자 노드들을 구현하기를 바랄 수 있다. SMS 및/또는 SPS 노드들의 세트를 구현하기 위해 사용될 자원들의 유형들은 그것들의 노드들에 대한 "설치 목적지 유형들"로서 본 출원에서 지칭될 수 있다. 도 11은 적어도 몇몇 실시예에 따른, SMS 또는 SPS의 노드들을 위해 선택될 수 있는 복수의 설치 목적지 유형을 예시한다.

설치 목적지들은 도시된 실시예에서 몇몇 유형의 SMS/SPS 기능 카테고리(예를 들어, 수집, 저장, 검색, 제어 또는 프로세싱)에 대해 제공자 네트워크(1102) 내에, 그리고 다른 유형들의 SMS/SPS 기능 카테고리에 대해 외부 제공자 네트워크(1102) 내에서 선택될 수 있다. 제공자 네트워크(1102) 내에, 컴퓨트 인스턴스들, 저장 인스턴스들, 또는 데이터베이스 인스턴스들과 같은 몇몇 자원은 멀티-테넌트 인스턴스 호스트들(1103)을 사용하여 구현될 수 있다. 그러한 멀티-테넌트 인스턴스 호스트들(이들 중 각각에 하나 이상의 클라이언트를 위한 SMS 또는 SPS 노드들이 인스턴스화될 수 있음)은 설치 목적지 유형들 중 제1 카테고리 "A" 를 형성할 수 있다. 다른 클라이언트들과 물리적 자원들을 공유해야 하는 것을 회피하기 위해, 몇몇 클라이언트는 이들의 SMS/SPS 노드들이 단일 클라이언트에 한정되는 인스턴스 호스트들을 사용하여 구현되기를 요청할 수 있다. 그러한 싱글-테넌트 인스턴스 호스트들은 설치 카테고리 유형 "B"을 형성할 수 있다. 싱글-테넌트 인스턴스 호스트들은 몇몇 이유로 인해 몇몇 클라이언트의 관점에서 선호될 수 있다. 멀티-테넌트 인스턴스 호스트들이 다른 클라이언트들에 속하는 컴퓨트 인스턴스들을 포함할 수 있기 때문에, 싱글-테넌트 인스턴스 호스트들에서 보다 멀티-테넌트 인스턴스 호스트들에서 다른 클라이언트의 인스턴스들로부터의 보안 공격들의 보다 높은 확률이 존재할 수 있다. 또한, "노이지-네이버(noisy-neighbor)" 현상(이때 멀티-테넌트 호스트 상에서 실행되는 하나의 클라이언트의 컴퓨트 인스턴스(CI1)가 작업 부하의 급증을 경험하고 대부분의 호스트의 컴퓨트 사이클 또는 다른 자원을 소비하기 시작하며, 그에 따라 상이한 컴퓨트 인스턴스(CI2) 상에서 실행되는 다른 클라이언트의 애플리케이션들의 성능에 가능성 있게 영향을 미침)은, 또한 싱글-테넌트 컴퓨트 인스턴스들이 사용될 때 회피될 수 있다.

IVN(1106A 및 1106B)과 같은, 분리된 가상 네트워크들(IVN들)(1106)은 도시된 실시예에서 설치 목적지 유형들의 다른 카테고리 "C"를 나타낼 수 있다. 제공자 네트워크 자원들을 사용하나 주로 클라이언트에 의해 제어되는 네트워크 구성을 가지고 구축되는, IVN(1106)은 사설 네트워크의 논리적 균등물로서 몇몇 실시예에서 제공자 네트워크의 요청 시 생성될 수 있다. 예를 들어, 클라이언트는 이미 IVN 외부에서 사용 중일 수 있는 IP 어드레스들의 중복 가능성에 대해 우려하지 않고, IVN(1106) 내에서 사용될 IP 어드레스들을 결정할 수 있다. 하나 이상의 IVN에서 다양한 유형의 SMS 및 SPS 노드들을 구현하는 것은 도시된 실시예에서의 클라이언트의 스트림 데이터의 관리 및/또는 프로세싱에 네트워크 보안의 추가 레벨을 추가할 수 있다. 몇몇 경우에서, 소정의 클라이언트는 하나의 IVN(1106)에 SMS/SPS 노드들의 하나의 기능 카테고리를, 그리고 상이한 IVN에 상이한 기능 카테고리를 배치하기를 바랄 수 있다. 소정의 IVN(1106)은 다양한 실시예에서 싱글-테넌트 인스턴스 호스트들, 멀티-테넌트 인스턴스 호스트들, 또는 양 유형의 인스턴스 호스트 중 어느 하나를 포함할 수 있다. 몇몇 실시예에서, 도 11에 도시되지 않은, 제공자 네트워크의 자원들을 사용하여 설치 목적지 유형 선택들(또는 보안 프로파일 선택들)의 다른 세트는, 적어도 몇몇 클라이언트가 이용 가능할 수 있다. 클라이언트들이 스트림-관련 동작들에 대한 제공자 네트워크의 가상화된 컴퓨팅 서비스로부터의 컴퓨트 인스턴스들을 획득하고 사용할 수 있는 실시예들에서, 컴퓨트 인스턴스들은 두 개의 모드 중 하나로 사용될 수 있다. 하나의 모드에서, 클라이언트는 SPS 또는 SMS에, SPS 작업자 노드들로서 구성되는 컴퓨트 인스턴스들에서(또는 수집, 저장, 또는 검색 노드들에서) 실행될 실행 가능한 프로그램 또는 프로그램들을 제공하고, SMS 또는 SPS가 프로그램들을 실행하고 노드들을 관리하게 할 수 있다. 이러한 제1 모드는 스트림 동작들을 위한 컴퓨트 인스턴스들의 "스트림 서비스 관리" 모드로서 지칭될 수 있다. 다른 모드에서, 클라이언트는 SPS 또는 SMS로부터의 보다 적은 지원으로, 실행 가능한 프로그램들을 실행하고 컴퓨트 인스턴스들을 관리하기를 바랄 수 있다. 이러한 제2 모드는 스트림 동작들을 위해 컴퓨트 인스턴스들을 사용하는 "클라이언트-관리" 모드로서 지칭될 수 있다. 따라서 동작의 이들 두 개의 모드는 클라이언트가 선택 가능한 설치 목적지 유형들 또는 보안 프로파일들에 대한 추가적인 선택들을 나타낼 수 있다. 클라이언트는 예를 들어, 실행 가능한 프로그램이 클라이언트의 조직으로부터의 청구-대상 전문가들에 의해 최상으로 수행될 수 있는 디버깅(싱글-스테핑을 포함하는)을 필요로 할 가능성이 있는 경우, 클라이언트-고나리 모드를 선택할 수 있는 한편, 스트림-서비스-고나리 모드는 디버길을 필요로 할 가능성이 없는 보다 완성적인 코드에 대해 적정한 선택일 수 있다. 몇몇 실시예에서, 상이한 가격 결정 정책들이 이들 두 개의 모드에 적용될 수 있다.

다수의 설치 옵션들이 도 11에 도시된 실시예에서의 제공자 네트워크의 외부 설비들에서 지원될 수 있다. 예를 들어, SMS 라이브러리들(1171) 및/또는 SPS 라이브러리들(1172)이 설치되는 호스트들(1160)이 클라이언트 설비들(예를 들어, 클라이언트가 소유한 데이터 센터들 또는 부지들)(1110A 또는 1110B) 내로부터의 스트림 관리 또는 프로세싱을 위해 사용될 수 있으며, 두 개의 유형의 클라이언트 설비는 제공자 네트워크에 대한 이들의 연결 방식에 대해 상이하다. 클라이언트 설비(1110A)는 적어도 몇몇 공유된 인터넷 링크(1151)를 통해 제공자 네트워크(1102)에 링크된다(즉, 다른 엔티티들의 네트워크 트래픽은 클라이언트 설비(1110A) 및 제공자 네트워크(1102) 간 링크들 중 몇몇 링크에 걸쳐 또한 흐를 수 있다). 그에 반해서, 몇몇 클라이언트 설비(1110B와 같은)는 특별한 공유되지 않은 전용 물리적 링크들(1106)(때때로 "직접 연결" 링크들로서 지칭될 수 있음)을 통해 제공자 네트워크에 링크될 수 있다. 이들 두 개의 상이한 유형의 클라이언트 부지들은 도 11에 사용되는 용어로 각각 설치 목적지 옵션들 "D" 및 "E"를 포함한다. 몇몇 실시예에서, SMS 및/또는 SPS의 부분들은 서드 파티 설비들(예를 들어, SMS/SPS의 클라이언트들에 의해 사용되나, 소유되거나 관리되지 않는 데이터 센터들)에서 또한 구현 가능할 수 있고, 그러한 서드 파티 부지들은 설치 목적지 유형 "F"로서 지정될 수 있다. 클라이언트 및/또는 서드 파티 부지들 중 적어도 몇몇 부지에서, SMS 및/또는 SPS 라이브러리들은 제공자 네트워크로부터 획득되고 SMS/SPS 노드들을 위해 사용될 호스트들 상에 설치되어야 할 수 있다. 적어도 일 실시예에서, 모든 상이한 기능 카테고리의 노드들은 적절한 라이브러리들의 도움으로 제공자 네트워크 외부에서 구현될 수 있다.

상이한 설치 목적지 유형들은 상이한 실시예들에서, 구현되는 네트워크 분리 피처들, 기능적으로 지원되는 침입 검출, 구현되는 물리적 보안 정책들, 지원된 암호화 레벨들 등과 같은, 다양한 보안-관련 측면들에 대해 서로 상이할 수 있다. 따라서, 다양한 목적지 유형들의 각각은 각각의 보안 프로파일을 갖는 것으로 간주될 수 있으며, 이는 하나 이상의 방식으로 다른 설치 목적지들의 보안 프로파일과 상이할 수 있다. 몇몇 실시예에서, SMS 및/또는 SPS의 클라이언트들은 도 12a 및 도 12b에 예시된 바와 같이, 예를 들어, SMS 또는 SPS의 하나 이상의 제어 노드에 요청을 송신함으로써, 프로그램에 따라 상이한 서브 시스템들 또는 노드 세트들에 대해 각각의 설치 목적지 유형들을 선택할 수 있다. 몇몇 실시예에서 그리고 스트림 애플리케이션들의 특정한 유형들에 대해, 클라이언트들이 보안 이유로 인해 뿐만 아니라, 성능 및/또는 기능성 이유들로 인해 설치 목적지 유형들을 제어하기를 바랄 수 있다. 예를 들어, 위에서 설명된 노이지-네이버 현상은 전용 클라이언트-부지 자원들 또는 싱글-테넌트 인스턴스 호스트들을 사용함으로써 회피될 수 있다. 몇몇 실시예에서, 클라이언트들은 이들이 SPS 스테이지들 또는 SMS 노드들을 위해 사용하기를 바라는 전용 또는 사유 하드웨어 및/또는 소프트웨어를 가질 수 있으며, 여기서 그러한 구성요소들을 사용하여 달성 가능한 기능적 역량 또는 성능 레벨들은 제공자 네트워크에서 용이하게 복제될 수 없거나, 제공자 네트워크에서 간단히 지원되지 않는다. 클라이언트는 예를 들어, 제공자 네트워크 자원들 단독으로 사용하여 가능할 수 있는 것보다 훨씬 더 높은 비율로 SPS 프로세싱을 수행할 수 있을 수 있는, 수퍼컴퓨터-레벨 프로세싱 역량들을 가지고 컴퓨터 서버 외부의 데이터 센터에 액세스할 수 있을 수 있다. 클라이언트가 다양한 노드들에 대한 설치 목적지들을 선택하게 하는 것은 그러한 전용 디바이스들 또는 소프트웨어가 사용되게 할 수 있다.

도 12a 및 도 12b는 적어도 몇몇 실시예에 따른, 각각, SPS 클라이언트들 및 SMS 클라이언트들에 의해 제출될 수 있는 보안 옵션 요청들의 예들을 예시한다. 도 12a는 클라이언트가 나타내는, 하나 이상의 프로세싱 스테이지에 대해 식별자들(1210), 스테이지의 제어 노드들에 대해 요청되는 설치 목적지 유형들(PDT들)(요소 1212), 및 작업자 노드들에 대해 요청되는 PDT들(요소 1214)을 갖는 SPS 보안 옵션 요청(1200)을 예시한다. 적어도 일 실시예에서, 클라이언트들은 또한 예를 들어, 데이터 레코드들이 다양한 네트워크 링크에 걸친 이들의 전송 이전에 지정된 알고리즘 또는 프로토콜을 사용하여 암호화 되거나, 다양한 제어 또는 관리 상호 작용이 암호화되기를 요청함으로써, 이들의 스트림 데이터 레코드들 또는 스트림 프로세싱 결과들을 위한 암호화 설정들을 구성하기 위한 요청들을 제출할 수 있을 수 있다. 예를 들어, 도 12a에서, 스테이지를 위한 암호화 설정들은 스테이지 프로세싱 동작들의 결과들에 적용될 암호화 기술들, 및/또는 스테이지의 제어 노드들 및 스테이지의 작업자 노드들 간 통신을 위해 사용되는 암호화를 나타낼 수 있다.

유사하게, 도 12b에서, 클라이언트의 SMS 보안 옵션 요청(1250)은 지정된 식별자들(1252)을 갖는 하나 이상의 스트림에 대한 클라이언트의 보안 선호들을 나타내는 다수의 요소를 포함한다. 수집 노드들, 저장 노드들, 및 검색 노드들에 대한 설치 목적지 유형 선호들이 각각 요소들(1254, 1258 및 1262)에 표시될 수 있다. 수집 제어 노드들, 저장 제어 노드들 및 검색 제어 노드들에 대한 PDT 선호들은 각각 요소들(1256, 1260 및 1264)에 의해 표시될 수 있다. 데이터 레코드들에 대한 암호화 선호들, 예를 들어 암호화가 이들이 노드의 하나의 카테고리에서 다른 카테고리로 전송됨에 따라 데이터 레코드들에 대해 구현될지 그리고/또는 이에 대해 어떻게 구현될지는 요소(1266)를 통해 표시될 수 있다. 도 12a 및 도 12b에 도시된 것들과 같은 보안 옵션 요청들을 사용하여, 클라이언트들은 이들의 스트림 관리 및 프로세싱 환경의 상이한 부분들에 대해 위치들(예를 들어, 제공자 네트워크 내 또는 제공자 네트워크의 외부) 및 다양한 다른 보안 프로파일 구성요소를 선택할 수 있을 수 있다.

노드 설치 목적지들의 선택은 적어도 몇몇 실시예에서 보안과 다른 이유들로 인해 제공될 수 있다는 것이 주목된다. 예를 들어, 클라이언트는 주로 보안 이유들로 인해서라기 보다는 (예를 들어, 이전에 표시된 "노이지-네이버" 문제들을 회피하기 위한) 성능 이유들로 인해 싱글-테넌트 호스트들에서 구현되는 몇몇 유형의 SMS 또는 SPS 노드들을 가지기를 바랄 수 있다. 설치 선택들은 스트림의 생애 동안 적어도 몇몇 실시예에서 변경될 수 있다 - 예를 들어, 클라이언트는 초기에 SMS 노드들이 멀티-테넌트 인스턴스 호스트들에서 인스턴스화되게 할 수 있으나, 이후에 노드들의 적어도 어떤 서브세트를 싱글-테넌트 인스턴스 호스트들로 이동시키기를 바랄 수 있다. 상이한 가격 결정 정책들이 적어도 몇몇 실시예에서 상이한 보안-관련 옵션들에 적용될 수 있다 - 예를 들어, IVN들 외부의 멀티-테넌트 인스턴스 호스트들에서 보다 IVN에서 특정한 기능 카테고리의 SMS 노드들을 구현하는 것이 비용이 더 들 수 있다, 또는 멀티-테넌트 인스턴스 호스트들에서 보다 싱글-테넌트 인스턴스 호스트들에서 SMS 노드들을 구현하는 것이 비용이 더 들 수 있다.

스트림 레코드들의 순차적 저장 및 검색

많은 유형의 스트림 애플리케이션들에 대해, 데이터 레코드들은 복수의 데이터 생성자(120)로부터 매우 높은 비율로 SMS에 수신될 수 있고, 데이터 소비자들은 레코드들이 생성된 순서로 저장된 데이터 레코드들에 액세스하기를 통상적으로 바랄 수 있다. 특히 회전 자기 디스크들이 스트림 데이터 레코드들에 대한 저장 디바이스들로서 사용되는 환경들에서, 이전에 언급된 바와 같이, 순차적 I/O 액세스 패턴들(판독들 및 기록들 양자에 대한)은 랜덤 I/O 액세스 패턴들에 비해 상당한 성능 이점들을 가질 수 있다. 몇몇 실시예에서, 스트림-특정 또는 분할-특정 시퀀스 번호들은 이들이 SMS에 의해 수신됨에 따라 데이터 레코드들에 할당될 수 있고, 시퀀스 번호들에 기초한 순차적 검색 동작들이 지원될 수 있다. 도 13a는 적어도 몇몇 실시예에 따른, 스트림 데이터 생성자 및 SMS의 수집 서브 시스템 간 예시적인 상호 작용들을 예시한다. 스트림 데이터 생성자는 수집 서브 시스템에 데이터 레코드(110)를 제출할 수 있고, 도시된 실시예에서, 수집 서브 시스템은 제출된 레코드에 대해 선택되었던 시퀀스 번호(102)로 응답할 수 있다. 적어도 몇몇 실시예에서, 수집 노드는 저장 서브 시스템으로부터 시퀀스 번호의 부분을 획득할 수 있다 - 예를 들어, 시퀀스 번호(102)는 그러한 실시예들에서 적용 가능한 지속 정책에 따라 수신된 데이터 레코드의 저장에 후속하여 결정될 수 있고, 저장 서브 시스템은 데이터 레코드에 대한 그 자체의 숫자 시퀀스 표시자를 생성하고 해당 표시자를 수집 노드에 의해 데이터 레코드에 할당되는 보다 큰 시퀀스 번호에의 포함을 위해 제공할 수 있다.

시퀀스 번호들은 데이터 레코드들의 안정한, 일관된 순서를 제공하도록, 그리고 데이터 소비자들에 의해 레코드들에 걸쳐 반복 가능한 반복자를 가능하게 하도록 다양한 실시예에서 구현될 수 있다. 특정한 분할의 데이터 레코드들에 할당되는 시퀀스 번호들은 이들이 적어도 몇몇 구현예에서 연속적일 필요는 없더라도, 시간 경과에 따라 단조적으로 증가할 수 있다. 다양한 실시예에서, 시퀀스 번호들이 다음 시맨틱스의 적어도 어떤 서브 세트와 할당될 수 있다: (a) 시퀀스 번호들은 스트림 내에서 고유하다, 즉, 소정의 스트림의 어떤 두 개의 데이터 레코드도 동일한 시퀀스 번호가 할당되지 않을 수 있다; (b) 시퀀스 번호들은 스트림의 데이터 레코드들로의 인덱스들로서의 역할을 할 수 있고, 소정의 스트림 분할 내 데이터 레코드들 동안 반복하기 위해 사용될 수 있다; (c) 임의의 소정의 데이터 생성자에 대해, 데이터 생성자가 데이터 레코드들을 성공적으로 제출한 순서는 데이터 레코드들에 할당되는 시퀀스 번호들에 반영된다; 그리고 (d) 소정의 분할 키 값을 갖는 데이터 레코드들에 대한 시퀀스 넘버링은 동적 재분할 동작들에 걸쳐 단조적으로 증가하는 시맨틱스를 보유한다 - 예를 들어, 재분할 후 분할 키 값(K1)을 갖는 데이터 레코드들에 할당되는 시퀀스 번호들은 동적 재분할 이전의 분할 키 값(K1)을 갖는 데이터 레코드들에 할당된 시퀀스 번호들 중 임의의 시퀀스 번호보다 각각 더 클 수 있다. (동적 재분할은 도 16에 대해 이하에서 보다 상세하게 설명된다.)

몇몇 실시예에서, 데이터 생성자는 적어도 몇몇 데이터 레코드에 대해 선택되는 시퀀스 번호(102)의 선택에 영향을 미치기를 바랄 수 있다. 예를 들어, 데이터 생성자(120)는 스트림의 할당된 시퀀스 번호들 내 분리자들 또는 경계들을 정하기를 바랄 수 있고, 따라서 해당 스트림의 데이터 소비자들이 스트림의 특정한 서브 세트들을 타겟으로 하는 판독 요청들을 제출하는 것이 보다 더 용이하게 된다. 몇몇 구현예에서, 데이터 생성자(120)는 레코드와 함께 최소 시퀀스 번호의 표시를 제출할 수 있고, SMS는 위에서 논의된 시퀀스 번호 시맨틱스에 또한 따르는 요청된 최소 시퀀스 번호에 따라 시퀀스 번호를 선택할 수 있다.

도 13b는 적어도 몇몇 실시예에 따른, SMS에서 수집된 데이터 레코드에 대해 생성될 수 있는 시퀀스 번호의 예시적인 요소들을 예시한다. 시퀀스 번호는 도시된 실시예에서 네 개의 요소를 포함할 수 있다: n1-비트 SMS 버전 번호(1302), n2-비트 타임 스탬프 또는 에포크 값(epoch value)(1304), n3-비트 서브 시퀀스 번호(1306), 및 n4-비트 분할 번호(1308). 몇몇 구현예에서, 128 비트 시퀀스 번호들이 사용될 수 있다, 예를 들어, n1, n2, n3 및 n4는 각각 4, 44, 64 및 16 비트일 수 있다. 버전 번호(1302)는 예를 들어, SMS 소프트웨어의 어떤 버전이 시퀀스 번호를 생성하기 위해 사용되었는지 말하는 것이 용이하도록, SMS 소프트웨어 버전의 첫 공개에 걸친 혼동을 회피하기 위해 단순하게 사용될 수 있다. 버전 번호(1302)는 적어도 몇몇 구현예에서 빈번하게 변경되도록 예상되지 않을 수 있다. 타임 스탬프 값(1304)은 예를 들어, 수집 서브 시스템 노드에 의해 지역적 클록 소스 또는 전역적으로 액세스 가능한 클록 소스(예를 들어, getCurrentEpoch 또는 getCurrentTime API를 구현하는 제공자 네트워크의 상태 관리 시스템)로부터 획득될 수 있다. 적어도 몇몇 구현예에서, 널리 공지된 시점으로부터의 오프셋(예를 들어, 1970년 1월 1일 00:00:00 AM UTC 이후 경과된 초들의 수, 이는 Unix™-기반 운영 체제들에서 다양한 시간-관련 시스템 호들을 호출함으로써 획득될 수 있음)은 타임 스탬프 값(1304)을 위해 사용될 수 있다. 몇몇 실시예에서, 서브 시퀀스 번호(1036)는 저장 서브 시스템에 의해 생성될 수 있고 특정한 분할의 데이터 레코드들이 저장 서비스에 기록되는 순서를 나타낼 수 있다. 따라서, 많은 데이터 레코드가 단지 대략 1초 간격들로 변경되는 소정의 초 및 타임 스탬프 값들(1304) 내에 수신되는 구현예에서, 서브 시퀀스 번호(1306)는 동일한 초 내에 도착하고 그에 따라 동일한 타임 스탬프 값이 할당되는 데이터 레코드들에 대한 레코드 도착(또는 저장) 순서의 표시자들로서의 역할을 할 수 있다. 분할 번호(1308)는 몇몇 실시예에서 소정의 스트림 내 분할을 고유하게 식별할 수 있다. 시퀀스 번호 타임 스탬프들이 (적어도 대략) 대응하는 데이터 레코드들이 수집된 클록 시간들을 나타내는 적어도 몇몇 구현예에서, 시퀀스 번호들은 특정한 유형들의 시간-기반 검색 요청들에 대한 인덱싱 메커니즘을 위해 사용될 수 있다. 예를 들어, 클라이언트는 특정한 날에 또는 지정된 시간 범위 동안 생성되거나 수집되는 스트림 레코드들을 검색하기를 바랄 수 있고, 시퀀스 번호들은 데이터 레코드들의 적절한 세트를 검색하기 위한 암시적인 보조 인덱스의 키들로서 사용될 수 있다. 따라서, 적어도 몇몇 실시예에서, 순서화된 저장 및 검색을 위한 타임 스탬프들을 포팜하는 시퀀스 번호들의 사용은 저장된 데이터 레코드들의 세트로의 일시적 인덱스를 제공하는 것에 대한 추가적인 혜택을 가질 수 있다.

소정의 분할의 데이터 레코드들은 보통 대규모 순차적 기록 동작들을 사용하여, 시퀀스 번호 순으로 통상적으로 (예를 들어, 디스크에) 기록될 수 있다. 몇몇 실시예에서, 이전에 표시된 바와 같이, 반복자-기반 프로그램 인터페이스들은 데이터 소비자들이 시퀀스 번호 순으로 데이터 레코드들을 판독하게 하도록 구현될 수 있다. 도 14는 적어도 몇몇 실시예에 따른, SMS에서 스트림 데이터 레코드들의 정리된 저장 및 검색의 예들을 예시한다. 시퀀스 번호 순으로 저장되는 분할(Sj-Pk)(스트림(Sj)의 k번째 분할)의 여섯 개의 데이터 레코드(110A 내지 110F)가 도시된다. 예시된 바와 같이, 시퀀스 번호들은 예를 들어, 값들이 위에서 논의된 타임 스탬프 부분들(1304) 또는 시퀀스 번호들(1306)에 할당되는 방식이 그것들의 요소들에 대한 연속적인 값들을 항상 야기하지는 않을 수 있기 때문에, 적어도 몇몇 실시예에서 연속적이지 않을 수 있다.

도 14에 도시된 예에서, 데이터 소비자는 시작 시퀀스 번호 "865"를 지정하여, 반복자가 생성되기를 요청하였다. 요청에 응답하여, SMS는 요청된 시작 시퀀스 번호 이상인 최근접 시퀀스 번호를 갖는 데이터 레코드에 위치되게, Iterator1을 초기화한다. 이러한 경우, 다음의 보다 낮은 시퀀스(860, 데이터 레코드(110B)에 할당되는)가 소비자의 요청에서의 시작 시퀀스 번호보다 작기 때문에, 시퀀스 번호(870)를 갖는 데이터 레코드(110C)가 반복자의 시작 위치로서 선택되었다. getIterator 인터페이스는 분할 내 요청된 위치에 커서를 설정하기 위한 요청의 논리적 균등물로서 간주될 수 있고, getNextRecords 인터페이스는 그 후 커서 위치에서 시작하는 데이터 레코드들을 판독하기 위해, 예를 들어, 시퀀스 번호 순으로 스트림을 따라 커서를 이동시키기 위해 사용될 수 있다. 예시된 예에서, 데이터 소비자는 Iterator1로 설정된 파라미터 "반복자(iterator)" 및 3으로 설정된 파라미터 "maxNumRecords"(리턴할 데이터 레코드들의 최대 수)를 갖는 getNextRecords 인터페이스를 호출하였다. 따라서, SMS 검색 서브 시스템은 데이터 소비자에 그 다음에 데이터 레코드들(110C, 110D 및 110E)을 차례로 리턴한다. 반복자 Iterator1은 getNextRecords 호가 완료된 후, 새로운 위치로, 예를 들어, 데이터 레코드(110F)로 이동될 수 있고, 동일한 반복자에 대한 후속하는 getNextRecord 호출들이 110F로 시작되는 데이터 레코드들을 리턴할 수 있다. 몇몇 실시예에서 getIterator 호의 시맨틱스가 상이할 수 있다 - 예를 들어, 지정된 시퀀스 번호 이상의 최근접 시퀀스 번호를 갖는 데이터 레코드에 반복자를 위치시키는 대신, 반복자는 몇몇 실시예에서 요청된 시퀀스 번호 이하의 최고 시퀀스 번호를 갖는 데이터 레코드에 위치될 수 있다. 다른 실시예에서, 클라이언트들은 getIterator 호에서 기존 시퀀스 번호를 지정해야 할 수 있다 - 예를 들어, 요청된 시퀀스 번호가 스트림에 존재하지 않는 경우 에러가 리턴될 수 있다.

분할 매핑들

이전에 설명된 바와 같이, 소정의 스트림의 레코드들의 수집, 저장, 검색 및 프로세싱에 관련된 작업 부하는 다양한 분할 및 재분할 정책에 따라 다양한 실시예에서 몇몇 노드 중에 세분되고 분산될 수 있다. 도 15는 적어도 몇몇 실시예에 따른, SMS 및 SPS 노드들에 대해 이루어질 수 있는 스트림 분할 매핑(1501) 및 대응하는 구성 결정들의 예를 예시한다. 특정한 데이터 스트림이 예를 들어, createStream API의 클라이언트의 호출에 응답하여, 생성되거나 초기화될 때, 분할 정책이 스트림에 대해 활성화될 수 있으며, 이는 스트림의 임의의 소정의 데이터 레코드가 멤버로 간주될 분할을 결정하기 위해 사용될 수 있다. 소정의 데이터 레코드에 대한 동작들을 수행할 수집 서브 시스템(204), 저장 서브 시스템(206), 검색 서브 시스템(208) 및 임의의 관련된 SPS 스테이지들(215)의 특정한 노드들이 레코들의 분할을 기초로 선택될 수 있다. 일 실시예에서, 적어도 소정의 데이터 레코드를 위해 사용되는 제어 노드들의 서브 세트도 또한 분할에 기초하여 선택될 수 있다. 적어도 몇몇 실시예에서, 데이터 스트림의 동적 재분할은 예를 들어, 정책에 표시되는 트리거 조건에 응답하여 또는 명백한 요청들에 응답하여, 분할 정책의 부분으로서 지원될 수 있다.

다양한 실시예에서, 소정의 데이터 레코드에 대해 선택되는 분할은 레코드에 대한 분할 키에 의존적일 수 있으며, 이의 값은 직접적으로(예를 들어, 기록 또는 입력 요청의 파라미터로서), 또는 간접적으로(예를 들어, SMS는 분할 키로서 데이터 생성자 클라이언트의 식별자 또는 명칭, 데이터 생성자의 IP 어드레스, 또는 데이터 레코드의 실제 콘텐츠의 부분들과 같은 메타데이터를 사용할 수 있다) 데이터 생성자에 의해 제공될 수 있다. 하나 이상의 매핑 함수(1506)가 도 15에 도시된 실시예에서 데이터 레코드 분할 식별자(1510)를 결정하기 위해 데이터 레코드 분할 키 또는 속성(1502)에 적용될 수 있다. 일 구현예에서, 예를 들어, 소정의 분할 식별자(1510)는 128-비트 정수 값들의 공간에 걸친 연접한 범위를 나타낼 수 있고, 따라서 스트림의 모든 분할에 대한 범위들의 합집합은 128-비트 정수가 상정할 수 있는 모든 가능한 값을 커버할 수 있다. 그러한 예시적인 시나리오에서, 하나의 간단한 매핑 함수(1506)는 데이터 레코드의 분할 키 값(들) 또는 선택된 속성 값(들)로부터 128-비트 해시 값을 생성할 수 있고, 분할 식별자는 해시 값이 있도록 발생하는 특정한 연접한 범위에 기초하여 결정될 수 있다. 몇몇 구현예에서, 연접한 범위들은 적어도 초기에 크기가 동일할 수 있고; 다른 구현예들에서, 상이한 부분들은 서로 크기가 상이할 수 있는 연접한 범위들에 대응할 수 있다. 재분할은 일 구현예에서 범위 경계들의 조절들을 또한 야기할 수 있다. 다른 분할 기능들(106)이 상이한 구현예들에서 사용될 수 있다.

데이터 스트림이 (아래에서 보다 상세하게 논의될 바와 같이) 동적 재분할을 겪는 경우, 특정한 키를 갖는 레코드들이 매핑되는 분할이 변경될 수 있다. 따라서, 적어도 몇몇 실시예에서, SMS 및/또는 SPS 제어 노드들은 스트림의 생애 동안 스트림에 적용되는 몇몇 상이한 매핑을 추적해야 할 수 있다. 몇몇 실시예에서, 타임 스탬프 유효 범위(1511) 또는 시퀀스 번호 유효 범위와 같은 메타데이터가 각 분할 매핑을 위해 제어 노드들에 의해 저장될 수 있다. 타임 스탬프 유효 범위(1511)는 예를 들어, 특정한 매핑(M1)이 스트림의 생성 시간으로부터 시간(T1)까지 적용된다는 것, 상이한 매핑(M2)이 T1에서 T2까지 적용된다는 것 등을 나타낼 수 있다. 스트림에 지시되는 판독 요청들에 응답할 때, 검색 노드들은 먼저 (예를 들어 판독 요청에서 표시된 시퀀스 번호에 의존적인) 매핑이 사용될 지를 결정해야 하고, 그 후 적절한 저장 노드들을 식별하기 위해 해당 매핑을 사용할 수 있다.

SMS 및 SPS 제어 노드들은 적어도 몇몇 실시예에서 몇몇 상이한 단위들로 자원들에 분할들을 매핑하는 것에 대해 책임이 있을 수 있다. 예를 들어, 도 15의 예시적인 구현예들(1599)에 도시된 바와 같이, 일 구현예에서, 각 수집, 저장, 검색 또는 프로세싱 (작업자) 노드는 Java™ 가상 기계(JVM) 또는 컴퓨트 인스턴스와 같은 서버 가상 기계 내에서 각각의 프로세스 또는 실행의 각각의 스레드로서 구현될 수 있고, 각 JVM 또는 컴퓨트 인스턴스는 특정한 물리적 호스트에 인스턴스화될 수 있다. 몇몇 실시예에서, 다수의 JVM은 자원 매핑 결정들의 다른 층에 추가하여, 단일 컴퓨트 인스턴스 내에서 개시될 수 있다. 따라서, 소정의 패턴에 대해, 하나 이상의 제어 노드는 어떤 특정한 자원들이 수집 노드들(1515), 저장 노드들(1520), 검색 노드들(1525), 또는 프로세싱 스테이지 작업자 노드들(1530)(예를 들어, 각각 스테이지들(PS1 또는 PS2)에 대해 노드들(1530A 또는 1530B))로서 사용될지를 선택할 수 있다. 제어 노드들은 그것들의 노드들의 서버들에의 매핑들(수집 서버들(1535), 저장 서버들(1540), 검색 서버들(1545), 또는 프로세싱 서버들(1550)과 같은), 및 서버들 및 호스트들 간 매핑들(수집 호스트들(1555), 저장 호스트들(1560), 검색 호스트들(1565) 또는 SPS 호스트들(1570A/1570B)과 같은)을 또한 결정할 수 있다. 몇몇 구현예에서, 분할 매핑은 예시되는 다양한 자원 단위(예를 들어, 노드, 서버 및 호스트 단위)의 각각에서의 식별 정보(예를 들어, 자원 식별자들), 함수 또는 함수들(1506)에 대한 입력으로서 사용된 데이터 레코드 속성들의 표시, 뿐만 아니라 함수들(1506) 자체를 포함하는 것으로 간주될 수 있다. 제어 서버들은 메타데이터 저장소에 분할 매핑의 표현들을 저장할 수 있고, 몇몇 실시예에서 데이터 생성자들, 데이터 소비자들에 대해, 또는 SMS 서브 시스템들 또는 SPS의 노드들에 대해 매핑 정보를 제공하기 위해 다양한 API(getPartitionInfo API) 또는 다른 프로그램 인터페이스를 노출시킬 수 있다.

분할들에의, 그리고 분할들로부터 자원들에의 데이터 레코드들의 매핑들은 다음과 같은 다양한 팩터에 의해 몇몇 실시예에서 더 복합해질 수 있다: (a) 몇몇 실시예에서 다수의 분할에 대해 책임이 있는 소정의 노드, 서버 또는 호스트가 지정될 수 있다, 또는 (b) 고장들 또는 다른 트리거들이 새로운 노드들, 서버들 또는 호스트들이 소정의 분할 또는 분할들의 세트에 할당되게 야기할 수 있다. 또한, 위에서 표시된 바와 같이 그리고 아래에 설명될 바와 같이, 소정의 스트림에 대한 분할 매핑들은 시간 경과에 따라 동적으로 변형될 수 있는 한편 스트림 레코들을은 SMS 및/또는 SPS 노드들에 의해 계속해서 핸들링된다. 결과적으로 매핑 메타데이터의 몇몇 버전이 상이한 시간의 기간에 각각 대응하여, 몇몇 실시예에서 적어도 일시적으로 소정의 스트림에 대해 유지될 수 있다.

동적 스트림 재분할

도 16은 적어도 몇몇 실시예에 따른, 동적 스트림 재분할의 예를 예시한다. 도 16에서 예시되는 타임 라인의 시간(T1)에서, 스트림(S1)이 생성되거나 초기화된다. 분할 매핑(PM1)이 스트림(S1)에 대해 생성되며, 시간 간격(T1 내지 T2) 동안 유효하게 유지된다. T1 및 T2 사이에 SMS에 의해 수신되는 세 개의 데이터 레코드가 예로서 도시된다. 데이터 레코드(110A)(DR110A)는 클라이언트가 제공한 분할 키 값 "Alice"를 갖고 제출되고, DR110B는 클라이언트가 제공한 분할 키 값 "Bill"을 갖고 제출되며, DR110C 클라이언트가 제공한 분할 키 값 "Charlie"를 갖고 제출된다. 초기 매핑(PM1)에서, 모든 세 개의 데이터 레코드(110A, 110B 및 110C)는 분할 식별자 "P1"를 갖는 동일한 분할에 매핑된다. P1 데이터 레코드들에 대해, 단일 노드(I1)가 수집을 핸들링하도록 구성되고, 단일 노드(S1)가 저장을 핸들링하도록 구성되고, 단일 노드(R1)가 검색을 핸들링하도록 구성되며, 단일 작업자 노드(W1)가 SPS 프로세싱을 핸들링하도록 구성된다. 매핑(PM1)의 유효한 범위에 대한 시작 타임 스탬프는 T1로 설정된다.

시간(T2)에서, 스트림(S1)은 도 16의 예시적인 타임 라인에서 동적으로 재분할된다. 데이터 레코드들은 재분할이 언제 발생하는지에 관계없이, 도시된 실시예에서 SMS 및 SPS에 의해 계속해서 도착하고 핸들링된다; SMS도 SPS도 오프라인 상태로 만들 필요는 없다. 재분할은 다수의 팩터 중 임의의 팩터의 결과로서 개시될 수 있다 - 예를 들어, 수집, 저장, 검색 또는 프로세싱 노드에서의 과부하 상태의 검출에 응답하여, 다양한 서브 시스템의 상이한 호스트들에서의 작업 부하 레벨들 간 스큐(skew) 또는 불균형의 검출에 응답하여, 또는 데이터 소비자 또는 데이터 생성자 클라이언트로부터의 요청에 응답하여. 도시된 실시예에서, 새로운 매핑(PM2)은 PM2에 대해 도시되는 유효한 범위 시작 타임 스탬프 설정에 의해 표시된 바와 같이, 시간(T2)에(또는 T2 직후에) 유효하게 된다. 적어도 몇몇 구현예에서, 재분할 전에 사용된 것과 상이한 데이터 레코드 속성들의 상이한 세트가 분할 데이터 레코드들에 대해 사용될 수 있다. 몇몇 경우에서, 추가적인 분할 속성이 데이터 생성자에 의해(예를 들어, SMS의 요청에) 제출될 수 있는 한편, 다른 경우들에서 추가적인 속성은 SMS 수집 노드에 의해 생성될 수 있다. 그러한 추가적인 속성들은 "솔티드(salted)"로서 지칭될 수 있고, 재분할을 위한 추가적인 속성들을 사용하는 기술은 "솔팅(salting)"으로서 지칭될 수 있다. 하나의 예시적인 구현예에서, 과부하 수집 서버는 데이터 생성자에(예를 들어, 데이터 생성자에 의해 실행된 SMS 클라이언트 라이브러리 코드에) 재분할을 위해, 랜덤으로 선택된 작은 정수 값이 이전에 사용된 분할 키에 추가하여 제공될 것임을 나타낼 수 있다. 원래 분할 키 및 솔티드 추가 정수의 조합은 수집 노드들의 상이한 세트 중에 수집 과부하를 분할하기 위해 이어서 사용될 수 있다. 몇몇 실시예에서, 검색 노드들 및/또는 데이터 소비자들은 재분할을 위해 사용된 추가적인 속성들에 관해 통지되어야 할 수 있다. 그러한 추가적인 속성들은 적어도 몇몇 구현예에서 재분할을 위해 사용되지 않을 수 있다.

도 16에 도시된 실시예에서, 새로운 분할 매핑은 T2 이전 동일한 키에 대해 선택되는 분할에 관해, 상이한 분할들이 T2 이후 수신되는 데이터 레코드들 중 적어도 몇몇에 대해 선택되게 야기한다. DR110P이 T2 이후 분할 키 값 "Alice"를 갖고 제출되고, DR110Q가 T2 이후 분할 키 값 "Bill"을 갖고 제출되며, DR110R은 T2 이후 분할 키 값 "Charlie"을 갖고 제출된다. PM2 매핑을 사용하여, 예시된 예시적인 시나리오에서 DR110P는 분할 "P4"의 멤버로 지정되고, DR110Q는 분할 "P5"의 멤버로 지정되는 한편, DR110R은 분할 "P6"의 멤버로 지정된다. 도시된 실시예에서, T2 이후 수신된 것으로 도시되는 예시적인 데이터 레코드들 중 어떤 것도 이전에 사용된 분할 "P1"의 멤버로서 지정되지 않는다; 대신, 완전히 새로운 분할들이 재분할 이후 사용될 수 있다. 몇몇 실시예에서, 적어도 몇몇 이전에 사용된 분할이 재분할 이후 계속해서 사용될 수 있다. 새로운 분할들(P4, P5 및 P6)의 각각에 대해, 상이한 노드들이 수집, 저장, 검색 및/또는 프로세싱을 위해 지정될 수 있다. 예를 들어, 노드들(I4, S4, R4 및 W4)은 분할(P4)을 위해 구성될 수 있고, 노드들(I5, S5, R5 및 P5)은 분할(P5)을 위해 구성될 수 있으며, 노드들(I6, S6, R6 및 P6)은 분할(P6)을 위해 구성될 수 있다. 몇몇 실시예에서, 동일한 저장 노드가 분할 이전 그러한 레코드들을 위해 사용된 것과 같이 분할 이후 특정한 분할 키 또는 속성을 갖는 레코드를 위해 사용될 수 있으나, 해당 노드 내의 상이한 저장 위치(예를 들어, 상이한 디스크, 상이한 디스크 분할, 또는 상이한 SSD)가 분할 이후 사용될 수 있다.

T2에서 동적 재분할 이후 적어도 일정 시간 기간 동안, 검색 요청들이 재분할 이전 SMS 수집 및/또는 저장 서브 시스템들에 의해 프로세싱된 데이터 레코드들에 대해 계속해서 검색될 수 있다. 적어도 몇몇 경우에서, 요청된 데이터 레코드들은 데이터 레코드들이 수집된 시간에 유효한 PM1 매핑에 기초하여 검색되어야 할 수 있다. 따라서, 도 16에 표시된 바와 같이, 데이터 검색의 목적들을 위해, PM1 및 PM2 양자는 T2 이후 일정 시간 동안 계속해서 사용될 수 있다. 적어도 몇몇 구현예에서, 데이터 레코드들은 그것들이 오래됨에 따라 스트림으로부터 결국 삭제될 수 있고, 보다 오래된 분할 매핑들이 예를 들어, 모든 대응하는 데이터 레코드 자체가 삭제되었을 때, 결국 또한 폐기될 수 있다. 몇몇 실시예에서, 삭제되는 대신(또는 그 이전), 스트림 레코드들은 저장 위치들 또는 디바이스들의 상이한 세트에 아카이브될 수 있고(예를 들어, 클라이언트가 선택한 아카이브 정책들에 기초하여), 따라서 SMS에 의해 사용되는 분할 매핑들은 아카이브 이후 레코드들을 검색하기 위해 여전히 사용 가능할 수 있다. 그러한 실시예들에서, PM1 및 PM2와 같은 분할 매핑들은 그것들이 아카이브 저장장치에 지시되는 검색 요청들을 지원하기 위해 요구되는 한 유지될 수 있다. 몇몇 아카이브 구현예에서, 스트림 분할 매핑들이 유지될 것을 필요로 하지 않는 상이한 검색 접근법들이 사용될 수 있다(예를 들어, 새로운 인덱스들이 아카이브된 데이터 레코드들에 대해 생성될 수 있다). 몇몇 실시예에서 재분할 이전에 사용되었으나, 재분할 이후 기록들이 더 이상 지시되지 않는 P2와 같은 분할은 재분할 이후 어떤 지점에서 판독들에 대해 "폐쇄"될 수 있다 - 예를 들어, "분할의 마지막에 이름" 에러 메시지의 균등물이 검색 요청들에 응답하여 제공될 수 있다.

몇몇 구현예에서, 소정의 데이터 스트림이 많은(예를 들어, 수백 또는 수천) 분할로 분할될 수 있다. 스트림(S1)이 1000개의 분할, P1, P2, ..., P1000로 초기에 분할되는 예시적인 경우를 고려하자. 하나의 분할, 즉 P7에 대응하는 과부하 상태가 검출되는 경우, P7에의 데이터 레코드들의 초기 매핑을 변경하는 것은 가치가 있을 수 있으나, 다른 분할들의 매핑이 변경되어야 할 필요는 없다. 하나의 접근법에서, 두 개의 새로운 분할(P1001 및 P1002)이 재분할 동작 동안 생성될 수 있다. 재분할 이후 수신되는 레코드들(이들의 속성들은 원래(즉, 원래 매핑을 기초로) 이들의 멤버십을 P7에 야기했을 것이다)은, 재분할 이후 P1001 또는 P1002 중 어느 하나에 매핑되고, 그에 따라 두 개의 분할 중에 P7의 작업 부하를 분산시킬 수 있다. 나머지 분할들, 예를 들어, P1 - P6 및 P8 - P1000은 변형될 필요가 없을 수 있다. 단지 분할들의 작은 서브 세트가 그러한 재분할에 의해 영향을 받음에 따라, 적어도 몇몇 실시예에서 분할 엔트리들(또는 분할 엔트리들의 트리)의 방향성 비주기적 그래프와 같은 조합된 데이터 구조가 생성되고 저장될 수 있다. 각 엔트리는 분할 함수 출력 범위, 및 유효 시간 범위(엔트리의 분할 정보가 유효한 것으로 간주되어야 하는 시간 기간)를 나타낼 수 있다. 상기한 예에서, 스트림(S1)(및 이의 초기 매핑)이 시간(T1)에서 생성되었지만, P7을 수반하는 재분할이 시간(T2)에서 수행되었다고 가정하자. 그러한 시나리오에서, P7에 관한 엔트리에 대한 유효 시간 기간은 "T1 내지 T2"일 수 있고, P1001 및 P1002에 대한 유효 시간 기간은 "T2 앞으로"일 수 있으며, 나머지 분할들에 대한 유효 시간 기간은 "T1 앞으로"일 수 있다. 그러한 조합된 데이터 구조를 사용하는 것은 적어도 몇몇 구현예에서 분할 매핑 메타데이터를 위해 사용되는 메모리 또는 저장장치의 양의 상당한 감소를 초래할 수 있다. 상기한 예에서, 분할(P7)의 두 개의 새로운 분할로의 분할이 논의되었다. 적어도 몇몇 구현예에서, 분할들은 재분할동안 또한 병합될 수 있다 - 예를 들어, 상대적으로 적은 검색 요청이 수신되거나, 또는 상대적으로 적은 레코드가 제출된 두 개의 인접한 분할이 단일 분할로 병합될 수 있다. 임의의 소정의 시점에 대해, 데이터 레코드가 속하는 분할이 분할 함수 및 유효 시간 범위 정보를 사용하여 분명하게 결정될 수 있다. 시간 경과에 따라, 조합된 데이터 구조가 보다 많은 분할 및/또는 병합이 수행됨에 따라 발달할 수 있으나 분할 메타데이터를 위해 요구되는 총 공간은 극적으로 증가하지 않을 수 있다(물론 분할들이 몇 번 발생하는지, 그리고 얼마나 많은 분할이 평균적으로 분할들에 의해 영향을 받는지에 의존적임). 그에 반해서, 상이한 구현예에서, 분할이 발생할 때마다, 스트림에 대한 변경되지 않은 메타데이터의 전체 세트가 복제되고 재분할에 의해 영향을 받은 분할들에 대한 엔트리들과 조합될 수 있다. 분할 매핑 메타데이터에 대한 저장장치 및 메모리 요건은 후자 구현예에서 특히 보다 오래된 매핑들이 위에서 설명된 바와 같이 재분할 이후 적어도 일정 시간 동안 유지되어야 할 수 있는 경우, 훨씬 더 빠른 비율로 증가할 수 있다.

타임 스탬프 값들(도 13b에 도시된 타임 스탬프 값(1304)과 같은)을 포함하는 시퀀스 번호들이 사용되는 적어도 몇몇 실시예에서, 특별한 유형의 시퀀스 번호 전환이 동적 재분할을 위해 구현될 수 있다. 예로서, 도 13b에 도시되는 것과 유사한, 타임 스탬프-기반 시퀀스 번호 기법이 스트림(S1)에 대해 사용되고 있으며, 여기서 새로운 타임 스탬프 값들이 시퀀스 번호들에의 포함을 위해 매 초마다 생성된다고 가정하자. 동적 재분할이 지원되는 적어도 몇몇 구현예에서, 동적 재분할 이후 할당되는 시퀀스 번호들은 동적 재분할 이전에 사용된 것과 상이한 타임 스탬프 값들의 세트(재분할 이벤트에 대응하는 선택된 초기 타임 스탬프 값으로 시작되는)를 모두 사용할 수 있다. 예를 들어, 동적 재분할이 커밋될 때(즉, 실행될 때) 사용 중인 타임 스탬프 값이 Tk였던 경우, 커밋 이후 발행되는 임의의 새로운 시퀀스 번호들은 타임 스탬프 값들(Tk+1 앞으로)을 사용하도록 요구될 수 있다. 시퀀스 번호 값들이 도 13b에서 사용되는 기법에서 이들의 보다 높은 차수의 비트들 중 적어도 몇몇으로 타임 스탬프 값을 인코딩하기 때문에, 재분할 이벤트들이 설명되는 바와 같이 타임 스탬프 경계들에 대응한다는 것을 보장하는 것은 검색 요청에 응답하여 사용될 매핑들을 식별하는 것에 수반되는 부기(bookkeeping)를 결과적으로 간략화할 수 있다. 따라서, 그러한 구현예들에서, 특정한 시퀀스 번호를 지정하는 검색 요청이 수신될 때, 타임 스탬프 값은 시퀀스 번호로부터 추출될 수 있고, 재분할-후 매핑이 사용되어야 할지, 또는 재분할-전 매핑이 사용되어야 할지가 용이하게 결정될 수 있다. 추출된 타임 스탬프 값이 재분할을 위해 선택되는 초기 타임 스탬프 값보다 낮은 경우, 재분할-전 매핑이 사용될 수 있고, 추출된 타임 스탬프 값이 재분할을 위해 선택되는 초기 타임 스탬프 값보다 높은 경우, 재분할-후 매핑이 사용될 수 있다.

스트림 관리 및 프로세싱을 위한 방법들

도 17은 적어도 몇몇 실시예에 따른, 스트림 레코드 수집 및 스트림 레코드 검색을 위한 프로그램 인터페이스들의 각각의 세트들을 지원하기 위해 수행될 수 있는 동작들의 측면들을 예시하는 흐름도이다. 요소(1701)에 도시된 바와 같이, 데이터 스트림을 생성하거나 초기화하기 위한 요청이 예를 들어, SMS 클라이언트 또는 데이터 생성자 클라이언트로부터 수신될 수 있다. 스트림을 위해 사용될 초기 분할 매핑이 결정될 수 있다(요소(1704)), 예를 들어, 특정한 데이터 레코드가 속하는 분할을 식별하기 위해 사용될 함수(들), 및 함수(들)에 대해 사용될 입력 파라미터는 분할 정책에 기초하여 식별될 수 있다. 이전에 언급된 바와 같이, SMS의 제어 구성요소들은 다양한 실시예에서 스트림 생성 요청들을 수신하고 이들에 응답하는 것에 대해 책임이 있을 수 있다. 스트림 생성 및 초기화(뿐만 아니라 다른 제어-영역 동작들)가 구현되는 방식은 실시예마다 상이할 수 있다. 일 실시예에서, 예를 들어, 제어 서버들의 리던던시 그룹이 설정될 수 있고, 해당 리던던시 그룹의 주요 제어 서버가 지속적 저장 장소에 새로운 스트림을 위한 적절한 메타데이터(예를 들어, 초기 분할 매핑, 수집, 저장 및 검색 노드들의 초기 세트들 등)를 생성하고 저장함으로써 스트림 생성 요청에 응답할 수 있다. 스트림에 관한 후속 질의들(예를 들어, 소정의 분할에 대해 책임이 있는 백-엔드 노드에 관한 프론트-엔드 수집 노드로부터의 요청)에 대한 응답들은 저장된 메타데이터를 사용하여 주요 제어 서버에 의해 생성될 수 있다. SMS 제어-영역 기능의 다른 구현예에서, 스트림 구성 메타데이터는 수집, 저장, 또는 검색 서브 시스템들의 적어도 몇몇 노드에 의해 직접 액세스 가능한 데이터베이스에 저장될 수 있다. 스트림이 생성되고 초기화된 후, 레코드 제출, 저장 및 검색과 같은 데이터-영역 동작들이 시작될 수 있고, 통상적으로 제어 구성요소들과의 추가적인 상호 작용들 없이, 대응하는 서브 시스템들의 각각의 구성요소들에 의해 핸들링될 수 있다.

몇몇 실시예에서, 데이터 생성자들은 기록 요청들과 함께 명백한 분할 키들을 제출하도록 요구될 수 있는 한편, 다른 실시예들에서, 분할 함수들을 위해 사용될 입력들이 데이터 생성자들의 아이디, 데이터 레코드들이 수신되거나, 데이터 레코드들의 콘텐츠 그 자체로부터의 IP 어드레스들과 같은, 기록 요청들과 연관된 메타데이터에 기초하여 결정될 수 있다. 적어도 하나의 구현예에서, 클라이언트들은 데이터 레코드 제출들에 분할 식별자들을 선택적으로 제공할 수 있고, 그러한 구현예에서 추가적인 분할 함수들은 요구되지 않을 수 있다.

스트림에 대한 수집, 저장 및 검색 기능들을 위한 노드들의 초기 세트를 결정하거나 구성할 때 다수의 상이한 팩터가 고려될 수 있다(요소(1707)). 예를 들어, 분할 매핑 그 자체(얼마나 많은 스트림이 분할되고, 분할들의 상대적 예상 크기들을 결정할 수 있는), 그러한 정보가 이용 가능한 경우 예상되는 수집 비율들 및/또는 검색 비율들에 대한 정보, 스트림 데이터 레코드들에 대한 내구성/지속성 요건, 및/또는 다양한 서브 시스템에 대한 높은 이용 가능성 요건(도 9 및 도 10에서 예시된 것들과 유사한 리던던시 그룹들의 셋 업을 야기할 수 있는)은 상이한 서브 시스템들의 노드들의 수 및 배치에 영향을 미칠 수 있다. 또한, 클라이언트들이 노드들의 다양한 카테고리에 대한 설치 목적지 유형 선호들을 나타낼 수 있는 실시예들에서(도 11, 도 12a 및 도 12b에 예시된 바와 같은), 그러한 선호들은 SMS 및/또는 SPS 노드들에 대해 사용될 자원들을 결정하는 것에서 또한 역할을 할 수 있다. 적어도 몇몇 실시예에서, 수집, 저장 및/또는 검색 기능들이 가능한 노드들의 각각의 풀들은 미리 셋 업될 수 있고, 제어 구성요소들은 생성되는 각 새로운 스트림에 그러한 풀들의 선택된 멤버들을 할당할 수 있다. 다른 실시예들에서, 적어도 몇몇 경우에서 수집, 저장 또는 검색 노드들은 스트림이 생성되거나 초기화될 때 인스턴스화되어야 할 수 있다.

도시된 실시예에서 수집 노드들에서, 레코드들은 예를 들어 인-라인 제출 인터페이스들(데이터가 제출 요청들에 포함됨) 및 참조에 의한 제출 인터페이스(데이터가 예를 들어, 웹 서비스 요청들 또는 다른 인터페이스들을 사용하여 SMS 수집 노드들 또는 SMS 저장 노드들에 의해 검색될 수 있는, 어드레스가 제출 요청들에 제공됨)를 포함하여, 데이터 레코드 제출을 위해 구현되는 프로그램 인터페이스의 세트 중 임의의 인터페이스를 통해 수신될 수 있다(요소(1710)). 다수의 상이한 유형의 프로그램 인터페이스들 중 임의의 인터페이스가 레코드들을 제출하는 방식들의 각각에 대해 상이한 실시예들에서 제공될 수 있다, 예를 들어, 각각의 애플리케이션 프로그래밍 인터페이스들(API들)이 인-라인 대 참조에 의한 제출에 대해 지원될 수 있거나, 웹 페이지들 또는 웹 사이트들이 설정될 수 있거나, 그래픽 유저 인터페이스들이 구현될 수 있거나, 명령어-라인 도구들이 발전될 수 있다. 적어도 몇몇 실시예에서, SMS는 예를 들어, 레코드들이 수집되거나 저장되는 순서를 나타내어, 각 수집된 레코드에 시퀀스 번호를 할당할 수 있고, 시퀀스 번호들은 데이터 소비자들에 의한 검색 요청들에 대해 사용 가능할 수 있다. 검색 서브 시스템 노드들에서, 레코드 검색 요청들이 구현된 프로그램 검색 인터페이스들의 세트 중 임의의 인터페이스를 통해 수신될 수 있고, 요청된 데이터 레코드들의 콘텐츠가 응답 시 제공될 수 있다(요소(1713)). 비-순차적 액세스에 대해, 인터페이스들은 예를 들어, getIterator(getIterator 호출에 표시되는 시퀀스 번호에 기초하여 분할 내에서 선택되는 위치에서 인스턴스화될 반복자를 요청하는) 또는 getRecordWithSequenceNumber(지정된 시퀀스 번호를 갖는 데이터 레코드를 획득하기 위한)를 포함할 수 있다. 순차적 액세스에 대해, getNextRecords(반복자의 현재 위치에서 또는 지정된 시퀀스 번호에서 시작하여, 유효한 다수의 레코드를 요청하는)와 같은 인터페이스들이 구현될 수 있다. 적어도 몇몇 실시예에서, 상이한 검색 인터페이스들은 그것들과 연관된 상이한 과금 비율들을 가질 수 있다 - 예를 들어, 순차적 검색에 대한 레코드-당 과금 비율들이 비-순차적 검색에 대한 레코드-당 과금 비율들보다 낮게 설정될 수 있다. 상이한 제출 인터페이스들이 몇몇 실시예에서 상이한 과금 비율들을 또한 가질 수 있다 - 예를 들어, 참조에 의한 제출들은 인라인 제출들보다 레코드당 더 많은 비용이 들 수 있다.

시간 경과에 따라, 제어 노드들 또는 특화된 과금 서버들은 스트림 관리 서비스의 다양한 서브 시스템에서 구현되는 상이한 프로그램 인터페이스들에 대한 사용량 메트릭스를 수집할 수 있다(요소(1716)). 메트릭스는 예를 들어, 상이한 프로그램 인터페이스들의 호출 카운트들, 수집되거나 검색되는 레코드들의 총 수(단일 호출로 다수의 레코드를 검색하기 위해 사용될 수 있는 getNextRecords와 같은 적어도 몇몇 인터페이스에 대한 호출 카운트들과 상이할 수 있음), 수집되거나 검색되는 데이터의 총 양 등을 포함할 수 있다. 스트림을 소유하는 클라이언트들, 또는 스트림으로부터의 데이터를 생성하고/하거나 소비하는 클라이언트들에 청구될 과금액은 프로그램 인터페이스들과 연관된 각각의 과금 비율들 및 사용량 메트릭스에 적어도 부분적으로 기초하여 선택적으로 생성될 수 있다(요소(1719)). 적어도 몇몇 실시예에서, 과금 활동들은 스트림 수집/검색 동작들에 대하여 동시에 발생하지 않을 수 있다 - 예를 들어, 청구서는 월 동안 수집되는 메트릭스에 기초하여 매월 과금 기간의 종료 시 생성될 수 있다.

도 18a는 적어도 몇몇 실시예에 따른, 스트림 프로세싱(SPS) 스테이지들을 구성하기 위해 수행될 수 있는 동작들의 측면들을 예시하는 흐름도이다. 요소(1801)에 도시된 바와 같이, 프로그램 인터페이스들은 클라이언트들이 스트림 데이터 레코드들을 위한 다수의 프로세싱 스테이지를 구성하게 하여 구현될 수 있다. 특정한 스테이지를 구성하기 위해, 예를 들어, 클라이언트는 스테이지에서 분할된 스트림 데이터 레코드들에 대해 수행될 프로세싱 동작(들), 프로세싱 동작들의 출력에 대한 분산 정책, 뿐만 아니라 프로세싱될 데이터가 획득될 입력 스트림들의 아이디와 같은 다른 파라미터들을 나타낼 수 있다. 몇몇 실시예에서, SPS 스테이지들에서의 프로세싱 동작들은 멱등성일 것이 요구될 수 있다. 다른 실시예들에서, 비-멱등성 동작들이 적어도 몇몇 스테이지에 대해 또한 지원될 수 있다. 소정의 스테이지에서 수행될 프로세싱이 비-멱등성인 경우, 클라이언트는 어떤 지속적 외부 장소에 동작들의 출력을 주기적으로 플러싱하도록 작업자 노드들을 구성하고, 플러시 동작들이 레코드 검색 시퀀스에 대하여 수행되었을 때를 레코딩하며, 이후에 복구 동안 플러시 동작들을 재연하도록 대체 작업자 노드들을 구성함으로써 몇몇 실시예에서 멱등성의 복구-관련 혜택들을 여전히 획득할 수 있을 수 있다. 적어도 몇몇 실시예에서, 클라이언트들은 몇몇 상이한 상태들이 병렬로 스트림 데이터에 대해 작동하고, 몇몇 스테이지의 결과들이 다른 스테이지들에 대한 입력 스트림들로서 사용되는, 프로세싱 스테이지들의 방향성 비주기적 그래프들(DAG들) 또는 다른 그래프들을 구성할 수 있을 수 있다. 몇몇 실시예에서, 지속적 스트림들보다는 하나 이상의 단기 스트림들이 상이한 스테이지들 간에서 생성될 수 있다, 예를 들어, 하나의 스테이지로부터 출력되는 데이터 레코드가 상이한 스테이지로의 입력으로서 공급되기 전에 반드시 지속적 저장 디바이스들 상에 저장될 필요는 없다.

예를 들어 체크포인트-기반 복구 정책 또는 최선-노력 복구 정책을 포함하는, 다수의 상이한 복구 정책 중 임의의 정책이 몇몇 실시예에서 SPS 스테이지들을 위해 구현될 수 있다. 일 실시예에서, 클라이언트는 상이한 SPS 스테이지들을 위한 복구 정책들을 선택하기 위해 프로그램 인터페이스를 사용할 수 있다. 체크포인트-기반 복구가 사용되는 스테이지들에서, 작업자 노드들은 간격을 두고, 스트림 분할에서 그것들이 얼만큼 도달했는지를 나타내는, 경과 레코드들 또는 체크포인트들을 저장하도록 구성될 수 있다(예를 들어, 가장 최근에 프로세싱된 레코드들의 시퀀스 번호들이 진행의 표시자들로서 저장될 수 있다). 경과 레코드들은 도 19에 대하여 아래에서 설명될 바와 같이, 고장들 이후 복구 동작들 동안 이후에 사용될 수 있다. 최선-노력 복구 정책에서, 경과 레코드들은 저장될 필요가 없고, 고장에 응답하여 구성되는 대체 작업자 노드들이 새로운 데이터 레코드들이 수신됨에 따라 그것들을 단순하게 프로세싱할 수 있다. 소정의 SPS 스테이지 또는 작업 흐름 내, 몇몇 실시예에서 상이한 복구 정책들이 상이한 스테이지들에 적용될 수 있다.

SPS 제어 서버는 예를 들어, 요소(1801)에 표시되는 프로그램 인터페이스들 중 하나를 통해, 출력 분산 기술자(DDesc1)에 따라 분산될 프로세싱의 결과들을 갖는, 분할 정책(PPol1)에 따라 스트림(S1)의 특정한 스테이지(PS1)에서 수행될 멱등성 동작(Op1)의 표시를 수신할 수 있다(요소(1804)). 상태(PS1)를 위해 구성될 작업자 노드들의 수, 및 노드들을 위해 요구되는 가상 또는 물리적 자원들이 예를 들어, Ppol1, 멱등성 동작들(Op1)의 복작도, 및 작업자 노드들을 위해 사용될 자원들의 수행 역량들과 같은 다양한 팩터에 기초하여 결정될 수 있다(요소(1807)).

그 후 작업자 노드들은 예를 들어, 선택된 가상 또는 물리적 기계 자원들에서 프로세스들 또는 스레드들로서, 인스턴스화되고 구성될 수 있다(요소(1810)). 하나의 간단한 구현예에서, 예를 들어, 하나의 작업자 노드가 S1의 각 분할에 대해 할당될 수 있다. 소정의 작업자 노드는 (a) S1의 검색 노드들의 적절한 서브 세트로부터 데이터 레코드들을 수신하고, (b) 수신된 데이터 레코드들에 대해 Op1을 수행하고, (c) 선택적으로, 예를 들어, PS1을 위한 복구 정책에 기초하여, 어떤 분할 레코드들의 세트가 프로세싱되었는지를 나타내는 경과 레코드들/체크포인트들을 저장하며, (d) (예를 들어, 지속적 또는 단기 스트림들 중간에, 또는 다른 프로세싱 스테이지들 또는 저장 시스템들로의 직접 입력들로서) DDesc1에 의해 표시되는 목적지들에 출력을 전송하도록 구성될 수 있다. 적어도 몇몇 실시예에서, SPS 프로세싱은 반드시 지속적으로 다른 곳으로 전송되어야 할 임의의 출력을 생성할 필요는 없을 수 있다. 예를 들어, 몇몇 SPS 애플리케이션은 데이터 레코드들의 일시적 저장소들로서의 역할을 단순히 할 수 있고/있거나 사용자들이 데이터 레코드들을 보게 하는 질의 인터페이스들을 구현할 수 있다. 그러한 애플리케이션은 그 자체의 출력을 관리할 수 있다, 예를 들어, 출력은 분산 기술자에 따르지 않고 수신된 질의들에 응답하여 생성될 수 있다. 로깅-관련 SPS 애플리케이션은 대규모 분산 시스템으로부터 수집되는 지난 로그 레코드들을 보유하여, 예를 들어, 클라이언트들이 디버깅 또는 분석 목적들을 위해 로깅 데이터를 보게 할 수 있다. 따라서, 몇몇 실시예에서, 출력 분산 기술자들은 SPS의 적어도 몇몇 스테이지에 대해, 적어도 몇몇 스트림에 대해, 또는 적어도 몇몇 분할에 대해 지정될 필요가 없다. 그 후 작업자 노드들은 이들의 각각의 구성 설정들에 따라 데이터 레코드들을 검색하고 프로세싱하는 것을 초기화할 수 있다(요소(1813)). SPS 제어 노드들은 적어도 몇몇 실시예에서 작업자 노드들의 동작 상태(예를 들어, 하트비트 프로토콜과 같은 반응성 체크들을 사용하여), 뿐만 아니라 작업자 노드들을 위해 사용된 자원들에서의 자원 이용 레벨들과 같은 다양한 다른 메트릭스를 모니터링할 수 있다(요소(1816)). 작업자 노드들로부터 수집되는 정보는 시스템 대체 작동이 요구되는지 예를 들어, 작업자 노드가 대체되어야 할지 및 이하에서 설명될 바와 같이 구현되는 복구 정책을 결정하기 위해 사용될 수 있다.

몇몇 실시예에서, 설치 가능한 SPS 클라이언트 라이브러리는 제공자 네트워크의 클라이언트가 선택한 자원들, 및/또는 클라이언트가 소유한 부지들에 SPS 작업자 노드들을 구현하기를 바라는 그것들의 클라이언트들에 대해 제공될 수 있다. 클라이언트 라이브러리는 또한 SPS 클라이언트들이 그들이 상태 모니터링 기능들, 자동화된 작업 부하 모니터링 및 균형, 보안 고나리, 동적 재분할 등과 같은, SPS 관리 서비스의 다양한 제어-영역 피처를 사용하기를 바라는 정도를 선택하게 할 수 있다. 도 18b는 적어도 몇몇 실시예에 따른, 스트림 프로세싱 작업자 노드들의 구성을 위한 클라이언트 라이브러리의 구성요소들의 호출들에 응답하여 수행될 수 있는 동작들의 측면들을 예시하는 흐름도이다. 요소(1851)에 도시된 바와 같이, SPS 클라이언트 라이브러리가 제공될 수 있다(예를 들어, 도 18a에 예시되는 것 같은 동작들을 수행하도록 구성 가능한 멀티-테넌트 SPS 관리 서비스의 웹 사이트로부터의 다운로드를 통해). 라이브러리는 다수의 실행 가능한 구성요소, 및/또는 클라이언트 애플리케이션들에 링크될 수 있는 구성요소들을 포함할 수 있다. 몇몇 라이브러리 구성요소는 클라이언트들이 하나 이상의 SPS 스테이지가 수행될 다양한 작업자 노드를 선택하거나, SPS 관리 서비스를 이용해서 그러한 작업자 노드를 등록하거나, 또는 그러한 작업자 노드의 원하는 속성들을 지정하게 할 수 있다. 예를 들어, 하나의 클라이언트는 작업자 노드들을 위한 제공자 네트워크의 가상 컴퓨팅 서비스에서 구현되는 컴퓨트 인스턴스들의 이들 자체의 세트를 사용하기를 바랄 수 있는 한편, 다른 클라이언트는 프로세싱 스트림 레코드들을 위한 클라이언트 그 자체의 데이터 센터(제공자 네트워크에 의해 지원되지 않는 전용 디바이스들과 같은)에 위치되는 컴퓨팅 서비스들을 사용하기를 바랄 수 있다. 클라이언트들은 원할 때, 가상 컴퓨팅 서비스의 컴퓨트 인스턴스들을 사용하여, 또는 이들 자체의 부지들에 필요 시를 기초로 온라인으로 작업자 노드들을 가져올 수 있다. 작업자 노드들의 요구형 인스턴스화에 추가하여 또는 그 대신, 몇몇 실시예에서 클라이언트들을 필요할 때 배치될 수 있는 잠재적으로 재-사용 가능한 작업자 노드의 풀들을 미리 구성할 수 있다. 몇몇 구현예에서, 라이브러리 구성요소는 클라이언트가 SPS 관리 서비스를 이용해서, 후속 제어-영역 동작들이 SPS 관리 서비스에 의해 핸들링될 수 있는, 지정된 스테이지의 작업자 노드로서 클라이언트에 의해 인스턴스화되는 특정한 프로세스 또는 스레드를 등록하게 하기 위해 실행되거나 호출될 수 있다. 일 실시예에서, 클라이언트는 작업자 노드들을 위해 SPS 관리 서비스에 의해 핸들링되는 것에 대한 상이한 레벨들의 제어-영역 책임들 중으로부터 또한 선택할 수 있을 수 있다 - 예를 들어, 하나의 클라이언트는 작업자 노드 상태를 모니터링하기 위해 이들 자체의 주문형 모듈들을 사용하기를 바랄 수 있는 한편, 다른 클라이언트는 작업자 노드 상태를 모니터링하고 고장이 검출되는 경우 적절한 액션을 취하기 위해 SPS 관리 서비스를 이용하기를 바랄 수 있다.

SPS 관리 서비스는 특정한 클라이언트가 특정한 SPS 스테이지(PS1)의 제어 영역 동작들 및/또는 작업자 노드들을 구성하기 위한 클라이언트 라이브러리를 사용하기를 바란다는 표시를 수신할 수 있다(요소(1854)). (PS1 그 자체는 라이브러리에 포함되는 프로그램 인터페이스를 사용하여, 또는 도 4에 예시된 웹-기반 인터페이스와 유사한 SPS 관리 서비스에 의해 노출되는 프로그램 인터페이스들을 사용하여 설계될 수 있다). 클라이언트는 데이터가 PS1에 의한 입력으로서 사용하기 위해 검색되어야 하는 스트림들을 또한 표시할 수 있다. 선택적으로, 적어도 몇몇 실시예에서, 클라이언트는 PS1을 위한 제어-영역 설정들, 예를 들어, 클라이언트가 노드들에 대해 서비스의 상태 모니터링 역량들을 사용하기를 원하는지, 또는 기꺼이 주문형 상태 모니터링 도구들을 사용할지를 표시할 수 있다(요소(1857)). 클라이언트에 의해 표시되는 선호들에 따라, 클라이언트의 사용을 위해 구성될 SMS 및/또는 SPS의 하나 이상의 노드가 결정될 수 있다(요소(1860)). 네트워크 연결이 SMS/SPS 노드들로 클라이언트의 작업자 노드들 사이에 설정될 수 있고/있거나, 다른 구성 동작들은 원할 때 데이터 레코드들의 흐름 및 프로세싱 결과들을 가능하게 하도록 수행될 수 있다. 데이터 레코드들은 검색 요청들 수신 시 SP1 작업자 노드들에 제공될 수 있고, 원하는 제어-영역 동작들이 (임의의 동작이 클라이언트에 의해 요청된 경우) 필요 시 수행될 수 있다. 적어도 몇몇 실시예에서, 클라이언트들이 그들이 SMS 관리 서비스의 다양한 서브 시스템의 제어-영역 기능을 사용하기를 바라는 정도를 제어하게 하는 유사한 접근법이 또한 또는 대신 구현될 수 있다는 것이 주목된다.

도 19는 적어도 몇몇 실시예에 따른, 스트리밍 프로세싱을 위한 하나 이상의 복구 정책을 구현하기 위해 수행될 수 있는 동작들의 측면들을 예시하는 흐름도이다. 요소(1901)에 도시된 바와 같이, SPS 제어 노드는 특정한 작업자 노드를 대체하기 위한 기준들을 트리거하는 것이 충족되었는지 - 예를 들어, 작업자 노드가 무응답이거나 이상이 있는 상태가 되었을 수 있거나, 현재 노드의 작업 부하 레벨들이 시스템 대체 작동에 대한 임계 값에 도달했을 수 있거나, 작업자 노드에서 검출되는 에러들의 수가 임계를 초과했을 수 있거나, 또는 작업자 노드의 몇몇 다른 예기치 않은 상태가 식별될 수 있는지 - 를 결정할 수 있다. 대체 작업자 노드가 식별되거나 인스턴스화될 수 있다(요소(1904)). 몇몇 실시예에서, 이용 가능한 작업자 스레드들의 풀이 셋 업될 수 있으며, 이로부터 하나가 예를 들어, 대체로서 선택될 수 있거나 새로운 스레드 또는 프로세스가 개시될 수 있다.

최선-노력 복구 정책이 특정한 작업자 노드가 활동 중이었을 SPS 스테이지에서 사용될 경우(요소(1907)에서 결정되는 바와 같이), 대체 작업자 노드는 그것들이 이용 가능하게 될 때, 추가적인 데이터 레코드들을 프로세싱하는 것을 간단하게 시작할 수 있다(요소(1916)), 예를 들어, 대체된 작업자 노드들의 경과의 어떤 레코드도 검토될 필요가 없을 수 있다. 체크포인트-기반 복구 정책이 사용될 경우, 대체 작업자 노드가 대체된 작업자 노드에 의해 저장되는 경과 레코드들에 액세스 할 수 있는 장소의 표시(예를 들어, 저장 디바이스 어드레스 또는 URL)가 제공될 수 있다(요소(1910)). 대체 작업자 노드는 대체된 노드에 의해 저장된 가장 최근 경과 레코드를 검색하고, 대체 작업자 노드가 스테이지의 멱등성 동작들을 수행해야 할 데이터 레코드들의 세트를 결정하기 위해 경과 레코드을 사용할 수 있다(요소(1913)). 그러한 체크포인트-기반 복구 정책에서, 최후 경과 레코드 및 대체 작업자 노드가 인스턴스화되는 시간 사이 지속기간에, 뿐만 아니라 대체된 작업자 노드가 저장된 경과 레코드에 후속하는 추가적인 레코들을 프로세싱하였던 비율에 따라, 몇몇 수의 데이터 레코드가 한 번보다 많이 프로세싱될 수 있다. 수행된 동작들이 멱등성인 경우, 그러한 반복 동작들은 적어도 몇몇 실시예에서 어떤 부정적 효과도 가지지 않을 수 있다. 대체 작업자 노드가 이전에-저장된 경과 레코드들에 기초하여 반복 복구 동작들을 수행한 후, 적어도 몇몇 실시예에서 대체 작업자 스레드는 복구가 완료되었는지를 나타내는 그 자체의 경과 레코드를 저장할 수 있고, 새롭게-수신된 데이터 레코드들에 대해 정상 작업자 스레드 동작들을 시작할 수 있다(요소(1916)).

도 20은 적어도 몇몇 실시예에 따른, 데이터 스트림들을 위한 복수의 보안 동작을 구현하기 위해 수행될 수 있는 동작들의 측면들을 예시하는 흐름도이다. 요소(2001)에 도시된 바와 같이, 예를 들어 상이한 기능 카테고리들의 노드들(예를 들어, 수집, 저장, 검색, 프로세싱 또는 제어 노드들)을 위한 설치 목적지 유형 옵션들을 포함하여, 클라이언트들이 데이터 스트림 관리 및 프로세싱을 위한 다양한 보안 옵션으로부터 선택하게 하는 하나 이상의 프로그램 인터페이스가 구현될 수 있다. 설치 목적지 유형들은 이들의 보안 프로파일들의 다양한 측면에서 서로 상이할 수 있다. SMS 또는 SPS 노드들을 위해 사용될 자원들의 물리적 위치는 몇몇 실시예에서 목적지 유형에 따라 상이할 수 있다. 예를 들어, 제공자 네트워크 데이터 센터들에 위치되는 인스턴스 호스트들과 같은 자원들이 노드들을 위해 사용될 수 있거나, 클라이언트가 소유한 설비들에서의 자원들이 사용될 수 있거나, 또는 서드 파티 자원들이 사용될 수 있다. 네트워크 분리 레벨들 또는 다른 네트워킹 특성들이 적어도 몇몇 실시예에서 목적지 유형에 따라 상이할 수 있다 - 예를 들어, 몇몇 SMS 또는 SPS 노드는 분리된 가상 네트워크들 내에서, 또는 전용 분리된 물리적 링크들을 통해 제공자 네트워크에 연결되는 클라이언트가 소유한 설비들에서 인스턴스화될 수 있다. 일 실시예에서, 클라이언트들은 특정한 유형들의 SMS 또는 SPS가 또한 이용 가능할 수 있는 멀티-테넌트 인스턴스 호스트들 대신, 제공자 네트워크의 싱글-테넌트 인스턴스 호스트들에서 설정될 것을 나타낼 수 있다. 적어도 몇몇 실시예에서, 다양한 유형의 암호 옵션들이 보안-관련 프로그램 인터페이스들을 통해 또한 선택 가능할 수 있다.

스트림(S1)에 대한 하나 이상의 기능 카테고리 중 노드들에 관한 클라이언트의 보안 프로파일 선택들 또는 선호들이 보안-관련 프로그램 인터페이스들을 통해 수신될 수 있다. 예를 들어, 클라이언트는 기능 카테고리(FC1)의 노드들을 위한 하나의 보안 프로파일(예를 들어, 클라이언트는 클라이언트가 소유한 부지들에 SPS 작업자 노드들을 구현하기를 바랄 수 있다) 및 기능 카테고리(FC2)의 노드들을 위한 상이한 보안 프로파일(예를 들어, 클라이언트는 기꺼이 제공자 네트워크 데이터 센터들에 SMS 수집 노드들 또는 저장 노드들을 구현할 수 있다)을 선택할 수 있다(요소(2004)). 몇몇 경우에서, 클라이언트는 동일한 보안 프로파일을 갖는 모든 상이한 기능 카테고리의 노드들을 셋 업하기로 결정할 수 있다. SMS 및/또는 SPS는 몇몇 실시예에서 다양한 기능 카테고리에 대한 디폴트 설치 목적지 유형들을 정의할 수 있다 - 예를 들어, 클라이언트가 다르게 나타내지 않는 한, 모든 기능 카테고리의 노드들이 제공자 네트워크의 분리된 가상 네트워크들 내에 셋 업될 수 있다.

그 후 상이한 기능 카테고리들의 노드들은 보안 프로파일들 및/또는 장소들에 대한 클라이언트의 선호들에 기초하여(또는 클라이언트가 선호들을 제공하지 않은 기능 카테고리들에 대해 디폴트 설정들에 기초하여) 구성될 수 있다(요소(2007)). 구성은 예를 들어, 적절한 물리적 호스트들 또는 기계들을 선택하는 것, 및 상이한 기능 카테고리들의 노드들에 대해 적절한 컴퓨트 인스턴스들, 가상 기계들, 프로세스들 및/또는 스레드들을 인스턴스화하는 것, 및 노드들 사이에 적절한 네트워크 연결들을 설정하는 것을 수반할 수 있다. 몇몇 실시예에서, 상이한 스트림 관리 및 프로세싱 기능들을 위해 실행 가능한 라이브러리 구성요소들이 구성의 부분으로서 제공자 네트워크 외부의 호스트들에의 설치를 위해 제공될 수 있다.

적어도 몇몇 실시예에 따라, 암호화 모듈들이 예를 들어, 클라이언트의 표현된 암호화 선호들에 따라, 또는 디폴드 암호화 설정들에 기초하여, 노드들의 하나 이상의 카테고리에서 활성화될 수 있다(요소(2010)). 그 후 다양한 기능 카테고리의 노드들이 활성화되고, 따라서 스트림 데이터가 클라이언트에 의해 원해질 때 수집, 저장, 검색 및/또는 프로세싱된다(요소(2013)).

도 21은 적어도 몇몇 실시예에 따른, 데이터 스트림들에 대한 분할 정책을 구현하기 위해 수행될 수 있는 동작들의 측면들을 예시하는 흐름도이다. 요소(2101)에 도시된 바와 같이, 분할 정책이 데이터 스트림을 위해 결정될 수 있다. 정책은 예를 들어, 데이터 생성자들에 의해 제공되는 키들에 기초하여, 또는 제출된 데이터 레코드들의 다양한 속성에 기초하여, 분할들에의 데이터 레코드들의 초기 매핑, 뿐만 아니라 데이터 스트림를 재분할하기 위한 하나 이상의 트리거 기준을 포함할 수 있다. 몇몇 실시예에서, 예를 들어, 해시 함수가 128-비트 정수 해시 값을 산출하여, 분할 키 또는 키들에 적용될 수 있다. 가능한 128-비트 정수들의 범위는 N개의 연접 서브-범위로 분할될 수 있으며, 각각은 스트림의 N개의 분할 중 하나를 나타낸다. 분할들의 수 및/또는 서브-범위들의 상대적 크기들은 몇몇 실시예에서 스트림마다 달라질 수 있다. 적어도 몇몇 실시예에서, 이를 대신하여 스트림이 구성될 클라이언트는 사용된 분할 기법, 예를 들어, 원하는 분할들의 수, 또는 사용될 분할 함수의 원하는 특성들에 관한 입력을 제공할 수 있다. 적어도 일 실시예에서, 클라이언트들은 제출된 데이터 레코드들의 몇몇 서브 세트 또는 전부에 대한 식별자들 또는 명칭들을 제공할 수 있다.

스트림의 데이터 레코드들이 수신됨에 따라, 이들의 각각의 분할들이 제공된 키들 및/또는 다른 속성들에 기초하여 결정될 수 있고, 수집, 저장 및 검색 노드들의 적절한 세트가 식별된 분할에 대해 선택될 수 있다(요소(2104)). 적어도 몇몇 실시예에서, 예를 들어, 소정의 분할의 레코드들이 수신된 시퀀스를 나타내는, 각각의 시퀀스 번호가 데이터 레코드들에 대해 생성될 수 있다(요소(2107)). 시퀀스 번호들은 몇몇 구현예에서, 타임 스탬프 값들(예를 들어, 1970년 1월 1일 00:00:00 UTC와 같은 널리 공지된 에포크 이후에 경과된 초들의 수), 저장 서브 시스템으로부터 획득되는 시퀀스 값들, SMS 소프트웨어의 버전 수들, 및/또는 분할 식별자들과 같은, 다수의 요소를 포함할 수 있다. 시퀀스 번호들은 예를 들어, 제출된 데이터 레코드들의 성공적인 수집을 확인 응답하기 위해, 몇몇 실시예에서 데이터 생성자들에 제공될 수 있다. 시퀀스 번호들은 몇몇 실시예에서 수집 순으로 스트림의 데이터 레코드들 또는 분할을 검색하기 위해 데이터 소비자들에 의해 또한 사용할 수 있다.

데이터 레코드들은 이들이 분할 정책에 기초하여 지향되는 저장 노드들에 적어도 몇몇 실시예에서 시퀀스 번호로 저장될 수 있다(요소(2110)). 회전 자기 디스크 저장 디바이스들이 사용되는 실시예들에서, 순차적 기록들이 디스크에 수신된 데이터 레코드들을 저장하기 위해 통상적으로 사용되고, 그렇게 함으로써 디스크 시크 레이턴시들을 회피할 수 있다. 적어도 몇몇 구현예에서, 비-휘발성 버퍼들이 예를 들어, 디스크 시크들의 확률을 더 감소시키기 위해, 디스크에 레코드들을 저장하기 전 기록 캐시들로서 사용될 수 있다. 시퀀스 번호에 의해 순서화되는 다수의 데이터 레코드의 판독들에 대한 요청들(예를 들어, getNextRecords 또는 유사한 인터페이스들의 호출들)에 응답하여, 데이터 레코드들은 저장 디바이스들로부터 순차적 판독들을 사용하여 이후에 판독될 수 있다(요소(2113)).

도 22는 적어도 몇몇 실시예에 따른, 데이터 스트림들의 동적 재분할을 구현하기 위해 수행될 수 있는 동작들의 측면들을 예시하는 흐름도이다. 요소(2201)에 도시된 바와 같이, 스트림이 동적으로 재분할될 것이라는 결정이 이루어질 수 있다(예를 들어, SMS 또는 SPS의 제어 구성요소에서). 수집, 저장, 검색, 프로세싱 또는 제어 노드들 중 하나 이상에서의 과부하의 검출, 또는 상이한 노드들의 작업 부하 레벨들의 불균형의 검출, 또는 클라이언트(예를 들어, 데이터 생성자 또는 데이터 소비자)로부터 수신될 수 있는 재분할 요청과 같은, 다수의 상이한 트리거 조건이 스트림을 재분할하는 결정을 초래할 수 있다. 클라이언트 재분할 요청들은 몇몇 구현예에서 생성될 변형된 매핑의 다양한 파라미터(예를 들어, 추가되거나 제거될 분할들의 수, 어떤 특정한 분할들이 조합되거나 분할되어야 할지 등)와 같은, 요청된 재분할의 특정한 세부 사항들을 포함할 수 있다. 일 구현예에서, 클라이언트 재분할 요청은 클라이언트가 해결하기를 원하는 문제 상태(부하 불균형과 같은)를 나타낼 수 있고, SMS 또는 SPS는 문제 상태의 설명을 적절한 재분할 동작으로 변환하는 것에 대해 책임이 있을 수 있다. 몇몇 경우에서, 재분할을 요청하거나 문제 상태를 설명하는 대신, 클라이언트는 재분할을 위해 사용될 트리거 기준들을 지정할 수 있다. 데이터 스트림의 데이터 내구성 요건에 대한 변경의 결정은 몇몇 실시예에서 재분할을 트리거할 수 있으며, 이는 예를 들어 스트림 레코드들에 대한 상이한 저장 디바이스들의 세트 또는 상이한 저장 기술의 선택을 야기할 수 있다. 데이터 스트림의 사용량(예를 들어, 데이터 레코드들이 생성되거나 소비되는 비율) 패턴에 대한 변경의 검출은 몇몇 경우에서 재분할을 또한 초래할 수 있고, 변경된 사용량 패턴에 보다 적절한 상이한 저장 기술 또는 저장 디바이스들의 상이한 세트의 사용을 또한 초래할 수 있다. 예를 들어, 재분할의 결정은 소정의 분할 또는 전체 스트림에 대해 예상되는 기록들 및 판독들의 비율에 대해, SSD들이 회전 자기 디스크들보다 더 적절한 저장 기술일 수 있다는 결정에 기초할 수 있다. 스케줄링된 또는 임박한 소프트웨어 및/또는 하드웨어 버전 변경들은 일 실시예에서 재분할을 트리거할 수 있다. 몇몇 경우에서, 가격 결정 또는 과금 우려는 클라이언트가 상이한 분할 접근법 또는 저장에 대한 상이한 접근법을 사용하여 보다 효율적으로 충족될 수 있는 수요예측 제약을 나타낼 때, 재분할을 트리거할 수 있다. 변경된 성능 타겟들은 적어도 몇몇 실시예에서 재분할을 또한 트리거할 수 있다. 도 22에 도시된 실시예에서, 재분할 이후 할당되는 시퀀스 번호들에 대해 사용될 초기 타임 스탬프 값(1970년 1월 1일 00:00:00 UTC로부터 초들의 오프셋, 몇몇 운영 시스템에서 시스템 호출을 통해 통상적으로 이용 가능한 에포크 값과 같은)이 선택될 수 있다(요소(2204)). 몇몇 구현예에서, 제공자 네트워크에서 구현되는 전역적 상태 관리기는 예를 들어, SMS 및/또는 SPS의 다양한 구성요소가 시퀀스 번호 생성을 위해 사용될 일관된 타임 스탬프 값들을 획득하게 하는, getEpochValue API를 지원할 수 있다. 다른 구현예들에서, 다른 시간 소스들이 사용될 수 있다 - 예를 들어, SMS 또는 SPS 제어 노드가 다른 구성요소들에 일관적으로-순서화된 타임 스탬프 값들을 제공하기 위해 지정될 수 있거나, 또는 지역적 시스템 호 호출이 사용될 수 있다. 몇몇 실시예에서, 타임 스탬프 값들은 반드시 임의의 특정한 호스트에서의 벽 시계 시간에 대응할 필요는 없다 - 예를 들어, 단조적으로 증가하는 정수 카운터가 간단하게 사용될 수 있다.

재분할 결정 시 사용 중인 매핑과 상이한, 변형된 분할 매핑이 스트림에 대해 생성될 수 있다(요소(2207)). 변경된 매핑은 적어도 몇몇 실시예에서 재분할 이전에 매핑된 동일한 키를 갖는 데이터 레코드들과 상이한 분할을 위해 특정한 분할 키를 갖고 데이터 레코드들을 매핑할 수 있다. 재분할을 위한 트리거 조건들 및/또는 관측된 작업 부하 메트릭스에 따라, 몇몇 분할(통상적으로, 과중하게 사용된 분할)은 분할될 수 있는 한편, 다른(통상적으로 가볍게-사용된) 분할들은 병합될 수 있다. 상이한 분할 기능이 몇몇 실시예에서 재분할 이전보다 재분할 이후에 사용될 수 있다 - 예를 들어, 상이한 해시 함수, 또는 해시 함수 결과들의 분할들로의 세분을 위한 상이한 접근법이 사용될 수 있다. 예를 들어, 분할들이 128-비트 정수들의 연접 범위들에 대응하는 몇몇 구현예에서, 128-비트 정수 공간은 재분할 이후 서브-범위들의 상이한 세트로 분할될 수 있다. 적어도 몇몇 실시예에서, 수집, 저장, 검색, 프로세싱 또는 제어 노드들의 새로운 세트들이 새롭게-생성된 분할들에 할당될 수 있다. 몇몇 구현예에서 공간-효율적인 조합된 데이터 구조가 초기 매핑 및 변형된 매핑 양자를 나타내기 위해 사용될 수 있다(요소(2208)). 예를 들어, 각 에트리가 분할 함수 출력 범위(예를 들어, 소정의 분할에 대응하는 분할 해시 함수의 결과들의 범위) 및 유효한 시간 범위의 표시를 포함하는, 방향성 비주기적 그래프 또는 트리 구조가 저장될 수 있고, 따라서 변형된 분할들에 대응하는 레코드들이 재분할의 결과로서 변경되기만 하면 된다. 재분할 동안 변경되지 않고 남아 있는 분할들에 대한 엔트리들은 데이터 구조가 변경될 필요가 없을 수 있다. 새로운 노드들은 변형된 분할 매핑을 구현하도록 구성될 수 있다(요소(2210)). 적어도 몇몇 실시예에서, 이전 매핑을 기초로 저장된 데이터 레코드들에 대한 검색 요청들이 적어도 일정 시간 동안 계속해서 검색될 수 있기 때문에, 이전 노드들 및 이전 매핑이 일정 시간 동안 유지될 수 있다. 특정한 시퀀스 번호 또는 타임 스탬프를 지정하는 판독 요청이 수신될 때(요소(2213)), 판독 요청이 새로운 분할 매핑을 사용하여 충족될지 또는 이전 분할 매핑을 사용하여 충족될지에 대한 결정이 이루어질 수 있다(예를 들어, 제어 노드에서 또는 검색 노드에서). 그 후 선택된 매핑이 요청된 데이터가 획득될 적절한 저장 노드를 식별하기 위해 사용될 수 있다.

도 23은 적어도 몇몇 실시예에 따른, 데이터 스트림 레코드들에 대한 최소-한 번의 레코드 수집 정책을 구현하기 위해 수행될 수 있는 동작들의 측면들을 예시하는 흐름도이다. 요소(2301)에 도시된 바와 같이, 하나 이상의 프로그램 인터페이스는 클라이언트들이 예를 들어 (a) 이에 따라 긍정 확인 응답이 수신될 때까지 한 번 이상 레코드 제출기가 레코드를 제출할 최소-한 번 정책 또는 (b) 이에 따라 확인 응답들이 적어도 몇몇 레코드 제출에 제공되지 않는 최선-노력 수집 정책을 포함하여, 몇몇 수집 정책 옵션 중으로부터 데이터 스트림을 위한 레코드 수집 정책을 선택하게 하도록 구현될 수 있다. 몇몇 데이터를 생성하는 클라이언트는 다른 클라이언트들과 같이 이들의 레코드들의 작은 부분의 잠재적 손실에 대해 걱정하지 않을 수 있고, 그에 따라 최선-노력 수집 접근법을 선택할 수 있다. 몇몇 구현예에서, 심지어 최선-노력 수집에 대해 구성되는 스트림들에 대해, SMS는 데이터 레코드들의 어떤 서브 세트에 대한 확인 응답들을 여전히 제공할 수 있거나, 또는 심지어 최선-노력 정책이 모든 데이터 레코드에 대한 확인 응답들을 필요로 하지 않더라도, 모든 데이터 레코드에 대한 확인 응답들을 제공하려고 노력할 수 있다.

요청은 지정된 스트림을 위해 사용될 특정한 수집 정책을 나타내어, 프로그램 인터페이스들 중 하나를 통해 수신될 수 있다(요소(2304)). 수집 노드들은 스트림에 대해 유효한 분할 정책에 따라 인스턴스화될 수 있다(요소(2307)). 동일한 데이터 레코드이 하나 이상의 제출이 수집 노드에 수신될 때(요소(2310)), 상이한 액션들이 유효한 수집 정책에 따라 취해질 수 있다. 최소-한 번 수집 정책이 사용 중인 경우(요소(2313)에서 결정되는 바와 같이), 확인 응답이 하나 이상의 제출에 대해 데이터 생성자에 송신될 수 있으나, 데이터 레코드는 저장 서브 시스템에 단지 한 번만 저장될 수 있다(2316). (스트림에 대해 유효한 지속 정책들에 따라, 소정의 레코드의 N개의 복제본이 몇몇 경우에서 저장될 수 있으나, 소정의 데이터 레코드가 M번 제출되는 경우, 복제본들은 제출들 중 단지 하나에 대해 생성될 수 있다 - 즉, 저장되는 레코드 복제본들의 총 수는 NxM이 아니라 여전히 N일 수 있다.) 최선-노력 수집 정책이 시행 중이었던 경우(요소(2313)에서 또한 검출되는 바와 같이), 데이터 레코드는 여전히 저장 디바이스에 한 번 저장될 수 있으나, 어떤 확인 응답도 데이터 생성자에 송신될 필요는 없다(요소(2319)). 적어도 몇몇 실시예에서, 클라이언트 과금액은 선택되는 수집 정책에 적어도 부분적으로 기초하여 선택적으로 결정될 수 있다(요소(2322)). 이전에 언급된 바와 같이, 몇몇 실시예에서, 최소-한 번 수집 정책의 두 개의 버전이 지원될 수 있다. 도 23에 예시된 것과 유사한, 하나의 버전에서, SMS는 데이터 레코드들의 중복을 제거하는 것에 대해 책임이 있을 수 있다(즉, 데이터가 두 개의 제출의 세트 중 단지 하나에 응답하여 SMS 저장 서브 시스템에 저장된다는 것을 보장한다). 최소-한 번 수집의 상이한 버전에서, SMS에 의한 데이터 레코드들의 중복이 허용될 수 있다. 후자의 접근법은 데이터 레코드 중복의 몇몇 부정적인 결과가 존재하거나 어떤 부정적인 결과도 존재하지 않는 스트림 애플리케이션들에, 그리고/또는 그것들 자체의 중복 제거를 수행하는 스트림 애플리케이션들에 유용할 수 있다.

도 24는 적어도 몇몇 실시예에 따른, 데이터 스트림들에 대한 복수의 지속 정책을 구현하기 위해 수행될 수 있는 동작들의 측면들을 예시하는 흐름도이다. 요소(2401)에 도시된 바와 같이, 클라이언트들이 복수의 지속 정책 중으로부터 스트림 데이터 레코드들에 대한 지속 정책을 선택하게 하는 하나 이상의 프로그램 인터페이스가 구현될 수 있다. 지속 정책들은 다양한 측면 중 임의의 측면에서 서로 상이할 수 있다: 예를 들어, (a) 저장될 복제본들의 수가 상이할 수 있다(예를 들어, N개-복제본 vs. 2개-복제본 vs. 단일-복제본 정책들이 지원될 수 있다) (b) 사용될 저장 장소/디바이스 유형들이 상이할 수 있다(예를 들어, 회전 자기 디스크 vs. SSD vs. RAM vs. 데이터베이스 서비스 또는 멀티-테넌트 저장 서비스) 및/또는 (c) 정책들은 대규모 고장들에 대한 회복성의 예상되는 정도가 상이할 수 있다(예를 들어, 다중-데이터-센터 vs. 단일-데이터-센터 정책들이 지원될 수 있다). 지정된 스트림에 대해 특정한 지속 정책의 클라이언트의 선택을 나타내는 요청이 수신될 수 있다(요소(2404)). 몇몇 실시예에서, 클라이언트에 의해 선택되는 지속 정책은 소정의 스트림의 각각의 분할들에 대해 상이한 저장 장소 유형들 또는 디바이스 유형들의 사용을 야기할 수 있다. 일 실시예에서, 클라이언트보다는 SMS가 스트림 레벨에서 또는 분할 레벨에서, 저장 장소 유형 또는 디바이스 유형들을 선택할 수 있다. 클라이언트들은 몇몇 실시예에서 지속 정책을 선택할 때 몇몇 실시예에서 데이터 내구성 목적들 및/또는 성능 목적들(원하는 판독 또는 기록 처리량 또는 레이턴시와 같은)을 나타낼 수 있고, 이들 목적은 적절한 저장 디바이스들 유형들 또는 장소들을 선택하기 위해 SMS에 의해 사용될 수 있다. 예를 들어, 낮은 레이턴시들이 원해지는 경우, SSD들은 하나 이상의 분할 또는 스트림의 데이터 레코드들을 저장하기 위해 회전 자기 디스크들 대신 사용될 수 있다.

수집 노드들의 세트는 데이터 생성자들로부터 선택된 스트림의 데이터 레코드들을 수신하도록 결정되거나 구성될 수 있고, 저장 노드들의 세트는 선택된 지속 정책을 구현하도록 구성될 수 있다(요소(2407)). 데이터 레코드가 노드에 수신될 때(요소(2410)), 데이터 레코드의 하나 이상의 카피가 데이터 레코드가 속하는 분할에 대해 책임이 있는 저장 노드들에 의해 선택된 저장 디바이스들에, 선택된 지속 정책에 따라, 저장될 수 있다(요소(2413)). 적어도 몇몇 구현예에서, 과금액은 클라이언트에 의해 선택되는 특정한 지속 정책들에 기초하여 선택적으로(그리고/또는 비동기로) 결정될 수 있다(요소(2416)).

스트림 프로세싱에 대한 분산식 작업 부하 관리

몇몇 실시예에서, SPS의 제어-영역 기능 중 상당한 부분 또는 전부가 예를 들어, 데이터베이스 테이블과 같은 공유된 데이터 구조를 통해 다양한 제어 동작(작업자 노드들의 분할 할당, 동적 재분할에 대한 응답들, 상태 모니터링 및/또는 부하 불균형)을 조정하는 소정의 SPS 스테이지 내 작업자 노드들에 의해, 분산식 방식으로 구현될 수 있다. 소정의 작업자 노드(W1)는 예를 들어, 스테이지의 입력 스트림들의 어떤 부분들(만약에 있다면)이 동시에 프로세싱되지 않는지를 결정하기 위해 공유된 데이터 구조 내 엔트리들을 점검할 수 있다. 그러한 분할(P1)이 발견되는 경우, W1은 W1이 P1의 레코드들에 대해 스테이지의 프로세싱 동작들을 수행할 것이라는 것을 나타내기 위해 공유된 데이터 구조에서의 엔트리를 업데이트할 수 있다. 다른 작업자 노드들은 W1이 P1 레코드들을 프로세싱하기 위해 할당된다는 것을 알게 될 수 있고, 그에 따라 그들 자체에 상이한 분할들을 할당할 수 있다. 작업자 노드들은 입력 스트림에 대해 유효한 현재 분할 맵들을 결정하기 위해 SMS 제어 영역에 질의들을 주기적으로 또는 가끔 제출하고, 필요 시 맵 변경들(예를 들어, 재분할의 결과로서)을 나타내기 위해 공유된 데이터 구조를 업데이트할 수 있다. 부하 불균형 및 다른 동작들은 아래에 설명될 바와 같이, 다양한 실시예에서 공유된 데이터 구조를 통해 또한 조정될 수 있다. 몇몇 그러한 분산식 구현예에서, 전용 제어 노드들은 SPS에 대해 요구되지 않고, 그렇게 함으로써 SPS 작업 흐름들을 구현하기 위해 요구되는 오버헤드를 감소시킬 수 있다. 그러한 분산식 SPS 제어 영역 구현예들은 예를 들어, 소비자들에 할당되는 제공자 네트워크 내 컴퓨트 인스턴스들에서, 또는 제공자 네트워크 밖의 장소들에서, 스트림 프로세싱의 다양한 측면을 구현하기 위해 SPS 클라이언트 라이브러리를 이용하는 수요예측을 의식하는 소비자들에게 특히 인기가 있을 수 있다. 분산식 SPS 제어-영역 기술들은 예를 들어, SMS 및 SPS를 위해 사용되는 모든 자원이 제공자 네트워크 내에 구성될 때, 클라이언트 라이브러리들이 사용되지 않는 실시예들에서 또한 사용될 수 있다. 작업자 노드들이 적어도 몇몇 프로세싱 스테이지에 대해 SPS 제어 영역 기능들 중 몇몇 또는 전부를 구현하는 SPS는 "분산식-제어 SPS"로서 본 출원에서 지칭될 수 있다.

도 25는 적어도 몇몇 실시예에 따른, 프로세싱 스테이지의 작업자 노드들이 데이터베이스 테이블을 사용하여 이들의 작업 부하들을 조정하는 스트림 프로세싱 시스템의 예를 예시한다. 분산식-제어 SPS(2590)내에, 두 개의 스테이지(215A 및 215B)가 정의되며, 각각은 작업자 노드들의 각각의 세트를 갖는다. 스테이지(215A)는 작업자 노드들(2540A 및 2540B)을 포함하는 한편, 스테이지(415B)는 작업자 노드들(2540K 및 2540L)을 포함한다. 각 스테이지(215A 및 215B)에 대해, 대응하는 분할 할당(PA) 테이블(2550)이 스테이지(215A)에 대한 PA 테이블(2550A) 및 스테이지(215B)에 대한 PA 테이블(2550B)과 같은, 데이터베이스 서비스(2520)에서 생성된다. 소정의 스테이지에 대한 PA 테이블(2550)은 예를 들어, 클라이언트 라이브러리 구성요소 또는 기능의 호출에 응답하여, 몇몇 실시예에서 스테이지 초기화 동안 생성될 수 있다. 각 PA 테이블(2550)은 스테이지의 입력 스트림들의 할당되지 않은 분할들(즉, 어떤 작업자 노드도 현재 할당되지 않은 분할들)을 나타내는 로우들(rows) 또는 엔트리들의 초기 세트로 파퓰레이팅될 수 있다. PA 테이블 엔트리들의 예시적인 컬럼 또는 속성이 도 26에 도시되고, 아래에 설명된다. 스테이지에 대해 개시되는 작업자 노드들(2540)(예를 들어, 컴퓨트 인스턴스들 또는 다른 서버들에 개시되는 프로세스들 또는 스레드들)에 스테이지의 PA 테이블에의 판독/기록 액세스 권한이 주어질 수 있다. 작업자 노드들로부터 PA 테이블들에 지시되는 판독들 및 기록들이 작업자 노드들(2540A, 2540B, 2540K 및 2540L) 각각에 대해 화살표들(2564A, 2564B, 2564K 및 2564L)에 의해 도 25에 표현된다.

소정의 작업자 노드(2540)는 PA 테이블에서의 엔트리들을 검토함으로써, 스테이지의 프로세싱 동작들을 수행할 특정한 분할을 선택하도록 구성될 수 있다. 일 구현예에서, 작업자 노드(2540A)는 그것이 할당되지 않은 부분(Pk)의 엔트리를 발견할 때까지 PA 테이블(2550A)에서의 엔트리들을 스캔할 수 있고, 엔트리를 업데이트함으로써, 예를 들어, 작업자 노드의 식별자를 엔트리의 컬럼들 중 하나에 삽입함으로써, 분할(Pk)을 그 자체에 할당하려고 시도할 수 있다. 그러한 삽입은 작업자 노드에 의해 분할을 로킹(locking)하는 것과 유사한 것으로 간주될 수 있다. 사용된 데이터베이스 서비스의 유형에 따라, (예를 들어, 동시에 가깝게 할당되지 않은 분할을 식별하는 두 개 이상의 작업자 노드에 의해) PA 테이블 엔트리들에 잠재적으로 동시에 발생하는 기록들을 관리하는 것에 대한 상이한 접근법들이 사용될 수 있다.

일 실시예에서, 제공자 네트워크의 비-관계형 멀티-테넌트 데이터베이스 서비스가 사용될 수 있으며, 이는 반드시 관계형 데이터베이스 트랜잭션 시맨틱스를 지원할 필요 없이 강한 일관성 및 조건부 기록 동작들을 지원한다. 조건부 기록 동작은 작업자 노드들에 의한 업데이트들을 위한 그러한 경우에 사용될 수 있다. PA 테이블에서 분할에 할당되는 특정한 작업자 노드의 식별자를 나타내기 위해 컬럼 " 작업자-노드-ID"가 사용되고, 어떤 작업자 노드도 분할에 할당되지 않는 경우에는 컬럼의 값이 "널"로 설정되는 예를 고려하자. 그러한 시나리오에서, 식별자(WID1)를 갖는 작업자 노드는 다음의 논리적 균등물을 요청할 수 있다: "분할(Pk)에 대한 엔트리에서, 작업자-노드-ID가 널이면, 해당 엔트리에 대한 작업자-노드-ID를 WID1로 설정하자". 그러한 조건부 기록 요청이 성공되는 경우, 식별자(WID1)를 갖는 작업자 노드는 분할(Pk)이 그것에 할당됨을 상정할 수 있다. 그 후 작업자 노드는 예를 들어, 화살표들(2554)(예를 들어, 작업자 노드들(2540A, 2540B, 2540K 및 2540L) 각각에 대해 화살표들(2554A, 2554B, 2554K 및 2554L))에 의해 표시된 바와 같이, SMS 검색 서브 시스템(206)의 레코드 검색 인터페이스들을 사용하여, 그리고 검색 레코드들 상에 프로세싱 동작들을 수행하여, 분할(Pk)의 데이터 레코드들을 검색하기 시작할 수 있다. 조건부 기록이 실패하는 경우, 작업자 노드는 상이한 할당되지 않은 분할에 대한 검색을 재개할 수 있다. 다른 실시예들에서, 트랜잭션들을 지원하는 데이터베이스 서비스들(관계형 데이터베이스들과 같은)이 사용될 수 있고, 트랜잭션 기능이 조건부 기록 동작들의 균등물을 구현하기 위해 - 예를 들어, 작업자 노드에 분할을 할당하려는 복수의 동시에 발생하는(또는 거의 동시에 발생하는) 시도 중 단지 하나가 성공한다는 것, 및 그러한 동시에 발생하는 시도들에 수반되는 작업자 노드들이 이들의 성공 또는 실패에 대해 확실하게 통지된다는 것을 보장하기 위해 사용될 수 있다. 조건부 기록들에도 트랜잭션 지원에도 의존하지 않는 동기화 기술들이 몇몇 실시예에서 사용될 수 있다. 몇몇 구현예에서 데이터베이스 서비스가 사용되지 않을 수 있다; 대신, 로킹 서비스(locking service)가 PA 테이블들과 유사한 지속적 데이터 구조들에서의 엔트리들에 대한 업데이트들을 위한 배타적인 액세스를 획득하기 위해 작업자 노드들에 의해 사용될 수 있다.

다른 작업자 노드들(2540)은 PA 테이블에서의 엔트리들을 검토할 수 있고, 어떤 분할들이 할당되지 않았는지를 결정하며, 그리고 그들 자체에 하나 이상의 분할을 할당하는 것에 결국에는 성공할 수 있다. 이러한 방식으로, 스테이지의 입력 스트림 또는 스트림들의 분할들에 대한 프로세싱 작업 부하는 스테지이의 작업자 노드들에 의해 그들 자체 중에 결국에는 분산될 수 있다.

임의의 소정의 스트림의 초기 분할 매핑은 시간 경과에 따라예를 들어, 이전에 설명된 동적 재분할 동작들의 결과로서, 변경될 수 있다. 따라서, 도 25에 도시된 실시예에서, 작업자 노드들(2540) 중 하나 이상은 현재 분할 메타데이터를 획득하기 위해 이들의 스테이지의 입력 스트림(들)의 SMS 제어 서브 시스템(210)에 요청들을 가끔(또는 아래에 설명될 바와 같이 트리거 조건에 응답하여) 제출할 수 있다. 몇몇 구현예에서, 그러한 요청들은 화살표들(2544A, 2544B, 2544K, 및 2544L)에 의해 표시되는 getStreamInfo API의 호출들과 같은, SMS 제어 영역 API들의 호출들을 포함할 수 있다. SMS 제어 서브 시스템은 예를 들어, 스트림의 분할들의 최신 리스트, 및/또는 분할들의 유효한 시간 기간들과 같은 다른 세부 사항들로 응답할 수 있다. SMS 제어 서브 시스템(210)에 의해 제공되는 분할 정보가 PA 테이블에서의 엔트리들에 매칭되지 않는 경우, PA 테이블은 하나 이상의 분할에 대한 엔트리들을 삽입하거나 삭제함으로써, 작업자 노드에 의해 변형될 수 있다. SMS 제어 서브 시스템에 대한 그러한 요청들(2554)은 화살표(2554A)의 라벨 "저 빈도"에 의해 표시되는 바와 같이, 적어도 몇몇 실시예에서 레코드 검색 요청들(2554)(및/또는 데이터베이스 판독 또는 기록 동작들(2564))보다 훨씬 덜 빈번할 수 있다. 예를 들어, 그것이 분할에 할당될 때, 작업자 노드는 분할 데이터가 완전히 소비될 때까지(예를 들어, 스트림의 소유자가 스트림을 폐쇄할 경우, 또는 분할이 동적 재분할의 결과로서 폐쇄되는 경우), 또는 어떤 다른 낮은 확률의 상황에 직면할 때까지(예를 들어, 아래에서 논의될 바와 같이, 상이한 작업자 노드가 검출된 부하 불균형으로 인해 분할의 이동을 요청하는 경우) 해당 분할의 데이터 레코드들을 통상적으로 검색하고 프로세싱하는 것을 계속할 수 있다. 따라서, getStreamInfo 또는 유사한 API들을 호출하는 것과 연관된 오버헤드는 상당한 정보량이 임의의 소정의 호출에 응답하여 제공되더라도(수백 또는 수천 개의 분할이 스테이지의 입력 스트림을 위해 정의되는 경우일 수 있는 바와 같이), 다양한 실시예에서 통상적으로 꽤 작을 수 있다.

따라서 분산식-제어 SPS 환경의 키 작업 부하-관리 동작들 중 몇몇이 도 25에 도시된 실시예에서 다음과 같이 요약될 수 있다 : (a) 스트림 프로세싱 스테이지의 제1 작업자 노드에 의해 데이터베이스 테이블에 액세스하는 것에 적어도 부분적으로 기초하여, 해당 스테이지를 위해 정의되는 프로세싱 동작들의 세트를 구현할 스트림 프로세싱 스테이지의 입력 데이터 스트림의 특정한 분할을 선택하는 동작; (b) 테이블에 저장된 특정한 엔트리에, 제1 작업자 노드에의 특정한 분할의 할당의 표시자를 기록하는 동작; (c) 제1 작업자 노드에 의해, 멀티-테넌트 스트림 관리 서비스에서 구현되는 프로그램 레코드 검색 인터페이스들을 사용하여 특정한 분할의 레코드들을 검색하는 동작; (d) 제1 작업자 노드에 의해, 특정한 분할의 레코드들에 대한 프로세싱 동작들의 세트를 구현하는 동작; (e) 제2 작업자 노드에 의해, 특정한 데이터베이스 테이블에서의 특정한 엔트리에 적어도 부분적으로 기초하여, 제1 작업자 노드가 특정한 분할에 대해 프로세싱 동작들의 세트를 수행하기 위해 할당되는지를 결정하는 동작; 및 (f) 제2 작업자 노드에 의해, 프로세싱 동작들의 세트를 수행할 상이한 분할을 선택하는 동작. 작업자 노드가 그것에 할당되는 분할에 더 이상 어떤 레코드도 남아 있지 않다는 것을 결정하는 경우 및 결정할 때, 작업자 노드는 SMS 제어 서브 시스템으로부터 입력 스트림 상의 메타데이터를 요청할 수 있고, 메타데이터가 불일치를 나타내는 경우 PA 테이블을 업데이트할 수 있다.

도 26은 적어도 몇몇 실시예에 따른, 작업 부하 조정을 위해 사용되는 분할 할당 테이블(2550)에 저장될 수 있는 예시적인 엔트리들을 예시한다. 도시된 바와 같이, 테이블(2550)은 네 개의 컬럼을 포함할 수 있다: 분할 식별자 컬럼(2614), 할당된 작업자 노드 식별자 컬럼(2618), 작업자 노드 상태 표시자 컬럼(2620), 및 작업 부하 레벨 표시자 컬럼(2622). 다른 컬럼 세트들이 다른 구현예들에서 구현될 수 있다 - 예를 들어, 분할 생성 시간 또는 분할 함수 출력 값 범위를 나타내는 컬럼이 몇몇 실시예에서 사용될 수 있거나, 또는 작업 부하 레벨 표시자 컬럼이 사용되지 않을 수 있다.

(예를 들어, 이전에 설명된 분할 엔트리 트리, 그래프 또는 다른 조합된 데이터 구조의 부분으로서) SMS 제어 서브 시스템에 의해 유지되는 분할 리스트(2650)가 적어도 몇몇 시점에서, 몇몇 실시예에서 PA 테이블(2550)에 포함되는 것보다 많은 분할을 포함할 수 있다는 것이 주목된다. 도시된 예에서, 분할 리스트(2650)는 분할들(P1, P2, P3, P4 및 P5)(이들 중 P1 및 P4는 재분할의 결과로서 폐쇄된 상태로 도시됨)을 포함하는 한편, P2, P3 및 P5는 활동 중(즉, 이의 데이터 레코드들이 현재 검색되고 프로세싱되고 있는 분할들)인 것으로 도시된다. PA 테이블(2650)은 도시된 실시예에서 활동 중 분할들에 대한 엔트리들을 포함하고, 폐쇄된 분할들(예를 들어, 작업자 노드들이 재분할이 일어난 후 getStreamInfo 호출들에 대한 응답들을 획득했을 때 이들에 의해 삭제되었을 수 있는)에 대한 엔트리들은 포함하지 않는다. 적어도 몇몇 구현예에서, 스트림의 모든 현재 개방된 분할들이 반드시 소정의 시점에 PA 테이블에 각각의 엔트리들을 가지지는 않을 수 있다; 대신, 예를 들어, 단지 현재 할당되거나 프로세싱되고 있는 그것들의 분할들의 서브 세트가 표현될 수 있다.

도 26에 예시된 예시적인 시나리오에서, 분할들(P1 및 P2)은 각각 식별자들(W7 및 W3)을 갖는 작업자 노드들에 할당되는 한편, P5는 현재 할당되지 않았다. 상태 표시자 컬럼(2620)은 상이한 구현예들에서 상이한 유형들의 값들을 저장할 수 있다. 몇몇 구현예에서, 작업자 노드들은 작업자 노드들이 활동 중이고 이들의 검색 및 프로세싱 동작들을 계속할 수 있다는 것을 나타내기 위해 이들의 할당된 분할들의 PA 엔트리들에서의 상태 표시자 컬럼들의 콘텐츠를 주기적으로(예를 들어, 매 N초마다, 또는 휴리스틱들의 어떤 세트에 기초한 스케줄에 따라) 업데이트하는 것에 대한 책임이 있을 수 있다. 도 26에서, 해당 엔트리에 대한 작업자 노드가 상태 표시자 컬럼("최후-변형-시간")을 업데이트한 가장 최근 시간의 표시가 저장될 수 있다 - 예를 들어, 작업자(W7)는 2013년 12월 1일 02:24:54.53초에 엔트리를 변형한 것으로 도시된다. 다른 작업자 노드들은 할당된 작업자 노드가 몇몇 실시예에서 정상 상태인지 또는 그렇지 않은지를 결정하기 위해 최후-변형 시간 값을 사용할 수 있다 - 예를 들어, X초 또는 분이 경과한 경우, 스테이지를 위한 시스템 대체 작동 정책에서 정의되는 바와 같이, 할당된 작업자 노드가 이상 상태 또는 액세스하기 어려운 상태인 것으로 상정할 수 있고 분할이 재할당될 수 있다. 다른 구현예들에서, 카운터가 상태 표시자로서 사용될 수 있거나(예를 들어, 카운터 값이 Y초 동안 변경되지 않은 경우, 할당된 작업자 노드는 시스템 대체 작동을 위한 후보로 여겨질 수 있다), 또는 할당된 작업자 노드가 엔트리를 마지막으로 판독한 때를 나타내는 "최후-판독-시간" 값이 사용될 수 있다.

적어도 몇몇 실시예에서, 일정한 최근 시간 간격 동안(예를 들어, 최후-변형-시간 이전 5분 동안) 프로세싱된 레코드들의 수, CPU 이용, 메모리 이용, 저장장치 이용과 같은 작업자 노드의 최근 성능-관련 메트릭스 등과 같은, 작업 부하 레벨 표시자 값(2622)이 예를 들어, 할당된 작업자 노드에 의해, 엔트리에 저장될 수 있다. 그러한 작업 부하 레벨 표시자 값들은 도 29에 대해 아래에서 설명될 바와 같이, 부하 불균형이 존재하는지를 결정하기 위해, 그리고 검출된 불균형에 응답하여 액션들을 취하기 위해 작업자 노드들에 의해 몇몇 실시예에서 사용될 수 있다. 예를 들어, 작업자 노드(Wk)는 이의 작업 부하 레벨이 평균 작업 부하 레벨을 초과한다고 결정할 수 있고, 이의 분할들 중 하나를 할당하지 않을 수 있거나, 또는 동적 재분할을 요청할 수 있다; 대안적으로, 작업자 노드(Wk)는 이의 작업 부하가 다른 작업자 노드들 또는 분할들의 작업 부하에 관해 너무 낮다고 결정할 수 있고, 그 자체에 추가적인 분할들을 할당할 수 있다. 따라서, 도 26에 표시된 PA 테이블의 컬럼들을 사용하여, 작업자 노드들은 집중식-제어 SPS 구현예들에서 전용 SPS 제어 노드들에 의해 통상적으로 수행될 수 있는 도시된 실시예에서 동일한 유형들의 제어-영역 기능들 중 몇몇을 수행할 수 있다.

도 27은 적어도 몇몇 실시예에 따른, 프로세싱 동작들을 수행하기 위한 분할들을 선택하기 위해 스트림 프로세싱 스테이지의 작업자 노드들에 의해 수행될 수 있는 동작들의 측면들을 예시한다. 요소(2701)에 도시된 바와 같이, PA 테이블(PAT1)은 분산식-제어 SPS 프로세싱 스테이지(SP1)에 대해 데이터베이스 서비스에서 초기화될 수 있다. 테이블은 예를 들어, SPS 클라이언트 라이브러리 구성요소가 예를 들어, 클라이언트 설비에서의 호스트로부터 또는 제공자 네트워크 데이터 센터에서의 컴퓨트 인스턴스로부터, 호출될 때, 생성될 수 있다. 클라이언트 라이브러리는 다양한 목적을 위해 사용될 수 있다: 예를 들어, SPS 스테이지에서 구현될 특정한 프로세싱 동작들에 대해 JAR(Java™ 아카이브) 파일과 같은 실행 가능한 구성요소를 제공하기 위해, 작업자 노드들을 식별하기 위해 사용될 수 있는 라벨(프로그램 명칭, 프로세스 명칭 또는 컴퓨트 인스턴스 명칭과 같은)을 나타내기 위해, 스테이지에 대한 입력으로서 사용될 스트림을 나타내기 위해, 스테이지의 출력 목적지들(만약에 있다면)을 나타내기 위해 등. PAT1은 스테이지의 입력 스트림(들)을 위해 정의되는 분할들({P1, P2, ...})의 적어도 서브 세트에 대한 로우들 또는 엔트리들로 몇몇 실시예에서 초기에 파퓰레이팅될 수 있다. 몇몇 구현예에서, 테이블은 초기에 빈 채로 남아 있을 수 있고, 작업자 노드들 중 하나 이상은 예를 들어, SMS 제어 서브 시스템으로부터 분할 메타데이터를 획득하는 것의 결과로서, 할당되지 않은 분할들에 대해 로우들로 테이블을 파퓰레이팅할 수 있다. 예를 들어, 제공자 네트워크 내 다양한 컴퓨트 인스턴스에서 또는 클라이언트가 소유한 컴퓨팅 디바이스들에서 작업자 노드들({W1, W2, ...})의 초기 세트가 스타트 업될 수 있다(요소(2704)). 작업자 노드들은 도시된 실시예에서 PAT1에의 판독 및 기록 액세스 권한이 주어질 수 있다.

작업자 노드들이 가동됨에 따라, 이들은 할당되지 않은 분할들을 발견하려고 시도하기 위해 PAT1에 각각 액세스할 수 있다. 예를 들어, 작업자 노드(W1)는 PAT1을 검토하고 분할(P1)이 할당되지 않았다는 것을 발견할 수 있다(요소(2707)). 그 후 W1은 예를 들어, P1이 W1에 할당된다는 것을 나타내기 위해, 사용된 데이터베이스 서비스의 유형에 따른 조건부 기록 요청 또는 트랜잭션의 업데이트 요청을 사용하여, PAT1에서의 P1의 엔트리를 업데이트할 수 있다(요소(2710)). 테이블을 업데이트한 후, W1은 SMS 검색 서브 시스템 인터페이스들을 사용하여 P1의 데이터 레코드들의 검색을 개시할 수 있고(요소(2713)), 검색된 레코드들에 대해 스테이지(PS1)의 프로세싱 동작들을 수행할 수 있다.

그동안, 일정 시간에, 상이한 작업자 노드(W2)는 할당되지 않은 분할들을 발견하기 위해 그 자체의 시도 시 PAT1에 액세스할 수 있다(요소(2716)). W2는 W1의 이전 업데이트에 기초하여, P1이 이미 할당되었으나, 상이한 분할(P2)이 할당되지 않았는지 결정할 수 있다. 몇몇 실시예에서, P2의 현재 인수(assignee) 작업자 노드가 이상 상태이거나 비활동 중이라는(예를 들어, P2의 엔트리에서의 상태 표시자 컬럼에 기초하여) W2에 의한 결정이 또한 W2가 P2를 선택하게 유도할 수 있다. 따라서, 적어도 몇몇 실시예에서, 할당되지 않은 상태, 또는 작업자 노드의 이상 상태의 결정 중 어느 하나는 재할당(또는 초기 할당)을 위해 소정의 분할을 선택하기 위해 사용될 수 있다. 그 후 W2는 그 자체에 P2를 할당하도록 PAT1을 업데이트하려고 시도할 수 있다(요소(2719)). 업데이트가 성공하는 경우, W2는 SMS 검색 인터페이스들을 사용하여 P2 레코드들을 검색하고(요소(2722)) 스테이지를 위해 정의되는 적절한 프로세싱 동작들을 수행하기 시작할 수 있다.

이전에 언급된 바와 같이, 분산식-제어 SPS에서의 작업자 노드들은 SMS로부터 분할 매핑 정보를 (통상적으로 빈번하지 않게) 획득하고, 필요한 경우 PA 테이블을 업데이트하기 위해 그러한 정보를 사용할 수 있다. 도 28은 적어도 몇몇 실시예에 따른, 스트림 관리 서비스 제어 서브 시스템으로부터 획득되는 정보에 기초하여 분할 할당 데이블을 업데이트하기 위해 스트림 스테이지 스테이지의 작업자 노드들에 의해 수행될 수 있는 동작들의 측면들을 예시한다. 요소(2801)에 도시된 바와 같이, 작업자 노드 초기화 동안 또는 그것에 할당되는 분할들 중 하나의 폐쇄와 같은 다양한 트리거 조건에 응답하여, 작업자 노드(W1)는 최신 또는 현재 분할 리스트, 또는 활동 분할 리스트를 획득하기 위한 요청을 SMS 제어 서브 시스템에 제출할 수 있다. 몇몇 구현예에서, getStreamInfo 또는 유사한 API가 이러한 목적을 위해 호출될 수 있다. 다른 트리거 조건이 몇몇 실시예에서 사용될 수 있다: 예를 들어, 작업자 노드들은 랜덤한 시간의 양 이후, 또는 작업 부하 레벨들의 예기치 않은 하락 또는 증가에 응답하여 새로운 분할 리스트들을 획득하도록 각각 구성될 수 있다. SMS에 의해 리턴되는 분할 리스트는 분할을 위해 PA 테이블에서의 엔트리들과 비교될 수 있다(요소(2807)). 불일치가 발견되는 경우(예를 들어, PA 테이블에 있지 않은 새롭게 획득된 분할 리스트에 어떤 분할이 존재하는 경우, 또는 SMS의 리스트에 있지 않는 PA 테이블에서의 엔트리가 존재하는 경우), 작업자 노드는 도시된 실시예에서 불일치를 해결하기 위해 PA 테이블에 엔트리들을 삽입하거나 삭제할 수 있다(요소(2810)). (몇몇 구현예에서 현재 삭제의 목적이 되는 엔트리가 할당된 작업자 노드를 가지는 - 예를 들어, 할당된 작업자 노드가 직접 또는 PA 테이블 그 자체를 통해, 통지될 수 있는 경우 추가적인 조정이 요구될 수 있다.)

불일치가 교정된 후, 또는 어떤 불일치도 검출되지 않았던 경우, 작업자 노드(W1)는 그것이 스테이지의 프로세싱 동작들을 수행해야 하는 분할들의 세트를 선택할 수 있고(요소(2813)), 그에 따라 PA 테이블을 업데이트할 수 있다. 몇몇 경우에서, 검색된 분할 리스트를 초래한 트리거 조건에 따라, W1은 그것에 할당되는 하나 이상의 분할을 이미 가질 수 있고, 이의 할당들을 변경하거나 PA 테이블을 업데이트할 필요는 없을 수 있다. 그 후 W1은 SMS 제어 서브 시스템과 상호 작용하거나 PA 테이블에서의 엔트리들의 수를 변경하지 않고, 이의 할당된 분할 또는 분할들의 데이터 레코드들을 계속해서 검색하고, 레코드들을 프로세싱할 수 있다(요소(2816)). 결국에는, 트리거 조건이 검출될 때(예를 들어, "분할의 마지막에 이름" 응답의 균등물이 분할이 폐쇄되었다는 것을 나타내어, 검색 요청에 대해 수신될 때), W1은 새로운 분할 정보를 위한 요청을 SMS 제어 서브 시스템에 다시 송신할 수 있고, 요소들(2801 앞으로)의 동작들이 반복될 수 있다.

도 29는 적어도 몇몇 실시예에 따른, 스트림 프로세싱 스테이지의 작업자 노드들에 의해 수행될 수 있는 부하 균형 동작들의 측면들을 예시한다. 요소(2901)에 도시된 바와 같이, 작업자 노드(W1)는 부하 균형 분석이 높은 자원 이용 레벨의 검출과 같은, 다양한 트리거 조건 중 임의의 조건의 검출 시, 또는 구성 가능한 스케줄에 기초하여 이의 스테이지 상에서 수행될지를 결정할 수 있다. W1은 스테이지에 대한 다양한 작업 부하 메트릭스를 결정하기 위해 PA 테이블에서의 엔트리들을 검토할 수 있다(요소(2904)). 그러한 메트릭스는 작업자 노드들에 할당되는 분할들의 평균 수, 상이한 분할들 또는 작업자 노드들의 평균 작업 부하 레벨(작업 부하 레벨 표시자들이 테이블에 저장되는 실시예들에서), 작업자 노드 당 부하 로드의 범위 또는 분산 등을 포함할 수 있다.

그 후 W1은 메트릭스의 몇몇 또는 전부와 그 자체의 부하 로드(예를 들어 W1에 할당되는 분할들의 수, 및/또는 분할 당 부하 로드 레벨 표시자들에 기초한)를 비교할 수 있다. 일반적으로, 세 개의 유형의 결론 중 임의의 결론이 도출될 수 있다: W1은 과부하 상태이라는 것, W1은 부족-부하 상태라는 것, 또는 W1의 작업 부하는 높지도 낮지도 않다는 것. "너무 높거나" 또는 "너무 낮은" 작업 부하 레벨들은 몇몇 실시예에서 이들 대신 스테이지가 구성되는 클라이언트들에 의해, 또는 다른 실시예들에서 휴리스틱들의 어떤 디폴트 세트를 사용하여 선택되는 정책들에 의해 정의될 수 있다. W1이 이의 작업 부하가 너무 낮다고, 예를 들어, 어떤 최소-부하 임계(T1) 미만이라고 결정하는 경우(요소(2907)), 보다 바쁘거나 보다 높은 부하 상태의 작업자 노드(Wk)가 식별될 수 있다(요소(2910)). 그 후 W1은 예를 들어, PA 테이블에 Pm 엔트리를 변형하려고 시도하거나, 그러한 변형을 요청함으로써(Wk에 대해 생성되는 통지를 야기할 수 있는), 또는 직접 Wk를 요청함으로써, 하나 이상의 분할(Pm)을 Wk로부터 그 자체로 이동하는 프로세스를 개시할 수 있다(요소(2913)).

W1이 이의 작업 부하가 너무 높다고, 예를 들어, 어떤 최대-임계(T2) 초과라고 결정하는 경우(요소(2916)), 그것은 인도할(예를 들어, 다른 작업자 노드들에 의한 할당을 위해 방출할) 이의 할당된 분할들(Pn) 중 하나 이상을 식별될 수 있다(요소(2919)). 그 후 W1은 예를 들어, Pn에 대한 엔트리의 인수 컬럼으로부터 이의 식별자를 제거함으로써, PA 테이블에서의 적절한 엔트리들을 변형할 수 있다(요소(2922)). W1의 작업 부하가 너무 높지도 너무 낮지도 않은 경우, 또는 W1이 이의 작업 부하를 증가하거나 감소하기 위해 상기에서 설명된 것과 같은 액션들을 취한 후, W1은 그것이 할당되는 분할들의 레코드들을 프로세싱하는 것을 재개할 수 있다(요소(2925)). 요소들(2901 앞으로)에 대응하는 동작들은 다른 부하 균형 분석을 트리거하는 조건이 충족될 때 그리고 충족되는 경우 반복될 수 있다. 도 29에 예시된 동작들에서, W1은 그것이 단지 그 자체의 작업 부하에 대해 불균형을 검출할 때 작업 부하 변경들을 개시하는 것으로 도시된다는 것이 주목된다. 다른 실시예들에서, W1은 그것이 그 자체와 다른 작업자 노드들 중에서 불균형을 검출하는 경우 - 예를 들어, 그것이 W2가 W3보다 훨씬 더 낮은 작업 부하 레벨을 가진다고 결정하는 경우, 재균형 액션들을 개시할 수 있다. 몇몇 구현예에서, W1은 그것이 작업 부하 불균형을 검출하는 경우 및 검출할 때 동적 재분할을 요청하거나 개시할 수 있다(예를 들어, 도 3에 도시된 것과 같은 repartitionStream SMS API 또는 이의 균등물을 호출함으로써). 몇몇 실시예에서, 도 29에 예시된 이 같은 동작들이 새롭게 구성된 작업자 노드에 의해 수행될 수 있다 - 예를 들어, 스테이지가 일정 시간 동안 이미 작동 중에 있은 후 새로운 노드들이 스테이지에 추가될 때, 새로운 노드들은 과중한 부하 상태의 기존 노드들로부터의 분할들의 재할당을 요청함으로써 기존 노드들에 그것들의 존재를 간접적으로 통지할 수 있다. 몇몇 실시예에서, SPS 작업자 노드들에 대해 위에서 설명된 것들과 유사한 분산식 제어 기술들이 하나 이상의 SMS 서브 시스템에서 또한 또는 대신 사용될 수 있다 - 예를 들어, 수집, 저장, 또는 검색 서브 시스템들의 노드들이 PA 테이블들과 유사한 공유된 데이터 구조들을 사용하여 그것들의 작업 부하들을 조정할 수 있다.

다양한 실시예에서, 도 17 내지 도 24 및 도 27 내지 도 29의 흐름도들에서 예시된 것들과 다른 동작들 이 위에서 설명된 스트림 관리 서비스 및/또는 스트림 프로세싱 기능을 구현하기 위해 사용될 수 있다. 도시된 동작들 중 몇몇이 몇몇 실시예에서 구현되지 않을 수 있거나 상이한 순서로, 또는 순차적으로보다는 병렬로 구현될 수 있다. 프로그램 인터페이스들이 다양한 실시예에서 지원되는 SMS 및 SPS 기능들의 각각에 대해, 웹 페이지들, 웹 사이트들, 웹-서비스 API들, 다른 API들, 명령어-라인 도구들, 그래픽 유저 인터페이스들, 모바일 애플리케이션들(app들), 태블릿 app들 등의 사용을 포함하여, 하나 이상의 기술의 임의의 조합이 인터페이스들을 구현하기 위해 사용될 수 있다.

사례들

스트림 데이터 레코드들의 수집, 저장, 검색 및 단계별 프로세싱을 위한 가변 분할-기반의, 동적으로 구성 가능한 관리 멀티-테넌트 서비스들을 설정하는 것에 대해, 위에서 설명된 기술들이 다수의 시나리오에서 유용할 수 있다. 예를 들어, 대규모 제공자 네트워크들은 동시에 수천 클라이언트 중 수십 클라이언트를 위해 다수의 상이한 멀티-테넌트 또는 싱글-테넌트 서비스의 서비스 인스턴스들을 구현하는 수천 인스턴스 호스트를 포함할 수 있다. 다양한 인스턴스 및 호스트 상에 설치되는 모니터링 및/또는 과금 에이전트들은 수천 메트릭스 레코드를 빠르게 생성할 수 있으며, 이는 누적 과금 레코드들을 생성하기 위해, 제공자 네트워크의 데이터 센터들에 대한 효율적인 권한 설정 계획들을 결정하기 위해, 네트워크 공격들을 검출하기 위해, 그리고 기타를 위해 저장되고 분석되어야 할 수 있다. 모니터링 레코드들은 가변 수집 및 저장을 위해 SMS에 대한 입력 스트림을 형성할 수 있고 설명된 SPS 기술들은 수집된 메트릭스의 분석을 위해 구현될 수 있다. 유사하게, 많은 로그 소스(예를 들어, 분산된 애플리케이션들의 노드들로부터의 애플리케이션들 로그들, 또는 데이터 센터에서의 호스트들 또는 컴퓨트 인스턴스로부터의 시스템 로그들)로부터 다수의 로그 레코드를 수집 및 분석하기 위한 애플리케이션들은 SMS 및 SPS 기능을 또한 이용할 수 있을 수 있다. 적어도 몇몇 환경에서, SPS 프로세싱 동작들은 실시간 ETL(추출-변환-로딩) 프로세싱 동작(즉, 오프라인으로 변환을 수행하는 대신, 목적지로 로딩하기 위해 실시간으로 수신된 데이터 레코드들을 변환하는 동작), 또는 데이터 웨어하우스로의 삽입을 위한 데이터 레코드들의 변환을 포함할 수 있다. 실시간으로 데이터 웨어하우스로 데이터를 로딩하기 위해 SMS/SPS 조합을 사용하는 것은 데이터가 분석을 위해 웨어하우스로 삽입될 수 있기 전에, 하나 이상의 데이터 소스로부터 데이터를 클리닝(cleaning) 및 큐레이팅(curating)하기 위해 통상적으로 요구되는 지연들을 회피할 수 있다.

다수의 상이한 "빅 데이터" 애플리케이션은 SMS 및 SPS 기술들을 사용하여 또한 구축될 수 있다. 예를 들어, 소셜 미디어 상호 작용들의 다양한 형태인 트렌드들의 분석이 스트림들을 사용하여 효율적으로 수행될 수 있다. 사용자들의 위치 정보와 같은, 이동 전화들 또는 태블릿 컴퓨터들로부터 수집되는 데이터가 스트림 레코드들로서 관리될 수 있다. 예를 들어 전체 모니터링 카메라들로부터 수집되는, 오디오 또는 비디오 정보는 다양한 종류의 공격들을 방지하는 것을 잠재적으로 도우면서, 가변 방식으로 수집되고 프로세싱될 수 있는 스트리밍 데이터 세트의 다른 카테고리를 나타낼 수 있다. 예를 들어 날씨 위성들, 해양-기반 센서들, 삼림-기반 센서들, 천문학 망원경들로부터 수집되는, 계속 늘어나는 데이터 세트들의 분석을 필요로 하는 과학적 애플리케이션들이 본 출원에서 설명된 스트림 관리 및 프로세싱 역량들로부터 또한 이익을 얻을 수 있다. 유연한 정책-기반 구성 옵션들 및 가격 결정 옵션들은 상이한 유형들의 사용자들이 이들의 특정한 수요예측 및 데이터 내구성/이용 가능성 요건에 맞추기 위해 스트리밍 기능을 커스터마이징하게 할 수 있다.

본 발명의 실시예들은 다음 절들을 고려하여 설명될 수 있다:

1. 시스템으로서,

하나 이상의 컴퓨팅 디바이스로서:

멀티-테넌트 스트림 관리 서비스의 하나 이상의 제어 구성요소에 의해, (a) 레코드 수집 서브 시스템, (b) 레코드 저장 서브 시스템, 및 (c) 레코드 검색 서브 시스템의 노드들의 각각의 세트의 노드들의 각각의 세트를 결정하는 동작으로서, 하나 이상의 제어 구성요소는 하나 이상의 데이터 생성자에 의해 생성되는 복수의 데이터 레코드를 포함하고, 레코드 수집 서브 시스템, 레코드 저장 서브 시스템, 및 레코드 검색 서브 시스템의 각 서브 시스템은 분할 정책을 포함하는 하나 이상의 정책에 기초하여 하나 이상의 제어 구성요소에 의해 동적으로 구성 가능한 하나 이상의 노드를 포함하는, 상기 결정하는 동작;

하나 이상의 프로그램 레코드 제출 인터페이스를 통해 제출되는 데이터 레코드들을 수신하는 동작으로서, 하나 이상의 프로그램 레코드 제출 인터페이스는 데이터 레코드들의 인-라인 제출을 지원하는 제1 제출 인터페이스 및 데이터가 저장되는 네트워크 어드레스들에 대한 참조에 의한 데이터 레코드들의 제출을 가능하게 하는 제2 제출 인터페이스를 포함하는, 상기 데이터 레코드들을 수신하는 동작;

하나 이상의 프로그램 레코드 검색 인터페이스를 통해 수신되는 레코드 검색 요청들에 응답하여 데이터 레코드들의 콘텐츠를 제공하는 동작으로서, 하나 이상의 프로그램 레코드 검색 인터페이스는 비-순차적 액세스 패턴을 가능하게 하는 제1 검색 인터페이스 및 순차적 액세스 패턴을 가능하게 하는 제2 검색 인터페이스를 포함하고, 제1 검색 인터페이스의 사용과 연관되는 과금 비율은 제2 검색 인터페이스의 사용과 연관되는 과금 비율과 상이한, 상기 데이터 레코드들을 제공하는 동작;

복수의 레코드 검색 인터페이스 및 복수의 레코드 제출 인터페이스의 각각의 사용량 카운트 메트릭스에 적어도 부분적으로 기초하여 특정한 데이터 스트림과 연관된 클라이언트 과금액을 생성하는 동작을 수행하도록 구성되는, 상기 하나 이상의 컴퓨팅 디바이스를 포함하는, 시스템.

2. 절 1에 있어서, 하나 이상의 컴퓨팅 디바이스는:

분할 정책에 따라, 특정한 데이터 레코드와 연관되는 키에 적어도 부분적으로 기초하여, 특정한 데이터 스트림의 분할에 상기 특정한 데이터 스트림의 특정한 데이터 레코드를 할당하는 동작으로서, 키는 특정한 데이터 레코드에 대응하는 기록 요청에 의해 표시되는, 상기 특정한 데이터 레코드를 할당하는 동작을 수행하도록 더 구성되는, 시스템.

3. 절 1에 있어서, 하나 이상의 컴퓨팅 디바이스는:

특정한 데이터 레코드가 할당되는 부분에 적어도 부분적으로 기초하여, (a) 특정한 데이터 레코드를 수용하는 것에 대해 책임이 있는 레코드 수집 서브 시스템의 특정한 노드, (b) 특정한 데이터 레코드의 적어도 하나의 카피를 저장하는 것에 대해 책임이 있는 레코드 저장 서브 시스템의 특정한 노드, 및 (c) 판독 요청에 응답하여 레코드 저장 서브 시스템으로부터 특정한 데이터 레코드를 획득하는 것에 대해 책임이 있는 검색 서브 시스템의 특정한 노드 중 하나 이상을 선택하는 동작을 수행하도록 더 구성되는, 시스템.

4. 절 1에 있어서, 레코드 수집 서브 시스템, 레코드 저장 서브 시스템, 및 레코드 검색 서브 시스템 중 적어도 하나의 서브 시스템은 리던던시 그룹의 멤버들로서 하나 이상의 제어 구성요소에 의해 구성되는 복수의 노드를 포함하고, 리던던시 그룹은: (a) 데이터 레코드들의 세트에 대해 동작들을 수행하도록 할당되는 하나 이상의 주요 노드 및 (b) 하나 이상의 트리거 이벤트의 검출에 응답하여 주요 역할을 맡도록 구성되는 하나 이상의 비-주요 노드를 포함하는, 시스템.

5. 절 1에 있어서, 하나 이상의 컴퓨팅 디바이스는:

특정한 데이터 레코드에 대응하여, 특정한 데이터 레코드가 속하는 분할의 다른 데이터 레코드들에 관해 특정한 데이터 레코드가 레코드 수집 서브 시스템에 수신된 순서를 나타내는 특정한 시퀀스 번호를 생성하는 동작;

레코드 저장 서브 시스템에 의해, 데이터 레코드들을 위해 생성되는 각각의 시퀀스 번호들에 적어도 부분적으로 기초한 순서로 특정한 데이터 레코드를 포함하는 복수의 데이터 레코드를 저장하는 동작; 및

파라미터로서 특정한 시퀀스 번호를 이용하여 제1 검색 인터페이스를 호출하는 판독 요청에 응답하여, 레코드 저장 서브 시스템에서 상기 특정한 데이터 레코드를 검색하는 동작을 수행하도록 더 구성되는, 시스템.

6. 방법으로서,

하나 이상의 컴퓨팅 디바이스에 의해:

복수의 데이터 레코드를 포함하는 특정한 데이터 스트림을 위해, 하나 이상의 제어 구성요소에 의해 스트림 분할 정책을 포함하는 하나 이상의 정책에 기초하여 스트림 관리 동작들을 수행하도록 구성 가능한 노드들의 세트를 결정하는 단계;

하나 이상의 프로그램 레코드 검색 인터페이스를 통해 수신되는 레코드 검색 요청들에 응답하여 데이터 레코드들을 제공하는 단계로서, 상기 하나 이상의 프로그램 레코드 검색 인터페이스는 비-순차적 액세스 패턴을 가능하게 하는 제1 검색 인터페이스 및 순차적 액세스 패턴을 가능하게 하는 제2 검색 인터페이스를 포함하고, 상기 제1 검색 인터페이스의 사용과 연관되는 과금 비율은 상기 제2 검색 인터페이스의 사용과 연관되는 과금 비율과 상이한, 상기 데이터 레코드들을 제공하는 단계; 및

상기 복수의 레코드 검색 인터페이스의 각각의 사용량 카운트 메트릭스에 적어도 부분적으로 기초하여 상기 특정한 데이터 스트림과 연관된 클라이언트 과금액을 생성하는 단계를 수행하는 단계를 포함하는, 방법.

7. 절 6에 있어서, 하나 이상의 컴퓨팅 디바이스에 의해,

상기 분할 정책에 따라, 상기 특정한 데이터 레코드와 연관되는 키에 적어도 부분적으로 기초하여, 상기 특정한 데이터 스트림의 제1 부분에 상기 특정한 데이터 스트림의 특정한 데이터 레코드를 할당하는 단계로서, 상기 키는 상기 특정한 데이터 레코드에 대응하는 기록 요청에 의해 표시되는, 상기 특정한 데이터 레코드를 할당하는 단계를 수행하는 단계를 더 포함하는, 방법.

8. 절 6에 있어서, 하나 이상의 컴퓨팅 디바이스에 의해,

특정한 데이터 레코드가 할당되는 부분에 적어도 부분적으로 기초하여, (a) 상기 특정한 데이터 레코드를 수용하는 것에 대해 책임이 있는 레코드 수집 서브 시스템의 특정한 노드, (b) 상기 특정한 데이터 레코드의 적어도 하나의 카피를 저장하는 것에 대해 책임이 있는 레코드 저장 서브 시스템의 특정한 노드, 및 (c) 판독 요청에 응답하여 상기 레코드 저장 서브 시스템으로부터 상기 특정한 데이터 레코드를 획득하는 것에 대해 책임이 있는 검색 서브 시스템의 특정한 노드 중 하나 이상을 선택하는 단계를 수행하는 단계를 더 포함하는, 방법.

9. 절 6에 있어서, 하나 이상의 컴퓨팅 디바이스에 의해,

하나 이상의 프로그램 레코드 제출 인터페이스를 통해 제출되는 데이터 레코드들을 수신하는 단계로서, 상기 하나 이상의 프로그램 레코드 제출 인터페이스는 데이터 레코드들의 인-라인 제출을 지원하는 제1 제출 인터페이스 및 다음 중 하나에 대한 참조에 의한 데이터 레코드들의 제출을 가능하게 하는 제2 제출 인터페이스를 포함하는, 상기 데이터 레코드들을 수신하는 단계를 수행하는 단계를 더 포함하는, 방법: (a) 제공자 네트워크에 의해 구현되는 저장 서비스에서의 객체 어드레스 (b) 범용 레코드 지시기(universal record locator) (c) 데이터베이스 레코드.

10. 절 6에 있어서, 하나 이상의 컴퓨팅 디바이스에 의해,

데이터 저장 서브 시스템의 특정한 노드에서, 다음 중 하나에 적어도 부분적으로 기초하여 특정한 데이터 레코드를 제거하는 단계를 수행하는 단계를 더 포함하는, 방법: (a) 상기 특정한 데이터 스트림을 위해 구성되는 데이터 중복-제거 윈도우, (b) 상기 특정한 데이터 스트림과 연관된 데이터 아카이브 정책, (c) 클라이언트에 의해 표시되는 데이터 보유 정책, (d) 상기 특정한 데이터 레코드를 제거하기 위한 클라이언트 요청, 또는 (e) 상기 특정한 데이터 레코드가 하나 이상의 데이터 소비자에 의해 프로세싱되었다는 표시.

11. 절 6에 있어서, 다음: (a) 레코드 수집 서브 시스템, (b) 레코드 저장 서브 시스템, 또는 (c) 상기 특정한 데이터 스트림을 위해 구성되는 레코드 검색 서브 시스템 중 적어도 하나의 서브 시스템은 상기 하나 이상의 제어 구성요소에 의해 리던던시 그룹의 멤버들로서 구성되는 복수의 노드를 포함하고, 상기 리던던시 그룹은: (a) 상기 스트림의 데이터 레코드들의 세트 상에서 동작들을 수행하도록 할당되는 하나 이상의 주요 노드 및 (b) 하나 이상의 트리거 이벤트에 응답하여 주요 역할을 맡도록 구성되는 하나 이상의 비-주요 노드를 포함하는, 시스템.

12. 절 11에 있어서, 하나 이상의 주요 노드 중 특정한 주요 노드는 특정한 데이터 센터에서 인스턴스화되고, 하나 이상의 비-주요 노드 중 특정한 비-주요 노드는 상이한 데이터 센터에서 인스턴스화되는, 방법.

13. 절 11에 있어서, 하나 이상의 컴퓨팅 디바이스에 의해,

상기 하나 이상의 트리거 이벤트 중 트리거 이벤트를 검출하는 단계; 및

상기 하나 이상의 비-주요 노드 중 특정한 비-주요 노드에 상기 주요 역할을 맡도록 통지하는 단계를 수행하는 단계를 더 포함하는, 방법.

14. 절 6에 있어서, 하나 이상의 제어 구성요소는 특정한 데이터 스트림를 포함하는 하나 이상의 데이터 스트림 상의 제어-영역 동작들에 대한 요청들에 응답하도록 구성되는 주요 제어 노드, 및 하나 이상의 트리거 이벤트에 응답하여 주요 역할을 맡도록 구성되는 적어도 하나의 비-주요 제어 노드를 포함하여, 리던던시 그룹으로서 구성되는 복수의 제어 노드를 포함하는, 방법.

15. 절 6에 있어서, 하나 이상의 컴퓨팅 디바이스에 의해,

제공자 네트워크의 네트워크-액세스 가능한 데이터베이스에, 스트림 분할 정책에 따라 생성되는 분할 맵을 포함하는 상기 특정한 데이터 스트림의 메타데이터를 저장하는 단계; 및

레코드 검색 서브 시스템으로부터, 특정한 레코드 검색 요청에 응답하기 위해 상기 메타데이터에 액세스하는 단계를 수행하는 단계를 더 포함하는, 방법.

16. 절 6에 있어서, 하나 이상의 컴퓨팅 디바이스에 의해,

상기 데이터 스트림의 특정한 데이터 레코드에 대응하여, 상기 특정한 데이터 레코드가 속하는 상기 분할의 다른 데이터 레코드들에 관해 상기 특정한 데이터 레코드가 레코드 수집 서브 시스템에 수신된 순서를 나타내는 특정한 시퀀스 번호를 생성하는 단계;

레코드 저장 서브 시스템에 의해, 상기 데이터 레코드들을 위해 생성되는 각각의 타임 스탬프들에 적어도 부분적으로 기초한 순서로 상기 특정한 데이터 레코드를 포함하는 복수의 데이터 레코드를 저장하는 단계; 및

파라미터로서 상기 특정한 시퀀스 번호를 이용하여 상기 제1 검색 인터페이스를 호출하는 판독 요청을 수신하는 것에 응답하여, 상기 레코드 저장 서브 시스템에서 상기 특정한 데이터 레코드를 검색하는 단계를 수행하는 단계를 더 포함하는, 방법.

17. 절 6에 있어서, 노드들의 세트의 특정한 노드는 다음 중 하나를 포함하는 방법: (a) 제공자 네트워크에 구현되는 데이터베이스 서비스의 데이터베이스 테이블의 적어도 부분, 또는 (b) 제공자 네트워크에 구현되는 저장 서비스의 저장 객체의 적어도 부분.

18. 하나 이상의 프로세서 상에서 실행될 때 멀티-테넌트 스트림 관리 서비스의 제어 노드를 구현하는 프로그램 명령어들을 저장하는 비-일시적 컴퓨터 액세스-가능한 저장 매체로서, 제어 노드는:

하나 이상의 데이터 생성자에 의해 생성되는 복수의 데이터 레코드로 구성될 특정한 데이터 스트림을 초기화하기 위한 요청을 수신하는 동작;

상기 특정한 데이터 스트림과 연관된 분할 정책에 적어도 부분적으로 기초하여, 레코드 검색 서브 시스템을 포함하여, 상기 특정한 데이터 스트림을 위한 하나 이상의 서브 시스템을 구성하기 위해 사용될 하나 이상의 파라미터를 결정하는 동작으로서, 상기 하나 이상의 파라미터는 상기 레코드 검색 서브 시스템에서 인스턴스화될 초기 수의 노드를 포함하는; 상기 하나 이상의 파라미터를 결정하는 동작;

상기 레코드 검색 서브 시스템의 특정한 노드를 위해 사용될 하나 이상의 자원을 식별하는 동작으로서, 상기 특정한 노드는 비-순차적 액세스 패턴을 가능하게 하는 제1 검색 인터페이스 및 순차적 액세스 패턴을 가능하게 하는 제2 검색 인터페이스를 포함하여, 복수의 프로그램 레코드 검색 인터페이스를 구현하도록 구성되어야 하는, 상기 하나 이상의 자원을 식별하는 동작; 및

상기 하나 이상의 자원을 사용하여 상기 레코드 검색 서브 시스템의 상기 특정한 노드를 구성하는 동작을 수행하도록 구성되는, 시스템.

19. 절 18에 있어서, 하나 이상의 서브 시스템은 특정한 데이터 스트림의 데이터 레코드들을 수신하도록 구성 가능한 하나 이상의 노드를 포함하는 레코드 수집 서브 시스템, 및 저장 위치들의 선택된 세트에 스트림의 데이터 레코드들을 저장하도록 구성 가능한 레코드 저장 서브 시스템을 포함하는, 비-일시적 컴퓨터 액세스-가능한 저장 매체.

20. 절 19에 있어서, 레코드 수집 서브 시스템, 레코드 저장 서브 시스템, 및 레코드 검색 서브 시스템 중 적어도 하나의 서브 시스템은 리던던시 그룹의 멤버들로서 구성되는 복수의 노드를 포함하고, 리던던시 그룹은: (a) 상기 스트림의 데이터 레코드들의 세트에 대해 동작들을 수행하도록 할당되는 하나 이상의 주요 노드 및 (b) 하나 이상의 트리거 이벤트에 응답하여 주요 역할을 맡도록 구성되는 하나 이상의 비-주요 노드를 포함하는, 시스템.

21. 절 19에 있어서, 다음: 상기 레코드 수집 서브 시스템, 상기 레코드 저장 서브 시스템 또는 상기 레코드 검색 서브 시스템 중 하나의 적어도 하나의 노드는 제공자 네트워크에서 구현되는 가상화된 컴퓨팅 서비스의 컴퓨트 인스턴스의 구성요소를 포함하는, 시스템.

22. 절 19에 있어서, 하나 이상의 데이터 생성자는 다음 중 하나 이상을 포함하는, 비-일시적 컴퓨터 액세스-가능한 저장 매체: (a) 컴퓨팅 디바이스의 로깅 구성요소, (b) 소셜 미디어 애플리케이션, (c) 컴퓨팅 디바이스에서의 모니터링 에이전트, (d) 센서 디바이스, (e) 이동 전화, 또는 (f) 태블릿 컴퓨터.

예시적인 컴퓨터 시스템

적어도 몇몇 실시예에서, SMS 서브 시스템들(예를 들어, 수집, 저장, 검색 및 제어 서브 시스템들)의 구성요소들, 뿐만 아니라 SPS 작업자 및 제어 노드들을 구현하기 위한 기술들을 포함하여, 본 출원에서 설명된 기술들 중 하나 이상 중 부분 또는 전부를 구현하는 서버는, 하나 이상의 컴퓨터 액세스-가능한 매체를 포함하거나 이들에 액세스하도록 구성되는 범용 컴퓨터 시스템을 포함할 수 있다. 도 30은 그러한 범용 컴퓨팅 디바이스(9000)를 예시한다. 예시된 실시예에서, 컴퓨팅 디바이스(9000)는 입력/출력(I/O) 인터페이스(9030)를 통해 시스템 메모리(9020)에 연결되는 하나 이상의 프로세서(9010)를 포함한다. 컴퓨팅 디바이스(9000)는 I/O 인터페이스(9030)에 연결되는 네트워크 인터페이스(9040)를 더 포함한다.

다양한 실시예에서, 컴퓨터 디바이스(9000)는 하나의 프로세서(9010)를 포함하는 단일 프로세서 시스템, 또는 몇몇(예를 들어, 2, 4, 8, 또는 다른 적합한 수의) 프로세서(9010)를 포함하는 멀티 프로세서 시스템일 수 있다. 프로세서들(9010)은 기존 명령어들이 가능한 임의의 적합한 프로세서들일 수 있다. 예를 들어, 다양한 실시예에서, 프로세서들(9010)은 x86, PowerPC, SPARC, 또는 MIPS ISA들, 또는 임의의 다른 적합한 ISA와 같은, 다양한 명령어 세트 아키텍처(ISA) 중 임의의 아키텍처를 구현하는 범용 또는 내장 프로세서들일 수 있다. 멀티 프로세서 시스템들에서, 프로세서들(9010)의 각각은 반드시는 아니나, 통상적으로 동일한 ISA를 구현할 수 있다. 몇몇 구현예에서, 그래픽 프로세싱 유닛들(GPU들)은 종래의 프로세서들 대신, 또는 이들에 추가하여, 사용될 수 있다.

시스템 메모리(9020)는 프로세서(들)(9010)에 의해 액세스 가능한 명령어들 및 데이터를 저장하도록 구성될 수 있다. 다양한 실시예에서, 시스템 메모리(9020)는 정적 랜덤 액세스 메모리(SRAM), 동기식 동적 RAM(SDRAM), 비휘발성/플래시-타입 메모리, 임의의 다른 유형의 메모리와 같은, 임의의 적합한 메모리 기술을 사용하여 구현될 수 있다. 예시된 실시예에서, 위에서 설명된 그것들의 방법들, 기술들, 및 데이터와 같은, 하나 이상의 원하는 기능을 구현하는 프로그램 명령어들 및 데이터 는 코드(9025) 및 데이터(9026)로서 시스템 메모리(9020) 내에 저장되는 것으로 도시된다.

일 실시예에서, I/O 인터페이스(9030)는 프로세서(9010), 시스템 메모리(9020), 및 네트워크 인터페이스(9040) 또는 데이터 객체 분할들의 물리적 복제본들을 저장하기 위해 사용되는 다양한 유형의 영속적 및/또는 휘발성 저장 디바이스와 같은 다른 주변 인터페이스들을 포함하는, 디바이스에서의 임의의 주변 디바이스들 간 I/O 트래픽을 조정하도록 구성될 수 있다. 몇몇 실시예에서, I/O 인터페이스(9030)는 데이터 신호들을 하나의 구성요소(예를 들어, 시스템 메모리(9020))로부터 다른 구성요소(예를 들어, 프로세서(9010))에 의해 사용하기에 적합한 포맷으로 변환하기 위한 임의의 필요한 프로토콜, 타이밍, 또는 다른 데이터 변환들을 수행할 수 있다. 몇몇 실시예에서, I/O 인터페이스(9030)는 예를 들어, 주변 구성요소 상호연결(PCI) 버스 표준 또는 범용 직렬 버스(USB) 표준의 변형과 같은, 다양한 유형의 주변 버스들을 통해 연결되는 디바이스들에 대한 지원을 포함할 수 있다. 몇몇 실시예에서, I/O 인터페이스(9030)의 기능은 예를 들어, 노스 브리지(north bridge) 및 사우스 브리지(south bridge)와 같은, 두 개 이상의 개별 구성요소로 분할될 수 있다. 또한, 몇몇 실시예에서 시스템 메모리(9020)에 대한 인터페이스와 같은, I/O 인터페이스(9030)의 기능의 일부 또는 전부는 프로세서(9010)로 직접적으로 통합될 수 있다.

네트워크 인터페이스(9040)는 예를 들어, 도 1 내지 도 29에 예시된 바와 같은 다른 컴퓨터 시스템들 또는 디바이스들과 같은, 네트워크 또는 네트워크들(9050)에 연결되는 컴퓨팅 디바이스(9000) 및 다른 디바이스들(9060) 사이에서 데이터가 교환되게 하도록 구성될 수 있다. 다양한 실시예에서, 네트워크 인터페이스(9040)는 예를 들어, 이더넷 네트워크의 유형들과 같은, 임의의 적합한 유선 또는 무선의 일반적인 데이터 네트워크들을 통해 통신을 지원할 수 있다. 추가적으로, 네트워크 인터페이스(9040)는 아날로그 음성 네트워크들 또는 디지털 파이버 통신 네트워크들과 같은 전화통신/전화기 네트워크들을 통해, 파이버 채널 SAN들과 같은 저장 영역 네트워크들을 통해, 또는 임의의 다른 적합한 유형의 네트워크 및/또는 프로토콜을 통해 통신을 지원할 수 있다.

몇몇 실시예에서, 시스템 메모리(9020)는 대응하는 방법들 및 장치의 실시예들을 구현하기 위해 도 1 내지 도 29에 대해 위에서 설명된 바와 같은 프로그램 명령어들 및 데이터를 저장하도록 구성되는 컴퓨터-액세스 가능한 매체의 일 실시예일 수 있다. 그러나, 다른 실시예들에서, 프로그램 명령어들 및/또는 데이터는 상이한 유형들의 컴퓨터-액세스 가능한 매체 상에 수신, 송신 또는 저장될 수 있다. 일반적으로 말해서, 컴퓨터-액세스 가능한 매체는 I/O 인터페이스(9030)를 통해 컴퓨팅 디바이스(9000)에 연결되는 자기 또는 광 매체들, 예를 들어, 디스크 또는 DVD/CD와 같은 비-일시적 저장 미디어 또는 메모리 미디어를 포함할 수 있다. 비-일시적 컴퓨터 액세스-가능한 저장 매체는 또한 시스템 메모리(9020) 또는 다른 유형의 메모리로서 컴퓨팅 디바이스(9000)의 몇몇 실시예에 포함될 수 있는, RAM(예를 들어 SDRAM, DDR SDRAM, RDRAM, SRAM 등), ROM 등과 같은 임의의 휘발성 또는 비-휘발성 매체를 포함할 수 있다. 또한, 컴퓨터-액세스 가능한 매체는 네트워크 인터페이스(9040)를 통해 구현될 수 있는 바와 같은, 네트워크 및/또는 무선 링크와 같은 통신 매체를 통해 전달되는, 전기, 전자기, 또는 디지털 신호들과 같은 신호들 또는 전송 매체를 포함할 수 있다. 도 30에 예시되는 것과 같은 다수의 컴퓨팅 디바이스의 부분들 또는 전부는 다양한 실시예에서 설명된 기능성을 구현하기 위해 사용될 수 있다: 예를 들어, 다양한 상이한 디바이스 및 서버 상에서 실행하는 소프트웨어 구성요소들이 기능성을 제공하기 위해 협력할 수 있다. 몇몇 실시예에서, 설명된 기능성의 부분들은 저장 디바이스들, 네트워크 디바이스들, 또는 범용 컴퓨터 시스템들을 사용하여 구현되는 것에 추가하여 또는 그 대신, 전용 컴퓨터 시스템들을 사용하여 구현될 수 있다. 용어 "컴퓨팅 디바이스"는, 본 출원에서 사용된 바와 같이, 적어도 모든 이들 유형의 디바이스들을 나타내고, 이들 유형의 디바이스들에 제한되지는 않는다.

결론

다양한 실시예는 컴퓨터 액세스-가능한 매체에 대한 상기한 설명에 따라 구현되는 명령어들 및/또는 데이터를 수신, 송신 또는 저장하는 것을 더 포함할 수 있다. 일반적으로 말해서, 컴퓨터 액세스-가능한 저장 매체는 자기 또는 광 미디어, 예를 들어, 디스크 또는 DVD/CD-ROM과 같은 저장 매체 또는 메모리 매체, RAM(예를 들어 SDRAM, DDR, RDRAM, SRAM 등), ROM 등과 같은 휘발성 또는 비-휘발성 매체, 뿐만 아니라 네트워크 및/또는 무선 링크와 같은 통신 매체를 통해 전달되는, 전기, 전자기, 또는 디지털 신호들과 같은 신호들 또는 전송 매체를 포함할 수 있다.

도면들에서 예시되고 본 출원에서 설명된 바와 같은 다양한 방법들은 방법들의 대표적인 실시예들을 나타낸다. 방법들은 소프트웨어에서, 하드웨어에서, 또는 이들의 조합으로 구현될 수 있다. 방법의 순서는 변경될 수 있고, 다양한 요소들이 추가, 재순서화, 결합, 생략, 변형 등이 될 수 있다.

다양한 변형 및 변경이 본 개시 내용의 혜택을 가지고 해당 기술분야의 통상의 기술자에게 명백할 수 있는 바와 같이 이루어질 수 있다. 모든 그러한 변형 및 변경을 포함하도록, 그리고 그에 따라, 상기한 설명이 한정적인 의미보다는 예시적인 의미로 간주되도록 의도된다.

Claims (15)

1. 방법으로서,
   하나 이상의 컴퓨팅 디바이스에 의해:
   복수의 데이터 레코드를 포함하는 특정한 데이터 스트림을 위해, 하나 이상의 제어 구성요소에 의해 스트림 분할 정책을 포함하는 하나 이상의 정책에 기초하여 스트림 관리 동작들을 수행하도록 구성 가능한 노드들의 세트를 결정하는 단계;
   하나 이상의 프로그램 레코드 검색 인터페이스를 통해 수신되는 레코드 검색 요청들에 응답하여 데이터 레코드들을 제공하는 단계로서, 상기 하나 이상의 프로그램 레코드 검색 인터페이스는 비-순차적 액세스 패턴을 가능하게 하는 제1 검색 인터페이스 및 순차적 액세스 패턴을 가능하게 하는 제2 검색 인터페이스를 포함하고, 상기 제1 검색 인터페이스의 사용과 연관된 과금 비율은 상기 제2 검색 인터페이스의 사용과 연관된 과금 비율과 상이한, 상기 데이터 레코드들을 제공하는 단계; 및
   복수의 상기 레코드 검색 인터페이스의 각각의 사용량 카운트 메트릭스에 적어도 부분적으로 기초하여 상기 특정한 데이터 스트림과 연관된 클라이언트 과금액을 생성하는 단계를 수행하는 단계를 포함하는, 방법.
2. 청구항 1에 있어서, 상기 하나 이상의 컴퓨팅 디바이스에 의해:
   상기 분할 정책에 따라, 상기 특정한 데이터 레코드와 연관된 키에 적어도 부분적으로 기초하여, 상기 특정한 데이터 스트림의 제1 분할에 상기 특정한 데이터 스트림의 특정한 데이터 레코드를 할당하는 단계를 수행하는 단계를 더 포함하고, 상기 키는 상기 특정한 데이터 레코드에 대응하는 기록 요청에 의해 표시되는, 방법.
3. 청구항 1에 있어서, 상기 하나 이상의 컴퓨팅 디바이스에 의해:
   특정한 데이터 레코드가 할당되는 분할에 적어도 부분적으로 기초하여, (a) 상기 특정한 데이터 레코드를 수용하는 것에 대해 책임이 있는 레코드 수집 서브 시스템의 특정한 노드, (b) 상기 특정한 데이터 레코드의 적어도 하나의 카피를 저장하는 것에 대해 책임이 있는 레코드 저장 서브 시스템의 특정한 노드, 및 (c) 판독 요청에 응답하여 상기 레코드 저장 서브 시스템으로부터 상기 특정한 데이터 레코드를 획득하는 것에 대해 책임이 있는 검색 서브 시스템의 특정한 노드 중 하나 이상을 선택하는 단계를 수행하는 단계를 더 포함하는, 방법.
4. 청구항 1에 있어서, 상기 하나 이상의 컴퓨팅 디바이스에 의해:
   하나 이상의 프로그램 레코드 제출 인터페이스를 통해 제출되는 데이터 레코드들을 수신하는 단계를 수행하는 단계를 더 포함하고, 상기 하나 이상의 프로그램 레코드 제출 인터페이스는 데이터 레코드들의 인-라인 제출을 지원하는 제1 제출 인터페이스 및 다음: (a) 제공자 네트워크에 의해 구현되는 저장 서비스에서의 객체 어드레스 (b) 범용 레코드 지시기(universal record locator) (c) 데이터베이스 레코드 중 하나에 대한 참조에 의한 데이터 레코드들의 제출을 가능하게 하는 제2 제출 인터페이스를 포함하는, 방법 .
5. 청구항 1에 있어서, 상기 하나 이상의 컴퓨팅 디바이스에 의해:
   데이터 저장 서브 시스템의 특정한 노드에서, 다음: (a) 상기 특정한 데이터 스트림을 위해 구성되는 데이터 중복-제거 윈도우, (b) 상기 특정한 데이터 스트림과 연관된 데이터 아카이브 정책, (c) 클라이언트에 의해 표시되는 데이터 유지 정책, (d) 상기 특정한 데이터 레코드를 제거하기 위한 클라이언트 요청, 또는 (e) 상기 특정한 데이터 레코드가 하나 이상의 데이터 소비자에 의해 프로세싱되었다는 표시 중 하나에 적어도 부분적으로 기초하여 특정한 데이터 레코드를 제거하는 단계를 수행하는 단계를 더 포함하는, 방법.
6. 청구항 1에 있어서, (a) 레코드 수집 서브 시스템, (b) 레코드 저장 서브 시스템, 또는 (c) 상기 특정한 데이터 스트림을 위해 구성되는 레코드 검색 서브 시스템 중 적어도 하나의 서브 시스템은 상기 하나 이상의 제어 구성요소에 의해 리던던시 그룹의 멤버들로서 구성되는 복수의 노드를 포함하고, 상기 리던던시 그룹은: (a) 상기 스트림의 데이터 레코드들의 세트에 대해 동작들을 수행하도록 할당되는 하나 이상의 주요 노드 및 (b) 하나 이상의 트리거 이벤트에 응답하여 주요 역할을 맡도록 구성되는 하나 이상의 비-주요 노드를 포함하는, 방법.
7. 청구항 6에 있어서, 상기 하나 이상의 주요 노드 중 특정한 주요 노드는 특정한 데이터 센터에서 인스턴스화되고, 상기 하나 이상의 비-주요 노드 중 특정한 비-주요 노드는 상이한 데이터 센터에서 인스턴스화되는, 방법.
8. 청구항 6에 있어서, 상기 하나 이상의 컴퓨팅 디바이스에 의해:
   상기 하나 이상의 트리거 이벤트 중 트리거 이벤트를 검출하는 단계; 및
   상기 하나 이상의 비-주요 노드 중 특정한 비-주요 노드에 상기 주요 역할을 맡도록 통지하는 단계를 수행하는 단계를 더 포함하는, 방법.
9. 청구항 1에 있어서, 상기 하나 이상의 제어 구성요소는 상기 특정한 데이터 스트림을 포함하는 하나 이상의 데이터 스트림 상의 제어-영역 동작들에 대한 요청들에 응답하도록 구성되는 주요 제어 노드, 및 하나 이상의 트리거 이벤트에 응답하여 주요 역할을 맡도록 구성되는 적어도 하나의 비-주요 제어 노드를 포함하여, 리던던시 그룹으로서 구성되는 복수의 제어 노드를 포함하는, 방법.
10. 청구항 1에 있어서, 상기 하나 이상의 컴퓨팅 디바이스에 의해:
    제공자 네트워크의 네트워크-액세스 가능한 데이터베이스에, 스트림 분할 정책에 따라 생성되는 분할 맵을 포함하는 상기 특정한 데이터 스트림의 메타데이터를 저장하는 단계; 및
    레코드 검색 서브 시스템으로부터, 특정한 레코드 검색 요청에 응답하기 위해 상기 메타데이터에 액세스하는 단계를 수행하는 단계를 더 포함하는, 방법.
11. 청구항 1에 있어서, 상기 하나 이상의 컴퓨팅 디바이스에 의해:
    상기 데이터 스트림의 특정한 데이터 레코드에 대응하여, 상기 특정한 데이터 레코드가 속하는 상기 분할의 다른 데이터 레코드들에 관해 상기 특정한 데이터 레코드가 레코드 수집 서브 시스템에 수신된 순서를 나타내는 특정한 시퀀스 번호를 생성하는 단계;
    레코드 저장 서브 시스템에 의해, 상기 데이터 레코드들을 위해 생성되는 각각의 타임 스탬프들에 적어도 부분적으로 기초한 순서로 상기 특정한 데이터 레코드를 포함하는 복수의 데이터 레코드를 저장하는 단계; 및
    파라미터로서 상기 특정한 시퀀스 번호를 이용하여 상기 제1 검색 인터페이스를 호출하는 판독 요청을 수신하는 것에 응답하여, 상기 레코드 저장 서브 시스템에서 상기 특정한 데이터 레코드를 검색하는 단계를 수행하는 단계를 더 포함하는, 방법.
12. 하나 이상의 프로세서 및 하나 이상의 메모리를 포함하는 시스템으로서, 상기 하나 이상의 메모리는 하나 이상의 프로세서 상에서 실행될 때 멀티-테넌트 스트림 관리 서비스의 제어 노드를 구현하는 프로그램 명령들을 포함하고, 상기 제어 노드는:
    하나 이상의 데이터 생성자에 의해 생성되는 복수의 데이터 레코드로 구성될 특정한 데이터 스트림을 초기화하기 위한 요청을 수신하고;
    상기 특정한 데이터 스트림과 연관된 분할 정책에 적어도 부분적으로 기초하여, 레코드 검색 서브 시스템을 포함하여, 상기 특정한 데이터 스트림을 위한 하나 이상의 서브 시스템을 구성하기 위해 사용될 하나 이상의 파라미터를 결정하되, 상기 하나 이상의 파라미터는 상기 레코드 검색 서브 시스템에서 인스턴스화될 노드들의 초기 수를 포함하는, 상기 하나 이상의 파라미터를 결정하고;
    상기 레코드 검색 서브 시스템의 특정한 노드를 위해 사용될 하나 이상의 자원을 식별하되, 상기 특정한 노드는 비-순차적 액세스 패턴을 가능하게 하는 제1 검색 인터페이스 및 순차적 액세스 패턴을 가능하게 하는 제2 검색 인터페이스를 포함하여, 복수의 프로그램 레코드 검색 인터페이스를 구현하도록 구성될, 상기 하나 이상의 자원을 식별하며; 그리고
    상기 하나 이상의 자원을 사용하여 상기 레코드 검색 서브 시스템의 상기 특정한 노드를 구성하도록 구성되는, 시스템.
13. 청구항 12에 있어서, 상기 하나 이상의 서브 시스템은 상기 특정한 데이터 스트림의 데이터 레코드들을 수신하도록 구성 가능한 하나 이상의 노드를 포함하는 레코드 수집 서브 시스템, 및 저장 위치들의 선택된 세트에 상기 스트림의 데이터 레코드들을 저장하도록 구성 가능한 레코드 저장 서브 시스템을 포함하는, 시스템.
14. 청구항 13에 있어서, 상기 레코드 수집 서브 시스템, 상기 레코드 저장 서브 시스템, 및 상기 레코드 검색 서브 시스템 중 적어도 하나의 서브 시스템은 리던던시 그룹의 멤버들로서 구성되는 복수의 노드를 포함하고, 상기 리던던시 그룹은: (a) 상기 스트림의 데이터 레코드들의 세트에 대해 동작들을 수행하도록 할당되는 하나 이상의 주요 노드 및 (b) 하나 이상의 트리거 이벤트에 응답하여 주요 역할을 맡도록 구성되는 하나 이상의 비-주요 노드를 포함하는, 시스템.
15. 청구항 13에 있어서, 다음: 상기 레코드 수집 서브 시스템, 상기 레코드 저장 서브 시스템 또는 상기 레코드 검색 서브 시스템 중 하나의 적어도 하나의 노드는 제공자 네트워크에서 구현되는 가상화된 컴퓨팅 서비스의 컴퓨트 인스턴스의 구성요소를 포함하는, 시스템.

Images