DEWS2004 6-C-03

JVO プロトタイプシステムの開発
田中昌宏†

白崎 裕治†

本田

安田 直樹††敏志†

大石 雅寿†

水本好彦†

増永 良文†††† 国立天文台 〒 181–8588 東京都三鷹市大沢 2–21–1†† 東京大学 宇宙線研究所 〒 277–8582 千葉県柏市柏の葉 5–1–5††† お茶の水女子大学 理学部 情報科学科 〒 112–8610 東京都文京区大塚 2–1–1
E-mail: †{masahiro.tanaka,yuji.shirasaki,honda.satoshi,masatoshi.ohishi,mizumoto.y}@nao.ac.jp,††yasuda@icrr.u-tokyo.ac.jp, †††masunaga@is.ocha.ac.jp
あらまし

国立天文台では 、すば る望遠鏡などが産み出す膨大かつ多様な天文観測データベースに基づく Japanese

Virtual Observatory (JVO) の開発をおこなっている。このシステムは、我々が定義した検索言語で記述された検索条件を受け取ると、必要なデータが保管されたデータベースサーバを自動的に探し 、Globus Toolkit 3 のグリッド サービスを用いて検索サービスを遠隔実行する。本システムにより、これまで困難であった多波長データへのアクセスを容易になる。本稿では、JVO プロトタイプシステムの実装について述べる。
キーワード

天文学 DB, 分散 DB, DB 言語, 科学 DB

Development of JVO prototype system
Masahiro TANAKA† , Yuji SHIRASAKI† , Satoshi HONDA† , Masatoshi OHISHI† , Yoshihiko
MIZUMOTO† , Naoki YASUDA†† , and Yoshifumi MASUNAGA†††† National Astronomical Observatory of Japan, 2–21–1 Osawa, Mitaka, Tokyo, 181–8588 Japan†† Institute for Cosmic Ray Research, University of Tokyo, 5–1–5 Kashiwa-no-Ha, Kashiwa, Chiba, 277–8582 Japan††† Department of Information Science, Ochanomizu Univerisity, 2–1–1 Otsuka, Bunkyo-ku, Tokyo, 112–8610 Japan
E-mail: †{masahiro.tanaka,yuji.shirasaki,honda.satoshi,masatoshi.ohishi,mizumoto.y}@nao.ac.jp,††yasuda@icrr.u-tokyo.ac.jp, †††masunaga@is.ocha.ac.jp
Abstract Japanese Virtual Observatory (JVO) is developed at National Astronomical Observatory of Japan (NAOJ) basedon a huge amount and variety of astronomical data produced by Subaru telescope etc. Once the JVO system receives a query
condition written in the query language we defined, the system searches for required database servers and executes remotequery services using Grid service of Globus Toolkit 3. This system provides easy access to multi-wavelength data, while it has
been difficult. This paper describes development of the JVO prototype system.
Key words Astronomical DB, Distributed DB, DB language, Scientific DB, Data Center

1. は じ め にアーカイブの活用が必須となる。しかし実際にそのような研究をおこなうには大きな労力を必要とする。というのは、天文学

すばる望遠鏡 [1] を始めとする世界中の望遠鏡や宇宙望遠鏡

データの公開をおこなっている機関は望遠鏡を開発・運用するなどの最新の天文観測装置により、良質で大規模なデータが大観測所である場合が多く、公開するデータの形式や方法も機関量に生み出される時代になった。そうしたデータは一次処理後ごとに統一されていないためである。世界各地に分散配置されアーカイブ化され 、一定期間経たのち一般に公開されるようにたデータアーカイブから研究に必要な数々のデータを取得し 、なってきている。こうした天文学データアーカイブの天文学研

データを変換・加工して解析可能な状態にするまでには、非常究における重要性は高まってきている。特に電波からガンマ線に大きな労力が必要である。多くの天文学データを集めて統一

にわたる広い波長範囲の電磁波による観測データを使った統計的な検索インタフェースを提供する CDS [2] のような機関もあ的な研究には、単一の望遠鏡では不十分であり、天文学データ

るが 、それでも世界中の観測データを集めることは事実上不可能である。
そこで、究極の天文学データアーカイブ検索システムとして、世界中に分散配置されたアーカイブサーバが連携することにより、世界中のすべての観測データの中から必要なデータを簡単に検索できるようなシステムが模索され始めている。このようなシステムは、計算機に蓄えられた観測データに基づいて仮想的な宇宙を構築し 、それを自在に「観測」するための「天文台」
であるということから「 Virtual Observatory (VO) 」と名付けられている。VO における大きな課題は、分散配置されたデータ
アーカイブの間で連携して検索することである。ここにグリッド を代表とする、情報処理の分野で最近発展している分散計算
機リソースを有効利用する技術の導入が考えられている。

VO 計画は 各国で 立ち上がっており、国立天文台に おいて

図 1 VOTable の例

も Japanese Virtual Observatory (JVO) [3] [4] が進められている。

Fig. 1 VOTable Example

JVO では、独自の VO システムの開発の他、各国の VO が相互連携するため International Virtual Observatory Alliance (IVOA) [5]は、いわゆるメタデータを「キーワード ・内容」形式で記録すにも参加し 、VO に関する国際標準仕様の策定など もおこなっる。重要なメタデータには 、観測時刻、観測装置、観測波長、ている。

座標系と座標、データの単位系などがある。

本稿では、2002 年度から富士通との協力により開発している

2. 2 天体カタログ

JVO プロトタイプシステムの実装について述べる。プロトタイ

天文学では画像・スペクトルデータだけでなく、天体カタロ

プ開発には次のような目的がある。1 つは VO の仕様を検討す

グも用いる。天体カタログは、個々の天体について、明るさなるにあたって、実際に動作するシステムを用いて機能を実証す

ど の観測値や属性を、テーブル形式で記録したデータである。

ること、もう 1 つは本運用の JVO システムの構築にあたり、採このため、RDB (Relational DataBase) で扱いやすいデータと言用した技術要素が有効かど うかを評価し 、異種分散データベー

える。天体カタログの項目には、天体の座標が必ず必要となる。

ス連携など の機能が実現可能かど うかを実証することである。

その他の項目は決まっていないが 、ほとんどの場合はある波長

こうして構築したプロトタイプに基づいて、運用システムを構における天体の明るさのデータが含まれる。

築する予定である。

2. 天文学観測データ

天体カタログのデータフォーマットには、FORTRAN での入出力が 容易なように 、単純な固定幅のテキスト 形式が 多かった。しかし これでは計算機がフォーマットを自動的に認識ではじめに VO で扱う天文学観測データについて簡単に紹介すきない。その他に FITS にもテーブ ルを格納する方式が 定める。実際の観測装置が出力する一次データは、装置ごとに異なられられているが 、それほど 一般的にはなっていない。最近、る形式を持つ。VO では通常この一次データを対象とはせず、XML 形式のテーブル表現形式とし て 、FITS テーブルの仕様

一次データを処理して得られた二次データを扱う。二次データを基に VOTable [7] が制定された。VOTable の例を図 1 に示す。

には、大きく分けて次のタイプがある。

VOTable に記録されるデータは大雑把に言えば 、テーブル形式

2. 1 画像・スペクト ルデータのデータ本体、およびテーブルのカラムについての詳しい情報

画像データは 2 次元のグリッド で表わされる。各々のピクセ(カラムメタデータ) から成る。VOTable は、計算機可読なデー

ルには通常、放射強度、すなわち明るさのデータが記録される。

タ形式として、VO におけるデータ交換のための標準的なデー

天文における画像の特徴は、世界地図のように、天球面から平

タフォーマットとなることが期待されている。

面に投影されるということである。このとき座標や投影法の情報が必要となる。天球座標系には赤道座標系、銀河座標系など複数ある。

3. JVO に必要な機能
3. 1 異種分散データベースの連携

天文学では画像の他、電磁波を分光して得られたスペクトル

前節で述べたような天文学観測データは 、アーカイブデー

データを扱うことも多い。各天体に対してスペクトルを測定しタとして公開されるケースが多くなっている。アーカイブデー

た結果は 、波長方向の 1 次元のグリッドデータで表わされる。

タを集めて公開し ているデ ータセンターもあり、その中では画像の各点に対してスペクトルまで測定している場合は、3 次

CDS [2] が最も充実している。しかしすばるの公開データを取元グリッドデータとなる。

得したいときは、CDS ではなく、国立天文台の SMOKA [8] にこうしたデータのファイルフォーマットとして、天文学ではアクセスする必要がある。というのは、アーカイブデータの管

一般的にバイナリ形式の FITS (Flexible File Transfer) [6] が使わ

理のためには観測装置のことまで理解していることが求められれる。FITS は大きくヘッダー部とデータ部からなり、データ部

るため、管理元は必然的に各観測所となるからである。また、には FITS データを階層的に含むことができる。ヘッダー部にアーカイブデータの管理方法も観測所の都合によって異なるこ

とが予想される。したがって、VO を実現するには、地理的に離age [10] をはじめとしていくつか存在する。そういったものをれているアーカイブデータを統一的に扱うための異種分散デー

流用可能か 、VO 用の可視化ツールが必要であるかど うかは検

タベース連携が必須となる。

討中である。

JVO では分散データベースへの問い合わせ言語として、SQLを拡張し た JVO Query Language (JVOQL) [9] を定義し た。ま4. JVO プロト タイプの開発方針

た、各国の VO と連携するため、IVOA 標準の検索言語の仕様

4. 1 ターゲット ユースケース

策定もおこなっている。さらに 、VO 間のデータ交換を可能に

JVO システムの開発にあたって、まず機能を限定したプロトするため、データ転送の際のフォーマットは標準に則ったもの

タイプの開発をおこない、採用した技術の有効性や機能を評価を採用すべきである。今後標準フォーマットになるとみられる

するという手法をとった。

のは、画像・スペクトルデータについては FITS 、天体カタログについては VOTable である。

JVO の利用例 (ユースケース) として、すばる望遠鏡の主焦点
カメラ Suprime-Cam (2k×4k ピ クセル ×10 CCDs) によって撮

3. 2 クロスマッチ

られた Subaru Deep Field (SDF) という領域のデータを用いた。

多波長観測データを使った研究の際にまず必要になるのが 、

ここで用いたデータの観測波長は i0 バンド (683-854nm) 、z 0 バ

異なる天体カタログから同じ 天体を探すことである。これはンド (834-993nm) の 2 つである。それぞれのバンドごとに、画RDB で ID を基に JOIN をとることと似ている。JOIN と異なる像データおよびその画像から検出された天体のカタログデータのは、同じ天体かど うかをまず座標位置の近さで判断することを用意した。分散データベース連携の実証のため、これらはそである。天体の位置の精度は、望遠鏡の口径や観測波長などでれぞれ異なるサーバにストアし 、検索サービス・クロスマッチ

決まる空間分解能や、観測時の空の状態などの条件などによっ

サービス・画像切り出しサービスを構築した。

て決まる。天体の位置はこの精度以内で不定である。したがっターゲットとなるクエリは、「 i0 バンド と z 0 バンド でクロスて同じ天体かど うかの判断は、天球面上の距離がある範囲以内マッチをとり、両方のカタログに含まれる天体のリストおよびであるという条件でおこなう。このような処理を「 クロスマッ

その画像を返す」というものである。これを JVOQL で記述すチ」と呼ぶ。クロスマッチは既存の RDB にはないが 、天文でると、以下のようになる。

は使用頻度が高いため、JVOQL ではクロスマッチのための仕様拡張をおこなっている。

select3. 3 画像・スペクト ルデータ

i.POS_EQ_RA_MAIN as ra1,

SQL には画像やスペクトルデータを扱うための仕様は制定さ

i.POS_EQ_DEC_MAIN as dec1,

れていないが、天文学においては必須となる。そこで、JVOQL

i.PHOT_SDSS_I,

では 、天体の位置に対応する画像を切り出す文法を追加してz.POS_EQ_RA_MAIN as ra2,

いる。

z.POS_EQ_DEC_MAIN as dec2,

3. 4 解 析 機 能z.PHOT_SDSS_Z,

検索して集められたデータは、解析に用いられる。ここで解i.BOX(POINT(ra1,dec1), 0.005, 0.005),

析とは、画像から天体の明るさを測定する、銀河の形を計算す

z.BOX(POINT(ra2,dec2), 0.005, 0.005)

る、天体の「色」によって分類する、などというように、デー
タを基にして各種パラータを求めることである。研究者が必要とするデータは、検索結果よりもこうした解析によって得られたデータだけであることが多い。また一般的には解析結果のfrom
Subaru.SPcam.i i,
Subaru.SPcam.z z
where

データ量は元となったデータの量より小さい。そこで、VO 側

XMATCH(i, z) < 10 arcsec NEAREST andで解析までおこない、その結果のみをダウンロード できれば 、BOX(POINT(201., 27.4), 0.10, 0.10) andネットワーク転送がボトルネックになる場合に有効である。さi.PHOT_SDSS_I - z.PHOT_SDSS_Z > 0.0 andらに利用者は解析ソフトウェアを用意しなくてもよいという利i.PHOT_SDSS_I < 20.0 and点もある。

z.PHOT_SDSS_Z < 20.0

しかし 、複雑な解析処理などを VO に依頼する際の一般的な指定方法についてはまだ考えられていない。こうした画像やス

ここで where 句にある XMATCH という条件は 、テーブル i とペクトルデータを VO で取り扱う方法の一般化は、今後の課題

z とでクロスマッチを取ることを表わし 、BOX(...) というである。

条件は 、赤経 201 度、赤緯 27.4 度を中心とする 0.1 度四方の3. 5 可視化機能

領域以内の天体を検索することを表わす。また 、select 句の取得した画像やスペクトルを調べるには、1 次元のプロット

i.BOX(...), z.BOX(...) というカラムは、where 句にマッや 2 次元の画像として表示する必要がある。VO でもデータのチし た天体の位置を中心に 、それぞれ i0 バンド と z 0 バンド

可視化をサポートすれば 、利便性が格段に向上する。

の画像を 0.005 度四方で切り出すということを表わしている。

クライアント動作の天文可視化ソフトウェアには 、SAOim-

JVOQL の文法についての詳細は白崎他 [9] を参照されたい。

5. 1. 1 実 行 制 御ユーザが JVOQL で検索条件を書き、JVO ポータルサーバに送ると、JVO システムは実行コントローラに制御を移す。実行コントローラはまず最初に JVOQL パーサを実行する。JVOQL
パーサは、ユーザが作成した JVOQL をパースし 、個々のリモー
トサーバへの検索条件へと分解する。次にスケジューラが呼ば
れ 、実行手順を作成する。この実行手順を元に 、実行コント
ローラは分解された検索条件をリモートサーバの検索サービスに送り、検索を実行するのである。
この実行コントローラは、動的に変化する実行手順にも対応するようにした。4. 1 節で述べたように 、クロスマッチ検索では 、まず最初に 2 つの天体カタログそれぞれに対してクロス
マッチ以外の条件でマッチする個数を求め、個数が少ない方の
図 2 JVO プロトタイプ第 2 版構成

サーバから多い方のサーバへデータ転送するようにする。このFig. 2 Configuration of JVO prototype version 2

ような手順にするのは、転送量をできるたけ少なくするためである。このように動的に変化する実行手順にも対応するため、

JVO ポータルがこのようなクエリを受け取ると以下のように動作する、というシステムを開発した。

スケジューラがサービスの実行結果に基づいて次回以降のサー
ビ スの実行手順を決めるという仕組みにした。さらに、1 つの（ 1 ） JVOQL をパースして個々のサーバへのクエリに分解。

サーバへの実行が失敗したときは、別の似た機能を持つサーバ（ 2 ） 個々のクエリを 2 つのサーバに送り、それぞれ条件にへ再試行するという機能も持たせた。

マッチする天体数を取得。
（ 3 ） マッチした天体数が少ない方のサーバで検索を実行。
結果をもう一方のサーバへ送る。
（ 4 ） 送られたデータとサーバ内のデータでクロスマッチを

プロトタイプ 1 では 、JVOQL パーサおよび スケジューラもリモートサーバのサービスとして実装している。

5. 1. 2 遠隔実行・データ転送
世界中に分散した天文データベース連携のため、ネットワー

実行。

ク接続された計算機間での遠隔実行・データ転送を実現するグ（ 5 ） クロスマッチの結果を基に、画像を切り出す。

リッド のミド ルウェアが必要となる。世界の VO が連携するた（ 6 ） 検索結果を元にテーブルデータおよび画像を表示する。

めに、ミド ルウェアとして標準的な技術を使うことが重要であ

4. 2 システム構成る。現在この条件を満たすものとして、Globus Alliance [12] で

図 2 に JVO プロトタイプのシステム構成を示す。システム開発された Globus Toolkit を採用した。

は、1 つの JVO ポータルサーバ、複数の分散データベースサー

1 回の遠隔実行の手順は以下のようになる。まず実行前にリバ、その他のサービス提供サーバから成る。このシステムの大モートサーバで実行したいシェルコマンド を送っておく。そしまかな動作は以下の通りである。まず利用者は Web ブラウザて globus-job-run により、送ったシェルコマンドをリモートサー

で JVO ポータルサーバにアクセスする。利用者認証後、JVO のバで実行する。そのシェルコマンドは実行ステータスおよび出メイン画面が現れる。この画面から JVOQL で記述した検索命

力したファイル名を標準出力に返す。実行コントローラは出力

令を実行制御コントローラに送る。コントローラは命令を解析されたファイルを GridFTP (globus-url-copy コマンド ) を用いてし 、レジストリを参照して要求されたサービスを提供するサー

次に実行をおこなうリモートサーバへ転送する。最後に実行さバを引き当て 、検索命令の実行手順を作成する。この手順にれたサービスの出力は、JVO ポータルサーバへと戻される。

従い、グリッド 経由で各サーバに実行要求を送る。結果のデー

5. 1. 3 サービスの検索

タは 、天体カタログデータは VOTable 、画像データは FITS 形

天体カタログデータは別々のサーバに分散配置されている。

式で得られることとした。ユーザインタフェースの詳細は本田

そこで実行コントローラは検索したいデータがどこのサーバに

他 [11] を参照されたい。

5. プロト タイプ第 1 版
5. 1 実装保管されているかを知る必要がある。このサーバ情報を取得するため、プロトタイプ第 1 版では UDDI (Universal Description,

Discovery, and Integration) を用いた。UDDI は Web サービスを検索・照会するシステムであり、必ずしも RDB 中のテーブル

前節で述べたシステム構成でターゲットユースケースの動作がどこにあるかを検索するために作られたものではない。そこを実現することが 、プロトタイプの目標である。実際にプロトで、天体カタログ 1 つ 1 つに検索サービスを対応させるというタイプを実装する上では、個々の技術要素として何を採用する方法を取った。こうすることにより、UDDI でサービ スを検索かが大きな問題となる。以下にプロタイプ第 1 版の実装についすれば天体カタログがどのサーバで提供しているかという情報て述べる。

まで得ることができる。ただし 、遠隔実行に Web サービ スを用いておらず、前述のような独自の遠隔実行方法を用いている

ため、UDDI から WSDL を取得しても JVO 用のサービ スのス

片方のテーブルは RDB 中の天体カタログとする。このサービケルトンを作成できるようにはなっていない。

スは、前述の検索サービスを拡張することにより構築した。

5. 1. 4 データ検索サービスc ) 画像検索サービス

データ検索サービスとして、天体カタログ検索サービス、クプロトタイプで開発した画像検索サービスは、入力として検ロスマッチ検索サービス、および画像検索サービスを開発した。

索の結果得られた VOTable を与えると、1 つの FITS 画像から、

a ) 天体カタログ検索サービス

VOTable に含まれる天体の座標を中心とする指定の大きさの画

天体カタログ検索サービ スの構築には RDB を用いた。この像を切り出す、というものである。しかし画像データには複数

プロトタイプ開発の目的の 1 つは、異種分散データベース同士枚の画像に分かれている場合もあり、そういうデータへの対応で連携した検索を実証することである。そこで Solaris マシン

は今後の開発課題である。

と Linux マシンという異機種のハード ウェアを組み合わせたテ

5. 2 評価

スト環境を用い、DBMS には Oracle と PostgreSQL の 2 種類を

このプロトタイプによって、分散したデータベースを JVOQL使用した。ただし RDB だけでは不足する機能として、JVOQL

により統一的に扱い、複数の独立なデータベース上のカタログに特有の領域指定構文を解釈すること、結果を VOTable で出力データを比較し 、対応天体がある部分の画像を取得できることすることがある。

を実証した。

天球座標による領域指定は、ほとんどの天文データ検索におしかし 多くの課題も出た。その 1 つはサービ スの遠隔実行

いて必須である。天球座標は赤経 (RA) 、赤緯 (Dec) で表わされが非常に遅いことである。個々のサービスの実処理時間は 1 秒

るが、これだけで効率的に検索することは難しい。というのは、以下であるにもかかわらず、遠隔実行にすると 1 分以上もかか

天球座標は 2 次元であり、直交座標とは異なり距離や領域を表り、全体の処理が終わるまでに 10 数分もかかった。この理由

わすために複雑な式変換を必要とするためである。そこで、天は、globus-job-run で発行したジョブが GRAM (Globus Resource

球座標を効率的に検索するため、天球座標の領域を 1 次元のイ

Allocation Manager) で管理されており、GRAM は長時間ジョブ

ンデックスで表わす HTM [13] (Hierarchical Triangular Mesh) をの遠隔実行を想定しているので、リアルタイム処理には向かな採用した。HTM では天球面をまず 8 分割し 、球面三角形の領域

いためである。globus-job-run はジョブを投げ ると 、結果を受に区切る。このとき各々の領域につけるインデックスは、N0 か

け取るために定期的にポーリングする。このポーリング間隔がら N3 および S0 から S3 である。さらに分割するときは、三角

Globus Toolkit のデフォルトでは 30 秒となっている。ソースを形の中点を結んだ線によって 4 つの三角形に分ける。それぞれ

修正してポーリング 間隔を 3 秒程度にすると 、サービ ス 1 個の領域は一定のルールによって 0 から 3 までの数字が与えらる。

の実行時間が 22 秒程度に短縮された。リアルタイム処理には

これは 2 進数で 2 桁に相当する。分割された領域のインデック

globus-job-run ではなく GSI-SSH を用いることで改善されるかスは、分割される前の親領域のインデックスからこの 2 進数のもしれない。

2 桁を増やすことによって作られる。このような分割を適当な遠隔サービスの実装方法にも課題があった。プロトタイプ第レベルまで繰り返すことによって、天球は一意的なインデクス

1 版では 、天体カタログ 1 つ 1 つに検索サービ スを作るといを持った多数の三角形の領域に分割される。JVO プロトタイプ

う方法を取った。こうすることにより、天体カタログが保管さの検索サービ スでも、次のようにして HTM によって天球座標

れているサーバの検索は、UDDI でのサービス検索に置き換えを検索する機能を付け加えた。まず RDB に登録する天体カタられる。しかしこの場合、天体カタログを新たに加えるときはログデータには、HTM のカラムを加えた。さらに、JVOQL にサービスも新たに構築することになる。そうすると、天体カタ

よる検索条件文中に領域指定の構文があると、検索サービスにログが増えた場合に管理が煩雑になる。また、WSDL の独自拡

おいて HTM の条件式に変換する。

張は他の VO との連携に支障が出る恐れがある。

天体カタログ 検索サービ スが 出力するデ ータは 、前述の

VOTable で 出 力す ること とし た 。VOTable は XML で あ り、

6. プロト タイプ第 2 版

IVOA 標準となることが 期待されている。デ ータ本体につい6. 1 実装の見直しては、RDB の結果に XML のタグを付加するだけでよい。そのJVO プロトタイプ第 1 版の評価で判明した問題点を改善する

他に VOTable に必要な情報として、カラムメタデータがある。

ため、JVO プロトタイプ第 2 版では採用した技術要素を以下のVOTable ではそれぞれのカラムに対して、カラム名・UCD [14]・

ように見直した。

単位・データ型・カラムの説明等の情報を加えることが要求さ

6. 1. 1 遠 隔 実 行れる。そこで RDB にデータ本体に加えてカラムメタデータをプロトタイプ 第 2 版では Globus Toolkit 3 を採用し 、そこで別テーブルとして登録することとした。

新たに導入された「グ リッド サービ ス」を遠隔実行に用いた。

b ) クロスマッチサービス

グリッド サービスは、Web サービスをグリッド 用に拡張したもクロスマッチ検索サービ スは、前述のように、2 つの天体カのであり、サービ スの記述方法も WSDL を拡張した GWSDL

タログの間で天球座標が近い天体を選ぶサービ スである。今が定められている。これはプロトタイプ第 1 版で構築したサー回構築したサービスの仕様は以下の通り。片方の天体カタログ

ビスと似ている。しかし独自仕様でなく、グリッド の標準仕様

テーブルとして検索サービスが出力した VOTable を与え、もうに則ることにより、サービスの構築を容易にしたり、外部との連携をし易くすることを図る。また、グリッド サービスの仕様

体カタログが利用できるかをわかりやすく表示することが可能に合わせて各サービスも再構築した。

になった。

6. 1. 2 データ転送
コントローラとデータベースサーバとの間のデータ転送には、

JVO プロトタイプでは Globus Toolkit を利用して実装してきた。しかし VO を構築する際に Globus Toolkit では不足すると認証つきのファイルシステムである SFS を利用した。また、各感じられる点もある。それは、サービス実行とデータ転送を別々

データベースサーバ間の転送には、Globus Toolkit 3 に含まれるに実装しなければならないということである。グリッド サービ

RFT (Reliable File Transfer) を利用した。RFT は GridFTP の転スの引数としてデータを転送するならば別にデータ転送を実装

送の信頼性を向上したものである。

する必要はない。しかしこの場合は中間データを一旦実行コン

6. 1. 3 レジストリ

トローラに戻すことになり、さらにその結果を別のサーバに渡JVO システムのレジストリは、各データベースサーバのサーす場合には無駄な転送が発生する。この問題は GridFTP または

ビス情報、および保管された天文観測データのメタデータを集

RFT を用いてリモートサーバ間で転送することにより解決す

約し 、検索できるようにしたものである。レジストリは次のよる。そこでプロトタイプ第 2 版では、グリッド サービスと RFT

うな場合に必要になる。例えば 、どんなカタログがあるかわかとを独自に連携させる方式を採った。しかし独自仕様はメンテらないが「クェーサーカタログのデータが欲しい」というよう

ナンスや外部との接続の時に問題となるため、遠隔実行とデーに、特定の種類のカタログを見つけたい場合。また、「この領域

タ転送を統合したサービスの仕様がミド ルウェアレベルで標準に含まれる天体のデータをすべて取得したい」というように 、的に提供されることが望ましい。

複数の天体カタログにまたがる検索をおこないたい場合。
プロトタイプ第 1 版では、天体カタログの検索は、UDDI を

また、グリッド サービスを利用できる言語が現状では Java のみであることも問題である。天文学データ処理ツールは Java 以使ったサービス検索に置き換えたため、メタデータの検索がで外のいろいろな言語で記述されており、コマンド として利用すきなかった。そこでプロトタイプ第 2 版では、天体カタログのることも多い。そこで、コマンド やいろいろな言語からグリッ

メタデータをレジストリに登録し 、レジストリに対して検索す

ド サービスを容易に利用できるような仕組みを期待する。

ることによって実現することにした。
メタデータには、アーカイブデータの情報 (観測装置、天域、7. お わ り に

波長域、データの所有者等) や、サービス提供サーバの情報が含

本稿では、Globus Toolkit を利用して JVO プロトタイプシス

まれる。メタデータの仕様は、国際的な VO における標準化案

テムを実装し 、分散データベースとして機能することを実証しと互換性を持つように設計した。これは将来諸外国の VO とのたこと、プロトタイプ第 2 版でグリッド サービスを採用するこ

連携を容易にするためである。このデータを XML 化し 、XMLとにより、実行時間の改善したことなどについて述べた。この

データベース (製品「 カレアレア 」を利用) に入力し 、XPATH

プロトタイプにより、分散データベースとしての JVO システムで検索することとした。

の枠組みが確立できた。

このレジストリに検索をかけることで、多波長の天体カタロ

プロトタイプの評価を踏まえ、今後、JVO 運用システムの開グを検索したり、検索サービスや解析サービスを提供するサー発を計画している。実用に耐えうるシステムにするには、検索

バを自動的に見つけたりすることが可能となる。

サービスの高性能化、解析ツールの充実などの改良が必要であ

6. 2 評価

プ ロトタイプ 第 2 版では 、第 1 版より実行時間が短縮される。また運用システムではユーザ認証およびリソースの管理が必要になる。その他の大きな課題として、組織間での VO の連た。検索処理だけに 2.3 、13 秒かかるジョブをグリッド サービ

携がある。別組織で保管されるデータは管理や運用のポリシー

スで発行すると、遠隔実行を含めた経過時間はそれぞれ 2.8 、16が異なる。そこで他の組織に配置された天文学データを利用す秒程度と 、わずかな増加にとど まったのである。このように 、るためには、どのようなプロトコルが必要か、どのような技術

余分な待ち時間はほとんどなくなり、パフォーマンスは大きくが使えるかになどついて検証することを考えている。

改善された。理由は調査中であるが 、Web サービスベースのグ
リッド サービスに変更したことにより、ポーリング間隔による謝辞

待ち時間がなくなったためであろう。さらに JVOQL パーサお(株) および (株) セックの方々のご支援を頂いた。本研究は科学

よびスケジューラをリモートサービスではなくメソッド 呼び出

研究費補助金 特定領域研究「 IT の深化の基盤を築く情報学研

しにし 、メタデータ検索を UDDI から XML データベースにし究」の補助を受けておこなわれた。

たことにより、それらにかかる時間がほとんど 無視できるようになった。こうして、JVO プロトタイプ第 2 版は、実用システ
ムに大きく近づいたと言える。
さらにサービスおよびテーブルのメタデータを XML データ
ベースに登録することにより、統一的にメタデータを検索することができるようになった。特に観測波長等の天体カタログについてのメタデータを検索することにより、JVO からどんな天本研究の JVO プロトタイプの開発においては 、富士通

文

献[1] Kaifu, Norio, “SUBARU Telescope” Proceedings of SPIE, Vol.3352,
pp.14–22, 1998
[2] CDS (Centre de Données astronomiques de Strasbourg) http://cdsweb.ustrasbg.fr/[3] 大石雅寿, “Japanese Virtual Observatory の構築” 天文月報, Vol.95,
No.12, pp.566–575, 東京, 2002.
[4] JVO http://jvo.nao.ac.jp/[5] International Virtual Observatory Alliance http://www.ivoa.net/[6] FITS Support Office http://fits.gsfc.nasa.gov/[7] VOTable Documentation http://vizier.u-strasbg.fr/doc/VOTable/[8] SMOKA Science Archive http://smoka.nao.ac.jp/[9] 白崎裕治他, “天文学 DB 用検索言語の開発” DEWS2004, 2004[10] SAOImage DS9 http://hea-www.harvard.edu/saord/ds9/[11] 本田敏志他, “バーチャル天文台の研究開発” DEWS2004, 2004[12] Globus Alliance http://www.globus.org/[13] Hierarchical Triangular Mesh http://www.sdss.jhu.edu/htm/[14] Unified Content Descriptors http://vizier.u-strasbg.fr/doc/UCD.htx