| Oracle® Fusion Middleware Oracle Event Processingアプリケーションの開発 12c リリース1 (12.1.3) E54312-04 |
|
 前へ |
 次へ |
Oracle Event Processingアプリケーションは常にストリーミング・データを監視するため、高可用性が不可欠です。Oracle Event Processingは、アプリケーション設計パターンと高可用性アダプタによって、アプリケーションのバックアップおよびフェイルオーバー処理の能力を強化します。
この章の内容は次のとおりです。
Oracle Event Processingの高可用性オプションは、Oracle Coherenceに依存します。Oracle Coherenceを使用せずにOracle Event Processingの高可用性オプションを実装することはできません。
パフォーマンスのチューニングを検討する場合、Oracle Event Processingアプリケーションに加えて必ずOracle Coherenceの構成を評価します。
詳細は、次を参照してください。
『Oracle Event Processingの管理』のOracle Coherenceに関する項
『Oracle Coherenceでのアプリケーションの開発』のOracle Coherenceの構成に関する項
Oracle Event Processingは、アクティブ・アクティブ高可用性アーキテクチャをサポートします。この方法には、高パフォーマンス、簡素性、およびフェイルオーバー時間の短縮という利点があり、データやサービスの障害が発生する可能性やその影響が緩和されます。
高可用性アプリケーションは、マルチサーバー・ドメインで稼働している複数のOracle Event Processingサーバーのグループにデプロイします。Oracle Event Processingは、グループ内の1つのサーバーをアクティブ・プライマリ・サーバーとして選択します。他のサーバーは、アクティブ・セカンダリ・サーバーとなります。
プライマリ・サーバーおよびセカンダリ・サーバーは、同一の入力イベントを受信するように構成され、それらを並列に処理しますが、プライマリ・サーバーのみがOracle Event Processingアプリケーション・クライアントにイベントを出力します。選択したサービス品質に依存して、セカンダリ・サーバーはインメモリー・キューを使用してそのような出力イベントをバッファリングし、プライマリ・サーバーは、プライマリ・サーバーが出力済のイベントを使用してセカンダリ・サーバーを最新に保ちます。
図17-1に、アクティブ・サーバー1つとプライマリ・サーバー2つの一般的な構成を示します。
図17-1 Oracle Event Processingの高可用性: プライマリ・サーバーおよびセカンダリ・サーバー
図17-2は、Oracle Event Processingの高可用性ライフサイクルの状態図を示します。この図では、状態名(SECONDARY、BECOMING_PRIMARYおよびPRIMARY)はOracle Event Processingの高可用性アダプタのRuntimeMBeanメソッドのgetStateの戻り値に対応します。このような状態はOracle Event Processing専用です。高可用性アダプタの詳細は、「高可用性入力アダプタ」を参照してください。
初期プライマリ・サーバーを指定することはできません。初期状態では、マルチサーバー・ドメインで起動する第1サーバーがプライマリになるため、特定の順序でサーバーを起動することによって、プライマリの選択に影響を与えることができます。稼働中の特定のサーバーを強制的にプライマリにすることはできません。プライマリが失敗するとバックアップが機能し、現在のプライマリがフェイルオーバーの起動に失敗しないかぎり、二度と自動的にプライマリになりません。
通常、セカンダリ・サーバーに障害が発生しても図17-3に示すようにOracle Event Processingアプリケーションの動作には影響はありません。選択するサービス品質に関係なくイベントの欠落や重複は発生しません。
プライマリ・サーバーで障害が発生した場合、図17-4で示すように、選択するサービス品質に応じて、Oracle Event Processingはイベントの欠落や重複を発生させる可能性があるフェイルオーバーを実行します。
フェイルオーバー中、Oracle Event Processingは新しいプライマリおよびSECONDARY状態からBECOMING_PRIMARY状態への新しいプライマリの遷移を選択します。選択するサービス品質に依存して、新しいプライマリは構成可能な準備状況のしきい値を満たすまでPRIMARY状態に遷移しません。詳細は、サービス品質オプションの選択にある特定のサービス品質オプションを参照してください。
新しいOracle Event ProcessingサーバーがOracle Event Processing高可用性マルチサーバー・ドメインに追加される場合、または既存の障害が発生したサーバーが再起動する場合、サーバーは、サーバーにデプロイされたすべてのアプリケーションが完全に結合するまで、Oracle Event Processing高可用性デプロイメントと通知グループを完全には結合しません。いつ完全に結合できるかは、アプリケーションの種類によって異なります。
アプリケーションが完全に同一の出力イベントのシーケンスを既存のセカンダリとして出力する必要がある場合(タイプ1アプリケーション)、一部の有限の期間(warm-up-window-lengthの期間)の入力ストリームを処理することによって、アプリケーションはその内部状態を再構築できます。このwarm-up-window-lengthの時間によって、アプリケーションが完全にOracle Event Processing高可用性デプロイメントと通知グループを結合するのにかかる最短時間が決定されます。
アプリケーションが完全に同一の出力イベントのシーケンスを既存のセカンダリとして出力する必要がない場合(タイプ2アプリケーション)、warm-up-window-lengthの時間はかからず、アプリケーションはデプロイされたときにOracle Event Processing高可用性デプロイメントと通知グループを完全に結合します。
詳細は、適切なwarm-up-window-length時間の選択を参照してください。
マルチサーバー・ドメイン内のすべてのサーバーは、同一のデプロイメント・グループに属します。デプロイメント・グループは、アプリケーションをデプロイする対象のグループです。Oracle Event Processingの高可用性のために同一のアプリケーションをグループ内のすべてのサーバーにデプロイする必要があります。
デフォルトでは、マルチサーバー・ドメイン内のすべてのサーバーも同一の通知グループに属します。サーバーは、サーバーで障害が発生したとき(およびグループを終了したとき)または動作を再開したとき(およびグループを再結合したとき)を示すメンバーシップ通知用の通知グループとともに、プライマリからの同期通知用の通知グループをリスニングします。
Oracle Event Processingの高可用性アプリケーションのスケールを変更する必要がある場合、ActiveActiveGroupBeanを使用して、すべてのサーバー(プライマリおよびセカンダリ)に広がる単一のデプロイメント・グループの利点を保持する一方で、プライマリ・サーバー・ユニットとして2つ以上のサーバーを機能させることを許可する通知グループを定義します。
マルチサーバー・ドメインのデプロイメント・グループを作成するためには、Oracle Coherenceベースのクラスタリングを使用する必要があります。デフォルト・グループまたはカスタム・グループのいずれかを使用できます。
詳細は、次を参照してください。
『Oracle Event Processingの管理』のカスタム・デプロイメント・グループに関する項。
Oracle Event Processing高可用性を実装するには、高可用性入力アダプタ(オプション)と、高可用性出力アダプタ(必須)をEPNに追加します。
高可用性入力アダプタ
プライマリ・サーバーのオプションの高可用性入力アダプタは、各セカンダリ・サーバーの対応する高可用性入力アダプタと通信し、イベント・タイムスタンプを正規化します。Oracle Event Processingの高可用性によって、高可用性入力アダプタの1つの種類が提供されます。
高可用性入力アダプタを参照してください。
高可用性出力アダプタ
アプリケーションに高可用性の機能を実装するには、EPNで各出力アダプタの前に高可用性出力アダプタを配置します。プライマリ・サーバーの高可用性出力アダプタは、Oracle Event Processingアプリケーションをダウンストリーム・クライアントに接続する出力ストリームにイベントを出力します。
プライマリの高可用性出力アダプタも対応する各セカンダリの高可用性出力アダプタと通信を行い、選択する高可用性のサービス品質に依存して、セカンダリ出力アダプタに出力イベントのインメモリー・キューをトリミングするように命令することができます。
高可用性出力アダプタの詳細は、バッファリング出力アダプタ、ブロードキャスト出力アダプタおよび相関出力アダプタを参照してください。どの出力アダプタを選択するかは、選択する高可用性のサービス品質によって決定されます。サービス品質オプションの選択を参照してください。
図17-5は、定位置にすべての実行可能な高可用性アダプタを持つEPNを簡略化して示しています。この図ではチャネルがなくプロセッサが1つです。
各イベントはイベントの発生時点で関連付けられます。イベント・タイムスタンプを生成するには、アプリケーション・タイムスタンプとシステム・タイムスタンプの2つの方法があります(アプリケーション・タイムスタンプとシステム・タイムスタンプの詳細は、「チャネル」を参照してください)。アプリケーション時間とは、イベントがCQLプロセッサに入る前に、時間値がアプリケーションによって外部で各イベントに割り当てられることを意味します。システム時間とは、CQLプロセッサへの到着時に、時間値がOracle Event Processingによって自動的にイベントに関連付けられることを意味します。
アプリケーション時間は、通常、アプリケーションの高可用性のために必要な最善の選択です。アプリケーション時間は、Oracle Event Processingにイベントが送信される前にイベントに関連付けられるため、アクティブなプライマリおよびセカンダリのインスタンスの全体に渡って整合性があります。システム時間は、システム・クロックが同期されていないことによって、イベントに関連付けられた時間値が各インスタンスで異なる可能性があるためアプリケーションのインスタンスに異なる結果を生成させます。
CQLの問合せが時間ベースのウィンドウを使用しないアプリケーションについては、システム時間を使用しても問題ありません。イベントベースのウィンドウのみ使用するアプリケーションは、受信時間ではなくイベントを受信した順番に依存するためこの場合はシステム時間を使用できます。
時間ベースのウィンドウを使用し、外部で生成された(アプリケーション)タイムスタンプを持たないアプリケーションについては、オプションのOracle Event Processing高可用性入力アダプタを使用して、すべてのサーバーで一定の時間値を指定できます。プライマリ・サーバー上の入力アダプタ・インスタンスは、イベントがアダプタに到着した時点でイベントに時間を割り当て(ナノ秒単位)、各イベントに割り当てられた時間値をすべてのセカンダリ・サーバーに転送します。
時間値は、EPN内の任意のダウンストリーム・チャネルにイベントが到着する前に各イベントに割り当てられるため、ダウンストリーム・チャネルは、イベントのチャネル到着時に新しい時間値をイベントに割り当てないようにアプリケーションの時間を使用するように構成する必要があります。
入力イベントは、このアダプタを使用するために各イベントを一意で識別するキーを持つ必要があります。
Oracle Event Processingの高可用性入力アダプタをハートビート・イベントを送信するように構成できます。
Oracle Event Processingの高可用性入力アダプタは、すべての高可用性のサービス品質オプションに適用できます。ただし、高可用性入力アダプタはパフォーマンスのオーバーヘッドを増加するため、一部の高可用性サービス品質オプション(「シンプル・フェイルオーバー」および「バッファリングを使用するシンプル・フェイルオーバー」など)には適しません。このようなオプションでは、かわりにアプリケーション時間と何らかの着信イベント・プロパティの使用を検討します。
詳細は、次を参照してください。
Oracle Event Processingの高可用性バッファリング出力アダプタは、バッファリング型キュー・トリミング方式を実装します。バッファはストリームからの出力イベントのスライディング・ウィンドウです。ウィンドウのサイズはミリ秒単位で測定されます。
Oracle Event Processingの高可用性バッファリング出力アダプタは、シンプル・フェイルオーバーおよび高可用性のサービス品質オプションのバッファリングを使用するシンプル・フェイルオーバーに適用されます。
詳細は、次を参照してください。
Oracle Event Processingの高可用性ブロードキャスト出力アダプタは、分散型キュー・トリミング方式を実装します。アクティブ・プライマリ・インスタンスは、メッセージを通知グループ内のアクティブ・セカンダリ・インスタンスにブロードキャストし、キューのローカル表現をトリミングするタイミングを通知します。
Oracle Event Processing高可用性ブロードキャスト出力アダプタは、軽量キュー・トリミングの高可用性のサービス品質オプションに適用されます。
詳細は、次を参照してください。
Oracle Event Processingの高可用性相関出力アダプタは、通常はJMSから2つのイベント・ストリームを関連付けます。このアダプタは、イベントのインバウンド・バッファと同一イベント・ストリームのセカンド・ソースに関連付け、構成可能な時間間隔の後で相関関係付けに障害が発生する場合にバッファを出力します。関連付けられたイベントは、キューからトリミングされます。関連付けられたイベントは、順序通りに整理されると仮定されます。
Oracle Event Processingの高可用性相関出力アダプタは、JMS高可用性のサービス品質オプションを使用する正確なリカバリに適用されます。
詳細は、次を参照してください。
Oracle Event Processing高可用性アプリケーションのスケールを変更する必要がある場合は、通知グループのSpring BeanであるActiveActiveGroupBeanを使用すると、JMSアプリケーションのスケーラビリティが向上します。
ActiveActiveGroupBeanでは、すべてのサーバー(プライマリおよびセカンダリ)に広がる単一のデプロイメント・グループの利点を保持する一方で、複数のサーバーを1つの高可用性ユニットとして機能させることが可能な通知グループを定義します。
図17-6は、最も単純な構成から高可用性、そして高可能性とスケーラビリティの両方へと至る3つのOracle Event Processingアプリケーションのシナリオを示します。
大半のアプリケーションは、高可用性を持たないシングルサーバー・ドメインで起動します。この最も単純なシナリオの場合、1つのOracle Event Processingサーバーで実行されるOracle Event Processingアプリケーションが、1つの入力イベント・ストリームを処理して出力イベントを生成します。
高可用性のシナリオ: アプリケーションがOracle Event Processing高可用性オプションを使用するように構成され、2つのサーバーで構成されるマルチサーバー・ドメインのデプロイメント・グループにデプロイされて、プライマリ・サーバーのみがイベントを出力します。
高可用性とスケーラビリティのシナリオ: 高可用性アプリケーションは、通知グループを定義するためにActiveActiveGroupBeanを使用するように構成されます。各通知グループには、単一の高可用性ユニットとして機能する複数のサーバーが含まれます。このシナリオでは、各通知グループ内のプライマリ・サーバーのみがイベントを出力します。通知グループ内のプライマリ・サーバーが万一機能しなくなった場合、Oracle Event Processingの高可用性フェイルオーバーが発生し、その通知グループ内のセカンダリ・サーバーが新しいプライマリを宣言して、構成するOracle Event Processing高可用性のサービス品質でイベントの出力を再開します。
詳細は、高可用性のあるパーティション化の構成を参照してください。
欠落イベントおよび複製イベントに対するアプリケーションの許容値と、期待されるイベント・スループットに適するサービス品質オプションを選択します。プライマリ・サーバーおよびセカンダリ・サーバーのハードウェア要件は、サービス品質がより正確になるほど上がるので注意してください。
表17-1に示すサービス品質オプションのいずれかを選択できます。
|
表17-1 Oracle Event Processing高可用性のサービス品質
|
シンプル・フェイルオーバー高可用性のサービス品質は、最低のパフォーマンス・オーバーヘッド(リカバリ時間が速い)および最低のデータ整合性(フェイルオーバー時に欠落イベントと複製イベントの両方の可能性があります)によって特徴付けられます。
プライマリ・サーバーはイベントを出力し、セカンダリ・サーバーは出力イベントのバッファリングを行わないため、その出力イベントを破棄します。現在のアクティブ・プライマリで障害が発生した場合、通知されると新しいアクティブ・プライマリが選択され、出力イベントの送信を開始します。
フェイルオーバー中には、前のプライマリより前または後で稼働しているかに応じて、新しいプライマリによって多くのイベントが欠落したり複製されたりする場合があります。
フェイルオーバー・ウィンドウ中には、イベントが欠落する場合があります。たとえば、1秒当たり100個のイベントを処理してフェイルオーバーに10秒かかる場合、1000個のイベントが欠落します。
新しいプライマリ・サーバーは、ただちにPRIMARY状態に入ります。BECOMING_PRIMARY状態から新しいプライマリ・サーバーが遷移する前に満たす必要がある構成可能な準備状態のしきい値はありません。Oracle Event Processingサーバーがマルチサーバー・ドメインに再結合するとき、セカンダリとしてただちに利用可能になります。
この高可用性のサービス品質を実装するには、各出力アダプタの前に高可用性バッファリング出力アダプタを使用して(サイズがゼロのスライディング・ウィンドウを使用して)EPNを構成します。パフォーマンス・オーバーヘッドを削減するには、高可用性入力アダプタを使用せずに一部の着信イベント・プロパティを持つアプリケーション時間を使用します。
詳細は、シンプル・フェイルオーバーの構成を参照してください。
バッファリングを使用するシンプル・フェイルオーバーの高可用性のサービス品質は、低いパフォーマンス・オーバーヘッド(リカバリ時間が速い)および向上したデータ整合性(フェイルオーバー時に欠落イベントはなくても多数の複製イベントの可能性があります)によって特徴付けられます。
プライマリ・サーバーはイベントを出力し、セカンダリ・サーバーはその出力イベントをバッファリングします。現在のアクティブ・プライマリで障害が発生した場合、通知されると新しいアクティブ・プライマリが選択され、出力イベントの送信を開始します。
フェイルオーバー・ウィンドウ中には、イベントが欠落する場合があります。たとえば、1秒当たり100個のイベントを処理してフェイルオーバーに10秒かかる場合、1000個のイベントが欠落します。セカンダリのバッファが大容量の場合、多数の複製が出力される可能性があります。一方、バッファが大容量になるほどメッセージの欠落の可能性は低くなります。
Oracle Event Processingサーバーがマルチサーバー・ドメインに再結合するとき、ご使用のアプリケーションがOracle Event Processing高可用性タイプ1アプリケーションの場合(アプリケーションが既存のセカンダリと完全に同一の出力イベントのシーケンスを出力する必要があります)、セカンダリとして利用できるようになる前にOracle Event Processingの高可用性出力アダプタに構成するwarm-up-window-lengthの時間を待機する必要があります。
この高可用性のサービス品質を実装するには、各出力アダプタの前にサイズがゼロより大きいスライディング・ウィンドウを使用し、高可用性バッファリング出力アダプタを使用してEPNを構成します。パフォーマンス・オーバーヘッドを削減するには、高可用性入力アダプタを使用せずに一部の着信イベント・プロパティを持つアプリケーション時間を使用します。
詳細は、次を参照してください。
この高可用性のサービス品質は、低いパフォーマンス・オーバーヘッド(リカバリ時間が速い)および向上したデータ整合性(フェイルオーバー時に欠落イベントはなくても少数の複製イベントの可能性があります)によって特徴付けられます。
アクティブ・プライマリはセカンダリに通信し、イベントを実際に処理します。これによって、特定の時点でプライマリによって送信されていないイベントのみを含むようにセカンダリは出力イベントのバッファをトリミングできます。イベントは現在のプライマリによって送信された後でのみトリミングされるので、セカンダリによってフェイルオーバーの発生時に任意の出力イベントが欠落しないようにできます。
アクティブ・プライマリがキュー・トリミング・メッセージをアクティブ・セカンダリに送信する頻度は、次のように構成可能です。
n個のイベントごと(n>0)
これによって、フェイルオーバー時に複製された出力イベントの数を最大n個に限定します。
nミリ秒ごと(n>0)
キュー・トリミング・アダプタには、アクティブ・プライマリおよびセカンダリの間で統一的にイベントを識別する方法が必要です。お薦めの方法は、イベントを識別するためにアプリケーション時間を使用することですが、一意にイベントを識別する任意のキー値が有効です。
キュー・トリミングの利点は、出力イベントが絶対に欠落しないことです。ただし、通信の必要があるトリミング・メッセージを送信するために、アクティブ・プライマリで若干のパフォーマンス・オーバーヘッドが発生します。このオーバーヘッドは、キュー・トリミング・メッセージの頻度が高くなるほど大きくなります。
フェイルオーバー中には、新しいプライマリがBECOMING_PRIMARY状態に入り、そのイベント・キュー(セカンダリとして累積していく)がフラッシュされるまで、PRIMARY状態には遷移しません。この遷移中には、新しい入力イベントがバッファリングされ、一部の複製イベントが出力される場合があります。
Oracle Event Processingサーバーがマルチサーバー・ドメインに再結合するとき、ご使用のアプリケーションがOracle Event Processing高可用性タイプ1アプリケーションの場合(アプリケーションが既存のセカンダリと完全に同一の出力イベントのシーケンスを出力する必要があります)、セカンダリとして利用できるようになる前にOracle Event Processingの高可用性出力アダプタに構成するwarm-up-window-lengthの時間を待機する必要があります。
この高可用性のサービス品質を実装するには、各入力アダプタおよび高可用性ブロードキャスト出力アダプタの後、各出力アダプタの前に、高可用性入力アダプタを使用してEPNを構成します。
詳細は、軽量キュー・トリミングの構成を参照してください。
JMSによる正確なリカバリの高可用性のサービス品質は、高パフォーマンス・オーバーヘッド(リカバリ時間が遅い)および最大のデータ整合性(フェイルオーバー時に欠落イベントも複製イベントもありません)によって特徴付けられます。この高可用性のサービス品質は、JMSの入力アダプタおよび出力アダプタにのみ対応します。
JMS高可用性のサービス品質を使用する正確なリカバリでは、シングルサーバーのイベント・パスに伴うトランザクションの保証は重視されず、サーバーのセットからの単一の出力が重視されます。保証を達成するため、セカンダリ・サーバーは、プライマリによってパブリッシュされるイベント・ストリームにJMS経由でリスニングします。図17-7は、この着信イベント・ストリームが、セカンダリが出力キューをトリミングするために使用する信頼できるキュー・トリミング・メッセージのソースであることを示します。JMSが信頼できる転送に構成されている場合、セカンダリで確認されるイベントのストリームは、正確にプライマリによって出力されるイベントのストリームであるため、フェイルオーバーは以前のプライマリ・サーバーによって転送されないイベントを新しいプライマリ・サーバーが正確に出力することを可能にします。
フェイルオーバー中には、新しいプライマリ・サーバーがBECOMING_PRIMARY状態に入り、そのイベント・キュー(セカンダリとして累積していく)がフラッシュされるまで、PRIMARY状態には遷移しません。この遷移中には、新しい入力イベントがバッファリングされ、複製イベントは出力されません。
Oracle Event Processingサーバーがマルチサーバー・ドメインに再結合するとき、ご使用のアプリケーションがOracle Event Processing高可用性タイプ1アプリケーションの場合(アプリケーションが既存のセカンダリと完全に同一の出力イベントのシーケンスを出力する必要があります)、セカンダリ・サーバーとして利用できるようになる前にOracle Event Processingの高可用性出力アダプタに構成するwarm-up-window-lengthの時間を待機する必要があります。
JMSによる正確なリカバリの高可用性のサービス品質を実装するには、各入力アダプタおよび高可用性相関出力アダプタの後、各出力アダプタの前に、高可用性入力アダプタを使用してEPNを構成します。
スケーラビリティを向上するため、高可用性のサービス品質を持つクラスタ・グループBeanも使用できます。
詳細は、次を参照してください。
高可用性のためのアプリケーションを設計する際には、ここで説明する主なユース・ケース、設計パターン、およびOracle CQL問合せの制約を考慮してください。
Oracle Event Processingの高可用性を宣言的に実装できますが、選択する高可用性のサービス品質から完全に利点を引き出すには、Oracle Event ProcessingアプリケーションがOracle Event Processingの提供する高可用性オプションを利用するように設計する必要があります。
高可用性オプションは様々なOracle Event Processingアプリケーション設計に適応させることができますが、通常、Oracle Event Processingの高可用性は次のユース・ケースを想定して設計されています。
アプリケーションは1つ以上の外部システムから入力イベントを受信します。
外部システムは、パブリッシュ/サブスクライブ・スタイルのシステムで、複数のアプリケーションのインスタンスが同時に接続し、同一のメッセージのストリームを受信することを可能にします。
アプリケーションは、複数のアプリケーションのコピーが同時に実行される場合、競合が発生しないように外部のシステムを更新しません。
アプリケーションは、出力イベントを外部のダウンストリーム・システムに送信します。複数のアプリケーションのインスタンスは、一度にメッセージを送信できるアプリケーションのインスタンスは1つのみですが、ダウンストリーム・システムに同時に接続できます。
このような制約では、次の異なるケースが注目されます。
アプリケーションは、障害の発生時に、一部の出力イベントのダウンストリーム・システムへの送信をスキップすることが許可されます。複製も許可されます。高可用性のサービス品質オプションとしてシンプル・フェイルオーバーを使用します。
アプリケーションは、複製イベントをダウンストリーム・システムに送信することを許可されますが、障害の発生時に任意のイベントをスキップすることは禁止されます。高可用性のサービス品質オプションとして、バッファリングを使用するシンプル・フェイルオーバーと軽量キュー・トリミングを使用します。
アプリケーションは、障害の発生中にイベントが送信できない短い一時停止を法として、障害の発生時に完全に同一のメッセージ/イベントのストリームを送信する必要があります。高可用性のサービス品質オプションとしてJMSによる正確なリカバリを使用します。
Oracle Event Processingの高可用性オプションを使用するOracle Event Processingアプリケーションを設計するときには、次の設計パターンを順守します。
Oracle Event Processingシステムは、該当する少数のイベントを生成するために問い合せられる多数の生の入力イベントを受信します。通常、該当するイベントは数が少なく、より価値があるという理由から、それらを保存するのが合理的です。
Oracle Event Processingシステムによって、イベントのウィンドウを問い合せることができます。きわめて大きいウィンドウを使用してシステムを構築することは魅力的ですが、障害の発生時に再構築の必要がある状態が増加します。通常、このような技術の高可用性ファシリティを活用するために、長期状態は分散型キャッシュやデータベースのような安定したストレージに保存されるとみなす方が良さそうです。
新しいOracle Event Processingサーバーが高可用性マルチサーバー・ドメインに追加される場合、または既存の障害が発生したサーバーが再起動する場合、サーバーは、サーバーにデプロイされたすべてのアプリケーションが完全に結合するまで、Oracle Event Processing高可用性デプロイメントと通知グループを完全には結合しません。いつ完全に結合するかは、アプリケーションの種類によって異なります。
Oracle Event Processingの高可用性アプリケーションは、表17-2で示すように、タイプ1またはタイプ2のアプリケーションとして記述されます。
|
表17-2 Oracle Event Processingの高可用性アプリケーションの種類
|
詳細は、高可用性マルチサーバー・ドメインの再結合を参照してください。
タイプ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アプリケーションが高可用性ブロードキャスト出力アダプタを使用する場合、一意のアプリケーション専用キーまたはアプリケーション時間のようなモノトニックなキーを使用することによって、イベントをトリミングできます。アプリケーション時間を使用してイベントをトリミングすることは、出力イベントが生成されない可能性があるアプリケーションにおいて、堅牢性が増すとともに不具合への脆弱性が低下するためお薦めです。
詳細は、次を参照してください。
タイプ2アプリケーションは、高可用性デプロイメントおよび通知グループに完全に結合すると、新しいセカンダリ・サーバーが既存のセカンダリ・サーバーと同一の出力イベントのシーケンスを生成するように要求しません。新しいクラスタ・メンバーが、入力イベントの処理を開始する時点に関して有効な出力イベントを生成するように要求するのみです。
タイプ2アプリケーションはwarm-up-window-length期間を要求しません。
大半のアプリケーションは、タイプ2アプリケーションです。アプリケーションが任意の時点で(プライマリOracle Event Processingサーバー上で)起動し、その時点で入力ストリームからイベントの処理を開始して、有効な出力イベントを生成することが多くあります。アプリケーションの起動中は入力ストリームが一時停止されず、入力イベントは常に生成されて受信します。多くの場合、若干異なるタイミングで同じ処理を実行するセカンダリ・ステージでも、アプリケーションの観点から見れば有効な出力イベントが生成されると想定できますが、タイミングのわずかな違いのために、プライマリ・サーバーによって生成されるイベントと同一とはかぎりません。
たとえば、金融市場が開いている間のみ実行される金融アプリケーションは、次のようにタイプ2のアプリケーションとして動作できます。すべてのサーバーは市場が開く前に起動し、市場データ・ストリームにおける同じ時点で着信イベントの処理を開始します。障害に備えるために複数のセカンダリ・サーバーを実行できますが、市場が開いている間セカンダリ・サーバーの数が十分な場合には、障害が発生するセカンダリ・サーバーを再起動したり、セカンダリ・サーバーを追加しないでください。これは、どのセカンダリ・サーバーも状態をリカバリする必要がないためです。
異なるサーバー上でアプリケーションの2つのコピーを実行でき、そのコピーは共有されたキャッシュやデータベースで競合しません。外部のリレーション(キャッシュや表など)を使用する場合、サーバーがクラスタに再結合するとき、アプリケーションは以前と同一のキャッシュや表にアクセスします。アプリケーションは同一の外部リレーションに再結合する必要があります。データが必ず同一のデータ・ソースから抽出されるように、サーバー上のデータ・ソースは変更しないでください。
多くの高可用性ソリューションでは、異なるサーバー間でイベントの関連付けが必要です。イベントを関連付けるには、イベントをユニバーサルに識別可能にする必要があります。イベントをユニバーサルに識別可能にする最適な方法は、外部情報、可能であればタイムスタンプを使用してイベントにシードすることです。詳細は、アプリケーション時間の優先を参照してください。
プライマリおよびセカンダリのサーバーは、キュー・トリミングおよび同等ベースのイベント識別子(継続的に増加しない、モノトニックではないイベント識別子)を使用する高可用性のサービス品質オプションを選択する場合、同一の出力イベントを完全に同一の順序で生成する必要があります。異なる順序で出力イベントを生成すると、障害の発生時に出力イベントが欠落したり、出力イベントが不要に重複したりする可能性があります。
図17-8で示される出力イベント・ストリームを検討してください。プライマリ・サーバーは、出力イベントa、b、およびcを持ちます。イベントcを出力後、プライマリはセカンダリにキュー・トリミング・メッセージを送信します。
セカンダリ・サーバーは、イベントc自体を含むイベントcの前に生成されたキュー内のすべてのイベントをトリミングします。この場合、イベント・セットは{a, b, e, d, c}となり、これらはプライマリ・サーバーがイベントdおよびeをまだ出力していないため適切ではありません。イベントcのトリミング・メッセージの処理後にフェイルオーバーが発生する場合、イベントは失われます。
複数のインスタンス上で実行される場合、アプリケーションが同一の順序でイベントを生成するためには、確定している必要があります。アプリケーションは次の要素に依存させないでください。
異なるマシン上に異なる結果を返す可能性がある乱数ジェネレータ。
System.getTimeMillisまたはSystem.nanoTimeなどのメソッド。これらはシステム・クロックが同期されていないため、異なるマシン上で異なる結果を返す可能性があります。
スレッド・スケジューリング・アルゴリズムは時間への依存度がきわめて高いため、マルチスレッドはアプリケーション内で非確定的なソースとなります。異なるスレッドは、異なるマシン上および異なる時間でスケジューリングできます。
たとえば、複数のスレッドが高可用性アダプタに並列にイベントを送信するEPNを作成しないでください。そのようなチャネルが高可用性アダプタのイベント・ソースの場合、イベントが異なるスレッドごとに並列にアダプタに送信されるようになり、イベント順序を非確定的にすることができる可能性があります。また、複数のスレッドを持つメディエータ(JMSサーバー)はイベントを送信しないでください。このメディエータはイベント・ソースとして機能します。
避ける必要があるチャネル構成に関する詳細は、次を参照してください。
『Oracle Event Processingのカスタマイズ』の構成ファイルの要素およびプロパティに関する項
Oracle Event Processingのスキーマ・リファレンスのmax-threads
Oracle Event Processingの高可用性を使用するとき、Oracle CQLの問合せの使用方法がすべてサポートされるわけではありません。この制約を解決するには、Oracle CQLの問合せを再定義する必要があります。詳細は、「Oracle CQLの問合せの制約」を参照してください。
Oracle Event Processingシステムで高可用性のパフォーマンスが最も高くなるのは、サーバーが調整を必要とせずに実行できるときです。通常、共有状態が存在せず、ダウンストリーム・システムが複製を許容する場合にこれは実行できます。高可用性のレベルを上げることは、ダウンストリーム・システムが確認するイベント・ストリームの忠実度を上げることを目標としますが、忠実度を上げることはパフォーマンスのペナルティを伴います。
セカンダリ・サーバーがマルチサーバー・ドメインに再結合するときには、現在のプライマリとアクティブ・セカンダリが一致するようにアプリケーション状態を再構築する時間が必要です。適切なwarm-up-window-length時間の選択を参照してください。
マルチサーバー・ドメインに再結合した後に、セカンダリ・サーバーがアクティブ・セカンダリ・サーバーとして利用可能になるためにかかる時間が、要求するアクティブ・セカンダリ・サーバーの数における要因となります。
準備完了前にセカンダリが新しいプライマリ・サーバーになることを宣言される場合、セカンダリ・サーバーは例外をスローします。
高可用性アプリケーションでは、Oracle CQL問合せに次のような制約があります。Oracle CQLと、この項で取り上げているトピックの詳細は、『Oracle Event Processing Oracle CQL言語リファレンス』の問合せに関する項を参照してください。
タイプ1アプリケーションでは、既存のセカンダリと完全に同一の出力イベントのシーケンスを生成する必要があり、すべての範囲ベースのOracle CQLウィンドウは、warm-up-window-lengthの時間よりも短くする必要があります。「適切なwarm-up-window-length時間の選択」を参照してください。
チャネルは、Oracle CQLの問合せが範囲ベースのウィンドウを含む場合にアプリケーション時間を使用する必要があります。アプリケーション時間の優先を参照してください。
タイプ1アプリケーションでは、既存のセカンダリと完全に同一の出力イベントのシーケンスを生成する必要があり、すべてのタプルベースのウィンドウは、時間によって条件が付けられる必要があります。「適切なwarm-up-window-length時間の選択」を参照してください。
パーティションを再構築できない場合があるため、パーティション化されたウィンドウは避けてください。パーティション化されたウィンドウを使用する場合、Oracle Event Processingサーバーの時間がパーティションを再構築するのに十分な長さとなるようにwarm-up-window-lengthを構成します。「適切なwarm-up-window-length時間の選択」を参照してください。
マルチサーバー・ドメインに結合する新しいステージが、既存のステージと完全に同一の出力イベントを生成すると想定される場合、Oracle CQL問合せでスライディング・ウィンドウは使用しないでください。高可用性マルチサーバー・ドメインの再結合を参照してください。
Oracle CQLの問合せが非イベント検出のDURATION句を含む場合、アプリケーション時間を使用する必要があります。「アプリケーション時間の優先」を参照してください。
Oracle Event Processingでは、各イベントはイベントの発生時点で関連付けられます。Oracle CQLは次の2種類を認識します。
アプリケーション時間: イベントがOracle CQLプロセッサに入る前に、アプリケーションによってOracle CQLの外で各イベントに割り当てられた時間値です。
システム時間: System.nanoTime()を必ずコールすることによって、Oracle CQLプロセッサに到着時にイベントに関連付けられる時間値です。
アプリケーション時間は、通常、アプリケーションの高可用性のために必要な最善の選択です。アプリケーション時間は、ダウンストリームにイベントが送信される前にイベントに関連付けられるため、アクティブなプライマリおよびセカンダリ・サーバーの全体に渡って整合性があります。
システム時間は、システム・クロックが同期されていないことによって、イベントに関連付けられた時間値が各サーバーで異なる可能性があるためアプリケーションのインスタンスに異なる結果を生成させます。Oracle CQLの問合せが時間ベースのウィンドウを使用しない場合、アプリケーションにシステム時間を使用できます。イベントベースのウィンドウのみ使用するアプリケーションは、受信時間ではなくイベントを受信した順番に依存するためこの場合はシステム時間を使用できます。
時間ベースのウィンドウを使用するOracle CQLの問合せに関してシステム時間を使用する必要がある場合は、特別なOracle Event Processingの高可用性入力アダプタを使用する必要があります。このアダプタは、着信イベントを補足し、プライマリおよびセカンダリ・サーバーのインスタンス全体に渡る統一的な時間を割り当てます。
アセンブリおよびコンポーネント構成ファイルで、Oracle Event Processingの高可用性のサービス品質を構成します。
Oracle Event Processingの高可用性の構成に変更を加えた後は、Oracle Event Processingアプリケーションを再デプロイする必要があります。
この項の内容は次のとおりです。
スライディング・ウィンドウのサイズをゼロ(0)に設定して、Oracle Event Processing高可用性バッファリング出力アダプタを使用してシンプル・フェイルオーバーを構成します。
この手順は、図17-9で示すEPNの例から始まり、シンプル・フェイルオーバー用に構成するために必要なコンポーネントを加えていきます。
シンプル・フェイルオーバーの構成:
スライディング・ウィンドウのサイズをゼロ(0)より大きく設定して、Oracle Event Processingバッファリング出力アダプタを使用してシンプル・フェイルオーバーを構成します。
この手順は、図17-10で示すEPNの例から始まり、バッファリングを使用するシンプル・フェイルオーバー用に構成するために必要なコンポーネントを加えていきます。
バッファリングを使用するシンプル・フェイルオーバーの構成:
Oracle Event Processingの高可用性入力アダプタおよびブロードキャスト出力アダプタを使用して、軽量キュー・トリミングを構成します。
この手順は、図17-11で示すEPNの例から始まり、軽量キュー・トリミング用に構成するために必要なコンポーネントを加えていきます。
軽量キュー・トリミングの構成:
Oracle Event Processingの高可用性入力アダプタおよび相関出力アダプタを使用して、JMSによる正確なリカバリを構成します。
この手順では、図17-12が示すEPNの例を作成する方法を説明します。このOracle Event Processingの高可用性のサービス品質に関する詳細は、「JMSによる正確なリカバリ」を参照してください。
注:
正確なリカバリのためにJMSアダプタによって使用されるJMS宛先は、キューではなくトピックである必要があります。
JMSによる正確なリカバリの構成
チャネルやプロセッサなどのEPN内の他のコンポーネントを構成する方法と同様に、EPNアセンブリ・ファイルおよびコンポーネント構成ファイルでOracle Event Processingの高可用性アダプタを構成します。
Oracle Event Processingの高可用性の構成に変更を加えた後は、Oracle Event Processingアプリケーションを再デプロイする必要があります。OSGiバンドルのデプロイを参照してください。
この項の内容は次のとおりです。
Oracle Event Processingの高可用性ブロードキャスト入力アダプタは、BroadcastInputAdapterインタフェースによって実装されます。
アセンブリ・ファイル
Oracle Event Processingの高可用性入力アダプタを宣言するためのルート要素は、provider要素をha-inboundに設定したwlevs:adapterです。入力アダプタでOracle Event Processingの高可用性入力アダプタの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の子要素
|
表17-4に、サポートされているインスタンス・プロパティと、その名前属性および値属性を示します。
|
表17-4 高可用性入力アダプタのインスタンス・プロパティ
|
構成ファイル
Oracle Event Processingの高可用性入力アダプタの構成用ルート要素は、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 子要素
|
Oracle Event Processingの高可用性バッファリング出力アダプタは、SlidingWindowQueueTrimmingAdapterインタフェースによって実装されます。
アセンブリ・ファイル
Oracle Event Processingの高可用性バッファリング出力アダプタを宣言するためのルート要素は、次の例で示すように、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 子要素
|
表17-7は、インスタンス・プロパティを一覧表示しています。
|
表17-7 インスタンス・プロパティ
|
構成ファイル
Oracle Event Processingの高可用性バッファリング出力アダプタの構成用ルート要素は、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 Event Processingの高可用性バッファリング出力アダプタに構成できるha-buffering-adapterの追加子要素を説明します。
|
表17-8 子要素
|
Oracle Event Processingの高可用性ブロードキャスト出力アダプタは、GroupBroadcastQueueTrimmingAdapterクラスによって実装されます。
アセンブリ・ファイル
Oracle Event Processingの高可用性ブロードキャスト出力アダプタを宣言するためのルート要素は、次に示すように、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 子要素
|
表17-10は、インスタンス・プロパティを一覧表示しています。
|
表17-10 インスタンス・プロパティ
|
構成ファイル
Oracle Event Processingの高可用性ブロードキャスト出力アダプタの構成用ルート要素は、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 子要素
|
Oracle Event Processingの高可用性相関出力アダプタは、CorrelatedQueueTrimmingAdapterインタフェースによって実装されます。
アセンブリ・ファイル
Oracle Event Processingの高可用性相関出力アダプタを宣言するためのルート要素は、次に示すように、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 子要素
|
表17-13は、インスタンス・プロパティを一覧表示しています。
|
表17-13 インスタンス・プロパティ
|
構成ファイル
Oracle Event Processingの高可用性相関出力アダプタの構成用ルート要素は、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 子要素
|
