17 高可用性アプリケーション
Oracle Stream Analyticsアプリケーションは常にストリーミング・データを監視するため、高可用性が不可欠です。Oracle Stream Analyticsは、アプリケーション設計パターンと高可用性アダプタによって、アプリケーションのバックアップおよびフェイルオーバー処理の能力を強化します。
この章の内容は次のとおりです。
17.1 Oracle Coherence
Oracle Stream Analyticsの高可用性オプションは、Oracle Coherenceに依存します。Oracle Coherenceを使用せずにOracle Stream Analyticsの高可用性オプションを実装することはできません。
パフォーマンスのチューニングを検討する場合、Oracle Stream Analyticsアプリケーションに加えて必ずOracle Coherenceの構成を評価します。
17.2 アーキテクチャ
Oracle Stream Analyticsは、アクティブ・アクティブ高可用性アーキテクチャをサポートします。この方法には、高パフォーマンス、簡素性、およびフェイルオーバー時間の短縮という利点があり、データやサービスの障害が発生する可能性やその影響が緩和されます。
高可用性アプリケーションは、マルチサーバー・ドメインで稼働している複数のOracle Stream Analyticsサーバーのグループにデプロイします。Oracle Stream Analyticsでは、グループ内のサーバーを1つ選択して、アクティブなプライマリ・サーバーに設定します。他のサーバーは、アクティブ・セカンダリ・サーバーとなります。
プライマリ・サーバーおよびセカンダリ・サーバーは、同一の入力イベントを受信するように構成され、それらを並列に処理しますが、プライマリ・サーバーのみがOracle Stream Analyticsアプリケーション・クライアントにイベントを出力します。選択したサービス品質に依存して、セカンダリ・サーバーはインメモリー・キューを使用してそのような出力イベントをバッファリングし、プライマリ・サーバーは、プライマリ・サーバーが出力済のイベントを使用してセカンダリ・サーバーを最新に保ちます。
図17-1に、アクティブ・サーバー1つとプライマリ・サーバー2つの一般的な構成を示します。
図17-1 Oracle Stream Analyticsの高可用性: プライマリ・サーバーおよびセカンダリ・サーバー

「図17-1 Oracle Stream Analyticsの高可用性: プライマリ・サーバーおよびセカンダリ・サーバー」の説明
17.3 ライフサイクルとフェイルオーバー
初期プライマリ・サーバーを指定することはできません。初期状態では、マルチサーバー・ドメインで起動する第1サーバーがプライマリになるため、特定の順序でサーバーを起動することによって、プライマリの選択に影響を与えることができます。稼働中の特定のサーバーを強制的にプライマリにすることはできません。プライマリが失敗するとバックアップが機能し、現在のプライマリがフェイルオーバーの起動に失敗しないかぎり、二度と自動的にプライマリになりません。
図17-2は、Oracle Stream Analytics高可用性ライフサイクルの状態図を示します。この図では、状態名(SECONDARY
、BECOMING_PRIMARY
およびPRIMARY
)はOracle Stream Analyticsの高可用性アダプタのRuntimeMBean
メソッドのgetState
の戻り値に対応します。このような状態はOracle Stream Analytics専用です。高可用性アダプタの詳細は、高可用性入力アダプタを参照してください。
17.3.1 セカンダリの障害
通常、セカンダリ・サーバーに障害が発生しても図17-3に示すようにOracle Stream Analyticsアプリケーションの動作には影響はありません。選択するサービス品質に関係なくイベントの欠落や重複は発生しません。
17.3.2 プライマリの障害およびフェイルオーバー
プライマリ・サーバーで障害が発生した場合、図17-4で示すように、選択するサービス品質に応じて、Oracle Stream Analyticsはイベントの欠落や重複を発生させる可能性があるフェイルオーバーを実行します。
フェイルオーバー中、Oracle Stream Analyticsは新しいプライマリおよびSECONDARY
状態からBECOMING_PRIMARY
状態への新しいプライマリの遷移を選択します。選択するサービス品質に依存して、新しいプライマリは構成可能な準備状況のしきい値を満たすまでPRIMARY
状態に遷移しません。詳細は、サービス品質オプションの選択にある特定のサービス品質オプションを参照してください。
17.3.3 高可用性マルチサーバー・ドメインの再結合
新しいOracle Stream AnalyticsサーバーがOracle Stream Analytics高可用性マルチサーバー・ドメインに追加されるか、または障害が発生した既存のサーバーが再起動される場合、サーバーでは、デプロイされているすべてのアプリケーションが完全に結合されるまで、Oracle Stream Analytics高可用性デプロイメントと通知グループは完全には結合されません。いつ完全に結合できるかは、アプリケーションの種類によって異なります。
アプリケーションが完全に同一の出力イベントのシーケンスを既存のセカンダリとして出力する必要がある場合(タイプ1アプリケーション)、一部の有限の期間(warm-up-window-length
の期間)の入力ストリームを処理することによって、アプリケーションはその内部状態を再構築できます。このwarm-up-window-length
の時間によって、アプリケーションが完全にOracle Stream Analytics高可用性デプロイメントと通知グループを結合するのにかかる最短時間が決定されます。
アプリケーションが完全に同一の出力イベントのシーケンスを既存のセカンダリとして出力する必要がない場合(タイプ2アプリケーション)、warm-up-window-length
の時間はかからず、アプリケーションはデプロイされたときにOracle Stream Analytics高可用性デプロイメントと通知グループを完全に結合します。
詳細は、適切なwarm-up-window-length時間の選択を参照してください。
17.4 デプロイメント・グループおよび通知グループ
マルチサーバー・ドメイン内のすべてのサーバーは、同一のデプロイメント・グループに属します。デプロイメント・グループは、アプリケーションをデプロイする対象のグループです。Oracle Stream Analyticsの高可用性のために同一のアプリケーションをグループ内のすべてのサーバーにデプロイする必要があります。
デフォルトでは、マルチサーバー・ドメイン内のすべてのサーバーも同一の通知グループに属します。サーバーは、サーバーで障害が発生したとき(およびグループを終了したとき)または動作を再開したとき(およびグループを再結合したとき)を示すメンバーシップ通知用の通知グループとともに、プライマリからの同期通知用の通知グループをリスニングします。
Oracle Stream Analyticsの高可用性アプリケーションのスケールを変更する必要がある場合、ActiveActiveGroupBean
を使用して、すべてのサーバー(プライマリおよびセカンダリ)に広がる単一のデプロイメント・グループの利点を保持する一方で、プライマリ・サーバー・ユニットとして2つ以上のサーバーを機能させることを許可する通知グループを定義します。
マルチサーバー・ドメインのデプロイメント・グループを作成するためには、Oracle Coherenceベースのクラスタリングを使用する必要があります。デフォルト・グループまたはカスタム・グループのいずれかを使用できます。
詳細は、次を参照してください。
17.5 高可用性アダプタ
Oracle Stream Analytics高可用性を実装するには、高可用性入力アダプタ(オプション)と、高可用性出力アダプタ(必須)をEPNに追加します。
高可用性入力アダプタ
プライマリ・サーバーのオプションの高可用性入力アダプタは、各セカンダリ・サーバーの対応する高可用性入力アダプタと通信し、イベント・タイムスタンプを正規化します。Oracle Stream Analyticsの高可用性によって、高可用性入力アダプタの1つの種類が提供されます。
高可用性入力アダプタを参照してください。
高可用性出力アダプタ
アプリケーションに高可用性の機能を実装するには、EPNで各出力アダプタの前に高可用性出力アダプタを配置します。プライマリ・サーバーの高可用性出力アダプタは、Oracle Stream Analyticsアプリケーションをダウンストリーム・クライアントに接続する出力ストリームにイベントを出力します。
プライマリの高可用性出力アダプタも対応する各セカンダリの高可用性出力アダプタと通信を行い、選択する高可用性のサービス品質に依存して、セカンダリ出力アダプタに出力イベントのインメモリー・キューをトリミングするように命令することができます。
高可用性出力アダプタの詳細は、バッファリング出力アダプタ、ブロードキャスト出力アダプタおよび相関出力アダプタを参照してください。どの出力アダプタを選択するかは、選択する高可用性のサービス品質によって決定されます。サービス品質オプションの選択を参照してください。
図17-5は、定位置にすべての実行可能な高可用性アダプタを持つEPNを簡略化して示しています。この図ではチャネルがなくプロセッサが1つです。
17.5.1 高可用性入力アダプタ
各イベントはイベントの発生時点で関連付けられます。イベント・タイムスタンプを生成するには、アプリケーション・タイムスタンプとシステム・タイムスタンプの2つの方法があります(アプリケーション・タイムスタンプとシステム・タイムスタンプの詳細は、チャネルを参照してください)。アプリケーション時間とは、イベントがCQLプロセッサに入る前に、時間値がアプリケーションによって外部で各イベントに割り当てられることを意味します。システム時間とは、CQLプロセッサへの到着時に、時間値がOracle Stream Analyticsによって自動的にイベントに関連付けられることを意味します。
アプリケーション時間は、通常、アプリケーションの高可用性のために必要な最善の選択です。アプリケーション時間は、Oracle Stream Analyticsにイベントが送信される前にイベントに関連付けられるため、アクティブなプライマリおよびセカンダリのインスタンスの全体に渡って整合性があります。システム時間は、システム・クロックが同期されていないことによって、イベントに関連付けられた時間値が各インスタンスで異なる可能性があるためアプリケーションのインスタンスに異なる結果を生成させます。
CQLの問合せが時間ベースのウィンドウを使用しないアプリケーションについては、システム時間を使用しても問題ありません。イベントベースのウィンドウのみ使用するアプリケーションは、受信時間ではなくイベントを受信した順番に依存するためこの場合はシステム時間を使用できます。
時間ベースのウィンドウを使用し、外部で生成された(アプリケーション)タイムスタンプを持たないアプリケーションについては、オプションのOracle Stream Analytics高可用性入力アダプタを使用して、すべてのサーバーで一定の時間値を指定できます。プライマリ・サーバー上の入力アダプタ・インスタンスは、イベントがアダプタに到着した時点でイベントに時間を割り当て(ナノ秒単位)、各イベントに割り当てられた時間値をすべてのセカンダリ・サーバーに転送します。
時間値は、EPN内の任意のダウンストリーム・チャネルにイベントが到着する前に各イベントに割り当てられるため、ダウンストリーム・チャネルは、イベントのチャネル到着時に新しい時間値をイベントに割り当てないようにアプリケーションの時間を使用するように構成する必要があります。
入力イベントは、このアダプタを使用するために各イベントを一意で識別するキーを持つ必要があります。
ハートビート・イベントを送信するように、Oracle Stream Analyticsの高可用性入力アダプタを構成できます。
Oracle Stream Analyticsの高可用性入力アダプタは、すべての高可用性のサービス品質オプションに適用できます。ただし、高可用性入力アダプタはパフォーマンスのオーバーヘッドを増加するため、一部の高可用性サービス品質オプション(シンプル・フェイルオーバーおよびバッファリングを使用するシンプル・フェイルオーバーなど)には適しません。このようなオプションでは、かわりにアプリケーション時間と何らかの着信イベント・プロパティの使用を検討します。
詳細は、次を参照してください。
17.5.2 バッファリング出力アダプタ
Oracle Stream Analyticsの高可用性バッファリング出力アダプタは、バッファリング型キュー・トリミング方式を実装します。バッファはストリームからの出力イベントのスライディング・ウィンドウです。ウィンドウのサイズはミリ秒単位で測定されます。
Oracle Stream Analyticsの高可用性バッファリング出力アダプタは、シンプル・フェイルオーバーおよび高可用性のサービス品質オプションのバッファリングを使用するシンプル・フェイルオーバーに適用されます。
詳細は、次を参照してください。
17.5.3 ブロードキャスト出力アダプタ
Oracle Stream Analyticsの高可用性ブロードキャスト出力アダプタは、分散型キュー・トリミング方式を実装します。アクティブ・プライマリ・インスタンスは、メッセージを通知グループ内のアクティブ・セカンダリ・インスタンスにブロードキャストし、キューのローカル表現をトリミングするタイミングを通知します。
Oracle Stream Analyticsの高可用性ブロードキャスト出力アダプタは、軽量キュー・トリミングの高可用性のサービス品質オプションに適用されます。
詳細は、次を参照してください。
17.5.4 相関出力アダプタ
Oracle Stream Analyticsの高可用性相関出力アダプタは、通常はJMSから2つのイベント・ストリームを関連付けます。このアダプタは、イベントのインバウンド・バッファと同一イベント・ストリームのセカンド・ソースに関連付け、構成可能な時間間隔の後で相関関係付けに障害が発生する場合にバッファを出力します。関連付けられたイベントは、キューからトリミングされます。関連付けられたイベントは、順序通りに整理されると仮定されます。
Oracle Stream Analyticsの高可用性相関出力アダプタは、JMS高可用性のサービス品質オプションを使用する正確なリカバリに適用されます。
詳細は、次を参照してください。
17.6 高可用性およびスケーラビリティ
Oracle Stream Analytics高可用性アプリケーションのスケールを変更する必要がある場合は、通知グループのSpring BeanであるActiveActiveGroupBean
を使用すると、JMSアプリケーションのスケーラビリティが向上します。
ActiveActiveGroupBean
では、すべてのサーバー(プライマリおよびセカンダリ)に広がる単一のデプロイメント・グループの利点を保持する一方で、複数のサーバーを1つの高可用性ユニットとして機能させることが可能な通知グループを定義します。
図17-6は、最も単純な構成から高可用性、そして高可能性とスケーラビリティの両方へと至る3つのOracle Stream Analyticsアプリケーションのシナリオを示します。
大半のアプリケーションは、高可用性を持たないシングルサーバー・ドメインで起動します。この最も単純なシナリオの場合、1つのOracle Stream Analyticsサーバーで実行されるOracle Stream Analyticsアプリケーションが、1つの入力イベント・ストリームを処理して出力イベントを生成します。
高可用性のシナリオ: アプリケーションがOracle Stream Analytics高可用性オプションを使用するように構成され、2つのサーバーで構成されるマルチサーバー・ドメインのデプロイメント・グループにデプロイされて、プライマリ・サーバーのみがイベントを出力します。
高可用性とスケーラビリティのシナリオ: 高可用性アプリケーションは、通知グループを定義するためにActiveActiveGroupBean
を使用するように構成されます。各通知グループには、単一の高可用性ユニットとして機能する複数のサーバーが含まれます。このシナリオでは、各通知グループ内のプライマリ・サーバーのみがイベントを出力します。通知グループ内のプライマリ・サーバーが停止した場合、Oracle Stream Analytics高可用性フェイルオーバーが発生し、その通知グループ内のセカンダリ・サーバーが新しいプライマリとして宣言されて、構成されているOracle Stream Analytics高可用性のサービス品質に従って、イベントの出力が再開されます。
詳細は、高可用性のあるパーティション化の構成を参照してください。
17.7 サービス品質オプションの選択
欠落イベントおよび複製イベントに対するアプリケーションの許容値と、期待されるイベント・スループットに適するサービス品質オプションを選択します。プライマリ・サーバーおよびセカンダリ・サーバーのハードウェア要件は、サービス品質がより正確になるほど上がるので注意してください。
表17-1に示すサービス品質オプションのいずれかを選択できます。
表17-1 Oracle Stream Analytics高可用性のサービス品質
高可用性オプション | 欠落イベント? | 重複イベント? | パフォーマンス・オーバーヘッド |
---|---|---|---|
はい(多数) |
はい(少数) |
ごくわずか |
|
はい(少数) |
はい(多数) |
低 |
|
いいえ |
はい(少数) |
低-中 |
|
いいえ |
いいえ |
高 |
17.7.1 シンプル・フェイルオーバー
シンプル・フェイルオーバー高可用性のサービス品質は、最低のパフォーマンス・オーバーヘッド(リカバリ時間が速い)および最低のデータ整合性(フェイルオーバー時に欠落イベントと複製イベントの両方の可能性があります)によって特徴付けられます。
プライマリ・サーバーはイベントを出力し、セカンダリ・サーバーは出力イベントのバッファリングを行わないため、その出力イベントを破棄します。現在のアクティブ・プライマリで障害が発生した場合、通知されると新しいアクティブ・プライマリが選択され、出力イベントの送信を開始します。
フェイルオーバー中には、前のプライマリより前または後で稼働しているかに応じて、新しいプライマリによって多くのイベントが欠落したり複製されたりする場合があります。
フェイルオーバー・ウィンドウ中には、イベントが欠落する場合があります。たとえば、1秒当たり100個のイベントを処理してフェイルオーバーに10秒かかる場合、1000個のイベントが欠落します。
新しいプライマリ・サーバーは、ただちにPRIMARY
状態に入ります。BECOMING_PRIMARY
状態から新しいプライマリ・サーバーが遷移する前に満たす必要がある構成可能な準備状態のしきい値はありません。Oracle Event Processingサーバーがマルチサーバー・ドメインに再結合するとき、セカンダリとしてただちに利用可能になります。
この高可用性のサービス品質を実装するには、各出力アダプタの前に高可用性バッファリング出力アダプタを使用して(サイズがゼロのスライディング・ウィンドウを使用して)EPNを構成します。パフォーマンス・オーバーヘッドを削減するには、高可用性入力アダプタを使用せずに一部の着信イベント・プロパティを持つアプリケーション時間を使用します。
詳細は、シンプル・フェイルオーバーの構成を参照してください。
17.7.2 バッファリングを使用するシンプル・フェイルオーバー
バッファリングを使用するシンプル・フェイルオーバーの高可用性のサービス品質は、低いパフォーマンス・オーバーヘッド(リカバリ時間が速い)および向上したデータ整合性(フェイルオーバー時に欠落イベントはなくても多数の複製イベントの可能性があります)によって特徴付けられます。
プライマリ・サーバーはイベントを出力し、セカンダリ・サーバーはその出力イベントをバッファリングします。現在のアクティブ・プライマリで障害が発生した場合、通知されると新しいアクティブ・プライマリが選択され、出力イベントの送信を開始します。
フェイルオーバー・ウィンドウ中には、イベントが欠落する場合があります。たとえば、1秒当たり100個のイベントを処理してフェイルオーバーに10秒かかる場合、1000個のイベントが欠落します。セカンダリのバッファが大容量の場合、多数の複製が出力される可能性があります。一方、バッファが大容量になるほどメッセージの欠落の可能性は低くなります。
Oracle Stream Analyticsサーバーによりマルチサーバー・ドメインが再結合される際、アプリケーションがOracle Stream Analyticsの高可用性タイプ1アプリケーションである場合(このアプリケーションでは、既存のセカンダリと完全に同一の出力イベントのシーケンスを生成する必要があります)、アプリケーションをセカンダリとして使用可能になるまで、Oracle Stream Analyticsの高可用性出力アダプタに構成したwarm-up-window-length
の時間待機する必要があります。
この高可用性のサービス品質を実装するには、各出力アダプタの前にサイズがゼロより大きいスライディング・ウィンドウを使用し、高可用性バッファリング出力アダプタを使用してEPNを構成します。パフォーマンス・オーバーヘッドを削減するには、高可用性入力アダプタを使用せずに一部の着信イベント・プロパティを持つアプリケーション時間を使用します。
詳細は、次を参照してください。
17.7.3 軽量キュー・トリミング
この高可用性のサービス品質は、低いパフォーマンス・オーバーヘッド(リカバリ時間が速い)および向上したデータ整合性(フェイルオーバー時に欠落イベントはなくても少数の複製イベントの可能性があります)によって特徴付けられます。
アクティブ・プライマリはセカンダリに通信し、イベントを実際に処理します。これによって、特定の時点でプライマリによって送信されていないイベントのみを含むようにセカンダリは出力イベントのバッファをトリミングできます。イベントは現在のプライマリによって送信された後でのみトリミングされるので、セカンダリによってフェイルオーバーの発生時に任意の出力イベントが欠落しないようにできます。
アクティブ・プライマリがキュー・トリミング・メッセージをアクティブ・セカンダリに送信する頻度は、次のように構成可能です。
-
n
個のイベントごと(n>0
)これによって、フェイルオーバー時に複製された出力イベントの数を最大
n
個に限定します。 -
n
ミリ秒ごと(n>0
)
キュー・トリミング・アダプタには、アクティブ・プライマリおよびセカンダリの間で統一的にイベントを識別する方法が必要です。お薦めの方法は、イベントを識別するためにアプリケーション時間を使用することですが、一意にイベントを識別する任意のキー値が有効です。
キュー・トリミングの利点は、出力イベントが絶対に欠落しないことです。ただし、通信の必要があるトリミング・メッセージを送信するために、アクティブ・プライマリで若干のパフォーマンス・オーバーヘッドが発生します。このオーバーヘッドは、キュー・トリミング・メッセージの頻度が高くなるほど大きくなります。
フェイルオーバー中には、新しいプライマリがBECOMING_PRIMARY
状態に入り、そのイベント・キュー(セカンダリとして累積していく)がフラッシュされるまで、PRIMARY
状態には遷移しません。この遷移中には、新しい入力イベントがバッファリングされ、一部の複製イベントが出力される場合があります。
Oracle Stream Analyticsサーバーによりマルチサーバー・ドメインが再結合される際、アプリケーションがOracle Stream Analyticsの高可用性タイプ1アプリケーションである場合(既存のセカンダリと完全に同一の出力イベントのシーケンスを生成する必要があるアプリケーション)、アプリケーションをセカンダリとして使用可能になるまで、Oracle Stream Analyticsの高可用性出力アダプタに構成したwarm-up-window-length
の時間待機する必要があります。
この高可用性のサービス品質を実装するには、各入力アダプタおよび高可用性ブロードキャスト出力アダプタの後、各出力アダプタの前に、高可用性入力アダプタを使用してEPNを構成します。
詳細は、軽量キュー・トリミングの構成を参照してください。
17.7.4 JMSによる正確なリカバリ
JMSによる正確なリカバリの高可用性のサービス品質は、高パフォーマンス・オーバーヘッド(リカバリ時間が遅い)および最大のデータ整合性(フェイルオーバー時に欠落イベントも複製イベントもありません)によって特徴付けられます。この高可用性のサービス品質は、JMSの入力アダプタおよび出力アダプタにのみ対応します。
JMS高可用性のサービス品質を使用する正確なリカバリでは、シングルサーバーのイベント・パスに伴うトランザクションの保証は重視されず、サーバーのセットからの単一の出力が重視されます。保証を達成するため、セカンダリ・サーバーは、プライマリによってパブリッシュされるイベント・ストリームにJMS経由でリスニングします。図17-7は、この着信イベント・ストリームが、セカンダリが出力キューをトリミングするために使用する信頼できるキュー・トリミング・メッセージのソースであることを示します。JMSが信頼できる転送に構成されている場合、セカンダリで確認されるイベントのストリームは、正確にプライマリによって出力されるイベントのストリームであるため、フェイルオーバーは以前のプライマリ・サーバーによって転送されないイベントを新しいプライマリ・サーバーが正確に出力することを可能にします。
フェイルオーバー中には、新しいプライマリ・サーバーがBECOMING_PRIMARY
状態に入り、そのイベント・キュー(セカンダリとして累積していく)がフラッシュされるまで、PRIMARY
状態には遷移しません。この遷移中には、新しい入力イベントがバッファリングされ、複製イベントは出力されません。
Oracle Stream Analyticsサーバーによりマルチサーバー・ドメインが再結合される際、アプリケーションがOracle Stream Analyticsの高可用性タイプ1アプリケーションである場合(このアプリケーションでは、既存のセカンダリと完全に同一の出力イベントのシーケンスを生成する必要があります)、アプリケーションをセカンダリ・サーバーとして使用可能になるまで、Oracle Stream Analyticsの高可用性出力アダプタに構成したwarm-up-window-length
の時間待機する必要があります。
JMSによる正確なリカバリの高可用性のサービス品質を実装するには、各入力アダプタおよび高可用性相関出力アダプタの後、各出力アダプタの前に、高可用性入力アダプタを使用してEPNを構成します。
スケーラビリティを向上するため、高可用性のサービス品質を持つクラスタ・グループBeanも使用できます。
詳細は、次を参照してください。
17.8 高可用性のためのアプリケーション設計
高可用性のためのアプリケーションを設計する際には、ここで説明する主なユース・ケース、設計パターン、およびOracle CQL問合せの制約を考慮してください。
Oracle Stream Analyticsの高可用性を宣言的に実装できますが、選択する高可用性のサービス品質から完全に利点を引き出すには、Oracle Stream AnalyticsアプリケーションがOracle Stream Analyticsの提供する高可用性オプションを利用するように設計する必要があります。
17.8.1 プライマリ高可用性のユース・ケース
様々なOracle Stream Analyticsアプリケーション設計に高可用性オプションを適応できますが、一般的に、Oracle Stream Analytics高可用性は、次のユース・ケースを対象に設計されています。
-
アプリケーションは1つ以上の外部システムから入力イベントを受信します。
-
外部システムは、パブリッシュ/サブスクライブ・スタイルのシステムで、複数のアプリケーションのインスタンスが同時に接続し、同一のメッセージのストリームを受信することを可能にします。
-
アプリケーションは、複数のアプリケーションのコピーが同時に実行される場合、競合が発生しないように外部のシステムを更新しません。
-
アプリケーションは、出力イベントを外部のダウンストリーム・システムに送信します。複数のアプリケーションのインスタンスは、一度にメッセージを送信できるアプリケーションのインスタンスは1つのみですが、ダウンストリーム・システムに同時に接続できます。
このような制約では、次の異なるケースが注目されます。
-
アプリケーションは、障害の発生時に、一部の出力イベントのダウンストリーム・システムへの送信をスキップすることが許可されます。複製も許可されます。高可用性のサービス品質オプションとしてシンプル・フェイルオーバーを使用します。
-
アプリケーションは、複製イベントをダウンストリーム・システムに送信することを許可されますが、障害の発生時に任意のイベントをスキップすることは禁止されます。高可用性のサービス品質オプションとして、バッファリングを使用するシンプル・フェイルオーバーと軽量キュー・トリミングを使用します。
-
アプリケーションは、障害の発生中にイベントが送信できない短い一時停止を法として、障害の発生時に完全に同一のメッセージ/イベントのストリームを送信する必要があります。高可用性のサービス品質オプションとしてJMSによる正確なリカバリを使用します。
17.8.2 高可用性の設計パターン
Oracle Stream AnalyticsアプリケーションをOracle Stream Analytics高可用性オプションとともに使用するように設計する場合は、次の設計パターンに従います。
17.8.2.3 必要なものの保存
Oracle Stream Analyticsシステムは、該当する少数のイベントを生成するために問い合せられる多数の生の入力イベントを受信します。通常、該当するイベントは数が少なく、より価値があるという理由から、それらを保存するのが合理的です。
17.8.2.4 Oracle Stream Analyticsアプリケーション状態の制限
Oracle Stream Analyticsシステムを使用すると、イベント・ウィンドウの問合せが可能です。きわめて大きいウィンドウを使用してシステムを構築することは魅力的ですが、障害の発生時に再構築の必要がある状態が増加します。通常、このような技術の高可用性ファシリティを活用するために、長期状態は分散型キャッシュやデータベースのような安定したストレージに保存されるとみなす方が良さそうです。
17.8.2.5 適切なwarm-up-window-length時間の選択
新しいOracle Stream Analyticsサーバーが高可用性マルチサーバー・ドメインに追加されるか、または障害が発生した既存のサーバーが再起動される場合、サーバーでは、デプロイされているすべてのアプリケーションが完全に結合されるまで、Oracle Stream Analytics高可用性デプロイメントと通知グループは完全には結合されません。いつ完全に結合するかは、アプリケーションの種類によって異なります。
Oracle Stream Analyticsの高可用性アプリケーションは、表17-2で示すように、タイプ1またはタイプ2のアプリケーションとして記述できます。
表17-2 Oracle Stream Analytics高可用性アプリケーション・タイプ
アプリケーション・タイプ | 出力イベントの完全に同一のシーケンスを生成する必要があるか? | 有限の期間内に入力ストリームを処理することによって内部状態を再構築できる必要があるか? | 完全に結合する前にこの期間を待機する必要があるか? |
---|---|---|---|
タイプ1 |
はい |
はい |
はい |
タイプ2 |
いいえ |
いいえ |
いいえ |
詳細は、高可用性マルチサーバー・ドメインの再結合を参照してください。
17.8.2.5.1 タイプ1アプリケーション
タイプ1アプリケーションは、高可用性デプロイメントおよび通知グループに完全に結合すると、新しいセカンダリが既存のセカンダリ・サーバーと完全に同一の出力イベントのシーケンスを生成するように要求します。
タイプ1アプリケーションは、アプリケーションを実行している他のセカンダリ・サーバーと完全に同一の出力イベントのストリームを生成した後で、有限の期間(warm-up-window-length
の時間)にその入力ストリームを処理することによって、内部状態を再構築する必要があります。
高可用性出力アダプタ上で、warm-up-window-length
の時間を構成します。warm-up-window-length
の時間の長さは、秒または分単位で指定します。たとえば、アプリケーションに5分、7分、15分の範囲をベースとするウィンドウを持つOracle CQL問合せが含まれる場合、最小のwarm-up-window-length
時間は15分(最大の範囲をベースとするウィンドウ・サイズ)となります。Oracleは、必要な状態が利用可能であることを保証するために数分の値を持つ最大ウィンドウ長もお薦めします。そのため先の例では17分または20分がwarm-up-window-length
時間に適した長さとなります。
サーバーは、warm-up-window-length
の期間中はシステム時間を使用するため、サーバー時間は処理中のイベントに関連したアプリケーション時間には直接関連付けられません。
タイプ1アプリケーションは、有限の期間中に発生したイベントのみを対象とします。すべての範囲をベースとするOracle CQLウィンドウは、warm-up-window-length
時間よりも短縮する必要があり、タプルベースのウィンドウが時間によって条件を付けられる必要があります。たとえば、アプリケーションは、直近の10個のイベントが直近の5分間に発生した場合、それらのイベントのみを問い合せます。このプロパティを持たないアプリケーションは、タイプ1アプリケーションではありえずwarm-up-window-length
の期間を使用できません。
たとえば、時間の条件を持たないタプルベースでパーティション化されたウィンドウを使用するアプリケーションは、任意の時間量がウィンドウの状態の再構築に必要となるためwarm-up-window-length
を使用できません。
タイプ1アプリケーションが高可用性ブロードキャスト出力アダプタを使用する場合、一意のアプリケーション専用キーまたはアプリケーション時間のようなモノトニックなキーを使用することによって、イベントをトリミングできます。アプリケーション時間を使用してイベントをトリミングすることは、出力イベントが生成されない可能性があるアプリケーションにおいて、堅牢性が増すとともに不具合への脆弱性が低下するためお薦めです。
詳細は、次を参照してください。
17.8.2.5.2 タイプ2アプリケーション
タイプ2アプリケーションは、高可用性デプロイメントおよび通知グループに完全に結合すると、新しいセカンダリ・サーバーが既存のセカンダリ・サーバーと同一の出力イベントのシーケンスを生成するように要求しません。新しいクラスタ・メンバーが、入力イベントの処理を開始する時点に関して有効な出力イベントを生成するように要求するのみです。
タイプ2アプリケーションはwarm-up-window-length
期間を要求しません。
大半のアプリケーションは、タイプ2アプリケーションです。アプリケーションが任意の時点で(プライマリOracle Stream Analyticsサーバー上で)起動し、その時点で入力ストリームからイベントの処理を開始して、有効な出力イベントを生成することが多くあります。アプリケーションの起動中は入力ストリームが一時停止されず、入力イベントは常に生成されて受信します。多くの場合、若干異なるタイミングで同じ処理を実行するセカンダリ・ステージでも、アプリケーションの観点から見れば有効な出力イベントが生成されると想定できますが、タイミングのわずかな違いのために、プライマリ・サーバーによって生成されるイベントと同一とはかぎりません。
たとえば、金融市場が開いている間のみ実行される金融アプリケーションは、次のようにタイプ2のアプリケーションとして動作できます。すべてのサーバーは市場が開く前に起動し、市場データ・ストリームにおける同じ時点で着信イベントの処理を開始します。障害に備えるために複数のセカンダリ・サーバーを実行できますが、市場が開いている間セカンダリ・サーバーの数が十分な場合には、障害が発生するセカンダリ・サーバーを再起動したり、セカンダリ・サーバーを追加しないでください。これは、どのセカンダリ・サーバーも状態をリカバリする必要がないためです。
17.8.2.6 アプリケーションが多重呼出し不変であることの保証
異なるサーバー上でアプリケーションの2つのコピーを実行でき、そのコピーは共有されたキャッシュやデータベースで競合しません。外部のリレーション(キャッシュや表など)を使用する場合、サーバーがクラスタに再結合するとき、アプリケーションは以前と同一のキャッシュや表にアクセスします。アプリケーションは同一の外部リレーションに再結合する必要があります。データが必ず同一のデータ・ソースから抽出されるように、サーバー上のデータ・ソースは変更しないでください。
17.8.2.7 外部のソース・イベント・アイデンティティ
多くの高可用性ソリューションでは、異なるサーバー間でイベントの関連付けが必要です。イベントを関連付けるには、イベントをユニバーサルに識別可能にする必要があります。イベントをユニバーサルに識別可能にする最適な方法は、外部情報、可能であればタイムスタンプを使用してイベントにシードすることです。詳細は、アプリケーション時間の優先を参照してください。
17.8.2.8 イベント順序の重要性の理解
プライマリおよびセカンダリのサーバーは、キュー・トリミングおよび同等ベースのイベント識別子(継続的に増加しない、モノトニックではないイベント識別子)を使用する高可用性のサービス品質オプションを選択する場合、同一の出力イベントを完全に同一の順序で生成する必要があります。異なる順序で出力イベントを生成すると、障害の発生時に出力イベントが欠落したり、出力イベントが不要に重複したりする可能性があります。
図17-8で示される出力イベント・ストリームを検討してください。プライマリ・サーバーは、出力イベントa
、b
、およびc
を持ちます。イベントc
を出力後、プライマリはセカンダリにキュー・トリミング・メッセージを送信します。
セカンダリ・サーバーは、イベントc
自体を含むイベントc
の前に生成されたキュー内のすべてのイベントをトリミングします。この場合、イベント・セットは{a, b, e, d, c}
となり、これらはプライマリ・サーバーがイベントd
およびe
をまだ出力していないため適切ではありません。イベントc
のトリミング・メッセージの処理後にフェイルオーバーが発生する場合、イベントは失われます。
17.8.2.8.1 確定的動作の優先
複数のインスタンス上で実行される場合、アプリケーションが同一の順序でイベントを生成するためには、確定している必要があります。アプリケーションは次の要素に依存させないでください。
-
異なるマシン上に異なる結果を返す可能性がある乱数ジェネレータ。
-
System.getTimeMillis
またはSystem.nanoTime
などのメソッド。これらはシステム・クロックが同期されていないため、異なるマシン上で異なる結果を返す可能性があります。
17.8.2.8.2 マルチスレッドの回避
スレッド・スケジューリング・アルゴリズムは時間への依存度がきわめて高いため、マルチスレッドはアプリケーション内で非確定的なソースとなります。異なるスレッドは、異なるマシン上および異なる時間でスケジューリングできます。
たとえば、複数のスレッドが高可用性アダプタに並列にイベントを送信するEPNを作成しないでください。そのようなチャネルが高可用性アダプタのイベント・ソースの場合、イベントが異なるスレッドごとに並列にアダプタに送信されるようになり、イベント順序を非確定的にすることができる可能性があります。また、複数のスレッドを持つメディエータ(JMSサーバー)はイベントを送信しないでください。このメディエータはイベント・ソースとして機能します。
17.8.2.9 高可用性を考慮したOracle CQL問合せの記述
Oracle Stream Analytics高可用性を使用する際に、Oracle CQL問合せのすべての使用方法がサポートされるわけではありません。この制約を解決するには、Oracle CQLの問合せを再定義する必要があります。詳細は、Oracle CQLの問合せの制約を参照してください。
17.8.2.10 サーバーのカップリングの回避
Oracle Stream Analyticsシステムで高可用性のパフォーマンスが最も高くなるのは、サーバーが調整を必要とせずに実行できるときです。通常、共有状態が存在せず、ダウンストリーム・システムが複製を許容する場合にこれは実行できます。高可用性のレベルを上げることは、ダウンストリーム・システムが確認するイベント・ストリームの忠実度を上げることを目標としますが、忠実度を上げることはパフォーマンスのペナルティを伴います。
17.8.2.11 サーバー・リカバリの計画
セカンダリ・サーバーがマルチサーバー・ドメインに再結合するときには、現在のプライマリとアクティブ・セカンダリが一致するようにアプリケーション状態を再構築する時間が必要です。適切なwarm-up-window-length時間の選択を参照してください。
マルチサーバー・ドメインに再結合した後に、セカンダリ・サーバーがアクティブ・セカンダリ・サーバーとして利用可能になるためにかかる時間が、要求するアクティブ・セカンダリ・サーバーの数における要因となります。
準備完了前にセカンダリが新しいプライマリ・サーバーになることを宣言される場合、セカンダリ・サーバーは例外をスローします。
17.8.3 Oracle CQLの問合せの制約
高可用性アプリケーションでは、Oracle CQL問合せに次のような制約があります。
17.8.3.1 範囲ベースのウィンドウ
タイプ1アプリケーションでは、既存のセカンダリと完全に同一の出力イベントのシーケンスを生成する必要があり、すべての範囲ベースのOracle CQLウィンドウは、warm-up-window-length
の時間よりも短くする必要があります。適切なwarm-up-window-length時間の選択を参照してください。
チャネルは、Oracle CQLの問合せが範囲ベースのウィンドウを含む場合にアプリケーション時間を使用する必要があります。アプリケーション時間の優先を参照してください。
17.8.3.2 タプルベースのウィンドウ
タイプ1アプリケーションでは、既存のセカンダリと完全に同一の出力イベントのシーケンスを生成する必要があり、すべてのタプルベースのウィンドウは、時間によって条件が付けられる必要があります。適切なwarm-up-window-length時間の選択を参照してください。
17.8.3.3 パーティション化されたウィンドウ
パーティションを再構築できない場合があるため、パーティション化されたウィンドウは避けてください。パーティション化されたウィンドウを使用する場合、Oracle Stream Analyticsサーバーの時間がパーティションを再構築するのに十分な長さとなるようにwarm-up-window-length
を構成します。適切なwarm-up-window-length時間の選択を参照してください。
17.8.3.4 スライディング・ウィンドウ
マルチサーバー・ドメインに結合する新しいステージが、既存のステージと完全に同一の出力イベントを生成すると想定される場合、Oracle CQL問合せでスライディング・ウィンドウは使用しないでください。高可用性マルチサーバー・ドメインの再結合を参照してください。
17.8.3.5 DURATION句および非イベント検出
Oracle CQLの問合せが非イベント検出のDURATION
句を含む場合、アプリケーション時間を使用する必要があります。アプリケーション時間の優先を参照してください。
17.8.3.6 アプリケーション時間の優先
Oracle Stream Analyticsでは、各イベントは、そのイベントの発生時点に関連付けられます。Oracle CQLは次の2種類を認識します。
-
アプリケーション時間: イベントがOracle CQLプロセッサに入る前に、アプリケーションによってOracle CQLの外で各イベントに割り当てられた時間値です。
-
システム時間:
System.nanoTime()
を必ずコールすることによって、Oracle CQLプロセッサに到着時にイベントに関連付けられる時間値です。
アプリケーション時間は、通常、アプリケーションの高可用性のために必要な最善の選択です。アプリケーション時間は、ダウンストリームにイベントが送信される前にイベントに関連付けられるため、アクティブなプライマリおよびセカンダリ・サーバーの全体に渡って整合性があります。
システム時間は、システム・クロックが同期されていないことによって、イベントに関連付けられた時間値が各サーバーで異なる可能性があるためアプリケーションのインスタンスに異なる結果を生成させます。Oracle CQLの問合せが時間ベースのウィンドウを使用しない場合、アプリケーションにシステム時間を使用できます。イベントベースのウィンドウのみ使用するアプリケーションは、受信時間ではなくイベントを受信した順番に依存するためこの場合はシステム時間を使用できます。
時間ベースのウィンドウを使用するOracle CQLの問合せに関してシステム時間を使用する必要がある場合は、Oracle Stream Analyticsの高可用性入力アダプタを使用する必要があります。このアダプタは、着信イベントを捕捉し、プライマリおよびセカンダリ・サーバーのインスタンス全体に渡る統一的な時間を割り当てます。
17.9 高可用性のサービス品質の構成
アセンブリおよびコンポーネント構成ファイルで、Oracle Stream Analyticsの高可用性のサービス品質を構成します。
Oracle Stream Analytics高可用性の構成を変更した後、Oracle Stream Analyticsアプリケーションを再デプロイする必要があります。
この項の内容は次のとおりです。
17.9.1 シンプル・フェイルオーバーの構成
スライディング・ウィンドウのサイズをゼロ(0)に設定し、Oracle Stream Analytics高可用性バッファリング出力アダプタを使用してシンプル・フェイルオーバーを構成します。
この手順は、図17-9で示すEPNの例から始まり、シンプル・フェイルオーバー用に構成するために必要なコンポーネントを加えていきます。
シンプル・フェイルオーバーの構成:
17.9.2 バッファリングを使用するシンプル・フェイルオーバーの構成
スライディング・ウィンドウのサイズをゼロ(0)より大きく設定して、Oracle Stream Analyticsバッファリング出力アダプタを使用してシンプル・フェイルオーバーを構成します。
この手順は、図17-10で示すEPNの例から始まり、バッファリングを使用するシンプル・フェイルオーバー用に構成するために必要なコンポーネントを加えていきます。
バッファリングを使用するシンプル・フェイルオーバーの構成:
17.9.3 軽量キュー・トリミングの構成
Oracle Stream Analyticsの高可用性入力アダプタおよびブロードキャスト出力アダプタを使用して、軽量キュー・トリミングを構成します。
この手順は、図17-11で示すEPNの例から始まり、軽量キュー・トリミング用に構成するために必要なコンポーネントを加えていきます。
軽量キュー・トリミングの構成:
17.9.4 JMSによる正確なリカバリの構成
Oracle Stream Analyticsの高可用性入力アダプタおよび相関出力アダプタを使用して、JMSによる正確なリカバリを構成します。
この手順では、図17-12が示すEPNの例を作成する方法を説明します。このOracle Stream Analytics高可用性のサービス品質の詳細は、JMSによる正確なリカバリを参照してください。
注意:
正確なリカバリのためにJMSアダプタによって使用されるJMS宛先は、キューではなくトピックである必要があります。
JMSによる正確なリカバリの構成
17.10 高可用性アダプタの構成
チャネルやプロセッサなどのEPN内の他のコンポーネントを構成する方法と同様に、EPNアセンブリ・ファイルおよびコンポーネント構成ファイルでOracle Stream Analyticsの高可用性アダプタを構成します。
Oracle Stream Analytics高可用性の構成を変更した後、Oracle Stream Analyticsアプリケーションを再デプロイする必要があります。OSGiバンドルのデプロイを参照してください。
この項の内容は次のとおりです。
17.10.1 高可用性入力アダプタの構成
Oracle Stream Analyticsの高可用性ブロードキャスト入力アダプタは、BroadcastInputAdapter
インタフェースによって実装されます。
アセンブリ・ファイル
Oracle Stream Analyticsの高可用性入力アダプタを宣言するためのルート要素は、provider
要素をha-inbound
に設定したwlevs:adapter
です。入力アダプタでOracle Stream Analyticsの高可用性入力アダプタのwlevs:listener要素も指定します。
<wlevs:adapter id="jmsAdapter" provider="jms-inbound" <wlevs:listener ref="myHaInputAdapter"/> </wlevs:adapter> <wlevs:adapter id="myHaInputAdapter" provider="ha-inbound"> <wlevs:instance-property name="keyProperties" value="id"/> <wlevs:instance-property name="timeProperty" value="arrivalTime"/> <wlevs:instance-property name="eventType" value="MyEventType"/> </wlevs:adapter> <wlevs:channel id="inputChannel" event-type="MyEventType "> <wlevs:source ref="myHaInputAdapter"/> <wlevs:application-timestamped> <wlevs:expression>arrivalTime</wlevs:expression> </wlevs:application-timestamped> </wlevs:channel>
表17-3は、追加子要素を説明しています。
表17-3 高可用性入力アダプタ用wlevs:adapterの子要素
子要素 | 説明 |
---|---|
|
1つ以上の |
表17-4に、サポートされているインスタンス・プロパティと、その名前属性および値属性を示します。
表17-4 高可用性入力アダプタのインスタンス・プロパティ
名前 | 値 |
---|---|
|
高可用性入力アダプタが時間値を割り当てる対象のイベント・プロパティ名を指定します。 これは、高可用性入力アダプタの接続対象となる、ダウンストリームEPNコンポーネントの |
|
Oracle Stream Analyticsの高可用性入力アダプタがイベント・インスタンスを識別するために使用する、1つ以上のイベント・プロパティのスペースで区切られたリストを指定します。 1つ以上のプロパティを指定する場合は、keyClassを指定する必要があります。 デフォルト: すべてのイベント・プロパティ。 |
|
複合キーとして使用される完全修飾Javaクラス名を指定します。 デフォルトでは、 |
|
Oracle Stream Analyticsの高可用性入力アダプタが実際の入力アダプタから受信するイベントの種類名を指定します。これは、高可用性入力アダプタの接続対象となる、ダウンストリームEPNコンポーネントで使用するイベント型と同一です。 タプル・イベントの場合、このプロパティは必須です。すべての他のJavaクラス・ベースのイベント型の場合、このプロパティはオプションです。 |
構成ファイル
Oracle Stream Analyticsの高可用性入力アダプタの構成用ルート要素は、ha-inbound-adapter
です。name
子要素は、次に示すアセンブリ・ファイル内の対応するwlevs:adapter
要素のid
属性と一致している必要があります。
<ha:ha-inbound-adapter> <name>myHaInputAdapter</name> <heartbeat units="millis">1000</heartbeat> <batch-size>10</batch-size> </ha:ha-inbound-adapter>
表17-5は、追加子要素を説明しています。
表17-5 子要素
子要素 | 説明 |
---|---|
|
時間を進めるためのハートビート・イベントを生成するまでに高可用性入力アダプタが待機できる時間の長さを指定します。
デフォルト: ハートビートが送信されません。 |
|
プライマリがセカンダリにブロードキャストする各タイミング・メッセージにおいてイベント数を指定します。 デフォルト: 1 (バッチを無効化)。 |
17.10.2 バッファリング出力アダプタの構成
Oracle Stream Analyticsの高可用性バッファリング出力アダプタは、SlidingWindowQueueTrimmingAdapter
インタフェースによって実装されます。
アセンブリ・ファイル
Oracle Stream Analyticsの高可用性バッファリング出力アダプタを宣言するためのルート要素は、次の例で示すように、provider
要素をha-buffering
に設定したwlevs:adapter
です。
<wlevs:adapter id="mySlidingWindowingAdapter" provider ="ha-buffering"> <wlevs:listener> <bean class="com.bea.wlevs.example.cluster.ClusterAdapterBean"/> </wlevs:listener> <wlevs:instance-property name="windowLength" value="15000"/> </wlevs:adapter>
表17-6は、追加子要素を説明しています。
表17-6 子要素
子要素 | 説明 |
---|---|
|
このOracle Stream Analyticsの高可用性バッファリング出力アダプタから、通常の出力アダプタのダウンストリームを指定します。 |
|
|
表17-7は、インスタンス・プロパティを一覧表示しています。
表17-7 インスタンス・プロパティ
名前 | 値 |
---|---|
|
スライディング・ウィンドウのサイズを整数のミリ秒で指定します。 デフォルト: |
構成ファイル
Oracle Stream Analyticsの高可用性バッファリング出力アダプタの構成用ルート要素は、ha-buffering-adapter
です。特定のアダプタのname
子要素は、次に示すアセンブリ・ファイル内の対応するwlevs:adapter
要素のid
属性と一致している必要があります。
<ha:ha-buffering-adapter > <name>mySlidingWindowingAdapter</name> <window-length>15000</window-length> <warm-up-window-length units="minutes">6</warm-up-window-length> </ha:ha-buffering-adapter >
表17-8は、Oracle Stream Analyticsの高可用性バッファリング出力アダプタに構成できるha-buffering-adapter
の追加子要素を示します。
表17-8 子要素
子要素 | 説明 |
---|---|
|
スライディング・ウィンドウのサイズを整数のミリ秒で指定します。 デフォルト: |
|
時間を進めるためのハートビート・イベントを生成するまでに高可用性入力アダプタが待機できる時間の長さを指定します。
デフォルト: |
17.10.3 ブロードキャスト出力アダプタの構成
Oracle Stream Analyticsの高可用性ブロードキャスト出力アダプタは、GroupBroadcastQueueTrimmingAdapter
クラスによって実装されます。
アセンブリ・ファイル
Oracle Stream Analyticsの高可用性ブロードキャスト出力アダプタを宣言するためのルート要素は、次に示すように、provider
要素をha-broadcast
に設定したwlevs:adapter
です。
<wlevs:adapter id="myBroadcastAdapter" provider="ha-broadcast"> <wlevs:listener ref="actualAdapter"/> <wlevs:instance-property name="keyProperties" value="time"/> <wlevs:instance-property name="monotonic" value="true"/> </wlevs:adapter>
表17-9は、追加子要素を説明しています。
表17-9 子要素
子要素 | 説明 |
---|---|
|
このOracle Stream Analyticsの高可用性ブロードキャスト出力アダプタから、通常の出力アダプタのダウンストリームを指定します。 |
|
|
表17-10は、インスタンス・プロパティを一覧表示しています。
表17-10 インスタンス・プロパティ
名前 | 値 |
---|---|
|
Oracle Stream Analyticsの高可用性ブロードキャスト出力アダプタがイベント・インスタンスを識別するために使用する、1つ以上のイベント・プロパティのスペースで区切られたリストを指定します。 1つ以上のプロパティを指定する場合は、keyClassを指定する必要があります。 デフォルト: すべてのイベント・プロパティ。 |
|
複合キーとして使用されるJavaクラスの完全修飾なクラス名を指定します。 デフォルトでは、 複合キーは、monotonicおよびtotalOrderになることがあります。 |
|
キーの値が(時間値のように)常に増加するかどうかを指定します。 有効な値は次のとおりです。
デフォルト: |
|
イベント・キーが一意かどうかを指定します。インスタンス・プロパティmonotonicが 有効な値は次のとおりです。
デフォルト: |
構成ファイル
Oracle Stream Analyticsの高可用性ブロードキャスト出力アダプタの構成用ルート要素は、ha-broadcast-adapter
です。特定のアダプタのname
子要素は、次に示すように、このアダプタが宣言されているEPNアセンブリ・ファイル内の対応するwlevs:adapter
要素のid
属性と一致している必要があります。
<ha:ha-broadcast-adapter> <name>myBroadcastAdapter</name> <trimming-interval units="events">10</trimming-interval> <warm-up-window-length units="minutes">6</warm-up-window-length> </ha:ha-broadcast-adapter>
表17-11は、追加子要素を説明しています。
表17-11 子要素
子要素 | 説明 |
---|---|
|
トリミング・メッセージが
デフォルト: |
|
以前に失敗したセカンダリの再起動後または新しいセカンダリが追加された後、アプリケーションが状態を再構築するのにかかる時間の長さを指定します。
デフォルト: 詳細は、適切なwarm-up-window-length時間の選択を参照してください。 |
17.10.4 相関出力アダプタの構成
Oracle Stream Analyticsの高可用性相関出力アダプタは、CorrelatedQueueTrimmingAdapter
インタフェースによって実装されます。
アセンブリ・ファイル
Oracle Stream Analyticsの高可用性相関出力アダプタを宣言するためのルート要素は、次に示すように、provider
要素をha-correlating
に設定したwlevs:adapter
です。
<wlevs:adapter id="myCorrelatingAdapter" provider="ha-correlating"> <wlevs:listener> <bean class="com.bea.wlevs.example.cluster.ClusterAdapterBean"/> </wlevs:listener> <wlevs:instance-property name="correlatedSource" ref="clusterCorrOutstream"/> <wlevs:instance-property name="failOverDelay" value="2000"/> </wlevs:adapter>
表17-12は、追加子要素を説明しています。
表17-12 子要素
子要素 | 説明 |
---|---|
|
このOracle Stream Analyticsの高可用性バッファリング出力アダプタから、通常の出力アダプタのダウンストリームを指定します。 |
|
|
表17-13は、インスタンス・プロパティを一覧表示しています。
表17-13 インスタンス・プロパティ
名前 | 値 |
---|---|
|
相関対象のイベント・ソースを指定します。このソースから参照されるイベントは、トリミング・キューからパージされます。フェイルオーバー時にキュー内に留まるイベントは再生されます。 |
|
フェイルオーバー後に相関関係が再起動される速さを決定するために使用される、遅延タイムアウトをミリ秒単位で指定します。 デフォルト: 0ミリ秒。 |
構成ファイル
Oracle Stream Analyticsの高可用性相関出力アダプタの構成用ルート要素は、ha-correlating-adapter
です。特定のアダプタのname
子要素は、次に示すように、このアダプタが宣言されているEPNアセンブリ・ファイル内の対応するwlevs:adapter
要素のid
属性と一致している必要があります。
<ha:ha-correlating-adapter> <name>myCorrelatingAdapter</name> <window-length>15000</window-length> <warm-up-window-length units="minutes">6</warm-up-window-length> </ha:ha-correlating-adapter>
表17-14は、子要素を説明しています。
表17-14 子要素
子要素 | 説明 |
---|---|
|
フェイルオーバー後に相関関係が再起動される速さを決定するために使用される、遅延タイムアウトをミリ秒単位で指定します。 デフォルト: 0ミリ秒。 |
|
以前に失敗したセカンダリの再起動後または新しいセカンダリが
デフォルト: 詳細は、適切なwarm-up-window-length時間の選択を参照してください。 |
window-length |
イベントの保存されたバッファの長さ(ミリ秒単位)。 |
trimming-interval |
セカンダリ・バッファからイベントをトリミングする必要のある間隔。単位は |
heartbeat |
このアダプタにおけるハートビート・タイムアウトの値。ハートビートは、このアダプタでイベントが生成されずに |
batch-size |
イベント・タイムスタンプをセカンダリに送信するときのバッチ・サイズ(イベント数単位)。デフォルトでは、バッチ処理は無効です。 |