本コラムでは早くは「余剰資源借用ビジネス」(2001/4/17) に分散コンピューティングとして取り上げ、「なぜLinuxスパコンが流行るのか」(2004/11/30) 、「どこまで行っても次世代コンピューティング」(2003/1/14) などでも触れられているグリッドコンピューティング。コンピュータを仮想化し、負荷分散や冗長性をこれまでの方法よりもより効果的に安価に実現する技術として期待されているが、果たして使える技術なのであろうか？

そもそもグリッドとは？

ここでグリッドコンピューティングについておさらいしてみよう。グリッドとは、多くのコンピュータをネットワークで接続し、個々のコンピュータの貢献は小さくとも多くのリソースを束ねることによって全体として高い処理性能、高い信頼性を実現し、安定的に必要なITリソースを容易に使うことができる技術、といえるだろう。さらに言うならば、科学技術計算などで駆使されるロジック部分、大規模オンラインショッピングサイトなどで重要になるデータ部分、そしてネットワーク部分に大別することができる。最近の注目は、ロジック部分（Computing Grid）とデータ部分（Data Grid）のグリッド化である。

実システムとしてグリッド化を行う際には計算グリッドやデータグリッド用ミドルウェアを導入するアプローチがいまのところ一般的である。アプリケーションとしては通常通り開発し、実際の計算処理、データハンドリングをグリッドとして展開する部分はミドルウェアに任せる、といった具合にである。

実システムに使えるの？

グリッドシステムを新規に構築する場合においても、既存システムをグリッド化する場合においても気になるのはパフォーマンスである。グリッド化していない場合とどの程度の差があるものなのか？

ITリソースの仮想化、ユーティリティ化という意味では大抵のシステムはグリッド化が可能であり、ある程度のメリットを享受できるが、やはりバッチ処理的な計算処理を多用するシステムがグリッドに向いていることは確かである。特に独立した小さな単位で計算可能な処理においては、処理時間にして半分以下にできる。場合によってはバッチ処理であったものが少々待たされる程度のオンライン処理として機能を再定義できるものもある。こうなると下手にシステムを再構築するよりもグリッドを導入したほうがコストをかけずにシステムの利用度を上げることも可能である。

驚くことに、既存アプリケーションをグリッド化することにそれほど多くの改修を行う必要はないのである。もちろん、システム構成によっては大幅な改修が必要な場合もあるだろうし、グリッドシステムの長所を引き出すためにはアプリケーション側のチューニング、リソースプランニングなどが重要であり、慎重に計画する必要があるが、率直な感想としてグリッド化への敷居は思いのほか低い。

気をつける点

反面、いくつか気をつける点がある。

まずは当然ながらシステムのグリッド適性である。処理を分割してノードに配布するため、独立分割できる処理に細分化できる必要がある。あまり細切れにしすぎるとグリッド化のオーバーヘッドが多くなり逆効果になるのでチューニングが必要だが、組織、アクセスレベル、データセグメントなど、処理やデータの区分けが必要になる。これらの区分けができにくいシステムはグリッドに向かない。

また、ノードにしても、最近のデスクトップPCは小型化されているのでCPUを100%の状態で長時間稼動させると本体が相当熱くなるので不向きである。やはり高負荷状態を長時間持続できるほどのキャパシティが必要である。そうなると、非力なPCを多数そろえるよりもある程度の信頼性があるサーバを相当数束ねるほうが現実的である。ノードの台数が増えるとそれだけ管理コスト、ライセンス料なども増えてくるので、適度なバランスが必要になってくる。

グリッドシステムの稼働状況を見ていると歯がゆくなる場面も多い。予め重いと思われる処理（ジョブ）は速いノードに回したいのだが、そのような小回りがきかない。また、データの構成によって分割される処理単位が効率的であったりそうでなかったりするので、ある程度ダイナミックに処理分割をコントロールしたくなる。システム全体をコントロールするインテリジェンスと言ったらいいのだろうか。また、現在の多くのグリッドはノードに処理をスケジューリングする際は、手の空いているノードにランダムに振り分けるのだが、ジョブのスケジューリングの際にも優先度なり、実行条件をダイナミックに変更できたらシステムパフォーマンスはさらに向上する。

向き不向きがあるにせよ、グリッド技術は現時点においてもその有効性が確認されたといっていい。間違いなく使える技術である。オープンで安価なミドルウェアが出回れば一気にブレークする可能性を秘めている。