Oracle Stream Analyticsでは、HTTPサーブレットおよび静的リソースをデプロイするJava WebサーバーとしてJettyがサポートされています。Jetty機能をOracle Stream Analyticsとともに使用するように構成できます。構成できる機能は、ネットワークI/O、ワーク・マネージャ、およびJettyサーバー・インスタンスの構成です。
Oracle Stream AnalyticsのJettyサポートは、バージョン1.2のOSGi HTTPサービスに基づいています。OSGi HTTPサービスAPIによって、実行時および静的リソースを持つオブジェクトを動的に登録および登録解除することが可能になります。この仕様には、JavaサーブレットAPI 2.1以上が必要です。http://java.sun.com/products/servlet/docs.html
を参照してください。
この章の内容は次のとおりです。
Oracle Stream Analyticsは、次のJetty機能をサポートしています。
サーブレット: Oracle Stream Analyticsでは、同期および非同期のJavaサーブレットをサポートします。非同期サーブレットはリクエストを受信し、スレッドを取得して作業を実行します。また、最終的には、アクションの完了を待機している間に(別のスレッドを再取得するよりも前に)スレッドを解放し、レスポンスを送信します。「アプリケーションの開発とデプロイメント」を参照してください。
ネットワークI/O統合: Oracle Stream Analyticsでは、ネットワークI/O (Net IO)を使用してJettyサービスのポートとリスニング・アドレスを構成します。Jettyは多重化されたネットワークI/Oに対応した組込み機能を備えています。ただし、同一ポート上での複数のプロトコルはサポートされません。
スレッド・プールの統合: Oracle Stream Analytics Jettyサービスは、Oracle Stream Analyticsワーク・マネージャを使用して、スケーラブルなスレッド・プーリングを可能にします。「Jetty構成の例」を参照してください。JettyにはJetty独自のスレッド・プール機能が用意されていまが、処理コストおよび構成の複雑さを最小限に抑えるために、Oracle Stream Analyticsの自動チューニング・スレッド・プールを使用することをお薦めします。
Jettyワーク・マネージャ: Oracle Stream Analyticsでは、アプリケーションがどのような優先順位で作業を実行するかを構成できます。ルールを定義して実行時パフォーマンスを監視して、アプリケーション・パフォーマンスを最適化し、サービスレベルのアグリーメントを保持します。ワーク・マネージャを定義して、アプリケーションに対してルールや制約を定義します。「Jetty構成オブジェクト」を参照してください。
Oracle Stream Analyticsでは、1つのスレッド・プールですべてのタイプの作業を実行します。作業の優先順位は、ユーザーが定義するルールと実行時のメトリックに基づいて決定され、メトリックとしては、リクエストを実行するのにかかった時間、リクエストをプールに出し入れする割合などがあります。
共通スレッド・プールのサイズは、スループットが最大になるように変更されます。キューは、スループットを一定期間監視し、履歴を基にスレッド数を調整するかどうかを判断します。たとえば、スループットの統計値の履歴に基づき、スレッド数を増やすことでスループットが向上すると判断されると、Oracle Stream Analyticsではスレッド数が自動的に増やされます。同様に、統計値に基づいてスレッドを減らしてもスループットが悪化しないと判断されると、Oracle Stream Analyticsではスレッド数が自動的に減らされます。
Oracle Stream Analyticsでは、定義済のパラメータと実行時のパフォーマンスおよびスループットを考慮に入れた実行モデルに基づいて、作業の優先順位が決定されてスレッドが割り当てられます。ユーザーは、一連のスケジューリング・ガイドラインを構成し、それらを1つまたは複数のアプリケーションに関連付けたり、特定のアプリケーション・コンポーネントに関連付けることができます。
たとえば、スケジューリング・ガイドラインのセットを1つのアプリケーションに関連付け、別のガイドラインのセットを別のアプリケーションに関連付けることができます。実行時には、Oracle Stream Analyticsではこのガイドラインに基づいて、保留中の作業やキューに入っているリクエストが実行スレッドに割り当てられます。
アプリケーション内の作業を管理するには、次のうち1つまたは複数のワーク・マネージャ・コンポーネントを定義します。
fairshare
: リクエストを処理するために必要な平均スレッド使用時間。
たとえば、Oracle Stream Analyticsで2つのモジュールが実行され、ModuleA
のワーク・マネージャではfairshare
が80に指定されていて、ModuleB
のワーク・マネージャではfairshare
が20に指定されています。各モジュールで切れ目なくリクエストを処理している状態(つまり、リクエスト数がスレッド数を超えている状態)が続く間は、Oracle Stream Analyticsでは、スレッド使用時間の80%がModuleA
に、20%がModuleB
にそれぞれ割り当てられます。
注意:
フェア・シェア要求クラスは、割合ではなく相対値として指定します。したがって、上の例でリクエスト・クラスを400と100に設定しても相対値としては同じです。
max-threads-constraint
: 制約対象の作業セットからのリクエストを実行する同時スレッドの数を制限します。デフォルトは無制限です。たとえば、最大スレッド数が10に定義された制約を3つのエントリ・ポイントで共有するとします。このスケジューリング・ロジックでは、統合された3つのエントリ・ポイントからのリクエストを10個以下のスレッドで実行します。
max-threads-constraint
は、リクエストが依存するリソース(たとえば接続プール)の可用性の観点から定義できます。
max-threads-constraint
は、リクエスト・クラスによるスレッドのフェア・シェアの実現やレスポンス時間の目標値の達成を妨げることがあります。一度制約条件が満たされると、同時実行数が制限値を下回るまで、Oracle Stream Analyticsではこのタイプのリクエストはスケジューリングされません。Oracle Stream Analyticsでは、フェア・シェアまたはレスポンス時間の目標値に基づいて作業がスケジューリングされます。
min-threads-constraint
: 制約対象のリクエストに割り当てられるスレッドの数を保証することでデッドロックを回避します。デフォルトはゼロです。min-threads-constraint
の値を1に設定すると、ピアから同期的に呼び出されるレプリケーション更新リクエストなどの場合に便利です。
min-threads-constraint
によってフェア・シェアが向上しない場合もあります。このタイプの制約は、主にOracle Stream Analyticsインスタンスがデッドロック状態に近づいたときに効果を発揮します。このような場合は、最近サービス・クラス内のリクエストがフェア・シェアを超えていたときでも、Oracle Stream Analyticsではこの制約によってリクエストがスケジューリングされます。
Oracle Stream Analyticsでは、Jettyへのデプロイメントのためのサーブレット開発をサポートします。
開発者は標準Java EE Webアプリケーションを作成し、サーブレットが実行されるサーバーのconfig.xml
ファイルでjetty-web-app
構成オブジェクトを使用してそのアプリケーションを構成します。
Oracle Stream Analyticsでは、Java Servletバージョン2.4仕様に規定されているように、warファイルまたは展開されたwarファイルのどちらでもパッケージのサーブレットのデプロイメントをサポートしています。事前に構成されたWebアプリケーションをサーバーの構成に組み込むことによって、展開済ディレクトリまたはwarファイルからアプリケーションをデプロイできます。
標準のweb.xmlファイルに指定されたセキュリティ制約はCommon Security Servicesのセキュリティ・プロバイダにマップされます。サーブレットAPIでは、宣言型のロール・ベース・セキュリティを指定します。つまり、特定のURLパターンをセキュリティ・ロールにマップできます。
この項では、Jetty構成の例を示し、その後にJetty構成オブジェクトの説明を示します。
構成するサーバーのconfig.xml
ファイルでJettyサーバー・インスタンスを構成します。Jettyに影響するセキュリティ構成タスクの詳細は、「Jettyセキュリティの構成」を参照してください。
次のconfig.xml
ファイルからのスニペットは、Jetty構成の例を示します。Jetty関連の構成情報のみが示されています。
<config> <netio> <name>JettyNetIO</name> <port>9002</port> </netio> <work-manager> <name>WM</name> <max-threads-constraint>64</max-threads-constraint> <min-threads-constraint>3</min-threads-constraint> </work-manager> <jetty> <name>TestJetty</name> <work-manager-name>WM</work-manager-name> <network-io-name>JettyNetIO</network-io-name> <debug-enabled>false</debug-enabled> <scratch-directory>JettyWork</scratch-directory> </jetty> <jetty-web-app> <name>test</name> <context-path>/test</context-path> <path>testWebApp.war</path> <jetty-name>TestJetty</jetty-nam> </jetty-web-app> </config>
この項では、次の構成オブジェクトを使用して、Jetty HTTPサーバーのインスタンスを構成する方法を説明します。使用しているOracle Stream Analyticsサーバーを記述するconfig.xml
ファイル内にJetty HTTPサーバーを構成します。
jetty
次の表に示すパラメータを使用して、config.xml
ファイルにjetty
構成オブジェクトを定義します。
表10-1 jetty要素構成パラメータ
パラメータ | データ型 | 説明 |
---|---|---|
network-io-name |
String |
使用されたNet IOサービスの名前。Net IOサービスは、サーバーがリスニングするポートを定義します。 詳細は、「Jetty構成オブジェクト」を参照してください。 |
work-manager-name |
String |
スレッドのプールに使用されるワーク・マネージャの名前。指定しない場合はデフォルトのワーク・マネージャが使用されます。 「Jetty構成オブジェクト」を参照してください。 |
scratch-directory |
String |
Webアプリケーション、JSPおよびその他のタイプのWebアーティファクトに必要な一時ファイルを保管するディレクトリの名前。 |
debug-enabled |
boolean |
JettyコードでOSGi Log Serviceを使用してデバッグ機能を有効にします。 |
name |
String |
jettyサーバー・インスタンスの名前。 |
netio
次の表に示すパラメータを使用して、config.xml
ファイルにnetio
構成オブジェクトを定義します。
表10-2 netio要素構成パラメータ
パラメータ | データ型 | 説明 |
---|---|---|
name |
String |
構成オブジェクトの名前。 |
port |
int |
リスニングするポート番号。 |
listen-address |
String |
このパラメータの値は、サービスが起動されるまで検証できません。 |
work-manager
次の表に示すパラメータを使用して、config.xml
ファイルにwork-manager
構成オブジェクトを定義します。
表10-3 work-manager要素構成パラメータ
パラメータ | データ型 | 説明 |
---|---|---|
min-threads-constraint |
Integer |
このワーク・マネージャが使用する最小スレッド数。 |
fairshare |
Integer |
このワーク・マネージャが使用する |
max-threads-constraint |
Integer |
このワーク・マネージャが使用する最大スレッド数制約。 |
name |
String |
このワーク・マネージャの名前。 |
jetty-web-app
次の構成オブジェクトを使用して、Jettyが使用するWebアプリケーションを定義します。
表10-4 jetty-web-app要素構成パラメータ
パラメータ | データ型 | 説明 |
---|---|---|
name |
String |
このワーク・マネージャの名前。 |
context-path |
String |
このWebアプリケーションのデプロイ先となるWebサーバーのネームスペースのコンテキスト・パス。 設定しない場合、デフォルトで |
scratch-directory |
String |
JettyがこのWebアプリケーションの一時ファイルを保管する場所。 「Jettyサーバー・インスタンスの構成」の |
path |
String |
サーバー上のWebアプリケーションの場所を指すファイル名。ディレクトリまたはwarファイルを指定できます。 |
jetty-name |
String |
このWebアプリケーションのデプロイ先のJettyサービス名。既存の「Jettyサーバー・インスタンスの構成」の名前と一致している必要があります。 |
name |
String |
この構成オブジェクトの名前。 |