Comments
Description
Transcript
グリッドコンピューティングの国際標準化に関する調査研究 (PDFﾌｧｲﾙ約
経済産業省委託 平成１８年度産業技術研究開発委託費 （基準認証研究開発事業：情報分野の国際競争力強化の標準化調査研究） グリッドコンピューティングの 国際標準化に関する調査研究 成 果 報 告 書 平成１９年３月 独立行政法人 財団法人 産業技術総合研究所 日本規格協会 情報技術標準化研究センター この調査研究は、経済産業省からの委託で実施したものの成果である。 1. 2. 3. 4. 5. 6. 7. 目 次 まえがき .................................................................................................................... 1 要約 ......................................................................................................................... 3 2.1. 背景と目的 ............................................................................................................. 3 2.2. 実施体制（委員会構成・名簿）..................................................................................... 3 2.3. スケジュール ........................................................................................................... 5 2.4. 実施事項................................................................................................................ 5 2.5. 得られた成果（成果一覧：技術的成果と国際標準化に関して） ........................................... 5 2.6. 国際規格案の内容・提案先・提案までの方法................................................................. 6 2.7. 今後の課題（技術的課題と国際標準化に関する課題を含む） ............................................ 6 委託業務実施計画 ...................................................................................................... 7 3.1. 背景 ...................................................................................................................... 7 3.2. 研究開発の目的 ...................................................................................................... 7 3.3. 実施計画の細目 ...................................................................................................... 7 3.4. 研究場所................................................................................................................ 8 3.5. 実施期間................................................................................................................ 8 3.6. 実施計画日程 ......................................................................................................... 8 3.7. 研究体制................................................................................................................ 9 実施結果................................................................................................................. 10 4.1. ガイドライン作成作業と用語フレームワーク定義のための具体的作業................................ 10 4.1.1. 過去の活動と本委員会の活動の関係...................................................................... 10 4.1.2. グリッドシステムのモデル ...................................................................................... 12 4.1.3. グリッドシステムの用途例 ...................................................................................... 31 4.2. 国際標準化動向調査.............................................................................................. 33 4.2.1. 国際標準化団体の状況 ....................................................................................... 33 あとがき................................................................................................................... 47 参考文献................................................................................................................. 48 付録 ....................................................................................................................... 49 付録Ａ OASIS および W3C の詳細状況 ............................................................................... 50 A.1. OASIS の詳細状況 ............................................................................................... 50 A.2. W3C の詳細状況 ................................................................................................. 56 付録Ｂ グリッドシステムの用途例および要件リスト................................................................. 63 1. グリッドシステムの用途例とその要件 ....................................................................... 63 2. 企業内技術計算グリッド （コンピューティンググリッド） ................................................. 65 3. 企業内技術計算グリッド（PC グリッド） ...................................................................... 74 4. 学術共同グリッド （コンピューティンググリッド）........................................................... 81 5. ビジネス・コンピューティング・グリッド （業務システムに対するサーバリソース提供）........... 87 6. ストレージ基盤サービス（ストレージグリッド） .............................................................. 96 付録Ｃ グリッドガイドラインの用語集 .................................................................................101 付録Ｄ 商用データセンタの要件 .....................................................................................106 （ⅰ） 1. まえがき 経済産業省委託事業グリッドコンピューティング標準化調査研究委員会は、日本規格協会情報技術 標準化研究センター（ＩＮＳＴＡＣ）において平成１４年から１６年にわたって行われた３年間の調査活動を 受け、それを更に発展させるものである。コンピュータ技術の進歩と高速ネットワークの普及によって、現 在の社会生活におけるコンピュータシステムの役割が著しく大きくなってきた。２１世紀に入ってこの動向 はますます止まるところを知らない。今後もコンピュータの性能向上とインターネットの発展は、相互に寄 与し合いながらますますそのスピードを速めて行くであろう。このような状況の中から、広域に分散した計 算資源を連携して利用するグリッドコンピューティング技術が急速に発展している。グリッドコンピューティ ングは、分散している計算資源や記憶資源などを繋いで大規模な計算やデータ処理をすることに始まり、 広域に分散し多くの組織にまたがって存在するデータ、ソフトウェア、センサ、実験機器、可視化装置、 さらには人間そのものなど多様なコンピュータリソースを有機的に結合し、シームレスなサービスの流れ を実現するという広範囲な技術である。グリッドコンピューティングはまだ萌芽期にある技術ではあるが、 将来の市場形成や社会的意義を考慮して、積極的に取り組むべき課題であると考えられる。 広域に分散した複数の組織間を接続し、資源を共有するためには、標準化が不可欠である。このため 1990 年代後半から標準化の必要性が叫ばれ、地域内での標準化から始まって、直ちに全世界での標 準化活動がボランティア的な組織によって急速に進められている。このような動きにわが国の産官学の 関係者が最初から積極的に参加し、多くの重要な役職を担っていることは、他の分野に見られない大き な特徴である。 1998 年、フロリダ州オーランドで開かれた Supercomputing 98 の際の会合を元にアメリカを中心とする Grid Forum が生まれた。2000 年にはヨーロッパの European Grid Forum と、日本などアジアを中心とす る Asia-Pacific 地域の活動と合併して Global Grid Forum (GGF) が発足し、年３回のフォーラムを開催し、 多くの標準や仕様を定めてきた。他方、グリッドの商業利用に焦点をあてた Enterprise Grid Alliance (EGA) は 2004 年に発足し、EGA 参照モデルや Use Cases を提示し、セキュリティの要求仕様を定め、 グリッドが実際にビジネスとして利用可能であることを示してきた。この二つの組織は 2006 年度に合併し、 Open Grid Forum (OGF) を発足させた。 本調査研究では、このような急激な動きに対して、わが国が産業競争力強化を目指して何をなすべき かについて、調査、分析、討論を行ってきた。本調査研究が、グリッドコンピューティング技術の確立の第 一歩となり、ひいては日米欧さらにはアジアを含めた協力体制によるグローバルなグリッド実現の契機と なることを期待している。 今回の委員会は、グリッドコンピューティング技術のガイドラインの国際提案を目指した調査研究活動 であり、ユースケースの分析から始め、標準化動向を見ながらガイドラインを作成し、これを普及啓発し Open Grid Forum などの国際標準化団体に提案しようとするものである。先行の研究委員会では、 １）グリッド関連技術標準化の状況の調査 ２）日本における主なグリッド技術の標準化活動の調査 ３）グリッド構築のガイドラインの提案 ４）グリッドコンピューティングに関する用語集の作成 などの成果を得たが、この委員会では、ガイドラインを精密化するとともに、何らかの意味で具体的な 事例への適用を通して妥当性を評価し、これを国際的に提案することを目指している。このため、本年度 は EGA 参照モデルや OGSA (Open Grid Services Architecture) を参照しながら、グリッドのモデル定義 について議論を積み重ね、委員会内でほぼ合意を得た。今後、OGF など国際的な標準化団体との協力 を通じて、ガイドラインを提案していきたい。 1-1 - 1 - グリッドコンピューティングは、イリノイ大 Tom De Fanti とアルゴンヌ国立研究所の Rick Stevens 等が 1995 年に行った最初の大規模なメタコンピューティングの実験 I-Way (The Information Wide Area Year) がその始まりと言われる。この実験では、全米 17 カ所の計算センターを結合しアプリケーションを走らせ た。これをもとに翌年 Globus プロジェクトが始まった。グリッドの基本概念を提案した文書"The Grid: Blueprint for a New Computing Infrastructure"が出版されたのは 1998 年のことである。 I-Way の実験から約１２年が経過した。この調査研究が、グリッドコンピューティング技術標準化確立の 第一歩となり、ひいては日米欧さらにはアジアを含めた協力体制によるグリッド技術確立の契機となるこ とを期待している。 グリッドコンピューティング標準化調査研究委員会委員長 小柳義夫 （工学院大学） 1-2 - 2 - 2. 要約 2.1. 背景と目的 グリッド・コンピューティング（以下、ここではグリッドという）がビジネスの世界で、ここ２～３年くらいの間 に盛んに取り上げられるようになっている。それに従って、グリッド技術に関する標準化団体 OGF(Open Grid Forum)を中心にして研究機関のみならず多くの企業も標準化に取り組んでいるが、標準化団体に おける取り組みだけでは、必ずしも十分とは言えない。例えば、いまだに企業各社が使っている言葉（用 語）や、実現している環境やアプリケーションなどケースによって実現している技術レベルが、企業各社 で大きく異なっている。このことはユーザ企業がグリッド技術を正しく理解し、採用していくことを妨げてい る大きな要因となっている。 このため、グリッド技術の基準規格（ガイドライン）を作成し、国際標準化として提案することを最終目的 とした活動を進めている。 グリッド技術に関するガイドラインを作成することによって、様々な場面におけるグリッドの情報交換の 効率性を飛躍的に高めることが可能となる。例えば、企業の製品に関する情報において、宣伝上の用語 とは別に、製品に用いられている技術や、実現できる機能、準拠する標準仕様などについて、どのレベ ルにあるかを記述することで、利用者には客観的な製品の評価が容易になる。また、グリッド環境の構築 における仕様作成においても、顧客の意図や要求事項を明確にベンダに伝えることが可能となり、仕様 のあいまいさを減少させることが可能である。このようなグリッド技術のガイドラインを用いることで、各社グ リッド製品や各プロジェクトのグリッド環境がどのレベルの基準を実現しているか明確化でき、比較が容 易となる。その他、グリッド環境構築の仕様記述手段の提供、企業と顧客間の契約（ＳＬＡ：Service Level Agreement）基準の明確化も実現可能となり、産業界におけるグリッド技術の採用・普及が加速される。グ リッド技術の導入により、ＴＣＯ（Total Cost of Ownership）削減、利用効率の向上、ユーティリティ事業を 含む新規ビジネス立ち上げなど、大きな経済的効果が期待される。 2.2. 実施体制（委員会構成・名簿） (a) 委員会構成 グリッドコンピューティング国際標準化調査研究委員会本委員会 グリッドコンピューティング標準化調査研究委員会（産総研に委託） (b) グリッドコンピューティング国際標準化調査研究委員会本委員会名簿 委員長 委員 委員 委員 委員 委員 小柳 伊藤 合田 安崎 和泉 鍜冶 義夫 智 憲人 篤郎 章 克彦 工学院大学 情報学部 （独）産業技術総合研究所 グリッド研究センター 東京工業大学 大学院総合理工学研究科 （株）日立製作所 ソフトウエア事業部 経済産業省 産業技術環境局 経済産業省 商務情報政策局 2-3 - 3 - 委員 委員 委員 委員 委員 委員 委員 國府田明弘 佐治 信之 鈴木 俊宏 高島 浩幸 高橋 元美 田崎 英明 濱田 正彦 委員 委員 委員 委員 委員 経産省 経産省 事務局 事務局 事務局 古川 彰 真栄城隆司 宮辺 裕 横川三津夫 吉岡 正博 坂本 教晃 森田 信輝 加山 英男 山中 正幸 河合 聖子 住商情報システム（株） IT 基盤ソリューション事業部 日本電気（株） システム基盤ソフトウエア開発本部 日本オラクル（株） システム事業推進本部 ノバルティスファーマ（株） 筑波研究所 鹿島建設（株） IT ソリューション部 富士通（株） 運用管理ソフト事業部 日本アイ・ビー・エム・システムズ・エンジニアリング（株） テクノロジー・イノベーション 東芝ソリューション（株） プラットフォームソリューション事業部 ファーストライディングテクノロジー（株） ソリューション営業部 新日鉄ソリューションズ（株） システム研究開発センター （独）理化学研究所 次世代スーパーコンピュータ開発実施本部 マツダ（株） IT ソリューション本部 経済産業省 商務情報政策局 経済産業省 産業技術環境局 （財）日本規格協会 情報技術標準化研究センター （財）日本規格協会 情報技術標準化研究センター （財）日本規格協会 情報技術標準化研究センター (c) グリッドコンピューティング標準化調査研究委員会名簿 委員長 幹事 委員 委員 委員 委員 委員 小柳 伊藤 安崎 溝口 森 田崎 濱田 義夫 智 篤郎 研一 拓也 英明 正彦 委員 鈴木 俊宏 委員 竹房あつ子 委員 真栄城隆司 委員 高島 浩幸 委員 吉岡 正博 ｵﾌﾞｻﾞｰﾊﾞ 森田 信輝 ｵﾌﾞｻﾞｰﾊﾞ 小林 秀司 ｵﾌﾞｻﾞｰﾊﾞ 加山 英男 ｵﾌﾞｻﾞｰﾊﾞ 山中 正幸 ｵﾌﾞｻﾞｰﾊﾞ 齋藤 充 事務局 伊達 浩一 工学院大学 情報学部 (独）産業総合研究所 グリッド研究センター （株）日立製作所 ソフトウェア事業部 東芝ソリューション（株） プラットフォームソリューション事業部 日本電気（株） システム基盤ソフトウェア開発本部 富士通（株） 運用管理ソフトウェア事業部 日本アイ・ビー・エム・システムエンジニアリング（株） オンデマンド・テクノロジー部 日本オラクル（株） システム事業推進本部 （独）産業総合研究所 グリッド研究センター ファーストライディングテクノロジー株式会社 ソリューション営業部 ノバルティスファーマ株式会社 筑波研究所 マツダ株式会社 ITソリューション本部 経済産業省 産業技術環境局 経済産業省 産業技術環境局 日本規格協会 情報技術標準化研究センター 日本規格協会 情報技術標準化研究センター （独）産業総合研究所 産学官連携推進部門工業標準部 （独）産業総合研究所 グリッド研究センター 2-4 - 4 - 2.3. スケジュール 委員会を以下の通り開催した。 第一回本委員会 第一回委員会 第二回委員会 第三回委員会 第四回委員会 第五回委員会 第六回委員会 第七回委員会 第八回委員会 第二回本委員会 第九回委員会 平成 18 年 5 月 31 日 平成 18 年 5 月 31 日 平成 18 年 6 月 23 日 平成 18 年 8 月 11 日 平成 18 年 9 月 27 日 平成 18 年 10 月 31 日 平成 18 年 11 月 22 日 平成 18 年 12 月 14 日 平成 19 年 1 月 19 日 平成 19 年 2 月 23 日 平成 19 年 2 月 23 日 2.4. 実施事項 (a) (b) (c) (d) (e) グリッドコンピューティング標準化調査研究委員会の運営 グリッドコンピューティング標準化調査研究委員会を設置し、事業管理・運営を実施した。 ガイドライン作成作業と用語フレームワーク定義のための具体的作業 1) ガイドラインの作成のための実事例調査作業 ノバルティスファーマ株式会社（以後ノバルティス）におけるグリッドシステム、マツダ株式会社（以後マ ツダ）におけるビジネスグリッドを活用したディザスタリカバリシステム、ファーストライディングテクノロジ ー株式会社（以後 FRT）における商用データセンタなど、実事例を調査した。 ・FRT 社（沖縄県）については現地で実状調査を行った。 2) ガイドライン作成作業 ガイドライン作成に先立ち、グリッド技術を適用したシステム・環境に関わるプレイヤ、提供物、管理な どについて、モデル化を実施した。一方で、ガイドラインを最初から汎用的な内容として記述すること は困難であり、グリッドシステムのいくつかの用途例について、モデルを用いた記述とガイドライン項目 の作成を実施した。 3) 用語集の作成作業 モデル化およびガイドラインのドキュメント中に登場する、グリッドに関する用語を定義した。 国際規格提案のための国内のコンセンサス形成 グリッドコンピューティング国際標準化調査研究委員会本委員会において、幅広い分野に渡って多く の有識者から意見を集めた。また、成果としてのガイドラインの内容を説明し、賛同を得るとともにいく つかのフィードバックを得た。 国際標準化動向調査 グリッド技術の標準化に関連した活動を行っている団体として、OGF(Open Grid Forum)の他、OASIS, W3C, DMTF, SNIA, ISO/IEC JTC1 について、標準化の状況を調査した。 ・OGF については第１８回（米国），１９回（米国）の会議に出席して動向調査を行った。 ・グリッドに関連する会議 SC06（米国）に出席して動向調査を行った。 報告書の作成 本年度の事業成果について、報告書の作成を実施した。 2.5. 得られた成果（成果一覧：技術的成果と国際標準化に関して） z グリッドシステムのモデル化 ¾ グリッドシステムのプレイヤ 2-5 - 5 - z ¾ グリッドシステムにおける提供物 ¾ プレイヤの役割と提供物の関係 ¾ 提供物の状態遷移 ¾ グリッドシステムの管理 グリッドシステムの用途例とその要件 ¾ 企業内科学技術グリッド コンピューティンググリッド PC グリッド ¾ 学術共同グリッド コンピューティンググリッド ¾ 商用データセンタのグリッド ビジネス・コンピューティング・グリッド（業務システムに対するサーバリソース提供） ストレージ基盤サービス（ストレージグリッド） 国際標準化動向調査の結果として、以下の成果を得た。 z グリッド関連の国際的標準化団体の状況 ¾ OGF の状況 ¾ OASIS の状況 ¾ W3C の状況 ¾ DMTF の状況 ¾ SNIA の状況 ¾ ISO/IEC JTC1 の状況 2.6. 国際規格案の内容・提案先・提案までの方法 本委員会の最終目的として、グリッド技術の産業規格（ガイドライン）の国際標準化提案を目指してい る。 今年度作成したガイドラインは、グリッドシステムとしてのいくつかの用途例に対して要件の項目をリス トアップしたものとなっている。今後、カバーする用途例を増やし、システムの特徴を踏まえた分類と、要 件としてのガイドライン項目の分類毎の整理を行い、最終的なガイドラインの作成を進める。 国際規格の提案先としては、OGF(Open Grid Forum)、または ISO/IEC JTC1 が候補として考えられる が、それら団体の今後の動向および作成するガイドラインの内容を吟味して確定する。 2.7. 今後の課題（技術的課題と国際標準化に関する課題を含む） グリッドシステムの特徴的な用途例を取り上げ、ガイドラインの項目の候補となる要件を抽出してきたこ とにより、グリッドシステムが持つ構造的な特徴や提供物の種別などにより、要件がコンポーネントに分解 できる可能性が見えてきた。コンポーネント間の重複が少ないように分割できるならば、ガイドラインをい くつかに分割でき、ガイドラインの利用者からみて、扱い易いものにできる。しかしながら、グリッドシステ ムはバリエーションが多く、系統的な分割を行うためには、詳細な分析と検討が必要である。 最終的な成果物であるガイドラインを国際標準化に提案するためには、提案先として適切な組織を選 択しなければならない。今後候補となる標準化団体の動向を調査しつつ、成果物としてのガイドラインの 内容を鑑みて、ガイドライン提案先の検討を行う必要がある。 2-6 - 6 - 3. 委託業務実施計画 3.1. 背景 グリッド・コンピューティング（以下、ここではグリッドという）がビジネスの世界で、ここ２～３年くらいの間 に盛んに取り上げられるようになっている。それに従って、グリッド技術に関する標準化団体 OGF(Open Grid Forum)などにおいて、研究機関のみならず多くの企業も標準化に取り組んでいるが、OGF におけ る取り組みだけでは、必ずしも十分とは言えない。例えば、いまだに企業各社が使っている言葉（用語） や、実現している環境やアプリケーションなどケースによって実現している技術レベルが、企業各社で大 きく異なっている。このことはユーザ企業がグリッド技術を正しく理解し、採用していくことを妨げている大 きな要因となっている。 3.2. 研究開発の目的 グリッド技術のガイドライン（基準規格）を作成することを最終目的とした活動を進める。 グリッド技術に関するガイドラインを作成することによって、様々な場面におけるグリッドの情報交換の 効率性を飛躍的に高めることが可能となる。例えば、企業の製品に関する情報において、宣伝上の用語 とは別に、製品に用いられている技術や、実現できる機能、準拠する標準仕様などについて、どのレベ ルにあるかを記述することで、利用者には客観的な製品の評価が容易になる。また、グリッド環境の構築 における仕様作成においても、顧客の意図や要求事項を明確にベンダに伝えることが可能となり、仕様 のあいまいさを減少させることが可能である。このようなグリッド技術のガイドラインを用いることで、各社グ リッド製品や各プロジェクトのグリッド環境がどのレベルの基準を実現しているか明確化でき、比較が容 易となる。その他、グリッド環境構築の仕様記述手段の提供、企業と顧客間の契約（ＳＬＡ：Service Level Agreement）基準の明確化も実現可能となり、産業界におけるグリッド技術の採用・普及が加速される。グ リッド技術の導入により、TCO（Total Cost of Ownership）削減、利用効率の向上、ユーティリティ事業を 含む新規ビジネス立ち上げなど、大きな経済的効果が期待される。 3.3. 実施計画の細目 (a) グリッドコンピューティング標準化調査研究委員会の運営 平成１７年度に引き続き、平成１８年度は２年目の委員会活動として、ガイドラインの国際標準化提案も 視野に入れた日本国内におけるコンセンサスづくりや、OGF で国際的な規格化の動きが出てきた時に 我が国として即時対応するため、「グリッドコンピューティング標準化調査研究委員会」の委員の必要に 応じた増強と、同時に、傘下のＷＧについても必要に応じ増設を図り、事業管理・運営を行う。 (b) ガイドライン作成作業と用語フレームワーク定義のための具体的作業 1) ガイドラインの作成のための実事例調査作業 科学技術計算グリッド、データセンタグリッド、企業内グリッド等について、欧米 等の海外における実事例も含め調査・分類・分析して、ガイドライン作成のための 参考資料とする。 2) ガイドライン作成作業 科学技術計算グリッド、データセンタグリッド、企業内グリッド等について、(1)構 成とモデル、(2)システム運用のポリシィ、(3)通信方法、(4)セキュリティ、(5)管理 情報、(6)制御方式等の６アイテムについて、具体的な項目を抽出。また、これらに 3-7 - 7 - 基づき、それぞれのグリッド環境下でクラス分けを行い、ガイドラインとする。上 記６アイテムについては、見直しも含めて検討する。 3) ガイドラインを作成する中で、グリッドに関する用語の定義の作業を開始する。当面、用語 に関するフレームワークづくりを先行し、グリッドに関する用語の規格化を推進する。 (c) 国際規格提案のための国内のコンセンサス形成 上記(b)に関して、INSTAC と協力し、国内の標準規格化を図るべく、国内の関係機関と連携をとり、国 内の規格に関するコンセンサスを形成する。 (d) 国際標準化動向調査 国際標準化団体である OGF や ISO/IEC JTC1 における標準化動向を調査し、国際規格提案の準備 をする。 グリッド技術の標準化に関連した活動を行っている団体の動向を調査する。グリッド技術の国際的な 標準化団体である OGF(Open Grid Forum)の他、OASIS, W3C, DMTF, SNIA, ISO/IEC JTC1 について も調査する。 (e) 報告書の作成 本年度の事業成果について、報告書にとりまとめる。 3.4. 研究場所 独立行政法人産業技術総合研究所 グリッド研究センター 〒１０１－００２１ 東京都千代田区外神田１－１８－１３ 秋葉原ダイビル１１階 3.5. 実施期間 事業期間 自 平成１８年４月１日 至 平成１９年３月３１日 3.6. 実施計画日程 年／月 研究内容 4 5 平成 18 年 7 8 9 6 10 11 12 平成 19 年 1 2 3 (a) グリッドコンピューティング標 準化調査研究委員会の運営 (b) ガイドラインの作成作業 (c)用語集の作成作業 (d)国際標準化動向調査 (e)報告書の作成 年／月 委 員 会 名 ①委員会 平成 17 年 4 5 ○ 6 ○ 3-8 - 8 - 7 8 ○ 9 ○ 平成 18 年 10 ○ 11 ○ 12 ○ 1 ○ 2 ○ 3 ○ 3.7. 研究体制 （１）管理体制及び研究組織 イ．管理体制 理事長 企画本部長 総括企画主幹 財務会計部門長 経理室長 産学官連携推進部門長 企業・大学契約室長 工業標準部長 業務管理責任者 グリッド研究センター長 関口 智嗣 ロ．研究組織 業務管理責任者 グリッド研究センター長 関口 智嗣 グリッド コンピューティング 標準化調査研究委員会 事務局 グリッド研究センター 秋葉原サイト （２）研究体制 研究者氏名 所属・役職 伊藤 智 独立行政法人産業技術総合研究所 グリッド研究センター センター長代理／ビジネス応用チーム・チーム長 独立行政法人産業技術総合研究所 グリッド研究センター 基盤ソフトウェアチーム 独立行政法人産業施術総合研究所 グリッド研究センター ビジネス応用チーム 竹房 あつ子 伊達 浩一 （３）経理担当者氏名及び機械装置等の管理責任者並びに役職名 （経理責任者）細川 潤一 独立行政法人産業技術総合研究所 財務会計部門 経理室長 （管理責任者）伊藤 智 独立行政法人産業技術総合研究所 グリッド研究センター 副センター長 3-9 - 9 - 4. 実施結果 本委員会では、以下二つの事業を行った。 （１） ガイドライン作成作業と用語フレームワーク定義のための具体的作業 （２） 国際標準化動向調査 ガイドライン作成作業と用語フレームワーク定義のための具体的作業は、ガイドラインを作成するため に必要な事例の調査と分析、グリッドシステム・環境のモデル化、グリッドシステムのいくつかの用途例に 対するガイドライン項目となる要件のリストアップを行った。また、国際標準化動向調査は、グリッド技術の 国際標準化団体である OGF (Open Grid Forum)とその他のグリッド技術の標準化に関連する団体の動 向を調査した。 以下、各々の項目について報告する。 4.1. ガイドライン作成作業と用語フレームワーク定義のための具体 的作業 4.1.1. (a) 過去の活動と本委員会の活動の関係 過去の活動 INSTAC は平成 14 年に「グリッドコンピューティング標準化調査研究委員会」を立ち上げ、グリッドコン ピューティング技術に関する標準化の動向を３年間に渡って、調査、分析、討論を行ってきた。その結果、 最終（平成 16）年度には 1) グリッド関連技術標準化の状況の調査 2) 日本における主なグリッド技術の標準化活動の調査 3) グリッド構築のガイドライン 4) グリッドコンピューティングに関する用語集 などの成果をあげた。 グリッド構築のガイドラインは、最終年度からスタートした活動の成果であり、グリッドとして構築された システムやグリッド関連製品の相互比較を可能とするために、グリッドを特徴付ける多くの項目を抽出し、 それぞれに複数の基準を規定している。これにより、グリッドの捉え方、および様々なグリッドの活動同士 の比較が行いやすくなった。グリッドにおける標準化の一つの方向性を示し、グリッドのガイドラインの枠 組みを作り上げることができた点で意義は大きい。 しかしながら、限られた時間と調査範囲の中での取り組みであることから、グリッド技術に関連した全て の項目を適切に抽出できている訳ではなく、各項目に記載された基準も目的を達成可能な内容に設定 できたとはいえない。また、現時点においても OGF やその他の標準化団体において多数の仕様が策定 中であり、策定された仕様を順次ガイドラインに取り込み、基準を再構築していく必要がある。特にビジネ ス分野においては、組織を越えたリソースの提供と利用にあたり、SLA、課金、QoS、など重要度の高い 項目が多数あり、ガイドラインの整備は必要である。 この活動のまとめとして、今後このガイドラインが一般に広く利用されるためには、以下の取り組みが 必要であると考えられた。 z ガイドラインの評価と見直しの実施 標準化団体における仕様策定状況および各種グリッドプロジェクトのフォローを行い、ガイドラインに おける項目と基準内容の妥当性を評価することが必要である。具体的な評価方法としては、グリッドの関 連プロジェクトにおける環境に対して、ガイドラインに照らしてみることが考えられる。さらに、評価結果に 4-10 - 10 - あわせて基準内容の見直しを行う必要がある。 z 国内におけるガイドラインの普及 作成したガイドラインを広く認知してもらい、活用を促す必要がある。そのため、グリッドに関連するシ ンポジウムや講演の機会を捉え、ガイドラインの紹介や利用方法の説明を行う必要がある。 z 国際標準化 グリッドのガイドラインは、国内においても一つのドキュメントとして作成されたに留まっている。国内に おいても効力のあるドキュメントとするとともに、OGF や JTC1 などの適切な標準化団体へ提案していくこ とで、国際的にも標準の位置づけとなることが望まれる。 (b) 本委員会の活動 INSTAC における委員会の活動を受けて、グリッドのガイドライン策定を進めるため、本委員会が設置 された。本委員会では、INSTAC の委員会で策定されたガイドラインをベースとして、3 年間の計画で改 定を行うことを目的としている。また、その過程としてガイドラインの記載に必要となる用語の定義を行う。 ガイドラインについては、最終的には、OGF や JTC1 など国際的な標準化に向けた活動を行う。 今年度は、昨年度の活動を受けて、グリッドシステムのモデル化を整理するとともに、具体的なガイドラ イン項目の作成を進める。 これまでの検討では、グリッドシステム全般に適用することを狙い、ガイドラインを項目とそのレベルと いう方法で記述していた。しかし、グリッドシステムは多様であり、汎用的なガイドラインとして記述するこ とは困難であることが明らかとなった。そこで、今年度の本委員会の活動では、グリッドシステムとしていく つかの用途例をとりあげ、それぞれのシステムへの要件をリストアップする方針で進めることとした。 4-11 - 11 - 4.1.2. (a) グリッドシステムのモデル グリッドシステムのプレイヤ グリッドシステムにおけるプレイヤ（登場人物）に関して、用語の定義・使い方を規定した。 過去に INSTAC の委員会では、OGSA でとりあげられているユースケース等を精査し、提供物として リソースに着目して整理した結果、グリッドシステムを構成するプレイヤを提供者、仲介者、利用者の３つ に分類してきた。ただし、この３者の関係は相対的・相互的なもので、仲介者なしで提供者と利用者だけ の２者しか登場してこないケースや、提供者や仲介者から提供されたリソースをさらに多段に仲介してい くようなケースを内包しており、やや複雑なモデルによる整理だった。 今回、改めて多くのユースケースを見直してきた結果、プレイヤ間での提供物の流れをモデル化し て整理していくと、提供物の流れは提供者と利用者の２者間の関係にすべて帰着できることが分かって きた。図 4-1にあるように、従来の仲介者は、提供者から見れば利用者に、利用者から見れば提供者に 見えるため、仲介者の概念は必ずしも必要ではなく、より単純化したモデルで考えることができた。した がって、本委員会ではプレイヤについては提供者と利用者の２者とすることにした。 提供者 リソース 提供者 仲介者 利用者 提供物 （リソース） 提供物 リソース 個々の関係は 提供者～利用者 提供者 リソース 提供者 利用者 提供者 提供物 （リソース） 利用者 提供物 リソース 図 4-1 提供者～仲介者～利用者の関係 上記の検討結果によれば、グリッド環境におけるプレイヤ間のもっとも基本的な関係は、提供物を介 して複数の提供者と利用者が結びつく相互関係である（図 4-2）。さらに、互いに提供者～利用者となる 関係が連鎖的につながっていく一般的な形態を示したものが図 4-3である。 4-12 - 12 - 提供者 利用者 提供物 提供物 提供者 リソース 利用者 提供者 利用者 提供物 （リソース） 提供者 提供物 リソース 図 4-2 提供者～利用者の基本モデル 提供者 リソース 提供者 利用者＝提供者 利用者＝提供者 提供物 （リソース） 提供物 （リソース） 利用者（ｴﾝﾄﾞﾕｰｻﾞ） 提供物 リソース 図 4-3 提供者～利用者の連鎖関係 また、提供者や利用者とは役割が異なる管理者をプレイヤとする考え方も検討してきたが、提供物 （リソース）の管理サービスを利用者に提供するという観点でみれば、サービス提供者の一形態であると みなすことができるため、やはり提供者～利用者の２者間モデルに帰着できる。 (b) グリッドシステムにおける提供物 グリッド環境を考える際にどのような IT リソースがグリッド化されてグリッド・コンポーネントとして協調し 利用されるかは極めて重要なことである。グリッド・コンポーネントはグリッド環境におけるプレイヤ（提供 者と利用者）間でやり取りされる提供物として定義することが出来る。 (1) グリッド環境提供物の階層構造 様々なグリッド・コンポーネントを分類することは、ガイドラインを作成し利用するにあたり、ガイドライン の記述が何を指しているのかを明示し、提供者と利用者の依存関係を明確にすることが可能になる。 ここでは提供物を図 4-4に示すように、横軸にストレージ、コンピューティング、ネットワークの３種類、 そして縦軸に物理環境からアプリケーションまでを４層に分類した。ちなみに、本図はエンタープライズ・ 4-13 - 13 - グ リ ッ ド ・ ア ラ イ ア ン ス （ EGA ： Enterprise Grid Alliance ） が 公 開 し た 参 照 モ デ ル [http://www.gridalliance.org/en/WorkGroups/ReferenceModel.asp]を参考にし、作成に当たっては多大 な影響を受けている。 第4層 アプリケーション・ サービス 各種サービス、ポータルシステム、ERP/CRMアプリケーション データベース、Webサーバ、アプリケーションサーバ、 第3層 仮想ファイルシステム、オーバーレイネットワーク プラットフォーム 第2層 OE/動作環境 第1層 物理環境 各種（ネットワーク 含）ファイルシステム 各種OS（Windows、 Linux、etc.） IP、TCP、UDP、etc. SAN、NAS、HSM サーバ、ブレード、 etc. スイッチ、ルータ、 FW機器、VPN装置 ストレージ コンピューティング ネットワーク 図 4-4 グリッド環境提供物の層 第１層（物理環境）：ハードウェア単独としてのコンポーネント この層は、基礎となる物理的構成要素であり、IT リソース群で物理的に構成されるグリッド環境を作り 上げる元となる。この層は、たとえば、従来型の個々のサーバ、ネットワーク・スイッチ、ディスクなどがこ れに含まれる。具体的には、ストレージとして、SAN、NAS、HSM、コンピュータとしてサーバやブレード、 ネットワークとしてスイッチ、ルータ、FW（ファイヤーウォール）機器、VPN 装置などがこの層に分類され る。 第２層（OE/動作環境）：第 1 層のコンポーネントをソフトウェアによって外部から制御・利用可能としたも の この層のコンポーネントは第１層の物理グリッド・コンポーネントを抽象化してリソースとして提供し、サ ービスまたはアプリケーションのようなグリッド・コンポーネントがそれを利用できるようにしたものである。 またこれによって、より概念的なレベルで、よりスケーラブルな管理が可能になる。具体的には、ストレー ジとして提供される各種（ネットワーク含）ファイルシステム、Windows や Linux といった各種 OS、IP や TCP、UDP というより論理化されたネットワークリソースが含まれる。 第３層（PF/プラットフォーム）：第 2 層のコンポーネントを複数組み合わせ、最終サービスを構成するコ ンポーネント この層に位置づけられるコンポーネントは、従来型のサービスやアプリケーションの単一インスタンス に相当し、実行可能バイナリのようなもの（たとえばデータベース）である。つまり複数のスレッドまたはプ ロセスに分解可能となる、第２層の OS の単一インスタンス上で実行可能プログラムとして実行されるアプ リケーションまたはサービスと位置付けられる。具体的には、データベース、Web サーバ、アプリケーショ ンサーバ、仮想ファイルシステム、クラスタ管理ツール、オーバーレイネットワークが挙げられる。更に負 荷分散されている Web サーバ、アプリケーション・サーバ・クラスタ、データベース・クラスタもこの層に分 4-14 - 14 - 類され、抽象度を高めた、しかし、同じインタフェースと機能を提供するものも存在する。 第４層（アプリケーション・サービス）：ビジネスや学術分野において、エンドユーザの職務実施のために 利用するサービス アプリケーション・サービスはエンドユーザに提供されるサービスであり、第３層のプラットフォーム層の グリッド・コンポーネントの集合体として実現されビジネスや科学技術計算機能を実行する。ポータルシス テムや ERP（Enterprise Resource Planning）、CRM（Customer Relationship Management）アプリケーショ ンをイメージすると理解しやすい。 ちなみに、エンドユーザは 4 層の上に位置することになる。すなわち何かしらのサービスやアプリケー ションを利用するエンドユーザは、対象となるインフラがどうなっているか、つまりグリッド環境か否かは判 らないこととなる。もし対象がグリッド環境であると判別が付く場合は、エンドユーザは管理の機能を肩代 わりするなどしていることが想定される（詳細は次節を参照）。 と ころ で 、OGF （ Open Grid Forum ）の主要 アー キテ ク チ ャであ る OGSA（ Open Grid Services Architecture）の標準化の対象は主に 3 層と 4 層に焦点が当てられている。更に OGSA 準拠を目指して いる Globus Toolkit は 4 層で提供されるグリッド・アプリケーションを作成するツールであり、3 層以下のイ ンフラストラクチャを効率良く動作させるために利用される。また ERP や CRM といった既存のアプリケー ションや業種別アプリケーション、Web サーバ等で提供されるポータル・サービスも同様に 3 層以下を利 用している。それらはどの層をグリッド環境として管理対象にしているかの違いとなる。 (2) グリッド環境における管理やセキュリティに関する考察 グリッド環境で重要な点は、グリッド・コンポーネントをサービスと考えて管理することにある。グリッド環 境の管理という点では、それぞれの層の管理も必要であるが、4 層を横断的にみることがグリッド環境の 管理機能に求められる。更にセキュリティに対する配慮も横断的になされるべきである。 管理、セキュリティ、… 第4層：アプリケーション・サービス 第3層：PF/プラットフォーム 第2層：OE/動作環境 第1層：物理環境 ストレージ コンピューティング 図 4-5 グリッド環境と管理やセキュリティの関係 4-15 - 15 - ネットワーク ちなみに、EGA の参照モデルでもグリッド管理エンティティ（GME： Grid Management Entity）と称し、 このような管理体系を基本として考えている。 (3) グリッド環境提供物を分類することによるメリット グリッド・コンポーネントをこのような各層に分類することにより、提供者と利用者の依存関係を明確に することが可能になる。例えば、商用データ・センタでは、そこに含まれる様々なグリッド・コンポーネント は、上の層になるに従って抽象度を増すオブジェクトの層として表現される。各層はその下の層を仮想 化または抽象化したものであり、これによって柔軟性、効果性、管理性が高まる。最も下に位置するのが 物理グリッド・コンポーネントであり、これは最終的には各層を介してビジネス・プロセスに結び付く。つま り、ビジネス・プロセスはそのような物理グリッド・コンポーネント上で実行されるサービスとして実現される ことになる。 またグリッド・コンポーネントの動作関係を記述するプロビジョニングは上位層から下位層に向けておこ なわれるなど、グリッドで必要な依存関係を明確に記述することができる。グリッド・コンポーネントの分類 がグリッド環境での協調動作する様々なコンポーネントを単純なモデルで表現し、同時にそれらの相互 の関連および依存関係を表すこともできる。様々なグリッド・コンポーネントを類似した同系のグループと してまとめ共有物として定義することも可能となる。 更にはこの関係を利用してユースケースなどグリッド環境を表現することによって他のユースケースと の関係も明確になり、グリッド環境を特徴、定義付ける際にとても有効な手段となる。これは環境のメンテ ナンスやそれ以降の拡張対しに極めて重要な作業となり、万が一の障害対策にも有効な表現手段とな ろう。 コンポーネントの分類は、その環境や使用法によって様々な側面を与えるが、それらのコンポーネント は基本的な特徴とライフサイクルを共有することとなり、グリッド環境を構築し管理する際には欠かせな い。 (c) プレイヤの役割と提供物の関係 先年度まで、本委員会では、(a)グリッドのプレイヤに示すように、基本的なプレイヤを利用者と提供者 という観点より定義してきたが、グリッドシステムの提供物との関係を IT ライフサイクルのフェーズ毎に見 てみるとプレイヤは、単純な利用者と提供者の関係だけではなく、様々な役割を持ちグリッドシステムの 提供物と関係していることが判った。そこで、本委員会では、プレイヤの役割を定義して各役割間の関係 とプレイヤの役割と提供物の関係を示すこととした。 尚、グリッドシステムは、(b)グリッド環境における提供物で示したレイヤのいずれか一部でグリッドを使 用しているシステムに対して、全体または一部を指し示す名称として使用している。 ●プレイヤの役割定義 ここでは、プレイヤの役割を定義する。ここで定義する役割は、機能的に分類した結果出てきた役割で ある。そのため、実際のグリッドシステムのプレイヤを見ると一人のプレイヤが複数の役割を兼任してい たり、1 つの役割を複数のプレイヤで協力して行っていたりすることがある。 ・ システム使用者 システム運営者が提供するグリッドシステムを使用する人(組織)。 4-16 - 16 - システム使用者は、 「使用しているシステムがグリッドである事を認識しているシステ ム使用者」と「提供者がグリッドシステムであることを隠蔽しているためグリッドシ ステムであることを認識していないシステム使用者」がいる。 （注）本報告書で記述するグリッドシステムのガイドラインは、基本的にグリッドシ ステムを認識していない利用者や提供者を読者として想定していないので、単純にシ ステム使用者と記述する場合は、グリッドシステムを認識しているシステム使用者を 指している。 ・ システム運営者 システム使用者へグリッドシステムを提供する人(組織)。 システム運営者は、主に下記のような機能をはたす。 ・グリッドシステムの仕様確定 ・グリッドシステムの運用管理，提供 ・グリッドシステムの評価 （注）システム運営者は、運営しているシステムがグリッドシステムであることを認 識してシステムの運営を行っているが、システムの使用者へグリッドシステムとして 公開するかどうかは、運営者の持つポリシやシステム使用者との契約事項によって決 定される。システム運営者は、システムの企画を行う機能と運用管理を行う機能を持 っている。 ・ システム構築者 システム運営者から提出された仕様に基づいてグリッドシステムを構築する人(組 織)。 システム構築者は、主に下記のような機能をはたす。 ・コンポーネントの選定 ・要求仕様にある特定機能を実現するコンポーネントの作成 ・確定したコンポーネントを接続 ・グリッドシステムが的確に動作するように設定 一般的には、システム・インテグレータの担当業務である。 ・ グリッド関連製品ベンダ グリッドシステムを構築するために必要な製品（グリッド関連製品）を提供するベン ダ。 グリッド関連製品は、特定の使用者の為に作成された物ではなく不特定多数の使用者 の為に作成されたグリッドシステムを構築するために必要不可欠な製品群をさす。 （例）グリッド関連製品には、グリッドシステムの構築用に作成されたグリッド用の ソフトウェア（GlobusToolkit，Condor，Gfarm，Ninf-G など）や、グリッドを 意識していないサーバ、ネットワークのようなハードウェアが含まれる。 ・ 外部グリッドシステム提供者 システム運営者が提供するグリッドシステムの一部を構成する外部のグリッドシステ ムを提供する人(組織)。 4-17 - 17 - ・ エンドユーザ グリッドシステムの第４層の使用者であり、他の者に何も提供することがないエンド ポイントに位置する人（組織） 。 （注）グリッドシステムの第４層の提供物は、グリッドシステムであることが使用者 に隠蔽されているため、エンドユーザはグリッドを意識することはない。エンドポイ ントの位置を含んでいても、第３層など下位のレイヤも使用している場合は、グリッ ドを意識して使用することがある。この場合は、システム使用者とエンドユーザの役 割を有している。 エンドユーザは、グリッドシステムを意識していないため、本委員会で作成するガイ ドラインの読者としては想定されていない。 なお、グリッドシステムのプレイヤの役割は提供物毎に存在するため、グリッドシステムが階層的または 並列的に複数のシステムが連携している構造を持っている場合は同一のプレイヤが複数の役割を持ち 得る。 グリッドシステム２ 業務アプリ 第４層 第３層 第２層 第１層 ネット ワーク スト コン レージ ピュー ティング グリッドシステム１ 商用データセンタ システム使用者 顧客企業 システム使用者 システム運営者 データセンタ事業者 システム運営者 外部グリッド システム提供者 エンドユーザ グリッドシステム全体 図 4-6 同一のプレイヤが複数の役割を持つ例 図 4-6は、第３層までを商用データセンタが提供し、その上に顧客企業が業務システムを構築している ケースである。下位のグリッドシステム１から見るとデータセンタ事業者がシステム運営者で顧客企業が システム使用者である。上位のグリッドシステム２から見ると、顧客企業がシステム運営者でデータセン タ事業者は外部グリッドシステム提供者である。楕円形がプレイヤの役割を表し、点線で結ばれている 役割は、同一プレイヤが複数の役割を持っていることを示している。また、矢印で提供者から提供物が 利用者へ提供されていることを表している。 ●IT ライフサイクルを想定したプレイヤ IT ライフサイクル（企画，予算，計画，調達，開発，運用，評価）の中で、エンドユーザを除くプレイヤの 役割を見てみる。（図 4-7） 4-18 - 18 - プレイヤの 役割 企画 予算 計画 調達 システム 使用者 利用者 （VOC） システム 運営者 提供者 利用者 利用者 システム 構築者 提供者 提供者 （見積） グリッド関連 製品ベンダ 提供者 （仕様） 提供者 （見積） 提供者 （製品） 外部グリッド システム 提供者 提供者 （仕様） 提供者 （見積） 提供者 利用者 開発 （構築） 利用者 運用 評価 （破棄） 利用者 利用者 提供者 利用者 提供者 利用者 提供者 提供者 提供者 提供者 図 4-7 IT ライフサイクルにおけるプレイヤの役割 ・ グリッドシステムの企画から構築フェーズでは、構築するグリッドシステムを企画するシステム運 営者や企画に合わせたシステムを構築するシステム構築者，構築するシステムに必要な製品を 供給するグリッド関連製品ベンダや外部より利用可能なグリッドシステムを提供する外部グリッド システム提供者などがある。 ・ システム運用や評価のフェーズでは、グリッドシステムを提供しているシステム運営者と外部グリ ッドシステム提供者とグリッドシステムを利用するシステム使用者がプレイヤとなる。 ●プレイヤの役割間の関係 プレイヤの役割間の関係を役割間で遣り取りされる物（対価）に着目して VCA(Value Chain Analysis)図 で記述する。（図 4-8） 4-19 - 19 - グリッド関連 製品ベンダ エンドユーザ ライセンス 使用料 製品 ライセンス 製品選定 グリッド システム提供 システム使用者 システム運営者 仕様提示 構築資金 システム構築者 使用料 グリッド システム 使用料 外部グリッド システム提供 外部グリッド システム選定 外部グリッド システム提供者 図 4-8 プレイヤの役割間の VCA 図 グリッドシステムの運用フェーズで、システム運営者がシステム使用者に対してグリッドシステムを提供し 対価として使用料を貰うことになる。外部グリッドシステムを使用する場合は、システム運営者が外部グリ ッドシステム提供者からシステムの提供を受け対価として使用料を払うことになる。 なお、システム運営者とシステム使用者が同一組織やボランティアの場合など必ずしも使用料が発生し ない場合も想定される。 グリッドシステムの企画から構築フェーズで、システム運営者からシステム構築者にシステム仕様が提示 され、その仕様に合わせて構築されたグリッドシステムがシステム構築者からシステム運営者に引き渡さ れる。グリッドシステム構築の対価として構築資金がシステム運営者からシステム構築者に払われる。 グリッドシステムにグリッド関連製品を使用する場合は、システム運営者は、グリッド関連製品ベンダより 製品ライセンスを貰いライセンス使用料を払う。 ライセンス使用料は、製品購入料としてシステム構築時に支払われる場合や、システム運用時にグリッ ド関連製品の使用量に伴い従量的に支払われる場合など製品や契約により支払い方法が異なることが 考えられる。 グリッドシステムで使用するグリッド関連製品を含む製品や外部グリッドシステムの選定は、システム構 築者が行う。現実には、システム運営者から使用製品やシステムの指定が有る場合も考えられるが、そ の場合は、システム運営者がシステム構築者の役割の一部を肩代わりしているものと考える。 エンドユーザは、システム運営者によりグリッドシステムを隠蔽して提供されているエンドユーザの環境 でジョブ（アプリケーション）を実行する特別なシステム使用者として位置付けられる。 次にプレイヤの役割間で遣り取りされる情報の流れに着目して役割間の関係を記述する。（図 4-9） 4-20 - 20 - グリッド関連 製品ベンダ エンドユーザ 製品ライセンス 仕様 提供システムのSLA システム使用者 システム運営者 製品仕様 グリッドシステムの 要求仕様 提供システムの SLA システム構築者 外部グリッド システム仕様 外部グリッド システム提供者 図 4-9 プレイヤの役割間の情報の流れ システム使用者とシステム運営者の間では、グリッドシステムが提供する機能に対しての SLA(Service Level Agreement)が結ばれる。 システム運営者とシステム構築者の間では、構築するグリッドシステムの RFP(Request For Proposal)が 示され最終的には要求仕様という形で合意する。 システム構築者は、グリッド関連製品ベンダの示す製品仕様と価格を見て使用する製品を決定する。 外部のグリッドシステムを使用する場合は、システム構築者が外部グリッドシステムの仕様を見て使用す るグリッドシステムを選定し、システム運営者と外部グリッドシステム提供者の間で提供されるグリッドシス テムの使用に対しての SLA が結ばれる。 なお、エンドユーザが存在する場合は、第４層のエンドポイントで実行されるジョブ（アプリケーション）を 実行する特別なシステム使用者であるため、エンドユーザ環境を提供するグリッドシステムのシステム運 営者とグリッドシステムを意識しない SLA を結ぶことになる。 ●プレイヤの役割とグリッドシステム提供物の関係 プレイヤの役割とグリッドシステムの提供物の関係を役割間で遣り取りされる情報と共に記述する。（図 4-10） 4-21 - 21 - システム使用者 提供サービスの SLA エンドユーザ エンドユーザ環境仕様 グリッド システム使用 エンドユーザ環境 製品ライセンス仕様 システム運営者 グリッド システムの 要求仕様 システム構築者 グリッドシステム 構築 製品 仕様 提供システム のSLA グリッド関連 製品ベンダ 提供 システム の仕様 グリッド関連製品 提供 外部グリッド システム提供者 各種サービス，ポータルシステム ERP/CRMアプリケーション・サービス 管理，セキュリティ、・ ・ ・ 仕様決定 運用管理 データベース，Webサーバ，アプリケーションサーバ 仮想ファイルシステム，オーバレイネットワーク 各種ファイル システム （ネットワーク含） 各種OS （Windows, Linux, UNIX, etc） Ethernet, IP, TCP, UDP, etc SAN, NAS, etc サーバ，ブレード， etc スイッチ，ルータ， FW機器， VPN装置，etc ストレージ コンピューティング ネットワーク グリッド・システム 外部グリッド システム提供 図 4-10 プレイヤの役割とグリッドシステム提供物の関係 システム使用者はシステム運営者の提供する機能を介してグリッドシステムを使用している。第 4 層にエ ンドポイントがあり、それを使用している特別なシステム使用者として、エンドユーザが存在していること がある。グリッドシステムの提供物が第４層でない場合は、エンドユーザは登場しない。 システム運営者はグリッドシステムの仕様を企画・決定し、運用フェーズでグリッドシステムの運用管理 を行う。 システム構築者は、グリッドシステムの要求仕様に従い必要な製品を選定してグリッドシステムを構築す る。 グリッド関連製品ベンダは、グリッドシステムで使用する製品を提供する。 外部グリッドシステム提供者は、グリッドシステムの外部より利用可能な機能を提供するグリッドシステム を提供する。 (d) 提供物の状態遷移 前節で提供者と利用者の間にある提供物を明らかにしたが、その提供物に対して、提供者と利用者 が行いうる操作・処理ごとに提供物の状態が遷移する。例えば、提供物を構成、配備する場合には、第１ 層では、未使用→構成済→稼動中になる。 この節では、ガイドラインを作成するにあたり、この提供物の状態遷移に関して用語の定義、提供物の 状態遷移を明らかにするために委員会で議論した結果を整理する。提供物の状態遷移は各層毎に異 なると考えられるが、基本的な状態遷移の概念は共通であると思われる。 図 4-11に示すように基本的に提供物は三つの状態（未使用/構成済/稼動中）をとり、それらの状態 間を三つのフェーズ（開始フェーズ/稼働フェーズ/終了フェーズ）で遷移する。図 4-12に示すように、 それぞれの層における稼働フェーズが上位層の遷移のトリガーとなり、最終的にエンドユーザへのサー ビスとつながる。 4-22 - 22 - 開始フェーズ 稼動フェーズ 構成・設定 起動 導入 ○○稼動中 ○○構成済 廃棄 上位層 下位層 ○○未使用 解体（分離） 停止 終了フェーズ 図 4-11 基本的な提供物の状態遷移 物理層稼動フェーズ 開始フェーズ 開始フェーズ ＯＥ層稼動フェーズ 開始フェーズ 構成 LANケーブル、 電源ケーブルの結線 導入 廃棄 HW構成済 解体（分離） HW稼動中 停止 ＯＥ起動 PF構成 グリッドミドルインストール 複数のOE環境を束ねる OE構成済 OE稼動中 ＯＥ解除 ＯＥ停止 ＰＦ起動 PF稼動中 PF構成済 ＰＦ解除 サービス配備 業務アプリケーション配備 ＰＦ停止 アプリケーション・ サービス層稼動 フェーズ サービス起動 ＳＶ配備済 SV稼動中 サービス解除 エンドユーザ層 未使用 起動 OE構成 OS、ミドル、ライブラリ、 ファイルシステム のインストール ＰＦ層稼動フェーズ 開始フェーズ サービス停止 終了フェーズ 終了フェーズ 終了フェーズ 終了フェーズ 図 4-12 提供物の状態遷移 ただし、これらの定義はマクロに見た遷移に過ぎず、詳細の遷移は層毎に異なる。さらに各層毎の提 供物の状態遷移についても次のように定義する。 第１層（物理層） ここでは物理デバイスのレベルでの状態を考える。SAN、NAS、HSM やサーバハードウェア、ネットワ 4-23 - 23 - ーク機器それぞれ単独での状態を表す。考えられる、状態は以下の３つになる。 (1) 未使用：この層での未使用とはハードウェアの物理構成（電源、ネットワーク接続など）が行われ ておらず、ただ単に部品が用意されている状態である。 (2) ハードウェア構成済：ハードウェアの設置が終わり、電源ケーブルが電源に接続され、ネットワー クケーブルがネットワークに接続されているような状態である。 (3) ハードウェア稼働中：電源が投入されており第２層の開始フェースが実施できる状態である。この 状況で、アプリケーションが動くわけではなく、このあと OS の起動やミドルウェアやアプリケーショ ンおよびネットワークの構成等が必要となる。 基本的な遷移をフェーズごとに考えると以下のようになる。 開始フェーズ：未使用→HW 構成済→HW 稼働中 未使用→HW 構成済の状態へは HW の組み立て、LAN ケーブル、電源ケーブル等の結線の作 業が必要となり、HW 構成済→HW 稼働中の状態への遷移は、電源の投入が必要となる。 稼働フェーズ：HW 稼働中 稼働フェーズでは提供物は HW 稼働中の状態であり、上位層（Operating Environment/動作環 境層）での状態遷移が行われている状態を表す。 終了フェーズ：HW 稼働中→HW 構成済→未使用 HW 稼働中→HW 構成済の状態へは電源の OFF 等の作業が必要となる。 HW 構成済→未使用は、基本的に一時的に追加した HW のみにて行われる状態遷移であって、 頻繁におきうる状態遷移ではない。施設移設や、サイトの運営停止などの際に行われ、作業とし ては、HW の解体やケーブル等の結線をはずすことになる。 第２層（Operating Environment/動作環境層） ここでは Linux などの各種 OS、ストレージとして提供される各種ファイルシステムやネットワークリソー ス・レベルでの状態を考える。第１層で構成される機器を利用する場合の論理化された集合体それぞれ での状態を表す。考えられる、状態は以下の３つになる。 (1) OE 未使用：この層での未使用とはハードウェアの物理構成（電源、ネットワーク接続など）が行わ れている上に、それら物理構成を利用起動できるが、サービスを提供するために必要な OS やネ ットワーク・ソフトウェア等が導入されていない状態を表す。第１層でのハードウェア稼働中と同じ 状態となる。 (2) OE 構成済：ハードウェアを起動でき、サービスを提供できるように、OS や各種ファイルシステムそ してネットワーク・ソフトウェアの導入構成が行われた状態である。 (3) OE 稼働中：OS が起動され、構成されたシステム・サービスやネットワークが利用可能となっており、 アプリケーションを行うにあたり、ユーティリティ・サービスが提供できるような状態である。 基本的な遷移をフェーズごとに考えると以下のようになる。 開始フェーズ：OE 未使用→OE 構成済→OE 稼働中 OE 未使用→OE 構成済の状態へは基本ソフトウェアを導入し、ネットワークの構成、システムサー 4-24 - 24 - ビスの構成の作業が必要となり、OE 構成済→OE 稼働中の状態への遷移は、OS の起動、システ ム・サービス（ネットワークの開始を含む）の開始が必要となる。 稼働フェーズ：OE 稼働中 稼働フェーズでは提供物は OE 稼働中の状態であり、上位層（PF/プラットフォーム）での状態遷 移が行われている状態を表す。 終了フェーズ：OE 稼働中→OE 構成済→OE 未使用 OE 稼働中→OE 構成済の状態へはネットワークの停止およびシステム・サービスの停止の作業 が必要となる。OE 構成済→OE 未使用は、基本的に一時的に追加した OE のみにて行われる状 態遷移であって、頻繁におきうる状態遷移ではない。サーバの構成変更や、サービス環境の変 更などの際に行われ、作業としては、システム・サービスの削除やネットワークの構成を削除する ことになる。 第３層 （PF/プラットフォーム） ここではユーティリティ・サービスやアプリケーションの単一インスタンスに相当し、実行可能バイナリの ようなもの（たとえばデータベース）である。つまり複数のスレッドまたはプロセスに分解可能となる、第２ 層の OS の単一インスタンス上で実行可能プログラムとして実行されるアプリケーションまたはサービスで の状態を考える。考えられる状態は、以下の３つになる。 (1) PF 未使用：この層での未使用とは基本ソフトウェアやネットワーク構成等が行われている上に、ユ ーザがアプリケーションを稼働するために必要なシステム構成を利用できる状態なあります。この 状態では、OS が起動され、構成されたシステム・サービスやネットワークが利用可能となっており、 アプリケーションを行うにあたりユーティリティ・サービスが行えるようにある状態である。第 2 層で の OE 稼働中と同じ状態となる。 (2) PF 構成済：ユーザにサービスを提供するにあたり、必要なユーティリティ・サービスの構成、また 複数の OE 環境を束ねるグリッドミドルウェアの導入を行い、グリッド環境をアプリケーションが使う ための構成が行われた状態である。 (3) PF 稼働中：ユーティリティ・サービスが起動され、構成されたグリッド環境が利用可能となっており、 ユーザアプリケーションがグリッド環境を使えるようになっている状態である。 基本的な遷移をフェーズごとに考えると以下のようになる。 開始フェーズ：PF 未使用→PF 構成済→PF 稼働中 PF 未使用→PF 構成済の状態へはグリッド・ミドルウェアを構成し、ユーザ・アプリケーションがグリ ッド環境を利用できるような構成の作業が必要となり、PF 構成済→PF 稼働中の状態への遷移は、 グリッドミドルウェアの起動、ユーティリティ・サービス（スケジューリング機能やプロビジョニング機 能）の開始が必要となる。 稼働フェーズ：PF 稼働中 稼働フェーズでは提供物は PF 稼働中の状態であり、上位層（アプリケーション・サービス）での状 態遷移が行われている状態を表す。 終了フェーズ：PF 稼働中→PF 構成済→PF 未使用 PF 稼働中→PF 構成済の状態へはグリッド環境の停止およびユーティリティ・サービスの停止の 作業が必要となる。PF 構成済→PF 未使用は、グリッド環境の構成変更や、サービス環境の変更 4-25 - 25 - などの際に行われ、作業としては、ユーティリティ・サービスの削除やグリッド環境の構成を削除 することになる。 第４層 （アプリケーション・サービス） アプリケーション・サービスはエンドユーザに提供されるサービスであり、第３層のプラットフォーム層の グリッド・コンポーネントの集合体として実現されビジネスや科学技術計算機能を実行する層となる。考え られる状態は、以下の３つになる。 (1) サービス未使用：この層での未使用とはグリッド環境構成等が行われている上に、ユーザがアプ リケーションを稼働させるために必要なユーティリティ・サービスを利用できる状態なあります。第３ 層での PF 稼働中と同じ状態となる。 (2) サービス構成済：ユーザの業務アプリケーションを稼働するにあたり、必要なサービスの配備、業 務アプリケーションの配備を行い、ユーザがアプリケーションを使うための構成が行われた状態で ある。 (3) サービス稼働中：ユーザ・アプリケーションおよびそれを使うためのサービスが起動され、構成さ れたグリッド環境でユーザ・アプリケーションがユーザからの要求を受け入れられる状態である。 基本的な遷移をフェーズごとに考えると以下のようになる。 開始フェーズ：サービス未使用→サービス構成済→サービス稼働中 サービス未使用→サービス構成済の状態へは業務アプリケーションやそれに関わるサービスを 構成し、グリッド環境への配備が必要となります。サービス構成済→サービス稼働中の状態への 遷移は、業務アプリケーションの起動、それに関わるサービスの開始が必要となる。 稼働フェーズ：サービス稼働中 稼働フェーズでは提供物はサービス稼働中の状態であり、業務アプリケーションが実行されてい る状態を表す。 終了フェーズ：サービス稼働中→サービス構成済→サービス未使用 サービス稼働中→サービス構成済の状態へは、業務アプリケーションの停止およびそれに関わ るサービスの停止の作業が必要となる。サービス構成済→サービス未使用は、業務アプリケーシ ョンの構成変更や、アプリケーション実行環境の変更などの際に行われ、作業としては、業務ア プリケーションの削除や関連するサービス環境の構成を削除することになります。 (e) グリッドシステムの管理 前節までで、「提供者」と「利用者」、「提供物」、「提供物の階層」、「提供物の分類」、「提供物の状態 遷移」を明らかにした。また、階層は下位階層を仮想化または抽象化することで柔軟性、硬化性、効果性、 管理性が高まることを示した。ここでは、これらを関係付けることで、参照モデルとし、この上でグリッド環 境に想定されるユースケースを明らかにし、具体的なグリッド環境を構築する為のガイドラインを作成す る基盤とする。 INSTAC でのガイドライン作成の作業は、多くのユースケースの共通項を抽出する、いわばボトムアッ プのアプローチであった。ここでは、トップダウンの参照モデルからのアプローチにより、昨年までのガイ ドラインと付き合わせることを考える。尚、以下のモデルは暫定のものであり来年度以降、さらに精密にし ていく必要がある。まず、本年度は、昨年度までに作成したガイドラインを前節までの概念と関係付け、さ 4-26 - 26 - らに、「提供物」の階層にどのように反映されうるかを示すに止める。 昨年までに作成したガイドラインの大項目の用語を拾い上げると、「利用目的」「提供物」「プレーヤプ レイヤ」「組織関係」「リソース」「アプリケーション」「通信」「運用ポリシ」「セキュリティ」「管理情報」「制御」 が挙げられる。これを前節までの概念で関係付けると以下のようになると考えられる。 （１）「利用目的」：グリッド環境の価値を示すものであり、「利用者」が持ち、「提供者」がこれを理解し、 提供するものと考えられる。「提供目的」という考え方もありうるが、ここでは「利用目的」を新たな 概念とする。これは、「サービスレベルアグリーメント」として記述され、理解されるべきである。 （２）「提供物」：前節の規定通りであり、階層を持ち、状態を持ち、状態を遷移させる「制御」が可能で あり、状態を必要に応じてアクセスできなければならない。 （３）「プレーヤプレイヤ」：「提供者」または「利用者」である。「仲介者」は「提供者」且つ「利用者」と考 えられ、ここでは省略する。また、「利用者」と「提供者」の間には、「利用目的」から派生する、利 用許諾とそれに対する対価からなる、何らかの契約関係が想定される。この契約関係は SLA（サ ービスレベルアグリーメント）として記述され、サービスレベルと課金の概念が生まれる。SLA は、 提供者と提供物の階層で実現するためにそれぞれのレベルの SLO（サービスレベル目標）に展 開される。SLO はグリッド環境の提供物ごとに SLA を満たすために導き出される条件である。プレ ーヤプレイヤ間の関係は SLA と対価とする。 （４）SLA：「利用者」と「提供者」の間の契約で、対価（またはペナルティ）の対象となるサービスの条件 を指す。通常、「利用者」が直接アクセスする第 4 層のサービスに対する条件となる。 （５）SLO：階層と状態を持ち、状態が制御、アクセスされるグリッド環境の「提供物」ごとの管理要件で ある。通常 SLA から「提供物」の階層内の依存関係に従って導き出される。 （６）「組織関係」：複数の「提供者」または/及び「利用者」の間の関係である。 （７）「リソース」：前節の「提供物」の階層内のグリッド・コンポーネントを指す。 （８）「アプリケーション」：第 4 層の「提供物」の一種である。 （９）「通信」：提供物の第 1 層及び第 2 層の「ネットワーク」の部分に当たる側面と、「利用者」と「提供 物」の間、「提供物」の間でやり取りされる情報の側面を持っていた。 (10)「運用ポリシ」：「提供者」が「提供物」を運用する上での規定であり、新たな概念と考えられる。提供 者より上位の何らかの概念（例えばエンタープライズ・グリッド環境の所有者である、エンタープラ イズなど）により確立され、「提供者」「提供物」「利用者」に適用されるものとも考えられるが、ここ では、何らかの上位概念も含めて「提供者」と考え、上位の「提供者」が「ポリシ」を確立し、下位の 「提供者」に適用するものと考える。「利用者」はこの一部を理解することで、「提供物」を利用する 場合がある。「運用」は上記（ｃ）の「提供物」の「状態遷移」及び各々の「状態」を、個別の SLO を 満たすために発生、維持させることであり、「管理」自体と考えられる。 (11)「セキュリティ」：「提供者」、「提供物」、「利用者」の集合と関係によって生じるすべての側面につい て検討する必要があるが今後の課題とする。例えば、この集合と関係から個別のアーキテクチャ や実装での、「提供物」間、または「提供物」とプレーヤプレイヤ間にセキュリティサービスの集合 が規定される。さらには、プレーヤプレイヤ間で生じるトラストなどについてのセキュリティサービス も発生する。 (12)「管理情報」：「提供者」が「提供物」から採取し、運用の目的に使用する。尚、この情報の一部は 「利用者」が利用のために参照する場合がある。ここでは、「提供者」の「提供物」からの「管理情 報の採取」という関係とする。 (13)「制御」：「提供者」が「提供物」を「ポリシ」に従って運用するためのオペレーションと考えられ「提供 者」の「提供物」に対する関係とする。 以上を「提供物」の階層を明示せずにまとめると、概略として図 4-13のようになる。詳細な定義及び、 上記の解析との突合せは、今後の課題である。 4-27 - 27 - ポリシ 利用目的 参照 理解 適用 持つ 提供物 確立 管理情報 モニタ アクセス 制御 提供者 利用 提供 利用者 契約関係 組織関係 図 4-13 提供物とプレイヤの関係 （１）「提供者」の持つ関係： ¾ 「提供物」を提供する。 ¾ 「ポリシ」を確立する。 ¾ 「利用者」と契約関係を持つ。 ¾ 複数の「利用者」、他の複数の「提供者」との間に組織関係を持つ。 ¾ 「利用目的」を理解する。 ¾ 「提供物」を制御する。 ¾ 「提供物」をモニタし「管理情報」を得る。 （２）「利用者」の持つ関係： ¾ 「提供物」を利用する。 ¾ 「利用目的」を持つ。 ¾ 「提供者」と契約関係を持つ。 ¾ 複数の「提供者」他の複数の「利用者」との間に組織関係を持つ。 ¾ 「ポリシ」を参照する。 ¾ 「提供物」にリクエストを発行する。 ¾ 「提供物」からレスポンスを受ける。 （３）「提供物」の持つ関係： ¾ 「利用者」によって利用される。 ¾ 「提供者」によって提供される。 ¾ 「提供物」からリクエストを受ける。 ¾ 「提供物」にレスポンスを返す。 ¾ 「提供者」によって制御される。 ¾ 「提供者」にモニタされ、管理情報を供給する。 （４）「ポリシ」の持つ関係： ¾ 「提供者」によって確立される。 4-28 - 28 - ¾ 「提供者」に適用される。 ¾ 「利用者」によって参照される。 （５）「利用目的」の持つ関係： ¾ 「利用者」が持つ。 ¾ 「提供者」によって理解される。 （６）「セキュリティ」の持つ関係：：上記のすべての概念と関係すると思われるが、今後の課題とする。 さらに、「提供物」の階層を考慮すると、提供物の階層とプレーヤプレイヤとの関係は、以下の図 4-14 ように展開される。 ポリシ SLO 提供者 提供者 情報 課金 制御 ﾚｽﾎﾟﾝｽ ﾚｽﾎﾟﾝｽ 制御 管理情報・ モニタ ﾘｸｴｽﾄ 3層 ﾚｽﾎﾟﾝｽ 契約関 係・SLA 情報 課金 管理情報・ モニタ ﾘｸｴｽﾄ 2層 提供者 情報 課金 制御 管理情報・ モニタ ﾘｸｴｽﾄ １層 提供者 情報 課金 制御 管理情報・ モニタ ポリシ SLO ポリシ SLO ﾘｸｴｽﾄ 利用者 ﾚｽﾎﾟﾝｽ 4層 セキュリティ・管理（人＋システム） 図 4-14 提供物の階層とプレーヤプレイヤの関係 （１） リクエスト・レスポンス：「利用者」は「提供物」第 4 層の各種サービス、ポータルシステム、ERP ア プリケーションとリクエスト・レスポンスにより、「提供物」を利用する。「提供物」第 4 層はさらに下位 の階層の「提供物」との間で相互にリクエスト・レスポンスにより、各種サービス、ポータルシステム、 ERP アプリケーションの機能を実現する。 （２） 契約関係・SLA・SLO・課金：「利用者」は「提供者」との間で契約関係を持つ。これは例えば、 SLA と課金という関係で表される。「提供物」の各階層間では、各階層の「提供物」の「提供者」が SLA を各階層で計測可能な SLO を確立して適用し、課金情報を収拾するという契約関係となる。 最終的には、「利用者」と「提供者」との間の契約関係での課金となる。 （３） ポリシ・管理情報：「提供者」は「提供物」を運用するための「ポリシ」を確立し、各階層の「提供物」 の「提供者」に適用し、管理情報を収集する。この管理情報は、「利用者」が参照することがある。 （４） 制御・管理情報モニタ：各階層の「提供物」はその「提供者」が制御し、管理情報をモニタする。こ の管理情報はさらに上位階層に収拾され、「利用者」が参照する場合がある。 尚、管理及びセキュリティについては多くのモデルで、「提供物」の階層・コンポーネントごとに検討、 モデル化されるべきことが提案されている。例えば、GGF の領域の階層図、EGA 参照モデルの分散階 層のグリッド管理エージェントがある。さらに EGA エンタープライズグリッドセキュリティ要件では、単に「提 供物」またはコンポーネントごとのセキュリティ要件だけでなく、「提供物の状態遷移」ごとのセキュリティ要 件が解析されている。 前節で提供者と利用者の間にある提供物を明らかにしたが、その提供物に対して、提供者と利用者 が行うことのできるアクセス（操作・処理）ごとに管理の可能性が生じるはずである。例えば、提供物を構 4-29 - 29 - 成、配備する場合には、その条件（提供物の状態、依存関係など）が満たされていること、構成、配備が 正常に進行していること、構成、配備が正常に完了した時点の条件（提供物の状態、依存関係など）が 満たされていることが、管理されていなければならない。 つまり、グリッド環境の管理について検討を進めると、管理の対象を提供物のみと考えるのでは不十 分であり、提供物の状態遷移ごとの管理が必要であり、さらには、提供物間、提供物とプレーヤプレイヤ 間の依存などの関係を明記し、それらの間でのアクセス（さらには管理のための管理情報へのアクセス や・制御）を含めた管理が必要となることが明らかになってきた。また、管理自体の目的（SLO の条件）、 提供物の分類によっても、管理の内容は異なるものと思われる。 管理の内容も、提供物に対する提供者及び利用者の操作・処理ごとに決まるもの行われる必要がで あり、さらに、（上位）提供者からのポリシ、グリッド環境の特性・機能に依存しておくなわれなければなら ない決まるものである。これには、提供者による提供物の管理・監視・監査、利用者による提供者への要 求・課金支払いなど、管理上の情報としてグリッド環境の特性・機能に付加され、アクセスされる。これら、 提供物、提供者、利用者間でやりとりされる情報、付加的提供物（WSDM の定義する管理ケーパビリティ を提供するサービス、EGA の分散階層に対するグリッド・コンポーネントごとの GME コンポーネントなど） の内容がガイドラインのレベルを規定するものとなるだろう。 しかし、ガイドラインにおいては、提供者のポリシ、グリッド環境の特性・機能に依存して最適な管理ケ ーパビリティを選択可能にする事が目標となる。 尚（ｄ）で新たに定義された「プレイヤの役割」と「管理」の関係についても来年度の課題とする。 4-30 - 30 - 4.1.3. グリッドシステムの用途例 昨年度は、いくつかの典型的なシステムを想定し、旧版ガイドラインへの適用と改善点の検討を行い つつ、グリッドシステムのモデル化を進めてきた。今年度はグリッドシステムの具体的な事例を調査し、グ リッド技術に関連する部分を中心にシステムの要件を抽出した。取り上げたグリッドシステムは以下のと おりである。 今回は、以下の大項目として三つ、小項目として五つのグリッドシステムを用途例として取り上げた。 ■企業内技術計算グリッド これは、一つの企業内で技術計算を実施するためのグリッド環境を構築しているケースである。技術 計算とは、学術分野におけるシミュレーション研究のように CPU パワーを必要とする解析処理を指し、企 業においては、自動車企業における構造解析、流体解析、衝突解析、創薬企業におけるドラッグスクリ ーニング、金融業におけるリスク分析などが該当する。 ここでは、ノバルティスの事例を参考とした。ノバルティスでは、技術計算を実施するために導入した 計算機システムの他、社員が使用している PC も解析処理の対象として活用している。技術計算専用に 導入した計算機システムと、PC では、システムとしての要件が大きくことなるため、本用途例を、以下の 二つのケースに分割して検討することとした。 ●コンピューティンググリッド 一つの企業内において、技術計算を実施する専用の計算機システムを複数有し、それらを統合 して利用しているケースである。 ●PC グリッド 技術計算を実施するための専用計算機システムではなく、社員のその他の業務のために割り当 てた PC や CAD 用ワークステーションなどを、技術計算のためにグリッド・システムの一部として環境 を提供し、遊休リソースを利用しているケースである。ここでは、ノバルティスの事例の他、これまで 日本 IBM の PC グリッド・プロジェクトで活用した簡易チェックリストも要件抽出の参考とした。 ■学術共同グリッド 複数の大学や研究所が学術利用を目的として、同等な立場で計算機システム（やデータ）を供出し共 有し合うグリッド環境を構築しているケースであり、共同研究などにおいて、大規模高速な解析の実現や、 研究効率の向上が主な目的である。学術共同グリッドとしては、共有するリソースがコンピューティング資 源の場合とデータ資源の場合と分けることができる。しかし、データ資源を共有するケースについては、 来年度の取り組みとする。 ●コンピューティンググリッド 技術計算を実施するリソースを複数の大学や研究所間で共有し合うケースである。ここでは、産 総研が中心にアジア諸地域と連携する取り組みである ApGrid の事例を参考とした。 ■商用データセンタ 商用データセンタでは、商用データセンタ事業者(提供者)が顧客(利用者)に対して、サーバやストレ ージをはじめとする各種リソースを貸し出し、顧客の業務システムをホストすることにより収益を得る。この 場合の提供物は商用データセンタ事業者が所有するサーバリソースやストレージリソースなどである。グ 4-31 - 31 - リッド技術を適用することにより、商用データセンタはリソースプールの稼働率向上、TCO 削減が期待で き、ひいては顧客企業に対して低廉なサービスを提供することが可能となる。 ●ビジネス・コンピューティング・グリッド（業務システムに対するサーバリソース提供） ビジネス・コンピューティング・グリッドは、企業などが運用する業務システムに対するグリッド技術 の応用例の一つで、業務システムを運用する際に必要となるリソースをリソースプールから動的に 確保し、業務システムへ割り当てることにより、業務システムの運用・管理を効率化することを目的と している。 ●ストレージ基盤サービス（ストレージグリッド） ストレージ基盤サービスは、商用データセンタ内のストレージをプールして、システム使用者の要 求に従いオンデマンドにストレージサービスを提供するデータグリッド技術の適用例の一つである。 [商用データセンターの実状調査] 日時 ９月２７日（水） 場所 沖縄県浦添市 沖縄電力（株）データセンタ会議室 出席者（敬称略） 小柳、伊藤、安崎、溝口、鈴木、森、竹房、真栄城、濱田、田崎、伊達 概要 ① データセンタの概要及び実状調査に当たって事前に、森委員より、ヒアリング及び調 査のポイントについて、内容説明を頂いた。 ②「在地方商用データセンタ(DC)の現状と課題」について、ファースト･ライディン グ･テクノロジー(FRT)社の真栄城委員より説明があった。また説明の後、出席委員全員 にて、FRT 社 DC（別棟ビル）の実状調査を実施した。概要はつぎのとおり。 1）施設の概要・・竣工は 2002 年 11 月、地上 5 階建て鉄骨で免震構造ビル、延べ床面積は 6,800 ㎡、 空調設備及び消化設備が完備。 さらに震度 6 クラスに耐える耐震構造を完備。 2）商用電源は、高圧 6.6KV で本線と予備線の 2 系統。待機電源は UPS400KVA×3 とガスタ ービン式自家発電 1,500KVA。 3）サービスメニューとして、各種セキュリティサービス(バリオ･セキュア･ネットワーク) と監視サービス(死活管理､性能管理､ログ監視)、ストレージレンタルサービス､沖縄広 域ディザスタリカバリ(DR)サービスを用意。 4）沖縄の地理的優位性は、先ず､地震の危険度が全国で一番低いこと。政府支援により設 備、通信コストが安いこと。特に中国と比較すると、通信コスト及びセキュリティ管 理の面で、大幅にメリットあるとのこと。 5）FRT 社 DC の活用事例として、金融･医療機関向け DC として、ビックニイウス（株）、モ バイル･VOD センタ及びメディアセンタとしてインデックス沖縄（株）、バックアップセ ンタ及びコールセンタとして外為ドットコム社などの事例紹介があった。 各用途例の詳細な説明およびガイドライン項目の候補である要件については付録 B を参照されたい。 なお、各要件に対する要請の度合いは、以下の四つのレベルによって記述することとした。 ・ Necessary ・ Preferable ・ Optional ・ Not applicable 4-32 - 32 - 4.2. 国際標準化動向調査 4.2.1. (a) 国際標準化団体の状況 OGF (Open Grid Forum) の状況 (1) OGF の概要 オープン・グリッド・フォーラム（OGF：Open Grid Forum）は、グローバル・グリッド・フォーラム（GGF： Grobal Grid Forum）とエンタープライズ・グリッド・アライアンス（EGA：Enterprise Grid Alliance）の合併に よって 2006 年 6 月に設立された。オープン・グリッド・フォーラムという名称は、グリッドの採用を加速する ためには、グリッド・コミュニティーや分散コンピューティング・コミュニティー全般に及ぶ強力なアライアン スを構築することが重要であるという認識を反映したものである。この名称は、グリッドの設計者、構築者、 ユーザ、ソリューション・プロバイダから成る、国際的なグリッド・コミュニティーをイメージして付けられた。 現時点で 50 ヶ国以上の 400 を超える組織から構成されている。 図 4-15 OGF のロゴ OGF のロゴ（図 4-15）を見てもわかるように、OGF はグリッドの革新を目指した「オープン・フォーラム」 の開催、そしてグリッド・ソフトウェアの相互運用性を可能にする「オープン・スタンダード」の開発によって、 グリッドの採用を促進するための活動をおこなっている。OGF を通して、より早く成果を公開し、より明確 な形で業界とコミュニケーションを図り、より効果的な仕方で他の標準化団体と連携を図る。EGA と GGF の成功の原動力となった人材の基盤と、それらの人々の関与の度合いを維持することにより、OGF は、 早い段階で目標とする成果を挙げることができるようになると期待されている。 OGF は、EGA と GGF のお互いの良さを併せ持った団体を目指している。たとえば、EGA に関しては、 それが企業に関する専門知識を持ち短期的かつ実際的な成果に焦点を当ていた点、GGF に関しては、 グリッドに関する調査研究や標準仕様策定に関してオープンで協調的なアプローチを取っていた点が 挙げられる。もちろん、GGF と EGA の技術ワーキンググループ、それぞれのこれまでの作業、進行中だ った作業は、すべて OGF に受け継がれ、既に公開されている仕様書、たとえば GGF の「OGSA（Open Grid Services Architecture）」や、EGA の「EGA 参照モデル」は、OGF から引き続き入手可能となってい る。 OGF は、法人会員と個人会員の 2 つの会員種別が設けられている。法人会員は、プラチナ、ゴールド、 シルバーの３つのレベルに大別され、Pay to Play の原則に基づき、参加企業の興味度合いに応じて OGF での活動範囲が規定されている。さらに個人会員は法人以外のさまざまな組織からの会員であり、 この個人会員もそれぞれの専門知識を出し合い、様々なレベルの活動に積極的に参加し貢献すること が可能となっている。 (2) OGF の組織体制 4-33 - 33 - OGF の組織体制は、図 4-16に示すように、GGF と EGA の良さを合わせ持った構造を目指した。理 事会（Board of Directors）を最高決定機関とし、会長以下、６つの組織機能が実務を担う。興味深いの は、標準化（Standards）を担当する組織と、エンタープライズ（Enterprise）と eScience を担当する組織を 同列に分けて配置している点である。またマーケティング（Marketing）と運営（Operation）が組織全体の 具体的な活動を促進させる。さらに、米国地域以外に対しても透過的な活動をおこなうべく、地域 （Regional）毎に独立した組織機能を持たせている。 図 4-16 OGF の体制 OGF の理事会は、法人、個人から構成され、組織の健全な発展を導く役割を担っている。理事会の 構成は、プラチナ・スポンサーの権利として各社から１名ずつ 12 名が選出され、さらに会員全員の総意 として投票によって 4 名が選出されるという方法が取られている。OGF 初年度の理事会メンバーは以下 の通りである。 Ian Baird（イアン・ベアード）：EMC Bernd Kosch（ベレント・コシュ（博士））：Fujitsu-Siemens Martin Walker（マーティン・ウォーカー（博士））：Hewlett-Packard Ken King（ケン・キング）：IBM Tom Gibbs（トム・ギブス）：Intel Tony Hey（トニー・ヘイ（博士））：Microsoft Mike Szelong （マイク・ツェロン）：Network Appliance Bob Thome（ボブ・トム）：Oracle Chris Purpura（クリス・プルプラ）：Platform Computing Malcolm Atkinson （マルコム・アトキンソン（博士））：UK e-Science Dr. Bill Nitzberg（ビル・ニッツバーグ（博士））：Altair Engineering Paul Strong（ポール・ストロング）：eBay 岸本光弘（博士）：富士通 Jason Carolan （ジェイソン・カロラン）：Sun Microsystems Charlie Catlett（チャーリー・キャットレット（博士））： TeraGrid, University of Chicago/Argonne Labs 4-34 - 34 - OGF 初年度の運営指導体制は、会長であるマーク・リネシュ（Mark Linesch）と、6 つの組織機能を担 当する 7 人の副会長で構成されている。 [エンタープライズ（Enterprise）] Robert Fogel（ロバート・フォーゲル）/ Intel [eScience] Geoffrey Fox（ジェフリー・フォックス（博士））/ Indiana University [標準（Standard）] David Snelling（デービッド・スネリング（博士））/ 富士通 [マーケティング（Marketing）] Hanoch Eiron（ハノーク・エイロン）/ Hewlett-Packard [運営（Operations）] Steve Crumb（スティーブ・クラン）/ OGF [地域（Regional）] [EMEA] Bernd Kosch（ベレント・コシュ（博士））/ Fujitsu-Siemens [アジア・パシフィック（日本含む）] 鈴木俊宏/ 日本オラクル ところで、OGF はグリッドの採用を促進することによりビジネス価値の向上と学術上の進歩に貢献する ことをミッションとしているが、それを実現する為に、現在以下の 2 つの戦略的優先課題に注力している。 1. グリッドの技術革新・採用拡大・情報交換のために、分散型コンピューティング・エコシステム 全体におけるグリッドの位置付けや重要な提言を説明する包括的なホワイト・ペーパーを作 成する。 2. グリッド・ソフトウェアの相互運用を可能にする技術仕様の公開に向けて、OGF の技術戦略 およびロードマップを提供する。 また、最近の大きな成果としては、2006 年 11 月 13 日、Supercomputing 2006（SC06）コンファレンスに おいて、ハイパフォーマンス・コンピューティング（High Performance Computing 、以下 HPC）領域にお いて相互運用性のデモンストレーションを実施し、相互運用可能なハイパフォーマンス・コンピューティン グの実現に向けた取り組みを明らかにした。デモンストレーションでは、OGF の OGSA HPC プロファイル のドラフト仕様に基づいた HPC アプリケーションを計算クラスタ上で処理させた。日本からは東京工業大 学がこのデモンストレーションに参加した。このプロファイルは、一般的に幅広く採用されている Web サ ービス仕様や OGF が策定した標準仕様を使用することにより、異なる HPC ミドルウェア・プラットフォーム 間で相互運用性が実現されることが証明されたことになる。 また、2007 年 2 月 12 日、ワールドワイドでの OGF 提携プログラム（OGF Affiliate Program）を発表し、 このプログラムに参加する提携メンバーとして以下の最初の 5 つの団体の参加を明らかにした。 グリッド協議会（Grid Consortium Japan） グリッド・フォーラム・オランダ（Grid Forum-Netherlands） グリッド・フォーラム韓国（Grid Forum-Korea） イスラエル・グリッド技術協会（Israeli Association of Grid Technologies：IGT） 4-35 - 35 - グリッド・フォーラム・シンガポール（Grid Forum-Singapore） 想定される OGF 提携メンバーは、OGF から法的認可を受け、それぞれの地域活動において意義ある グリッドに関する課題や開発に取り組んでいる会員制の独立法人である。OGF はグリッドの採用拡大、 教育、そして、グリッドの採用を促進するベスト・プラクティスとグローバル・スタンダードの開発への積極 的な参加がローカル・レベルでもグローバル・レベルでも重要であることを認識しており、OGF 提携メン バーを OGF のミッションと原則に合致しつつグローバルなグリッド・コミュニティーの利益に寄与する OGF にとって重要な貢献を行ってくれる団体と位置づけている。 以上のように OGF は「オープン・スタンダード」と「オープン・フォーラム」を実践する国際的な視野に立 って活動を開始した。OGF は GGF と EGA によって成し遂げられた重要な成果をベースとして、確固とし た戦略上の土台を据え、様々な課題に果敢に取り組みながら、新しく生まれ変わったグリッド・コミュニテ ィーとしての活躍が期待されている。 （3） GGF18 及び OGF19 への出席報告 GGF18 場所 米国ワシントンＤＣコンベンションセンター 日時 9 月 12 日（月）～14 日（木） 出席者 伊藤智 概要 2006 年に Global Ｇｒｉｄ Forum (GGF）と Enterprise Grid Alliance (EGA) が統合して ＯＧ F（Open Grid Frum）となって初の会議であり、グリッドの最新動向及び標準化技術に 関して調査するため参加した。会議では新しい組織が発表された。報告者は主に エンタープライズグリッドに関係する活動に参加した。 今後の見通し EGA とＧＧＦが合併し、グリッドの標準化活動において、ますます企業系の活動が重要と なってきた。今後もＯＧＦでの動向に注目する必要がある。 OGF19 場所 米国ノース・カロライナ大学 日時 1 月 29 日（月）～2 月 1 日（木） 出席者 小柳義夫、伊藤智、森拓也、竹房あつ子 概要 グリッドコンピューティング標準化調査研究では、グリッドコンピューティング のためのガイドラインを策定し、Open Grid Forum (OGF) などに対して国際発信す ることを計画している。OGF は標準化が大きな目的であり、相互運用性の議論が多 いが、本調査研究では、実用的な業務にグリッドを適用することを考え、ある程度 の性能保証につながるガイドラインを提示しようとしている。 このため、OGF における標準化の方向性を探り、われわれのような提案をどのよ うな形で行ったらよいかを考えるために、種々のグループの議論に参加した。 今後の見通し グリッドそのものの研究者とグリッドの利用者とがともに集う Open Grid Forum は、われわれの成果を国際的に情報発信するのにもっともふさわしい場であるとい う印象を受けた。本年１０月頃アメリカ西海岸で予定されている、OGF21 で是非と も発表したいと思う。 4-36 - 36 - (b) OASIS の状況 (1) 概要 OASIS は主にビジネス分野における構造化文書を利用した情報交換、流通、運用技術やビジネスプ ロセスの標準化を行う非営利の国際団体である。1993 年に SGML(Standard Generalized Markup Language)を利用する製品間の相互互換性確保を目的として設立された業界団体 SGML Open が、 1998 年に XML 等に対象技術範囲を拡大し、OASIS へと改称した。XML など構造化文書の標準化団体 としては W3C が挙げられるが、OASIS は XML や SGML 等の標準技術を基盤に、その上位層のビジネ スアプリケーション側からみた相互運用性の確保や運用性の向上を目的としている点が異なっている。 本稿は、「グリッドコンピューティング標準化調査研究」の平成 17 年度報告をベースに 2006 年度に OASIS 標準となったドキュメント及び主要な技術委員会（以下 TC）の状況についてまとめる。尚、「コンピ ューティングマネージメント」、「Web サービス」、2006 年からカテゴリ分けされた「サービス指向アーキテク チャ（SOA）」の各カテゴリの TC の状況については付録に添付する。 z OASIS eXtensible Access Control Markup Language (XACML) TC：アクセス権限を決定する 為のポリシを表現する XML スキーマとプロトコルを定義している。XACML2.0 仕様が 2005 年 2 月に OASIS 標準となっており、現在 XACML3.0 の作業中である。 ¾ アドミニストレーションポリシ、委任ポリシ：XACML v3.0 Administrative Policy Version 1.0, Working Draft（2007 年 1 月ワーキングドラフト） ¾ Web サービスのコンテキストにおいて、認可ポリシ、アクセス制御ポリシ、プライバシ・ ポリシ に XACML を利用する方法：Web Services Profile of XACML (WS-XACML) Version 1.0, WD（2006 年 12 月ワーキングドラフト） 及びSchema for Web Services Profile of XACML (WS-XACML) Version 1.0, WD(2006 年 12 月ワーキングドラフト) ¾ XACML シンタクスと処理モデルを一般化し、他のタイプのポリシ（管理ポリシなど）と の整合性を向上させる：XACML v3.0 improved generality（2005 年 3 月のワーキングド ラフト） z OASIS Provisioning Services TC：組織内、組織間でのアイデンティティ情報とシステムリ ソースのプロビジョニングと割り当てを管理する XML フレームワークを提供するService Provisioning Markup Language (SPML) V2.0を 2006 年 4 月に OASIS 標準としている。主要 な内容は、プロビジョニングを記述するためのモデルと、XML ベースのリクエスト・レスポ ンスプロトコル、及びプロファイルである。 z OASIS Web Services Distributed Management (WSDM) TC：分散リソースを管理するための Web サービスアーキテクチャを定義すると共に、Web サービス自体の管理アーキテクチャを 定義する。WSDM1.1 が 2006 年 8 月に OASIS 標準となっており、さらにプライマ・ドキュメン トを 2006 年に作成している。 OASIS 標準： ¾ Web Services Distributed Management: Management Using Web Services (WSDM-MUWS) v1.1 Part 1 ¾ Web Services Distributed Management: Management Using Web Services (WSDM-MUWS) v1.1, Part 2 ¾ Web Services Distributed Management: Management of Web Services (WSDM-MOWS v1.1 プライマ・ドキュメント： ¾ WSDM MUWS Primer（2006 年 2 月コミッティドラフト） 4-37 - 37 - ¾ z WSDM MOWS Primer（2006 年 2 月コミッティドラフト） OASIS Web Services Notification (WSN) TC：「通知」「イベント」を使用した Web サービ スのインタラクション方法の標準を定義する。これは、イベントドリブンなアーキテクチャ を Web サービスで実現するための基盤となる。 以下の仕様が 2006 年 8 月に OASIS 標準となっている。 z ¾ WS-BaseNotification 1.3：Specification、XML Schema、WSDL ¾ WS-BrokeredNotification 1.3：Specification、XML Schema、WSDL ¾ WS-Topics 1.3：Specification、XML Schema OASIS Web Services Resource Framework (WSRF) TC：Web サービスを使う状態を持つリソー スをモデル化し、アクセスするための、汎用かつオープンなフレームワークを定義する。以 下が 2006 年 4 月に OASIS 標準となっている。 ¾ WS-Resource specification、WS-Resource WSDL ¾ WS-ResourceProperties (WSRF-RP) specification、WS-ResourceProperties (WSRF-RP) WSDL ¾ WS-ResourceLifetime (WSRF-RL) specification、WS-ResourceLifetime (WSRF-RL) WSDL ¾ WS-ServiceGroup (WSRF-SG) specification、WS-ServiceGroup (WSRF-SG) WSDL ¾ WS-BaseFaults (WSRF-BF) specification、WS-BaseFaults (WSRF-BF) WSDL またApplication Notes (AppNotes)を 2006 年 3 月に、WSRF Primerを 2006 年 5 月にそれぞれコ ミッティドラフトとしている。 OASIS ebXML Business Process TC：XML を使用したビジネスコラボレーションのための情報交換 （ビジネストランザクション）を、自動かつ予測可能にするためのビジネスプロセス基盤を 標準ベースで提供することを目標としている。最新バージョン ebXML Business Process Specification Schema v2.0.4仕様が 2006 年 12 月に OASIS 標準となっている。 OASIS Framework for Web Services Implementation (FWSI) TC：堅牢な Web サービス実装のた めの、実践的な拡張可能な方法論と、共通機能エレメントを定義する。活動は方法論と共通 機能の 2 つの SC で進められている。現在それぞれのパブリックレビュードラフトが作成さ れている。 Web Service Implementation Methodology,(2005 年 7 月) Functional Elements Specification 2.0, Committee Draft (2006 年 9 月) OASIS Web Services Business Process Execution Language (WSBPEL) TC：ビジネスプロセスの アクティビティを Web サービスとして記述するための XML ベースの言語を定義している。 2002 年 8 月にサブミットされた Business Process Execution Language for Web Services (BPEL4WS) 仕様をベースに継続作業中であり、2007 年 1 月に WS-BPEL2.0をコミッティドラ フトとしている。 OASIS Web Services Reliable Exchange (WS-RX) TC ：2005 年 2 月に TC にサブミットされた WS-ReliableMessaging および WS-RM Policy 使用をベースに、Web サービスを使用した高信 頼メッセージ交換プロトコルを定義する。以下がコミッティレビュードラフトである。 Web Services Reliable Messaging v1.1 （2006 年 8 月） 4-38 - 38 - Web Services Reliable Messaging Policy Assertion v1.1 （2006 年 8 月） OASIS Web Services Secure Exchange (WS-SX) TC：WS Security仕様を拡張し、複数 SOAP メッ セージのトラスとされた交換を可能にし、さらにメッセージのフォーマットやセキュリティ トークンを支配するセキュリティポリシを定義する。以下の仕様のサブミットをベースに作 業中である。 WS-SecureConversation (2005 年 2 月) WS-Trust (2005 年 2 月) WS-SecurityPolicy (2005 年 7 月) 以下がコミッティドラフトとなっている。 WS-SecureConversation 1.3 (2006 年 9 月) WS-Trust 1.3 (2006 年 9 月) OASIS SOA Reference Model TC：個別分野のサービス指向アーキテクチャ構築をガイドするため の核となる参照モデルを開発しておりReference Model for Service Oriented Architecture v1.0が 2006 年 10 月に OASIS 標準となっている。 4-39 - 39 - (c) W3C の状況 (1) 概要 W3C（World Wide Web コンソーシアム）は 1994 年 8 月、World Wide Web（以下 WWW）の潜在能力 を完全に引き出し、その発展をプロモートし、共通プロトコルを開発し、インタオペラビリティを保証する為 に生まれた。W3C は現在、全世界から約 400 近いメンバを持っており、Web の発展への貢献が、国際的 に認知されている。 グリッドの標準化活動としては、Globus プロジェクトを中心に、その第一世代の独自プロトコルに拠る異 種分散環境の実現を狙ったが、2002 年に発表された OGSA 以降、既存の WWW 及び、Web サービス のインフラストラクチャ上でのリファクタリングへと向かっている。2004 年発表の Web サービスリソースフレ ームワーク関連では、WS-Addressing 仕様が W3C で標準化作業に入っている。 本稿は、「グリッドコンピューティング標準化調査研究」の平成 17 年度報告をベースに 2006 年度に 「XML アクティビティ」、「Web サービスアクティビティ」の範囲で、W3C となった勧告ドキュメントの状況に ついてまとめる。 W3C 全体としては、モバイル機器を中心とした「デバイス非依存性」や、次世代の Web としての「セマ ンティック Web」関連の活動が盛んであるが、時代を反映して Web サービス関連のアクティビティの活動 も活発である。また、すべての仕様のベースとなる XML アクティビティも活動を継続している。尚、関連 する両アクティビティ内の作業グループ（以下 WG）の状況は付録に添付する。 XML アクティビティ XML の適用範囲が拡大し、各仕様の配備も進んでいることから、2006 年 10 月にアクティビティ 全体としてリニューアルされ、8 ワーキンググループとコーディネーショングループが活動して いる。以下では、2006 年に更新されている、ワーキングドラフト、候補勧告、勧告をリストアッ プする。 Efficient XML Interchange Measurements Note(2006 年 7 月、ワーキングドラフト)：各種の XML 交換エンコーディングフォーマットについてのエンコーディング性能結果を報告している。 評価方法、評価結果についての合意に至っているわけではなく、レビュー目的で発行された ものであるが、XML をインフラストラクチャとして広く利用するために不可欠な活動のひと つである。 XML Inclusions (XInclude) Version 1.0（2006 年 10 月、提案勧告）：複数の XML ドキュメントをマ ージするためのインクルード機能の処理モデルとシンタクスを規定している。 XProc: An XML Pipeline Language（2006 年 11 月、ワーキングドラフト）：XML ドキュメント上 で実行されるパイプライン型のオペレーションを記述する言語を規定する。 XQuery 1.0 及び Xpath 2.0 関連仕様が 2007 年 1 月に W3C 勧告となっている。 XQuery 1.0 and XPath 2.0 Data Model (2007 年 1 月の W3C 勧告) ：XPath 2.0、XQuery 1.0、 XSLT 2.0 に適用されるデータモデルを規定する。 XSLT 2.0 and XQuery 1.0 Serialization (2007 年 1 月の W3C 勧告)：データモデル仕様の定 4-40 - 40 - 義するインスタンスを、オクテットシーケンスにシリアライズする方法を規定する。 XQuery 1.0 and XPath 2.0 Formal Semantics (2007 年 1 月の W3C 勧告)：XPath 2.0、XQuery 1.0 のフォーマルセマンティクスを規定する。 XQuery 1.0: An XML Query Language (2007 年 1 月の W3C 勧告)：多様なタイプの XML データ ソースに対して広く利用できる問合せ言語を規定する。XML の構造を利用し、あらゆる データ種別にまたがる問合せを表現できる。 XML Syntax for XQuery 1.0 (XQueryX) (2007 年 1 月の W3C 勧告)：XQuery 1.0 のシンタク ス仕様を規定している。 XQuery 1.0 and XPath 2.0 Functions and Operators (2007 年 1 月の W3C 勧告)：XPath 2.0、 XQuery 1.0、XSLT 2.0 で共通に使用される、(1)XML スキーマ仕様、及びXQuery 1.0 and XPath 2.0 Data Model 仕様で定義されるデータタイプに対する、コンストラクタ関数、 オペレータ、関数、(2) XQuery 1.0 and XPath 2.0 Data Model 仕様で定義されるノー ド、ノードシーケンスに対するオペレータと関数を規定する。 XML Path Language (XPath) 2.0 (2007 年 1 月の W3C 勧告)：XQuery 1.0 and XPath 2.0 Data Model に定義されるデータモデルに準拠する値の処理を可能にするための(パス)式言語 である。 XSL Transformations (XSLT) Version 2.0 (2007 年 1 月の W3C 勧告)： XML ドキュメントを 他の XML ドキュメントに変換するための言語のシンタクスとセマンティックスを規定す る。 Guide to Versioning XML Languages using XML Schema 1.1（2006 年 9 月ワーキングドラフト）： XML スキーマの主要な課題はバージョニングである。開発の継続するでスキーマ変更に対す る堅牢性に有効な構文を XML スキーマ 1．1 仕様の中で検討をしている。 Web サービスアクティビティ Web サービスは、各種のプラットフォーム、フレームワークで動作する、異なるソフトウェア間 のインタオペレーションに対して標準の手段を提供するものである。Web サービスは XML を利用す ることで、インタオペラビリティ、拡張可能性、マシン処理可能な記述という特性をもち、より複 雑なオペレーションを可能にするために、疎結合の合成を可能にしている。シンプルなサービスを 提供するプログラムが相互にインタラクトすることで、付加価値サービスを容易に提供できるよう になる。 W3C の Web サービスアクティビティは、Web サービスのインフラストラクチャデザイン、アーキテ クチャ定義、コアテクノロジー定義を分担し、XML ベースのメッセージングフレームワークである SOAP 1.2 始め、Web サービス、さらにはグリッドの基盤でもある以下の仕様を W3C 勧告としている。 Web Services Addressing 1.0 - Core （2006 年 5 月、W3C 勧告）：Web Seivices Addressing は Web サービス及びメッセージのアドレス付けを行うためのトランスポート中立なメカニズム である。Core 仕様は Web サービスの参照及び、メッセージ中でエンドポイントのエンド・ツ ー・エンドのアドレス付けを可能にするための抽象プロパティと XML 情報セットを定義して いる。エンドポイント・メッセンジャ、ファイアウォール、ゲートウェイ 等の処理ノード を含むようなネットワークを介してトランスポート中立なメッセージ転送をサポート可能 にするための仕様である。 4-41 - 41 - Web Services Addressing 1.0 - SOAP Binding（2006 年 5 月、W3C 勧告）： Web Seivices Addressing 1.0 – Core 仕様の抽象プロパティに対する SOAP1.2 バインディングを定義している。 Web Services Addressing 1.0 - WSDL Binding（候補勧告）：2006 年 5 月に候補勧告となってい る。Web Seivices Addressing 1.0 – Core 仕様の抽象プロパティに対する WSDL2.0 バイン ディングを定義している。 WSDL 2.0 関連仕様が 2006 年 3 月に W3C 勧告となっている。 Web Services Description Language (WSDL) Version 2.0 Part 0: Primer （2006 年 3 月に 候補勧告）：以下の WSDL 2.0 仕様 Part1/2 に対するチュートリアル・ドキュメントで ある。 Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language 及びschema、 wsdlx schema (2006 年 3 月に候補勧告) ：Web サービスが提供するものについての抽象 モデルをベースにした記述に使用するためのコア言語を規定する。また準拠性の基準も 規定している。 Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts及び SOAP 1.2 binding schema、HTTP binding schema (2006 年 3 月に候補勧告) ：上記 WSDL 2.0 コア 言語に対する「メッセージ交換パターン」「オペレーションスタイル」「バインディン グ（SOAP1.2 及び HTTP）拡張」の規定義拡張部分に当たる規定である。 Web Services Description Language (WSDL) Version 2.0 SOAP 1.1 Binding （2006 年 3 月にワーキングドラフト）：SOAP1.1 バインディングを別のドキュメントに分離してい る。 Web Services Description Language (WSDL) Version 2.0: RDF Mapping （2006 年 3 月ワー キングドラフト）：WSDL 2.0 モデルの RDF 及び OWL 記述と、WSDL 記述から RDF 記述へ の変換手続きの説明を行っている。 WS-Policy 関連仕様がワーキングドラフトとなり始めている。Web サービスベースのシステム中 に存在するエンティティの持つポリシを記述するための汎用モデルと対応するシンタクス で構成され、他の Web サービス関連仕様でサービスの要件、サービスのケーパビリティを記 述するために拡張仕様として使用される構文のベースセットを定義するものである。 Web Services Policy 1.5 - Framework（2006 年 11 月、ワーキングドラフト） Web Services Policy 1.5 - Attachment（2006 年 11 月、ワーキングドラフト）： Web Services Policy 1.5 - Primer （2006 年 12 月、ワーキングドラフト） Web Services Policy 1.5 - Guidelines for Policy Assertion Authors（2006 年 12 月、ワ ーキングドラフト） 4-42 - 42 - (d) DMTF (Distributed Management Task Force) の状況 (1) 概要 DMTF（Distributed Management Task Force, Inc.：分散マネージメントタスクフォース）は、1992 年に 設立された、パソコンや周辺機器等の管理に関する標準を策定する業界団体である。大手情報機器メ ーカーを中心に 30 社以上で構成され、デスクトップ、エンタープライズ、およびインターネット環境のため の管理標準とイニシャチブの開発、採用、および相互運用を主導する活動を行っている。DMTF の主な 標準規格に DMI（Desktop Management Interface）と CIM（Common Information Model）がある。また、 様々な規格開発の枠組みとして WBEM（Web-based Enterprise Management）イニシャチブがある。これ らについて以下に説明する。 DMTF に関して、詳しくは次の URL を参照のこと。<http://www.dmtf.org/home> (2) DMI（Desktop Management Interface） パソコンや周辺機器等を統一的に管理するための標準インタフェース。DMI では、クライアント/サー バ型の管理ツールと MIF（Management Information Format）という構造化言語を使って定義されたデー タベース・ファイル（MIF ファイル）を使用する。パソコンなどのクライアント側にはサービスレイヤと呼ぶプ ログラムを組み込み、これが管理対象の情報を収集し、MIF ファイルに格納する。管理を行うサーバには 市販の管理ソフトなどを組み込んでおき、これがネットワークを通じて管理対象となるコンピュータにアク セスし、MIF ファイルを参照して適切な指示を出す。DMI の最初のバージョンである DMI 1.0 は 1994 年 に発表され、OS やプロトコルに依らないで、コンピュータ システムのハードウェア／ソフトウェアを管理 する仕組みを提供した。現在 PC などのシステムに実装されているのは、1996 年に発表された DMI 2.0 や、セキュリティ機能を強化した DMI 2.0s である。 (3) CIM（Common Information Model） DMI のアーキテクチャを取り入れた、インターネットにおける管理モデル。特定の実装に縛られない管 理情報に対する概念の情報モデルであり、ビジネス管理環境でのエンティティやリレーションシップ(関 係)のオブジェクト指向による記述を行っている。CIM 仕様には、モデリング言語, ネーミング, メタスキ ーマ、他の管理モデル（前述の DMTF の MIF など）とのマッピング、が規定されており、次の２つのモデ ルから構成される。 z z コアモデル - 全ての管理領域に適用できる概念をもった情報モデルであり、依存性などの基本 的関係やシステムやデバイスなどの高次の概念を規定する。 共通モデル - 特殊な技術や実装を除く、特定の管理領域を共通化する概念をもった情報モデ ルであり、コンピュータ・システムやネットワークユーザ、デバイス管理など特定の領域を記述す る。 CIM スキーマは、実際のモデル記述と情報のフレームワークを提供するものであり、プロパティと関係 情報を持つ一連のクラスも定義し、管理対象環境についての情報を組織化できるようになっている。 (4) WBEM イニシャチブ WBEM（Web-based Enterprise Management）は、様々な既存の管理技術とインターネット技術を利用 して、エンタープライズ コンピュータ環境を管理する統一的な手段を提供する DMTF 内の業界イニシ ャチブであり、CIM 標準の開発もここに含まれる。主な開発項目には、CIM スキーマの XML での記述 方法と、HTTP 上で XML エンコードされたスキーマを使用して CIM 操作をする方法などが含まれる。 CIM スキーマは、WBEM イニシャチブの管理オブジェクトのモデリング基盤として機能する。 4-43 - 43 - (5) WS-Management ところで、今年度になってグリッドのリソースを管理するための Web サービスのプロトコルに関して DMTF から WS-Management という新しい標準の提案があった。これについても以下に言及しておく。 異なるハードウェアとオペレーティング・システムで構成されるネットワーク環境で、PC、サーバ、装置、 Web サービス、アプリケーションなどのシステムを管理するための SOAP ベースのプロトコル。OASIS で検 討されている WSDM（Web Services Distributed Management）と対比されるが、執筆時点で 2006 年 4 月 5 日付けの「Preliminary」バージョンが公開されている。WS-Management は、リソースおよびその表現を 操作する SOAP ベースのプロトコルで、リソースの生成、修正、削除、取得のための手段を提供する WS-Transfer（W3C で検討）の機能を利用している。 この標準は WSDM の対抗として提案されたといっても過言ではなく、Web サービス・リソース及び管理 に関して、WSRF、WSDM、WS-Transfer 、WS-Management といった同じような標準が複数の団体から 提案されることは市場を混乱させるとして、それを整理、統合する WS-ResourceTransfer の標準化が進 められている。 4-44 - 44 - (e) SNIA (Storage Networking Industry Association) の状況 (1) 概要 SNIA（Storage Networking Industry Association：ストレージネットワーキング・インダストリ・アソシエーシ ョン）は、世界中の 300 を超える企業と個人で構成される非営利団体。SNIA は、オープンなストレージネ ットワーキングソリューションを実現するための標準規格の策定、教育／サービスの提供を行っている。 特に、ストレージ・ネットワーキングの仕様に DMTF の CIM を採用しており、また、直接 DMTF に参加し て WBEM 関連標準の開発作業も行っている。日本での活動は、ストレージネットワーキング・インダスト リ・アソシエーション日本支部（英語名：Storage Networking Industry Association Japan Forum、略称： SNIA Japan）が行っている。 SNIA に関して、詳しくは次の URL を参照のこと。<http://www.snia-j.org/> SNIA の主な活動に SMI（Storage Management Initiative）があり、そこで定められた仕様は SMI-S（SMI Specification）と呼ばれる。SNIA は、この SMI-S を使った新しいストレージ管理の実現を推進している。以 下に SMI-S について説明を行う。 (2) SMI-S（Storage Management Initiative Specification） SMI-S は、Web ベースのストレージ・システム管理の標準モデル仕様。ストレージネットワーク上のスト レージデバイスと管理アプリケーション間の通信を標準化する。これによって、複数のデバイスが混在し ている環境であっても各デバイスを共通のインタフェースで管理できるようになり、管理コストなどを低減 させることができる。この SMI-S は SNIA が現在、普及に最も注力している技術であり、マルチベンダ環境 でのストレージ、管理アプリケーションに共通のインタフェースを提供し、相互に運用管理できるようにす ることを目指している。SMI-S のインタフェースは、CIM などの WBEM 関連標準を用いて各ベンダの管理 情報のモデルを統一し、管理アプリケーションと各デバイスとの間を SLP（Service location Protocol）※や HTTP の標準方式で結ぶ。 ※ネットワークアプリケーションがエンタープライズ・ネットワーク中のネットワークにつながれたサービ スの存在、位置および配置を検知可能にするためのフレームワークを提供するプロトコル（RFC 2165）。 4-45 - 45 - (f) ISO/IEC JTC1 の状況 (1) 概要 グリッド技術の標準化は、ISO/IEC JTC1（情報処理分野の標準化を担当する、ISO と IEC とのジョイン ト TC）においても注目を受けた。2005 年 11 月 12 日カナダのバンフにおいて、Technology Watch Workshop が開催され、そのトピックの一つにグリッドが取り上げられた。グリッドに関するプレゼンテーシ ョンは以下の 2 件であった。 z Global Grid Forum - Leading the pervasive adoption of grid computing for research and industry, Mark Linesch, Global Grid Forum z Standardization of Grid Computing, Satoshi Sekiguchi, Grid Technology Research Center, AIST 当時 GGF 会長の Mark Linesch 氏からグリッド技術の採用と普及という観点からグリッドと GGF の紹介、 産総研グリッド研究センター長の関口智嗣氏から日本におけるグリッド技術の標準化活動の状況につい ての紹介が行われた。 残念ながら、2006 年 11 月 13-17 日に南アフリカで行われた Technology Watch Workshop や、その外 の昨年の委員会では特にグリッド技術がトピックとして取り上げられることはなかったが、グリッド技術の標 準化は多岐に渡るため、デジュール標準化をおこなっている ISO/IEC JTC1 の活動と様々な接点がある のは言うまでもない。特にグリッドの個々の要素技術は JTC1 内の SC で議論されることも大いに考えられ るため、今後の動向が注目される。 (g) SC06 の状況 SC は 1988 年から毎年米国で開催される高性能計算・ネットワーク技術・ストレージと分析のための国 際会議で、主たる IT 企業と世界各国の研究所が大規模な展示を行うとともに、併設された会場では学会 論文の発表が行われる。10 年ほど前より、グリッドが話題として多く取り上げられるようになった。 場所 米国タンパコンベンションセンター 日時 １１月１２日（日）～１７日（金） 出席者 伊藤智 竹房あつ子 概要 OGF (Open Grid Forum)の Open Grid Service Architecture (OGSA) High Performance Computing (HPC) Profile ワーキンググループが、SC06 展示会場において、インターオペラビリテ ィ（相互運用性）デモンストレーションを実施した。 OGSA HPC Profile では、OGF の Job Submission Description Language (JSDL), OGSA Basic Execution Service (BES) および WS-I Basic Profile 仕様をベースとした HPC におけるグリッドイン ターオペラビリティの標準を提案している。JSDL はジョブをサブミットする際に必要なパラメタを XML で記述するための XSD スキーマ、OGSA BES はジョブサブミッションサービスに関するイン タフェース（WSDL、サービス状態遷移）を規定している。また、WS-I Basic Profile はウェブサービ スにおける相互運用性の向上を目的とし、SOAP、WSDL、HTTPS 等の関連仕様の明確化を行っ ている。 SC06 では、12 団体が共同で 1 つのプロトコルを介して異なるウェブサービスツールと計算資源 マネージャを利用したサイトにジョブを相互にサブミットするデモンストレーションを行った。参加 団 体 は Altair 、 ANL 、 CROWN 、 EGEE 、 Fujitsu Labs of Europe 、 HP 、 Microsoft 、 Platform Computing、東工大、UK eScience、UVa、Genesis II である。 今後の見通し グリッドの展開領域は拡大し、SC は、そのようなグリッドの動向を把握することができる良いイベ ントである。 4-46 - 46 - 5. あとがき 本年度は３年計画の２年目として、ガイドラインの基礎となるグリッドのモデルの精密化のための議論を 行った。生のビジネスの現場から事例を収集することは現実には困難であるので、われわれはいくつか の事例にを分析し、これに基づいてモデルを構築することに力を注いだ。従ってわれわれとしては、ある システムがグリッドといえるかどうかの判定基準を与えることを意図しているわけではない。むしろ、グリッ ド・コンピューティング技術を生かすためには、どのような要件があるかを提示しようとするものである。ま だ十分とはいえないが、今後の活動のための貴重な指針を得たと考えている。 グリッドコンピューティング標準化調査研究員会委員長 小柳義夫 （工学院大学） 5-47 - 47 - 6. 参考文献 以下の資料を参考文献として参照した。 幕田幸男他、「ビジネスグリッドの実証実験」、情報処理 Vol.47 No.9 p.962-969、2006 年 9 月 15 日 社団法人電子情報技術産業協会、ソリューションサービス事業委員会 編著、「ＳＬＡガイドライン第三版」、 日経 BP 社 2006 年 10 月 2 日発行 6-48 - 48 - 7. 付録 以下の資料を添付する。 ・Ａ OASIS および W3C の詳細状況 標準化団体 OASIS および W3C における代表的な TC における活動状況についてまとめた。 ・Ｂ グリッドシステムの用途例および要件リスト グリッドガイドラインをまとめるにあたって、特徴的なグリッドシステムの用途例をいくつか挙げ、それらの記述とそ れらの要件をリストアップした。 ・C グリッドガイドラインの用語集 グリッドガイドラインに登場する用語について、説明を記述するための用語集を作成している。モデル化の議論 と、用途例の要件リストに登場する用語についてまとめた。 ・D 商用データセンタの要件 商用データセンタとして、スペース、電源、ネットワークまでのファシリティを提供するケースの要件リストである。 （ファーストライディングテクノロジー株式会社よる資料提供） 7-49 - 49 - 付録Ａ OASIS および W3C の詳細状況 昨年度まで継続して調査してきた OASIS および W3C の状況について 2006 年度の情報を更新したのでここに 述べる。 A.1. OASIS の詳細状況 概要 OASIS は主にビジネス分野における構造化文書を利用した情報交換、流通、運用技術やビジネス プロセスの標準化を行う非営利の国際団体である。1993 年に SGML(Standard Generalized Markup Language)を利用する製品間の相互互換性確保を目的として設立された業界団体 SGML Open が、 1998 年に XML 等に対象技術範囲を拡大し、OASIS へと改称した。XML など構造化文書の標準化団 体としては W3C が挙げられるが、OASIS は XML や SGML 等の標準技術を基盤に、その上位層のビジ ネスアプリケーション側からみた相互運用性の確保や運用性の向上を目的としている点が異な っている。 本稿は、「グリッドコンピューティング標準化調査研究」の平成 17 年度報告をベースに 2006 年 度の状況により、主に「コンピューティングマネージメント」と「Web サービス」のカテゴリの 以下の技術委員会（以下 TC）の状況について更新する。 コンピューティングマネージメントカテゴリ z OASIS DCML Framework TC：DCML は Data Center Markup Language である。DCML の狙いはデ ータセンタのコンテンツと、そのコンテンツの管理に使用する情報を表現するための XML ベ ースの仕様によって、データセンタ基盤の自動管理に関連する総合的な標準の集合を開発し ていく支援となることである。特にフレームワークに作業を限定しているが、このフレーム ワークはコンテンツの命名方法、拡張方法、XML 表現、セキュリティ、DCML ドキュメントの 処理方法、外部情報の参照や利用方法、バージョニングの方法などについてのルールや規約 を指す。 z OASIS eXtensible Access Control Markup Language (XACML) TC：アクセス権限を決定する 為のポリシを表現する XML スキーマとプロトコルを定義している。XACML2.0 仕様が 2005 年 2 月に OASIS 標準となっており、現在 XACML3.0 の作業中である。 XACML2.0 ドキュメントは以下である。 ¾ XACML 2.0 Core: eXtensible Access Control Markup Language (XACML) Version 2.0： Specification Document、Policy Schema、Context Schema ¾ Core and hierarchical role based access control (RBAC) profile of XACML v2.0： Specification Document ¾ Hierarchical resource profile of XACML v2.0：Specification Document ¾ Multiple resource profile of XACML v2.0：Specification Document ¾ Privacy policy profile of XACML v2.0：Specification Document ¾ SAML 2.0 profile of XACML v2.0：Specification Document、SAML 2.0 Assertion 、 Extension Schema 、SAML 2.0 Protocol Extension Schema ¾ XML Digital Signature profile of XACML v2.0：Specification Document XACML3.0 の作業中ドキュメントは以下である。 7-50 - 50 - ¾ XACML 3.0 Issues List ¾ アドミニストレーションポリシ、委任ポリシ：XACML v3.0 Administrative Policy Version 1.0, Working Draft 15, 4 January 2007 ¾ Web サービスのコンテキストにおいて、認可ポリシ、アクセス制御ポリシ、プライバシ・ ポリシ に XACML を利用する方法：Web Services Profile of XACML (WS-XACML) Version 1.0, WD 8, 12 December 2006 及びSchema for Web Services Profile of XACML (WS-XACML) Version 1.0, WD 8, 12 December 2006 ¾ XACML シンタクスと処理モデルを一般化し、他のタイプのポリシ（管理ポリシなど）と の整合性を向上させる：XACML v3.0 improved generality（2005 年 3 月のワーキングド ラフト） メンテナンス活動： ¾ XACML2.0 バージョン 2 の SAML2.0 プロファイル：SAML 2.0 Profile of XACML 2.0, Version 2（2006 年ワーキングドラフト）、SAML 2.0 profile of XACML v2.0 Errata、 eXtensible Access Control Markup Language (XACML) Version 2.0 Errataのメンテナ ンス活動も継続中。 標準トラック以外の活動： ¾ XACML 2.0 コンフォーマンステスト：Draft XACML 2.0 Conformance Tests、Conformance test changes、To-Do List for XACML 2.0 Conformance Tests ¾ OASIS Naming Guidelines for XACML（2006 年 10 月）：ファイル名、URI、XML ネーム スペース、メタデータの命名規則、バージョニングの規定 z ¾ XACML delegation use-cases ¾ Web-services policy language use-cases and requirements OASIS Provisioning Services TC：組織内、組織間でのアイデンティティ情報とシステムリ ソースのプロビジョニングと割り当てを管理する XML フレームワークを提供するService Provisioning Markup Language (SPML) V2.0を 2006 年 4 月に OASIS 標準としている。以下 の 3 つのドキュメントで構成されている。主要な仕様は、プロビジョニングを記述するため のモデルと、XML ベースのリクエスト・レスポンスプロトコル、及びプロファイルである。 z ¾ OASIS Service Provisioning Markup Language (SPML) Version 2 ¾ OASIS Service Provisioning Markup Language (SPML) v2 - DSML v2 Profile ¾ OASIS Service Provisioning Markup Language (SPML) v2 - XSD Profile OASIS Solution Deployment Descriptor (SDD) TC：マルチプラットフォーム環境で、ライ フサイクル管理を行うために必要な、ソフトウェアのインストール特性を表現するための標 準の方法を定義する。具体的には、配備、コンフィギュレーション、メンテナンスに関連す るソフトウェアの「インストール単位」を記述する XML ドキュメントのための XML スキーマ （Installable Unit Deployment Descriptor または IUDD という。）を定義することである。 憲章から、以下のドキュメントが予定されている。 ¾ SDD に対する XML スキーマ仕様：コア記述子とマルチプラットフォーム・ソリューショ ンのための拡張 ¾ ソフトウェアパッケージと関連リソースのフォーマット仕様 ¾ プライマ・ドキュメント ¾ DMTF 及び関連標準化団体への要求仕様の入力。 ¾ ソリューションインストールとライフサイクル管理のベストプラクティス・ドキュメ 7-51 - 51 - ント。 z OASIS Web Services Distributed Management (WSDM) TC：分散リソースを管理するための Web サービスアーキテクチャを定義すると共に、Web サービス自体の管理アーキテクチャを 定義する。WSDM1.1 が 2006 年 8 月に OASIS 標準となっており、さらにプライマ・ドキュメン トを 2006 年に作成している。 OASIS 標準： ¾ Web Services Distributed Management: Management Using Web Services (WSDM-MUWS) v1.1 Part 1 ¾ Web Services Distributed Management: Management Using Web Services (WSDM-MUWS) v1.1, Part 2 ¾ Web Services Distributed Management: Management of Web Services (WSDM-MOWS v1.1 プライマ・ドキュメント： z ¾ WSDM MUWS Primer（2006 年 2 月コミッティドラフト） ¾ WSDM MOWS Primer（2006 年 2 月コミッティドラフト） OASIS Web Services Notification (WSN) TC：「通知」「イベント」を使用した Web サービ スのインタラクション方法の標準を定義する。これは、イベントドリブンなアーキテクチャ を Web サービスで実現するための基盤となる。 以下の仕様が 2006 年 8 月に OASIS 標準となっている。 z ¾ WS-BaseNotification 1.3：Specification、XML Schema、WSDL ¾ WS-BrokeredNotification 1.3：Specification、XML Schema、WSDL ¾ WS-Topics 1.3：Specification、XML Schema OASIS Web Services Quality Model TC：Web サービスの契約コンテキストにおいて、Web サ ービスをあるサービス品質でセキュアに提供するための品質モデルから作業を開始してい る。この品質モデルを XML 表現するための標準タイプである WS-QDL (Web Services Quality Description Language)を提案すると共に、品質モデルのガイドラインを開発する予定であ る。2005 年 9 月のコミッティドラフトがある。 ¾ z Quality Model for Web Services v2.0 OASIS Web Services Resource Framework (WSRF) TC：Web サービスを使う状態を持つリソー スをモデル化し、アクセスするための、汎用かつオープンなフレームワークを定義する。以 下が 2006 年 4 月に OASIS 標準となっている。 ¾ WS-Resource specification、WS-Resource WSDL ¾ WS-ResourceProperties (WSRF-RP) specification、WS-ResourceProperties (WSRF-RP) WSDL ¾ WS-ResourceLifetime (WSRF-RL) specification、WS-ResourceLifetime (WSRF-RL) WSDL ¾ WS-ServiceGroup (WSRF-SG) specification、WS-ServiceGroup (WSRF-SG) WSDL ¾ WS-BaseFaults (WSRF-BF) specification、WS-BaseFaults (WSRF-BF) WSDL またApplication Notes (AppNotes)を 2006 年 3 月に、WSRF Primerを 2006 年 5 月にそれぞれコ ミッティドラフトとしている。 Web サービスカテゴリ 7-52 - 52 - OASIS Asynchronous Service Access Protocol (ASAP) TC：非同期の Web サービス、長時間実行 される Web サービスのための非常にシンプルな SOAP 拡張をASAP Specificationで提案して いる。 OASIS ebXML Business Process TC：XML を使用したビジネスコラボレーションのための情報交換 （ビジネストランザクション）を、自動かつ予測可能にするためのビジネスプロセス基盤を 標準ベースで提供することを目標としている。最新バージョン ebXML Business Process Specification Schema v2.0.4仕様が 2006 年 12 月に OASIS 標準となっている。 OASIS ebXML Collaboration Protocol Profile and Agreement (CPPA) TC：取引パートナーが電 子メッセージ交換による電子ビジネスコラボレーションに参加する方法を記述する。CPP （Collaboration Protocol Profile）はパーティ間のメッセージ交換ケーパビリティを記述 し、CPA（Collaboration Protocol Agreement）はパーティ間のメッセージ交換のアグリー メントを記述するための仕様である。ebXML Collaboration Protocol Profile and Agreement (CPPA) v2.0が 2002 年 6 月に OASIS 標準となっている。現在「自動ネゴシエーション」「ト ランザクションケーパビリティ」「Web サービスインタラクション」のサブ委員会（以下 SC） に分かれ、次バージョンの作業中である。 OASIS ebXML Implementation, Interoperability and Conformance (IIC) TC：ソフトウェアの プロバイダが ebXML 仕様に従いインターオペラブルなインフラストラクチャを提供可能にす るために、テストフレームワーク、コンフォーマンステスト、インタオペラビリティテスト の各 SC で活動をしている。以下のドキュメントがある。 ebXML Test Framework v1.0 ebXML EAN-UCC Deployment Guide for ebMSG OASIS ebXML Messaging Services TC：e ビジネス・トランザクションのトランスポート、ルーテ ィング、パッケージングを定義するOASIS ebXML Messaging Service Specification 2.0 (01 April, 2002)が OASIS 標準（2004 年に ISO 標準）となっており、現在バージョン 3.0 の作業 中である。 OASIS ebXML Messaging Service Specification 3.0: Part 1, Core Features (2006 年 12 月ワーキングドラフト) OASIS ebXML Messaging Services 3.0: Conformance Profiles (2006 年 6 月コミッティド ラフト) OASIS ebXML Registry TC：相互運用可能な、e ビジネストランザクションのためのレジストリ、 リポジトリのための仕様として、レジストリの情報モデルとレジストリのサービス仕様であ るOASIS ebXML Registry Information Model (RIM) v3.0 と OASIS ebXML Registry Services (RS) v3.0 を 2005 年 5 月に OASIS 標準としている。さらに、レジストリについて、コンテ ント管理、ライフサイクル管理、品質管理の仕様も持っている。現在、情報モデルのコア・ コンポーネント、セキュリティサービス、セマンティックコンポーネントの管理の各 SC に 分かれて作業を継続している。 OASIS Electronic Business Service Oriented Architecture (ebSOA) TC：2001 年から更新され ていないebXML Technical Architecture Specification v1.0.4の刷新にあたり、その後の ebXML 仕様、W3C の Web サービスアーキテクチャをはじめ、関連する仕様を考慮し、評価す 7-53 - 53 - ることで先進のアーキテクチャパターンの可能性を検討する。 OASIS Framework for Web Services Implementation (FWSI) TC：堅牢な Web サービス実装のた めの、実践的な拡張可能な方法論と、共通機能エレメントを定義する。活動は方法論と共通 機能の 2 つの SC で進められている。現在それぞれのパブリックレビュードラフトが作成さ れている。 Web Service Implementation Methodology,(2005 年 7 月) Functional Elements Specification 2.0, Committee Draft (2006 年 9 月) OASIS Open Building Information Exchange (oBIX) TC：施設内の電源、機器の制御系とエンタ ープライズアプリケーションの間のコミュニケーションを Web サービスベースで可能にしよ うという取り組みである。電源、機器の制御系で使用されている専用のプロトコルをオープ ンなプロトコルに接続するという挑戦である。活動は、「ロードマップ」「XML ベースのプ ロトコル定義」「電源システム」「セキュリティシステム」の各 SC に別れて進められてい る。 OASIS Translation Web Services TC：翻訳業の Web サービスについての標準メカニズムを継続 検討している。 OASIS UDDI Specification TC：Web サービスの動的なディスカバリと呼出を可能にする、 Web サービスレジストリの基盤として UDDI.org が開発、出版している Universal Description, Discovery, and Integration (UDDI)仕様の作業を継続している。UDDI v2 が 2003 年 2 月に、 UDDI v3が 2005 年 2 月に OASIS 標準となっている。この TC は OASIS の提供する e-メールリ スト、アーカイブサービス、及び Web ページを利用し、他の TC、標準化団体とのリエゾン、 ビジネスレジストリオペレータからのフィードバック、仕様のメンテナンス活動などを継続 している。 OASIS Web Services Business Process Execution Language (WSBPEL) TC：ビジネスプロセスの アクティビティを Web サービスとして記述するための XML ベースの言語を定義している。 2002 年 8 月にサブミットされた Business Process Execution Language for Web Services (BPEL4WS) 仕様のをベースに継続作業中であり、2007 年 1 月に WS-BPEL2.0をコミッティド ラフトとしている。 OASIS Web Services Composite Application Framework (WS-CAF) TC：複数 Web サービスアプリ ケーションのコーディネーションと合成をサポートするオープンフレームワークを定義す る。2003 年 7 月に TC にサブミットされた WS-Context、WS-Coordination Framework、 WS-Transaction Management 仕様をベースに継続作業中である。WS-Coordination Framework specificationがコミッティドラフトとなっている。 OASIS Web Services for Remote Portlets (WSRP) TC：対話型 Web サービスを提供するコンポー ネント間のインタラクションを標準化するために必要なインタフェースとセマンティック スを定義しておりWSRP 1.0 specificationが 2003 年 8 月に OASIS 標準となっている。その 後も「コンフォーマンス」「ポートレット間のコーディネーション」「WSDL 記述」「相互運 用性」「マークアップ言語」「プライマ・ドキュメント作成」「レジストリ」その他の各分 7-54 - 54 - 野での作業を継続している。参考文献も多い。 OASIS Web Services Reliable Exchange (WS-RX) TC ：2005 年 2 月に TC にサブミットされた WS-ReliableMessaging および WS-RM Policy 使用をベースに、Web サービスを使用した高信 頼メッセージ交換プロトコルを定義する。以下がコミッティレビュードラフトである。 Web Services Reliable Messaging v1.1 （2006 年 8 月） Web Services Reliable Messaging Policy Assertion v1.1 （2006 年 8 月） OASIS Web Services Reliable Messaging (WSRM) TC：アプリケーションまたは Web サービスに メッセージ配信を保証するための標準の相互運用可能な方法を提供する。WS-Reliability v1.1が 2004 年 11 月に OASIS 標準となっている。 OASIS Web Services Secure Exchange (WS-SX) TC：WS Security仕様を拡張し、複数 SOAP メッ セージのトラスとされた交換を可能にし、さらにメッセージのフォーマットやセキュリティ トークンを支配するセキュリティポリシを定義する。以下の仕様のサブミットをベースに作 業中である。 WS-SecureConversation (2005 年 2 月) WS-Trust (2005 年 2 月) WS-SecurityPolicy (2005 年 7 月) 以下がコミッティドラフトとなっている。 WS-SecureConversation 1.3 (2006 年 9 月) WS-Trust 1.3 (2006 年 9 月) SOAカテゴリ 以下では Web サービスカテゴリと重複の無い TC のみをリストする。 OASIS Semantic Execution Environment TC：SOA 内でセマンティック Web サービスを配備する上 でのガイドライン、その正当性、実装の方向の検討を開始している。憲章から以下のドキュ メントを作成予定である。 セマンティック Web サービスのアーキテクチャと情報モデル サービス仕様 その他の技術レポート、ホワイトペーパなど OASIS SOA Adoption Blueprints TC：実ビジネスに対し、SOA を計画、構築するためのアーキテ クチャ上のブループリントを開発しようとしている。 OASIS SOA Reference Model TC：個別分野のサービス指向アーキテクチャ構築をガイドするため の核となる参照モデルを開発しておりReference Model for Service Oriented Architecture v1.0が 2006 年 10 月に OASIS 標準となっている。 7-55 - 55 - A.2. W3C の詳細状況 概要 W3C（World Wide Web コンソーシアム）は 1994 年 8 月、World Wide Web（以下 WWW）の潜在能力 を完全に引き出し、その発展をプロモートし、共通プロトコルを開発し、インタオペラビリティ を保証する為に生まれた。W3C は現在、全世界から約 400 近いメンバを持っており、Web の発展 への貢献が、国際的に認知されている。 グリッドの標準化活動としては、Globus プロジェクトを中心に、その第一世代の独自プロトコル に拠る異種分散環境の実現を狙ったが、2002 年に発表された OGSA 以降、既存の WWW 及び、Web サービスのインフラストラクチャ上でのリファクタリングへと向かっている。2004 年発表の Web サービスリソースフレームワーク関連では、WS-Addressing 仕様が W3C で標準化作業に入ってい る。 以下では、本「グリッドコンピューティング標準化調査研究」に関連があると思われる、グリ ッド及び Web サービスのセキュリティ、ポリシ、管理、記述/識別に関係する W3C のいくつかの 標準化状況を調査する。2006 年度の状況としては、W3C においても、時代を反映して活動が活発 な Web サービスアクティビティ及び、すべての仕様のベースとなる XML アクティビティの状況を 報告する。W3C の概要等については、「グリッドコンピューティング標準化調査研究」の平成 17 年度報告を参照。 XML アクティビティ XML は SGML (ISO 8879)から派生した、シンプルでフレキシブルなテキストフォーマットであり、 W3C が XML 仕様を作成、開発、継続メンテナンスしている。また XML をベースとする、その他の 業界を横断する仕様の主要な開発センターとなっている。これらの仕様のうち XML クエリー、XML スキーマ仕様（2007 年 1 月に W3C 勧告となった。）は XML アクティビティに含まれるが、Web サ ービス、SVG、XHTML アクティビティで分担されている仕様もある。XML アクティビティ全体とし ての目標は、仕様の安定性、後方互換性の維持とインタオペラビリティ推進の支援、XML に新た なコミュニティを育てることである。 XML の適用範囲が拡大し、各仕様の配備も進んでいることから、2006 年 10 月にアクティビティ 全体としてリニューアルされ、8 ワーキンググループとコーディネーショングループが活動して いる。以下では、これまでの仕様及び昨年度に更新されている、ワーキングドラフト、候補勧告 をリストアップする。 Efficient XML Interchange Working Group ：各種の XML 交換エンコーディングフォーマットに ついてのエンコーディング性能結果をEfficient XML Interchange Measurements Note(2006 年 7 月ワーキングドラフト)として発行している。評価方法、評価結果についての合意に至 っているわけではなく、レビュー目的で発行されたものであるが、XML をインフラストラク チャとして広く利用するために不可欠な活動のひとつである。 XML Core Working Group ：Namespaces in XML 1.0 (Second Edition)、 Namespaces in XML 1.1 (Second Edition)、Extensible Markup Language (XML) 1.1 (Second Edition)のメンテナ ンスを行うと共に、以下のドキュメントがあり。 XML Inclusions (XInclude) Version 1.0（2006 年 10 月の提案勧告） 7-56 - 56 - xml:id Version 1.0（2005 年 9 月 W3C 勧告） XML Processing Working Group ：XML ドキュメント上で実行されるパイプライン型のオペレーシ ョンを記述する言語XProc: An XML Pipeline Languageのワーキングドラフトを 2006 年 11 月に発行している。 XML Query Working Group：XQuery 1.0 が 2007 年 1 月に W3C 勧告となっている。並行して XQuery 言語をベースとした XML ドキュメントの更新仕様拡張に向けた検討を開始しておりXQuery Update Facility Use Cases（2006 年 5 月のワーキングドラフト）、XML Query Update Facility （2006 年 5 月のワーキングドラフト）を発行している。以下は 2007 年 1 月の W3C 勧告とな った XQuery 関連の仕様及び関連ドキュメントの一覧である。 XML Query Requirements (2005 年 6 月のワーキングドラフト) XML Query Use Cases (2006 年 6 月のワーキングドラフト) XQuery 1.0 and XPath 2.0 Data Model (2007 年 1 月の W3C 勧告、XSL ワーキンググループ とジョイント) XSLT 2.0 and XQuery 1.0 Serialization (2007 年 1 月の W3C 勧告、XSL ワーキンググルー プとジョイント) XQuery 1.0 and XPath 2.0 Formal Semantics (2007 年 1 月の W3C 勧告、XSL ワーキンググ ループとジョイント) XQuery 1.0: An XML Query Language (2007 年 1 月の W3C 勧告、XSL ワーキンググループと ジョイント) XML Syntax for XQuery 1.0 (XQueryX) (2007 年 1 月の W3C 勧告、XSL ワーキンググループ とジョイント) XQuery 1.0 and XPath 2.0 Functions and Operators (2007 年 1 月の W3C 勧告、XSL ワーキ ンググループとジョイント) XPath Requirements Version 2.0 (2005 年 6 月のワーキングドラフト XSL ワーキンググルー プとジョイント) XML Path Language (XPath) 2.0 (2007 年 1 月の W3C 勧告、XSL ワーキンググループとジョ イント) XML Query and XPath Full-Text Requirements (2003 年 5 月のワーキングドラフト XSL ワ ーキンググループとジョイント) XML Query and XPath Full-Text Use Cases (2006 年 5 月のワーキングドラフト XSL ワーキ ンググループとジョイント) XQuery 1.0 and XPath 2.0 Full-Text (2003 年 5 月のワーキングドラフト XSL ワーキンググ ループとジョイント) Building a Tokenizer for XPath or XQuery (2005 年 4 月のワーキングドラフト XSL ワー キンググループとジョイント) XSL Transformations (XSLT) Version 2.0 (2007 年 1 月の W3C 勧告、XSL ワーキンググルー プとジョイント) XML Schema Group：XML スキーマ 1.1 の作業を開始しXML Schema 1.1 Part 2: Datatypesをまず、 2006 年 2 月にワーキングドラフトに、XML Schema 1.1 Part 1: Structuresを 2006 年 8 月に ワーキングドラフトとしている。主要な課題は XML スキーマのバージョニングである。以下 に、これまでの主要ドキュメントの一覧を示す。 7-57 - 57 - XML Schema Part 0: Primer（2004 年 10 月 W3C 勧告） XML Schema Part 1: Structures（2004 年 10 月 W3C 勧告） XML Schema Part 2: Datatypes（2004 年 10 月 W3C 勧告） XML Schema: Component Designators（2005 年 3 月ワーキングドラフト）XML スキーマの個 別コンポーネントを参照するためのメカニズムを提案している。 Guide to Versioning XML Languages using XML Schema 1.1（2006 年 9 月ワーキングドラフ ト）開発中の XML スキーマ 1.1 でスキーマ変更に対する堅牢性に有効な構文を検討して いる。 Processing XML 1.1 documents with XML Schema 1.0 processors（2005 年 5 月ワーキング グループノート） XML Schema Requirements（1999 年 2 月 W2C ノート） XSL Working Group：以下の XSLT、XPath 仕様を W3C 勧告にしている。 XSLT 1.0 （1999 年 W3C 勧告） XPath 1.0（1999 年 W3C 勧告） XSL 1.1 (XSL-FO 1.1) （2006 年 12 月 W3C 勧告） XQuery 1.0 and XPath 2.0 Data Model (XDM) （200 ７年 1 月 W3C 勧告） XPath 2.0 requirements（2005 年 6 月ワーキングドラフト） XSLT 2.0 requirements XSLT 2.0（2006 年 12 月 W3C 勧告） XPath 2.0（2006 年 12 月 W3C 勧告） XML Binary Characterization Working Group：XML のバイナリエンコーディングに求められる特 性を整理し、以下のワーキンググループノート（2005 年 3 月）を残している。 XML Binary Characterization Use Cases XML Binary Characterization Properties XML Binary Characterization Measurement Methodologies XML Binary Characterization XML Linking Working Group：XLink、XPointer、XML Base 仕様を策定していたが、活動を終了し ている。以下主要な勧告の一覧を示す。 XML Linking Language (Xlink) Version 1.0(2001 年 6 月勧告) XML Base(2001 年 6 月勧告) XPointer Framework、XPointer element() scheme、XPointer xmlns() scheme(2003 年 3 月 勧告) Web サービスアクティビティ Web サービスは、各種のプラットフォーム、フレームワークで動作する、異なるソフトウェア間の インタオペレーションに対して標準の手段を提供するものである。Web サービスは XML を利用する ことで、インタオペラビリティ、拡張可能性、マシン処理可能な記述という特性をもち、より複雑 なオペレーションを可能にするために、疎結合の合成を可能にしている。シンプルなサービスを提 供するプログラムが相互にインタラクトすることで、付加価値サービスを容易に提供できるように なる。 7-58 - 58 - W3C の Web サービスアクティビティは、Web サービスのインフラストラクチャデザイン、アーキテ クチャ定義、コアテクノロジー定義を分担し、XML ベースのメッセージングフレームワークである SOAP 1.2 始め、Web サービス、さらにはグリッドの基盤でもある以下の仕様を W3C 勧告としている。 SOAP Version 1.2 Part 0: Primer ：SOAP Version 1.2 Part1/Part2 に対するチュートリアル・ ドキュメントである。 SOAP Version 1.2 Part 1: Messaging Framework ：SOAP 自体は非集中型の分散環境での構造化 情報交換を意図した軽量プロトコルであり、Part1 では多様な下位プロトコル上での交換を 可能にするメッセージ構造を持つ、拡張可能なメッセージングのためのフレームワークを XML テクノロジーベースで定義している。具体的には、「SOAP 処理モデル」「SOAP フィーチ ャとモジュールによる、拡張性のモデル」「SOAP プロトコルバインディングのためのフレー ムワーク」「メッセージ構造」を定義している。 SOAP Version 1.2 Part 2: Adjuncts ：Part2 では「アプリケーション定義のデータ構造に対す るデータモデル」「データモデルに従ったデータインスタンスのエンコーディングルール」 「RPC コールのための規約」「フィーチャとバインディングを記述するための規約」「メッ セージ交換パターンとフィーチャ」「Web メソッドフィーチャ」「HTTP バインディング」を 定義している。 SOAP Version 1.2 Specification Assertions and Test Collection ：SOAP 1.2 テストスイー ト準拠をクレームするための、SOAP Part1/2 のアサーションを定義したドキュメントである。 XML-binary Optimized Packaging ：XML 情報セットをより高速にシリアライズするための手段と して XML-binary Optimized Packaging (XOP)規約を定義している。基本的には base64 エン コーディングをベースとしている。 SOAP Message Transmission Optimization Mechanism ：SOAP メッセージの転送及びワイアフォ ーマットを最適化するための抽象フィーチャと具体的インプリメンテーションの定義して いる。具体的インプリメンテーションは XML-binary Optimized Packaging (XOP)規約に拠っ ている。 Resource Representation SOAP Header Block ：SOAP メッセージに Web の各種表現形式を搬送す るための SOAP ヘッダーブロックのセマンティックスとシリアライズについて定義している。 Web Services Addressing 1.0 - Core ：2006 年 5 月に W3C 勧告となった。Web Seivices Addressing は Web サービス及びメッセージのアドレス付けを行うためのトランスポート中立なメカニズ ムである。Core 仕様は Web サービスの参照及び、メッセージ中でエンドポイントのエンド・ ツー・エンドのアドレス付けを可能にするための抽象プロパティと XML 情報セットを定義し ている。エンドポイント・メッセンジャ、ファイアウォール、ゲートウェイ 等の処理ノー ドを含むようなネットワークを介してトランスポート中立なメッセージ転送をサポート可 能にするための仕様である。 Web Services Addressing 1.0 - SOAP Binding ：2006 年 5 月に W3C 勧告となった。Web Seivices Addressing 1.0 – Core 仕様の抽象プロパティに対する SOAP1.2 バインディングを定義して いる。 Web サービスの台頭と共に、このアクティビティの活動も活発になり、現在 7 ワーキンググルー プ、1 インタレストグループが登録されている。各グループについて、W3C 勧告以前の段階のド キュメントへのリファレンスと概要を示す。尚、Web Services Architecture Working Groupが 活動を終了している。 7-59 - 59 - Semantic Annotations for Web Services Description Language Working Group ： Semantic Annotations for WSDL（2006 年 9 月にワーキングドラフト）: WSDL の各コンポー ネントに付加的なセマンティックスを記述できる拡張アトリビュートのセットを WSDL 2.0 に対して定義している。この定義は、オントロジーなどのセマンティック・モデル を参照する形のアノーテーション方式を取っており、セマンティック・モデル自体の表 現言語は規定せず、特定のセマンティック・モデルの表現言語にも依存しない。つまり、 WSDL ドキュメント外で定義されるセマンティック・モデルの概念を WSDL コンポーネン ト内からアノーテーションによって参照出来るようにするためのメカニズムとして提 供される。 Semantic Annotations for WSDL — Usage Guide（2006 年 9 月にワーキングドラフトとなっ ている。）：上記の使用ガイドドキュメントである。WSDL は Web サービスのインタフェ ースに対する入出力メッセージの構造や、呼び出し方法のシンタクス記述を提供してい るが、Web サービス自体が本当に何をするのかについてのセマンティック記述が必要と いう立場からの使用ガイドである。曖昧性のないフォーマルな言語でこのようなセマン ティックスが表現されることは、自動ディスカバリやソフトウェアコンポーネントの合 成・統合に必要となる。 Semantic Web Services Interest Group ：主にセマンティック Web のテクノロジーを Web サー ビスアクティビティに統合する方向を指向した話題について、W3C 内外のメンバに対してフ ォーラム活動を行っている。 Web Services Description Language (WSDL) Version 2.0: RDF Mapping ：（2007 年 1 月に 候補勧告となっている。）WSDL のコンポーネントモデルを RDF（Resource Description Language）及び OWL （Web Ontology Language）で記述する方法を提示し、さらに WSDL 記述を RDF 形式に変換する手続きを提示している。 Web Services Addressing Working Group ：Web Seivices Addressing 仕様自体は、W3C 内の仕 様としては、SOAP、WSDL、CDL 仕様に仕様に関連する。OASIS 関連ではWS-BPEL、WS-Security、 WS Distributed Management 、 Web Services Reliable Exchange (WS-RX) 、 WS Reliable Messaging、WS Composite Application Framework、WS-Resource Framework、WS-Notification の各仕様に関連している。またWeb Services Interoperability Organizationと連携してい る。現在の憲章期間は 2007 年 6 月までである。 Web Services Addressing 1.0 - WSDL Binding（候補勧告）：2006 年 5 月に候補勧告となっ ている。Web Seivices Addressing 1.0 – Core 仕様の抽象プロパティに対する WSDL2.0 バインディングを定義している。 Web Services Choreography Working Group ： WS-CDL 仕 様 を 開 発 中 で あ り 、 Web Services Choreography Description Language Version 1.0(2005 年 11 月)を候補勧告としている。2006 年には以下のチュートリアル・ドキュメントを発行している。 Web Services Choreography Description Language: Primer（2006 年 6 月ワーキングドラフ ト）： Web Services Description Working Group ：WSDL 仕様は Web サービスを記述する XML ドキュメ ントであり、現在の憲章期間 2007 年 6 月までに WSDL 2.0 仕様を完成させる計画である。 Web Services Description Language (WSDL) Version 2.0 Part 0: Primer （2006 年 3 月に 7-60 - 60 - 候補勧告）：以下の WSDL 2.0 仕様 Part1/2 に対するチュートリアル・ドキュメントで ある。 Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language 及びschema、 wsdlx schema (2006 年 3 月に候補勧告) ：Web サービスが提供するものについての抽象 モデルをベースにした記述に使用するためのコア言語を定義している。また準拠性の基 準も定義している。 Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts及び SOAP 1.2 binding schema、HTTP binding schema (2006 年 3 月に候補勧告) ：上記 WSDL 2.0 コア 言語に対する「メッセージ交換パターン」「オペレーションスタイル」「バインディン グ（SOAP1.2 及び HTTP）拡張」の規定義拡張部分に当たる。 Web Services Description Language (WSDL) Version 2.0 SOAP 1.1 Binding （2006 年 3 月にワーキングドラフト）：SOAP1.1 バインディングを別のドキュメントに分離してい る。 Web Services Description Language (WSDL) Version 2.0: RDF Mapping （2006 年 3 月ワー キングドラフト）：WSDL 2.0 モデルの RDF 及び OWL 記述と、WSDL 記述から RDF 記述へ の変換手続きの説明を行っている。 Web Services Description Requirements （2002 年のワーキングドラフト）：WSDL 2.0 に 対する要求仕様ドキュメント。 Web Services Description Usage Scenarios （2002 年のワーキングドラフト）：WSDL 2.0 に対する仕様シナリオ・ドキュメント。 Describing Media Content of Binary Data in XML (W3C ワーキンググループノートで終了) ： XML 及び XML スキーマドキュメントのバイナリエレメントを持つコンテントに対する content-type を規定している。 Discussion of Alternative Schema Languages and Type System Support in WSDL 2.0 (W3C ワーキンググループノートで終了)：WDSL 2.0 仕様のベースとなるタイプシステムにつ いて XML Schema 1.0 以外の代替案について DTD（Document Type Definitions）と Relax NG を検討している。 Web Services Policy Working Group ：WS-Policy 仕様は Web サービスベースのシステム中に存 在するエンティティの持つポリシを記述するための汎用モデルと対応するシンタクスで構 成され、他の Web サービス関連仕様でサービスの要件、サービスのケーパビリティを記述す るために拡張仕様として使用される構文のベースセットを定義するものである。 Web Services Policy 1.5 - Framework（2006 年 11 月にワーキングドラフト）：ドメイン固 有のポリシ表現のためのフレームワークとモデルを定義する。ポリシはポリシ選択肢の 集まりであり、ポリシ選択肢は個別ポリシの集まり、ポリシは XML 情報セットにより、 ポリシ式として記述される。 Web Services Policy 1.5 - Attachment（2006 年 11 月にワーキングドラフト）：Web Services Policy 1.5 - Framework で定義されたポリシを、適用されるサブジェクト（エンドポ イント、メッセージ、リソース、オペレーションなどの実体）に結びつける汎用メカニ ズムを定義する。具体的には、XML ドキュメントを直接添付する方式と、外部参照の形 態を取るものが定義される。また、この汎用メカニズムでポリシを WSDL と UDDI 記述と どのように結びつけるかを定義する。 Web Services Policy 1.5 - Primer（2006 年 12 月にワーキングドラフト）Web Services Policy 1.5 – Framework 仕様と Web Services Policy 1.5 – Attachment 仕様に対するチュー 7-61 - 61 - トリアル・ドキュメントである。 Web Services Policy 1.5 - Guidelines for Policy Assertion Authors（2006 年 12 月にワ ーキングドラフト）ポリシ・アサーション記述者に対するガイドライン・ドキュメント であり、ベストプラクティスとインタオペラビリティを達成させるために必要なパター ンを提示する。 XML Schema Patterns for Databinding Working Group ：XML をデータバインディングに使うコ ミュニティの拡大に伴い、効率よいインプリメントが可能な XML スキーマのパターンを定義 することが有効となると予想される。具体的には、ハッシュテーブル、ベクトル、各種コレ クションなどの抽象データ構造を定義する方向である。主にモデルを扱う関係から「プロフ ァイル」ではなく「パターン」という用語を使用している。抽象データ構造を、「基本」「発 展」「ペンディング」に分類し、前者 2 つについて作業を開始している。 XML Schema Patterns for Common Data Structures 1.0（2006 年 5 月のワーキングドラフト） 共通に使用されるデータ構造を XML 表現する場合の XML スキーマ 1.0 パターンの集合を 提示している。提示されているデータ構造は特定のプログラミング言語、データベース、 モデリング環境とは独立なものとしている。 Basic XML Schema Patterns for Databinding 1.0（2006 年 11 月のワーキングドラフト） Advanced XML Schema Patterns for Databinding 1.0（2006 年 11 月のワーキングドラフト） XML Protocol Working Group：SOAP 仕様を開発、メンテナンスしている。以下、ドキュメントの リストを示す。 XML Protocol (XMLP) Requirements（2003 年のワーキンググループノート） XML Protocol Usage Scenarios（2003 年のワーキンググループノート） XML Protocol Abstract Model （2003 年のワーキングドラフト） SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)( 2006 年 12 月の提案勧 告)：すでに 2003 年に勧告となっているものに対する第 2 版である。 SOAP Version 1.2 Part 2: Adjuncts (Second Edition) （2006 年 12 月の提案勧告）：すで に 2003 年に勧告となっているものに対する第 2 版である。 SOAP Version 1.2 Part 0: Primer (Second Edition) （2006 年 12 月の提案勧告） ：すで に 2003 年に勧告となっているものに対する第 2 版である。 SOAP 1.2 Attachment Feature（2004 年のワーキンググループノート）：SOAP 添付に対する 抽象モデルを表現する SOAP1.2 フィーチャを定義している。 SOAP Optimized Serialization Use Cases and Requirements（ワーキングドラフト） XML-binary Optimized Packaging (XOP) (2005 年 1 月の提案勧告) SOAP Message Transmission Optimization Mechanism (MTOM) (2005 年 1 月の提案勧告) Resource Representation SOAP Header Block (RRSHB) (2005 年 1 月の提案勧告) SOAP Version 1.2 Email Binding（ノート） SOAP Version 1.2 Message Normalization（ノート） XOP Inclusion Mechanism - Frequently Asked Questions（ノート） The "application/soap+xml" media type (RFC 3902) Describing Media Content of Binary Data in XML（ノート） 7-62 - 62 - 付録Ｂ グリッドシステムの用途例および要件リスト 1. グリッドシステムの用途例とその要件 昨年度は、いくつかの典型的なシステムを想定し、旧版ガイドラインへの適用と改善点の検討を行い つつ、グリッドシステムのモデル化を進めてきた。今年度はグリッドシステムの具体的な事例を調査し、グ リッド技術に関連する部分を中心にシステムの要件を抽出した。取り上げたグリッドシステムは以下のと おりである。 今回は、以下の大項目として三つ、小項目として五つのグリッドシステムを用途例として取り上げた。 ■企業内技術計算グリッド これは、一つの企業内で技術計算を実施するためのグリッド環境を構築しているケースである。技術 計算とは、学術分野におけるシミュレーション研究のように CPU パワーを必要とする解析処理を指し、企 業においては、自動車企業における構造解析、流体解析、衝突解析、創薬企業におけるドラッグスクリ ーニング、金融業におけるリスク分析などが該当する。 ここでは、ノバルティスの事例を参考とした。ノバルティスでは、技術計算を実施するために導入した 計算機システムの他、社員が使用している PC も解析処理の対象として活用している。技術計算専用に 導入した計算機システムと、PC では、システムとしての要件が大きくことなるため、本用途例を、以下の 二つのケースに分割して検討することとした。 ●コンピューティンググリッド 一つの企業内において、技術計算を実施する専用の計算機システムを複数有し、それらを統合 して利用しているケースである。 ●PC グリッド 技術計算を実施するための専用計算機システムではなく、社員のその他の業務のために割り当 てた PC や CAD 用ワークステーションなどを、技術計算のためにグリッド・システムの一部として環境 を提供し、遊休リソースを利用しているケースである。ここでは、ノバルティスの事例の他、これまで 日本 IBM の PC グリッド・プロジェクトで活用した簡易チェックリストも要件抽出の参考とした。 ■学術共同グリッド 複数の大学や研究所が学術利用を目的として、同等な立場で計算機システム（やデータ）を供出し共 有し合うグリッド環境を構築しているケースであり、共同研究などにおいて、大規模高速な解析の実現や、 研究効率の向上が主な目的である。学術共同グリッドとしては、共有するリソースがコンピューティング資 源の場合とデータ資源の場合と分けることができる。しかし、データ資源を共有するケースについては、 来年度の取り組みとする。 ●コンピューティンググリッド 技術計算を実施するリソースを複数の大学や研究所間で共有し合うケースである。ここでは、産 総研が中心にアジア諸地域と連携する取り組みである ApGrid の事例を参考とした。 ■商用データセンタ 7-63 - 63 - 商用データセンタでは、商用データセンタ事業者(提供者)が顧客(利用者)に対して、サーバやストレ ージをはじめとする各種リソースを貸し出し、顧客の業務システムをホストすることにより収益を得る。この 場合の提供物は商用データセンタ事業者が所有するサーバリソースやストレージリソースなどである。グ リッド技術を適用することにより、商用データセンタはリソースプールの稼働率向上、TCO 削減が期待で き、ひいては顧客企業に対して低廉なサービスを提供することが可能となる。 ●ビジネス・コンピューティング・グリッド（業務システムに対するサーバリソース提供） ビジネス・コンピューティング・グリッドは、企業などが運用する業務システムに対するグリッド技術 の応用例の一つで、業務システムを運用する際に必要となるリソースをリソースプールから動的に 確保し、業務システムへ割り当てることにより、業務システムの運用・管理を効率化することを目的と している。 ●ストレージ基盤サービス（ストレージグリッド） ストレージ基盤サービスは、商用データセンタ内のストレージをプールして、システム使用者の要 求に従いオンデマンドにストレージサービスを提供するデータグリッド技術の適用例の一つである。 以下、各小項目の用途例に対して、モデル化の議論を踏まえたシステムの記述とその要件をリストアッ プする。 7-64 - 64 - 2. 企業内技術計算グリッド （コンピューティンググリッド） ●概要 一つの企業内において、技術計算を実施する専用の計算機システムを複数有し、それらを統合して 利用しているケースについて記述する。ここでは、ノバルティスの事例を参考とした。ノバルティスでは、 技術計算を実施するために導入した計算機システムの他、社員が使用している PC も解析処理の対象と して活用しているが、ここでは、ＰＣグリッドに関わる要件は次節で扱うこととし除いた。 ●企業内技術計算のグリッドへの期待 現在、企業内のテクニカル分野では、「LSI 設計シミュレーション」「金融ポートフォーリオ管理」「バイオ インフォマティクス」などの必要性が高まり、より一層のコンピューティングリソース(計算資源)が必要にな ると予測されている。また、最近のビジネス環境より、企業にはより一層のコストダウンを迫られている。そ こで、企業内のテクニカルコンピューティングへグリッドを適用することで、コストを抑えつつ必要なコンピ ューティングパワーを得るシステムとして企業内技術計算グリッドが構築されつつある。 企業内技術計算グリッドに対する期待（ニーズ）は、グリッド環境の提供者（IS 部門）と利用者（社内技 術者）とでは異なる。以下に、提供者と利用者が、企業内技術計算グリッドに対する典型的な期待の例を 記述する。 z グリッド環境提供者の期待 ¾ 資源を有効活用する事により TCO を削減する。 ¾ グリッドの持つ柔軟な構成変更機能によりスケーラビリティを確保し将来の拡張に備える。 ¾ 障害発生時にグリッドの環境を柔軟に変更する事によりシステムの高い可用性を確保する。 z グリッド環境利用者の期待 ¾ グリッド上に多数存在するコンピュータへ並行して多数のジョブを実行させる事が可能に成 るため、高いスループットを確保する事ができる。 ¾ グリッド上に存在する適切(高性能)な計算機を利用する事により、適切な計算性能を得る事 ができる。 ¾ 特定のコンピュータ障害に左右されず、期待した時間内に処理が終了する。 ¾ 関係の無いグリッド利用者と隔離した形でジョブを実行する事で、他利用者からの影響をお さえることができる。 次に企業における技術計算としてのグリッドのシステム構成について考察する。 なお、このシステム構成のモデルは、必然的なものではなく、本ガイドラインの適用に必要となるものを想 定して、できるだけ妥当と思える内容を仮定している。 ●システム規模 企業内技術計算グリッドでは、企業内の複数の事業所に分散されたサーバ資源をグリッド技術にて柔 軟に結合させたものを示している。 企業内技術計算にグリッド環境の適用を検討する国内の企業のシステム規模としては、下記のものが 想定される。 z 国内に数箇所から十数か所の事業所にサーバや利用者が分散している。 7-65 - 65 - z z 数百程度の大中小のサーバが混在し、CPU 数は、サーバ数の１０倍程度になる。 利用者には、社内技術者と関連会社社員が数百人程度いる。 ●グリッドの利用形態 ＜プロジェクト単位の管理＞ 企業内では、複数のプロジェクトが不定期、または定期的に発足，解散が繰り返される。プロジェクト毎 にリソースが割り当てられ、プロジェクトのメンバは、プロジェクトに割り当てられたリソースを利用する。プ ロジェクトの参加者は複数の部門に分かれるが、プロジェクトの幹事部門が存在し、課金の決済も幹事 部門が行う。プロジェクトのメンバは発足時に都度集められ、必要に応じてメンバの追加，削除が行われ る事が想定される。また、使用されるリソースもプロジェクトの要求に合わせて柔軟に割り当てられる。 この様なプロジェクトをグリッドにおける仮想組織と想定する事で企業内におけるテクニカルグリッドを考 え、そのメンバをリソース利用者と考える事ができる。 プロジェクトのメンバーに参加する 計算リソースプール 計算機 計算機 計算機 プロジェクト単位にリソースは動的に割当てられる プロジェクトは必 プロジェクト A プロジェクト B 要に応じて発足， 解散される プロジェクトのメンバに参加する 社員 A 社員 B 社員 C 関連会社員α 図 2-1 企業内のプロジェクトによるリソース利用のイメージ ＜利用者のジョブ実行＞ 利用者のグリッド利用は、ジョブ投入という形で実施される。利用者がジョブ投入する形態としては、利 用者に見える形として下記の３つの形態が考えられる。 （ｉ） 同期型投入ジョブ 利用者の要求に合せて不定期に投入されるジョブで、投入から終了までユーザとのセッションが 張られる事が前提になる。利用者がジョブの処理終了までクライアントで待つシステム形態となる ため比較的短時間に処理結果が得られるジョブに適用される場合が多い。 （ｉｉ） 非同期型投入ジョブ 利用者の要求に合せて不定期に投入され、投入後に接続が切れ、処理終了後に通知があり処 理結果を取り出す方式のジョブで投入から終了までユーザとのセッション継続の必要は無い。利 7-66 - 66 - 用者がジョブの処理終了までクライアントで待つ必要がなく比較的長時間の処理が必要なジョブ への適用が好まれる。 サイエンス分野でのバッチジョブと言われるジョブが、この形態のジョブである。 （ｉｉｉ） 定期実行型ジョブ システム管理者の設定したワークフローに沿って定刻に計画的に実行されるジョブ。旧来よりバッ チ処理と呼ばれているジョブである。 経験的に、技術計算は、長時間の処理が必要で、必要に応じて不定期にユーザが実行したい時に実 行する場合が殆どである。つまり、企業内技術計算グリッドは、(ii)非同期投入型ジョブが殆どと想定され る。そこで、本考察では、（ｉｉ）をモデルに想定してガイドラインへの適用を考えていく事とする。 ●システムモデルの特徴 システムモデルの特徴として次のことが想定される。 z z z プロジェクト毎にグリッド環境にデータの保存ストレージが準備される。 恒久的な知識や情報や断続的に実行されるジョブの一時的な実行結果などの保管場所はグリッ ド内の環境に用意されるものとする。この保存ストレージのセキュリティ(機密性,完全性,可用性)は、 運用システム全体としてのグリッドシステムとして保証される必要がある。なお、保存ストレージは、 グリッドシステムの提供者とプロジェクト責任者で管理権限を分担して管理する事になる。 利用者は自分の所属する事務所のジョブ投入ポータルからジョブを実行する。 非同期投入型ジョブのグリッド化を考えた場合、一般的な利用者はジョブが実際に実行される事 業所を知る必要は無い。また、ジョブの実行は、予め定められたポリシによって決定され、実行さ れる事業部が固定されているわけでは無い。 データは、事前にジョブ投入ポータルを介してプロジェクトのデータ保存ストレージに送られる。ま た、投入されたジョブは事業部間のスケジューリングシステムで調整され、最適な実行サイトへ投 入され、実行終了後の結果は、データ保存ストレージへ保存され終了通知後に取出される方式 になる。 テクニカルコンピューティンで使用されるアプリケーションのセットは定型的なものである。 ユーザが不特定多数のアプリケーションを実行させるわけでは無い。 サーバはジョブが投入される前にアプリケーションが実行可能に設定されていると想定して良 い。 7-67 - 67 - 事業部１ プロジェクト A メンバ（事業部１） ジョブ投入 ポータル （事業部１） 事業部１ プロジェクト A 実行環境 計算機 計算機 実行計算機 割当て ジョブ投入 データ入出力 計算機 計算機 入力データ送信 プロジェクト A 結果データ取出 事業部２ 保存ストレージ 計算機 事業部２ プロジェクト B メンバ（事業部２） 計算機 ジョブ投入 ポータル （事業部２） プロジェクト B 実行環境 計算機 実行計算機 割当て 計算機 ジョブ投入 事業部３ データ入出力 入力データ送信 計算機 プロジェクト B 結果データ取出 計算機 保存ストレージ 計算機 図 2-2 企業内のプロジェクトによるストレージリソース利用のイメージ このような、システムの特徴を持つ、企業内技術計算へのグリッド適用を念頭にガイドラインの要件項 目を当てはめていく。 なお、ここでのシステムは、先進的なグリッドの適用を行っている企業の技術計算グリッドの例で、企業内 技術計算グリッドの形態を規定しているものではない。 2.1. グリッドシステムのモデルとの関係 2.1.1. グリッドのプレイヤ 本ケースでは、企業のＩ S 部門が提供者であり、技術者など技術計算を実施する者が利用者となる。 利用者が他者に提供物として提供することはない。提供者と利用者は同一企業に属しているが、企業内 の部署は異なるのが一般的である。 提供者 利用者 提供物 提供物 図 2-3 提供者と利用者 2.1.2. グリッド環境における提供物 本ケースの提供物は、第４層までの環境を提供者が管理し提供している。 7-68 - 68 - 企業内 利用者 利用者 ポータル グリッドミドルウェア 計算機システム１ 管理ノード 計算機システム２ 管理ノード 演算ノード 演算ノード 演算ノード 演算ノード 演算ノード 演算ノード 演算ノード 演算ノード 図 2-4 提供物の構成例 具体的な提供物は、技術計算に使用するアプリケーションの実行処理である。利用者は、複数の計算 機システムを統合するグリッドミドルウェアに実行処理のリクエストを与える。リクエストは、実行するアプリ ケーションと入力データから構成される。グリッドミドルウェアは受付けたリクエストに基づき、管理下にあ るコンピューティングリソースに処理を分配する。処理を実行したコンピューティングリソースは、処理結 果を出力ファイルとして取得し、利用者に戻す。リクエストを受付け、処理を分配するグリッドミドルウェア は、ポータルなどのインタフェースを持っている場合もある。 グリッド・システム エンドユーザ環境 ポータルシステム 技術計算アプリケーション（構造解析、流体解析など） バッチキューシステム、グリッドミドルウェア 仮想ファイルシステム 各種ファイル システム （ネットワーク含） 各種OS （Windows, Linux, UNIX, etc） Ethernet, IP, TCP, UDP, etc SAN, NAS, etc サーバ，ブレード， etc スイッチ，ルータ， FW機器， VPN装置，etc ストレージ コンピューティング 図 2-5 提供物の階層図 7-69 - 69 - ネットワーク 第１層は、解析処理を実行するためのコンピューティングリソースが主となるが、解析処理に必要とす る入出力データを収めるストレージリソースと、複数のコンピューティング資源（計算機システム）を連携 するネットワークリソースも構成要素である。 2.1.3. プレイヤの役割と提供物の関係 本ケースの提供物に関係するプレイヤとその役割は、以下のとおりである。 ・ 技術者 企業において解析業務などを提供物としてのアプリケーション実行処理を利用する者。 役割：エンドユーザ、システム使用者 ・ IS 部門 企業において本システムを運用管理する部門。本システムの仕様を策定し、システムインテグレータ にシステムの構築を依頼する者。 役割：システム運営者 ・ システムインテグレータ IS 部門の仕様に従い、システムの構築を行う者。当該企業とは異なる企業に依頼するのが一般的で ある。 役割：システム構築者 ・ ベンダ グリッドシステムを構成する、サーバ装置、ストレージ装置、ネットワーク装置の他、システムを統合する ためのグリッドミドルウェアやキューイングシステムのソフトウェアを提供するベンダ。 役割：グリッド関連製品ベンダ また、本ケースでは、外部グリッドシステム提供者の役割を果たすプレイヤは存在しない。 システム使用者 エンドユーザ （技術者） システム使用 エンドユーザ環境 提供サービスのSLA ポータルシステム 技術計算アプリケーション（構造解析、流体解析など） 仕様決定 運用管理 システムの要求仕様 システム構築 製品仕様 グリッド関連 製品ベンダ （ベンダ） 管理，セキュリティ、・ ・ ・ システム運営者 （IS部門） システム構築者 （SIer） グリッド・システム （アプリケーション実行処理） バッチキューシステム、グリッドミドルウェア 仮想ファイルシステム 各種ファイル システム （ネットワーク含） 各種OS （Windows, Linux, UNIX, etc） Ethernet, IP, TCP, UDP, etc SAN, NAS, etc サーバ，ブレード， etc スイッチ，ルータ， FW機器， VPN装置，etc ストレージ コンピューティング ネットワーク グリッド関連製品提供 図 2-6 提供物とプレイヤの関係 7-70 - 70 - 2.1.4. 提供物の状態遷移 システム構築者が、システムの全てのコンポーネントを導入し、プラットフォーム第３層または第４層ま でを構築し、稼動可能な状態とする。システム運営者は、第４層へアプリケーションの追加などを行い、 システムを起動して、システム使用者に提供する。 2.1.5. グリッドシステムの管理 企業という同一組織ではあるが、IS 部門は計算機環境を提供することを業務としているため、利用者 に対するＳＬＡを持つ。運用時間、障害が発生した際の復旧など、運用上の制約事項が存在する。ハー ドウェアを常時監視し、障害が発生した場合の代替処置など。 システム使用者は通常プロジェクトなどのグループ毎に管理され、グループ毎の課金が実施される。 提供者は、利用者によって利用されたリソース量を把握し、課金情報とする。 2.1.6. グリッドシステムのセキュリティ 企業という同一組織内で使用するため、外部の利用者に対してデータを保護するなどの処置は基本 的に必要ない。事業所が複数に渡る場合、それらの間を接続するネットワークは、VPN などにより保護さ れる必要がある。 7-71 - 71 - 2.2. 要件リスト 2.2.1. システム使用者 ■ 提供物の情報 ・ 提供物の情報は使用者システムに開示されること（necessary） ・ システム使用者が利用した提供物の利用量は、システム使用者に開示されること（necessary）また 当該システム使用者以外には参照できないこと（necessary） ・ 提供物の構成情報や性能など、静的な情報はシステム使用者に開示されること（preferable） ■ ・ ・ ・ 提供物の利用 アプリケーションを実行するジョブの投入と結果の取得が可能であること（necessary） アプリケーションを実行するジョブのステータスが確認可能であること（preferable） 複数のシステム使用者間および、システム使用者自身による、優先度付けが可能であること (optional) 2.2.2. システム運営者 ■ システムの管理 ・ 簡便なインタフェースにより、計算リソースとなる各計算機システムの状況をシステム運営者が監視 可能であること（necessary） ・ ユーザが投入したジョブの配布状況、ステータス状況をシステム運営者が確認可能であること （necessary） ・ 計算リソースとなる各計算機システム上にジョブを割り当てる条件をシステム運営者が、設定可能で あること（preferable） ・ アプリケーションプログラムを、計算リソースとなる各計算機システム上への配備手段がシステム運 営者に用意されていること（necessary） ■ 提供物の情報 ・ システム使用者が利用した提供物の利用量は、システム運営者によって把握されること （necessary）、 ■ ジョブの管理 ・ システム使用者の投入した各ジョブの状況を、システム運営者が監視可能であること（necessary） ・ 計算リソースとなる計算機システム上で実行中のジョブをシステム運営者が中止可能であること （preferable） ・ 実行されたジョブの統計情報をシステム運営者が獲得可能であること（preferable） ・ 実行に失敗したジョブが自動的に再実行されること（preferable） ・ ジョブ毎の利用量に関する課金情報がシステム運営者によって取得できること（necessary） ■ セキュリティ ・ 計算リソース（計算ノード）にジョブを分配するサーバ（管理ノード）上で、ジョブおよびデータが保護 されていること（necessary） ・ サーバ（管理ノード）と計算リソース（計算ノード）間において、データが暗号化され、誰からも内容を 読まれることがないこと（necessary） ・ 複数の計算機システムにおいて統一的な ID 管理（認証、認可、属性管理）が行えていること （necessary） 7-72 - 72 - ・ 複数の計算機システムに対して、複数回のサインインをすることなくアクセス可能であること （necessary） ■ 障害系 ・ ジョブの投入を受け持つサーバ（管理ノード）が障害により動作しなくなった場合にも、代替サーバ によってジョブの投入が継続できること（preferable） ■ ネットワーク ・ 利用者の利用端末と、提供物が提供されるリソース（サーバ）との間のネットワークについて、十分な 帯域とダウンタイムに関する接続性が保証されていること（preferable）？ 2.2.3. システム構築者 システム運営者の要件を満たすシステムを構築することが、システム構築者に求められる要件であり、 システム構築者に特別な要件は存在しない。 2.2.4. グリッド関連製品ベンダ システム運営者の要件を満たすシステムを構築するためのグリッド関連製品を提供できることがグリッ ド関連製品ベンダに求められる要件であり、グリッド関連製品ベンダに特別な要件は存在しない。 2.2.5. 外部グリッドシステム提供者 本ケースの場合、外部グリッドシステム提供者は存在しないので、本要件も存在しない。 7-73 - 73 - 3. 企業内技術計算グリッド（PC グリッド） 一つの企業内において、技術計算を実施する専用計算機システムを用意するだけでなく、企業における業務 で使用している PC や CAD 用ワークステーションなどをグリッド環境に組み込み利用しているケースである。PC グリッドでは一般的に業務で提供されている PC や CAD 用ワークステーションの CPU 資源をユーザが使用して いない時間帯に、グリッドシステムとして活用し、高速あるいは多量の処理要求に対応することになる。端末が空 いている時間のみグリッドシステムに参加することになるので、ボランティア型グリッドと言われることもある。また 計算結果を得るための時間が決められている種類の計算では、技術計算用サーバと組み合わせて使用してい るケースも多く見られる。ここでは、ノバルティスの事例を参考とした。前節で解説したようにノバルティスでは、技 術計算を実施するために導入した計算機システムの他、社員が使用している PC も解析処理の対象として活用 している。ここでは、前節で扱わなかったＰＣグリッドに関わる要件を中心に扱う。 PC グリッドとは個人が業務やプライベートで利用しているコンピュータ(PC)の CPU 利用に特化したプロセッ シング･グリッドである。PC １台では高速 CPU を持つ高速計算サーバには及ばないが、100 台また 1000 台以上 集めればサーバに匹敵する処理能力を得ることが可能になる。 PC グリッドは通常は専用サーバに処理させるような処理を、大量の PC に処理させるために必要な仕組みを ミドルウェアとして提供する。 図 3-1 PC グリッド概要 PC グリッド環境を提供する代表的なミドルウェアは UnitedDevices 社の GridMP や PlatformComputing 社の LSF で提供される PC グリッド機能（ActiveCluster）などがある。またオープンソース・プロジェクとして BOINC （http://boinc.berkeley.edu/）がある。BOINC は SETI@home のグリッドインフラに使用されているオープンソー ス・プロジェクトである。 一般的には PC は Windows システムが多いので、以下のような機能を前提にかんがえておく必要性がある。 ・メモリーと CPU アイドル率、ディスク容量、テンポラリ領域、利用できるソフトウェア、そしてユーザ定義 のリソース制限に基づくワークロードのスケジューリングと配布。 ・実行の最中に起きた問題に対し自動的にジョブのリスケジューリングを行うので、単一障害点の心配 がない。 ・企業のネットワーク構造に適合するよう設計されており、簡単に構成が可能であり、最小限のネットワ ーク通信を保証するために、キャッシング＆ステージング技術を備えている。 ・デスクトップと分散されたデータとアプリケーション双方の機密を保証するために Windows のセキュリ ティ機能を利用する。 7-74 - 74 - PC グリッドは以下のような動きをする。 １．クライアントは、構成されたグリッド環境へジョブを投入する。 ２．グリッド環境では、多数の PC が所属している PC グリッド環境か、または並列計算ジョブなどは計算 サーバ・ホストへ依頼するなどジョブをスケジューリングする。 ３．PC は PC グリッドサーバ（PC グリッドミドルウェアの制御を行っている） へジョブを要求する。 ４．ジョブが PC へ転送され、PC で実行される。 図 3-2 PC グリッドの動き 3.1. グリッドシステムのモデルとの関係 3.1.1. グリッドのプレイヤ 本ケースでは、前節のものと同様に企業のＩＴシステム部門がグリッドシステムの提供者であり、技術者 などが利用者となる。現実には実際の資源を提供するのは、業務用端末や CAD 端末であり、PC やワー クステーションの利用者が提供者と考えることができるが、PC やワークステーションの利用者は自身がグ リッドシステムとして稼働しているという認識がないので、提供者はそのグリッドシステムを管理しているＩＴ システム部門になると設定する。また利用者が他者に提供物として提供するケースは考えない。提供者 と利用者は同一企業に属しているが、企業内の部署は異なるのが一般的である。 提供者 利用者 提供物 提供物 図 3-3 提供者と利用者 7-75 - 75 - 3.1.2. グリッド環境における提供物 本ケースの提供物は、前節と同様に第４層までの環境を提供者が管理し提供している。 具体的な提供物は、技術計算に使用するアプリケーションの実行処理である。利用者による利用の方 法としては、ポータルなどのインタフェースを介する場合もあるが、複数の計算機システムを統合するグリ ッドミドルウェアに実行処理のリクエストを与える。グリッドミドルウェアは受付けたリクエストに基づき、管理 下にある PC/ワークステーションに処理を分配する。 第１層は、解析処理を実行するための PC/ワークステーション・コンピューティング資源が主となるが、 解析処理に必要とする諸データを収めるストレージ資源も必要になる。計算時にはこのデータは実行さ れる各 PC/ワークステーションに分割配布されることになる。 3.1.3. プレイヤの役割と提供物の関係 本ケースの提供物に関係するプレイヤとその役割は、以下のとおりである。 ・ 技術者 企業において解析業務などを提供物としてのアプリケーション実行処理を利用する者。 役割：エンドユーザ、システム使用者 ・ IS 部門 企業において本システムを運用管理する部門。本システムの仕様を策定し、システムインテグレータにシ ステムの構築を依頼する者。本ケースにおける実際の資源は業務ユーザーの使用している PC やワーク ステーションである。 役割：システム運営者 ・ システムインテグレータ IS 部門の仕様に従い、システムの構築を行う者。当該企業とは異なる企業に依頼するのが一般的で ある。 役割：システム構築者 ・ ベンダ グリッドシステムを構成する、サーバ装置、ストレージ装置、ネットワーク装置の他、システムを統合する ためのグリッドミドルウェアやキューイングシステムのソフトウェアを提供するベンダ。PC グリッドでは GridMP や LSF などを提供するベンダになる。 役割：グリッド関連製品ベンダ また、本ケースでは、外部グリッドシステム提供者の役割を果たすプレイヤは存在しないケースが多い。 7-76 - 76 - システム使用者 エンドユーザ （技術者） システム使用 エンドユーザ環境 提供サービスのSLA ポータルシステム 技術計算アプリケーション（構造解析、流体解析など） 管理，セキュリティ、・ ・ ・ システム運営者 （IS部門） 仕様決定 運用管理 システムの要求仕様 システム構築者 （SIer） システム構築 製品仕様 グリッド関連 製品ベンダ （ベンダ） グリッド・システム （アプリケーション実行処理） バッチキューシステム、グリッドミドルウェア 仮想ファイルシステム 各種ファイル システム （ネットワーク含） 各種OS （Windows, Linux, UNIX, etc） Ethernet, IP, TCP, UDP, etc SAN, NAS, etc サーバ，ブレード， etc スイッチ，ルータ， FW機器， VPN装置，etc ストレージ コンピューティング ネットワーク グリッド関連製品提供 図 3-4 提供物とプレイヤの関係 3.1.4. 提供物の状態遷移 本ケースの提供物は、基本的に第４層までのシステムを全て導入、構成・設定、起動して、はじめて利 用者への提供物として運用される。さらにグリッド環境として利用できる資源になるには、PC/ワークステ ーション利用者がその資源を利用せずに、グリッド環境として提供することに同意している時点となる。し かしながら、計算を要求するエンドユーザも資源を提供する PC/ワークステーション利用者はそれを意識 することはない。すべてグリッドミドルウェアおよび管理ノードが制御する。 3.1.5. グリッドシステムの管理 企業という同一組織ではあるが、ＩＴシステム部門は計算機環境を提供することを業務としているため、 利用者に対するＳＬＡを持つ。運用時間、障害が発生した際の復旧など、運用上の制約事項が存在する。 ハードウェアを常時監視し、障害が発生した場合の代替処置など。 また、利用者は通常プロジェクトなどのグループ毎に管理され、グループ毎の課金が実施される。提 供者は、利用者によって利用されたリソース量を把握し、課金情報とする。 7-77 - 77 - 企業内 利用者 利用者 ポータル グリッドミドルウェア 計算機システム１ PCグリッド 管理ノード 計算機システム２ PCグリッド 管理ノード サーバ 演算ノード 演算ノード 演算ノード 演算ノード 演算ノード 演算ノード 演算ノード 演算ノード 図 3-5 提供物の構成例 z z z プロジェクト毎にグリッド環境にプログラムおよびデータが準備され、各計算ノードへ配布される。 恒久的な知識や情報や断続的に実行されるジョブの一時的な実行結果などの保管場所はグリッ ド内の環境に用意されるものとする。この保存ストレージのセキュリティ(機密性,完全性,可用性)は、 運用システム全体としてのグリッドシステムとして保証される必要がある。なお、保存ストレージは、 グリッドシステムの提供者と計算実行責任者で管理権限を分担して管理する事になる。 利用者は自分の所属する組織のジョブ投入ポータルからジョブを実行する。 PC グリッドの多くは非同期投入型ジョブとなる。一般的な利用者はジョブが実際に実行される資 源を知る必要は無い。また、ジョブの実行は、予め定められたポリシによって決定され、実行され る資源が固定されているわけでは無い。 プログラムやデータは、事前にジョブ投入ポータルを介してプロジェクトのデータ保存ストレージ に送られる。また、投入されたジョブは事業部間のスケジューリングシステムで調整され、最適な 実行サイトへ投入され、実行終了後の結果は、データ保存ストレージへ保存され終了通知後に 取出される方式になる。 PC グリッド環境で使用されるアプリケーションのセットは定型的なものである。 ユーザが不特定多数のアプリケーションを実行させるわけでは無い。 サーバはジョブが投入される前にアプリケーションが実行可能に設定されていると想定して良 い。 7-78 - 78 - 3.2. 要件リスト 3.2.1. システム使用者 ■ 提供物の情報 ・ 提供物の情報は使用者システムに開示されること（necessary） ・ システム使用者が利用した提供物の利用量は、システム使用者に開示されること（necessary）また 当該システム使用者以外には参照できないこと（necessary） ・ 提供物の構成情報や性能など、静的な情報はシステム使用者に開示されること（preferable） ■ ・ ・ ・ 提供物の利用 アプリケーションを実行するジョブの投入と結果の取得が可能であること（necessary） アプリケーションを実行するジョブのステータスが確認可能であること（preferable） 複数のシステム使用者間および、システム使用者自身による、優先度付けが可能であること (optional) 3.2.2. システム運営者 ■ システムの管理 ・ 簡便なインタフェースにより、計算リソースとなる各計算機システムの状況をシステム運営者が監視 可能であること（necessary） ・ ユーザが投入したジョブの配布状況、ステータス状況をシステム運営者が確認可能であること （necessary） ・ 計算リソースとなる各計算機システム上にジョブを割り当てる条件をシステム運営者が、設定可能で あること（preferable） ・ アプリケーションプログラムを、計算リソースとなる各計算機システム上への配備手段がシステム運 営者に用意されていること（necessary） ・ グリッド・ジョブが実行される PC/ワークステーションに PC グリッドミドルウェアの導入/保守することが 可能なこと（necessary） ・ PC グリッドミドルウェアの導入/保守が自動的に行われること(optional) ・ グリッドシステムの運営ポリシに沿ったシステム管理権限の委譲と障害時のエスカレーションプロセ スがシステム運営者内で定められていること（necessary） ■ 提供物の情報 ・ システム使用者が利用した提供物の利用量は、システム運営者によって把握されること（necessary） ■ ジョブの管理 ・ システム使用者の投入した各ジョブの状況を、システム運営者が監視可能であること（necessary） ・ 計算リソースとなる計算機システム上で実行中のジョブをシステム運営者が中止可能であること （preferable） ・ 実行されたジョブの統計情報をシステム運営者が獲得可能であること（preferable） ・ 実行に失敗したジョブが自動的に再実行されること（preferable） ・ ジョブ毎の利用量に関する課金情報がシステム運営者によって取得できること（necessary） ・ PC/ワークステーションの資源で活動するグリッドジョブが PC 使用者に対し影響を与えないこと （necessary） ■ セキュリティ 7-79 - 79 - ・ 計算リソース（計算ノード）にジョブを分配するサーバ（管理ノード）上で、ジョブおよびデータが保護 されていること（necessary） ・ サーバ（管理ノード）と計算リソース（計算ノード）間において、データが暗号化され、誰からも内容を 読まれることがないこと（necessary） ・ 組織・サイトをまたがる統一的な ID 管理（認証、認可、属性管理）が行えていること（necessary） ・ 複数の計算機システムに対して、複数回のサインインをすることなくアクセス可能であること （necessary） ■ 障害系 ・ ジョブの投入を受け持つサーバ（管理ノード）が障害により動作しなくなった場合にも、代替サーバ によってジョブの投入が継続できること（preferable） ・ ジョブの実行を受け持つ PC やワークステーションが障害により動作しなくなった場合にも代替の PC やワークステーションによってジョブの実行が継続できること（preferable） ■ ネットワーク ・ 利用者の利用端末と、提供物が提供されるリソース（サーバ）との間のネットワークについて、十分な 帯域とダウンタイムに関する接続性が保証されていること（preferable） ・ 実行されるジョブが大量のデータを必要とする場合、実行時間やデータ配布時間が長くならないよ うな仕組み（キャッシュサーバ等）の設置を考慮する（preferable） 3.2.3. システム構築者 システム運営者の要件を満たすシステムを構築することが、システム構築者に求められる要件であり、 システム構築者に特別な要件は存在しない。 3.2.4. グリッド関連製品ベンダ システム運営者の要件を満たすシステムを構築するためのグリッド関連製品を提供できることがグリッ ド関連製品ベンダに求められる要件であり、グリッド関連製品ベンダに特別な要件は存在しない。 3.2.5. 外部グリッドシステム提供者 本ケースの場合、外部グリッドシステム提供者は存在しないので、本要件も存在しない。 7-80 - 80 - 4. 学術共同グリッド （コンピューティンググリッド） ●概要 複数の大学や研究所が学術利用を目的として、同等な立場で計算機システム（やデータ）を供出し共 有し合うグリッド環境を構築しているケースであり、共同研究などにおいて、大規模高速な解析の実現や、 研究効率の向上が主な目的である。学術共同グリッドとしては、共有するリソースがコンピューティング資 源の場合とデータ資源の場合と分けることができる。しかし、データ資源を共有するケースについては、 来年度の取り組みとする。 学術共同コンピューティンググリッドは、技術計算を実施するリソースを複数の大学や研究所間で共有 し合うケースである。ここでは、産総研が中心にアジア諸地域と連携する取り組みである ApGrid(http://www.apgrid.org/)の事例を参考とした。 図 4-1 学術共同コンピューティンググリッドのシステムモデル ●システムモデルの特徴 学術共同コンピューティンググリッドは、異なる組織に属する研究者があるテーマの研究活動のため の仮想組織（VO）を構成する。研究者個人や一組織のリソースでは利用困難なリソースを求めて複数組 織の資源からなるグリッドを形成する。 図 4-1に学術コンピューティンググリッドのシステムモデルを示す。資源提供者、利用者とも、複数の 共同関係にある組織により構成される。多くは資源の利用と提供の双方を行う組織からなるが、資源提 供のみ、あるいは資源利用のみの組織も存在する。 学術共同コンピューティンググリッドにおける提供物は、第３層の場合と第４層の場合とがあり、また、 双方とも提供する場合もある。利用者自身がアプリケーションプログラムを開発し、構築されたグリッド上 7-81 - 81 - で直接実行する場合は第３層、提供者がアプリケーションポータルサービスを構築し、利用者が計算環 境を意識することなくポータルを介して科学技術計算結果を取得するような場合は第４層と考える。前者 と後者で必要とされる技術的要求が異なるため，ここでも特に第３層を提供するケースについて述べて いく。 4.1. グリッドシステムのモデルとの関係 4.1.1. グリッドのプレイヤ 本ケースでは、複数学術研究機関のＩ S部門(研究者である場合もある)が提供者であり、研究者など科 学技術計算を実施する者が利用者となる。学術共同グリッドでは、利用者が他者に提供物として提供す ることもあるが、ここでは除外する。提供者と利用者は同じ組織あるいは共同関係にある他の組織に属す る。 提供者 利用者 提供物 提供物 図 4-2 提供者と利用者 4.1.2. グリッド環境における提供物 本ケースでは、第３層までの環境を提供者が管理し、提供する。提供物は複数組織の複数提供者に より管理されることもある。 具体的な提供物は、グリッドミドルウェアが配備された科学技術計算アプリケーションプログラムの実行 環境である。実行環境は組織内・組織外の利用者から効率よく利用されるため、通常バッチスケジューラ 等のグリッドミドルウェアで管理されている。利用者は組織内・共同組織内のグリッドミドルウェアのインタ フェースを介して複数の計算機システム上でアプリケーションプログラムを実行する。グリッドミドルウェア は受け付けたリクエストに基づき、管理下にある計算資源等に処理を分配する。実行処理では、利用者 は実行プログラム、入力データを直接あるいはデータステージングシステム等により利用するシステム上 に配備し、実行結果を同様にして取得する。 第１層は主に科学技術計算を実行するために必要となる組織内または共同組織内のコンピューティン グ資源、ストレージ資源、ネットワーク資源からなるが、大型望遠鏡、加速器といった超高精度実験装置 も含まれる場合がある。 4.1.3. プレイヤの役割と提供物の関係 本ケースの提供物に関係するプレイヤとその役割は、以下のとおりである。 ・ 研究者 学術研究機関において、科学的課題を解明することを目的として、主に自身が作成した科学技術計算 プログラムを実行する者。 役割：システム使用者 7-82 - 82 - ・ IS 部門(研究者である場合もある) 学術研究機関において、本システムを運用管理する部門。本システムの仕様を策定し、システムインテ グレータにシステムの構築を依頼する者。本プレイヤは、共同関係にある他の組織の利用者にも本シス テムを提供する。 役割：システム運営者、外部グリッドシステム提供者 ・ システムインテグレータ IS 部門の仕様に従い、システムの構築を行う者。当該機関とは異なる企業等に依頼するのが一般的で ある。 役割：システム構築者 ・ ベンダ グリッドシステムを構成する、サーバ装置、ストレージ装置、ネットワーク装置の他、システムを統合するた めのグリッドミドルウェアやキューイングシステムのソフトウェアを提供するベンダ。 役割：グリッド関連製品ベンダ システム使用者 （研究者） グリッド・システム エンドユーザ環境 提供サービスのSLA システム使用 各種サービス，ポータルシステム ERP/CRMアプリケーション・サービス 仕様決定 運用管理 システムの要求仕様 システム構築者 （システムインテグレータ） 製品仕様 グリッド関連 製品ベンダ （ベンダ） システム構築 提供リソースのSLA 管理，セキュリティ、・ ・ ・ システム運営者 （IS部門） データベース，Webサーバ，アプリケーションサーバ 仮想ファイルシステム，オーバレイネットワーク 各種ファイル システム （ネットワーク含） 各種OS （Windows, Linux, UNIX, etc） Ethernet, IP, TCP, UDP, etc SAN, NAS, etc サーバ，ブレード， etc スイッチ，ルータ， FW機器， VPN装置，etc ストレージ コンピューティング ネットワーク グリッド関連製品提供 図 4-3 提供物とプレイヤの関係 4.1.4. 提供物の状態遷移 システム構築者が、システムのすべてのコンポーネントを導入して第３層までを構築し、稼動可能な状 態とする。システム運営者はシステムを起動して、システム使用者に提供する。 4.1.5. グリッドシステムの管理 学術的な科学技術計算を目的としてボランティアベースで共同関係にある組織内の資源を提供して いるため、運用時間中の障害に対する補償はされない場合が多い。よって、ミドルウェアレベルや利用 7-83 - 83 - 者自身による耐故障性や冗長化への対応が求められる。 資源の公平な利用のため、提供物の利用量に応じて課金または何らかのポイントが課せられることが ある。 4.1.6. グリッドシステムのセキュリティ 提供物は組織内および共同関係にある他の組織の利用者に対して提供されるため、利用者は VO で 認められている CA 局で発行するユーザ証明書を利用しなければならない。また、利用者によって資源 の提供ポリシを変えて運用することもある。 共同関係にある組織間で科学技術計算目的に利用されるため、一般に他の利用者に対してデータを 保護するなどの処置はされていない。しかしながら、競合関係にある利用者が存在する場合もあるため、 必要に応じてデータの保護、組織間を接続するネットワークの保護に対応する。 7-84 - 84 - 4.2. 要件リスト 4.2.1. システム使用者 ■ 提供物の情報 ・ 提供物の情報は使用者システムに開示されること（necessary） ・ システム使用者が利用した提供物の利用量は、システム使用者に開示されること（preferable）また 当該システム使用者以外には参照できないこと（preferable） ・ 提供物の構成情報や性能など、静的な情報はシステム使用者に開示されること（preferable） ・ グループへのデータの閲覧許可の制御か可能であること（preferable） ■ ・ ・ ・ ・ ・ ・ ・ ・ 提供物の利用 アプリケーションを実行するジョブの投入と結果の取得が可能であること（necessary） アプリケーションを実行するジョブのステータスが確認可能であること（necessary） 複数のシステム使用者間および、システム使用者自身による、優先度付けが可能であること (preferable) 異機種コンピュータへの統一的なインタフェースの提供される(necessary) 計算サーバ、データの所在を意識せず利用可能である(optional) リソースが予約可能であること(preferable) ユーザ自身のプログラムが利用可能であること(necessary) 商用アプリが利用可能であること(preferable) ■ セキュリティ ・ シングルサインオンが可能であること（preferable） 4.2.2. システム運営者 ■ システムの管理 ・ 簡便なインタフェースにより、計算リソースとなる各計算機システムの状況をシステム運営者が監視 可能であること（necessary） ・ ユーザが投入したジョブの配布状況、ステータス状況をシステム運営者が確認可能であること （necessary） ・ 計算リソースとなる各計算機システム上にジョブを割り当てる条件をシステム運営者が、設定可能で あること（preferable） ・ 計算サーバの負荷状況に応じて、手動または自動で負荷分散が可能であること（preferable） ・ 商用アプリケーションのライセンス管理と提供（optional） ■ 提供物の情報 ・ システム使用者が利用した提供物の利用量は、システム運営者によって把握されること （preferable）、 ■ ジョブの管理 ・ システム使用者の投入した各ジョブの状況を、システム運営者が監視可能であること（preferable） ・ 計算リソースとなる計算機システム上で実行中のジョブをシステム運営者が中止可能であること （necessary） ・ 実行されたジョブの統計情報をシステム運営者が獲得可能であること（preferable） ・ 実行に失敗したジョブが自動的に再実行されること（optional） 7-85 - 85 - ・ ジョブ毎の利用量に関する課金情報がシステム運営者によって取得できること（optional） ■ セキュリティ ・ 計算リソース（計算ノード）にジョブを分配するサーバ（管理ノード）上で、ジョブおよびデータが保護 されていること（necessary） ・ サーバ（管理ノード）と計算リソース（計算ノード）間において、データが暗号化され、誰からも内容を 読まれることがないこと（preferable） ・ 統一的な ID 管理（認証、認可、属性管理）が行えていること（necessary） ・ 複数の計算機システムに対して、複数回のサインインをすることなくアクセス可能であること （preferable） ・ 運用ポリシを定めた CA 局で発行されたユーザ証明書の利用（necessary） ・ VO 管理サーバにより、VO ごとのユーザ、ジョブ、ポリシが管理可能であること（preferable） ■ 障害系 ・ ジョブの投入を受け持つサーバ（管理ノード）が障害により動作しなくなった場合にも、代替サーバ によってジョブの投入が継続できること（optional） ・ VO 管理サーバが障害により動作しなくなった場合にも、代替サーバによってジョブの投入が継続 できること（preferable） ・ データのバックアップおよび障害復旧が行えること(通常の計算資源上のデータは optional，利用者 の個人データや観測データ等は necessary) ■ ネットワーク ・ 利用者の利用端末と、提供物が提供されるリソース（サーバ）との間のネットワークについて、十分な 帯域とダウンタイムに関する接続性が保証されていること（optional） 4.2.3. システム構築者 システム運営者の要件を満たすシステムを構築することが、システム構築者に求められる要件であり、 システム構築者に特別な要件は存在しない。 4.2.4. グリッド関連製品ベンダ システム運営者の要件を満たすシステムを構築するためのグリッド関連製品を提供できることがグリッ ド関連製品ベンダに求められる要件であり、グリッド関連製品ベンダに特別な要件は存在しない。 4.2.5. 外部グリッドシステム提供者 本ケースの場合、外部グリッドシステム提供者＝システム運営者であるため、ここで特別な要件は存在 しない。 7-86 - 86 - 5. ビジネス・コンピューティング・グリッド （業務システムに対するサーバリソース提供） ●概要 ビジネス・コンピューティング・グリッドは、企業などが運用する業務システムに対するグリッド技術の応 用例の一つで、業務システムを運用する際に必要となるリソースをリソースプールから動的に確保し、業 務システムへ割り当てることにより、業務システムの運用・管理を効率化することを目的としている。 ●提供者、利用者、提供物の関係 商用データセンタでは、商用データセンタ事業者(提供者)が顧客(利用者)に対して、サーバをはじめ とする各種リソースを貸し出し、顧客の業務システムをホストすることにより収益を得る（商用データセンタ によるホスティングサービス）。この場合の提供物は商用データセンタ事業者が所有するサーバリソース などである。グリッド技術を適用することにより、商用データセンタはリソースプールの稼働率向上、TCO 削減が期待でき、ひいては顧客企業に対して低廉なサービスを提供することが可能となる。また、分散し た複数のデータセンタを連携させ互いにリソースを融通することにより、複数データセンタにまたがる負 荷分散やディザスタリカバリなども実現でき、顧客に対してさらなる付加価値を提供できる。 一方、企業内データセンタでは、企業内の情報サービス部門(提供者)がデータセンタを運用し、同一 企業内の業務システム運用部門(利用者)に対し各種リソースを提供し、利用者の業務システムをホスト する。この場合の提供物は利用部門と同一の企業が所有するサーバリソースなどである。グリッド技術を 適用することにより、企業内業務システム全体として保有リソースの稼働率を向上させ、TCO の削減が実 現できる。また、企業内データセンタであっても、分散した複数データセンタを連携させることにより、複 数データセンタにまたがる負荷分散やディザスタリカバリなども実現できる。なお、商用データセンタが提 供するハウジングサービスやコロケーションサービスを用いて自社リソースを外部データセンタで運用す る場合も企業内データセンタのケースに分類できる。これはリソース(提供物)の提供者と利用者が同一 企業体に属すからである。 ●ビジネス・コンピューティング・グリッド(業務システムに対するサーバリソース提供)の例 ビジネス・コンピューティング・グリッドの典型例として次のような例を考察する。 商用データセンタは数千台のサーバ計算機を運用しており、数百台から千台単位のサーバを各管理 者、あるいは、管理者グループが管理する。 商用データセンタは提供者と利用者間の事前の契約に基づき商用データセンタのリソースに利用者 の業務システムをホストする。この契約では提供者が利用者に提供するサービスのサービスレベルやそ のサービスに対する支払条件など、両者が履行すべき義務が定められている。商用データセンタにホス トされている利用者の業務システムは、典型的には「図 5-1」に示すような、いわゆる Web3 階層型のア プリケーションシステムなどが想定される。利用者はこのような業務システムの運用をビジネス・コンピュ ーティング・グリッドに予約する。ビジネス・コンピューティング・グリッドはその予約に基づき、管理するサ ーバや各種ネットワーク機器を利用者の業務システムに割り当てる。ビジネス・コンピューティング・グリッ ドは利用者と提供者の契約の中で合意したサービスレベルを満たすために、利用者のアプリケーション システムの負荷変動などに応じて適宜「Web サーバ」、「AP サーバ」等に対するサーバ割り当て数を増 減させる。 7-87 - 87 - 図 5-1 ビジネス・コンピューティング・グリッドにホストされる業務システム例 ●サーバリソース提供の概要 ここではビジネス・コンピューティング・グリッドの事例として、平成 15 年度から 17 年度にかけて実施さ れたビジネスグリッドコンピューティングプロジェクトでの実証実験を紹介する。このプロジェクトではビジ ネス・コンピューティング・グリッドの実現を目指し、ビジネスグリッドミドルウェアと呼ばれるミドルウェアを 研究開発した。そして、その研究開発の一環として、ビジネスグリッドミドルウェアの適用性を実証するた めに、2 社のユーザ企業と共同で、ユーザ企業の企業内業務システムを対象にディザスタリカバリ、及び、 複数データセンタでの負荷分散を想定した実験を行った。ここではビジネスコンピューティングプロジェ クトにおける実証実験『ビジネスグリッドの実証実験』から、グローバルにビジネス展開する国内自動車メ ーカ、マツダ(株)での実証実験事例について紹介する。 ビジネスグリッドコンピューティングプロジェクトにおける実証実験の目的は、ビジネスグリッドミドルウェ アによって、以下の項目を実証することにあった。 • 業務システムへの投資コスト・運用管理コストを抑えつつ、業務システムを複数サイトへ配置し、災 害発生時の業務継続性を高めること • 平常時にディザスタリカバリ用のリソースを有効活用すること • 複数サイトにまたがる業務システムの運用を効率化すること • 各データセンタにおいて、負荷変動、サーバ障害に自律的に対応すること • 負荷変動に応じた自律的なサーバの拡張/縮退、障害時の自律的な復旧によりサービスレベル(レ スポンスタイム、業務継続時間)を維持すること これらの項目を実証するため、ビジネスグリッドコンピューティングプロジェクトではユーザ企業の協力 の元、「図 5-2」にあげるような業務システムを構築した。まず、この実証実験の業務システムについて説 明する。 7-88 - 88 - 図 5-2 ビジネスコンピューティングプロジェクト実証実験の業務システム構成 「平常時」のシステム構成を参照すると、本ユーザ企業の業務システムは 2 つのデータセンタ DC#1 と DC#2 で運用されている。このうち、業務システム A は両データセンタで分散運用されており、Web アプリ ケーションサーバとデータベースから構成されている。これらのデータベースにはそれぞれ地理的に分 散した異なるエンドユーザのデータが格納されている。そして、それらのデータは互いに他データセンタ のデータベースにリプリケーションされている。業務システム B、業務システム C も Web アプリケーション サーバとデータベースから構成されており、それらの業務システムはそれぞれ片方のデータセンタで運 用されている。これらの業務システムのデータのリプリケーションをそれぞれ他データセンタのデータベ ースに行っている。それぞれのデータセンタにはサーバリソースのプールが存在し、業務システムの負 荷に応じて自動的にリソースの割り当てが行われる。リソースプール中のリソースが枯渇した場合は、業 務優先度に従い、低優先度の業務から高優先度の業務へリソース割り当ての変更が自動的に行われる。 本実証実験では業務 A がもっとも優先度の高い業務となっている。また、業務システムによってはサー バリソースに必要となる OS、ミドルウェアが他の業務システムと異なっているものもある。 次に、本実証実験の評価シナリオについて説明する。実証実験では 8 つの「評価シナリオ」を作成し、 ビジネスグリッドミドルウェアの検証を行った。ここではそのうちのひとつの、複数データセンタにまたがり 配置されている業務システムのディザスタリカバリのシナリオについて説明する。 このディザスタリカバリのシナリオでは 3 つの業務がそれぞれのデータセンタのリソースをすべて利用 しリソースプール中に空きリソースがなく、また、災害復旧用の専用待機リソースも持たないことを前提と した。この前提の下で、DC#1 のデータセンタが被災しディザスタリカバリを行うというシナリオを設定した。 このシナリオでは災害発生時には各業務の優先度に従い業務を縮退し、片側のデータセンタで全業務 を運用することが必要である。 このシナリオの評価の結果、ビジネスグリッドコンピューティングプロジェクトでは、ディザスタリカバリ判 定、ディザスタリカバリの発動の操作により、2 つのデータセンタにまたがる業務システム A においては DC#2 のみでの縮退運転を行うことで業務を復旧できること、及び、業務システム B においては、DC#2 の業務システム C を縮退運転させることにより手当てしたリソースを業務システム B に割り当てることによ り、業務が再開できたことを確認した。また、その際に事前に設定されていた性能目標値(Recovery Time Objective(RTO): 4H) を上回る結果(業務システム A においては RTO: 39 分 25 秒、業務システム B に おいては RTO: 87 分 32 秒)を実現できた。これにより、ビジネスグリッドミドルウェアが従来の災害対策方 式と比較し、迅速な災害復旧を実現できることを実証し、業務継続性の向上に対する手段として適用で 7-89 - 89 - きる可能性を示した。 5.1. グリッドシステムのモデルとの関係 ここでは、上述の実証実験の例をもとに本委員会で検討しているグリッドシステムのモデルとの関係に ついて考察する。考察に当たって次のようにうグリッドシステムに関わるプレイヤを定める。 DC#1 は顧客企業により運営されている企業内データセンタである。DC#2 は顧客企業に対してホステ ィングサービスを提供するデータセンタ事業者が運営するデータセンタとする。ここでデータセンタ事業 者は顧客企業に対して提供物としてサーバリソースなどを提供する。顧客企業は顧客製品の販売会社 (以下販売会社)に対して販売管理システムを提供する。顧客企業はこの販売管理システムと複数の社 内業務システムをビジネス・コンピューティング・グリッドにより自社の企業内データセンタ、及び、データ センタ事業者のデータセンタのサーバリソースなどを用いて運用する。ここで、販売管理システムは社内 業務システムより業務優先度が高く設定されている業務システムである。 5.1.1. グリッドのプレイヤ DC#1 は顧客企業により運営されている企業内データセンタである。DC#2 は顧客企業に対してホステ ィングサービスを提供するデータセンタ事業者が運営するデータセンタである。図 5-3に示すように、デ ータセンタ事業者は顧客企業に対して提供物としてサーバリソースなどを提供する。顧客企業は、サー バや OS、ミドルウェアに加えて業務アプリケーションを導入して社内ユーザや販社会社に対して提供物 として業務システム（販売管理システムおよび社内業務システム）を提供する。 - 販売会社: 販売管理システムのシステム使用者(エンドユーザ) 顧客企業： 販売管理システム、社内業務システムのシステム運営者。顧客企業の企業内データ センタのシステム運営者でもある データセンタ事業者: データセンタ事業者のデータセンタのシステム運営者 データセンタ事業者 提供者 提供物 顧客企業 利用者 販社会社 提供者 提供物 提供物 （サーバリソース等） 利用者 提供物 （販売管理 システム） 提供物 （社内業務 システム） 利用者 提供物 図 5-3 提供者と利用者 5.1.2. グリッド環境における提供物 グリッド環境における提供物について考察する。販売管理システム、社内業務システムに割り当てられ るリソースはサーバリソースとデータベースサーバである。これらリソースの提供形態は、サーバハードウ ェアのみを提供する場合から、サーバハードウェアと OS を提供する形態、さらに、アプリケーションサー バやデータベース管理製品などハードウェアからミドルウェアまでを含む形態が存在する。したがってビ ジネス・コンピューティング・グリッドでの提供物は第 1 層から第 3 層にわたることがわかる。 7-90 - 90 - 図 5-4に示すように、データセンタ事業者は第１層から第３層に渡る部分を顧客企業に提供する。顧 客企業はこれら提供物に対して第２層から第４層に渡るソフトウェアなどを付け加え、第４層をエンドユー ザである販社会社に提供する。 グリッド・システム エンドユーザ環境 管理，セキュリティ、・・ ・ 業務 業務 業務 ミドルウェア ミドルウェア ミドルウェア OS 各種OS （Windows, Linux, UNIX, etc） Ethernet, IP, TCP, UDP, etc サーバ，ブレード， etc スイッチ，ルータ， FW機器， VPN装置，etc SAN, NAS, etc サーバ ストレージ OS サーバ OS コンピューティング サーバ 顧客企業が運営し、 社内ユーザや販社 会社に提供する提 供物（業務アプリ） データセンタ事業 者が運営し 顧客企業に提供す る提供物（サーバ などのリソース） ネットワーク 図 5-4 ビジネス・コンピューティング・グリッドの提供物 5.1.3. プレイヤの役割と提供物の関係 本ケースの提供物に関係するプレイヤとその役割は、以下のとおりである。 ・ 販売会社 役割： エンドユーザ ・ エンドユーザである販売会社は、業務システムＡ（販売管理システム）を使用する ・ 顧客企業 役割：システム使用者、エンドユーザ ・ システム使用者である顧客企業は、データセンタ事業者が提供する提供物にサーバリソースを追 加して、販売会社向けの販売管理システムを運営したり、顧客企業自身に対して社内業務システ ムを運営したりする。ここで、サーバリソースは、ハードウェアのみの場合、ＯＳを含む場合、さらに ミドルウェアを含む場合がある。 ・ データセンタ事業者 役割： システム運営者 ・ システム運営者であるデータセンタ事業者は、システム使用者である顧客企業に対してサーバリ ソースを提供する。ここで、サーバリソースは、ハードウェアのみの場合、ＯＳを含む場合、さらにミ ドルウェアを含む場合がある。 図 5-5は、プレイヤと提供物の関係を図示したものである。本実証実験では、システム運営者からの 7-91 - 91 - 提供物は１層から３層にわたり異なる場合がある。システム使用者はそれに応じ、業務アプリケーションを 構成するソフトウェアをプロビジョニングする必要がある。 販社会社 （エンドユーザ） 業務アプリ グリッド・システム エンドユーザ環境 業務 業務 管理，セキュリティ、・ ・ ・ ミドルウェア ミドルウェア OS 各種OS （Windows, Linux, UNIX, etc） Ethernet, IP, TCP, UDP, etc サーバ，ブレード， etc スイッチ，ルータ， FW機器， VPN装置，etc SAN, NAS, etc サーバ ストレージ 顧客企業 （システム使用者） （エンドユーザ） 業務 OS サーバ コンピューティング ミドルウェア システム 使用 OS サーバ 運用管理 データセンタ事業者 （システム運営者） ネットワーク 提供物 図 5-5 ビジネス・コンピューティング・グリッドの提供物とプレイヤの関係 5.1.4. 提供物の状態遷移 ビジネス・コンピューティング・グリッドでは、システム運営者から提供される提供物に対して、システム 使用者がプロビジョニング(業務アプリケーションの導入・構成・設定)を行い、提供物を起動することで、 業務システムが使用可能となる。この際、提供されるリソースのレイヤによっては、OS やミドルウェアなど の業務システムを構成するソフトウェアコンポーネントを必要に応じてプロビジョニングする必要がある。 これらのプロビジョニング処理はシステム使用者の指示によりビジネス・コンピューティング・グリッドの 管理ミドルウェアが自動的に行われる。 5.1.5. グリッドシステムの管理 ビジネスグリッドミドルウェアでは、システム運営者をインフラ管理者、そのシステム使用者を業務管理 者と呼び、グリッドシステムの管理について規定している。システム運営者はシステム使用者と事前の契 約を取り交わし、提供物が満たすべきサービスレベルについて事前合意を行う。システム運営者はその サービスレベルを満たすよう、ビジネス・コンピューティング・グリッドの管理ミドルウェアに対してリソース 割り当てなどについてのポリシを設定し、ＳＬＡに基づく自律管理を行わせる。ビジネス・コンピューティン グ・グリッドの管理ミドルウェアは課金情報などのリソース使用量の情報を収集し管理する。 システム使用者はシステム使用者に許された範囲で業務システムの実行を予約し、提供物の割り当て を受ける。また、割り当てられた提供物に対して業務システムのプロビジョニングと起動などの制御を行う。 7-92 - 92 - また、業務システムが不要になれば、提供物の解体を行い、割り当てられた提供物を解放する。システ ム使用者はシステム使用者に許される範囲で複数の業務システムに対して優先度を設定できる。この優 先度はビジネス・コンピューティング・グリッドでのリソース割り当ての自律管理で参照され、優先度の高 い業務システムに対して優先的にリソース割り当てが行われる。システム使用者はシステム使用者のリソ ース使用量に応じて契約に定められた費用をリソース使用の対価として支払う。 5.1.6. グリッドシステムのセキュリティ ビジネス・コンピューティング・グリッドでは、提供物にプロビジョニングされる顧客企業の業務システム は他の顧客企業の業務システムと隔離され管理される。また、データセンタ内の業務系通信においても 他の顧客企業の業務系通信から隔離される。これにより複数の顧客企業間の業務システムの干渉を防 ぐ。 提供物のプロビジョニング時には安全に顧客業務システムのソフトウェアとデータが提供物にプロビジ ョニングされ、提供物の解体時には提供物上の顧客業務システムのソフトウェアとデータは、安全に退避 させた上で削除される。 ビジネス・コンピューティング・グリッドの管理ミドルウェアではシステム使用者、システム運営者の認証 と認可を行い、システム使用者、システム運営者が許可されない対象物(提供物、顧客企業の業務シス テム)に対する許可されない操作を防ぐ仕組みとなっている。 7-93 - 93 - 5.2. 要件リスト 5.2.1. システム使用者 ■ 提供物の情報 ・ 提供物の情報はシステム使用者に開示されること（necessary） ・ システム使用者が利用した提供物の利用量は、システム使用者に開示されること（necessary）また 当該システム使用者以外には参照できないこと（necessary） ・ 提供物の構成情報や性能など、静的な情報はシステム使用者に開示されること（necessary） ■ ・ ・ ・ ・ 提供物の利用 提供物への統一的なインタフェースが提供されること(necessary) 提供物の所在を意識せず利用可能であること(necessary) システム使用者の業務の実行状態が確認可能であること（necessary） システム使用者自身による複数業務の優先度付けが可能であること(necessary) 5.2.2. システム運営者 ■ システムの管理 ・ 簡便なインタフェースにより、計算リソースとなる各計算機システムの状況をシステム運営者が監視 可能であること（necessary） ・ 提供物への操作が統一的なインタフェースで実施可能であること(necessary) ・ システム使用者による提供物の使用条件や性能保証をシステム運営者が、設定可能であること （necessary） ・ 障害などにより業務が停止しないこと (necessary) ・ 提供物の負荷状況に応じて、負荷分散が可能であること(necessary) ・ 商用アプリケーションのライセンス管理と提供が行えること(preferable) ■ 提供物の情報 ・ システム使用者が利用した提供物の利用量は、システム運営者によって把握されること（necessary） ■ 業務の管理 ・ システム使用者が実行する業務の配布状況、ステータス状況をシステム運営者が確認可能であるこ と（necessary） ・ システム使用者の業務をシステム運営者が起動・停止など制御可能であること（necessary） ・ 実行された業務の統計情報をシステム運営者が獲得可能であること（necessary） ・ システム使用者による業務実行などによる課金情報がシステム運営者によって取得できること （necessary） ・ 同一サーバを共有する業務が互いに影響を与えないこと(necessary) ・ 複数システム使用者の業務の優先度付けが可能であること(necessary) ■ セキュリティ ・ グリッドシステムにおいてシステム使用者の業務プログラムとデータが他のシステム使用者から保護 保護されていること（necessary） ・ 統一的な ID 管理（認証、認可、属性管理）が行えていること（preferable） ・ 複数の提供物や管理システムなどに対して、複数回のサインインをすることなくアクセス可能である こと（preferable） 7-94 - 94 - ■ 障害系 ・ グリッドシステムの管理システムが障害により動作しなくなった場合にも、代替サーバによって管理 システムがバックアップされ業務の管理が継続できること（necessary） ・ 提供物が障害により動作しなくなった場合にも代替の提供物によりシステム使用者の業務の実行が 継続できること（necessary） ■ ネットワーク ・ システム使用者の端末と、提供物との間のネットワークについて、十分な帯域とダウンタイムに関す る接続性が保証されていること（preferable） ・ エンドユーザと提供物との間のネットワークについて、十分な帯域が保証されていること(necessary) 5.2.3. システム構築者 システム運営者の要件を満たすシステムを構築することが、システム構築者に求められる要件であり、 システム構築者に特別な要件は存在しない。 5.2.4. グリッド関連製品ベンダ システム運営者の要件を満たすシステムを構築するためのグリッド関連製品を提供できることがグリッ ド関連製品ベンダに求められる要件であり、グリッド関連製品ベンダに特別な要件は存在しない。 5.2.5. 外部グリッドシステム提供者 本ケースの場合、外部グリッドシステム提供者＝システム運営者であるため、ここで特別な要件は存在 しない。 7-95 - 95 - 6. ストレージ基盤サービス（ストレージグリッド） ●概要 現在、企業のコンピュータシステムでは、コンプライアンスやセキュリティ監査の為のフォレンジックや データウェアハウスを構築するために大容量のデータ保管が必要に成ってきているが、企業内だけで、 そのデータを保管するために必要な要件(容量，性能など)をみたすストレージをタイムリに提供すること が段々と困難になってきている。また、BC(Business Continuity)を考慮した災害復旧対策の一環として、 データの安全性を保ち、早急な復旧を実現するために、オンラインでアクセス可能な遠隔地のストレージ にバックアップを置く必要がでてきている。 そこで、外部の商用 DC が準備しているストレージプールを利用してシステムを構築する要求が増え、 そのためのストレージを提供するようなサービスも提案され始めている。 ストレージ基盤サービスは、このような要求に答えるために、商用 DC 内のストレージをプールして、シ ステム使用者の要求に従いオンデマンドにストレージサービスを提供するデータグリッド技術の適用例 の一つである。 なお、商用 DC がデータの保管場所としてストレージシステムを外部に提供するサービスには、外部エ ンドユーザに向けて、Web 上で公開されるデスクトップ環境として提供されるものやシステム運営者に対 してシステムを構成するコンポーネントの一部としてストレージやファイルシステムとしてデータアクセスと 制御用のインタフェースを提供するものなど、色々なサービスの形態が考えられる。ここで記述するストレ ージ基盤サービスは、後者のサービスを提供するシステムの一つである FRT のストレージサービスを参 考にして、一般化した適用例を考え、そのモデルと要件を考察している。 エンドユーザ エンドユーザ インターネット インターネット 業務システム１ エンドユーザアクセスI/F 業務システム運営者 NFS CIFS iSCSI NFS CIFS iSCSI ストレージプール （A）ストレージ基盤サービス ストレージプール （B）ストレージサービス 図 6-1 ストレージ基盤サービスとストレージサービス 6.1. グリッドシステムのモデルとの関係 ここでは、4.1.2 グリッドシステムのモデルに従い、ストレージ基盤サービスのモデルを記述する。 7-96 - 96 - 6.1.1. グリッドのプレイヤ 本ケースでは、ストレージ基盤サービスを提供する商用 DC とストレージ基盤サービスが提供するスト レージを使用して企業の業務システムを運営する IT システム部門（IS 部門）、その業務システムを利用 するエンドユーザの３種類のプレイヤが存在する。 商用 DC は、純粋な提供者であるのに対し、IS 部門は、ストレージ基盤サービスの利用者の側面とエ ンドユーザに業務システムを提供する提供者の側面を持つ。 商用 DC IT システム部門 提供者 利用者 提供物 エンドユーザ 利用者 提供者 提供物 提供物 提供物 図 6-2 利用者と提供者 6.1.2. グリッド環境における提供物 本ケースの提供物は、第２層までの環境を提供者である商用 DC が管理し提供している。 ストレージ基盤サービス 利用者 ストレージ基盤サービス 提供者 第4層 第3層 NFS サービス 第2層 NFS Ｉ／Ｆ iSCSI Ｉ／Ｆ 第1層 ネットワーク コンピューティング ストレージ ネットワーク コンピューティング ストレージ 第４層 : DBMS クライアントツール, 各種UI(GFarm), 各種 shell, 各種ブラウザ 第３層: 各種DBMS, GFarm, Web サーバ, etc... 第２層: ufs, ext2, NTFS, NFS, CIFS OS kernel の一部として提供 第１層: iSCSI 図 6-3 ストレージ基盤サービスの提供物 具体的な提供物は、第３層以上のシステムを構築するのに必要な要件を満たすストレージと、そのア クセス方法、及び、ストレージを管理するために必要な制御用の IF である。 ストレージ基盤サービスでは、第２層までしか提供しないため、エンドユーザがデータを保管する場所 として利用するための第３層以上のシステムが存在することが前提になっているが、そのシステムは、本 ケースの範疇に入っていない。すなわち、本ケースにおける提供物は、図 6-3の右側部分である。 7-97 - 97 - 6.1.3. プレイヤの役割と提供物の関係 本ケースの提供物に関係するプレイヤとその役割は、以下のとおりである。 ・ 業務システム利用者 企業において、業務システムを使用してビジネス業務のジョブ(アプリケーション)を実行する者。 一般的に業務システムの構成等は隠蔽されているためにグリッド技術が使用されていることを意識して いない。 役割：エンドユーザ ・ 業務システム提供者（IS 部門） エンドユーザが使用する業務システムを企画し運用管理する部門。 業務システムが使用するストレージの利用形態を決定しストレージ基盤サービスのシステム運営者に利 用を依頼する者。 ストレージ基盤サービスがグリッドシステムであることを意識して企業の業務システムを構築するが、エン ドユーザに対しては、システムの具体的な構成等は隠蔽している。 役割：システム使用者 ・ ストレージ基盤サービス提供者（商用 DC） 商用 DC でストレージ基盤サービスのシステムを運営する者。 ストレージ基盤サービスの仕様を企画・決定し、システムインテグレータに構築を依頼し業務システム提 供者にストレージ基盤サービスを提供するために運営・管理を行う。 役割：システム運営者 ・ システムインテグレータ 商用 DC から依頼を受けてストレージ基盤サービスのシステムを構築するもの。商用 DC の内部に構築 部門を持つ場合と外部の企業に依頼する場合がある。 役割：システム構築者 ・ グリッド関連製品ベンダ ストレージ基盤サービスで使用するグリッド製品を提供するベンダ。 ストレージ基盤サービスでは、単純なストレージ機能を提供するわけでは無いので、ストレージを仮想化 するためのシステムやアクセスするためのネットワーク、管理用のサーバやソフトウェアなど各種製品が 利用されるので、その製品を提供するベンダが必要になる。 役割：グリッド関連製品ベンダ プレイヤの役割と提供物の関係を図 6-4に示す。 7-98 - 98 - 業務システム提供 業務システム 利用者 （エンドユーザ） ストレージ基盤サービス 業務システム運営 インテグレータ （システム構築者） 業務システム提供者 （システム使用者） ストレージ 基盤サービス 構築 NFS Ｉ／Ｆ iSCSI Ｉ／Ｆ ネットワーク ストレージ基盤サービス提供 コンピューティング ストレージ基盤 サービス提供者 （システム運営者) グリッド関連 製品提供 ストレージ グリッド関連 製品ベンダ （グリッド関連 製品ベンダ） ストレージ基盤 サービス運営 図 6-4 プレイヤの役割と提供物の関係 6.2. 要件リスト 本ケースにおいては、要件の項目を抽出したが、各項目の要請の度合いについては評価を行っていない。 6.2.1. システム使用者 ■ 提供物の情報 ・ ストレージの情報（オブジェクトタイプ，容量，性能，可用性，…）が統一されたプロトコルで提供され ている。 ・ システム使用者が使用しているストレージ領域の利用状況の情報（残容量，使用率，バックアップ， …）が開示されている。 ・ システム使用者に対して、ストレージ基盤が契約通りに提供されているか監査可能な情報が提示さ れる。 ■ 提供物の利用 ・ ストレージ基盤サービスで使用しているストレージの領域を統一的に制御する手段がある。 ・ ストレージに複数アクセス方法（iSCSI，NFS，CIFS，…）が準備されシステム使用者が自由に選択可 能である。 ・ 物理的なストレージの所在は隠蔽されていて、システム使用者は意識しないで使用できる。 ・ システム使用者が使用しているストレージ領域の容量、タイプ、性能、可用性等の仕様を利用者が ストレージ基盤サービスの利用開始後に妥当な変更を依頼することが可能である。 ・ 提供されたストレージ領域のアクセス権などシステム使用者が業務システムを構築するのに必要な 管理項目が、システム使用者の環境に合わせてシステム使用者の権限で設定可能である。 7-99 - 99 - 6.2.2. システム運営者 ■ ・ ・ ・ ・ システムの管理 システム使用者と独立してストレージ基盤サービス全体の管理が行われる。 部分的なストレージの設定変更や増設・廃棄が全体のシステムを停止することなく行うことができる。 ストレージ基盤サービスのシステムを部分的に稼動や停止することが可能である。 システム使用者に意識させること無くストレージのハードウェアを移行可能である。 ■ 提供物の情報 ・ ストレージ基盤サービスのシステム構成は、常に最新の状態に構成され、システム運用者が容易 にアクセスできる。 ・ ストレージ基盤サービス全体の性能情報やセキュリティ情報などが統一的なインタフェースで管理さ れている。 ・ システム使用者の利用状況など課金に必要な情報がセキュリティに抵触しない方法で収集されて いる。 ・ システム使用者へのストレージ領域の割当て状況が把握できる。 ■ ・ ・ ・ セキュリティ ストレージ基盤サービスのシステム運用者にもストレージに記録されている情報が漏洩しない。 ストレージ基盤サービスのシステム使用者間でストレージ上の情報への機密が保たれている。 ストレージ基盤サービスに格納した情報の完全性は、システム運用者が保護可能な範囲で保たれ ている。 ・ ストレージへのアクセスが暗号化されている。 ■ 障害系 ・ 部分的なストレージ基盤サービスの障害が全体に普及しない。 ・ システム使用者ごとにストレージのバックアップが取られていて部分的なシステムの障害に対応が 可能である。 ・ システム使用者の使用方法に関係せずストレージのバックアップが可能である。 ■ ネットワーク ・ ストレージ基盤サービスを構成する専用のネットワークが存在し、ストレージアクセスの QOS が保証 されている。 6.2.3. システム構築者 システム運営者の要件を満たすシステムを構築することが、システム構築者に求められる要件であり、 システム構築者に特別な要件は存在しない。 6.2.4. グリッド関連製品ベンダ システム運営者の要件を満たすシステムを構築するためのグリッド関連製品を提供できることがグリッ ド関連製品ベンダに求められる要件であり、グリッド関連製品ベンダに特別な要件は存在しない。 6.2.5. 外部グリッドシステム提供者 本ケースでは、外部グリッドシステム提供者の要件の考察は行わない。 7-100 - 100 - 付録Ｃ グリッドガイドラインの用語集 ここでは、今年度作成しているグリッドガイドラインに登場する用語についての定義を記述する。一般的な用 語もあるが、あくまで今回作成しているグリッドガイドラインで用いている用語の説明である。 ID 管理 システムの利用者の識別子と認証情報、その利用者が許可されている権限に関する情報、さらに、属性情報(利用 者の個人情報を含む場合もある)などを管理すること(認証、権限、属性管理)。「VO 管理」とほぼ同じ意味。単に、 システムの利用者の識別子と認証情報を管理することを指す場合もある。 OE／動作環境 第 1 層の物理コンポーネントをソフトウェアによって外部から制御・利用可能としたもので、抽象化してリソースとして 提供し、サービスまたはアプリケーションのようなグリッド・コンポーネントがそれを利用できるようにしたものである。 具体的には、ストレージとして提供される各種（ネットワーク含）ファイルシステム、Windows や Linux といった各種 OS、IP や TCP、UDP というより論理化されたネットワークリソースが含まれる。 PC グリッド PC に特化した基盤で構築されたグリッドコンピューティングのことをさす。デスクトップグリッドとも呼ばれる。 SLA, SLO 「利用者」と「提供者」の間には、「利用目的」から派生する、利用許諾とそれに対する対価からなる何らかの契約関 係が想定される。この契約関係は SLA（サービスレベルアグリーメント）として記述され、サービスレベルと課金の概 念が生まれる。SLA は、提供者と提供物の階層で実現するためにそれぞれのレベルの SLO（サービスレベル目 標）に展開されるのが一般的であり、SLO は、グリッド環境の提供物ごとに SLA を満たすために導き出される条件 である。 VO (Virtual Organization) グリッドの資源を共有し、共同作業を行うための仮想的な組織。 アプリケーション エンドユーザにサービスを提供し、エンドユーザにはその利用環境がグリッドシステムであることを意識させないグ リッド・コンポーネントを指す。また、ビジネス・プロセスはエンドユーザに提供されるサービスであり、第３層のプラッ トフォーム層のグリッド・コンポーネントの集合体として実現されビジネスや科学技術計算機能を実行する。ポータ ルシステムや ERP アプリケーションをイメージすると理解しやすい。 エンドユーザ グリッドシステムの第４層の使用者であり、他の者に提供することがないエンドポイントに位置する人（組織）。 （注）グリッドシステムの第４層の提供物は、グリッドシステムであることが使用者に隠蔽されているため、エンドユーザ はグリッドを意識することはない。エンドポイントを持っていても、第３層など下位のレイヤも使用している場合は、グ リッドを意識して使用することがある。この場合は、システム使用者とエンドユーザの役割を有している。 エンドユーザは、グリッドシステムを意識していないため、本委員会で作成するガイドブックの読者としては想定されて いない。 外部グリッドシステム提供者 システム運営者が提供するグリッドシステムの一部を構成する外部のシステムを提供する人(組織)。 管理 本ガイドラインでは、グリッドシステムを構成する個別のグリッド・コンポーネントが適切に動作することを前提にし、 グリッドシステムの持つ地理的分散性、グリッド・コンポーネントのヘテロジェニアス性、グリッドシステムの提供する 7-101 - 101 - 提供物、サービスのダイナミックに変化する性質に対して、グリッドシステムの提供する提供物、サービスが、SLA やポリシの要件を満たすように動作させることである。具体的には、「グリッド管理エンティティ」のような概念による、 グリッドシステムの提供する提供物、サービスのレベルでの管理が必要となる。 クラスタ 分散コンピューティングのアーキテクチャの 1 つ。ネットワークで接続されたコンピュータの集合体。クラスタには、計 算負荷を分散してシステム全体の計算能力を高めるハイ・パフォーマンス・クラスタや、一部のコンピュータが停止 しても全体のシステムダウンを回避する HA（High Availability）クラスタなどの分類がある。クラスタシステム構築用 のソフトウェアが計算機ベンダやソフトウェアベンダから提供されている。高度なクラスタシステムの実現には各ベン ダ固有の機能が使われることが多いため、全て同一のベンダ、機種の計算機で構成しなければならないことが多く、 構築や運用は部門などの比較的狭い範囲内で行われている。 グリッド管理エンティティ グリッド管理エンティティは、グリッド 内のすべてのグリッド・コンポーネント間の関係、たとえば、オペレーティング・ システムおよびアプリケーションの、サーバおよびネットワークへのマッピングなどや、ライフサイクルを指す。たとえ ば、コンポーネントの検出、構成、開始、停止などを管理し、人的リソース、プロセス、テクノロジーなどで実現される。 グリッド管理エンティティは、グリッドシステムとグリッド・コンポーネントの管理に関係する重要な問題を理解するた めの基盤を提供する。 グリッド関連製品 特定の使用者の為に作成された物ではなく不特定多数の使用者の為に作成されたグリッドシステムを構築するた めに必要不可欠な製品群をさす。 ガイドラインでは単純に製品と記述することもある。 （例）グリッド関連製品には、グリッドシステムの構築用に作成されたグリッド用のソフトウェア（GlobusToolkit，Condor， Gfarm，Ninf-G など）や、グリッドを意識していないサーバ，ネットワークのようなハードウェアが含まれる。 グリッド関連製品ベンダ グリッドシステムを構築するために必要な製品（グリッド関連製品）を提供するベンダ。 グリッド・コンポーネント 製品や外部のシステム、特定のシステム運営者の為に作成されたシステムなどを含めたグリッドシステムを構成す る要素の総称。少なくとも単独で意味のある特定の機能を提供する単位。グリッド・コンポーネント は、物理か論理 かを問わず、グリッドシステム内でいくつかのリソースやサービスが集まって他のグリッド・コンポーネントを形成した り、1 つのグリッド・コンポーネントが構成要素としていくつかのグリッド・コンポーネントに分解されるという点で再帰 的な構造を持つ。 グリッドシステム グリッド環境における提供物で示したレイヤのいずれか一部でグリッド技術を使用しているシステムに対して、全体 または一部を指し示す名称。 コンピューティングコンポーネント グリッドシステムの最下位層（第１層）に位置づけられるサーバなどの汎用コンピュータとしての物理グリッド・コンポ ーネントを指す。 システム 特定の目的を自律的に機能するために複数のコンポーネントで構成されているもの。グリッド技術を使用している かどうかの有無を問わない。 システム運営者 システム使用者へグリッドシステムを提供する人(組織)。 7-102 - 102 - システム運営者は、主に下記のような機能をはたす。 ・グリッドシステムの仕様確定 ・グリッドシステムの運用管理，提供 ・グリッドシステムの評価 （注）システム運営者は、運営しているシステムがグリッドシステムであることを認識してシステムの運営を行っている が、システムの使用者へグリッドシステムとして公開するかどうかは、運営者の持つポリシやシステム使用者との契 約事項によって決定される。システム運営者は、システムの企画を行う機能と運用管理を行う機能を持っている。 システム構築者 システム運営者から提出された仕様に基づいてグリッドシステムを構築する人(組織)。 システム構築者は、主に下記のような機能をはたす。 ・コンポーネントの選定 ・要求仕様にある特定機能を実現するコンポーネントの作成 ・確定したコンポーネントを接続 ・グリッドシステムが的確に動作するように設定 一般的には、システムインテグレータの担当業務である。 システム使用者 システム運営者が提供するグリッドシステムを使用する人(組織)。 システム使用者は、使用しているシステムがグリッドである事を認識しているシステム使用者と提供者がグリッドシス テムであることを隠蔽しているためグリッドシステムであることを認識していないシステム使用者がいる。 （注）本報告書で記述するグリッドシステムのガイドラインは、基本的にグリッドシステムを認識している利用者や提供 者を読書として想定していないので、単純にシステム使用者と記述する場合は、グリッドシステムを意識しているシ ステム使用者を指している。 商用データセンタ 対価を得て顧客企業に対して業務アプリケーションやミドルウェアなどのソフトウェア、サーバなどのハードウェア、 あるいは、それらの設置場所などを提供するデータセンタ、あるいは、そのような事業を営む者を言う。顧客企業に 対するサービス提供に付随して、ネットワーク接続、電力、空調などの周辺サービスを提供することが多い。 ジョブ 利用者がグリッドを利用する際の仕事（実行）の単位であり、グリッド上で生成、実行、終了する、1 つ以上のタスク からなる。 シングルサインオン 一度の認証を受けるだけで、許可されているシステムをすべて利用できるようにすること。 ストレージコンポーネント グリッドシステムの最下位層（第１層）に位置づけられるディスクやアレイなど、ストレージ・コンポーネントである物理 グリッド・コンポーネントを指す。 制御 グリッドシステムを適切に管理するために、グリッドの「システム運営者」が「提供物」に対して行う操作である。グリッ ドシステムの持つ地理的分散性からリモート制御が必要であり、グリッド・コンポーネントのヘテロジェニアス性から 標準化、仮想化された制御が必要であり、グリッドシステムの提供する提供物、サービスのダイナミックに変化する 7-103 - 103 - 性質から、制御の自動化が必要である。 セキュリティ 本ガイドラインでは、グリッドシステムを構成する個別のグリッド・コンポーネントのセキュリティが適切であることを前 提に、グリッドシステムの持つ地理的分散性、グリッド・コンポーネントのヘテロジェニアス性、グリッドシステムの提 供する提供物、サービスのダイナミックに変化する性質に対して、グリッドシステムの提供する提供物、サービスが 適切なセキュリティ要件を満たす必要がある。 ダウンタイム システムなどが稼動していない時間のこと。本ガイドラインでは特に災害や障害などでシステムが停止している時 間を言う。 仲介者 グリッドシステムをモデル化するうえで、過去の INSTAC 委員会で使用した定義で、提供者と利用者の間でリソース を仲介するプレイヤを指す。本ガイドラインでは、プレイヤとして提供者と利用者しか使っていないため、ガイドライ ン中には出てこない。 提供者 本ガイドラインでは、グリッドシステムをモデル化するうえで、利用者にリソースを提供するプレイヤ（登場人物）を指 す。利用者と対になるプレイヤ。 提供物 本ガイドラインでは、グリッドシステムをモデル化するうえで、プレイヤとしての提供者と利用者の間でやり取りされる リソースのことを指す。 ディザスタリカバリ 事故、災害などに被災し停止したシステムを復旧させること。 認可 認証の済んだグリッドの利用者に対して、許可されるアクションを決定すること。 認証 利用者がグリッドを利用する際、提供者側が利用者の身元確認を行うこと。 ネットワークコンポーネント グリッドシステムの最下位層（第１層）に位置づけられるスイッチやルータなど、ネットワーク・デバイスである物理グリ ッド・コンポーネントを指す。 ビジネスプロセス 業務、あるいは複数の業務からなる一連の処理のこと。 物理環境 グリッドシステムの最下位層（第１層）に位置づけられる、ハードウエア単独としてのコンポーネント。この層は、基礎 となる物理的構成要素であり、IT リソース群で物理的に構成されるグリッド環境を作り上げる元となる。具体的には、 ストレージとして、SAN、NAS、HSM、コンピュータとしてサーバやブレード、ネットワークとしてスイッチ、ルータ、 FW 機器、VPN 装置などがこの層に分類される。 PF/プラットフォーム OE/動作環境上のコンポーネントを複数組み合わせ、最終サービスを構成するコンポーネントであり、従来型のサ ービスやアプリケーションの単一インスタンスに相当し、実行可能バイナリのようなものを指す。具体的には、データ ベース、Web サーバ、アプリケーションサーバ、仮想ファイルシステム、クラスタ管理ツール、オーバーレイネットワ ークが挙げられる。 7-104 - 104 - プレイヤ グリッドシステムをモデル化するうえで、グリッド環境における登場人物を指す。 プロビジョニング 業務システムを構築する際に OS、ミドルウェア、業務アプリケーションなどのソフトウェアや業務処理に必要なデー タをサーバなどのハードウェアや基盤となるソフトウェアに配置・設定すること。 ポリシ グリッドのシステムを運用するにあたって、グリッドの「システム運営者」が規定し、実施し、監査可能にする項目の 規定である。「利用者」と「提供者」の間の利用許諾とそれに対する対価からなる何らかの契約関係を成立させるた めの規定と、グリッド・コンポーネントのレベルの運用による制約の 2 面性を持つ。課金方法、SLA、セキュリティ、サ ポートなど、「システム運営者」によるグリッドシステムの運用方法を規定するものであり、各プレイヤの振舞に関係 する。 ユーティリティ 英語で電気、ガス、水道などの社会基盤を支える公共サービスのこと(日本語ではこれらは通常ライフラインと呼ば れる)。転じてサーバなどの計算資源を必要なときに必要なだけ提供するようなサービス、あるいは、そのようなサー ビスを利用するモデルのことを言う(ユーティリティ・コンピューティング)。 利用者 本ガイドラインでは、グリッドシステムをモデル化するうえで、提供者からリソースの提供をうけるプレイヤ（登場人 物）を指す。提供者と対になるプレイヤ。 7-105 - 105 - 付録Ｄ 商用データセンタの要件 商用データセンタとして、スペース、電源、ネットワークまでのファシリティを提供するケースの要件リストである。 （FRT よる資料提供） 項目 立地条件 Spec 公共交通機関等からの距離 周辺環境 空港・駅・港・高速道路・主要幹線道路 海・河川・湖・火山・崖が与える影響を考慮 自衛隊・米軍・警察・発電施設等の与える影響を考慮 地殻プレート 複数のデータセンタを利用する場合に考慮 台風 台風が直撃（風速25m以上の暴風圏内）する頻度を考慮 積雪 1m以上の積雪が続く期間を考慮 洪水 人口用水路の確認、河川からの距離を確認 地震発生確率（マグニチュード7以上）を考慮 建物 津波 海からの距離を確認、海抜を確認 移動時間 データセンタまでの駆けつけ時間を考慮 築年数 ビル構造 鉄骨造等 耐震基準 震度6クラスの地震後にも継続使用が可能 地震対策 制震構造・免震構造・耐震構造 ビルの元々の目的 地質調査データの分析・評価 データセンタ専用ビル・オフィスビル・オフィスビル併設・その他施設 液状化現象の可能性とその対応策を確認 グランドレベル（GL）調査-41m～-48m以深にN値50以上の砂岩層等 外壁 外壁の構造 SR(サーバールーム）床荷重 ブレードストレージ機器などを考慮（1t/㎡等） 窓（ガラス）の設置の有無 BMS 建築/通信 SR有効高さ（スラブ面～大梁下） 設置可能機器の種類を考慮 SR有効高さ（スラブ面～アクセス床上面） 強電・弱電配線の可用性を考慮 SRの総面積 SRの可用性 作業室 iDCの可用性を考慮 荷捌き室 iDCの可用性を考慮 機器搬入出口 iDCの可用性を考慮 出入り口・機器搬入口 複数設置を考慮 人用・貨物エレベーター エレベータ内容量と積載荷重を考慮 BMS ビルメンテナンスの運用状況 BMSのメーカー ビルメンテナンスの運用状況 BMSのポイント数 ビルメンテナンスの運用状況 BMSの冗長性 ビルメンテナンスの運用状況 ビル管理者の人数（平日昼間） ビルメンテナンスの運用状況 ビル管理者の人数（夜間、休日） ビルメンテナンスの運用状況 iDC提供キャリア NTT、KDDI、SBT、IIJ、USEN、その他 バックボーン 回線容量 キャリア種類（複数キャリア） 冗長構成 接続IX 商用IX接続の有無 提供回線帯域、種類 インターネット共用/専有、専用線 国内接続経路・海外接続経路の確認（通信迂回路の有無） 遅延 複数拠点間の通信遅延時間 付加サービス IPアドレス提供サービス、ドメイン取得サービス ネットワークサービス（セキュリティ・ルータ） ファイアウォール、IDS/ADS、ウィルスプロテクション ロードバランサー、コンテンツフィルタ、VPN、マルチホーミング 地下埋設光ファイバーの引き込み箇所数、場所 複数経路・引き込み管路管理状況・架空、埋設 引き込み管路数 MDF空き状況 拡張性を考慮 MDF室広さ 拡張性を考慮 各キャリアの引き込み状況 複数キャリアを考慮 縦シャフト数 縦シャフトスペース 拡張性を考慮 拡張性を考慮 7-106 - 106 - 項目 通信配線 アクセス床 ラック Spec ケーブルの仕様 ケーブルの横引きルート 可用性を考慮 メーカー 機器設置を考慮 耐荷重 1t/㎡ 可用性 免震装置の設置可能性を考慮 標準的なラック寸法 使用機器の搭載可用性を考慮 排熱性、耐荷重、機器マウントレールの可用性、排熱ファン設置個 数、他のラックとの接続性、電源用ファクトラインの有無、棚板種類、 設置機器に対する耐震用設備の有無、 ラック仕様 Security データセンタ側でのビル内施設の管理 ラック開錠方法 iDC立会い、ユーザにて自由 ラックキー保管方法 iDC管理、ユーザ管理 ラックキー種類 カギ錠、暗証錠 ラックの固定方法 SR室内管理 架台の耐震固定状況を考慮 入館申請による事前入館管理、非接触式IDカードキー、データセンタ への入退館・サーバルームへの入退室のログ管理、 サーバ室出入口のインターロック機能、生体認証、 人感センサー、不正侵入検知、常時監視、アンチパスバック機能、 マントラップ セキュリティーシステム 建物周囲 契約警備会社、警備内容、緊急時対応状況、建物周辺警備・監視 監視カメラシステム 設置台数、設置場所、モニター状況 カメラの種類 アナログカメラ 映像の保管メディア、保管期間 録画保存期間、メディア保管状況 入退室管理 警備の人数 （平日昼間） 警備の人数 （夜間、休日） 電気設備 ラック当たり基本供給電力量 ラック当たり最大供給電力量 増設の可用性 SR単位面積当たり供給電力量 コロケーションの際の検討内容 提供電源内容 100V、200V、単相、三相 電気設備の２重化 受電設備 受電方法・受電電圧 送電経路 変電設備 変電設備 高圧受電、特高受電 冗長化（本線・予備線）・ループ化、発電所の確認 冗長化を確認 メーカー、年式 変電設備の保守契約 非常用発電機 非常用発電機 非常用発電機の設置場所 設置の有無 屋内・屋外、耐地震構造施設内・施設外、 低気圧時の吸気対応 吸気設備有り無し 発電機の連続運転可能時間 連続運転可能時間 発電機のメーカー、年式 発電機の容量 発電機用オイルタンクの容量 連続運転可能時間、給油体制構築の確認 発電機の試験運転頻度 無負荷、実負荷での実施状況の確認 発電機の点検頻度 年間の頻度の確認 発電機の保守契約 有 UPS UPSメーカー、種類、年式 UPSのタイプ UPSの容量 可用性の確認 UPSの供給可能時間 非常用発電機の実稼動までにかかる時間を考慮 蓄電池の種類、メーカー、年式 UPSの試験 年間の頻度を確認 UPSの保守契約 UPSの1次側・2次側 冗長構成を確認 7-107 - 107 - 項目 空調設備 Spec ラック当たり冷却容量 使用電力量・ラック内発熱量を考慮 SR単位面積当たり冷却容量 フロア設計の際に考慮 空調容量 最大冷却能力を考慮 空調タイプ 冷房方式 空調機械のメーカー、年式 空調機械の容量と台数 拡張性を考慮 断水の場合の空調機械の運転時間 引き込み水道管路の冗長化を確認、水の再利用設備を確認 水漏れ検知システム サーバルーム内への漏水を考慮 温度、湿度設計条件 温度・湿度の計測ポイント数を確認 湿度制御の方式 消火設備 各種認証取得 ガイドライン準拠 窓口 機器障害対応 サーバホスティングサービス SR消火設備 人体及び機器に影響を与えるか考慮 オフィスエリア消火設備 設置の有無 超高感度煙感知機 設置の有無 防火区画 延焼の確認 火災訓練 年間の頻度と火元責任者の確認 ISMS/BS7799 プライバシーマーク 財団法人日本情報処理開発協会 FISC 金融情報システムセンター FSA 金融庁 地方公共団体のITアウトソーシングガイドライン 総務省 24H365D 有人対応 言語 複数言語対応（日本語・英語・中国語・ウチナーグチ） 対応人員 オペレータ、SE 一次対応 専任対応 リモートハンドサービス 電源オフ/オン、ランプ状態確認、画面表示内容の確認、 ケーブルの抜き差し確認、メディア脱着、メディアクリーニング サーバマウント、HDD/メモリ増設・交換、各種状態監視、 システムバックアップ 機器種類 HDD容量、メモリ、CPU、増設可否、運用代行内容、対応OS ストレージホスティング 機器種類 HDD容量、メモリ、CPU、増設可否、運用代行内容、対応OS バックアップ メディア保管庫の確認 バックアップシステム 7-108 - 108 - 経済産業省委託 平成 18 年度産業技術研究開発委託費 「基準認証研究開発事業：情報分野の国際競争力強化の標準化調査研究」 「グリッドコンピューティングの国際標準化に関する調査研究」 成果報告書 発行 印刷 平成 19 年 3 月 財団法人 日 本 規 格 協 会 情報技術標準化研究センター 〒100-0014 東京都千代田区永田町 2-13-5 電話（03）3592-1408 株式会社 スタンダード・ワークス 〒107-8440 東京都港区赤坂 4-1-24 日本規格協会ビル内 電話（03）3585-4558 －禁無断転載―