レベル: 中級 Abel W. Lin (awlin@ncmir.ucsd.edu), Software Architect, National Center for Microscopy and Imaging Research
2006年 5月 02日 「統合グリッドの構築」シリーズでは、エンドツーエンド・プロセスをグリッド対応にするために必要なコンポーネント実装を中心に説明してきました。第 1 回では、エンドツーエンド・プロセスをグリッド対応にすることの意味について考察し、National Center for Microscopy and Imaging Research (NCMIR) の Telescience Project で開発されたグリッド・ベース・システムのアーキテクチャーについて説明しました。第 2 回では、エンドツーエンド・プロセスにとってグリッド・インターフェースが非常に重要である理由と、オンデマンド形式でリソースを統合することにより、より質の高いデータをより速く収集する方法を取り上げました。第 3 回では、Telescience ATOMIC パッケージの統合認証と認可のバンドルについて説明しました。今回は、Telescience アーキテクチャー内でのワークフローの使用について考察します。
なぜワークフローなのでしょうか。ワークフローとは何でしょうか。
第 1 世代のグリッド (およびその前身のスーパーコンピューティング・センター) のユース・モデルは、航空路線におけるハブ・アンド・スポークのモデルと似ています。ハブとしては、ユーザーのデータ環境が使われます。ユーザーは、各ステップごとに、全国にある個々の仮想組織にログインして、データを渡し、ジョブを実行（スポークに相当）する必要がありました (図 1 を参照)。
第 1 回で触れたように、オンデマンドの世界では、データは、自動的に保持され、計装（instrument）から計算、分析へと自ずと流れていきます。分析結果は、中央のハブを経由することなく計装に直接伝えられ、データ収集パラメーターや手法を洗練するためのフィードバックに絶えず自動的に使用されます。このような要件に対応するためには、グリッド・アプリケーションは、あらゆるものを網羅するモノリシックなプログラムとしてはもはや構築されず、むしろ既存のプログラム・コンポーネントを利用して構築されます。ワークフロー・ツールは、プログラム・コンポーネント間に跨るアクティビティー (たとえば、認証やデータの入出力) を管理するために必要なツールとして一般的に定義されます。ワークフロー・ツールを使用することで、オンデマンド統合グリッドに必要な Point-to-Pointのプロセスが可能になります。
図1. ハブアンドスポークと Point-to-Point プロセスの比較 (実線はデータ転送、点線はユーザー・モニター・ツールを指しています)
ワークフローを使用する上での課題
コアのグリッド・ツール(主要なWeb サービス API に対して、現在バンドルされているApplication to Middleware Interaction Component (ATOMIC) )と同様に、Telescience Project には相補的な多数のワークフロー・ツールがありますが、機能にはまだ重複があります。コアのグリッド・ミドルウェア・コンポーネントに比べて、現在採用され始めたばかりのワークフロー・ツールは、更なる大きな変化の途上にあります。
これらのワークフロー・ツールは、以下の階層クラスに分類されます。
ワークフロー・ツール
| ワークフローのタイプ | 説明 |
|---|
| プロセス管理 | 最上位レベルの科学的(研究室)プロセスの枠組みを構成し、ポリシー、プロセス、状態管理や運用ツールを通じて、より下位レベルのワークフローを調整および管轄し、また、科学研究 (またはその研究内のインスタンス) を構成するパイプラインを提供します。 | | インターアプリケーション | 計算オペレーションを効率化するパイプライン・ツールまたはプラン策定ツールです。 | | イントラアプリケーション | ヘテロな物理リソース群の上でのプラン実行を最適化するプランナーおよび実行エンジンです。 |
Telescience ワークフローのアプローチは、ワークフロー・レイヤ間でのステートフルな情報の調整および共有を効率化することです。各レイヤには独自の機能と要件があります。プロセスおよびステート管理ツール（標準的にはポータル・ベース）は、ユーザーに関するコンテクスト情報を保持および委譲するために必要です。コンテクスト情報には、プロセス管理、科学プロセスの管理、認証と認可、上位フローの状態、等に関する情報が含まれます。Telescience Project では、これらの情報の多く (例えば、認証・認可の情報) は、ATOMIC ツール・キット API を経由して下位のワークフローに渡されます (第 3 回の図 1 を参照)。
インターアプリケーション・ツールは、プロセス・パイプラインを作成します。プロセス・パイプラインは、最上位階層の実験プロセス管理ワークフローのサブ・コンポーネントです。これらのツールは、主にユーザー駆動の GUI 環境で、プロセス管理ワークフロー内部の手順を操作するツールであったり、或いは、プロセス管理ワークフロー自体を必要に応じて提供する汎用的なツールであったりします。最下位階層のイントラアプリケーション・ワークフローは実行可能プランから構成され、それらはヘテロな物理リソース・プールにマップされていきます。Telescience Project について述べれば、ワークフロー・コントローラーとしてはポータルが使用されており、イントラアプリケーションクラスのワークフロー・ツールが、科学計算のアルゴリズムをグリッド環境に取り込みます。
ワークフロー・コントローラーとしてのポータル再解説
科学者が従事するエンドツーエンド・プロセスは、実験の構想から始まり、実験結果を積み重ねて最終的な発見に達するまでのステップの全体として定義できます。その中には、当初の計画、情報収集・データ取得・分析のプロセス、および一つあるいは多くのデシジョンポイントにおけるこのプロセスの繰り返しが含まれます。研究プロセスは、ストーブの煙突のように単なる直線的なプロセスではありません。動的で、高度に逐次化されたプロセスであって、そこでは、ユーザーとの相互のやり取りが何度も行われ、データの可視化、およびフィードバックが行われます。このフィードバックを可能にすることが、統合グリッドの目標です。
ワークフローの観点では、研究プロセスが、ワークフロー・ツールの階層での第一次のワークフローであり、直接エンド・ユーザーとやり取りする最初のワークフロー・レベルで、もあります。第 2 回で説明したように、Telescience のインフラストラクチャーは、チームが、個々のアクションとのインターフェースというレベルを超えて、グリッド・ミドルウェアではなくプロセスに従って自動化された、よりリッチなユーザー環境へ統合することを可能にします(第 2 回の図 2 を参照)。ポータルは、この役割を担うために、プロセス・ワークフロー管理により重きをおき、コンポーネントの状態情報と永続情報の管理をすることがより重要になりました。それに対して、アプリケーション・コンポーネントを起動させる機構は、ハブとスポーク処理用の第 1 世代のグリッド・ポータル実装の場合に比べ重要でなくなりました。従来、ポータルはワークフロー・ツールとしては考慮されていませんでしたが、我々のチームは、アプリケーションおよびワークフロー情報の配信にポータルが非常に重要であることに気づいたわけです。
イントラアプリケーションのワークフロー
ポータル・ワークフロー・コントローラーの目標は、「作業を行う」アプリケーションのアクティビティーを調整することです。これらのアプリケーションは、単にグリッド管理下のデータへのアクセスを必要とするだけのスタンドアロン・アプリケーションの場合もあれば、おびただしい数のヘテロな計算リソースやデータ・リソースを使用する複雑な並列アプリケーションの場合もあります。
強大なモノリシック構造物だった第 1 世代のグリッド・コードと異なり、これらのコンポーネント・モジュールは小型で動的です。傾向として「心地よい並列」である初期のコードとは異なり、現在のコードはヘテロな並列であり、多くの場合、計算処理を開始する前に、複数の先行コンポーネントが完了する必要があります。この並列へテロ状況に、さらにリソースのヘテロ状況が合わさって、ワークフローを抽象的に計画及び実行する高度なワークフロー計画ツールおよび実行ツールが必要となります。これは多くの科学コミュニティに共通する要求であって、既にいくつかのツールが存在します。
Planning for Execution in Grids (Pegasus) 環境は、もともとTelescience Project 内で使用されてきたワークフロー計画ツールです。Pegasus は、複雑な科学ワークフローをグリッドなどの分散リソースにマップするフレームワークです。Pegasus が、抽象的なワークフロー記述を実行可能な形式にマップし、Condor Directed Acyclic Graph Manager (DAGMan) が実行可能なワークフローで指定されたジョブを実行します。Pegasus と DAGMan がワークフローを、マップし、実行するのは、Condor プール、LSF または PBS によって管理されているクラスター、TeraGrid ホスト、および個々のホストです。
Pegasus が扱う、抽象的なワークフロー記述では、分析はアプリケーション・コンポーネントとそのコンポーネントが使用するデータによって記述されます。ワークフローが抽象的というのは、実行に必要なリソースを指定していないからです。Pegasus はこの抽象的なワークフロー記述を受け取り、必要な計算リソースを指定した実行可能なワークフローを生成するとともに、計算処理の入出力データを準備するデータ管理のノードを含めます。新しく生成されたデータ成果物を後で見つけられるよう、登録するための追加のワークフロー・ノードも追加されます。
すべてを統合する
Telescience モデルでは、ポータル環境に、より下位のワークフロー・クラスが必要とするユーザーとセッションの状態に関するすべての関連情報を管轄することが求められます。ポータルがユーザー情報と状態の管轄者であるのに対して、ATOMICは配送車両で、与えられたプロセスで必要適切な情報へのアクセスをダウンストリーム・アプリケーションやワークフローに提供します。このようなセッション情報の抽象化は、ワークフロー・クラスを跨る遷移があってもシームレスなユーザー環境を保つために必要であり、将来のワークフロー・テクノロジーの開発ニーズに合わせた拡張可能性があります。
図 2 は、エンド・ユーザーによって開始された複数クラスを持つ典型的なワークフローのハイレベルの概要です。ユーザーは、科学的プロセスのメイン・ワークフロー・コントローラー・ポートレットから、外部アプリケーション (この例では、Telemicroscopy 制御セッション) を起動します。ログインに際して、ポータルがセッション情報を管轄し (例えば、認証パラメーターおよびデータ管理パラメーター)、実行時に ATOMIC ツールおよびサービスを経由してアプリケーションに渡されます。これらのパラメーターを使用して、アプリケーションはより下位のワークフロー・クラスを開始します (この例では、Pegasus が計画した、ヘテロな計算リソース群で処理する断層画像からの並列的な3次元再構成（tomographic volume reconstruction)のワークフロー)。
次世代の ATOMIC Web/グリッド・サービス・ベースの実装では、さらに外部アプリケーション・レベルとメインのポータル・ワークフローにおける進捗を動的に通知できるようになります。すべては、シームレスなユーザー環境で行われ、ワークフロー・クラス間の遷移に伴う典型的なオーバーヘッドは、エンド・ユーザーにもアプリケーション開発者にもかかりません。たとえば、現在のアプリケーションを変更しなくても、Pegasus 内によりしっかりとしたリソースおよびネットワーク検出ツールを組み込めることが期待できます。
図2. Telescience Portal
結論
データあるいは情報の取得から、最初のデータ取得の帰結としての最終的な発見までの間に起こるすべてのステップを網羅するオンデマンド統合グリッドを定義しようとしたら、単一のグリッド・ミドルウェアやワークフロー・ツールではこのニーズに十分に対応できないことは明らかです。複数の相互運用可能なツールの統合によってのみ、これに対処することができます。
このシリーズでは、中核的なグリッド・コンポーネント (ATOMIC) のバンドルによる統合、およびより大規模なアーキテクチャー内でのワークフロー・ツールの階層的な利用を示しました。次の最終回では、オンデマンド統合グリッドを可能にするTelescience アーキテクチャーを利用した Telescience Project の具体的な応用例を紹介し、将来の開発および課題について考察します。
参考文献 学ぶために
議論するために
著者について  | | | Abel W. Lin is the architect and technical lead for the Telescience Project at the National Center for Microscopy and Imaging Research. He has more than five years' experience applying grid and other computer science technologies to scientific processes. He designed and led the implementation of the first-generation proof-of-concept systems for the Telescience Portal and ATOMIC components of the Telescience Project, and is an interdisciplinary scientist with published research in biology and computer science. His interests include distributed systems architecture, software project management, and structural biology. Outside of the office, he is an avid reader, golfer, and bodysurfer.
|
記事の評価
| 
