JP2016541081A - データストリームのためのクライアント構成可能なセキュリティオプション - Google Patents

データストリームのためのクライアント構成可能なセキュリティオプション Download PDF

Info

Publication number
JP2016541081A
JP2016541081A JP2016553272A JP2016553272A JP2016541081A JP 2016541081 A JP2016541081 A JP 2016541081A JP 2016553272 A JP2016553272 A JP 2016553272A JP 2016553272 A JP2016553272 A JP 2016553272A JP 2016541081 A JP2016541081 A JP 2016541081A
Authority
JP
Japan
Prior art keywords
data
node
stream
nodes
client
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2016553272A
Other languages
English (en)
Other versions
JP6250189B2 (ja
Inventor
サイマー，マーヴィン・マイケル
ガーレ，ガウラヴ・ディ
デュナガン，ジョン・デイヴィッド
バージェス，グレッグ
ション，イン
Original Assignee
アマゾン・テクノロジーズ・インコーポレーテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by アマゾン・テクノロジーズ・インコーポレーテッド filed Critical アマゾン・テクノロジーズ・インコーポレーテッド
Publication of JP2016541081A publication Critical patent/JP2016541081A/ja
Application granted granted Critical
Publication of JP6250189B2 publication Critical patent/JP6250189B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1027—Persistence of sessions during load balancing

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

特定のデータストリームのために選択されるセキュリティオプションを含む構成要求が受信される。データ採集カテゴリおよびデータ検索カテゴリなどの複数の機能カテゴリのノードがストリームのために構成される。セキュリティオプションは、少なくとも１つの機能カテゴリのノードのために利用されるリソースのセキュリティプロファイルを示す。構成要求に従って、第１の機能カテゴリのノードが、第１のセキュリティプロファイルを有するデータリソースにおいて構成され、第２の機能カテゴリのノードの構成が、異なるセキュリティプロファイルを有する異なるリソースにおいて起動される。【選択図】図１１

Description

データ記憶のコストが長年にわたって低下し、計算インフラストラクチャの様々な要素を相互接続する能力が向上するにつれて、多種多様なアプリケーションに関連するますます多くのデータが収集され、分析される可能性が出てきた。例えば、携帯電話はその位置や電話ユーザが利用するアプリケーションなどを示すデータを生成することができ、カスタマイズしたクーポン、広告などをユーザに提示するためにその少なくとも一部を収集し、分析することが可能である。監視カメラから収集されたデータの分析は、犯罪の抑止、及び／または解決に役立つ可能性があり、また航空機のエンジン、自動車または複雑な機械の内部の様々な位置に組み込まれたセンサーから収集されるデータは、予防保守、効率性の向上やコストの低減などの様々な目的で利用することができる。
コモディティハードウェアの利用の増加に伴い、ストリーミングデータ量が増加している（また、場合によっては増加が可能となっている）。コモディティハードウェアのための仮想化技術の出現によって様々な計算リソースを効率的かつ確実に複数の顧客によって共有することが可能になり、多くの種類のアプリケーションのための大規模計算リソースの管理に関して利点がもたらされている。例えば、単一の物理計算機によりホスティングされ、かつ、そのそれぞれが、自身が所定のハードウェア計算リソースの唯一の操作者および管理者であるかのような錯覚をユーザに与える個別の論理計算システムとして作動するソフトウェアシミュレーションである１つ以上の仮想マシンを各ユーザに提供することができる。また一方で、様々な仮想マシンの間でアプリケーションを隔離させてセキュリティを提供することで、仮想化技術は単一の物理計算機を複数のユーザ間で共有させることができる。さらに、いくつかの仮想化技術により、複数の個別の物理計算システムに及ぶ複数の仮想プロセッサを有する単一の仮想マシンなどの、２つ以上の物理リソースに及ぶ仮想リソースの提供が可能である。計算プラットフォームに加えて、いくつかの大規模な組織も仮想化技術を利用して構築された様々な種類の記憶サービスを提供する。そのような記憶サービスを利用して、大量のデータを所望の持続性レベルで記憶させることができる。
様々なプロバイダからの比較的コストの低い仮想化された計算、及び／または記憶リソースが利用可能であるにもかかわらず、動的に変動する大規模なデータストリームの収集、記憶および処理の管理および統合は、様々な理由から、依然として困難な課題である。大規模なデータストリームの処理のために設定されたシステムにより多くのリソースが追加されるにつれ、例えば、システムの異なる部分の間で作業負荷の不均衡が生じる可能性がある。この状況を放置すると、他のリソースの未活用（およびそれによる浪費）に加えて、そのような不均衡がいくつかのリソースにおける重大な性能問題につながる可能性がある。またクライアントのストリーミングデータまたはストリーミングデータの分析結果が、クライアントが制御していない設備において記憶されている場合に、クライアントがそのようなデータまたは結果のセキュリティに関して懸念を抱く可能性もある。分散したシステムの規模が大きくなるにつれて必然的に発生頻度が高まる傾向にある、時折起こる接続の喪失、及び／またはハードウェアの故障などの障害についてはまた、費用が掛かるストリームデータの収集、記憶または分析の中断を防止するために、効果的に対処しなければならない可能性がある。
少なくともいくつかの実施形態による、データストリームの概念の簡便な概要を示している。 少なくともいくつかの実施形態による、ストリーム管理システム（ＳＭＳ）およびストリーム処理ステージの収集を含むストリーム処理システム（ＳＰＳ）の様々なサブコンポーネントの間のデータの流れの概要を示している。 少なくともいくつかの実施形態による、ＳＭＳおよびＳＰＳに実装されてもよいそれぞれのプログラムインターフェイス群の実施例を説明する。 少なくともいくつかの実施形態による、ＳＰＳクライアントによるストリーム処理ステージのグラフの生成を可能にするために実装されてもよい、ウェブベースのインターフェイスの実施例を説明する。 少なくともいくつかの実施形態による、ＳＭＳに実装されてもよいプログラムレコード送信インターフェイスおよびレコード検索インターフェイスの実施例を説明する。 少なくともいくつかの実施形態による、ＳＭＳの採集サブシステムの例示的な要素を説明する。 少なくともいくつかの実施形態による、ＳＭＳの記憶サブシステムの例示的な要素を説明する。 少なくともいくつかの実施形態による、ＳＭＳの検索サブシステムの例示的な要素および検索サブシステムのＳＰＳとの対話の実施例を説明する。 少なくともいくつかの実施形態による、ＳＭＳまたはＳＰＳのノードのために設定されてもよい冗長グループの実施例を説明する。 少なくともいくつかの実施形態による、所定の冗長グループのノードが複数のデータセンターの間で分散されてもよいプロバイダーネットワーク環境を説明する。 少なくともいくつかの実施形態による、ＳＭＳまたはＳＰＳのノードのために選択されてもよい複数の配置先を説明する。 少なくともいくつかの実施形態による、ＳＰＳクライアントおよびＳＭＳクライアントによってそれぞれ送信されてもよいセキュリティオプション要求の実施例を説明する。 少なくともいくつかの実施形態による、ストリームデータプロデューサとＳＭＳの採集ノードとの間の対話の実施例を説明する。 少なくともいくつかの実施形態による、採集されたデータレコードのためにＳＭＳにおいて生成されてもよいシーケンス番号の例示的な要素を説明する。 少なくともいくつかの実施形態による、ＳＭＳにおけるストリームデータレコードの順序付けられた記憶および検索の実施例を説明する。 少なくともいくつかの実施形態による、ストリームのパーティションマッピングならびに、ＳＭＳおよびＳＰＳノードのために行われてもよい対応する構成決定の実施例を説明する。 少なくともいくつかの実施形態による、動的ストリーム再分割の実施例を説明する。 少なくともいくつかの実施形態による、ストリームレコード採集およびストリームレコード検索のためのそれぞれのプログラムインターフェイス群をサポートするために実行されてもよい操作の態様を説明する流れ図である。 少なくともいくつかの実施形態による、ストリーム処理ステージを構成するために実行されてもよい操作の態様を説明する流れ図である。 少なくともいくつかの実施形態による、ストリーム処理ワーカーノードの構成のためのクライアントライブラリのコンポーネントの呼び出しに応じて実行されてもよい操作の態様を説明する流れ図である。 少なくともいくつかの実施形態による、ストリーム処理のための１つ以上の回復ポリシーを実装するために実行されてもよい操作の態様を説明する流れ図である。 少なくともいくつかの実施形態による、データストリームのための複数のセキュリティオプションを実装するために実行されてもよい操作の態様を説明する流れ図である。 少なくともいくつかの実施形態による、データストリームのための分割ポリシーを実装するために実行されてもよい操作の態様を説明する流れ図である。 少なくともいくつかの実施形態による、データストリームの動的再分割を実装するために実行されてもよい操作の態様を説明する流れ図である。 少なくともいくつかの実施形態による、データストリームレコードのための少なくとも１回のレコード採集ポリシーを実装するために実行されてもよい操作の態様を説明する流れ図である。 少なくともいくつかの実施形態による、データストリームのための複数の永続性ポリシーを実装するために実行されてもよい操作の態様を説明する流れ図である。 少なくともいくつかの実施形態による、処理ステージのワーカーノードがデータベーステーブルを利用してそれらの作業負荷を調整するストリーム処理システムの実施例を説明する。 少なくともいくつかの実施形態による、作業負荷調整のためにパーティション割り当てテーブルに記憶されてもよい例示的なエントリを説明する。 少なくともいくつかの実施形態による、ストリーム処理ステージのワーカーノードによって、処理操作を実行するためのパーティションの選択のために実行されてもよい操作の態様を説明する。 少なくともいくつかの実施形態による、ストリーム処理ステージのワーカーノードによって、ストリーム管理サービス制御サブシステムから取得した情報に基づいてパーティション割り当てテーブルを更新するために実行されてもよい操作の態様を説明する。 少なくともいくつかの実施形態による、ストリーム処理ステージのワーカーノードによって実行されてもよいロードバランシング操作の態様を説明する。 少なくともいくつかの実施形態で利用されてもよい計算装置の実施例を説明するブロック図である。
本明細書内の実施形態は、いくつかの実施形態の実施例および例示のための図面を用いて記載される。しかし、実施形態は、本明細書に記載された実施形態または図面に限定されないことが当業者には理解されよう。図面およびその詳細な記述は、実施形態を開示された特定の形態に限定することを意図するものではなく、反対に添付された特許請求の範囲によって定められるような趣旨および範囲に入るすべての修正、均等物および代替例を包括することを意図していることが理解されるべきである。本明細書にて利用されている見出しは、構成上の目的のためであり、説明または特許請求の範囲を限定するために利用されることを意図するものではない。本出願の全体において、「ｍａｙ」の用語は強制の意味（すなわち、しなければならないことを意味する）ではなく許可の意味（すなわち、可能性を有することを意味する）で用いられる。同様に、「ｉｎｃｌｕｄｅ」、「ｉｎｃｌｕｄｉｎｇ」および「ｉｎｃｌｕｄｅｓ」の用語は含むことを意味するが、それに限定されない。
数百あるいは数千もの同時並行的データプロデューサおよびデータコンシューマを処理するように設計された大規模なデータストリームを作成、記憶、検索および処理を管理するための方法および装置の様々な実施形態を説明する。「データストリーム」の用語は、本明細書内で用いられるように、１つ以上のデータプロデューサによって生成され、また１つ以上のデータコンシューマによってアクセスされてもよく、各データレコードを変更不能なバイト列とする、データレコードのシーケンスを指す。いくつかの実施形態において、ストリーム管理サービス（ＳＭＳ）はストリームの作成、構成および削除、ならびにストリームデータレコードの送信、記憶および検索を可能にするプログラムインターフェイス（例、アプリケーションプログラミングインターフェイス（ＡＰＩ）、ウェブページもしくはウェブサイト、グラフィックユーザーインターフェイス、またはコマンドラインツール）を提供してもよい。ＳＭＳ制御コンポーネントと対話するものであるストリーム操作（ストリーム作成もしくは削除、または以下に述べる動的再分割操作の種類など）のいくつかのタイプは、本明細書内で「制御プレーン」操作と称することがある。一方、データレコード送信、記憶および検索などの通常（例、正常な動作状態において）制御コンポーネントとの対話を要求しない操作は、本明細書内では「データプレーン」操作と称るることがある。動的にプロビジョニングされた計算、記憶およびネットワーキングリソース群は、そのような実施形態のいくつかにおいて、例えば、以下でさらに詳細に述べるように、多数のサービスコンポーネントの間でスケーラブルな形式でストリーム管理の作業負荷を分散させることができる様々な分割ポリシーに基づいて、サービスを実装するために利用されてもよい。本明細書において、ストリーム管理サービス、また、ストリーム管理サービスを実装するために利用される仮想及び／または物理リソースの収集を含むストリーム管理システムを指すために、ＳＭＳの頭字語が用いられることがある。
ＳＭＳの顧客の一部は、様々な実施形態においてＳＭＳプログラムインターフェイスを直接呼び出すアプリケーションを開発してもよい。しかし少なくともいくつかの実施形態では、ＳＭＳインターフェイスに加えて、ＳＭＳに直接サポートされた下位ストリーム管理関数を利用してアプリケーションを開発することを望まないクライアントのために、ストリーム処理の様々な態様を簡略化することができる高抽象度またはアプリケーションレベルの処理のフレームワークが顧客のために提供されてもよい。そのようなフレームワークは、顧客が下位ストリーム管理操作よりもストリームレコードを利用して実装されるビジネスロジックにより重点を置くことを可能にする（例えばＳＭＳインターフェイス上に構築された）それ自体のプログラムインターフェイスを提供してもよい。いくつかの実施形態において、それ自体の制御プレーンおよびデータプレーンコンポーネントを有する、ストリーム処理のためのリソースの自動供給、処理ノードの自動フェイルオーバー、任意のストリーム処理ワークフローグラフを構築する能力、一時ストリームのためのサポート、作業負荷の変更または他のトリガする条件に基づく動的再分割、などの高度機能を提供することができるストリーム処理サービス（ＳＰＳ）として、上位フレームワークが実装されてもよい。少なくともいくつかの実施形態では、ストリーム管理サービス、ストリーム処理サービス、または両方のサービスのいずれかが、マルチテナント管理のネットワークアクセス可能サービスとして仮想化環境において実装されてもよい。すなわちそのような実施形態において、少なくとも場合によってはリソースが共有されている方法を必ずしも顧客に正確に認識させることなく、または所定のリソースが共有されていることを一切顧客に認識させることなく、様々な物理リソース（コンピュータサーバまたはホスト、記憶装置、ネットワーキング装置など）が異なる顧客のストリーム間で共有されてもよい。管理されたマルチテナントストリーム管理及び／または処理管理サービスの制御コンポーネントは、クライアントによる選択が一部可能な様々な適用可能なポリシーに基づいて、特定のストリームのために利用されるノードまたはリソースを動的に追加し、取り除き、または再構成してもよい。加えて、制御コンポーネントもまた、（例えば、少なくともいくつかのハードウェアまたはソフトウェアが両方のクライアントによって共有されることが可能であるにもかかわらず、あるクライアントのストリームアプリケーションが別のクライアントのデータにアクセスできないように万全を期すために）様々な種類のセキュリティプロトコルの透明な形での実装、請求のためのリソースの使用の監視、監査またはデバッグのために利用可能なロギング情報の生成などの役割を担ってもよい。（１つ以上の）管理されたマルチテナントサービスのクライアントのパースペクティブから、（１つ以上の）サービスによって実装される制御／管理機能により、大規模ストリーミングアプリケーションのサポートに関わる複雑性の大部分を解消することができる。いくつかのシナリオでは、そのようなマルチテナントサービスの顧客が少なくともいくつかのタイプのストリーム関連の操作のためのリソースの共有を望まないことを示すことができる可能性があり、その場合少なくとも一時的に、それらのタイプの操作のための（すなわち、単一の顧客またはクライアントのために実行される操作に限定される）シングルテナントとして、いくつかの物理リソースが指定されてもよい。
様々な実施形態において、ＳＭＳ及び／またはＳＰＳ制御プレーンならびにデータプレーン操作の実装のためにいくつかの異なる手法が取られてもよい。例えば制御プレーン操作に関して、いくつかの実装において、制御サーバまたはノードの冗長グループが設定されてもよい。冗長グループは、複数の制御サーバを含んでもよく、それら複数の制御サーバにおいては、あるサーバが様々なストリームに関する管理要求への応答の役割を担うプライマリサーバとして指定される。一方で、現在のプライマリにおける障害（またはその接続の喪失）などのトリガする条件の場合に、プライマリとして引き継ぐために別のサーバが指定されてもよい。別の実装においては、ネットワークアクセス可能データベースサービスにおいて作成される１つ以上のテーブルが、様々なストリームのための（パーティションマップなどの）制御プレーンメタデータを記憶させるために利用されてもよく、様々な採集、記憶または検索ノードが、データプレーン操作のために要求されるメタデータのサブセットを取得するために必要なテーブルにアクセスすることができる可能性がある。異なる実施形態におけるＳＰＳおよびＳＭＳデータプレーンならびに制御プレーン機能の様々な態様に関する詳細については、以下で説明する。ストリーム管理サービスが実装されるいくつかの実施形態においては、上位プリミティブを提供するストリーム処理サービスが必ずしも実装されなくてもよいことに留意されたい。他の実施形態では、ストリーム処理サービスの高レベルのプログラムインターフェイスのみが顧客に公開されてもよく、によって利用される下位ストリーム管理インターフェイスがクライアントに利用可能にされなくてもよい。
いくつかの実施形態によると、ストリーム管理システムは、データレコードの取得または収集の役割を主に担うレコード採集サブシステム、適用可能な永続性または持続性ポリシーにしたがうデータレコードの内容の保存の役割を主に担うレコード記憶サブシステム、および記憶するレコードに向けられる読み出し要求への応答の役割を主に担うレコード検索サブシステムを含む、複数の独立的に構成可能なサブシステムを含んでもよい。いくつかの実施形態では、制御サブシステムも、例えば、仮想または物理サーバなどの選択されたリソースにおいて、採集、記憶および検索サブシステムのそれぞれのために要求されたノード数を動的に決定及び／または初期化することにより、残りのサブシステムを構成する役割を担う１つ以上の管理または制御コンポーネントを含んで、実装されてもよい。採集、記憶、検索および制御サブシステムのそれぞれが、それぞれの複数のハードウェア及び／またはソフトウェアコンポーネントを利用して実装されてもよい。利用されるものは、サブシステムの「ノード」または「サーバ」と総称される場合がある、。従ってＳＭＳの様々なリソースについては、採集、記憶、検索または制御の４つの機能カテゴリの１つに属すると論理的に言うことができる。いくつかの実装においては、他のサブシステムの各々について、それぞれの制御コンポーネント群が構築されてもよく、例えば、独立した採集制御サブシステム、記憶制御サブシステム及び／または検索制御サブシステムが実装されてもよい。そのような制御サブシステムのそれぞれが、対応するサブシステムの他のノードのために利用されるリソースの識別、及び／またはクライアントからのまたは他のサブシステムからの管理クエリへの応答、の役割を担ってもよい。いくつかの実装においては、様々な種類のＳＭＳ、及び／またはＳＰＳ関数の実行が可能であるノードのプールが事前に設定されてもよく、それらのプールのうちの選択された構成要素が、必要に応じて新しいストリームまたは新しい処理ステージに割り当てられてもよい。
少なくともいくつかの実施形態では、例えば、採集、記憶、検索及び／または制御ノードの異なる群の間にデータレコードのサブセットを分散させるために、ストリーム分割ポリシーおよび関連するマッピングが実装されてもよい。例えば、特定のデータストリームのために選択された分割ポリシーに基づき、また、レコード採集率及び／または検索率の予測などの他の要因に基づき、いくつのノード（例、処理またはスレッド）が最初に（すなわちストリーム作成時に）採集、記憶および検索のために構築されるべきかを、また、それらのノードがどのようにして仮想及び／または物理マシンにマッピングされるべきかを、制御コンポーネントが決定してもよい。時間と共に、所定のストリームに関連する作業負荷が増加するか、または減少することがあり、それが（他のトリガする条件の間で）ストリームの再分割につながる可能性がある。そのような再分割は、レコードのパーティション、利用される分割キー、パーティションの総数、採集ノード、記憶ノードもしくは検索ノードの数、または異なる物理または仮想リソース上のノードの配置を決定するために利用される関数などの様々なパラメータを変更するものであってもよい。少なくともいくつかの実施形態では、以下に詳細に述べる技術を利用して、データレコードの流れを中断することなく、再分割が動的に実装されてもよい。いくつかの実施形態では、異なる分割スキームおよび再分割トリガ基準が、例えばクライアントが提供するパラメータに基づいて、またはＳＭＳ制御ノードのヒューリスティックに基づいて、異なるデータストリームのために利用されてもよい。いくつかの実施形態では、例えばクライアントの選好、ストリームの予測生存時間または他の要因に基づいて、再分割の数及び／または頻度を制限することが可能な場合がある。
異なる実施形態では、いくつかの異なるレコード採集ポリシーおよびインターフェイスが実装されてもよい。例えば、いくつかの実施形態では、クライアント（例えば、ＳＭＳの顧客のためにＳＭＳのプログラムインターフェイスを呼び出すよう構成された実行可能コンポーネントまたはモジュール）が、インライン送信インターフェイスまたはバイリファレンス送信インターフェイスのいずれかを利用してもよい。そのような実施形態では、インライン送信のため、データレコードの内容または本体の一部として送信要求が含まれてもよい。対照的にバイリファレンス送信要求においては、データレコードの内容または本体をそこから取得することができるアドレス（記憶装置アドレス、データベースレコードアドレスまたはＵＲＬ（ユニフォームレコードロケータなど））が提供されてもよい。いくつかの実装においては、ハイブリッド送信インターフェイスも同様に、またはハイブリッド送信インターフェイスが代わりにサポートされてもよく、そのようなハイブリッド送信インターフェイスにおいては、データレコードの第１のＮバイト列がインラインで含まれてもよく、一方で残りのバイト列（もしあれば）が参照用に提供され得る。そのようなシナリオでは、（Ｎバイト列の長さより本体が短い）短いレコードの送信要求によって完全に特定されてもよく、一方で、より長いレコードの一部を対応するアドレスから取得しなければならない場合もあり得る。
いくつかの実施形態では、採集中にレコード内容を特定するための異なる代替例に加えて、多様な応答また重複排除に関する採集ポリシーが実装されてもよい。例えば、いくつかのストリームアプリケーションのために、あらゆるデータレコードがＳＭＳによって確実に採集されることをクライアントが求める場合がある。大規模な分散ストリーム管理環境では、データプロデューサと採集ノードとの間のパスにおいて、パケットが失われるか、または様々な障害が時に生じる場合があり、その結果いくつかの送信データが失われる可能性がある。従っていくつかの実施形態では、ＳＭＳが少なくとも１回の採集ポリシーを実装し、それに従って採集サブシステムから肯定応答を受信するまで、レコードサブミッタが同じレコードを１回以上送信してもよい。正常な動作状態において、レコードは１回送信され、受信する採集ノードがレコードを取得し記憶させた後にサブミッタが応答を受信してもよい。応答が失われるかまたは遅延した場合、またはレコード送信要求自体が失われた場合は、応答が最終的に受信されるまでサブミッタが同じデータレコードを１回以上再送信してもよい。採集ノードは、例えば、応答がサブミッタにより受信されていればレコードは再送信されないという予測に基づいて、それが重複であるかどうかに関わらず各送信のための応答を生成してもよい。しかし、少なくともいくつかの実施形態において、同じデータレコードが複数回送信されたことを認識し、重複データの新しいコピーを不必要に記憶させることを回避する役割を採集ノードが担ってもよい。１つの実施形態において、少なくとも１回の採集ポリシーの少なくとも２つのバージョンがサポートされてもよい。すなわち、ＳＭＳがデータレコードの重複を排除する（すなわち、２つ以上の送信群のうちの１つのみを受けてデータが確実にＳＭＳ記憶サブシステムに記憶されるようにする）役割を担う１つのバージョン（「少なくとも１回の採集、重複なし」と称される場合がある）と、ＳＭＳによるデータレコード記憶の重複が許可される１つのバージョン（「少なくとも１回の、重複が許可された」と称される場合がある）である。少なくとも１回の、重複が許可された手法は、データレコード重複の否定的な結果がほとんど、あるいはまったくないストリームアプリケーションにとって、及び／または自身の重複削除を実行するストリームアプリケーションにとって有用である場合がある。送信されるすべてのデータレコードごとに応答が要求されるわけではないベストエフォート型採集ポリシーなどの他の採集ポリシーもまた、サポートされてもよい。少なくともいくつかの実施形態では、ベストエフォート型採集ポリシーが有効である場合、少数のデータレコードの喪失は容認されることがある。様々な実施形態においてクライアントは、自身が様々なストリームについてどの採集ポリシーの利用を望むか選択してもよい。
ストリームレコードの記憶に関しては、少なくともいくつかの実施形態において、いくつかの代替的なポリシーもまたサポートされてもよい。例えば、クライアントは、記憶される所定のデータレコードのコピー数、コピーのために利用される記憶技術のタイプ（例、揮発性または不揮発性ＲＡＭ、回転式ディスクベースの記憶装置、ソリッドステート装置（ＳＳＤ）、ネットワーク接続型記憶装置など）などのレコード記憶の態様を左右する、ＳＭＳにサポートされたいくつかの中から１つの永続性ポリシーを選択することができる場合がある。例えば、クライアントがディスクベースの記憶装置にＮ個のレプリカの永続性ポリシーを選択する場合、Ｎ個のレコードのコピーがＮ個それぞれのディスク装置に安全に書き込まれるまでデータレコード送信は完了したものとみなされないことがある。ディスクベースの記憶装置が利用される少なくともいくつかの実施形態では、例えば、ディスクシークによる性能への影響を回避するために、ＳＭＳ記憶サブシステムが所定のパーティションの受信データレコードをディスクに順次書き込むことを試みてもよい。例えば、採集時間に基づく順序付けられたレコード検索を可能にするタイムスタンプを用いた技術を含む、以下に述べる様々な技術を利用して、シーケンス番号がデータレコードのために（また、データレコードと共に記憶されても）生成されてもよい。少なくともいくつかの実施形態では、所定のパーティションのデータレコードが、例えば、ディスク上に隣接して、また他のパーティションのデータレコードから離れて、ともに記憶されてもよい。いくつかの実装においては、（クライアントによって、またはＳＭＳによって選択された）保持ポリシーまたは（いくつかの重複が送信されたとしても、所定のデータレコードが重複してＳＭＳ記憶サブシステムに記憶されないように万全を期すようＳＭＳに要求してもよい期間に、その所定のデータレコードのいずれかの送信に続く時限を示す）重複排除時間窓ポリシーに従って、少なくともいくつかのデータレコードが異なるタイプの記憶サービスへとアーカイブされ、及び／または時限後にＳＭＳから削除されてもよいそのような除去操作は、本明細書内でストリーム「トリミング」と称することがある。いくつかの実施形態において、クライアントは、ストリームトリミング要求を送信してもよい。これは、例えば、特定のデータレコードがもはや必要とされなくなったために、トリミング要求を送信するクライアントのパースペクティブから、その特定のデータレコードを削除することが可能であることをＳＭＳに通知する、または特定のデータレコードの削除を明示的に要求することである。所定のストリームのデータレコードを消費する複数のクライアントが存在するシナリオにおいては、ＳＭＳが関係するすべてのコンシューマによってアクセスされる前に所定のレコードが早まって削除される、あるいはトリミングされることがないよう万全を期す役割を担ってもよい。いくつかの実装においては、所定のストリームのＮ個のデータコンシューマがある場合、ＳＭＳは、自身がＮ個のデータコンシューマすべてが、ストリームの所定のレコードＲの読み出しまたは処理を行ったと判定するまで、レコードＲの削除を待ってもよい。例えばコンシューマからのそれぞれのトリミング要求に基づいて、またはストリームにおいてデータコンシューマがどこまで進行したかに関するそれぞれの指示に基づいて、すべてのコンシューマによってＲが読み出されたとＳＭＳが判定してもよい。いくつかの実施形態では、いくつかのタイプのデータコンシューマ（試験関連のアプリケーションなど）が、少なくともデータレコードの小規模なサブセットのアクセスされる前の削除を容認してもよい。従って、少なくともいくつかの実施形態において、アプリケーションは検索前にデータ削除の容認性に関する通知をＳＭＳに行うことが可能である場合があり、ＳＭＳがその通知にしたがって削除をスケジュールしてもよい。いくつかの実施形態では、例えばストリームデータレコードのコピー先となるべきタイプの記憶装置を示すデータ保持ポリシーおよびそのようなコピーに利用されるスケジューリングポリシーの一部として、アーカイバルポリシーが実装されてもよい。
少なくともいくつかの実施形態では、複数のプログラムインターフェイスもまたレコード検索のためにサポートされてもよい。１つの実施形態においては、１つのプログラムインターフェイス（例、ｇｅｔＩｔｅｒａｔｏｒ）がイテレータまたはカーソルをインスタンス化しストリームのパーティション内の（例えば、シーケンス番号またはタイムスタンプに基づく）特定の論理オフセットに位置付けるために利用されてもよい、あるいは、イテレータを用いた手法が利用されてもよい。異なるプログラムインターフェイス（ｇｅｔＮｅｘｔＲｅｃｏｒｄｓなど）がその後、イテレータの現在の位置から順次開始される特定の数のデータレコードを読み出すために利用されてもよい。イテレータのインスタンス化により、クライアントによるストリームパーティション内のレコード検索の任意のまたはランダムな開始位置の特定が事実上可能になることがある。そのような実施形態において、クライアントがデータレコードをランダムアクセスパターンで読み出すことを望む場合、クライアントが新しいイテレータを繰り返し作成しなければならない可能性がある。回転式ディスクを用いた記憶システムにおいては、頻繁なランダムアクセスのために要求されたディスクシークが、Ｉ／Ｏ応答時間に深刻な影響を与える場合がある。従って、少なくともいくつかの実施形態では、クライアントがストリームデータレコードのランダムではなく順次の読み出しを行う動機として、順次読み出しアクセスに適用される課金率とは異なる（例えば、より高い）課金率がランダム読み出しアクセスに適用される可能性がある。従って、いくつかの実装においては、Ｘ＞Ｙとして、クライアントが例えば、ｇｅｔＩｔｅｒａｔｏｒの呼び出しごとにＸ通貨単位を、また、ｇｅｔＮｅｘｔＲｅｃｏｒｄｓを介して検索されるレコードごとにＹ通貨単位を請求されることがある。代替的なクライアントインターフェイスが他の操作カテゴリ（採集など）のためにサポートされるとき、少なくともいくつかの実施形態では、代替例のための課金率または価格が異なる場合がある。例えば、クライアントが順次読み出しよりもランダム読み出しにより高い料金を請求される場合があるように、クライアントがオンライン送信要求よりもバイリファレンス送信要求により高い料金を請求される場合がある。様々な実施形態において、データレコードの大きさ、時間の経過による書き込み対読み出し要求の分散、選択された永続性ポリシーなどの他の要因も請求に影響を与える可能性がある。
いくつかの実施形態によると、ストリーム処理サービス（ＳＰＳ）により、クライアントが多数の処理ステージを含む、所定のステージにおいて実行される処理の出力が０個以上の他のステージのための入力として利用されてもよい複雑な処理ワークフローを任意に特定することが可能になる場合がある。分割ポリシー（データレコードの採集、記憶および検索のためのＳＭＳについて説明するポリシーと同様に）は、いくつかの実施形態における様々なステージで、複数のワーカーノード間の処理作業負荷を分割するために利用されてもよい。そのような１つの実施形態において、例えば、ステージのための（１つ以上の）入力データソース（例えば、ストリームのための分割ポリシーと共にデータレコードが検索される１つ以上のストリーム）、ステージにおいて実行される処理操作、およびステージからの出力または結果の分散のための記述子または特定（例えば、出力が記憶位置に保存され、ネットワークエンドポイントに送信され、または１つもしくは複数の他の処理ステージに異なるストリームの形式で入力されるか否か）を含む所与のステージのための様々な構成設定を特定することを、クライアントが可能にするプログラムＳＰＳインターフェイスが実装されてもよい。少なくともいくつかの実施形態では、ＳＰＳステージのために特定された処理操作は、冪等であってもよい。すなわち所定の処理操作が同じ入力データにおいて複数回実行される場合、その操作の結果は操作が１回のみ実行された場合に取得されていたであろう結果と異ならない。以下に詳細に述べるように、処理操作が冪等である場合、障害（例、ＳＰＳステージにおけるワーカーノード障害）からの回復は簡略化されてもよい。いくつかの実施形態によると、ＳＰＳステージの一部またはすべてにおいて非冪等処理操作が許可されてもよい。
入力ストリーム分割ポリシー、次いでＳＰＳプログラムインターフェイスを介して受信される処理操作の性質などの構成情報に少なくとも部分的に基づき、様々な実施形態において、処理ワークフローの様々なステージのために最初に設定されるワーカーノードの数をＳＰＳ制御サーバが決定してもよい。ワーカーノードのために利用されるリソースの性能もまた（例、利用されている仮想または物理マシン）、ワーカーノードの初期数および配置の決定の際に考慮されてもよい。（いくつかの実装において、それぞれが実行可能スレッドまたは実行可能処理を含んでもよい）選択された数のワーカーノードがインスタンス化されてもよい。例えば、適切な入力ソースから（例えば、１つ以上のストリームパーティションの検索ノードから）データレコードを取得し、データレコード上で特定の処理操作を実行し、また処理の結果を（１つ以上の）特定の出力先に送信するために、各ワーカーノードが構成されてもよい。加えて、少なくともいくつかの実施形態では、チェックポイントスキームが実装されてもよく、それに従って、パーティションレコードが順次処理されていることを前提として、そのワーカーノードにおいて処理されているパーティションの一部を示すプログレスレコードまたはチェックポイントを記憶させるために、所定のワーカーノードが構成されてもよい。ワーカーノードは、例えば、いくつかの実装においてプログレスレコードを永続性記憶装置に周期的に（例えば、Ｎ秒に１回またはＲ個のデータレコードが処理されるごとに１回）、及び／またはＳＰＳ制御サーバからのチェックポイント要求に応じて書き込んでもよい。
いくつかの実施形態では、ワーカーノード障害からの迅速な回復のためにプログレスレコードが利用されてもよい。例えば、ハートビート機構を利用して、及び／またはリソース利用レベル（ＣＰＵ利用、Ｉ／Ｏ装置利用またはネットワーク利用レベルなど）を監視することで、ＳＰＳ制御サーバが時間の経過に伴う様々なワーカーノードの健全性状態を監視するなどしてもよい。特定のワーカーノードが所望のまたは不健全な状態（例えば、応答しないまたは過負荷である場合）にあることをＳＰＳ制御サーバが判定することに応じて、置換ワーカーノードが特定のワーカーノードの役割を引き継ぐためにインスタンス化されてもよい。置換ワーカーノードは、置換ワーカーノードが処理するべきデータ、レコード群を識別するために、置換されたワーカーノードによって記憶された最新のプログレスレコードにアクセスしてもよい。処理操作が冪等である実施形態において、いくつかの操作が繰り返されたとしても（例えば、最新のプログレスレコードが置換ワーカーのインスタンス化のしばらく前に書き込まれたために）、処理の全体的な結果は障害および置換による影響を受けない。いくつかの実装においては、それによって処理される所定のストリームまたはパーティションのサブセットを示すプログレスレコードの記憶に加えて、ワーカーノードもまた蓄積されたアプリケーション状態の情報を記憶させるよう構成されてもよい。例えば、ストリーム処理ワークフローがサービス使用メトリクスを示すストリーミングデータレコードの分析に基づいて特定のサービスのためのクライアントの課金額を決定する役割を担う場合、ワーカーノードが、様々なクライアントのために決定された累積課金額を周期的に記憶してもよい。
少なくともいくつかの実施形態では、ＳＰＳ制御サーバがまた、様々なステージのための入力ストリームの動的再分割の要求、所定のステージにおいて所定のパーティションに割り当てられたワーカーノード数の変更、より高性能なワーカーノードのいくつかのステージへの割り当て、またはワーカーノードある物理リソースから異なる性能を有する別の物理リソースへの転送などの他のアクションの起動によって、変化する作業負荷レベルまたは検知される作業負荷の不均衡（例えば、あるパーティションのための採集率が他の採集率よりも不釣り合いに高い）などの様々な他のトリガに応答するように構成されてもよい。いくつかの実施形態では、例えば、ＳＰＳ制御サーバによるチェックポイントを用いた回復ポリシーではなく、ベストエフォート型回復ポリシーが所定のステージのために実装されることの決定を受けて、上述のタイプのプログレスレコードが、少なくともいくつかのＳＰＳステージのワーカーノードによって記憶されない可能性がある。そのようなベストエフォート型回復ポリシーのいくつかの実装においては、置換ワーカーノードは、プログレスレコードへのアクセスを要求することなく、新しいデータレコードを受信されたとおりに、単純に処理してもよい。いくつかの実施形態では、クライアントがベストエフォート型回復ポリシーをＳＰＳステージにおいて実装することを望む場合、ステージにおいて実行されるストリーム処理操作が必ずしも冪等である必要はない。非冪等処理操作が、ＳＰＳステージのストリームレコードにおいて実行されるいくつかの実施形態では、チェックポイントを用いた回復がサポートされない場合があり、ベストエフォート型回復などの異なる回復スキームが利用されてもよい。少なくとも１つの実施形態では、冪等ストリーム処理操作のみが、ＳＰＳステージにおいて可能である場合がある。
いくつかのストリームのデータレコードが慎重な扱いを要する機密情報を含む場合があり、またはＳＰＳステージにおいて実行される処理操作が競合者により発見されると問題となる可能性がある独自のアルゴリズムを含む場合がある。従って、特にクライアント自身によって完全制御されないプロバイダーネットワークデータセンターに位置するリソースを利用して操作が実行される場合に、クライアントがストリーム管理および処理操作の様々なカテゴリのセキュリティに関して懸念を抱く可能性がある。会社または公的部門の組織などの法人によって１つ以上のインターネット及び／または他のネットワークを介して分散されたクライアント群へとアクセス可能なネットワークアクセス可能サービス（様々な種類のクラウドベースのデータベース、計算または記憶サービスなど）を提供するよう設定されたネットワークは、本明細書においてプロバイダーネットワークと称する場合がある。いくつかの実施形態では、クライアントが、複数のセキュリティ関連のオプションから自身のデータストリームのためのものを選択することができる場合がある。上述のように、ＳＰＳおよびＳＭＳの組み合せられた構成は、ＳＭＳ及び／またはＳＰＳのための制御ノード、ＳＭＳ採集ノード、ＳＭＳ記憶ノード、ＳＭＳ検索ノードおよびＳＰＳ処理またはワーカーノードなどの、いくつかの異なる機能カテゴリに属するノードを含んでもよい。いくつかの実施形態において、クライアントが行うことができるセキュリティ関連の選択は、様々な種類のノードの配置または位置のためのオプションを含んでもよい。例えば、１つの実施形態において、ストリームレコードがプロバイダーネットワークに位置するリソースを利用して最初に収集され、及び／または記憶される場合であっても、ストリームワークフローの１つ以上の処理ステージのためのＳＰＳワーカーノードのクライアント所有の設備に位置する計算装置における実装を、クライアントが要求できる可能性がある。そのような配置要求に応じて、所定のストリームのための異なる機能カテゴリのノードが、それぞれの異なるセキュリティ特徴またはプロファイルを有するリソース群においてインスタンス化されてもよい。
リソース群については、異なる実施形態において様々なセキュリティ関連の特徴、例えば、物理位置、利用される（例えば、リソースへの物理アクセスを有する）物理セキュリティプロトコル、（例えば、エンティティにとってリソースのネットワークアドレスが可視である程度の）ネットワーク隔離レベル、マルチテナンシー対シングルテナンシーなどを含めて互いに異なってもよい。いくつかの実施形態では、クライアントが隔離された仮想ネットワーク（ＩＶＮ）を、所定のクライアントをそのクライアントのＩＶＮ内に含まれる様々な装置のネットワーキング構成への所定の実質的制御として、プロバイダーネットワーク内に構築することができる場合がある。特に、クライアントは、自身のＩＶＮ内の様々なサーバまたは計算インスタンスに割り当てられたネットワークアドレス（例、インターネットプロトコルまたはＩＰアドレス）へのアクセスを制限することができる場合がある。そのような実施形態では、自身のＳＭＳまたはＳＰＳノードの特定のサブセットが特定のＩＶＮ内でインスタンス化されるようにクライアントが要求してもよい。（通常はマルチテナントホストとして構成されてもよい）仮想化インスタンスホストなどのプロバイダーネットワークリソースが、ＳＭＳまたはＳＰＳノードの様々なカテゴリのために利用されている実施形態においては、いくつかのノード群がそのクライアント単体に属するインスタンスの実装に制限されるインスタンスホスト上でインスタンス化されるようにクライアントが要求してもよい（すなわち、いくつかのＳＭＳまたはＳＰＳノードが、シングルテナントホストとして構成されるインスタンスホストにおいて実装されてもよい）。
いくつかの実施形態では、別のセキュリティ関連のオプションとして、特定のストリームのデータレコードがネットワークリンクで送信される前に、例えば、ＳＭＳにおいて採集される前に、採集および記憶サブシステムの間で、記憶および検索サブシステムの間で、検索サブシステムとＳＰＳワーカーノードとの間で、及び／またはワーカーノードとＳＰＳ出力先との間で暗号化されるように、クライアントが要求してもよい。クライアントは、いくつかの実施形態において利用される暗号化アルゴリズムを特定してもよい。１つの実施形態において、ＴＬＳ（トランスポートレイヤーセキュリティ）またはＳＳＬ（セキュアソケットレイヤー）プロトコルなどの安全なネットワーキングプロトコルが、データレコード送信のために、及び／またはＳＰＳ処理結果の送信のために利用されてもよい。
データストリームの概念および概要
図１は少なくともいくつかの実施形態による、データストリームの概念の簡便な概要を示している。図示のように、ストリーム１００は、ＤＲ１１０Ａ、１１０Ｂ、１１０Ｃ、１１０Ｄおよび１１０Ｅなどの複数のデータレコード（ＤＲ）１１０を含んでもよい。データプロデューサ１２０Ａおよび１２０Ｂなどの１つ以上のデータプロデューサ１２０（データソースとも称される場合がある）は、ストリーム１００のデータレコードの内容を生成するための書き込み操作１５１を実行してもよい。いくつかの異なるタイプのデータプロデューサが、例えば、携帯電話またはタブレットアプリケーション、センサーアレイ、ソーシャルメディアプラットフォーム、ロギングアプリケーションまたはシステムロギングコンポーネント、様々な種類の監視エージェントなどの異なる実施形態におけるデータのストリームを生成してもよい。１つ以上のデータコンシューマ１３０（データコンシューマ１３０Ａおよび１３０Ｂなど）が、データプロデューサ１２０によって生成されたデータレコードの内容にアクセスするための読み出し操作１５２を実行してもよい。いくつかの実施形態では、データコンシューマ１３０が、例えば、ストリーム処理ステージのワーカーノードを含んでもよい。
少なくともいくつかの実施形態では、ＳＭＳに記憶されるような所定のデータレコード１１０が、データ部分１０１（例、ＤＲ１１０Ａ、１１０Ｂ、１１０Ｃ、１１０Ｄおよび１１０Ｅのそれぞれのデータ部分１０１Ａ、１０１Ｂ、１０１Ｃ、１０１Ｄおよび１０１Ｅ）およびシーケンス番号ＳＮ１０２（例、ＤＲ１１０Ａ、１１０Ｂ、１１０Ｃ、１１０Ｄおよび１１０ＥのそれぞれのＳＮ１０２Ａ、１０２Ｂ、１０２Ｃ、１０２Ｄおよび１０２Ｅ）を含んでもよい。図示する実施形態において、ストリーム管理システムにおいて（またはストリーム管理システムの特定のノードにおいて）ＤＲが受信される順序を、シーケンス番号１０２が示してもよい。データ部分１０１は、いくつかの実装において、変更不能な解釈されないバイト列を含んでもよい。すなわち、書き込み操作１５２が完了すると、書き込み結果として生成されたＤＲの内容をＳＭＳによって変更することはできず、また一般的にはＳＭＳがデータの意味論を認識することはできない。いくつかの実装においては、所定のストリーム１００の異なるデータレコードが異なる量のデータを含んでもよい。一方、他の実装においては、所定のストリームのすべてのデータレコードが同じ大きさであってもよい。少なくともいくつかの実装において、ＳＭＳのノード（例えば、採集サブシステムノード及び／または記憶サブシステムノード）が、ＳＮ１０２を生成する役割を担ってもよい。以下に詳細に述べるように、データレコードのシーケンス番号が、常に必ずしも連続している必要はない。１つの実装では、クライアントまたはデータプロデューサ１２０が、書き込み要求の一部として対応するデータレコードのために利用される最小のシーケンス番号の指示を出してもよい。いくつかの実施形態では、例えば、データ部分が取得されてもよい記憶装置アドレス（装置内のデバイス名およびオフセットなど）またはネットワークアドレス（ＵＲＬなど）を提供することによって、データプロデューサ１２０が、データレコードのデータ部分へのポインタ（またはそのアドレス）を含む書き込み要求を送信してもよい。
ストリーム管理サービスは、様々な実施形態においてデータプロデューサ１２０からのデータを受信し、データを記憶し、またデータコンシューマ１３０が１つ以上のアクセスパターンでデータにアクセスすることを可能にする役割を担ってもよい。少なくともいくつかの実施形態では、データレコードの受信、記憶および検索の作業負荷を分散するためにストリーム１００が分割されるかまたは「共有され」てもよい。そのような実施形態においては、データレコードの１つ以上の属性に基づく受信データレコード１１０のためにパーティションまたは分割データベースが、選択されてもよい。また、データレコードを採集する、記憶させる、または検索する特定のノードが、パーティションに基づいて識別されてもよい。いくつかの実装においては、データプロデューサ１２０が、明示的な分割キーに分割属性としての役割を果たす各書き込み操作を提供してもよく、そのようなキーが、パーティション識別子へとマッピングされてもよい。他の実装においては、データプロデューサ１２０の識別、データプロデューサのＩＰアドレスなどの要因に基づいて、または送信されるデータの内容に基づいて、ＳＭＳがパーティションＩＤを推定してもよい。データストリームが分割されるいくつかの実装においては、シーケンス番号がパーティション単位で割り当てられてもよい。例えば、シーケンス番号が特定のパーティションのデータレコードが受信される順序を示してもよいが、異なる２つのパーティションにおけるデータレコードＤＲ１およびＤＲ２のシーケンス番号は、ＤＲ１およびＤＲ２が受信された相対順序を必ずしも示すとは限らない。他の実装においては、データレコードＤＲ１に割り当てられるシーケンス番号ＳＮ１が、データレコードＤＲ２に割り当てられるシーケンス番号ＳＮ２より小さい場合、ＤＲ１およびＤＲ２が属するパーティションに関わらず、ＤＲ１がＳＭＳによってＤＲ２より先に受信されたことが、これにより示されるように、シーケンス番号が、パーティション単位ではなくストリーム全体に割り当てられてもよい。
様々な実施形態において、ＳＭＳによってサポートされる検索または読み出しインターフェイスにより、データコンシューマ１３０が、データレコードに順次及び／またはランダムにアクセスすることが可能になる場合がある。１つの実施形態において、イテレータを用いた読み出しアプリケーションプログラミングインターフェイス（ＡＰＩ）群がサポートされてもよい。データコンシューマ１３０は、特定のシーケンス番号及び／またはパーティション識別子によって示されるイテレータの初期位置でデータストリームのためのイテレータを取得するための要求を送信してもよい。イニシエータがインスタンス化された後、データコンシューマは、データレコードをストリームまたはパーティション内のその初期位置から順次読み出すための要求を送信してもよい。データコンシューマが、いくつかのランダムな順序でデータレコードの読み出しを望む場合、そのような実施形態の各読み出しのために新しいイテレータが、インスタンス化されなければならない可能性がある。少なくともいくつかの実装において、所定のパーティションまたはストリームのデータレコードが、ディスクシークを回避する順次書き込み操作を通常利用して、シーケンス番号順にディスクベースの記憶装置に書き込まれてもよい。順次読み出し操作はまた、ディスクシークのオーバーヘッドを回避してもよい。従って、いくつかの実施形態では、例えば、イテレータのインスタンス化などのランダムアクセス読み出し操作に関連する課金率が順次アクセス読み出し操作よりも高い場合があるなど、価格に関する動機のために、データコンシューマにランダム読み出しよりも順次読み出しの実行がより求められる場合がある。
（例示的なシステム環境）
図２は、少なくともいくつかの実施形態による、ストリーム管理システム（ＳＭＳ）およびストリーム処理ステージの収集を含むストリーム処理システム（ＳＰＳ）の様々なサブコンポーネントの間のデータの流れの概要を示している。図示のように、ＳＭＳ２８０は、採集サブシステム２０４、記憶サブシステム２０６、検索サブシステム２０８およびＳＭＳ制御サブシステム２１０を含んでもよい。ＳＭＳサブシステムの各々は、例えば、以下に述べるようにプロバイダーネットワーク（またはクライアント所有のもしくはサードパーティの設備）の様々なリソースにおいて、それぞれの実行可能スレッドまたはインスタンス化された処理を利用して実装される１つ以上のノードまたはコンポーネントを含んでもよい。採集サブシステム２０４のノードは、（例えば、ＳＭＳ制御サブシステム２１０のノードによって）データプロデューサ１２０（１２０Ａ、１２０Ｂおよび１２０Ｃなど）から特定のデータストリームのデータレコードを、ストリームのために利用されている分割ポリシーに基づいて取得するようするよう構成されてもよく、各採集ノードが受信されたデータレコードを、記憶サブシステム２０６の対応するノードへと伝えてもよい。記憶サブシステムノードは、ストリームのために選択される永続性ポリシーに従って、様々な種類の記憶装置のいずれかにデータレコードを保存してもよい。検索サブシステム２０８のノードは、ＳＰＳ２９０のワーカーノードなどのデータコンシューマからの読み出し要求に応答してもよい。ＳＰＳ２９０のステージ２１５Ａ、２１５Ｂ、１２１５Ｃおよび２１５Ｄなどのストリーム処理ステージ２１５は、ＳＰＳ制御サブシステム２２０を用いて構築されてもよい。各ステージ２１５は、ＳＰＳ制御サブシステム２２０によって構成される、受信されたデータレコード上の処理操作群を実行するための１つ以上のワーカーノードを含んでもよい。図示のように、いくつかのステージ２１５（２１５Ａおよび２１５Ｂなど）は、データレコードをＳＭＳ２８０から直接取得してもよい。一方、他のステージ２１５（２１５Ｃおよび２１５Ｄなど）が、それ以外のステージからそれらの入力を受信してもよい。いくつかの実施形態では、複数のＳＰＳステージ２１５が並列に動作してもよい。例えば、ステージ２１５Ａおよび２１５Ｂにおいて、同じストリームから検索されたレコード上の異なる処理操作が、同時に実行されてもよい。図２において説明されるサブシステムおよび処理ステージに類似した、特定のストリームのためのそれぞれのサブシステムおよび処理ステージが、他のストリームと同様にインスタンス化されてもよいことに留意されたい。
少なくともいくつかの実施形態では、図２に示されるサブシステムおよび処理ステージの少なくともいくつかのノードが、プロバイダーネットワークリソースを利用して実装されてもよい。上述のように、インターネット及び／または他のネットワークを介して分散したクライアント群にアクセス可能な１つ以上のネットワークアクセス可能サービス（様々な種類のクラウドベースのデータベース、計算または記憶サービスなど）を提供するために、会社または公的部門の組織などの法人によって設定されたネットワークは、本明細書内でプロバイダーネットワークと称する場合がある。上位サービスを構築するために、いくつかのサービスが利用されてもよい。例えば、計算、記憶またはデータベースサービスが、ストリーム管理サービスまたはストリーム処理サービスのための構築ブロックとして利用されてもよい。プロバイダーネットワークの少なくともいくつかのコアサービスが、「インスタンス」と呼ばれるサービスユニットのクライアントの利用のために実装されてもよい。例えば、仮想化された計算サービスによってインスタンス化された仮想マシンが、「計算インスタンス」を表す場合があり、記憶サービスによってインスタンス化されたブロックレベルのなどの記憶装置が、「ストレージインスタンス」と称されることがあるか、またはデータベース管理サーバが、「データベースインスタンス」と称されることがある。プロバイダーネットワークの様々なネットワークアクセス可能サービスのそのようなユニットが実装されるサーバなどの計算装置は、本明細書において「インスタンスホスト」または単に「ホスト」と称することがある。いくつかの実施形態では、採集サブシステム２０４、記憶サブシステム２０６、検索サブシステム２０８、ＳＭＳ制御システム２１０、処理ステージ２１５、及び／またはＳＰＳ制御サブシステム２２０のノードは、複数のインスタンスホスト上の様々な計算インスタンスにおいて実行するスレッドまたは処理を含んでもよい。所定のインスタンスホストは、いくつかの計算インスタンスを含んでもよく、特定のインスタンスホストにおける計算インスタンスの収集は、１つ以上のクライアントの様々な異なるストリームのためのノードを実装するために利用されてもよい。いくつかの実施形態では、ストレージインスタンスは、様々なストリームのデータレコードの記憶のために、またはストリーム処理ステージの結果の宛先として利用されてもよい。時間の経過に従って、例えば、図１５および図１６を参照して以下に述べるように、データレコードの受信、記憶および処理の継続中にノードの追加もしくは除去、ノードの処理または計算インスタンスもしくはインスタンスホストへのマッピングの変更、または所定のストリームの再分割を行うことで、制御サブシステムノードは、他のサブシステム群を様々なトリガする条件に応じて動的に修正してもよい。
プロバイダーネットワークリソースが、ストリーム関連の操作のために利用される実施形態の文脈では、「クライアント」の語は、所定の通信のソースまたは宛先として利用される際に、プロバイダーネットワークの少なくとも１つのネットワークアクセス可能サービスへのアクセスおよびその利用が可能な法人（複数のユーザまたは単一のユーザを有する組織、グループなどの）によって所有され、管理され、またそのような法人に割り当てられる計算装置、処理、ハードウェアモジュールまたはソフトウェアモジュールのいずれかを指す場合がある。あるサービスのクライアントは、それ自体が別のサービスのリソースを利用して実装されてもよい。例えば、ストリームデータコンシューマ（ストリーム管理サービスのクライアント）が、計算インスタンス（仮想化された計算サービスによって提供されるリソース）を含んでもよい。
所定のプロバイダーネットワークは、物理及び／または仮想化されたコンピュータサーバ、１つ以上の記憶装置を各々が有する記憶サーバ、ネットワーク装置などの収集などの様々なリソースプールをホスティングし、プロバイダによって提供されるインフラストラクチャおよびサービスの実装、構成および分散のために必要とされる（異なる地域に分散されてもよい）多数のデータセンターを含んでもよい。様々な実施形態において、その一部が、異なるデータセンターまたは異なる地域においてインスタンス化されるかまたは実行されてもよい、いくつかの異なるハードウェア及び／またはソフトウェアコンポーネントは、各サービスを実装するためにまとめて利用されてもよい。クライアントは、クライアント所有の、またはクライアントが管理する敷地もしくはプロバイダーネットワークの外部のデータセンターに位置する装置から、及び／またはプロバイダーネットワーク内の装置からのプロバイダーネットワークにおけるリソースおよびサービスと対話してもよい。プロバイダーネットワークは、本明細書内に記載のストリーム管理および処理技術の多くが実装されてもよい１つの例示的なコンテキストとしての役割を果たす。しかし、これらの技術はまた、プロバイダーネットワーク以外のタイプの分散システムに、例えば、単一の事業体によってそれ自体のアプリケーションのために操作される大規模分散環境に適用されてもよいことに留意されたい。
プログラムインターフェイス実施例
上述のように、少なくともいくつかの実施形態では、様々なストリームを用いたアプリケーションのための所望のビジネスロジックを実装するために、ＳＰＳクライアントがより容易に利用することが可能な上位機能を構築するために、ＳＰＳがＳＭＳプログラムインターフェイスを利用してもよい。ＳＰＳとＳＭＳ機能との間の違いを考慮すると、類似が有用である場合がある。ＳＰＳ関数は、一般にＣ＋＋などの上位言語におけるプログラム言語構造と比較されることがあり、一方ＳＭＳ関数は、一般にプログラム言語構造がコンパイラによって翻訳されるアセンブリ言語命令と比較されることがある。アセンブリ言語命令を直接利用して同じ操作を実装することが可能である場合があるが、上位言語のプログラミングは、通常、顧客またはユーザの多くのカテゴリにとってより容易であることがある。同様に、ＳＭＳによって提供されるプリミティブを利用して様々なアプリケーションを実装することが可能である場合があるが、ＳＰＳの特徴を利用するとその実行がより容易であることがある。ＳＰＳ処理操作（データレコード上で実行される冪等処理操作など）が、ストリームレコードのデータ内容において実装されてもよく、一方ＳＭＳ操作は、レコードの内容を考慮せずにレコード自体を取得し、記憶させ、検索するために実行される。図３は、少なくともいくつかの実施形態による、ＳＭＳおよびＳＰＳに実装されてもよいそれぞれのプログラムインターフェイス群の実施例を説明する。いくつかの異なるアプリケーションプログラミングインターフェイス（ＡＰＩ）がＳＭＳおよびＳＰＳの両方のために例として示される。説明されるＡＰＩは、任意の所与の実装においてサポートされるそれらＡＰＩの網羅的なリストであることを意図されておらず、説明されるＡＰＩの一部は、所定の実装においてサポートされない場合がある。
矢印３５０によって示すように、ＳＰＳクライアント３７５は、処理ステージを構成するＳＰＳプログラムインターフェイス３０５を呼び出してもよい。様々な種類のＳＰＳプログラムインターフェイス３０５が、異なる実施形態において実装されてもよい。例えば、ステージのワーカーノードが、インターフェイス呼び出しにおいて特定される冪等操作群を実行するようにする場合がある。また、出力分布記述子またはポリシーによって示された宛先へと結果を分散させるように、クライアントが、それぞれ構成される特定の入力ストリームのための新しい処理ステージ２１５の構成を要求することを、ｃｒｅａｔｅＳｔｒｅａｍＰｒｏｃｅｓｓｉｎｇＳｔａｇｅ ＡＰＩが可能にする場合がある。ｃｒｅａｔｅＳｔｒｅａｍＰｒｏｃｅｓｓｉｎｇＳｔａｇｅ ＡＰＩ またはその等価物のいくつかのバージョンにおいては、クライアントが、入力ストリームの作成を同様に要求することができ、一方他のバージョンにおいては、処理ステージが作成される前に入力ストリームを作成しなければならない場合がある。回復ポリシーがワーカーノードのために特定され、例えば、チェックポイントを用いた回復技術が利用されるか、またはベストエフォート型回復技術が選好されるかを示してもよい。いくつかの実施形態では、ｉｎｉｔｉａｌｉｚｅＷｏｒｋｅｒＮｏｄｅ ＡＰＩがサポートされ、特定のステージでのワーカーノードの明示的なインスタンス化を要求してもよい。チェックポイントを用いた回復が実装される実施形態においては、ｓａｖｅＣｈｅｃｋｐｏｉｎｔ ＡＰＩがサポートされ、プログレスレコードがワーカーノードによって生成されるよう、クライアントが要求することを可能にしてもよい。
特定のステージにおいて実行される処理操作結果を利用して作成される１つ以上のストリームおよび新しく作成されるストリームのために利用される特定の分割ポリシーをクライアントが示すことができるｓｅｔＯｕｔｐｕｔＤｉｓｔｒｉｂｕｔｉｏｎ ＡＰＩなどの様々な種類のＳＰＳ出力管理ＡＰＩが、異なる実施形態においてサポートされてもよい。いくつかの処理ステージが主に再分割のために構成されてもよい。例えば、レコード属性集合Ａ１に基づいてデータレコードをＮ１パーティションへとマッピングする１つの分割関数ＰＦ１が、入力ストリームＳ１のために利用されてもよく、これらの同じデータレコードをＮ２パーティションへと（異なる属性集合Ａ２または同じ属性集合Ａ１のいずれかを利用して）マッピングする異なる分割関数ＰＦ２を実装するために、処理ステージが利用されてもよい。複数のステージを含む任意のグラフ（例えば、有向非巡回グラフ）を構成するために、ｌｉｎｋＳｔａｇｅｓなどのいくつかのＳＰＳ ＡＰＩが利用されてもよい。いくつかの実施形態では、サードパーティもしくはオープンソースのストリーム処理フレームワークまたはサービスへのコネクタがサポートされてもよい。そのような１つの実施形態においては、既存のサードパーティのまたはオープンソースのシステムによって消費するためのデータレコードを、（例えば、ステージにおいて実行される処理操作結果を適切にフォーマットすることによって）準備するために、ＳＰＳステージが利用されてもよい。図示する実施形態においては、そのようなコネクタを設定するためにｃｒｅａｔｅＴｈｉｒｄＰａｒｔｙＣｏｎｎｅｃｔｏｒなどのＡＰＩが利用されてもよく、ＳＰＳステージの結果のサードパーティのシステムと互換性のあるフォーマットへの適切な変換が、ｃｒｅａｔｅＴｈｉｒｄＰａｒｔｙＣｏｎｎｅｃｔｏｒの呼び出し結果としてインスタンス化された１つ以上のコネクタモジュールによって実行されてもよい。
ＳＰＳは、その少なくともいくつかの関数を実行するために、矢印３５２で示されるようにＳＭＳ ＡＰＩ３０７を呼び出してもよい。図示する実施形態において、ＳＭＳ ＡＰＩ３０７は、例えば、（ストリームをそれぞれ作成し削除する）ｃｒｅａｔｅＳｔｒｅａｍおよびｄｅｌｅｔｅＳｔｒｅａｍならびに（所定のパーティションの役割を担う様々な種類のノードのネットワークアドレスなどの、ストリームのためのメタデータを取得する）ｇｅｔＳｔｒｅａｍＩｎｆｏを含んでもよい。データレコードを書き込むために、ｐｕｔＲｅｃｏｒｄインターフェイスが利用されてもよく、一方、ｇｅｔＩｔｅｒａｔｏｒおよびｇｅｔＮｅｘｔＲｅｃｏｒｄｓインターフェイスが、それぞれ非順次および順次読み出しのために利用されてもよい。いくつかの実施形態では、特定のストリームの動的再分割を要求するために、ｒｅｐａｒｔｉｔｉｏｎＳｔｒｅａｍインターフェイスが利用されてもよい。矢印３５４で示すように、その実行を望むクライアント３７０がＳＭＳ ＡＰＩ３０７を直接呼び出してもよい。上述のように、他の実施形態において、様々な他のＳＭＳ及び／またはＳＰＳ ＡＰＩがまた実装されてもよく、図３に示すいくつかのＡＰＩはいくつかの実施形態においては実装されない可能性がある。
様々な実施形態において、ＳＰＳまたはＳＭＳのいずれかのために、ＡＰＩ以外のプログラムインターフェイスが、同様にまたは代わりに実装されてもよい。そのようなインターフェイスは、グラフィックユーザーインターフェイス、ウェブページまたはウェブサイト、コマンドラインインターフェイスなどを含んでもよい。場合によっては、ウェブベースのインターフェイスまたはＧＵＩが、ＡＰＩを構築ブロックとして利用してもよい。例えば、ウェブベースの対話が、結果的にＳＭＳまたはＳＰＳの制御コンポーネントにおいて１つ以上のＡＰＩの呼び出しを行ってもよい。図４は、少なくともいくつかの実施形態による、ＳＰＳクライアントによるストリーム処理ステージのグラフの生成を可能にするために実装され得るウェブベースのインターフェイスの実施例を説明する。図示のように、インターフェイスはメッセージ領域４０２、グラフメニュー領域４０４およびグラフデザイン領域４０３を有するウェブページ４００を含む。
メッセージ領域４０２内のストリーム処理グラフの構築に関する汎用命令と同様にストリームの概念およびプリミティブに関して詳細に知るために利用することが可能なリンクが、ユーザに提供されてもよい。いくつかのグラフィックアイコンが、メニュー領域４０４においてストリーム処理グラフのツールセットの一部として提供されてもよい。例えば、クライアントは、様々なＳＰＳ処理ステージの入力または出力として、永続性ストリーム４５１、一時ストリーム４５２、またはサードパーティの処理環境へのコネクタ４５３を示すことができる場合がある。ウェブベースのインターフェイスが実装されるＳＰＳ／ＳＭＳに関して、永続性ストリーム４５１は、ディスク、不揮発性ＲＡＭまたはＳＳＤなどの永続性記憶装置上にそのデータレコードが記憶されるストリームとして定義されてもよく、一時ストリーム４５２は、そのデータレコードが永続性記憶装置に記憶される必要がないストリームとして定義されてもよい。一時ストリームは、例えば、ベストエフォート型回復ポリシーが実装される異なるＳＰＳステージによって入力として消費されることが予期されるＳＰＳステージの出力から作成されてもよい。
チェックポイントを用いたワーカーノード回復が利用されるステージ４５５（例えば、各ワーカーノードが間隔を置いてプログレスレコードを保存し、また特定のワーカーノードの障害時には、処理を開始するデータレコードを決定するために置換ノードが障害の起きたノードのプログレスレコードを参照する）およびベストエフォート型回復が利用されるステージ４５６（例えば、置換ワーカーノードがプログレスレコードを参照せず、単純に新しいデータレコードの処理を受信されたまま開始する）の２つのタイプの処理ステージが、例示的なＳＰＳグラフ構築ウェブページ４００においてサポートされる。メッセージ領域４０２の指示によって示される通り、各ステージにおいて実行される処理操作に関する詳細が、グラフ構築領域４０３の対応するアイコンのクリックによって入力されてもよい。ストリーム、コネクタおよび処理ステージのためのアイコンに加えて、メニュー領域４０４もまたサードパーティのまたは外部のストリーム処理システムを示すアイコンタイプ４５９およびそのリソースが、処理ステージのために利用中であるプロバイダーネットワークにおいて実装されてもよい記憶サービスのノードを示すアイコンタイプ４６０を含む。
図４に示される例示的なシナリオにおいては、クライアントが３つの処理ステージ４１２、４１５および４１６を含むグラフ４０５をグラフデザイン領域４０３内に構築している。チェックポイントを用いた回復を利用するよう構成される処理ステージ４１２は、永続性ストリーム４１１を入力として利用する。ステージ４１２における処理の出力または結果は、ステージ４１５の入力を形成する異なる永続性ストリーム４１３のフォーマットで、またステージ４１６の入力を形成する一時ストリーム４１４のフォーマットで２つの宛先に送信される。ステージ４１５および４１６の両方それらのワーカーノードのためのベストエフォート型回復ポリシーを利用する。ステージ４１５の出力が、一時ストリームの形式で記憶サービスノード４１９に送信される。ステージ４１５の出力が、コネクタ４１７を介してサードパーティの処理システム４１８に送信される。処理ステージグラフの表示を保存するために、「グラフ保存」ボタン４２０が、例えば、ＪＳＯＮ（ＪＡＶＡスクリプト・オブジェクト・ノーテーション）、ＸＭＬ（エクステンシブル・マークアップ・ランゲージ）またはＹＡＭＬなどの任意の適切なフォーマットで利用されてもよい。様々な実施形態において、図４に示されるツールと同様のツールを利用して任意に複雑な処理ワークフローが構築されてもよい。そのようなツールを利用して作成されるワークフローが続いて起動されてもよく、そのような起動が、結果的にＳＭＳ ＡＰＩを呼び出してもよい。例えば、図４のステージ４１２などの処理ステージのためのデータレコードを取得するために、ｇｅｔＩｔｅｒａｔｏｒ及び／またはｇｅｔＮｅｘｔＲｅｃｏｒｄｓインターフェイスがストリーム４１１において呼び出されてもよい。
図５は、少なくともいくつかの実施形態による、ＳＭＳに実装されてもよいプログラムレコード送信インターフェイスおよびレコード検索インターフェイスの実施例を説明する。図示する実施形態においては、示されるＤＲ１１０Ｋおよび１１０Ｑなどのデータレコードが様々な種類のプログラム採集インターフェイス５１０を介してＳＭＳへと送信されてもよい。いくつかの実施形態では、（ストリーム「Ｓ１」のための）５０１Ａまたは（ストリーム「Ｓ２」のための）５０１Ｂなどのストリーム識別子、レコードのデータまたは本体の指示、（５０４Ａまたは５０４Ｂなどの）任意のパーティションキー５０４および（シーケンシング優先インジケータ５０６Ａおよび５０６Ｂなどの）任意のシーケンシング優先インジケータ５０６の４つのタイプの要素をＤＲ１１０が含んでもよい。いくつかのデータレコード（例、ＤＲ１１０Ｋのインラインデータ５０２）においては、データ自体がインラインで提供されてもよく、一方他のデータレコードのためには、ポインタまたはアドレス５０３が提供され、ＳＭＳにネットワークアクセス可能な位置（またはネットワーク転送を要求しないローカルデバイスのアドレス）を示してもよい。いくつかの実施形態では、所定のストリームがインラインおよび（アドレスを用いた）リファレンスによる両方のデータレコード送信をサポートしてもよい。他の実施形態では、すべてのデータをインラインで、またはすべてのデータをリファレンスにより供給するために、所定のストリームが、データプロデューサを要求してもよい。いくつかの実装においては、データレコード送信が、レコードのために利用されるパーティション識別子を含んでもよい。
図示する実施形態において、受信データレコード１１０は、分割ポリシーに基づいてそれぞれの採集及び／または記憶ノードに向けられてもよい。同様に、レコード検索はまた、パーティションに基づいてもよい。例えば、所定のパーティションのレコードに向けられた読み出し要求に応答するために、１つ以上の検索ノードが指定されてもよい。いくつかのストリームについては、データプロデューサが、明示的なパーティションキーに各データレコードの書き込み要求を提供するように要求されてもよい。他のストリームについては、明示的に供給されるパーティションキー以外のメタデータまたは属性に依拠する分割スキームに従って、ＳＭＳがデータレコードを分散させることが可能である場合がある。例えば、データプロデューサの送信に関連する識別情報が、パーティションキーとして利用されてもよいか、またはデータプロデューサのＩＰアドレスの送信の一部もしくは全部が利用されてもよいか、または送信中のデータの一部が利用されてもよい。いくつかの実装においては、例えば１２８ビットの整数などの特定の大きさの整数値を取得するために、ハッシュ関数が、パーティションキーに適用されてもよい。その大きさの正の整数の全範囲（例えば、０から２＾１２８−１）が、各サブレンジがそれぞれのパーティションを表すＮ個の連続したサブレンジに分割されてもよい。従って、そのような実施例では、データレコードのために決定されるかまたは供給される所与のパーティションキーが対応する１２８ビットの整数にハッシュされ、またその整数が属する１２８ビットの整数の連続したサブレンジが、データレコードが属するパーティションを示してもよい。分割ポリシーおよびそれらの利用に関する詳細を、図１５を参照して以下に示す。
特定のパーティションのデータレコードを採集しまたは受け入れ、データレコードを記憶し、特定のパーティションのための読み出し要求に応答する役割を担うノード群は、図５においてパーティションのためのＩＳＲ（採集、記憶および検索）ノードと総称される。ストリームＳiのｋ番目のパーティションを示すためにＳｊ〜Ｐｋの表記が利用される。説明する実施形態においては、パーティションＳ１〜Ｐ１のレコードの採集、記憶および検索のためにＩＳＲノード５２０Ａが構成され、ＩＳＲノード５２０ＢがパーティションＳ１〜Ｐ２のレコードのために設定され、ＩＳＲノード５２０ＣがパーティションＳ１〜Ｐ３のレコードのために設定され、ＩＳＲノード５２０ＫがパーティションＳ２〜Ｐ１のレコードのために設定され、またＩＳＲノード５２０ＬがパーティションＳ２〜Ｐ２のレコードのために設定される。いくつかの実施形態では、２つ以上のパーティション（または２つ以上のストリームの２つ以上のパーティション）のデータレコードを処理するように、採集サブシステム、記憶サブシステムまたは検索サブシステムの所与のノードが構成されてもよい。いくつかの実施形態では、所定のストリームの単一のパーティションのレコードが、２つ以上のノードによって採集され、記憶され、または検索されてもよい。所定のパーティションＳｊ〜Ｐｋのために指定される採集ノード数は、少なくともいくつかの場合には、異なるパーティションＳｊ〜Ｐlのために指定される採集ノードと異なってもよく、またＳｊ〜Ｐｋのために指定される記憶ノード数及び／またはＳｊ〜Ｐｋのために指定される検索ノード数とも異なってもよい。採集及び／または検索に関連して、いくつかの実施形態では、どのノードがどのパーティションのための役割を担うかをクライアントが決定することを可能にするために、ＳＭＳ制御ノードが、ＡＰＩ（ｇｅｔＳｔｒｅａｍＩｎｆｏなど）を実装してもよい。データレコードとパーティションとの間の、パーティションと構成されるＩＳＲノード（または制御ノード）との間のマッピングは、動的再分割に関して以下に述べるように時間の経過に応じて修正されてもよい。
いくつかの実施形態では、いくつかの異なるプログラムインターフェイス５８０が、所定のパーティションからのストリームデータレコードの検索または読み出しのために実装されてもよい。図５に示すように、（特定のシーケンス番号を有するデータレコードにおいてまたはその後に、イテレータをインスタンス化するか、またはカーソルを読み出すための）ｇｅｔＩｔｅｒａｔｏｒまたは（特定のシーケンス番号を有するデータレコードを読み出すための）ｇｅｔＲｅｃｏｒｄなどの非順次アクセスのために、いくつかの検索インターフェイス５８１が実装されてもよい。ｇｅｔＮｅｘｔＲｅｃｏｒｄｓ（Ｎ個のレコードをイテレータの現在の位置からシーケンス番号順に読み出すように要求するインターフェイス）などの順次検索のために、他の検索インターフェイス５８２が実装されてもよい。回転式ディスクベースの記憶装置システムにおいては上述のように、Ｉ／Ｏについて平均的に要求されるディスクヘッドのシーク数は、順次Ｉ／ＯについてはランダムＩ／Ｏよりも通常はるかに小さい可能性があるため、順次Ｉ／Ｏが、ランダムＩ／Ｏよりも多くの場合はるかに効率的である可能性がある。多くの実施形態において、所定のパーティションのデータレコードがシーケンス番号順に書き込まれてもよく、結果的に（例えば、ｇｅｔＮｅｘｔＲｅｃｏｒｄｓまたは同様のインターフェイスを利用する）シーケンス番号順の順次読み出し要求が、ランダム読み出し要求よりもはるかに効率的である場合がある。従って、少なくともいくつかの実施形態では、順次対非順次検索インターフェイスのために異なる課金率が設定されてもよい。例えば、クライアントが非順次読み出しについてより多く課金されてもよい。
（採集サブシステム）
図６は、少なくともいくつかの実施形態による、ＳＭＳの採集サブシステム２０４の例示的な要素を説明する。図示する実施形態においては、採集操作が、データプロデューサ１２０（例、１２０Ａ、１２０Ｂ、又は１２０Ｃ）と対話するものであるフロントエンド関数、およびＳＭＳ記憶サブシステムと対話するものであるバックエンド関数に、論理的に分割される。そのようなフロントエンド／バックエンドの分割は、記憶サブシステムのセキュリティの向上およびデータプロデューサに分割ポリシーを提供する必要性の回避など、いくつかの利点を有する場合がある。ＳＭＳクライアントライブラリ６０２が、様々なデータプロデューサ１２０においてインストールのために提供されてもよく、データプロデューサが、ライブラリ６０２に含まれるプログラムインターフェイスを呼び出して、採集のためのデータを送信してもよい。例えば、１つの実施形態において、データプロデューサ１２０が、数百または数千のプロバイダーネットワークの物理及び／または仮想サーバにおいてインスタンス化されたロギングまたは監視エージェントを含んでもよい。そのようなエージェントは、そのそれぞれのサーバにおける様々なログメッセージ及び／またはメトリクスを収集し、収集されたメッセージまたはメトリクスを、フロントエンド負荷分散機６０４の、ＳＭＳの１つ以上の採集制御ノード６６０によってインスタンス化されたエンドポイントへと周期的に送信してもよい。いくつかの実施形態では、データプロデューサが、ストリームデータを送信する宛先であってもよい負荷分散機のために、１つ以上の仮想ＩＰアドレス（ＶＩＰ）が構築されてもよい。１つの実装においては、データが、データプロデューサ１２０によって送信される宛先であるいくつかの同等に構成される負荷分散機の間から、ＶＩＰが特定の負荷分散機を選択するために、ラウンドロビンＤＮＳ（ドメイン名システム）技術が利用されてもよい。
図示する実施形態においては、受信されたデータレコードがいくつかのフロントエンドノード６０６（例、６０６Ａ、６０６Ｂまたは６０６Ｃ）のいずれかに向けられてもよい。少なくともいくつかの実施形態では、負荷分散機６０４が、データレコードのために利用中である分割ポリシー６５０を認識しない場合がある。従って、所定のデータレコードのために、パーティションを用いたロードバランシングではなくラウンドロビンロードバランシング（またはいくつかの汎用ロードバランシングアルゴリズム）を利用して、フロントエンドノード６０６が選択される可能性がある。フロントエンドノード６０６は、様々なストリームのための分割ポリシー６５０を認識してもよく、所定のパーティションのデータレコードのために構成される特定のバックエンド採集ノード６０８（例、６０８Ａ、６０８Ｂおよび６０８Ｃ）の識別情報を取得するための採集制御ノード６６０と対話してもよい。従って、図示する実施形態においては、データレコードが属するそれぞれのパーティションに基づいて、フロントエンドノード６０４が、複数のバックエンドノード６０６へとデータレコードをそれぞれ送信してもよい。上述のように、データレコードが属するパーティションは、データプロデューサによって供給されるパーティションキー、データプロデューサの識別情報またはアドレスなどの１つ以上の他の属性、またはデータの内容などの様々な要因の任意の組み合わせに基づいて決定されてもよい。
バックエンドノード６０６は、１つ以上のストリームの１つ以上のパーティションに属するデータレコードをそれぞれ受信し、データレコードを記憶サブシステムの１つ以上のノードへと送信してもよい。データがＨＴＴＰ（ハイパーテキスト・トランスファー・プロトコル）「ＰＵＴ」ウェブサービスＡＰＩを介して送信されるいくつかの実施形態において、バックエンドノードは、「ＰＵＴサーバ」と称されることがある。（異なるサブシステムのための制御関数が個別のノード群によって処理される実施形態において、次に記憶サブシステムの制御ノードへと対応するクエリを送信してもよい）制御ノード６６０へとクエリを送信することにより、そのデータレコードが送信される宛先である記憶サブシステムノード群を、所定のバックエンドノードが決定してもよい。
少なくともいくつかの実施形態では、少なくとも１回の採集ポリシーまたはベストエフォート型採集ポリシーなどのいくつかの異なる採集応答ポリシー６５２がサポートされてもよい。少なくとも１回のポリシーにおいては、データプロデューサ１２０が、送信された各データレコードのための肯定応答を要求してもよく、（第１の送信の応答が受信されない場合には）応答が最終的に受信されるまで同じデータレコードを繰り返し送信してもよい。ベストエフォート型採集ポリシーにおいては、（採集サブシステムが時折応答を提供してもよいか、またはデータプロデューサからの応答のための明示的な要求に応答してもよいが）送信された少なくともいくつかのデータレコードのために、肯定応答が要求されない場合がある。採集サブシステム２０４が、データプロデューサに応答を提供することを要求されるいくつかの実施形態では、所定のデータレコードのための役割を担うバックエンド採集ノード６０８は、（例えば、ストリームのために構築される永続性ポリシーに従って）要求される数のデータレコードのレプリカが、応答の生成前に記憶サブシステムにおいて正常に作成されるまで待ってもよい。様々な実施形態においては、例えば、受信された各データレコードのための採集サブシステムによって同じパーティションまたはストリームの他のレコードに対して、レコードが採集された順序を示すシーケンス番号が生成されてもよく、またそのようなシーケンス番号が応答として、または応答の一部として、データプロデューサへと返されてもよい。シーケンス番号に関するさらなる詳細が、図１３ａおよび図１３ｂを参照して以下に示される。いくつかの実装において、応答及び／またはシーケンス番号が、フロントエンドノード６０６を介してデータプロデューサへと送信し返されてもよい。少なくとも１つの実装においては、少なくとも１回のポリシーが採集サブシステム自体のフロントエンドとバックエンドノードとの間で実装されてもよい。例えば、バックエンドノードが応答を提供するまで、所定のフロントエンドノード６０６がデータレコードを適切なバックエンドノード６０８へと繰り返し送信してもよい。
採集制御ノード６６０は、他の関数の間で、ストリームの動的再分割から生じる採集関連の構成操作のためにフロントエンドおよびバックエンドノードを起動し、ノードの健全性および作業負荷レベルを監視し、必要に応じてフェイルオーバーを統合し、どのノードが所定のパーティションのための役割を担うかに関するクエリへの、またはポリシー関連のクエリへの応答を提供する役割を担ってもよい。いくつかの実施形態では、時間の経過に従って、所定の１つ以上のストリーム群のために指定される採集制御ノードの数自体が変更されてもよい。例えば、１つ以上の主制御ノードが、必要に応じて制御ノードプールを再構成する役割を担ってもよい。採集フロントエンドまたはバックエンドノードのために冗長グループが設定されるいくつかの実施形態では、図９および図１０を参照して以下に詳細に述べるように、制御ノード６６０は、どのノードがプライマリであり、どれが非プライマリであるかを把握し、フェイルオーバーのためのトリガする条件を検知し、また選択し、フェイルオーバーを要求されている際に置換を選択する役割を担ってもよい。図６で説明する多層採集サブシステム構造は、いくつかの実施形態では実装されない可能性があることに留意されたい。例えば、いくつかのシナリオでは、単一の採集ノード群のみが構成されてもよい。
記憶サブシステム
図７は、少なくともいくつかの実施形態による、ＳＭＳの記憶サブシステムの例示的な要素を説明する。図示のように、採集ノード６０８（例、異なるノード群によってフロントエンドおよびバックエンド採集の役割が果たされる実施形態におけるバックエンド採集ノード）が、ストリームの１つ以上のパーティションのデータレコードをこれらのパーティションのために構成されるそれぞれの記憶ノード７０２へと送信してもよい。例えば、パーティションＳ１〜Ｐ１のデータレコード１１０Ａが、記憶ノード７０２Ａへと送信され、パーティションＳ２〜Ｐ３のデータレコード１１０Ｂが、記憶ノード７０２Ｂおよび７０２Ｃへと送信され、パーティションＳ３〜Ｐ７のデータレコード１１０Ｃが、記憶ノード７０２Ｄへと送信され、また、パーティションＳ４〜Ｐ５のデータレコード１１０Ｄが、最初に記憶ノード７０２Ｅへと送信される。図示する実施形態においては、異なるストリームのデータレコードに適用される永続性ポリシー７５０を実行し、必要に応じて記憶ノードを構成しかつ再構成し、記憶ノード状態を監視し、フェイルオーバーを管理し、記憶構成クエリまたは記憶ポリシークエリに応答し、また様々な他の管理タスクを行う役割を、記憶制御ノード７８０が担ってもよい。
永続性ポリシー７５０は、異なる実施形態において、様々な方法で互いに異なってもよい。例えば、ストリームＳｊに適用される永続性ポリシーＰ１は、（ａ）記憶される各データレコードのレプリカ数、（ｂ）レプリカが記憶される記憶装置またはシステムのタイプ（例えば、揮発性メモリ、不揮発性キャッシュ、回転式ディスクベースの記憶装置、半導体ドライブ（ＳＳＤ）、様々な種類の記憶装置、様々な種類のＲＡＩＤ（低価格ディスクの冗長アレイ）に、データベース管理システムに、プロバイダーネットワークによって実装される記憶サービスのノードなどにレプリカが記憶されるかどうか）、（ｃ）レプリカの地理的分布（例えば、レプリカを異なるデータセンターに配置してストリームデータが大規模障害または特定のタイプの災害から回復できるようにするかどうか）、（ｄ）書き込み応答プロトコル（例えばＮ個のレプリカが記憶される場合、応答が採集ノードに提供されなければならなくなる前に、Ｎ個のうちいくつのコピーが正常に書き込まれなければならないか）、及び／または（ｅ）データレコードの複数のレプリカが記憶される場合に、レプリカが並列かまたは順次のいずれによって作成されるべきか、という点において、ストリームＳｋに適用されるポリシーＰ２と異なってもよい。データレコード１１０Ｄの場合のように、複数のレプリカが記憶される他の場合においては、所定の記憶ノードがデータレコードを別の記憶ノードに送信してもよい（例えば、記憶ノード７０２Ｅが、データレコード１１０Ｄをさらなる複製のために記憶ノード７０２Ｆに送信し、記憶ノード７０２Ｆが、それを記憶ノード７０２Ｇへと送信する）。２つのインメモリレプリカが記憶されるデータレコード１１０Ｂの場合のように、複数のレプリカ永続性ポリシーが利用される他の場合には、採集ノードは、複数の複製を並列に起動してもよい。少なくともいくつかの実施形態では、クライアントが選択する永続性ポリシーが、ストリームデータレコードのために利用される記憶位置のタイプを特定しない可能性があり、代わりにコスト、パフォーマンス、データソースへの近接性、持続性要件などの様々な基準に基づき、ＳＭＳが記憶技術及び／または位置の適切なタイプを選択してもよい。１つの実施形態において、クライアントまたはＳＭＳのいずれかが所定のストリームの異なるパーティションのために、または異なるストリームのために異なる記憶技術または記憶位置タイプを利用することを決定してもよい。
図７における実施例においては、ストリームＳ１（または少なくともストリームＳ１のパーティションＳ１〜Ｐ１）に適用される永続性ポリシーは、単一のレプリカインメモリポリシーであり、一方ストリームＳ２については、２つの並行レプリカインメモリポリシーが適用される。従って、データレコード１１０Ａのインメモリレプリカ７０４Ａが、記憶ノード７０２Ａにおいて作成され、一方データレコード１１０Ｂに対応する２つのインメモリレプリカ７０５Ａおよび７０５Ｂが、記憶ノード７０２Ｂおよび７０２Ｃにおいて並列に作成される。ストリームＳ３のデータレコード１１０Ｃについては、単一のオンディスクレプリカ７０６Ａが作成される。ストリームＳ４については、ディスク上の順次の３つのレプリカポリシーが適用可能であり、結果的にそれぞれのオンディスクレプリカ７０７Ａ、７０７Ｂおよび７０７Ｃが、記憶ノード７０２Ｅ、７０２Ｆおよび７０２Ｇにおいて順次に作成される。様々な他のタイプの永続性ポリシーが、異なる実施形態においてデータストリームに適用されてもよい。データコンシューマによる様々な種類の検索ＡＰＩの呼び出しに応じて、検索サブシステムのノードが、適切な記憶ノードからデータレコードを取得してもよい。
検索サブシステムおよび処理ステージ
図８は、少なくともいくつかの実施形態による、ＳＭＳの検索サブシステムの例示的な要素および検索サブシステムのＳＰＳとの対話の実施例を説明する。図示のように、検索サブシステム２０６は、検索ノード８０２Ａ、８０２Ｂおよび８０２Ｃなどの複数の検索ノード８０２を、検索制御ノード８８０群と同様に含んでもよい。各検索ノード８０２は、以下に述べるようにＳＰＳのワーカーノード８４０などの様々なクライアントまたはデータコンシューマ１３０からのストリームデータ検索要求に応答するよう構成されてもよい。異なる実施形態において、上述の非順次および順次検索インターフェイスなどの多様なプログラム検索インターフェイス８０２は、検索ノードによって実装されてもよい。いくつかの実施形態では、ＨＴＴＰ ＧＥＴ要求などのウェブサービスＡＰＩが、データレコード検索のために利用されてもよく、従って、検索ノード８０２は、ＧＥＴサーバと称される場合がある。所定の検索ノード８０２は、例えば、検索制御ノード８８０によって、図示する実施形態における記憶ノード７０２Ａおよび７０２Ｂなどの適切な記憶サブシステムノード７０２群から、１つ以上のストリームパーティションのデータレコードを取得するよう構成されてもよい。
図示する実施形態においては、検索ノード８０２が、１つ以上の記憶ノード７０２と対話し、また１つ以上のＳＰＳワーカーノード８４０から受信された検索要求に応答してもよい。例えば、パーティションＳ４〜Ｐ５のデータレコード（例、データレコード１１０Ｋ）およびＳ５〜Ｐ８のデータレコード（例、データレコード１１０Ｌ）が、検索ノード８０２Ａによって記憶ノード７０２Ａから読みだされ、ワーカーノード８４０Ａおよび８４０Ｋのそれぞれに提供される。１１０ＭなどのパーティションＳ６〜Ｐ７のデータレコードが、検索ノード８０２Ｂによって記憶ノード７０２Ａから読み出され、ワーカーノード８４０Ｋに提供される。パーティションＳ４〜Ｐ７のデータレコードが、検索ノード８０２Ｃによって記憶ノード７０２Ｂから読み出され、ワーカーノード８４０Ｂおよび他のデータコンシューマ１３０（例、ＳＰＳを介してＳＭＳと対話する代わりにＳＭＳ検索ＡＰＩを直接呼び出すデータコンシューマ）に提供される。
少なくともいくつかの実施形態では、今後の検索要求を予期して様々なパーティションのデータレコードが一時的に保持されてもよい、それぞれのキャッシュ８０４（検索ノード８０２Ａにおけるキャッシュ８０４Ａ、検索ノード８０２Ｂにおけるキャッシュ８０４Ｂ、および検索ノード８０２Ｃにおけるキャッシュ８０４Ｃなど）を検索ノード８０２の一部または全部が実装してもよい。例えば、キャッシングポリシー（例えば、所定のパーティションのためにどのような大きさのキャッシュが構成されるべきか、どのような長さのデータレコードがキャッシュされるべきか）、記憶ノード選択ポリシー（例えば、データレコードの複数のレプリカが記憶されるシナリオにおいて、所定のデータレコードを取得するためにまずどの特定の記憶ノードが連絡されるべきか）などを含めて、いくつかの検索ポリシー８８２を実装する役割を、検索制御ノード８８０が担ってもよい。加えて、検索制御ノードが、検索ノード８０２をインスタンス化および監視し、どの検索ノードがどのパーティションのための役割を担うかに関するクエリに応答し、再分割操作を起動しそれに応答する、などの役割を担ってもよい。
説明する実施例においては、ＳＰＳ２９０が、２１５Ａおよび２１５Ｂの２つの処理ステージを含む。ＳＰＳ制御ノード８８５は、様々な処理ステージ２１５において、パーティションＳ４〜Ｐ５のレコードを処理するためのワーカーノード８４０Ａ、パーティションＳ４〜Ｐ７のレコードを処理するためのワーカーノード８４０Ｂ、およびパーティションＳ５〜Ｐ８およびＳ６〜Ｐ７のレコードを処理するためのワーカーノード８４０Ｋを含むワーカーノード８０４、をインスタンス化する役割を担ってもよい。ＳＰＳ制御ノード８８５は、ＳＰＳクライアントによる処理ワークフローの設計を可能にするプログラムインターフェイス（図３および図４において説明されるプログラムインターフェイスなど）を実装してもよい。ワーカーノードがプログレスレコードを記憶するかどうか、またそれがいつかを示し、それらのそれぞれのパーティションをどの程度処理するかを示す、異なる処理ステージまたはワークフロー、プログレスレコードのために利用される記憶装置のタイプなどのために、様々なチェックポイントポリシー８５０が実装されてもよい。フェイルオーバー／回復ポリシー８５２は、ワーカーノードの異なるノードへの交換につながるトリガする条件または閾値を示し、また、所定の処理ステージのためにベストエフォート型回復が利用されるか、またはチェックポイントを用いた回復が利用かどうかを示してもよい。少なくともいくつかの実施形態では、例えば、所定のストリームのデータレコードが取得される検索ノードを識別するため、また特定の処理ワークフローのために要求されてもよい新しい一時または永続性ストリームを構築するなどのために、ＳＰＳ制御ノード８８５は、様々な種類のＳＭＳ制御ノードと対話してもよい。少なくとも１つの実施形態において、ストリームをインスタンス化するために、クライアントは、ＳＰＳ制御ノードと対話してもよい。例えば、ＳＭＳ制御インターフェイスを利用する代わりに、いくつかのクライアントが、上位ＳＰＳインターフェイスのみの呼び出しを望む場合がある。図６、７および８において、ＳＭＳ採集、記憶および検索サブシステムのために、またＳＰＳステージのために、個別の制御ノード群が示されるが、少なくともいくつかの実施形態では、いくつかのサブシステム及び／またはＳＰＳのために、所定の制御ノードが利用されてもよいことに留意されたい。
ノード冗長グループ
少なくともいくつかの実施形態では、ノードの冗長グループがＳＭＳの１つ以上のサブシステムのために構成されてもよい。すなわち、例えば、ストリームパーティションＳｊ〜Ｐｋのためのデータレコードを検索するための１つの検索ノードを構成する代わりに、２つ以上のノードが、そのような検索のために構築され、所定の時点において１つのノードに「プライマリ」またはアクティブな役割が授けられ、一方他の１つ以上のノードが「非プライマリ」ノードとして指定されてもよい。現在のプライマリノードが、例えば、クライアントまたは他のサブシステムのノードのいずれかから受信される要求などの作業要求に応答する役割を担ってもよい。フェイルオーバーがトリガされるまで、例えば、障害、プライマリへの接続の喪失または他のトリガする条件のために、前のプライマリの役割を引き継ぐために、選択される非プライマリが制御ノードによって通知されてもよい時点まで、１つ以上の非プライマリノードが、休止状態のままであってもよい。従って、フェイルオーバー中に現在のプライマリノードからプライマリの役割が取り消されて、現在の非プライマリノードに授けられてもよい。いくつかの実施形態では、フェイルオーバーが発生することが決定される、例えば、明示的な通知が要求されない場合に、非プライマリノード自体がプライマリとして引き継いでもよい。様々な実施形態のＳＭＳにおいて、採集、記憶、検索及び／または制御関数のためにノードのそのような冗長グループが設定されてもよく、また少なくともいくつかの実施形態のＳＰＳにおいて、ワーカーノードのために同様の手法がとられてもよい。いくつかの実施形態では、所定の関数のために、少なくとも１つのプライマリノードおよび少なくとも１つの非プライマリノードを含むそのようなグループは、「冗長グループ」または「複製グループ」と称されることがある。記憶ノードの冗長グループが記憶させるデータレコードの物理コピーの数とは独立的に実装されてもよいことに留意されたい。例えば、記憶されるデータレコードのレプリカ数は、永続性ポリシーによって決定するされてもよく、一方、対応するパーティションのために構成される記憶ノード数は、冗長グループポリシーに基づいて決定されてもよい。
図９は、少なくともいくつかの実施形態による、ＳＭＳまたはＳＰＳのノードのために設定されてもよい冗長グループの実施例を説明する。図示する実施形態においては、所定のストリームパーティションＳｊ〜Ｐｋのために、それぞれの冗長グループ（ＲＧ）９０５、９１５、９２５および９３５が、採集ノード、記憶ノード、検索ノードおよび制御ノードのために設定される。いくつかの実施形態では、採集制御ノード、記憶制御ノードまたは検索制御ノードのための個別のＲＧが実装されてもよいが、制御ノードのための共通のＲＧ９３５が、説明する実施形態において実装される。各ＲＧは、プライマリノード（例、プライマリ採集ノード９１０Ａ、プライマリ記憶ノード９２０Ａ、プライマリ検索ノード９３０Ａおよびプライマリ制御ノード９４０Ａ）および少なくとも１つの非プライマリノード（例、非プライマリ採集ノード９１０Ｂ、非プライマリ記憶ノード９２０Ｂ、非プライマリ検索ノード９２０Ｃおよび非プライマリ検索ノード９２０Ｄ）を含む。それぞれの（採集ノードのための）フェイルオーバーポリシー９１２、（記憶ノードのための）９２２、（検索ノードのための）９３２および（制御ノードのための）９４２に従って、プライマリの役割は取り消され、また現在の非プライマリに授けられてもよい。フェイルオーバーポリシーは、例えば、プライマリまたは非プライマリの健全性状態が監視されるかどうか、またその方法、所定の冗長グループにおいて構成される非プライマリの数などの、プライマリ状態の変更につながるトリガする条件を左右してもよい。少なくともいくつかの実施形態では、複数のパーティションのために単一のＲＧが構築されてもよい。例えば、ＲＧ９０５が、パーティションＳｊ〜ＰｋおよびＳｐ〜Ｐｑのレコードの採集を処理する役割を担ってもよい。いくつかの実装においては、あるパーティションのためにプライマリとして指定されるノードが、別のパーティションのための非プライマリとして同時に指定されてもよい。１つの実施形態において、所定のＲＧ内で複数のノードが、プライマリノードとして同時に指定されてもよい。例えば、いずれかのプライマリの障害時に１つのノードが、プライマリ非プライマリとして指定され、所定のパーティションの採集関連の作業負荷が、２つのプライマリノードの間で分散されてもよい。所定のＲＧにおいてインスタンス化されるノード数が、対応する関数のために所望される可用性または回復力レベルに（例えば、いくつの同時並行的または重複する障害にグループが耐えられるように意図されているかに）依存してもよい。いくつかの実施形態では、ＳＭＳノードのための利用に加えて、またはその代わりに、冗長グループが、ＳＰＳ処理ステージのワーカーノードのために設定されてもよい。図１０で説明するように、所定のＲＧの構成要素が、時に、例えば、いくつかのデータセンターにまたがって地理的に分散されてもよい。いくつかの実施形態では、例えば、ハートビート機構または他の健全性モニタリング技術を利用して選択される制御ノードが、フェイルオーバーをトリガする条件を検知するよう構成されてもよく、適切な非プライマリノードを故障したプライマリの置換として選択し、選択された置換ノードを通知し／起動することなどによって、そのような制御ノードがフェイルオーバーを統合してもよい。
いくつかの実施形態では、プロバイダーネットワークが複数の地域に組織されてもよく、各地域には、本明細書内で「アベイラビリティゾーン」と称する場合がある１つ以上の可用性コンテナを含んでもよい。同様に、所定の可用性コンテナにおけるリソースが、他の可用性コンテナにおいては障害から隔離されるような（例えば、電源関連の機器、冷却機器、物理セキュリティコンポーネントなどの独立したインフラストラクチャコンポーネントを利用する）方法で操作される、１つ以上の別々の位置またはデータセンターを可用性コンテナが含んでもよい。ある可用性コンテナにおける障害は、他の任意の可用性コンテナにおける障害につながることを予期できない場合がある。従って、リソースインスタンスまたは制御サーバの可用性プロファイルは、異なる可用性コンテナにおけるリソースインスタンスまたは制御サーバの可用性プロファイルから独立するよう意図される。それぞれの可用性コンテナにおいて複数のアプリケーションインスタンスを起動するか、または（いくつかのＳＭＳおよびＳＰＳの場合において）所定の冗長グループのノードを複数の可用性コンテナに分散させることによって、様々な種類のアプリケーションが、単一の位置における障害から保護されてもよい。同時にいくつかの実装においては、同じ地域に存在するリソース（ＳＭＳおよびＳＰＳノードのために利用されるホストまたは計算インスタンスなど）間で安価かつレイテンシの低いネットワーク接続性が提供されてもよく、また、同じ可用性コンテナのリソース間のネットワーク送信がより早い場合がある。例えば、地域レベル、可用性コンテナレベルまたはデータセンターレベルのいずれかで、それらのアプリケーションが実行される様々なコンポーネントの正確な位置の、所望される制御程度を維持するために、それらのストリーム管理またはストリーム処理リソースが確保され、及び／またはインスタンス化される位置の特定を、いくつかのクライアントが望む場合がある。リソースが、例えば、パフォーマンス、高可用性などのためのクライアント要件に適合する限り、リソースが確保され、またはインスタンス化される正確な位置に他のクライアントが、興味を示さない場合がある。いくつかの実施形態では、１つの可用性コンテナ（またはデータセンター）に位置する制御ノードが、他の可用性コンテナ（または他のデータセンター）において他のＳＭＳまたはＳＰＳノードを遠隔で構成することができる場合がある。すなわち、特定の可用性コンテナまたはデータセンターは、ＳＭＳ／ＳＰＳノードを管理するローカル制御ノードを有する必要がない場合がある。
図１０は、少なくともいくつかの実施形態による、所定の冗長グループのノードが複数のデータセンターの間で分散されてもよいプロバイダーネットワーク環境を説明する。図示する実施形態において、プロバイダーネットワーク１００２は、コンテナ１００３Ａ、１００３Ｂおよび１００３Ｃの３つの可用性を含む。各可用性コンテナは、１つ以上のデータセンターの一部または全部を含む。例えば、可用性コンテナ１００３Ａはデータセンター１００５Ａおよび１００５Ｂを含み、可用性コンテナ１００３Ｂはデータセンター１００５Ｃを含み、また可用性コンテナ１００３Ｃはデータセンター１００５Ｄを含む。ＳＭＳ及び／またはＳＰＳノードのいくつかの異なる冗長グループ１０１２が示される。いくつかのＲＧ１０１２は、データセンター１００５Ａ内に位置するＲＧ１０１２Ａの場合のように、単一のデータセンター内で完全に実装されてもよい。可用性コンテナ１００３Ａのデータセンター１００５Ａおよび１００５Ｂに及ぶＲＧ１０１２Ｂなどの他のＲＧは、所定の可用性コンテナ内の複数のデータセンター内のリソースを利用してもよい。異なる可用性コンテナに広がるリソースを利用して、さらに別のＲＧが実装されてもよい。例えば、ＲＧ１０１２Ｃは、可用性コンテナ１００３Ａおよび１００３Ｂのそれぞれのデータセンター１００５Ｂおよび１００５Ｃに位置するリソースを利用し、ＲＧ１０１２Ｄは、可用性コンテナ１００３Ａ、１００３Ｂおよび１００３Ｃそれぞれのデータセンター１００５Ｂ、１００５Ｃおよび１００５Ｄにおけるリソースを利用する。１つの実施例の展開においては、ＲＧ１０１２が、１つのプライマリおよび２つの非プライマリノードを含む場合、３つのノードのそれぞれが異なる可用性コンテナに位置してもよく、それによって、２つの異なる可用性コンテナにおいて同時に大規模障害事象が発生したとしても少なくとも１つのノードが機能したままでいる可能性が高くなる。
図示する実施形態において、ストリーム関連の設定をプロバイダーネットワーク１００２内で構成するために、ＳＭＳおよびＳＰＳそれぞれに関連するコンソールサービス１０７８および１０７６が使いやすいウェブベースのインターフェイスを提供してもよい。そのうち少なくともいくつかが、ＳＭＳ及び／またはＳＰＳによって利用されてもよいいくつかの付加的なサービスが、１つ以上のデータセンターまたは１つ以上の可用性コンテナに広がるリソースを利用して、プロバイダーネットワーク１００２において実装されてもよい。例えば、クライアントが様々な異なる能力レベルの計算インスタンスとして実装される、選択された度合いの計算能力を利用することを可能にする仮想計算サービス１０７２が実装されてもよく、そのような計算インスタンスが、ＳＭＳ及び／またはＳＰＳノードを実装するために利用されてもよい。クライアントが、例えば、ブロックデバイスボリュームインターフェイスまたはウェブサービスインターフェイスのいずれかを介して、所望のデータ持続性レベルでデータオブジェクトを記憶させ、それにアクセスすることを可能にする、１つ以上の記憶サービス１０７０が実装されてもよい。いくつかの実施形態では、記憶オブジェクトがサービス１０７２の計算インスタンスに取り付け可能であり、それからアクセス可能であってもよく、またＳＭＳ記憶サブシステムにおいて様々なストリーム永続性ポリシーを実装するために利用されてもよい。１つの実施形態において、高性能キー値データベース管理サービス１０７４または関係するデータベースサービスなどの１つ以上のデータベースサービスが、プロバイダーネットワーク１００２において実装されてもよく、ＳＭＮＳ記憶サブシステムによってストリームデータレコードを記憶させるため、及び／または制御サブシステム、採集サブシステム、記憶サブシステム、検索サブシステムもしくは処理ステージのメタデータを記憶させるために、そのようなデータベースサービスが利用されてもよい。
ストリームセキュリティオプション
少なくともいくつかの実施形態では、ＳＭＳ及び／またはＳＰＳのユーザにデータストリームのためのいくつかのセキュリティ関連のオプションが提供され、クライアントが採集、記憶、検索、処理及び／または制御などの様々な機能カテゴリのために利用されるリソース（例、仮想または物理マシン）のセキュリティプロファイルを選択することを可能にしてもよい。そのようなオプションは、例えば、様々なノードのために利用されるリソースの物理的位置のタイプに関する選択（例えば、プロバイダーネットワーク設備が利用されるか、またはプロバイダーネットワーク設備とは異なるセキュリティ特徴を有してもよいクライアント所有の設備が利用されるかのどちらか）、ストリームデータの暗号化に関する選択、及び／またはストリーム処理インフラストラクチャの様々な部分におけるネットワーク隔離の選択を含んでもよい。例えば、侵入者または攻撃者が価値のある独自のビジネスロジックまたはアルゴリズムへのアクセスを取得する可能性に関して一部のクライアントが懸念を抱き、クライアント所有の敷地内の計算装置を利用するストリーム処理ワーカーノードの実装を望む可能性がある。ＳＭＳ及び／またはＳＰＳノード群を実装するために利用されるリソースのタイプは、本明細書内でこれらのノードのための「配置先タイプ」と称する場合がある。図１１は、少なくともいくつかの実施形態による、ＳＭＳまたはＳＰＳのノードのために選択されてもよい複数の配置先を説明する。
図示する実施形態においては、いくつかのタイプのＳＭＳ／ＳＰＳ機能カテゴリ（例、採集、記憶、検索、制御または処理）のためのプロバイダーネットワーク１１０２内で、また他のタイプのＳＭＳ／ＳＰＳ機能カテゴリのためのプロバイダーネットワーク１１０２外で、配置先が選択されてもよい。プロバイダーネットワーク１１０２内では、マルチテナント・インスタンスホスト１１０３を利用して、計算インスタンス、ストレージインスタンスまたはデータベースインスタンスなどのいくつかのリソースが実装されてもよい。そのそれぞれにおいて１つ以上のクライアントのためのＳＭＳまたはＳＰＳノードがインスタンス化されてもよい、そのようなマルチテナント・インスタンスホストは、配置先タイプの第１のカテゴリ「Ａ」を形成してもよい。物理リソースを他のクライアントと共有する必要性を回避するため、それらのＳＭＳ／ＳＰＳノードが、単一のクライアントに制限されるインスタンスホストを利用して実装されることを、いくつかのクライアントが要求してもよい。そのようなシングルテナント・インスタンスホストは、配置カテゴリタイプ「Ｂ」を形成してもよい。シングルテナント・インスタンスホストは、いくつかの理由により一部のクライアントの観点から望ましい場合がある。マルチテナント・インスタンスホストが、他のクライアントに属する計算インスタンスを含んでもよいため、別のクライアントのインスタンスからのセキュリティ攻撃の可能性が、マルチテナント・インスタンスホストにおいては、シングルテナント・インスタンスホストよりも高い場合がある。加えてシングルテナント・インスタンスホストが利用される際には、マルチテナントホスト上で動作する、あるクライアントの計算インスタンスＣＩ１が、その作業負荷の急増を経験してホストの計算サイクルまたは他のリソースの大半の消費を開始し、従って、異なる計算インスタンスＣＩ２上で動作する別のクライアントのアプリケーションのパフォーマンスに潜在的に影響を与える「ノイジーネイバー」現象もまた回避されてもよい。
図示する実施形態においては、ＩＶＮ１１０６Ａおよび１１０６Ｂなどの隔離された仮想ネットワーク（ＩＶＮ）１１０６は、配置先タイプの別のカテゴリ「Ｃ」を表してもよい。いくつかの実施形態では、ＩＶＮ１１０６は、プロバイダーネットワーククライアントの要求において、プロバイダーネットワークリソースを利用するがクライアントによって大部分を制御されるネットワーク構成を有して構築されるプライベートネットワークの論理的等価物として作成されてもよい。例えば、クライアントは、ＩＶＮの外部ですでに利用されている場合があるＩＰアドレスの複製の可能性について懸念する必要なく、ＩＶＮ１１０６内で利用されるＩＰアドレスを決定してもよい。図示する実施形態においては、１つ以上のＩＶＮにおける様々な種類のＳＭＳおよびＳＰＳノードの実装により、クライアントのストリームデータの管理及び／または処理により高いレベルのネットワークセキュリティが追加されてもよい。場合によっては、ＳＭＳ／ＳＰＳノードの１つの機能カテゴリを１つのＩＶＮ１１０６に、また異なる機能カテゴリを異なるＩＶＮに配置することを所定のクライアントが望む場合がある。様々な実施形態において、所定のＩＶＮ１１０６は、シングルテナント・インスタンスホスト、マルチテナント・インスタンスホストのいずれか、または両方のタイプのインスタンスホストを含んでもよい。いくつかの実施形態では、図１１に示されない、プロバイダーネットワークのリソースを利用した配置先タイプの別の一連の選択（またはセキュリティプロファイルの選択）が、少なくとも一部のクライアントにとって利用可能であってもよい。クライアントが、ストリーム関連の操作のためのプロバイダーネットワークの仮想化された計算サービスから計算インスタンスを取得し利用することができる実施形態においては、計算インスタンスが、１つまたは２つのモードで利用されてもよい。１つのモードでは、クライアントがＳＰＳまたはＳＭＳに、ＳＰＳワーカーノードとして（または採集、記憶もしくは検索ノードにおいて）構成される計算インスタンスにおいて実行される、１つ以上の実行可能プログラムまたはプログラムを提供してもよく、また、ＳＭＳまたはＳＰＳにプログラムを実行させてノードを管理させてもよい。この第１のモードは、ストリーム操作のための計算インスタンスの利用の「ストリームサービス管理」モードと称されることがある。他のモードでは、クライアントが、ＳＰＳまたはＳＭＳからのサポートを減らした実行可能プログラムの実行および計算インスタンスの管理を望む場合がある。この第２のモードは、ストリーム操作のための計算インスタンスの利用の「クライアント管理」モードと称することがある。従って、操作のこれらの２つのモードは、クライアントによる選択が可能な配置先タイプまたはセキュリティプロファイルに関連する付加的な選択を表してもよい。例えば、実行可能プログラムがクライアントの組織からの目的物の専門家によって最適に実行することができる（シングルステップを含む）デバッグを要求する可能性がある場合に、クライアントがクライアント管理モードを選んでもよい。一方で、ストリームサービス管理モードが、デバッグを要求する可能性があるより成熟したコードにとって合理的な選択であってもよい。いくつかの実施形態では、異なる価格ポリシーが、これら２つのモードに適用してもよい。
図１１に示す実施形態においては、いくつかの配置オプションがプロバイダーネットワークの外部の設備においてサポートされてもよい。例えば、ＳＭＳライブラリ１１７１及び／またはＳＰＳライブラリ１１７２がインストールされるホスト１１６０が、プロバイダーネットワークへの接続方法が異なる２つのタイプのクライアント設備であるクライアント設備（例、クライアント所有のデータセンターまたは敷地）１１１０Ａまたは１１１０Ｂ内からのストリーム管理または処理のために利用されてもよい。クライアント設備１１１０Ａは、少なくともいくつかの共有インターネットリンク１１５１を介してプロバイダーネットワーク１１０２にリンクされる（すなわち、クライアント設備１１１０Ａとプロバイダーネットワーク１１０２との間のリンクの一部で他の法人のネットワークトラフィックも流れてもよい）。対照的にいくつかのクライアント設備（１１１０Ｂなど）は、（「直接接続」リンクと時に称される場合がある）特別な非共有の専用物理リンク１１０６を介してプロバイダーネットワークにリンクされてもよい。これら２つの異なるタイプのクライアントの敷地は、図１１において利用される用語で、それぞれ配置先オプション「Ｄ」および「Ｅ」を含む。いくつかの実施形態では、ＳＭＳ及び／またはＳＰＳの一部もまた、サードパーティの設備（例えば、ＳＭＳ／ＳＰＳのクライアントによって利用されるが所有も管理もされていないデータセンター）において実装可能であってもよく、またそのようなサードパーティの敷地が、配置先タイプ「Ｆ」として指定されてもよい。少なくともいくつかのクライアント及び／またはサードパーティの敷地において、ＳＭＳ及び／またはＳＰＳライブラリがプロバイダーネットワークから取得され、ＳＭＳ／ＳＰＳノードのために利用されるホストにおいてインストールされなければならない可能性がある。少なくとも１つの実施形態においては、すべての異なる機能カテゴリのノードが、適切なライブラリを用いてプロバイダーネットワークの外部で実装されてもよい。
異なる配置先タイプについては、実装されるネットワーク隔離の特徴、サポートされる侵入検知機能、実装される物理セキュリティポリシー、サポートされる暗号化レベルなどの、異なる実施形態における様々なセキュリティ関連の態様が互いに異なってもよい。従って、様々な宛先タイプのそれぞれが、他の配置先のセキュリティプロファイルと１つ以上の方法で異なる可能性があるそれぞれのセキュリティプロファイルを有すると見なされてもよい。いくつかの実施形態では、図１２ａおよび１２ｂにおいて説明するように、例えば、ＳＭＳまたはＳＰＳの１つ以上の制御ノードに要求を送信することにより、ＳＭＳ及び／またはＳＰＳのクライアントが異なるサブシステムまたはノード群のための、それぞれの配置先タイプをプログラムで選択してもよい。いくつかの実施形態において、またストリームアプリケーションの特定のタイプのために、セキュリティ上の理由のみのためではなく、同様にパフォーマンス及び／または機能上の理由から、クライアントが配置先タイプの制御を望んでもよいことに留意されたい。例えば、専用のクライアント敷地のリソースまたはシングルテナント・インスタンスホストを利用することで、上述のノイジーネイバー現象が回避されてもよい。いくつかの実施形態では、ＳＰＳステージまたはＳＭＳノードのために利用することをクライアントが望む、そのようなコンポーネントを利用することで達成可能な機能またはパフォーマンスレベルはプロバイダーネットワークにおいて容易に複製することができず、またはプロバイダーネットワークにおいて単純にサポートされない、専用または独自のハードウェア及び／またはソフトウェアをクライアントが有してもよい。クライアントは外部のデータセンターにおいて、例えば、プロバイダーネットワークリソースのみを利用した場合に可能であるよりもはるかに高い割合でＳＰＳ処理を実行することができる場合がある、スーパーコンピュータレベルの処理能力を用いたコンピュータサーバへのアクセスを有してもよい。クライアントによる様々なノードのための配置先の選択を可能にすることにより、そのような専用装置またはソフトウェアが利用できるようになる場合がある。
図１２ａおよび１２ｂは、少なくともいくつかの実施形態による、ＳＰＳクライアントおよびＳＭＳクライアントによってそれぞれ送信されてもよいセキュリティオプション要求の実施例を説明する。図１２ａは、クライアントが識別子１２１０を有する１つ以上の処理ステージのために、ステージ（要素１２１２）の制御ノードのために要求される配置先タイプ（ＰＤＴ）およびワーカーノード（要素１２１４）のために要求されるＰＤＴを示す、ＳＰＳセキュリティオプション要求１２００を説明する。少なくとも１つの実施形態において、クライアントはまた、例えば、特定のアルゴリズムまたはプロトコルを利用した、様々なネットワークリンクでの送信前のデータレコードの暗号化または様々な制御または管理上の対話の暗号化を要求することによって、それらのストリームデータレコードまたはストリーム処理結果のための暗号化設定を構成するための要求を送信することが可能である場合がある。例えば、図１２ａにおいては、ステージのための暗号化設定が、ステージ処理操作結果及び／またはステージの制御ノードとステージのワーカーノードとの間の通信のために利用される暗号化に適用される暗号化技術を示してもよい。
同様に図１２ｂにおいては、クライアントのＳＭＳセキュリティオプション要求１２５０が、特定の識別子１２５２を有する１つ以上のストリームに対するクライアントのセキュリティの選好を示すいくつかの要素を含む。採集ノード、記憶ノードおよび検索ノードに対する配置先タイプの選好が、要素１２５４、１２５８および１２６２のそれぞれにおいて示されてもよい。採集制御ノード、記憶制御ノードおよび検索制御ノードに対するＰＤＴの選好が、要素１２５６、１２６０および１２６４のそれぞれによって示されてもよい。例えば、データレコードがあるカテゴリのノードから別のカテゴリのノードに送信される際にデータレコードのために暗号化が実装されるかどうか、及び／またはその方法などの、データレコードに対する暗号化の選好が、要素１２６６を介して示されてもよい。図１２ａおよび１２ｂに示されるようなセキュリティオプション要求を利用して、クライアントはそれらのストリーム管理および処理環境の異なる部分のための位置（例、プロバイダーネットワーク内、またはプロバイダーネットワークの外部）および様々な他のセキュリティプロファイルコンポーネントを選択することができる場合がある。
少なくともいくつかの実施形態では、セキュリティ以外の理由からノード配置先の選択が提供されてもよいことに留意されたい。例えば、（例えば、「ノイジーネイバー」問題を回避するためなどの、主にセキュリティ上の理由よりも早期に示されるパフォーマンス上の理由から、クライアントがシングルテナントホストにおいて実装されるいくつかのタイプのＳＭＳまたはＳＰＳノードを有することを望む場合がある。少なくともいくつかの実施形態では、ストリームの生存時間中に配置選択が変更されてもよい。例えば、クライアントが最初にマルチテナント・インスタンスホストにおけるＳＭＳノードのインスタンス化を可能にしてもよいが、ノードの少なくともいくつかのサブセットのシングルテナント・インスタンスホストへの移動をその後に望んでもよい。少なくともいくつかの実施形態では、異なる価格ポリシーが異なるセキュリティ関連のオプションに適用されてもよい。例えば、ＩＶＮにおいて特定の機能カテゴリのＳＭＳノードを実装する方がＩＶＮ外のマルチテナント・インスタンスホストにおいて実装するよりも費用がかかる場合があるか、またはシングルテナント・インスタンスホストにおいてＳＭＳノードを実装する方が、マルチテナント・インスタンスホストにおいて実装するよりも費用がかかる場合がある。
（ストリームレコードの順次記憶および検索）
多くの種類のストリームアプリケーションのために、データレコードがＳＭＳにおいて複数のデータプロデューサ１２０から非常に高い割合で受信されてもよく、データコンシューマは通常、レコードが生成された順序で記憶されたデータレコードにアクセスすることを望む可能性がある。上述のように、特に回転式磁気ディスクが、ストリームデータレコードのための記憶装置として利用される環境においては、（読み書き両方のための）順次Ｉ／Ｏアクセスパターンが、ランダムＩ／Ｏアクセスパターンに対して重大な性能優位性を有してもよい。いくつかの実施形態、ストリームに特有の、または、パーティションに特有のシーケンス番号が、ＳＭＳから受信されたようにデータレコードに割り当てられてもよく、シーケンス番号に基づく順次検索操作がサポートされてもよい。図１３ａは、少なくともいくつかの実施形態によるストリームデータプロデューサとＳＭＳの採集ノードとの間の対話の実施例を説明する。ストリームデータプロデューサは、データレコード１１０を採集サブシステムへと送信してもよく、また図示する実施形態においては、採集サブシステムが送信されるレコードのために選択されたシーケンス番号１０２を用いて応答してもよい。少なくともいくつかの実施形態では、採集ノードがシーケンス番号の一部を記憶サブシステムから取得してもよい。例えば、そのような実施形態においては、受信されるデータレコードの記憶に続き、シーケンス番号１０２が適用可能な永続性ポリシーに従って決定されてもよく、記憶サブシステムがデータレコードのためのそれ自体の番号順のインジケータを生成し、採集ノードによってデータレコードに割り当てるさらに大きなシーケンス番号に含めるためにそのインジケータを提供してもよい。
様々な実施形態において、データレコードの安定した順序付け、一貫した順序付けを提供し、データコンシューマによるレコードの繰り返すことができる反復を可能にするために、シーケンス番号が実装されてもよい。少なくともいくつかの実装において、特定のパーティションのデータレコードに割り当てられるシーケンス番号は連続している必要はないが、時間と共に単調に増加してもよい。様々な実施形態において、シーケンス番号が以下の意味論の少なくともいくつかのサブセットと共に割り当てられてもよい。（ａ）シーケンス番号がストリーム内で固有である、すなわち、同じシーケンス番号が割り当てられる所定のストリームのデータレコードが２つあってはならない、（ｂ）シーケンス番号がストリームのデータレコードへのインデックスとしての役割を果たしてもよく、データレコードを所定のストリームパーティション内で反復させるために利用されてもよい、（ｃ）所与のデータプロデューサのために、データプロデューサがデータレコードを正常に送信した順序がデータレコードに割り当てられるシーケンス番号に反映される、また、（ｄ）所定のパーティションキー値を用いたデータレコードのためのシーケンス番号付けが、動的再分割操作にまたがって単調増加する意味論を保持する。例えば、再分割後にデータレコードに割り当てられるパーティションキー値Ｋ１を用いたシーケンス番号はそれぞれ、動的再分割の前にそのパーティションキー値Ｋ１を用いてデータレコードに割り当てられた任意のシーケンス番号よりも大きくてもよい（動的再分割については図１６を参照して以下に詳細に説明する）。
いくつかの実施形態では、データプロデューサが少なくともいくつかのデータレコードのために選択されるシーケンス番号１０２の選択に影響を与えることを望む場合がある。例えば、データプロデューサ１２０が、割り当てられるストリームのシーケンス番号内の境界またはセパレータの境を定め、ストリームの特定のサブセットにおいて目標とされる読み出し要求のそのストリームのデータコンシューマによる送信をより容易にすることを望む場合がある。いくつかの実装においては、データプロデューサ１２０が、レコードと共に最小のシーケンス番号の指示を送信してもよく、上述のシーケンス番号の意味論にも従い、要求される最小値に従ってＳＭＳがシーケンス番号を選択してもよい。
図１３ｂは、少なくともいくつかの実施形態による、採集されたデータレコードのためにＳＭＳにおいて生成されてもよいシーケンス番号の例示的な要素を説明する。図示する実施形態においては、シーケンス番号が、ｎ１ビットのＳＭＳバージョン番号１３０２、ｎ２ビットのタイムスタンプまたはエポック値１３０４、ｎ３ビットのサブシーケンス番号１３０６およびｎ４ビットのパーティション番号１３０８の４つの要素を含んでもよい。いくつかの実装においては、１２８ビットのシーケンス番号が利用されてもよい。例えば、ｎ１、ｎ２、ｎ３およびｎ４は、それぞれ４、４４、６４および１６ビットであってもよい。バージョン番号１３０２は、単純にＳＭＳソフトウェアバージョンの展開における混乱を回避し、例えば、シーケンス番号を生成するためにＳＭＳソフトウェアのどのバージョンが利用されたかを明らかにできるようにするために利用されてもよい。少なくともいくつかの実装においては、バージョン番号１３０２が頻繁に変化することを予期されない場合がある。タイムスタンプ値１３０４は、例えば、ローカルクロックソースまたは世界中からアクセス可能なクロックソース（例えば、ｇｅｔＣｕｒｒｅｎｔＥｐｏｃｈまたはｇｅｔＣｕｒｒｅｎｔＴｉｍｅ ＡＰＩを実装するプロバイダーネットワークの状態管理システム）から採集サブシステムノードによって取得されてもよい。少なくともいくつかの実装において、周知の時点からのオフセット（例えば、Ｕｎｉｘ（商標）を利用したオペレーティングシステムにおける様々な時間関連のシステムを呼び出すことで取得可能である、１９７０年１月１日００:００:００ＡＭ ＵＴＣから経過した秒数）が、タイムスタンプ値１３０４のために利用されてもよい。いくつかの実施形態では、サブシーケンス番号１０３６が記憶サブシステムによって生成されてもよく、また、特定のパーティションのデータレコードが記憶装置に書き込まれる順序を示してもよい。従って、多数のデータレコードが所定の秒内で受信され、タイムスタンプ値１３０４が約１秒の間隔で変化するのみである実装においては、サブシーケンス番号１３０６が、同じ秒内で到着したために同じタイムスタンプ値が割り当てられることになるデータレコードのためのレコードの到着（または記憶）順序のインジケータとしての役割を果たしてもよい。いくつかの実施形態では、パーティション番号１３０８が所定のストリーム内でパーティションを一意的に識別してもよい。シーケンス番号タイムスタンプが、対応するデータレコードが採集された（少なくともおおよその）時刻を示す、少なくともいくつかの実装においては、特定のタイプの時間に基づく検索要求のためのインデックス機構にシーケンス番号が利用されてもよい。例えば、クライアントが特定の日または特定の時間範囲において生成されるか、または採集されたストリームレコードを検索することを望む場合があり、シーケンス番号が適切なデータレコード群を検索するための暗黙の２次インデックスのキーとして利用されてもよい。従って、少なくともいくつかの実施形態では、順序付けられた記憶および検索のためのタイムスタンプを含むシーケンスの利用に、記憶されるデータレコード群に一時的なインデックスを提供するという付加的な利点があってもよい。
所定のパーティションのデータレコードはしばしばラージシーケンシャル書き込み操作を利用して、通常シーケンス番号順に（例えば、ディスクに）書き込まれてもよい。上述のように、いくつかの実施形態では、データコンシューマがシーケンス番号順にデータレコードを読み出すことができるよう、イテレータを用いたプログラムインターフェイスが実装されてもよい。図１４は、少なくともいくつかの実施形態による、ＳＭＳにおけるストリームデータレコードの順序付けられた記憶および検索の実施例を説明する。パーティションＳｊ〜Ｐｋ（ストリームＳｊのｋ番目のパーティション）６つのデータレコード１１０Ａ〜１１０Ｆが記憶されるシーケンス番号順に示される。説明するように少なくともいくつかの実施形態では、例えば、値が上述のタイムスタンプ部１３０４またはサブシーケンス番号１３０６に割り当てられる方法が、これら要素のための連続した値に必ずしもつながらない可能性があるため、シーケンス番号は連続していない場合がある。
図１４に示す実施例では、データコンシューマが作成されるイテレータを要求し、開始シーケンス番号「８６５」を特定する。要求に応じて、要求される開始シーケンス番号以上である最も近いシーケンス番号を有するデータレコードに位置するＩｔｅｒａｔｏｒ１をＳＭＳが初期化している。この場合コンシューマの要求において、次に近いシーケンス（データレコード１１０Ｂに割り当てられる８６０）が開始シーケンス番号より小さいため、シーケンス番号８７０を有するデータレコード１１０Ｃがイテレータの開始位置として選択されている。ｇｅｔＩｔｅｒａｔｏｒインターフェイスは、パーティション内の要求位置でカーソルを設定するための要求の論理的等価物と見なされてもよく、例えば、ストリームに沿ってシーケンス番号順にカーソルを移動させるためのカーソル位置から開始されるデータレコードをその後読み出すために、ｇｅｔＮｅｘｔＲｅｃｏｒｄｓインターフェイスが利用されてもよい。説明する実施例においては、Ｉｔｅｒａｔｏｒ１に設定される「イテレータ」および３に設定される「ｍａｘＮｕｍＲｅｃｏｒｄｓ」（戻されるデータレコードの最大数）のパラメータを有するｇｅｔＮｅｘｔＲｅｃｏｒｄｓインターフェイスを、データコンシューマが呼び出している。従って、ＳＭＳ検索サブシステムが、データレコード１１０Ｃ、１１０Ｄおよび１１０Ｅを、その順序でデータコンシューマに戻す。イテレータであるＩｔｅｒａｔｏｒ１は、ｇｅｔＮｅｘｔＲｅｃｏｒｄｓの呼び出し後に、新しい位置に、例えば、データレコード１１０Ｆへと動かされてもよい。同じイテレータのための次に続くｇｅｔＮｅｘｔＲｅｃｏｒｄｓの呼び出しは、１１０Ｆから始まるデータレコードを返してもよい。いくつかの実施形態では、ｇｅｔＩｔｅｒａｔｏｒの呼び出しの意味論が異なってもよい。いくつかの実施形態では、例えば、特定の順序付けられた数以上の最も近いシーケンス番号を有するデータレコードにおいて、イテレータを位置づける代わりに、要求されるシーケンス番号以下で最大のシーケンス番号を有する最も近いデータレコードにおいて、イテレータが位置付けられてもよい。別の実施形態において、クライアントは、ｇｅｔＩｔｅｒａｔｏｒの呼び出しにおいて既存のシーケンス番号を特定しなければならない場合がある。例えば、要求されるシーケンス番号を有するレコードがストリームに存在しない場合に、エラーが戻されてもよい。
パーティションマッピング
上述のように様々な実施形態において、所定のストリームのレコードの採集、記憶、検索および処理に関連する作業負荷は、様々な分割および再分割ポリシーに従って、いくつかのノードの間でさらに分割され、分散させられてもよい。図１５は、少なくともいくつかの実施形態による、ストリームのパーティションマッピング１５０１ならびに、ＳＭＳおよびＳＰＳノードのために行われてもよい、対応する構成決定の実施例を説明する。例えば、ｃｒｅａｔｅＳｔｒｅａｍＡＰＩのクライアントによる呼び出しに応じて特定のデータストリームが作成されるか、または初期化されると、分割ポリシーが起動されてもよい。それによってストリームの所与のデータレコードが、その構成要素であると見なされるパーティションを決定するために利用されてもよい。採集サブシステム２０４、記憶サブシステム２０６、検索サブシステム２０８および所定のデータレコードのための操作を実行する関連する任意のＳＰＳステージ２１５の特定のノードがレコードのパーティションに基づいて選択されてもよい。１つの実施形態において、少なくとも所定のデータレコードのために利用される制御ノードのサブセットが、同様にパーティションに基づいて選択されてもよい。少なくともいくつかの実施形態では、例えば、ポリシーにおいて示されるトリガする条件に応じて、または明示的な要求に応じて、データストリームの動的再分割が分割ポリシーの一部としてサポートされてもよい。
様々な実施形態において、データプロデューサによってその値が直接的に（例えば、書き込みまたはｐｕｔ要求のパラメータとして）、または間接的に（例えば、ＳＭＳがデータプロデューサクライアント、データプロデューサのＩＰアドレスまたはデータレコードの実際の内容の一部の識別子または名称などのメタデータをパーティションキーとして利用してもよい）供給されてもよいレコードのための分割キーに、所定のデータレコードのために選択されるパーティションが依存してもよい。図１５に示される実施形態では、データレコードパーティション識別子１５１０を決定するために、１つ以上のマッピング関数１５０６がデータレコードパーティションキーまたは属性１５０２に適用されてもよい。１つの実装では、例えば、所定のパーティション識別子１５１０が、１２８ビットの整数値のスペースの連続した範囲を表してもよい。その範囲は、ストリームのすべてのパーティションのための範囲の集合が、１２８ビットの整数が仮定できるすべての潜在的な値を包括してもよいような範囲であり得る。そのような例示的なシナリオにおいては、１つの単純なマッピング関数１５０６が、データレコードの（１つ以上の）パーティションキー値または（１つ以上の）選択される属性値から１２８ビットのハッシュ値を生成してもよく、またハッシュ値が収まることになる特定の連続した範囲に基づいて、パーティション識別子が決定されてもよい。いくつかの実装においては、連続した範囲が少なくとも当初は等しい規模であってもよい。他の実装においては、異なるパーティションが互いに規模が異なる可能性のある連続した範囲に対応してもよい。再分割はまた、１つの実装において範囲境界を調整する結果となってもよい。他の分割関数１０６が異なる実装において利用されてもよい。
（以下に詳細に述べるように）データストリームが動的再分割を受ける場合、特定のキーを有するレコードがマッピングされるパーティションが変化してもよい。従って少なくともいくつかの実施形態では、ＳＭＳ及び／またはＳＰＳ制御ノードが、ストリームの生存時間中にストリームに適用するいくつかの異なるマッピングを把握しなければならない場合がある。いくつかの実施形態では、タイムスタンプの有効性の範囲１５１１またはaシーケンス番号の有効性の範囲などのメタデータが、各パーティションマッピングのための制御ノードによって記憶されてもよい。タイムスタンプの有効性の範囲１５１１は例えば、ストリームの作成時から時間Ｔ１まで特定のマッピングＭ１が適用すること、Ｔ１からＴ２まで異なるマッピングＭ２が適用することなどを示してもよい。ストリームに向けられた読み出し要求への応答時には、（例えば読み出し要求において示されるシーケンス番号によって）どのマッピングが利用されるべきかを検索ノードがまず決定し、次いで適切な記憶ノードの識別のためにそのマッピングを利用しなければならない場合がある。
少なくともいくつかの実施形態では、パーティションをいくつかの異なるの粒度のリソースへとマッピングする役割をＳＭＳおよびＳＰＳ制御ノードが担ってもよい。例えば、図１５の実装例１５９９において示されるように、１つの実装において、各採集、記憶、検索または処理（ワーカー）ノードが、Ｊａｖａ（商標）仮想マシン（ＪＶＭ）または計算インスタンスなどのサーバ仮想マシン内の実行のそれぞれの処理またはそれぞれのスレッドとして実装されてもよい。各ＪＶＭまたは計算インスタンスは、特定の物理ホストにおいてインスタンス化されてもよい。いくつかの実施形態では、複数のＪＶＭが単一の計算インスタンス内で起動され、リソースマッピングの決定に別の層を追加してもよい。従って、所定のパーティションのために、どの特定のリソースが、採集ノード１５１５、記憶ノード１５２０、検索ノード１５２５、または処理ステージワーカーノード１５３０（例えば、ステージＰＳ１またはＰＳ２のそれぞれのためのノード１５３０Ａまたは１５３０Ｂ）として利用されるべきかを、１つ以上の制御ノードが選択してもよい。制御ノードはまた、これらのノードのサーバ（採集サーバ１５３５、記憶サーバ１５４０、検索サーバ１５４５、または処理サーバ１５５０など）へのマッピング、サーバとホスト（採集ホスト１５５５、記憶ホスト１５６０、検索ホスト１５６５またはＳＰＳホスト１５７０Ａ／１５７０Ｂなど）との間のマッピングを決定してもよい。いくつかの実装においては、パーティションマッピングが、説明される様々なそれぞれのリソースの粒度（例、ノード、サーバおよびホストの粒度）の識別情報（例、リソースの識別子）、１つ以上の関数１５０６へ入力および関数１５０６自体として利用されているデータレコード属性の指示、を含むよう見なされてもよい。制御サーバは、パーティションマッピングの表示をメタデータ記憶装置に記憶させてもよく、またいくつかの実施形態では、様々なＡＰＩ（ｇｅｔＰａｒｔｉｔｉｏｎＩｎｆｏ ＡＰＩなど）または他のプログラムインターフェイスが、マッピング情報をデータプロデューサ、データコンシューマへと、または、ＳＭＳサブシステムもしくはＳＰＳのノードへと提供するために公開されてもよい。
いくつかの実施形態では、（ａ）所定のノード、サーバまたはホストがいくつかの実施形態において複数のパーティションの役割を担うよう指定されてもよいか、または（ｂ）障害または他のトリガにより、新しいノード、サーバまたはホストが所定のパーティションまたはパーティション群に割り当てられてもよい、などの様々な要因のため、データレコードのパーティションへの、またパーティションからリソースへのマッピングが、さらに複雑である場合がある。加えて、上述のように、また以下に述べるように、所定のストリームのためのパーティションマッピングが、ストリームレコードがＳＭＳ及び／またはＳＰＳノードによって継続して処理される間に、時間の経過と共に動的に修正されてもよい。結果的にいくつかの実施形態では、マッピングのメタデータのいくつかのバージョンが異なる時間にそれぞれ対応して、所定のストリームのために少なくとも一時的に保持されてもよい。
動的ストリーム再分割
図１６は、少なくともいくつかの実施形態による、動的ストリーム再分割の実施例を説明する。図１６において説明するタイムラインの時間Ｔ１において、ストリームＳ１が作成されるかまたは初期化される。パーティションマッピングＰＭ１がストリームＳ１のために作成され、時間間隔Ｔ１からＴ２の間で有効であり続ける。Ｔ１とＴ２との間でＳＭＳによって受信される３つのデータレコードが例として示される。データレコード１１０Ａ（ＤＲ１１０Ａ）がクライアント供給のパーティションキー値「Ａｌｉｃｅ」を用いて送信され、ＤＲ１１０Ｂがクライアント供給のパーティションキー値「Ｂｉｌｌ」を用いて送信され、またＤＲ１１０Ｃがクライアント供給のパーティションキー値「Ｃｈａｒｌｉｅ」を用いて送信される。初期のマッピングＰＭ１では、３つのデータレコード１１０Ａ、１１０Ｂおよび１１０Ｃのすべてが、パーティション識別子「Ｐ１」を有する同じパーティションへとマッピングされる。Ｐ１データレコードについては、単一のノードＩ１が採集を扱うよう構成され、単一のノードＳ１が記憶を扱うよう構成され、単一のノードＲ１が検索を扱うよう構成され、単一のワーカーノードＷ１がＳＰＳ処理を扱うよう構成される。マッピングＰＭ１の有効性の範囲のための開始タイムスタンプがＴ１に設定される。
図１６の例示的なタイムラインにおいて、ストリームＳ１が時間Ｔ２で動的に再分割される。図示する実施形態においては再分割がいつ行われるかに関わらず、データレコードが継続して到着し、ＳＭＳおよびＳＰＳによって処理され、ＳＭＳあるいはＳＰＳのいずれもオフラインにする必要がない。例えば、採集、記憶、検索または処理ノードにおける過負荷状態の検知に応じて、様々なサブシステムの異なるホストでの作業負荷レベル間のスキューまたは不均衡の検知に応じて、またはデータコンシューマまたはデータプロデューサクライアントからの要求に応じて、いくつかの要因のいずれかの結果として再分割が起動されてもよい。図示する実施形態においては、ＰＭ２のために示す有効性の範囲の開始タイムスタンプ設定によって示されるように、新しいマッピングＰＭ２が時間Ｔ２（またはＴ２の少し後）で有効となる。少なくともいくつかの実装において、異なるデータレコード属性群が、再分割の前に利用されたよりも分割データレコードのために利用されてもよい。場合によっては、追加的な分割属性が（例えば、ＳＭＳの要求において）データプロデューサによって送信されてもよい。一方、他の場合では、付加的な属性がＳＭＳ採集ノードによって生成されてもよい。そのような付加的な属性は、「塩漬けにされた」属性と称することがあり、再分割のための付加的な属性を利用する技術は、「塩漬け」と称することがある。１つの実装例において、過負荷採集サーバはデータプロデューサに（例えば、データプロデューサによって実行されるＳＭＳクライアントライブラリコードに）、再分割のために、前に利用されたパーティションキーに加えてランダムに選択される小さな整数値が提供されるよう示してもよい。採集作業負荷を異なる採集ノード群の間で分散させるために、当初のパーティションキーと塩漬けにされた付加的な整数の組み合わせが続いて利用されてもよい。いくつかの実施形態では、検索ノード及び／またはデータコンシューマが、再分割のために利用されている付加的な属性に関して知らされなければならない場合がある。少なくともいくつかの実装において、そのような付加的な属性が再分割のために利用されない場合がある。
図１６に示される実施形態では、新しいパーティションマッピングが結果的に、Ｔ２の前に同じキーのために選択されるパーティションに対して、Ｔ２の後に受信される少なくともいくつかのデータレコードのために選択される異なるパーティションとなる。Ｔ２の後にパーティションキー値「Ａｌｉｃｅ」を用いてＤＲ１１０Ｐが送信され、Ｔ２の後にパーティションキー値「Ｂｉｌｌ」を用いてＤＲ１１０Ｑが送信され、Ｔ２の後にパーティションキー値「Ｃｈａｒｌｉｅ」を用いてＤＲ１１０Ｒが送信される。説明する例示的なシナリオにおいては、ＰＭ２マッピングを利用して、ＤＲ１１０Ｐがパーティション「Ｐ４」の構成要素に指定され、ＤＲ１１０Ｑがパーティション「Ｐ５」の構成要素に指定され、一方でＤＲ１１０Ｒがパーティション「Ｐ６」の構成要素に指定される。図示する実施形態においては、Ｔ２の後に受信されるよう示されるデータレコードはいずれも前に利用されたパーティション「Ｐ１」の構成要素として指定されず、かわりに全く新しいパーティションが再分割後に利用されてもよい。いくつかの実施形態では、少なくともいくつかの前に利用されたパーティションが再分割後に継続して利用されてもよい。新しいパーティションＰ４、Ｐ５およびＰ６のそれぞれについて、採集、記憶、検索及び／または処理のために異なるノードが指定されてもよい。例えば、ノードＩ４、Ｓ４、Ｒ４およびＷ４がパーティションＰ４、ノードＩ５、Ｓ５、Ｒ５のために構成されてもよく、Ｐ５がパーティションＰ５のために構成されてもよく、またノードＩ６、Ｓ６、Ｒ６およびＰ６がパーティションＰ６のために構成されてもよい。いくつかの実施形態では、同じ記憶ノードが再分割後に特定のパーティションキーまたは属性を有するレコードのために、再分割前にそのようなレコードのために利用されたように利用されてもよいが、そのノード内の異なる記憶位置（例、異なるディスク、異なるディスクパーティション、異なるＳＳＤ）が再分割後に利用されてもよい。
Ｔ２での動的再分割後の少なくともしばらくの時間、再分割の前にＳＭＳ採集及び／または記憶サブシステムによって処理されたデータレコードのために検索要求が継続的に検索されてもよい。少なくともいくつかの場合においては、要求されたデータレコードを、データレコードが採集された時に有効であったＰＭ１マッピングに基づいて検索しなければならない場合がある。従って、図１６に示されるようにデータ検索の目的のために、ＰＭ１およびＰＭ２の両方がＴ２の後のしばらくの間継続して利用されてもよい。少なくともいくつかの実装において、データレコードは古くなると最終的にストリームから削除されてもよく、例えば、対応するデータレコードのすべて自体が削除される際に、古くなったパーティションマッピングもまた、最終的に処分されてもよい。いくつかの実施形態では、削除される代わりに（またはその前に）、ＳＭＳによって利用されるパーティションマッピングがアーカイブ後にレコードを検索するために依然として利用可能であってもよいように、ストリームレコードが（例えば、クライアントに選択されたアーカイバルポリシーに基づいて）異なる記憶位置または装置のセットへとアーカイブされてもよい。そのような実施形態では、ＰＭ１およびＰＭ２などのパーティションマッピングは、保存用記憶装置に向けられる検索要求をサポートする必要がある限り保持されてもよい。いくつかのアーカイブの実装においては、ストリームのパーティションマッピングが保持されることを要求しない（例えば、アーカイブされるデータレコードのために新しいインデックスが作成されてもよい）異なる検索手法が利用されてもよい。いくつかの実施形態では、Ｐ２などの再分割前に利用されていたが再分割後には書き込みが向けられる先にはならないパーティションがある時点で読み出しに対して「閉じられた」状態にあってもよい。例えば、「パーティションの終わりに達しました」とのエラーメッセージの等価物が検索要求に応じて提供されてもよい。
いくつかの実装においては、所定のデータストリームが多数の（例、数百または数千の）パーティションに分割されてもよい。ストリームＳ１が初めにＰ１、Ｐ２、・・・、Ｐ１０００の１０００のパーティションに分割される例示的な場合について考慮する。１つのパーティション、例えば、Ｐ７に対応する過負荷状態が検知される場合には、データレコードのＰ７への初期マッピングを変更する価値があるかもしれないが、他のパーティションのマッピングを変更する必要はない。１つの手法では、２つの新しいパーティションＰ１００１およびＰ１００２が再分割操作を介して作成されてもよい。再分割後に受信された、属性がもともとは（すなわち、もとのマッピングに基づいて）Ｐ７の構成要素となる結果になったレコードが再分割後にＰ１００１またはＰ１００２のいずれかへとマッピングされ、従ってＰ７の作業負荷を２つのパーティションの間で分散してもよい。例えば、Ｐ１〜Ｐ６およびＰ８〜Ｐ１０００の残りのパーティションを修正する必要がない場合がある。パーティションの小さなサブセットのみがそのような再分割による影響を受けるとき、少なくともいくつかの実施形態では、パーティションエントリの有向非巡回グラフなどの組み合わせられたデータ構造（すなわちパーティションエントリのツリー）が生成され、記憶されてもよい。各エントリは、分割関数の出力範囲および有効時間範囲（エントリの分割情報が有効であると見なされる時限）を示してもよい。上記の実施例において、Ｐ７を含む再分割が時間Ｔ２において実行され、一方でストリームＳ１（およびその初期マッピング）が時間Ｔ１において作成されたと仮定する。そのようなシナリオにおいては、Ｐ７に関するエントリのための有効時限が「Ｔ１からＴ２」となり、Ｐ１００１およびＰ１００２のための有効時限が「Ｔ２以降」となり、残りのパーティションのための有効時間の時限が「Ｔ１以降」となる。少なくともいくつかの実装において、そのような組み合わせられたデータ構造の利用はパーティションマッピングメタデータのために利用されるメモリまたは記憶量の大幅な低減につながる可能性がある。上記の実施例においては、パーティションＰ７の２つの新しいパーティションへの分割が説明された。少なくともいくつかの実装において、複数のパーティションがまた、再分割の間に組み合わせられてもよい。例えば、受信された検索要求が比較的少数であったか、または送信されたレコードが比較的少数であった２つの隣接するパーティションが、単一のパーティションへと組み合わせられてもよい。所与の時点で、データレコードが属するパーティションが分割関数および有効時間範囲の情報を利用して明確に決定されてもよい。時間の経過と共により多くの分割及び／または組み合わせが実行されるにつれ、組み合わせられたデータ構造が発展してもよいが、メタデータの分割のために求められる全体のスペースが（もちろん分割の頻度および、分割により影響される平均的なパーティションの数によるが）劇的に増大しない場合がある。対照的に異なる実装においては、再分割のたびに毎回、ストリームのために変更されないメタデータ群の全体が複製され、再分割による影響を受けるパーティションのためのエントリと組み合わせられてもよい。特に上述のように再分割後、少なくともしばらくの間古くなったマッピングが保持されなければならない場合に、パーティションマッピングのメタデータのための記憶およびメモリ要件が後者の実装においてははるかに速い速度で増大してもよい。
タイムスタンプ値（図１３ｂに示されるタイムスタンプ値１３０４など）を含むシーケンス番号が利用される少なくともいくつかの実施形態では、特別なタイプのシーケンス番号の推移が動的再分割のために実装されてもよい。例として図１３ｂに示されるのと同様のタイムスタンプを用いたシーケンス番号スキームが、新しいタイムスタンプ値がシーケンス番号に含められるために毎秒生成されるストリームＳ１のために利用されていると仮定する。動的再分割がサポートされる少なくともいくつかの実装において、動的再分割後に割り当てられるシーケンス番号がすべて、動的再分割前に利用されるものとは異なる（再分割事象に対応する、選択された初期タイムスタンプ値から始まる）タイムスタンプ値のセットを利用してもよい。例えば、動的再分割が完遂される（すなわち実施される）時に利用されるタイムスタンプ値がＴｋである場合、完遂後に発行される新しいシーケンス番号はいずれも、タイムスタンプ値Ｔｋ＋１以降の利用を要求されてもよい。図１３ｂで利用されるスキームにおける、少なくともいくつかの上位ビットにおいて、シーケンス番号値がタイムスタンプ値をコード化するため、記載のようにタイムスタンプ境界に対応する再分割事象が次に検索要求に応じて利用されるマッピングの識別に関与する記憶処理を簡略化するように万全を期されてもよい。従って、そのような実装において、特定のシーケンス番号を特定する検索要求が受信される際に、タイムスタンプ値がそのシーケンス番号から抽出されてもよく、また、再分割後のマッピングが利用されるべきか、または再分割前のマッピングが利用されるべきかが容易に決定されてもよい。抽出されたタイムスタンプ値が再分割のために選択された初期タイムスタンプよりも小さい場合、再分割前のマッピングが利用されてもよく、抽出されたタイムスタンプ値が再分割のために選択された初期タイムスタンプ値以上である場合、再分割後のマッピングが利用されてもよい。
ストリーム管理および処理方法
図１７は、少なくともいくつかの実施形態による、ストリームレコード採集およびストリームレコード検索のためのそれぞれのプログラムインターフェイス群をサポートするために実行されてもよい操作の態様を説明する流れ図である。要素１７０１に示されるように、データストリームを作成するかまたは初期化するための要求が、例えば、ＳＭＳクライアントまたはデータプロデューサクライアントから受信されてもよい。ストリームのために利用される初期パーティションマッピングが決定されてもよい（要素１７０４）。例えば、特定のデータレコードが属するパーティションを識別するために利用される（１つ以上の）関数および（１つ以上の）関数のために利用される入力パラメータが、分割ポリシーに基づいて識別されてもよい。上述のように様々な実施形態において、ＳＭＳの制御コンポーネントが、ストリーム作成要求を受信し、それに応答する役割を担ってもよい。ストリーム作成および初期化（および他の制御プレーン操作）が実装される方法が、実施形態によって異なってもよい。１つの実施形態において、例えば、制御サーバの冗長グループが構築されてもよく、永続性記憶位置における新しいストリーム（例、初期パーティションマッピング、採集、記憶および検索のノードの初期セットなど）のための適切なメタデータを生成し記憶させることによって、その冗長グループのプライマリ制御サーバが、ストリーム作成要求に応答してもよい。ストリーム（例、所定のパーティションのための役割を担うバックエンドノードに関するフロントエンド採集ノードからの要求）に関する次に続くクエリへの応答が、記憶されるメタデータを利用するプライマリ制御サーバによって生成されてもよい。ＳＭＳ制御プレーン機能の別の実装においては、少なくともいくつかの採集、記憶、または検索サブシステムのノードによって、ストリーム構成メタデータが、直接アクセス可能であるデータベースに記憶されてもよい。ストリームが作成され、初期化された後、レコード送信、記憶および検索などのデータプレーン操作が開始されてもよく、通常、制御コンポーネントとの付加的な対話なしで対応するサブシステムのそれぞれのコンポーネントによって処理されてもよい。
いくつかの実施形態では、データプロデューサが書き込み要求を有する明示的なパーティションキーを送信するよう要求されてもよい。一方、他の実施形態では、データプロデューサ、データレコードがそこから受信されるＩＰアドレスの識別などの書き込み要求に関連するメタデータに基づいて、またはデータレコード自体の内容から、分割関数のために利用される入力が決定されてもよい。少なくとも１つの実装において、クライアントはデータレコード送信におけるパーティション識別子を任意に供給してもよく、追加的な分割関数がそのような実装においては要求されない場合がある。
ストリームのための採集、記憶および検索関数のためのノードの初期セットを決定するかまたは構成する際にいくつかの異なる要因が考慮されてもよい（要素１７０７）。例えば、（ストリームが分割されるパーティションの数およびパーティションの予想される相対的な大きさを決定してもよい）パーティションマッピング自体、もしも利用可能であれば、予想される採集率及び／または検索率に関する情報、ストリームデータレコードのための持続性／永続性要件、及び／または（図９および１０において説明するものと同様の冗長グループを結果的に設定してもよい）様々なサブシステムのための高可用性要件が、異なるサブシステムのノードの数および配置に影響する場合がある。加えて、（図１１、１２ａおよび１２ｂで説明するように）クライアントがノードの様々なカテゴリのための配置先タイプの選好を示してもよい実施形態においては、そのような選好がまた、ＳＭＳ及び／またはＳＰＳノードのために利用されるリソースを決定する役割を果たしてもよい。少なくともいくつかの実施形態では、採集、記憶及び／または検索関数を実行することができるノードのそれぞれのプールが事前に設定されてもよく、制御コンポーネントがそのようなプールの選択される構成要素を、作成される新しいストリームそれぞれに割り当ててもよい。他の実施形態では、少なくともいくつかの場合に、ストリームが作成されるか、または初期化される際に、新しい採集、記憶または検索ノードをインスタンス化しなければならない場合がある。
図示する実施形態の採集ノードにおいて、例えば（データが送信要求に含まれる）インライン送信インターフェイスおよび（アドレスが送信要求において提供され、そこから例えばウェブサービス要求または他のインターフェイスを利用してＳＭＳ採集ノードまたはＳＭＳ記憶ノードがデータを検索することができる、）バイリファレンス送信インターフェイスを含む、データレコード送信のために実装される任意のプログラムインターフェイス群を介して、レコードが受信されてもよい（要素１７１０）。それぞれのレコードの送信方法のための異なる実施形態において、いくつかの異なるタイプのプログラムインターフェイスのいずれかが提供されてもよい。例えば、それぞれのアプリケーションプログラミングインターフェイス（ＡＰＩ）がインライン対バイリファレンス送信のためにサポートされてもよく、ウェブページまたはウェブサイトが構築されてもよく、グラフィックユーザーインターフェイス実装されてもよく、またはコマンドラインツールが開発されてもよい。少なくともいくつかの実施形態では、ＳＭＳがシーケンス番号を採集されたレコードそれぞれに割り当てて、例えば、レコードが採集されるか、または記憶される順序を示してもよく、また、シーケンス番号がデータコンシューマによる検索要求のために利用可能であってもよい。検索サブシステムノードにおいて、実装される任意のプログラム検索インターフェイス群を介してレコード検索要求が受信されてもよく、それに応じて要求されるデータレコード内容が提供されてもよい（要素１７１３）。非順次アクセスのために、例えば、（ｇｅｔＩｔｅｒａｔｏｒの呼び出しにおいて示されるシーケンス番号に基づいてパーティション内で選択される位置においてインスタンス化されるイテレータを要求する）ｇｅｔＩｔｅｒａｔｏｒまたは（特定のシーケンス番号を有するデータレコードを取得する）ｇｅｔＲｅｃｏｒｄＷｉｔｈシーケンスＮｕｍｂｅｒを、インターフェイスが含んでもよい。順次アクセスのために、（イテレータの現在の位置から、または特定のシーケンス番号から始まる順序のいくつかのレコードを要求する）ｇｅｔＮｅｘｔＲｅｃｏｒｄｓなどのインターフェイスが実装されてもよい。少なくともいくつかの実施形態では、異なる検索インターフェイスが、それらに関連する異なる課金率を有してもよい。例えば、順次検索のためのレコードごとの課金率が、非順次検索のためのレコードごとの課金率よりも低く設定されてもよい。いくつかの実施形態では、異なる送信インターフェイスもまた、異なる課金率を有してもよい。例えば、バイリファレンス送信についてはインライン送信よりもレコードあたり高いコストがかかる場合がある。
時間の経過と共に、制御ノードまたはまたは特定の請求サーバが、ストリーム管理サービスの様々なサブシステムにおいて実装される異なるプログラムインターフェイスのための使用メトリクスを収集してもよい（要素１７１６）。例えば、異なるプログラムインターフェイスの起動カウント、（単一起動を利用する複数のレコードを検索するために利用することができるｇｅｔＮｅｘｔＲｅｃｏｒｄｓなどの少なくともいくつかのインターフェイスのための起動カウントとは異なってもよい）採集されるまたは検索されるレコードの総数、採集されるまたは検索されるデータの総量などをメトリクスがを含んでもよい。ストリームを所有するクライアント、またはストリームからデータを生成し、及び／または消費するクライアントに請求される課金額は、使用メトリクスおよびプログラムインターフェイスに関連するそれぞれの課金率に少なくとも部分的に基づいて任意に生成されてもよい（要素１７１９）。少なくともいくつかの実施形態では、課金アクティビティはストリーム採集／検索操作に対して非同期であってもよい。例えば、月間に収集されたメトリクスに基づいて、請求書が請求月末に生成されてもよい。
図１８ａは、少なくともいくつかの実施形態による、ストリーム処理（ＳＰＳ）ステージを構成するために実行されてもよい操作の態様を説明する流れ図である。要素１８０１に示されるように、クライアントがストリームデータレコードのためのいくつかの処理ステージを構成することを可能にするプログラムインターフェイスが実装されてもよい。特定のステージを構成するために、例えば、ステージにおける分割されたストリームデータレコード上で実行される（１つ以上の）処理操作、処理操作の出力のための分散ポリシー、および、処理されるデータがそこから取得される入力ストリームの識別などの他のパラメータを、クライアントが示してもよい。いくつかの実施形態では、ＳＰＳステージにおける処理操作が冪等であるよう要求されてもよい。他の実施形態では、非冪等操作がまた、少なくともいくつかのステージのためにサポートされてもよい。所定のステージにおいて実行される処理が非冪等である場合、いくつかの実施形態において、いくつかの永続的な外部位置へと操作の出力を周期的にフラッシュするワーカーノードを構成し、レコード検索シーケンスに関してフラッシュ操作がいつ実行されたかを記録し、その後回復中にフラッシュ操作をリレーする置換ワーカーノードを構成することによって、クライアントが依然として冪等性による回復関連の利点を得ることができる場合がある。少なくともいくつかの実施形態では、ストリームデータに並列に、また他のステージのための入力ストリームとして利用されているいくつかのステージの結果に作用するいくつかの異なる状態を用いて、クライアントが有向非巡回グラフ（ＤＡＧ）または処理ステージの他のグラフを構成することができる場合がある。いくつかの実施形態では、永続性ストリームではなく１つ以上の一時ストリームが異なるステージ間で作成されてもよい。例えば、１つのステージからのデータレコード出力は異なるステージへの入力として供給される前に必ずしも永続性記憶装置に記憶される必要はない。
いくつかの実施形態では、例えば、チェックポイントを用いた回復ポリシーまたはベストエフォート型回復ポリシーを含む任意のいくつかの異なる回復ポリシーがＳＰＳステージのために実装されてもよい。１つの実施形態において、クライアントは異なるＳＰＳステージのための回復ポリシーを選択するために、プログラムインターフェイスを利用してもよい。チェックポイントを用いた回復が利用されるステージにおいては、自身がストリームパーティションにおいてどこまで達したかを示す間隔を置いて、ワーカーノードがプログレスレコードまたはチェックポイントを記憶させるよう構成されてもよい（例えば、直近で処理されたレコードのシーケンス番号が進捗のインジケータとして記憶されてもよい）。その後プログレスレコードが障害後の回復操作の間に、図１９を参照して以下に述べるように利用されてもよい。ベストエフォート型回復ポリシーにおいては、プログレスレコードが記憶される必要はなく、障害に応じて構成される置換ワーカーノードが、新しいデータレコードを受信されるままに単に処理してもよい。いくつかの実施形態では、所定のＳＰＳステージグラフまたはワークフロー内において、異なる回復ポリシーが異なるステージに適用されてもよい。
ＳＰＳ制御サーバは、例えば、要素１８０１に示されるプログラムインターフェイスの１つを介して、ストリームＳ１の特定のステージＰＳ１において分割ポリシーＰＰｏｌ１に従って実行される冪等操作Ｏｐ１の指示を出力分布記述子ＤＤｅｓｃ１に従って分散される処理結果と共に受信してもよい（要素１８０４）。例えば、ｐｏｌ１、冪等操作Ｏｐ１の複雑性およびワーカーノードのために利用されるリソースの性能などの様々な要因に基づいて、状態ＰＳ１のために構成されるワーカーノード数およびノードのために必要とされる仮想または物理リソースが決定されてもよい（要素１８０７）。
ワーカーノードがその後、例えば、選択された仮想または物理マシンリソースの処理またはスレッドとしてインスタンス化され構成されてもよい（要素１８１０）。１つの単純な実装においては、例えば、Ｓ１の各パーティションのために１つのワーカーノードが初めに割り当てられてもよい。所定のワーカーノードは、（ａ）Ｓ１の検索ノードの適切なサブセットからデータレコードを受信し、（ｂ）受信されたデータレコード上でＯＰ１を実行し、（ｃ）例えば、ＰＳ１のための回復ポリシーに基づいて、どのパーティションレコード群が処理されたかを示すプログレスレコード／チェックポイントを任意に記憶させ、（ｄ）ＤＤｅｓｃ１によって示される宛先に（例えば、中間の永続性もしくは一時ストリームへの、または他の処理ステージもしくは記憶システムへの直接の入力として）出力を送信する、ように構成されてもよい。少なくともいくつかの実施形態では、ＳＰＳ処理が他の場所に継続的に送信される必要がある出力を、必ずしも生成しない場合があることに留意されたい。例えば、いくつかのＳＰＳアプリケーションが単にデータレコードの一時的なレポジトリとしての役割を果たしてもよく、及び／またはユーザによるデータレコードの閲覧を可能にするクエリインターフェイスを実装してもよい。そのようなアプリケーションがそれ自体の出力を管理してもよい。例えば、分散記述子に従ってではなく、受信されるクエリに応じて出力が生成されてもよい。ロギング関連のＳＰＳアプリケーションは、大規模分散システムから収集された最終日のログレコードを保持し、例えば、デバッグまたは分析目的でのクライアントによるロギングデータの閲覧を可能にしてもよい。従って、いくつかの実施形態では、ＳＰＳの少なくともいくつかのステージのため、少なくともいくつかのストリームのため、または少なくともいくつかのパーティションのために、出力分布記述子を特定する必要がない。ワーカーノードはその後、それらのそれぞれの構成設定ごとのデータレコードの検索および処理を起動してもよい（要素１８１３）。少なくともいくつかの実施形態では、ＳＰＳ制御ノードが（例えば、ハートビートプロトコルなどの応答性チェックを利用して）ワーカーノードの健全性状態およびワーカーノードのために利用されているリソースにおけるリソース利用レベルなどの様々な他のメトリクスを監視してもよい（要素１８１６）。例えば、ワーカーノードが置換され、回復ポリシーが以下に述べるように実装される場合、フェイルオーバーが要求されるかどうかを決定するために、ワーカーノードから収集された情報が利用されてもよい。
いくつかの実施形態では、クライアント所有の敷地において、及び／またはクライアント選択のプロバイダーネットワークのリソースにおいてＳＰＳワーカーノードを実装することを望むこれらのクライアントに、インストール可能なＳＰＳクライアントライブラリが提供されてもよい。クライアントライブラリはまた、健全性モニタリング関数、自動化された作業負荷の監視およびバランシング、セキュリティ管理、動的再分割などのＳＰＳ管理サービスの様々な制御プレーン特徴を利用することを自身が望む程度を、ＳＰＳクライアントが選択することを可能にしてもよい。図１８ｂは、少なくともいくつかの実施形態による、ストリーム処理ワーカーノードの構成のためのクライアントライブラリのコンポーネントの呼び出しに応じて実行されてもよい操作の態様を説明する流れ図である。要素１８５１に示されるように、例えば、（図１８ａで説明する種類の操作を実行するよう構成可能なマルチテナントＳＰＳ管理サービスのウェブサイトからのダウンロードを介して）ＳＰＳクライアントライブラリが提供されてもよい。クライアントアプリケーションにリンクすることができるいくつかの実行可能コンポーネント、及び／またはコンポーネントをライブラリは含んでもよい。いくつかのライブラリコンポーネントは、クライアントがＳＰＳ管理サービスを選択し、それを用いて登録を行うか、または１つ以上のＳＰＳステージのストリーム処理操作が実行される様々なワーカーノードの所望のプロパティを特定することを可能にしてもよい。例えば、あるクライアントがワーカーノードのためにプロバイダーネットワークの仮想計算サービスにおいて実装される自身の計算インスタンス群の利用を望み、一方で別のクライアントがストリームレコードの処理のためにクライアント自体のデータセンターに位置する計算装置（プロバイダーネットワークによってサポートされない専用装置など）の利用を望む場合がある。クライアントは必要に応じて所望の通り、自身の敷地においてワーカーノードをオンラインにするか、または仮想計算サービスの計算インスタンスを利用してもよい。ワーカーノードのそのような所望に応じたインスタンス化に加えてまたはその代わりに、いくつかの実施形態では、クライアントが必要な時に展開することができる潜在的に再利用可能なワーカーノードのプールを予め構成してもよい。いくつかの実装においては、クライアントがＳＰＳ管理サービスを用いて、クライアントによってインスタンス化された特定の処理またはスレッドを次に続く制御プレーン操作が、ＳＰＳ管理サービスによってそのために処理されてもよい特定のステージのワーカーノードとして登録することを可能にするために、ライブラリコンポーネントが実行され、または呼び出されてもよい。１つの実施形態において、クライアントがまた、ワーカーノードのためにＳＰＳ管理サービスによって処理される異なるレベルの制御プレーンの役割から選択を行うことが可能であってもよい。例えば、あるクライアントがワーカーノードの健全性を監視するために自身の独自モジュールの利用を望み、一方で障害が検知される場合にワーカーノードの健全性を監視し適切なアクションを行うために、別のクライアントがＳＰＳ管理サービスの利用を望む場合がある。
ＳＰＳ管理サービスは、特定のＳＰＳステージＰＳ１のワーカーノード及び／または制御プレーン操作を構成するためのクライアントライブラリの利用を特定のクライアントが望むことの指示を受信してもよい（要素１８５４）（ライブラリに含まれるプログラムインターフェイスを利用して、また図４で説明するウェブベースのインターフェイスと同様のＳＰＳ管理サービスによって公開されるプログラムインターフェイスを利用して、ＰＳ１自体が設計されてもよい）。クライアントはまた、ＰＳ１による入力としての利用のためにそのデータが検索されるストリームを示してもよい。少なくともいくつかの実施形態では、例えば、クライアントがノードのためのサービスの健全性モニタリング能力の利用を望むか、または独自健全性モニタリングツールの利用を望むかなどの、ＰＳ１のための制御プレーン設定をクライアントが任意に示してもよい。（要素１８５７）。クライアントによって示される選好により、クライアントによる利用のために構成されるＳＭＳ及び／またはＳＰＳの１つ以上のノードが決定されてもよい。（要素１８６０）。ネットワーク接続性がクライアントのワーカーノード間でＳＭＳ／ＳＰＳノードへと構築されてもよく、及び／またはデータレコードの流れおよび処理結果を所望の通り可能にするように他の構成操作が実行されてもよい。受信検索要求の際にデータレコードがＳＰ１ワーカーノードに提供されてもよく、また（クライアントに要求されるプレーン操作がある場合には）所望の制御プレーン操作が必要に応じて実行されてもよい。少なくともいくつかの実施形態では、ＳＭＳ管理サービスの様々なサブシステムの制御プレーン機能の利用を望む程度をクライアントが制御することを可能にする同様の手法もまた、代わりに実装されてもよいことに留意されたい。
図１９は、少なくともいくつかの実施形態による、ストリーム処理のための１つ以上の回復ポリシーを実装するために実行されてもよい操作の態様を説明する流れ図である。要素１９０１に示されるように、ＳＰＳ制御ノードは、特定のワーカーノードの置換のためのトリガ基準が満たされたと判定してもよい。例えば、ワーカーノードが応答しないまたは不健全な状態になったか、現在のノードの作業負荷レベルがフェイルオーバーの閾値に達したか、ワーカーノードにおいて検知されたエラー数が閾値を超えたか、またはワーカーノードのいくつかの他の予期せぬ状態が識別される場合がある。置換ワーカーノードは識別されるか、またはインスタンス化されてもよい（要素１９０４）。いくつかの実施形態では、例えば、そこから１つが置換として選択されてもよいか、または新しいスレッドまたは処理が起動されてもよい、利用可能なワーカースレッドのプールが設定されてもよい。
特定のワーカーノードがアクティブであったＳＰＳステージにおいてベストエフォート型回復ポリシーが利用される場合（要素１９０７において決定されるように）、付加的なデータレコードが利用可能になると、置換ワーカーノードが単に付加的なデータレコードの処理を開始してもよく（要素１９１６）、例えば、置換されたワーカーノードの進捗のレコードを調べる必要がない。チェックポイントを用いた回復ポリシーが利用される場合、置換ワーカーノードが置換されたワーカーノードによって記憶されるプログレスレコードにアクセスしてもよい位置（例えば、記憶装置アドレスまたはＵＲＬ）の指示が提供されてもよい。（要素１９１０）。置換ワーカーノードが置換されたノードによって記憶される最新のプログレスレコードを検索してもよく、置換ワーカーノードがステージの冪等操作を実行するべきデータレコード群を決定するプログレスレコードを利用してもよい（要素１９１３）。そのようなチェックポイントを用いた回復ポリシーにおいては、最新のプログレスレコードと置換ワーカーノードがインスタンス化される時間との間の長さによって、また、置換されたワーカーノードが記憶されているプログレスレコードに続く付加的なレコードを処理した割合によって、いくつかのデータレコードが２回以上処理されてもよい。少なくともいくつかの実施形態では、実行中の操作が冪等である場合、そのような繰り返し操作には悪影響がない場合がある。少なくともいくつかの実施形態では、前に記憶されたプログレスレコードに基づいて置換ワーカーノードが繰り返し回復操作を実行した後、置換ワーカースレッドが、回復が完了したことを示すそれ自体のプログレスレコードを記憶させてもよく、また、新しく受信されるデータレコード上で通常のワーカースレッド操作を開始してもよい（要素１９１６）。
図２０は、少なくともいくつかの実施形態による、データストリームのための複数のセキュリティオプションを実装するために実行されてもよい操作の態様を説明する流れ図である。要素２００１に示されるように、例えば、異なる機能カテゴリのノード（例、採集、記憶、検索、処理または制御ノード）のための配置先タイプのオプションを含む、データストリーム管理および処理のための多様なセキュリティオプションからクライアントが選択を行うことを可能にする１つ以上のプログラムインターフェイスが実装されてもよい。配置先タイプは、セキュリティプロファイルの様々な態様において互いに異なってもよい。いくつかの実施形態において、ＳＭＳまたはＳＰＳノードのために利用されるリソースの物理位置は、宛先タイプごとに互いに異なってもよい。例えば、プロバイダーネットワークデータセンターに位置するインスタンスホストなどのリソースがノードのために利用されてもよいか、またはクライアント所有の設備におけるリソースが利用されてもよいか、またはサードパーティのリソースが利用されてもよい。少なくともいくつかの実施形態では、ネットワーク隔離レベルまたは他のネットワーキングの特徴は、宛先タイプごとに互いに異なってもよい。例えば、隔離された仮想ネットワーク、または隔離された専用物理リンクによってプロバイダーネットワークに接続されたクライアント所有の設備内で、いくつかのＳＭＳまたはＳＰＳノードがインスタンス化されてもよい。１つの実施形態において、特定のタイプのＳＭＳまたはＳＰＳノードが同様に利用可能である場合があるマルチテナント・インスタンスホストの利用の代わりにプロバイダーネットワークのシングルテナント・インスタンスホストにおいて構築されることを、クライアントが示してもよい。少なくともいくつかの実施形態では、様々な種類の暗号化オプションもまた、セキュリティ関連のプログラムインターフェイスを介して選択可能である場合がある。
セキュリティ関連のプログラムインターフェイスを介して、ストリームＳ１のための１つ以上の機能カテゴリのノードに関するクライアントのセキュリティプロファイルの選択または嗜好が受信されてもよい。機能カテゴリＦＣ１のノードのための１つのセキュリティプロファイル（例えば、クライアントがクライアント所有の敷地においてＳＰＳワーカーノードを実装することを望む場合がある）および異なる機能カテゴリＦＣ２のノードのための異なるセキュリティプロファイル（例えば、クライアントがＳＭＳ採集ノードまたは記憶ノードをプロバイダーネットワークデータセンターにおいて実装することを望む場合がある）を、例えば、クライアントが選択してもよい（要素２００４）。場合によっては、クライアントが同じセキュリティプロファイルを有する異なる機能カテゴリすべてのノードを設定することを決定してもよい。いくつかの実施形態では、ＳＭＳ及び／またはＳＰＳは、様々な機能カテゴリのためのデフォルトの配置先タイプを定義してもよい。例えば、クライアントが別に示さない限り、機能カテゴリすべてのノードがプロバイダーネットワークの隔離された仮想ネットワーク内で設定されてもよい。
異なる機能カテゴリのノードがその後、セキュリティプロファイル及び／または位置に対するクライアントの選好に基づいて（またはクライアントが選好しない機能カテゴリのためのデフォルトの設定に基づいて）構成されてもよい（要素２００７）。例えば、構成については、適切な物理ホストまたはマシンの選択ならびに異なる機能カテゴリのノードのための適切な計算インスタンス、仮想マシン、処理及び／またはスレッドのインスタンス化、ならびノード間の適切なネットワーク接続の構築を行うものであってもよい。いくつかの実施形態では、プロバイダーネットワークの外部のホストにおけるインストールのために、異なるストリーム管理および処理関数のための実行可能ライブラリコンポーネントが提供されてもよい。
少なくともいくつかの実施形態によって、例えば、クライアントが表明した暗号化の選好に従って、またはデフォルトの暗号化設定に基づいて、ノードの１つ以上のカテゴリにおいて暗号化モジュールが起動されてもよい。（要素２０１０）。その後、様々な機能カテゴリのノードが、クライアントの所望のように、ストリームデータが採集され、記憶され、検索され、及び／または処理されるように、起動されてもよい（要素２０１３）。
図２１は、少なくともいくつかの実施形態による、データストリームのための分割ポリシーを実装するために実行されてもよい操作の態様を説明する流れ図である。要素２１０１に示されるように、分割ポリシーがデータストリームのために決定されてもよい。例えば、データプロデューサにより供給されたキーに基づいて、または送信されたデータレコードの様々な属性およびデータストリームの再分割のための１つ以上のトリガ基準に基づくデータレコードのパーティションへの初期マッピングを、ポリシーに含めてもよい。いくつかの実施形態では、例えば、ハッシュ関数がパーティションキーまたはキーに適用され、１２８ビットの整数のハッシュ値を供給してもよい。潜在的な１２８ビットの整数の範囲は、それぞれがストリームのＮ個のパーティションの１つを表すＮ個の連続したサブレンジに分割されてもよい。いくつかの実施形態では、パーティション数及び／またはサブレンジの相対的な大きさがストリームごとに互いに変化してもよい。少なくともいくつかの実施形態では、そのためにストリームが構成されるクライアントが、例えば、所望のパーティション数、または利用される分割関数の所望の特徴などの利用される分割スキームに関する入力を提供してもよい。少なくとも１つの実施形態において、クライアントがいくつかのサブセットまたは送信されたすべてのデータレコードのためのパーティション識別子または名称を提供してもよい。
ストリームのデータレコードが受信されると、供給されるキー及び／または他の属性に基づいてそれらのそれぞれのパーティションが決定されてもよく、また適切な採集、記憶および検索ノード群が識別されたパーティションのために選択されてもよい（要素２１０４）。少なくともいくつかの実施形態では、例えば、所定のパーティションのレコードが受信されたシーケンスを示すデータレコードのためにそれぞれのシーケンス番号が生成されてもよい（要素２１０７）。シーケンス番号は、いくつかの実装において、タイムスタンプ値（例えば、１９７０年１月１日００:００:００ＡＭ ＵＴＣなどの周知の日時から経過した秒数）、記憶サブシステムから取得されたサブシーケンス値、ＳＭＳソフトウェアのバージョン番号、及び／またはパーティション識別子などのいくつかの要素を含んでもよい。いくつかの実施形態では、例えば、送信されたデータレコードの成功した採集に応答するために、シーケンス番号がデータプロデューサに提供されてもよい。いくつかの実施形態では、シーケンス番号はまた、データコンシューマによって、ストリームまたはパーティションのデータレコードを採集順に検索するために利用されてもよい。
少なくともいくつかの実施形態では、データレコードはそれらが向けられる記憶ノードにおいて、分割ポリシーに基づきシーケンス番号順に記憶されてもよい（要素２１１０）。回転式磁気ディスク記憶装置が利用される実施形態においては、順次書き込みは通常、受信されたデータレコードをディスクに保存し、それによってディスクシークのレイテンシを回避するために利用されてもよい。少なくともいくつかの実装において、レコードをディスクへ記憶する前に不揮発性バッファが、例えば、ディスクシークの可能性をさらに削減するために書き込みキャッシュとして利用されてもよい。シーケンス番号によって順序付けられた複数のデータレコードの読み出しのための要求（例、ｇｅｔＮｅｘｔＲｅｃｏｒｄｓまたは同様のインターフェイスの呼び出し）に応じて、データレコードが後に記憶装置からの順次読み出しを利用して読み出されてもよい（要素２１１３）。
図２２は、少なくともいくつかの実施形態による、データストリームの動的再分割を実装するために実行されてもよい操作の態様を説明する流れ図である。要素２２０１に示されるように、（例えば、ＳＭＳまたはＳＰＳの制御コンポーネントにおいて）ストリームが動的に再分割されることが判定されてもよい。１つ以上の採集、記憶、検索、処理または制御ノードにおける過負荷の検知、または異なるノードの作業負荷レベルの不均衡の検知、またはクライアント（例、データプロデューサまたはデータコンシューマ）から受信されてもよい再分割要求などのいくつかの異なるトリガする条件が、ストリームを再分割するための決定につながってもよい。いくつかの実装において、クライアント再分割要求は、生成される修正されたマッピングの様々なパラメータなどの要求される再分割の特定の詳細（例、追加されるまたは取り除かれるパーティション数、どの特定のパーティションが組み合わせられるか、または分割されるかなど）を含んでもよい。１つの実装において、クライアント再分割要求は、クライアントが解決することを望む問題状態（負荷の不均衡など）を示してもよく、ＳＭＳまたはＳＰＳが問題状態の記述の適切な再分割操作への翻訳の役割を担ってもよい。場合によっては、再分割の要求または問題状態の記述の代わりに、クライアントが再分割のために利用されるトリガ基準を特定してもよい。いくつかの実施形態では、データストリームのデータ持続性要件を変更する決定が再分割をトリガすることがある。それにより、例えば、結果的にストリームレコードのために異なる記憶装置群または異なる記憶技術が選択されてもよい。場合によっては、データストリームの利用パターンの変更（例えば、データレコードが生成されるまたは消費される割合）の検知もまた再分割につながってもよく、また利用パターンの変更のためにより適切な異なる記憶技術または異なる記憶装置群の利用につながってもよい。例えば、再分割の決定は、所定のパーティションまたはストリーム全体の予想される読み書きの割合のために、ＳＳＤが回転式磁気ディスクよりも適切な記憶技術であってもよいという決定に基づいてもよい。１つの実施形態においては、スケジュールされた、または差し迫ったソフトウェア及び／またはハードウェアバージョン変更が再分割をトリガしてもよい。場合によっては、異なる分割手法または異なる記憶手法を利用して、より効率的に満たすことができる予算の都合をクライアントが示す際に、価格または請求への懸念が再分割をトリガしてもよい。少なくともいくつかの実施形態では、変更された性能目標がまた、再分割をトリガしてもよい。図２２に示される実施形態では、再分割後に割り当てられたシーケンス番号のために利用される初期タイムスタンプ値（１９７０年１月１日００:００:００ＡＭ ＵＴＣからの秒のオフセット、いくつかのオペレーティングシステムにおいてシステム呼び出しを介して通常利用可能であるエポック値など）が選択されてもよい（要素２２０４）。いくつかの実装においては、プロバイダーネットワークにおいて実装されるグローバル状態マネージャが、ｇｅｔＥｐｏｃｈＶａｌｕｅ ＡＰＩをサポートし、例えば、シーケンス番号生成のために利用される一貫したタイムスタンプ値をＳＭＳ及び／またはＳＰＳの様々なコンポーネントが取得することを可能にしてもよい。他の実装においては、他の時刻源が利用されてもよい。例えば、ＳＭＳまたはＳＰＳ制御ノードが一貫して順序付けられたタイムスタンプ値を他のコンポーネントに提供するために指定されてもよいか、またはローカルシステムコール呼び出しが利用されてもよい。いくつかの実施形態では、タイムスタンプ値は必ずしもどのような特定のホストにおける壁時計時刻にも対応する必要はない。例えば、単調増加する整数のカウンタ値が単純に利用されてもよい。
再分割決定時に利用されるマッピングとは異なる修正されたパーティションマッピングがストリームのために生成されてもよい（要素２２０７）。少なくともいくつかの実施形態では、変更されたマッピングが、再分割前にマッピングされた同じキーを有するデータレコードではなく特定のパーティションキーを有するデータレコードを異なるパーティションへとマッピングしてもよい。再分割のためのトリガする条件によって、及び／または監視された作業負荷メトリクスによって、いくつかのパーティション（通常、多用されるパーティション）が分割されてもよく、一方で他の（通常、やや利用される）パーティションが組み合わせられてもよい。いくつかの実施形態では、再分割後に再分割前とは異なる分割関数が利用されてもよい。例えば、異なるハッシュ関数、またはハッシュ関数結果のパーティションへの再分割の異なる手法が利用されてもよい。例えば、パーティションが１２８ビットの整数の連続範囲に対応するいくつかの実装においては、再分割後に１２８ビットの整数空間が異なるサブレンジ群に分割されてもよい。少なくともいくつかの実施形態では、新しい採集、記憶、検索、処理または制御ノード群が新しく作成されたパーティションに割り当てられてもよい。いくつかの実装においては、初期マッピングおよび修正されたマッピングの両方を表すために空間効率よく組み合わせられたデータ構造が利用されてもよい（要素２２０８）。再分割の結果として修正されたパーティションに対応するレコードのみを変更すればよいように、例えば、分割関数の出力範囲（例えば、所定のパーティションに対応する分割ハッシュ関数の結果の範囲）および有効時間範囲の指示を各エントリが含む有向非巡回グラフまたはツリー構造が記憶されてもよい。再分割の間に変更されないままでいるパーティションのためのエントリは、データ構造において修正される必要がない場合がある。新しいノードは、修正されたパーティションマッピングを実装するよう構成されてもよい（要素２２１０）。少なくともいくつかの実施形態では、前のマッピングに基づいて記憶されるデータレコードのための検索要求が少なくともしばらくの間は受信され続けてもよいため、前のノードおよび前のマッピングがしばらくの間保持されてもよい。特定のシーケンス番号またはタイムスタンプを特定する読み出し要求が受信される際（要素２２１３）、（例えば、制御ノードにおいてか、または検索ノードにおいて）新しいパーティションマッピングまたは前のパーティションマッピングのどちらを利用して読み出し要求を満たすかに関する決定が行われてもよい。選択されたマッピングがその後、要求されるデータが取得された適切な記憶ノードを識別するために利用されてもよい。
図２３は少なくともいくつかの実施形態による、データストリームレコードのための少なくとも１回のレコード採集ポリシーを実装するために実行されてもよい操作の態様を説明する流れ図である。要素２３０１に示されるように、例えば、（ａ）それに従って肯定応答が受信されるまでレコードサブミッタがレコードを１回以上送信する少なくとも１回のポリシー、または（ｂ）それに従って少なくともいくつかのレコード送信のための応答が提供されないベストエフォート型採集ポリシー、を含めたいくつかの採集ポリシーオプションからクライアントがデータストリームのためのレコード採集ポリシーを選択することを可能にするために、１つ以上のプログラムインターフェイスが実装されてもよい。いくつかのデータを作成するクライアントは自身のレコードのごく一部を喪失する可能性に関して他のクライアントほどには懸念しない場合があり、従って、ベストエフォート型採集手法を選ぶことがある。いくつかの実装においては、ベストエフォート型採集のために構成されるストリームについても、ＳＭＳが依然としてデータレコードのいくつかのサブセットのための応答を提供してもよいか、またはベストエフォート型ポリシーがすべてのデータレコードのための応答を要求しなくても、すべてのデータレコードのための応答の提供を試みてもよい。
特定のストリームのために利用される特定の採集ポリシーを示すプログラムインターフェイスの１つを介して、要求が受信されてもよい（要素２３０４）。ストリームのために有効である分割ポリシーに従って、採集ノードがインスタンス化されてもよい（要素２３０７）。採集ノードにおいて同じデータレコードの１つ以上の送信が受信される際に（要素２３１０）、有効である採集ポリシーに依存して異なるアクションが行われてもよい。（要素２３１３において判定されるように）少なくとも１回の採集ポリシーが利用されている場合、１つ以上の送信のそれぞれのために応答がデータプロデューサにに送信されてもよいが、データレコードが記憶サブシステムにおいて１回だけ保存されてもよい（２３１６）。（場合によってはストリームのために有効である永続性ポリシーに従って、所定のレコードのＮ個のレプリカが記憶されてもよいが、所定のデータレコードがＭ回送信される場合、１回の送信のみのために複数のレプリカが生成されてもよく、すなわち記憶されるレコードレプリカの総数がＮ×Ｍ個ではなく依然としてＮ個であってもよいことに留意されたい）（要素２３１３で同様に検知されるように）ベストエフォート型採集ポリシーが有効であった場合に、データレコードが依然として記憶装置に１回保存されてもよいが、データプロデューサに応答が送信される必要はない（要素２３１９）。少なくともいくつかの実施形態では、クライアントの課金額が任意に決定されてもよい（要素２３２２）。上述のようにいくつかの実施形態では、少なくとも１回の採集ポリシーの２つのバージョンがサポートされてもよい。１つのバージョンでは、図２３で説明するのと同様に、ＳＭＳがデータレコードの重複を排除する（すなわち、２つ以上の送信群の１つのみに応じて、データがＳＭＳ記憶サブシステムにおいて確実に記憶されるようにする）役割を担ってもよい。少なくとも１回の採集の異なるバージョンにおいては、データレコードのＳＭＳによる重複が許可されてもよい。データレコードの重複の否定的な結果がほとんどあるいはまったくないストリームアプリケーションにとって、及び／または自身の重複削除を実行するストリームアプリケーションにとって、後者の手法が有用である場合がある。
図２４は、少なくともいくつかの実施形態による、データストリームのための複数の永続性ポリシーを実装するために実行されてもよい操作の態様を説明する流れ図である。要素２４０１に示されるように、クライアントがストリームデータレコードのための永続性ポリシーを複数の永続性ポリシーから選択することを可能にする１つ以上のプログラムインターフェイスが実装されてもよい。様々な観点のいずれかにおいて、永続性ポリシーは互いに異なってもよい。例えば、（ａ）保存されるレプリカ数が異なってもよく（例、Ｎ個のレプリカ対２つのレプリカ対単一のレプリカのポリシーがサポートされてもよい）、（ｂ）利用される記憶位置／装置タイプが異なってもよく、（例、回転式磁気ディスク対ＳＳＤ対ＲＡＭ対データベースサービスまたはマルチテナント記憶サービス）及び／または（ｃ）大規模障害に対する障害回復力の予想される程度に関するポリシーが異なってもよい（例えば、複数のデータセンター対単一のデータセンターのポリシーがサポートされてもよい）。特定のストリームのための特定の永続性ポリシーのクライアントの選択を示す要求が受信されてもよい（要素２４０４）。いくつかの実施形態では、クライアントによって選択される永続性ポリシーが結果的に所定のストリームのそれぞれのパーティションのための異なる記憶位置タイプまたは装置タイプの利用につながってもよい。１つの実施形態において、クライアントではなくＳＭＳが記憶位置タイプまたは装置タイプをストリームレベルでまたはパーティションレベルで選択してもよい。いくつかの実施形態では永続性ポリシーの選択時に、クライアントがデータの持続性目標及び／またはパフォーマンス目標（所望の読み出しもしくは書き込み処理能力またはレイテンシなど）をいくつかの実施形態では示してもよく、またこれらの目標は適切な記憶装置タイプまたは位置を選択するためにＳＭＳによって利用されてもよい。例えば、低レイテンシが所望される場合、１つ以上のパーティションまたはストリームのデータレコードを記憶させるために回転式磁気ディスクの代わりにＳＳＤが利用されてもよい。
採集ノード群が選択されたストリームのデータレコードをデータプロデューサから受信するように決定されるか、または構成されてもよく、記憶ノード群が選択された永続性ポリシーを実装するよう構成されてもよい（要素２４０７）。データレコードが採集ノードにおいて受信される際に（要素２４１０）、データレコードが属するパーティションの役割を担う記憶ノードによって選択された記憶装置において選択された永続性ポリシーに基づき、データレコードの１つ以上のコピーが記憶されてもよい（要素２４１３）。少なくともいくつかの実装においては、クライアントによって選択された特定の永続性ポリシーに基づいて、課金額が任意に（及び／または非同期に）決定されてもよい（要素２４１６）。
ストリーム処理のための分散作業負荷の管理
いくつかの実施形態では、例えば、様々な制御操作（パーティションのワーカーノードへの割り当て、動的再分割への応答、健全性モニタリング及び／またはロードバランシングなど）を調整する所定のＳＰＳステージ内のワーカーノードによって、データベーステーブルなどの共有されたデータ構造を介して、ＳＰＳの制御プレーン機能の大部分またはすべてが分散的方法で実装されてもよい。例えば、ステージの入力ストリーム（もしあれば）のどのパーティションが現在処理されていないかを判定するために。所定のワーカーノードＷ１が共有されたデータ構造内のエントリを調べてもよい。そのようなパーティションＰ１が発見される場合、Ｗ１がＰ１のレコード上でステージの処理操作を実行することを示すためにＷ１が共有されたデータ構造内のエントリを更新してもよい。他のワーカーノードがＰ１レコードを処理するためにＷ１が割り当てられることを認識してもよく、またそれによって異なるパーティションを自身に割り当ててもよい。入力ストリームに有効である現在のパーティションマップを決定するためにワーカーノードが周期的にまたは時にクエリをＳＭＳ制御プレーンに送信してもよい。また、必要に応じてマップの変更を（例えば、再分割結果として）示すために共有されたデータ構造を更新してもよい。様々な実施形態において、以下に述べるようにロードバランシングおよび他の操作がまた、共有されたデータ構造を介して調整されてもよい。そのようないくつかの分散実装において、専用制御ノードがＳＰＳのために要求されず、そのためにＳＰＳワークフローを実装するために求められるオーバーヘッドが削減される場合がある。そのような分散ＳＰＳ制御プレーンの実装が特に、例えば、顧客に割り当てられるプロバイダーネットワーク内の計算インスタンスにおける、またはプロバイダーネットワーク外の位置における、ストリーム処理の様々な態様を実装するためにＳＰＳクライアントライブラリを利用する、予算を気にする顧客に人気が高い場合がある。例えば、ＳＭＳおよびＳＰＳのために利用されるすべてのリソースがプロバイダーネットワーク内で構成される場合にクライアントライブラリが利用されない実施形態において、分散ＳＰＳ制御プレーン技術がまた利用されてもよい。少なくともいくつかの処理ステージのためにワーカーノードがＳＰＳ制御プレーン関数の一部または全部を実装するＳＰＳは、本明細書において「分散制御ＳＰＳ」と称する場合がある。
図２５は、少なくともいくつかの実施形態による、処理ステージのワーカーノードがデータベーステーブルを利用してそれらの作業負荷を調整するストリーム処理システムの実施例を説明する。分散制御ＳＰＳ２５９０内で、２つのステージ２１５Ａおよび２１５Ｂの各々が、それぞれのワーカーノード群と共に定義される。ステージ２１５Ａはワーカーノード２５４０Ａおよび２５４０Ｂを含み、一方でステージ４１５Ｂがワーカーノード２５４０Ｋおよび２５４０Ｌを含む。ステージ２１５Ａおよび２１５Ｂのそれぞれのために、ステージ２１５ＡのためのＰＡテーブル２５５０Ａおよびステージ２１５ＢのためのＰＡテーブル２５５０Ｂなどの対応するパーティション割り当て（ＰＡ）テーブル２５５０がデータベースサービス２５２０において作成される。いくつかの実施形態では、例えば、クライアントライブラリコンポーネントまたは関数の呼び出しに応じて、ステージの初期化中に所定のステージのためのＰＡテーブル２５５０が作成されてもよい。各ＰＡテーブル２５５０はエントリの初期セットまたはステージの入力ストリームの割り当てられないパーティション（すなわち、ワーカーノードが現在割り当てられていないパーティション）を表す行を与えられてもよい。ＰＡテーブルエントリの例示的な列または属性を図２６に示し、以下に述べる。ステージのために起動されるワーカーノード２５４０（例、計算インスタンスまたは他のサーバにおいて起動される処理またはスレッド）は、ステージのＰＡテーブルへの読み書きアクセスを許可されてもよい。図２５において、ワーカーノードからＰＡテーブルに向けられた読み書きが矢印２５６４Ａ、２５６４Ｂ、２５６４Ｋおよび２５６４Ｌによって、ワーカーノード２５４０Ａ、２５４０Ｂ、２５４０Ｋおよび２５４０Ｌのそれぞれのために表される。
ＰＡテーブルにおいてエントリを検証することで、所定のワーカーノード２５４０がステージの処理操作を実行するための特定のパーティションを選択するよう構成されてもよい。１つの実装においては、ワーカーノード２５４０Ａは、割り当てられないパーティションＰｋのエントリを発見するまでＰＡテーブル２５５０Ａにおいて、エントリをスキャンしてもよく、例えば、ワーカーノードの識別子をエントリの列に１つに挿入することによってエントリを更新してパーティションＰｋのそれ自体への割り当てを試みてもよい。そのような挿入はワーカーノードによるパーティションのロックに類似していると見なされる場合がある。利用中のデータベースサービスのタイプによって、ＰＡテーブルエントリへの同時並行的書き込みを潜在的に管理するための異なる手法が（例えば、割り当てられないパーティションをほぼ同時に識別することになる２つ以上のワーカーノードによって）利用されてもよい。
１つの実施形態において、関係するデータベースのトランザクション・セマンティクスを必ずしもサポートすることなく強い整合性および条件付き書き込み操作をサポートするプロバイダーネットワークの無関係なマルチテナントデータベースサービスが利用されてもよい。ワーカーノードによる更新のためのそのような場合には、条件付き書き込み操作が利用されてもよい。列「ｗｏｒｋｅｒ−ｎｏｄｅ−ＩＤ」がＰＡテーブルにおいてパーティションに割り当てられる特定のワーカーノードの識別子を示すために利用され、ワーカーノードがパーティションに割り当てられない場合に列の値が「ｎｕｌｌ」に設定される実施例について考慮する。そのようなシナリオにおいては、識別子ＷＩＤ１を有するワーカーノードが以下の論理的等価物を要求してもよい。「パーティションＰｋのためのエントリにおいて、ｗｏｒｋｅｒ−ｎｏｄｅ−ＩＤがｎｕｌｌである場合、その後そのエントリのためのｗｏｒｋｅｒ−ｎｏｄｅ−ＩＤをＷＩＤ１に設定する」そのような条件付き書き込み要求が成功する場合、パーティションＰｋがそれに割り当てられると識別子ＷＩＤ１を有するワーカーノードが仮定してもよい。ワーカーノードはその後、例えば、ＳＭＳ検索サブシステム２０６のレコード検索インターフェイスを利用して、矢印２５５４（例えば、ワーカーノード２５４０Ａ、２５４０Ｂ、２５４０Ｋおよび２５４０Ｌそれぞれのための矢印２５５４Ａ、２５５４Ｂ、２５５４Ｋおよび２５５４Ｌ）によって示されるようにパーティションＰｋのデータレコードの検索および検索されるレコード上の処理操作の実行を開始してもよい。条件付き書き込みが失敗する場合には、ワーカーノードが異なる割り当てられないパーティションの検索を再開してもよい。他の実施形態では、例えば、パーティションをワーカーノードに割り当てる複数の同時並行的（または同時並行的に近い）試みの１つのみが成功し、そのような同時並行的試みに関与するワーカーノードがそれらの成功または障害について確実に知らされるように万全を期すために、トランザクションをサポートするデータベースサービス（関係するデータベースなど）が利用されてもよく、条件付き書き込み操作の等価物を実装するためにトランザクション機能が利用されてもよい。いくつかの実施形態では、条件付き書き込みにもトランザクションのサポートにも依拠しない同期技術が利用されてもよい。いくつかの実装において、ＰＡテーブルに類似している永続性データ構造においてエントリの更新のための排他アクセスを取得するためにデータベースサービスが利用されず、代わりにロッキングサービスがワーカーノードによって利用されてもよい。
他のワーカーノード２５４０がＰＡテーブルにおいてエントリを調べて、どのパーティションが割り当てられないかを判定してもよく、また最終的に１つ以上のパーティションをそれらに割り当てることに成功してもよい。この方法で、ステージの入力ストリームまたはストリームのパーティションのための処理作業負荷がそれらの間でステージのワーカーノードによって最終的に分散させられてもよい。
所与のストリームの初期パーティションマッピングは、例えば、上述の動的再分割操作の結果として時間の経過と共に変化してもよい。従って図２５に示す実施形態において、１つ以上のワーカーノード２５４０が時に（以下に述べるように、またはトリガする条件に応じて）要求を、現在のパーティションメタデータを取得するためにそれらのステージの（１つ以上の）入力ストリームのＳＭＳ制御サブシステム２１０へと送信してもよい。いくつかの実装においては、矢印２５４４Ａ、２５４４Ｂ、２５４４Ｋおよび２５４４Ｌによって示されるｇｅｔＳｔｒｅａｍＩｎｆｏ ＡＰＩの呼び出しなどのＳＭＳ制御プレーンＡＰＩの呼び出しをそのような要求が含んでもよい。ＳＭＳ制御サブシステムは、例えば、ストリームのパーティションの最新のリスト、及び／またはパーティションの有効時限などの他の詳細に応答してもよい。ＳＭＳ制御サブシステム２１０によって提供されるパーティション情報がＰＡテーブルにおけるエントリと一致しない場合、例えば、１つ以上のパーティションのためのエントリを挿入するかまたは削除することでＰＡテーブルがワーカーノードによって修正されてもよい。少なくともいくつかの実施形態では、矢印２５５４Ａのラベル「低頻度」によって示されるように、そのようなＳＭＳ制御サブシステムへの要求２５５４がレコード検索要求２５５４（及び／またはデータベースの読み出しもしくは書き込み操作２５６４）よりも通常はるかに頻繁である可能性がある。例えば、一度パーティションに割り当てられると、ワーカーノードは通常、パーティションデータが完全に消費されるまで（例えばストリームの所有者がストリームを閉じる場合、または動的再分割の結果としてパーティションが閉じられる場合）、または他のいくつかの可能性が低い状況に直面するまで（例えば、以下に述べるように、検知された負荷の不均衡のために異なるワーカーノードがパーティションの転送を要求する場合）、パーティションのデータレコードの検索および処理を継続してもよい。従って、様々な実施形態において、所与の呼び出しに応じて大量の情報が提供される場合であっても（数百または数千のパーティションがステージの入力ストリームのために定義される場合にありうるものとして）、ｇｅｔＳｔｒｅａｍＩｎｆｏまたは同様のＡＰＩの呼び出しに関連するオーバーヘッドは通常、極めて小さくてもよい。
従って、図２５に示す実施形態において、分散制御ＳＰＳ環境のいくつかのキー作業負荷の管理操作は、以下のように要約される。（ａ）ストリーム処理ステージの第１のワーカーノードによるデータベーステーブルへのアクセスに少なくとも部分的に基づく、そのステージのために定義される処理操作群を実装するためのストリーム処理ステージの入力データストリームの特定のパーティションの選択、（ｂ）特定のパーティションの第１のワーカーノードへの割り当てのインジケータの、テーブルに記憶される特定のエントリへの書き込み、（ｃ）マルチテナントストリーム管理サービスにおいて実装されるプログラムレコード検索インターフェイスを利用した、第１のワーカーノードによる特定のパーティションのレコードの検索、（ｄ）第１のワーカーノードによる処理操作群の、特定のパーティションのレコード上での実装、（ｅ）第２のワーカーノードによる、特定のデータベーステーブルにおける特定のエントリに少なくとも部分的に基づく、処理操作群の特定のパーティション上での実行のために第１のワーカーノードが割り当てられることの判定、および（f）第２のワーカーノードによる、処理操作群を実行するための異なるパーティションの選択。ワーカーノードが、それに割り当てられるパーティションにレコードがこれ以上とどまらないことをが判定する場合、ワーカーノードはＳＭＳ制御サブシステムの入力ストリーム上のメタデータを要求してもよく、またメタデータが矛盾を示す場合にはＰＡテーブルを更新してもよい。
図２６は、少なくともいくつかの実施形態による、作業負荷調整のためにパーティション割り当てテーブル２５５０に記憶されてもよい例示的なエントリを説明する。図示のように、テーブル２５５０は、パーティション識別子列２６１４、割り当てられるワーカーノード識別子列２６１８、ワーカーノード健全性インジケータ列２６２０および作業負荷レベルインジケータ列２６２２の４つの列を含んでもよい。他の実装においては、他の列のセットが実装されてもよい。いくつかの実施形態では、例えば、パーティション作成時間または分割関数の出力値範囲を示す列が利用されてもよいか、または作業負荷レベルインジケータ列が利用されない場合がある。
いくつかの実施形態では、ＳＭＳ制御サブシステムによって（例えば、上述のように、パーティションエントリツリー、グラフまたは他の組み合わせられたデータ構造の一部として）維持されるパーティションリスト２６５０が少なくともいくつかの時点において、ＰＡテーブル２５５０に含まれるよりも多くのパーティションを含んでもよいことに留意されたい。示される実施例において、パーティションリスト２６５０はパーティションＰ１、Ｐ２、Ｐ３、Ｐ４およびＰ５を含み、Ｐ１およびＰ４は再分割の結果として閉じられた状態で示され、一方でＰ２、Ｐ３およびＰ５がアクティブ（すなわち、データレコードが現在検索され、処理されているパーティション）として示される。図示する実施形態においては、ＰＡテーブル２６５０はアクティブなパーティションのためのエントリを含み、（例えば、再分割が行われた後ｇｅｔＳｔｒｅａｍＩｎｆｏの呼び出しへの応答を取得した時にワーカーノードによって削除された可能性があってもよい）閉じられたパーティションのためのエントリを含まない。少なくともいくつかの実装においては、ストリームの現在開いているすべてのパーティションが所定の時点で必ずしもＰＡテーブルにおいてそれぞれのエントリを有さない場合があってもよく、代わりに、例えば、現在割り当てられるか、または処理されているこれらのパーティションのサブセットのみが表されてもよい。
図２６で説明する例示的なシナリオにおいては、パーティションＰ１およびＰ２が識別子Ｗ７およびＷ３それぞれを有するワーカーノードに割り当てられ、一方でＰ５は現在割り当てられていない。健全性インジケータ列２６２０は、異なる実装において異なるタイプの値を記憶させてもよい。いくつかの実装においては、ワーカーノードがアクティブであり、それらの検索および処理操作を行えることを示すために、それらの割り当てられるパーティションのＰＡエントリにおける健全性インジケータ列の内容を周期的に（例えば、Ｎ秒ごとに、またはいくつかのヒューリスティック群に基づくスケジュールに応じて）更新する役割をワーカーノードが担ってもよい。図２６において、そのエントリのためのワーカーノードが健全性インジケータ列（「ｌａｓｔ−ｍｏｄｉｆｉｅｄ−ｔｉｍｅ」）を更新した最新時間の指示が記憶されてもよい。例えば、ワーカーＷ７が２０１３年１２月１日の０２:２４:５４．５３秒においてエントリを修正したとしてが示される。いくつかの実施形態では、割り当てられるワーカーノードが健全かまたはそうでないかを判定するために他のワーカーノードが最新修正時間値を利用してもよい。例えば、Ｘ秒または分が経過した場合、ステージのためのフェイルオーバーポリシーにおいて定義されるように、割り当てられるワーカーノードが不健全またはアクセス不可能であると仮定される場合、パーティションが再度割り当てられてもよい。他の実装においては、カウンタが健全性インジケータとして利用されてもよいか（例えば、カウンタ値がＹ秒の間に変更されない場合、割り当てられるワーカーノードがフェイルオーバーの候補であると見なされてもよい）、または割り当てられたワーカーノードがエントリを最後にいつ読み出したかを示す「ｌａｓｔ−ｒｅａｄ−ｔｉｍｅ」値が利用されてもよい。
少なくともいくつかの実施形態では、例えば、割り当てられたワーカーノードによって、いくつかの最新の時間間隔（例えば、最新修正時間の５分前に）の間に処理されるレコード数、ＣＰＵ利用、メモリ利用、記憶利用などの最新のパフォーマンス関連のワーカーノードのメトリクスなどの作業負荷レベルインジケータ値２６２２がエントリにおいて記憶されてもよい。いくつかの実施形態では、図２９を参照して以下に述べるように、負荷の不均衡が存在するかどうかを判定するために、また検知された不均衡に応じてアクションを取るために、そのような作業負荷レベルインジケータ値がワーカーノードによって利用されてもよい。例えば、ワーカーノードＷｋがその作業負荷レベルが平均的な作業負荷レベルを超えると判定してもよく、そのパーティションの１つに割り当てなくてもよく、または動的再分割を要求してもよい。また代替的に、ワーカーノードＷｋがその作業負荷が他のワーカーノードまたはパーティションの作業負荷に対して低すぎると判定してもよく、付加的なパーティションをそれ自体に割り当ててもよい。従って、図示する実施形態においては、図２６で示されるＰＡテーブルの列を利用して、集中制御ＳＰＳ実装における専用ＳＰＳ制御ノードによって通常実行されてもよい、いくつかの同じタイプの制御プレーン関数をワーカーノードが実行してもよい。
図２７は、少なくともいくつかの実施形態による、ストリーム処理ステージのワーカーノードによって、処理操作を実行するためのパーティションの選択のために実行されてもよい操作の態様を説明する。要素２７０１に示されるように、ＰＡテーブルＰＡＴ１はデータベースサービスにおいて分散制御ＳＰＳ処理ステージＳＰ１のために初期化されてもよい。例えば、ＳＰＳクライアントライブラリコンポーネントが呼び出される際に、例えば、クライアント設備におけるホストから、またはプロバイダーネットワークデータセンターにおける計算インスタンスからテーブルが作成されてもよい。例えば、ＳＰＳステージにおいて実装される特定の処理操作のためのＪＡＲ（Ｊａｖａ（商標）アーカイブ）ファイルなどの実行可能コンポーネントを提供し、ワーカーノードを識別するために利用してもよいラベル（プログラム名、処理名または計算インスタンス名など）を示し、ステージのための入力として利用されるストリームを示し、ステージの出力先（もしあれば）を示すなどの様々な目的のためにクライアントライブラリが利用されてもよい。いくつかの実施形態では、ステージの（１つ以上の）入力ストリームのために定義される、少なくともパーティションのサブセット｛Ｐ１、Ｐ２、・・・｝のためにＰＡＴ１が初めにエントリまたは行を与えられてもよい。いくつかの実装においては、テーブルが初めは空のままであってもよく、１つ以上のワーカーノードが割り当てられないパーティションのための行を、例えば、パーティションのメタデータのＳＭＳ制御サブシステムからの取得結果としてテーブルに与えてもよい。例えば、プロバイダーネットワーク内の様々な計算インスタンスにおいて、またはクライアント所有の計算装置において、ワーカーノードの初期セット｛Ｗ１、Ｗ２、・・・｝が起動されてもよい（要素２７０４）。図示する実施形態においては、ワーカーノードはＰＡＴ１への読み書きアクセスを許可されてもよい。
ワーカーノードがオンラインになると、割り当てられないパーティションを発見しようと試みるために、それらがそれぞれＰＡＴ１にアクセスしてもよい。例えば、ワーカーノードＷ１がＰＡＴ１を調べ、パーティションＰ１が割り当てられないことを発見してもよい（要素２７０７）。例えば、利用されるデータベースサービスのタイプにより、条件付き書き込み要求またはトランザクションの更新要求を利用してＰ１がＷ１に割り当てられることを示すために、Ｗ１がその後Ｐ１のエントリをＰＡＴ１において更新してもよい（要素２７１０）。テーブルが更新されると、ＳＭＳ検索サブシステムインターフェイスを利用してＷ１がＰ１のデータレコードの検索を起動してもよく（要素２７１３）、検索されるレコード上でステージＰＳ１の処理操作を実行してもよい。
一方で、いくつかの時点において、異なるワーカーノードＷ２が、割り当てられないパーティションを発見する自身の試みにおいてＰＡＴ１にアクセスしてもよい（要素２７１６）。Ｗ２はＷ１の前の更新に基づいて、Ｐ１がすでに割り当てられているが、異なるパーティションＰ２が割り当てられていないと判定してもよい。いくつかの実施形態では、Ｗ２による（例えば、Ｐ２のエントリ内の健全性インジケータ列に基づく）、Ｐ２の現在割り当てられているワーカーノードが不健全または非アクティブであることの判定がまた、Ｗ２にＰ２を選択させてもよい。従って、少なくともいくつかの実施形態では、割り当てられない状態または現在のワーカーノードの不健全な状態の判定が、再割り当て（または初期割り当て）のための所定のパーティションの選択のために利用されてもよい。Ｗ２がその後、Ｐ２をそれ自体に割り当てるためにＰＡＴ１の更新を試みてもよい（要素２７１９）。更新が成功する場合、Ｗ２がＳＭＳ検索インターフェイスを利用してＰ２のレコードの検索を開始し（要素２７２２）、ステージのために定義される適切な処理操作を実行してもよい。
上述のように、分散制御ＳＰＳにおけるワーカーノードは（通常、低頻度で）パーティションマッピング情報をＳＭＳから取得し、必要であればＰＡテーブルを更新するためにそのような情報を利用してもよい。図２８は、少なくともいくつかの実施形態による、ストリーム処理ステージのワーカーノードによって、ストリーム管理サービス制御サブシステムから取得した情報に基づいてパーティション割り当てテーブルを更新するために実行されてもよい操作の態様を説明する。要素２８０１に示されるように、ワーカーノードの初期化中に、またはそれに割り当てられるパーティションの１つの終了などのトリガする様々な条件に応じて、最新のまたは現在のパーティションリスト、またはアクティブパーティションリストを取得するために、ワーカーノードＷ１が要求をＳＭＳ制御サブシステムに送信してもよい。いくつかの実装においては、ｇｅｔＳｔｒｅａｍＩｎｆｏまたは同様のＡＰＩがこの目的のために呼び出されてもよい。いくつかの実施形態では、他のトリガする条件が利用されてもよい。例えば、ワーカーノードがそれぞれ、ランダムな時間の後に、または作業負荷レベルの予期せぬ下落もしくは上昇に応じて、新しいパーティションリストを取得するよう構成されてもよい。ＳＭＳによって戻されたパーティションリストは、パーティションのためのＰＡテーブルにおけるエントリと比較されてもよい（要素２８０７）。図示する実施形態においては、矛盾が発見される場合（例えば、新しく取得されたパーティションリストにＰＡテーブルにはないいくつかのパーティションがある場合、またはＳＭＳのリストにはないエントリがＰＡテーブルにある場合）、矛盾を解決するためにワーカーノードがＰＡテーブルにおけるエントリを挿入するか、または削除してもよい（要素２８１０）。（いくつかの実装において、削除を目標としたエントリが割り当てられるワーカーノードを現在有している場合、付加的な調整が要求されてもよい。例えば、直接またはＰＡテーブル自体を介して、割り当てられるワーカーノードが通知されてもよい）。
矛盾が修正された後、または矛盾が検知されなかった場合、ワーカーノードＷ１がステージの処理操作を実行すべきパーティション群を選択してもよく（要素２８１３）、またそれに従ってＰＡテーブルを更新してもよい。場合によっては、検索されるパーティションリストにつながったトリガする条件によって、それに割り当てられる１つ以上のパーティションをＷ１がすでに有している可能性があり、その割り当てに変更を加えるか、またはＰＡテーブルを更新する必要がない場合がある。Ｗ１はその後、ＳＭＳ制御サブシステムと対話するか、またはエントリ数をＰＡテーブルにおいて変更する必要なく、それに割り当てられる１つ以上のパーティションのデータレコードの検索およびレコードの処理に進んでもよい（要素２８１６）。最終的にトリガする条件が検知される際に（例えば、「パーティションの終わりに達しました」との応答の等価物が検索要求まで受信され、パーティションが閉じられたことを示す場合）、Ｗ１は新しいパーティション情報を求める要求を再度ＳＭＳ制御サブシステムに送信してもよく、要素２８０１以降の操作が繰り返されてもよい。
図２９は、少なくともいくつかの実施形態による、ストリーム処理ステージのワーカーノードによって実行されてもよいロードバランシング操作の態様を説明する。要素２９０１に示されるように、高いリソース利用レベルの検知などの多様なトリガする条件のいずれかの検知時に、または構成可能なスケジュールに基づいて、ロードバランシング分析がそのステージ上で実行されることをワーカーノードＷ１が判定してもよい。Ｗ１は、ＰＡテーブルにおけるエントリを調べ（要素２９０４）、ステージのための様々な作業負荷メトリクスを決定してもよい。そのようなメトリクスは、ワーカーノードに割り当てられる平均的な数のパーティション、（作業負荷レベルインジケータがテーブルに保存される実施形態における）ワーカーノードの、または異なるパーティションの平均的な作業負荷レベル、ワーカーノードごとの作業負荷の範囲または分散などを含んでもよい。
Ｗ１はその後、（例えば、Ｗ１に割り当てられるパーティション数、及び／またはパーティションごとの作業負荷レベルインジケータに基づいて）それ自体の作業負荷をメトリクスの一部または全部と比較してもよい。一般に、Ｗ１が過負荷であるか、Ｗ１が低負荷であるか、またはＷ１の作業負荷が高すぎも低すぎもしないとの３つのタイプの結論のいずれかに達することができる。「高すぎる」または「低すぎる」作業負荷レベルは、いくつかの実施形態においては、そのためにステージが構成されるクライアントが選択するポリシーによって、または他の実施形態においては、いくつかのデフォルトのヒューリスティック群を利用して定義されてもよい。例えば、いくつかの最小付加閾値Ｔ１を下回るなど、Ｗ１がその作業負荷が低すぎることを判定する場合には（要素２９０７）、よりビジーなまたはより負荷が高いワーカーノードＷｋが識別されてもよい（要素２９１０）。Ｗ１はその後、例えば、ＰｍのエントリをＰＡテーブルにおいて修正することを試みるか、そのような修正を要求するか（Ｗｋのために生成されている通知につながる可能性がある）、またはＷｋを直接要求することによって、１つ以上のパーティションＷｋからＰｍのそれ自体への転送処理を起動してもよい（要素２９１３）。
例えば、最大閾値Ｔ２を上回るなど、作業負荷が高すぎることをＷ１が判定する場合（要素２９１６）、その割り当てられたパーティションのうち放棄する（すなわち、他のワーカーノードによる割り当てのために解放する）ための１つ以上のＰｎが識別されてもよい（要素２９１９）。Ｗ１はその後、例えば、その識別子をＰｎのためのエントリの割り当てられた列から取り除くことによって、ＰＡテーブルにおいて適切なエントリを修正してもよい（要素２９２２）。Ｗ１の作業負荷が高すぎも低すぎもしなかった場合、またはＷ１がその作業負荷を増加させるかもしくは減少させるために上述の種類のアクションを取った後、それが割り当てられるパーティションのレコードの処理をＷ１が再開してもよい（要素２９２５）。他のロードバランシング分析をトリガする条件が満たされる場合に、要素２９０１以降に対応する操作が繰り返されてもよい。図２９において説明する操作においては、Ｗ１がそれ自体の作業負荷に対する不均衡を検知する際にのみ、作業負荷の変更を起動するように示されることに留意されたい。他の実施形態では、Ｗ１がそれ以外のワーカーノード間で不均衡を検知する場合、例えば、Ｗ２がＷ３よりもはるかに低い作業負荷レベルを有すると判定する場合に、にリバランシングアクションを起動してもよい。いくつかの実装においては、Ｗ１が作業負荷の不均衡を検知する場合に、（例えば、図３で示すようなｒｅｐａｒｔｉｔｉｏｎＳｔｒｅａｍＳＭＳ ＡＰＩ、またはその等価物を呼び出すことにより）動的再分割を要求するか、または起動してもよい。いくつかの実施形態では、図２９において説明する種類の操作が新しく構成されたワーカーノードによって実行されてもよい。例えば、ステージがすでにしばらくの間作動した後に新しいノードがステージに追加される際に、負荷が重い既存のノードからのパーティションの再割り当てを要求することで、新しいノードがそれらの存在を既存のノードに間接的に通知してもよい。いくつかの実施形態では、ＳＰＳワーカーノードのための上述と同様の分散制御技術が同様に、または代わりに、１つ以上のＳＭＳサブシステムにおいて利用されてもよい。例えば、採集、記憶または検索サブシステムのノードが、ＰＡテーブルと同様の共有されたデータ構造を利用して、それらの作業負荷を調整してもよい。
様々な実施形態において、図１７〜図２４および図２７〜２９の流れ図において説明される以外の操作が、上述のストリーム管理サービス及び／またはストリーム処理機能を実装するたえに利用されてもよいことに留意されたい。、いくつかの実施形態では、図示される操作のいくつかが実装されなくてもよく、または異なる順序で、もしくは順次ではなく並列に実装されてもよい。様々な実施形態において、プログラムインターフェイスがサポートされるＳＭＳおよびＳＰＳ関数のそれぞれに関して、インターフェイスを実装するために、ウェブページ、ウェブサイト、ウェブ-サービスＡＰＩ、他のＡＰＩ、コマンドラインツール、グラフィックユーザーインターフェイス、モバイルアプリケーション（ａｐｐ）、タブレットａｐｐなどの利用を含めた１つ以上の技術の任意の組み合わせが利用されてもよいことにも留意されたい。
利用例
スケーラブルな分割を利用した、ストリームデータレコードの収集、記憶、検索および段階的処理のための、動的に構成可能な管理されたマルチテナントサービスを構築する上述の技術が、いくつかのシナリオにおいて有用である場合がある。例えば、大規模なプロバイダーネットワークが、いくつかの異なるマルチテナントまたはシングルテナントサービスのサービスインスタンスを数万のクライアントのために同時に実装する数千のインスタンスホストを含んでもよい。様々なインスタンスおよびホスト上にインストールされた監視及び／または請求を行うエージェントは、正確な請求レコードを生成するために記憶され、分析されなければならない可能性がある数千のメトリックレコードを迅速に生成し、プロバイダーネットワークのデータセンターのための効果的な整備計画を決定し、ネットワーク攻撃を検知するなどしてもよい。監視レコードがスケーラブルな採集および記憶のためのＳＭＳへの入力ストリームを形成してもよく、記載されるＳＰＳ技術が収集されたメトリクスの分析のために実装されてもよい。同様に、（例えば、分散したアプリケーションのノードからのアプリケーションログ、またはデータセンターにおけるホストもしくは計算インスタンスからのシステムログなどの）多数のログソースから多数のログレコードを収集し分析するためのアプリケーションは、また、ＳＭＳおよびＳＰＳ機能を利用することができる場合がある。少なくともいくつかの環境では、ＳＰＳ処理操作が、リアルタイムＥＴＬ（Ｅｘｔｒａｃｔ−Ｔｒａｎｓｆｏｒｍ−Ｌｏａｄ）処理操作（すなわち、受信されるデータレコードを宛先にロードするために、オフラインで変換を行う代わりにリアルタイムで変換する操作）、またはデータウェアハウスへの挿入のためのデータレコードの変換を含んでもよい。データをデータウェアハウスにリアルタイムでロードするためのＳＭＳ／ＳＰＳの組み合わせの利用により、分析のためにデータがウェアハウスに挿入することが可能である前に、１つ以上のデータソースからのデータをクリーンにし、監督するために通常必要とされる遅延が回避される場合がある。
いくつかの異なる「ビッグデータ」アプリケーションがまた、ＳＭＳおよびＳＰＳ技術を利用して構築されてもよい。例えば、様々な形式のソーシャルメディア対話において、トレンドの分析がストリームを利用して効率的に実行されてもよい。ユーザの位置情報などの、携帯電話またはタブレットコンピュータから収集されるデータがストリームレコードとして管理されてもよい。例えば、監視カメラ群から収集される聴覚または視覚情報は、スケーラブルに収集され、処理されることが可能であり、潜在的に様々な種類の攻撃を防止する助けとなるストリーミングデータ群の別のカテゴリを表してもよい。例えば、気象衛星、海に拠点を置くセンサー、森林に拠点を置くセンサー、天体望遠鏡などから収集される、増加する一方のデータ群の分析を要求する科学的手法が、また、本明細書に記載のストリーム管理および処理能力により利点を得る場合がある。柔軟なポリシーを用いた構成オプションおよび価格オプションが、異なるタイプのユーザがそれらの特定の予算およびデータ持続性／可用性要件に適合するように、ストリーミング機能をカスタマイズする上での助けとなってもよい。
本開示の実施形態については、以下の節の観点から記すことが可能である。
１．
（ａ）制御ノード、（ｂ）レコード採集ノード、（ｃ）レコード記憶ノード、（ｄ）レコード検索ノードおよび（ｅ）レコード処理ノード、を含む１つ以上の機能カテゴリのノードのための配置オプションを含む特定のストリームのデータレコードのための複数のセキュリティ関連のオプションからクライアントが選択を行うことを可能にするプログラムインターフェイス群を実装し、
前記プログラムインターフェイス群のプログラムインターフェイスを介して、特定のストリームのために選択された配置オプションであって、それに従って前記特定のストリームに関連する第１の機能カテゴリのノードがプロバイダーネットワークの１つ以上のデータセンターにおいて構成され、前記特定のストリームに関連する第２の機能カテゴリのノードが前記プロバイダーネットワークの外部設備において構成されるような前記配置オプションを含む１つ以上の要求を受信し、
前記プロバイダーネットワークの１つ以上のデータセンターにおいて前記第１の機能カテゴリの１つ以上のノードを構成し、
前記プロバイダーネットワークの前記外部設備において前記第２の機能カテゴリの１つ以上のノードの構成を起動し、また、
前記特定のストリームのデータレコードの収集を開始するために、前記データストリームに割り当てられた１つ以上のレコード採集ノードを起動する、
ように構成される１つ以上の計算装置、
を含むシステム。
２．
前記第１の機能カテゴリが、レコード記憶ノードを含み、前記第２の機能カテゴリが、レコード処理ノードを含む、節１に記載のシステム。
３．
前記複数のセキュリティ関連のオプションが、前記クライアントに関連し前記プロバイダーネットワークにおいて実装される隔離された仮想ネットワーク内に、特定の機能カテゴリの１つ以上のノードを構成するためのオプションを含む、節１に記載のシステム。
４．
前記プロバイダーネットワークが、複数のインスタンスホストを利用するマルチテナント計算サービスを実装し、
前記複数のインスタンスホストのうちの少なくともいくつかのインスタンスホストが、それぞれ、複数のクライアントの代わりに計算インスタンスをインスタンス化するように構成可能であり、
記複数のセキュリティ関連のオプションが、ノードの特定の機能カテゴリの１つ以上のノードを、１つ以下のクライアントをホスティングするインスタンスホスト上でインスタンス化するオプションを含む、節１に記載のシステム。
５．
前記複数のセキュリティ関連のオプションが、１つ以上の機能カテゴリのノードにおいて、データレコードのネットワークリンクを用いた送信の前に前記データレコードを暗号化するオプションを含む、節１に記載のシステム。
６．
１つ以上の計算装置による、データストリーム管理サービスのクライアントが特定のストリームのために、前記ストリーム管理サービスのノードの１つ以上の機能カテゴリのための配置オプションを選択することを可能にするプログラムインターフェイス群の実装であって、前記ストリーム管理サービスは、少なくとも（ａ）データ採集ノードおよび（ｂ）データ処理ノードを含む複数の機能カテゴリのノードを利用して前記実装すること、
前記プログラムインターフェイス群のプログラムインターフェイスを介した、特定のストリームのために選択される配置オプションであって、それに従って第１の機能カテゴリのノードが第１のセキュリティプロファイルを有するリソースを利用して構成され、第２の機能カテゴリのノードは、異なるセキュリティプロファイルを有するリソースを利用して構成されるような前記配置オプションを含む要求を受信すること、
前記第１のセキュリティプロファイルを有する第１の選択されたリソースで、前記第１の機能カテゴリの１つ以上のノードの構成を起動すること、
前記異なるセキュリティプロファイルを有する第２の選択されたリソースで、前記第２の機能カテゴリの１つ以上のノードの構成を起動すること、を、
１つ以上の計算装置によって実行すること、
を含む方法。
７．
前記複数の機能カテゴリが、
（ａ）データ記憶ノード、（ｂ）データ検索ノードおよび（ｃ）制御ノード、
の１つまたは複数を含む、節６に記載の方法。
８．
前記要求に従って前記第１の選択されたリソースが、プロバイダーネットワークのデータセンターにおいて実装され、
第２の選択されたリソースが、前記プロバイダーネットワークの外部設備において実装される、節６に記載の方法。
９．
前記プロバイダーネットワークの前記外部設備が、前記プロバイダーネットワークに特定のクライアントによる利用専用の非共有物理リンクを介してリンクされる、節８に記載の方法。
１０．
前記第１の機能カテゴリが、データ採集ノードを含み、ノードの前記第２の機能カテゴリが、データ処理ノードを含む、節８に記載の方法。
１１．
前記第２の選択されたリソースが、（ａ）前記プロバイダーネットワークにおいてサポートされない能力を有するハードウェア装置または（ｂ）前記プロバイダーネットワークにおいてサポートされない能力を有するソフトウェアモジュール、の１つまたは複数を含む、節６に記載の方法。
１２．
前記第１の選択されたリソースが、前記要求に従って前記プロバイダーネットワークの仮想計算サービスの第１の計算インスタンスにおいて実装され、
第２の選択されたリソースが、前記仮想計算サービスの第２の計算インスタンスにおいて実装され、
前記第１の機能カテゴリが、クライアントの提供による実行可能なプログラムを利用して実行され、
前記第１の機能カテゴリの前記第１の計算インスタンスにおける実行が、前記ストリーム管理サービスによって管理され、
前記第２の機能カテゴリの操作が、前記クライアントによって管理される、節６に記載の方法。
１３．
前記要求に従って、前記プロバイダーネットワークにおいて実装された前記クライアントの前記隔離された仮想ネットワーク内で、前記第１の選択されたリソースが実装される、節６に記載の方法。
１４．
前記プロバイダーネットワークが複数のインスタンスホストを利用してマルチテナント計算サービスを実装し、
前記複数のインスタンスホストのうちの少なくともいくつかのインスタンスホストがそれぞれ、複数のクライアントの代わりに計算インスタンスをインスタンス化するように構成可能であり、
前記要求に従って、２つ以上のクライアントの代わりに計算インスタンスをインスタンス化するように構成可能であるインスタンスホストを前記第１の選択されたリソースが含む、節６に記載の方法。
１５．
データレコードのネットワークを用いた送信前に、１つ以上の機能カテゴリのノードにおける前記データレコードの暗号化をクライアントが要求することを可能にするプログラムインターフェイスを実装すること、を、
前記１つ以上の計算装置が実行することをさらに含む、節６に記載の方法。
１６．
前記複数の機能カテゴリの１つ以上の機能カテゴリのノードの機能のサブセットを少なくとも実装するための、前記プロバイダーネットワークの外部設備の１つ以上の計算装置においてインストール可能である、実行可能なモジュールのライブラリを提供すること、を、
前記１つ以上の計算装置が実行することをさらに含む、節６に記載の方法。
１７．
前記第１の機能カテゴリの１つ以上のノードの前記構成の前記起動が、可用性要件にしたがった、複数のデータセンターのそれぞれにおける少なくとも１つのノードの前記構成の起動を含む、節６に記載の方法。
１８．
１つ以上のプロセッサにおいて実行される際に、
複数の機能カテゴリのノードが構成される特定のデータストリームのために選択されたセキュリティオプションを含む構成要求であり、前記複数の機能カテゴリが少なくともデータ採集カテゴリおよびデータ検索カテゴリを含み、前記セキュリティオプションが少なくとも１つの機能カテゴリのノードのために利用されるリソースのセキュリティプロファイルを示す前記構成要求を受信し、
前記選択されたセキュリティオプションを含む前記要求に従って、第１のセキュリティプロファイルを有するリソースにおいて第１の機能カテゴリのノードを構成し、
第２の機能カテゴリのノードの、異なるセキュリティプロファイルを有する異なるリソースにおける構成を起動する、
プログラム命令を記憶させる持続性コンピュータアクセス可能媒体。
１９．
前記複数の機能カテゴリが、
（ａ）データ記憶カテゴリ、（ｂ）データ処理カテゴリまたは（ｃ）制御カテゴリ、
の１つまたは複数を含む、節１８に記載の持続性コンピュータアクセス可能媒体。
２０．
前記第１の機能カテゴリに前記ノードのために利用される前記リソースが、プロバイダーネットワーク内に位置し、
前記第２の機能カテゴリのノードのために利用される前記リソースが、前記プロバイダーネットワーク外に位置する、節１８に記載の持続性コンピュータアクセス可能媒体。
２１．
前記第１の機能カテゴリの１つ以上のノードが、前記構成要求に従って、プロバイダーネットワークにおいて実装される隔離された仮想ネットワーク内の計算装置において構成される、節１８に記載の持続性コンピュータアクセス可能媒体。
２２．
前記第１の機能カテゴリの少なくとも１つのノードが、前記構成要求に従って、マルチテナント仮想計算サービスの特定のインスタンスホストにおいてインスタンス化され、
前記特定のインスタンスホストが、１つ以下のクライアントに代わって計算インスタンスを起動するように構成される、節１８に記載の持続性コンピュータアクセス可能媒体。
説明するコンピュータシステム
少なくともいくつかの実施形態では、ＳＭＳサブシステムのコンポーネント（例、採集、記憶、検索および制御サブシステム）を実装する技術、ならびにＳＰＳワーカーおよび制御ノードを含む、本明細書に記載の１つ以上の技術の一部または全部を実装するサーバが、１つ以上のコンピュータアクセス可能媒体を含むかまたはそれにアクセスするよう構成される汎用コンピュータシステムを含んでもよい。図３０は、そのような汎用計算装置９０００を説明する。説明する実施形態において、計算装置９０００は、入力／出力（Ｉ／Ｏ）インターフェイス９０３０を介してシステムメモリ９０２０に連結される１つ以上のプロセッサ９０１０を含む。計算装置９０００はさらに、Ｉ／Ｏインターフェイス９０３０に連結されるネットワークインターフェイス９０４０を含む。
様々な実施形態において、計算装置９０００は１つのプロセッサ９０１０を含む単一プロセッサシステムであってもよいか、または、いくつかのプロセッサ９０１０（たとば、２、４、８、または他の好適な数）を含むマルチプロセッサシステムであってもよい。プロセッサ９０１０は、命令を実行することができる任意の好適なプロセッサであってもよい。例えば、様々な実施形態において、プロセッサ９０１０は、ｘ８６、ＰｏｗｅｒＰＣ、ＳＰＡＲＣ、もしくはＭＩＰＳＩＳＡ、または他の任意の好適なＩＳＡなどの多様な命令セットアーキテクチャ（ＩＳＡ）を実装する、汎用または組み込み型プロセッサであってもよい。マルチプロセッサシステムにおいては、プロセッサ９０１０のそれぞれが共通して同じＩＳＡを実装してもよいが、必ずしもそうでなくてもよい。いくつかの実装においては、従来のプロセッサの代わりに、またはそれに加えてグラフィックスプロセッシングユニット（ＧＰＵ）が利用されてもよい。
システムメモリ９０２０は、命令および（１つ以上の）プロセッサ９０１０によってアクセス可能なデータを記憶させるよう構成されてもよい。様々な実施形態において、システムメモリ９０２０が、スタティックランダムアクセスメモリ（ＳＲＡＭ）、同期型ダイナミックＲＡＭ（ＳＤＲＡＭ）、不揮発性／フラッシュタイプメモリ、または任意の他のタイプのメモリなどの任意の好適なメモリ技術を利用して実装されてもよい。説明する実施形態においては、上述のこれらの方法、技術およびデータなどの１つ以上の所望の関数を実装するプログラム命令およびデータが、システムメモリ９０２０内でコード９０２５およびデータ９０２６として記憶されて示される。
１つの実施形態において、プロセッサ９０１０、システムメモリ９０２０、および、データオブジェクトパーティションの物理レプリカを記憶させるために利用される様々な種類の永続性及び／または揮発性記憶装置などのネットワークインターフェイス９０４０または他の周辺インターフェイスを含む任意の周辺装置の間のＩ／Ｏトラフィックを装置内で調整するようＩ／Ｏインターフェイス９０３０が構成されてもよい。いくつかの実施形態では、Ｉ／Ｏインターフェイス９０３０が、あるコンポーネント（例、システムメモリ９０２０）から別のコンポーネント（例、プロセッサ９０１０）による利用に好適なフォーマットにデータ信号を変換するために、任意の必要なプロトコル、タイミングまたは他のデータ変換を実行してもよい。いくつかの実施形態では、例えば、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）バス標準またはユニバーサルシリアルバス（ＵＳＢ）標準のバリアントなどの様々な種類の周辺バスを通じて取り付けられた装置のサポートを、Ｉ／Ｏインターフェイス９０３０が含んでもよい。いくつかの実施形態では、Ｉ／Ｏインターフェイス９０３０の関数が、例えば、ノースブリッジおよびサウスブリッジなどの２つ以上の個別のコンポーネントに分割されてもよい。またいくつかの実施形態では、システムメモリ９０２０へのインターフェイスなどのＩ／Ｏインターフェイス９０３０の一部または全部の機能が、プロセッサ９０１０に直接組み込まれてもよい。
例えば、図１から図２９において説明するように、計算装置９０００と、１つ以上のネットワーク９０５０に取り付けられる他のコンピュータシステムまたは装置などの他の装置９０６０との間でデータを交換することができるように、ネットワークインターフェイス９０４０が構成されてもよい。様々な実施形態において、ネットワークインターフェイス９０４０は、例えば、Ｅｔｈｅｒｎｅｔネットワークなどのタイプの任意の好適な有線または無線の一般的なデータネットワークを介して通信をサポートしてもよい。さらに、ネットワークインターフェイス９０４０は、アナログ音声ネットワークもしくはデジタルファイバ通信ネットワークなどの遠距離通信／電話ネットワークを介して、Ｆｉｂｒｅ ＣｈａｎｎｅｌＳＡＮなどの記憶領域ネットワークを介して、または他の任意の好適なタイプのネットワーク及び／またはプロトコルを介して、通信をサポートしてもよい。
いくつかの実施形態では、システムメモリ９０２０が、対応する方法および装置の実施形態を実装するための図１から図２９に関する上述のプログラム命令およびデータを記憶させるように構成されるコンピュータアクセス可能媒体の１つの実施形態であってもよい。しかし他の実施形態では、プログラム命令及び／またはデータが異なるタイプのコンピュータアクセス可能媒体において受信され、送信されるか、または記憶されてもよい。コンピュータアクセス可能媒体は、一般的に、例えば、Ｉ／Ｏインターフェイス９０３０を介して計算装置９０００に連結されるディスクまたはＤＶＤ／ＣＤなどの磁気または光学媒体のような持続性記憶媒体またはメモリ媒体を含んでもよい。持続性コンピュータアクセス可能記憶媒体は、また、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭなど）、ＲＯＭなどの、計算装置９０００のいくつかの実施形態においてシステムメモリ９０２０または別のタイプのメモリとして含まれてもよい任意の揮発性または不揮発性メディアを含んでもよい。さらに、コンピュータアクセス可能媒体は、ネットワークインターフェイス９０４０を介して実装されてもよい、伝送媒体またはネットワーク及び／または無線リンクなどの通信媒体を介して伝達される電気、電磁波もしくはデジタル信号信号を含んでもよい。図３０で説明するような複数の計算装置の一部または全部が、様々な実施形態において記載される機能を実装するために利用されてもよい。例えば、多様な異なる装置およびサーバにおいて作動するソフトウェアコンポーネントが、機能を提供するために協働してもよい。いくつかの実施形態では、記載された機能の一部または全部が、汎用コンピュータシステムを利用しての実装に加えて、またはその代わりに、記憶装置、ネットワーク装置または専用コンピュータシステムを利用して実装されてもよい。「計算装置」の用語は、本明細書内で使用されるように、少なくともこれらのタイプの装置すべてを表すが、これらのタイプの装置に限定されない。
結論
様々な実施形態は、コンピュータアクセス可能媒体に関する上述の説明に従って実装される、受信、送信または記憶命令及び／またはデータをさらに含んでもよい。コンピュータアクセス可能媒体は、一般的に、例えば、ディスクまたはＤＶＤ／ＣＤ-ＲＯＭなどの磁気または光学媒体、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ、ＲＤＲＡＭ、ＳＲＡＭなど）、ＲＯＭなどの揮発性または不揮発性媒体、ならびに伝送媒体またはネットワーク及び／または無線リンクなどの通信媒体を介して伝達される電気、電磁波、またはデジタル信号などの信号などの記憶媒体またはメモリ媒体を含んでもよい。
図面で説明し、本明細書内に記載する様々な方法は、方法の例示的な実施形態を表す。方法がソフトウェア、ハードウェアまたはそれらの組み合わせにおいて実装されてもよい。方法の順序は変更されてもよく、様々な要素が追加され、再び順序付けられ、組み合わせられ、省略され、修正されるなどしてもよい。
本開示の利益を得る当業者にとって明白であるように、様々な修正および変更が行われてもよい。そのような修正および変更を包括することが意図され、従って、上記の説明は限定的意味ではなく説明的意味であると見なされるべきである。

Claims (15)

  1. １つ以上の計算装置による、データストリーム管理サービスのクライアントが特定のストリームのために、前記ストリーム管理サービスのノードの１つ以上の機能カテゴリのための配置オプションを選択することを可能にするプログラムインターフェイス群を実装することであって、前記ストリーム管理サービスは、少なくとも（ａ）データ採集ノードおよび（ｂ）データ処理ノードを含む複数の機能カテゴリのノードを利用して前記実装すること、
    前記プログラムインターフェイス群のプログラムインターフェイスを介した、特定のストリームのために選択される配置オプションであって、それに従って第１の機能カテゴリのノードは、第１のセキュリティプロファイルを有するリソースを利用して構成され、第２の機能カテゴリのノードは、異なるセキュリティプロファイルを有するリソースを利用して構成されるような前記配置オプションを含む要求を受信すること、
    前記第１のセキュリティプロファイルを有する第１の選択されたリソースで、前記第１の機能カテゴリの１つ以上のノードの構成を起動すること、
    前記異なるセキュリティプロファイルを有する第２の選択されたリソースで、前記第２の機能カテゴリの１つ以上のノードの構成を起動すること、を、
    １つ以上の計算装置によって実行すること、
    を含む方法。
  2. 前記複数の機能カテゴリは、
    （ａ）データ記憶ノード、（ｂ）データ検索ノードおよび（ｃ）制御ノード、の１つまたは複数を含む、請求項１に記載の方法。
  3. 前記要求に従って前記第１の選択されたリソースは、プロバイダーネットワークのデータセンターにおいて実装され、
    第２の選択されたリソースは、前記プロバイダーネットワークの外部設備において実装される、請求項１に記載の方法。
  4. 前記プロバイダーネットワークの前記外部設備は、特定のクライアントによる利用専用の非共有物理リンクを介して前記プロバイダーネットワークにリンクされる、請求項３に記載の方法。
  5. 前記第１の機能カテゴリは、データ採集ノードを含み、
    ノードの前記第２の機能カテゴリは、データ処理ノードを含む、請求項３に記載の方法。
  6. 前記要求に従って前記第１の選択されたリソースは、前記プロバイダーネットワークの仮想計算サービスの第１の計算インスタンスにおいて実装され、
    第２の選択されたリソースは、前記仮想計算サービスの第２の計算インスタンスにおいて実装され、
    前記第１の機能カテゴリは、クライアントの提供による実行可能なプログラムを利用して実行され、
    前記第１の機能カテゴリの前記第１の計算インスタンスにおける実行は、前記ストリーム管理サービスによって管理され、
    前記第２の機能カテゴリの操作は、前記クライアントによって管理される、請求項１に記載の方法。
  7. 前記要求に従って、前記プロバイダーネットワークにおいて実装された前記クライアントの前記隔離された仮想ネットワーク内で、前記第１の選択されたリソースが実装される、請求項１に記載の方法。
  8. 前記プロバイダーネットワークは、複数のインスタンスホストを利用してマルチテナント計算サービスを実装し、
    前記複数のインスタンスホストのうちの少なくともいくつかのインスタンスホストは、それぞれ、複数のクライアントの代わりに計算インスタンスをインスタンス化するように構成可能であり、
    前記第１の選択されたリソースは、前記要求に従って、２つ以上のクライアントの代わりに計算インスタンスをインスタンス化するように構成可能であるインスタンスホストを含む、請求項１に記載の方法。
  9. データレコードのネットワークを用いた送信前に、１つ以上の機能カテゴリのノードにおける前記データレコードの暗号化をクライアントが要求することを可能にするプログラムインターフェイスを実装すること、を、
    前記１つ以上の計算装置が実行すること、をさらに含む、請求項１に記載の方法。
  10. 前記複数の機能カテゴリの１つ以上の機能カテゴリのノードの機能のサブセットを少なくとも実装するための、前記プロバイダーネットワークの外部設備の１つ以上の計算装置においてインストール可能である、実行可能なモジュールのライブラリを提供すること、を、
    前記１つ以上の計算装置が実行すること、をさらに含む、請求項１に記載の方法。
  11. 前記第１の機能カテゴリの１つ以上のノードの前記構成の前記起動は、可用性要件にしたがった、複数のデータセンターのそれぞれにおける少なくとも１つのノードの前記構成の起動を含む、請求項１に記載の方法。
  12. １つ以上のプロセッサと、１つ以上のメモリを含むシステムであって、
    前記１つ以上の１つ以上のメモリは、
    前記１つ以上のプロセッサにおいて実行される際に前記システムに、
    複数の機能カテゴリのノードが構成される特定のデータストリームのために選択されたセキュリティオプションを含む構成要求であり、前記複数の機能カテゴリが少なくともデータ採集カテゴリおよびデータ検索カテゴリを含み、前記セキュリティオプションが少なくとも１つの機能カテゴリのノードのために利用されるリソースのセキュリティプロファイルを示す前記構成要求を受信させ、
    前記選択されたセキュリティオプションを含む前記要求に従って、第１のセキュリティプロファイルを有するリソースにおいて第１の機能カテゴリのノードを構成させ、
    第２の機能カテゴリのノードの、異なるセキュリティプロファイルを有する異なるリソースにおける構成を起動させる、プログラム命令を含む、システム。
  13. 前記複数の機能カテゴリは、
    （ａ）データ記憶カテゴリ、（ｂ）データ処理カテゴリまたは（ｃ）制御カテゴリ、
    の１つまたは複数を含む、請求項１２に記載のシステム。
  14. 前記第１の機能カテゴリに前記ノードのために利用される前記リソースは、プロバイダーネットワーク内に位置し、
    前記第２の機能カテゴリのノードのために利用される前記リソースは、前記プロバイダーネットワーク外に位置する、請求項１２に記載のシステム。
  15. 前記構成要求に従って、前記第１の機能カテゴリの１つ以上のノードは、プロバイダーネットワークにおいて実装される隔離された仮想ネットワーク内の計算装置において構成される、請求項１２に記載のシステム。
JP2016553272A 2013-11-11 2014-11-11 データストリームのためのクライアント構成可能なセキュリティオプション Active JP6250189B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US14/077,158 2013-11-11
US14/077,158 US9276959B2 (en) 2013-11-11 2013-11-11 Client-configurable security options for data streams
PCT/US2014/065046 WO2015119691A2 (en) 2013-11-11 2014-11-11 Client-configurable security options for data streams

Publications (2)

Publication Number Publication Date
JP2016541081A true JP2016541081A (ja) 2016-12-28
JP6250189B2 JP6250189B2 (ja) 2017-12-20

Family

ID=53045007

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016553272A Active JP6250189B2 (ja) 2013-11-11 2014-11-11 データストリームのためのクライアント構成可能なセキュリティオプション

Country Status (7)

Country Link
US (1) US9276959B2 (ja)
EP (1) EP3069495B1 (ja)
JP (1) JP6250189B2 (ja)
CN (1) CN105723679B (ja)
AU (2) AU2014381598A1 (ja)
CA (1) CA2929776C (ja)
WO (1) WO2015119691A2 (ja)

Families Citing this family (62)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11176111B2 (en) 2013-03-15 2021-11-16 Nuodb, Inc. Distributed database management system with dynamically split B-tree indexes
US9501363B1 (en) 2013-03-15 2016-11-22 Nuodb, Inc. Distributed database management system with node failure detection
US10740323B1 (en) 2013-03-15 2020-08-11 Nuodb, Inc. Global uniqueness checking in distributed databases
WO2015047140A1 (en) * 2013-09-24 2015-04-02 Telefonaktiebolaget L M Ericsson (Publ) Simplified creation of an application in a selected stream processing platform
US9720989B2 (en) 2013-11-11 2017-08-01 Amazon Technologies, Inc. Dynamic partitioning techniques for data streams
US9668172B2 (en) * 2013-12-11 2017-05-30 Viavi Solutions Uk Limited Method and apparatus for enabling near real time data analysis
US10164944B1 (en) * 2014-08-05 2018-12-25 Amdocs Development Limited System, method, and computer program for implementing a virtual obfuscation service in a network
US9639589B1 (en) 2013-12-20 2017-05-02 Amazon Technologies, Inc. Chained replication techniques for large-scale data streams
US9397905B1 (en) * 2014-01-24 2016-07-19 Amazon Technologies, Inc. Aggregated health check of a multi-tenant service container
US10635669B1 (en) * 2014-01-27 2020-04-28 Microstrategy Incorporated Data engine integration and data refinement
US11921715B2 (en) 2014-01-27 2024-03-05 Microstrategy Incorporated Search integration
US10255320B1 (en) 2014-01-27 2019-04-09 Microstrategy Incorporated Search integration
US11386085B2 (en) 2014-01-27 2022-07-12 Microstrategy Incorporated Deriving metrics from queries
US20150286701A1 (en) * 2014-04-04 2015-10-08 Quantum Corporation Data Classification Aware Object Storage
US10057156B2 (en) 2014-08-08 2018-08-21 At&T Intellectual Property I, L.P. Hierarchical network configuration
US10146293B2 (en) * 2014-09-22 2018-12-04 Western Digital Technologies, Inc. Performance-aware power capping control of data storage devices
FR3029311B1 (fr) * 2014-11-27 2017-01-06 Thales Sa Procede de gestion d'une architecture et architecture associee
US10095547B1 (en) * 2015-03-13 2018-10-09 Twitter, Inc. Stream processing at scale
US10884869B2 (en) 2015-04-16 2021-01-05 Nuodb, Inc. Backup and restore in a distributed database utilizing consistent database snapshots
US10180954B2 (en) 2015-05-29 2019-01-15 Nuodb, Inc. Disconnected operation within distributed database systems
US10067969B2 (en) 2015-05-29 2018-09-04 Nuodb, Inc. Table partitioning within distributed database systems
US9965206B2 (en) 2015-10-23 2018-05-08 Western Digital Technologies, Inc. Enhanced queue management for power control of data storage device
CN105577675A (zh) * 2015-12-31 2016-05-11 深圳前海微众银行股份有限公司 多租户资源管理的方法及装置
EP3403432B1 (en) 2016-01-15 2020-11-18 Microsoft Technology Licensing, LLC Database based redundancy in a telecommunications network
US10440152B2 (en) 2016-01-27 2019-10-08 Oracle International Corporation System and method of initiating virtual machine configuration on a subordinate node from a privileged node in a high-performance computing environment
US20170235817A1 (en) 2016-02-12 2017-08-17 Nutanix, Inc. Entity database feedback aggregation
US10437853B2 (en) * 2016-03-16 2019-10-08 Microsoft Technology Licensing, Llc Tracking data replication and discrepancies in incremental data audits
US20170270153A1 (en) * 2016-03-16 2017-09-21 Linkedin Corporation Real-time incremental data audits
US10122788B2 (en) * 2016-03-29 2018-11-06 Amazon Technologies, Inc. Managed function execution for processing data streams in real time
US10530823B2 (en) 2016-08-10 2020-01-07 At&T Intellectual Property I, L.P. Network stream processing to ensuring a guarantee that each record is accounted for exactly once
US10917324B2 (en) * 2016-09-28 2021-02-09 Amazon Technologies, Inc. Network health data aggregation service
US10893086B2 (en) * 2016-11-10 2021-01-12 Sony Corporation Node type based control of assistance for data streaming
US11080274B2 (en) 2017-01-17 2021-08-03 Futurewei Technologies, Inc. Best-efforts database functions
US10805241B2 (en) * 2017-01-17 2020-10-13 Futurewei Technologies, Inc. Database functions-defined network switch and database system
US10812543B1 (en) 2017-02-27 2020-10-20 Amazon Technologies, Inc. Managed distribution of data stream contents
US10817334B1 (en) * 2017-03-14 2020-10-27 Twitter, Inc. Real-time analysis of data streaming objects for distributed stream processing
EP3669286A4 (en) 2017-08-15 2021-06-23 NUODB Inc. DIVISION OF INDEX INTO DISTRIBUTED DATABASES
CN107665097B (zh) * 2017-08-22 2021-02-23 深圳市硅格半导体有限公司 一种固态硬盘分区的方法、装置及计算机可读存储介质
CN110019112B (zh) 2017-08-25 2023-10-31 阿里巴巴集团控股有限公司 数据事务处理方法、装置以及电子设备
US10628591B2 (en) * 2017-11-20 2020-04-21 Forcepoint Llc Method for fast and efficient discovery of data assets
US10606661B2 (en) * 2017-12-15 2020-03-31 Rubrik, Inc. On-demand provisioning of customized developer environments
US10956246B1 (en) 2018-07-16 2021-03-23 Amazon Technologies, Inc. Isolated read channel management interfaces at streaming data service
US11075984B1 (en) 2018-07-16 2021-07-27 Amazon Technologies, Inc. Workload management at streaming data service supporting persistent connections for reads
US10768830B1 (en) 2018-07-16 2020-09-08 Amazon Technologies, Inc. Streaming data service with isolated read channels
US10855754B1 (en) 2018-07-16 2020-12-01 Amazon Technologies, Inc. Isolated read channel categories at streaming data service
US11070600B1 (en) 2018-07-16 2021-07-20 Amazon Technologies, Inc. Optimization techniques to support lagging readers at streaming data service
US10798140B1 (en) 2018-07-16 2020-10-06 Amazon Technologies, Inc. Stream data record reads using push-mode persistent connections
US11609933B1 (en) * 2018-07-18 2023-03-21 Amazon Technologies, Inc. Atomic partition scheme updates to store items in partitions of a time series database
CN109144487B (zh) * 2018-09-26 2024-02-13 河南智锐科技有限公司 进件业务开发方法、装置、计算机设备和存储介质
US11989186B2 (en) 2018-11-23 2024-05-21 Amazon Technologies, Inc. Scalable architecture for a distributed time-series database
US11934409B2 (en) 2018-11-23 2024-03-19 Amazon Technologies, Inc. Continuous functions in a time-series database
EP3912035A1 (en) 2019-01-15 2021-11-24 Microsoft Technology Licensing, LLC Dynamic auto-configuration of multi-tenant paas components
US11853317B1 (en) * 2019-03-18 2023-12-26 Amazon Technologies, Inc. Creating replicas using queries to a time series database
CN110119422B (zh) * 2019-05-16 2021-05-07 武汉神算云信息科技有限责任公司 小微信贷租户数据仓库数据处理***及设备
US11614970B2 (en) 2019-12-06 2023-03-28 Microstrategy Incorporated High-throughput parallel data transmission
CN111104428A (zh) * 2019-12-18 2020-05-05 深圳证券交易所 流计算方法、流计算装置、流计算***及介质
US11567965B2 (en) 2020-01-23 2023-01-31 Microstrategy Incorporated Enhanced preparation and integration of data sets
US11025688B1 (en) * 2020-04-16 2021-06-01 Capital One Services, Llc Automated streaming data platform
US11711381B2 (en) 2020-10-29 2023-07-25 International Business Machines Corporation Automatic hotspot identification in network graphs
CN115086689B (zh) 2021-03-15 2024-04-05 阿里巴巴创新公司 虚拟直播管理方法、电子设备及计算机存储介质
US20230297592A1 (en) * 2022-03-21 2023-09-21 Oracle International Corporation Custom stream partitioning services
WO2023235619A1 (en) * 2022-06-03 2023-12-07 Bluevoyant Llc Devices, methods, and systems for generating a highly-scalable, efficient composite record index

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005038113A (ja) * 2003-07-18 2005-02-10 Nec Corp シングルプロセッサ向けｏｓによる並列処理システムにおけるセキュリティ管理システム

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7386586B1 (en) 1998-12-22 2008-06-10 Computer Associates Think, Inc. System for scheduling and monitoring computer processes
WO2001022682A2 (en) 1999-09-22 2001-03-29 Streaming21, Inc. Method and system for providing real-time streaming services
US8055894B2 (en) 1999-11-09 2011-11-08 Google Inc. Process and streaming server for encrypting a data stream with bandwidth based variation
EP1359722A1 (en) 2002-03-27 2003-11-05 BRITISH TELECOMMUNICATIONS public limited company Data streaming system and method
TWI370979B (en) 2004-05-14 2012-08-21 Ibm Grid computing system, information processing unit, job execution request generation unit, control method, program, and recording medium
WO2006011270A1 (ja) * 2004-07-27 2006-02-02 Sharp Kabushiki Kaisha 擬似ビデオオンデマンドシステム、擬似ビデオオンデマンドシステムの制御方法、およびそれらに用いるプログラムおよび記録媒体
US20060264178A1 (en) * 2005-05-20 2006-11-23 Noble Gayle L Wireless diagnostic systems
TW200717246A (en) 2005-06-24 2007-05-01 Koninkl Philips Electronics Nv Self-synchronizing data streaming between address-based producer and consumer circuits
US7716180B2 (en) * 2005-12-29 2010-05-11 Amazon Technologies, Inc. Distributed storage system with web services client interface
US7633864B2 (en) * 2006-12-20 2009-12-15 Sun Microsystems, Inc. Method and system for creating a demilitarized zone using network stack instances
CA2705319C (en) 2007-11-10 2019-01-15 Laurence Reid Systems and methods for workflow automation, adaptation and integration
US8488661B2 (en) 2008-06-13 2013-07-16 Verizon Patent And Licensing Inc. Systems and methods for data streaming
EP2377032A4 (en) 2008-12-05 2012-11-07 Social Communications Co CADISM IN REAL INVISIBLE TIME
KR20130010911A (ko) 2008-12-05 2013-01-29 소우셜 커뮤니케이션즈 컴퍼니 실시간 커널
US9628535B2 (en) 2011-04-15 2017-04-18 International Business Machines Corporation Data streaming infrastructure for remote execution in a constrained environment
US8463633B2 (en) 2011-07-27 2013-06-11 Xerox Corporation Methods and systems for deploying a service workflow in a hybrid cloud environment
US8489680B1 (en) * 2011-08-18 2013-07-16 Google Inc. Transmission of input values using an unreliable communication link
US20130067109A1 (en) * 2011-09-12 2013-03-14 Tektronix, Inc. Monitoring Over-the-Top Adaptive Video Streaming
CN103281594A (zh) * 2012-01-12 2013-09-04 特克特朗尼克公司 监控基于开放互联网的自适应视频流式传输
US8775282B1 (en) * 2012-05-18 2014-07-08 Amazon Technologies, Inc. Capacity management of draining-state platforms providing network-accessible resources
CN103685395A (zh) * 2012-09-14 2014-03-26 腾讯科技（深圳）有限公司 对数据流进行分发处理的方法及***

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005038113A (ja) * 2003-07-18 2005-02-10 Nec Corp シングルプロセッサ向けｏｓによる並列処理システムにおけるセキュリティ管理システム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
北上眞二ほか: "オープンソースソフトウェア環境を基盤としたＭ２Ｍデータ分析サービスシステムの開発", 電子情報通信学会技術研究報告, vol. Ｖｏｌ．１１２ Ｎｏ．１７９, JPN6017018227, 14 August 2012 (2012-08-14), JP, pages ３３−３８ページ *

Also Published As

Publication number Publication date
CA2929776C (en) 2018-10-16
US9276959B2 (en) 2016-03-01
AU2018202230A1 (en) 2018-04-26
EP3069495B1 (en) 2019-08-28
AU2014381598A1 (en) 2016-06-02
JP6250189B2 (ja) 2017-12-20
CN105723679B (zh) 2019-04-26
EP3069495A4 (en) 2017-05-03
CN105723679A (zh) 2016-06-29
WO2015119691A2 (en) 2015-08-13
US20150135255A1 (en) 2015-05-14
WO2015119691A3 (en) 2015-10-29
CA2929776A1 (en) 2015-08-13
EP3069495A2 (en) 2016-09-21

Similar Documents

Publication Publication Date Title
JP6250189B2 (ja) データストリームのためのクライアント構成可能なセキュリティオプション
US10795905B2 (en) Data stream ingestion and persistence techniques
US10691716B2 (en) Dynamic partitioning techniques for data streams
JP6510112B2 (ja) データストリーム取り込み及び永続性ポリシ
EP3069274B1 (en) Managed service for acquisition, storage and consumption of large-scale data streams
AU2014346366B2 (en) Partition-based data stream processing framework

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170420

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170530

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170830

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20171114

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20171121

R150 Certificate of patent or registration of utility model

Ref document number: 6250189

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250