クラウドの特徴を備えるように Java EE コンテナーを拡張する

並列性、弾力性、マルチテナンシー、そしてセキュリティーを備えるように JEE コンテナー/アプリケーションを拡張するためのストラテジーとパターン

この記事では、クラウド・アプリケーションおよび Java Enterprise Edition アプリケーションの基本的な特徴を概説し、それらを比較対照して類似点と相違点を明らかにします。そして、並列性、弾力性、マルチテナンシー、そしてセキュリティーといったクラウドが持つ特徴を備えるように Java EE コンテナーおよびアプリケーションを拡張するための一連のストラテジーを定義し、またそのためのパターンを紹介します。

Jayakrishnan Ramdas, Senior Technology Architect, Infosys LTD

IT 業界で 15 年以上の経験を持つ Jayakrishnan Ramdas は、有名なソフトウェア・サービス・ベンダー、Infosys LTD に勤務しています。アーキテクトとしての 6 年以上の経験のなかで、TOGAF (業界標準のアーキテクチャー・フレームワーク) を完成させるとともに、さまざまな IBM 認定プログラムを完了しました。



J. Srinivas, Principal Architect, Infosys LTD

業界での 16 年の経験を持つ J. Srinivas は現在、Infosys LTD の欧州 Banking and Capital Markets 部署でテクノロジーを焦点とするグループのリーダーを務めています。プロジェクト管理およびアーキテクチャーの分野に携わってきた彼は、プロセス、テクノロジー、そして意欲あるチームの構築に熱意を燃やしています。彼は Infosys アジャイル・プロセス・チームの中核的メンバーであり、Infosys でのクラウド・コンピューティングのエバンジェリストです。



2011年 6月 10日

JEE (Java Enterprise Edition) アーキテクチャーのベースとなっているのは、アプリケーションのトランザクションとステートフル性、マルチスレッド化、およびリソース・プールを効率的に管理する機能を備えたコンポーネントです。ビジネス・ロジックは再利用可能なコンポーネントにまとめられ、サーバーは基礎となるサービスを、コンポーネントのタイプ別に (コンテナーという形で) 提供します。このことから、JEE アプリケーションは、要件が複雑な場合でも比較的容易に作成することができます。

私たちが JEE でのコンテナー・サービスの概念をさらに強化する斬新的なアイデアとして思い付いたのは、クラウド・コンピューティングの強力な概念となっている並列性、弾力性、マルチテナンシー、そしてセキュリティーのサポートを追加するという方法です。この記事では、JEE コンテナー/アプリケーションにクラウド・コンピューティングの特徴を追加して拡張するためのストラテジーおよびパターンを説明します。記事の内容は以下のとおりです。

  • 私たちが統合したクラウドの特徴の概要
  • JEE アプリケーションに既に備わっている特徴の概要
  • JEE コンテナーをクラウドに拡張する方法についての説明
  • 並列性、同期化、ストレージ、弾力性、マルチテナンシー、およびセキュリティーの概念を組み込んでマイグレーションする際の設計ストラテジー

クラウドの特徴

図 1 に、クラウドの概要と、種類の異なるクラウド・デプロイメント・モデルを示します。

図 1. クラウドのサービス・モデルと、クラウドのコンポーネントの全体像
クラウドのサービス・モデルとコンポーネントの概要

上記のクラウド・スタックの一番下に示されているサービス・モデルは、IaaS (Infrastructure as a Service) です。このモデルでは、インフラストラクチャーはクラウドに移され、クラウドがソフトウェア (ビジネス・アプリケーションを含む) を容易にデプロイできるようにします。ただし、IaaS にはアプリケーション開発環境もなければ、テスト用のサービスもありません。図に示されているように、最上位の抽象化層がもたらす特徴には、弾力性、自動デプロイメント、およびユーティリティー・コンピューティングなどがあります。

PaaS (Platform as a Service) は、アプリケーション・ソフトウェアを作成、デプロイ、保守するための環境を提供します。PaaS プロバイダーは、アプリケーションのビルド、デプロイ、テストといった基本ライフサイクルを実現するためのサービス、アプリケーションのステート管理、トランザクション、セキュリティーなどのビルディング・ブロックを提供するサービス、そしてアプリケーションの実行期間にわたってリソース管理を行うサービスなどを提供する必要があります。

SaaS (Software as a Service) は、エンドユーザーがアプリケーションにアクセスして利用するための環境を提供します。

クラウドの基本的な特徴のうち、アプリケーションが必ずサポートしなければならないのは、弾力性マルチテナンシーです。プロビジョニングや自動化などの特徴は、アプリケーション・サーバーのデプロイメント機能によってサポートされるので、これらをサポートすることでコードにもたらされる影響はたいしたことはありません。並列性、分散ストレージに対する要求、そしてセキュリティーの強化は、弾力性とマルチテナンシーを実現するために対応しなければならない特徴をサポートする役割を果たします。

これらの特徴について、以下に詳しく説明します。

弾力性

弾力性とは、必要に応じてインフラストラクチャーをスケールアップ/スケールダウンする能力のことです。負荷のピーク時には、クラスターにさらにインスタンスを追加し、負荷が下がるとインスタンス数を減らします。インスタンスの増減は、動的に行わなければなりません。この動的増減を可能にするのは、動的クラスタリング手法をサポートするアプリケーション・サーバーの機能です。

弾力性は単にアプリケーション・サーバーがサポートしなければならない特徴というだけではなく、アプリケーション自体も弾力性をサポートできなければなりません。つまり、アプリケーションは、並行性をサポートするために必要となるリソースを扱えるように設計されていなければならない、ということを意味します。弾力性をサポートするようにアプリケーションを設計あるいはカスタマイズすると、アプリケーションに並列性、ステートレス性、トランザクション・サポートなども実装されることになります。

すべてのリソースに、実行のステートレス性および並列性をサポートさせる弾力性を実装する方法については、設計ストラテジーのセクションで説明します。

マルチテナンシー

マルチテナンシーとは、アプリケーションが、単一のアプリケーション・インスタンスで複数の顧客に対処できることを意味します。つまり、5 人の顧客がコンテンツ管理サービスを使用しているとしたら、各顧客のデータおよび実行パラメーターが適切に分離された状態で、5 人の顧客全員が同じアプリケーション・インスタンスを使用できるということです。アプリケーションがマルチテナンシーをサポートするには、分散ストレージ、並列性、セキュリティー、そして疎結合に取り組まなければなりません。

マルチテナンシーをサポートするには、以下の 2 つの方法があります。

  • すべてのテナントに共通の物理ストレージを使用する
  • テナントごとに個別の物理ストレージ・リソースを使用する

並列性とトランザクション・サポート

この記事で意味する並列性とは、複数のリクエストを並行して実行できること、あるいは大規模なデータ・セットのタスクを複数のサブタスクに分割し、これらのサブタスクを並行して実行できることです。このような並列性は、使用可能なリソースの有効利用を促進します。また、並列性を組み込むことで、スループットおよびパフォーマンスも向上します。一方、トランザクション・サポートは、あらゆるリソースのステートの変更が同期されることを保証することによって信頼性を確実にすることなので、並列性とトランザクション・サポートという 2 つの概念は、両極端に位置します。つまり、どちらか一方を強化すると、その分、もう一方の概念が犠牲になるということです。

この相反する特徴のバランスを取るには、並列性とトランザクション・サポートを適切に組み合わせることが不可欠です。ストラテジーのセクションで紹介する 4 つのストラテジーのうち、以下の 2 つはそれぞれ並列性、トランザクション・サポートに対処します。

  • 並列性のための同期および非同期手法
  • トランザクション・サポートのための、スレッド完了ベースおよびデータ到着ベースの同期手法

この記事で説明するマイグレーション・ストラテジーは、関数を使わずに並列性を実現する手法に従っていますが、関数の変更を要するストラテジーもいくつかあります。Google フレームワークの MapReduce (MR) はその一例です。MR は、サイズの大きなデータを複数のキーと値のペアに分割する Map 関数を使用して並列性を実装する手法です (MapReduce とクラウドに関する記事については、「参考文献」を参照してください)。

疎結合とステートレス性

疎結合の場合、サービスの呼び出しは必ず標準インターフェースを介して行われます。そのため、呼び出す対象のコンポーネントや呼び出し側のコンポーネントが変更されても、他方には影響しません。疎結合は、サービスの呼び出しを行うプロキシーを使用することで実現されます。ステートレス性は、疎結合に伴う 1 つの特性であり、サービスに対するどの呼び出しもその前の呼び出しには依存しないことを意味します。ステートレス性は、永続ストレージでステートの変更を管理することによって実現されます。

疎結合とステートレス性はいずれも、システム・コールを依存関係から解放することを促進する優れた特徴です。

分散ストレージ

分散ストレージは、データの存在する場所が重要な意味を持たないようにデータを永続化する手段です。これは同時に、同じデータを異なる複数の場所に保管できることも意味します。この特徴は、弾力性とステートレス性を向上させるものの、トランザクション・サポートに対してはマイナスの影響を与える可能性があるため、両方のバランスを取る必要が出てきます。

分散ストレージに関するストラテジーには、以下の 4 つがあります。

  • レプリケーション・ノード: データを異なる複数のノードで使用できるようにします。データは即時に他のノードへのレプリケーションが行われます。
  • オンデマンド・レプリケーション: データのレプリケーションを手動で、あるいは自動的に行うためのトリガーを定義します。
  • フェイルオーバー時の一方向のレプリケーション: マスター・ノードから子ノードへの引継ぎ計画です。マスター・ノードに障害が発生している間は、レプリケーション作業は特定の子ノードに割り当てられます。
  • ファイルシステム共有: 例えばファイルシステム・リソースなど、レプリケーションにコストがかかる場合に使用されます。

セキュリティー

クラウド・アプリケーションのセキュリティーは、クラウド・アプリケーションが持ついくつかの特徴に大きく影響します。つまり、マルチテナンシー、並列性、および疎結合といった特徴を実現するには、さらなるセキュリティーが必要となるためです。また、アプリケーションをハイブリッド・アプリケーション (例えば、クラウド・コンポーネントとローカル・システム・コンポーネントのハイブリッド・アプリケーション) としてデプロイする場合には、クロスドメインのシングル・サインオン機能が必須となりますが、それによってセキュリティーに関連する事項が追加で必要になります。

分散ストレージ、並列性、トランスポートにもセキュリティーに関する懸念事項があります。

クラウド・アプリケーションが持つ特徴を理解できたところで、次は Java EE コンテナーの構造を見て行きます。


Java EE コンテナー・アプリケーションの特徴

従来の JEE アプリケーションはコンテナー・サービスに依存し、以下の機能を使用します。

  • スティッキー・セッション: 接続状態を管理するために使用します。
  • RDBMS: SQL で直接使用するか、または ORM を使用したストアード・プロシージャーという手段で間接的に使用します。
  • JMS オブジェクト

JEE アプリケーションは、メッセージ駆動型 Bean と セッション Bean、そしてコンテナーが提供するフレームワークを使用して実装された Web サービスを使用することもあります。新しく構築されたアプリケーションでは、非同期処理や、キャッシング・サービスあるいは JavaMail サービスが使用される場合もあります。

以降のセクションで、JEE コンテナー・アプリケーションの属性および機能の詳細について説明します。

データおよび操作

プログラミング・ロジックのどこを取っても、データ (またはメモリー) に関連する部分と、操作 (または実行) に関連する部分に大別することができます。この 2 つの部分がやりとりすることによって、操作がデータに作用し、データが操作で使用されます。JEE パッケージ、コンテナー、およびアプリケーションを含む全体も、これと同じように 2 つに分けることができます。

コンテナー

データ面での品質は、アクセスされたデータの信頼性と可用性を確保する能力、並行性を許容する能力、およびストレージ内のデータのセキュリティーが判断基準となります。一方、操作面における品質の判断基準は、リスナーがデータの到着をリッスンする能力、リモート呼び出しを行う能力、そしてアクセス制御とトランスポート・セキュリティーです。

表 1. JEE アプリケーションのデータおよび操作における品質の定義
品質特性実装特性実装
データ信頼性トランザクショントランザクションによってデータへの同期アクセスを可能にします。
可用性パーシスタンスパーシスタンスのタイプによってデータの可用性が決まります。
並行性ステート管理ステート管理メカニズムによって同時に処理できるリクエストの数を確実にします。
セキュリティーセキュリティー保管時および送信時の暗号化
操作非同期通信リスナー非同期呼び出しのトリガー
同期通信リモート呼び出し現行プロセス外部での同期呼び出し
セキュリティーセキュリティーアクセス制御のチェックとトランスポート・セキュリティー

コンテナーには、以下の 2 つの役目があります。

  1. データおよび操作の品質特性が維持されるようにするためのメカニズムを備えること
  2. ヒープ・メモリーや実行スレッドの数など、システム・リソースの使用量を制御すること

したがって、2 つの異なるパターンのそれぞれについて取り組まなければならないことになります。1 つは管理対象リソースのパターン、そしてもう 1 つは管理対象タスクのパターンです。

管理対象リソース・パターン

データ関連のサービスを提供する管理対象リソースは、セッション管理、トランザクション、パーシスタンス、およびセキュリティーを実装します。呼び出し側は、ネーミング・ディレクトリーを使用してリソース・マネージャーを見つけます。リソース・マネージャーは、コンテナーが提供するオブジェクト・プールを使用してシステム・リソースを管理します。典型的な管理対象リソースには、図 2 に示すパターンがあります。

図 2. 管理対象リソース・パターン
管理対象リソース・パターン

コンテナーまたはアプリケーションは、JNDI からリソース・マネージャーのハンドルを取得することができます。リソース・マネージャーはオブジェクト・プールを実装して、パーシスタンス、セキュリティー・ステート管理、およびトランザクションを実装する管理対象リソースを取得します。

管理対象タスク・パターン

管理対象タスクは、リモート呼び出し、リスナー、およびセキュリティーを実装する操作関連のサービスを提供し、コンテナーが提供するスレッド・プールとネーミング・ディレクトリーのサービスを使用します。さらに、管理対象タスクは大抵の場合、その操作対象となる管理対象リソースを 1 つ以上カプセル化します。コンテナーは、データが到着すると管理対象リスナーをトリガーします。このデータは、時刻、メッセージ、あるいはリクエストという形にすることができます。管理対象リスナーは、アプリケーションがトリガーすることもできます。

図 3. 管理対象タスク・パターン
管理対象タスク・パターン

コンテナーが提供するすべてのサービスは、上記のパターンのいずれか、またはこの 2 つのパターンの組み合わせに分解することができます。例えば、JMS (Java Message Service) の場合、JMS Destinations には管理対象リソース・パターンが当てはまり、JMS MessageListener には管理対象タスク・パターンが当てはまります。同様にして、JDBC Connection は管理対象リソース・パターンになります。

JEE コンテナー・アプリケーションがどのように機能するかを説明したところで、次はいよいよ、コンテナー・アプリケーションをクラウドに拡張する方法を検討します。


コンテナーの拡張: 基本的な方法

この方法では、以下のようにしてコンテナーをクラウドに拡張します。

  1. クラウドの特徴を実装の属性に分解する。
  2. 実装属性に関連する変更によって、管理対象リソース・パターンと管理対象タスク・パターンを拡張する。

管理対象リソース・パターンをクラウド・リソース・パターンに拡張する方法、そして管理対象タスク・パターンをクラウド・タスク・パターンに拡張する方法については、ストラテジーのセクションで説明します。

管理対象リソース・パターンには、以下の拡張機能を追加することで、クラウド・リソース・パターンに拡張します (図 4 を参照)。

  • CloudResource
  • Isolator
  • Replicator
  • LockManager
  • LockDataResource
  • StateDataResource

同様に、管理対象タスク・パターンには Proxy と StateManager を追加して、クラウド・タスク・パターンに拡張します (図 5 を参照)。

ここからは、以上に挙げたコンポーネントについて説明します。

クラウド・リソース・パターン

クラウド・リソース・パターンには、上述の拡張機能が組み込まれます。以下に、各コンポーネントの概要およびコンポーネント相互の対話について説明します。

CloudResource
CloudResource は管理対象リソースを拡張し、必要に応じて分散トランザクションおよびステート・パーシスタンス・ロジックを組み込みます。

StateDataResource
StateDataResource は、特定のクラウド・リソースのステートの変更を表す CloudResource のインスタンスです。ステート・パーシスタンス・ロジック自体は、ステートレスに実行されます。

Isolator
Isolator は、入力に含まれる制御フィールドを使用して顧客のテナントを識別し、該当するセキュリティーおよびパーティション・ロジックを適用して、適切な場所に入力を保管します。Isolator により、アプリケーション・コードがマルチテナント・ストレージのストラテジーによって乱雑にならないこと、そして適切なマルチ・テナント・ストラテジーが適用されることが確実になります。Isolator 自体は、CloudResource のコレクションです。

Replicator
Replicator が使用されるのは、レプリケーション・ノードおよびオンデマンド・レプリケーションのストレージ・ストラテジーが使用される場合だけです。Replicator は、データが唯一の分散トランザクション・データとして、全レプリケーション・ノードに永続化されることを確実にします。Isolator と Replicator との違いは、Isolator はテナントに応じて適切なストレージにデータが格納されるようにする一方、Replicator は同じテナントの全レプリケーション・ストレージにデータが格納されるようにするという点です。

LockManager および LockDataResource
LockManager の役割は、すべての Replicator で、特定のデータをプロセスの 1 つのスレッドに対してロックすることです。LockManager は、すべてのレプリケーション・ノードで同じステータスが表示されるようにします。つまり、サーバー 1 のサーバー・プロセス内のスレッドに対してデータがロックされている場合、サーバー 2 のプロセスには、たとえ調べている対象がストレージのレプリカであったとしても、そのステータスはロックされていると表示されるということです。この機能は、レプリケーション・ノードおよびオンデマンド・レプリケーションのストレージ・ストラテジーにのみ必要となります。

このパターンに対する変更は、全体として以下のように要約することができます (図 4 を参照)。

  • リソース・マネージャーが新たに Isolator を提供するようになり、この Isolator が、ストレージ・ストラテジーに応じて CloudResource を直接提供するか、または Replicator を提供することになります。
  • クラウド・リソースが分散トランザクションをサポートするようになり、ステート管理もステート・パーシスタンスに対処するようになります。
図 4. 分散トランザクションをサポートするようになったクラウド・リソース・パターン
分散トランザクションをサポートするようになったクラウド・リソース・パターン

クラウド・タスク・パターン

管理対象タスク・パターンを拡張するクラウド・タスク・パターンには、Proxy および StateManager 拡張機能が追加されます。Proxy が並列性ストラテジーを決定し、そのストラテジーを実行するために、StateManager にステート・パーシスタンスを制御するように指示します。

Proxy
Proxy は、管理対象タスクを事前処理および事後処理ロジックと併せてラップします。事前処理ロジックでは、メッセージ・セキュリティーの処理に続き、プロトコルに応じて入力がフォーマット設定され、管理対象タスクが実行されます。管理対象タスクが実行された後は、事後処理ロジックによって、出力に対する処理内容が決定されます。

StateManager
タスクのステートレスな実行によって、タスクへの入力が初期ステートであること、そして最終的なステートに関連するすべての情報が出力に含まれていることが確実になります。したがって、StateManager の役割は、入力と出力を処理し、CloudResource として入力/出力を受け渡すことです。

図 5. クラウド・タスク・パターンの StateManager によって CloudResource として受け渡される入力/出力
クラウド・タスク・パターンの StateManager によって CloudResource として受け渡される入力/出力

表 2 に、クラウドの各特徴と、それに対応する設計ストラテジー、そしてそれらが影響を及ぼす JEE 実装属性とパターンを詳細に記載します。

表 2. クラウドの特徴と、その特徴が設計ストラテジーおよび実装属性に与える影響
クラウドの特徴設計ストラテジー実装属性パターンパターン拡張機能
ステートレス性ステート・パーシスタンスによるステートレス性リスナー、リモート呼び出し側クラウド・タスクStateManager
ステートレス性ステート・パーシスタンスによるステートレス性ステート管理クラウド・リソースStateDataResource
分散ストレージレプリケーション・ノード、オンデマンド・レプリケーションパーシスタンスクラウド・リソースクラウド・リソース
分散ストレージレプリケーション・ノード、オンデマンド・レプリケーショントランザクションクラウド・リソースCloudResource
並列性および同期化すべてのストラテジーリスナー、リモート呼び出し側クラウド・タスクProxy
疎結合すべてのストラテジーリスナー、リモート呼び出し側クラウド・タスクProxy
マルチテナンシーすべてのストラテジーパーシスタンスクラウド・リソースIsolator
セキュリティー暗号化パーシスタンスクラウド・リソースIsolator
セキュリティー暗号化暗号化クラウド・タスクProxy

コンテナーの拡張: 共通コンテナー・サービスに対する方法

この方法では、クラウド・リソースおよびクラウド・タスクのパターンとマッチするように既存のコンテナー・サービスを修正し、これらのサービスをできるだけアプリケーションの内部に干渉しないような方法でアプリケーションに追加します。要するに、私たちはすべてのサービスをクラウド・リソース・パターンに変換したということです。アプリケーションがクラウド・リソース・パターンを操作するときには、該当するパターンがクラウド・タスク・パターンに変換されて、クラウドで使用できるようになります。以下に、サービス、従来の方法、そして私たちの新しい方法を記載します。

  • サービス: JDBC データベース接続
    従来の方法: 管理対象リソース。
    新しい方法: 分散トランザクション (2 相コミット)、スレッド・プール対応の共有可能な接続、そしてステートレスな呼び出しをサポートするバージョンにアップグレードします。既存の新しいバージョンを基に、残りの機能はクラウド・リソース・パターンを使用して提供することができます。
  • サービス: JMS オブジェクト
    従来の方法: JMS の Sender および Receiver がタスクであり、JMS のメッセージおよび宛先がオブジェクトです。
    新しい方法: JDBC データベース接続に使用した方法と同じ。弾力性を支援するために JMS クライアントが存在するノードのすべてに必ず JMS Server も共存するように、構成を変更することができます。
  • サービス: キャッシュ・オブジェクト
    従来の方法: 現在は、メモリー内キャッシュ・サービスまたは分散キャッシュ・サービスをサポートします。
    新しい方法: 効果的に共有を活用するには、すべてのキャッシュを分散キャッシュに変換する必要があります。キャッシュ・サービスは、オプションでクラウド・リソース・アダプターによってラップすることができます。
  • サービス: セッション
    従来の方法: ほとんどのアプリケーションは、スティッキー・セッションを使用します。
    新しい方法: 他に影響を与えないようにコードを変更するには、すべてのリクエストにフィルターを設定する方法を使用することができます。そして、そのフィルターに、getSession() をオーバーライドできるカスタム HttpServletRequestWrapper を作成させて、これをクラウド・リソースとして提供します。また、スティッキー・セッションを排除します。
  • サービス: パーシスタンス・ストラテジー
    従来の方法: ORM ベースのコンテナー管理パーシスタンスが役に立ちます。
    新しい方法: ORM ベースのコンテナー管理パーシスタンスでは、ストレージが持つリレーショナルな性質によってアプリケーション・コードが煩雑になる、ということがありません。そのため、パーシスタンス層を非リレーショナル DB に変更するのも容易です。Hibernate Shards は、分散ストレージを可能にするとともに、クラウド・リソース・パターンでの Replicator のように機能します。アプリケーションが DAO (Data Access Object) と動的 SQL およびストアード・プロシージャーを使用している場合には、アノテーションを使用して、DAO に渡される値オブジェクトをクラウド・リソースとして宣言することができます。
  • サービス: 変数
    従来の方法: 変数の処理。
    新しい方法: パブリック変数と静的変数、ファイル入出力、そしてログ書き込みをすべて変更して、クラウド・リソースを使用しなければならないようにします。
  • サービス: メソッド呼び出し
    従来の方法: メソッド呼び出しの処理。
    新しい方法: 関連するすべてのメソッド呼び出しをクラウド・タスクに変換します。

設計ストラテジーへの影響

最後に、アプリケーションでクラウドの特徴を有効にすることによって、設計ストラテジーにどのような影響があるかを検討します。ここでは、以下の内容について検討します。

  • 同期および非同期並列性
  • データ到着およびスレッド完了ベースの同期化
  • レプリケーション・ノード、オンデマンド・レプリケーション、フェイルオーバーを使用した片方向レプリケーション、およびストレージ側でのファイルシステム共有
  • 疎結合とステートレス性
  • 弾力性
  • 単一ストレージおよび個別ストレージによるマルチテナンシー
  • セキュリティー

並列性

前に説明したように、並列性とは、タスクが複数のサブタスクに分割されて最後に合成されるという、タスクの並列処理機能を意味します。並列性のストラテジーには、同期と非同期という 2 つの方式があります。

同期
同期方式では、呼び出し側は現在実行中のタスクの処理が完了してから、次のタスクの処理に進みます。各タスクをトリガーするには、サービス呼び出しを使用します。タスクは、呼び出し側からのサービス呼び出しを待機し、呼び出されて処理が完了したら、呼び出し側に制御を返します。並列性を実現するために、各タスクの子スレッドのスケジューリングを行うメイン・スレッドが実行されます。こうすることで、複数のタスクが並行して実行される一方で、それぞれのスレッドによってタスクが同期的に実行されます。

この同期方式のストラテジーは、データ集約に最適です。アプリケーションに異なる複数のソースからの情報が必要な場合、それぞれのソースのデータを同期的に取得しながらも、各ソースを並行して取得することができます。

非同期
この場合、呼び出し側はメッセージングを使用してタスクを非同期的に呼び出します。タスクの処理が完了すると、タスクの出力は、次のタスクがその出力を取得できるように永続ストレージ域に保管されます。

非同期方式のストラテジーは、オーケストレーション・タスクに適しています。各オーケストレーション・タスクは非同期で呼び出され、そのそれぞれが、同期化ストラテジーを使用してデータ集約タスクを呼び出します。

同期化ストラテジー

同期化ストラテジーはトランザクション・サポートを保証することから、タスクの信頼性が確実になります。同期化ストラテジーによって、必ず次のタスクの処理が行われる前に、関連するタスクの処理が完了し、関連するデータが使用できるようになります。同期化ストラテジーには、データの到着をベースとした同期化と、スレッドの完了をベースとした同期化があります。

データ到着ベース
データ到着ベースの同期化とは、特定のデータが特定の場所に到着すると、タスクがトリガーされるということです。データ到着ベースの同期化が特に重要になるのは、呼び出されたタスクの出力が特定の場所に出力されるのを参照しなければ、呼び出し側タスクが処理を先に進められないような非同期呼び出しの場合です。

スレッドはデータ域をポーリングして、データが到着しているかどうかを確認します。データが到着すると直ちにスレッドはタスクをトリガーするためのメッセージを送信します。MessageListener は、データ到着ベースの同期化実装の 1 つです。

スレッド完了ベース
スレッド完了ベースの同期化では、リソース・モニターが並行スレッドを調べ、該当するリソースにアクセスしている間、タスクの実行を同期化します。これと同じストラテジーは、データ到着ベースのストラテジーとスレッド完了ベースのストラテジーを組み合わせて、インスタンス間で共有しなければならないリソースに適用することができます。

このストラテジーは通常、単一の JVM 内部のスレッドに適用されます。外部リソースにとって、この方法はデータ到着ベースの同期化の拡張となります。この場合、モニター・ステータスがデータであり、リスナーがこのデータを現行の JVM 内で実行されているスレッドに渡します。

ストレージ

ストレージには、さまざまなタイプがあります。一例としては、データベース、ファイルシステム、メモリー内データ、そしてネイティブ・ディレクトリーのようなパーシスタンス・デバイスなどがあります。ストレージ・ストラテジーに不可欠とされるのは、JEE アプリケーションに、真のネットワーク・オブジェクト (そのステート変更が、クラスター内のすべての JVM に反映されるオブジェクトのこと) を作成する手段、そして動的 RDBMS SQL が機能しない場合に分散データ・ソースをマイグレーションする手段を確実に用意することです。さらに、ストレージ・ストラテジーは並列性およびマルチテナンシーの重要な構成要素でもあります。

レプリケーション・ノード
レプリケーション・ノードのストラテジーは、同じデータが異なる複数のノードで入手可能であり、データが即時に他のノードにレプリケートされることを意味します。データベースには、ウォーム・レプリケーション・ストラテジーとホット・レプリケーション・ストラテジーを適用することができます。その他のストレージ分野では、2 相コミットに適用されるストラテジーを使用する必要があります。

実行をサポートするスレッドは、最低限 2 つはあります。一方のスレッドには同期的に呼び出す保存/更新アクションがあり、このスレッドがソケット接続を介して他のノードにデータを送信します。そして、レスポンスを受信した時点で、コミットを発行して実際にノードを更新します。リスナー・スレッドは、他のノードからの変更をリッスンして応答します。ソケット接続の代わりに、メッセージングまたは HTTP ベースのサービスを使用することもできます。

レプリケーションは、ほとんど更新されることのない読み取り専用のデータに最適ですが、レプリケーションにはコストがかかります。すべてのキャッシングとメモリー内データは、レプリケーション・ノード・ベースのストレージとして再設計することができます。

オンデマンド・レプリケーション
これはレプリケーション・ストラテジーのバリエーションです。この場合、現行のノードには通常のコミットが適用される一方で、ある論理的なポイントでコードがレプリケーションをトリガーするように設定することができます。さらに、同期ストラテジーを使用して、必要に応じてレプリケーションをトリガーすることもできます。

オンデマンド・レプリケーションは、各ノードがデータのそれぞれ異なる部分を処理し、論理的な手順でこれらの部分を結合する場合に役立ちます。MapReduce スタイルのプログラミング・モデルでは、このストラテジーを使用することができます。

フェイルオーバーを使用した片方向レプリケーション
マスター・ノードを割り当て、すべてのデータをマスター・ノードから子ノードにレプリケートするというのも、レプリケーションのバリエーションです。フェイルオーバーの間は、子ノードのいずれか 1 つがマスター・ノードになり、すべてのレプリケーションはその子ノードを起点に行われることになります。アプリケーションは常にマスター・ノードと連動します。高可用性を目的とした設計では、このストラテジーがファイルシステム共有ストラテジーと連携します。

ファイルシステム共有
ファイルシステム共有のストラテジーは一般に、レプリケーションにコストがかかるファイルシステム・ベースのリソースで使用されます。この場合、ファイルシステム自体がさまざまなノード間を移動して、ロード・バランシングを行います。このストラテジーによって、可用性が完全に実現されるわけではありませんが、ほぼそれに近いものが実現します。リレーショナル・データベースのファイルシステムは、この方法で処理することができます。

疎結合とステートレス性

ステートレス性は、呼び出しに必要なすべてのデータが使用可能であることと、リクエストを処理したマシンへの依存性が一切ないことを確実にすることで実現されます。疎結合は、呼び出しが置き換え可能であることを確実にします。HTTP ベースの REST または Web サービス呼び出しによって、この両方が確実になります。

弾力性

弾力性は、並列性サポートとトランザクション・サポートが適切に組み合わされること、そしてさらに重要な点として、実行がステートレスであり、したがって繰り返し可能であることを確実にすることで、実現されます。各実行のステートは、それぞれ個別に保持されます。オブジェクトの同じ 1 つのインスタンスで、複数のスレッドを実行させることができます。その場合、各スレッドはオブジェクトの個別の領域を受け持ちます。したがって、プール内に多数のオブジェクトがある必要はありません。一部のデータベース・プロバイダーでは、この機能に対処するための共有可能な接続をすでに提供しています。これは、20 から 30 の同時共有読み取りトランザクションには、平均して 2 から 3 の接続があれば十分であることを意味します。

トランザクションの所要時間が短くなればなるほど、弾力性には有利となります。したがって、長時間実行されるタスクは複数の繰り返し可能なステートレス・タスクに分割して、トランザクションのサイズを縮小するのが理にかなっています。

マルチテナンシー

マルチテナンシーは、アプリケーションの 1 つのインスタンスが実際には複数のクライアントに対応し、クライアントごとのデータを適切に分離できることを意味します。マルチテナンシーにはさまざまな設計上の考慮事項がありますが、コードをリファクタリングすることなく対処できる重要な考慮事項の 1 つは、異なる複数のテナントに対し、単一のストレージで対応するか、あるいは個別のストレージで対応するかです。

複数のテナントに共通のストレージ
これは、すべての顧客に 1 つの共通のストレージ・リソースだけが使用されることを意味します。この構成は保守しやすく、スケーラビリティーにも優れています。なぜなら、この構成には論理的な分離しかないことから、個々のデータ要素をそれぞれ別個のキーで暗号化できるためです。データベースでは、スキーマとパーティションがデータを論理的に分離し、XML では名前空間がデータを論理的に分離します。

テナントごとに分離された個別ストレージ
各顧客がそれぞれに固有のストレージを使用します。この場合、データは物理的に分離されます。このモデルが適しているのは、ポリシーがデータの機密性を決定付けるアプリケーションです。このように分離したストレージには、ルーティング・サービスを使用してアクセスし、過剰なプログラミング・ロジックによって複雑にならないようにする必要があります。

セキュリティー

分散ストレージおよびマルチテナンシーによって、セキュリティーに関する新たな要求が生じます。ストレージ、メッセージング、およびトランスポートのセキュリティーにも、セキュリティー・ストラテジーが対処しなければならないということです。さらに、ハイブリッド・クラウドや仮想プライベート・クラウドの実装には、クロスドメインのシングル・サインオンが必要になるため、フェデレーションも必要になってきます。

このようなセキュリティーに関する新たな要求は、それぞれのアプリケーションに固有のクラウドの特徴から派生するものなので、他の機能およびコードには影響を与えることなく実装することができます。


まとめ

以上で概説した方法論は、コンテナー・サービスでクラウドの特徴を実現し、アプリケーションをクラウドにマイグレートする際に役立つ設計ストラテジーとパターンを提供します。クラウド・リソース・パターンおよびクラウド・タスク・パターンは、再利用可能なパターンになるように設計されており、どのストラテジーが選択されるかはまったく想定していません。

この記事では、クラウド・アプリケーションを他に類のないアプリケーションにしている特徴と、これらの特徴に対応する Java EE コンテナーおよびアプリケーションの特徴を検討しました。そして管理対象リソース・パターンと管理対象タスク・パターンを、それぞれクラウド・リソース・パターン、クラウド・タスク・パターンに適応させて、コンテナー・サービスをクラウド・アプリケーションで使用できるように拡張する方法を紹介しました。

また、JEE コンテナーをクラウド・アプリケーションに統合することがクラウド・アプリケーションの設計ストラテジーに与える影響についても指摘しました。

最後に指摘しておく点として、管理対象リソースおよび管理対象タスクのパターンに拡張機能を実装するには、JCA (JEE Connector Architecture) が 1 つの選択肢となります。JCA が提供するフレームワークでは、ワーク、ライフサイクル、接続、およびトランザクション管理によってリソースを定義できるとともに、セキュリティー・アーキテクチャー、インバウンド通信、メッセージング・インフローを拡張することができます。

参考文献

学ぶために

製品や技術を入手するために

  • IBM Smart Business Development and Test on the IBM Cloud で使用できる製品イメージを調べてください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing, Java technology
ArticleID=678227
ArticleTitle=クラウドの特徴を備えるように Java EE コンテナーを拡張する
publish-date=06102011