JP2018133105A - データストリーム取り込み及び永続性ポリシ - Google Patents

Abstract

【課題】 プログラムによるインタフェースが実装され、ストリーム管理サービスのクライアントがデータストリームのためにデータ取り込みポリシを選択するのを可能にする。
【解決手段】 少なくとも１回の取り込みポリシを選択するクライアント要求が受信される。少なくとも１回のポリシにより、クライアントは肯定応答が受信されるまで、１回以上のデータレコードの表示をサービスに伝送し得る。特定のデータレコードを表示する複数の伝送の受信に対応して、それぞれの肯定応答がクライアントに送信される。ストリームのために選択された永続性ポリシに基づいて、データレコードのコピーが、複数の伝送のうちの１つの特定の伝送に対応して、１つ以上の記憶位置に記憶される。
【選択図】図６

Description

データ記憶の費用が年とともに下落するに従い、また、計算インフラストラクチャの様
々な要素を相互接続する能力が改善するにつれ、多種多様のアプリケーションに対応可能
なより多くのデータが、場合により収集され分析され得る。例えば、携帯電話は、位置、
電話のユーザによって使用されるアプリケーション等を示すデータを生成することができ
、少なくともそのいくつかは、カスタマイズされたクーポン、広告等をユーザに提示する
ために、収集され分析され得る。監視カメラによって収集されたデータの分析は、犯罪を
防止し及び／または解決する上で有用であってよく、航空機のエンジン、自動車または複
雑な機械装置内部の様々な位置に埋め込まれたセンサから収集されたデータは、予防保全
、効率の向上及び費用の低減のような様々な目的に使用され得る。

ストリーミングデータ量の増加は、商品のハードウェアの使用増加に付随する（及び場
合によっては可能になった）。商品のハードウェア用の仮想化技術の到来は、多くの種類
のアプリケーション用の大規模な計算リソースを運用するに際し、様々な計算リソースが
効率的に、かつ安全に多数の顧客によって共有されるのを可能にするという利点を提供し
てきた。例えば、仮想化技術は、単一の物理的計算機によりホスティングされる１つ以上
の仮想マシンを各ユーザに提供することによって、単一の物理的計算機が多数のユーザ間
で共有されることを可能にてよく、それぞれのこのような仮想マシンは、独自の論理計算
システムとして動作するソフトウェアシミュレーションであり、自分が唯一の操作者であ
り、所与のハードウェアの計算リソースを管理しているという錯覚をユーザに提供する。
一方、様々な仮想マシンの間にアプリケーションの単独及び安全も提供し得る。さらに、
ある仮想化技術は、多数の異なる物理計算システムに及ぶ多数の仮想プロセッサを備える
単一の仮想マシンのような、２つまたはそれ以上の物理リソースに及ぶ仮想リソースを提
供することが可能である。計算プラットフォームに加えて、いくつかの大きな組織は、ま
た、仮想技術を使用して構築された、様々な種類のストレージサービスを提供している。
このようなストレージサービスを使用し、大量のデータが所望の耐久レベルで記憶され得
る。

様々なプロバイダから比較的低コストで仮想化した計算リソース及び／またはストレー
ジリソースを入手可能であるものの、しかしながら、大きく動的に変動するデータストリ
ームを収集、記憶及び処理の管理及びオーケストレーションは、様々な理由で難易度の高
い仕事である。より多くのリソースが大量のデータストリームを扱うために設定されたシ
ステムに追加されるにつれ、例えば、システムの異なる部分間のワークロードにおける不
均衡が生じ得る。この不均衡に対処がされないままの場合には、その他のリソースの利用
が不十分になることに加え（及び、そのため損失）、このような不均衡は、いくつかのリ
ソースで重大な性能障害に繋がり得る。このようなデータまたは結果がクライアントが制
御しない設備に格納される場合には、クライアントはまた、ストリーミングデータまたは
ストリーミングデータの分析結果の安全性に関して、懸念し得る。分散システムのサイズ
が大きくなるにつれて、時折起こる接続故障及び／またはハードウェア破損のような、頻
度の増加とともに自然に起こり得る破損は、費用のかかる破損からストリームデータの収
集、記憶または分析を守るために、効果的に対処されなければならない場合もある。

少なくともいくつかの実施形態による、データストリームの構想の簡略化した概略を提供する。 少なくともいくつかの実施形態による、ストリーム処理ステージの収集を含む、ストリーム管理システム（ＳＭＳ）及びストリーム処理システム（ＳＰＳ）の様々なサブコンポーネントの間のデータの流れの概略を提供する。 少なくともいくつかの実施形態による、ＳＭＳ及びＳＰＳで実装され得るプログラムによるインタフェースのそれぞれのセットの例を示す。 少なくともいくつかの実施形態による、ＳＰＳクライアントがストリーム処理ステージのグラフ生成を可能にするために実装され得るウェブベースのインタフェースの例を示す。 少なくともいくつかの実施形態による、ＳＭＳで実装され得る、プログラミングによるレコードのサブミッションインタフェース及びレコード検索インタフェースの例を示す。 少なくともいくつかの実施形態による、ＳＭＳの取り込みサブシステムの実施例の要素を示す。 少なくともいくつかの実施形態による、ＳＭＳのストレージサブシステムの実施例の要素を示す。 少なくともいくつかの実施形態による、ＳＭＳの検索サブシステム及びＳＰＳでの検索サブシステムの相互作用の実施例の要素を示す。 少なくともいくつかの実施形態による、ＳＭＳまたはＳＰＳのノード用に設定され得る冗長グループの実施例を示す。 少なくともいくつかの実施形態による、所与の冗長グループのノードが複数のデータセンタに分散され得る、プロバイダのネットワーク環境を示す。 少なくともいくつかの実施形態による、ＳＭＳまたはＳＰＳのノード用に選択され得る複数の宛先の実施例を示す。 少なくともいくつかの実施形態による、ＳＰＳクライアント及びＳＭＳクライアントのそれぞれによって送信され得る、セキュリティオプションの要求の実施例を示す。 少なくともいくつかの実施形態による、ストリームデータ生成部とＳＭＳの取り込みノードとの間の相互作用の実施例を示す。 少なくともいくつかの実施形態による、ＳＭＳで取り込まれたデータレコードのために生成され得る、シーケンス番号の実施例の要素を示す。 少なくともいくつかの実施形態による、ＳＭＳでストリームデータレコードが並べられたストレージ及び検索の実施例を示す。 少なくともいくつかの実施形態による、ＳＭＳノード及びＳＰＳノードのために作製され得るストリームパーティションマッピング及び対応する構成決定の実施例を示す。 少なくともいくつかの実施形態による、動的ストリームの再分割の実施例を示す。 少なくともいくつかの実施形態による、ストリームレコードの取り込み及びストリームレコードの検索用のプログラムによるインタフェースのそれぞれのセットを支援するために実行され得る、動作の態様を示すフローチャートである。 少なくともいくつかの実施形態による、ストリーム処理ステージを構成するよう実行され得る、動作の態様を示すフローチャートである。 少なくともいくつかの実施形態による、ストリーム処理ワーカノードの構成のための、クライアントのライブラリコンポーネントの呼び出しに対応して実行され得る動作の態様を示すフローチャートである。 少なくともいくつかの実施形態による、ストリーム処理のために１つ以上のリカバリポリシを実装するために実行され得る、動作の態様を示すフローチャートである。 少なくともいくつかの実施形態による、データストリーム用の複数のセキュリティオプションを実装するために実行され得る、動作の態様を示すフローチャートである。 少なくともいくつかの実施形態による、データストリームのためにポリシの分割を実装するために実行され得る、動作の態様を示すフローチャートである。 少なくともいくつかの実施形態による、データストリームの動的再分割を実装するために実行され得る、動作の態様を示すフローチャートである。 少なくともいくつかの実施形態による、データストリームレコード用の少なくとも１回のレコードの取り込みポリシを実装するために実行され得る、動作の態様を示すフローチャートである。 少なくともいくつかの実施形態による、データストリーム用の複数の永続性ポリシを実装するために実行され得る、動作の態様を示すフローチャートである。 少なくともいくつかの実施形態による、処理ステージのワーカノードがデータベーステーブルを使用してワークロードを調節するストリーム処理システムの例を示す。 少なくともいくつかの実施形態による、ワークロードの調節に使用されるパーティションの割り当てテーブルに記憶され得る入力の実施例を示す。 少なくともいくつかの実施形態による、処理動作を実行するパーティションを選択するために、ストリーム処理ステージのワーカノードによって実行され得る動作の態様を示す。 少なくともいくつかの実施形態による、ストリーム管理サービス制御サブシステムから取得された情報に基づいて、パーティション割り当てテーブルをアップデートするために、ストリーム処理ステージのワーカノードによって実行され得る動作の態様を示す。 少なくともいくつかの実施形態による、ストリーム処理ステージのワーカノードによって実行され得る負荷分散動作の態様を示す。 少なくともいくつかの実施形態で使用され得る計算装置の実施例を示すブロック図である。

実施形態は、いくつかの実施形態及び説明図用に一例として本明細書で記載されている
ものの、当業者は、実施形態は実施形態または図面に限定されないことを理解するであろ
う。図面及び詳細な説明は、開示された特定の形式の実施形態に限定することを意図せず
、反対に添付の特許請求の範囲により規定されるように趣旨及び範囲内にある全ての修正
、等価物及び代替物を網羅しようとするものであると理解すべきである。本明細書で使用
された見出しは、組織の目的のためのみであり、記述の範囲または特許請求の範囲を限定
するために使用されることを意図したものではない。本願の全体を通じて使用されるとき
、「してもよい」という語は、義務の意味（即ち必須を意味する）というよりはむしろ、
許可の意味で使用されている（即ち、あることを行う可能性を有することを意味する）。
同様に、「含む」、「含んでいる」は、含んでいることを意味するが、これらに限定され
ない。

何百または何千もの同時並行データ生成部及びデータコンシューマの取り扱いを目的と
した、大規模データストリームの作成、記憶、検索及び処理を管理するための方法及び装
置の様々な実施形態が記載されている。本発明で使用する場合、「データストリーム」と
いう用語は、１つ以上のデータ生成部によって生成し、１つ以上のデータコンシューマに
よってアクセスされ得るデータレコードのシーケンスを意味し、各データレコードは、不
変のバイト列であると仮定される。いくつかの実施形態では、ストリーム管理サービス（
ＳＭＳ）は、ストリームデータレコードの送信、記憶及び検索と同様に、ストリームの作
成、構成及び削除を可能にするために、プログラムによるインタフェース（例えば、アプ
リケーションプログラミングインタフェース（ＡＰＩ）、ウェブページ若しくはウェブサ
イト、グラフィカルユーザインターフェースまたはコマンドラインツール）を提供し得る
。ＳＭＳ制御コンポーネントとの相互作用を含む、（ストリーム作成若しくは削除、また
は下記に記載の動的再分割操作の種類のような）いくつかの種類のストリーム操作は、本
明細書では「制御プレーン」操作と呼ばれることもある。一方、典型的には、制御コンポ
ーネントとの相互作用を必要としない（例えば、通常の操作条件下で）データレコードの
送信、記憶及び検索のような操作は、本明細書では「データプレーン」操作と呼ばれるこ
ともある。ダイナミックプロビジョンされた計算、記憶及びネットワークリソースのセッ
トは、例えば、さらに詳細に後述のように、ストリーム管理ワークロードが数々のサービ
スコンポーネントの中でスケーラブルな方法で分散されることが可能な様々なパーティシ
ョンポリシに基づいて、このようないくつかの実施形態におけるサービスを実装するため
に使用され得る。頭字語のＳＭＳは、本明細書においてはストリーム管理サービスを意味
するために使用され得る。また、ストリーム管理サービスを実装するために使用される、
仮想及び／または物理リソースの収集を含む、ストリーム管理システムを意味するために
使用され得る。

ＳＭＳの何人かの顧客は、様々な実施形態で、ＳＭＳプログラムによるインタフェース
を直接起動するアプリケーションを開発し得る。少なくともいくつかの実施形態では、し
かしながら、ＳＭＳインタフェースに加えて、より高いレベルの抽象化またはアプリケー
ションレベルの処理フレームワークは、顧客に提供されてよく、ＳＭＳによって直接支援
される、より低いレベルのストリーム管理機能を使用するアプリケーションの開発を望ま
ない、これらのクライアントに対するストリーム処理の様々な態様を簡略化し得る。この
ようなフレームワークは、それ自身のプログラムによるインタフェース（例えば、ＳＭＳ
インタフェースの上部に設置）を提供してよく、より低いレベルのストリーム管理操作よ
りも顧客がストリームレコードを使用して実装されるビジネスロジックにより集中し得る
。より高いレベルのフレームワークは、いくつかの実施形態では、それ自身の制御プレー
ン及びデータプレーンコンポーネントを備えるストリーム処理サービス（ＳＰＳ）として
実装されてよく、ストリーム処理のための自動リソースプロビジョニング、処理ノードの
自動フェイルオーバ、任意のストリーム処理ワークフローグラフを構築する能力、一過性
のストリームの支援、ワークロードの変化またはその他のトリガ条件に基づいた動的再分
割等のような、高度な機能性を提供し得る。少なくともいくつかの実施形態では、ストリ
ーム管理サービス、ストリーム処理サービスの何れか、または両方のサービスは、仮想環
境においてマルチテナント管理ネットワークでアクセス可能なサービスであり得る。すな
わち、（コンピュータサーバまたはホスト、記憶装置、ネットワーク装置等のような）様
々な物理リソースは、少なくとも場合によっては、リソースがどのように共有されている
のか正確に顧客に必ずしも気付かせる必要がなく、あるいは所与のリソースが共有されて
いることを全く気付かせることさえなく、このような実施形態における異なる顧客のスト
リーム間で共有される。管理されたマルチテナントストリーム管理及び／または処理中の
管理サービスの制御コンポーネントは、動的に追加、削除し、または様々な適用可能なポ
リシに基づいた特定のストリームに使用されるノード若しくはリソースを再構成してよく
、それらのいくつかはクライアントが選択可能であり得る。加えて、制御コンポーネント
は、また、（例えば、少なくともいくつかのハードウェアまたはソフトウェアが双方のク
ライアントに共有される可能性があっても、１つのクライアントのストリームのアプリケ
ーションは別のクライアントのデータにアクセスすることができないことを確実にするた
めの）様々な種類のセキュリティプロトコルを、透過的に実装する役割をし、監査または
デバック等に使用され得る請求、ロギング情報の生成のためのリソース使用状況を監視す
る。管理されたマルチテナントサービス（単数または複数）のクライアントの見地から、
サービス（単数または複数）によって実装される制御／管理者機能は、大規模のストリー
ミングアプリケーションを支援することに伴う複雑さの大部分を解消し得る。いくつかの
場合では、このようなマルチテナントサービスの顧客は、少なくともいくつかの種類のス
トリーム関連の操作のためのリソースを共有したくない場合には、いくつかの物理リソー
スは、これらの種類の操作のためにシングルテナントのように少なくとも一時的に指定さ
れ得る（すなわち、単一の顧客またはクライアントに代わって実行される操作に限定する
）ことを表すことが可能であり得る。

様々な実施形態では、いくつかの異なる手法がＳＭＳ及び／またはＳＰＳ制御プレーン
及びデータプレーン操作を実装するためにとられ得る。例えば、制御プレーンの操作に関
しては、いくつかの実装では、制御サーバまたはノードの冗長グループが設定され得る。
冗長グループは複数の制御サーバを含んでよく、そのうちの１つのサーバは、様々なスト
リームに関して管理者の要求に応答する役割をするプライマリサーバとして示されている
。一方、別のサーバは、現在のプライマリでの破損（または接続不良）のようなトリガ条
件の場合、プライマリとして引き継ぐように示され得る。別の実装においては、ネットワ
ークにアクセス可能なデータベースサービスで作成された１つ以上のテーブルは、様々な
ストリームに（パーティションマップのような）制御プレーンメタデータを格納するため
に使用され得る。また、様々な取り込み、記憶ノードや検索ノードは、データプレーン操
作に必要なメタデータのサブセットの取得する必要に応じてテーブルにアクセス可能であ
り得る。異なる実施形態における、ＳＰＳ及びＳＭＳデータプレーン及び制御プレーンの
機能性の様々な態様に関する詳細は、下記に提供されている。ストリーム管理サービスが
実装される、いくつかの実施形態では、より高いレベルの基本要素を提供するストリーム
処理サービスは必ずしも実装されない可能性があることに注意する。その他の実施形態で
は、高いレベルのストリーム処理サービスのプログラムによるインタフェースのみが顧客
に公開され、使用されるより低レベルのストリーム管理インタフェースはクライアントに
は入手可能ではない。

いくつかの実施形態によると、ストリーム管理システムは、データレコードを取得また
は収集する役割を主にするレコード取り込みサブシステムと、適用可能な永続性または耐
久性ポリシによるデータレコードコンテンツを保存する役割を主にするレコード記憶サブ
システムと、及び格納されたレコードに向けられた読み出し要求に応答する役割を主にす
るレコード検索サブシステムと、を含む、複数の独立して構成可能なサブシステムを備え
得る。制御サブシステムは、また、いくつかの実施形態において実装され、例えば、動的
に判定することによって及び／または必要な数のノードを初期化することによって、サブ
システムを、仮想または物理サーバのような選択されたリソースで取り込み、記憶及び取
得するために、残りのサブシステムを構成する役割をする１つ以上の管理者または制御コ
ンポーネントを備え得る。取り込み、記憶、検索及び制御サブシステムのそれぞれは、全
体がサブシステムの「ノード」または「サーバ」と呼ばれ得る、複数のハードウェア及び
／またはソフトウェアコンポーネントのそれぞれを使用して実装され得る。このように、
ＳＭＳの様々なリソースが、取り込み、記憶、検索または制御という４つの機能カテゴリ
のうちの１つに論理的に属するとされ得る。いくつかの実装においては、制御コンポーネ
ントのそれぞれのセットは、その他のサブシステムのそれぞれに構築され得る。例えば、
独立取り込み制御サブシステム、記憶制御サブシステム及び／または検索制御サブシステ
ムが実装され得る。それぞれのこのような制御サブシステムは、対応するサブシステムの
その他のノードのために及び／またはクライアントまたはその他のサブシステムからの管
理クエリに応答するために、使用されるリソースを識別する役割をし得る。いくつかの実
装においては、様々な種類のＳＭＳ及び／またはＳＰＳの機能を可能にするノードプール
は、予め設定されてよく、これらのプールの選択されたメンバは、必要に応じて新しいス
トリームまたは新しい処理ステージに割り当てられ得る。

ストリームパーティションポリシ及び関連するマッピングは、例えば、取り込み、記憶
、検索及び／または制御ノードの異なるセットの間のデータレコードのサブセットに分散
するために、少なくともいくつかの実施形態においては、実装され得る。例えば、レコー
ド取り込み率及び／または検索率の予想のようなその他の要因と同様に、特定のデータス
トリームに選択されるパーティションポリシに基づいて、制御コンポーネントは、いくつ
のノード（例えばプロセスまたはスレッド）が取り込み、記憶及び検索のために最初に確
率されるか（すなわち、ストリーム作成時間）、及びこれらのノードがどのように仮想及
び／または物理マシンにマッピングされるべきかを判定し得る。時間の経過とともに、所
与のストリームに関連するワークロードは、増加または減少してよく、これは（その他の
トリガ条件のなかで）ストリームの再分割という結果をもたらし得る。このような再分割
は、レコードのパーティション、使用されるパーティションキー、パーティションのすべ
ての数、取り込みノードの数、記憶ノード若しくは検索ノード、または異なる物理リソー
ス若しくは仮想リソースへのノードの配置を判定するために使用される機能のような、様
々なパラメータへの変更を伴い得る。少なくともいくつかの実施形態では、さらに詳細に
書きに記載された技術を使用して、再分割はデータレコードの流れを中断することなく動
的に実装され得る。いくつかの実施形態では、異なるパーティションの手法及び再分割の
トリガ基準は、例えば、クライアントが提供するパラメータまたはＳＭＳ制御ノードの発
見に基づいて異なるデータストリームに使用され得る。いくつかの実施形態では、再分割
の数及び／または頻度を制限することが可能であり得る。例えば、クライアントの好み、
ストリームの予想耐用期間またはその他の要因である。

いくつかの異なるレコード取り込みポリシ及びインタフェースは、異なる実施形態にお
いて実装され得る。例えば、いくつかの実施形態では、クライアント（例えば、ＳＭＳの
顧客に代わってＳＭＳのプログラムによるインタフェースを起動するよう構成された実行
可能なコンポーネントまたはモジュール）は、インラインサブミッションインタフェース
またはバイリファレンスサブミッションインタフェースの何れにも利用し得る。その実施
形態において、インラインサブミッションには、データレコードのコンテンツまたは本文
がサブミッション要求の一部として含まれ得る。対照的に、バイリファレンスサブミッシ
ョン要求においては、アドレス（記憶装置アドレス、データベースレコードアドレスまた
はＵＲＬ（ユニフォームリソースロケータ））は、データレコードのコンテンツまたは本
文が取得され得るところから提供され得る。いくつかの実装においては、ハイブリッドサ
ブミッションインタフェースも、または代わりに支援され得る。データレコードの第１の
Ｎバイトはインラインに含まれ得る。それに対し、残りのバイト（可能ならば）は、参照
により提供される。このような場合には、短いレコード（その本文がＮバイトの長さ未満
である）はサブミッション要求によって十分に指定され得るが、一方、それよりも長いレ
コードの部分は対応するアドレスから入手し得る。

取り込み中のレコードコンテンツを指定するための異なる選択肢に加え、いくつかの実
施形態では、様々な応答または複製排除に関連する取り込みポリシもまた、実装され得る
。例えば、いくつかのストリームアプリケーションには、クライアントはそれぞれ及び全
てのデータレコードがＳＭＳによって確実に取り込まれることを確保したい場合がある。
大規模に分散されるストリーム管理環境においては、データ生成部と取り込みノードとの
間のパスに沿ってパケットは破損するか、様々な障害が時折起こり得、これはいくつかの
送信されたデータを潜在的に失う結果となり得る。したがって、いくつかの実施形態では
、レコード送信者は、同じレコードを、肯定応答が取り込みサブシステムから受信される
まで、１度以上送信し得ることにより、ＳＭＳは少なくとも１回の取り込みポリシを実装
し得る。通常の操作環境下では、レコードは一度送信されてよく、送信者は受信する取り
込みノードがレコードを取得し格納した後に応答を受信してよい。応答が損失されたか遅
延した場合、またはレコード送信要求自体が損失された場合には、送信者は、最終的に応
答が受信されるまで、同じデータレコードを１度以上再送信してよい。例えば、応答がす
でに送信者によって受信されていた場合、レコードは再送信されないという予想に基づい
て、取り込みノードは、送信が複製であるか否かにかかわらず、各送信に対し応答を生成
し得る。しかしながら、取り込みノードは、少なくともいくつかの実施形態では、同一の
データレコードは複数回送信されたことを認識し、複製のデータの新しいコピーを不必要
に記憶することを避ける役割をし得る。一実施形態では、少なくとも１回の取り込みポリ
シの少なくとも２つのバージョンは、（「少なくとも１回の取り込み、複製不可」と称さ
れ得る）、ＳＭＳがデータレコードを複製排除する役割をする（すなわち、２つまたはそ
れ以上の送信のセットの１つのみに対応して、データがＳＭＳ記憶サブシステムに格納さ
れることを確実にする）１つのバージョン、及び、（「少なくとも１回、複製可」と称さ
れ得る）ＳＭＳによってデータレコードストレージの複製が許可される１つのバージョン
を支援され得る。少なくとも１回の複製が許可された手法は、データレコードの複製の否
定的な結果が少数であるか、全く無いストリームアプリケーション、及び／またはそれ自
身の複製を排除を実行するストリームアプリケーションには有用であり得る。その他の取
り込みポリシもまた、応答が送信されたデータレコード毎に必要とされないベストエフォ
ートの取り込みポリシのように支援され得る。少数のデータレコードの損失は、ベストエ
フォートの取り込みポリシが少なくともいくつかの実施形態で有効である場合に受け入れ
可能であり得る。クライアントは様々な実施形態における様々なストリームに使用を希望
する取り込みポリシを選択し得る。

ストリームレコードの記憶に関しては、いくつかの代替的なポリシもまた、少なくとも
いくつかの実施形態で支援され得る。例えば、クライアントはＳＭＳによって支援される
いくつかのうちから永続性のポリシを選択可能であってよく、これは格納されるべき所与
のデータレコードのコピーの数として、このようなレコードの記憶の態様を管理し、記憶
技術の種類（例えば、揮発性または不揮発性ＲＡＭ、回転ディスクベースのストレージ、
固体装置（ＳＳＤ）、ネットワーク接続記憶装置等）がコピー等に使用され得る。例えば
、クライアントがディスクベースのストレージサーバへのＮ−レプリカ永続性ポリシを選
択する場合、データレコードの送信は、レコードのＮコピーがＮの各ディスク装置に安全
に書き込まれるまで完全であると考えられない可能性がある。ディスクベースの記憶装置
が使用される少なくともいくつかの実施形態では、ＳＭＳ記憶サブシステムは、例えばデ
ィスクシークのパフォーマンスインパクトを避けるために、順次、ディスクに対して所与
のパーティションの入ってくるデータレコードの書き込みを試み得る。シーケンス番号は
、例えば、取り込み時間に基づいて並べられたレコード検索を可能にするタイムスタンプ
に基づいた技術を含む、様々な下記の技術を使用してデータレコードに生成（かつ記憶）
され得る。少なくともいくつかの実施形態では、所与のパーティションのデータレコード
は、例えば、ディスクに連続的に、及びその他のパーティションのデータレコードから分
離して一緒に記憶され得る。いくつかの実装においては、（クライアント若しくはＳＭＳ
によって選択された）保持ポリシまたは（任意の所与のデータレコードの送信後の期間を
表示し、その間、いくつかの複製が送信されたとしてもＳＭＳは、複製のないその所与の
データレコードが、ＳＭＳ記憶サブシステムに格納されることを確保する必要があり得る
）複製排除時間窓ポリシによれば、少なくともいくつかのデータレコードは、異なる種類
のストレージサービスに移され得る及び／またはＳＭＳからある期間の後に削除され得る
。このような除去の操作は、本明細書においては、「トリミング」と称し得る。クライア
ントはいくつかの実施形態では、ストリームをトリミングする要求を送信し得る。例えば
、ＳＭＳに指定のデータレコードはもはや必要されておらず、そのためトリミング要求を
送信するクライアントの見地から、削除が可能であることを通知するか、または指定のデ
ータレコードの削除を明示的に要求する。多数のクライアントが所与のストリームのデー
タレコードを使用する可能性がある場合では、ＳＭＳは、すべての関係コンシューマによ
ってアクセスされる前に、所与のレコードが尚早に削除またはトリミングされないことを
確実にする役割があってよい。いくつかの実装においては、所与のストリームのＮデータ
コンシューマがある場合には、ストリームの所与のレコードＲを削除する前に、ＳＭＳは
すべてのＮデータコンシューマがＲを読み出しまたは尚早に処理したことを判定するまで
待機し得る。例えば、コンシューマからの各トリミング要求に基づいて、または、ストリ
ーム内でデータコンシューマがどのくらい進んでいるかというそれぞれの表示に基づいて
、Ｒはすべてのコンシューマによって読み込まれたと、ＳＭＳは判定し得る。いくつかの
実施形態では、データコンシューマの（テストに関連するアプリケーションのような）い
くつかの種類は、アクセスされる前に、少なくとも一部の部分のデータレコードの削除を
受け入れ得る。したがって、アプリケーションは、少なくともいくつかの実施形態におい
ては、検索前にデータ削除の受容性に関してＳＭＳに通知可能であってよく、及びＳＭＳ
はその通知によって削除を予定し得る。いくつかの実施形態では、例えば、データ保持ポ
リシの一部として、保存用のポリシが実装されてよく、例えば、ストリームデータレコー
ドがコピーされるべき記憶装置の種類を表示し、ポリシがこのようなコピーへの使用とを
予定する。

少なくともいくつかの実施形態においては、複数のプログラムによるインタフェースも
また、レコード検索のために支援され得る。一実施形態では、イテレータベースの手法が
使用されてよく、一プログラムによるインタフェース（例えば、ｇｅｔＩｔｅｒａｔｏｒ
）はインスタンス化し、イテレータまたはカーソルを指定の理論オフセットに配置するた
めに、ストリームのパーティション内で（例えば、シーケンス番号またはタイムスタンプ
に基づいて）使用され得る。次に（ｇｅｔＮｅｘｔＲｅｃｏｒｄのような）異なるプログ
ラムによるインタフェースは、イテレータの現在位置から順次開始する指定の数のデータ
レコードを読み込むために使用され得る。イテレータのインスタンス化は、要するに、ク
ライアントが恣意的または無作為の開始位置を、ストリームパーティション内でレコード
検索するために特定することを可能にし得る。クライアントがこのような実施形態で無作
為なアクセスパターンでデータレコードの読み出しを希望する場合には、クライアントは
繰り返し新しいイテレータを生成しなくてはならない場合がある。回転ディスクベースの
記憶システムにおいては、頻繁なランダムアクセスに必要とされるディスクシークは、Ｉ
／Ｏ応答回数に著しく影響を与える場合がある。したがって、ストリームデータレコード
を無作為に読み込むよりも順次に読み込むことをクライアントに促すために、少なくとも
いくつかの実施形態では、異なる（例えば高い）課金率が、シーケンシャルリードアクセ
スに適用されるよりも、ランダムリードアクセスに適用され得る。したがって、いくつか
の実装においてはＸ＞Ｙの状態で、例えば、クライアントはｇｅｔＩｔｅｒａｔｏｒ通話
毎にＸ通貨単位で、及び、レコード検索毎にｇｅｔＮｅｘｔＲｅｃｏｒｄを介しＹ通貨単
位請求され得る。代替的なクライアントインタフェースが、（取り込みのような）その他
の操作カテゴリに支援される場合、少なくともいくつかの実施形態では、課金率または代
替物の価格もまた、異なり得る。クライアントがシーケンシャルリードよりもランダムリ
ードにより課金され得るのと同様に、例えば、クライアントは、オンラインの送信要求よ
りもバイリファレンスの送信要求により課金され得る。データレコードのサイズ、時間の
経過とともに書き込み対読み出し要求の分散、選択された永続性ポリシ等のような、その
他の要因もまた様々な実施形態において課金に影響し得る。

いくつかの実施形態によると、ストリーム処理サービス（ＳＰＳ）は、クライアントが
、多数の処理ステージを含む複雑な処理ワークフローを適宜、特定することを可能にし、
所与のステージで実行される処理の出力が、ゼロまたはそれ以上のその他のステージ用に
入力として使用され得る。パーティションポリシ（データレコードの取り込み、格納及び
検索のためのＳＭＳに記載されるものに類似）は、いくつかの実施形態における様々なス
テージで複数のワーカノードのうち処理中のワークロードを分割するために使用され得る
。このような一実施形態では、プログラムによるＳＰＳインタフェースは、クライアント
が任意の所与のステージのために様々な構成設定を特定可能なように実装されてよく、例
えば、ステージのために入力データソース（単数または複数）（例えば、ストリーム用の
パーティションポリシと一緒に、データレコードが検索される１つ以上のストリーム）、
ステージで実行される処理操作、及びステージからの出力または結果の分散のためディス
クリプタまたは指定（例えば、出力が記憶位置に保存され、ネットワークの終点に送信さ
れ、または異なるストリームの形式で１つ以上のその他のステージに入力されるか否かを
問わず）を含む。少なくともいくつかの実施形態では、ＳＰＳステージのために指定され
る処理操作は冪等であり得る。すなわち、所与の処理操作が同じ入力データで複数回実行
される場合、操作の結果は、操作が１回のみ実行された場合に得られたであろう結果とは
異ならない。さらに詳細に後述のように、破損からのリカバリ（例えば、ＳＰＳステージ
でのワーカノードの損失）は、処理操作が冪等の場合、簡略化され得る。いくつかの実施
形態によると、非冪等の処理操作はいくつかのまたはすべてのＳＰＳステージで許可され
得る。

入力ストリームパーティションポリシ及び次にＳＰＳプログラムによるインタフェース
を介して受信される処理操作の性質のような構成情報に少なくとも部分的に基づいて、様
々な実施形態では、処理ワークフローの様々なステージのために、どのくらいの数のワー
カノードが最初に設定されるべきかをＳＰＳ制御サーバは判定し得る。ワーカノードに使
用されるリソースの遂行能力（例えば、使用される仮想マシンまたは物理マシン）もまた
、初期番号及びワーカノードの配置を決定する際に、考慮され得る。選択されたワーカノ
ードの番号は、インスタンス化され得る（いくつかの実装では、実行可能なスレッドまた
は実行可能なプロセスをそれぞれ備える）。各ワーカノードは、例えば、適切な入力ソー
スからデータレコードを（例えば、１つ以上のストリームパーティションの検索ノードか
ら）取得し、データレコードで指定された処理操作を実行し、及び指定された宛先（単数
または複数）に処理の結果を伝送するよう構成され得る。加えて、少なくともいくつかの
実施形態では、パーティションレコードが連続して処理される仮定で、所与のワーカノー
ドは、そのワーカノードで処理されてきたプログレスレコードまたはパーティションの一
部を示すチェックポイントを格納するよう構成され得るにしたがい、チェックポイントの
スキームが実装され得る。いくつかの実装において、例えば、ワーカノードは、プログレ
スレコードを永続性ストレージに定期的（例えば、Ｎ秒毎に１度、またはＲデータレコー
ドに１度が処理されている）に及び／またはＳＰＳ制御サーバからチェックポイントの要
求に対応して、書き込みしてよい。

いくつかの実施形態では、プログレスレコードはワーカノードの破損から迅速にリカバ
リするために使用され得る。例えば、ＳＰＳ制御サーバは、（ＣＰＵ利用、Ｉ／Ｏ装置利
用またはネットワーク利用レベルのような）例えば、ハートビート機構の使用及び／また
はリソース利用レベルの監視により、様々なワーカノードの健康状態を時間の経過ととも
に監視し得る。特定のワーカノードが好ましくないまたは健康ではない状態にあるとのＳ
ＰＳ制御サーバによる判定に対応して（例えば、応答しないかオーバーロードの場合）、
交換されたワーカノードは特定のワーカノードの役割を引き継ぐためにインスタンス化さ
れ得る。交換されたワーカノードは、交換されたワーカノードによって格納された最新の
プログレスレコードにアクセスして、交換されたワーカノードが処理すべきデータレコー
ドのセットを識別し得る。処理操作が冪等である実施形態では、いくつかの操作が繰り返
されていても（例えば、最新のプログレスレコードが交換されたワーカのインスタンス化
以前のある時に書き込まれたため）、処理全体の結果は破損及び交換の影響を受けないで
あろう。いくつかの実装においては、所与のストリームのサブセットまたはこのサブセッ
トによって処理されたパーティションを表すプログレスレコードを格納することに加えて
、ワーカノードもまた、蓄積されたアプリケーション状態の情報を格納するよう構成され
得る。例えば、ストリーム処理ワークフローは、サービス使用メトリクスを表すストリー
ミングデータレコードの分析に基づいて特定のサービスのためクライアント課金額を決定
する役割をする場合には、ワーカノードは、様々なクライアントに決定された累積の課金
額を定期的に格納し得る。

少なくともいくつかの実施形態では、ＳＰＳ制御サーバは、また、様々なステージのた
めの入力ストリームの動的再分割の要求のようなその他の動作を開始し、所与のステージ
で所与のパーティションに割り当てられたワーカノードの数の変更し、いくつかのステー
ジにより高い性能のワーカノードの割り当てし、または異なる性能能力で１つの物理リソ
ースから別の物理リソースへワーカノードの伝達することによって、ワークロードレベル
若しくは検出されたワークロードの不均衡（例えば、１つのパーティションに対する取り
込みレートがその他のものよりも不均衡に高くなっている場合）の変更のような、様々な
その他のトリガに、応答するよう構成され得る。いくつかの実施形態では、例えば、ベス
トエフォートリカバリポリシは、チェックポイントベースのリカバリポリシよりもむしろ
、所与のステージのために実装されるＳＰＳ制御サーバによる判定に対応して、上記に記
載した種類のプログレスレコードは、少なくともいくつかのＳＰＳステージのワーカノー
ドによって格納されない場合がある。このようなベストエフォートリカバリポリシのいく
つかの実装においては、交換されたワーカノードは、プログレスレコードにアクセスする
必要なく、受信された際に新しいデータレコードを単純に処理し得る。いくつかの実施形
態では、クライアントがＳＰＳステージでベストエフォートリカバリポリシの実装を希望
する場合には、ステージで実行されるストリーム処理操作は必ずしも冪等である必要はな
い。非冪等の処理操作がＳＰＳステージでストリームレコード上で実行されるいくつかの
実施形態では、チェックポイントベースのリカバリは支援されなくてよく、ベストエフォ
ートリカバリのような異なるリカバリスキームが使用され得る。少なくとも一実施形態に
おいては、冪等ストリーム処理操作のみがＳＰＳステージ許容され得る。

いくつかのストリームのデータレコードは、秘密または機密情報を含み、またはＳＰＳ
ステージで実行される処理操作は、競合相手による発見は問題となり得る著作権のあるア
ルゴリズムの使用を含み得る。そのため、クライアントは様々なカテゴリのストリーム管
理及び処理操作のセキュリティについて、特に操作が、クライアント自身によって完全に
制御されないプロバイダネットワークデータセンタに配置されるリソースを使用して実行
される場合、関心があり得る。インターネット及び／またはその他のネットワークを介し
て分散されたクライアントのセットにアクセス可能な（様々な種類のクラウドベースのデ
ータベース、電算処理またはストレージサービスのような）１つ以上のネットワークにア
クセス可能なサービスを提供する会社または公的部門の組織のようなエンティティによっ
て設定されるネットワークは、本明細書ではプロバイダネットワークと称され得る。いく
つかの実施形態では、クライアントはデータストリームのために、複数のセキュリティに
関連する選択肢のうちから選択可能であり得る。上記のように、組み合わされたＳＰＳ及
びＳＭＳの構成は、ＳＭＳ及び／またはＳＰＳ用の制御ノード、ＳＭＳ取り込みノード、
ＳＭＳ記憶ノード、ＳＭＳ検索ノード及びＳＰＳ処理若しくはワーカノードのような、異
なる機能のカテゴリのいくつかに属するノードを備え得る。いくつかの実施形態では、ク
ライアントが入手可能であるセキュリティに関連する選択肢は、様々な種類のノードの位
置または配置のため選択肢を含み得る。例えば、一実施形態では、クライアントは、たと
えストリームレコードが当初、プロバイダネットワークに配置されるリソースを使用して
収集及び／または格納されても、ストリームワークフローの１つ以上の処理ステージのた
めのＳＰＳワーカノードは、クライアント所有の設備に配置された計算装置に実装される
ことを要求することが可能であり得る。このような配置要求に対応して、所与のストリー
ムのための異なる機能カテゴリのノードは、異なるセキュリティ特性またはプロフィール
とセットで各リソースでインスタンス化され得る。

リソースセットは、異なる実施形態において、例えば、物理位置、使用される物理セキ
ュリティプロトコル（例えば、リソースへの物理アクセルを有するもの）、ネットワーク
隔離レベル（例えば、リソースのネットワークアドレスが様々なエンティティに可視であ
る範囲）、マルチテナント対シングルテナント等を含む、様々なセキュリティに関連する
特性が互いに異なり得る。いくつかの実施形態では、クライアントのＩＶＮ内に含まれた
様々な装置のネットワーク構成を実質的に制御する所与のクライアントとともに、クライ
アントは、プロバイダネットワーク内に隔離された仮想ネットワーク（ＩＶＮ）を確率し
得る。特に、クライアントは、様々なサーバまたはＩＶＮ内のコンピュートインスタンス
に割り当てられたネットワークアドレス（例えば、インターネットプロトコルまたはＩＰ
アドレス）にアクセスすることを制限し得る。このような実施形態においては、クライア
ントはＳＭＳノードまたはＳＰＳノードの一定のサブセットが特定のＩＶＮ内でインスタ
ンス化されることを要求し得る。仮想インスタンスホスト（典型的にはマルチテナントホ
ストとして構成され得る）のようなプロバイダネットワークリソースが、ＳＭＳノードま
たはＳＰＳノードの様々なカテゴリに使用される実施形態では、クライアントは、いくつ
かのセットのノードは、クライアントのみに属するインスタンスの実装を制限されるイン
スタンスホスト上でインスタンス化されることを要求し得る（すなわち、いくつかのＳＭ
ＳノードまたはＳＰＳノードはシングルテナントホストとして構成されたインスタンスホ
ストに実装され得る）。

いくつかの実施形態では、別のセキュリティ関連の選択肢としては、クライアントは、
特定のストリームのデータレコードは、例えば、ＳＭＳに取り込まれる前に、取り込みと
記憶サブシステムとの間、記憶サブシステムと検索サブシステムとの間、検索サブシステ
ムとＳＰＳワーカノードとの間、及び／またはワーカノードとＳＰＳ出力宛先との間のネ
ットワークリンクから伝送される前に暗号化されることを要求し得る。クライアントはい
くつかの実施形態にて使用される暗号化アルゴリズムを特定し得る。一実施形態では、Ｔ
ＬＳ（トランスポート層セキュリティ）またはＳＳＬ（セキュアソケット層）プロトコル
のようなセキュアなネットワークプロトコルは、データレコードの伝送及び／またはＳＰ
Ｓ処理結果の伝送に使用され得る。

データストリームのコンセプト及び概略
図１は、少なくともいくつかの実施形態による、データストリームの構想の簡略化した
概略を提供する。ここに示すように、ストリーム１００は、ＤＲ１１０Ａ、１１０Ｂ、１
１０Ｃ、１１０Ｄ及び１１０Ｅのような複数のデータレコード（ＤＲ）１１０を備え得る
。データ生成部１２０Ａ及びデータ生成部１２０Ｂのような１つ以上のデータ生成部１２
０（データソースとも称され得る）ストリーム１００のデータレコードの内容を生成する
ために書き込み操作１５１を実行し得る。いくつかの異なる種類のデータ生成部は、例え
ば、携帯電話あるいはタブレットアプリケーション、センサアレイ、ソーシャルメディア
プラットフォーム、ロギングアプリケーションあるいはシステムロギングコンポーネント
、種々のモニタリングエージェント等のような、異なる実施形態においてデータのストリ
ームを生成し得る。（データコンシューマ１３０Ａ及びデータコンシューマ１３０Ｂのよ
うな）１つ以上のデータコンシューマ１３０は、データ生成部１２０によって生成された
データレコードの内容にアクセスするために読み出し操作１５２を実行し得る。いくつか
の実施形態では、データコンシューマ１３０は、例えば、ストリーム処理ステージのワー
カノードを備え得る。

少なくともいくつかの実施形態では、ＳＭＳに記憶される際の所与のデータレコード１
１０はデータ部分１０１（例えば、それぞれＤＲ１１０Ａ，１１０Ｂ，１１０Ｃ，１１０
Ｄ及び１１０Ｅのデータ部分１０１Ａ、１０１Ｂ、１０１Ｃ、１０１Ｄ及び１０１Ｅ）及
びシーケンス番号ＳＮ１０２（例えば、それぞれＤＲ１１０Ａ，１１０Ｂ，１１０Ｃ，１
１０Ｄ及び１１０ＥのＳＮ１０２Ａ、１０２Ｂ、１０２Ｃ、１０２Ｄ及び１０２Ｅ）を備
え得る。シーケンス番号１０２は記載された実施形態において、ＤＲはストリーム管理シ
ステム（またはストリーム管理システムの特定のノード）で受信された順序であることを
示し得る。データ部分１０１はいくつかの実装においては、変更不能な解釈されないバイ
ト列を含み得る。すなわち、書き込み操作１５２が完了すると、書き込みの結果として生
じたＤＲの内容は、ＳＭＳによって変更されなくてよく、一般にＳＭＳはデータの意味を
認識しなくてよい。いくつかの実装においては、所与のストリーム１００の異なるデータ
レコードは、異なる量のデータを含み、それに対しその他の実施形態では、所与のストリ
ームの全てのデータレコードは同じサイズであり得る。少なくともいくつかの実装におい
ては、ＳＭＳのノード（例えば、取り込みサブシステムノード及び／または記憶サブシス
テム）は、ＳＮ１０２を生成する役割をし得る。さらに詳細に後述のように、データレコ
ードのシーケンス番号は、必ずしも連続とは限らない。一実装においては、クライアント
またはデータ生成部１２０は、書き込み要求の一部として、対応するデータレコードに使
用される最小のシーケンス番号の表示を提供し得る。いくつかの実施形態では、データ生
成部１２０は、データレコードのデータの一部（またはアドレス）にポインタを含む書き
込み要求を、例えば、（装置名及び装置内のオフセットのような）記憶装置のアドレスま
たはデータ部分が取得され得る（ＵＲＬのような）ネットワークアドレスを提供すること
によって送信し得る。

様々な実施形態では、ストリーム管理サービスは、データ生成部１２０からデータを受
信し、データを格納し、及びデータコンシューマ１３０を１つ以上のアクセスパターンに
おいてデータをアクセス可能にする役割をし得る。少なくともいくつかの実施形態では、
ストリーム１００は、データレコードを受信し、格納し、及び検索するワークロードを分
散するためにパーティション化または「分割」され得る。このような実施形態においては
、パーティションまたは分割は、データレコードの１つ以上の属性に基づいて入ってくる
データレコード１１０のために選択され、及びデータレコードを取り込みし、格納しまた
は検索する特定のノードは、パーティションに基づいて識別され得る。いくつかの実装に
おいては、データ生成部１２０は、パーティションの属性として機能し得る各書き込み操
作を明示的なパーティションキーに提供し、及びこのようなキーはパーティション識別子
にマッピングされ得る。その他の実施形態においては、ＳＭＳは、データ生成部１２０の
識別、データ生成部のＩＰアドレスの要因に基づいて、または送信されたデータの内容に
基づいて、パーティションＩＤを推測し得る。データストリームがパーティション化され
るいくつかの実装においては、シーケンス番号はパーティション毎に割り当てられ得る。
例えば、シーケンス番号は、特定のパーティションのデータレコードが受信される順序を
示すが、２つの異なるパーティションにおけるデータレコードＤＲ１及びＤＲ２のシーケ
ンス番号は、ＤＲ１及びＤＲ２が受信された関連する順序を必ずしも示さない可能性があ
る。その他の実装においては、データレコードＤＲ１に割り当てられたシーケンス番号Ｓ
Ｎ１がデータレコードＤＲ２に割り当てられたシーケンス番号ＳＮ２よりも低い場合には
、ＤＲ１及びＤＲ２がどちらのパーティションに属するかに関わらず、これは、ＤＲ１は
ＳＭＳによってＤＲ２よりも前に受信されたことを示すように、シーケンス番号はパーテ
ィション毎のベースよりもむしろストリーム幅に割り当てられ得る。

様々な実施形態では、ＳＭＳによって支援される検索または読み出しインタフェースは
、データコンシューマ１３０がデータレコードに連続して及び／または無作為の順番でア
クセスするのを可能にし得る。一実施形態では、イテレータベースの読み出しアプリケー
ションプログラミングインタフェース（ＡＰＩ）のセットは支援され得る。データコンシ
ューマ１３０は、特定のシーケンス番号及び／またはパーティション識別子によって表さ
れたイテレータの初期の位置とともに、データストリームのためにイテレータを取得する
よう要求を送信し得る。イニシエータがインスタンス化された後、データコンシューマは
、ストリーム内またはパーティション内の初期位置から始まるシーケンスの順序で、デー
タレコードを読み込むために要求を送信し得る。データコンシューマが何らかの無作為の
順序でデータレコードを読み込みたい場合には、このような実施形態では、新しいイテレ
ータは各読み出しのためにインスタンス化しなければならない場合がある。少なくともい
くつかの実装においては、所与のパーティションまたはストリームのデータレコードは、
典型的にはディスクシークを避ける連続的な書き込み操作を使用して、シーケンス番号順
でディスクベースのストレージに書き込まれ得る。シーケンシャル読み出し操作はまた、
ディスクシークのオーバーヘッドを避け得る。したがって、いくつかの実施形態では、デ
ータコンシューマは無作為の読み出しよりもシーケンシャルな読み出しを実行することを
価格で動機付けして奨励され得る。例えば、イテレータのインスタンス化のような、ラン
ダムアクセス読み出し操作はシーケンシャルにアクセスする読み出し操作よりも高い関連
する課金率を有し得る。

システム環境の例
図２は、少なくともいくつかの実施形態による、ストリーム処理ステージの収集を含む
、ストリーム管理システム（ＳＭＳ）及びストリーム処理システム（ＳＰＳ）の様々なサ
ブコンポーネントの間のデータの流れの概略を提供する。ここに示すように、ＳＭＳ２８
０は取り込みサブシステム２０４、記憶サブシステム２０６，検索サブシステム２０８及
びＳＭＳ制御サブシステム２１０を備え得る。後述のように、ＳＭＳサブシステムのそれ
ぞれは、１つ以上のノードまたはコンポーネントを含んでよく、例えば、対応する実行可
能なスレッドまたはプロバイダネットワーク（またはクライアント所有設備か第三者の設
備）の様々なリソースでインスタンス化されるプロセスを使用して実装される。取り込み
サブシステム２０４のノードは、ストリームに使用されるパーティションポリシに基づい
て、（１２０Ａ、１２０Ｂ、及び１２０Ｃのような）データ生成部１２０から特定のデー
タストリームのデータレコードを取得するよう、（例えば、ＳＭＳ制御サブシステム２１
０のノードによって）構成され、各取り込みノードは、記憶サブシステム２０６の対応す
るノードに受信されたデータレコードを渡し得る。記憶サブシステムのノードは、ストリ
ームのために選択された永続性ポリシにより、様々な種類の記憶装置の何れかに、データ
レコードを保存し得る。検索サブシステム２０８のノードは、ＳＰＳ２９０のワーカノー
ドのようなデータコンシューマからの読み出し要求に応答し得る。ＳＰＳ２９０のステー
ジ２１５Ａ、ステージ２１５Ｂ、ステージ１２１５Ｃ及びステージ２１５Ｄのようなスト
リーム処理ステージ２１５は、ＳＰＳ制御サブシステム２２０の助けによって確立され得
る。各ステージ２１５は、受信されたデータレコードで処理操作のセットを実行するＳＰ
Ｓ制御サブシステム２２０によって構成された１つ以上のワーカノードを含み得る。ここ
に示すように、（２１５Ａ及び２１５Ｂのような）いくつかのステージ２１５は、ＳＭＳ
２８０から直接データレコードを取得し得る。一方、（２１５Ｃ及び２１５Ｄのような）
その他は、その他のステージから入力を受信し得る。多数のＳＰＳステージ２１５は、い
くつかの実施形態においては並行して操作し得る。例えば、異なる処理操作は、ステージ
２１５Ａ及びステージ２１５Ｂで同じストリームから検索されたデータレコード上で同時
に実行され得る。特定のストリーム用の、図２に示されたものと類似する、それぞれのサ
ブシステム及び処理ステージは、また、その他のストリームもインスタンス化され得るこ
とに注意する。

少なくともいくつかの実施形態においては、図２に示されているサブシステム及び処理
ステージのノードのうち少なくともいくつかは、プロバイダネットワークリソースを使用
して実装され得る。前述したように、インターネット及び／またはその他のネットワーク
を介して分散されたクライアントのセットにアクセス可能な（様々な種類のクラウドベー
スのデータベース、電算処理またはストレージサービスのような）１つ以上のネットワー
クにアクセス可能なサービスを提供する会社または公的部門の組織のようなエンティティ
によって設定されるネットワークは、本明細書ではプロバイダネットワークと称され得る
。サービスのいくつかは、より高いレベルのサービスを構築するために使用され得る。例
えば、算出、記憶またはデータベースサービスは、ストリーム管理サービスまたはストリ
ーム処理サービスのためのビルディングブロックとして使用され得る。プロバイダネット
ワークの少なくともいくつかのコアサービスは、「インスタンス」と呼ばれるサービスユ
ニットにおいてクライアントが使用するためにパッケージ化され得る。例えば、仮想計算
サービスによってインスタンス化される仮想マシンは、「コンピュートインスタンス」を
表し、及びストレージサービスによってインスタンス化されるブロックレベルのボリュー
ムのような記憶装置は、「ストレージインスタンス」と呼ばれることもあり、またはデー
タベース管理サーバは「データベースインスタンス」と呼ばれることもある。プロバイダ
ネットワークの様々なネットワークにアクセス可能なサービスの装置が実装される、サー
バのような計算装置は、本明細書では、「インスタンスホスト」またはより簡単に「ホス
ト」と呼ばれ得る。いくつかの実施形態では、取り込みサブシステム２０４のノード、記
憶サブシステム２０６、検索サブシステム２０８、ＳＭＳ制御システム２１０、処理ステ
ージ２１５及び／またはＳＰＳ制御サブシステム２２０は、複数のインスタンスホスト上
の様々なコンピュートインスタンスで実行するスレッドまたはプロセスを備え得る。及び
／またはＳＰＳ制御サブシステム２２０は、複数のインスタンスホスト上の様々なコンピ
ュートインスタンスで実行するスレッドまたはプロセスを備え得る。所与のインスタンス
ホストはいくつかのコンピュートインスタンス及び特定のインスタンスホストでコンピュ
ートインスタンスでの収集は、１つ以上のクライアントの様々な異なるストリームのため
にノードを実行するために使用され得る。ストレージインスタンスは、いくつかの実施形
態では、様々なストリームのデータレコードを記憶するために使用されるか、ストリーム
処理ステージの結果の宛先であり得る。図１５及び図１６を参照すると、以下に記載され
るように、データレコードを依然、受信、記憶及び処理し続ける間、時間の経過とともに
、例えば、ノードを追加または削除、ノードのマッピングをコンピュートインスタンスま
たはインスタンスホストに変更または所与のストリームを再分割することによって、制御
サブシステムは、様々なトリガ条件に対応してその他のサブシステムの人口を動的に修正
し得る。

プロバイダネットワークリソースがストリームに関連した操作に使用される実施形態と
の関係においては、「クライアント」という用語は、所与の通信のソースまたは宛先とし
て使用される場合、（多数のユーザまたは単一のユーザを有する組織、グループのような
）エンティティに所有され、管理されまたは割り当てられる、計算装置、プロセス、ハー
ドウェアモジュールまたはソフトウェアモジュールのいずれかを意味し得る。プロバイダ
ネットワークの少なくとも１つのネットワークにアクセス可能なサービスにアクセスし、
利用することが可能なあるサービスのクライアントは、別のサービスのリソースを使用し
て自身が実装され得る。例えば、ストリームデータコンシューマ（ストリーム管理サービ
スのクライアント）は、コンピュートインスタンス（仮想化された計算サービスによって
提供されたり）を備え得る。

所与のプロバイダネットワークは、物理的及び／若しくは仮想化されたコンピュータサ
ーバの収集、それぞれに１つ以上の記憶装置を備えるストレージサーバ及びネットワーク
機器等のような、様々なリソースツールをホストする（異なる地理的領域にわたって分散
され得る）多数のデータセンタを含んでよく、プロバイダによって提供されるインフラス
トラクチャ及びサービスを実装、構成及び分散する必要がある。いくつかの異なるハード
ウェア及び／またはソフトウェアコンポーネントは、そのいくつかはインスタンス化され
るか、異なるデータセンタまたは異なる地理的領域で実行され得るが、様々な実施形態に
おけるサービスのそれぞれを実装するために一括して使用され得る。クライアントは、プ
ロバイダネットワークの外部にあるクライアント所有またはクライアント管理の構内若し
くはデータセンタに位置される装置及び／またはプロバイダネットワーク内装置から、プ
ロバイダネットワークでリソース及びサービスと相互作用し得る。プロバイダネットワー
クは、本明細書で記載される多くのストリーム管理技術及びストリーム処理技術が実装さ
れる一例のコンテキストとしての役割をするが、これらの技術は、プロバイダネットワー
クよりもその他の種類の分散システムに、例えば、アプリケーションの単一ビジネスエン
ティティによって操作される大規模な分散環境に、適用され得ることに留意する。

プログラムによるインタフェースの例
上記のように、少なくともいくつかの実施形態では、ＳＰＳは、様々なストリームベー
スのアプリケーションに、所望のビジネスロジックを実装するために、ＳＰＳクライアン
トによってより容易に使用されることが可能な、より高いレベルの機能を構築するように
、ＳＭＳプログラムによるインタフェースを利用し得る。ＳＰＳとＳＭＳの機能の違いを
考えると、類似性が有用である。ＳＰＳの機能は、一般に、Ｃ＋＋のような、より高いレ
ベルの言語におけるプログラミング言語の構築と比較され得る。それに対してＳＭＳの機
能は一般に、プログラミング言語構築はコンパイラによって変換されるアセンブリ言語命
令と比較され得る。アセンブリ言語命令を直接使用して同一の操作を実行することは可能
であり得るが、より高いレベルの言語におけるプログラミングは、一般に、顧客またはユ
ーザの多くのカテゴリにはより容易である。同様に、ＳＭＳによって供給された基本要素
を使用して、様々なアプリケーションを実行することは可能であり得るが、ＳＰＳ特徴を
使用して行うことはより容易であり得る。ＳＰＳ処理操作（データレコードで実行される
冪等の処理操作のような）は、ストリームレコードのデータコンテンツ上で実行され得る
。一方、ＳＭＳ操作は、レコードのコンテンツを通常考慮せずに、ＳＭＳ操作の取得、記
憶及び検索を実行する。図３は、少なくともいくつかの実施形態による、ＳＭＳ及びＳＰ
Ｓで実装され得るプログラムによるインタフェースのそれぞれのセットの例を示す。いく
つかの異なるアプリケーションプログラミングインタフェース（ＡＰＩ）は、ＳＭＳ及び
ＳＰＳの両方を例として指示する。示されているＡＰＩは、任意の所与の実装で支援され
る網羅的なリストであることを目的としていない。示されているＡＰＩのいくつかは、所
与の実装で支援されなくてよい。

矢印３５０で示されているように、ＳＰＳクライアント３７５は、ＳＰＳプログラムに
よるインタフェース３０５を起動して処理ステージを構成し得る。様々な種類のＳＰＳプ
ログラムによるインタフェース３０５は、異なる実施形態において実装され得る。例えば
、ｃｒｅａｔｅＳｔｒｅａｍＰｒｏｃｅｓｓｉｎｇＳｔａｇｅＡＰＩは、クライアントが
特定の入力ストリームのために新しい処理ステージ２１５の構成を要求を可能にし得る。
ステージのワーカノードは、インタフェースの起動で特定される、一連の冪等操作を実行
し、出力分散ディスクリプタまたはポリシによって表示された宛先に、結果を分散するよ
う、それぞれ構成される。ｃｒｅａｔｅＳｔｒｅａｍＰｒｏｃｅｓｓｉｎｇＳｔａｇｅ
ＡＰＩまたはその等価物のいくつかのバージョンにおいては、クライアントは入力ストリ
ームも同様に作成を要求し得る。一方、その他のバージョンでは、入力ストリームは、処
理ステージが作成される前に作成されなければならない可能性がある。リカバリポリシは
ワーカノードに指定されてよく、例えば、チェックポイントベースのリカバリ技術が使用
されるべきか否か、またはベストエフォートのリカバリ技術が好ましいか否かを示す。い
くつかの実施形態では、ｉｎｉｔｉａｌｉｚｅＷｏｒｋｅｒＮｏｄｅ ＡＰＩは特定のス
テージでワーカノードの明示的なインスタンス化を要求するために支援され得る。チェッ
クポイントベースのリカバリが実装される実施形態では、ｓａｖｅＣｈｅｃｋｐｏｉｎｔ
ＡＰＩが、プログレスレコードがワーカノードによって生成されるようクライアントが
要求することが可能になるよう支援され得る。

様々な種類のＳＰＳ出力管理ＡＰＩは、ｓｅｔＯｕｔｐｕｔＤｉｓｔｒｉｂｕｔｉｏｎ
ＡＰＩのような、異なる実施形態において支援され得る。それによって、クライアント
は、特定のステージで実行される処理操作の結果を使用して、１つ以上のストリームが作
成されることを示してよく、及び、特定のパーティションポリシが新しく作成されたスト
リームに使用される。いくつかの処理ステージが再分割のために主に構成され得る。例え
ば、レコードの属性セットＡ１に基づいて、データレコードをＮ１パーティションにマッ
プする１つのパーティション機能ＰＦ１は入力ストリームＳ１に使用され、及びＮ２パー
ティションに、（異なる属性セットＡ２または同一の属性セットＡ１の何れかを使用して
）これらの同一のデータレコードをマップするために処理ステージは異なるパーティショ
ンの機能ＰＦ２を実装するように使用され得る。ｌｉｎｋＳｔａｇｅのような、いくつか
のＳＰＳ ＡＰＩは、任意のグラフ（例えば、有向非巡回グラフ）を構成するために使用
され得る。いくつかの実施形態では、第三者またはオープンソースのストリーム処理フレ
ームワークまたはサービスへのコネクタが支援され得る。このような一実施形態において
は、ＳＰＳステージは、第三者またはオープンソースシステムが存在することによる消費
に、（例えば、ステージで実行される処理操作の結果を適切にフォーマットすることによ
って）データレコードを用意するために使用され得る。記載された実施形態において、ｃ
ｒｅａｔｅＴｈｉｒｄＰａｒｔｙＣｏｎｎｅｃｔｏｒのようなＡＰＩは、このようなコネ
クタを設定するために使用されてよく、ＳＰＳステージの結果を適切に第三者システムと
互換性があるフォーマットへの変換は、ｃｒｅａｔｅＴｈｉｒｄＰａｒｔｙＣｏｎｎｅｃ
ｔｏｒの結果としてインスタンス化された、１つ以上のコネクタモジュールによって実行
され得る。

ＳＰＳは矢印３５２で示すように、少なくとも機能のいくつかを実行するために、ＳＭ
Ｓ ＡＰＩ３０７を起動してよい。例えば、記載された実施形態では、ＳＭＳ ＡＰＩ３
０７は、ｃｒｅａｔｅＳｔｒｅａｍ及びｄｅｌｅｔｅＳｔｒｅａｍ（それぞれストリーム
を作成し削除するために）と、（所与のパーティションの役割をする、様々な種類のノー
ドのネットワークアドレスのように、ストリームのためにメタデータを取得するために）
ｇｅｔＳｔｒｅａｍＩｎｆｏとを含み得る。ｐｕｔＲｅｃｏｒｄインタフェースは、デー
タレコードを書き込むために使用され得る。一方、ｇｅｔＩｔｅｒａｔｏｒ及びｇｅｔＮ
ｅｘｔＲｅｃｏｒｄｓインタフェースは、それぞれ、非シーケンシャルリードとシーケン
シャルリードに使用され得る。ｒｅｐａｒｔｉｔｉｏｎＳｔｒｅａｍインタフェースは、
いくつかの実施形態では、特定のストリームの動的再分割を要求するために使用され得る
。このようにすることを希望するクライアント３７０は、矢印３５４によって示されるよ
うに、直接ＳＭＳ ＡＰＩ３０７を起動し得る。上記のように、様々なその他のＳＭＳ及
び／またはＳＰＳ ＡＰＩは、また、その他の実施形態で実装されてよく、図３に列挙さ
れたＡＰＩのいくつかは、いくつかの実施形態で実装されなくてよい。

種々の実施形態では、以外のＡＰＩプログラムによるインタフェースもまた、ＳＰＳま
たはＳＭＳの代わりに、または何れかに実装され得る。このようなインタフェースはグラ
フィカルユーザインターフェース、ウェブページまたはウェブサイト、コマンドラインイ
ンタフェース等を含み得る。場合によっては、ウェブベースのインタフェースまたはＧＵ
Ｉは、ビルディングブロックとしてＡＰＩを使用し得る。例えば、ウェブベースの相互作
用は、ＳＭＳまたはＳＰＳの制御コンポーネントで１つ以上のＡＰＩの起動がもたらされ
る可能性がある。図４は、少なくともいくつかの実施形態による、ＳＰＳクライアントが
ストリーム処理ステージのグラフ生成を可能にするために実装され得るウェブベースのイ
ンタフェースの実施例を示す。ここに示すように、インタフェースは、メッセージ領域４
０２、グラフメニュー領域４０４及びグラフデザイン領域４０３を有するウェブページ４
００を備える。

ユーザは、ストリームの概念及び基本要素についてより学習するために使用可能なリン
クと同様に、メッセージ領域４０２のストリーム処理グラフの構築に関する一般的な命令
を提供され得る。いくつかのグラフィカルアイコンは、メニュー領域４０４におけるスト
リーム処理グラフツールセットの一部として提供され得る。例えば、クライアントは、様
々なＳＰＳ処理ステージの入力または出力、永続性ストリーム４５１、一過性のストリー
ム４５２、または第三者の処理環境へのコネクタ４５３として示すことが可能である。ウ
ェブベースのインタフェースが実装されるＳＰＳ／ＳＭＳに関して、永続性ストリーム４
５１は、ディスク、不揮発性ＲＡＭまたはＳＳＤのようなデータレコードが永続性記憶装
置に格納されるストリームとして定義されてよく、一過性ストリーム４５２はデータレコ
ードが永続性記憶装置に格納される必要がないものとして定義されてよい。一過性ストリ
ームは、例えば、ベストエフォートリカバリポリシが実装される、異なるＳＰＳステージ
によって入力として消費されることが予想されるＳＰＳステージの出力から作成され得る
。

２つの種類の処理ステージが例示的なＳＰＳグラフ構成ウェブページ４００において支
援されている。チェックポイントベースのワーカノードリカバリが使用されるステージ４
５５（例えば、各ワーカノードがインターバルでプログレスレコードを保存し、特定のワ
ーカノードの破損の場合、交換されたノードが、どのデータレコードが処理を始めるべき
か判断する、損失したノードのプログレスレコードを参照する）、及びベストエフォート
リカバリが使用されるステージ４５６が使用される（例えば、交換されたワーカノードは
プログレスレコードを参照せず、しかし受信されたときに新しいデータレコードを単に処
理し始める）。各ステージで実行される処理操作に関する詳細は、メッセージ領域４０２
における命令によって示されるように、グラフ構成領域４０３中の対応するアイコンをク
リックすることによって、入力され得る。ストリーム、コネクタ及び処理ステージのアイ
コンに加え、メニュー領域４０４はまた、第三者または外部のストリーム処理システムを
示すアイコンタイプ４５９を含む。アイコンタイプ４６０は、リソースが処理ステージに
使用される、プロバイダネットワークで実装され得るストレージサービスのノードを示す
。

図４に示されている例示的な場合においては、クライアントは、グラフデザイン領域４
０３内に、３つの処理ステージ４１２、処理ステージ４１５及び処理ステージ４１６を備
えるグラフ４０５を構築した。処理ステージ４１２は、チェックポイントベースのリカバ
リを使用するよう構成され、入力として永続性ストリーム４１１を使用する。ステージ４
１２での処理の出力または結果は、ステージ４１５の入力を形成する、異なる永続性スト
リーム４１３の形態で、及びステージ４１６の入力を形成する、一過性ストリーム４１４
の形態で、２つの宛先に送信される。ステージ４１５及びステージ４１６の両方は、ベス
トエフォートリカバリポリシをワーカノードに使用する。ステージ４１５の出力は、一過
性ストリームの形態でストレージサービスノード４１９に送信される。ステージ４１５の
出力は、コネクタ４１７を介して第三者処理システム４１８に送信される。「グラフを保
存」というボタン４２０は、例えば、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏ
ｂｊｅｃｔＮｏｔａｔｉｏｎ）、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎ
ｇｕａｇｅ）またはＹＡＭＬ任意の適切なフォーマットで処理ステージのグラフの表示を
保存するために使用され得る。任意の複雑な処理ワークフローは、様々な実施形態で、図
４に示されたものに類似するツールを使用して構築され得る。このようなツールを使用し
て作成されたワークフローは、次にアクティブ化され、このようなアクティブ化は、例え
ば、図４のステージ４１２のような処理ステージのためにデータレコードを取得するため
に、ＳＭＳ ＡＰＩの起動がもたらされる可能性があり、ｇｅｔＩｔｅｒａｔｏｒ及び／
またはｇｅｔＮｅｘｔＲｅｃｏｒｄインタフェースは、ストリーム４１１上で起動され得
る。

図５は、少なくともいくつかの実施形態による、ＳＭＳで実装され得る、プログラミン
グによるレコードの送信インタフェース及びレコード検索インタフェースの実施例を示す
。図示された実施形態において、ＤＲ１１０Ｋ及び１１０Ｑのような、データレコードは
、様々な種類のプログラムによる取り込みインタフェース５１０を介してＳＭＳに送信さ
れ得る。ＤＲ１１０は、いくつかの実施形態で、（ストリーム「Ｓ１」に）５０１Ａまた
は（ストリーム「Ｓ２」に）５０１Ｂのようなストリーム識別子、データまたはレコード
本体の表示、（５０４Ａまたは５０４Ｂのような）任意のパーティションキー５０４及び
（順序付け設定表示５０６Ａ及び順序付け設定表示５０６Ｂのような）任意の順序付け設
定表示５０６の、４つの種類の要素を備え得る。データ自体は、いくつかのレコード（例
えば、ＤＲ１１０Ｋのインラインデータ５０２）においてインラインにて提供されてよい
。一方、その他のデータレコードには、ポインタまたはアドレス５０３が提供されてよく
、ＳＭＳ（またはネットワークの転送を必要としないローカルデバイスのアドレス）にネ
ットワークにアクセス可能な位置を表示する。いくつかの実施形態では、所与のストリー
ムは、インライン及びバイリファレンス（アドレスベース）データレコード送信の送信に
よって支援し得る。その他の実施形態では、所与のストリームは、すべてのデータをイン
ラインで、またはすべてのデータを参照によって供給するためにデータ生成部を必要とし
得る。いくつかの実装においては、データレコードの送信は、パーティション識別子がレ
コードに使用されることを含み得る。

図示された実施形態において、入力データレコード１１０は、パーティションポリシに
基づいて、それぞれの取り込み及び／またはストレージノードに向けられ得る。同様に、
レコードの検索もパーティションベースであり得る。例えば、１つ以上の検索ノードは所
与のパーティションのレコードに向けられた要求の読み取りに対応して指示され得る。い
くつかのストリームには、データ生成部は、明示的にパーティションキーに各データレコ
ード書き込み要求を提供することを必要とし得る。その他のストリームには、ＳＭＳは、
明示的に与えられたパーティションキー以外のメタデータまたは属性に依存するパーティ
ションスキームによるデータレコードを分散することが可能であり得る。例えば、データ
生成部への送信に関する識別情報は、パーティションキーとして使用され得る。またはデ
ータ生成部のＩＰアドレスの一部若しくはすべての送信データが使用されるか、送信され
るデータの一部が使用され得る。いくつかの実装においては、例えば、ハッシュ関数が、
１２８ビット整数のような特定のサイズの整数値を取得するために、パーティションキー
に適用され得る。そのサイズの正の整数の全範囲（例えば、０から２^∧１２８−１）は、
Ｎ連続副範囲に分けられてよく、対応するパーティションを表す各副範囲を備え得る。こ
のため、このような実施例においては、データレコードのために決定され、または供給さ
れる任意の所与のパーティションキーは、１２８ビット整数値に対応してハッシュされ、
整数値が属する１２８ビット整数値の連続副範囲は、データレコードが属するパーティシ
ョンを表し得る。さらにパーティションポリシ及びその使用についての詳細は、図１５に
関して下記に提供され得る。

特定のパーティションのデータレコードを取り込みまたは受信、データレコードの格納
、及び特定のパーティションに対する読み込み要求に応答する役割をするノードのセット
は、図５のパーティション用のＩＳＲ（取り込み、記憶及び検索）ノードと総称される。
Ｓｊ−Ｐｋという表記は、ストリームＳｉのｋ番目のパーティションを表すために使用さ
れる。図示した実施形態では、ＩＳＲノード５２０Ａは、パーティションＳ１〜Ｐ１のレ
コードを取り込み、格納及び検索するように構成され、ＩＳＲノード５２０Ｂはパーティ
ションＳ１〜Ｐ２のレコードを設定し、ＩＳＲノード５２０Ｃは、パーティションＳ１〜
Ｐ３のレコードを設定し、ＩＳＲノード５２０Ｋは、パーティションＳ２〜Ｐ１のレコー
ドを設定し、及びＩＳＲノード５２０Ｌは、パーティションＳ２〜Ｐ２のレコードを設定
する。いくつかの実施形態では、取り込みサブシステム、記憶サブシステムまたは検索サ
ブシステムの所与のノードは、２つ以上のパーティション（または２つ以上のストリーム
の２つ以上のパーティション）のデータレコードを取り扱うよう構成され得る。いくつか
の実施形態では、所与のストリームの単一パーティションのレコードは、２つ以上のノー
ドによって取り込まれ、格納され、または検索され得る。所与のパーティションＳｊ〜Ｐ
ｋ用に示された取り込みノードの数は、少なくともいくつかの場合において、異なるパー
ティションＳｊ〜Ｐｌ用に指定された取り込みノードの数と異なり得る。また、Ｓｊ〜Ｐ
ｋ用に指定された記憶ノードの数及び／またはＳｊ〜Ｐｋ用に指定された検索ノードの数
と異なり得る。取り込み及び／または検索に関して、ＳＭＳ制御ノードは、いくつかの実
施形態において、どのノードがどのパーティションに対し役割をするかをクライアントが
決定することが可能になるように、（ｇｅｔＳｔｒｅａｍＩｎｆｏのような）ＡＰＩを実
装し得る。データレコードとパーティションとの間及びパーティションとＩＳＲノード（
または制御ノード）との間の構成されたマッピングは、下記の動的再分割に関する記載し
たように、経時修正され得る。

いくつかの実施形態では、いくつかの異なるプログラムによるインタフェース５８０は
、所与のパーティションからストリームデータレコードを検索または読み込みするために
実装され得る。図５にて示すように、いくつかの検索インタフェース５８１は、（特定の
シーケンス番号を備えたデータレコードで、または特定のシーケンス番号を備えたデータ
レコードの後に、イテレータをインスタンス化またはカーソルを読み込みするための）ｇ
ｅｔＩｔｅｒａｔｏｒまたは（特定のシーケンス番号を備えたデータレコードを読み込む
ための）ｇｅｔＲｅｃｏｒｄのような、非シーケンシャルアクセスのために実装され得る
。その他の検索インタフェース５８２は、ｇｅｔＮｅｘｔＲｅｃｏｒｄ（シーケンス番号
の小さい順に、Ｎレコードがイテレータの現在位置から読み込まれることを要求するイン
タフェース）のようなシーケンシャル検索のために実装され得る。回転ディスクベースの
記憶システムにおいては、前述のように、多くの場合、シーケンシャルＩ／Ｏは、ランダ
ムＩ／Ｏよりもさらに、より効率的であり得る。平均Ｉ／Ｏ当たりに要求されるディスク
ヘッドシークの数は、典型的には、ランダムＩ／Ｏに対するよりも、シーケンシャルＩ／
Ｏに対してはかなり低い可能性がある。多くの実施形態では、所与のパーティションのデ
ータレコードは、シーケンス番号順に書き込まれ得る。シーケンス番号順に基づいて、そ
の結果、シーケンシャル読み込み要求（例えば、ｇｅｔＮｅｘｔＲｅｃｏｒｄまたは類似
のインタフェースを使用する）は、ランダムリードリクエストよりも著しくより効率的で
あり得る。したがって、少なくともいくつかの実施形態では、異なる課金はシーケンシャ
ル対非シーケンシャル検索インタフェースに設定され得る。例えば、クライアントは非シ
ーケンシャルリードに対し、より多く課金され得る。

取り込みサブシステム
図６は、少なくともいくつかの実施形態による、ＳＭＳの取り込みサブシステム２０４
の要素の実施例を示す。図示された実施形態において、取り込み操作は、フロントエンド
及びバックエンドの機能に論理的に分かれ、データ生成部１２０（例えば、１２０Ａ、１
２０Ｂまたは１２０Ｃ）との相互作用を含むフロントエンドの機能及びＳＭＳ記憶サブシ
ステムとの相互作用を含むバックエンド機能を備える。このようなフロントエンド／バッ
クエンドの分割は、記憶サブシステムのセキュリティを向上し、データ生成部にパーティ
ショニングポリシの詳細を提供する必要を避けるなどの、いくつかの利点を有し得る。Ｓ
ＭＳクライアントライブラリ６０２は、様々なデータ生成部１２０でインストールするた
めに提供され得る。データ生成部は、ライブラリ６０２に含まれるプログラムによるイン
タフェースを起動して取り込みのためにデータを送信し得る。例えば、一実施形態では、
データ生成部１２０は、何十万かのプロバイダネットワークの物理的及び／または仮想サ
ーバをインスタンス化されたロギングエージェントまたはモニタリングエージェントを備
え得る。このようなエージェントは、それぞれのサーバに様々なログメッセージ及び／ま
たは測定基準を収集し得る。また、定期的に、収集したメッセージまたは測定基準を、Ｓ
ＭＳの１つ以上の取り込み制御ノード６６０によってインスタンス化されたフロントエン
ド負荷分散装置６０４の終点に送信し得る。いくつかの実施形態では、１つ以上の仮想Ｉ
Ｐアドレス（ＶＩＰ）は、負荷分散装置用に確立され、データ生成部はストリームデータ
を送信し得る。一実装においては、ラウンドロビンＤＮＳ（ドメイン名システム）技術は
、データがデータ生成部１２０によって送信される、いくつかの同等に構成された負荷分
散装置のうち、特定の負荷分散装置を選択するためにＶＩＰに使用され得る。

図示された実施形態において、受信されたデータレコードはいくつかのフロントエンド
のノード６０６（例えば、６０６Ａ，６０６Ｂまたは６０６Ｃ）のいずれかに向けられ得
る。少なくともいくつかの実施形態では、負荷分散装置６０４は、データレコードに使用
するパーティショニングポリシ６５０を理解しなくてよい。したがって、フロントエンド
ノード６０６は、パーティションベースの負荷調整よりも、ラウンドロビン負荷分散（ま
たはいくつかのその他の汎用負荷調整アルゴリズム）を使用して、所与のデータレコード
に選択され得る。フロントエンドのノード６０６は、様々なストリーム用のパーティショ
ニングポリシ６５０を理解し、取り込み制御ノード６６０と相互作用して、所与のパーテ
ィションのデータレコードに構成される、特定のバックエンド取り込みノード６０８（例
えば、６０８Ａ，６０８Ｂまたは６０８Ｃ）の識別子を取得し得る。そのため、図示され
た実施形態においては、フロントエンドのノード６０４は、データレコードが属するそれ
ぞれのパーティションに基づいて、複数のバックエンドノード６０６にデータレコードを
それぞれ伝送し得る。上記のように、データレコードが属するパーティションは、データ
生成部によって供給されるパーティションキー、データ生成部の識別またはアドレスのよ
うな１つ以上のその他の属性、またはデータのコンテンツのような、様々な要因の任意の
組み合わせに基づいて決定され得る。

バックエンドノード６０６は、１つ以上のストリームの１つ以上のパーティションに属
するデータレコードをそれぞれ受信し、データレコードを記憶サブシステムの１つ以上の
ノードに伝送し得る。データがＨＴＴＰ（ハイパーテキストトランスファープロトコル）
の「ＰＵＴ」ウェブサービスＡＰＩを介して送信される、いくつかの実施形態では、バッ
クエンドノードは、「ＰＵＴサーバ」と称され得る。所与のバックエンドノードは、その
データレコードが制御ノード６６０にクエリを送信することによって伝送される、記憶サ
ブシステムノードのセットを決定し得る（順次、異なるサブシステムの制御機能が、ノー
ドの分離したセットによって処理される実施形態において、対応するクエリを記憶サブシ
ステムの制御ノードに送信し得る）。

少なくともいくつかの実施形態においては、少なくとも１回の取り込みポリシまたはベ
ストエフォート取り込みポリシのような、いくつかの異なる取り込み応答ポリシ６５２が
支援され得る。少なくとも１回のポリシでは、データ生成部１２０は、送信された各デー
タレコードに肯定応答を要求し、（第１送信の応答が受信されない場合には）応答が最終
的に受信されるまで、繰り返し同じデータレコードを送信し得る。ベストエフォート取り
込みポリシにおいては、肯定応答は、送信された少なくともいくつかのデータレコードは
必要とされなくてよい（しかしながら、取り込みサブシステムは依然として不定期に応答
を提供し得る。またはデータ生成部からの応答の明示的な要求に応答し得る）。取り込み
サブシステム２０４がデータ生成部に応答を提供するよう要求する、いくつかの実施形態
では、所与のデータレコードの役割をするバックエンド取り込みノード６０８は、応答を
生成する前に、要求された数のデータレコードの複製が、記憶サブシステムで正常に作成
されるまで（例えば、ストリームに確立された永続性ポリシに従って）待機し得る。様々
な実施形態では、シーケンス番号は、受信された各データレコードのために取り込みサブ
システムによって生成され得る。例えば、類似のパーティションまたはストリームのその
他のレコードに関連してそのレコードが取り込まれた順序を示す。またこのようなシーケ
ンス番号はデータ生成部に応答として、または応答の一部として返され得る。シーケンス
番号に関するさらなる詳細は、図１３ａ及び図１３ｂを参照して以下に提供され得る。い
くつかの実装においては、応答及び／またはシーケンス番号は、フロントエンドのノード
６０６を介してデータ生成部に戻って伝送され得る。少なくとも一実装においては、少な
くとも１回のポリシが、取り込みサブシステム自体のフロントエンドノードとバックエン
ドノードの間で実装され得る。例えば、所与のフロントエンドのノード６０６は、バック
エンドノードが応答を提供するまで、適切なバックエンドノード６０８にデータレコード
を繰り返し送信し得る。

取り込み制御ノード６６０は、ストリームの動的再分割に起因する、取り込みに関連し
た構成操作に対し、その他の機能のうち、フロントエンドノードとバックエンドノードを
インスタンス化し、ノードのヘルスとワークロードレベルを監視し、必要に応じてフェイ
ルオーバを編成し、所与のパーティションの役割をするノードに関するクエリまたはポリ
シに関連したクエリへの応答を提供する役割があってよい。いくつかの実施形態では、１
つ以上のストリームの所与のセットに指定された、取り込み制御ノードの数は、時間とと
もに変化され得る。例えば、１つ以上のマスター制御ノードは、必要に応じて制御ノード
プールの再構成をする役割をし得る。冗長グループが取り込みフロントエンドノードまた
はバックエンドノードに設定される、いくつかの実施形態では、図９及び図１０を参照し
て、さらに詳細に後述のように、制御ノード６６０は、どのノードがプライマリでどのノ
ードが非プライマリであるか把握し、フェイルオーバに対するトリガ条件検出し、フェイ
ルオーバが要求されたときに置換えを選択し得る。図６に示された、多層の取り込みサブ
システム構造は、いくつかの実施形態で実装されない可能性があることに注意する。例え
ば、取り込みノードの単一セットのみがいくつかの場合において構成され得る。

記憶サブシステム
図７は、少なくともいくつかの実施形態による、ＳＭＳの記憶サブシステムの要素の実
施例を示す。ここに示すように、取り込みノード６０８（例えば、フロントエンド及びバ
ックエンド取り込みの役割は、異なるノードのセットによって処理される実施形態におけ
るバックエンド取り込みノード）は、これらのパーティション用に構成されたそれぞれの
記憶ノード７０２に、ストリームの１つ以上のパーティションのデータレコードを伝送し
得る。例えば、パーティションＳ１〜Ｐ１のデータレコード１１０Ａはストレージノード
７０２Ａに送信され、パーティションＳ２〜Ｐ３のデータレコード１１０Ｂは、ストレー
ジノード７０２Ｂ及びストレージノード７０２Ｃに送信され、パーティションＳ３〜Ｐ７
のデータレコード１１０Ｃは、ストレージノード７０２Ｄに送信され、及びパーティショ
ンＳ４〜Ｐ５のデータレコード１１０Ｄは、ストレージノード７０２Ｅに初めに送信され
る。記憶制御ノード７８０は、異なるストリームのデータレコードに適用される永続性ポ
リシ７５０を実現し、必要に応じてストレージノードを構成及び再構成し、ストレージノ
ードの状態を監視し、フェイルオーバを管理し、ストレージ構成クエリまたはストレージ
ポリシクエリに応答し、及び図示された実施形態において様々なその他の管理タスクをす
る役割をし得る。

永続性ポリシ７５０は、異なる実施形態において、様々な方法で互いに異なり得る。例
えば、ストリームＳｊに適用される永続性ポリシＰ１は、（ａ）格納される各データレコ
ードのいくつかの複製（ｂ）複製が記憶される記憶装置またはシステムの種類（例えば、
複製が揮発性メモリ、不揮発性キャッシュ、回転ディスクベースのストレージ、ソリッド
ステートドライブ（ＳＳＤ）、様々な種類のストレージアプライアンス、データベース管
理システム中の様々な種類のＲＡＩＤ（安価なディスクの冗長アレイ）、プロバイダネッ
トワークによって実装されるストレージサービスのノードなどに記憶されるべきか否か）
（ｃ）複製の地理的分散（例えば、ストリームデータは、異なるデータセンタに複製を配
置することによって、大規模な破損または特定の種類の事故に対し回復力があるか否か）
（ｄ）書き込み応答プロトコル（例えば、Ｎ複製が格納される場合には、応答が取り込み
ノードに提供される前に、いくつのＮ複製が正常に書き込みする必要があるか）及び／ま
たは（ｅ）データレコードの多数の複製が格納される場合、複製は並行してまたは継続し
て作成されるか否かという点においてストリームＳｋに適用されるポリシＰ２、とは異な
り得る。多数の複製が格納されるいくつかの場合には、データレコード１１０Ｄの場合の
ように、所与のストレージノードは、データレコードは別のストレージノードに送信し得
る（例えば、ストレージノード７０２Ｅはさらにストレージノード７０２Ｆにデータレコ
ード１１０Ｄをさらに複製するために送信し、ストレージノード７０２Ｆはストレージノ
ード７０２Ｇを送信する）。多数の複製永続性ポリシが使用される、その他の場合におい
ては、２つのメモリ内複製が格納されるデータレコード１１０Ｂの場合においては、取り
込みノードは多数の複製を並行して開始し得る。少なくともいくつかの実施形態において
は、クライアントの選択した永続性ポリシは、ストリームデータレコードに使用される記
憶位置の種類を明示しなくてよい。むしろ、ＳＭＳは、記憶技術の適切な種類及び／また
は費用、性能、データレコードへの費用、性能、データソースへの近接、耐久性の条件等
、様々な基準に基づいた位置を選択し得る。一実施形態では、クライアントまたはＳＭＳ
のどちらかは、所与のストリームの異なるパーティションまたは異なるストリーム用の、
異なる記憶技術または記憶位置の種類を使用するために決定し得る。

図７に示された実施例においては、ストリームＳ１（または少なくともストリームＳ１
のパーティションＳ１〜Ｐ１）に適用される永続性ポリシは、メモリ内ポリシの単一の複
製である。一方、ストリームＳ２には、２つの並行複製メモリ内ポリシが適用される。し
たがって、データレコード１１０Ａのメモリ内複製７０４Ａは、ストレージノード７０２
Ａで作成され、一方、データレコード１１０Ｂに対応する２つのメモリ内複製７０５Ａ及
びメモリ内複製７０５Ｂは、ストレージノード７０２Ｂ及びストレージノード７０２Ｃで
並行して作成される。ストリームＳ３のデータレコード１１０Ｃには、単一ディスク上の
複製７０６Ａが作成される。ストリームＳ４には、シーケンシャルな３つの複製のディス
ク上ポリシが適用可能であり、その結果、それぞれのディスク上の複製７０７Ａ、複製７
０７Ｂ及び複製７０７Ｃはシーケンシャルにストレージノード７０２Ｅ、ストレージノー
ド７０２Ｆ及びストレージノード７０２Ｇで作成される。様々なその他の種類の永続性ポ
リシが、異なる実施形態でデータストリームに適用され得る。検索サブシステムのノード
は、データコンシューマによる、様々な種類の検索ＡＰＩの起動に対応する適切なストレ
ージノードから、データレコードを取得し得る。

検索サブシステム及び処理ステージ
図８は、少なくともいくつかの実施形態による、ＳＭＳの検索サブシステムの実施例の
要素及びＳＰＳとの検索サブシステムの相互作用の実施例を示す。示されているように、
検索サブシステム２０６は、検索制御ノード８８０の収集と同様に、検索ノード８０２Ａ
、検索ノード８０２Ｂ及び検索ノード８０２Ｃのような、複数の検索ノード８０２を備え
得る。検索ノード８０２のそれぞれは、後述のように、ＳＰＳのワーカノード８４０のよ
うな、様々なクライアントまたはデータコンシューマ１３０からのストリームデータの検
索要求に応答するよう構成され得る。様々なプログラムによる検索インタフェース８０２
は、前述した非シーケンシャル検索インタフェース及びシーケンシャル検索インタフェー
スによって、異なる実施形態において検索ノードによって実装され得る。いくつかの実施
形態では、ＨＴＴＰ ＧＥＴ要求のようなウェブサービスＡＰＩは、データレコード検索
に使用され、したがって、検索ノード８０２はＧＥＴサーバと称され得る。所与の検索ノ
ード８０２は、記憶ノード７０２Ａ及び記憶ノード７０２Ｂのような、適切な記憶サブシ
ステム７０２のセットから、記載された実施形態においては、例えば、検索制御ノード８
８０によって、１つ以上のストリームパーティションのデータレコードを取得するよう構
成され得る。

記載された実施形態において、検索ノード８０２は１つ以上の記憶ノード７０２と対話
し、また、１つ以上のＳＰＳワーカノード８４０から受信された検索要求に応答し得る。
例えば、パーティションＳ４〜Ｐ５のデータレコード（例えば、データレコード１１０Ｋ
）及びパーティションＳ５からＰ８（例えば、データレコード１１０Ｌ）は、記憶ノード
７０２Ａから、検索ノード８０２Ａによって読み込まれ、ワーカノード８４０Ａ及びワー
カノード８４０Ｋにそれぞれ提供される。１１０Ｍのような、パーティションＳ６〜Ｐ７
のデータレコードは、記憶ノード７０２Ａから検索ノード８０２Ｂによって読み込まれ、
ワーカノード８４０Ｋに提供される。パーティションＳ４〜Ｐ７のデータレコードは、検
索ノード８０２Ｃによって記憶ノード７０２Ｂから読み込まれ、ワーカノード８４０Ｂに
提供され、また、その他のデータコンシューマ１３０（例えば、ＳＰＳを介してＳＭＳと
対話する代わりに、直接ＳＭＳ検索ＡＰＩをデータコンシューマ起動する）に提供される
。

少なくともいくつかの実施形態においては、検索ノード８０２のいくつか、またはすべ
ては、様々なパーティションのデータレコードが将来の検索要求を予測して一時的に保持
され得る、それぞれのキャッシュ８０４を実装し得る（検索ノード８０２Ａでのキャッシ
ュ８０４Ａ、検索ノード８０２Ｂでのキャッシュ８０４Ｂ及び検索ノード８０２Ｃでのキ
ャッシュ８０４Ｃ）。検索制御ノード８８０は、例えば、キャッシュポリシ（例えば、キ
ャッシュが所与のパーティションを構成するためにどのくらいの大きさであるべきか、デ
ータレコードはどのくらいの長さをキャッシュすべきか）、記憶ノード選択ポリシ（例え
ば、どの特定の記憶ノードが、データレコードの多数の複製が格納される場合において、
所与のデータレコードを取得するために最初に接触されるべきか）、などを含む、いくつ
かの検索ポリシ８８２を実装する役割をし得る。加えて、検索制御ノードは、検索ノード
８０２をインスタンス化し監視する役割をし、どちらの検索ノードがどちらのパーティシ
ョンの役割をし、再分割の操作等を開始して、応答するかに関するクエリに応答し得る。

図示された実施例では、ＳＰＳ２９０は２つの処理ステージ２１５Ａ及び処理ステージ
２１５Ｂを備える。ＳＰＳ制御ノード８８５は、パーティションＳ４〜Ｐ５のレコードを
処理するワーカノード８４０Ａ、パーティションＳ４〜Ｐ７のレコードを処理するワーカ
ノード８４０Ｂ、パーティションＳ５〜Ｐ８及びパーティションＳ６〜Ｐ７のレコードを
処理するワーカノード８４０Ｋのような、様々な処理ステージ２１５でワーカノード８０
４をインスタンス化する役割をし得る。ＳＰＳ制御ノード８８５は、（図３及び図４に示
されたような）プログラムによるインタフェースを実装し、ＳＰＳクライアントが処理ワ
ークフローを設計するのを可能にする。様々なチェックポイントポリシ８５０が、異なる
処理ステージまたはワークフローに実装されてよく、いつワーカノードがプログレスレコ
ードを格納するべきかを表示し、どのくらいそれぞれのパーティション、プログレスレコ
ード等に使用される記憶装置の種類などを処理しているのかを表示する。フェイルオーバ
／リカバリポリシ８５２は、異なるノードでワーカノードを置き換えすることにつながる
、トリガ条件または閾値を表示してよく、ベストエフォートリカバリが使用されるか、チ
ェックポイントベースのリカバリが所与の処理ステージに使用されるかを表示し得る。少
なくともいくつかの実施形態においては、ＳＰＳ制御ノード８８５は、例えば、所与のス
トリームのデータレコードが取得される検索ノードを識別し、特定の処理ワークフロー等
に必要であり得る新しい一過性または永続性のストリームを確立するために、様々な種類
のＳＭＳ制御ノードと相互作用してよい。少なくとも一実施形態においては、クライアン
トはＳＰＳ制御ノードと対話し、ストリームをインスタンス化し得る。例えば、ＳＭＳ制
御インタフェースを利用する代わりに、あるクライアントはより高いレベルのＳＰＳイン
タフェースのみを起動したい可能性がある。ＳＭＳの取り込み、格納及び検索サブシステ
ムのための制御ノードの分離したセットは図６、図７及び図８に示されているが、ＳＰＳ
ステージには、少なくともいくつかの実施形態では、所与の制御ノードはいくつかのサブ
システム及び／またはＳＰＳに使用され得ることに注意する。

ノード冗長グループ
少なくともいくつかの実施形態においては、ノードの冗長グループは、ＳＭＳの１つ以
上のサブシステム用に構成され得る。すなわち、例えば、ストリームパーティションＳｊ
〜Ｐｋ用のデータレコードを検索する１つの検索ノードを構成する代わりに、２つまたは
それ以上のノードが、このような検索のために確立されてよく、「プライマリ」と認めら
れている１つのノードまたは所与の時点で動作中の役割をする一方、その他のノードは「
非プライマリ」ノードとして設計されている。現在のプライマリノードは、例えば、クラ
イアントまたはその他のサブシステムのノードの何れかから受信した要求の、ワーク要求
に応答する役割をし得る。非プライマリノードまたはノードは、例えば、破損、プライマ
リへの接続不良、またはその他のトリガ条件のため、フェイルオーバがトリガされるまで
休眠したままでよく、その場合には、選択された非プライマリは制御ノードによって通知
され、従来のプライマリの役割に取って代わってもよい。したがって、プライマリの役割
は、フェイルオーバの間、従来のプライマリノードから取り消され、現在の非プライマリ
ノードを許可される。いくつかの実施形態では、非プライマリノードは、フェイルオーバ
が起こったと決定されたときに、プライマリとして取って代わり得る。例えば、明示的な
通知が必要とされなくてよい。様々な実施形態では、このようなノードの冗長グループは
、ＳＭＳの機能を取り込み、格納、検索及び／または制御するために設定されてよく、類
似の手法もまた、少なくともいくつかの実施形態でＳＰＳのワーカノードに取られてよい
。いくつかの実施形態では、所与の機能のための、少なくとも１つのプライマリノード及
び少なくとも１つの非プライマリノードを備える、このようなグループは、「冗長グルー
プ」または「複製グループ」と呼ばれ得る。ストレージノードの冗長グループは、格納さ
れるデータレコードのいくつかの物理的複製を独立して実装され、例えば、格納されるべ
きいくつかの複製のデータレコードは、永続性ポリシによって決定されてよく、一方、対
応するパーティションのために構成された、いくつかの記憶ノードは、冗長グループポリ
シに基づいて決定されることに注意する。

図９は、少なくともいくつかの実施形態による、ＳＭＳまたはＳＰＳのノード用に設定
され得る冗長グループの実施例を示す。記載された実施形態において、所与のストリーム
パーティションＳｊ〜Ｐｋには、それぞれの冗長グループ（ＲＧ）９０５、冗長グループ
９１５、冗長グループ９２５及び冗長グループ９３５が取り込みノード、記憶ノード、検
索ノード及び制御ノードのために設定されている。取り込み制御ノード、記憶制御ノード
または検索制御ノードのための分離したＲＧはいくつかの実施形態で実装されているが、
制御ノードのための共通のＲＧ９３５は、図示された実施形態において実装されている。
各ＲＧは、プライマリノード（例えば、プライマリ取り込みノード９１０Ａ、プライマリ
記憶ノード９２０Ａ、プライマリ検索ノード９３０Ａ及びプライマリ制御ノード９４０Ａ
）及び少なくとも１つの非プライマリノード（例えば、非プライマリ取り込みノード９１
０Ｂ、非プライマリ記憶ノード９２０Ｂ，非プライマリ検索ノード９２０Ｃ及び非プライ
マリ検索ノード９２０Ｄ）を備える。プライマリの役割は、それぞれのフェイルオーバポ
リシ９１２（取り込みノード用）、フェイルオーバポリシ９２２（記憶ノード用）、フェ
イルオーバポリシ９３２（検索ノード用）及びフェイルオーバポリシ９４２（制御ノード
用）にしたがい、取り消され、現在の非プライマリが許可される。例えば、フェイルオー
バポリシは、プライマリステイタスにおける変更につながるトリガ条件管理してよく、プ
ライマリまたは非プライマリのヘルスステータスが監視されているか否か、及びどのよう
に監視されているか、所与の冗長グループ等に構成されるべき非プライマリの数を管理し
得る。少なくともいくつかの実施形態においては、単一のＲＧは、多数のパーティション
用に確立され得る。例えば、ＲＧ９０５は、パーティションＳｐ〜Ｐｑと同様に、パーテ
ィションＳｊ〜Ｐｋのレコードの取り込みを処理する役割があり得る。いくつかの実装に
おいては、１つのパーティション用のプライマリとして設計されたノードは、同時に、別
のパーティション用の非プライマリとして設計され得る。一実施形態では、多数のノード
は、同時に、所与のＲＧ内のプライマリノードとして示され得る。例えば、所与のパーテ
ィションの取り込みに関連したワークロードは、２つのプライマリノードに分散されてよ
く、破損した場合に備え、どちらかがプライマリで非プライマリとして示される１つのノ
ードを備える。所与のＲＧ内のインスタンス化されたノードの数は、対応する機能に望ま
しい入手可能性または回復レベルに依存し得る（例えば、そのグループ耐え得ることを予
定しているのが、どのくらい多くの同時発生または重複する破損か）。いくつかの実施形
態では、ＳＭＳノードへの使用またはＳＭＳノードへの使用の代わりに、冗長グループは
ＳＰＳ処理ステージのワーカノードのために設定され得る。図１０に示されるように、所
与のＲＧのメンバは、例えば、いくつかのデータセンタにわたって地理的に時々、分散さ
れ得る。いくつかの実施形態では、選択された制御ノードは、例えば、ハートビート機構
またはその他のヘルス監視技術を使用し、フェイルオーバトリガ条件を検出するよう構成
され得る。また、このような制御ノードは、損失したプライマリの置換えとして、適切な
非プライマリノードを選択し、選択された置換えのノード等を通知／起動することによっ
てフェイルオーバを調整し得る。

いくつかの実施形態では、プロバイダネットワークは、複数の地理的領域に分けられ、
各領域は１つ以上のアベイラビリティコンテナを含んでよく、本明細書では「アベイラビ
リティゾーン」とも呼ばれる。アベイラビリティコンテナは、順次、１つ以上の異なる位
置またはデータセンタを備え、所与のアベイラビリティコンテナにおけるリソースが、そ
の他のアベイラビリティコンテナにおける破損から絶縁されるような方法で設計され得る
（例えば、電力関連装置、冷却装置、物理的安全構成要素等の、独立したインフラストラ
クチャコンポーネント）。一アベイラビリティコンテナにおける破損は、任意のその他の
アベイラビリティコンテナにおける損失という結果にならない可能性がある。このため、
リソースインスタンスのアベイラビリティプロフィールまたは制御サーバは、異なるアベ
イラビリティコンテナにおいて、リソースインスタンスのアベイラビリティプロフィール
または制御コントロールサーバに依存しないことを意図している。様々な種類のアプリケ
ーションは、それぞれのアベイラビリティコンテナにおける多数のアプリケーションイン
スタンスを起動すること、または、（いくつかのＳＭＳ及びＳＰＳの場合）多数のアベイ
ラビリティコンテナにわたって、所与の冗長グループのノードを分散するによって、多数
の単一の位置での破損から保護され得る。同時に、いくつかの実装においては、安価で短
待ち時間のネットワークの接続は、類似の地理的領域内にあるリソース（ＳＭＳ及びＳＰ
Ｓノードに使用されるホストまたはコンピュートインスタンス）間で提供されてよく、類
似のアベイラビリティコンテナのリソース間のネットワーク伝送がさらに速くなり得る。
あるクライアントは、ストリーム管理リソースまたはストリーム処理リソースが予約及び
／またはインスタンス化される位置を特定したいと思う可能性がある。例えば、アプリケ
ーションが実行される様々な構成要素の所望の制御度合いを維持するアベイラビリティコ
ンテナレベルまたはデータセンタレベルの何れかの領域レベルリソースが、例えば性能、
ハイアベイラビリティ等のクライアントの要求に合致する限り、その他のクライアントは
、リソースが予約またはインスタンス化される、実際の場所にあまり興味が無い可能性が
ある。いくつかの実施形態では、１つのアベイラビリティコンテナ（またはデータセンタ
）に配置された制御ノードは、その他のアベイラビリティコンテナ（またはその他のデー
タセンタ）におけるその他のＳＭＳまたはＳＰＳノードを遠隔から構成することが可能で
あり得る。つまり、特定のアベイラビリティコンテナまたはデータセンタが、ＳＭＳ／Ｓ
ＰＳノードを管理するためにローカル制御ノードを有する必要はない。

図１０は、少なくともいくつかの実施形態による、所与の冗長グループのノードが複数
のデータセンタに分散され得る、プロバイダのネットワーク環境を示す。図示された実施
形態においては、プロバイダネットワーク１００２は、３つの可用性コンテナ１００３Ａ
、可用性コンテナ１００３Ｂ及び可用性コンテナ１００３Ｃを備える。各可用性コンテナ
は、１つ以上のデータセンタの一部または全部を含む。例えば、可用性コンテナ１００３
Ａはデータセンタ１００５Ａ及びデータセンタ１００５Ｂを備え、可用性コンテナ１００
３Ｂはデータセンタ１００５Ｃを含み、及び可用性コンテナ１００３Ｃはデータセンタ１
００５Ｄを含む。ＳＭＳ及び／またはＳＰＳノードのいくつかの異なる冗長グループ１０
１２が示されている。データセンタ１００５Ａ内に配置されたＲＧ１０１２Ａの場合のよ
うに、いくつかのＲＧ１０１２は、単一のデータセンタ内に全体が実装され得る。その他
のＲＧは、ＲＧ１０１２Ｂのように、所与の可用性コンテナ内で多数のデータセンタのリ
ソースを使用してよく、可用性コンテナ１００３Ａのデータセンタ１００５Ａ及びデータ
センタ１００５Ｂにわたる。しかしながら、その他のＲＧは、異なる可用性コンテナにわ
たって広がるリソースを使用して実装され得る。例えば、ＲＧ１０１２Ｃは、可用性コン
テナ１００３Ａ及び可用性コンテナ１００３Ｂのデータセンタ１００５Ｂ及びデータセン
タ１００５Ｃに配置されたリソースをそれぞれ使用し、ＲＧ１０１２Ｄは、可用性コンテ
ナ１００３Ａ、可用性コンテナ１００３Ｂ及び可用性コンテナ１００３Ｃ中それぞれのデ
ータセンタ１００５Ｂ、データセンタ１００５Ｃ及びデータセンタ１００５Ｄでリソース
を利用する。一例示的な配置においては、ＲＧ１０１２が１つのプライマリノード及び２
つの非プライマリノードを備え、３つのノードのそれぞれは、異なる可用性コンテナに配
置され得る。そのため、少なくとも１つのノードは、大規模な破損イベントが２つの異な
る可用性コンテナを同時に起こしても、機能的なままである可能性が高い。

図示された実施形態において、ＳＭＳ及びＳＰＳのそれぞれに関連する、コンソールサ
ービス１０７８及びコンソールサービス１０７６は、使用が簡単なウェブベースのインタ
フェースを、プロバイダネットワーク１００２にストリームに関連する設定を構成するた
めに提供し得る。いくつかのさらなるサービスは、その少なくともいくつかはＳＭＳ及び
／またはＳＰＳによって使用され得るが、１つ以上のデータセンタにわたる、または１つ
以上の可用性コンテナを横断するリソースを使用してプロバイダネットワーク１００２に
て実装され得る。例えば、仮想計算サービス１０７２は、実装され得る。クライアントが
様々な異なるケーパビリティレベルのコンピュートインスタンスとしてパッケージ化され
た計算能力の選択された量を利用することができ、このようなコンピュートインスタンス
は、ＳＭＳ及び／またはＳＰＳノードを実装するために使用され得る。１つ以上のストレ
ージサービス１０７０は、例えばブロックデバイスボリュームインタフェース、またはウ
ェブサービスインタフェースの何れかを介して実装されてよく、クライアントが所望のデ
ータ耐久性でデータオブジェクトを記憶しアクセスするのを可能にする。ストレージオブ
ジェクトは、サービス１０７２のコンピュートインスタンスに取り付け可能であり得る。
またはサービス１０７２のコンピュートインスタンスからアクセス可能であり得る。いく
つかの実施形態では、ＳＭＳストレージサブシステムで様々なストリーム永続性ポリシに
使用され得る。一実施形態では、ハイパフォーマンスキー値管理サービス１０７４のよう
な、１つ以上のデータベースサービスまたはリレーショナルデータベースサービスは、プ
ロバイダネットワーク１００２で実装され得る。このようなデータベースサービスは、Ｓ
ＭＮＳストレージサブシステムによってストリームデータレコードに及び／または制御サ
ブシステム、取り込みサブシステム、記憶サブシステム、検索サブシステムまたは処理ス
テージのメタデータを格納するために使用され得る。

ストリームセキュリティオプション
少なくともいくつかの実施形態においては、ＳＭＳ及び／またはＳＰＳのユーザは、デ
ータストリームのためにいくつかのセキュリティに関連するオプションが提供されてよく
、クライアントが、取り込み、記憶、検索、処理及び／または制御のような、様々な機能
カテゴリに使用するためにリソースのセキュリティプロフィール（例えば、仮想または物
理マシン）を選択することが可能になる。このようなオプションとしては、例えば、様々
なノードに使用されるリソースの物理位置の種類に関する選択（例えば、プロバイダネッ
トワーク設備が使用されるべきかどうか、またはクライアント所有の設備が使用されるべ
きかどうかであり、これはプロバイダネットワーク設備とは異なるセキュリティ特徴を有
し得る）、ストリームデータの暗号化に関する選択、及び／またはストリーム処理インフ
ラストラクチャの様々な部分においてネットワークを遮断する選択が挙げられる。あるク
ライアントは、貴重な独占しているビジネスロジックまたはアルゴリズムへのアクセスを
する侵入者または攻撃者の可能性について懸念を持ち得る。例えば、クライアント所有の
プロミス内の計算装置を使用してストリーム処理ワーカノードを実装し得る。ＳＭＳ及び
／またはＳＰＳノードのセットを実装するために使用されるリソースの種類は、本明細書
においては、これらのノードに対する「配置先種類」と称し得る。図１１は、少なくとも
いくつかの実施形態による、ＳＭＳまたはＳＰＳのノード用に選択され得る複数の配置先
の種類を示す。

図示された実施形態において、配置先は、ＳＭＳ／ＳＰＳ機能カテゴリ用のプロバイダ
ネットワーク１１０２（例えば、取り込み、記憶、検索、制御または処理）及びその他の
種類のＳＭＳ／ＳＰＳの機能カテゴリ用の外部のプロバイダネットワーク１１０２内で選
択され得る。プロバイダネットワーク１１０２内では、コンピュートインスタンス、スト
レージインスタンスまたはデータベースインスタンスのような、いくつかのリソースは、
マルチテナントのインスタンスホスト１１０３を使用して実装され得る。このようなマル
チテナントのインスタンスホストは、１つ以上のクライアントに対するＳＭＳまたはＳＰ
Ｓノードのそれぞれがインスタンス化されてよく、配置先の種類の第１カテゴリ「Ａ」を
形成し得る。その他のクライアントと物理リソースを共有しなければならないことを避け
るために、あるクライアントはＳＭＳ／ＳＰＳノードを単一のクライアントに限定したイ
ンスタンスホストを使用して実装されることを要求し得る。このようなシングルテナント
のインスタンスホストは、配置カテゴリの種類「Ｂ」を形成し得る。シングルテナントの
インスタンスホストは、いくつかの理由のため、あるクライアントの観点から、望ましい
場合がある。マルチテナントのインスタンスホストは、その他のクライアントに属するコ
ンピュートインスタンスを含み得る。シングルテナントのインスタンスホストよりも、マ
ルチテナントのインスタンスホストにおける別のクライアントのインスタンスからのセキ
ュリティ攻撃の可能性がより高くなり得る。加えて、マルチテナントホストで動くあるク
ライアントのコンピュートインスタンスＣＩ１は、ワークロードでサージを経験し、ホス
トの計算サイクルまたはその他のリソースの大きな割合を消費し始め、そのため場合によ
り異なるコンピュートインスタンスＣＩ２上で動く別のクライアントのアプリケーション
の性能に衝撃を与える、「ノイジーネイバー」現象は、またシングルテナントのインスタ
ンスホストが使用されるときに避けられ得る。

ＩＶＮ１１０６Ａ及びＩＶＮ１１０６Ｂのような、隔離された仮想ネットワーク（ＩＶ
Ｎ）１１０６は、図示された実施形態において、配置先種類の別のカテゴリ「Ｃ」を表し
得る。いくつかの実施形態では、ＩＶＮ１１０６は、プライベートネットワークの論理等
価として、プロバイダネットワークのクライアントの要求で作成されてよく、プロバイダ
ネットワークのリソースを使用して構築するが、クライアントによって主に制御されるネ
ットワーク構成である。例えば、クライアントは、ＩＶＮの外部ですでに使用され得るＩ
Ｐアドレスを複製する可能性について懸念することなしに、ＩＰアドレスを決定し、ＩＶ
Ｎ１１０６内で使用し得る。図示された実施形態において、１つ以上のＩＶＮにおいて、
ＳＭＳ及びＳＰＳノードの様々な種類の実装は、クライアントのストリームデータの管理
及び／または処理に対するネットワークセキュリティのレベルをさらに上げ得る。場合に
よっては、所与のクライアントは、１つのＩＶＮ１１０６におけるＳＭＳ／ＳＰＳノード
の１つの機能的カテゴリ、及び異なるＩＶＮに異なる機能的カテゴリを配置したいと思う
可能性がある。様々な実施形態では、所与のＩＶＮ１１０６は、シングルテナントのイン
スタンスホストかマルチテナントのインスタンスホストの何れか、またはインスタンスホ
ストの両種類を備え得る。いくつかの実施形態では、プロバイダネットワークのリソース
を使用する、配置先種類の選択の別のセット（またはセキュリティプロフィールの選択）
は、図１１には図示されていないが、少なくともあるクライアントには入手可能であり得
る。クライアントが、ストリーム関連の操作のために、プロバイダネットワークの仮想計
算サービスからコンピュートインスタンスを取得し使用できる実施形態においては、コン
ピュートインスタンスは２つのモードのうち１つで使用され得る。１つのモードにおいて
は、クライアントは、ＳＰＳまたはＳＭＳに、実行可能なプログラムまたは、ＳＰＳワー
カノードとして構成されたコンピュートインスタンスにて（若しくは取り込みノード、記
憶ノードまたは検索ノードにて）動作されるプログラムを提供し、ＳＭＳあるいはＳＰＳ
にプログラムを動作させ、ノードを管理させ得る。この第１モードは、ストリーム操作に
コンピュートインスタンスを使用する「ストリームサービスが管理する」モードとして呼
ばれることもある。その他のモードにおいては、クライアントは、ＳＰＳまたはＳＭＳか
ら支援がより少ない状態で、実行可能なプログラムを動かし、コンピュートインスタンス
の管理をすることを希望する場合がある。この第２モードは、ストリーム操作にコンピュ
ートインスタンスを使用する「クライアントが管理する」モードとして呼ばれることもあ
る。よって、これら２つの操作モードは、クライアントが選択可能な配置先の種類または
セキュリティプロフィールに関する追加の選択肢を表し得る。例えば、クライアントは、
実行可能なプログラムが、クライアントの組織から主題に関する専門家によって最適に実
行されるデバッグ（シングルステッピングを含む）を必要とする可能性がある場合には、
クライアントが管理するモードを選択し得る。一方、ストリームサービスが管理するモー
ドは、デバッグを必要とする可能性のないより完成したコードには有効な選択肢であり得
る。いくつかの実施形態では、異なる価格設定がこれら２つのモードに適用し得る。

いくつかの配置の選択肢が、図１１に示された実施形態におけるプロバイダネットワー
ク外部の設備で支援され得る。例えば、ＳＭＳライブラリ１１７１及び／またはＳＰＳラ
イブラリ１１７２がインストールされるホスト１１６０は、クライアントの設備１１１０
Ａまたは設備１１１０Ｂ内（例えば、クライアントが所有するデータセンタ若しくは構内
）でストリーム管理またはストリーム処理に使用されてよく、２種類のクライアントの設
備は、プロバイダネットワークへの接続方法において異なる。クライアントの設備１１１
０Ａは、プロバイダネットワーク１１０２に少なくともいくつかの共有されるインターネ
ットリンク１１５１を介してリンクされている（すなわち、その他のエンティティのネッ
トワークトラフィックは、また、クライアントの設備１１１０Ａとプロバイダネットワー
ク１１０２との間のリンクのいくつかにわたって流れ得る）。対照的に、（１１１０Ｂの
ような）いくつかのクライアントの設備は、特別な共有されない専用の物理リンク１１０
６（時に「直接接続リンク」と呼ばれ得る）を介してプロバイダネットワークにリンクさ
れ得る。これら２つの異なる種類のクライアントの構内は、配置先の選択肢「Ｄ」及び「
Ｅ」を備え、そのそれぞれが図１１にて用語が使用されている。いくつかの実施形態では
、ＳＭＳ及び／またはＳＰＳの一部は、また、第三者の構内（例えば、ＳＭＳ及び／また
はＳＰＳのクライアントによって使用されるが所有または管理されないデータセンタ）で
実装可能であってよく、このような第三者の構内は、配置先「Ｆ」として示され得る。少
なくともいくつかのクライアント及び／または第三者の構内においては、ＳＭＳ及び／ま
たはＳＰＳライブラリは、プロバイダネットワークから取得され、ＳＭＳ及び／またはＳ
ＰＳノードに使用されるホストにインストールされる必要があり得る。少なくとも一実施
形態においては、すべての異なる機能カテゴリのノードは、適切なライブラリの支援でプ
ロバイダネットワークの外部に実装され得る。
異なる実施形態においては、異なる配置先の種類は、ネットワーク隔離の特徴が実装され
、侵入検知の機能が支援され、物理セキュリティポリシが実装され、暗号化レベルが支援
されるなど、様々なセキュリティに関連する態様において、互いに異なり得る。したがっ
て、様々な配置の種類のそれぞれは、対応するセキュリティプロフィールを有すると考え
られてよく、これは１つ以上の方法で、その他の配置先のセキュリティプロフィールとは
異なることがある。いくつかの実施形態では、ＳＭＳ及び／またはＳＰＳのクライアント
は、異なるサブシステムまたはノードセットに対し、例えば、図１２ａ及び図１２ｂにて
示されているように、ＳＭＳまたはＳＰＳの１つ以上の制御ノードに要求を送信すること
によって、それぞれの配置先の種類をプログラムで選択し得る。注意が必要なのは、いく
つかの実施形態及びストリームアプリケーションの特定の種類においては、クライアント
は配置先の種類を、単にセキュリティの理由からではなく、性能及び／または機能性の理
由から制御したいと思う可能性があることである。例えば、前述のノイジーネイバー現象
は、専用のクライアントの設備のリソースまたはシングルテナントのインスタンスホスト
を使用することにより回避され得る。いくつかの実施形態では、クライアントは、ＳＰＳ
ステージまたはＳＭＳノードに使用を希望する専用または専有のハードウェア及び／また
はソフトウェアを有し得る。このようなコンポーネントを使用して達成可能な機能上の能
力または性能レベルは、プロバイダネットワークで容易に複製されることが不可能であり
、または単にプロバイダネットワークで支援されない。クライアントは外部のデータセン
タで、スーパーコンピュータレベルの処理能力を有するコンピュータサーバにアクセスし
得る。例えば、プロバイダネットワークのリソースのみを使用するときに可能な処理より
も、かなり高い速度でＳＰＳ処理を実行することが可能であり得る。クライアントが様々
なノードへの配置先を選択することを可能にすることで、このような専用装置または専用
ソフトウェアが使用できる。

図１２ａ及び図１２ｂは、少なくともいくつかの実施形態による、ＳＰＳクライアント
及びＳＭＳクライアントのそれぞれによって送信され得る、セキュリティオプションの要
求の実施例を示す。図１２ａは、ＳＰＳセキュリティオプションの要求１２００を示し、
識別子１２１０を備える１つ以上の処理ステージには、クライアントが、ステージ（要素
１２１２）の制御ノードに要求される配置先の種類（ＰＤＴ）、及びワーカノード（要素
１２１４）に要求されるＰＤＴを示す。少なくとも一実施形態においては、クライアント
もまた、ストリームデータレコードまたはストリーム処理結果に対する暗号化設定を構成
する要求を送信可能であり得る。例えば、様々なネットワークリンクにわたって伝送する
前に、特定のアルゴリズムまたはプロトコルを使用して暗号化されるデータレコードを要
求することにより、または様々な制御若しくは管理相互作用を暗号化することを要求する
ことにより、例えば、図１２ａでは、ステージに対する暗号化設定は、ステージ処理操作
の結果に適用される暗号化技術及び／またはステージの制御ノードとステージのワーカノ
ードとの間の通信に使用される暗号を示し得る。

同様に、図１２ｂにおいては、クライアントのＳＭＳのセキュリティオプション要求１
２５０は、特定の識別子１２５２を備える、１つ以上のストリームに対するクライアント
のセキュリティの基本設定を示すいくつかの要素を備える。取り込みノード、記憶ノード
及び検索ノードに対する配置先の種類の基本設定は、それぞれ要素１２５４、要素１２５
８及び要素１２６２に示され得る。取り込み制御ノード、記憶制御ノード及び検索制御ノ
ードに対するＰＤＴの基本設定は、それぞれ要素１２５６、要素１２６０及び要素１２６
４に示され得る。例えば、データレコードがあるノードのカテゴリから別のカテゴリへと
伝送されるときに、暗号がデータレコードに対して実行されるか否か、及び／またはどの
ように実行されるか、のようなデータレコードに対する暗号化の基本設定は、要素１２６
６を介して示され得る。図１２ａ及び図１２ｂに示されるようなセキュリティオプション
の要求を使用して、クライアントは位置（例えば、プロバイダネットワークの内部または
プロバイダネットワークの外部）及びストリーム管理及び処理環境の異なる部分に対する
、様々なその他のセキュリティプロフィールコンポーネントを選択可能であり得る。

ノードの配置先の選択は、少なくともいくつかの実施形態では、セキュリティよりもそ
の他の理由にあることに注意する。例えば、クライアントは、性能上の理由から（例えば
、主にセキュリティ上の理由よりもむしろ、前述の「ノイジーネイバー」の問題を避ける
ため）、シングルテナントのホストで実装される、いくつかの種類のＳＭＳまたはＳＰＳ
ノードを有することを要望し得る。配置の選択は、少なくともいくつかの実施形態では、
ストリームの耐用年数の間に変更され得る。例えば、クライアントは最初にＳＭＳノード
がマルチテナントのインスタンスホストでのインスタンス化を許可するが、後で、ノード
のサブセットの少なくともいくつかをシングルテナントのインスタンスホストに移動する
ことを要望する可能性がある。少なくともいくつかの実施形態では、異なる価格設定が異
なるセキュリティ関連のオプションに適用され得る。例えば、ＩＶＮの外部のマルチテナ
ントのインスタンスホストよりも、ＩＶＮでの特定の機能的カテゴリのＳＭＳノードを実
装する方が、費用がかかる可能性がある。またはマルチテナントのインスタンスホストで
するよりも、シングルテナントのインスタンスホストでＳＭＳノードを実装する方が、費
用がかかる可能性がある。

ストリームレコードのシーケンシャル記憶及びシーケンシャル検索
多くの種類のストリームアプリケーションには、データレコードが複数のデータ生成部
１２０から高速でＳＭＳで受信されてよく、データコンシューマは、典型的には、レコー
ドが生成された順番に、記憶されたデータレコードにアクセスすることを希望し得る。特
に、前述したように、回転磁気ディスクがストリームデータレコードに記憶装置として使
用される環境においては、シーケンシャルＩ／Ｏアクセスパターン（読み出し及び書き込
み）は、ランダムＩ／Ｏアクセスパターンに優る著しい性能面での利点を有し得る。いく
つかの実施形態では、ストリーム固有またはパーティション固有のシーケンス番号は、Ｓ
ＭＳによって受信されたときに、データレコードを割り当てられ得る。シーケンス番号に
基づいたシーケンシャル検索操作が支援され得る。図１３ａは、少なくともいくつかの実
施形態による、ストリームデータ生成部とＳＭＳの取り込みサブシステムとの間の相互作
用例を示す。ストリームデータ生成部は、データレコード１１０を取り込みサブシステム
に送信してよく、図示された実施形態においては、取り込みサブシステムは、送信された
レコード用に選択されたシーケンス番号１０２に応答してよい。少なくともいくつかの実
施形態においては、取り込みノードは記憶サブシステムからシーケンス番号の一部を取得
し得る。例えば、シーケンス番号１０２は、このような実施形態における、適用可能な永
続性ポリシによる、受信されたデータレコードが記憶された後で決定され得る。また、記
憶サブシステムは、データレコードに対し、自身の数列インジケータを生成してよく、取
り込みノードによってデータレコードに割り当てられる、より大きなシーケンス番号に含
めるために、そのインジケータを提供してよい。

シーケンス番号は、様々な実施形態において、安定的で一貫性のあるデータレコードの
順序を提供するため、また、データコンュシーマによってレコード上で繰り返し反復する
ことを可能にするために、実装され得る。少なくともいくつかの実装においては連続であ
る必要はないが、特定のパーティションのデータレコードに割り当てられたシーケンス番
号は、時間とともに単調増加し得る。様々な実施形態では、シーケンス番号は以下のセマ
ンティックスの少なくともいくつかのサブセットに割り当てられ得る。（ａ）シーケンス
番号はストリーム内で固有である。すなわち、所与のストリームの２つのデータレコード
は同一のシーケンス番号に割り当てられる可能性はない。（ｂ）シーケンス番号は、スト
リームのデータレコードに索引付けとして機能し得る。また、所与のストリームパーティ
ション内のデータレコード内を繰り返して使用され得る。（ｃ）任意の所与のデータ生成
部には、データ生成部が正常にデータレコードを送信する順序は、データレコードに割り
当てられたシーケンス番号に反映される。及び（ｄ）所与のパーティションキー値を有す
るデータレコードにシーケンス番号の付与は、動的再分割操作にわたって、セマンティッ
クの単調増加を維持する。例えば、再分割後にパーティションキー値Ｋ１を有するデータ
レコードに割り当てられたシーケンス番号は、任意のシーケンス番号よりもそれぞれが大
きくてよく、このシーケンス番号は、動的再分割の前にそのパーティションキー値Ｋ１を
有するデータレコードに割り当てられている。（動的再分割は図１６を参照して下記にさ
らに詳細が記載されている。）

いくつかの実施形態では、データ生成部は少なくともいくつかのデータレコードに選択
されたシーケンス番号１０２の選択に影響したい可能性がある。例えば、そのストリーム
のデータコンシューマにとって、ストリームの特定のサブセットを対象とする読み出し要
求を送信することをより容易にするために、データ生成部１２０は、境界または割り当て
られたストリームのシーケンス番号内のセパレータを画定したいかもしれない。いくつか
の実装においては、データ生成部１２０は、最小のシーケンス番号の表示をレコードとと
もに送信してよく、また、ＳＭＳは、上述したシーケンス番号のセマンティックにも従う
、要求最小によるシーケンス番号を選択してよい。

図１３ｂは、少なくともいくつかの実施形態による、ＳＭＳでの取り込まれたデータレ
コードのために生成され得るシーケンス番号の要素例を示す。図示された実施形態におい
ては、シーケンス番号は４つの要素、ｎ１−ビットＳＭＳバージョン番号１３０２、ｎ２
−ビットタイムスタンプまたはエポック値１３０４、ｎ３−ビットサブシーケンス番号１
３０６及びｎ４−ビットパーティション番号１３０８、を含み得る。いくつかの実装にお
いては、１２８ビットのシーケンス番号が使用されてよく、例えば、ｎ１、ｎ２、ｎ３及
びｎ４は、それぞれ、４、４４、６４及び１６ビットであり得る。バージョン番号１３０
２は、例えば、ＳＭＳソフトウェアのどのバージョンがシーケンス番号を生成するために
使用されたのか区別を容易にするために、単にＳＭＳソフトウェアバージョンのロールア
ウトを、混乱を避けるために使用され得る。バージョン番号１３０２は、少なくともいく
つかの態様において変更が頻繁に行われることを想定していない。タイムスタンプ値１３
０４は、例えば、取り込みサブシステムノードによってローカルクロックソースまたはグ
ローバルにアクセス可能なクロックソース（例えば、ｇｅｔＣｕｒｒｅｎｔＥｐｏｃｈま
たはｇｅｔＣｕｒｒｅｎｔＴｉｍｅ ＡＰＩを実装するプロバイダネットワークの状態管
理システム）から取得され得る。少なくともいくつかの実装においては、時間においてよ
く知られたポイントからのオフセットは、（例えば、１９７０年１月１日の協定世界時０
０：００：００から経過した秒数であり、Ｕｎｉｘ（登録商標）ベースのオペレーティン
グシステムで、様々な時間に関連したシステムコールによって得ることができる）タイム
スタンプ値１３０４に使用され得る。いくつかの実施形態では、サブシーケンス番号１０
３６は、記憶サブシステムによって生成されてよく、特定のパーティションのデータレコ
ードが記憶装置に書き込まれる順を示してよい。このように、多数のデータレコードが所
与の秒内に受信され、タイムスタンプ値１３０４が約１秒から２秒の間隔でのみ変更する
実装においては、サブシーケンス番号１３０６は、たまたま同一の秒内に到着し、そのた
め同一のタイムスタンプ値の割り当てられるデータレコードに対し、レコードが到着（ま
たは記憶）する順のインジケータとしての役割をしてよい。いくつかの実施形態では、パ
ーティション番号１３０８は、所与のストリーム内のパーティションを固有に識別し得る
。対応するデータレコードが取り込まれるシーケンス番号のタイムスタンプが（少なくと
もほぼ）クロックタイムを示す少なくともいくつかの実装においては、シーケンス番号が
特定の種類の時間ベースの検索要求のためのインデックス機構に使用され得る。例えば、
クライアントは、特定の日または特定の時間範囲の間に生成され取り込まれたストリーム
レコードを検索することを希望し、シーケンス番号はデータレコードの適切なセットを検
索する暗黙の二次インデックスのキーとして使用され得る。このように、少なくともいく
つかの実施形態においては、並べられた記憶及び検索に対するタイムスタンプを含むシー
ケンス番号の使用は、時間的なインデックスを格納されたデータレコードのセットに提供
する追加の利点を有し得る。

所与のパーティションのデータレコードは、典型的には、シーケンス番号順に（例えば
、ディスクに）書き込まれ、しばしば大規模な連続的な書き込み操作を使用して書き込ま
れる。いくつかの実施形態では、前述したように、イテレータベースのプログラムによる
インタフェースは、データコンシューマがシーケンス番号順にデータレコードを読み込む
ことができるように実装され得る。図１４は、少なくともいくつかの実施形態による、Ｓ
ＭＳでのストリームデータレコードを順番に並べられた記憶及び検索する実施例を示す。
パーティションＳｊ〜Ｐｋ（ストリームＳｊのｋ番目のパーティション）の、６つのデー
タレコード１１０Ａ〜１１０Ｆがシーケンス番号順に格納されていることを示す。図示さ
れているように、シーケンス番号は少なくともいくつかの実施形態において、連続してい
ない場合がある。例えば、値がタイムスタンプ部１３０４に割り当てられる手法か、また
は上述したサブシーケンス番号１３０６は、それらの要素に対して必ずしも連続値になる
とは限らないからである。

図１４に示された実施例においては、データコンシューマは、イテレータが作成するよ
う要求し、シーケンス番号「８６５」での開始を明示する。要求に対して、ＳＭＳは、イ
テレータ１を初期化し、要求された開始シーケンス番号よりも大きいか等しい、最も近い
シーケンス番号でデータレコードに配置する。この場合、シーケンス番号８７０のデータ
レコード１１０Ｃは、イテレータの開始位置として選択されており、次のより低いシーケ
ンス（データレコード１１０Ｂに割り当てられた８６０）は、コンシューマの要求におけ
る開始シーケンス番号よりも小さい。このｇｅｔＩｔｅｒａｔｏｒインタフェースは、パ
ーティション内の要求された位置でカーソルを設定するための要求の論理等価として考え
られ、ｇｅｔＮｅｘｔＲｅｃｏｒｄインタフェースは、次に、例えばシーケンス番号順に
ストリームに沿ってカーソルを移動するために、カーソルの位置から始まるデータレコー
ドを読み出すために使用され得る。図示された実施例では、データコンシューマはｇｅｔ
ＮｅｘｔＲｅｃｏｒｄインタフェースを“ｉｔｅｒａｔｏｒ”のセットをＩｔｅｒａｔｏ
ｒ１に、“ｍａｘＮｕｍＲｅｃｏｒｄｓ”（データレコードを返す最大数）のセットを３
にするパラメータで起動する。したがって、ＳＭＳ検索サブシステムは、データレコード
１１０Ｃ，データレコード１１０Ｄ及びデータレコード１１０Ｅをその順でデータコンシ
ューマに返す。イテレータのＩｔｅｒａｔｏｒ１は、例えば、データレコード１１０Ｆの
ような、新しい位置に移動され、ｇｅｔＮｅｘｔＲｅｃｏｒｄが完了を宣言した後、次に
同一のイテレータに対するｇｅｔＮｅｘｔＲｅｃｏｒｄの起動は１１０Ｆで始まるデータ
レコードを返し得る。ｇｅｔＩｔｅｒａｔｏｒの宣言のセマンティックスはいくつかの実
施形態において異なり得る。例えば、特定のシーケンス番号よりも大きいか等しい、最も
近いシーケンス番号でデータレコードでイテレータを配置する。イテレータは、いくつか
の実施形態で、要求されたシーケンス番号と等しいかまたは低い最も近いデータレコード
に配置され得る。別の実施形態では、クライアントはｇｅｔＩｔｅｒａｔｏｒの呼び出し
における現在のシーケンス番号を特定しなければならない可能性がある。例えば、要求さ
れたシーケンス番号がストリーム中に存在しない場合、エラーが返され得る。

パーティションマッピング
前述したように、様々なパーティション及び再分割ポリシによる様々な実施形態におい
ては、所与のストリームのレコードの取り込み、記憶、検索及び処理に関するワークロー
ドは、細分化され、いくつかのノードに分散される。図１５は、少なくともいくつかの実
施形態による、ＳＭＳノード及びＳＰＳノードのために作成され得るストリームパーティ
ションマッピング１５０１及び対応する構成決定の実施例を示す。例えばクライアントに
よるｃｒｅａｔｅＳｔｒｅａｍ ＡＰＩの起動に対応して、特定のデータストリームが作
成されるか初期化されるとき、パーティショニングポリシはストリームのために有効にさ
れ、ストリームの任意の所与のデータレコードがメンバと考えられるか、パーティション
を決定するために使用され得る。所与のデータレコードに対して操作を実行する、取り込
みサブシステム２０４、記憶サブシステム２０６、検索サブシステム２０８及び任意の関
連するＳＰＳステージ２１５の特定のノードは、レコードのパーティションを基準にして
選択され得る。一実施形態では、所与のデータレコードに使用される少なくとも制御ノー
ドのサブセットは、パーティションにも基づいて選択され得る。少なくともいくつかの実
施形態においては、データレコードの動的再分割は、例えば、ポリシに示されたトリガ条
件または明示的な要求に対応して、パーティションポリシの一部として支援され得る。

様々な実施形態では、所与のデータレコードに選択されたパーティションは、レコード
に対しては、パーティションキーに依存し、その値はデータ生成部によって直接（例えば
、パラメータの書き込みまたは要求として）または間接的（例えば、ＳＭＳは、データ生
成部のクライアントの識別子若しくは名前、データ生成部のＩＰアドレス、またはパーテ
ィションキーとしてデータレコードの実際のコンテンツの一部のようなメタデータを使用
し得る）の何れかで供給され得る。１つ以上のマッピングの機能１５０６は、図１５に示
された実施形態のデータレコードのパーティション識別子１５１０を決定するために、デ
ータレコードのパーティションキーまたは属性１５０２に適用されてよい。一実装におい
ては、例えば、所与のパーティション識別子１５１０は、１２８ビットの整数値のスペー
スの連続した範囲にわたって、表し得る。ストリームのすべてのパーティションに対する
範囲のユニオンが、１２８ビットの整数値が仮定する、すべての可能な値をカバーし得る
。このような例示的な場合においては、１つの単純なマッピング機能１５０６は、データ
レコードのパーティションキー値（単数または複数）から１２８ビットのハッシュ値を生
成するか、データレコードの属性値を選択されてよく、パーティションの識別子は、ハッ
シュ値がある特定の隣接する範囲に基づいて決定され得る。いくつかの実装においては、
隣接する範囲は、少なくとも最初はサイズが等しく、その他の実装では、異なるパーティ
ションは、互いにサイズが異なり得る隣接する範囲に対応する。再分割は、また、１つの
実装において範囲の境界を調整する結果となり得る。その他のパーティション機能１０６
は、異なる実装で使用され得る。

データストリームが（さらに詳細に下記に記載されているように）動的再分割された場
合、特定のキーを有するレコードがマップされるパーティションは変更し得る。したがっ
て、少なくともいくつかの実施形態においては、ＳＭＳ及び／またはＳＰＳ制御ノードは
、ストリームの耐用年数の間、ストリームに適用する、いくつかの異なるマッピングを把
握する必要がある。いくつかの実施形態では、タイムスタンプの有効性の範囲１５１１の
ようなメタデータまたはシーケンス番号の有効性の範囲は、各パーティションマッピング
に制御ノードによって格納され得る。タイムスタンプの有効性の範囲１５１１は、例えば
、特定のマッピングＭ１は、ストリームの作成時間から時間Ｔ１までを適用し、異なるマ
ッピングＭ２はＴ１からＴ２等に適用することを表し得る。ストリームに向けられた読み
出し要求に応答して、検索ノードは、どのマッピングが（例えば読み出し要求に示された
シーケンス番号に基づいて）使用され、次にそのマッピングを適切な記憶ノードを識別す
るために使用する。

少なくともいくつかの実施形態では、ＳＭＳ制御ノード及びＳＰＳ制御ノードは、いく
つかの異なる粒度でパーティションをリソースにマッピングする役割をし得る。例えば、
図１５の例示的な実装１５９９に示されているように、１つの実装、各取り込み、記憶、
検索または処理（ワーカ）ノードは、実装され得る。サーバ仮想マシン内でそれぞれの処
理、または実行のそれぞれのスレッドとしてＪａｖａ（登録商標）仮想マシン（ＪＶＭ）
またはコンピュートインスタンス、及び各ＪＶＭまたはコンピュートインスタンスは特定
の物理ホストでインスタンス化され得る。いくつかの実施形態では、多数のＪＶＭは、単
一のコンピュートインスタンス内で起動されてよく、リソースのマッピング決定の別の層
を加える。したがって、所与のパーティションには、１つ以上の制御ノードが、どの特定
のリソースが取り込みノード１５１５、記憶ノード１５２０、検索ノード１５２５または
処理ステージワーカノード１５３０（例えば、ステージＰＳ１またはステージＰＳ２に対
してそれぞれ、ノード１５３０Ａまたはノード１５３０Ｂ）として使用されるべきか、選
択し得る。制御ノードは、また、それらのノードをサーバ（取り込みサーバ１５３５，ス
トレージサーバ１５４０，検索サーバ１５４５または処理サーバ１５５０のように）にマ
ッピングすること、及びサーバとホスト（取り込みホスト１５５５、ストレージホスト１
５６０、検索ホスト１５６５またはＳＰＳホスト１５７０Ａ／ホスト１５７０Ｂ）との間
をマッピングすることを決定し得る。いくつかの実装においては、パーティションマッピ
ングは、示されている様々なリソースの粒度（例えば、ノード、サーバ及びホスト粒度）
のそれぞれに、識別情報（例えば、リソースの識別子）を含むと考えられ得る。機能１５
０６自身と同様に、機能１５０６への入力として使用されるデータレコードの属性の表示
が使用される。制御サーバは、メタデータ記憶にてパーティションマッピングの表示を記
憶し得る。いくつかの実施形態では、（ｇｅｔＰａｒｔｉｔｉｏｎＩｎｆｏＡＰＩのよう
な）様々なＡＰＩまたはその他のプログラムによるインタフェースを暴露して、データ生
成部、データコンシューマまたはＳＭＳサブシステムのノードまたはＳＰＳにマッピング
の情報を提供し得る。

データレコードをパーティションにマッピングすること、及びパーティションからリソ
ースにマッピングすることは、（ａ）所与のノード、サーバまたはホストは、いくつかの
実施形態において、多数のパーティションの役割をするよう設計され得る、または（ｂ）
破損またはその他のトリガは、所与のパーティションまたはパーティションのセットに割
り当てられた新しいノード、サーバまたはホストがもたらされる可能性があるというよう
な、様々な要因からさらにいくつかの実施形態においては複雑になり得る。加えて、上記
に示したように、また下記に記載するように、所与のストリームに対するパーティション
マッピングは、ストリームレコードがＳＭＳノード及び／またはＳＰＳノードによって処
理され続ける一方、時間の経過とともに動的に修正され得る。その結果、マッピングのメ
タデータのいくつかのバージョンは、いくつかの実施形態においては、少なくとも一時的
に所与のストリームに保持されるため、それぞれは異なる時間にそれぞれ対応し得る。

動的ストリームの再分割
図１６は、少なくともいくつかの実施形態による、動的ストリームの再分割の実施例を
示す。図１６に示された時系列の時間Ｔ１で、ストリームＳ１が作成されるか初期化され
る。パーティションマッピングＰＭ１は、ストリームＳ１のために作成され、時間間隔Ｔ
１からＴ２の間に有効を維持する。Ｔ１とＴ２との間のＳＭＳによって受信された３つの
データレコードは、一例として示されている。データレコード１１０Ａ（ＤＲ１１０Ａ）
は、クライアントが供給するパーティションキー値「Ａｌｉｃｅ」とともに送信され、Ｄ
Ｒ１１０Ｂはクライアントが供給するパーティションキー値「Ｂｉｌｌ」とともに送信さ
れ、ＤＲ１１０Ｃは、クライアントが供給するパーティションキー値「Ｃｈａｒｌｉｅ」
とともに送信される。初期のマッピングＰＭ１において、すべての３つのデータレコード
１１０Ａ、データレコード１１０Ｂ及びデータレコード１１０Ｃは、パーティション識別
子「Ｐ１」を備える同一のパーティションにマッピングされる。Ｐ１データレコードには
、単一のノードＩ１が取り込みを処理するために構成され、単一のノードＳ１は、記憶装
置を処理するために構成され、単一のノードＲ１は、検索を処理するために構成され、及
び単一のワーカノードＷ１は、ＳＰＳ処理を行うために構成される。ＰＭ１をマッピング
する有効な範囲の開始のタイムスタンプはＴ１に設定されている。

時間Ｔ２、ストリームＳ１は、図１６の例示的な時系列において動的に再分割される。
図示された実施形態において、データレコードは継続して到着し、ＳＭＳ及びＳＰＳによ
って処理される。再分割がいつ起こるのかに関係なく、ＳＭＳまたはＳＰＳの何れもオフ
ラインにする必要はない。例えば、取り込み、記憶、検索または処理ノードにおいてオー
バーロード状態の検出に対応して、様々なサブシステムの異なるホストでのワークロード
レベル間のずれ、または不均衡の検出に対応して、またはデータコンシューマ若しくはデ
ータ生成部からの要求に対応して、再分割はいくつかの要因のいずれかの結果として開始
され得る。図示された実施形態において、ＰＭ２に示された有効範囲の開始タイムスタン
プの設定によって示されるように、新しいマッピングＰＭ２は、時間Ｔ２（またはＴ２の
直後）で影響を及ぼす。少なくともいくつかの実装においては、データレコードの属性の
異なるセットは、再分割の前に使用されたよりもデータレコードの分割に使用され得る。
場合によっては、追加の分割の属性は、（例えば、ＳＭＳの要求で）データ生成部によっ
て送信され得る。一方、その他の場合では、追加の属性はＳＭＳ取り込みノードによって
生成され得る。このような追加の属性は「塩漬けされた」属性と称され得る。再分割に追
加の属性を使用する技術は、「塩漬けする」と称され得る。一例示的な実装においては、
オーバーロードした取り込みサーバは、データ生成部（例えば、データ生成部によって実
行されるＳＭＳクライアントライブラリコード）に示してよく、再分割には、無作為に選
択された小整数値が以前に使用されたパーティションキーに加えて提供される。元のパー
ティションキーと塩漬けされた追加の整数との組み合わせは、その後に、取り込みノード
の異なるセットに取り込みワークロードを分散するために使用され得る。いくつかの実施
形態では、検索ノード及び／またはデータコンシューマは、再分割に使用される追加の属
性に関して通知される必要があり得る。このような追加の属性は、少なくともいくつかの
実装において、再分割に使用されなくてよい。

図１６に示す実施形態では、Ｔ２前の同一のキーのために選択されたパーティションに
対して、新しいパーティションマッピングは、Ｔ２の後に受信されたデータレコードの少
なくともいくつかのために選択された、異なるパーティションの結果になる。ＤＲ１１０
Ｐは、パーティションキー値「Ａｌｉｃｅ」でＴ２の後に送信され、ＤＲ１１０Ｑは、パ
ーティションキー値「Ｂｉｌｌ」でＴ２の後に送信され、ＤＲ１１０Ｒは、パーティショ
ンキー値「Ｃｈａｒｌｉｅ」でＴ２の後に送信される。図示された場合においては、ＰＭ
２のマッピングを使用して、ＤＲ１１０Ｐは、パーティション「Ｐ４」のメンバに指定さ
れ、ＤＲ１１０Ｑは、パーティション「Ｐ５」のメンバに指定され、一方、ＤＲ１１０Ｒ
は、パーティション「Ｐ６」のメンバに指定される。図示された実施形態において、Ｔ２
の後の受信として示される、例示的なデータレコードの何れも、以前に使用されたパーテ
ィションの「Ｐ１」のメンバとして指定されない。その代わりに、完全に新しいパーティ
ションが、再分割後に使用され得る。いくつかの実施形態では、少なくともいくつかの以
前に使用されたパーティションが再分割後に使用され続けてよい。新しいパーティション
のＰ４、Ｐ５及びＰ６のそれぞれには、異なるノードが取り込み、記憶、検索及び／また
は処理に指定され得る。例えば、ノードＩ４、ノードＳ４、ノードＲ４及びノードＷ４は
、パーティションＰ４に構成されてよく、ノードＩ５、ノードＳ５、ノードＲ５及びノー
ドＰ５は、パーティションＰ５に構成されてよく、ノードＩ６、ノードＳ６、ノードＲ６
及びノードＰ６は、パーティションＰ６に構成されてよい。いくつかの実施形態では、同
一の記憶ノードは、再分割前のこのようなレコードに使用されたように、再分割後の特定
のパーティションキーまたは属性を備えるレコードに使用され得る。しかしながら、その
ノード（例えば、異なるディスク、異なるディスクパーティションまたは異なるＳＳＤ）
内の異なる記憶位置は、再分割後に使用され得る。

Ｔ２での動的再分割後、少なくともある時間、検索要求は、再分割の前にＳＭＳ取り込
み及び／または記憶サブシステムによって処理された、データレコードのために、継続し
て検索されてよい。少なくともいくつかの場合においては、要求されたデータレコードは
、データレコードが取り込まれた時に有効である、ＰＭ１マッピングに基づいて検索され
る必要があり得る。したがって、図１６に示されたように、データ検索の目的で、ＰＭ１
及びＰＭ２の両方は、Ｔ２の後のある時点で継続して使用され得る。少なくともいくつか
の実装においては、データレコードは、古くなるにつれて、ストリームから最終的に削除
され、より古いパーティションマッピングは、また、最終的に破棄され得る。例えば、す
べての対応するデータレコード自体が削除される。いくつかの実施形態では、削除される
代わりに（または削除の前に）、ストリームレコードは、ＳＭＳによって使用されるパー
ティションマッピングは、アーカイブの後、レコードを検索することが依然として不可能
なように、記憶位置または記憶装置の異なるセットに、（例えば、クライアントが選択し
たアーカイブポリシに基づいて）アーカイブされ得る。このような実施形態においては、
アーカイブストレージに向けられた検索要求を支援する必要がある限り、ＰＭ１及びＰＭ
２のようなパーティションマッピングは保持され得る。いくつかのアーカイブの実装にお
いては、ストリームパーティションマッピングが保持される必要のない、異なる検索手法
が使用され得る（例えば、新しいインデックスがアーカイブされたデータレコードのため
に作成され得る）。いくつかの実施形態では、再分割の前に使用されたが、再分割の後、
書き込みがもはや指示されない、Ｐ２のようなパーティションは、再分割の後ある時点で
読み込みのために「閉じられ」得る。例えば、「パーティションの最後に達しました」と
いうエラーメッセージの等価は検索要求に対して提供され得る。

いくつかの実装においては、所与のデータストリームは、多数（例えば、何十万）のパ
ーティションに分かれ得る。ストリームＳ１が初めに１０００のパーティションのＰ１，
Ｐ２，・・・，Ｐ１０００に分かれる例示的な場合を考える。１つのパーティション、例
えばＰ７に対応するオーバーロード状態が検出される場合、データレコードＰ７を初期の
マッピングを変更することは価値があり得るが、その他のパーティションのマッピングは
、変更される必要はない。１つの手法においては、２つの新しいパーティションＰ１００
１及びＰ１００２が、再分割操作を介して作成され得る。その属性が元々、（すなわち、
元のマッピングを基準として）Ｐ７におけるメンバの結果となる再分割後に受信されたレ
コードは、再分割後、つまり、２つのパーティションのうち、Ｐ７のワークロードを分配
した後、Ｐ１００１またはＰ１００２のいずれかにマッピングされ得る。残余のパーティ
ション、例えばＰ１〜Ｐ６及びＰ８〜Ｐ１０００は、修正される必要はなくてよい。小さ
なパーティションのサブセットのみがこのような再分割によって影響を受けるため、少な
くともいくつかの実施形態では、パーティション入力（またはパーティション入力のツリ
ー）の有向非巡回グラフのような組み合わされたデータ構造が、生成され、格納され得る
。各入力は、パーティション機能の出力範囲と、有効な時間範囲（入力のパーティション
情報が有効である時間）を示し得る。前述の例では、Ｐ７を含む再分割は、時間Ｔ２で実
行された。一方、ストリームＳ１（及びその初期のマッピング）は時間Ｔ１で作られる。
このような場合においては、Ｐ７に関する入力の有効な時間は「Ｔ１からＴ２」であり、
Ｐ１００１及びＰ１００２の有効な時間は「Ｔ２以降」、及び残りのパーティションの有
効な時間は、「Ｔ１以降」であろう。このような組み合わされたデータ構造の使用は、少
なくともいくつかの実装における、パーティションマッピングのメタデータに使用される
、メモリまたはストレージに実質的な減少につながり得る。上記の例では、パーティショ
ンＰ７を２つの新しいパーティションに分けることが記載されていた。少なくともいくつ
かの実装においては、パーティションはまた、再分割をする間にマージされ得る。例えば
、比較的少ない検索要求が受信され、または比較的少ないレコードが送信された、２つの
隣接したパーティションは、単一のパーティションにマージされ得る。任意の所与の時点
では、データレコードが属するパーティションは、パーティションの機能及び有効な時間
範囲の情報を使用して、明確に決定され得る。時間の経過とともに、組み合わされたデー
タ構造は、より多くの分割及び／またはマージが実行されながら発展し得るが、メタデー
タを分割するために必要な全空間は、急激に増加し得ない（分割の頻度、分割によって影
響を受けるパーティションの平均数）。対照的に、異なる実施形態では、再分割が起こる
たびに、ストリームのための変更されていないメタデータのセットの全体が、複製され、
再分割の影響を受けたパーティションのための入力とセットで組み合わされ得る。パーテ
ィションマッピングのメタデータのためのストレージ及びメモリの要求は、後の実装にお
いては、さらに速い速度で増加し得る。特に以前のマッピングが上記のように、再分割後
の少なくともある時点で、保持される必要があり得る。

タイムスタンプ値（図１３ｂに示されたタイムスタンプ値１３０４のような）を含むシ
ーケンス番号が使用される、少なくともいくつかの実施形態では、シーケンス番号の推移
の特定の種類は、動的再分割のために実装され得る。図１３ｂに示されているのと同様に
、タイムスタンプベースのシーケンス番号のスキームがストリームＳ１に使用される一例
として考えると、新しいタイムスタンプ値が常にシーケンス番号で生成される動的再分割
が支援される少なくともいくつかの実装においては、動的再分割後割り当てられたシーケ
ンス番号は、（再分割に対応して、選択された初期のタイムスタンプ値から始まる）動的
再分割前に使用されるものと異なるタイムスタンプ値のセットをすべて使用し得る。例え
ば、動的再分割がコミットする（すなわち、有効になる）時間で使用されるタイムスタン
プ値がＴｋであった場合には、コミット後に発行される新しいシーケンス番号は、Ｔｋ＋
１以降のタイムスタンプ値を使用する必要があり得る。シーケンス番号値が、図１３ｂに
使用されるスキームにおける少なくともいくつかの上位ビットをタイムスタンプ値を符号
化するため、記載されたように、タイムスタンプの境界に対応する再分割のイベントは、
順次、検索要求に対応して使用されるマッピングの識別に関する記帳を簡素化し得ること
を確実にする。したがって、このような実装においては、特定のシーケンス番号を特定す
る検索要求が受信されると、タイムスタンプ値がシーケンス番号から抽出されてよく、再
分割後のマッピングが使用されるべきか、または再分割前のマッピングが使用されるべき
かを容易に判断され得る。抽出されたタイムスタンプ値が、再分割のために選択された初
期のタイムスタンプよりも低い場合には、再分割前のマッピングが使用されてよく、抽出
されたタイムスタンプ値が再分割に選択された初期のタイムスタンプ値に等しいかまたは
高い場合には、再分割後のマッピングが使用され得る。

ストリームの管理及び処理の方法
図１７は、少なくともいくつかの実施形態による、ストリームレコードの取り込み及び
ストリームレコードの検索用のプログラムによるインタフェースのそれぞれのセットを支
援するために実行され得る、操作の態様を示すフローチャートである。要素１７０１に示
されているように、例えば、ＳＭＳのクライアントまたはデータ生成部のクライアントか
ら、データストリームを作成するか初期化する要求が受信され得る。ストリームに使用さ
れる初期のパーティションマッピングは、決定され得る（要素１７０４）。例えば、特定
のデータレコードが属するパーティションを識別するのに使用される機能（単数または複
数）、及び機能（単数または複数）に使用される入力パラメータは、パーティションポリ
シに基づいて識別され得る。前述のように、ＳＭＳの制御コンポーネントは、様々な実施
形態で、ストリームの作成要求を受信し、応答する役割をし得る。ストリームの作成及び
初期化が実行される方法（その他の制御プレーン操作と同様に）は、一実施形態から別の
実施形態によって異なり得る。一実施形態では、例えば、制御サーバの冗長グループが確
立されてよく、その冗長グループのプライマリ制御サーバは、（例えば、初期パーティシ
ョンマッピング、取り込みノード、記憶ノード及び検索ノード等の初期のセット）新しい
ストリームのために、永続性記憶位置に、適切なメタデータを生成し格納することによっ
て、ストリーム作成要求に応答してよい。ストリームに関する次のクエリに対する応答（
例えば、所与のパーティションの役割をするバックエンドノードに関するフロントエンド
の取り込みノードからの要求）は、格納されたメタデータを使用するプライマリ制御サー
バによって生成され得る。ＳＭＳ制御プレーンの機能の別の実装では、ストリーム構成の
メタデータは、取り込みサブシステム、記憶サブシステムまたは検索サブシステムの少な
くともいくつかのノードによって直接アクセス可能なデータベースに格納され得る。スト
リームが作成し初期化された後、典型的には制御コンポーネントと追加の相互作用をせず
に、レコードの送信、記憶及び検索のようなデータプレーンが開始してよく、対応するサ
ブシステムのそれぞれのコンポーネントによって処理されてよい。

いくつかの実施形態では、データ生成部は書き込み要求を有する明示的なパーティショ
ンキーを送信する必要はなくてよい。一方、その他の実施形態においては、パーティショ
ン機能に使用される入力は、データ生成部の識別、データレコードが受信されるＩＰアド
レス、またはデータレコード自身のコンテンツからのような、書き込み要求に関連するメ
タデータに基づいて決定され得る。少なくとも一実装においては、クライアントは所望に
より、データレコードの送信におけるパーティションの識別子を供給し、追加のパーティ
ション機能は、このような実装にいて必要とされなくてよい。

ストリームのための取り込み機能、記憶機能及び検索機能用のノードの初期セットを決
定または構成するとき、いくつかの異なる要素が考慮に入れられ得る（要素１７０７）。
例えば、（ストリームが分けられるパーティションの数及びパーティションの関連する予
想サイズを決定し得る）パーティションマッピング自体、このような情報が入手可能な場
合には予想される取り込み率及び／または検索率に関する情報、ストリームデータレコー
ドのための耐久性／永続性の要件、及び／または（図９及び図１０に示されたものと類似
の冗長グループの設定になり得る）様々なサブシステムのための高可用性の要件は、異な
るサブシステムのノードの数と配置に影響し得る。加えて、クライアントが、（図１１、
図１２ａ及び図１２ｂに示されるように）様々なカテゴリのノードに対して配置先種類の
基本設定を示し得る実施形態においては、このような基本設定は、また、ＳＭＳ及び／ま
たはＳＰＳノードに使用されるリソースを決定する上で役割をし得る。少なくともいくつ
かの実施形態においては、取り込み、記憶及び／または検索機能の実行が可能なノードの
それぞれのプールは、前もって設定され、制御コンポーネントは、作成される新しいスト
リームのそれぞれにこのようなプールの選択されたメンバを割り当て得る。その他の実施
形態では、少なくともいくつかの場合においては、新しい取り込みノード、記憶ノードま
たは検索ノードは、ストリームが作成または初期化されるときにインスタンス化される必
要があり得る。

図示された実施形態における取り込みノードでは、レコードは、例えば、（データは送
信要求に含まれている）インラインの送信インタフェースを含む、データレコードの送信
（要素１７１０）のために実装されたプログラムによるインタフェースのセットのいずれ
かを介して受信され、参照によるバイリファレンス送信インタフェース（アドレスが送信
要求に提供され、たとえば、ウェブサービス要求またはその他のインタフェースを使用し
てデータがＳＭＳ取り込みノードまたはＳＭＳ記憶ノードによって検索され得る。）いく
つかの異なる種類のプログラムによるインタフェースのいずれかは、レコードを送信する
方法のそれぞれに、異なる実施形態に提供され得る。例えば、それぞれのアプリケーショ
ンプログラミングインタフェース（ＡＰＩ）は、インライン対バイリファレンス送信のた
めに支援され得る。ウェブページまたはウェブサイトは確立され、グラフィカルユーザイ
ンターフェースが実装され、またはコマンドラインツールが開発され得る。少なくともい
くつかの実施形態においては、ＳＭＳは各取り込みレコードにシーケンス番号を割り当て
得る。例えば、レコードが取り込みまたは格納される順に表示し、シーケンス番号はデー
タコンシューマによって検索要求に使用可能であり得る。検索サブシステムノードでは、
レコード検索要求は、実装されたプログラムによる検索インタフェースの任意のセットを
介して受信され、要求されたデータレコードのコンテンツは、応答（要素１７１３）に提
供され得る。非シーケンシャルなアクセスには、例えばインタフェースは、（ｇｅｔＩｔ
ｅｒａｔｏｒの起動で示されたシーケンス番号に基づいて、イテレータがパーティション
内で選択された位置でインスタンス化されるように要求する）ｇｅｔＩｔｅｒａｔｏｒま
たは（特定のシーケンス番号を備えたデータレコードを取得するための）ｇｅｔＲｅｃｏ
ｒｄＷｉｔｈＳｅｑｕｅｎｃｅＮｕｍｂｅｒを含み得る。シーケンシャルなアクセスには
、（イテレータの現在位置から始まる順、または特定のシーケンス番号から始まる順に、
いくつかのレコードを要求する）ｇｅｔＮｅｘｔＲｅｃｏｒｄのようなインタフェースが
実装され得る。少なくともいくつかの実施形態においては、異なる検索インタフェースは
、それに関連する異なる課金率を有し得る。例えば、シーケンシャル検索のためのレコー
ド課金毎の率は、非シーケンシャル検索に対するレコード毎の課金率より低く設定され得
る。異なる送信インタフェースは、またいくつかの実施形態において、異なる課金率を有
し得る。例えば、バイリファレンス送信は、インライン送信よりもレコード毎の費用がよ
りかかり得る。

時間の経過とともに、制御ノードまたは特定の課金サーバは、ストリーム管理サービス
（要素１７１６）の様々なサブシステムで実装される異なるプログラムによるインタフェ
ースに対する使用メトリクスを収集し得る。例えば、このメトリクスは、異なるプログラ
ムによるインタフェースの起動カウントと、（単一起動で多数のレコードを検索するため
に使用され得るｇｅｔＮｅｘｔＲｅｃｏｒｄのような、少なくともいくつかのインタフェ
ースのための起動カウントとは異なり得る）取り込まれるか検索されるレコードの総数と
、取り込まれるか検索されるデータの総量等とを含み得る。ストリームを所有するクライ
アントまたはストリームからデータを生成及び／若しくは消費するクライアントに請求さ
れる課金額は、プログラムによるインタフェース（要素１７１９）に関連する、少なくと
も部分的に使用メトリクス及びそれぞれの課金率に基づいて、所望により生成され得る。
少なくともいくつかの実施形態においては、課金動作は、ストリーム取り込み／検索操作
に関して非同期であり得る。例えば、請求書はその月の間に収集されたメトリクスに基づ
いて月毎の請求期間の最後に生成され得る。

図１８ａは、少なくともいくつかの実施形態による、ストリーム処理ステージ（ＳＰＳ
）を構成するよう実行され得る、操作の態様を示すフローチャートである。要素１８０１
に示されているように、プログラムによるインタフェースは、クライアントがストリーム
データレコードのためにいくつかの処理ステージ構成可能にするよう実装され得る。例え
ば、特定のステージを構成するために、クライアントは、ステージで分割されたストリー
ムデータレコード上で実行される処理操作（単数または複数）を示してよく、処理される
データの入力ストリームの識別のような、その他のパラメータと同様に、処理操作の出力
のための分散ポリシが取得され得る。いくつかの実施形態では、ＳＰＳステージでの処理
操作は、冪等に必要であり得る。その他の実施形態では、非冪等の操作は、また、少なく
ともいくつかのステージで支援され得る。所与のステージで実行される処理が非冪等であ
る場合、クライアントは依然として、いくつかの実施形態で、ワーカノードが定期的に、
いくつかの永続性のある外部位置に操作の出力をフラッシュするように構成し、レコード
検索シーケンスに関してフラッシュ操作がいつ実行されたか記録し、及び後に交換された
ワーカノードが回復中にフラッシュ操作を再操作するよう構成することで、回復に関連し
た冪等の利益を取得することが可能である。少なくともいくつかの実施形態においては、
並行してストリームデータ上で操作しているいくつかの異なる状態、及びその他のステー
ジに入力ストリームとして使用されるいくつかのステージの結果を備える、クライアント
は有向非巡回グラフ（ＤＡＧ）またはその他の処理ステージのグラフを構成することが可
能であり得る。いくつかの実施形態では、永続性ストリームよりもむしろ、１つ以上の一
過性は、異なるステージ間で作成され得る。例えば、１つのステージからのデータレコー
ド出力は、異なるステージに入力として入れられる前に、必ずしも永続性記憶装置に格納
されない。

例えば、チェックポイントベースの回復ポリシまたはベストエフォート回復ポリシを含
む、いくつかの実施形態では、いくつかの異なる回復ポリシのいずれかは、ＳＰＳステー
ジに実装され得る。一実施形態では、クライアントは異なるＳＰＳステージに対する回復
ポリシを選択するために、プログラムによるインタフェースを使用し得る。チェックポイ
ントベースの回復が使用されるステージでは、ワーカノードは、プログレスレコードまた
は間隔毎のチェックポイントを格納するよう構成され、ストリームパーティション内でワ
ーカノードがどのくらいまで達したのか示し得る（例えば、一番最近処理されたレコード
のシーケンス番号がプログレスのインジケータとして格納され得る）。図１９を参照して
以下に記載されたように、プログレスレコードは、破損後の復旧操作の間、後に使用され
得る。ベストエフォートリカバリポリシにおいては、プログレスレコードは格納される必
要がなく、破損に対応して構成される交換されたワーカノードは、受信されるときに新し
いデータレコードを単に処理し得る。所与のＳＰＳステージグラフまたはワークフローの
中では、いくつかの実施形態において異なる回復ポリシが異なるステージに適用され得る
。

ＳＰＳ制御サーバは、例えば、要素１８０１において示されたプログラムによるインタ
フェースの１つを介して、パーティションポリシＰＰｏｌ１による、ストリームＳ１の特
定のステージＰＳ１で実行される冪等操作Ｏｐ１の表示を受信してよく、処理の結果が出
力分散ディスクリプタＤＤｅｓｃ１に従って分散される（要素１８０４）。状態ＰＳ１の
ために構成されるワーカノードの数及び、ノードに必要な仮想リソースまたは物理リソー
スは、例えば、Ｐｐｏｌ１冪等操作Ｏｐ１の複雑性及びワーカノードに使用されるリソー
スの遂行能力（要素１８０７）のような様々な要因に基づいて、決定され得る。

ワーカノードは、次にインスタンス化され、例えば、選択された仮想または物理マシン
リソースで、プロセスまたはスレッドとして構成され得る（要素１８１０）。単純な一実
装においては、例えば、１つのワーカノードは、Ｓ１の各パーティションに最初に割り当
てられ得る。所与のワーカノードは、（ａ）Ｓ１の検索ノードの適切なサブセットからデ
ータレコードを受信し、（ｂ）受信されたデータレコード上でＯｐ１を実行し、（ｃ）所
望により、例えば、ＰＳ１のために回復ポリシに基づいて、パーティションレコードのセ
ットが処理されたことを示すプログレスレコード／チェックポイントを格納し、及び（ｄ
）ＤＤｅｓｃ１（例えば、中間永続性ストリームまたは一過性ストリームへの入力、また
はその他の処理ステージまたは記憶システムへの直接入力）によって示された宛先に出力
を伝送するよう構成され得る。少なくともいくつかの実施形態においては、ＳＰＳ処理は
、継続的にどこかに伝送される必要がある任意の出力を必ずしも生成しなくてよいことに
注意する。例えば、いくつかのＳＰＳアプリケーションは、単にデータレコードの一時的
なリポジトリとして機能し、及び／またはユーザがデータレコードを見ることを可能にす
るクエリのインタフェースを実装し得る。このようなアプリケーションは、出力を管理し
得る。例えば、出力は受信されたクエリに対応して生成され得るが、分散されたディスク
リプタにより生成されない。ロギングに関連したＳＰＳアプリケーションは、大規模な分
散システムから収集された最終日のログレコードを保持し、例えば、クライアントがデバ
ッグまたは分析の目的でロギングデータを見ることを可能にする。したがって、いくつか
の実施形態では、出力分散ディスクリプタは、ＳＰＳの少なくともいくつかのステージ、
少なくともいくつかのストリーム、または少なくともいくつかのパーティションのために
特定される必要はない。ワーカノードは、次に、それぞれの構成の設定（要素１８１３）
通りに、検索を開始し、データレコードを処理し始め得る。少なくともいくつかの実施形
態においては、ＳＰＳ制御ノードは、ワーカノード（要素１８１６）に使用されるリソー
スにおけるリソース利用レベルのような、様々なその他のメトリクスと同様に、（例えば
、ハートビートプロトコルのように応答性チェックを使用して）ワーカノードのヘルスス
テータスを監視し得る。ワーカノードから収集される情報は、下記に記載するように、例
えば、ワーカノードは置換えられ、回復ポリシが実装されるべき場合にフェイルオーバが
必要か否かを決定するために使用され得る。

いくつかの実施形態では、実装可能なＳＰＳクライアントのライブラリは、クライアン
トが所有する構内でＳＰＳワーカノードを、及び／またはクライアントが選択するプロバ
イダネットワークのリソースを実装することを希望するクライアントに提供され得る。ク
ライアントのライブラリはまた、ＳＰＳクライアントが、ヘルス監視機能、自動ワークロ
ード監視及び分散、セキュリティ管理、動的再分割等のような、ＳＰＳ管理サービスの様
々な制御プレーン特徴の使用を希望する程度を選択するのを可能にし得る。図１８ｂは、
少なくともいくつかの実施形態による、ストリーム処理ワーカノードの構成のための、ク
ライアントのライブラリコンポーネントの起動に対応して実行され得る操作の態様を示す
フローチャートである。要素１８５１に示されるように、ＳＰＳクライアントのライブラ
リは、（例えば、図１８ａに図示したように、操作の種類を実行するよう構成されるマル
チテナントのＳＰＳ管理サービスのウェブサイトからダウンロードを介して）提供され得
る。ライブラリは、いくつかの実行可能なコンポーネント及び／またはクライアントのア
プリケーションにリンク可能なコンポーネントを含み得る。いくつかのライブラリのコン
ポーネントは、クライアントが、選択、ＳＰＳ管理サービスを登録、または１つ以上のＳ
ＰＳステージのストリーム処理操作が実行される、様々なワーカノードの所望の特性を明
示することを可能にし得る。例えば、あるクライアントは、ワーカノードのためのプロバ
イダネットワークの仮想計算サービスで実装されるコンピュートインスタンスのセットを
使用することを希望してよい。一方、別のクライアントは、ストリームレコードを処理す
るために、（プロバイダネットワークによって支援されない専用装置のような）クライア
ント自身のデータセンタに配置された計算装置を使用することを希望してよい。クライア
ントはワーカノードをクライアントの構内において必要に応じて、または所望により、仮
想計算サービスのコンピュートインスタンスを使用してオンラインにし得る。このような
オンデマンドでのワーカノードのインスタンス化に加え、またはその代わりに、いくつか
の実施形態では、クライアントは、必要な時に配置され得る、潜在的に再利用可能なワー
カノードのプールを事前に構成し得る。いくつかの実装においては、ライブラリコンポー
ネントは、クライアントが、指定されるステージのワーカノードのようなクライアントに
よってインスタンス化される、ＳＰＳ管理サービス、特定のプロセスまたはスレッドでの
登録を可能にするよう実行または起動されてよく、後の制御プレーン操作がＳＰＳ管理サ
ービスによって処理され得る。一実施形態では、クライアントは、またワーカノードのた
めにＳＰＳ管理サービスによって処理される異なるレベルの制御プレーンの役割から選択
することも可能であり得る。例えば、あるクライアントは、ワーカノードのヘルス状態を
監視するためにクライアント自身のカスタムモジュールを使用することを希望し、一方、
別のクライアントはワーカノードのヘルス状態を監視し、破損が検出された場合には適切
な行動を取るためのＳＰＳ管理サービスを利用することを希望し得る。

ＳＰＳ管理サービスは、特定のクライアントは、特定のＳＰＳステージＰＳ１（要素１
８５４）のワーカノード及び／または制御プレーン操作を構成するクライアントのライブ
ラリを使用することを希望するという表示を受信し得る。（ＰＳ１自体は、ライブラリに
含まれるプログラムによるインタフェースまたはＳＰＳ管理サービスによって露出される
プログラムによるインタフェースを使用して設計されてよく、これは図４に示されたウェ
ブベースのインタフェースに類似している）クライアントはまた、データがＰＳ１による
入力として使用するために検索されるストリームを示し得る。所望により、少なくともい
くつかの実施形態においては、クライアントは、例えばクライアントがノードのために、
サービスのヘルス状態の監視能力を使用することを希望するか、または独自のヘルス状態
を監視するツール（要素１８５７）を使用することを希望するかに対するＰＳ１に制御プ
レーンを設定を示し得る。クライアントによって示された基本設定に応じて、クライアン
トの使用するために構成されるＳＭＳ及び／またはＳＰＳの１つ以上のノードは、決定さ
れ得る（要素１８６０）。ネットワークの接続性は、ＳＭＳ及び／またはＳＰＳのノード
へのクライアントのワーカノード、並びに／またはその他の構成操作は、データレコード
が流れ、かつ所望の結果を処理することを可能にするために実行され得る。データレコー
ドは、検索要求を受信するとＳＰ１ワーカノードに提供され、所望の制御プレーン操作（
クライアントによってそれが要求された場合）は必要に応じて実行され得る。少なくとも
いくつかの実施形態においては、クライアントが、ＳＭＳ管理サービスの様々なサブシス
テムの制御プレーンの機能性を使用することを希望する範囲の制御を可能にする類似の手
法も、あるいはその代わりに実装され得ることに注意する。

図１９は、少なくともいくつかの実施形態による、ストリーム処理のために１つ以上の
リカバリポリシを実装するために実行され得る、操作の態様を示すフローチャートである
。要素１９０１に示されているように、ＳＰＳ制御ノードは、特定のワーカノードを置き
換えるためのトリガ基準が合致したと決定し得る。例えば、ワーカノードは応答しなくな
るか、ヘルス状態でなくなり、現在のノードのワークロードレベルは、フェイルオーバの
ため閾値に達し、ワーカノードで検出された、いくつかのエラーは、閾値を超え、または
ワーカノードの何か別の予期しない状態が識別され得る。置換えられたワーカノードは識
別されるかインスタンス化され得る（要素１９０４）。いくつかの実施形態では、入手可
能なワーカスレッドのプールが設定され、置き換えとして選択されてよく、例えば、新し
いスレッドまたはプロセスが開始され得る。

ベストエフォートリカバリポリシが、特定のワーカノードが動作しているＳＰＳステー
ジで（要素１９０７にて決定される際に）使用される場合には、置き換えられたワーカノ
ードは、入手可能になるときに（要素１９１６）、追加のデータレコードを単に処理し始
めてよく、例えば、置換えられたワーカノードの進捗記録は確認されない。チェックポイ
ントベースの回復ポリシが使用される場合、置換えられたワーカノードは、置換えられた
ワーカノードによって格納されたプログレスレコードにアクセスし得る位置の表示（例え
ば、記憶装置のアドレスまたはＵＲＬ）は、提供され得る（要素１９１０）。置換えられ
たワーカノードは、置換えられたノードによって格納された直近のプログレスレコードを
検索し、置換えられたワーカノードが、ステージの冪等操作を実行（要素１９１３）すべ
きデータレコードのセットを決定するためにプログレスレコードを使用し得る。このよう
なチェックポイントベースの回復ポリシにおいては、最後のプログレスレコードと置換え
られたワーカノードがインスタンス化される時間との間の持続時間に応じて、置換えられ
たワーカノードが、記憶されたプログレスレコード以降の、追加のレコードを処理した速
度と同様に、いくつかの数のデータレコードが２回以上処理され得る。実行されるこの操
作は冪等である場合には、このような反復操作は少なくともいくつかの実施形態では、良
くない影響を有し得ない。置換えられたワーカノードが、以前に格納されたプログレスレ
コードに基づいて、反復の回復操作を実行した後、少なくともいくつかの実施形態では、
置き換えのワーカスレッドは、そのプログレスレコードを格納してよく、回復が完了した
ことを示し、新しく受信されたデータレコード（要素１９１６）上の通常のワーカスレッ
ド操作を開始してよい。

図２０は、少なくともいくつかの実施形態による、データストリーム用の複数のセキュ
リティオプションを実装するために実行され得る、操作の態様を示すフローチャートであ
る。要素２００１に示されているように、クライアントがデータストリームの管理及び処
理のために、例えば、異なる機能カテゴリ（例えば、取り込み、記憶、検索、処理または
制御ノード）のノードのための配置先の種類の選択肢を含む、様々なセキュリティオプシ
ョンから選択するのを可能にする、１つ以上のプログラムによるインタフェースが実装さ
れ得る。配置先の種類は、様々なセキュリティプロフィールに関連する態様において、互
いに異なり得る。ＳＭＳまたはＳＰＳノードに使用されるリソースの物理位置は、いくつ
かの実施形態において、宛先の種類によって異なり得る。例えば、プロバイダネットワー
クデータセンタに配置されるインスタンスホストのようなリソースは、ノードに使用され
得る。またはクライアントが所有する設備のリソースが使用され得る。または第三者のリ
ソースが使用され得る。ネットワーク隔離レベルまたはその他のネットワークの特徴は、
少なくともいくつかの実施形態において、宛先の種類によって異なり得る。例えば、いく
つかのＳＭＳノードまたはＳＰＳノードは、隔離された仮想ネットワーク内、または、専
用の隔離された物理リンクを介してプロバイダネットワークに接続されたクライアントが
所有する設備でインスタンス化されてよい。一実施形態では、特定の種類のＳＭＳノード
またはＳＰＳノードは、入手することも可能なマルチテナントのインスタンスホストを使
用する代わりに、プロバイダネットワークのシングルテナントのインスタンスホストに確
立されることをクライアントは示し得る。少なくともいくつかの実施形態においては、様
々な種類の暗号化の選択肢はまた、セキュリティに関連するプログラムによるインタフェ
ースを介して選択され得る。

クライアントのセキュリティプロフィールの選択またはストリームＳ１のための１つ以
上の機能カテゴリのノードに関する基本設定は、セキュリティに関連するプログラムによ
るインタフェースを介して受信され得る。例えば、クライアントは機能カテゴリＦＣ１（
例えば、クライアントはクライアントが所有する構内でＳＰＳワーカノードを実装したい
と希望し得る）のノードに１つのセキュリティプロフィール及び異なる機能カテゴリＦＣ
２のノードに異なるセキュリティプロフィール（例えば、クライアントはプロバイダネッ
トワークデータセンタでのＳＭＳ取り込みノードまたは記憶ノードの実装を希望し得る）
（要素２００４）を選択し得る。場合によっては、クライアントは類似のセキュリティプ
ロフィールですべての異なる機能カテゴリのノードを設定すると決定し得る。ＳＭＳ及び
／またはＳＰＳは、いくつかの実施形態では、様々な機能カテゴリに対し、デフォルトの
配置先種類を定義し得る。例えば、クライアントが支持しない限り、すべての機能カテゴ
リのノードはプロバイダネットワークの隔離された仮想ネットワーク内に設定され得る。

異なる機能カテゴリのノードは、次に、セキュリティプロフィール及び／または位置に
対するクライアントの基本設定に基づいて（またはクライアントが基本設定を提供しない
機能カテゴリのデフォルトの設定に基づいて）（要素２００７）構成され得る。構成は、
例えば、適切な物理ホストまたは物理マシンを選択すること、適切なコンピュートインス
タンス、仮想マシン、異なる機能カテゴリのノードのプロセス及び／またはスレッドをイ
ンスタンス化すること、ノード間の適切なネットワーク接続を確立すること、を含み得る
。いくつかの実施形態では、異なるストリーム管理及び処理機能に対する実行可能なライ
ブラリのコンポーネントは、構成の一部としてプロバイダネットワークの外部ホストにイ
ンストールするために提供され得る。

少なくともいくつかの実施形態による、暗号化モジュールは、例えば、クライアントに
よって示された暗号の基本設定によって、またはデフォルトの暗号化設定（要素２０１０
）に基づいてノードの１つ以上のカテゴリで作動され得る。様々な機能カテゴリのノード
は、次に、クライアントの希望で（要素２０１３）、ストリームデータが取り込まれ、格
納され、検索され及び／または処理されるように作動されてよい。

図２１は、少なくともいくつかの実施形態による、データストリームのためのポリシを
動的再分割を実装するために実行され得る、操作の態様を示すフローチャートである。要
素２１０１にて示すように、パーティションポリシは、データストリームのために決定さ
れ得る。ポリシは、例えば、データストリームを再分割するための１つ以上のトリガ基準
と同様に、データ生成部によって供給されるキーに基づいて、または送信されるデータレ
コードの様々な属性に基づいて、パーティションにデータレコードを初期にマッピングす
ることを含み得る。例えば、いくつかの実施形態では、ハッシュ関数がパーティションキ
ーまたはキーに適用されてよく、１２８ビット整数のハッシュ値を生成する。可能な１２
８ビット整数の範囲は、Ｎ連続副範囲に分かれてよく、それぞれはストリームのＮパーテ
ィションのひとつを表す。いくつかの実施形態では、パーティションの数及び／または副
範囲の関連するサイズは、ストリームによって異なってよい。少なくともいくつかの実施
形態においては、代理してストリームが構成されるクライアントは、パーティションスキ
ームの使用、例えば、使用される所望のパーティションの数、所望のパーティション機能
の特徴に関する、入力を提供し得る。少なくとも１つの実施形態においては、クライアン
トはパーティションの識別子または送信されるデータレコードのいくつか、またはすべて
の名前を提供し得る。

ストリームのデータレコードが受信されると、それぞれのパーティションは供給された
キー及び／またはその他の属性に基づいて決定され得る。また、取り込み、記憶及び検索
ノードの適切なセットは、識別されるパーティション（要素２１０４）のために選択され
得る。少なくともいくつかの実施形態においては、それぞれのシーケンス番号（要素２１
０７）は、例えば、所与のパーティションのレコードが受信された順を示すデータレコー
ドのために生成され得る。シーケンス番号は、タイムスタンプ値（例えば、よく知られた
１９７０年１月１日の協定世界時００：００：００などからの経過秒数）、記憶サブシス
テム、ＳＭＳソフトウェアのバージョン番号及び／またはパーティション識別子から取得
されるサブシーケンス値のようないくつかの実装においていくつかの要素を構成し得る。
シーケンス番号はいくつかの実施形態では、データ生成部に、例えば、送信されたデータ
レコードの正常な取り込みへの応答に、提供され得る。いくつかの実施形態では、シーケ
ンス番号はデータコンシューマによって、ストリームのデータレコードまたはパーティシ
ョンを取り込み順に検索し、使用され得る。

データレコードは、パーティションポリシ（要素２１１０）に基づいて向けられた、ス
トレージノードで、少なくともいくつかの実施形態では、シーケンス番号順に格納され得
る。回転磁気ディスクの記憶装置が使用される実施形態では、シーケンシャルライトが典
型的には、受信されたデータレコードをディスクに保存するために使用され得る。それに
よってディスクシークレイテンシを避ける。少なくともいくつかの実装においては、不揮
発性のバッファは、例えば、ディスクシークの確立をさらに減少させるために、レコード
をディスクに記憶する前にライトキャッシュとして使用され得る。シーケンス番号によっ
て並べられた多数のデータレコードの読み込みに対する要求（例えば、ｇｅｔＮｅｘｔＲ
ｅｃｏｒｄまたは類似のインタフェースの起動）に対応して、データレコードは、記憶装
置（要素２１１３）からシーケンシャルリードを使用して後に読み込まれ得る。

図２２は、少なくともいくつかの実施形態による、データストリームの動的再分割を実
装するために実行され得る、操作の態様を示すフローチャートである。要素２２０１に示
されるように、ストリームが、（例えば、ＳＭＳまたはＳＰＳの制御コンポーネントで）
動的に再分割されるべきであると決定され得る。いくつかの異なるトリガ条件が、取り込
み、記憶、検索、処理または制御ノードのうち１つ以上で、過負荷の検出のようなストリ
ームを再分割する決定、または異なるノードのワークロードレベルにおける不均衡の検出
、またはクライアント（例えば、データ生成部またはデータコンシューマ）から受信され
得る再分割要求に誘導し得る。いくつかの実装において、クライアントの再分割要求は、
生成される修正されたマッピングの様々なパラメータのような、要求された再分割の特定
の詳細を含み得る（例えば、特定のパーティションが組み合わされ、または分割などされ
るべき、追加または削除された、パーティションの数）。一実装においては、クライアン
トによる再分割の要求は、クライアントが解決を希望する（負荷の不均衡のような）問題
のある状態を示し得る。また、ＳＭＳまたはＳＰＳは、問題のある状態の記載を適切な再
分割の操作に変換する役割があってよい。場合によっては、問題のある状態を再分割また
は記載することを要求する代わりに、クライアントは再分割に使用するためにトリガ基準
を特定し得る。データストリームにおけるデータの耐久性要件の変更を決定するのは、再
分割をトリガし得る。いくつかの実施形態では、例えば、ストリームレコードのために、
異なるセットの記憶装置または異なる記憶技術を選択する結果になり得る。データストリ
ームの使用状況の変化（例えば、データレコードが生成または消費される速度）の検出は
、また、場合によっては、再分割をもたらし、また、変更された使用状況により適切な、
異なる記憶技術または異なる記憶装置のセットを使用することになり得る。例えば、再分
割の決定は、所与のパーティションまたはストリーム全体に予想される読み出し及び書き
込みの速度には、ＳＳＤは回転磁気ディスクよりも、より適切な記憶技術であり得るとい
う判断をもとになされ得る。予定された、または間近に迫ったソフトウェア及び／または
ハードウェアのバージョン改訂は、一実施形態では、再分割をトリガし得る。場合によっ
ては、課金または請求についての懸念は、再分割をトリガし得る。クライアントが予算の
制約があることを示す場合には、異なるパーティション手法または異なる格納手段を使用
してより効率的になり得る。変更された性能目標は、また少なくともいくつかの実施形態
では、再分割をトリガし得る。図２２に示された実施形態においては、再分割後に割り当
てられるシーケンス番号に使用される、初期のタイムスタンプ値は、（１９７０年１月１
日の協定世界時００：００：００秒からのオフセットのように、エポック値は、典型的に
は、いくつかのオペレーティングシステムにおけるシステムコールを介して入手可能であ
る）選択され得る（要素２２０４）。いくつかの実装においては、プロバイダネットワー
クで実装されるグローバル状態管理部は、ｇｅｔＥｐｏｃｈＶａｌｕｅ ＡＰＩを支援し
てよく、例えば、均一なタイムスタンプ値を取得するためにＳＭＳ及び／またはＳＰＳの
様々なコンポーネントがシーケンス番号の生成のために使用されることを可能にする。そ
の他の実装においては、その他の時間源が使用され得る。例えば、ＳＭＳまたはＳＰＳ制
御ノードは、その他のコンポーネントに均一に並べられたタイムスタンプ値を提供するよ
う指定され得るか、またはローカルシステムコールの起動が使用され得る。いくつかの実
施形態では、タイムスタンプ値は、任意の特定のホストで、必ずしも壁時計時刻に対応す
る必要がない。例えば、単調増加整数カウンタ値が単に使用され得る。

修正されたパーティションマッピングは、再分割の決定時に使用されるマッピングとは
異なり、ストリームのために生成され得る（要素２２０７）少なくともいくつかの実施形
態においては、変更されたマッピングは、特定のパーティションキーを有するデータレコ
ードを、再分割前にマップされた同一のキーを有するデータレコードと異なるパーティシ
ョンにマップし得る。いくつかのパーティション（典型的には、使用頻度が高いパーティ
ション）が分割され得る。一方、その他の（典型的には、使用頻度が低い）パーティショ
ンが、再分割及び／または観察されたワークロードメトリクスのためのトリガ条件に応じ
て、組み合わされ得る。いくつかの実施形態では、異なるパーティション機能が、再分割
の前よりも再分割後に使用され得る。例えば、異なるハッシュ関数、またはハッシュ関数
による結果をパーティションに細分化するための異なる手法が使用され得る。いくつかの
実装においては、例えば、１２８ビット整数、１２８ビット整数空間の連続的な範囲に対
応するパーティションは、再分割後に副範囲の異なるセットに分けられ得る。少なくとも
いくつかの実施形態においては、取り込み、記憶、検索、処理または制御ノードの新しい
セットは、新しく作成されたパーティションに割り当てられ得る。いくつかの実装におい
ては、空間効率のよい組み合わされたデータ構造は、初期のマッピング及び修正されたマ
ッピング（要素２２０８）の両方を表すために使用され得る。例えば、有向非巡回グラフ
またはツリー構造は格納されてよく、各入力は、修正されたパーティションに対応するレ
コードのみが再分割の結果として変更が必要であるように、パーティション機能出力範囲
（例えば、所与のパーティションに対応するパーティションのハッシュ関数の結果の範囲
）の表示及び有効な時間範囲を含み得る。再分割の間に変更されないパーティションの入
力は、データ構造中で修正される必要がない可能性がある。新しいノードは、修正された
パーティションマッピング（要素２２１０）を実装するよう構成され得る。少なくともい
くつかの実施形態においては、以前のマッピングを基準にして格納されたデータレコード
に対する検索要求が少なくともある時に継続して受信され得るため、従来のノード及び従
来のマッピングは、ある時に保持され得る。特定のシーケンス番号またはタイムスタンプ
を明示する読み出し要求が受信されると（要素２２１３）、新しいパーティションマッピ
ングか、または従来のパーティションマッピングを使用して読み出し要求を満たすかにつ
いての決定が（例えば、制御ノードまたは検索ノードで）され得る。選択されたマッピン
グは、次に、要求されたデータが取得される、適切な記憶ノードを識別するために使用さ
れ得る。

図２３は、少なくともいくつかの実施形態による、データストリームレコード用の少な
くとも１回のレコードの取り込みポリシを実装するために実行され得る、操作の態様を示
すフローチャートである。要素２３０１に示されるように、１つ以上のプログラムによる
インタフェースは、クライアントが、データストリームのために、例えば、（ａ）肯定応
答が受信されるまで、どちらのレコード送信者がレコードを１回以上送信したかによる、
少なくとも１回のポリシまたは（ｂ）どちらの応答が少なくともいくつかのレコード送信
に提供されないかによる、ベストエフォート取り込みポリシを含む、いくつかの取り込み
ポリシの選択肢から、レコード取り込みポリシを選択可能なように実装され得る。いくつ
かのデータを生成するクライアントは、その他の人と同じようには、レコードのほんの一
部分の潜在的な損失については心配しない可能性がある。そのためベストエフォートの取
り込み手法を選択し得る。いくつかの実装においては、ベストエフォートの取り込みのた
めに構成されたストリームに対しても、ＳＭＳは、データレコードのいくつかのサブセッ
トに対して応答を依然として提供し得る。または、ベストエフォートポリシはデータレコ
ード毎に応答を必要とはしないものの、すべてのデータレコードに対する応答の提供を試
みようとさえし得る。

要求は、特定のストリーム（要素２３０４）のために使用される特定の取り込みポリシ
を示す、プログラムによるインタフェースの１つを介して受信され得る。取り込みノード
は、ストリームに影響するパーティションポリシによって、インスタンス化され得る（要
素２３０７）。同一データレコードの１つ以上の送信が取り込みノードで受信されると（
要素２３１０）、異なる動作が、有効な取り込みポリシに依存して行われ得る。少なくと
も１回取り込みポリシが使用されると（要素２３１３において決定されるように）、応答
は、１つ以上の送信のそれぞれのために、データ生成部に送信され得る。しかしながら、
データレコードは記憶サブシステム（２３１６）にて１度のみ保存され得る。（ストリー
ムのために有効な永続性ポリシによる、所与のレコードのＮ複製が場合によっては、格納
され得る。しかしながら、所与のデータレコードがＭ回数送信されると、複製は送信のう
ち１つのみに対して生成され得る。すなわち、格納されたレコードの複製の全体数は、依
然としてＮであり、ＮｘＭではないことに注意する）。ベストエフォート取り込みポリシ
が有効であった場合には、（要素２３１３においても検出されるように）データレコード
は記憶装置にて依然として１度のみ保存され得る。しかしながら、応答はデータ生成部（
要素２３１９）に送信される必要はない。少なくともいくつかの実施形態においては、ク
ライアントの請求額は、所望により、少なくとも部分的に選択された取り込みポリシ（要
素２３２２）に基づいて、決定され得る。前述したように、いくつかの実施形態では、少
なくとも１回の取り込みポリシの２つのバージョンは、支援され得る。図２３に示された
ものと同様に、１つのバージョンにおいて、ＳＭＳは、データレコードを複製を排除する
機能があり得る（すなわち、２つまたはそれ以上の送信のセットの１つのみに対応して、
データがＳＭＳ記憶サブシステムに格納されることを確実にする）。少なくとも１回の取
り込みの異なるバージョンにおいては、ＳＭＳによるデータレコードの複製が許可され得
る。後者の手法は、ストリームアプリケーションには有用であり得、データレコードの複
製の否定的な結果が少数であるか、全く無い。及び／またはそれぞれの複製を排除を実行
するストリームアプリケーションであり得る。

図２４は、少なくともいくつかの実施形態による、データストリーム用の複数の永続性
ポリシを実装するために実行され得る、操作の態様を示すフローチャートである。要素２
４０１に示されるように、クライアントが複数の永続性ポリシからストリームデータレコ
ードのために永続性ポリシを選択可能にする、１つ以上のプログラムによるインタフェー
スが実装され得る。永続性ポリシは様々な面のいずれかにおいて、互いに異なり得る。例
えば、（ａ）保存すべきいくつかの複製の数が異なり得る（例えば、Ｎ個の複製対２つの
複製対単一の複製ポリシが支援され得る）（ｂ）使用されるストレージの位置／装置の種
類が異なり得る（例えば、回転磁気ディスク対ＳＳＤ対ＲＡＭ対データベースサービスま
たはマルチテナントストレージサービス）及び／または（ｃ）ポリシが大規模な破損に対
する回復力の予想される範囲が異なり得る（例えば、マルチデータセンタ対シングルデー
タセンタポリシが支援され得る）。要求が、特定のストリーム（要素２４０４）のため、
特定の永続性ポリシのクライアントの選択を示す受信され得る。いくつかの実施形態では
、クライアントに選択された永続性ポリシは、所与のストリームのそれぞれのパーティシ
ョンのための異なる記憶位置の種類または装置の種類の使用をする結果となり得る。一実
施形態では、ストリームレベルまたはパーティションレベルの何れかで、クライアントよ
りもむしろＳＭＳが記憶位置の種類または装置の種類を選択し得る。いくつかの実施形態
では、クライアントは、（所望の読み出し及び書き込みスループットまたは待ち時間のよ
うな）データの耐久性及び／または性能の目標を示し得る。いくつかの実施形態では、永
続性ポリシを選択する際に、これらの目標は、適切な記憶装置の種類または位置を選択す
るために、ＳＭＳによって使用され得る。例えば、短待ち時間が所望される場合には、Ｓ
ＳＤは、１つ以上のパーティションまたはストリームのデータレコードを格納するために
、回転磁気ディスクの代わりに、使用され得る。

１セットの取り込みノードは、データ生成部からの選択されたストリームのデータレコ
ードを受信するよう決定または構成され得る。また、ストレージノードセットは、選択さ
れた永続性ポリシを実装するように構成され得る（要素２４０７）。データレコードが取
り込みノードにおいて受信されるとき（要素２４１０）、１つ以上のデータレコードのコ
ピーが、データレコードが属するパーティションの役割をするストレージノードによって
選択された記憶装置で、選択された永続性ポリシに基づいて格納され得る（要素２４１３
）。少なくともいくつかの実装においては、請求額は所望により（及び／または非同期的
に）、クライアントによって選択された特定の永続性ポリシに基づいて、決定され得る（
要素２４１６）。

ストリーム処理のための分散化したワークロード管理
いくつかの実施形態では、ＳＰＳの実質的な部分または制御プレーンの機能性のすべて
は、例えば、（ワーカノードへのパーティションの割り当て、動的パーティションへの応
答、ヘルス監視及び／または負荷分散のような）様々な制御操作を調整する所与のＳＰＳ
ステージ内のワーカノードによって、データベーステーブルのような、共有されたデータ
構造を介して、分散化された方法で実装され得る。所与のワーカノードＷ１は、例えば、
どのステージの入力ストリームのパーティションが（もしあれば）、現時点では処理され
ていない共有されたデータ構造内の入力であるか決定するために調べ得る。このようなパ
ーティションＰ１が発見されるときには、Ｗ１は、Ｗ１がＰ１のレコード上でステージの
処理操作を実行することを示すために、共有されたデータ構造中の入力をアップデートし
得る。その他のワーカノードは、Ｗ１はＰ１レコードを処理するために割り当てられ、ま
た、したがって、異なるパーティションをＰ１レコードに割り当て得ることを学習し得る
。ワーカノードは定期的に、または場合により、ＳＭＳ制御プレーンにクエリを送信して
、入力ストリームに有効な現在のパーティションマップを決定し、また、必要であれば（
例えば、再分割の結果として）マップの変更を示す共有されたデータ構造をアップデート
し得る。負荷分散及びその他の操作は、また、様々な実施形態において下記に記載される
ように、共有されたデータ構造を介して調整され得る。いくつかのこのような分散化され
た実装においては、専用の制御ノードは、ＳＰＳに必要とされず、そのためＳＰＳワーク
フローを実装するのに必要なオーバーヘッドを低減する。このような分散化されたＳＰＳ
制御プレーンの実装は、例えば、顧客またはプロバイダネットワーク外の位置に割り当て
られるプロバイダネットワーク内のコンピュートインスタンスのような、ＳＰＳクライア
ントライブラリを利用してストリーム処理の様々な態様を実装する、特に予算に敏感な顧
客には人気があり得る。分散されたＳＰＳ制御プレーン技術は、また、クライアントライ
ブラリが使用されていない実施形態において使用され得る。例えば、ＳＭＳ及びＳＰＳに
使用されるすべてのリソースがプロバイダネットワーク内に構成されている場合である。
ワーカノードが、少なくともいくつかの処理ステージのための、いくつかのまたはすべて
のＳＰＳ制御プレーン機能を実装するＳＰＳは、本明細書においては、「分散された制御
ＳＰＳ」と称する。

図２５は、少なくともいくつかの実施形態による、処理ステージのワーカノードがデー
タベーステーブルを使用してワークロードを調節するストリーム処理システムの例を示す
。分散された制御ＳＰＳ２５９０内では、２つのステージ２１５Ａ及びステージ２１５Ｂ
は、ワーカノードのそれぞれのセットで定義される。ステージ２１５Ａは、ワーカノード
２５４０Ａ及びワーカノード２５４０Ｂを備え、一方、ステージ４１５Ｂは、ワーカノー
ド２５４０Ｋ及びワーカノード２５４０Ｌを備える。ステージ２１５Ａ及びステージ２１
５Ｂのそれぞれには、対応するパーティションの割り当て（ＰＡ）テーブル２５５０は、
ステージ２１５ＡにはＰＡテーブル２５５０Ａ及びステージ２１５ＮにはＰＡテーブル２
５５０Ｂのような、データベースサービス２５２０で作成される。いくつかの実施形態で
は、所与のステージに対するＰＡテーブル２５５０は、例えば、クライアントライブラリ
コンポーネントまたは機能の起動に対応して、ステージの初期化中に作成され得る。各Ｐ
Ａテーブル２５５０は、入力の初期セットで、またはステージの入力ストリームの未割り
当てのパーティションを表す行が備えられ得る（すなわち、ワーカノードが現時点で割り
当てられていないパーティション）。例示的なカラムまたはＰＡテーブル入力の属性は、
図２６に示され、以下に記載されている。ステージのために開始されるワーカノード２５
４０（例えば、コンピュートインスタンスまたはその他のサーバで開始されるプロセスま
たはスレッド）は、ステージのＰＡテーブルに読み出し／書き込みアクセスを許可され得
る。ワーカノードからＰＡテーブルに向けられる読み出し及び書き込みは、ワーカノード
２５４０Ａ、２５４０Ｂ、２５４０Ｋ及び２５４０Ｌに対し、それぞれ２５６４Ａ、２５
６４Ｂ、２５６４Ｋ及び２５６４Ｌの矢印で図２５において示されている。

所与のワーカノード２５４０は、ＰＡテーブル中の入力を調べることによって、ステー
ジの処理操作を実行する特定のパーティションを選択するよう構成され得る。一実装にお
いては、ワーカノード２５４０Ａは、未割り当てのパーティションＰｋの入力を見つけら
れるまでＰＡテーブル２５５０Ａにおける入力をスキャンし、入力をアップデートするこ
とによって、例えば、ワーカノードの識別子を入力のカラムのうちの１つに挿入すること
によって、パーティションＰｋの割り当てを試み得る。このような挿入は、ワーカノード
によってパーティションをロックすることに類似していると考えられ得る。使用されるデ
ータベースのサービスの種類によって、同時にＰＡテーブルの入力への書き込みを潜在的
に管理するための異なる手法（例えば、ほぼ同時に未割り当てのパーティションを期せず
して識別する、２つまたはそれ以上のワーカノードによって）が、使用され得る。

一実施形態では、プロバイダネットワークの非リレーショナルマルチテナントデータベ
ースサービスが使用されてよく、強い整合性及び条件付き書き込み操作を支援するリレー
ショナルデータベースのトランザクションセマンティクスを必ずしも支援せずに、条件付
きの書き込み操作は、ワーカノードによるアップデートのような場合で使用され得る。Ｐ
Ａテーブル中のパーティションに割り当てられた特定のワーカノードの識別子を示すため
に、カラム「ワーカノードＩＤ」が使用される例、及びワーカノードがパーティションに
割り当てられないカラムの値が「ｎｕｌｌ」に設定されるを考える。このような場合にお
いては、識別子ＷＩＤ１を備えるワーカノードは、以下の論理的等価を要求し得る。「パ
ーティションＰｋに対する入力においては、ワーカノードＩＤはｎｕｌｌであり、次に、
その入力に対するワーカノードＩＤをＷＩＤ１に設定する」。このような条件付きの書き
込み要求が成功する場合には、識別子ＷＩＤ１を有するワーカノードは、パーティション
Ｐｋが割り当てられると仮定され得る。ワーカノードは次に、パーティションＰｋのデー
タレコードを検索し、例えば、矢印２５５４（例えば、ワーカノード２５４０Ａ、２５４
０Ｂ、２５４０Ｋ及び２５４０Ｌに対し、それぞれ２５５４Ａ、２５５４Ｂ、２５５４Ｋ
及び２５５４Ｌの矢印）で示されるように、ＳＭＳ検索サブシステム２０６のレコード検
索インタフェースを使用して、及び検索レコード上の処理操作を実行し始め得る。条件付
きの書き込みが失敗すると、ワーカノードは異なる未割り当てパーティションに対して検
索を開始し得る。その他の実施形態では、トランザクションを支援する（リレーショナル
データベースのような）データベースサービスが使用されてよく、トランザクションの機
能性は条件付きの書き込み操作の等価を実装するために使用され得る。例えば、ワーカノ
ードの成功にパーティションを割り当てる、複数の同時（またはほぼ同時）の試みのうち
１つのみを確保するために、このような同時の試みに含まれるワーカノードは確実に成功
または失敗を通知される条件付きの書き込みまたはトランザクションの支援のどちらにも
依存しない同期技術は、いくつかの実施形態で使用され得る。データベースサービスが使
用されなくてよい、いくつかの実装においては、その代わりに、ロッキングサービスが、
ＰＡテーブルに類似の永続性データ構造における入力をアップデートするため、排他アク
セスを取得するために、ワーカノードによって使用され得る。

その他のワーカノード２５４０は、ＰＡテーブルにおける入力を調査し、どちらのパー
ティションが未割り当てかを決定し、それらに１つ以上のパーティションを割り当てする
ことに結果的に成功し得る。このように、ステージの入力ストリームのパーティションま
たはストリームのためのワークロードを処理することは、結果的に、ステージのワーカノ
ードにより、それらに分散され得る。

任意の所与のストリームの初期のパーティションマッピングは、例えば、前述した動的
再分割操作の結果として、時間の経過とともに変化し得る。したがって、図２５に示され
た実施形態に示すように、１つ以上のワーカノード２５４０は、場合により（または以下
に記載されるようにトリガ条件に対応して）、現在のパーティションメタデータを取得す
るために、ステージの入力ストリーム（単数または複数）のＳＭＳ制御サブシステム２１
０に要求を送信し得る。いくつかの実装においては、このような要求は、矢印２５４４Ａ
、２５４４Ｂ、２５４４Ｋ及び２５４４Ｌによって示されたｇｅｔＳｔｒｅａｍＩｎｆｏ
ＡＰＩの起動のように、ＳＭＳ制御プレーンＡＰＩの起動を含み得る。ＳＭＳ制御サブ
システムは、例えば、ストリームのパーティションの最新のリスト及び／またはパーティ
ションの有効時間のようなその他の詳細で応答し得る。ＳＭＳ制御サブシステム２１０に
よって提供されたパーティション情報がＰＡテーブル中の入力に合致しない場合には、例
えば、１つ以上のパーティションに入力を挿入または削除することによって、ＰＡテーブ
ルはワーカノードによって修正され得る。ＳＭＳ制御サブシステムへのこのような要求２
５５４は、典型的には、少なくともいくつかの実施形態においては、矢印２５５４Ａの「
低頻度」ラベルによって示されたように、レコード検索要求２５５４（及び／またはデー
タベースの読み出しまたは書き込み操作２５６４）よりもかなり低頻度である。例えば、
一旦、パーティションに割り当てられると、ワーカノードは、典型的には、（例えば、ス
トリームの所有者がストリームを閉鎖する場合、またはパーティションが動的再分割の結
果閉鎖する場合には）パーティションデータが完全に消費されるまで、または（例えば、
異なるワーカノードが、以下に記載されるように、負荷の不均衡を検出したため、パーテ
ィションの移動を要求する場合には）何か他の確立の低い環境に遭遇するまで、そのパー
ティションのデータレコードを検索し、処理し続け得る。このため、たとえ実質的な情報
量が任意の所与の起動に対応して提供される場合でも、ｇｅｔＳｔｒｅａｍＩｎｆｏまた
はｓｉｍｉｌａｒＡＰＩの起動に関連したオーバーヘッドは、典型的には、様々な実施形
態で非常に小さくてよい（何十万かのパーティションがステージの入力ストリームに定義
される場合にはあり得る）。

したがって、分散された制御ＳＰＳ環境のキーワークロード管理操作のいくつかは、図
２５に図示された実施形態において、以下のように要約され得る。（ａ）ストリーム処理
ステージの第１のワーカノードによって、データベースのテーブルに少なくとも一部アク
セスすることに基づいて、ステージに定義された処理操作のセットを実装する、ストリー
ム処理ステージの入力データストリームの特定のパーティションを選択し、（ｂ）テーブ
ルに格納された特定の入力に、第１のワーカノードに特定のパーティションの割り当ての
表示を書き込みし、（ｃ）第１のワーカノードによって、マルチテナントのストリーム管
理サービスで実装されるプログラムによるレコード検索のインタフェースを使用して、特
定のパーティションのレコードを検索し、（ｄ）第１のワーカノードによって、特定のパ
ーティションのレコード上の処理操作のセットを実装し、（ｅ）第２のワーカノードによ
って、少なくとも部分的に特定のデータベーステーブル中の特定の入力に基づいて、第１
のワーカノードが特定のパーティション上の処理操作のセットを実行するために割り当て
られることを決定し、及び（ｆ）第２のワーカノードによって、処理操作のセットを実行
するための異なるパーティションを選択する。ワーカノードがこれ以上のレコードが割り
当てられないパーティション内に留まることを決定する場合またはするときに、ワーカノ
ードはＳＭＳ制御サブシステムから入力ストリーム上でメタデータを要求してよく、メタ
データが不一致を示した場合にはＰＡテーブルをアップデートしてよい。

図２６は、少なくともいくつかの実施形態による、ワークロードの調節に使用されるパ
ーティションの割り当てテーブル２５５０に格納され得る入力の例を示す。ここに示すよ
うに、テーブル２５５０は、パーティション識別子カラム２６１４，割り当てられたワー
カノード識別子カラム２６１８，ワーカノードヘルスインジケータカラム２６２０及びワ
ークロードレベルインジケータカラム２６２２の４つのカラムを備える。その他のカラム
セットがその他の実装において実装され得る。例えば、パーティション作成時間を示すカ
ラムまたはパーティション機能出力値範囲がいくつかの実施形態で使用され得る。または
ワークロードレベルインジケータカラムは使用されなくてよい。

いくつかの実施形態においては、ＳＭＳ制御サブシステム（例えば、パーティション入
力ツリーの一部として、前述したグラフまたはその他の組み合わされたデータ構造）によ
って維持されたパーティションリスト２６５０は、少なくともある時点において、ＰＡテ
ーブル２５５０に含まれるよりも多くのパーティションを含むことに注意する。図示され
た実施例において、パーティションリスト２６５０は、パーティションＰ１、Ｐ２、Ｐ３
、Ｐ４及びＰ５を含み、パーティションＰ１及びＰ４は再分割の結果、閉じられた状態に
示され、一方、パーティションＰ２、Ｐ３及びＰ５は動作中である（すなわち、データレ
コードが現在検索され処理されているパーティション）。ＰＡテーブル２６５０は、図示
された実施形態において動作中のパーティションのための入力を含み、閉じられたパーテ
ィションのための入力を含まない（例えば、再分割が行われた後、ｇｅｔＳｔｒｅａｍＩ
ｎｆｏの起動に対応して取得されたときに、ワーカノードによって削除された可能性があ
る）少なくともいくつかの実装においては、ストリームの現在開いているパーティション
のすべてが、所与の時間でＰＡテーブルにおいてそれぞれの入力を必ずしも有しない可能
性がある。その代わりに、例えば、現在割り当てられ、または処理中の、それらのパーテ
ィションのサブセットのみが示され得る。

図２６に示された例示的な場合においては、パーティションＰ１及びＰ２は、識別子Ｗ
７及びＷ３をそれぞれ有するワーカノードに割り当てられ、一方、Ｐ５は現時点では、割
り当てられていない。ヘルスインジケータカラム２６２０は、異なる実装において、異な
る種類の値を格納し得る。いくつかの実装においては、ワーカノードは定期的に（例えば
、毎Ｎ秒に一度、またはヒューリスティックスのいくつかのセットに基づいたスケジュー
ルによって）、割り当てられたパーティションのＰＡ入力中のヘルスインジケータカラム
のコンテンツをアップデートして、ワーカノードが動作中であり、検索及び処理操作を継
続可能であることを示す役割をし得る。図２６において、その入力のためのワーカノード
がヘルスインジケータカラムをアップデートした（「最後に修正された時間」）、直近の
時間の表示は、格納され得る。例えば、ワーカＷ７が、２０１３年１２月１日の０２：２
４：５４及び５３秒に入力を修正したと示されている。いくつかの実施形態では、その他
のワーカノードは最後に修正された時刻値を使用して、割り当てられたワーカノードが健
全化否かを判断する。例えば、ステージのためのフェイルオーバポリシにて定義されるよ
うにＸ秒またはＸ分が経過した場合、割り当てられたワーカノードは健全ではないか、ま
たはアクセス不可能であるとされ、パーティションは再割り当てされ得る。その他の実装
においては、カウンタはヘルス状態のインジケータとして使用されてよく、（例えば、カ
ウンタ値がＹ秒で変化しない場合には、割り当てられたワーカノードはフェイルオーバの
ための候補と判断され得る。または、割り当てられたワーカノードが最後に入力を読み出
した時を示す「最終の読み出し時刻」値が使用され得る。

少なくともいくつかの実施形態においては、ワークロードレベルのインジケータ値２６
２２は、例えば、いくつかの最近の時間間隔中（例えば、最後に修正された時刻の前５分
間で）に処理された、いくつかのレコードのような割り当てられたワーカノード、ＣＰＵ
利用、メモリ利用、ストレージ利用などのような最近の性能に関連するワーカノードのメ
トリクスによって、入力に格納され得る。いくつかの実施形態において、このようなワー
クロードレベルのインジケータ値は、図２９に関して下記に記載されるように、負荷の不
均衡が存在するか否かを決定し、検出された不均衡に対応して行動をするために、ワーカ
ノードによって使用され得る。例えば、ワーカノードＷｋは、ワークロードレベルが平均
のワークロードレベルより上であることを判定し、パーティションの一つに割り当てず、
または動的再分割を要求し得る。あるいは、ワーカノードＷｋは、ワークロードがその他
のワーカノードまたはパーティションのワークロードと比較して低すぎると判定し、追加
のパーティション自体に割り当て得る。したがって、図２６に示されたＰＡテーブルのカ
ラムを使用して、ワーカノードは、集中化制御ＳＰＳの実装における、専用のＳＰＳ制御
ノードによって典型的に実行され得る、図示された実施形態における制御プレーンの機能
の類似の種類のいくつかを実行し得る。

図２７は、少なくともいくつかの実施形態による、処理操作を実行するパーティション
を選択するために、ストリーム処理ステージのワーカノードによって実行され得る操作の
態様を示す。要素２７０１に示されるように、ＰＡテーブルＰＡＴ１は、分散された制御
ＳＰＳ処理ステージＳＰ１のために、データベースサービスで初期化され得る。例えば、
テーブルは、ＳＰＳクライアントのライブラリコンポーネントが起動されるときに、例え
ば、クライアントの設備のホストから、またはプロバイダネットワークのデータセンタの
コンピュートインスタンスから作成され得る。クライアントのライブラリは様々な目的に
使用され得る。例えば、ＳＰＳステージで実装される特定の処理操作のためのＪＡＲ（Ｊ
ａｖａ（登録商標）アーカイブ）ファイルのような、実行可能なコンポーネントを提供す
るため、ワーカノードを識別するために使用され得るラベル（プログラム名、プロセス名
またはコンピュートインスタンス名）を表示するため、ステージへの入力に使用されるス
トリームを表示するため、ステージの出力先（もしあれば）を表示するため、等である。
ＰＡＴ１は、いくつかの実施形態では、ステージの入力ストリーム（単数または複数）に
定義された少なくともパーティション｛Ｐ１，Ｐ２，・・・｝のサブセットのための入力
または列に最初に格納され得る。いくつかの実装においては、テーブルは最初は空であっ
てよく、例えば、ＳＭＳ制御サブシステムからのパーティションのメタデータを取得した
結果として、１つ以上のワーカノードはテーブルを割り当てていないパーティションのた
めの列をポピュレートし得る。ワーカノード｛Ｗ１，Ｗ２，・・・｝の初期のセットは、
例えば、プロバイダネットワーク内の様々なコンピュートインスタンスで、またはクライ
アントが所有する計算装置で起動され得る（要素２７０４）。ワーカノードは、図示され
た実施形態において、ＰＡＴ１への読み出し及び書き込みアクセスを許可し得る。

ワーカノードがオンラインなると、それぞれが割り当てられていないパーティションを
見つけるために、ＰＡＴ１にアクセスし得る。例えば、ワーカノードＷ１は、ＰＡＴ１を
調べ、パーティションＰ１が割り当てていないことを見つける（要素２７０７）。Ｗ１は
次にＰＡＴ１のＰ１の入力をアップデートする。例えば、使用されるデータベースサービ
スの種類に応じて、条件付き書き込み要求またはトランザクショナルアップデート要求を
使用して、Ｐ１がＷ１に割り当てられることを示す（要素２７１０）。テーブルをアップ
デートし、Ｗ１は、ＳＭＳ検索サブシステムインタフェース（要素２７１３）を使用して
、Ｐ１のデータレコードの検索を開始し得る。また、検索されたレコード上のステージＰ
Ｓ１の処理操作を実行し得る。

その間、ある時点で、異なるワーカノードＷ２が、割り当てられていないパーティショ
ンを見つめようとＰＡＴ１にアクセスし得る（要素２７１６）。Ｗ２は、Ｗ１の以前のア
ップデートに基づいて、Ｐ１がすでに割り当てられていること、しかし異なるパーティシ
ョンＰ２が割り当てられていないことを判断し得る。いくつかの実施形態では、Ｐ２の現
在の受託者ワーカノードは、Ｗ２によって健全ではないか、動作中ではないことを（Ｐ２
の入力におけるヘルスインジケータカラムに基づいて）判断し、Ｗ２をＰ２を選択するよ
う導き得る。このように、少なくともいくつかの実施形態においては、割り当てられてい
ない状態または現在のワーカノードの健全ではない状態の判断の何れかは、再割り当て（
または最初の割り当て）のために所与のパーティションを選択するために使用され得る。
Ｗ２は、次にＰＡＴ１をアップデートしてそれ自体をＰ２を割り当てるよう試み得る（要
素２７１９）。アップデートが成功した場合には、Ｗ２はＰ２レコードをＳＭＳ検索イン
タフェース（要素２７２２）を使用して検索し始め、ステージのために定義された適切な
処理操作を実行し始める。

前述のように、分散された制御ＳＰＳワーカノードは、典型的には低頻度で、ＳＭＳか
らマッピング情報を取得してよく、必要に応じてＰＡテーブルをアップデートするための
このような情報を使用し得る。図２８は、少なくともいくつかの実施形態による、ストリ
ーム管理サービス制御サブシステムから取得された情報に基づいて、パーティション割り
当てテーブルをアップデートするために、ストリーム処理ステージのワーカノードによっ
て実行され得る操作の態様を示す。要素２８０１に示されるように、割り当てられたパー
ティションの１つを閉鎖するようなワーカノードの初期化中、または様々なトリガ条件に
対応して、ワーカノードＷ１は最新の若しくは現在のパーティションリストまたは非アク
ティブのパーティションリストを取得するために、ＳＭＳ制御サブシステムへ要求を送信
し得る。いくつかの実装においては、ｇｅｔＳｔｒｅａｍＩｎｆｏまたは類似のＡＰＩは
、この目的で起動され得る。その他のトリガ条件はいくつかの実施形態において使用され
得る。例えば、ワーカノードは無作為な時間量後に新規のパーティションリストを取得す
るようそれぞれ構成され得る。またはワークロードレベルにおける予期しない減少若しく
は増加に対応して取得するよう構成され得る。ＳＭＳによって返されたパーティションリ
ストは、パーティションのためのＰＡテーブル中の入力と比較され得る（要素２８０７）
。不一致が明らかになる場合には、（例えば、ＰＡテーブル中に存在しない、新規に取得
されたパーティションリストにいくつかのパーティションがある場合、またはＳＭＳのリ
ストに存在しないＰＡテーブル中の入力がある場合には、ワーカノードは、図示された実
施形態の不一致を解決するために、ＰＡテーブル中の入力を挿入または削除し得る（要素
２８１０）。（いくつかの実施形態においては、現在、削除を対象とする入力は、割り当
てられたワーカノードを有する場合には、追加の調整が必要となり得る。例えば、割り当
てられたワーカノードは、直接またはＰＡテーブル自体を介して通知され得る）。

不一致が修正された後、または不一致が検出された場合には、ワーカノードＷ１は、ス
テージの処理操作を実行すべきパーティションのセットを選択し（要素２８１３）、した
がってＰＡテーブルをアップデートし得る。場合によっては、検索されたパーティション
リストに導くトリガ条件に応じて、Ｗ１は、すでに割り当てられた１つ以上のパーティシ
ョンを有し、割り当てを変更するかＰＡテーブルをアップデートする必要がない。Ｗ１は
次に、ＳＭＳ制御サブシステムと相互作用し、ＰＡテーブルのいくつかの入力を変更する
必要なく、割り当てられたパーティションのデータレコードの検索及びレコードの処理に
進み得る（要素２８１６）。最終的に、トリガ条件が検出されると、（例えば、「パーテ
ィションの最後に到達した」ことに相当する応答が検索要求に受信され、パーティション
が閉鎖されたことを示す。Ｗ１は新しいパーティション情報のためにＳＭＳ制御サブシス
テムへの要求を再度、送信し、要素２８０１以降の操作が繰り返され得る。

図２９は、少なくともいくつかの実施形態による、ストリーム処理ステージのワーカノ
ードによって実行され得る負荷分散操作の態様を示す。要素２９０１に示されるように、
ワーカノードＷ１は、負荷分散分析は、高リソース利用レベルの検出のような、様々なト
リガ条件のいずれかの検出によって、または構成可能なスケジュールに基づいて、ステー
ジ上で実行されると判断し得る。Ｗ１はステージのために様々なワークロードメトリクス
を判断するためＰＡテーブル（要素２９０４）の入力を調査し得る。このようなメトリク
スは、ワーカノードに割り当てられた平均の数のパーティション、（ワークロードレベル
インジケータがテーブルに保存される実施形態において）ワーカノードの平均ワークロー
ドレベルまたは異なるパーティションの平均ワークロードレベル、ワーカノードのワーク
ロード毎の範囲または分散等を含み得る。

Ｗ１は、次にワークロードを、（例えば、Ｗ１に割り当てられたいくつかのパーティシ
ョンに基づいて、及び／またはパーティション毎のワークロードレベルインジケータに基
づいて）いくつかまたはすべてのメトリクスと比較する。一般的に、Ｗ１が過負荷であり
、Ｗ１が負荷が少ない、またはＷ１のワークロードが高すぎもなく低過ぎもないという、
３つの種類の結果のいずれかが描かれ得る。「高すぎる」または「低すぎる」ワークロー
ドレベルは、いくつかの実施形態において、代表してステージが構成されるクライアント
によって選択されたポリシによって、またはその他の実施形態における発見のいくつかの
デフォルトのセットを使用して、定義され得る。Ｗ１がワークロードが、例えば、いくつ
かの最低負荷の閾値Ｔ１未満のように、低すぎると判断した場合には（要素２９０７）、
よりビジーまたはより高負荷のワーカノードＷｋが識別され得る（要素２９１０）。Ｗ１
は、次に、１つ以上のパーティションＰｍをＷｋからＷ１自身（要素２９１３）に転送す
るプロセスを開始し得る。例えば、ＰＡテーブルのＰｍ入力を修正することを試みること
によって、このような（Ｗｋのために生成された通知がもたらされ得る）修正を要求する
ことによって、またはＷｋを直接要求することによって、開始し得る。

Ｗ１は、ワークロードが、例えば、最大閾値Ｔ２を超えるように、高すぎると判断した
場合には（要素２９１６）、放棄するために（すなわち、その他のワーカノードによって
割り当てをリリースするために）（要素２９１９）、１つ以上の割り当てられたパーティ
ションＰｎを識別し得る。Ｗ１は、次に、例えば、ＰＡテーブルのＰｎのための入力の受
託者カラムから識別子を削除することによって、適切な入力を修正し得る（要素２９２２
）。Ｗ１のワークロードが高すぎもなく低過ぎもない場合には、またはＷ１は、ワークロ
ードを増加または減少するために、上述の動作の種類をとった後に、Ｗ１は、割り当てら
れるパーティションのレコードの処理を開始し得る（要素２９２５）。別の負荷分散の分
析をトリガする条件が合致するとき、または合致する場合には、要素２９０１以降に対応
する操作が繰り返され得る。図２９に示された操作において、Ｗ１は、ワークロードに対
して不均衡を検出する場合に限り、ワークロードの変化を開始として示されるであること
に注意する。その他の実施形態では、Ｗ１は、Ｗ１自身よりもその他のワーカノードの間
の不均衡を検出する場合、例えば、Ｗ２がＷ３よりも低いワークロードレベルを有すると
判断した場合には、再度均衡をとる動作を開始し得る。いくつかの実装においては、Ｗ１
は、ワークロードの不均衡を検出した場合、または検出するとき、（例えば、図３または
その等価に示されたような、ｒｅｐａｒｔｉｔｉｏｎＳｔｒｅａｍ ＳＭＳ ＡＰＩを起
動することによって）動的再分割を要求または開始し得る。いくつかの実施形態では、図
２９に示された操作の種類は、新しく構成されたワーカノードによって実行され得る。例
えば、ステージがすでにしばらくの間操作された後、新しいノードがステージに加えられ
るときに、新しいノードは、過負荷の現在のノードからパーティションの再割り当てを要
求することによって、間接的に、現在のノードの有無を通知し得る。いくつかの実施形態
では、ＳＰＳワーカノードのために、上記に類似する分散された制御技術は、１つ以上の
ＳＭＳサブシステムで使用され得るまたは代わりに使用される。例えば、取り込み、記憶
または検索サブシステムのノードは、ＰＡテーブルに類似する共有されたデータ構造を使
用してワークロードを調整し得る。

様々な実施形態では、図１７〜図２４及び図２７〜図２９のフローチャートに示された
もの以外の操作は、上記のストリーム管理サービス及び／またはストリーム処理機能を実
装するために使用され得ることに注意する。示された操作のいくつかは、いくつかの実施
形態において実装されなくてよい。または異なる順で実装されるか、または連続して実装
されるよりもむしろ、並行して行われ得る。プログラムによるインタフェースが様々な実
施形態において支援される、ＳＭＳ及びＳＰＳの機能のそれぞれに関して、１つ以上の技
術の任意の組み合わせが、ウェブページ、ウェブサイト、ウェブサービスＡＰＩ、その他
のＡＰＩ、コマンドラインツール、グラフィカルユーザインターフェース、モバイルアプ
リケーション（ａｐｐ）、タブレットアプリケーション等の使用を含む、インタフェース
を実装するために使用され得ることにも注意する。

ユースケース
スケーラブルなパーティションベース、収集、検索及び段階的なストリームデータレコ
ードの処理のため、動的に構成可能に管理されたマルチテナントサービスを確立する、上
記の技術、いくつかの場合において有用であり得る。例えば、大きなプロバイダネットワ
ークは、いくつかの異なるマルチテナントのサービスインスタンスまたは同時に何万もの
クライアントに対するシングルテナントを実装する、何千ものインスタンスホストを備え
得る。様々なインスタンス及びホストにインストールされた監視及び／または課金エージ
ェントは、プロバイダネットワークのデータセンタに効果的なプロビジョニングプランを
決定するため、ネットワーク攻撃等を検出するなどのために、正確な課金レコードを生成
するために格納され分析される必要があり得る、何千ものメトリクスレコードを迅速に生
成し得る。監視レコードは、スケーラブルな取り込み及び格納のために、ＳＭＳに入力ス
トリームを形成し得る。また、記載されたＳＰＳ技術は、収集されたメトリクスの分析の
ために実装され得る。同様に、多数のログソースから大多数のログレコードを収集し分析
するアプリケーション（例えば、分散されたアプリケーションのノードからのアプリケー
ションログ、またはデータセンタにおけるホストまたはコンピュートインスタンスからシ
ステムログ）は、また、ＳＭＳ及びＳＰＳの機能を利用可能であり得る。少なくともいく
つかの環境においては、ＳＰＳ処理操作は、リアルタイムのＥＴＬ（抽出変換負荷）処理
操作（すなわち、オフラインで変換する代わりに、宛先にロードするために、リアルタイ
ムで受信されたデータレコードを変換する操作）またはデータウェアハウスに挿入するた
めにデータレコードの変換を備え得る。リアルタイムでデータウェアハウスにデータをロ
ードするために、ＳＭＳ及び／またはＳＰＳの組み合わせを使用することは、データが分
析のためにウェアハウスに挿入可能である前に、典型的には、１つ以上のデータソースか
らクリーンでキュレートなデータを必要とする遅延を回避し得る。

いくつかの異なる「ビッグデータ」のアプリケーションもまた、ＳＭＳ及びＳＰＳ技術
を使用して構築され得る。例えば、様々な形式のソーシャルメディアの相互作用における
トレンド分析が、ストリームを使用して効率的に実行され得る。ユーザの位置情報のよう
な、携帯電話またはタブレット型コンピュータから収集されたデータはストリームレコー
ドとして管理され得る。例えば、全監視カメラから収集されたオーディオまたはビデオ情
報は、スケーラブルな方法で収集され処理され、場合により様々な種類の攻撃を防ぐ助け
となり得る、ストリーミングデータセットの別のカテゴリを表し得る。例えば気象衛星、
海洋ベースのセンサ、森林ベースのセンサ、天体望遠鏡から収集された、増える一方のデ
ータセットの分析を必要とする科学研究用のアプリケーションは、また、本明細書に記載
されたストリーム管理及び処理能力から利益を得られ得る。適応性のあるポリシベースの
構成の選択肢及び価格設定は、異なる種類のユーザがストリーミングの機能性を特定の予
算及びデータの耐久性／可用性の必要条件に適合するように、カスタマイズするのを支援
し得る。

本開示の実施形態は、以下の条項を考慮して記載され得る。
１．
システムは、
１つ以上の計算装置であって、
マルチテナントストリーム管理サービスのクライアントが、特定のデータストリームに
、複数のデータ取り込みポリシの中からデータ取り込みポリシを選択するのを可能にする
プログラムによるインタフェースの第１のセットを実装し、複数のデータ取り込みポリシ
は、レコード送信者が１回以上データレコードの表示をストリーム管理サービスに肯定応
答が受信されるまで伝送することによる少なくとも１回の取り込みポリシを含み、
クライアントが特定のデータストリームのために、複数のデータ永続性ポリシから、デ
ータの永続性ポリシを選択するのを可能にするプログラムによるインタフェースの第２セ
ットを実装し、データレコードの多数の複製のどちらがストリーム管理サービスによって
それぞれの記憶位置に格納されるかにより、複数のデータ永続性ポリシは多数の複製の永
続性ポリシを含み、
第１及び第２のセットのそれぞれのプログラムによるインタフェースを介してストリー
ム管理サービスで、クライアントが特定のデータストリームのために、少なくとも１回の
取り込みポリシを選択したことの第１の表示と、クライアントが特定のデータストリーム
のために多数の複製永続性ポリシを選択したという第２の表示を受信し、
特定のデータレコードをストリーム管理サービスに示す複数の伝送に対応して、少なく
とも１回の取り込みポリシによる複数の転送に対応する少なくとも１つの肯定応答を送信
し、
複数の伝送の特定の伝送に対応して、多数の複製の永続性ポリシによる複製の記憶位置
で、特定のデータレコードのコピーを格納するよう構成された計算装置を備える、システ
ム。
２．
どちらのストリーム管理サービスが、対応する肯定応答をレコード送信者に提供せずに
、少なくともいくつかの特定したストリームのデータレコードを受け入れ及び格納するべ
きかにより、複数のデータ取り込みポリシがベストエフォートの取り込みポリシを備える
、条項１にて説明されるシステム。
３．
クライアントによって選択された多数の複製永続性ポリシが、データレコードのコピー
の格納に使用される記憶位置の種類の表示を備え、記憶位置の種類は、（ａ）磁気ディス
クベースのストレージ、（ｂ）ソリッドステートドライブ（ＳＳＤ）、（ｃ）揮発性ＲＡ
Ｍ（ランダムアクセスメモリ）、（ｄ）不揮発性ＲＡＭ、（ｅ）データベース管理システ
ム、または（ｆ）プロバイダネットワークによって実装されるネットワークにアクセス可
能なストレージサービスのストレージノード、のうち１つを備える、条項１にて説明され
るシステム。
４．
クライアントによって選択された多数の複製永続性ポリシは、要求されたデータ耐久性
レベルの表示を備え、１つ以上の計算装置がさらに、少なくとも部分的に要求されたデー
タの耐久性レベルに基づいて複数の記憶位置を選択するよう構成される、条項１にて説明
されるシステム。
５．
１つ以上の計算装置はさらに、特定のクライアントが少なくとも部分的に、（ａ）特定
のクライアントによって選択されたデータ取り込みポリシ、及び（ｂ）特定のクライアン
トによって選択されたデータ永続性ポリシのうち、１つ以上に基づいてストリーム管理操
作に請求される請求額を決定するよう構成される、条項１にて説明されるシステム。
６．
プログラムによるインタフェースのセットを実装して、ストリーム管理サービスのクラ
イアントが、複数のデータ取り込みポリシの中から、特定のデータストリームのためにデ
ータ取り込みポリシを選択するのを可能にし、
複数のデータ取り込みポリシは、どちらのレコード送信者が１回以上データレコードの
表示を、ストリーム管理サービスに肯定応答が受信されるまで伝送するべきかによって、
少なくとも１回の取り込みポリシを含み、
プログラムによるインタフェースのセットを介して要求を受信し、クライアントが少な
くとも１回の取り込みポリシを特定のデータストリームのために選択したことを示し、
ストリーム管理サービスにおいて特定のデータレコードを示す複数の送信の受信に対応
して、
少なくとも１回の取り込みポリシによって、複数の伝送の各伝送に対応する、それぞ
れの肯定応答を送信し、
複数の伝送のうち特定の伝送の受信に応答して格納し、特定のデータストリームのた
めに選択されたデータ永続性ポリシにより、１つ以上の記憶位置での特定のデータレコー
ドのコピーを格納することを、１つ以上の計算装置によって実行することを含む方法。
７．
どちらのストリーム管理サービスが、対応する肯定応答をレコード送信者に提供せずに
、特定されたストリームの少なくともいくつかのデータレコードを受け入れ及び格納する
べきかにより、複数のデータ取り込みポリシがベストエフォートの取り込みポリシを備え
る、条項６にて説明される方法。
８．
少なくとも１回の取り込みポリシにより、ストリーム管理サービスが複製されたデータ
レコードを削除するよう構成される、条項６にて説明される方法。
９．
少なくとも１回の取り込みポリシにより、ストリーム管理サービスが、複数の伝送に対
応して、特定のデータレコードのうち２つ以上のコピーを格納するよう構成される、条項
６にて説明される方法。
１０．
クライアントが特定のデータストリームのために、複数のデータ永続性ポリシから、デ
ータの永続性ポリシを選択するのを可能にするプログラムによるインタフェースの第２セ
ットの実装を、１つ以上の計算装置によって実行することをさらに含む、条項６にて説明
される方法。
１１．
複数のデータ永続性ポリシが、多数の複製永続性ポリシと、単一の複製永続性ポリシを
含む、条項１０にて説明される方法。
１２．
データ永続性ポリシがデータレコードを格納するために使用される記憶位置の種類の表
示を備え、記憶位置の種類は、（ａ）磁気ディスクベースのストレージ、（ｂ）ソリッド
ステートドライブ（ＳＳＤ）、（ｃ）揮発性ＲＡＭ（ランダムアクセスメモリ）、（ｄ）
不揮発性ＲＡＭ、（ｅ）データベース管理システム、または（ｆ）プロバイダネットワー
クによって実装されるネットワークにアクセス可能なストレージサービスのストレージノ
ードのうちの１つを備える、条項１０にて説明される方法。
１３．
データ永続性ポリシは特定のデータストリームの第１パーティションに使用される記憶
位置の第１種類の表示と、特定のデータストリームの第２のパーティションに使用される
記憶位置の異なる種類の表示と、を備える、条項１０にて説明される方法。
１４．
クライアントによって選択されたデータ永続性ポリシは、データレコードを格納するた
めに使用される記憶位置の種類の表示を含まず、データレコードは、１つ以上の計算装置
によって、ストリーム管理サービスの１つ以上のコンポーネントにより、データレコード
を格納するために使用される記憶位置の種類の選択を実行することをさらに含む、条項１
０にて説明される方法。
１５．
記憶位置の種類を選択することが、特定のデータストリームの第１のパーティションの
ための記憶位置の第１の種類を選択し、特定のデータストリームの第２のパーティション
のための記憶位置の異なる種類を選択することを含む、条項１４にて説明される方法。
１６．
データ永続性ポリシが目標の待ち時間の表示を含み、ストリーム管理サービスの１つ以
上のコンポーネントによって、データレコードを少なくとも部分的に目標の待ち時間に基
づいて格納するために使用される記憶位置の種類を選択１つ以上の計算装置によって実行
されることをさらに含む、条項１０にて説明される方法。
１７．
クライアントによって選択されたデータ永続性ポリシが、要求されたデータの耐久性レ
ベルの表示を含み、１つ以上の計算装置によって、少なくとも部分的に要求されたデータ
耐久性レベルに基づいてストリームのデータレコードが格納された複数の記憶位置の選択
をさらに含む、条項１０にて説明される方法。
１８．
１つ以上の計算装置によって、（ａ）特定のクライアントによって選択されたデータ取
り込みポリシ、及び（ｂ）特定のクライアントによって選択されたデータ永続性ポリシの
うち少なくとも部分的に１つ以上に基づいて、特定のクライアントがストリーム管理操作
に対して請求されるべき請求額を決定することの実行をさらに含む、条項６にて説明され
る方法。
１９．
（ａ）特定のデータレコードの１つ以上の属性に基づいて、特定のデータレコードが特
定のパーティションのメンバとして指定され、（ｂ）いくつかのデータ取り込みノードの
うちのデータ取り込みノードが、特定のパーティションのデータレコードを取り込むため
に選択されることによる、少なくとも部分的にパーティションポリシに基づいて特定のデ
ータストリームのために構成されるいくつかのデータ取り込みノードの決定を１つ以上の
計算装置によって実行することをさらに含む、条項６にて説明される方法。
２０．
（ａ）特定のデータレコードの１つ以上の属性に基づいて、特定のデータレコードが特
定のパーティションのメンバとして指定され（ｂ）いくつかのデータストレージノードの
うちのデータストレージノードが、特定のパーティションのデータレコードを格納するた
めに選択されることにより、少なくとも部分的にパーティションポリシに基づいて、いく
つかのデータストレージノードが特定のデータストリームを構成するよう決定することを
、１つ以上の計算装置によって、実行することをさらに含む、条項６にて説明される方法
。
２１．
特定のデータストリームの複数のデータレコードの各データレコードに対応して、特定
のデータレコードを含む、並べられたデータレコードのセットに対する読み出し要求に応
答することが不可能な、それぞれのシーケンス番号を格納し、
データストリームの異なるデータレコードの送信者から、異なるデータレコードに対応
する格納される最小のシーケンス番号の表示を受信し、
異なるデータレコードに対応して、最小のシーケンス番号より大きいかまたは等しい特
定のシーケンス番号を格納することを、１つ以上の計算装置によって実行することをさら
に含む、条項６にて説明される方法。
２２．
特定のデータストリームのために、クライアントがストリーム管理サービスを選択可能
にするプログラムによるインタフェースのセットを実装し、そのデータレコードは、選択
されたデータ取り込みポリシに基づいてストリームに取り込まれ、複数のデータ永続性ポ
リシは、（ａ）特定のデータストリームのデータレコードの多数のコピーによる多数の複
製永続性ポリシがそれぞれの記憶位置に格納され、（ｂ）特定のデータストリームのデー
タレコードの単一コピーが格納される、単一の複製永続性ポリシを含み、
プログラムによるインタフェースのセットを介して要求を受信し、クライアントが多数
の複製永続性ポリシを特定のデータストリームのために選択したことを示し、
特定のデータストリームのデータレコードのために、多数の複製永続性ポリシを実装す
るために、複数のストレージノードを構成する、１つ以上のプロセッサ上で実行される場
合に、プログラムの命令を格納する、非一時的にコンピュータにアクセス可能な記憶媒体
。
２３．
条項２２にて説明されるように、非一時的コンピュータでアクセス可能な記憶媒体であ
って、複数のデータ永続性ポリシのうちの、少なくとも１つのデータ永続性ポリシがデー
タレコードを格納するために使用される記憶位置の種類を示すことを含み、記憶位置の種
類は、（ａ）磁気ディスクベースのストレージ、（ｂ）ソリッドステートドライブ（ＳＳ
Ｄ）、（ｃ）揮発性ＲＡＭ（ランダムアクセスメモリ）、（ｄ）不揮発性ＲＡＭ、（ｅ）
データベース管理システム、または（ｆ）プロバイダネットワークによって実装されるネ
ットワークにアクセス可能なストレージサービスのストレージノードのうちの１つを備え
る、記憶媒体。
２４．
条項２２にて説明されるように、非一時的コンピュータでアクセス可能な記憶媒体であ
って、クライアントによって選択された多数の複製永続性ポリシが、要求されたデータの
耐久性レベルの表示を含み、１つ以上のプロセッサ上で実行される命令は、少なくとも部
分的に要求されたデータ耐久性レベルに基づいて、構成されるいくつかのストレージノー
ドを決定する、記憶媒体。
２５．
条項２２にて説明されるように、非一時的コンピュータでアクセス可能な記憶媒体であ
って、１つ以上の計算装置によって、少なくとも部分的に特定のクライアントによって選
択されたデータ永続性ポリシに基づいて、特定のクライアントがストリーム管理操作に対
して請求される請求額の決定を実行することをさらに含む、記憶媒体。
２６．
条項２２にて説明されるように、非一時的コンピュータでアクセス可能な記憶媒体であ
って、（ａ）特定のデータレコードの１つ以上の属性に基づいて、特定のパーティション
のメンバとして特定のデータレコードが指定され、（ｂ）いくつかのデータストレージノ
ードのうちのデータストレージノードが、特定のパーティションのデータレコードを格納
するために選択されることにより、少なくとも部分的にパーティションポリシに基づいて
、特定のデータストリームのために構成されるいくつかのデータストレージノードの決定
を１つ以上の計算装置によって実行することをさらに含む、記憶媒体。
２７．
マルチテナントストリーム管理サービスの複数のノードのうち、データストリームのデ
ータレコードを分散するために適用されるパーティションポリシを決定し、パーティショ
ンポリシは、データレコードに関連する、少なくとも部分的に１つ以上の属性値に基づい
て、複数のパーティションにデータレコードの初期のマッピングを含み、
初期のマッピングを使用して、少なくとも部分的に特定の属性値に基づいて、データス
トリームの特定のデータレコードがメンバを指定される第１のパーティションを識別し、
特定のデータレコードに対応して、ストリーム管理サービスの取り込みノードでレコー
ド取得シーケンス内の特定のデータレコードの位置を示す、シーケンス番号を生成し、取
り込みノードは少なくとも部分的に初期のマッピングに基づいて選択され、
複数のデータレコードのそれぞれのシーケンス番号に少なくとも部分的に基づいて、ス
トリーム管理サービスのデータ記憶位置の順で第１のパーティションの複数のデータレコ
ードを格納し、データ記憶位置は、少なくとも部分的に初期のマッピングに基づいて選択
され、
データストリームを再分割するためのトリガ条件が合致したという決定に対応して、デ
ータレコードの修正されたマッピングをパーティションに生成し、データストリームのデ
ータレコード取得における一時停止をスケジューリングなしに修正されたマッピングの使
用を開始し、特定の属性値で別のデータレコードのために選択し、その他のデータレコー
ドは、（ａ）ストリーム管理サービスの異なる取り込みノードまたは（ｂ）ストリーム管
理サービスの異なるデータ格納位置のうち少なくとも１つで修正されたマッピングの使用
の開始に続いて受信されるよう構成された、１つ以上の計算装置を備えるシステム。
２８．
シーケンス番号は（ａ）特定のデータレコードの取り込みに関連するタイムスタンプ、
及び（ｂ）追加のサブシーケンス値の表示を含む、条項２７にて説明されるシステム。
２９．
条項２８にて説明されるシステムであって、１つ以上の計算装置がさらに
修正されたマッピングを使用してマップされたデータレコードのシーケンス番号に使用
される初期のタイムスタンプ値を選択し、
特定のシーケンス番号を示すデータレコードの検索要求に対応して特定のシーケンス番
号によって示された特定のタイムスタンプの値が初期のタイムスタンプ値よりも低いとい
う決定に対応して、１つ以上のデータレコードを検索するために初期のマッピングを利用
し、
特定のタイムスタンプ値が初期のタイムスタンプ値よりも低くないという決定に対応し
て、１つ以上のデータレコードを検索するために修正されたマッピングを利用するよう構
成される、システム。
３０．
トリガ条件が（ａ）オーバーロードの状態の検出、（ｂ）ワークロードの不均衡の検出
、（ｃ）再分割のクライアントの要求、（ｄ）データストリームにおけるデータの耐久性
要件の変更を決定、（ｅ）ソフトウェアのバージョン変更のスケジュールの決定、（ｆ）
データストリームの使用状況の変化を検出（ｇ）データストリームの再分割の価格の影響
の決定、または（ｈ）データストリームに関連する性能ターゲットの決定のうち、１つ以
上を含む、条項２７にて説明されるシステム。
３１．
１つ以上の計算装置であって、データストリームに使用される１つ以上のパーティショ
ン基準を示すクライアントの要求を受信し、少なくとも部分的にクライアントの要求に基
づいて、初期のマッピングを生成することをさらに含む、条項２７にて説明されるシステ
ム。
３２．
データレコードの少なくとも部分的に１つ以上の属性値に基づいて複数のパーティショ
ンにデータストリームのデータレコードの初期のマッピングを決定し、
初期のマッピングを使用して、少なくとも部分的に特定の属性値に基づいて、データス
トリームの特定のデータレコードがメンバを指定する第１のパーティションを識別し、
初期のマッピングに少なくとも部分的に基づいて選択された記憶位置で特定のデータレ
コードを格納し、
トリガ条件が合致するという決定に対応して、修正されたデータレコードのマッピング
をパーティションに生成し、特定の属性値で別のデータレコードのために選択し、
その他のデータレコードは、修正されたマッピング、異なる記憶位置の使用の開始に
続いて受信されることを、ストリーム管理サービスの１つ以上の計算装置によって実行す
ることを含む方法。
３３．
トリガ条件が合致したという決定の前に特定のデータレコード上で、少なくとも部分的
に初期のマッピングに基づいて、選択されたワーカノードで処理操作を実行し、
トリガ条件が合致したという決定の後に、特定の属性値で異なるデータレコード上で、
少なくとも部分的に修正されたマッピングに基づいて選択された、異なるワーカノードで
処理操作を１つ以上の計算装置によって実行することをさらに含む、条項３２にて説明さ
れる方法。
３４．
特定のデータレコードに対応して、ストリーム管理サービスの取り込みノードでレコード
取得シーケンス内の特定のデータレコードの位置を示す、シーケンス番号を生成し、
取り込みノードは少なくとも部分的に初期のマッピングに基づいて選択され、
シーケンス番号に対応して第１のパーティションのデータレコードを順番に格納するこ
とを、１つ以上の計算装置によって実行することをさらに含む、条項３２にて説明される
方法。
３５．
シーケンス番号は（ａ）特定のデータレコードの取り込みに関連するタイムスタンプ、
及び（ｂ）追加のサブシーケンス値を含む、条項３４にて説明される方法。
３６．
タイムスタンプが、特定のデータレコードが取り込まれた時刻を示し、１つ以上の計算
装置によって、少なくとも部分的に特定のレコードの取り込む時間範囲に基づいて、１つ
以上のデータレコードが検索されることを要求する検索要求に対応して、１つ以上のデー
タレコードを検索するために、インデックスキーとして１つ以上のデータレコードに関連
するシーケンス番号の使用を実行することをさらに含む条項３５にて説明される方法。
３７．
修正されたマッピングを使用してマップされたデータレコードのシーケンス番号に使用
される初期のタイムスタンプ値を選択し、
特定のシーケンス番号を示すデータレコードの検索要求の受信に対応して、
特定のシーケンス番号によって示された特定のタイムスタンプの値が初期のタイムスタ
ンプ値よりも低いという決定に対応して、１つ以上のデータレコードを検索するために初
期のマッピングを利用し、
特定のタイムスタンプの値が初期のタイムスタンプ値よりも低くないという決定に対応
して、１つ以上のデータレコードを検索するために修正されたマッピングの使用を１つ以
上の計算装置によって実行することをさらに含む、条項３５にて説明される方法。
３８．
修正されたマッピングは少なくとも１つの追加の属性値を使用してデータレコードのパ
ーティションを決定する、条項３２にて説明される方法。
３９．
１つ以上の計算装置によって、
データストリームに使用される１つ以上のパーティション基準を示すクライアントの要
求を受信し、
少なくとも部分的にクライアントの要求に基づいて、初期のマッピングの生成を実行す
ることをさらに含む、条項３２にて説明される方法。
４０．
１つ以上の計算装置によって、トリガ条件を示すクライアントの要求を受信を実行する
ことをさらに含む、条項３２にて説明される方法。
４１．
１つ以上の計算装置によって、データストリームを再分割するクライアントの要求を受
信し、クライアントの要求は修正されたマッピングの１つ以上のパラメータを示すことを
実行することをさらに含む、条項３２にて説明される方法。
４２．
１つ以上の計算装置によって、再分割を介して潜在的な解決のために問題状態を示すク
ライアントの要求の受信を実行することをさらに含む、条項３２にて説明される方法。
４３．
選択されたビット数を含む、バイナリ値として表されるハッシュ結果を取得するために
、特定のデータレコードのコンテンツの少なくとも部分的にハッシュ関数を適用し、
選択されたビット数を使用してバイナリ値が表され得る範囲の、ハッシュ結果が属する
特定の副範囲を決定し、
少なくとも部分的に副範囲に基づいて第１パーティションの識別を、１つ以上の計算装
置によって、実行することをさらに含む、条項３２にて説明される方法。
４４．
（ａ）データレコードのソースによって提供されたパーティションキー、（ｂ）データ
レコードのソースの識別、（ｃ）データレコードのコンテンツの少なくとも一部、または
（ｄ）データレコードのソースのネットワークアドレスのうち、１つ以上の属性値が少な
くとも１つを含む、条項３２にて説明される方法。
４５．
１つ以上の計算装置によって、修正されたマッピングの生成の後に、ストリーム管理シ
ステムの異なる数のノードを、（ａ）データレコードの取り込み、（ｂ）データレコード
の格納、または（ｃ）修正されたマッピングの生成前に構成されたよりもデータストリー
ムのためのデータレコードの検索のうち１つ以上実行するよう構成されることを実行する
ことをさらに含む、条項３２にて説明される方法。
４６．
初期のマッピング及び修正されたマッピングを表す組み合わされたデータ構造を格納し
、
組み合わされたデータ構造は、（ａ）初期のマッピングによる特定のデータレコードの
属性がマップされる第１のパーティションを示す第１の入力、及び第１のパーティション
に適用可能な初期のマッピングの時間範囲、及び（ｂ）修正されたマッピングによる特定
のデータレコードの属性がマップされる異なるパーティションを示す第２の入力、及び異
なるパーティションに適用可能な修正されたマッピングの異なる時間範囲を含む、条項３
２にて説明される方法。
４７．
組み合わされたデータ構造が（ａ）ツリーまたは（ｂ）有向非巡回グラフのうち１つを
備える、条項４６にて説明される方法。
４８．
修正されたマッピングが初期のマッピングによって示されたパーティションの対の統合
を示すことを含む、条項３２にて説明される方法。
４９．
ストリーム管理サービスの複数のノードのうち、データストリームのデータレコードを
分散するために適用されるパーティションポリシを決定し、
パーティションポリシは、データレコードに関連する、複数のパーティションにデータ
レコードの初期のマッピングを示すことを含み、
初期のマッピングにより、及び、初期のマッピングによるデータレコードを格納するた
めにストリーム管理サービスのデータ格納ノードの第１セットにより、ストリームのデー
タレコードを受信するためにストリーム管理サービスの取り込みノードの第１セットを構
成し、
異なる複数のパーティションにデータレコードの修正されたマッピングを生成し、修正
されたマッピングの生成の後に受信されたデータレコードのために、取り込みノードの異
なるセット及びデータストレージノードの異なるセットを構成し、到着するデータレコー
ドが修正されたマッピングによって格納される、少なくとも特定の時刻のために、初期の
マッピングによるデータノードの第１セットに格納されたデータレコードを保持する、１
つ以上のプロセッサ上で実行される場合に、プログラムの命令を格納する、非一時的にコ
ンピュータにアクセス可能な記憶媒体。
５０．
条項４９にて説明されるように、非一時的コンピュータでアクセス可能な記憶媒体であ
って、１つ以上のプロセッサ上で実行される命令は、初期のマッピングによるデータスト
リームのためのデータ検索ノードの初期のセットを構成し、トリガ条件が合致したという
決定に対応して、データストリームのためのデータ検索ノードの異なるセットを構成する
、記憶媒体。
５１．
トリガ条件が（ａ）オーバーロードの状態の検出、（ｂ）ワークロードの不均衡の検出
、 （ｃ）再分割のクライアントの要求、（ｄ）データストリームにおけるデータの耐久
性要件の変更を決定、（ｅ）ソフトウェアのバージョン変更のスケジュールの決定、（ｆ
）データストリームの使用状況の変化を検出（ｇ）データストリームの再分割の価格の影
響の決定、または（ｈ）データストリームに関連する性能ターゲットの決定のうち、１つ
以上を含む、条項４９にて説明されるように、非一時的コンピュータでアクセス可能な記
憶媒体。
５２．
１つ以上のプロセッサ上で実行される命令は、データストリームに使用される１つ以上
のパーティション基準を示すクライアントの要求を受信し、少なくとも部分的にクライア
ントの要求に基づいて、初期のマッピングを生成する、条項４９にて説明されるように、
非一時的コンピュータでアクセス可能な記憶媒体。
５３．
１つ以上のプロセッサ上で実行される命令が、データストリームを再分割するためのト
リガ条件を示すクライアントの要求を受信する、条項４９にて説明されるように、非一時
的コンピュータでアクセス可能な記憶媒体。

コンピュータシステムの例
少なくともいくつかの実施形態においては、ＳＭＳサブシステム（例えば、取り込み、
格納、検索及び制御サブシステム）のコンポーネントを実装する技術を含む、本明細書に
記載された、一部またはすべての１つ以上の技術を実装するサーバは、ＳＰＳワーカ及び
制御ノードと同様に、１つ以上のコンピュータがアクセス可能な媒体にアクセスすること
を含むか、またはアクセスするよう構成された汎用コンピュータシステムを含み得る。図
３０は、このような汎用計算装置９０００を示す。図示した実施形態では、計算装置９０
００は、入力／出力（Ｉ／Ｏ）インタフェース９０３０を介して、システムメモリ９０２
０に接続された１つ以上のプロセッサ９０１０を含む。計算装置９０００は、さらに、Ｉ
／Ｏインタフェース９０３０に接続されたネットワークインタフェース９０４０を含む。

様々な実施形態では、計算装置９０００は、１つのプロセッサ９０１０を含む、単一プ
ロセッサまたは、いくつかのプロセッサ９０１０を含む、マルチプロセッサシステムであ
り得る（例えば、２、４、８または別の好適な数）。プロセッサ９０１０は、命令を実行
可能な任意の好適なプロセッサであり得る。例えば、様々な実施形態では、プロセッサ９
０１０は、ｘ８６、ＰｏｗｅｒＰＣ、ＳＰＡＲＣまたはＭＩＰＳ ＩＳＡ、または任意の
その他の好適なＩＳＡのような、任意の様々な命令セットアーキテクチャ（ＩＳＡ）を実
行する汎用または組込型プロセッサであり得る。いくつかの実装においては、グラフィッ
クス処理ユニット（ＧＰＵ）は、従来のプロセッサの代わりに、または追加して使用され
得る。

システムメモリ９０２０は、プロセッサ（単数または複数）９０１０によってアクセス
可能な命令及びデータを格納するよう構成され得る。様々な実施形態では、システムメモ
リ９０２０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）、シンクロナスダイミ
ックランダムアクセスメモリ（ＳＤＲＡＭ）、不揮発性／フラッシュタイプのメモリまた
は任意のその他の種類のメモリの種類を使用して実装され得る。図示した実施形態では、
１つ以上の所望の機能を実装する、プログラムの命令及びデータは、これらの方法、技術
及び上述のデータが示され、コード９０２５及びデータ９０２６のように、システムメモ
リ９０２０内に記憶される。

一実施形態では、Ｉ／Ｏインタフェース９０３０は、プロセッサ９０１０と、システム
メモリ９０２０と、データオブジェクトパーティションの物理複製を格納するために使用
される、様々な種類の永続的及び／または揮発性記憶装置のような、ネットワークインタ
フェース９０４０またはその他の周辺インタフェースを含む、装置内の任意の周辺装置と
の間のＩ／Ｏトラフィックを調節するよう構成され得る。いくつかの実施形態では、Ｉ／
Ｏインタフェース９０３０は、１つのコンポーネント（例えば、システムメモリ９０２０
）からデータ信号を変換するために、任意の必要なプロトコル、タイミングまたはその他
のデータ変換を別のコンポーネント（例えば、プロセッサ９０１０）によって使用するの
に適したフォーマットに実行し得る。いくつかの実施形態では、Ｉ／Ｏインタフェース９
０３０は、例えば、周辺構成要素相互接続装置（ＰＣＩ）バス規格の変形またはユニバー
サルシリアルバス（ＵＳＢ）規格のような、様々な種類の周辺のバスを通して取り付けら
れる装置への支援を含み得る。いくつかの実施形態では、Ｉ／Ｏインタフェース９０３０
の機能は、例えば、ノースブリッジ及びサウスブリッジのように、２つまたはそれ以上の
分離したコンポーネントに分かれ得る。また、いくつかの実施形態では、システムメモリ
９０２０へのインタフェースのような、いくつかの、またはすべてのＩ／Ｏインタフェー
ス９０３０の機能は、プロセッサ９０１０に直接組み込まれ得る。

ネットワークインタフェース９０４０は、コンピュータシステムまたは例えば、図１か
ら図２９に図示された装置のような、ネットワークまたはネットワーク９０５０に取り付
けられた、データが計算装置９０００とその他の装置９０６０との間で交換できるように
構成され得る。様々な実施形態では、ネットワークインタフェース９０４０は、例えばイ
ーサネット（登録商標）ネットワークの種類のような、任意の好適な有線または無線の一
般的なデータネットワークを介して、通信を支援し得る。さらに、ネットワークインタフ
ェース９０４０は、ファイバチャネルＳＡＮのようなストレージエリアネットワークを介
して、または任意のその他の好適な種類のネットワーク及び／またはプロトコルを介して
、アナログ音声ネットワークまたはデジタルファイバ通信ネットワークのような、電気通
信／電話網を介した通信を支援し得る。

いくつかの実施形態では、システムメモリ９０２０は、対応する方法及び装置の実施形
態を実装するために、図１から図２９のために上記に記載されたように、プログラムの命
令及びデータを格納するよう構成された、コンピュータでアクセス可能な媒体の一実施形
態であり得る。しかしながら、その他の実施形態では、プログラムの命令及び／またはデ
ータが受信され、送信され、または異なる種類のコンピュータがアクセス可能な媒体に格
納され得る。一般に、コンピュータがアクセス可能な媒体は、磁気または光学媒体のよう
な、非一時的記憶媒体またはメモリ媒体を含み得る。例えば、Ｉ／Ｏインタフェース９０
３０を介して計算装置９０００に接続されたディスクまたはＤＶＤ／ＣＤである。非一時
的コンピュータがアクセス可能な記憶媒体は、また、いくつかの実施形態において、シス
テムメモリ９０２０または別の種類のメモリのように、計算装置９０００中に含まれてよ
い、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭ等）、ＲＯ
Ｍ等のような、任意の揮発性または不揮発性媒体を含み得る。さらに、コンピュータがア
クセス可能な媒体は、ネットワークインタフェース９０４０を経由して実装され得るよう
な、ネットワーク及び／または無線接続のような、電気信号、電磁波信号またはデジタル
信号のような、通信媒体を経由して伝達される伝送媒体または信号を含み得る。図３０に
示されたような、多数の計算装置の一部または全部は、様々な実施形態において、記載さ
れた機能を実装するために使用され得る。例えば、様々に異なる装置及びサーバで実行す
るソフトウェアコンポーネントは、機能性を提供するために一緒に動き得る。いくつかの
実施形態では、汎用コンピュータシステムを使用して実装されることに加えて、またはそ
の代わりに、記憶装置、ネットワーク装置または専用コンピュータシステムを使用して、
記載された機能性の一部は実装され得る。「計算装置」という用語は、本発明で使用する
場合、少なくともすべてのこれらの種類の装置を意味し、これらの種類の装置に限定され
ない。

結論
様々な実施形態は、さらに、コンピュータがアクセス可能な媒体についての前述の記載
により実装される、受信し、送信し、または命令及び／またはデータを格納することを含
み得る。一般に、コンピュータがアクセス可能な媒体は、磁気媒体または光媒体のような
、記憶媒体またはメモリ媒体を含み得る。ネットワーク及び／または無線接続のような、
通信媒体を経由して伝達される、伝送媒体または電気信号、電磁波信号またはデジタル信
号のような信号と同様に、例えば、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ、ＲＤＲＡＭ、
ＳＲＡＭ、ｅｔｃ．），ＲＯＭ等のような、ディスクまたはＤＶＤ／ＣＤ−ＲＯＭ、揮発
性媒体または不揮発性媒体が含み得る。

図面に示され、本明細書で記載された、様々な方法は、例示的な方法の実施形態を表す
。この方法はソフトウェア、ハードウェアまたはこれらの組み合わせにおいて実施され得
る。方法の順序は変更されてよく、様々な要素が追加され、順序が変更され、組み合わさ
れ、省略され、修正等され得る。

様々な修正及び変更が、本開示の利益を有する当業者には明白であるため、成され得る
。すべてのこのような修正及び変更を受け入れることを目的としており、したがって、上
記の記載は制限を意味するよりもむしろ、例証としてみなされるべきである。

Claims (15)

1. マルチテナントのストリーム管理サービスの複数のノードのうち、データストリームのデータレコードを分散するために適用されるパーティションポリシを決定し、前記パーティションポリシは、前記データレコードに関連する１つ以上の属性値に少なくとも部分的に基づく、複数のパーティションへのデータレコードの初期のマッピングを含み、
   前記初期のマッピングを使用して、特定の属性値に少なくとも部分的に基づいて、前記データストリームの特定のデータレコードがメンバを指定される第１のパーティションを識別し、
   前記特定のデータレコードに対応して、前記ストリーム管理サービスの取り込みノードにおけるレコード取得シーケンス内の前記特定のデータレコードの位置を示す、シーケンス番号を生成し、前記取り込みノードは、前記初期のマッピングに少なくとも部分的に基づいて選択され、
   複数のデータレコードのそれぞれのシーケンス番号に少なくとも部分的に基づいて、前記ストリーム管理サービスのデータ記憶位置に、順番に前記第１のパーティションの複数のデータレコードを格納し、前記データ記憶位置は、前記初期のマッピングに少なくとも部分的に基づいて選択され、
   前記データストリームを再分割するためのトリガ条件が合致したという決定に対応して、
   パーティションに対するデータレコードの修正されたマッピングを生成し、
   前記データストリームのデータレコード取得における一時停止をスケジューリングすることなしに、前記修正されたマッピングの使用を開始し、
   前記特定の属性値を有し、前記修正されたマッピングの使用の開始に続いて受信される別のデータレコードのために、（ａ）前記ストリーム管理サービスの異なる取り込みノード、または（ｂ）前記ストリーム管理サービスの異なるデータ記憶位置のうち少なくとも１つを選択する
   ように構成された、１つ以上の計算装置を備えるシステム。
2. 前記シーケンス番号は、（ａ）前記特定のデータレコードの取り込みに関連するタイムスタンプ、及び（ｂ）追加のサブシーケンス値の表示を含む、
   請求項１記載のシステム。
3. １つ以上の計算装置は、さらに
   前記修正されたマッピングを使用してマップされたデータレコードのシーケンス番号に使用される初期のタイムスタンプ値を選択し、
   特定のシーケンス番号を示すデータレコードの検索要求に対応して、
   前記特定のシーケンス番号によって示された特定のタイムスタンプの値が、前記初期のタイムスタンプ値よりも低いという決定に対応して、１つ以上のデータレコードを検索するために前記初期のマッピングを利用し、
   前記特定のタイムスタンプの値が、前記初期のタイムスタンプ値よりも低くないという決定に対応して、１つ以上のデータレコードを検索するために前記修正されたマッピングを利用する
   ように構成される、請求項２記載のシステム。
4. 前記トリガ条件は、（ａ）オーバーロードの状態の検出、（ｂ）ワークロードの不均衡の検出、（ｃ）再分割のクライアントの要求、（ｄ）データストリームにおけるデータの耐久性要件の変更の決定、（ｅ）ソフトウェアのバージョン変更のスケジュールの決定、（ｆ）データストリームの使用パターンの変化の検出（ｇ）データストリームの再分割の価格の影響の決定、または（ｈ）データストリームに関連する性能ターゲットの決定
   のうち、１つ以上を含む、請求項１記載のシステム。
5. １つ以上の計算装置は、さらに
   前記データストリームに使用される１つ以上のパーティション基準を示すクライアントの要求を受信し、前記クライアントの要求に少なくとも部分的に基づいて、前記初期のマッピングを生成する
   ように構成される、請求項１記載のシステム。
6. データレコードの１つ以上の属性値に少なくとも部分的に基づいて、複数のパーティションへのデータストリームの前記データレコードの初期のマッピングを決定すること、
   前記初期のマッピングを使用して、特定の属性値に少なくとも部分的に基づいて、前記データストリームの特定のデータレコードがメンバを指定される第１のパーティションを識別すること、
   前記初期のマッピングに少なくとも部分的に基づいて選択された記憶位置で前記特定のデータレコードを格納すること、
   トリガ条件が合致したという決定に対応して、
   パーティションに対する修正されたデータレコードのマッピングを生成し、
   前記特定の属性値を有し、前記修正されたマッピングの使用の開始に続いて受信される別のデータレコードのために、異なる記憶位置を選択すること
   をストリーム管理サービスの１つ以上の計算装置によって実行すること
   を含む方法。
7. 前記トリガ条件が合致したという決定の前に、前記特定のデータレコード上で、前記初期のマッピングに少なくとも部分的に基づいて、選択されたワーカノードで処理操作を実行し、
   前記トリガ条件が合致したという決定の後に、前記特定の属性値を有する異なるデータレコード上で、前記修正されたマッピングに少なくとも部分的に基づいて選択された、異なるワーカノードで、前記処理操作を実行すること
   をさらに含む、請求項６記載の方法。
8. 前記特定のデータレコードに対応して、前記ストリーム管理サービスの取り込みノードで、レコード取得シーケンス内の前記特定のデータレコードの位置を示すシーケンス番号を生成すること実行することを含み、
   前記取り込みノードは、前記初期のマッピングに少なくとも部分的に基づいて選択され、
   シーケンス番号に対応して、前記第１のパーティションのデータレコードを順番に格納することを実行すること
   をさらに含む、請求項６記載の方法。
9. 前記シーケンス番号は、（ａ）前記特定のデータレコードの取り込みに関連するタイムスタンプ、及び（ｂ）追加のサブシーケンス値の表示を含む、
   請求項８記載の方法。
10. 前記タイムスタンプが、前記特定のデータレコードが取り込まれた時刻を示し、
    特定のレコードの取り込み時間範囲に少なくとも部分的に基づいて、１つ以上のデータレコードが検索されることを要求する検索要求に対応して、前記１つ以上のデータレコードを検索するために、インデックスキーとして前記１つ以上のデータレコードに関連するシーケンス番号を使用することを実行すること
    をさらに含む、請求項９記載の方法。
11. 前記修正されたマッピングを使用してマップされたデータレコードのシーケンス番号に使用される初期のタイムスタンプ値を選択し、
    特定のシーケンス番号を示すデータレコードの検索要求の受信に対応して、
    前記特定のシーケンス番号によって示された特定のタイムスタンプの値が、前記初期のタイムスタンプ値よりも低いという決定に対応して、１つ以上のデータレコードを検索するために前記初期のマッピングを利用し、
    前記特定のタイムスタンプの値が、前記初期のタイムスタンプ値よりも低くないという決定に対応して、１つ以上のデータレコードを検索するために前記修正されたマッピングを利用することを実行すること
    をさらに含む、請求項９記載の方法。
12. 前記修正されたマッピングは、少なくとも１つの追加の属性値を使用してデータレコードの前記パーティションを決定する、請求項６記載の方法。
13. 前記１つ以上の属性値は、
    （ａ）データレコードのソースによって提供されたパーティションキー、（ｂ）データレコードのソースの識別、（ｃ）データレコードのコンテンツの少なくとも一部、または（ｄ）データレコードのソースのネットワークアドレスのうち、
    少なくとも１つを含む、請求項６記載の方法。
14. １つ以上のプロセッサ上で実行されるプログラム命令を格納するコンピュータアクセス可能な記憶媒体であって、
    前記プログラム命令は、
    データストリームのデータレコードをストリーム管理サービスの複数のノードに、分散するために適用されるパーティションポリシを決定し、
    前記パーティションポリシは、複数のパーティションへのデータレコードの初期のマッピングを含み、
    前記初期のマッピングに従って、ストリームのデータレコードを受信するために、前記ストリーム管理サービスの取り込みノードの第１セットと、データレコードを格納するために、前記ストリーム管理サービスのデータ格納ノードの第１セットを構成し、
    前記データストリームを動的に再分割するためのトリガ条件が合致したという決定に対応して、
    異なる複数のパーティションに対するデータレコードの修正されたマッピングを生成し、
    前記修正されたマッピングの生成に続いて受信されたデータレコードのために、取り込みノードの異なるセット及びデータストレージノードの異なるセットを構成し、
    到着するデータレコードが、前記修正されたマッピングに従って格納される、少なくとも特定の期間に、前記初期のマッピングに従ってデータ格納ノードの前記第１セットに格納されたデータレコードを保持する、
    コンピュータアクセス可能な記憶媒体。
15. 前記トリガ条件は、（ａ）オーバーロードの状態の検出、（ｂ）ワークロードの不均衡の検出、（ｃ）再分割のクライアントの要求、（ｄ）データストリームにおけるデータの耐久性要件の変更の決定、（ｅ）ソフトウェアのバージョン変更のスケジュールの決定、（ｆ）データストリームの使用パターンの変化の検出（ｇ）データストリームの再分割の価格の影響の決定、または（ｈ）データストリームに関連する性能ターゲットの決定のうち、１つ以上を含む、請求項１４記載のコンピュータアクセス可能な記憶媒体。

Images