レベル: 中級 Martin Brown, Developer and writer, Consultant
2007年 10月 30日 オープンソース・ツールを使ってグリッド・アプリケーションを開発することで、さまざまな可能性が生まれます。第 1 に、開発プロセスが非常に速くなります。特に、Perl や Python などのスクリプト言語と Apache のような開発環境を利用した場合にはそれが顕著です。また、参考として利用できる例が豊富です。オープンソース技術を使ってグリッド・ソリューションを開発する利点と欠点について調べてみましょう。
オープンソース・コンポーネント
オープンソース・コミュニティーには非常に多岐にわたるツールや製品が用意されてサポートされており、それらをとても容易にグリッド環境に活用することができます。オープンソース・ツールには、Linux® や BSD などのオペレーティング・システムから GNU CC などの完全な C/C++ 開発環境まで、ありとあらゆるソフトウェアと技術が含まれます。また、Perl のような使いやすいスクリプト言語や、Apache や Eclipse IDE (Integrated Development Environment: 統合開発環境) などのコンポーネントやツール・キット、開発環境も利用することができます。
これらのコンポーネントを個別に、あるいは組み合わせて使うことで、グリッド・ソリューションを構築することができます。その場合にはネイティブ・ソリューションを使うこともでき、あるいは、グリッドのデプロイメント環境 (Globus など) でよく使用される一連の WS-* サービスを含む、標準化されたグリッド・ソリューションを利用することもできます。
オープンソースのコンポーネントを使うことによる一般的な利点は、利用しやすく、また開発やデプロイメントが容易なことです。オープンソースのソフトウェアは無料で利用できるため、自分にとって適切なものが見つかるまで、さまざまなソリューションを使用し、デプロイし、そして試すことができます。
オープンソース・ツールを利用することで、作業をスピードアップできることもあります。これは、オープンソース・ツールが複数の人の協力による作業で開発されており、そうした人達がオリジナルのソース・コードを編集したり変更したりできるからです。そのため、個々の開発者が問題のあるコンポーネントや処理時間の長いコンポーネントを見つけてコードを修正あるいは変更し、使いやすくしたり、あるいはもっと便利なものにしたりすることができます。
しかし大部分のオープンソース・ソリューションに関して最も重要なことは、ニーズや要件に合わせてオリジナルのコードを自由に使用でき、編集でき、そして拡張できることでしょう。もし選択したツールで必要な情報を提供できない場合は、大部分の商用ツールではとてもサポートできない方法でそのツールを拡張したり、あるいはオリジナルのソース・コードを変更したりすることで、必要なことを実現できるのです。
ほとんどの場合には、オリジナル・ソリューションの柔軟性を利用すれば必要なことを実現できます。では、最も一般的なソリューションであるオープンソースのスクリプト言語によって実現できる機能と柔軟性を調べてみることにしましょう。
スクリプト言語を使う
オープンソース・モデルを活用できる重要な領域が、スクリプト言語の領域です。Perl や PHP、Python、そして Ruby などの言語は、どれも広範な機能を提供しており、これらの言語を利用することで、分散環境で使用するアプリケーションを素早く容易に開発することができます。
スクリプト言語を使用する場合には「作成、コンパイル、リンク、実行」という通常の手順に従う必要がないため、アプリケーションの開発は C/C++ を使用する従来のアプリケーションの場合よりもずっと迅速に行えることが多いものです。しかも、どのスクリプト言語にも、さまざまな Web サービス技術 (SOAP や XML-RPC など) に接続するためのライブラリーや拡張機能が提供されています。これはつまり、既存のインフラとのインターフェースをとるソリューションを非常に早く開発できる、あるいはグリッド・サービスをサポートするまったく新しい Web サービスを作成できるということを意味しています。
最近の大部分の Web ソリューションでは、Web サービスが重要部分となっていることが多いものです。Web サービスには、デプロイメントが容易で柔軟性があり、また互換性もあるという、いくつかの利点があります。例えば Web サービスのクライアントを、下記のスクリプトを使って Perl で開発することができます。
リスト 1. Web サービスのクライアントを Perl を使って開発する
#!/usr/bin/perl
use warnings;
use strict;
use SOAP::Lite;
print SOAP::Lite
-> uri('http://snode1:32080/')
-> proxy('http://snode1:32080/?session=store')
-> submit_image($image)
-> result;
print "\n";
|
この例は、写真の保存システムを実装する、Perl で作成されたグリッド・ソリューションから引用したものです (「参考文献」に挙げたチュートリアル・シリーズ「Building a Grid with Perl」を参照してください)。この例では SOAP::Lite モジュールを使って SOAP クライアントを作成しています。そして、グリッド・ノード snode1 のポート 32080 のWeb サービスにアクセスし、画像をシステムに送信しています。
グリッド内の個々のサーバーの構成を単純にするには、Perl の内部ハッシュ型を使います。これを下記に示します。
リスト 2. Perl の内部ハッシュ型を使う
$node = {
'name' => 'linux-grid-1',
'type' => 'snode',
'remote => 'snode1',
'gridid' => '43729810-09399528-817022102',
'grid' => 'image-grid-1',
'nodeid' => '57175600-10287415-53438102',
'distributorid' => '',
'distributor' => '',
'verification-id' => '',
};
|
ある写真がグリッドに送信されると、個々のノードが生成する情報を使って、それらのノードのストレージが現在利用可能かどうかを追跡し、あるノードを選択して (Perl の Dumper を使って) 情報をシリアライズし、データベースに保存できる構造にします。
グリッド全体にわたって情報を分散させるためには、現在未解決の要求のリストを取得し、さらにプロバイダー (グリッド・ノード) のリストを処理してから、SOAP インターフェースを使って最終的な作業単位をターゲット・ノードに分散させます。既存の項目に対するノードの検索は、それとはほとんど逆です。つまり既知のノードそれぞれに対して検索を依頼し、そしてそのレスポンスを照合します。
リスト 3 は別の例で、すべて Python で作成された計算グリッドの例です。このソリューションでは Web サービスを利用しているだけではなく、スクリプト言語としての Python 言語の柔軟性も利用しています。
大部分の計算グリッド用に、計算を実行して結果を返すアプリケーションを開発する必要があります。Python を使うと、計算を実行する Python スクリプトを分散させることができます。これにより、スタンドアロンのアプリケーションで提供される機能に限定されることなく、任意の Python スクリプトを分散方式で処理できる、完全な柔軟性を実現することができます。
グリッド機能の中核は Web サービスです。この場合は軽量に実装できる XML-RPC を使った Web サービスです。下記は、その中心的なプロバイダーである (グリッド・ノードの) Python モジュールを示しています。
リスト 3. Python で作成された計算グリッド
import time,sys
sys.path.append('..')
import DWGrid
from xmlrpclib import Server
gridspec = DWGrid.DWGrid()
provider = DWGrid.DWGridProvider(gridspec,'sulaco','192.168.0.101')
provider.register_component()
distributor = Server(gridspec.distributor)
def get_workunits():
global provider,gridspec
items = distributor.getworkunits(5)
counter = 0
for item in items:
gridspec.workunitqueue.add(item,'queue',item['_workunitid'])
counter = counter+1
return counter
def run_calculation(item):
workunit = provider.grid.workunitqueue.get(item,'queue')
distributor.log_status(provider.name,1)
gridspec.workunitqueue.move(workunit['_workunitid'],'queue','active')
modulename = workunit['calctype']
try:
exec 'import calculate_' + modulename + ' as calculate'
except:
(result,moduledata) = distributor.get_service_byname(modulename,'module')
if (result == 0):
modulefile = open('calculate_%s.py' % modulename,'w')
modulefile.write(moduledata)
modulefile.close()
try:
exec 'import calculate_' + modulename + ' as calculate'
except:
gridspec.workunitqueue.move(workunit['_workunitid'],'active','queue')
print "Error, module recovered from server does not load"
sys.exit(1)
else:
print "Error, module %s from server doesnt exist" % (modulename)
gridspec.workunitqueue.move(workunit['_workunitid'],'active','queue')
sys.exit(1)
distributor.log_event('log',provider.name,
'Starting Processing Workunit ID %s' % (item))
calcfunc = calculate.DWGridComputational()
result = calcfunc.execute(workunit['args'])
distributor.log_event('log',provider.name,'Finished Processing
Workunit ID %s' % (item))
workunit['result'] = result
gridspec.workunitqueue.move(workunit['_workunitid'],'active','complete')
gridspec.resultqueue.add(workunit,'queue',workunit['_workunitid'])
def put_results(items):
for resultid in items:
workunit = gridspec.resultqueue.get(resultid,'queue')
gridspec.resultqueue.move(resultid,'queue','active')
try:
distributor.putresult(workunit)
except:
gridspec.resultqueue.move(resultid,'active','queue')
return
gridspec.resultqueue.move(resultid,'active','complete')
while 1:
# first thing we need to do is check if there is anything
# in our queue that needs calculating
items = provider.grid.workunitqueue.list('queue')
if len(items) > 0:
run_calculation(items[0])
else:
count = get_workunits()
if count == 0:
distributor.log_status(provider.name,0)
time.sleep(60)
continue
items = provider.grid.resultqueue.list('queue')
if len(items) > 0:
put_results(items)
|
このモジュールには圧倒されるかもしれませんが、ここにはグリッド・コンポーネントを実行する下記のコアとなる要素があるのです。
-
get_workunits() は分散ノードにアクセスして未解決の作業単位のリストを取得します。
-
run_calculation() は計算に必要な Python モジュールを抽出し、そのモジュールを外部ファイルに保存し、組み込みの計算メソッドを実行する準備が整ったファイルをロードして実行し、その計算結果をプロバイダーの内部キューに追加します。
-
put_results() は完了した結果を取得し、それらを分散ノードに送信します。
この Python によるソリューションあるいは他のオープンソースによるソリューションを使うことで開発期間の短縮にどれほど効果があるかの一例を示すと、Python ベースのグリッド・ソリューション全体のコードが 300 行をわずかに上回る程度になります。しかもこのソリューションは (登録要素や分散要素、データ収集要素など) さまざまな実行モジュールや結果を処理するために十分な柔軟性を備えています。
オープンソースのライブラリーと環境
ここまで、オープンソースのツールを使うことでニーズや要件に合わせてオリジナルのコードを編集でき、変更できるというメリットがどの程度のものなのか説明してきました。しかし多くの場合、そうした編集や変更は必要なく、必要なツールと機能は既に用意されています。これはそうしたツールや機能がオリジナルのソリューションに組み込まれているからではなく、そうしたソリューションが最初から柔軟で拡張性が高いことが多いからです。
提供されているいくつかの主な環境を見る前に、多くのスクリプト言語で提供されている基本的なライブラリーや拡張機能を無視すべきではありません。Python と PHP には、そのまま使用できる非常に広範な種類の標準モジュールや機能が用意されています。また、サードパーティーによる拡張機能も非常に豊富にあります。Perl には、よく知られたモジュール・ライブラリーである CPAN (Comprehensive Perl Archive Network) があります。
オープンソースの環境としては、数多く存在するさまざまなコンポーネントの機能を組み合わせて 1 つのシステムにし、そのシステムを使って異なるタイプのアプリケーションを開発およびデプロイすることができるような (オープンソース技術に基づいて構築された) 環境がいくつかあります。ここで説明するオープンソース環境は、すべてがグリッド・ソリューションの開発を明確なターゲットにしているわけではありませんが、大部分の環境はグリッド・ベースのソリューション開発のベースとして適合させたり変更したり、あるいは使用したりすることができます。
LAMP とそのバリエーション
オリジナルの LAMP 環境は、Web サイトを作成するために使われる Linux オペレーティング・システムと Apache HTTP サーバー、MySQL データベース、そして PHP ツール・セットを組み合わせたものを指しました。やがて汎用の LAMP からいくつかのバリエーションが生まれ、また多様化が進みました。例えば、「P」は、PHP 以外にも Perl または Python ベースの環境を指すためによく使われ、また Ruby または Ruby on Rails ソリューションを指す「R」で置き換えて LAMR になることもあり、また Java™/JSP 環境を指す「J」で置き換えられることもあります。
「L」が Windows® で置き換えられ (WAMP)、それが今度は WIMP (Windows と IIS) に、SAMP や (Solaris)、MAMP (Mac OS X) に、さらには BAMP (BSD) にもなりました。MySQL も PostgreSQL で置き換えられています (LAPP)。また商用の環境やアプリケーションも追加され、例えば WASP (Windows、Apache、SQL Server、そして PHP) や OPAL (Oracle) などの頭字語も生まれました。
LAMP バンドルは Web サイトの開発とデプロイメント用に作られたものであり、個々の要素の最適なもの (その多くが既に組み合わされ、使われています) からいくつかを組み合わせたものです。この、個々のツールを組み合わせて 1 つのバンドルにしたものはグリッドの開発を想定して作られたものではありませんが、これを利用することでグリッド・ベースのソリューションの開発とデプロイメントを非常に容易に行うことができます。
グリッドのデプロイメントを行う際には、典型的なグリッド・ソリューションのさまざまな部分を処理するために LAMP の各ツール (下記) を活用することができます。
- Apache は強力な HTTP サーバー・プラットフォームとして、さまざまなアプリケーションやスクリプトに対してスケーラブルな環境を提供します。また Apache を使うことでセキュリティー機能や追跡機能を提供することもできます。
- MySQL と PostgreSQL、そして Apache Derby は、どれも非常に効率的なリレーショナル・データベース・ソリューションです。典型的なグリッド・ソリューションでは、これらのリレーショナル・データベース・ソリューションを使用することで、集中型のストレージとリソースを提供することができます。
- Perl、Python、PHP、Ruby その他はどれも、迅速なアプリケーション開発に適したスクリプト環境を提供します。また Web サービスやセキュリティーなどの特別な機能を提供する、広範な種類の強力なライブラリーと拡張機能を呼び出すこともできます。
LAMP またはそのバリエーションのソリューションを利用すると、非常に短い期間での開発プロセスを実現できることに加え、デプロイメントのプロセスも容易かつ短い期間のプロセスにすることができます。大部分の Linux ディストリビューションには、標準で LAMP ツール・キットが同梱されています。従って LAMP 環境を使用するグリッドの構築は、Linux ベースの個々のグリッド・ノードをインストールして設定し、そしてグリッド・アプリケーションのスクリプトをノードにデプロイするという、単純なケースがほとんどです。
Apache の Java ツール・キット
Java そのものは厳密にはオープンソースではありませんが、Web サーバーや Web サービスなどのコア機能を提供するための、またいくつかのグリッド専用ツール・キットを作成するための、膨大な種類のオープンソースのツール・キットやライブラリーが Java 技術の上に構築されています。入手可能なさまざまなツール・キットの中でも重要なものは、Apache Software Foundation が提供するものです。
Apache では、グリッド環境を構築する際に使用できる一連のツール (下記) が作成されています。
- Apache Tomcat は Java ベースの Web サーバー環境であり、Java アプリケーション用の基本的なファイルや Web ベースのソリューション (JSP やサーブレットなど) の共有に使用することができます。Tomcat は多くの場合、基本的なサーバー環境として、Apache Java ツール・キットの他の多くのツールに使用されます (それらのツール自体が同じ JSP/サーブレット技術をベースにしています)。
- Axis は SOAP による Web サービス・ソリューションの実装です。Axis 2 は Axis を再開発したものであり、SOAP だけではなく REST (Representational State Transfer) など他のソリューションもサポートしています。Axis2 ツール・キットには WS-Reliable Messaging や WS-Coordination、WS-Security、そして WS-Addressing など、いくつかの重要な Web サービスの実装が含まれており、これらはどれも、Web サービスをベースにする最近のグリッド環境の主要部分と見なされています。
- Apache Muse は、WS-ResourceFramework と WS-BaseNotification、そして WS-DistributedManagement 標準を実装したもので、これらの標準も Web サービスをベースにする多くのグリッド環境の重要な要素です。Muse も Axis/Axis2 も、コアとなる HTTP プロトコルを Tomcat による Web サーバー環境によって提供しています。
これらの多くのサービスを組み合わせ、また Web サービス・ベースのさまざまなソリューションで提供される機能を利用することで、Web サービス・ベースのグリッド・ソリューションを容易に構築することができます。「参考文献」には、グリッド・ソリューションの構築にさまざまな Apache ツール・キットを利用したチュートリアルや記事、そしてソリューションのリストを挙げてあります。
上記のソリューションはどれもオープンソースですが、Apache Software Foundation によって強力にコントロールされ、進められています (Apache Software Foundation では、個々のプロジェクトが目標を守り、その目標に集中した活動をするように、開発者やアーキテクトのグループが統制を行っています)。
ActiveGrid
ActiveGrid システムは、その名前が示すようなグリッド専用の開発およびデプロイメントの環境ではなく、また真のオープンソースでもありません。ActiveGrid はグリッド・スタイルの技術を利用したアプリケーションを LAMP ツール・キットを利用して開発するための環境であり、ActiveGrid を利用すれば高度な分散ビジネス・アプリケーションの開発を行うことができます。
ActiveGrid システムは、アプリケーションの設計と開発のための ActiveGrid Application Builder と、アプリケーションのデプロイメントに使用する ActiveGrid Application Server という 2 つのコンポーネントに依存しています。
ActiveGrid システムの目標は、個別の小規模アプリケーションの開発に使用できる小さくてスケーラブルなコンポーネントを提供することではなく、グリッド環境を利用した本格的なアプリケーションを開発することです。
まとめ
この記事では、オープンソース技術を利用してグリッド・ソリューションを開発することの利点と欠点を見てきました。この記事で紹介した例や情報から得られる重要な項目としては、使いやすさと開発の速さが挙げられるでしょう。スクリプト言語によって実現される迅速な開発が可能な環境と、数多くのオープンソース・ライブラリーやその他のソリューションとを組み合わせることで、グリッド・ベースのソリューションを非常に迅速かつ容易に構築することができます。
この記事で詳細に説明した Perl と Python によるソリューションはどちらも、グリッド・ソリューションを開発するための、他の大きなシリーズから引用したものです (「参考文献」を参照)。
参考文献 学ぶために
製品や技術を入手するために
-
IBM 製品の試用版をダウンロードし、DB2® や Lotus®、Rational®、Tivoli®、WebSphere® などが提供するアプリケーション開発ツールやミドルウェア製品をお試しください。
- 皆さんの次期開発プロジェクトを IBM trial software で革新してください。ダウンロード、あるいは DVD で入手することができます。
議論するために
著者について  | 
| | Martin Brown は、プロのライターとして 8 年以上の経験を持ち、さまざまな分野で多数の本と記事を執筆しています。専門分野は、Perl、Python、Java、JavaScript、Basic、Pascal、Modula-2、C、C++、Rebol、Gawk、Shellscript、Windows、Solaris、Linux、BeOS、Mac OS/X など数え切れないほどの開発言語とプラットフォーム、そして Web プログラミング、システム管理、そしてシステム統合にも及びます。彼は ServerWatch.com、LinuxToday.com、IBM developerWorks の定期的なコントリビューターで、Computerworld、The Apple Blog、そして Microsoft の SME (Subject Matter Expert) などのサイトでもお馴染みのブロガーとなっています。連絡先は彼の Web サイト、http://www.mcslp.com です。 |
記事の評価
| 
