| Oracle® Complex Event Processing開発者ガイド 11g リリース1 (11.1.1.4.0) for Eclipse B61654-02 |
|
 前 |
 次 |
この章では、Oracle CEPアプリケーションを増加するイベント・ロードに従ってスケール可能にするために使用するOracle CEPコンポーネントとデザイン・パターンについて説明します。
特定のスケーラビリティ・オプションを実行する方法の詳細は、第23章「スケーラビリティの構成」を参照してください。
Oracle CEPは、増加するイベント・ロードに従ってアプリケーションをスケールするためのオプションを提供します。
一般的に、イベントの到着時またはイベント処理ネットワーク(EPN)内で、またはその両方で入力イベント・ストリームをパーティション化し、イベントの並列処理ができるようにアプリケーションを設計できます。
イベント処理順序のできるだけ早い段階でスケーラビリティと並列処理を実行する必要があります。たとえば、通常、アプリケーションが依存する低ボリュームイベント、高価値のイベントを抽出するために、高ボリュームと低ボリュームのイベントを並列処理します。
Oracle CEPは、22.2項「スケーラビリティ・コンポーネント」の説明に従って使用できる、様々なスケーラビリティ・コンポーネントを提供します。
Oracle CEPでは、Oracle CEPアプリケーションのスケーラビリティを向上させるために使用する次のコンポーネントを提供します。
A com.bea.wlevs.channel.EventPartitionerは、図22-1に示すように、出力イベント・シンク間でチャネルのイベントパーティション化するメカニズムを提供します。
この項では次について説明します:
詳細は、23.1項「チャネルEventPartitionerでのスケーラビリティの構成」を参照してください。
Oracle CEPでは、チャネルで使用するよう構成可能な、デフォルトのイベント・プロパティ・ベースのEventPartitionerを提供しています。
デフォルトのEventPartitionerを使用するようチャネルを構成する場合、チャネルがイベントをパーティション化するイベント・プロパティ名を指定します。デフォルトのEventPartitionerでは、イベント・プロパティ値のObject.hashCode()を内部ハッシュ関数への入力として使用し、ハッシュ・キーを計算します。hashkey % number-of-listenersはイベントを受信するリスナーの計算に使用されます。このアルゴリズムは、新規アイテムを配置するバケットを計算する、HashMapで使用するものと同じアルゴリズムに基づいています。実際には、同じイベント・プロパティ値のイベントは、同じリスナーに送信されます。
|
注意: デフォルトのイベント・プロパティ・ベースのEventPartitionerでは、ラウンド・ロビン方式でディスパッチされません。 |
オプションで、チャネルのリスナーへのイベントのディスパッチ方法をカスタマイズするのではなく、独自のイベント・パーティショナ・インスタンスを作成し、チャネルで使用するよう構成することができます。
詳細は、次を参照してください:
イベント・パーティショナ・チャネルを使用する場合、ロード・バランシングを使用するには、各リスナーが同じである必要があります。
使用しない場合は、リスナーは同一でなくてもかまいません。
デフォルトでは、Oracle CEPサーバーは、デプロイメントの際に各イベント・パーティショナを初期化し、EventPartitionerメソッドactivateConfigurationが ActivatableBean.afterConfigurationActiveの前、およびEventPartitionerクラスのpartitionメソッドの起動前に起動することによる再デプロイメントの際にはイベント・パーティショナを再初期化します。
表22-1では、イベント・パーティショナ・チャネルで使用可能なスレッド・オプションが一覧表示されています。
表22-1 イベント・パーティショナ・チャネルのスレッド・オプション
| スレッド割当先 | 説明 | 使用するタイミング |
|---|---|---|
|
チャネル |
|
外部メッセージ形式の内部イベント形式への変換が容易である場合、通常は適用されます。 マルチスレッドをチャネル粒度で制御します。ボリュームが異なるため、一部のチャネルでは他のチャネルより必要なスレッド数が多くなる場合があります。 |
|
アダプタ |
|
外部メッセージ形式の内部イベント形式への変換が難しい場合、通常は推奨されます。 この手法は、アダプタがマルチスレッドであり、インバウンド・イベント・レートが高く、複数スレッドをインバウンド処理のスケールに使用できない場合にアダプタがボトルネックになる場合に最適です。 |
|
注意: どちらの手法でも、イベント順序は保証されません。複数スレッドは随時使用されます。 |
イベント・パーティショナを使用するようにチャネルを構成する場合、次の制限事項を考慮します。
イベント・パーティショナでチャネルを構成した場合、バッチ処理はサポートされていません。
詳細は、9.1.6項「バッチ処理チャネル」を参照してください。
com.oracle.cep.cluster.hagroups.ActiveActiveGroupBeanを使用して、ActiveActiveGroupBeanで作成された通知グループによって、Oracle CEPアプリケーションの受信JMSストリームをパーティション化できます。
例22-1で示すように、ActiveActiveGroupBeanをEPNアセンブリ・ファイルに追加します。
例22-1 ActiveActiveGroupBeanのbean要素
<bean id="clusterAdapter" class="com.oracle.cep.cluster.hagroups.ActiveActiveGroupBean"> </bean>
デフォルトでは、ActiveActiveGroupBeanは次の名前の通知グループを作成します。
ActiveActiveGroupBean_X
Xは文字列です。
実行時に、ActiveActiveGroupBeanは、Oracle CEPサーバーに定義された既存のグループをスキャンし、次のデフォルトのパターン一致を適用します。
ActiveActiveGroupBean_\\w+
一致が見つかったら、その名前の通知グループを作成します。
オプションで、23.2.3項「ActiveActiveGroupBeanグループ・パターン一致の構成方法」の説明に従って、独自のクラスタ・グループ・パターン一致を定義できます。
この項では次について説明します:
22.2.2.1項「高可用性なしのActiveActiveGroupBeanを使用したOracle CEPアプリケーションのスケーラビリティ」
22.2.2.2項「高可用性のあるActiveActiveGroupBeanを使用したOracle CEPアプリケーションのスケーラビリティ」
詳細は、次を参照してください:
ActiveActiveGroupBeanを使用して、高可用性に対して構成されていないOracle CEPアプリケーション内のセレクタによって、受信JMSイベント・ストリームをパーティション化できます。
図22-2で示すように、マルチサーバー・ドメインを考慮してください。
このスケーラビリティ・シナリオでは、各サーバー(ホスト1のActiveActiveGroupBean_group1、ホスト2のActiveActiveGroupBean_group2など)のOracle CEPサーバーconfig.xmlでクラスタ・グループを定義し、Oracle CEPアプリケーションにActiveActiveGroupBeanのインスタンスを追加して、これらのクラスタ・グループに基づく通知グループを定義します。
各通知グループは、異なるJMSセレクタにバインドされています。Oracle CEPアプリケーションにあるコンポーネント構成ファイルの構成は、例22-2で示すように、jms-adapterの構成と同じです。
例22-2 共通jms-adapterセレクタの定義
<jms-adapter>
<message-selector>${CONDITION}</message-selector>
<bindings>
<group-binding group-id="ActiveActiveGroupBean_group1">
<param id="CONDITION">acctid > 400</param>
</group-binding>
<group-binding group-id="ActiveActiveGroupBean_group2">
<param id="CONDITION">acctid BETWEEN 301 AND 400</param>
</group-binding>
<group-binding group-id="ActiveActiveGroupBean_group3">
<param id="CONDITION">acctid BETWEEN 201 AND 300</param>
</group-binding>
<group-binding group-id="ActiveActiveGroupBean_group4">
<param id="CONDITION">acctid <= 200</param>
</group-binding>
</bindings>
</jms-adapter>
実行時に、各Oracle CEPサーバーにある各Oracle CEPアプリケーション・インスタンスのActiveActiveGroupBeanインスタンスは、ActiveActiveGroupBean_クラスタ・グループを検索し、それに基づいて通信グループを作成します。その後、Oracle CEPアプリケーション自体は、その通知グループと一致するgroup-idに対応するmessage-selectorに構成します。これにより、App1の各インスタンスが同時にメッセージの合計数のサブセットを処理するようにJMSトピックはパーティション化されます。
詳細は、23.2.1項「Oracle CEP高可用性なしのJMSアプリケーションでスケーラビリティを構成する方法」を参照してください。
セレクタによる受信JMSイベント・ストリームのパーティション化に加えて、ActiveActiveGroupBeanを使用して、単一の高可用性のある単位として2つ以上のOracle CEPサーバーを構成できます。
図22-3で示すように、Oracle CEP高可用性アプリケーションがデプロイされたマルチサーバー・ドメインを考慮してください。
このシナリオでは、ホスト1およびホスト2に同じActiveActiveGroupBean_クラスタ・グループ(ActiveActiveGroupBean_group1)を作成し、ホスト3およびホスト4に同じActiveActiveGroupBean_クラスタ・グループ(ActiveActiveGroupBean_group2)を作成します。
実行時に、各Oracle CEPサーバーにある各Oracle CEPアプリケーション・インスタンスのActiveActiveGroupBeanインスタンスは、ActiveActiveGroupBean_クラスタ・グループを検索し、それに基づいて通信グループを作成します。ホスト1およびホスト2両方が1つの通知グループ(ActiveActiveGroupBean_group1)に属し、ホスト3およびホスト4両方が別の通信グループ(ActiveActiveGroupBean_group2)に属します。
各Oracle CEPアプリケーション自体は、通知グループと一致するgroup-idに対応するmessage-selectorに構成します。これにより、App1の各インスタンスが同時にメッセージの合計数のサブセットを処理するようにJMSトピックはパーティション化されます。
2つ以上のOracle CEPサーバーが同じ通知グループに属する場合、ActiveActiveGroupBeanによって、各通信グループのプライマリ・サーバ-のみがイベントを出力するようにします。特定の通知グループ内でプライマリ・サーバーが停止した場合、Oracle CEP高可用性フェイルオーバーが発生し、その通知グループのいずれかのセカンダリ・サーバーが新しいプライマリ・サーバーとして宣言され、構成したOracle CEP高可用性のサービス品質に応じてイベントの出力を再開します。
詳細は、23.2.2項「Oracle CEP高可用性のあるJMSアプリケーションでスケーラビリティを構成する方法」を参照してください。
