実施形態は、いくつかの実施形態及び説明図用に一例として本明細書で記載されているものの、当業者は、実施形態は実施形態または図面に限定されないことを理解するであろう。図面及び詳細な説明は、開示された特定の形式の実施形態に限定することを意図せず、反対に添付の特許請求の範囲により規定されるように趣旨及び範囲内にある全ての修正、等価物及び代替物を網羅しようとするものであると理解すべきである。本明細書で使用された見出しは、組織の目的のためのみであり、記述の範囲または特許請求の範囲を限定するために使用されることを意図したものではない。本願の全体を通じて使用されるとき、「してもよい」という語は、義務の意味(即ち必須を意味する)というよりはむしろ、許可の意味で使用されている(即ち、あることを行う可能性を有することを意味する)。同様に、「含む」、「含んでいる」は、含んでいることを意味するが、これらに限定されない。
何百または何千もの同時並行データ生成部及びデータコンシューマの取り扱いを目的とした、大規模データストリームの作成、記憶、検索及び処理を管理するための方法及び装置の様々な実施形態が記載されている。本発明で使用する場合、「データストリーム」という用語は、1つ以上のデータ生成部によって生成し、1つ以上のデータコンシューマによってアクセスされ得るデータレコードのシーケンスを意味し、各データレコードは、不変のバイト列であると仮定される。いくつかの実施形態では、ストリーム管理サービス(SMS)は、ストリームデータレコードの送信、記憶及び検索と同様に、ストリームの作成、構成及び削除を可能にするために、プログラムによるインタフェース(例えば、アプリケーションプログラミングインタフェース(API)、ウェブページ若しくはウェブサイト、グラフィカルユーザインターフェースまたはコマンドラインツール)を提供し得る。SMS制御コンポーネントとの相互作用を含む、(ストリーム作成若しくは削除、または下記に記載の動的再分割操作の種類のような)いくつかの種類のストリーム操作は、本明細書では「制御プレーン」操作と呼ばれることもある。一方、典型的には、制御コンポーネントとの相互作用を必要としない(例えば、通常の操作条件下で)データレコードの送信、記憶及び検索のような操作は、本明細書では「データプレーン」操作と呼ばれることもある。ダイナミックプロビジョンされた計算、記憶及びネットワークリソースのセットは、例えば、さらに詳細に後述のように、ストリーム管理ワークロードが数々のサービスコンポーネントの中でスケーラブルな方法で分散されることが可能な様々なパーティションポリシに基づいて、このようないくつかの実施形態におけるサービスを実装するために使用され得る。頭字語のSMSは、本明細書においてはストリーム管理サービスを意味するために使用され得る。また、ストリーム管理サービスを実装するために使用される、仮想及び/または物理リソースの収集を含む、ストリーム管理システムを意味するために使用され得る。
SMSの何人かの顧客は、様々な実施形態で、SMSプログラムによるインタフェースを直接起動するアプリケーションを開発し得る。少なくともいくつかの実施形態では、しかしながら、SMSインタフェースに加えて、より高いレベルの抽象化またはアプリケーションレベルの処理フレームワークは、顧客に提供されてよく、SMSによって直接支援される、より低いレベルのストリーム管理機能を使用するアプリケーションの開発を望まない、これらのクライアントに対するストリーム処理の様々な態様を簡略化し得る。このようなフレームワークは、それ自身のプログラムによるインタフェース(例えば、SMSインタフェースの上部に設置)を提供してよく、より低いレベルのストリーム管理操作よりも顧客がストリームレコードを使用して実装されるビジネスロジックにより集中し得る。より高いレベルのフレームワークは、いくつかの実施形態では、それ自身の制御プレーン及びデータプレーンコンポーネントを備えるストリーム処理サービス(SPS)として実装されてよく、ストリーム処理のための自動リソースプロビジョニング、処理ノードの自動フェイルオーバ、任意のストリーム処理ワークフローグラフを構築する能力、一過性のストリームの支援、ワークロードの変化またはその他のトリガ条件に基づいた動的再分割等のような、高度な機能性を提供し得る。少なくともいくつかの実施形態では、ストリーム管理サービス、ストリーム処理サービスの何れか、または両方のサービスは、仮想環境においてマルチテナント管理ネットワークでアクセス可能なサービスであり得る。すなわち、(コンピュータサーバまたはホスト、記憶装置、ネットワーク装置等のような)様々な物理リソースは、少なくとも場合によっては、リソースがどのように共有されているのか正確に顧客に必ずしも気付かせる必要がなく、あるいは所与のリソースが共有されていることを全く気付かせることさえなく、このような実施形態における異なる顧客のストリーム間で共有される。管理されたマルチテナントストリーム管理及び/または処理中の管理サービスの制御コンポーネントは、動的に追加、削除し、または様々な適用可能なポリシに基づいた特定のストリームに使用されるノード若しくはリソースを再構成してよく、それらのいくつかはクライアントが選択可能であり得る。加えて、制御コンポーネントは、また、(例えば、少なくともいくつかのハードウェアまたはソフトウェアが双方のクライアントに共有される可能性があっても、1つのクライアントのストリームのアプリケーションは別のクライアントのデータにアクセスすることができないことを確実にするための)様々な種類のセキュリティプロトコルを、透過的に実装する役割をし、監査またはデバック等に使用され得る請求、ロギング情報の生成のためのリソース使用状況を監視する。管理されたマルチテナントサービス(単数または複数)のクライアントの見地から、サービス(単数または複数)によって実装される制御/管理者機能は、大規模のストリーミングアプリケーションを支援することに伴う複雑さの大部分を解消し得る。いくつかの場合では、このようなマルチテナントサービスの顧客は、少なくともいくつかの種類のストリーム関連の操作のためのリソースを共有したくない場合には、いくつかの物理リソースは、これらの種類の操作のためにシングルテナントのように少なくとも一時的に指定され得る(すなわち、単一の顧客またはクライアントに代わって実行される操作に限定する)ことを表すことが可能であり得る。
様々な実施形態では、いくつかの異なる手法がSMS及び/またはSPS制御プレーン及びデータプレーン操作を実装するためにとられ得る。例えば、制御プレーンの操作に関しては、いくつかの実装では、制御サーバまたはノードの冗長グループが設定され得る。冗長グループは複数の制御サーバを含んでよく、そのうちの1つのサーバは、様々なストリームに関して管理者の要求に応答する役割をするプライマリサーバとして示されている。一方、別のサーバは、現在のプライマリでの破損(または接続不良)のようなトリガ条件の場合、プライマリとして引き継ぐように示され得る。別の実装においては、ネットワークにアクセス可能なデータベースサービスで作成された1つ以上のテーブルは、様々なストリームに(パーティションマップのような)制御プレーンメタデータを格納するために使用され得る。また、様々な取り込み、記憶ノードや検索ノードは、データプレーン操作に必要なメタデータのサブセットの取得する必要に応じてテーブルにアクセス可能であり得る。異なる実施形態における、SPS及びSMSデータプレーン及び制御プレーンの機能性の様々な態様に関する詳細は、下記に提供されている。ストリーム管理サービスが実装される、いくつかの実施形態では、より高いレベルの基本要素を提供するストリーム処理サービスは必ずしも実装されない可能性があることに注意する。その他の実施形態では、高いレベルのストリーム処理サービスのプログラムによるインタフェースのみが顧客に公開され、使用されるより低レベルのストリーム管理インタフェースはクライアントには入手可能ではない。
いくつかの実施形態によると、ストリーム管理システムは、データレコードを取得または収集する役割を主にするレコード取り込みサブシステムと、適用可能な永続性または耐久性ポリシによるデータレコードコンテンツを保存する役割を主にするレコード記憶サブシステムと、及び格納されたレコードに向けられた読み出し要求に応答する役割を主にするレコード検索サブシステムと、を含む、複数の独立して構成可能なサブシステムを備え得る。制御サブシステムは、また、いくつかの実施形態において実装され、例えば、動的に判定することによって及び/または必要な数のノードを初期化することによって、サブシステムを、仮想または物理サーバのような選択されたリソースで取り込み、記憶及び取得するために、残りのサブシステムを構成する役割をする1つ以上の管理者または制御コンポーネントを備え得る。取り込み、記憶、検索及び制御サブシステムのそれぞれは、全体がサブシステムの「ノード」または「サーバ」と呼ばれ得る、複数のハードウェア及び/またはソフトウェアコンポーネントのそれぞれを使用して実装され得る。このように、SMSの様々なリソースが、取り込み、記憶、検索または制御という4つの機能カテゴリのうちの1つに論理的に属するとされ得る。いくつかの実装においては、制御コンポーネントのそれぞれのセットは、その他のサブシステムのそれぞれに構築され得る。例えば、独立取り込み制御サブシステム、記憶制御サブシステム及び/または検索制御サブシステムが実装され得る。それぞれのこのような制御サブシステムは、対応するサブシステムのその他のノードのために及び/またはクライアントまたはその他のサブシステムからの管理クエリに応答するために、使用されるリソースを識別する役割をし得る。いくつかの実装においては、様々な種類のSMS及び/またはSPSの機能を可能にするノードプールは、予め設定されてよく、これらのプールの選択されたメンバは、必要に応じて新しいストリームまたは新しい処理ステージに割り当てられ得る。
ストリームパーティションポリシ及び関連するマッピングは、例えば、取り込み、記憶、検索及び/または制御ノードの異なるセットの間のデータレコードのサブセットに分散するために、少なくともいくつかの実施形態においては、実装され得る。例えば、レコード取り込み率及び/または検索率の予想のようなその他の要因と同様に、特定のデータストリームに選択されるパーティションポリシに基づいて、制御コンポーネントは、いくつのノード(例えばプロセスまたはスレッド)が取り込み、記憶及び検索のために最初に確率されるか(すなわち、ストリーム作成時間)、及びこれらのノードがどのように仮想及び/または物理マシンにマッピングされるべきかを判定し得る。時間の経過とともに、所与のストリームに関連するワークロードは、増加または減少してよく、これは(その他のトリガ条件のなかで)ストリームの再分割という結果をもたらし得る。このような再分割は、レコードのパーティション、使用されるパーティションキー、パーティションのすべての数、取り込みノードの数、記憶ノード若しくは検索ノード、または異なる物理リソース若しくは仮想リソースへのノードの配置を判定するために使用される機能のような、様々なパラメータへの変更を伴い得る。少なくともいくつかの実施形態では、さらに詳細に書きに記載された技術を使用して、再分割はデータレコードの流れを中断することなく動的に実装され得る。いくつかの実施形態では、異なるパーティションの手法及び再分割のトリガ基準は、例えば、クライアントが提供するパラメータまたはSMS制御ノードの発見に基づいて異なるデータストリームに使用され得る。いくつかの実施形態では、再分割の数及び/または頻度を制限することが可能であり得る。例えば、クライアントの好み、ストリームの予想耐用期間またはその他の要因である。
いくつかの異なるレコード取り込みポリシ及びインタフェースは、異なる実施形態において実装され得る。例えば、いくつかの実施形態では、クライアント(例えば、SMSの顧客に代わってSMSのプログラムによるインタフェースを起動するよう構成された実行可能なコンポーネントまたはモジュール)は、インラインサブミッションインタフェースまたはバイリファレンスサブミッションインタフェースの何れにも利用し得る。その実施形態において、インラインサブミッションには、データレコードのコンテンツまたは本文がサブミッション要求の一部として含まれ得る。対照的に、バイリファレンスサブミッション要求においては、アドレス(記憶装置アドレス、データベースレコードアドレスまたはURL(ユニフォームリソースロケータ))は、データレコードのコンテンツまたは本文が取得され得るところから提供され得る。いくつかの実装においては、ハイブリッドサブミッションインタフェースも、または代わりに支援され得る。データレコードの第1のNバイトはインラインに含まれ得る。それに対し、残りのバイト(可能ならば)は、参照により提供される。このような場合には、短いレコード(その本文がNバイトの長さ未満である)はサブミッション要求によって十分に指定され得るが、一方、それよりも長いレコードの部分は対応するアドレスから入手し得る。
取り込み中のレコードコンテンツを指定するための異なる選択肢に加え、いくつかの実施形態では、様々な応答または複製排除に関連する取り込みポリシもまた、実装され得る。例えば、いくつかのストリームアプリケーションには、クライアントはそれぞれ及び全てのデータレコードがSMSによって確実に取り込まれることを確保したい場合がある。大規模に分散されるストリーム管理環境においては、データ生成部と取り込みノードとの間のパスに沿ってパケットは破損するか、様々な障害が時折起こり得、これはいくつかの送信されたデータを潜在的に失う結果となり得る。したがって、いくつかの実施形態では、レコード送信者は、同じレコードを、肯定応答が取り込みサブシステムから受信されるまで、1度以上送信し得ることにより、SMSは少なくとも1回の取り込みポリシを実装し得る。通常の操作環境下では、レコードは一度送信されてよく、送信者は受信する取り込みノードがレコードを取得し格納した後に応答を受信してよい。応答が損失されたか遅延した場合、またはレコード送信要求自体が損失された場合には、送信者は、最終的に応答が受信されるまで、同じデータレコードを1度以上再送信してよい。例えば、応答がすでに送信者によって受信されていた場合、レコードは再送信されないという予想に基づいて、取り込みノードは、送信が複製であるか否かにかかわらず、各送信に対し応答を生成し得る。しかしながら、取り込みノードは、少なくともいくつかの実施形態では、同一のデータレコードは複数回送信されたことを認識し、複製のデータの新しいコピーを不必要に記憶することを避ける役割をし得る。一実施形態では、少なくとも1回の取り込みポリシの少なくとも2つのバージョンは、(「少なくとも1回の取り込み、複製不可」と称され得る)、SMSがデータレコードを複製排除する役割をする(すなわち、2つまたはそれ以上の送信のセットの1つのみに対応して、データがSMS記憶サブシステムに格納されることを確実にする)1つのバージョン、及び、(「少なくとも1回、複製可」と称され得る)SMSによってデータレコードストレージの複製が許可される1つのバージョンを支援され得る。少なくとも1回の複製が許可された手法は、データレコードの複製の否定的な結果が少数であるか、全く無いストリームアプリケーション、及び/またはそれ自身の複製を排除を実行するストリームアプリケーションには有用であり得る。その他の取り込みポリシもまた、応答が送信されたデータレコード毎に必要とされないベストエフォートの取り込みポリシのように支援され得る。少数のデータレコードの損失は、ベストエフォートの取り込みポリシが少なくともいくつかの実施形態で有効である場合に受け入れ可能であり得る。クライアントは様々な実施形態における様々なストリームに使用を希望する取り込みポリシを選択し得る。
ストリームレコードの記憶に関しては、いくつかの代替的なポリシもまた、少なくともいくつかの実施形態で支援され得る。例えば、クライアントはSMSによって支援されるいくつかのうちから永続性のポリシを選択可能であってよく、これは格納されるべき所与のデータレコードのコピーの数として、このようなレコードの記憶の態様を管理し、記憶技術の種類(例えば、揮発性または不揮発性RAM、回転ディスクベースのストレージ、固体装置(SSD)、ネットワーク接続記憶装置等)がコピー等に使用され得る。例えば、クライアントがディスクベースのストレージサーバへのN−レプリカ永続性ポリシを選択する場合、データレコードの送信は、レコードのNコピーがNの各ディスク装置に安全に書き込まれるまで完全であると考えられない可能性がある。ディスクベースの記憶装置が使用される少なくともいくつかの実施形態では、SMS記憶サブシステムは、例えばディスクシークのパフォーマンスインパクトを避けるために、順次、ディスクに対して所与のパーティションの入ってくるデータレコードの書き込みを試み得る。シーケンス番号は、例えば、取り込み時間に基づいて並べられたレコード検索を可能にするタイムスタンプに基づいた技術を含む、様々な下記の技術を使用してデータレコードに生成(かつ記憶)され得る。少なくともいくつかの実施形態では、所与のパーティションのデータレコードは、例えば、ディスクに連続的に、及びその他のパーティションのデータレコードから分離して一緒に記憶され得る。いくつかの実装においては、(クライアント若しくはSMSによって選択された)保持ポリシまたは(任意の所与のデータレコードの送信後の期間を表示し、その間、いくつかの複製が送信されたとしてもSMSは、複製のないその所与のデータレコードが、SMS記憶サブシステムに格納されることを確保する必要があり得る)複製排除時間窓ポリシによれば、少なくともいくつかのデータレコードは、異なる種類のストレージサービスに移され得る及び/またはSMSからある期間の後に削除され得る。このような除去の操作は、本明細書においては、「トリミング」と称し得る。クライアントはいくつかの実施形態では、ストリームをトリミングする要求を送信し得る。例えば、SMSに指定のデータレコードはもはや必要されておらず、そのためトリミング要求を送信するクライアントの見地から、削除が可能であることを通知するか、または指定のデータレコードの削除を明示的に要求する。多数のクライアントが所与のストリームのデータレコードを使用する可能性がある場合では、SMSは、すべての関係コンシューマによってアクセスされる前に、所与のレコードが尚早に削除またはトリミングされないことを確実にする役割があってよい。いくつかの実装においては、所与のストリームのNデータコンシューマがある場合には、ストリームの所与のレコードRを削除する前に、SMSはすべてのNデータコンシューマがRを読み出しまたは尚早に処理したことを判定するまで待機し得る。例えば、コンシューマからの各トリミング要求に基づいて、または、ストリーム内でデータコンシューマがどのくらい進んでいるかというそれぞれの表示に基づいて、Rはすべてのコンシューマによって読み込まれたと、SMSは判定し得る。いくつかの実施形態では、データコンシューマの(テストに関連するアプリケーションのような)いくつかの種類は、アクセスされる前に、少なくとも一部の部分のデータレコードの削除を受け入れ得る。したがって、アプリケーションは、少なくともいくつかの実施形態においては、検索前にデータ削除の受容性に関してSMSに通知可能であってよく、及びSMSはその通知によって削除を予定し得る。いくつかの実施形態では、例えば、データ保持ポリシの一部として、保存用のポリシが実装されてよく、例えば、ストリームデータレコードがコピーされるべき記憶装置の種類を表示し、ポリシがこのようなコピーへの使用とを予定する。
少なくともいくつかの実施形態においては、複数のプログラムによるインタフェースもまた、レコード検索のために支援され得る。一実施形態では、イテレータベースの手法が使用されてよく、一プログラムによるインタフェース(例えば、getIterator)はインスタンス化し、イテレータまたはカーソルを指定の理論オフセットに配置するために、ストリームのパーティション内で(例えば、シーケンス番号またはタイムスタンプに基づいて)使用され得る。次に(getNextRecordのような)異なるプログラムによるインタフェースは、イテレータの現在位置から順次開始する指定の数のデータレコードを読み込むために使用され得る。イテレータのインスタンス化は、要するに、クライアントが恣意的または無作為の開始位置を、ストリームパーティション内でレコード検索するために特定することを可能にし得る。クライアントがこのような実施形態で無作為なアクセスパターンでデータレコードの読み出しを希望する場合には、クライアントは繰り返し新しいイテレータを生成しなくてはならない場合がある。回転ディスクベースの記憶システムにおいては、頻繁なランダムアクセスに必要とされるディスクシークは、I/O応答回数に著しく影響を与える場合がある。したがって、ストリームデータレコードを無作為に読み込むよりも順次に読み込むことをクライアントに促すために、少なくともいくつかの実施形態では、異なる(例えば高い)課金率が、シーケンシャルリードアクセスに適用されるよりも、ランダムリードアクセスに適用され得る。したがって、いくつかの実装においてはX>Yの状態で、例えば、クライアントはgetIterator通話毎にX通貨単位で、及び、レコード検索毎にgetNextRecordを介しY通貨単位請求され得る。代替的なクライアントインタフェースが、(取り込みのような)その他の操作カテゴリに支援される場合、少なくともいくつかの実施形態では、課金率または代替物の価格もまた、異なり得る。クライアントがシーケンシャルリードよりもランダムリードにより課金され得るのと同様に、例えば、クライアントは、オンラインの送信要求よりもバイリファレンスの送信要求により課金され得る。データレコードのサイズ、時間の経過とともに書き込み対読み出し要求の分散、選択された永続性ポリシ等のような、その他の要因もまた様々な実施形態において課金に影響し得る。
いくつかの実施形態によると、ストリーム処理サービス(SPS)は、クライアントが、多数の処理ステージを含む複雑な処理ワークフローを適宜、特定することを可能にし、所与のステージで実行される処理の出力が、ゼロまたはそれ以上のその他のステージ用に入力として使用され得る。パーティションポリシ(データレコードの取り込み、格納及び検索のためのSMSに記載されるものに類似)は、いくつかの実施形態における様々なステージで複数のワーカノードのうち処理中のワークロードを分割するために使用され得る。このような一実施形態では、プログラムによるSPSインタフェースは、クライアントが任意の所与のステージのために様々な構成設定を特定可能なように実装されてよく、例えば、ステージのために入力データソース(単数または複数)(例えば、ストリーム用のパーティションポリシと一緒に、データレコードが検索される1つ以上のストリーム)、ステージで実行される処理操作、及びステージからの出力または結果の分散のためディスクリプタまたは指定(例えば、出力が記憶位置に保存され、ネットワークの終点に送信され、または異なるストリームの形式で1つ以上のその他のステージに入力されるか否かを問わず)を含む。少なくともいくつかの実施形態では、SPSステージのために指定される処理操作は冪等であり得る。すなわち、所与の処理操作が同じ入力データで複数回実行される場合、操作の結果は、操作が1回のみ実行された場合に得られたであろう結果とは異ならない。さらに詳細に後述のように、破損からのリカバリ(例えば、SPSステージでのワーカノードの損失)は、処理操作が冪等の場合、簡略化され得る。いくつかの実施形態によると、非冪等の処理操作はいくつかのまたはすべてのSPSステージで許可され得る。
入力ストリームパーティションポリシ及び次にSPSプログラムによるインタフェースを介して受信される処理操作の性質のような構成情報に少なくとも部分的に基づいて、様々な実施形態では、処理ワークフローの様々なステージのために、どのくらいの数のワーカノードが最初に設定されるべきかをSPS制御サーバは判定し得る。ワーカノードに使用されるリソースの遂行能力(例えば、使用される仮想マシンまたは物理マシン)もまた、初期番号及びワーカノードの配置を決定する際に、考慮され得る。選択されたワーカノードの番号は、インスタンス化され得る(いくつかの実装では、実行可能なスレッドまたは実行可能なプロセスをそれぞれ備える)。各ワーカノードは、例えば、適切な入力ソースからデータレコードを(例えば、1つ以上のストリームパーティションの検索ノードから)取得し、データレコードで指定された処理操作を実行し、及び指定された宛先(単数または複数)に処理の結果を伝送するよう構成され得る。加えて、少なくともいくつかの実施形態では、パーティションレコードが連続して処理される仮定で、所与のワーカノードは、そのワーカノードで処理されてきたプログレスレコードまたはパーティションの一部を示すチェックポイントを格納するよう構成され得るにしたがい、チェックポイントのスキームが実装され得る。いくつかの実装において、例えば、ワーカノードは、プログレスレコードを永続性ストレージに定期的(例えば、N秒毎に1度、またはRデータレコードに1度が処理されている)に及び/またはSPS制御サーバからチェックポイントの要求に対応して、書き込みしてよい。
いくつかの実施形態では、プログレスレコードはワーカノードの破損から迅速にリカバリするために使用され得る。例えば、SPS制御サーバは、(CPU利用、I/O装置利用またはネットワーク利用レベルのような)例えば、ハートビート機構の使用及び/またはリソース利用レベルの監視により、様々なワーカノードの健康状態を時間の経過とともに監視し得る。特定のワーカノードが好ましくないまたは健康ではない状態にあるとのSPS制御サーバによる判定に対応して(例えば、応答しないかオーバーロードの場合)、交換されたワーカノードは特定のワーカノードの役割を引き継ぐためにインスタンス化され得る。交換されたワーカノードは、交換されたワーカノードによって格納された最新のプログレスレコードにアクセスして、交換されたワーカノードが処理すべきデータレコードのセットを識別し得る。処理操作が冪等である実施形態では、いくつかの操作が繰り返されていても(例えば、最新のプログレスレコードが交換されたワーカのインスタンス化以前のある時に書き込まれたため)、処理全体の結果は破損及び交換の影響を受けないであろう。いくつかの実装においては、所与のストリームのサブセットまたはこのサブセットによって処理されたパーティションを表すプログレスレコードを格納することに加えて、ワーカノードもまた、蓄積されたアプリケーション状態の情報を格納するよう構成され得る。例えば、ストリーム処理ワークフローは、サービス使用メトリクスを表すストリーミングデータレコードの分析に基づいて特定のサービスのためクライアント課金額を決定する役割をする場合には、ワーカノードは、様々なクライアントに決定された累積の課金額を定期的に格納し得る。
少なくともいくつかの実施形態では、SPS制御サーバは、また、様々なステージのための入力ストリームの動的再分割の要求のようなその他の動作を開始し、所与のステージで所与のパーティションに割り当てられたワーカノードの数の変更し、いくつかのステージにより高い性能のワーカノードの割り当てし、または異なる性能能力で1つの物理リソースから別の物理リソースへワーカノードの伝達することによって、ワークロードレベル若しくは検出されたワークロードの不均衡(例えば、1つのパーティションに対する取り込みレートがその他のものよりも不均衡に高くなっている場合)の変更のような、様々なその他のトリガに、応答するよう構成され得る。いくつかの実施形態では、例えば、ベストエフォートリカバリポリシは、チェックポイントベースのリカバリポリシよりもむしろ、所与のステージのために実装されるSPS制御サーバによる判定に対応して、上記に記載した種類のプログレスレコードは、少なくともいくつかのSPSステージのワーカノードによって格納されない場合がある。このようなベストエフォートリカバリポリシのいくつかの実装においては、交換されたワーカノードは、プログレスレコードにアクセスする必要なく、受信された際に新しいデータレコードを単純に処理し得る。いくつかの実施形態では、クライアントがSPSステージでベストエフォートリカバリポリシの実装を希望する場合には、ステージで実行されるストリーム処理操作は必ずしも冪等である必要はない。非冪等の処理操作がSPSステージでストリームレコード上で実行されるいくつかの実施形態では、チェックポイントベースのリカバリは支援されなくてよく、ベストエフォートリカバリのような異なるリカバリスキームが使用され得る。少なくとも一実施形態においては、冪等ストリーム処理操作のみがSPSステージ許容され得る。
いくつかのストリームのデータレコードは、秘密または機密情報を含み、またはSPSステージで実行される処理操作は、競合相手による発見は問題となり得る著作権のあるアルゴリズムの使用を含み得る。そのため、クライアントは様々なカテゴリのストリーム管理及び処理操作のセキュリティについて、特に操作が、クライアント自身によって完全に制御されないプロバイダネットワークデータセンタに配置されるリソースを使用して実行される場合、関心があり得る。インターネット及び/またはその他のネットワークを介して分散されたクライアントのセットにアクセス可能な(様々な種類のクラウドベースのデータベース、電算処理またはストレージサービスのような)1つ以上のネットワークにアクセス可能なサービスを提供する会社または公的部門の組織のようなエンティティによって設定されるネットワークは、本明細書ではプロバイダネットワークと称され得る。いくつかの実施形態では、クライアントはデータストリームのために、複数のセキュリティに関連する選択肢のうちから選択可能であり得る。上記のように、組み合わされたSPS及びSMSの構成は、SMS及び/またはSPS用の制御ノード、SMS取り込みノード、SMS記憶ノード、SMS検索ノード及びSPS処理若しくはワーカノードのような、異なる機能のカテゴリのいくつかに属するノードを備え得る。いくつかの実施形態では、クライアントが入手可能であるセキュリティに関連する選択肢は、様々な種類のノードの位置または配置のため選択肢を含み得る。例えば、一実施形態では、クライアントは、たとえストリームレコードが当初、プロバイダネットワークに配置されるリソースを使用して収集及び/または格納されても、ストリームワークフローの1つ以上の処理ステージのためのSPSワーカノードは、クライアント所有の設備に配置された計算装置に実装されることを要求することが可能であり得る。このような配置要求に対応して、所与のストリームのための異なる機能カテゴリのノードは、異なるセキュリティ特性またはプロフィールとセットで各リソースでインスタンス化され得る。
リソースセットは、異なる実施形態において、例えば、物理位置、使用される物理セキュリティプロトコル(例えば、リソースへの物理アクセルを有するもの)、ネットワーク隔離レベル(例えば、リソースのネットワークアドレスが様々なエンティティに可視である範囲)、マルチテナント対シングルテナント等を含む、様々なセキュリティに関連する特性が互いに異なり得る。いくつかの実施形態では、クライアントのIVN内に含まれた様々な装置のネットワーク構成を実質的に制御する所与のクライアントとともに、クライアントは、プロバイダネットワーク内に隔離された仮想ネットワーク(IVN)を確率し得る。特に、クライアントは、様々なサーバまたはIVN内のコンピュートインスタンスに割り当てられたネットワークアドレス(例えば、インターネットプロトコルまたはIPアドレス)にアクセスすることを制限し得る。このような実施形態においては、クライアントはSMSノードまたはSPSノードの一定のサブセットが特定のIVN内でインスタンス化されることを要求し得る。仮想インスタンスホスト(典型的にはマルチテナントホストとして構成され得る)のようなプロバイダネットワークリソースが、SMSノードまたはSPSノードの様々なカテゴリに使用される実施形態では、クライアントは、いくつかのセットのノードは、クライアントのみに属するインスタンスの実装を制限されるインスタンスホスト上でインスタンス化されることを要求し得る(すなわち、いくつかのSMSノードまたはSPSノードはシングルテナントホストとして構成されたインスタンスホストに実装され得る)。
いくつかの実施形態では、別のセキュリティ関連の選択肢としては、クライアントは、特定のストリームのデータレコードは、例えば、SMSに取り込まれる前に、取り込みと記憶サブシステムとの間、記憶サブシステムと検索サブシステムとの間、検索サブシステムとSPSワーカノードとの間、及び/またはワーカノードとSPS出力宛先との間のネットワークリンクから伝送される前に暗号化されることを要求し得る。クライアントはいくつかの実施形態にて使用される暗号化アルゴリズムを特定し得る。一実施形態では、TLS(トランスポート層セキュリティ)またはSSL(セキュアソケット層)プロトコルのようなセキュアなネットワークプロトコルは、データレコードの伝送及び/またはSPS処理結果の伝送に使用され得る。
データストリームのコンセプト及び概略
図1は、少なくともいくつかの実施形態による、データストリームの構想の簡略化した概略を提供する。ここに示すように、ストリーム100は、DR110A、110B、110C、110D及び110Eのような複数のデータレコード(DR)110を備え得る。データ生成部120A及びデータ生成部120Bのような1つ以上のデータ生成部120(データソースとも称され得る)ストリーム100のデータレコードの内容を生成するために書き込み操作151を実行し得る。いくつかの異なる種類のデータ生成部は、例えば、携帯電話あるいはタブレットアプリケーション、センサアレイ、ソーシャルメディアプラットフォーム、ロギングアプリケーションあるいはシステムロギングコンポーネント、種々のモニタリングエージェント等のような、異なる実施形態においてデータのストリームを生成し得る。(データコンシューマ130A及びデータコンシューマ130Bのような)1つ以上のデータコンシューマ130は、データ生成部120によって生成されたデータレコードの内容にアクセスするために読み出し操作152を実行し得る。いくつかの実施形態では、データコンシューマ130は、例えば、ストリーム処理ステージのワーカノードを備え得る。
少なくともいくつかの実施形態では、SMSに記憶される際の所与のデータレコード110はデータ部分101(例えば、それぞれDR110A,110B,110C,110D及び110Eのデータ部分101A、101B、101C、101D及び101E)及びシーケンス番号SN102(例えば、それぞれDR110A,110B,110C,110D及び110EのSN102A、102B、102C、102D及び102E)を備え得る。シーケンス番号102は記載された実施形態において、DRはストリーム管理システム(またはストリーム管理システムの特定のノード)で受信された順序であることを示し得る。データ部分101はいくつかの実装においては、変更不能な解釈されないバイト列を含み得る。すなわち、書き込み操作152が完了すると、書き込みの結果として生じたDRの内容は、SMSによって変更されなくてよく、一般にSMSはデータの意味を認識しなくてよい。いくつかの実装においては、所与のストリーム100の異なるデータレコードは、異なる量のデータを含み、それに対しその他の実施形態では、所与のストリームの全てのデータレコードは同じサイズであり得る。少なくともいくつかの実装においては、SMSのノード(例えば、取り込みサブシステムノード及び/または記憶サブシステム)は、SN102を生成する役割をし得る。さらに詳細に後述のように、データレコードのシーケンス番号は、必ずしも連続とは限らない。一実装においては、クライアントまたはデータ生成部120は、書き込み要求の一部として、対応するデータレコードに使用される最小のシーケンス番号の表示を提供し得る。いくつかの実施形態では、データ生成部120は、データレコードのデータの一部(またはアドレス)にポインタを含む書き込み要求を、例えば、(装置名及び装置内のオフセットのような)記憶装置のアドレスまたはデータ部分が取得され得る(URLのような)ネットワークアドレスを提供することによって送信し得る。
様々な実施形態では、ストリーム管理サービスは、データ生成部120からデータを受信し、データを格納し、及びデータコンシューマ130を1つ以上のアクセスパターンにおいてデータをアクセス可能にする役割をし得る。少なくともいくつかの実施形態では、ストリーム100は、データレコードを受信し、格納し、及び検索するワークロードを分散するためにパーティション化または「分割」され得る。このような実施形態においては、パーティションまたは分割は、データレコードの1つ以上の属性に基づいて入ってくるデータレコード110のために選択され、及びデータレコードを取り込みし、格納しまたは検索する特定のノードは、パーティションに基づいて識別され得る。いくつかの実装においては、データ生成部120は、パーティションの属性として機能し得る各書き込み操作を明示的なパーティションキーに提供し、及びこのようなキーはパーティション識別子にマッピングされ得る。その他の実施形態においては、SMSは、データ生成部120の識別、データ生成部のIPアドレスの要因に基づいて、または送信されたデータの内容に基づいて、パーティションIDを推測し得る。データストリームがパーティション化されるいくつかの実装においては、シーケンス番号はパーティション毎に割り当てられ得る。例えば、シーケンス番号は、特定のパーティションのデータレコードが受信される順序を示すが、2つの異なるパーティションにおけるデータレコードDR1及びDR2のシーケンス番号は、DR1及びDR2が受信された関連する順序を必ずしも示さない可能性がある。その他の実装においては、データレコードDR1に割り当てられたシーケンス番号SN1がデータレコードDR2に割り当てられたシーケンス番号SN2よりも低い場合には、DR1及びDR2がどちらのパーティションに属するかに関わらず、これは、DR1はSMSによってDR2よりも前に受信されたことを示すように、シーケンス番号はパーティション毎のベースよりもむしろストリーム幅に割り当てられ得る。
様々な実施形態では、SMSによって支援される検索または読み出しインタフェースは、データコンシューマ130がデータレコードに連続して及び/または無作為の順番でアクセスするのを可能にし得る。一実施形態では、イテレータベースの読み出しアプリケーションプログラミングインタフェース(API)のセットは支援され得る。データコンシューマ130は、特定のシーケンス番号及び/またはパーティション識別子によって表されたイテレータの初期の位置とともに、データストリームのためにイテレータを取得するよう要求を送信し得る。イニシエータがインスタンス化された後、データコンシューマは、ストリーム内またはパーティション内の初期位置から始まるシーケンスの順序で、データレコードを読み込むために要求を送信し得る。データコンシューマが何らかの無作為の順序でデータレコードを読み込みたい場合には、このような実施形態では、新しいイテレータは各読み出しのためにインスタンス化しなければならない場合がある。少なくともいくつかの実装においては、所与のパーティションまたはストリームのデータレコードは、典型的にはディスクシークを避ける連続的な書き込み操作を使用して、シーケンス番号順でディスクベースのストレージに書き込まれ得る。シーケンシャル読み出し操作はまた、ディスクシークのオーバーヘッドを避け得る。したがって、いくつかの実施形態では、データコンシューマは無作為の読み出しよりもシーケンシャルな読み出しを実行することを価格で動機付けして奨励され得る。例えば、イテレータのインスタンス化のような、ランダムアクセス読み出し操作はシーケンシャルにアクセスする読み出し操作よりも高い関連する課金率を有し得る。
システム環境の例
図2は、少なくともいくつかの実施形態による、ストリーム処理ステージの収集を含む、ストリーム管理システム(SMS)及びストリーム処理システム(SPS)の様々なサブコンポーネントの間のデータの流れの概略を提供する。ここに示すように、SMS280は取り込みサブシステム204、記憶サブシステム206,検索サブシステム208及びSMS制御サブシステム210を備え得る。後述のように、SMSサブシステムのそれぞれは、1つ以上のノードまたはコンポーネントを含んでよく、例えば、対応する実行可能なスレッドまたはプロバイダネットワーク(またはクライアント所有設備か第三者の設備)の様々なリソースでインスタンス化されるプロセスを使用して実装される。取り込みサブシステム204のノードは、ストリームに使用されるパーティションポリシに基づいて、(120A、120B、及び120Cのような)データ生成部120から特定のデータストリームのデータレコードを取得するよう、(例えば、SMS制御サブシステム210のノードによって)構成され、各取り込みノードは、記憶サブシステム206の対応するノードに受信されたデータレコードを渡し得る。記憶サブシステムのノードは、ストリームのために選択された永続性ポリシにより、様々な種類の記憶装置の何れかに、データレコードを保存し得る。検索サブシステム208のノードは、SPS290のワーカノードのようなデータコンシューマからの読み出し要求に応答し得る。SPS290のステージ215A、ステージ215B、ステージ1215C及びステージ215Dのようなストリーム処理ステージ215は、SPS制御サブシステム220の助けによって確立され得る。各ステージ215は、受信されたデータレコードで処理操作のセットを実行するSPS制御サブシステム220によって構成された1つ以上のワーカノードを含み得る。ここに示すように、(215A及び215Bのような)いくつかのステージ215は、SMS280から直接データレコードを取得し得る。一方、(215C及び215Dのような)その他は、その他のステージから入力を受信し得る。多数のSPSステージ215は、いくつかの実施形態においては並行して操作し得る。例えば、異なる処理操作は、ステージ215A及びステージ215Bで同じストリームから検索されたデータレコード上で同時に実行され得る。特定のストリーム用の、図2に示されたものと類似する、それぞれのサブシステム及び処理ステージは、また、その他のストリームもインスタンス化され得ることに注意する。
少なくともいくつかの実施形態においては、図2に示されているサブシステム及び処理ステージのノードのうち少なくともいくつかは、プロバイダネットワークリソースを使用して実装され得る。前述したように、インターネット及び/またはその他のネットワークを介して分散されたクライアントのセットにアクセス可能な(様々な種類のクラウドベースのデータベース、電算処理またはストレージサービスのような)1つ以上のネットワークにアクセス可能なサービスを提供する会社または公的部門の組織のようなエンティティによって設定されるネットワークは、本明細書ではプロバイダネットワークと称され得る。サービスのいくつかは、より高いレベルのサービスを構築するために使用され得る。例えば、算出、記憶またはデータベースサービスは、ストリーム管理サービスまたはストリーム処理サービスのためのビルディングブロックとして使用され得る。プロバイダネットワークの少なくともいくつかのコアサービスは、「インスタンス」と呼ばれるサービスユニットにおいてクライアントが使用するためにパッケージ化され得る。例えば、仮想計算サービスによってインスタンス化される仮想マシンは、「コンピュートインスタンス」を表し、及びストレージサービスによってインスタンス化されるブロックレベルのボリュームのような記憶装置は、「ストレージインスタンス」と呼ばれることもあり、またはデータベース管理サーバは「データベースインスタンス」と呼ばれることもある。プロバイダネットワークの様々なネットワークにアクセス可能なサービスの装置が実装される、サーバのような計算装置は、本明細書では、「インスタンスホスト」またはより簡単に「ホスト」と呼ばれ得る。いくつかの実施形態では、取り込みサブシステム204のノード、記憶サブシステム206、検索サブシステム208、SMS制御システム210、処理ステージ215及び/またはSPS制御サブシステム220は、複数のインスタンスホスト上の様々なコンピュートインスタンスで実行するスレッドまたはプロセスを備え得る。及び/またはSPS制御サブシステム220は、複数のインスタンスホスト上の様々なコンピュートインスタンスで実行するスレッドまたはプロセスを備え得る。所与のインスタンスホストはいくつかのコンピュートインスタンス及び特定のインスタンスホストでコンピュートインスタンスでの収集は、1つ以上のクライアントの様々な異なるストリームのためにノードを実行するために使用され得る。ストレージインスタンスは、いくつかの実施形態では、様々なストリームのデータレコードを記憶するために使用されるか、ストリーム処理ステージの結果の宛先であり得る。図15及び図16を参照すると、以下に記載されるように、データレコードを依然、受信、記憶及び処理し続ける間、時間の経過とともに、例えば、ノードを追加または削除、ノードのマッピングをコンピュートインスタンスまたはインスタンスホストに変更または所与のストリームを再分割することによって、制御サブシステムは、様々なトリガ条件に対応してその他のサブシステムの人口を動的に修正し得る。
プロバイダネットワークリソースがストリームに関連した操作に使用される実施形態との関係においては、「クライアント」という用語は、所与の通信のソースまたは宛先として使用される場合、(多数のユーザまたは単一のユーザを有する組織、グループのような)エンティティに所有され、管理されまたは割り当てられる、計算装置、プロセス、ハードウェアモジュールまたはソフトウェアモジュールのいずれかを意味し得る。プロバイダネットワークの少なくとも1つのネットワークにアクセス可能なサービスにアクセスし、利用することが可能なあるサービスのクライアントは、別のサービスのリソースを使用して自身が実装され得る。例えば、ストリームデータコンシューマ(ストリーム管理サービスのクライアント)は、コンピュートインスタンス(仮想化された計算サービスによって提供されたり)を備え得る。
所与のプロバイダネットワークは、物理的及び/若しくは仮想化されたコンピュータサーバの収集、それぞれに1つ以上の記憶装置を備えるストレージサーバ及びネットワーク機器等のような、様々なリソースツールをホストする(異なる地理的領域にわたって分散され得る)多数のデータセンタを含んでよく、プロバイダによって提供されるインフラストラクチャ及びサービスを実装、構成及び分散する必要がある。いくつかの異なるハードウェア及び/またはソフトウェアコンポーネントは、そのいくつかはインスタンス化されるか、異なるデータセンタまたは異なる地理的領域で実行され得るが、様々な実施形態におけるサービスのそれぞれを実装するために一括して使用され得る。クライアントは、プロバイダネットワークの外部にあるクライアント所有またはクライアント管理の構内若しくはデータセンタに位置される装置及び/またはプロバイダネットワーク内装置から、プロバイダネットワークでリソース及びサービスと相互作用し得る。プロバイダネットワークは、本明細書で記載される多くのストリーム管理技術及びストリーム処理技術が実装される一例のコンテキストとしての役割をするが、これらの技術は、プロバイダネットワークよりもその他の種類の分散システムに、例えば、アプリケーションの単一ビジネスエンティティによって操作される大規模な分散環境に、適用され得ることに留意する。
プログラムによるインタフェースの例
上記のように、少なくともいくつかの実施形態では、SPSは、様々なストリームベースのアプリケーションに、所望のビジネスロジックを実装するために、SPSクライアントによってより容易に使用されることが可能な、より高いレベルの機能を構築するように、SMSプログラムによるインタフェースを利用し得る。SPSとSMSの機能の違いを考えると、類似性が有用である。SPSの機能は、一般に、C++のような、より高いレベルの言語におけるプログラミング言語の構築と比較され得る。それに対してSMSの機能は一般に、プログラミング言語構築はコンパイラによって変換されるアセンブリ言語命令と比較され得る。アセンブリ言語命令を直接使用して同一の操作を実行することは可能であり得るが、より高いレベルの言語におけるプログラミングは、一般に、顧客またはユーザの多くのカテゴリにはより容易である。同様に、SMSによって供給された基本要素を使用して、様々なアプリケーションを実行することは可能であり得るが、SPS特徴を使用して行うことはより容易であり得る。SPS処理操作(データレコードで実行される冪等の処理操作のような)は、ストリームレコードのデータコンテンツ上で実行され得る。一方、SMS操作は、レコードのコンテンツを通常考慮せずに、SMS操作の取得、記憶及び検索を実行する。図3は、少なくともいくつかの実施形態による、SMS及びSPSで実装され得るプログラムによるインタフェースのそれぞれのセットの例を示す。いくつかの異なるアプリケーションプログラミングインタフェース(API)は、SMS及びSPSの両方を例として指示する。示されているAPIは、任意の所与の実装で支援される網羅的なリストであることを目的としていない。示されているAPIのいくつかは、所与の実装で支援されなくてよい。
矢印350で示されているように、SPSクライアント375は、SPSプログラムによるインタフェース305を起動して処理ステージを構成し得る。様々な種類のSPSプログラムによるインタフェース305は、異なる実施形態において実装され得る。例えば、createStreamProcessingStageAPIは、クライアントが特定の入力ストリームのために新しい処理ステージ215の構成を要求を可能にし得る。ステージのワーカノードは、インタフェースの起動で特定される、一連の冪等操作を実行し、出力分散ディスクリプタまたはポリシによって表示された宛先に、結果を分散するよう、それぞれ構成される。createStreamProcessingStage APIまたはその等価物のいくつかのバージョンにおいては、クライアントは入力ストリームも同様に作成を要求し得る。一方、その他のバージョンでは、入力ストリームは、処理ステージが作成される前に作成されなければならない可能性がある。リカバリポリシはワーカノードに指定されてよく、例えば、チェックポイントベースのリカバリ技術が使用されるべきか否か、またはベストエフォートのリカバリ技術が好ましいか否かを示す。いくつかの実施形態では、initializeWorkerNode APIは特定のステージでワーカノードの明示的なインスタンス化を要求するために支援され得る。チェックポイントベースのリカバリが実装される実施形態では、saveCheckpoint APIが、プログレスレコードがワーカノードによって生成されるようクライアントが要求することが可能になるよう支援され得る。
様々な種類のSPS出力管理APIは、setOutputDistribution APIのような、異なる実施形態において支援され得る。それによって、クライアントは、特定のステージで実行される処理操作の結果を使用して、1つ以上のストリームが作成されることを示してよく、及び、特定のパーティションポリシが新しく作成されたストリームに使用される。いくつかの処理ステージが再分割のために主に構成され得る。例えば、レコードの属性セットA1に基づいて、データレコードをN1パーティションにマップする1つのパーティション機能PF1は入力ストリームS1に使用され、及びN2パーティションに、(異なる属性セットA2または同一の属性セットA1の何れかを使用して)これらの同一のデータレコードをマップするために処理ステージは異なるパーティションの機能PF2を実装するように使用され得る。linkStageのような、いくつかのSPS APIは、任意のグラフ(例えば、有向非巡回グラフ)を構成するために使用され得る。いくつかの実施形態では、第三者またはオープンソースのストリーム処理フレームワークまたはサービスへのコネクタが支援され得る。このような一実施形態においては、SPSステージは、第三者またはオープンソースシステムが存在することによる消費に、(例えば、ステージで実行される処理操作の結果を適切にフォーマットすることによって)データレコードを用意するために使用され得る。記載された実施形態において、createThirdPartyConnectorのようなAPIは、このようなコネクタを設定するために使用されてよく、SPSステージの結果を適切に第三者システムと互換性があるフォーマットへの変換は、createThirdPartyConnectorの結果としてインスタンス化された、1つ以上のコネクタモジュールによって実行され得る。
SPSは矢印352で示すように、少なくとも機能のいくつかを実行するために、SMS API307を起動してよい。例えば、記載された実施形態では、SMS API307は、createStream及びdeleteStream(それぞれストリームを作成し削除するために)と、(所与のパーティションの役割をする、様々な種類のノードのネットワークアドレスのように、ストリームのためにメタデータを取得するために)getStreamInfoとを含み得る。putRecordインタフェースは、データレコードを書き込むために使用され得る。一方、getIterator及びgetNextRecordsインタフェースは、それぞれ、非シーケンシャルリードとシーケンシャルリードに使用され得る。repartitionStreamインタフェースは、いくつかの実施形態では、特定のストリームの動的再分割を要求するために使用され得る。このようにすることを希望するクライアント370は、矢印354によって示されるように、直接SMS API307を起動し得る。上記のように、様々なその他のSMS及び/またはSPS APIは、また、その他の実施形態で実装されてよく、図3に列挙されたAPIのいくつかは、いくつかの実施形態で実装されなくてよい。
種々の実施形態では、以外のAPIプログラムによるインタフェースもまた、SPSまたはSMSの代わりに、または何れかに実装され得る。このようなインタフェースはグラフィカルユーザインターフェース、ウェブページまたはウェブサイト、コマンドラインインタフェース等を含み得る。場合によっては、ウェブベースのインタフェースまたはGUIは、ビルディングブロックとしてAPIを使用し得る。例えば、ウェブベースの相互作用は、SMSまたはSPSの制御コンポーネントで1つ以上のAPIの起動がもたらされる可能性がある。図4は、少なくともいくつかの実施形態による、SPSクライアントがストリーム処理ステージのグラフ生成を可能にするために実装され得るウェブベースのインタフェースの実施例を示す。ここに示すように、インタフェースは、メッセージ領域402、グラフメニュー領域404及びグラフデザイン領域403を有するウェブページ400を備える。
ユーザは、ストリームの概念及び基本要素についてより学習するために使用可能なリンクと同様に、メッセージ領域402のストリーム処理グラフの構築に関する一般的な命令を提供され得る。いくつかのグラフィカルアイコンは、メニュー領域404におけるストリーム処理グラフツールセットの一部として提供され得る。例えば、クライアントは、様々なSPS処理ステージの入力または出力、永続性ストリーム451、一過性のストリーム452、または第三者の処理環境へのコネクタ453として示すことが可能である。ウェブベースのインタフェースが実装されるSPS/SMSに関して、永続性ストリーム451は、ディスク、不揮発性RAMまたはSSDのようなデータレコードが永続性記憶装置に格納されるストリームとして定義されてよく、一過性ストリーム452はデータレコードが永続性記憶装置に格納される必要がないものとして定義されてよい。一過性ストリームは、例えば、ベストエフォートリカバリポリシが実装される、異なるSPSステージによって入力として消費されることが予想されるSPSステージの出力から作成され得る。
2つの種類の処理ステージが例示的なSPSグラフ構成ウェブページ400において支援されている。チェックポイントベースのワーカノードリカバリが使用されるステージ455(例えば、各ワーカノードがインターバルでプログレスレコードを保存し、特定のワーカノードの破損の場合、交換されたノードが、どのデータレコードが処理を始めるべきか判断する、損失したノードのプログレスレコードを参照する)、及びベストエフォートリカバリが使用されるステージ456が使用される(例えば、交換されたワーカノードはプログレスレコードを参照せず、しかし受信されたときに新しいデータレコードを単に処理し始める)。各ステージで実行される処理操作に関する詳細は、メッセージ領域402における命令によって示されるように、グラフ構成領域403中の対応するアイコンをクリックすることによって、入力され得る。ストリーム、コネクタ及び処理ステージのアイコンに加え、メニュー領域404はまた、第三者または外部のストリーム処理システムを示すアイコンタイプ459を含む。アイコンタイプ460は、リソースが処理ステージに使用される、プロバイダネットワークで実装され得るストレージサービスのノードを示す。
図4に示されている例示的な場合においては、クライアントは、グラフデザイン領域403内に、3つの処理ステージ412、処理ステージ415及び処理ステージ416を備えるグラフ405を構築した。処理ステージ412は、チェックポイントベースのリカバリを使用するよう構成され、入力として永続性ストリーム411を使用する。ステージ412での処理の出力または結果は、ステージ415の入力を形成する、異なる永続性ストリーム413の形態で、及びステージ416の入力を形成する、一過性ストリーム414の形態で、2つの宛先に送信される。ステージ415及びステージ416の両方は、ベストエフォートリカバリポリシをワーカノードに使用する。ステージ415の出力は、一過性ストリームの形態でストレージサービスノード419に送信される。ステージ415の出力は、コネクタ417を介して第三者処理システム418に送信される。「グラフを保存」というボタン420は、例えば、JSON(JavaScript(登録商標) ObjectNotation)、XML(Extensible Markup Language)またはYAML任意の適切なフォーマットで処理ステージのグラフの表示を保存するために使用され得る。任意の複雑な処理ワークフローは、様々な実施形態で、図4に示されたものに類似するツールを使用して構築され得る。このようなツールを使用して作成されたワークフローは、次にアクティブ化され、このようなアクティブ化は、例えば、図4のステージ412のような処理ステージのためにデータレコードを取得するために、SMS APIの起動がもたらされる可能性があり、getIterator及び/またはgetNextRecordインタフェースは、ストリーム411上で起動され得る。
図5は、少なくともいくつかの実施形態による、SMSで実装され得る、プログラミングによるレコードの送信インタフェース及びレコード検索インタフェースの実施例を示す。図示された実施形態において、DR110K及び110Qのような、データレコードは、様々な種類のプログラムによる取り込みインタフェース510を介してSMSに送信され得る。DR110は、いくつかの実施形態で、(ストリーム「S1」に)501Aまたは(ストリーム「S2」に)501Bのようなストリーム識別子、データまたはレコード本体の表示、(504Aまたは504Bのような)任意のパーティションキー504及び(順序付け設定表示506A及び順序付け設定表示506Bのような)任意の順序付け設定表示506の、4つの種類の要素を備え得る。データ自体は、いくつかのレコード(例えば、DR110Kのインラインデータ502)においてインラインにて提供されてよい。一方、その他のデータレコードには、ポインタまたはアドレス503が提供されてよく、SMS(またはネットワークの転送を必要としないローカルデバイスのアドレス)にネットワークにアクセス可能な位置を表示する。いくつかの実施形態では、所与のストリームは、インライン及びバイリファレンス(アドレスベース)データレコード送信の送信によって支援し得る。その他の実施形態では、所与のストリームは、すべてのデータをインラインで、またはすべてのデータを参照によって供給するためにデータ生成部を必要とし得る。いくつかの実装においては、データレコードの送信は、パーティション識別子がレコードに使用されることを含み得る。
図示された実施形態において、入力データレコード110は、パーティションポリシに基づいて、それぞれの取り込み及び/またはストレージノードに向けられ得る。同様に、レコードの検索もパーティションベースであり得る。例えば、1つ以上の検索ノードは所与のパーティションのレコードに向けられた要求の読み取りに対応して指示され得る。いくつかのストリームには、データ生成部は、明示的にパーティションキーに各データレコード書き込み要求を提供することを必要とし得る。その他のストリームには、SMSは、明示的に与えられたパーティションキー以外のメタデータまたは属性に依存するパーティションスキームによるデータレコードを分散することが可能であり得る。例えば、データ生成部への送信に関する識別情報は、パーティションキーとして使用され得る。またはデータ生成部のIPアドレスの一部若しくはすべての送信データが使用されるか、送信されるデータの一部が使用され得る。いくつかの実装においては、例えば、ハッシュ関数が、128ビット整数のような特定のサイズの整数値を取得するために、パーティションキーに適用され得る。そのサイズの正の整数の全範囲(例えば、0から2∧128−1)は、N連続副範囲に分けられてよく、対応するパーティションを表す各副範囲を備え得る。このため、このような実施例においては、データレコードのために決定され、または供給される任意の所与のパーティションキーは、128ビット整数値に対応してハッシュされ、整数値が属する128ビット整数値の連続副範囲は、データレコードが属するパーティションを表し得る。さらにパーティションポリシ及びその使用についての詳細は、図15に関して下記に提供され得る。
特定のパーティションのデータレコードを取り込みまたは受信、データレコードの格納、及び特定のパーティションに対する読み込み要求に応答する役割をするノードのセットは、図5のパーティション用のISR(取り込み、記憶及び検索)ノードと総称される。Sj−Pkという表記は、ストリームSiのk番目のパーティションを表すために使用される。図示した実施形態では、ISRノード520Aは、パーティションS1〜P1のレコードを取り込み、格納及び検索するように構成され、ISRノード520BはパーティションS1〜P2のレコードを設定し、ISRノード520Cは、パーティションS1〜P3のレコードを設定し、ISRノード520Kは、パーティションS2〜P1のレコードを設定し、及びISRノード520Lは、パーティションS2〜P2のレコードを設定する。いくつかの実施形態では、取り込みサブシステム、記憶サブシステムまたは検索サブシステムの所与のノードは、2つ以上のパーティション(または2つ以上のストリームの2つ以上のパーティション)のデータレコードを取り扱うよう構成され得る。いくつかの実施形態では、所与のストリームの単一パーティションのレコードは、2つ以上のノードによって取り込まれ、格納され、または検索され得る。所与のパーティションSj〜Pk用に示された取り込みノードの数は、少なくともいくつかの場合において、異なるパーティションSj〜Pl用に指定された取り込みノードの数と異なり得る。また、Sj〜Pk用に指定された記憶ノードの数及び/またはSj〜Pk用に指定された検索ノードの数と異なり得る。取り込み及び/または検索に関して、SMS制御ノードは、いくつかの実施形態において、どのノードがどのパーティションに対し役割をするかをクライアントが決定することが可能になるように、(getStreamInfoのような)APIを実装し得る。データレコードとパーティションとの間及びパーティションとISRノード(または制御ノード)との間の構成されたマッピングは、下記の動的再分割に関する記載したように、経時修正され得る。
いくつかの実施形態では、いくつかの異なるプログラムによるインタフェース580は、所与のパーティションからストリームデータレコードを検索または読み込みするために実装され得る。図5にて示すように、いくつかの検索インタフェース581は、(特定のシーケンス番号を備えたデータレコードで、または特定のシーケンス番号を備えたデータレコードの後に、イテレータをインスタンス化またはカーソルを読み込みするための)getIteratorまたは(特定のシーケンス番号を備えたデータレコードを読み込むための)getRecordのような、非シーケンシャルアクセスのために実装され得る。その他の検索インタフェース582は、getNextRecord(シーケンス番号の小さい順に、Nレコードがイテレータの現在位置から読み込まれることを要求するインタフェース)のようなシーケンシャル検索のために実装され得る。回転ディスクベースの記憶システムにおいては、前述のように、多くの場合、シーケンシャルI/Oは、ランダムI/Oよりもさらに、より効率的であり得る。平均I/O当たりに要求されるディスクヘッドシークの数は、典型的には、ランダムI/Oに対するよりも、シーケンシャルI/Oに対してはかなり低い可能性がある。多くの実施形態では、所与のパーティションのデータレコードは、シーケンス番号順に書き込まれ得る。シーケンス番号順に基づいて、その結果、シーケンシャル読み込み要求(例えば、getNextRecordまたは類似のインタフェースを使用する)は、ランダムリードリクエストよりも著しくより効率的であり得る。したがって、少なくともいくつかの実施形態では、異なる課金はシーケンシャル対非シーケンシャル検索インタフェースに設定され得る。例えば、クライアントは非シーケンシャルリードに対し、より多く課金され得る。
取り込みサブシステム
図6は、少なくともいくつかの実施形態による、SMSの取り込みサブシステム204の要素の実施例を示す。図示された実施形態において、取り込み操作は、フロントエンド及びバックエンドの機能に論理的に分かれ、データ生成部120(例えば、120A、120Bまたは120C)との相互作用を含むフロントエンドの機能及びSMS記憶サブシステムとの相互作用を含むバックエンド機能を備える。このようなフロントエンド/バックエンドの分割は、記憶サブシステムのセキュリティを向上し、データ生成部にパーティショニングポリシの詳細を提供する必要を避けるなどの、いくつかの利点を有し得る。SMSクライアントライブラリ602は、様々なデータ生成部120でインストールするために提供され得る。データ生成部は、ライブラリ602に含まれるプログラムによるインタフェースを起動して取り込みのためにデータを送信し得る。例えば、一実施形態では、データ生成部120は、何十万かのプロバイダネットワークの物理的及び/または仮想サーバをインスタンス化されたロギングエージェントまたはモニタリングエージェントを備え得る。このようなエージェントは、それぞれのサーバに様々なログメッセージ及び/または測定基準を収集し得る。また、定期的に、収集したメッセージまたは測定基準を、SMSの1つ以上の取り込み制御ノード660によってインスタンス化されたフロントエンド負荷分散装置604の終点に送信し得る。いくつかの実施形態では、1つ以上の仮想IPアドレス(VIP)は、負荷分散装置用に確立され、データ生成部はストリームデータを送信し得る。一実装においては、ラウンドロビンDNS(ドメイン名システム)技術は、データがデータ生成部120によって送信される、いくつかの同等に構成された負荷分散装置のうち、特定の負荷分散装置を選択するためにVIPに使用され得る。
図示された実施形態において、受信されたデータレコードはいくつかのフロントエンドのノード606(例えば、606A,606Bまたは606C)のいずれかに向けられ得る。少なくともいくつかの実施形態では、負荷分散装置604は、データレコードに使用するパーティショニングポリシ650を理解しなくてよい。したがって、フロントエンドノード606は、パーティションベースの負荷調整よりも、ラウンドロビン負荷分散(またはいくつかのその他の汎用負荷調整アルゴリズム)を使用して、所与のデータレコードに選択され得る。フロントエンドのノード606は、様々なストリーム用のパーティショニングポリシ650を理解し、取り込み制御ノード660と相互作用して、所与のパーティションのデータレコードに構成される、特定のバックエンド取り込みノード608(例えば、608A,608Bまたは608C)の識別子を取得し得る。そのため、図示された実施形態においては、フロントエンドのノード604は、データレコードが属するそれぞれのパーティションに基づいて、複数のバックエンドノード606にデータレコードをそれぞれ伝送し得る。上記のように、データレコードが属するパーティションは、データ生成部によって供給されるパーティションキー、データ生成部の識別またはアドレスのような1つ以上のその他の属性、またはデータのコンテンツのような、様々な要因の任意の組み合わせに基づいて決定され得る。
バックエンドノード606は、1つ以上のストリームの1つ以上のパーティションに属するデータレコードをそれぞれ受信し、データレコードを記憶サブシステムの1つ以上のノードに伝送し得る。データがHTTP(ハイパーテキストトランスファープロトコル)の「PUT」ウェブサービスAPIを介して送信される、いくつかの実施形態では、バックエンドノードは、「PUTサーバ」と称され得る。所与のバックエンドノードは、そのデータレコードが制御ノード660にクエリを送信することによって伝送される、記憶サブシステムノードのセットを決定し得る(順次、異なるサブシステムの制御機能が、ノードの分離したセットによって処理される実施形態において、対応するクエリを記憶サブシステムの制御ノードに送信し得る)。
少なくともいくつかの実施形態においては、少なくとも1回の取り込みポリシまたはベストエフォート取り込みポリシのような、いくつかの異なる取り込み応答ポリシ652が支援され得る。少なくとも1回のポリシでは、データ生成部120は、送信された各データレコードに肯定応答を要求し、(第1送信の応答が受信されない場合には)応答が最終的に受信されるまで、繰り返し同じデータレコードを送信し得る。ベストエフォート取り込みポリシにおいては、肯定応答は、送信された少なくともいくつかのデータレコードは必要とされなくてよい(しかしながら、取り込みサブシステムは依然として不定期に応答を提供し得る。またはデータ生成部からの応答の明示的な要求に応答し得る)。取り込みサブシステム204がデータ生成部に応答を提供するよう要求する、いくつかの実施形態では、所与のデータレコードの役割をするバックエンド取り込みノード608は、応答を生成する前に、要求された数のデータレコードの複製が、記憶サブシステムで正常に作成されるまで(例えば、ストリームに確立された永続性ポリシに従って)待機し得る。様々な実施形態では、シーケンス番号は、受信された各データレコードのために取り込みサブシステムによって生成され得る。例えば、類似のパーティションまたはストリームのその他のレコードに関連してそのレコードが取り込まれた順序を示す。またこのようなシーケンス番号はデータ生成部に応答として、または応答の一部として返され得る。シーケンス番号に関するさらなる詳細は、図13a及び図13bを参照して以下に提供され得る。いくつかの実装においては、応答及び/またはシーケンス番号は、フロントエンドのノード606を介してデータ生成部に戻って伝送され得る。少なくとも一実装においては、少なくとも1回のポリシが、取り込みサブシステム自体のフロントエンドノードとバックエンドノードの間で実装され得る。例えば、所与のフロントエンドのノード606は、バックエンドノードが応答を提供するまで、適切なバックエンドノード608にデータレコードを繰り返し送信し得る。
取り込み制御ノード660は、ストリームの動的再分割に起因する、取り込みに関連した構成操作に対し、その他の機能のうち、フロントエンドノードとバックエンドノードをインスタンス化し、ノードのヘルスとワークロードレベルを監視し、必要に応じてフェイルオーバを編成し、所与のパーティションの役割をするノードに関するクエリまたはポリシに関連したクエリへの応答を提供する役割があってよい。いくつかの実施形態では、1つ以上のストリームの所与のセットに指定された、取り込み制御ノードの数は、時間とともに変化され得る。例えば、1つ以上のマスター制御ノードは、必要に応じて制御ノードプールの再構成をする役割をし得る。冗長グループが取り込みフロントエンドノードまたはバックエンドノードに設定される、いくつかの実施形態では、図9及び図10を参照して、さらに詳細に後述のように、制御ノード660は、どのノードがプライマリでどのノードが非プライマリであるか把握し、フェイルオーバに対するトリガ条件検出し、フェイルオーバが要求されたときに置換えを選択し得る。図6に示された、多層の取り込みサブシステム構造は、いくつかの実施形態で実装されない可能性があることに注意する。例えば、取り込みノードの単一セットのみがいくつかの場合において構成され得る。
記憶サブシステム
図7は、少なくともいくつかの実施形態による、SMSの記憶サブシステムの要素の実施例を示す。ここに示すように、取り込みノード608(例えば、フロントエンド及びバックエンド取り込みの役割は、異なるノードのセットによって処理される実施形態におけるバックエンド取り込みノード)は、これらのパーティション用に構成されたそれぞれの記憶ノード702に、ストリームの1つ以上のパーティションのデータレコードを伝送し得る。例えば、パーティションS1〜P1のデータレコード110Aはストレージノード702Aに送信され、パーティションS2〜P3のデータレコード110Bは、ストレージノード702B及びストレージノード702Cに送信され、パーティションS3〜P7のデータレコード110Cは、ストレージノード702Dに送信され、及びパーティションS4〜P5のデータレコード110Dは、ストレージノード702Eに初めに送信される。記憶制御ノード780は、異なるストリームのデータレコードに適用される永続性ポリシ750を実現し、必要に応じてストレージノードを構成及び再構成し、ストレージノードの状態を監視し、フェイルオーバを管理し、ストレージ構成クエリまたはストレージポリシクエリに応答し、及び図示された実施形態において様々なその他の管理タスクをする役割をし得る。
永続性ポリシ750は、異なる実施形態において、様々な方法で互いに異なり得る。例えば、ストリームSjに適用される永続性ポリシP1は、(a)格納される各データレコードのいくつかの複製(b)複製が記憶される記憶装置またはシステムの種類(例えば、複製が揮発性メモリ、不揮発性キャッシュ、回転ディスクベースのストレージ、ソリッドステートドライブ(SSD)、様々な種類のストレージアプライアンス、データベース管理システム中の様々な種類のRAID(安価なディスクの冗長アレイ)、プロバイダネットワークによって実装されるストレージサービスのノードなどに記憶されるべきか否か)(c)複製の地理的分散(例えば、ストリームデータは、異なるデータセンタに複製を配置することによって、大規模な破損または特定の種類の事故に対し回復力があるか否か)(d)書き込み応答プロトコル(例えば、N複製が格納される場合には、応答が取り込みノードに提供される前に、いくつのN複製が正常に書き込みする必要があるか)及び/または(e)データレコードの多数の複製が格納される場合、複製は並行してまたは継続して作成されるか否かという点においてストリームSkに適用されるポリシP2、とは異なり得る。多数の複製が格納されるいくつかの場合には、データレコード110Dの場合のように、所与のストレージノードは、データレコードは別のストレージノードに送信し得る(例えば、ストレージノード702Eはさらにストレージノード702Fにデータレコード110Dをさらに複製するために送信し、ストレージノード702Fはストレージノード702Gを送信する)。多数の複製永続性ポリシが使用される、その他の場合においては、2つのメモリ内複製が格納されるデータレコード110Bの場合においては、取り込みノードは多数の複製を並行して開始し得る。少なくともいくつかの実施形態においては、クライアントの選択した永続性ポリシは、ストリームデータレコードに使用される記憶位置の種類を明示しなくてよい。むしろ、SMSは、記憶技術の適切な種類及び/または費用、性能、データレコードへの費用、性能、データソースへの近接、耐久性の条件等、様々な基準に基づいた位置を選択し得る。一実施形態では、クライアントまたはSMSのどちらかは、所与のストリームの異なるパーティションまたは異なるストリーム用の、異なる記憶技術または記憶位置の種類を使用するために決定し得る。
図7に示された実施例においては、ストリームS1(または少なくともストリームS1のパーティションS1〜P1)に適用される永続性ポリシは、メモリ内ポリシの単一の複製である。一方、ストリームS2には、2つの並行複製メモリ内ポリシが適用される。したがって、データレコード110Aのメモリ内複製704Aは、ストレージノード702Aで作成され、一方、データレコード110Bに対応する2つのメモリ内複製705A及びメモリ内複製705Bは、ストレージノード702B及びストレージノード702Cで並行して作成される。ストリームS3のデータレコード110Cには、単一ディスク上の複製706Aが作成される。ストリームS4には、シーケンシャルな3つの複製のディスク上ポリシが適用可能であり、その結果、それぞれのディスク上の複製707A、複製707B及び複製707Cはシーケンシャルにストレージノード702E、ストレージノード702F及びストレージノード702Gで作成される。様々なその他の種類の永続性ポリシが、異なる実施形態でデータストリームに適用され得る。検索サブシステムのノードは、データコンシューマによる、様々な種類の検索APIの起動に対応する適切なストレージノードから、データレコードを取得し得る。
検索サブシステム及び処理ステージ
図8は、少なくともいくつかの実施形態による、SMSの検索サブシステムの実施例の要素及びSPSとの検索サブシステムの相互作用の実施例を示す。示されているように、検索サブシステム206は、検索制御ノード880の収集と同様に、検索ノード802A、検索ノード802B及び検索ノード802Cのような、複数の検索ノード802を備え得る。検索ノード802のそれぞれは、後述のように、SPSのワーカノード840のような、様々なクライアントまたはデータコンシューマ130からのストリームデータの検索要求に応答するよう構成され得る。様々なプログラムによる検索インタフェース802は、前述した非シーケンシャル検索インタフェース及びシーケンシャル検索インタフェースによって、異なる実施形態において検索ノードによって実装され得る。いくつかの実施形態では、HTTP GET要求のようなウェブサービスAPIは、データレコード検索に使用され、したがって、検索ノード802はGETサーバと称され得る。所与の検索ノード802は、記憶ノード702A及び記憶ノード702Bのような、適切な記憶サブシステム702のセットから、記載された実施形態においては、例えば、検索制御ノード880によって、1つ以上のストリームパーティションのデータレコードを取得するよう構成され得る。
記載された実施形態において、検索ノード802は1つ以上の記憶ノード702と対話し、また、1つ以上のSPSワーカノード840から受信された検索要求に応答し得る。例えば、パーティションS4〜P5のデータレコード(例えば、データレコード110K)及びパーティションS5からP8(例えば、データレコード110L)は、記憶ノード702Aから、検索ノード802Aによって読み込まれ、ワーカノード840A及びワーカノード840Kにそれぞれ提供される。110Mのような、パーティションS6〜P7のデータレコードは、記憶ノード702Aから検索ノード802Bによって読み込まれ、ワーカノード840Kに提供される。パーティションS4〜P7のデータレコードは、検索ノード802Cによって記憶ノード702Bから読み込まれ、ワーカノード840Bに提供され、また、その他のデータコンシューマ130(例えば、SPSを介してSMSと対話する代わりに、直接SMS検索APIをデータコンシューマ起動する)に提供される。
少なくともいくつかの実施形態においては、検索ノード802のいくつか、またはすべては、様々なパーティションのデータレコードが将来の検索要求を予測して一時的に保持され得る、それぞれのキャッシュ804を実装し得る(検索ノード802Aでのキャッシュ804A、検索ノード802Bでのキャッシュ804B及び検索ノード802Cでのキャッシュ804C)。検索制御ノード880は、例えば、キャッシュポリシ(例えば、キャッシュが所与のパーティションを構成するためにどのくらいの大きさであるべきか、データレコードはどのくらいの長さをキャッシュすべきか)、記憶ノード選択ポリシ(例えば、どの特定の記憶ノードが、データレコードの多数の複製が格納される場合において、所与のデータレコードを取得するために最初に接触されるべきか)、などを含む、いくつかの検索ポリシ882を実装する役割をし得る。加えて、検索制御ノードは、検索ノード802をインスタンス化し監視する役割をし、どちらの検索ノードがどちらのパーティションの役割をし、再分割の操作等を開始して、応答するかに関するクエリに応答し得る。
図示された実施例では、SPS290は2つの処理ステージ215A及び処理ステージ215Bを備える。SPS制御ノード885は、パーティションS4〜P5のレコードを処理するワーカノード840A、パーティションS4〜P7のレコードを処理するワーカノード840B、パーティションS5〜P8及びパーティションS6〜P7のレコードを処理するワーカノード840Kのような、様々な処理ステージ215でワーカノード804をインスタンス化する役割をし得る。SPS制御ノード885は、(図3及び図4に示されたような)プログラムによるインタフェースを実装し、SPSクライアントが処理ワークフローを設計するのを可能にする。様々なチェックポイントポリシ850が、異なる処理ステージまたはワークフローに実装されてよく、いつワーカノードがプログレスレコードを格納するべきかを表示し、どのくらいそれぞれのパーティション、プログレスレコード等に使用される記憶装置の種類などを処理しているのかを表示する。フェイルオーバ/リカバリポリシ852は、異なるノードでワーカノードを置き換えすることにつながる、トリガ条件または閾値を表示してよく、ベストエフォートリカバリが使用されるか、チェックポイントベースのリカバリが所与の処理ステージに使用されるかを表示し得る。少なくともいくつかの実施形態においては、SPS制御ノード885は、例えば、所与のストリームのデータレコードが取得される検索ノードを識別し、特定の処理ワークフロー等に必要であり得る新しい一過性または永続性のストリームを確立するために、様々な種類のSMS制御ノードと相互作用してよい。少なくとも一実施形態においては、クライアントはSPS制御ノードと対話し、ストリームをインスタンス化し得る。例えば、SMS制御インタフェースを利用する代わりに、あるクライアントはより高いレベルのSPSインタフェースのみを起動したい可能性がある。SMSの取り込み、格納及び検索サブシステムのための制御ノードの分離したセットは図6、図7及び図8に示されているが、SPSステージには、少なくともいくつかの実施形態では、所与の制御ノードはいくつかのサブシステム及び/またはSPSに使用され得ることに注意する。
ノード冗長グループ
少なくともいくつかの実施形態においては、ノードの冗長グループは、SMSの1つ以上のサブシステム用に構成され得る。すなわち、例えば、ストリームパーティションSj〜Pk用のデータレコードを検索する1つの検索ノードを構成する代わりに、2つまたはそれ以上のノードが、このような検索のために確立されてよく、「プライマリ」と認められている1つのノードまたは所与の時点で動作中の役割をする一方、その他のノードは「非プライマリ」ノードとして設計されている。現在のプライマリノードは、例えば、クライアントまたはその他のサブシステムのノードの何れかから受信した要求の、ワーク要求に応答する役割をし得る。非プライマリノードまたはノードは、例えば、破損、プライマリへの接続不良、またはその他のトリガ条件のため、フェイルオーバがトリガされるまで休眠したままでよく、その場合には、選択された非プライマリは制御ノードによって通知され、従来のプライマリの役割に取って代わってもよい。したがって、プライマリの役割は、フェイルオーバの間、従来のプライマリノードから取り消され、現在の非プライマリノードを許可される。いくつかの実施形態では、非プライマリノードは、フェイルオーバが起こったと決定されたときに、プライマリとして取って代わり得る。例えば、明示的な通知が必要とされなくてよい。様々な実施形態では、このようなノードの冗長グループは、SMSの機能を取り込み、格納、検索及び/または制御するために設定されてよく、類似の手法もまた、少なくともいくつかの実施形態でSPSのワーカノードに取られてよい。いくつかの実施形態では、所与の機能のための、少なくとも1つのプライマリノード及び少なくとも1つの非プライマリノードを備える、このようなグループは、「冗長グループ」または「複製グループ」と呼ばれ得る。ストレージノードの冗長グループは、格納されるデータレコードのいくつかの物理的複製を独立して実装され、例えば、格納されるべきいくつかの複製のデータレコードは、永続性ポリシによって決定されてよく、一方、対応するパーティションのために構成された、いくつかの記憶ノードは、冗長グループポリシに基づいて決定されることに注意する。
図9は、少なくともいくつかの実施形態による、SMSまたはSPSのノード用に設定され得る冗長グループの実施例を示す。記載された実施形態において、所与のストリームパーティションSj〜Pkには、それぞれの冗長グループ(RG)905、冗長グループ915、冗長グループ925及び冗長グループ935が取り込みノード、記憶ノード、検索ノード及び制御ノードのために設定されている。取り込み制御ノード、記憶制御ノードまたは検索制御ノードのための分離したRGはいくつかの実施形態で実装されているが、制御ノードのための共通のRG935は、図示された実施形態において実装されている。各RGは、プライマリノード(例えば、プライマリ取り込みノード910A、プライマリ記憶ノード920A、プライマリ検索ノード930A及びプライマリ制御ノード940A)及び少なくとも1つの非プライマリノード(例えば、非プライマリ取り込みノード910B、非プライマリ記憶ノード920B,非プライマリ検索ノード920C及び非プライマリ検索ノード920D)を備える。プライマリの役割は、それぞれのフェイルオーバポリシ912(取り込みノード用)、フェイルオーバポリシ922(記憶ノード用)、フェイルオーバポリシ932(検索ノード用)及びフェイルオーバポリシ942(制御ノード用)にしたがい、取り消され、現在の非プライマリが許可される。例えば、フェイルオーバポリシは、プライマリステイタスにおける変更につながるトリガ条件管理してよく、プライマリまたは非プライマリのヘルスステータスが監視されているか否か、及びどのように監視されているか、所与の冗長グループ等に構成されるべき非プライマリの数を管理し得る。少なくともいくつかの実施形態においては、単一のRGは、多数のパーティション用に確立され得る。例えば、RG905は、パーティションSp〜Pqと同様に、パーティションSj〜Pkのレコードの取り込みを処理する役割があり得る。いくつかの実装においては、1つのパーティション用のプライマリとして設計されたノードは、同時に、別のパーティション用の非プライマリとして設計され得る。一実施形態では、多数のノードは、同時に、所与のRG内のプライマリノードとして示され得る。例えば、所与のパーティションの取り込みに関連したワークロードは、2つのプライマリノードに分散されてよく、破損した場合に備え、どちらかがプライマリで非プライマリとして示される1つのノードを備える。所与のRG内のインスタンス化されたノードの数は、対応する機能に望ましい入手可能性または回復レベルに依存し得る(例えば、そのグループ耐え得ることを予定しているのが、どのくらい多くの同時発生または重複する破損か)。いくつかの実施形態では、SMSノードへの使用またはSMSノードへの使用の代わりに、冗長グループはSPS処理ステージのワーカノードのために設定され得る。図10に示されるように、所与のRGのメンバは、例えば、いくつかのデータセンタにわたって地理的に時々、分散され得る。いくつかの実施形態では、選択された制御ノードは、例えば、ハートビート機構またはその他のヘルス監視技術を使用し、フェイルオーバトリガ条件を検出するよう構成され得る。また、このような制御ノードは、損失したプライマリの置換えとして、適切な非プライマリノードを選択し、選択された置換えのノード等を通知/起動することによってフェイルオーバを調整し得る。
いくつかの実施形態では、プロバイダネットワークは、複数の地理的領域に分けられ、各領域は1つ以上のアベイラビリティコンテナを含んでよく、本明細書では「アベイラビリティゾーン」とも呼ばれる。アベイラビリティコンテナは、順次、1つ以上の異なる位置またはデータセンタを備え、所与のアベイラビリティコンテナにおけるリソースが、その他のアベイラビリティコンテナにおける破損から絶縁されるような方法で設計され得る(例えば、電力関連装置、冷却装置、物理的安全構成要素等の、独立したインフラストラクチャコンポーネント)。一アベイラビリティコンテナにおける破損は、任意のその他のアベイラビリティコンテナにおける損失という結果にならない可能性がある。このため、リソースインスタンスのアベイラビリティプロフィールまたは制御サーバは、異なるアベイラビリティコンテナにおいて、リソースインスタンスのアベイラビリティプロフィールまたは制御コントロールサーバに依存しないことを意図している。様々な種類のアプリケーションは、それぞれのアベイラビリティコンテナにおける多数のアプリケーションインスタンスを起動すること、または、(いくつかのSMS及びSPSの場合)多数のアベイラビリティコンテナにわたって、所与の冗長グループのノードを分散するによって、多数の単一の位置での破損から保護され得る。同時に、いくつかの実装においては、安価で短待ち時間のネットワークの接続は、類似の地理的領域内にあるリソース(SMS及びSPSノードに使用されるホストまたはコンピュートインスタンス)間で提供されてよく、類似のアベイラビリティコンテナのリソース間のネットワーク伝送がさらに速くなり得る。あるクライアントは、ストリーム管理リソースまたはストリーム処理リソースが予約及び/またはインスタンス化される位置を特定したいと思う可能性がある。例えば、アプリケーションが実行される様々な構成要素の所望の制御度合いを維持するアベイラビリティコンテナレベルまたはデータセンタレベルの何れかの領域レベルリソースが、例えば性能、ハイアベイラビリティ等のクライアントの要求に合致する限り、その他のクライアントは、リソースが予約またはインスタンス化される、実際の場所にあまり興味が無い可能性がある。いくつかの実施形態では、1つのアベイラビリティコンテナ(またはデータセンタ)に配置された制御ノードは、その他のアベイラビリティコンテナ(またはその他のデータセンタ)におけるその他のSMSまたはSPSノードを遠隔から構成することが可能であり得る。つまり、特定のアベイラビリティコンテナまたはデータセンタが、SMS/SPSノードを管理するためにローカル制御ノードを有する必要はない。
図10は、少なくともいくつかの実施形態による、所与の冗長グループのノードが複数のデータセンタに分散され得る、プロバイダのネットワーク環境を示す。図示された実施形態においては、プロバイダネットワーク1002は、3つの可用性コンテナ1003A、可用性コンテナ1003B及び可用性コンテナ1003Cを備える。各可用性コンテナは、1つ以上のデータセンタの一部または全部を含む。例えば、可用性コンテナ1003Aはデータセンタ1005A及びデータセンタ1005Bを備え、可用性コンテナ1003Bはデータセンタ1005Cを含み、及び可用性コンテナ1003Cはデータセンタ1005Dを含む。SMS及び/またはSPSノードのいくつかの異なる冗長グループ1012が示されている。データセンタ1005A内に配置されたRG1012Aの場合のように、いくつかのRG1012は、単一のデータセンタ内に全体が実装され得る。その他のRGは、RG1012Bのように、所与の可用性コンテナ内で多数のデータセンタのリソースを使用してよく、可用性コンテナ1003Aのデータセンタ1005A及びデータセンタ1005Bにわたる。しかしながら、その他のRGは、異なる可用性コンテナにわたって広がるリソースを使用して実装され得る。例えば、RG1012Cは、可用性コンテナ1003A及び可用性コンテナ1003Bのデータセンタ1005B及びデータセンタ1005Cに配置されたリソースをそれぞれ使用し、RG1012Dは、可用性コンテナ1003A、可用性コンテナ1003B及び可用性コンテナ1003C中それぞれのデータセンタ1005B、データセンタ1005C及びデータセンタ1005Dでリソースを利用する。一例示的な配置においては、RG1012が1つのプライマリノード及び2つの非プライマリノードを備え、3つのノードのそれぞれは、異なる可用性コンテナに配置され得る。そのため、少なくとも1つのノードは、大規模な破損イベントが2つの異なる可用性コンテナを同時に起こしても、機能的なままである可能性が高い。
図示された実施形態において、SMS及びSPSのそれぞれに関連する、コンソールサービス1078及びコンソールサービス1076は、使用が簡単なウェブベースのインタフェースを、プロバイダネットワーク1002にストリームに関連する設定を構成するために提供し得る。いくつかのさらなるサービスは、その少なくともいくつかはSMS及び/またはSPSによって使用され得るが、1つ以上のデータセンタにわたる、または1つ以上の可用性コンテナを横断するリソースを使用してプロバイダネットワーク1002にて実装され得る。例えば、仮想計算サービス1072は、実装され得る。クライアントが様々な異なるケーパビリティレベルのコンピュートインスタンスとしてパッケージ化された計算能力の選択された量を利用することができ、このようなコンピュートインスタンスは、SMS及び/またはSPSノードを実装するために使用され得る。1つ以上のストレージサービス1070は、例えばブロックデバイスボリュームインタフェース、またはウェブサービスインタフェースの何れかを介して実装されてよく、クライアントが所望のデータ耐久性でデータオブジェクトを記憶しアクセスするのを可能にする。ストレージオブジェクトは、サービス1072のコンピュートインスタンスに取り付け可能であり得る。またはサービス1072のコンピュートインスタンスからアクセス可能であり得る。いくつかの実施形態では、SMSストレージサブシステムで様々なストリーム永続性ポリシに使用され得る。一実施形態では、ハイパフォーマンスキー値管理サービス1074のような、1つ以上のデータベースサービスまたはリレーショナルデータベースサービスは、プロバイダネットワーク1002で実装され得る。このようなデータベースサービスは、SMNSストレージサブシステムによってストリームデータレコードに及び/または制御サブシステム、取り込みサブシステム、記憶サブシステム、検索サブシステムまたは処理ステージのメタデータを格納するために使用され得る。
ストリームセキュリティオプション
少なくともいくつかの実施形態においては、SMS及び/またはSPSのユーザは、データストリームのためにいくつかのセキュリティに関連するオプションが提供されてよく、クライアントが、取り込み、記憶、検索、処理及び/または制御のような、様々な機能カテゴリに使用するためにリソースのセキュリティプロフィール(例えば、仮想または物理マシン)を選択することが可能になる。このようなオプションとしては、例えば、様々なノードに使用されるリソースの物理位置の種類に関する選択(例えば、プロバイダネットワーク設備が使用されるべきかどうか、またはクライアント所有の設備が使用されるべきかどうかであり、これはプロバイダネットワーク設備とは異なるセキュリティ特徴を有し得る)、ストリームデータの暗号化に関する選択、及び/またはストリーム処理インフラストラクチャの様々な部分においてネットワークを遮断する選択が挙げられる。あるクライアントは、貴重な独占しているビジネスロジックまたはアルゴリズムへのアクセスをする侵入者または攻撃者の可能性について懸念を持ち得る。例えば、クライアント所有のプロミス内の計算装置を使用してストリーム処理ワーカノードを実装し得る。SMS及び/またはSPSノードのセットを実装するために使用されるリソースの種類は、本明細書においては、これらのノードに対する「配置先種類」と称し得る。図11は、少なくともいくつかの実施形態による、SMSまたはSPSのノード用に選択され得る複数の配置先の種類を示す。
図示された実施形態において、配置先は、SMS/SPS機能カテゴリ用のプロバイダネットワーク1102(例えば、取り込み、記憶、検索、制御または処理)及びその他の種類のSMS/SPSの機能カテゴリ用の外部のプロバイダネットワーク1102内で選択され得る。プロバイダネットワーク1102内では、コンピュートインスタンス、ストレージインスタンスまたはデータベースインスタンスのような、いくつかのリソースは、マルチテナントのインスタンスホスト1103を使用して実装され得る。このようなマルチテナントのインスタンスホストは、1つ以上のクライアントに対するSMSまたはSPSノードのそれぞれがインスタンス化されてよく、配置先の種類の第1カテゴリ「A」を形成し得る。その他のクライアントと物理リソースを共有しなければならないことを避けるために、あるクライアントはSMS/SPSノードを単一のクライアントに限定したインスタンスホストを使用して実装されることを要求し得る。このようなシングルテナントのインスタンスホストは、配置カテゴリの種類「B」を形成し得る。シングルテナントのインスタンスホストは、いくつかの理由のため、あるクライアントの観点から、望ましい場合がある。マルチテナントのインスタンスホストは、その他のクライアントに属するコンピュートインスタンスを含み得る。シングルテナントのインスタンスホストよりも、マルチテナントのインスタンスホストにおける別のクライアントのインスタンスからのセキュリティ攻撃の可能性がより高くなり得る。加えて、マルチテナントホストで動くあるクライアントのコンピュートインスタンスCI1は、ワークロードでサージを経験し、ホストの計算サイクルまたはその他のリソースの大きな割合を消費し始め、そのため場合により異なるコンピュートインスタンスCI2上で動く別のクライアントのアプリケーションの性能に衝撃を与える、「ノイジーネイバー」現象は、またシングルテナントのインスタンスホストが使用されるときに避けられ得る。
IVN1106A及びIVN1106Bのような、隔離された仮想ネットワーク(IVN)1106は、図示された実施形態において、配置先種類の別のカテゴリ「C」を表し得る。いくつかの実施形態では、IVN1106は、プライベートネットワークの論理等価として、プロバイダネットワークのクライアントの要求で作成されてよく、プロバイダネットワークのリソースを使用して構築するが、クライアントによって主に制御されるネットワーク構成である。例えば、クライアントは、IVNの外部ですでに使用され得るIPアドレスを複製する可能性について懸念することなしに、IPアドレスを決定し、IVN1106内で使用し得る。図示された実施形態において、1つ以上のIVNにおいて、SMS及びSPSノードの様々な種類の実装は、クライアントのストリームデータの管理及び/または処理に対するネットワークセキュリティのレベルをさらに上げ得る。場合によっては、所与のクライアントは、1つのIVN1106におけるSMS/SPSノードの1つの機能的カテゴリ、及び異なるIVNに異なる機能的カテゴリを配置したいと思う可能性がある。様々な実施形態では、所与のIVN1106は、シングルテナントのインスタンスホストかマルチテナントのインスタンスホストの何れか、またはインスタンスホストの両種類を備え得る。いくつかの実施形態では、プロバイダネットワークのリソースを使用する、配置先種類の選択の別のセット(またはセキュリティプロフィールの選択)は、図11には図示されていないが、少なくともあるクライアントには入手可能であり得る。クライアントが、ストリーム関連の操作のために、プロバイダネットワークの仮想計算サービスからコンピュートインスタンスを取得し使用できる実施形態においては、コンピュートインスタンスは2つのモードのうち1つで使用され得る。1つのモードにおいては、クライアントは、SPSまたはSMSに、実行可能なプログラムまたは、SPSワーカノードとして構成されたコンピュートインスタンスにて(若しくは取り込みノード、記憶ノードまたは検索ノードにて)動作されるプログラムを提供し、SMSあるいはSPSにプログラムを動作させ、ノードを管理させ得る。この第1モードは、ストリーム操作にコンピュートインスタンスを使用する「ストリームサービスが管理する」モードとして呼ばれることもある。その他のモードにおいては、クライアントは、SPSまたはSMSから支援がより少ない状態で、実行可能なプログラムを動かし、コンピュートインスタンスの管理をすることを希望する場合がある。この第2モードは、ストリーム操作にコンピュートインスタンスを使用する「クライアントが管理する」モードとして呼ばれることもある。よって、これら2つの操作モードは、クライアントが選択可能な配置先の種類またはセキュリティプロフィールに関する追加の選択肢を表し得る。例えば、クライアントは、実行可能なプログラムが、クライアントの組織から主題に関する専門家によって最適に実行されるデバッグ(シングルステッピングを含む)を必要とする可能性がある場合には、クライアントが管理するモードを選択し得る。一方、ストリームサービスが管理するモードは、デバッグを必要とする可能性のないより完成したコードには有効な選択肢であり得る。いくつかの実施形態では、異なる価格設定がこれら2つのモードに適用し得る。
いくつかの配置の選択肢が、図11に示された実施形態におけるプロバイダネットワーク外部の設備で支援され得る。例えば、SMSライブラリ1171及び/またはSPSライブラリ1172がインストールされるホスト1160は、クライアントの設備1110Aまたは設備1110B内(例えば、クライアントが所有するデータセンタ若しくは構内)でストリーム管理またはストリーム処理に使用されてよく、2種類のクライアントの設備は、プロバイダネットワークへの接続方法において異なる。クライアントの設備1110Aは、プロバイダネットワーク1102に少なくともいくつかの共有されるインターネットリンク1151を介してリンクされている(すなわち、その他のエンティティのネットワークトラフィックは、また、クライアントの設備1110Aとプロバイダネットワーク1102との間のリンクのいくつかにわたって流れ得る)。対照的に、(1110Bのような)いくつかのクライアントの設備は、特別な共有されない専用の物理リンク1106(時に「直接接続リンク」と呼ばれ得る)を介してプロバイダネットワークにリンクされ得る。これら2つの異なる種類のクライアントの構内は、配置先の選択肢「D」及び「E」を備え、そのそれぞれが図11にて用語が使用されている。いくつかの実施形態では、SMS及び/またはSPSの一部は、また、第三者の構内(例えば、SMS及び/またはSPSのクライアントによって使用されるが所有または管理されないデータセンタ)で実装可能であってよく、このような第三者の構内は、配置先「F」として示され得る。少なくともいくつかのクライアント及び/または第三者の構内においては、SMS及び/またはSPSライブラリは、プロバイダネットワークから取得され、SMS及び/またはSPSノードに使用されるホストにインストールされる必要があり得る。少なくとも一実施形態においては、すべての異なる機能カテゴリのノードは、適切なライブラリの支援でプロバイダネットワークの外部に実装され得る。
異なる実施形態においては、異なる配置先の種類は、ネットワーク隔離の特徴が実装され、侵入検知の機能が支援され、物理セキュリティポリシが実装され、暗号化レベルが支援されるなど、様々なセキュリティに関連する態様において、互いに異なり得る。したがって、様々な配置の種類のそれぞれは、対応するセキュリティプロフィールを有すると考えられてよく、これは1つ以上の方法で、その他の配置先のセキュリティプロフィールとは異なることがある。いくつかの実施形態では、SMS及び/またはSPSのクライアントは、異なるサブシステムまたはノードセットに対し、例えば、図12a及び図12bにて示されているように、SMSまたはSPSの1つ以上の制御ノードに要求を送信することによって、それぞれの配置先の種類をプログラムで選択し得る。注意が必要なのは、いくつかの実施形態及びストリームアプリケーションの特定の種類においては、クライアントは配置先の種類を、単にセキュリティの理由からではなく、性能及び/または機能性の理由から制御したいと思う可能性があることである。例えば、前述のノイジーネイバー現象は、専用のクライアントの設備のリソースまたはシングルテナントのインスタンスホストを使用することにより回避され得る。いくつかの実施形態では、クライアントは、SPSステージまたはSMSノードに使用を希望する専用または専有のハードウェア及び/またはソフトウェアを有し得る。このようなコンポーネントを使用して達成可能な機能上の能力または性能レベルは、プロバイダネットワークで容易に複製されることが不可能であり、または単にプロバイダネットワークで支援されない。クライアントは外部のデータセンタで、スーパーコンピュータレベルの処理能力を有するコンピュータサーバにアクセスし得る。例えば、プロバイダネットワークのリソースのみを使用するときに可能な処理よりも、かなり高い速度でSPS処理を実行することが可能であり得る。クライアントが様々なノードへの配置先を選択することを可能にすることで、このような専用装置または専用ソフトウェアが使用できる。
図12a及び図12bは、少なくともいくつかの実施形態による、SPSクライアント及びSMSクライアントのそれぞれによって送信され得る、セキュリティオプションの要求の実施例を示す。図12aは、SPSセキュリティオプションの要求1200を示し、識別子1210を備える1つ以上の処理ステージには、クライアントが、ステージ(要素1212)の制御ノードに要求される配置先の種類(PDT)、及びワーカノード(要素1214)に要求されるPDTを示す。少なくとも一実施形態においては、クライアントもまた、ストリームデータレコードまたはストリーム処理結果に対する暗号化設定を構成する要求を送信可能であり得る。例えば、様々なネットワークリンクにわたって伝送する前に、特定のアルゴリズムまたはプロトコルを使用して暗号化されるデータレコードを要求することにより、または様々な制御若しくは管理相互作用を暗号化することを要求することにより、例えば、図12aでは、ステージに対する暗号化設定は、ステージ処理操作の結果に適用される暗号化技術及び/またはステージの制御ノードとステージのワーカノードとの間の通信に使用される暗号を示し得る。
同様に、図12bにおいては、クライアントのSMSのセキュリティオプション要求1250は、特定の識別子1252を備える、1つ以上のストリームに対するクライアントのセキュリティの基本設定を示すいくつかの要素を備える。取り込みノード、記憶ノード及び検索ノードに対する配置先の種類の基本設定は、それぞれ要素1254、要素1258及び要素1262に示され得る。取り込み制御ノード、記憶制御ノード及び検索制御ノードに対するPDTの基本設定は、それぞれ要素1256、要素1260及び要素1264に示され得る。例えば、データレコードがあるノードのカテゴリから別のカテゴリへと伝送されるときに、暗号がデータレコードに対して実行されるか否か、及び/またはどのように実行されるか、のようなデータレコードに対する暗号化の基本設定は、要素1266を介して示され得る。図12a及び図12bに示されるようなセキュリティオプションの要求を使用して、クライアントは位置(例えば、プロバイダネットワークの内部またはプロバイダネットワークの外部)及びストリーム管理及び処理環境の異なる部分に対する、様々なその他のセキュリティプロフィールコンポーネントを選択可能であり得る。
ノードの配置先の選択は、少なくともいくつかの実施形態では、セキュリティよりもその他の理由にあることに注意する。例えば、クライアントは、性能上の理由から(例えば、主にセキュリティ上の理由よりもむしろ、前述の「ノイジーネイバー」の問題を避けるため)、シングルテナントのホストで実装される、いくつかの種類のSMSまたはSPSノードを有することを要望し得る。配置の選択は、少なくともいくつかの実施形態では、ストリームの耐用年数の間に変更され得る。例えば、クライアントは最初にSMSノードがマルチテナントのインスタンスホストでのインスタンス化を許可するが、後で、ノードのサブセットの少なくともいくつかをシングルテナントのインスタンスホストに移動することを要望する可能性がある。少なくともいくつかの実施形態では、異なる価格設定が異なるセキュリティ関連のオプションに適用され得る。例えば、IVNの外部のマルチテナントのインスタンスホストよりも、IVNでの特定の機能的カテゴリのSMSノードを実装する方が、費用がかかる可能性がある。またはマルチテナントのインスタンスホストでするよりも、シングルテナントのインスタンスホストでSMSノードを実装する方が、費用がかかる可能性がある。
ストリームレコードのシーケンシャル記憶及びシーケンシャル検索
多くの種類のストリームアプリケーションには、データレコードが複数のデータ生成部120から高速でSMSで受信されてよく、データコンシューマは、典型的には、レコードが生成された順番に、記憶されたデータレコードにアクセスすることを希望し得る。特に、前述したように、回転磁気ディスクがストリームデータレコードに記憶装置として使用される環境においては、シーケンシャルI/Oアクセスパターン(読み出し及び書き込み)は、ランダムI/Oアクセスパターンに優る著しい性能面での利点を有し得る。いくつかの実施形態では、ストリーム固有またはパーティション固有のシーケンス番号は、SMSによって受信されたときに、データレコードを割り当てられ得る。シーケンス番号に基づいたシーケンシャル検索操作が支援され得る。図13aは、少なくともいくつかの実施形態による、ストリームデータ生成部とSMSの取り込みサブシステムとの間の相互作用例を示す。ストリームデータ生成部は、データレコード110を取り込みサブシステムに送信してよく、図示された実施形態においては、取り込みサブシステムは、送信されたレコード用に選択されたシーケンス番号102に応答してよい。少なくともいくつかの実施形態においては、取り込みノードは記憶サブシステムからシーケンス番号の一部を取得し得る。例えば、シーケンス番号102は、このような実施形態における、適用可能な永続性ポリシによる、受信されたデータレコードが記憶された後で決定され得る。また、記憶サブシステムは、データレコードに対し、自身の数列インジケータを生成してよく、取り込みノードによってデータレコードに割り当てられる、より大きなシーケンス番号に含めるために、そのインジケータを提供してよい。
シーケンス番号は、様々な実施形態において、安定的で一貫性のあるデータレコードの順序を提供するため、また、データコンュシーマによってレコード上で繰り返し反復することを可能にするために、実装され得る。少なくともいくつかの実装においては連続である必要はないが、特定のパーティションのデータレコードに割り当てられたシーケンス番号は、時間とともに単調増加し得る。様々な実施形態では、シーケンス番号は以下のセマンティックスの少なくともいくつかのサブセットに割り当てられ得る。(a)シーケンス番号はストリーム内で固有である。すなわち、所与のストリームの2つのデータレコードは同一のシーケンス番号に割り当てられる可能性はない。(b)シーケンス番号は、ストリームのデータレコードに索引付けとして機能し得る。また、所与のストリームパーティション内のデータレコード内を繰り返して使用され得る。(c)任意の所与のデータ生成部には、データ生成部が正常にデータレコードを送信する順序は、データレコードに割り当てられたシーケンス番号に反映される。及び(d)所与のパーティションキー値を有するデータレコードにシーケンス番号の付与は、動的再分割操作にわたって、セマンティックの単調増加を維持する。例えば、再分割後にパーティションキー値K1を有するデータレコードに割り当てられたシーケンス番号は、任意のシーケンス番号よりもそれぞれが大きくてよく、このシーケンス番号は、動的再分割の前にそのパーティションキー値K1を有するデータレコードに割り当てられている。(動的再分割は図16を参照して下記にさらに詳細が記載されている。)
いくつかの実施形態では、データ生成部は少なくともいくつかのデータレコードに選択されたシーケンス番号102の選択に影響したい可能性がある。例えば、そのストリームのデータコンシューマにとって、ストリームの特定のサブセットを対象とする読み出し要求を送信することをより容易にするために、データ生成部120は、境界または割り当てられたストリームのシーケンス番号内のセパレータを画定したいかもしれない。いくつかの実装においては、データ生成部120は、最小のシーケンス番号の表示をレコードとともに送信してよく、また、SMSは、上述したシーケンス番号のセマンティックにも従う、要求最小によるシーケンス番号を選択してよい。
図13bは、少なくともいくつかの実施形態による、SMSでの取り込まれたデータレコードのために生成され得るシーケンス番号の要素例を示す。図示された実施形態においては、シーケンス番号は4つの要素、n1−ビットSMSバージョン番号1302、n2−ビットタイムスタンプまたはエポック値1304、n3−ビットサブシーケンス番号1306及びn4−ビットパーティション番号1308、を含み得る。いくつかの実装においては、128ビットのシーケンス番号が使用されてよく、例えば、n1、n2、n3及びn4は、それぞれ、4、44、64及び16ビットであり得る。バージョン番号1302は、例えば、SMSソフトウェアのどのバージョンがシーケンス番号を生成するために使用されたのか区別を容易にするために、単にSMSソフトウェアバージョンのロールアウトを、混乱を避けるために使用され得る。バージョン番号1302は、少なくともいくつかの態様において変更が頻繁に行われることを想定していない。タイムスタンプ値1304は、例えば、取り込みサブシステムノードによってローカルクロックソースまたはグローバルにアクセス可能なクロックソース(例えば、getCurrentEpochまたはgetCurrentTime APIを実装するプロバイダネットワークの状態管理システム)から取得され得る。少なくともいくつかの実装においては、時間においてよく知られたポイントからのオフセットは、(例えば、1970年1月1日の協定世界時00:00:00から経過した秒数であり、Unix(登録商標)ベースのオペレーティングシステムで、様々な時間に関連したシステムコールによって得ることができる)タイムスタンプ値1304に使用され得る。いくつかの実施形態では、サブシーケンス番号1036は、記憶サブシステムによって生成されてよく、特定のパーティションのデータレコードが記憶装置に書き込まれる順を示してよい。このように、多数のデータレコードが所与の秒内に受信され、タイムスタンプ値1304が約1秒から2秒の間隔でのみ変更する実装においては、サブシーケンス番号1306は、たまたま同一の秒内に到着し、そのため同一のタイムスタンプ値の割り当てられるデータレコードに対し、レコードが到着(または記憶)する順のインジケータとしての役割をしてよい。いくつかの実施形態では、パーティション番号1308は、所与のストリーム内のパーティションを固有に識別し得る。対応するデータレコードが取り込まれるシーケンス番号のタイムスタンプが(少なくともほぼ)クロックタイムを示す少なくともいくつかの実装においては、シーケンス番号が特定の種類の時間ベースの検索要求のためのインデックス機構に使用され得る。例えば、クライアントは、特定の日または特定の時間範囲の間に生成され取り込まれたストリームレコードを検索することを希望し、シーケンス番号はデータレコードの適切なセットを検索する暗黙の二次インデックスのキーとして使用され得る。このように、少なくともいくつかの実施形態においては、並べられた記憶及び検索に対するタイムスタンプを含むシーケンス番号の使用は、時間的なインデックスを格納されたデータレコードのセットに提供する追加の利点を有し得る。
所与のパーティションのデータレコードは、典型的には、シーケンス番号順に(例えば、ディスクに)書き込まれ、しばしば大規模な連続的な書き込み操作を使用して書き込まれる。いくつかの実施形態では、前述したように、イテレータベースのプログラムによるインタフェースは、データコンシューマがシーケンス番号順にデータレコードを読み込むことができるように実装され得る。図14は、少なくともいくつかの実施形態による、SMSでのストリームデータレコードを順番に並べられた記憶及び検索する実施例を示す。パーティションSj〜Pk(ストリームSjのk番目のパーティション)の、6つのデータレコード110A〜110Fがシーケンス番号順に格納されていることを示す。図示されているように、シーケンス番号は少なくともいくつかの実施形態において、連続していない場合がある。例えば、値がタイムスタンプ部1304に割り当てられる手法か、または上述したサブシーケンス番号1306は、それらの要素に対して必ずしも連続値になるとは限らないからである。
図14に示された実施例においては、データコンシューマは、イテレータが作成するよう要求し、シーケンス番号「865」での開始を明示する。要求に対して、SMSは、イテレータ1を初期化し、要求された開始シーケンス番号よりも大きいか等しい、最も近いシーケンス番号でデータレコードに配置する。この場合、シーケンス番号870のデータレコード110Cは、イテレータの開始位置として選択されており、次のより低いシーケンス(データレコード110Bに割り当てられた860)は、コンシューマの要求における開始シーケンス番号よりも小さい。このgetIteratorインタフェースは、パーティション内の要求された位置でカーソルを設定するための要求の論理等価として考えられ、getNextRecordインタフェースは、次に、例えばシーケンス番号順にストリームに沿ってカーソルを移動するために、カーソルの位置から始まるデータレコードを読み出すために使用され得る。図示された実施例では、データコンシューマはgetNextRecordインタフェースを“iterator”のセットをIterator1に、“maxNumRecords”(データレコードを返す最大数)のセットを3にするパラメータで起動する。したがって、SMS検索サブシステムは、データレコード110C,データレコード110D及びデータレコード110Eをその順でデータコンシューマに返す。イテレータのIterator1は、例えば、データレコード110Fのような、新しい位置に移動され、getNextRecordが完了を宣言した後、次に同一のイテレータに対するgetNextRecordの起動は110Fで始まるデータレコードを返し得る。getIteratorの宣言のセマンティックスはいくつかの実施形態において異なり得る。例えば、特定のシーケンス番号よりも大きいか等しい、最も近いシーケンス番号でデータレコードでイテレータを配置する。イテレータは、いくつかの実施形態で、要求されたシーケンス番号と等しいかまたは低い最も近いデータレコードに配置され得る。別の実施形態では、クライアントはgetIteratorの呼び出しにおける現在のシーケンス番号を特定しなければならない可能性がある。例えば、要求されたシーケンス番号がストリーム中に存在しない場合、エラーが返され得る。
パーティションマッピング
前述したように、様々なパーティション及び再分割ポリシによる様々な実施形態においては、所与のストリームのレコードの取り込み、記憶、検索及び処理に関するワークロードは、細分化され、いくつかのノードに分散される。図15は、少なくともいくつかの実施形態による、SMSノード及びSPSノードのために作成され得るストリームパーティションマッピング1501及び対応する構成決定の実施例を示す。例えばクライアントによるcreateStream APIの起動に対応して、特定のデータストリームが作成されるか初期化されるとき、パーティショニングポリシはストリームのために有効にされ、ストリームの任意の所与のデータレコードがメンバと考えられるか、パーティションを決定するために使用され得る。所与のデータレコードに対して操作を実行する、取り込みサブシステム204、記憶サブシステム206、検索サブシステム208及び任意の関連するSPSステージ215の特定のノードは、レコードのパーティションを基準にして選択され得る。一実施形態では、所与のデータレコードに使用される少なくとも制御ノードのサブセットは、パーティションにも基づいて選択され得る。少なくともいくつかの実施形態においては、データレコードの動的再分割は、例えば、ポリシに示されたトリガ条件または明示的な要求に対応して、パーティションポリシの一部として支援され得る。
様々な実施形態では、所与のデータレコードに選択されたパーティションは、レコードに対しては、パーティションキーに依存し、その値はデータ生成部によって直接(例えば、パラメータの書き込みまたは要求として)または間接的(例えば、SMSは、データ生成部のクライアントの識別子若しくは名前、データ生成部のIPアドレス、またはパーティションキーとしてデータレコードの実際のコンテンツの一部のようなメタデータを使用し得る)の何れかで供給され得る。1つ以上のマッピングの機能1506は、図15に示された実施形態のデータレコードのパーティション識別子1510を決定するために、データレコードのパーティションキーまたは属性1502に適用されてよい。一実装においては、例えば、所与のパーティション識別子1510は、128ビットの整数値のスペースの連続した範囲にわたって、表し得る。ストリームのすべてのパーティションに対する範囲のユニオンが、128ビットの整数値が仮定する、すべての可能な値をカバーし得る。このような例示的な場合においては、1つの単純なマッピング機能1506は、データレコードのパーティションキー値(単数または複数)から128ビットのハッシュ値を生成するか、データレコードの属性値を選択されてよく、パーティションの識別子は、ハッシュ値がある特定の隣接する範囲に基づいて決定され得る。いくつかの実装においては、隣接する範囲は、少なくとも最初はサイズが等しく、その他の実装では、異なるパーティションは、互いにサイズが異なり得る隣接する範囲に対応する。再分割は、また、1つの実装において範囲の境界を調整する結果となり得る。その他のパーティション機能106は、異なる実装で使用され得る。
データストリームが(さらに詳細に下記に記載されているように)動的再分割された場合、特定のキーを有するレコードがマップされるパーティションは変更し得る。したがって、少なくともいくつかの実施形態においては、SMS及び/またはSPS制御ノードは、ストリームの耐用年数の間、ストリームに適用する、いくつかの異なるマッピングを把握する必要がある。いくつかの実施形態では、タイムスタンプの有効性の範囲1511のようなメタデータまたはシーケンス番号の有効性の範囲は、各パーティションマッピングに制御ノードによって格納され得る。タイムスタンプの有効性の範囲1511は、例えば、特定のマッピングM1は、ストリームの作成時間から時間T1までを適用し、異なるマッピングM2はT1からT2等に適用することを表し得る。ストリームに向けられた読み出し要求に応答して、検索ノードは、どのマッピングが(例えば読み出し要求に示されたシーケンス番号に基づいて)使用され、次にそのマッピングを適切な記憶ノードを識別するために使用する。
少なくともいくつかの実施形態では、SMS制御ノード及びSPS制御ノードは、いくつかの異なる粒度でパーティションをリソースにマッピングする役割をし得る。例えば、図15の例示的な実装1599に示されているように、1つの実装、各取り込み、記憶、検索または処理(ワーカ)ノードは、実装され得る。サーバ仮想マシン内でそれぞれの処理、または実行のそれぞれのスレッドとしてJava(登録商標)仮想マシン(JVM)またはコンピュートインスタンス、及び各JVMまたはコンピュートインスタンスは特定の物理ホストでインスタンス化され得る。いくつかの実施形態では、多数のJVMは、単一のコンピュートインスタンス内で起動されてよく、リソースのマッピング決定の別の層を加える。したがって、所与のパーティションには、1つ以上の制御ノードが、どの特定のリソースが取り込みノード1515、記憶ノード1520、検索ノード1525または処理ステージワーカノード1530(例えば、ステージPS1またはステージPS2に対してそれぞれ、ノード1530Aまたはノード1530B)として使用されるべきか、選択し得る。制御ノードは、また、それらのノードをサーバ(取り込みサーバ1535,ストレージサーバ1540,検索サーバ1545または処理サーバ1550のように)にマッピングすること、及びサーバとホスト(取り込みホスト1555、ストレージホスト1560、検索ホスト1565またはSPSホスト1570A/ホスト1570B)との間をマッピングすることを決定し得る。いくつかの実装においては、パーティションマッピングは、示されている様々なリソースの粒度(例えば、ノード、サーバ及びホスト粒度)のそれぞれに、識別情報(例えば、リソースの識別子)を含むと考えられ得る。機能1506自身と同様に、機能1506への入力として使用されるデータレコードの属性の表示が使用される。制御サーバは、メタデータ記憶にてパーティションマッピングの表示を記憶し得る。いくつかの実施形態では、(getPartitionInfoAPIのような)様々なAPIまたはその他のプログラムによるインタフェースを暴露して、データ生成部、データコンシューマまたはSMSサブシステムのノードまたはSPSにマッピングの情報を提供し得る。
データレコードをパーティションにマッピングすること、及びパーティションからリソースにマッピングすることは、(a)所与のノード、サーバまたはホストは、いくつかの実施形態において、多数のパーティションの役割をするよう設計され得る、または(b)破損またはその他のトリガは、所与のパーティションまたはパーティションのセットに割り当てられた新しいノード、サーバまたはホストがもたらされる可能性があるというような、様々な要因からさらにいくつかの実施形態においては複雑になり得る。加えて、上記に示したように、また下記に記載するように、所与のストリームに対するパーティションマッピングは、ストリームレコードがSMSノード及び/またはSPSノードによって処理され続ける一方、時間の経過とともに動的に修正され得る。その結果、マッピングのメタデータのいくつかのバージョンは、いくつかの実施形態においては、少なくとも一時的に所与のストリームに保持されるため、それぞれは異なる時間にそれぞれ対応し得る。
動的ストリームの再分割
図16は、少なくともいくつかの実施形態による、動的ストリームの再分割の実施例を示す。図16に示された時系列の時間T1で、ストリームS1が作成されるか初期化される。パーティションマッピングPM1は、ストリームS1のために作成され、時間間隔T1からT2の間に有効を維持する。T1とT2との間のSMSによって受信された3つのデータレコードは、一例として示されている。データレコード110A(DR110A)は、クライアントが供給するパーティションキー値「Alice」とともに送信され、DR110Bはクライアントが供給するパーティションキー値「Bill」とともに送信され、DR110Cは、クライアントが供給するパーティションキー値「Charlie」とともに送信される。初期のマッピングPM1において、すべての3つのデータレコード110A、データレコード110B及びデータレコード110Cは、パーティション識別子「P1」を備える同一のパーティションにマッピングされる。P1データレコードには、単一のノードI1が取り込みを処理するために構成され、単一のノードS1は、記憶装置を処理するために構成され、単一のノードR1は、検索を処理するために構成され、及び単一のワーカノードW1は、SPS処理を行うために構成される。PM1をマッピングする有効な範囲の開始のタイムスタンプはT1に設定されている。
時間T2、ストリームS1は、図16の例示的な時系列において動的に再分割される。図示された実施形態において、データレコードは継続して到着し、SMS及びSPSによって処理される。再分割がいつ起こるのかに関係なく、SMSまたはSPSの何れもオフラインにする必要はない。例えば、取り込み、記憶、検索または処理ノードにおいてオーバーロード状態の検出に対応して、様々なサブシステムの異なるホストでのワークロードレベル間のずれ、または不均衡の検出に対応して、またはデータコンシューマ若しくはデータ生成部からの要求に対応して、再分割はいくつかの要因のいずれかの結果として開始され得る。図示された実施形態において、PM2に示された有効範囲の開始タイムスタンプの設定によって示されるように、新しいマッピングPM2は、時間T2(またはT2の直後)で影響を及ぼす。少なくともいくつかの実装においては、データレコードの属性の異なるセットは、再分割の前に使用されたよりもデータレコードの分割に使用され得る。場合によっては、追加の分割の属性は、(例えば、SMSの要求で)データ生成部によって送信され得る。一方、その他の場合では、追加の属性はSMS取り込みノードによって生成され得る。このような追加の属性は「塩漬けされた」属性と称され得る。再分割に追加の属性を使用する技術は、「塩漬けする」と称され得る。一例示的な実装においては、オーバーロードした取り込みサーバは、データ生成部(例えば、データ生成部によって実行されるSMSクライアントライブラリコード)に示してよく、再分割には、無作為に選択された小整数値が以前に使用されたパーティションキーに加えて提供される。元のパーティションキーと塩漬けされた追加の整数との組み合わせは、その後に、取り込みノードの異なるセットに取り込みワークロードを分散するために使用され得る。いくつかの実施形態では、検索ノード及び/またはデータコンシューマは、再分割に使用される追加の属性に関して通知される必要があり得る。このような追加の属性は、少なくともいくつかの実装において、再分割に使用されなくてよい。
図16に示す実施形態では、T2前の同一のキーのために選択されたパーティションに対して、新しいパーティションマッピングは、T2の後に受信されたデータレコードの少なくともいくつかのために選択された、異なるパーティションの結果になる。DR110Pは、パーティションキー値「Alice」でT2の後に送信され、DR110Qは、パーティションキー値「Bill」でT2の後に送信され、DR110Rは、パーティションキー値「Charlie」でT2の後に送信される。図示された場合においては、PM2のマッピングを使用して、DR110Pは、パーティション「P4」のメンバに指定され、DR110Qは、パーティション「P5」のメンバに指定され、一方、DR110Rは、パーティション「P6」のメンバに指定される。図示された実施形態において、T2の後の受信として示される、例示的なデータレコードの何れも、以前に使用されたパーティションの「P1」のメンバとして指定されない。その代わりに、完全に新しいパーティションが、再分割後に使用され得る。いくつかの実施形態では、少なくともいくつかの以前に使用されたパーティションが再分割後に使用され続けてよい。新しいパーティションのP4、P5及びP6のそれぞれには、異なるノードが取り込み、記憶、検索及び/または処理に指定され得る。例えば、ノードI4、ノードS4、ノードR4及びノードW4は、パーティションP4に構成されてよく、ノードI5、ノードS5、ノードR5及びノードP5は、パーティションP5に構成されてよく、ノードI6、ノードS6、ノードR6及びノードP6は、パーティションP6に構成されてよい。いくつかの実施形態では、同一の記憶ノードは、再分割前のこのようなレコードに使用されたように、再分割後の特定のパーティションキーまたは属性を備えるレコードに使用され得る。しかしながら、そのノード(例えば、異なるディスク、異なるディスクパーティションまたは異なるSSD)内の異なる記憶位置は、再分割後に使用され得る。
T2での動的再分割後、少なくともある時間、検索要求は、再分割の前にSMS取り込み及び/または記憶サブシステムによって処理された、データレコードのために、継続して検索されてよい。少なくともいくつかの場合においては、要求されたデータレコードは、データレコードが取り込まれた時に有効である、PM1マッピングに基づいて検索される必要があり得る。したがって、図16に示されたように、データ検索の目的で、PM1及びPM2の両方は、T2の後のある時点で継続して使用され得る。少なくともいくつかの実装においては、データレコードは、古くなるにつれて、ストリームから最終的に削除され、より古いパーティションマッピングは、また、最終的に破棄され得る。例えば、すべての対応するデータレコード自体が削除される。いくつかの実施形態では、削除される代わりに(または削除の前に)、ストリームレコードは、SMSによって使用されるパーティションマッピングは、アーカイブの後、レコードを検索することが依然として不可能なように、記憶位置または記憶装置の異なるセットに、(例えば、クライアントが選択したアーカイブポリシに基づいて)アーカイブされ得る。このような実施形態においては、アーカイブストレージに向けられた検索要求を支援する必要がある限り、PM1及びPM2のようなパーティションマッピングは保持され得る。いくつかのアーカイブの実装においては、ストリームパーティションマッピングが保持される必要のない、異なる検索手法が使用され得る(例えば、新しいインデックスがアーカイブされたデータレコードのために作成され得る)。いくつかの実施形態では、再分割の前に使用されたが、再分割の後、書き込みがもはや指示されない、P2のようなパーティションは、再分割の後ある時点で読み込みのために「閉じられ」得る。例えば、「パーティションの最後に達しました」というエラーメッセージの等価は検索要求に対して提供され得る。
いくつかの実装においては、所与のデータストリームは、多数(例えば、何十万)のパーティションに分かれ得る。ストリームS1が初めに1000のパーティションのP1,P2,・・・,P1000に分かれる例示的な場合を考える。1つのパーティション、例えばP7に対応するオーバーロード状態が検出される場合、データレコードP7を初期のマッピングを変更することは価値があり得るが、その他のパーティションのマッピングは、変更される必要はない。1つの手法においては、2つの新しいパーティションP1001及びP1002が、再分割操作を介して作成され得る。その属性が元々、(すなわち、元のマッピングを基準として)P7におけるメンバの結果となる再分割後に受信されたレコードは、再分割後、つまり、2つのパーティションのうち、P7のワークロードを分配した後、P1001またはP1002のいずれかにマッピングされ得る。残余のパーティション、例えばP1〜P6及びP8〜P1000は、修正される必要はなくてよい。小さなパーティションのサブセットのみがこのような再分割によって影響を受けるため、少なくともいくつかの実施形態では、パーティション入力(またはパーティション入力のツリー)の有向非巡回グラフのような組み合わされたデータ構造が、生成され、格納され得る。各入力は、パーティション機能の出力範囲と、有効な時間範囲(入力のパーティション情報が有効である時間)を示し得る。前述の例では、P7を含む再分割は、時間T2で実行された。一方、ストリームS1(及びその初期のマッピング)は時間T1で作られる。このような場合においては、P7に関する入力の有効な時間は「T1からT2」であり、P1001及びP1002の有効な時間は「T2以降」、及び残りのパーティションの有効な時間は、「T1以降」であろう。このような組み合わされたデータ構造の使用は、少なくともいくつかの実装における、パーティションマッピングのメタデータに使用される、メモリまたはストレージに実質的な減少につながり得る。上記の例では、パーティションP7を2つの新しいパーティションに分けることが記載されていた。少なくともいくつかの実装においては、パーティションはまた、再分割をする間にマージされ得る。例えば、比較的少ない検索要求が受信され、または比較的少ないレコードが送信された、2つの隣接したパーティションは、単一のパーティションにマージされ得る。任意の所与の時点では、データレコードが属するパーティションは、パーティションの機能及び有効な時間範囲の情報を使用して、明確に決定され得る。時間の経過とともに、組み合わされたデータ構造は、より多くの分割及び/またはマージが実行されながら発展し得るが、メタデータを分割するために必要な全空間は、急激に増加し得ない(分割の頻度、分割によって影響を受けるパーティションの平均数)。対照的に、異なる実施形態では、再分割が起こるたびに、ストリームのための変更されていないメタデータのセットの全体が、複製され、再分割の影響を受けたパーティションのための入力とセットで組み合わされ得る。パーティションマッピングのメタデータのためのストレージ及びメモリの要求は、後の実装においては、さらに速い速度で増加し得る。特に以前のマッピングが上記のように、再分割後の少なくともある時点で、保持される必要があり得る。
タイムスタンプ値(図13bに示されたタイムスタンプ値1304のような)を含むシーケンス番号が使用される、少なくともいくつかの実施形態では、シーケンス番号の推移の特定の種類は、動的再分割のために実装され得る。図13bに示されているのと同様に、タイムスタンプベースのシーケンス番号のスキームがストリームS1に使用される一例として考えると、新しいタイムスタンプ値が常にシーケンス番号で生成される動的再分割が支援される少なくともいくつかの実装においては、動的再分割後割り当てられたシーケンス番号は、(再分割に対応して、選択された初期のタイムスタンプ値から始まる)動的再分割前に使用されるものと異なるタイムスタンプ値のセットをすべて使用し得る。例えば、動的再分割がコミットする(すなわち、有効になる)時間で使用されるタイムスタンプ値がTkであった場合には、コミット後に発行される新しいシーケンス番号は、Tk+1以降のタイムスタンプ値を使用する必要があり得る。シーケンス番号値が、図13bに使用されるスキームにおける少なくともいくつかの上位ビットをタイムスタンプ値を符号化するため、記載されたように、タイムスタンプの境界に対応する再分割のイベントは、順次、検索要求に対応して使用されるマッピングの識別に関する記帳を簡素化し得ることを確実にする。したがって、このような実装においては、特定のシーケンス番号を特定する検索要求が受信されると、タイムスタンプ値がシーケンス番号から抽出されてよく、再分割後のマッピングが使用されるべきか、または再分割前のマッピングが使用されるべきかを容易に判断され得る。抽出されたタイムスタンプ値が、再分割のために選択された初期のタイムスタンプよりも低い場合には、再分割前のマッピングが使用されてよく、抽出されたタイムスタンプ値が再分割に選択された初期のタイムスタンプ値に等しいかまたは高い場合には、再分割後のマッピングが使用され得る。
ストリームの管理及び処理の方法
図17は、少なくともいくつかの実施形態による、ストリームレコードの取り込み及びストリームレコードの検索用のプログラムによるインタフェースのそれぞれのセットを支援するために実行され得る、操作の態様を示すフローチャートである。要素1701に示されているように、例えば、SMSのクライアントまたはデータ生成部のクライアントから、データストリームを作成するか初期化する要求が受信され得る。ストリームに使用される初期のパーティションマッピングは、決定され得る(要素1704)。例えば、特定のデータレコードが属するパーティションを識別するのに使用される機能(単数または複数)、及び機能(単数または複数)に使用される入力パラメータは、パーティションポリシに基づいて識別され得る。前述のように、SMSの制御コンポーネントは、様々な実施形態で、ストリームの作成要求を受信し、応答する役割をし得る。ストリームの作成及び初期化が実行される方法(その他の制御プレーン操作と同様に)は、一実施形態から別の実施形態によって異なり得る。一実施形態では、例えば、制御サーバの冗長グループが確立されてよく、その冗長グループのプライマリ制御サーバは、(例えば、初期パーティションマッピング、取り込みノード、記憶ノード及び検索ノード等の初期のセット)新しいストリームのために、永続性記憶位置に、適切なメタデータを生成し格納することによって、ストリーム作成要求に応答してよい。ストリームに関する次のクエリに対する応答(例えば、所与のパーティションの役割をするバックエンドノードに関するフロントエンドの取り込みノードからの要求)は、格納されたメタデータを使用するプライマリ制御サーバによって生成され得る。SMS制御プレーンの機能の別の実装では、ストリーム構成のメタデータは、取り込みサブシステム、記憶サブシステムまたは検索サブシステムの少なくともいくつかのノードによって直接アクセス可能なデータベースに格納され得る。ストリームが作成し初期化された後、典型的には制御コンポーネントと追加の相互作用をせずに、レコードの送信、記憶及び検索のようなデータプレーンが開始してよく、対応するサブシステムのそれぞれのコンポーネントによって処理されてよい。
いくつかの実施形態では、データ生成部は書き込み要求を有する明示的なパーティションキーを送信する必要はなくてよい。一方、その他の実施形態においては、パーティション機能に使用される入力は、データ生成部の識別、データレコードが受信されるIPアドレス、またはデータレコード自身のコンテンツからのような、書き込み要求に関連するメタデータに基づいて決定され得る。少なくとも一実装においては、クライアントは所望により、データレコードの送信におけるパーティションの識別子を供給し、追加のパーティション機能は、このような実装にいて必要とされなくてよい。
ストリームのための取り込み機能、記憶機能及び検索機能用のノードの初期セットを決定または構成するとき、いくつかの異なる要素が考慮に入れられ得る(要素1707)。例えば、(ストリームが分けられるパーティションの数及びパーティションの関連する予想サイズを決定し得る)パーティションマッピング自体、このような情報が入手可能な場合には予想される取り込み率及び/または検索率に関する情報、ストリームデータレコードのための耐久性/永続性の要件、及び/または(図9及び図10に示されたものと類似の冗長グループの設定になり得る)様々なサブシステムのための高可用性の要件は、異なるサブシステムのノードの数と配置に影響し得る。加えて、クライアントが、(図11、図12a及び図12bに示されるように)様々なカテゴリのノードに対して配置先種類の基本設定を示し得る実施形態においては、このような基本設定は、また、SMS及び/またはSPSノードに使用されるリソースを決定する上で役割をし得る。少なくともいくつかの実施形態においては、取り込み、記憶及び/または検索機能の実行が可能なノードのそれぞれのプールは、前もって設定され、制御コンポーネントは、作成される新しいストリームのそれぞれにこのようなプールの選択されたメンバを割り当て得る。その他の実施形態では、少なくともいくつかの場合においては、新しい取り込みノード、記憶ノードまたは検索ノードは、ストリームが作成または初期化されるときにインスタンス化される必要があり得る。
図示された実施形態における取り込みノードでは、レコードは、例えば、(データは送信要求に含まれている)インラインの送信インタフェースを含む、データレコードの送信(要素1710)のために実装されたプログラムによるインタフェースのセットのいずれかを介して受信され、参照によるバイリファレンス送信インタフェース(アドレスが送信要求に提供され、たとえば、ウェブサービス要求またはその他のインタフェースを使用してデータがSMS取り込みノードまたはSMS記憶ノードによって検索され得る。)いくつかの異なる種類のプログラムによるインタフェースのいずれかは、レコードを送信する方法のそれぞれに、異なる実施形態に提供され得る。例えば、それぞれのアプリケーションプログラミングインタフェース(API)は、インライン対バイリファレンス送信のために支援され得る。ウェブページまたはウェブサイトは確立され、グラフィカルユーザインターフェースが実装され、またはコマンドラインツールが開発され得る。少なくともいくつかの実施形態においては、SMSは各取り込みレコードにシーケンス番号を割り当て得る。例えば、レコードが取り込みまたは格納される順に表示し、シーケンス番号はデータコンシューマによって検索要求に使用可能であり得る。検索サブシステムノードでは、レコード検索要求は、実装されたプログラムによる検索インタフェースの任意のセットを介して受信され、要求されたデータレコードのコンテンツは、応答(要素1713)に提供され得る。非シーケンシャルなアクセスには、例えばインタフェースは、(getIteratorの起動で示されたシーケンス番号に基づいて、イテレータがパーティション内で選択された位置でインスタンス化されるように要求する)getIteratorまたは(特定のシーケンス番号を備えたデータレコードを取得するための)getRecordWithSequenceNumberを含み得る。シーケンシャルなアクセスには、(イテレータの現在位置から始まる順、または特定のシーケンス番号から始まる順に、いくつかのレコードを要求する)getNextRecordのようなインタフェースが実装され得る。少なくともいくつかの実施形態においては、異なる検索インタフェースは、それに関連する異なる課金率を有し得る。例えば、シーケンシャル検索のためのレコード課金毎の率は、非シーケンシャル検索に対するレコード毎の課金率より低く設定され得る。異なる送信インタフェースは、またいくつかの実施形態において、異なる課金率を有し得る。例えば、バイリファレンス送信は、インライン送信よりもレコード毎の費用がよりかかり得る。
時間の経過とともに、制御ノードまたは特定の課金サーバは、ストリーム管理サービス(要素1716)の様々なサブシステムで実装される異なるプログラムによるインタフェースに対する使用メトリクスを収集し得る。例えば、このメトリクスは、異なるプログラムによるインタフェースの起動カウントと、(単一起動で多数のレコードを検索するために使用され得るgetNextRecordのような、少なくともいくつかのインタフェースのための起動カウントとは異なり得る)取り込まれるか検索されるレコードの総数と、取り込まれるか検索されるデータの総量等とを含み得る。ストリームを所有するクライアントまたはストリームからデータを生成及び/若しくは消費するクライアントに請求される課金額は、プログラムによるインタフェース(要素1719)に関連する、少なくとも部分的に使用メトリクス及びそれぞれの課金率に基づいて、所望により生成され得る。少なくともいくつかの実施形態においては、課金動作は、ストリーム取り込み/検索操作に関して非同期であり得る。例えば、請求書はその月の間に収集されたメトリクスに基づいて月毎の請求期間の最後に生成され得る。
図18aは、少なくともいくつかの実施形態による、ストリーム処理ステージ(SPS)を構成するよう実行され得る、操作の態様を示すフローチャートである。要素1801に示されているように、プログラムによるインタフェースは、クライアントがストリームデータレコードのためにいくつかの処理ステージ構成可能にするよう実装され得る。例えば、特定のステージを構成するために、クライアントは、ステージで分割されたストリームデータレコード上で実行される処理操作(単数または複数)を示してよく、処理されるデータの入力ストリームの識別のような、その他のパラメータと同様に、処理操作の出力のための分散ポリシが取得され得る。いくつかの実施形態では、SPSステージでの処理操作は、冪等に必要であり得る。その他の実施形態では、非冪等の操作は、また、少なくともいくつかのステージで支援され得る。所与のステージで実行される処理が非冪等である場合、クライアントは依然として、いくつかの実施形態で、ワーカノードが定期的に、いくつかの永続性のある外部位置に操作の出力をフラッシュするように構成し、レコード検索シーケンスに関してフラッシュ操作がいつ実行されたか記録し、及び後に交換されたワーカノードが回復中にフラッシュ操作を再操作するよう構成することで、回復に関連した冪等の利益を取得することが可能である。少なくともいくつかの実施形態においては、並行してストリームデータ上で操作しているいくつかの異なる状態、及びその他のステージに入力ストリームとして使用されるいくつかのステージの結果を備える、クライアントは有向非巡回グラフ(DAG)またはその他の処理ステージのグラフを構成することが可能であり得る。いくつかの実施形態では、永続性ストリームよりもむしろ、1つ以上の一過性は、異なるステージ間で作成され得る。例えば、1つのステージからのデータレコード出力は、異なるステージに入力として入れられる前に、必ずしも永続性記憶装置に格納されない。
例えば、チェックポイントベースの回復ポリシまたはベストエフォート回復ポリシを含む、いくつかの実施形態では、いくつかの異なる回復ポリシのいずれかは、SPSステージに実装され得る。一実施形態では、クライアントは異なるSPSステージに対する回復ポリシを選択するために、プログラムによるインタフェースを使用し得る。チェックポイントベースの回復が使用されるステージでは、ワーカノードは、プログレスレコードまたは間隔毎のチェックポイントを格納するよう構成され、ストリームパーティション内でワーカノードがどのくらいまで達したのか示し得る(例えば、一番最近処理されたレコードのシーケンス番号がプログレスのインジケータとして格納され得る)。図19を参照して以下に記載されたように、プログレスレコードは、破損後の復旧操作の間、後に使用され得る。ベストエフォートリカバリポリシにおいては、プログレスレコードは格納される必要がなく、破損に対応して構成される交換されたワーカノードは、受信されるときに新しいデータレコードを単に処理し得る。所与のSPSステージグラフまたはワークフローの中では、いくつかの実施形態において異なる回復ポリシが異なるステージに適用され得る。
SPS制御サーバは、例えば、要素1801において示されたプログラムによるインタフェースの1つを介して、パーティションポリシPPol1による、ストリームS1の特定のステージPS1で実行される冪等操作Op1の表示を受信してよく、処理の結果が出力分散ディスクリプタDDesc1に従って分散される(要素1804)。状態PS1のために構成されるワーカノードの数及び、ノードに必要な仮想リソースまたは物理リソースは、例えば、Ppol1冪等操作Op1の複雑性及びワーカノードに使用されるリソースの遂行能力(要素1807)のような様々な要因に基づいて、決定され得る。
ワーカノードは、次にインスタンス化され、例えば、選択された仮想または物理マシンリソースで、プロセスまたはスレッドとして構成され得る(要素1810)。単純な一実装においては、例えば、1つのワーカノードは、S1の各パーティションに最初に割り当てられ得る。所与のワーカノードは、(a)S1の検索ノードの適切なサブセットからデータレコードを受信し、(b)受信されたデータレコード上でOp1を実行し、(c)所望により、例えば、PS1のために回復ポリシに基づいて、パーティションレコードのセットが処理されたことを示すプログレスレコード/チェックポイントを格納し、及び(d)DDesc1(例えば、中間永続性ストリームまたは一過性ストリームへの入力、またはその他の処理ステージまたは記憶システムへの直接入力)によって示された宛先に出力を伝送するよう構成され得る。少なくともいくつかの実施形態においては、SPS処理は、継続的にどこかに伝送される必要がある任意の出力を必ずしも生成しなくてよいことに注意する。例えば、いくつかのSPSアプリケーションは、単にデータレコードの一時的なリポジトリとして機能し、及び/またはユーザがデータレコードを見ることを可能にするクエリのインタフェースを実装し得る。このようなアプリケーションは、出力を管理し得る。例えば、出力は受信されたクエリに対応して生成され得るが、分散されたディスクリプタにより生成されない。ロギングに関連したSPSアプリケーションは、大規模な分散システムから収集された最終日のログレコードを保持し、例えば、クライアントがデバッグまたは分析の目的でロギングデータを見ることを可能にする。したがって、いくつかの実施形態では、出力分散ディスクリプタは、SPSの少なくともいくつかのステージ、少なくともいくつかのストリーム、または少なくともいくつかのパーティションのために特定される必要はない。ワーカノードは、次に、それぞれの構成の設定(要素1813)通りに、検索を開始し、データレコードを処理し始め得る。少なくともいくつかの実施形態においては、SPS制御ノードは、ワーカノード(要素1816)に使用されるリソースにおけるリソース利用レベルのような、様々なその他のメトリクスと同様に、(例えば、ハートビートプロトコルのように応答性チェックを使用して)ワーカノードのヘルスステータスを監視し得る。ワーカノードから収集される情報は、下記に記載するように、例えば、ワーカノードは置換えられ、回復ポリシが実装されるべき場合にフェイルオーバが必要か否かを決定するために使用され得る。
いくつかの実施形態では、実装可能なSPSクライアントのライブラリは、クライアントが所有する構内でSPSワーカノードを、及び/またはクライアントが選択するプロバイダネットワークのリソースを実装することを希望するクライアントに提供され得る。クライアントのライブラリはまた、SPSクライアントが、ヘルス監視機能、自動ワークロード監視及び分散、セキュリティ管理、動的再分割等のような、SPS管理サービスの様々な制御プレーン特徴の使用を希望する程度を選択するのを可能にし得る。図18bは、少なくともいくつかの実施形態による、ストリーム処理ワーカノードの構成のための、クライアントのライブラリコンポーネントの起動に対応して実行され得る操作の態様を示すフローチャートである。要素1851に示されるように、SPSクライアントのライブラリは、(例えば、図18aに図示したように、操作の種類を実行するよう構成されるマルチテナントのSPS管理サービスのウェブサイトからダウンロードを介して)提供され得る。ライブラリは、いくつかの実行可能なコンポーネント及び/またはクライアントのアプリケーションにリンク可能なコンポーネントを含み得る。いくつかのライブラリのコンポーネントは、クライアントが、選択、SPS管理サービスを登録、または1つ以上のSPSステージのストリーム処理操作が実行される、様々なワーカノードの所望の特性を明示することを可能にし得る。例えば、あるクライアントは、ワーカノードのためのプロバイダネットワークの仮想計算サービスで実装されるコンピュートインスタンスのセットを使用することを希望してよい。一方、別のクライアントは、ストリームレコードを処理するために、(プロバイダネットワークによって支援されない専用装置のような)クライアント自身のデータセンタに配置された計算装置を使用することを希望してよい。クライアントはワーカノードをクライアントの構内において必要に応じて、または所望により、仮想計算サービスのコンピュートインスタンスを使用してオンラインにし得る。このようなオンデマンドでのワーカノードのインスタンス化に加え、またはその代わりに、いくつかの実施形態では、クライアントは、必要な時に配置され得る、潜在的に再利用可能なワーカノードのプールを事前に構成し得る。いくつかの実装においては、ライブラリコンポーネントは、クライアントが、指定されるステージのワーカノードのようなクライアントによってインスタンス化される、SPS管理サービス、特定のプロセスまたはスレッドでの登録を可能にするよう実行または起動されてよく、後の制御プレーン操作がSPS管理サービスによって処理され得る。一実施形態では、クライアントは、またワーカノードのためにSPS管理サービスによって処理される異なるレベルの制御プレーンの役割から選択することも可能であり得る。例えば、あるクライアントは、ワーカノードのヘルス状態を監視するためにクライアント自身のカスタムモジュールを使用することを希望し、一方、別のクライアントはワーカノードのヘルス状態を監視し、破損が検出された場合には適切な行動を取るためのSPS管理サービスを利用することを希望し得る。
SPS管理サービスは、特定のクライアントは、特定のSPSステージPS1(要素1854)のワーカノード及び/または制御プレーン操作を構成するクライアントのライブラリを使用することを希望するという表示を受信し得る。(PS1自体は、ライブラリに含まれるプログラムによるインタフェースまたはSPS管理サービスによって露出されるプログラムによるインタフェースを使用して設計されてよく、これは図4に示されたウェブベースのインタフェースに類似している)クライアントはまた、データがPS1による入力として使用するために検索されるストリームを示し得る。所望により、少なくともいくつかの実施形態においては、クライアントは、例えばクライアントがノードのために、サービスのヘルス状態の監視能力を使用することを希望するか、または独自のヘルス状態を監視するツール(要素1857)を使用することを希望するかに対するPS1に制御プレーンを設定を示し得る。クライアントによって示された基本設定に応じて、クライアントの使用するために構成されるSMS及び/またはSPSの1つ以上のノードは、決定され得る(要素1860)。ネットワークの接続性は、SMS及び/またはSPSのノードへのクライアントのワーカノード、並びに/またはその他の構成操作は、データレコードが流れ、かつ所望の結果を処理することを可能にするために実行され得る。データレコードは、検索要求を受信するとSP1ワーカノードに提供され、所望の制御プレーン操作(クライアントによってそれが要求された場合)は必要に応じて実行され得る。少なくともいくつかの実施形態においては、クライアントが、SMS管理サービスの様々なサブシステムの制御プレーンの機能性を使用することを希望する範囲の制御を可能にする類似の手法も、あるいはその代わりに実装され得ることに注意する。
図19は、少なくともいくつかの実施形態による、ストリーム処理のために1つ以上のリカバリポリシを実装するために実行され得る、操作の態様を示すフローチャートである。要素1901に示されているように、SPS制御ノードは、特定のワーカノードを置き換えるためのトリガ基準が合致したと決定し得る。例えば、ワーカノードは応答しなくなるか、ヘルス状態でなくなり、現在のノードのワークロードレベルは、フェイルオーバのため閾値に達し、ワーカノードで検出された、いくつかのエラーは、閾値を超え、またはワーカノードの何か別の予期しない状態が識別され得る。置換えられたワーカノードは識別されるかインスタンス化され得る(要素1904)。いくつかの実施形態では、入手可能なワーカスレッドのプールが設定され、置き換えとして選択されてよく、例えば、新しいスレッドまたはプロセスが開始され得る。
ベストエフォートリカバリポリシが、特定のワーカノードが動作しているSPSステージで(要素1907にて決定される際に)使用される場合には、置き換えられたワーカノードは、入手可能になるときに(要素1916)、追加のデータレコードを単に処理し始めてよく、例えば、置換えられたワーカノードの進捗記録は確認されない。チェックポイントベースの回復ポリシが使用される場合、置換えられたワーカノードは、置換えられたワーカノードによって格納されたプログレスレコードにアクセスし得る位置の表示(例えば、記憶装置のアドレスまたはURL)は、提供され得る(要素1910)。置換えられたワーカノードは、置換えられたノードによって格納された直近のプログレスレコードを検索し、置換えられたワーカノードが、ステージの冪等操作を実行(要素1913)すべきデータレコードのセットを決定するためにプログレスレコードを使用し得る。このようなチェックポイントベースの回復ポリシにおいては、最後のプログレスレコードと置換えられたワーカノードがインスタンス化される時間との間の持続時間に応じて、置換えられたワーカノードが、記憶されたプログレスレコード以降の、追加のレコードを処理した速度と同様に、いくつかの数のデータレコードが2回以上処理され得る。実行されるこの操作は冪等である場合には、このような反復操作は少なくともいくつかの実施形態では、良くない影響を有し得ない。置換えられたワーカノードが、以前に格納されたプログレスレコードに基づいて、反復の回復操作を実行した後、少なくともいくつかの実施形態では、置き換えのワーカスレッドは、そのプログレスレコードを格納してよく、回復が完了したことを示し、新しく受信されたデータレコード(要素1916)上の通常のワーカスレッド操作を開始してよい。
図20は、少なくともいくつかの実施形態による、データストリーム用の複数のセキュリティオプションを実装するために実行され得る、操作の態様を示すフローチャートである。要素2001に示されているように、クライアントがデータストリームの管理及び処理のために、例えば、異なる機能カテゴリ(例えば、取り込み、記憶、検索、処理または制御ノード)のノードのための配置先の種類の選択肢を含む、様々なセキュリティオプションから選択するのを可能にする、1つ以上のプログラムによるインタフェースが実装され得る。配置先の種類は、様々なセキュリティプロフィールに関連する態様において、互いに異なり得る。SMSまたはSPSノードに使用されるリソースの物理位置は、いくつかの実施形態において、宛先の種類によって異なり得る。例えば、プロバイダネットワークデータセンタに配置されるインスタンスホストのようなリソースは、ノードに使用され得る。またはクライアントが所有する設備のリソースが使用され得る。または第三者のリソースが使用され得る。ネットワーク隔離レベルまたはその他のネットワークの特徴は、少なくともいくつかの実施形態において、宛先の種類によって異なり得る。例えば、いくつかのSMSノードまたはSPSノードは、隔離された仮想ネットワーク内、または、専用の隔離された物理リンクを介してプロバイダネットワークに接続されたクライアントが所有する設備でインスタンス化されてよい。一実施形態では、特定の種類のSMSノードまたはSPSノードは、入手することも可能なマルチテナントのインスタンスホストを使用する代わりに、プロバイダネットワークのシングルテナントのインスタンスホストに確立されることをクライアントは示し得る。少なくともいくつかの実施形態においては、様々な種類の暗号化の選択肢はまた、セキュリティに関連するプログラムによるインタフェースを介して選択され得る。
クライアントのセキュリティプロフィールの選択またはストリームS1のための1つ以上の機能カテゴリのノードに関する基本設定は、セキュリティに関連するプログラムによるインタフェースを介して受信され得る。例えば、クライアントは機能カテゴリFC1(例えば、クライアントはクライアントが所有する構内でSPSワーカノードを実装したいと希望し得る)のノードに1つのセキュリティプロフィール及び異なる機能カテゴリFC2のノードに異なるセキュリティプロフィール(例えば、クライアントはプロバイダネットワークデータセンタでのSMS取り込みノードまたは記憶ノードの実装を希望し得る)(要素2004)を選択し得る。場合によっては、クライアントは類似のセキュリティプロフィールですべての異なる機能カテゴリのノードを設定すると決定し得る。SMS及び/またはSPSは、いくつかの実施形態では、様々な機能カテゴリに対し、デフォルトの配置先種類を定義し得る。例えば、クライアントが支持しない限り、すべての機能カテゴリのノードはプロバイダネットワークの隔離された仮想ネットワーク内に設定され得る。
異なる機能カテゴリのノードは、次に、セキュリティプロフィール及び/または位置に対するクライアントの基本設定に基づいて(またはクライアントが基本設定を提供しない機能カテゴリのデフォルトの設定に基づいて)(要素2007)構成され得る。構成は、例えば、適切な物理ホストまたは物理マシンを選択すること、適切なコンピュートインスタンス、仮想マシン、異なる機能カテゴリのノードのプロセス及び/またはスレッドをインスタンス化すること、ノード間の適切なネットワーク接続を確立すること、を含み得る。いくつかの実施形態では、異なるストリーム管理及び処理機能に対する実行可能なライブラリのコンポーネントは、構成の一部としてプロバイダネットワークの外部ホストにインストールするために提供され得る。
少なくともいくつかの実施形態による、暗号化モジュールは、例えば、クライアントによって示された暗号の基本設定によって、またはデフォルトの暗号化設定(要素2010)に基づいてノードの1つ以上のカテゴリで作動され得る。様々な機能カテゴリのノードは、次に、クライアントの希望で(要素2013)、ストリームデータが取り込まれ、格納され、検索され及び/または処理されるように作動されてよい。
図21は、少なくともいくつかの実施形態による、データストリームのためのポリシを動的再分割を実装するために実行され得る、操作の態様を示すフローチャートである。要素2101にて示すように、パーティションポリシは、データストリームのために決定され得る。ポリシは、例えば、データストリームを再分割するための1つ以上のトリガ基準と同様に、データ生成部によって供給されるキーに基づいて、または送信されるデータレコードの様々な属性に基づいて、パーティションにデータレコードを初期にマッピングすることを含み得る。例えば、いくつかの実施形態では、ハッシュ関数がパーティションキーまたはキーに適用されてよく、128ビット整数のハッシュ値を生成する。可能な128ビット整数の範囲は、N連続副範囲に分かれてよく、それぞれはストリームのNパーティションのひとつを表す。いくつかの実施形態では、パーティションの数及び/または副範囲の関連するサイズは、ストリームによって異なってよい。少なくともいくつかの実施形態においては、代理してストリームが構成されるクライアントは、パーティションスキームの使用、例えば、使用される所望のパーティションの数、所望のパーティション機能の特徴に関する、入力を提供し得る。少なくとも1つの実施形態においては、クライアントはパーティションの識別子または送信されるデータレコードのいくつか、またはすべての名前を提供し得る。
ストリームのデータレコードが受信されると、それぞれのパーティションは供給されたキー及び/またはその他の属性に基づいて決定され得る。また、取り込み、記憶及び検索ノードの適切なセットは、識別されるパーティション(要素2104)のために選択され得る。少なくともいくつかの実施形態においては、それぞれのシーケンス番号(要素2107)は、例えば、所与のパーティションのレコードが受信された順を示すデータレコードのために生成され得る。シーケンス番号は、タイムスタンプ値(例えば、よく知られた1970年1月1日の協定世界時00:00:00などからの経過秒数)、記憶サブシステム、SMSソフトウェアのバージョン番号及び/またはパーティション識別子から取得されるサブシーケンス値のようないくつかの実装においていくつかの要素を構成し得る。シーケンス番号はいくつかの実施形態では、データ生成部に、例えば、送信されたデータレコードの正常な取り込みへの応答に、提供され得る。いくつかの実施形態では、シーケンス番号はデータコンシューマによって、ストリームのデータレコードまたはパーティションを取り込み順に検索し、使用され得る。
データレコードは、パーティションポリシ(要素2110)に基づいて向けられた、ストレージノードで、少なくともいくつかの実施形態では、シーケンス番号順に格納され得る。回転磁気ディスクの記憶装置が使用される実施形態では、シーケンシャルライトが典型的には、受信されたデータレコードをディスクに保存するために使用され得る。それによってディスクシークレイテンシを避ける。少なくともいくつかの実装においては、不揮発性のバッファは、例えば、ディスクシークの確立をさらに減少させるために、レコードをディスクに記憶する前にライトキャッシュとして使用され得る。シーケンス番号によって並べられた多数のデータレコードの読み込みに対する要求(例えば、getNextRecordまたは類似のインタフェースの起動)に対応して、データレコードは、記憶装置(要素2113)からシーケンシャルリードを使用して後に読み込まれ得る。
図22は、少なくともいくつかの実施形態による、データストリームの動的再分割を実装するために実行され得る、操作の態様を示すフローチャートである。要素2201に示されるように、ストリームが、(例えば、SMSまたはSPSの制御コンポーネントで)動的に再分割されるべきであると決定され得る。いくつかの異なるトリガ条件が、取り込み、記憶、検索、処理または制御ノードのうち1つ以上で、過負荷の検出のようなストリームを再分割する決定、または異なるノードのワークロードレベルにおける不均衡の検出、またはクライアント(例えば、データ生成部またはデータコンシューマ)から受信され得る再分割要求に誘導し得る。いくつかの実装において、クライアントの再分割要求は、生成される修正されたマッピングの様々なパラメータのような、要求された再分割の特定の詳細を含み得る(例えば、特定のパーティションが組み合わされ、または分割などされるべき、追加または削除された、パーティションの数)。一実装においては、クライアントによる再分割の要求は、クライアントが解決を希望する(負荷の不均衡のような)問題のある状態を示し得る。また、SMSまたはSPSは、問題のある状態の記載を適切な再分割の操作に変換する役割があってよい。場合によっては、問題のある状態を再分割または記載することを要求する代わりに、クライアントは再分割に使用するためにトリガ基準を特定し得る。データストリームにおけるデータの耐久性要件の変更を決定するのは、再分割をトリガし得る。いくつかの実施形態では、例えば、ストリームレコードのために、異なるセットの記憶装置または異なる記憶技術を選択する結果になり得る。データストリームの使用状況の変化(例えば、データレコードが生成または消費される速度)の検出は、また、場合によっては、再分割をもたらし、また、変更された使用状況により適切な、異なる記憶技術または異なる記憶装置のセットを使用することになり得る。例えば、再分割の決定は、所与のパーティションまたはストリーム全体に予想される読み出し及び書き込みの速度には、SSDは回転磁気ディスクよりも、より適切な記憶技術であり得るという判断をもとになされ得る。予定された、または間近に迫ったソフトウェア及び/またはハードウェアのバージョン改訂は、一実施形態では、再分割をトリガし得る。場合によっては、課金または請求についての懸念は、再分割をトリガし得る。クライアントが予算の制約があることを示す場合には、異なるパーティション手法または異なる格納手段を使用してより効率的になり得る。変更された性能目標は、また少なくともいくつかの実施形態では、再分割をトリガし得る。図22に示された実施形態においては、再分割後に割り当てられるシーケンス番号に使用される、初期のタイムスタンプ値は、(1970年1月1日の協定世界時00:00:00秒からのオフセットのように、エポック値は、典型的には、いくつかのオペレーティングシステムにおけるシステムコールを介して入手可能である)選択され得る(要素2204)。いくつかの実装においては、プロバイダネットワークで実装されるグローバル状態管理部は、getEpochValue APIを支援してよく、例えば、均一なタイムスタンプ値を取得するためにSMS及び/またはSPSの様々なコンポーネントがシーケンス番号の生成のために使用されることを可能にする。その他の実装においては、その他の時間源が使用され得る。例えば、SMSまたはSPS制御ノードは、その他のコンポーネントに均一に並べられたタイムスタンプ値を提供するよう指定され得るか、またはローカルシステムコールの起動が使用され得る。いくつかの実施形態では、タイムスタンプ値は、任意の特定のホストで、必ずしも壁時計時刻に対応する必要がない。例えば、単調増加整数カウンタ値が単に使用され得る。
修正されたパーティションマッピングは、再分割の決定時に使用されるマッピングとは異なり、ストリームのために生成され得る(要素2207)少なくともいくつかの実施形態においては、変更されたマッピングは、特定のパーティションキーを有するデータレコードを、再分割前にマップされた同一のキーを有するデータレコードと異なるパーティションにマップし得る。いくつかのパーティション(典型的には、使用頻度が高いパーティション)が分割され得る。一方、その他の(典型的には、使用頻度が低い)パーティションが、再分割及び/または観察されたワークロードメトリクスのためのトリガ条件に応じて、組み合わされ得る。いくつかの実施形態では、異なるパーティション機能が、再分割の前よりも再分割後に使用され得る。例えば、異なるハッシュ関数、またはハッシュ関数による結果をパーティションに細分化するための異なる手法が使用され得る。いくつかの実装においては、例えば、128ビット整数、128ビット整数空間の連続的な範囲に対応するパーティションは、再分割後に副範囲の異なるセットに分けられ得る。少なくともいくつかの実施形態においては、取り込み、記憶、検索、処理または制御ノードの新しいセットは、新しく作成されたパーティションに割り当てられ得る。いくつかの実装においては、空間効率のよい組み合わされたデータ構造は、初期のマッピング及び修正されたマッピング(要素2208)の両方を表すために使用され得る。例えば、有向非巡回グラフまたはツリー構造は格納されてよく、各入力は、修正されたパーティションに対応するレコードのみが再分割の結果として変更が必要であるように、パーティション機能出力範囲(例えば、所与のパーティションに対応するパーティションのハッシュ関数の結果の範囲)の表示及び有効な時間範囲を含み得る。再分割の間に変更されないパーティションの入力は、データ構造中で修正される必要がない可能性がある。新しいノードは、修正されたパーティションマッピング(要素2210)を実装するよう構成され得る。少なくともいくつかの実施形態においては、以前のマッピングを基準にして格納されたデータレコードに対する検索要求が少なくともある時に継続して受信され得るため、従来のノード及び従来のマッピングは、ある時に保持され得る。特定のシーケンス番号またはタイムスタンプを明示する読み出し要求が受信されると(要素2213)、新しいパーティションマッピングか、または従来のパーティションマッピングを使用して読み出し要求を満たすかについての決定が(例えば、制御ノードまたは検索ノードで)され得る。選択されたマッピングは、次に、要求されたデータが取得される、適切な記憶ノードを識別するために使用され得る。
図23は、少なくともいくつかの実施形態による、データストリームレコード用の少なくとも1回のレコードの取り込みポリシを実装するために実行され得る、操作の態様を示すフローチャートである。要素2301に示されるように、1つ以上のプログラムによるインタフェースは、クライアントが、データストリームのために、例えば、(a)肯定応答が受信されるまで、どちらのレコード送信者がレコードを1回以上送信したかによる、少なくとも1回のポリシまたは(b)どちらの応答が少なくともいくつかのレコード送信に提供されないかによる、ベストエフォート取り込みポリシを含む、いくつかの取り込みポリシの選択肢から、レコード取り込みポリシを選択可能なように実装され得る。いくつかのデータを生成するクライアントは、その他の人と同じようには、レコードのほんの一部分の潜在的な損失については心配しない可能性がある。そのためベストエフォートの取り込み手法を選択し得る。いくつかの実装においては、ベストエフォートの取り込みのために構成されたストリームに対しても、SMSは、データレコードのいくつかのサブセットに対して応答を依然として提供し得る。または、ベストエフォートポリシはデータレコード毎に応答を必要とはしないものの、すべてのデータレコードに対する応答の提供を試みようとさえし得る。
要求は、特定のストリーム(要素2304)のために使用される特定の取り込みポリシを示す、プログラムによるインタフェースの1つを介して受信され得る。取り込みノードは、ストリームに影響するパーティションポリシによって、インスタンス化され得る(要素2307)。同一データレコードの1つ以上の送信が取り込みノードで受信されると(要素2310)、異なる動作が、有効な取り込みポリシに依存して行われ得る。少なくとも1回取り込みポリシが使用されると(要素2313において決定されるように)、応答は、1つ以上の送信のそれぞれのために、データ生成部に送信され得る。しかしながら、データレコードは記憶サブシステム(2316)にて1度のみ保存され得る。(ストリームのために有効な永続性ポリシによる、所与のレコードのN複製が場合によっては、格納され得る。しかしながら、所与のデータレコードがM回数送信されると、複製は送信のうち1つのみに対して生成され得る。すなわち、格納されたレコードの複製の全体数は、依然としてNであり、NxMではないことに注意する)。ベストエフォート取り込みポリシが有効であった場合には、(要素2313においても検出されるように)データレコードは記憶装置にて依然として1度のみ保存され得る。しかしながら、応答はデータ生成部(要素2319)に送信される必要はない。少なくともいくつかの実施形態においては、クライアントの請求額は、所望により、少なくとも部分的に選択された取り込みポリシ(要素2322)に基づいて、決定され得る。前述したように、いくつかの実施形態では、少なくとも1回の取り込みポリシの2つのバージョンは、支援され得る。図23に示されたものと同様に、1つのバージョンにおいて、SMSは、データレコードを複製を排除する機能があり得る(すなわち、2つまたはそれ以上の送信のセットの1つのみに対応して、データがSMS記憶サブシステムに格納されることを確実にする)。少なくとも1回の取り込みの異なるバージョンにおいては、SMSによるデータレコードの複製が許可され得る。後者の手法は、ストリームアプリケーションには有用であり得、データレコードの複製の否定的な結果が少数であるか、全く無い。及び/またはそれぞれの複製を排除を実行するストリームアプリケーションであり得る。
図24は、少なくともいくつかの実施形態による、データストリーム用の複数の永続性ポリシを実装するために実行され得る、操作の態様を示すフローチャートである。要素2401に示されるように、クライアントが複数の永続性ポリシからストリームデータレコードのために永続性ポリシを選択可能にする、1つ以上のプログラムによるインタフェースが実装され得る。永続性ポリシは様々な面のいずれかにおいて、互いに異なり得る。例えば、(a)保存すべきいくつかの複製の数が異なり得る(例えば、N個の複製対2つの複製対単一の複製ポリシが支援され得る)(b)使用されるストレージの位置/装置の種類が異なり得る(例えば、回転磁気ディスク対SSD対RAM対データベースサービスまたはマルチテナントストレージサービス)及び/または(c)ポリシが大規模な破損に対する回復力の予想される範囲が異なり得る(例えば、マルチデータセンタ対シングルデータセンタポリシが支援され得る)。要求が、特定のストリーム(要素2404)のため、特定の永続性ポリシのクライアントの選択を示す受信され得る。いくつかの実施形態では、クライアントに選択された永続性ポリシは、所与のストリームのそれぞれのパーティションのための異なる記憶位置の種類または装置の種類の使用をする結果となり得る。一実施形態では、ストリームレベルまたはパーティションレベルの何れかで、クライアントよりもむしろSMSが記憶位置の種類または装置の種類を選択し得る。いくつかの実施形態では、クライアントは、(所望の読み出し及び書き込みスループットまたは待ち時間のような)データの耐久性及び/または性能の目標を示し得る。いくつかの実施形態では、永続性ポリシを選択する際に、これらの目標は、適切な記憶装置の種類または位置を選択するために、SMSによって使用され得る。例えば、短待ち時間が所望される場合には、SSDは、1つ以上のパーティションまたはストリームのデータレコードを格納するために、回転磁気ディスクの代わりに、使用され得る。
1セットの取り込みノードは、データ生成部からの選択されたストリームのデータレコードを受信するよう決定または構成され得る。また、ストレージノードセットは、選択された永続性ポリシを実装するように構成され得る(要素2407)。データレコードが取り込みノードにおいて受信されるとき(要素2410)、1つ以上のデータレコードのコピーが、データレコードが属するパーティションの役割をするストレージノードによって選択された記憶装置で、選択された永続性ポリシに基づいて格納され得る(要素2413)。少なくともいくつかの実装においては、請求額は所望により(及び/または非同期的に)、クライアントによって選択された特定の永続性ポリシに基づいて、決定され得る(要素2416)。
ストリーム処理のための分散化したワークロード管理
いくつかの実施形態では、SPSの実質的な部分または制御プレーンの機能性のすべては、例えば、(ワーカノードへのパーティションの割り当て、動的パーティションへの応答、ヘルス監視及び/または負荷分散のような)様々な制御操作を調整する所与のSPSステージ内のワーカノードによって、データベーステーブルのような、共有されたデータ構造を介して、分散化された方法で実装され得る。所与のワーカノードW1は、例えば、どのステージの入力ストリームのパーティションが(もしあれば)、現時点では処理されていない共有されたデータ構造内の入力であるか決定するために調べ得る。このようなパーティションP1が発見されるときには、W1は、W1がP1のレコード上でステージの処理操作を実行することを示すために、共有されたデータ構造中の入力をアップデートし得る。その他のワーカノードは、W1はP1レコードを処理するために割り当てられ、また、したがって、異なるパーティションをP1レコードに割り当て得ることを学習し得る。ワーカノードは定期的に、または場合により、SMS制御プレーンにクエリを送信して、入力ストリームに有効な現在のパーティションマップを決定し、また、必要であれば(例えば、再分割の結果として)マップの変更を示す共有されたデータ構造をアップデートし得る。負荷分散及びその他の操作は、また、様々な実施形態において下記に記載されるように、共有されたデータ構造を介して調整され得る。いくつかのこのような分散化された実装においては、専用の制御ノードは、SPSに必要とされず、そのためSPSワークフローを実装するのに必要なオーバーヘッドを低減する。このような分散化されたSPS制御プレーンの実装は、例えば、顧客またはプロバイダネットワーク外の位置に割り当てられるプロバイダネットワーク内のコンピュートインスタンスのような、SPSクライアントライブラリを利用してストリーム処理の様々な態様を実装する、特に予算に敏感な顧客には人気があり得る。分散されたSPS制御プレーン技術は、また、クライアントライブラリが使用されていない実施形態において使用され得る。例えば、SMS及びSPSに使用されるすべてのリソースがプロバイダネットワーク内に構成されている場合である。ワーカノードが、少なくともいくつかの処理ステージのための、いくつかのまたはすべてのSPS制御プレーン機能を実装するSPSは、本明細書においては、「分散された制御SPS」と称する。
図25は、少なくともいくつかの実施形態による、処理ステージのワーカノードがデータベーステーブルを使用してワークロードを調節するストリーム処理システムの例を示す。分散された制御SPS2590内では、2つのステージ215A及びステージ215Bは、ワーカノードのそれぞれのセットで定義される。ステージ215Aは、ワーカノード2540A及びワーカノード2540Bを備え、一方、ステージ415Bは、ワーカノード2540K及びワーカノード2540Lを備える。ステージ215A及びステージ215Bのそれぞれには、対応するパーティションの割り当て(PA)テーブル2550は、ステージ215AにはPAテーブル2550A及びステージ215NにはPAテーブル2550Bのような、データベースサービス2520で作成される。いくつかの実施形態では、所与のステージに対するPAテーブル2550は、例えば、クライアントライブラリコンポーネントまたは機能の起動に対応して、ステージの初期化中に作成され得る。各PAテーブル2550は、入力の初期セットで、またはステージの入力ストリームの未割り当てのパーティションを表す行が備えられ得る(すなわち、ワーカノードが現時点で割り当てられていないパーティション)。例示的なカラムまたはPAテーブル入力の属性は、図26に示され、以下に記載されている。ステージのために開始されるワーカノード2540(例えば、コンピュートインスタンスまたはその他のサーバで開始されるプロセスまたはスレッド)は、ステージのPAテーブルに読み出し/書き込みアクセスを許可され得る。ワーカノードからPAテーブルに向けられる読み出し及び書き込みは、ワーカノード2540A、2540B、2540K及び2540Lに対し、それぞれ2564A、2564B、2564K及び2564Lの矢印で図25において示されている。
所与のワーカノード2540は、PAテーブル中の入力を調べることによって、ステージの処理操作を実行する特定のパーティションを選択するよう構成され得る。一実装においては、ワーカノード2540Aは、未割り当てのパーティションPkの入力を見つけられるまでPAテーブル2550Aにおける入力をスキャンし、入力をアップデートすることによって、例えば、ワーカノードの識別子を入力のカラムのうちの1つに挿入することによって、パーティションPkの割り当てを試み得る。このような挿入は、ワーカノードによってパーティションをロックすることに類似していると考えられ得る。使用されるデータベースのサービスの種類によって、同時にPAテーブルの入力への書き込みを潜在的に管理するための異なる手法(例えば、ほぼ同時に未割り当てのパーティションを期せずして識別する、2つまたはそれ以上のワーカノードによって)が、使用され得る。
一実施形態では、プロバイダネットワークの非リレーショナルマルチテナントデータベースサービスが使用されてよく、強い整合性及び条件付き書き込み操作を支援するリレーショナルデータベースのトランザクションセマンティクスを必ずしも支援せずに、条件付きの書き込み操作は、ワーカノードによるアップデートのような場合で使用され得る。PAテーブル中のパーティションに割り当てられた特定のワーカノードの識別子を示すために、カラム「ワーカノードID」が使用される例、及びワーカノードがパーティションに割り当てられないカラムの値が「null」に設定されるを考える。このような場合においては、識別子WID1を備えるワーカノードは、以下の論理的等価を要求し得る。「パーティションPkに対する入力においては、ワーカノードIDはnullであり、次に、その入力に対するワーカノードIDをWID1に設定する」。このような条件付きの書き込み要求が成功する場合には、識別子WID1を有するワーカノードは、パーティションPkが割り当てられると仮定され得る。ワーカノードは次に、パーティションPkのデータレコードを検索し、例えば、矢印2554(例えば、ワーカノード2540A、2540B、2540K及び2540Lに対し、それぞれ2554A、2554B、2554K及び2554Lの矢印)で示されるように、SMS検索サブシステム206のレコード検索インタフェースを使用して、及び検索レコード上の処理操作を実行し始め得る。条件付きの書き込みが失敗すると、ワーカノードは異なる未割り当てパーティションに対して検索を開始し得る。その他の実施形態では、トランザクションを支援する(リレーショナルデータベースのような)データベースサービスが使用されてよく、トランザクションの機能性は条件付きの書き込み操作の等価を実装するために使用され得る。例えば、ワーカノードの成功にパーティションを割り当てる、複数の同時(またはほぼ同時)の試みのうち1つのみを確保するために、このような同時の試みに含まれるワーカノードは確実に成功または失敗を通知される条件付きの書き込みまたはトランザクションの支援のどちらにも依存しない同期技術は、いくつかの実施形態で使用され得る。データベースサービスが使用されなくてよい、いくつかの実装においては、その代わりに、ロッキングサービスが、PAテーブルに類似の永続性データ構造における入力をアップデートするため、排他アクセスを取得するために、ワーカノードによって使用され得る。
その他のワーカノード2540は、PAテーブルにおける入力を調査し、どちらのパーティションが未割り当てかを決定し、それらに1つ以上のパーティションを割り当てすることに結果的に成功し得る。このように、ステージの入力ストリームのパーティションまたはストリームのためのワークロードを処理することは、結果的に、ステージのワーカノードにより、それらに分散され得る。
任意の所与のストリームの初期のパーティションマッピングは、例えば、前述した動的再分割操作の結果として、時間の経過とともに変化し得る。したがって、図25に示された実施形態に示すように、1つ以上のワーカノード2540は、場合により(または以下に記載されるようにトリガ条件に対応して)、現在のパーティションメタデータを取得するために、ステージの入力ストリーム(単数または複数)のSMS制御サブシステム210に要求を送信し得る。いくつかの実装においては、このような要求は、矢印2544A、2544B、2544K及び2544Lによって示されたgetStreamInfo APIの起動のように、SMS制御プレーンAPIの起動を含み得る。SMS制御サブシステムは、例えば、ストリームのパーティションの最新のリスト及び/またはパーティションの有効時間のようなその他の詳細で応答し得る。SMS制御サブシステム210によって提供されたパーティション情報がPAテーブル中の入力に合致しない場合には、例えば、1つ以上のパーティションに入力を挿入または削除することによって、PAテーブルはワーカノードによって修正され得る。SMS制御サブシステムへのこのような要求2554は、典型的には、少なくともいくつかの実施形態においては、矢印2554Aの「低頻度」ラベルによって示されたように、レコード検索要求2554(及び/またはデータベースの読み出しまたは書き込み操作2564)よりもかなり低頻度である。例えば、一旦、パーティションに割り当てられると、ワーカノードは、典型的には、(例えば、ストリームの所有者がストリームを閉鎖する場合、またはパーティションが動的再分割の結果閉鎖する場合には)パーティションデータが完全に消費されるまで、または(例えば、異なるワーカノードが、以下に記載されるように、負荷の不均衡を検出したため、パーティションの移動を要求する場合には)何か他の確立の低い環境に遭遇するまで、そのパーティションのデータレコードを検索し、処理し続け得る。このため、たとえ実質的な情報量が任意の所与の起動に対応して提供される場合でも、getStreamInfoまたはsimilarAPIの起動に関連したオーバーヘッドは、典型的には、様々な実施形態で非常に小さくてよい(何十万かのパーティションがステージの入力ストリームに定義される場合にはあり得る)。
したがって、分散された制御SPS環境のキーワークロード管理操作のいくつかは、図25に図示された実施形態において、以下のように要約され得る。(a)ストリーム処理ステージの第1のワーカノードによって、データベースのテーブルに少なくとも一部アクセスすることに基づいて、ステージに定義された処理操作のセットを実装する、ストリーム処理ステージの入力データストリームの特定のパーティションを選択し、(b)テーブルに格納された特定の入力に、第1のワーカノードに特定のパーティションの割り当ての表示を書き込みし、(c)第1のワーカノードによって、マルチテナントのストリーム管理サービスで実装されるプログラムによるレコード検索のインタフェースを使用して、特定のパーティションのレコードを検索し、(d)第1のワーカノードによって、特定のパーティションのレコード上の処理操作のセットを実装し、(e)第2のワーカノードによって、少なくとも部分的に特定のデータベーステーブル中の特定の入力に基づいて、第1のワーカノードが特定のパーティション上の処理操作のセットを実行するために割り当てられることを決定し、及び(f)第2のワーカノードによって、処理操作のセットを実行するための異なるパーティションを選択する。ワーカノードがこれ以上のレコードが割り当てられないパーティション内に留まることを決定する場合またはするときに、ワーカノードはSMS制御サブシステムから入力ストリーム上でメタデータを要求してよく、メタデータが不一致を示した場合にはPAテーブルをアップデートしてよい。
図26は、少なくともいくつかの実施形態による、ワークロードの調節に使用されるパーティションの割り当てテーブル2550に格納され得る入力の例を示す。ここに示すように、テーブル2550は、パーティション識別子カラム2614,割り当てられたワーカノード識別子カラム2618,ワーカノードヘルスインジケータカラム2620及びワークロードレベルインジケータカラム2622の4つのカラムを備える。その他のカラムセットがその他の実装において実装され得る。例えば、パーティション作成時間を示すカラムまたはパーティション機能出力値範囲がいくつかの実施形態で使用され得る。またはワークロードレベルインジケータカラムは使用されなくてよい。
いくつかの実施形態においては、SMS制御サブシステム(例えば、パーティション入力ツリーの一部として、前述したグラフまたはその他の組み合わされたデータ構造)によって維持されたパーティションリスト2650は、少なくともある時点において、PAテーブル2550に含まれるよりも多くのパーティションを含むことに注意する。図示された実施例において、パーティションリスト2650は、パーティションP1、P2、P3、P4及びP5を含み、パーティションP1及びP4は再分割の結果、閉じられた状態に示され、一方、パーティションP2、P3及びP5は動作中である(すなわち、データレコードが現在検索され処理されているパーティション)。PAテーブル2650は、図示された実施形態において動作中のパーティションのための入力を含み、閉じられたパーティションのための入力を含まない(例えば、再分割が行われた後、getStreamInfoの起動に対応して取得されたときに、ワーカノードによって削除された可能性がある)少なくともいくつかの実装においては、ストリームの現在開いているパーティションのすべてが、所与の時間でPAテーブルにおいてそれぞれの入力を必ずしも有しない可能性がある。その代わりに、例えば、現在割り当てられ、または処理中の、それらのパーティションのサブセットのみが示され得る。
図26に示された例示的な場合においては、パーティションP1及びP2は、識別子W7及びW3をそれぞれ有するワーカノードに割り当てられ、一方、P5は現時点では、割り当てられていない。ヘルスインジケータカラム2620は、異なる実装において、異なる種類の値を格納し得る。いくつかの実装においては、ワーカノードは定期的に(例えば、毎N秒に一度、またはヒューリスティックスのいくつかのセットに基づいたスケジュールによって)、割り当てられたパーティションのPA入力中のヘルスインジケータカラムのコンテンツをアップデートして、ワーカノードが動作中であり、検索及び処理操作を継続可能であることを示す役割をし得る。図26において、その入力のためのワーカノードがヘルスインジケータカラムをアップデートした(「最後に修正された時間」)、直近の時間の表示は、格納され得る。例えば、ワーカW7が、2013年12月1日の02:24:54及び53秒に入力を修正したと示されている。いくつかの実施形態では、その他のワーカノードは最後に修正された時刻値を使用して、割り当てられたワーカノードが健全化否かを判断する。例えば、ステージのためのフェイルオーバポリシにて定義されるようにX秒またはX分が経過した場合、割り当てられたワーカノードは健全ではないか、またはアクセス不可能であるとされ、パーティションは再割り当てされ得る。その他の実装においては、カウンタはヘルス状態のインジケータとして使用されてよく、(例えば、カウンタ値がY秒で変化しない場合には、割り当てられたワーカノードはフェイルオーバのための候補と判断され得る。または、割り当てられたワーカノードが最後に入力を読み出した時を示す「最終の読み出し時刻」値が使用され得る。
少なくともいくつかの実施形態においては、ワークロードレベルのインジケータ値2622は、例えば、いくつかの最近の時間間隔中(例えば、最後に修正された時刻の前5分間で)に処理された、いくつかのレコードのような割り当てられたワーカノード、CPU利用、メモリ利用、ストレージ利用などのような最近の性能に関連するワーカノードのメトリクスによって、入力に格納され得る。いくつかの実施形態において、このようなワークロードレベルのインジケータ値は、図29に関して下記に記載されるように、負荷の不均衡が存在するか否かを決定し、検出された不均衡に対応して行動をするために、ワーカノードによって使用され得る。例えば、ワーカノードWkは、ワークロードレベルが平均のワークロードレベルより上であることを判定し、パーティションの一つに割り当てず、または動的再分割を要求し得る。あるいは、ワーカノードWkは、ワークロードがその他のワーカノードまたはパーティションのワークロードと比較して低すぎると判定し、追加のパーティション自体に割り当て得る。したがって、図26に示されたPAテーブルのカラムを使用して、ワーカノードは、集中化制御SPSの実装における、専用のSPS制御ノードによって典型的に実行され得る、図示された実施形態における制御プレーンの機能の類似の種類のいくつかを実行し得る。
図27は、少なくともいくつかの実施形態による、処理操作を実行するパーティションを選択するために、ストリーム処理ステージのワーカノードによって実行され得る操作の態様を示す。要素2701に示されるように、PAテーブルPAT1は、分散された制御SPS処理ステージSP1のために、データベースサービスで初期化され得る。例えば、テーブルは、SPSクライアントのライブラリコンポーネントが起動されるときに、例えば、クライアントの設備のホストから、またはプロバイダネットワークのデータセンタのコンピュートインスタンスから作成され得る。クライアントのライブラリは様々な目的に使用され得る。例えば、SPSステージで実装される特定の処理操作のためのJAR(Java(登録商標)アーカイブ)ファイルのような、実行可能なコンポーネントを提供するため、ワーカノードを識別するために使用され得るラベル(プログラム名、プロセス名またはコンピュートインスタンス名)を表示するため、ステージへの入力に使用されるストリームを表示するため、ステージの出力先(もしあれば)を表示するため、等である。PAT1は、いくつかの実施形態では、ステージの入力ストリーム(単数または複数)に定義された少なくともパーティション{P1,P2,・・・}のサブセットのための入力または列に最初に格納され得る。いくつかの実装においては、テーブルは最初は空であってよく、例えば、SMS制御サブシステムからのパーティションのメタデータを取得した結果として、1つ以上のワーカノードはテーブルを割り当てていないパーティションのための列をポピュレートし得る。ワーカノード{W1,W2,・・・}の初期のセットは、例えば、プロバイダネットワーク内の様々なコンピュートインスタンスで、またはクライアントが所有する計算装置で起動され得る(要素2704)。ワーカノードは、図示された実施形態において、PAT1への読み出し及び書き込みアクセスを許可し得る。
ワーカノードがオンラインなると、それぞれが割り当てられていないパーティションを見つけるために、PAT1にアクセスし得る。例えば、ワーカノードW1は、PAT1を調べ、パーティションP1が割り当てていないことを見つける(要素2707)。W1は次にPAT1のP1の入力をアップデートする。例えば、使用されるデータベースサービスの種類に応じて、条件付き書き込み要求またはトランザクショナルアップデート要求を使用して、P1がW1に割り当てられることを示す(要素2710)。テーブルをアップデートし、W1は、SMS検索サブシステムインタフェース(要素2713)を使用して、P1のデータレコードの検索を開始し得る。また、検索されたレコード上のステージPS1の処理操作を実行し得る。
その間、ある時点で、異なるワーカノードW2が、割り当てられていないパーティションを見つめようとPAT1にアクセスし得る(要素2716)。W2は、W1の以前のアップデートに基づいて、P1がすでに割り当てられていること、しかし異なるパーティションP2が割り当てられていないことを判断し得る。いくつかの実施形態では、P2の現在の受託者ワーカノードは、W2によって健全ではないか、動作中ではないことを(P2の入力におけるヘルスインジケータカラムに基づいて)判断し、W2をP2を選択するよう導き得る。このように、少なくともいくつかの実施形態においては、割り当てられていない状態または現在のワーカノードの健全ではない状態の判断の何れかは、再割り当て(または最初の割り当て)のために所与のパーティションを選択するために使用され得る。W2は、次にPAT1をアップデートしてそれ自体をP2を割り当てるよう試み得る(要素2719)。アップデートが成功した場合には、W2はP2レコードをSMS検索インタフェース(要素2722)を使用して検索し始め、ステージのために定義された適切な処理操作を実行し始める。
前述のように、分散された制御SPSワーカノードは、典型的には低頻度で、SMSからマッピング情報を取得してよく、必要に応じてPAテーブルをアップデートするためのこのような情報を使用し得る。図28は、少なくともいくつかの実施形態による、ストリーム管理サービス制御サブシステムから取得された情報に基づいて、パーティション割り当てテーブルをアップデートするために、ストリーム処理ステージのワーカノードによって実行され得る操作の態様を示す。要素2801に示されるように、割り当てられたパーティションの1つを閉鎖するようなワーカノードの初期化中、または様々なトリガ条件に対応して、ワーカノードW1は最新の若しくは現在のパーティションリストまたは非アクティブのパーティションリストを取得するために、SMS制御サブシステムへ要求を送信し得る。いくつかの実装においては、getStreamInfoまたは類似のAPIは、この目的で起動され得る。その他のトリガ条件はいくつかの実施形態において使用され得る。例えば、ワーカノードは無作為な時間量後に新規のパーティションリストを取得するようそれぞれ構成され得る。またはワークロードレベルにおける予期しない減少若しくは増加に対応して取得するよう構成され得る。SMSによって返されたパーティションリストは、パーティションのためのPAテーブル中の入力と比較され得る(要素2807)。不一致が明らかになる場合には、(例えば、PAテーブル中に存在しない、新規に取得されたパーティションリストにいくつかのパーティションがある場合、またはSMSのリストに存在しないPAテーブル中の入力がある場合には、ワーカノードは、図示された実施形態の不一致を解決するために、PAテーブル中の入力を挿入または削除し得る(要素2810)。(いくつかの実施形態においては、現在、削除を対象とする入力は、割り当てられたワーカノードを有する場合には、追加の調整が必要となり得る。例えば、割り当てられたワーカノードは、直接またはPAテーブル自体を介して通知され得る)。
不一致が修正された後、または不一致が検出された場合には、ワーカノードW1は、ステージの処理操作を実行すべきパーティションのセットを選択し(要素2813)、したがってPAテーブルをアップデートし得る。場合によっては、検索されたパーティションリストに導くトリガ条件に応じて、W1は、すでに割り当てられた1つ以上のパーティションを有し、割り当てを変更するかPAテーブルをアップデートする必要がない。W1は次に、SMS制御サブシステムと相互作用し、PAテーブルのいくつかの入力を変更する必要なく、割り当てられたパーティションのデータレコードの検索及びレコードの処理に進み得る(要素2816)。最終的に、トリガ条件が検出されると、(例えば、「パーティションの最後に到達した」ことに相当する応答が検索要求に受信され、パーティションが閉鎖されたことを示す。W1は新しいパーティション情報のためにSMS制御サブシステムへの要求を再度、送信し、要素2801以降の操作が繰り返され得る。
図29は、少なくともいくつかの実施形態による、ストリーム処理ステージのワーカノードによって実行され得る負荷分散操作の態様を示す。要素2901に示されるように、ワーカノードW1は、負荷分散分析は、高リソース利用レベルの検出のような、様々なトリガ条件のいずれかの検出によって、または構成可能なスケジュールに基づいて、ステージ上で実行されると判断し得る。W1はステージのために様々なワークロードメトリクスを判断するためPAテーブル(要素2904)の入力を調査し得る。このようなメトリクスは、ワーカノードに割り当てられた平均の数のパーティション、(ワークロードレベルインジケータがテーブルに保存される実施形態において)ワーカノードの平均ワークロードレベルまたは異なるパーティションの平均ワークロードレベル、ワーカノードのワークロード毎の範囲または分散等を含み得る。
W1は、次にワークロードを、(例えば、W1に割り当てられたいくつかのパーティションに基づいて、及び/またはパーティション毎のワークロードレベルインジケータに基づいて)いくつかまたはすべてのメトリクスと比較する。一般的に、W1が過負荷であり、W1が負荷が少ない、またはW1のワークロードが高すぎもなく低過ぎもないという、3つの種類の結果のいずれかが描かれ得る。「高すぎる」または「低すぎる」ワークロードレベルは、いくつかの実施形態において、代表してステージが構成されるクライアントによって選択されたポリシによって、またはその他の実施形態における発見のいくつかのデフォルトのセットを使用して、定義され得る。W1がワークロードが、例えば、いくつかの最低負荷の閾値T1未満のように、低すぎると判断した場合には(要素2907)、よりビジーまたはより高負荷のワーカノードWkが識別され得る(要素2910)。W1は、次に、1つ以上のパーティションPmをWkからW1自身(要素2913)に転送するプロセスを開始し得る。例えば、PAテーブルのPm入力を修正することを試みることによって、このような(Wkのために生成された通知がもたらされ得る)修正を要求することによって、またはWkを直接要求することによって、開始し得る。
W1は、ワークロードが、例えば、最大閾値T2を超えるように、高すぎると判断した場合には(要素2916)、放棄するために(すなわち、その他のワーカノードによって割り当てをリリースするために)(要素2919)、1つ以上の割り当てられたパーティションPnを識別し得る。W1は、次に、例えば、PAテーブルのPnのための入力の受託者カラムから識別子を削除することによって、適切な入力を修正し得る(要素2922)。W1のワークロードが高すぎもなく低過ぎもない場合には、またはW1は、ワークロードを増加または減少するために、上述の動作の種類をとった後に、W1は、割り当てられるパーティションのレコードの処理を開始し得る(要素2925)。別の負荷分散の分析をトリガする条件が合致するとき、または合致する場合には、要素2901以降に対応する操作が繰り返され得る。図29に示された操作において、W1は、ワークロードに対して不均衡を検出する場合に限り、ワークロードの変化を開始として示されるであることに注意する。その他の実施形態では、W1は、W1自身よりもその他のワーカノードの間の不均衡を検出する場合、例えば、W2がW3よりも低いワークロードレベルを有すると判断した場合には、再度均衡をとる動作を開始し得る。いくつかの実装においては、W1は、ワークロードの不均衡を検出した場合、または検出するとき、(例えば、図3またはその等価に示されたような、repartitionStream SMS APIを起動することによって)動的再分割を要求または開始し得る。いくつかの実施形態では、図29に示された操作の種類は、新しく構成されたワーカノードによって実行され得る。例えば、ステージがすでにしばらくの間操作された後、新しいノードがステージに加えられるときに、新しいノードは、過負荷の現在のノードからパーティションの再割り当てを要求することによって、間接的に、現在のノードの有無を通知し得る。いくつかの実施形態では、SPSワーカノードのために、上記に類似する分散された制御技術は、1つ以上のSMSサブシステムで使用され得るまたは代わりに使用される。例えば、取り込み、記憶または検索サブシステムのノードは、PAテーブルに類似する共有されたデータ構造を使用してワークロードを調整し得る。
様々な実施形態では、図17〜図24及び図27〜図29のフローチャートに示されたもの以外の操作は、上記のストリーム管理サービス及び/またはストリーム処理機能を実装するために使用され得ることに注意する。示された操作のいくつかは、いくつかの実施形態において実装されなくてよい。または異なる順で実装されるか、または連続して実装されるよりもむしろ、並行して行われ得る。プログラムによるインタフェースが様々な実施形態において支援される、SMS及びSPSの機能のそれぞれに関して、1つ以上の技術の任意の組み合わせが、ウェブページ、ウェブサイト、ウェブサービスAPI、その他のAPI、コマンドラインツール、グラフィカルユーザインターフェース、モバイルアプリケーション(app)、タブレットアプリケーション等の使用を含む、インタフェースを実装するために使用され得ることにも注意する。
ユースケース
スケーラブルなパーティションベース、収集、検索及び段階的なストリームデータレコードの処理のため、動的に構成可能に管理されたマルチテナントサービスを確立する、上記の技術、いくつかの場合において有用であり得る。例えば、大きなプロバイダネットワークは、いくつかの異なるマルチテナントのサービスインスタンスまたは同時に何万ものクライアントに対するシングルテナントを実装する、何千ものインスタンスホストを備え得る。様々なインスタンス及びホストにインストールされた監視及び/または課金エージェントは、プロバイダネットワークのデータセンタに効果的なプロビジョニングプランを決定するため、ネットワーク攻撃等を検出するなどのために、正確な課金レコードを生成するために格納され分析される必要があり得る、何千ものメトリクスレコードを迅速に生成し得る。監視レコードは、スケーラブルな取り込み及び格納のために、SMSに入力ストリームを形成し得る。また、記載されたSPS技術は、収集されたメトリクスの分析のために実装され得る。同様に、多数のログソースから大多数のログレコードを収集し分析するアプリケーション(例えば、分散されたアプリケーションのノードからのアプリケーションログ、またはデータセンタにおけるホストまたはコンピュートインスタンスからシステムログ)は、また、SMS及びSPSの機能を利用可能であり得る。少なくともいくつかの環境においては、SPS処理操作は、リアルタイムのETL(抽出変換負荷)処理操作(すなわち、オフラインで変換する代わりに、宛先にロードするために、リアルタイムで受信されたデータレコードを変換する操作)またはデータウェアハウスに挿入するためにデータレコードの変換を備え得る。リアルタイムでデータウェアハウスにデータをロードするために、SMS及び/またはSPSの組み合わせを使用することは、データが分析のためにウェアハウスに挿入可能である前に、典型的には、1つ以上のデータソースからクリーンでキュレートなデータを必要とする遅延を回避し得る。
いくつかの異なる「ビッグデータ」のアプリケーションもまた、SMS及びSPS技術を使用して構築され得る。例えば、様々な形式のソーシャルメディアの相互作用におけるトレンド分析が、ストリームを使用して効率的に実行され得る。ユーザの位置情報のような、携帯電話またはタブレット型コンピュータから収集されたデータはストリームレコードとして管理され得る。例えば、全監視カメラから収集されたオーディオまたはビデオ情報は、スケーラブルな方法で収集され処理され、場合により様々な種類の攻撃を防ぐ助けとなり得る、ストリーミングデータセットの別のカテゴリを表し得る。例えば気象衛星、海洋ベースのセンサ、森林ベースのセンサ、天体望遠鏡から収集された、増える一方のデータセットの分析を必要とする科学研究用のアプリケーションは、また、本明細書に記載されたストリーム管理及び処理能力から利益を得られ得る。適応性のあるポリシベースの構成の選択肢及び価格設定は、異なる種類のユーザがストリーミングの機能性を特定の予算及びデータの耐久性/可用性の必要条件に適合するように、カスタマイズするのを支援し得る。
本開示の実施形態は、以下の条項を考慮して記載され得る。
1.
システムは、
1つ以上の計算装置であって、
マルチテナントストリーム管理サービスのクライアントが、特定のデータストリームに、複数のデータ取り込みポリシの中からデータ取り込みポリシを選択するのを可能にするプログラムによるインタフェースの第1のセットを実装し、複数のデータ取り込みポリシは、レコード送信者が1回以上データレコードの表示をストリーム管理サービスに肯定応答が受信されるまで伝送することによる少なくとも1回の取り込みポリシを含み、
クライアントが特定のデータストリームのために、複数のデータ永続性ポリシから、データの永続性ポリシを選択するのを可能にするプログラムによるインタフェースの第2セットを実装し、データレコードの多数の複製のどちらがストリーム管理サービスによってそれぞれの記憶位置に格納されるかにより、複数のデータ永続性ポリシは多数の複製の永続性ポリシを含み、
第1及び第2のセットのそれぞれのプログラムによるインタフェースを介してストリーム管理サービスで、クライアントが特定のデータストリームのために、少なくとも1回の取り込みポリシを選択したことの第1の表示と、クライアントが特定のデータストリームのために多数の複製永続性ポリシを選択したという第2の表示を受信し、
特定のデータレコードをストリーム管理サービスに示す複数の伝送に対応して、少なくとも1回の取り込みポリシによる複数の転送に対応する少なくとも1つの肯定応答を送信し、
複数の伝送の特定の伝送に対応して、多数の複製の永続性ポリシによる複製の記憶位置で、特定のデータレコードのコピーを格納するよう構成された計算装置を備える、システム。
2.
どちらのストリーム管理サービスが、対応する肯定応答をレコード送信者に提供せずに、少なくともいくつかの特定したストリームのデータレコードを受け入れ及び格納するべきかにより、複数のデータ取り込みポリシがベストエフォートの取り込みポリシを備える、条項1にて説明されるシステム。
3.
クライアントによって選択された多数の複製永続性ポリシが、データレコードのコピーの格納に使用される記憶位置の種類の表示を備え、記憶位置の種類は、(a)磁気ディスクベースのストレージ、(b)ソリッドステートドライブ(SSD)、(c)揮発性RAM(ランダムアクセスメモリ)、(d)不揮発性RAM、(e)データベース管理システム、または(f)プロバイダネットワークによって実装されるネットワークにアクセス可能なストレージサービスのストレージノード、のうち1つを備える、条項1にて説明されるシステム。
4.
クライアントによって選択された多数の複製永続性ポリシは、要求されたデータ耐久性レベルの表示を備え、1つ以上の計算装置がさらに、少なくとも部分的に要求されたデータの耐久性レベルに基づいて複数の記憶位置を選択するよう構成される、条項1にて説明されるシステム。
5.
1つ以上の計算装置はさらに、特定のクライアントが少なくとも部分的に、(a)特定のクライアントによって選択されたデータ取り込みポリシ、及び(b)特定のクライアントによって選択されたデータ永続性ポリシのうち、1つ以上に基づいてストリーム管理操作に請求される請求額を決定するよう構成される、条項1にて説明されるシステム。
6.
プログラムによるインタフェースのセットを実装して、ストリーム管理サービスのクライアントが、複数のデータ取り込みポリシの中から、特定のデータストリームのためにデータ取り込みポリシを選択するのを可能にし、
複数のデータ取り込みポリシは、どちらのレコード送信者が1回以上データレコードの表示を、ストリーム管理サービスに肯定応答が受信されるまで伝送するべきかによって、少なくとも1回の取り込みポリシを含み、
プログラムによるインタフェースのセットを介して要求を受信し、クライアントが少なくとも1回の取り込みポリシを特定のデータストリームのために選択したことを示し、
ストリーム管理サービスにおいて特定のデータレコードを示す複数の送信の受信に対応して、
少なくとも1回の取り込みポリシによって、複数の伝送の各伝送に対応する、それぞれの肯定応答を送信し、
複数の伝送のうち特定の伝送の受信に応答して格納し、特定のデータストリームのために選択されたデータ永続性ポリシにより、1つ以上の記憶位置での特定のデータレコードのコピーを格納することを、1つ以上の計算装置によって実行することを含む方法。
7.
どちらのストリーム管理サービスが、対応する肯定応答をレコード送信者に提供せずに、特定されたストリームの少なくともいくつかのデータレコードを受け入れ及び格納するべきかにより、複数のデータ取り込みポリシがベストエフォートの取り込みポリシを備える、条項6にて説明される方法。
8.
少なくとも1回の取り込みポリシにより、ストリーム管理サービスが複製されたデータレコードを削除するよう構成される、条項6にて説明される方法。
9.
少なくとも1回の取り込みポリシにより、ストリーム管理サービスが、複数の伝送に対応して、特定のデータレコードのうち2つ以上のコピーを格納するよう構成される、条項6にて説明される方法。
10.
クライアントが特定のデータストリームのために、複数のデータ永続性ポリシから、データの永続性ポリシを選択するのを可能にするプログラムによるインタフェースの第2セットの実装を、1つ以上の計算装置によって実行することをさらに含む、条項6にて説明される方法。
11.
複数のデータ永続性ポリシが、多数の複製永続性ポリシと、単一の複製永続性ポリシを含む、条項10にて説明される方法。
12.
データ永続性ポリシがデータレコードを格納するために使用される記憶位置の種類の表示を備え、記憶位置の種類は、(a)磁気ディスクベースのストレージ、(b)ソリッドステートドライブ(SSD)、(c)揮発性RAM(ランダムアクセスメモリ)、(d)不揮発性RAM、(e)データベース管理システム、または(f)プロバイダネットワークによって実装されるネットワークにアクセス可能なストレージサービスのストレージノードのうちの1つを備える、条項10にて説明される方法。
13.
データ永続性ポリシは特定のデータストリームの第1パーティションに使用される記憶位置の第1種類の表示と、特定のデータストリームの第2のパーティションに使用される記憶位置の異なる種類の表示と、を備える、条項10にて説明される方法。
14.
クライアントによって選択されたデータ永続性ポリシは、データレコードを格納するために使用される記憶位置の種類の表示を含まず、データレコードは、1つ以上の計算装置によって、ストリーム管理サービスの1つ以上のコンポーネントにより、データレコードを格納するために使用される記憶位置の種類の選択を実行することをさらに含む、条項10にて説明される方法。
15.
記憶位置の種類を選択することが、特定のデータストリームの第1のパーティションのための記憶位置の第1の種類を選択し、特定のデータストリームの第2のパーティションのための記憶位置の異なる種類を選択することを含む、条項14にて説明される方法。
16.
データ永続性ポリシが目標の待ち時間の表示を含み、ストリーム管理サービスの1つ以上のコンポーネントによって、データレコードを少なくとも部分的に目標の待ち時間に基づいて格納するために使用される記憶位置の種類を選択1つ以上の計算装置によって実行されることをさらに含む、条項10にて説明される方法。
17.
クライアントによって選択されたデータ永続性ポリシが、要求されたデータの耐久性レベルの表示を含み、1つ以上の計算装置によって、少なくとも部分的に要求されたデータ耐久性レベルに基づいてストリームのデータレコードが格納された複数の記憶位置の選択をさらに含む、条項10にて説明される方法。
18.
1つ以上の計算装置によって、(a)特定のクライアントによって選択されたデータ取り込みポリシ、及び(b)特定のクライアントによって選択されたデータ永続性ポリシのうち少なくとも部分的に1つ以上に基づいて、特定のクライアントがストリーム管理操作に対して請求されるべき請求額を決定することの実行をさらに含む、条項6にて説明される方法。
19.
(a)特定のデータレコードの1つ以上の属性に基づいて、特定のデータレコードが特定のパーティションのメンバとして指定され、(b)いくつかのデータ取り込みノードのうちのデータ取り込みノードが、特定のパーティションのデータレコードを取り込むために選択されることによる、少なくとも部分的にパーティションポリシに基づいて特定のデータストリームのために構成されるいくつかのデータ取り込みノードの決定を1つ以上の計算装置によって実行することをさらに含む、条項6にて説明される方法。
20.
(a)特定のデータレコードの1つ以上の属性に基づいて、特定のデータレコードが特定のパーティションのメンバとして指定され(b)いくつかのデータストレージノードのうちのデータストレージノードが、特定のパーティションのデータレコードを格納するために選択されることにより、少なくとも部分的にパーティションポリシに基づいて、いくつかのデータストレージノードが特定のデータストリームを構成するよう決定することを、1つ以上の計算装置によって、実行することをさらに含む、条項6にて説明される方法。
21.
特定のデータストリームの複数のデータレコードの各データレコードに対応して、特定のデータレコードを含む、並べられたデータレコードのセットに対する読み出し要求に応答することが不可能な、それぞれのシーケンス番号を格納し、
データストリームの異なるデータレコードの送信者から、異なるデータレコードに対応する格納される最小のシーケンス番号の表示を受信し、
異なるデータレコードに対応して、最小のシーケンス番号より大きいかまたは等しい特定のシーケンス番号を格納することを、1つ以上の計算装置によって実行することをさらに含む、条項6にて説明される方法。
22.
特定のデータストリームのために、クライアントがストリーム管理サービスを選択可能にするプログラムによるインタフェースのセットを実装し、そのデータレコードは、選択されたデータ取り込みポリシに基づいてストリームに取り込まれ、複数のデータ永続性ポリシは、(a)特定のデータストリームのデータレコードの多数のコピーによる多数の複製永続性ポリシがそれぞれの記憶位置に格納され、(b)特定のデータストリームのデータレコードの単一コピーが格納される、単一の複製永続性ポリシを含み、
プログラムによるインタフェースのセットを介して要求を受信し、クライアントが多数の複製永続性ポリシを特定のデータストリームのために選択したことを示し、
特定のデータストリームのデータレコードのために、多数の複製永続性ポリシを実装するために、複数のストレージノードを構成する、1つ以上のプロセッサ上で実行される場合に、プログラムの命令を格納する、非一時的にコンピュータにアクセス可能な記憶媒体。
23.
条項22にて説明されるように、非一時的コンピュータでアクセス可能な記憶媒体であって、複数のデータ永続性ポリシのうちの、少なくとも1つのデータ永続性ポリシがデータレコードを格納するために使用される記憶位置の種類を示すことを含み、記憶位置の種類は、(a)磁気ディスクベースのストレージ、(b)ソリッドステートドライブ(SSD)、(c)揮発性RAM(ランダムアクセスメモリ)、(d)不揮発性RAM、(e)データベース管理システム、または(f)プロバイダネットワークによって実装されるネットワークにアクセス可能なストレージサービスのストレージノードのうちの1つを備える、記憶媒体。
24.
条項22にて説明されるように、非一時的コンピュータでアクセス可能な記憶媒体であって、クライアントによって選択された多数の複製永続性ポリシが、要求されたデータの耐久性レベルの表示を含み、1つ以上のプロセッサ上で実行される命令は、少なくとも部分的に要求されたデータ耐久性レベルに基づいて、構成されるいくつかのストレージノードを決定する、記憶媒体。
25.
条項22にて説明されるように、非一時的コンピュータでアクセス可能な記憶媒体であって、1つ以上の計算装置によって、少なくとも部分的に特定のクライアントによって選択されたデータ永続性ポリシに基づいて、特定のクライアントがストリーム管理操作に対して請求される請求額の決定を実行することをさらに含む、記憶媒体。
26.
条項22にて説明されるように、非一時的コンピュータでアクセス可能な記憶媒体であって、(a)特定のデータレコードの1つ以上の属性に基づいて、特定のパーティションのメンバとして特定のデータレコードが指定され、(b)いくつかのデータストレージノードのうちのデータストレージノードが、特定のパーティションのデータレコードを格納するために選択されることにより、少なくとも部分的にパーティションポリシに基づいて、特定のデータストリームのために構成されるいくつかのデータストレージノードの決定を1つ以上の計算装置によって実行することをさらに含む、記憶媒体。
27.
マルチテナントストリーム管理サービスの複数のノードのうち、データストリームのデータレコードを分散するために適用されるパーティションポリシを決定し、パーティションポリシは、データレコードに関連する、少なくとも部分的に1つ以上の属性値に基づいて、複数のパーティションにデータレコードの初期のマッピングを含み、
初期のマッピングを使用して、少なくとも部分的に特定の属性値に基づいて、データストリームの特定のデータレコードがメンバを指定される第1のパーティションを識別し、
特定のデータレコードに対応して、ストリーム管理サービスの取り込みノードでレコード取得シーケンス内の特定のデータレコードの位置を示す、シーケンス番号を生成し、取り込みノードは少なくとも部分的に初期のマッピングに基づいて選択され、
複数のデータレコードのそれぞれのシーケンス番号に少なくとも部分的に基づいて、ストリーム管理サービスのデータ記憶位置の順で第1のパーティションの複数のデータレコードを格納し、データ記憶位置は、少なくとも部分的に初期のマッピングに基づいて選択され、
データストリームを再分割するためのトリガ条件が合致したという決定に対応して、データレコードの修正されたマッピングをパーティションに生成し、データストリームのデータレコード取得における一時停止をスケジューリングなしに修正されたマッピングの使用を開始し、特定の属性値で別のデータレコードのために選択し、その他のデータレコードは、(a)ストリーム管理サービスの異なる取り込みノードまたは(b)ストリーム管理サービスの異なるデータ格納位置のうち少なくとも1つで修正されたマッピングの使用の開始に続いて受信されるよう構成された、1つ以上の計算装置を備えるシステム。
28.
シーケンス番号は(a)特定のデータレコードの取り込みに関連するタイムスタンプ、及び(b)追加のサブシーケンス値の表示を含む、条項27にて説明されるシステム。
29.
条項28にて説明されるシステムであって、1つ以上の計算装置がさらに
修正されたマッピングを使用してマップされたデータレコードのシーケンス番号に使用される初期のタイムスタンプ値を選択し、
特定のシーケンス番号を示すデータレコードの検索要求に対応して特定のシーケンス番号によって示された特定のタイムスタンプの値が初期のタイムスタンプ値よりも低いという決定に対応して、1つ以上のデータレコードを検索するために初期のマッピングを利用し、
特定のタイムスタンプ値が初期のタイムスタンプ値よりも低くないという決定に対応して、1つ以上のデータレコードを検索するために修正されたマッピングを利用するよう構成される、システム。
30.
トリガ条件が(a)オーバーロードの状態の検出、(b)ワークロードの不均衡の検出、(c)再分割のクライアントの要求、(d)データストリームにおけるデータの耐久性要件の変更を決定、(e)ソフトウェアのバージョン変更のスケジュールの決定、(f)データストリームの使用状況の変化を検出(g)データストリームの再分割の価格の影響の決定、または(h)データストリームに関連する性能ターゲットの決定のうち、1つ以上を含む、条項27にて説明されるシステム。
31.
1つ以上の計算装置であって、データストリームに使用される1つ以上のパーティション基準を示すクライアントの要求を受信し、少なくとも部分的にクライアントの要求に基づいて、初期のマッピングを生成することをさらに含む、条項27にて説明されるシステム。
32.
データレコードの少なくとも部分的に1つ以上の属性値に基づいて複数のパーティションにデータストリームのデータレコードの初期のマッピングを決定し、
初期のマッピングを使用して、少なくとも部分的に特定の属性値に基づいて、データストリームの特定のデータレコードがメンバを指定する第1のパーティションを識別し、
初期のマッピングに少なくとも部分的に基づいて選択された記憶位置で特定のデータレコードを格納し、
トリガ条件が合致するという決定に対応して、修正されたデータレコードのマッピングをパーティションに生成し、特定の属性値で別のデータレコードのために選択し、
その他のデータレコードは、修正されたマッピング、異なる記憶位置の使用の開始に続いて受信されることを、ストリーム管理サービスの1つ以上の計算装置によって実行することを含む方法。
33.
トリガ条件が合致したという決定の前に特定のデータレコード上で、少なくとも部分的に初期のマッピングに基づいて、選択されたワーカノードで処理操作を実行し、
トリガ条件が合致したという決定の後に、特定の属性値で異なるデータレコード上で、少なくとも部分的に修正されたマッピングに基づいて選択された、異なるワーカノードで処理操作を1つ以上の計算装置によって実行することをさらに含む、条項32にて説明される方法。
34.
特定のデータレコードに対応して、ストリーム管理サービスの取り込みノードでレコード取得シーケンス内の特定のデータレコードの位置を示す、シーケンス番号を生成し、
取り込みノードは少なくとも部分的に初期のマッピングに基づいて選択され、
シーケンス番号に対応して第1のパーティションのデータレコードを順番に格納することを、1つ以上の計算装置によって実行することをさらに含む、条項32にて説明される方法。
35.
シーケンス番号は(a)特定のデータレコードの取り込みに関連するタイムスタンプ、及び(b)追加のサブシーケンス値を含む、条項34にて説明される方法。
36.
タイムスタンプが、特定のデータレコードが取り込まれた時刻を示し、1つ以上の計算装置によって、少なくとも部分的に特定のレコードの取り込む時間範囲に基づいて、1つ以上のデータレコードが検索されることを要求する検索要求に対応して、1つ以上のデータレコードを検索するために、インデックスキーとして1つ以上のデータレコードに関連するシーケンス番号の使用を実行することをさらに含む条項35にて説明される方法。
37.
修正されたマッピングを使用してマップされたデータレコードのシーケンス番号に使用される初期のタイムスタンプ値を選択し、
特定のシーケンス番号を示すデータレコードの検索要求の受信に対応して、
特定のシーケンス番号によって示された特定のタイムスタンプの値が初期のタイムスタンプ値よりも低いという決定に対応して、1つ以上のデータレコードを検索するために初期のマッピングを利用し、
特定のタイムスタンプの値が初期のタイムスタンプ値よりも低くないという決定に対応して、1つ以上のデータレコードを検索するために修正されたマッピングの使用を1つ以上の計算装置によって実行することをさらに含む、条項35にて説明される方法。
38.
修正されたマッピングは少なくとも1つの追加の属性値を使用してデータレコードのパーティションを決定する、条項32にて説明される方法。
39.
1つ以上の計算装置によって、
データストリームに使用される1つ以上のパーティション基準を示すクライアントの要求を受信し、
少なくとも部分的にクライアントの要求に基づいて、初期のマッピングの生成を実行することをさらに含む、条項32にて説明される方法。
40.
1つ以上の計算装置によって、トリガ条件を示すクライアントの要求を受信を実行することをさらに含む、条項32にて説明される方法。
41.
1つ以上の計算装置によって、データストリームを再分割するクライアントの要求を受信し、クライアントの要求は修正されたマッピングの1つ以上のパラメータを示すことを実行することをさらに含む、条項32にて説明される方法。
42.
1つ以上の計算装置によって、再分割を介して潜在的な解決のために問題状態を示すクライアントの要求の受信を実行することをさらに含む、条項32にて説明される方法。
43.
選択されたビット数を含む、バイナリ値として表されるハッシュ結果を取得するために、特定のデータレコードのコンテンツの少なくとも部分的にハッシュ関数を適用し、
選択されたビット数を使用してバイナリ値が表され得る範囲の、ハッシュ結果が属する特定の副範囲を決定し、
少なくとも部分的に副範囲に基づいて第1パーティションの識別を、1つ以上の計算装置によって、実行することをさらに含む、条項32にて説明される方法。
44.
(a)データレコードのソースによって提供されたパーティションキー、(b)データレコードのソースの識別、(c)データレコードのコンテンツの少なくとも一部、または(d)データレコードのソースのネットワークアドレスのうち、1つ以上の属性値が少なくとも1つを含む、条項32にて説明される方法。
45.
1つ以上の計算装置によって、修正されたマッピングの生成の後に、ストリーム管理システムの異なる数のノードを、(a)データレコードの取り込み、(b)データレコードの格納、または(c)修正されたマッピングの生成前に構成されたよりもデータストリームのためのデータレコードの検索のうち1つ以上実行するよう構成されることを実行することをさらに含む、条項32にて説明される方法。
46.
初期のマッピング及び修正されたマッピングを表す組み合わされたデータ構造を格納し、
組み合わされたデータ構造は、(a)初期のマッピングによる特定のデータレコードの属性がマップされる第1のパーティションを示す第1の入力、及び第1のパーティションに適用可能な初期のマッピングの時間範囲、及び(b)修正されたマッピングによる特定のデータレコードの属性がマップされる異なるパーティションを示す第2の入力、及び異なるパーティションに適用可能な修正されたマッピングの異なる時間範囲を含む、条項32にて説明される方法。
47.
組み合わされたデータ構造が(a)ツリーまたは(b)有向非巡回グラフのうち1つを備える、条項46にて説明される方法。
48.
修正されたマッピングが初期のマッピングによって示されたパーティションの対の統合を示すことを含む、条項32にて説明される方法。
49.
ストリーム管理サービスの複数のノードのうち、データストリームのデータレコードを分散するために適用されるパーティションポリシを決定し、
パーティションポリシは、データレコードに関連する、複数のパーティションにデータレコードの初期のマッピングを示すことを含み、
初期のマッピングにより、及び、初期のマッピングによるデータレコードを格納するためにストリーム管理サービスのデータ格納ノードの第1セットにより、ストリームのデータレコードを受信するためにストリーム管理サービスの取り込みノードの第1セットを構成し、
異なる複数のパーティションにデータレコードの修正されたマッピングを生成し、修正されたマッピングの生成の後に受信されたデータレコードのために、取り込みノードの異なるセット及びデータストレージノードの異なるセットを構成し、到着するデータレコードが修正されたマッピングによって格納される、少なくとも特定の時刻のために、初期のマッピングによるデータノードの第1セットに格納されたデータレコードを保持する、1つ以上のプロセッサ上で実行される場合に、プログラムの命令を格納する、非一時的にコンピュータにアクセス可能な記憶媒体。
50.
条項49にて説明されるように、非一時的コンピュータでアクセス可能な記憶媒体であって、1つ以上のプロセッサ上で実行される命令は、初期のマッピングによるデータストリームのためのデータ検索ノードの初期のセットを構成し、トリガ条件が合致したという決定に対応して、データストリームのためのデータ検索ノードの異なるセットを構成する、記憶媒体。
51.
トリガ条件が(a)オーバーロードの状態の検出、(b)ワークロードの不均衡の検出、 (c)再分割のクライアントの要求、(d)データストリームにおけるデータの耐久性要件の変更を決定、(e)ソフトウェアのバージョン変更のスケジュールの決定、(f)データストリームの使用状況の変化を検出(g)データストリームの再分割の価格の影響の決定、または(h)データストリームに関連する性能ターゲットの決定のうち、1つ以上を含む、条項49にて説明されるように、非一時的コンピュータでアクセス可能な記憶媒体。
52.
1つ以上のプロセッサ上で実行される命令は、データストリームに使用される1つ以上のパーティション基準を示すクライアントの要求を受信し、少なくとも部分的にクライアントの要求に基づいて、初期のマッピングを生成する、条項49にて説明されるように、非一時的コンピュータでアクセス可能な記憶媒体。
53.
1つ以上のプロセッサ上で実行される命令が、データストリームを再分割するためのトリガ条件を示すクライアントの要求を受信する、条項49にて説明されるように、非一時的コンピュータでアクセス可能な記憶媒体。
コンピュータシステムの例
少なくともいくつかの実施形態においては、SMSサブシステム(例えば、取り込み、格納、検索及び制御サブシステム)のコンポーネントを実装する技術を含む、本明細書に記載された、一部またはすべての1つ以上の技術を実装するサーバは、SPSワーカ及び制御ノードと同様に、1つ以上のコンピュータがアクセス可能な媒体にアクセスすることを含むか、またはアクセスするよう構成された汎用コンピュータシステムを含み得る。図30は、このような汎用計算装置9000を示す。図示した実施形態では、計算装置9000は、入力/出力(I/O)インタフェース9030を介して、システムメモリ9020に接続された1つ以上のプロセッサ9010を含む。計算装置9000は、さらに、I/Oインタフェース9030に接続されたネットワークインタフェース9040を含む。
様々な実施形態では、計算装置9000は、1つのプロセッサ9010を含む、単一プロセッサまたは、いくつかのプロセッサ9010を含む、マルチプロセッサシステムであり得る(例えば、2、4、8または別の好適な数)。プロセッサ9010は、命令を実行可能な任意の好適なプロセッサであり得る。例えば、様々な実施形態では、プロセッサ9010は、x86、PowerPC、SPARCまたはMIPS ISA、または任意のその他の好適なISAのような、任意の様々な命令セットアーキテクチャ(ISA)を実行する汎用または組込型プロセッサであり得る。いくつかの実装においては、グラフィックス処理ユニット(GPU)は、従来のプロセッサの代わりに、または追加して使用され得る。
システムメモリ9020は、プロセッサ(単数または複数)9010によってアクセス可能な命令及びデータを格納するよう構成され得る。様々な実施形態では、システムメモリ9020は、スタティックランダムアクセスメモリ(SRAM)、シンクロナスダイミックランダムアクセスメモリ(SDRAM)、不揮発性/フラッシュタイプのメモリまたは任意のその他の種類のメモリの種類を使用して実装され得る。図示した実施形態では、1つ以上の所望の機能を実装する、プログラムの命令及びデータは、これらの方法、技術及び上述のデータが示され、コード9025及びデータ9026のように、システムメモリ9020内に記憶される。
一実施形態では、I/Oインタフェース9030は、プロセッサ9010と、システムメモリ9020と、データオブジェクトパーティションの物理複製を格納するために使用される、様々な種類の永続的及び/または揮発性記憶装置のような、ネットワークインタフェース9040またはその他の周辺インタフェースを含む、装置内の任意の周辺装置との間のI/Oトラフィックを調節するよう構成され得る。いくつかの実施形態では、I/Oインタフェース9030は、1つのコンポーネント(例えば、システムメモリ9020)からデータ信号を変換するために、任意の必要なプロトコル、タイミングまたはその他のデータ変換を別のコンポーネント(例えば、プロセッサ9010)によって使用するのに適したフォーマットに実行し得る。いくつかの実施形態では、I/Oインタフェース9030は、例えば、周辺構成要素相互接続装置(PCI)バス規格の変形またはユニバーサルシリアルバス(USB)規格のような、様々な種類の周辺のバスを通して取り付けられる装置への支援を含み得る。いくつかの実施形態では、I/Oインタフェース9030の機能は、例えば、ノースブリッジ及びサウスブリッジのように、2つまたはそれ以上の分離したコンポーネントに分かれ得る。また、いくつかの実施形態では、システムメモリ9020へのインタフェースのような、いくつかの、またはすべてのI/Oインタフェース9030の機能は、プロセッサ9010に直接組み込まれ得る。
ネットワークインタフェース9040は、コンピュータシステムまたは例えば、図1から図29に図示された装置のような、ネットワークまたはネットワーク9050に取り付けられた、データが計算装置9000とその他の装置9060との間で交換できるように構成され得る。様々な実施形態では、ネットワークインタフェース9040は、例えばイーサネット(登録商標)ネットワークの種類のような、任意の好適な有線または無線の一般的なデータネットワークを介して、通信を支援し得る。さらに、ネットワークインタフェース9040は、ファイバチャネルSANのようなストレージエリアネットワークを介して、または任意のその他の好適な種類のネットワーク及び/またはプロトコルを介して、アナログ音声ネットワークまたはデジタルファイバ通信ネットワークのような、電気通信/電話網を介した通信を支援し得る。
いくつかの実施形態では、システムメモリ9020は、対応する方法及び装置の実施形態を実装するために、図1から図29のために上記に記載されたように、プログラムの命令及びデータを格納するよう構成された、コンピュータでアクセス可能な媒体の一実施形態であり得る。しかしながら、その他の実施形態では、プログラムの命令及び/またはデータが受信され、送信され、または異なる種類のコンピュータがアクセス可能な媒体に格納され得る。一般に、コンピュータがアクセス可能な媒体は、磁気または光学媒体のような、非一時的記憶媒体またはメモリ媒体を含み得る。例えば、I/Oインタフェース9030を介して計算装置9000に接続されたディスクまたはDVD/CDである。非一時的コンピュータがアクセス可能な記憶媒体は、また、いくつかの実施形態において、システムメモリ9020または別の種類のメモリのように、計算装置9000中に含まれてよい、RAM(例えば、SDRAM、DDRSDRAM、RDRAM、SRAM等)、ROM等のような、任意の揮発性または不揮発性媒体を含み得る。さらに、コンピュータがアクセス可能な媒体は、ネットワークインタフェース9040を経由して実装され得るような、ネットワーク及び/または無線接続のような、電気信号、電磁波信号またはデジタル信号のような、通信媒体を経由して伝達される伝送媒体または信号を含み得る。図30に示されたような、多数の計算装置の一部または全部は、様々な実施形態において、記載された機能を実装するために使用され得る。例えば、様々に異なる装置及びサーバで実行するソフトウェアコンポーネントは、機能性を提供するために一緒に動き得る。いくつかの実施形態では、汎用コンピュータシステムを使用して実装されることに加えて、またはその代わりに、記憶装置、ネットワーク装置または専用コンピュータシステムを使用して、記載された機能性の一部は実装され得る。「計算装置」という用語は、本発明で使用する場合、少なくともすべてのこれらの種類の装置を意味し、これらの種類の装置に限定されない。
結論
様々な実施形態は、さらに、コンピュータがアクセス可能な媒体についての前述の記載により実装される、受信し、送信し、または命令及び/またはデータを格納することを含み得る。一般に、コンピュータがアクセス可能な媒体は、磁気媒体または光媒体のような、記憶媒体またはメモリ媒体を含み得る。ネットワーク及び/または無線接続のような、通信媒体を経由して伝達される、伝送媒体または電気信号、電磁波信号またはデジタル信号のような信号と同様に、例えば、RAM(例えば、SDRAM、DDR、RDRAM、SRAM、etc.),ROM等のような、ディスクまたはDVD/CD−ROM、揮発性媒体または不揮発性媒体が含み得る。
図面に示され、本明細書で記載された、様々な方法は、例示的な方法の実施形態を表す。この方法はソフトウェア、ハードウェアまたはこれらの組み合わせにおいて実施され得る。方法の順序は変更されてよく、様々な要素が追加され、順序が変更され、組み合わされ、省略され、修正等され得る。
様々な修正及び変更が、本開示の利益を有する当業者には明白であるため、成され得る。すべてのこのような修正及び変更を受け入れることを目的としており、したがって、上記の記載は制限を意味するよりもむしろ、例証としてみなされるべきである。