BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース 並行処理フレームワークのJPPF、負荷分散とフェイルオーバー、J2EEインテグレーションを提供

並行処理フレームワークのJPPF、負荷分散とフェイルオーバー、J2EEインテグレーションを提供

ブックマーク

Java Parallel Processing Framework (JPPF、Java並行処理フレームワーク)のプロジェクトチームは先日、JPPF 1.0 のリリース候補初版(Release Candidate:RC1)を発表(サイト・英語)した。JPPF(サイト・英語)はオープンソースのグリッド・コンピューティング・フレームワークであり、これを使用して様々なJavaアプリケーションを分散実行環境で並行して動かすことができる。
 

JPPF のアーキテクチャ(source)は、クライアント、サーバそしてノードと呼ばれる3つの主要なコンポーネントから成っている。このフレームワークの動作の仕組みは、多くのタスクを引き受けて、その実行をいくつかのノードに割り当て、そして全ての処理の実行が終了すると、結果を再構成してクライアントに送り返す、というものである。

JPPF は、負荷分散やフェイルオーバー、そしてリカバリといったサービスも提供する。JMXを用いた管理コンソールにより、実行されたタスクはもちろん、ノードのモニタリングも可能である。タスクは、リモートでキャンセルやリスタートをしたり、あるいは指定の日時や一定時間が経過した時点でタイムアウトするように設定することができる。

このフレームワークは、ネイティブのグリッド・アプリケーションへのアクセスをサーバに提供する、JCA 1.5 準拠のリソース・アダプタを使用しているJ2EEアプリケーションサーバと統合する。リソース・アダプタは、JTAのトランザクション・タイムアウトのいかなるリスクをも排除するため、非同期のタスク実行を実装している。JPPFは以下のアプリケーション・サーバをサポートしている。

InfoQはこのフレームワークの作者であるLaurent Cohen氏に会い、JPPFの並行処理の性能やプロジェクトの今後のロードマップについて話を聞いた。バージョン1.0 GA(一般入手可能版)のリリースについて、Laurent氏は、来月のGAリリースを計画していると話した。

JPPF フレームワークと、JDK 1.5から導入されたjava.util.concurrent APIとの比較について答え、Laurent氏は、たくさんのプロセッサを積んだ1台のコンピュータという環境では、JPPFは java.util.concurrentパッケージのクラス群を直接使用するよりもかなり遅くなるだろうと述べた。しかし、アーキテクチャが複数のマシンのネットワークの場合、JPPFは、JDKの並行処理クラス群に比べ、すぐれたソリューションである。JPPFは、そのアーキテクチャを構成するあらゆるコンポーネントで、内部的にjava.util.concurrent APIを使用している。ノードは、ExecutorService(サイト・英語)インタフェースを使用して、タスクのマルチスレッド処理を行うように設定されている。

Javaの並行処理APIの一部としてJava 7に導入されるであろう重要な特徴は、きめの細かい並行処理の要求に使用されるfork-join(サイト・英語)のフレームワークである。InfoQでは、JPPFで利用可能な同様の特徴があるかを尋ねた。彼の回答は以下のとおりである。

これは、JPPFが当初から目的としてきたことです。JPPFは、多くのタスクを引き受け、その実行をノードに分散し、そしてその結果を適切なフォーマットで再構成するように設計されました。この点で、JPPFはfork-joinフレームワークを派生し、分散させたものと考えることができます。

JPPFはGigaSpaces(サイト・英語)やTerracotta(サイト・英語)、GridGain(サイト・英語)といった他のオープンソースのパラレル・コンピューティング・フレームワークと比較するとどうか、という質問に答え、Laurent氏は次のように言った。

スコープや機能性の点から見ると、GridGainはJPPFに最も近いオープンソース・フレームワークです。両者の違いは実装のアーキテクチャにあります。分散処理の実現に、GridGainはピア・ツー・ピアのトポロジを使っていますが、JPPFでは何層にもわたる(マルチ・ティアの)アーキテクチャを使用しています。

Terracotta は考え方が非常に異なります。彼らの分散JVMの実装はすばらしい成果ですが、しかしながら、本質的にグリッド・コンピューティング・フレームワークではありません。Terracottaはクラスタリングに最適で、分散キャッシングやトランザクション管理、レプリケーション等のきわめて重要な特徴を提供します。

 GigaSpacesやGlobus Toolkit(サイト・英語)がより大きなものを管理するのに対し、JPPFは1つの組織内のローカルなトポロジを実装しており、これらのフレームワークと調和が取れます。

JPPFにおける負荷分散の実装の詳細に関して、彼は以下のように説明した。

アプリケーションは集中型のJPPFサーバにタスクを送信し、"タスク・バンドル"として分類されます。ノードの性能情報 (これは動的に計算されるのですが )にもとづき、バンドルはいくつかのサブ・バンドルに分割され、各ノードに送信されます。各サブ・バンドルのサイズは、そのノードの過去の実績に応じて計算されます。性能情報は絶えず再評価され、フレームワークは新しく変化していく条件に自動的に適合されます。性能情報には、アプリケーションによって送信されるタスクの種類や数、実際にサーバに登録されているノードの数等が含まれています。

そして、フェイルオーバーの性能については、次のように述べた。

フェイルオーバーはJPPFアーキテクチャの全てのコンポーネントで実装されており、3つの主要なメカニズムである、動的なトポロジと障害検知、そして自動的な再送信に依存しています。JPPFのコンポーネントは、いつでも任意の順で、ネットワークに追加したり削除したりできるのです。

Laurent氏は、2つの典型的な障害の事例と、そういった場合にJPPFがどのように別のノードへと障害を迂回するかを話した。

1つめの事例は、ノードが故障したり、突然サーバから切断された場合です。サーバは障害を検知し、完了しなかった作業を自動的に別のノードへと送信するでしょう。

2つめの事例は、クライアントがサーバから切断された場合です。クライアントは、接続に成功するか任意に指定されたタイムアウトが発生するまで、自動的にサーバに再接続しようとするでしょう。その間、クライアントがたくさんのサーバに接続するように構成することができます。サーバ群は、効果的なフェイルオーバーの戦略を特徴付ける、サーバのコネクションプールの階層構造になっています。そしてクライアントは、階層構造の中の隣のサーバに作業を再送信するでしょう。

JPPF フレームワークはどのようにアプリケーションレベルのセキュリティをサポートしているのか、という質問に答え、氏は、JPPFはアプリケーションで使用されているどんなセキュリティ・フレームワークでも、透過的な方法で使用する、と言った。さらに、JPPFのノードには設定可能なセキュリティ・ポリシーがあり、クライアントのコードがノードのホスト上で出来ることや出来ないこと(例えばファイルシステムへの書き込み/読み取りや、他のサーバへの接続等)をポリシーで定義する。

最後に、JPPFフレームワークの今後のリリースについて、Laurent氏は、ビジネス・ルール・エンジン(例えばILOG Inc(サイト・英語)やJBoss Rules(サイト・英語))やWebサービスとの統合があるだろうと言った。さらに、データ・ウェアハウジング・システムに保存された大きなデータ集合からのデータ検索において分散処理が重要な役割を果たす、ETLやビジネス・インテリジェンス(BI)、データ・マイニング等の分野のツールとの統合もあるだろう。

JPPF プロジェクトは、2年前にSourceForge.net(サイト・英語)の1つとして始まった。現在は、Apache License Version 2.0(サイト・英語)の下で許諾されており、JPPFの最新バージョンはSourceForgeプロジェクトのWebサイト(source)からダウンロード可能である。

原文はこちらです:http://www.infoq.com/news/2007/11/jppf-1.0

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

BT