グリッド化の決断を下すとき
グリッドアーキテクチャを用いる理由
新規アプリケーションの設計時には、多くの理由から基本プラットフォームでのグリッドアーキテクチャの採用を検討すべきである。グリッドコンピューティングのフレームワークであるグリッドアーキテクチャは、データを処理する独特のプラットフォームを提供し、従来に代わるコスト効率に優れたアーキテクチャになり得る。シングルサーバアーキテクチャに比べると、グリッドアーキテクチャには並列処理、リソースの負荷分散、未使用リソースの活用といった多くの利点がある。従来のサーバ環境におけるアプリケーションの発展は、サーバのハードウェアの限界に達している。同じサーバ上で実行されるほかのアプリケーションとの間には、リソースの競合も起きている。かといってハードウェアをアップグレードするとなると、アプリケーションの実行を止めなければならないのが普通だ。アプリケーション配信の信頼性は、サーバの健全性に依存しており、それはクラスタ環境の利用によって補える。だが、クラスタによって冗長性は得られてもリソースが増えることはない。
グリッドアーキテクチャでは（クラスタとは）別の方法が取られている。1台のサーバに限定することなく複数のコンピュータにアプリケーションの処理を割り当てるため、アプリケーションの実行を止めずにリソースを追加できる。こうした仮想環境では、単一障害点（そこに障害が生じるだけでシステム全体が停止するような箇所）の問題が解消され、ジョブを投入（submit）するユーザから見たパフォーマンスも向上する。メモリ、プロセッサ、ディスク領域はもちろん、ジョブ管理さえも、1台のコンピュータであるかのように機能する複数のマシンで扱われるため、どのマシンもアプリケーションを単独で実行することがない。一見、余計にコストがかかりそうだが、実はコストの面で利点がある。既存マシンの遊休リソースを使うことにより、グリッドコンピューティングはリソースの有効活用によるコスト削減を実現し、新規ハードウェア購入の必要性を抑えているのだ。
グリッドアプリケーションの例
グリッドアーキテクチャはまだ成熟していないと考える人もいるだろうが、このアーキテクチャをすでに採用したプロジェクトはいくつか存在する。ヒトたんぱく質解析プロジェクト（Human Proteome Folding Project）は、グリッドテクノロジを使ったヒトゲノムの機能解明に注力している。ヒトゲノムは2003年に完全解読が終了したが、その30,000ものタンパク質がどのような働きをするのか、また解読結果が生命科学にどのように役立つのかについては今後明らかにしていく必要がある。最新のコンピュータ1台ですべてのヒトゲノムを解析しようとすると計算に100万年もの時間がかかりかねない。そこで、科学者たちはデータを分割して、計算グリッドを構成する何百台というコンピュータに送信している。
最もよく知られているグリッドアプリケーションとして、世界的な学術研究アプリケーションがある。また、グリッドアーキテクチャを使ってイントラネット情報センタを構築している企業もある。グリッドはデータをバラバラにするのではなく、既存のハードディスク上の空き領域を利用してNAS（Network Access Storage）に似た仮想ストレージ上にデータベースを作成するのに使われている。
グリッドの標準規格
アプリケーションへのグリッドアーキテクチャの適用が決まったら、開発者は標準規格の採用によって事態の混乱と複雑化を避ける必要がある。数々の団体が、グリッドアーキテクチャのコンポーネントモデルに対する規格を定めている。企業や組織がグリッドを構築して事業拡大や学術研究促進を図るのを支援しているOpen Grid Forum（OGF）も、そうした団体の1つだ。
グリッドアーキテクチャでは事実上すべてのオペレーティングシステムおよびハードウェア上の空きリソースを使用する可能性があるので、サービス指向アーキテクチャ（SOA：Service Oriented architecture）の利用が必須になる。SOAのすばらしさは、どんなオペレーティングシステム、アプリケーション、ハードウェアでもその種類の違いを意識せずに連携させられる点にある。また、Global Grid Forumが発表したOGSA（Open Grid Service Architecture）には、グリッドコンピューティングの要件がオープンスタンダードな形で定められ、SOAがその基盤として使われている。なお、本稿に登場する各事例はGlobal Grid Forumが定めるこの標準規格を参照している。
ツールとコンポーネント
グリッドアプリケーションを構築する一般的な方法は、オープンソースキットを利用することだ。こうしたキットには、開発者が既存のアプリケーションの変換、またはデータベースのようなグリッドリソースの開発支援を行うにために必要なあらゆるものが備わっている。市場にはGlobus Toolkit、Parallel Virtual Machine、Simple Grid Protocolなど、いくつかのツールキットが出ている。
ツールキットにはグリッドでのポート識別に使われるコンポーネントモデルが含まれる。また、使用するグリッド用ソフトウェアに依存したコンポーネントも何種類かある。ほとんどすべてのグリッドには、利用可能なリソースを追跡してジョブの割り当て先を決定する管理コンポーネントが存在する。比較的高度な管理コンポーネントは、グリッドの障害からの回復と、グリッド上のほかのメンバへの迅速なタスク再割り当てにより、自律コンピューティングの域に達している。
あるコンピュータがローカルタスクを割り当てられ、アイドル状態でなくなった場合、管理コンポーネントはアイドル状態にある別のコンピュータに対してジョブの再割り当てを行う。複雑なグリッドにはサーバのクラスタが組み込まれていることがあるため、グリッドを効率よく管理するために組織階層的な配信の必要性が生じる可能性がある。ジョブはグリッド上の1つの管理ノードから送られてくるとは限らない。むしろ、階層内のより小さなジョブマネージャへと送られる可能性がある。その後、こうしたジョブはグリッドメンバへと送るための準備を整える。
マシンをグリッドに参加させるためには、多くの場合、専用のクライアントソフトウェアをインストールする必要がある。ドナー（donor）ソフトウェアとも呼ばれるこのソフトウェアにより、マシンはグリッドへの接続を行う。クライアントソフトウェアは、グリッドとの通信に用いるポートやジョブの実行方法、データの優先順位付けを決定したり、コンポーネントマネージャに代わって利用可能なリソースを追跡したりといった複数のタスクを実行する。
すべてのグリッドでクライアントソフトウェアが必要なわけではないが、その存在によってグリッド構築の複雑さは軽減され、クライアントコンピュータを標準規格に従わせることができる。使用するグリッドツールにもよるが、クライアントソフトウェアの使用には認証局、または特定のユーザIDおよびパスワード、あるいはそれらすべてが必要になる場合がある。これにより、グリッドマネージャはどのユーザがデータを参照し、どんな変更を行い、いつデータを手放したかを知ることができる。
ジョブの投入はグリッド上のほぼどんなノードでも可能だが、そのためにはサブミッション・ソフトウェアが必要になる。この処理は、ユーザのパーミッション設定または専用のソフトウェアアプリケーションによって許可することができる。
たいていの場合、グリッドにはジョブの優先度と最適な実行時間を決定するためのスケジューリング・プログラムが組み込まれている。スケジューリング・プログラムは、利用可能なリソースに基づいて最初に実行すべきジョブを決めるというポリシーに従うジョブキューの設定により、グリッドの負荷抑制にも役立つ。管理コンポーネントとは違い、スケジューリング・プログラムはグリッドのメンバにデータを送ることはなく、ジョブの優先度設定だけを行う。
グリッド内では通信の機能が欠かせない。グリッドは、独立したコンピュータどうしの連携によって機能するからだ。管理コンポーネントはどのクライアントマシンにより多くの作業を割り当てられるかを知る必要があり、クライアント側はどのマシンとデータの送受信を行うべきかを知る必要がある。また、グリッドオペレータは作業を確実に完了させたいと考えている。
通信のための明確な規格がなければ、グリッドによる情報の発信によってネットワークが麻痺するほどの混乱が生じるだろう。グリッドアーキテクチャ内の規格では、特定の通信機能に対するTCP/IPポートが規定されている。ただし、具体的なポートはグリッドの機能と実装されているツールによって変わる可能性がある。
グリッドのパフォーマンス計測は、グリッドの作業負荷の評価と、リソース追加要否の判断のために必要である。監視ツール類は、すべてのリソースを相互に適切な形で動作させるとともに、グリッドの通信に問題がないか、改善できる部分はどこかといった確認に役立つ。また、負荷を計測したデータおよびグラフはコスト面での利点を経営陣に説明するのに効果的である。多くのグリッド管理用クライアントには、グリッドの負荷の測定に役立つ監視ツールが組み込まれている。
セキュリティの問題
アプリケーションとデータをネットワークのあちこちに分散させることで、データの完全性と安全性が損なわれるように思えるが、グリッドアーキテクチャはきわめてセキュアである。OGSAのガイドラインに設けられた規格は、セキュリティの分野で確立されたデータの安全を守るための基本事項に基づいている。
グリッドの管理者は、ユーザおよびコンピュータに対してグリッドへのジョブ投入のパーミッションを設定できるほか、データの参照または変更が可能なユーザおよびコンピュータ、そしてデータの保存先を決定することができる。また、グリッドの通信は、PKIの認証局（CA：Certificate Authority）を使ったSSL（Secure Socket Layer）によってさらにセキュア化されている。
最もわかりやすいセキュリティ上の課題は、グリッドを実行する物理的なハードウェアを不正なアクセスから保護することである。非常に知名度の高いグリッドの中にはSETI@Homeプロジェクトのように一般に公開されているものもあるが、一企業の専用グリッドであればオフィスの室内に設置するべきである。その場合、コーポレート・ファイアウォールや侵入検知システム（IDS：Intrusion Detection Systems）が、インターネットからの論理的な不正アクセスを防止するのに役立つ。ただし、適切に設定されたファイアウォールを利用すれば、リモートオフィスとの連携は可能だ。
グリッドのリソース
グリッドアーキテクチャの基本事項の理解に加え、開発者は想定するアプリケーションがどのように動作するのかについても知る必要がある。独自のインタフェースを必要とする複数のユーザがいるか？ 大量のデータを扱うのか？ 冗長性が問題になるか？ アプリケーションの規模が現時点で利用できるハードウェアリソースの点で問題になるか？ こうした項目にあてはまるなら、グリッドコンピューティングがよい選択肢になるだろう。
だが、グリッド環境がすべてのジョブを最適に処理できるわけではない。小さなデータベースなど、リソースをほとんど使用しない小規模なアプリケーションは、おそらくグリッドコンピューティングの恩恵を受けられないだろう。しかし、大量の複雑な処理やバッチ処理を必要とする大規模なデータセットは、最新のマシンでさえフリーズさせてしまう可能性がある。また、新規アプリケーションの場合は、開発または導入に必要なハードウェアの入手に苦労する場合がある。
管理職の説得
グリッドアーキテクチャは従来のアーキテクチャほど知られていないので、管理職層の説得には支障を来す可能性がある。よく理解せずに、グリッドコンピューティングは不安定で、効果が実証されておらず、信頼性が不十分だと思っている人は少なくないだろう。幸いなことに、そうした人々を別の方向から説得できる手がある。
管理職、とりわけ財布の紐が堅い人々に働きかける最善の方法の1つは、コスト面でのメリットを指摘することだ。グリッドアーキテクチャはオープンスタンダードに頼っているため、市場には無償または手頃な価格で手に入るものが多数出回っている。また、使うあてのないリソースや遊休マシンを利用する、ハードディスクの空き領域をデータグリッドに割り当てる、ユーザとのインタラクションをあまり必要としない、といった理由から、うまくいけば総所有コストを最大限に活用できることにもなる。
まとめ
グリッドアーキテクチャは、開発者、システム管理者、ITマネージャに対してアプリケーションに関する数々のメリットをもたらす。特に、ユーザ数と計算データの量が多くて高速処理が必要なアプリケーションの場合はその傾向が顕著である。利用可能なツールやリソースの豊富な存在は、グリッドアーキテクチャの適用を容易にしている。グリッドでのデータ交換にオープンスタンダード言語を使用すれば、すでに大半のプログラマの手元にあるツール群が利用できる。また、大規模なデータセットの並列処理が可能になることで、計算時間が短縮され、パフォーマンスが向上する。
システムおよびサーバの管理者には、グリッド環境がもたらす構築の単純さと監視機能がありがたく感じられるはずだ。グリッド内の監視モジュールにより、管理者はもっと多くのリソースを接続してグリッドを拡大する必要があるかどうかを判断できる。また、グリッドアーキテクチャではシステム管理者がすでに保有しているコンピュータを利用するので、データセンタ内の既存のリソースだけで間に合わせられることが多い。さらに、グリッドアーキテクチャには最新のセキュリティ手法が採用されているため、システム管理者はそのネットワーク、アプリケーション、データの安全性について安心して居られる。
一方、管理職としては、手持ちの機器をあてがってグリッドアプリケーションの負荷に対処することにより、総所有コストを最大限に活用することができる。また、システムをダウンさせたり余計なコストをかけたりすることなく、プロセッサパワーやディスクスペースなど、より多くのリソースをアプリケーションに追加できるので、オーバーヘッドが軽減され、顧客満足度の向上にもつながる。
ITManagersJournal.com 原文
