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