付属資料1　SC98参加報告

電子技術総合研究所　高木浩光

　フロリダ州 Orlando の OCCC (Orange County Convention Center) で11月9日から13日まで開催された、国際会議「SC98」に参加したので、その報告を行う。また、続けてバージニア大学のLegionグループを訪問し、グローバルコンピューティングシステムについて調査を行ってきたので、その報告も行う。

1. SC98

　この会議は、かつて「Supercomputing'XX」と呼ばれていたものが、'97年より、名称を「High Performance Networking and Computing Conference」と改めたものである。Supercomputing'XXのころより通称として「SCXX」と呼ばれていたことから、今回も通称として「SC98」と呼ばれている。

　SC98は今回で、第11回目であるが、10周年にあたり、第1回の開かれた同じOrlandoで開催された。これまでの開催都市、展示を含めた参加者数を以下に示す。

　今後の開催地の予定は

とのことである。これらについては、SC Conference Seriesのホームページ

http://www.supercomp.org/

で確認することができる。

　今年の参加者は、technical program への有料登録者は2,025人、展示だけの入場者を含めると5,750人とのことである。前々回やや少なかったのを除けば、ここ6年間はほぼ横ばいといったところであろう。ホームページには、開示を認めた参加者3,200人の名簿が掲載されているが、日本からの参加者（日本の研究機関所属または日本名の企業関係者）は約200人であった。　

　会議は、日曜から月曜まで、チュートリアルとEducational Program が開かれた後、月曜夜の「Gala Openings」で展示会場が公開されて始まった。そして火曜から木曜までの3日間にわたってtechnical programや招待講演、パネル、展示、Exhibitor's Forumなどのセッションが平行して開かれ、最終日の金曜の午前にパネルセッションが開かれて終わった。

　筆者ら、電総研のグループは、前回に続き、研究展示(Research Exhibits)としてブースを出した。今回は十分な広さを確保して本格的な出展となった。筆者は、ブースの設営とブースでのプレゼンテーションに追われ、多くのセッションを見ることができなかった。以下は、主に展示開場にて調査した情報と、最終日のパネルセッションの内容を元に報告する。

1.1 展示

　大規模な展示はこの会議の特色の一つとなっている。今年も広大な会場に多くの企業の展示が派手に設営されていた。今年は、10のハードウェアベンダ (Compaq/Digital, Dell, Fujitsu, HP/Convex, Hitachi, IBM, NEC/HNSX, SGI, Sun Microsystems, Tera) を始めとして、ソフトウェア、大容量記憶装置、ネットワーク、出版、学会など69の企業等が出展した。最近になって会議の名前に「Networking」の文字が含められたことからも想像されるように、ネットワーク関連の展示が増えてきている。

　大学・研究所の展示も、年々盛んになってきており、今年は56の展示があった。NASA、ANL、ASCIなどの大研究所は例年のようにベンダー並みの展示を出していた。

　日本からは、電子技術総合研究所、原子力研究所計算科学推進センター、航技研、RWCP、RIST、九州大学、埼玉大学、筑波大学の8つのブースの出展があった。

　特に今回、電子技術総合研究所と筑波大学とは、「Tsukuba HPC Alliance」と称して、連続した区画を確保し、共同でセミナースペースを作り、関係者やゲストのセミナーを定期的に行った。外部からの講演者として、J. Dongarra 教授、R. Eigenmann教授、大阪大学の門林助手らが招かれた。筑波大学は、PAXの20年の歴史、CP-PACSのアーキテクチャ、応用などのパネルを示し、日本にあるCP-PACSとネットワークで繋いで、動作モニターとデモ計算を表示していた。電総研は、NinfとGlobal Computing Testbed を展示し、日本におけるグローバルコンピューティング研究のアクティビティを世界に印象づけることができた。

　RWCP (新情報処理研究組合) は、128台のPCクラスタや32台のAlphaクラスタを持ち込んで、企業並みの規模の展示をしていた。九州大学は、PPRAMについて展示、応用の一つとして、分子軌道計算エンジンの模型を出展していた。埼玉大学は毎年SCに参加しており、VRMLなどを用いた可視化による教育をテーマにしていた。

　日本から以外の展示に目を向けると、応用に関する展示が多かったように思われる。一部には、「どうhigh-performance computingに関係するの?」と首を傾げたくなるものもあるくらいだった。一方、基礎的な研究に目を向けると、そのほとんどが、グローバルコンピューティングあるいはJava関連のものだったように思う。もはや昔の「Supercomputing」というイメージではなかった。

　そのグローバルコンピューティング関連の最大の展示といえば、iGRID (The International Grid) である。これはイリノイ大学シカゴ校とインディアナ大学との共同で、vBNSの高速ネットワークを活用して、世界中の様々な分野の研究者と、広域分散処理、バーチャルリアリティ、大型データベースなどの技術を使って共同研究を行うプロジェクトである。

　これは、昨年のSC97でデモが行われた「GUSTO」と呼ばれたグローバルコンピューティングテストベッドを発展させて、国際的なものにしたものと言える。アメリカ国内だけでなく、カナダ、シンガポール、日本ともつながっている。「GRID」とは、広域ネットワークを介して組織間で互いの計算機を利用しあうメタコンピューティングのためのインフラの総称であるが、同様の目的を持つ研究機関の集会として「GRID meeting」が、この年の7月にシカゴで開かれた国際会議「HPDC」(High Performance Distributed Computing)と併設して開催されている。今回の「iGRID」も同様に、いくつものプロジェクトが共同でブースを出したものと言える。

　このiGIRDには日本からも参加している。日本とは今回の展示に間に合わせるかたちで、TransPAC (Asia-Pacific Advanced Network Consortium)のネットワーク(70Mbps)で結ばれた。日本との共同のデモとしては、大阪大学のグループにより、大阪大学に設置されている3MV ultra-high voltage電子顕微鏡をSC会場からリモート操作するデモが行われた。また、慶応大学SFCの村井純助教授が、デジタルビデオのインターネット経由の伝送技術のデモとして、慶応大学のキャンパスに対して「情報処理系論」の授業を展示会場から行った。

グローバルコンピューティング関連で他には、バージニア大学のLegionのグループが比較的広い区画を確保してデモを行っていた。Legionは既に実用の域に達しているようで、企業から製品化の話も出ているとのことである。

他には、今回、Java関連の研究の展示が目立った。Emory UniversityのIceTのグループ、UC BerkeleyのNinjaプロジェクトなどである。

　IceTは、Javaを用いた分散計算環境のひとつである。Javaを用いた分散計算環境の研究はじつに多数存在するが、IceTの特長は、JNI (Java Native Interface)を活用している点である。すなわち、計算ルーチンそのものは、ネイティブコード(各CPUアーキテクチャ用バイナリコード)で作成するものとしており、計算のプログラムはJavaで書かれるわけではない。多くのJavaによる分散計算研究が、マルチプラットフォーム性を活用するためにJavaを採用しているのに対してである。ならばいったい何のためにJavaを使うのか? 以前よりこの疑問を持っていた筆者は展示ブースでこの疑問をぶつけてみた。回答はこうだった。まず、Javaによる数値計算は現状では実行速度の点で難がある。したがって計算ルーチンはネイティブコードとする。Javaを使うのは、分散計算環境を実現するためのジョブ発行や負荷分散といったシステムのコア部分に対してであり、これはJavaのプログラミングのしやすさからという点と、JNIを様々な言語とのインターフェイスとして利用しているとのことだった。なるほど、たしかにJNIを多言語との汎用的なインターフェイスとして使うというアイデアはおもしろい、他にも活用できそうだとの感想を持った。ここで、セキュリティの確保はどうするのかと尋ねたところ、それは今後の課題であると、現在は解決法を持っていない様子だった。

　UC Berkeleyのブースの近くを通りかかったところ、「系列」という日本語の文字が目をひいた。これは何か? と尋ねたところ、Ninjaプロジェクトのデモのひとつであるとのことだった。「Ninja」は、Matt Welsh氏が開発を進めているJavaによる分散コンピューティング環境に関する様々なツール群である。そのコアとなるのは「NinjaRMI」という、Java RMIと同一の機能を一から実装しなおしたものである。なぜ実装し直しているのかと尋ねたところ、SunのRMIは自由に改造できないので、自由に改良できるものを持っておきたかったからとのことである。その上、RMIとの互換性を維持していきたいとのことだった。これをベースにして、「iSpace」と「MultiSpace」という、分散環境を構築中とのことだった。その内容をきくと、SunのJavaSpacesがやろうとしていることにたいへん近いようだった。JavaSpacesとの違いは? と尋ねると、プログラミングモデルに工夫があり、「Path」という、データフローモデル的なアプローチをベースとしているとのことであった。なお、「系列」というネーミングは変だと伝えておいた。

1.2 パネルセッション

　最終日(金曜)の昼でSC98は終幕となったのだが、その午前中を通してJavaに関するパネルセッションが設けられていた。そのタイトルは「Java Grande I: Rationale, Status and the Forum」と「Java Grande II: Issues and Futures」であった。同時に開かれている他のセッションに比べて聴衆の数は多かったとのことで、Javaによる高性能計算に関する関心の高さがうかがわれた。

　Java Grandeは、1998年3月にStanford大学で開かれたワークショップ「Java for High Performance Networking and Computing」の席で、Syracuse大学の Geoffery C. Fox教授が音頭をとって始められた、Javaを高性能計算に向いたものとするための様々な問題を解決していくことを目的としたフォーラムである。これまで、2つのワーキンググループ、「Numerics」と「Concurrency and Applications」に別れて議論が行われてきており、今回のパネルセッションの前半では、その成果報告が行われた。

　Numericsワーキンググループでは、Javaを数値計算に利用する際に問題となる5つの点を指摘している。それは、(1)複素数計算を実現しようとしたときに十分な性能が得られない点、(2)クラスをまたがった最適化が簡単ではない現状ではより高速化の簡単な「Lightweight」が必要だとする点、(3)基本型以外の値に対する演算を(メソッド呼び出しではなく)演算子によって記述できるためにオペレータオーバーローディングをサポートすべきだとする点、(4)浮動小数点演算ハードウェアの性能を完全に活かすことのできるように精度に関する言語仕様を緩和するべきだとする点、(5)現状のJavaの仕様である「配列の配列」によるものではない真の多次元配列が必要だとする点であった。このうち、(4)に関して提案された手法 (の一部) は、既に Sun の JDK 1.2 に採り入れられている。また、(1)と(2)については、Java言語設計者である、James Gosling氏やGuy Steele氏らも検討するつもりがあることを表明している。(3)についてはGosling氏もSteele氏も、言語が複雑になると難色を示しているが、今後このワーキングループの提案がどのように扱われていくかは興味深い。

　Concurrency and Applicationsワーキンググループでは、ベンチマーク等によって、RMIの性能の問題点を指摘している。RMIの性能が低いために、現状では並列計算には使えないとのことである。その性能の低さの原因を、オブジェクトserializationと、RMI自体の性能とに分けて議論されている。パネルでは、これらの性能評価の結果と、解決法に関するいくつかの提案をしていた。その他、MPI (Message Passing Interface) をJavaで利用することの標準化に関する議論がまとめられていた。

　後半のJava Grande IIでは、今後の展望について4つの講演があった。そのうち特に目をひいたのは、新たなコミュニティ「Datorr」の立ち上げを呼び掛けるものであった。Datorr とは「Desktop Access TO Remote Resources」の略で、グローバルコンピューティング、メタコンピューティング、およびWebコンピューティングに関する研究者が一堂に会してなんらかの標準化のための活動を行っていこうというもので、Argonne National Laboratoryの Gregorvon Laszewski氏が音頭をとっていた。既に、第一回のワークショップが、1998年10月8日から9日にかけて、同研究所で行われたとのことだった。これはJava Grandeの、concurrency / applicationsワーキンググループのミーティングと連続開催されそうで、Javaのコミュニティから派生したと言うことができる。このことからも、グローバルコンピューティングやメタコンピューティングとのJavaの関わりは大きいことが伺い知れる。この第一回ワークショップでは、まず、Datorrに関連すると思われる現存の研究プロジェクトのリストアップが行われたそうである。それらはタイトルだけを列挙すると以下の通りとのことだった。

・Akenti - A Distributed Access Control System

・Arcade: A Web-Java Based Framework for Distributed Computing

・CIF - DOE2000 Collaboratory Interoperability Framework Project

http://www-fp.mcs.anl.gov/cif/

・Common Component Architecture Forum (CCA Forum)

http://www.acl.lanl.gov/cca-forum/

・CUMULVUS http://acts.nersc.gov/cumulvs/main.html

・CPU-Usage Monitoring with DSRT System

http://dast.nlanr.net/Projects/monitor.html

・Distributed Resource Management for DisCom2

・Condor http://www.cs.wisc.edu/condor/

・DiscWorld http://www.dhpc.adelaide.edu.au/projects/dhpci/index.html

・EveryWare: A Toolkit for Building Adaptive Computational Grid Programs

http://nws.npaci.edu/EveryWare/

・Globus: The Globus Grid Computing Toolkit

・GlobusJ

・Habanero

・Harness: Dynamic Reconfiguration and Virtual Machine Management in the Harness Metacomputing System

・IceT http://www.mathcs.emory.edu/icet/

・JINI http://java.sun.com/products/jini/

・Llava http://www.tc.cornell.edu/UserDoc/SP/Llava_info.html

・Ligature: Component Architecture for High-Performance Computing

http://www.acl.lanl.gov/ligature/

・Legion http://www.cs.virginia.edu/~legion

・Ninja http://ninja.cs.berkeley.edu/

・NCSA Workbench Project

・Netsolve http://www.cs.utk.edu/netsolve/

・Northrhine-Westphalian Metacomputer Taskforce

http://www.uni-paderborn.de/pc2/nrw-mc/

・PAWS http://acts.nersc.gov/paws/main.html

・PARDIS http://www.cs.indiana.edu/hyplan/kksiazek/pardis.html

・POEMS http://www.cs.utexas.edu/users/poems/poems.html

・Sweb -- The Virtual Workshop Companion: A Web Interface for Online Labs

http://www.tc.cornell.edu/~susan/webnet98/

・UCLA Java Effort For Collaborative Computing

http://www.math.ucla.edu/~anderson/JAVAclass/CAMJava.html

・Teraweb http://www.arc.umn.edu/structure/

・UNICORE: Uniform Access to Computing Resources

http://www.fz-juelich.de/unicore

・WebSubmit: A Web Interface to Remote High-Performance Computing Resources

http://www.itl.nist.gov/div895/sasg/websubmit/websubmit.html

・WebFlow: Web Based Metacomputing

http://www.npac.syr.edu/users/haupt/WebFlow/

筆者らのNinfプロジェクトもまさにこのDatorrがスコープとする研究であり、今後このDatorrの活動に参加していくと約束してきた。

1.3 全般的な感想

　SCは、Supercomputingという元の名前からも想像されるように、以前はスーパーコンピュータのためのものであったが、応用面以外の研究の流れは、もはや大部分がネットワークコンピューティングの方向に向かっているようであったし、企業展示も、科学技術計算だけでなく、ハイエンドのインターネットサーバといった分野も参入してきており、もはやこの流れは止まらないように感じられた。

2. バージニア大学Legionグループ訪問

2.1 チュートリアル

　SC98が閉幕した翌週、筆者らはVirginia州Charlottesville市にあるバージニア大学のAndrew Grimshaw教授らのグループを訪問し、Legionプロジェクトに関して調査と討論を行ってきた。以下はこれについて報告する。

　到着一日目は、まず、Legionチームのメンバーから、Legionについてのチュートリアルを受けた。

　Legionとは何かを一言で表現するなら「メタ・オペレーション・システム」であるとのことだった。デスクトップのマシンから分散した資源を簡単にリモートに使えるようにするものとのことである。Legionは、分散ファイルシステムもサポートしており、他のグローバルコンピューティングシステムに比べると、もはや分散OSの世界に踏み込んでいるように感じられた。

　Legionは「オブジェクト・ベース」なシステムだと強調されており、計算機やユーザといった資源のすべてが「オブジェクト」として統一的に抽象化されている。オブジェクトには、ディレクトリ構造で名前が付けられており、コマンドレベルでこのディレクトリ構造の操作ができる。すべてがオブジェクトで表現されていることから、素性はとてもよさそうだが、スピードと安定性が気になった。実行速度に関しては何も見せてもらえなかったが、システムの立ち上げの様子を見せてもらったが、非常に遅かった。いつまで経っても終わらず、話題がなくて気まずい思いをしたほどだった。これは、ブートストラップとしてシステムのオブジェクトを構築しているからのようで、一度構築してしまえば後はこんなには遅くはないとのことらしい。

　今回受けたチュートリアルでは、セキュリティに重点が置かれていた。すべてのオブジェクトのリファレンス(LOID)に公開鍵が含まれており、それを用いた強固で柔軟なセキュリティが実現されているそうである。しかし、すべてのメッセージ通信において、公開鍵暗号を使った認証が行われるとすると、実行速度に問題があるように思われた。

　スケジューリングに関しては、クラス・オブジェクトが行うとのことだった。各クラスオブジェブジェクトの実装によって、スケジューリングポリシーをクラス毎にき決められるからとことらしい。しかし、この方法では、スケジューリングポリシーがオブジェクトクラスごとに固定してしまうので、スケジューリングオブジェクトは外付けにしようということになりつつあるようだ。

　GCはしないとのことだった。クラスオブジェクトがつねにインスタンスへのポインタを握っているので、インスタンスへのリファレンスがなくなることはあり得ないというのが一つの理由。使われないオブジェクトは自動的に inart になり vaults に入ってしまうからいいのだ、というようなことも言っていた。しかし、長期的に安定して動かすためには何らかのGC的なものがないとまずいのではないかと感じた。

　テネシー大学のJack Dongarra教授らのNetSolveプロジェクトと共同で、Legion <-> NetSolve との協調処理を実験しているとのことだったので、詳しく話をきいたところ、NetSolveのAPIを実装しているだけで、NetSolveのコンポーネントやプロトコルを使っているわけではなかった。つまり、Legionの実行モジュールのひとつとしてNetSolveのクライアントが位置付けられていた。

　同様の方法で、MPI2やPVM、CORBAへのラッパーが用意されており、既存のコードをLegionシステムに載せて動かすことは簡単だと強調されていた。このため、計算プログラムの記述に利用可能な言語としては、FORTRAN、C、C++、Javaなどと多くのものがカバーされていた。

2.2 セキュリティに関する議論

　翌日は、それぞれの分野を担当している方と、詳細なディスカッションを行った。筆者はセキュリティを担当しているAdam J. Jerrari氏とお話しした。

　まず、速度の問題はないかとたずねた。特に、鍵の生成に非常に時間がかかるはずで、オブジェクトを作成するたびに、鍵を生成するのでは、実用にならないのではないかとたずねた。その点は課題だと認識しているとのことで、前日のデモで立ち上がりが非常に遅かったのもそれが原因であるとのことだった。改善策として、アイドル状態のときにあらかじめ鍵を生成しておく方法などを検討しているとのことだった。

　次に、鍵生成時に使用する乱数のランダム性が不十分だと、鍵が破られてしまうのではないか? という点を指摘してみた。ウェブブラウザなどの人間の操作が介入するものでは、そのタイミング等によってランダム性を実現できるが、Legionのように、機械的に連続して鍵を生成するシステムでは、そこが問題になるはずだというわけである。この点については現状では対策していないとのことだった。そのためには、プラットフォームとなるOSの力を借りる必要があって、いくつかのOSでは、そういった要求に応えられるランダム性を持つ乱数器の機能を持っているが、多くのOSが備えていない点が問題だとのことだった。

　次に、セキュリティホールの危険性について議論となった。ウェブブラウザのようにたくさんの人が使うソフトウェアになれば、多くの人がセキュリティホールがないかと調べてくれるが、そうでない限り、セキュリティホールは発見されにくい。そこまで普及すればうれしいのだが…という話題になった。

　彼は、元々はモバイル・エージェントの研究をしていて、分散プログラムでのセキュアな実行について関心を持ったとのことだった。モバイル・エージェントの研究をやめてしまったのは、それにはアプリケーションがないからとのことだった。その点で、Legionは、分散計算というはっきりとした目的があるでやりがいがあるとのことだった。

2.3 感想

　Legionは既に実用化に向けて動き出しているようだった。そのためにセキュリティに対してこのところ力を入れているとのことだ。こうしたシステムには、他にもCondorやGlobusなどがあり、乱立状態であるが、他のシステムとのコラボレーションを重視しているようで、各システムとのゲートウェイの開発の計画があるそうだ。そろそろ何かしらの標準化が必要ではないかと感じたが、しばらくはこのまま乱立状態が続くように思われた。

謝辞

　本稿をまとめるにあたって、東京大学の小柳教授、電子技術総合研究所の中田研究官からいろいろとご教示頂いた。ここに感謝する次第である。