5.2 サーバ動的切り替えの枠組みにおける今後の課題 56
においても枠組みの有効性を評価する必要がある．特に，サーバ切り替 え指示システムとGridRPC資源管理モジュール群のスケーラビリティが 課題となると考えられる．
(b) GridRPC以外のグリッドミドルウェアへの対応
Grid-enabled MPI[25]等ではサーバ毎にプログラム起動/終了を制御し難 いため，F-Omegaの適用には，プロセス間接続の復元等も考慮したサー バ切り替え機構が必要である．
(c) 運用計画/利用方針ファイル間のマッチング項目の書式統一
各サーバ管理者が作成するサーバ運用計画ファイル内のサービス項目と，
ユーザが作成するサーバ利用方針ファイル内の要求サービス項目は，相 互運用可能な書式で統一される必要がある．たとえば，globus gram="1"
とGT-GRAM="ON"といったサービス項目の記述が実際では同じ意味の場合
でも，現時点では異なる項目と判断されるため，期待されるサーバ利用 を達成できない状況が考えられる．
(d) 一般ユーザのフィードバックに基づく改良
より実践的な有用性を高めるべく，著者以外の一般ユーザの意見に基づ く枠組みの改良が必要である．現在，F-Omegaのミドルウェア実装は公 開されていない．ユーザを多く獲得し，フィードバック情報から課題の 抽出を行うことが今後の課題である．
57
6 結言
WAN上の計算資源を組み合わせて一つの計算機システムとしてユーザに提供す るグリッドにおいて，簡便性の向上が重要な課題である．特に，計算機へのグリッド アプリケーションの配置，およびグリッドアプリケーションの実行においては，多 数の計算機を用いるグリッドのため，ユーザの作業コストが莫大である．本論文で は，グリッドアプリケーションの「配置」と「実行」を支援する新しい枠組みを提 案した．そして，提案する枠組みをそれぞれミドルウェアとして実装し，実際的な グリッド環境において，その有効性を明らかにした．
第1章では，本研究の背景および目的を述べた．広域分散計算を支援するグリッ ドには，計算機の管理・利用に関するいくつかの要素技術を開発する必要がある．研 究で前提とするミドルウェアやプログラミングモデルを述べ，本論文では特に，グ リッドアプリケーションの計算機への配置，およびグリッドアプリケーションのサー バ動的切り替えに関する問題を提起した．
第2章では，グリッドアプリケーションの「配置」と「実行」の関連研究を分類 し，提案する枠組みの位置づけを述べた．提案する枠組み Relis-G は，計算機の不 均質性に自動的に対処可能とする点が特徴の，ライブラリ自動配置の枠組みである．
提案する枠組み F-Omega は，サーバ運用計画の監視機構と連携して自動的にサー バを切り替え可能とする点が特徴の，サーバ動的切り替えの枠組みである．
第3章では，サーバの不均質性に自動的に対処可能とする，新しいライブラリの 自動配置の枠組みRelis-G を提案した．Relis-G は次の特徴を持つ．
• 従来の手作業の配置に比べて少ない入力コストで，多数のサーバに対するライ ブラリの一斉配置を可能とする．特に，デバッグなど頻繁なライブラリ更新を 必要とする場合に，極めて少ないコストで配置可能とする．
• ライブラリの可搬化に関するノウハウの習得などの煩雑さを軽減するべく，ラ イブラリを自動的に可搬化させる機能を持ったライブラリ配置システムを提供 する．
• サーバ毎の運用方針(二次記憶の利用規則など)への適応における煩雑さを軽 減するべく，運用方針に自動的に適応しながら配置を行うライブラリ配置シス テムを提供する．
58
以上のとおり，Relis-G のライブラリ配置システムはグリッドにおいて有用性の高 い特徴を備えている．
さらに，Relis-Gの有効性を検証するべく，枠組みをミドルウェアとして実装し，
実グリッド環境における実験結果を示した．
配置に要する時間 2サイト12台のOSが不均質なサーバ群に対しライブラリの配置 を行った．結果として，従来の手作業の配置に比べて，少ない入力コストで，
ライブラリを一斉配置できることを確認した．特に，デバッグなど頻繁なライ ブラリ更新を必要とする場合に，2回目以降の配置を極めて少ないコストで行 えることを示した．
ライブラリ可搬化機能の有効性検証 機種依存性のあるライブラリ2種を例として，
実験環境に対して配置させた．結果として，ライブラリ可搬化機能によって作 成されたソフトウェアパッケージを用いることで，不均質サーバ上でライブラ リのコンパイル・リンクを正しく行えることを確認した．これにより，ユーザ にとって，ライブラリの可搬化に関するノウハウの習得などの煩雑さが軽減さ れたといえる．
運用方針自動適応機能の有効性検証 配置において外部ライブラリの場所といった サーバの運用方針情報を必要とするライブラリを実験環境に対して配置させ た．結果として，運用方針へ自動的に適応しながら配置を行う機能により，正 しく運用方針を守って配置が行われることを確認した．これにより，ユーザに とって，サーバ毎の運用方針へ適応する際の煩雑さが軽減されたといえる．
第4章では，サーバ監視機構と連携して自動的にサーバを切り替え可能な，新しい サーバ動的切り替えの枠組み F-Omega を提案した．F-Omegaは次の特徴を持つ．
• 従来手作業で行っていたサーバ稼動状況の監視，サーバ切り替え指示といった 煩雑な作業を不要とするべく，グリッドアプリケーションに対し，サーバ監視 機構と連携しながら利用するサーバを自動的に適切に切り替え可能とする．
• 従来ユーザとサーバ管理者が手作業で管理していた，事前予約などの複雑な サーバ利用契約に応じたサーバ利用可能量の変化を自動的に監視可能とする べく，サーバの運用計画の自動監視機構を提供する．
59
• アプリケーション開発者を煩雑なサーバ管理の実装から開放するべく，GridRPC のためのサーバ自動管理モジュールをアプリケーション開発者に提供する．
以上のとおり，F-Omega はグリッドアプリケーションのサーバ動的切り替えのため の有用性の高い特徴を備えている．
さらに，F-Omegaの有効性を検証するべく，枠組みをミドルウェアとして実装し，
試験的グリッドにおける実験結果を示した．
サーバ動的切り替えの性能調査 12台のサーバ群の稼動状況を数時間おきに度々変 動させたが，自動ステアリングシステムによってサンプルアプリケーションの 利用するサーバが自動的に適切に切り替えられ，2.8日間にわたって計算が継 続されることを確認した．この効果は，サーバ自動管理機構を持たない従来の
GridRPCミドルウェアで得ることはできない．また，サーバ監視機構と連携
しない並列プログラミングミドルウェアと比較して，サーバ切り替えの指示の ためのコストが大きく軽減されるといえる．
サーバ運用計画ファイルの記述コストの調査 サーバのメンテナンスや外乱ジョブ毎 に，線形に（1行ずつ）増加することを確認した．これは通常，従来の電子メー ルなどに自然言語で記す場合よりも短いか同程度の記述量である．
サーバ利用方針ファイルの実用性検証 提案する書式が，外部のグリッド実験におけ るサーバ利用方針の記述にも用いることができ，現実的な利用方針の記述に有 用であることを確認した．
第5章では，グリッドアプリケーションの「配置」と「実行」の枠組みそれぞれ について，今後解決すべき課題を短期的な課題，中長期的な課題に分け，整理した．
1. Relis-G: ライブラリの自動配置の枠組み (a) 短期的な課題
i. サーバが動的に定まる状況に対応するべく，オンデマンドに自動的 にライブラリを配置可能とする．
ii. 可搬性のある高速なライブラリの配置を支援するべくソフトウェア 自動チューニング機構と併用する．
60
iii. グリッドアプリケーションの開発・配置・実行で一貫した位置透過性 を実現するべく，自動分散化コンパイラOpenGRと併用する．
iv. ユーザの入力のコストをさらに軽減するべく，インストール環境定 義ファイルなどの作成を支援するシステムを開発する．
(b) 中長期的な課題
i. 数千・数万ホストを対象としてライブラリ自動配置機能のスケーラ ビリティの評価を行う．
ii. データ構造の不均質性を隠蔽するデータアクセスインタフェースを 開発する．
iii. ソースコードが公開されない，第三者が作成したライブラリをも，自 動的に配置できるシステムを開発する．
iv. ユーザを多く獲得し，フィードバックに基づく改良を行う．
2. F-Omega: グリッドアプリケーションのサーバ動的切り替えの枠組み
(a) 短期的な課題
i. サーバ管理者によるサーバ運用計画ファイルの作成のコストを軽減 するべく，ユーザ別に定義される運用計画から本ファイルを自動作 成するシステムを開発する．
ii. 計算タスクの特性やサーバの性能を意識したサーバ選択を可能とす るべく，サーバ切り替え指示システムやActuatorの機能を拡張する．
iii. サーバ利用方針ファイルとNinf-Gのクライアントコンフィギュレー ションファイルの整合性を保つべく，それらを自動同期するシステム を開発する．
(b) 中長期的な課題
i. 数千・数万ホストを対象としてサーバ切り替え指示システムとGridRPC 資源管理モジュール群のスケーラビリティの評価を行う．
ii. Grid-enabled MPIのような，サーバ毎にプログラム起動/終了を制御 し難いグリッドミドルウェアに対応可能とする．
iii. サーバ運用計画ファイル・サーバ利用方針ファイルにおけるサービス 項目を相互運用可能な書式で統一する．