1. パブリック・リソース・コンピューティング

世界中の計算パワーとディスクスペースの主な部分は、 もはやスーパーコンピュータ・センタやマシン・ルームの中にあるのではなく、 一般市民の所有する何億ものパーソナル・コンピュータやゲーム機本体の中にあります。 パブリック・リソース・コンピューティングとは、これらの資源(リソース)を、 科学的なスーパーコンピューティングをするために使うことです。 (パブリック・リソース・コンピューティングは、 グローバル・コンピューティング、あるいは、ピアー・ツー・ピアー・ コンピューティングとも呼ばれることがあります。 ) このパラダイムによって、今までできなかった研究ができるようになりました。 さらに、現在の科学研究に対する一般市民の認識を鼓舞し、 科学への興味で集まったグローバルなコミュニティに、触媒として作用します。 また、科学の進展方向を制御する手段を一般市民に与えます。

パブリック・リソース・コンピューティングは、1990年代の中ごろに、 2つのプロジェクトとして現れました。 GIMPS と Distributed.net です。 著者のグループは、1999年に SETI@home [1] を開始し、世界中で何百万人もの参加者を引きつけてきました。 現在、 SETI@home は、約百万台の計算機上で走っており、継続的に 70 TeraFLOPS の計算速度を提供しています。 (それに比べて、 従来の最大のスーパーコンピュータである^訳注1 NEC社の地球シミュレータは、約 35 TeraFLOPs の性能です)。

潜在的なリソースの量はより大きいものです。 インターネットに接続している PC は急速に増えており、 2015年には、10億台に達すると予測されています。 これらの PC を集めれば、PetaFLOPs の何十倍、何百倍もの 計算パワーになるかもしれません。 パブリック・リソースを活用するというアプローチは、 計算パワーだけでなく記憶容量についても適用できます。 もし、1億台のコンピュータ利用者が、 それぞれ 10G バイトの記憶容量を提供したら、合計では ( Exabyte、言い換えると 10¹⁸ バイトに達するので) どんな集中型の記憶システムの容量をも超えるものになります。

このような資源量の見込みや、有望なアプリケーションがたくさんあるにもかかわらず、 大きな規模で パブリック・リソースを使うプロジェクトは多くは現れてきませんでした。 その理由の1つは、適切なミドルウェアの不足です。 (つまり、 クライアントとサーバのソフトウエア、管理ツール、利用者向けウェブ機能などなど・・・ が足りなかったのです)。 いくつかの、オープンソースを使うシステムが開発されてきました。 たとえば、 Cosm や jxta、XtremWeb [4]です。 しかしこれらは、 必要な機能の一部しかもっていません。 商品になっているものには Entropia [2] と United Devices のものがあり、 機能的には揃っているのですが、無料では使えません。

1.1 グリッド・コンピューティングとの対照

パブリック・リソース・コンピューティングもグリッド・コンピューティングも、 今あるコンピューティング資源をより有効に使うという目標で一致しています。 しかし、これら2つの考え方には大きな差があるので、 現在のグリッド・ミドルウェア[5]が、 パブリック・リソース・コンピューティングに適切であるとは思えません。

グリッド・コンピューティングには、組織が所有する資源を使います。 つまり、スーパコンピュータ、クラスタ、PCなど、 大学や研究所あるいは会社が所有しているものを使います。 これらの資源は、ITを職業とする人達によって集中的に管理され、 ほとんどの時間、電源を入れられて広帯域の接続でネットワークにつながれています。 そして、組織と組織の間には対称な相互関係があります。 つまり、 個々の組織はリソースを提供することもあれば、使う側になることもあります。 悪意のある振る舞い−−意図的な計算結果の変造のようなこと−−を行えば、 そのシステムの外側で、たとえばその実行者を解雇などして、対処されるでしょう。

これと対照的に、パブリック・リソース・コンピューティング では、プロジェクトと参加者との関係は非対称です。 典型的なプロジェクトは小さな学術的グループであり、 コンピュータそのものについての専門知識や人数の面では大したことはありません。 ほとんどの参加者は Windowsや Macintosh あるいは Linux PCをもつ個人です。 インターネットには、電話線、ケーブルモデム、DSLで接続していて、 しばしば、ネットワークアドレス変換(NAT) やファイヤウォールを介してネットワークにつながっています。 それらのコンピュータは、電源もネットワーク接続もしばしば切ることがあります。 参加者はコンピュータの専門家ではありません。 それらの人々が参加してくれるのは、 そのプロジェクトに興味があって、かつ、功績(credit)やスクリーンセイバーの画像のような 「インセンティブ」を受けとる場合だけです。 プロジェクト側には、参加者を縛り制御する方法はありませんから、 悪意ある行動を予防することはできません。

従って、パブリック・リソース・コンピューティングがミドルウェアに求めるものは、 グリッド・コンピューティングの場合と異なります。 たとえば、 BOINC の冗長計算の機能、不正に耐える計数システム、 参加者が体裁を変更できるアプリケーショングラフィクスへの支援、といったものは、 グリッド・システムには必要ありません。 実は、これ以降の内容は、 ほとんどパブリック・リソース・コンピューティングを第一の用途とするものです。

一方、グリッド・コンピューティングはパブリック・リソース・コンピューティング にはない要件をたくさん持っています。 グリッドのアーキテクチャは、商用であれ研究用の学術的なものであれ、 既存のたくさんのシステムに適合しなければなりません。 さらに、 資源の発見とアクセスのための、一般性のある機構を提供する必要があります。 要するに、この何十年かコンピュータサイエンスが盛んに研究してきた、 動的で異種混合の分散システムにおける全ての課題を、 グリッドのアーキテクチャは解決しなければなりません。 その結果、Open Grid Services Architecture [7] のようなものが登場してきました。 これは、複雑さと、 さらにある程度はパフォーマンスの代償のもとに、一般性を達成します。

2 BOINC

BOINC (Berkeley Open Infrastructure for Network Computing) は、パブリック・リソースを使った分散コンピューティングの ためのプラットフォームです。 BOINC は U.C. Berkeley の Spaces Sciences Laboratory で開発中です。 開発は、 SETI@home を作り、今もその運用を続けているグループが行っています。 BOINC はオープンソースであり、 http://boinc.berkeley.edu からソースを入手できます。

2.1 BOINC の目標

パブリック・リソース・コンピューティングを導入するに際しての障壁を低くします。 BOINC は、科学研究者がほどほどのコンピュータスキルだけで、 大きなパブリック・リソース・コンピューティングのプロジェクトを立ち上げ、 運用ができるようにします。 立ち上げ初期に必要な仕事は1週間程度、 保守には、週あたり1時間程度でできるようにするのが目標です。 BOINC を使って作ったプロジェクトのサーバは、1台ですませることも可能です。 そのサーバで使うソフトウエアは、 普及しているオープンソースのソフトウエア (Linux, Apache, PHP,MySQL, Python)です。

自律的な各プロジェクト間で、資源を共用すること。 BOINC をベースにしたプロジェクトは、自律的です。 [つまり、] プロジェクトはどこかで集中管理されたり、登録が必要ということはありません。 それぞれのプロジェクトは自分のサーバを運用し、それ自身だけで動作できます。 そうであっても、PC 所有者はプロジェクトが独立していることにわずらわされることなく、 複数のプロジェクトに参加できます。 参加者は、各プロジェクトに対して「資源占有率」(resource share) を指定できるようになっており、この数値により、稀少な資源(CPUやディスク容量) をどのようにプロジェクト間に分け与えるかを決めます。 ほとんどの参加者が複数のプロジェクトに登録してくれれば、 全体としての資源利用率は改善されます。 というのは、あるプロジェクトが修理のために一時閉鎖されたとしても、 別のプロジェクトが一時的にその分の計算機パワーを譲り受けることができるからです。 また、1台のコンピュータの中でも、たとえばそのCPU時間をあるプロジェクトに使わせながら、 ネットワーク能力は別のプロジェクトのファイル転送のために使わせることによって、 資源利用率を上げられるでしょう。

多種多様なアプリケーションを支援すること。 BOINC は、広い範囲のアプリケーションに適応できます。 データの配付のために、柔軟でスケーラブルな仕組みを提供しており、 スケジューリング・アルゴリズムは、[計算からの] 要件を考慮にいれて知的に仕事を資源に割り当てます。 一般的な言語(C, C++, FORTRAN) で書かれた既存アプリケーションならば、ほとんど手を入れることなく BOINC アプリケーションとして動作させることができます。 アプリケーションは複数ファイルで構成されていても構いません (たとえば、複数のプログラムとそれらを調整する役のスクリプトという形)。 新しい版のアプリケーションを展開するのに、参加者の手をわずらわす必要はありません。

参加者に報いること。 パブリック・リソース・コンピューティングの プロジェクトは、参加者を引きつけ参加させつづけるために、 「インセンティブ」を与える必要があります。 多くの参加者にとっての主要なインセンティブは、功績(credit)[を認めてもらうこと] です。 ここで言う功績とは、個々の参加者がどれだけ計算に貢献したかを目に見える数字にしたものです。 BOINC は功績の集計システムをもっており、複数の資源種別 (CPU, network, disk)の使用状況を功績の値に反映することができます。 このシステムは、複数のプロジェクトに渡って共通に使えるものであり、 「不正行為」に対して高い抵抗力をもちます。 (ここで 「不正行為」 といっているのは、まともに計算をせずに功績を得ようと試みることです。 ) また、BOINC はプロジェクトのアプリケーションに、 ビジュアルなグラフィクスを簡単に追加できるようにします。 このグラフィクスを作れば、スクリーンセイバーも提供できます。

2.2 BOINC を使っているプロジェクト

たくさんのパブリック・リソース・コンピューティングのプロジェクトが BOINC を使っています。 これらのプロジェクトからの要件が、 BOINC の設計を方向づけました。

SETI@home, 初代の SETI@home プロジェクト[1] の後継プロジェクトです。 このプロジェクトでは、 Arecibo 電波天文台からの電波望遠鏡データをデジタル信号処理します。 BOINC を使ってこのプロジェクトを作り直す開発が行われてきており、 現在は、既存の SETI@home 参加者たち(活動している参加者が 50万人以上います) を、この BOINC ベースのものに移行させる段階にあります。 SETI@home は、クライアントのディスクをデータの保管に使う ^訳注2 でしょう。 これによって、集中型のテープ保管所が必要なくなります。

Predictor@home: [11] Scripps Research Institute に本拠地があるこのプロジェクトは、 蛋白質の振る舞いを研究するために、 マクロ分子動力学のためのFORTRAN プログラム、CHARMM を使います。 システムは Scripps の中では稼働状態になっており、一般公開開始に向けて準備中です。

Folding@home[10]. このプロジェクトの本拠地は Stanford University にあります。 蛋白質の折り畳み、折り畳みの失敗、凝集、およびそれらに関連する疾病を研究しています。 新しい計算手法と分散コンピューティングを使い、 いままでに比べ千倍から百万倍の時間の長さにわたってシミュレーションを行います。 BOINC をベースにしたプロジェクトが実装されてきており、 テストをしているところです。

Climateprediction.net[14]. このプロジェクト(本拠地は Oxford University)の目的は、 コンピュータ・シミュレーションに基づく長期気候予測の不確実性の度合を定量化し、 さらにはその不確実性を減らすことです。 目標を達成するため、 天下りのシナリオ(初期条件と境界条件、さらに自然の要素と人間により作られた要素を含みます) および内部モデルパラメタのもとで、多数のシミュレーションを実施します。 この Climateprediction.net アプリケーションは、 それ自身百万行におよぶ FORTRAN プログラムです。 50年ぶんのシミュレーション実行(PC で約 3ヶ月計算にかかります)の結果として、 2 GB の詳細なファイルを作り出します。 これらの大きな出力ファイルをアップロードして吟味するべき場合が、 ほんのわずかな率ですが発生します。 それは、たとえば、[別途出力される] 小さいサマリのファイルが、 そのシミュレーションモデルにはバグがあるかもしれないと示している場合です。

Climate@home. このプロジェクトは、 NCAR, MIT, UCAR, Rutgers, Lawrence Berkeley Lab, および U.C. Berkeley にいる研究者たちの協調活動です。 科学的な目標は、Climateprediction.net のそれと似たものですが、 モデルには NCAR Community Climate System Model (CCSM) を使うことになります。 このプロジェクトは Climateprediction.net と互換性を高め、 冗長な努力をできるだけ減らし、 さらには異なる気候モデルの比較を体系的に可能にするため、 協調することになります。

CERN projects. CERN (スイス、Geneva) では、あるBOINC ベースのプロジェクトを 組織内の 1,000 台の PCに展開ずみです。 2004年10月の50年記念にあわせて、 その公開番プロジェクトを開始することを計画しています。 このプロジェクトの現在のアプリケーションは FORTRAN で書かれたプログラムです。 このプログラムは、個々の超伝導磁石のパラメタの関数としてその振る舞いが変化する LHC (Large Hadron Collider)をシミュレートします。 CERN の研究者は他のアプリケーションも研究しています。

Einstein@home. このプロジェクトに参加している研究者は、 University of Wisconsin, U.C. Berkeley, California Institute of Technology, LIGO Hanford Observatory, University of Glasgow, および the Albert Einstein Institute の人達です。 目的は、回転する中性子星から発する類の重力波を検出することです。 この種の重力波は、高度に選択的なフィルタリング・ テクニックを使ってはじめて検出できるものなので、猛烈な計算能力を必要とします。 このプロジェクトは、 Laser Interferometry Gravitational Observatory (LIGO) および British/German GEO6000 gravitational wave detector で採取したデータを解析するでしょう。

UCB/Intel study of Internet resources. このプロジェクトは、U.C. Berkeley Computer Sciences Department とIntel Berkeley Research Laboratory の研究者による共同研究です。 消費者のインターネット利用の構造と性能、 家庭用PC の性能、信頼性、利用特性の研究を進めるために、 どのような資源がピアー・ツー・ピアー・サービス のために利用できるかを理解しようとしています。 このプロジェクトでは、一日の特定の時刻または時間帯に処理をする必要があります。 この処理の最中は、BOINC の他のアプリケーションは一時中断する必要があります。 BOINC API はこの要件を満たしています。

2.3 BOINC 実装の概観

パブリック・リソース・コンピューティング を実施する組織や研究グループに一つずつ BOINC プロジェクトを作ります。 プロジェクトは、1つのマスター URL によって識別され、 そのURLはプロジェクトのウェブサイトのホームページを指すとともに、 スケジューリング・サーバ群のディレクトリとしても機能します。 参加者はプロジェクトに登録します。 1つのプロジェクトで走らせるアプリケーションは、ひとつでも複数でも構いません。 それらの内容は、時間がたつにつれて変えてゆくことができます。

BOINC プロジェクトは関係データベースを使っており、 その中に、アプリケーション、プラットフォーム、版(version)、 ワークユニット、リザルト、アカウント、チームなどの記述を格納しています。 このデータベースを中心にBOINC プロジェクトのサーバ複合体が出来上がっています。 サーバ機能を実行するのは、ウェブ画面をサービスするプログラムと、 デーモンプロセス群です。 デーモンプロセスのひとつ、 スケジューリング・サーバは、 クライアントからの RPC を処理するサーバであり、 クライアントに仕事を与え、完了した計算結果の報告を受けとります。 データ・サーバは、ファイルのアップロードを処理します。 証明書のしくみで確かめた正規のファイルだけを、 事前に記述しておいた大きさの範囲で受けとります。 ファイルのダウンロードは、単純な HTTP [サーバのしくみ] で処理されます。

BOINC から提供するツールの中にｃvロジェクトの新設、開始、停止、および 問合わせのためのものがあります (Python スクリプトと C++ インタフェース)。 これらのツールは、新しい種類のアプリケーションの追加、 プラットフォーム、アプリケーションの版の追加をし、 ワークユニットの生成とサーバ性能の監視もします。 BOINC はシステムプログラマやITの専門家が使うものではなく、 科学者が使うように設計されています。 ツール群はシンプルで説明書も良く整っていますから、 機能を充分にもったプロジェクトが数時間のうちに作り出せます。

参加者がプロジェクトに加わるときには、 そのプロジェクトのウェブサイトを訪れて登録フォームに入力してもらい、 BOINC クライアントをダウンロードしてもらいます。 このクライアントは以下のいくつかのモードで動作します。 スクリーンセイバーのモードでは、走っているアプリケーションのグラフィクスが表示されます。 Windowsサービスのモードでは、誰もログオンしていなくてもクライアントが走り、 エラーがあればデータベースに記録されます。 アプリケーションのモードでは状況表示を表形式で行い、 プロジェクト、仕事、ファイル転送、ディスク使用量を見ることができます。 UNIX コマンドライン・プログラムのモードでは、標準入力、標準出力、標準エラー出力 (stdin, stdout, stderr)を通じてやり取りを行いますので、 cron ジョブや スタートアップ・ファイルから実行することができます。

BOINC から提供するツールの中には、 参加者がこのクライアント・ソフトウエアをリモートから多数のマシンにインストールし、 そのクライアントを複数のプロジェクトに参加させるために使えるものがあります。

3 設計上の課題と解決

3.1 計算とデータの記述方法

BOINC が抽象化した、ファイル、アプリケーションおよびデータの概念は、 シンプルではあるが深みのあるものです。 プロジェクトは、アプリケーションの版(複数)を種々のプラットフォーム (Windows, Linux/x86, Mac OS/X, など)に対して定義します。 1つのアプリケーションは、任意のファイルの集まりであって構いません。

ワークユニット とは、ある計算に対しての入力となるものを表現したものです。 つまり、そのアプリケーション(ただし、版は限定しません)と、 入力ファイルへの参照の集まり、そしてコマンドライン引数と環境変数の集合(複数) のことです。 個々のワークユニットが持つパラメタには、 計算やメモリ、記憶容量についての要件と、計算完了までのだいたいの期限といったものがあります。 リザルトは、計算の結果を表現します。 つまり、ワークユニットへの参照と、 出力ファイルへの参照の一覧とからなっています。

[BOINC で言う] ファイルは、アプリケーションの版あるいは、ワークユニット、 リザルトと結びつきがあるもの[を対象にして抽象化とした概念] です。 ファイルは、プロジェクトの範囲で重複のない名前をもち、 [一度作られたら内容が] 変化しません。 ファイルは複製することができますので、 ファイルの記述には、そのファイルをダウンロードあるいはアップロードできる URL(複数)の一覧を含んでいます。 ファイルには属性を付けることができます。 それら属性が示すのは、 たとえば、計算が終わった後もそのファイルを消さずにその計算機に残すべきであるとか、 デジタル署名により本物であることを検証しなければならないファイルであるとか、 ネットワーク転送時には圧縮しなければならないファイルであるか、といったことです。

BOINC クライアントがスケジューリング・サーバと通信するときには、 計算が終わった仕事をサーバへ報告し、 上述の諸々のものをまとめて記述した XML文書をサーバから受けとります。 その後そのクライアントは、[受けとったXML文書に従って] ファイルをダウンロードおよび アップロードし、アプリケーションを走らせます。 クライアントは併行性を最大に発揮するために、 可能なら複数 CPU を使い、かつ、通信と計算をオーバラップさせます。

BOINC の計算システムは、分散記憶の設備としても機能します (計算の入力または結果の格納、または、 分散コンピューティングとは関連のないデータの格納もできます)。 この記憶設備の機能は、Gnutella あるいは PAST [13]、 Oceanstore [9] のような ピアー・ツー・ピアー の格納システムとは大きく異なります。 上記のピアー・ツー・ピアーの格納システムでは、 ファイルはどのピアーによっても生成できるものであり、 ファイルの所在を知っている集中型データベースは存在していません。 そのため、BOINC では問題にはならない種類の一連の技術課題 (たとえば、ファイルの名前づけとファイル位置のような) に行き当たります。

3.2 冗長コンピューティング

パブリック・リソース・コンピューティングのプロジェクトは、 誤りを含む計算結果を扱う必要があります。 これらの[誤りを含む] 計算結果は、 誤動作しているコンピュータから発生したり (典型的にはオーバクロックが原因)、 ときおりは悪意ある参加者から送られてきます。

BOINC は、誤りのある計算結果を認識して排除するための機能、 冗長コンピューティング、を提供します。 プロジェクトは、各ワークユニットに対していくつリザルトを生成するべきか(N個)を指定します。 N 以下の［別途指定した］個数 M だけ、分配したリザルトの計算が済んだら、 アプリケーションに固有な関数を使ってそれらの結果を比較し、 標準的な計算結果を選択しようとします。 もし[計算結果の中で] 一致がみられない場合、あるいは、 計算結果が失敗に終わっている場合、 BOINC はそのワークユニットについて、 [追加の計算結果を集めるために] 新しいリザルトを生成します。 この［新しいリザルトを生成するという］過程は、 リザルト個数の累計が[あらかじめ決めておいた] 上限に達するか、 タイムアウト限界に達するまで続けられます。

悪意ある参加者は BOINCシステムの裏をかくために、多数のリザルトを獲得し、 定足数に足るリザルト群を推測して作り出す可能性があります。 BOINC はこのような企てを困難にするために、 特定のワークユニットから生成するリザルトは、 ある参加者について高々1つしか配らないという手段を持っています。 プロジェクトによっては、特定の計算機に一日に配付するリザルト数に上限を設けることもできます。

BOINC はいくつかのサーバ側デーモンプロセスによって、 冗長コンピューティングを実現しています。 それらのデーモンプロセスは以下のものです。

• transitioner は、冗長コンピューティングの論理を実装しています。 つまり、必要に応じて新しいリザルトを生成し、異常な状況が発生したことを検出します。
• validater は、リザルト群を検査して標準的リザルト (canonical result)を選び出します。 この処理には、 アプリケーション固有なリザルト比較関数を含みます。
• assimilater は、新たに見つけた標準的リザルトを処理します。 このデーモンに含まれるアプリケーション固有関数は、 典型的にはそのリザルトを解析して、[取り出した］内容を科学データベースに追加します。
• file deleter は、 不要になった入力ファイルおよび出力ファイルをデータ・サーバ上から消します。

BOINC のアーキテクチャでは、サーバとデーモンは異なる計算機で走らせることができるようになっており、 複製をたてることも可能です。 これによって、BOINC サーバはスケーラブルになっています。 プロジェクトの一部分が停止してしまっても、いくつかのデーモンは走ることができるので、 可用性も向上しています(たとえば、 スケジューリング・サーバと transitioner は、 サイエンス・データベースがたとえ停止していても稼働できます)。

ある種の数値計算アプリケーションは[いろいろなものに敏感で]、 同一のワークユニットであっても、計算をするマシンのアーキテクチャの違いや、 オペレーティング・システム、コンパイラの種類、コンパイル時フラグなどの違いによって、 異なる結果を出してしまいます。 アプリケーションがこのようなものであるときは、 計算結果に数値上のばらつきがあってもそれで正しい場合と、 本当に異常な計算結果が含まれている場合とを見分けるのが難しくなるでしょう。 このようなアプリケーションのために、 BOINC は、 一様な冗長計算(homogeneous redundancy)という仕組みを提供します。 この機能を有効にすると、 BOINC スケジューラは、 特定のワークユニットに対して生成した [複数の] リザルトを、 同一の OS 名と同一の CPU ベンダーの計算機だけに送るようになります。 この場合、リザルトの比較に「厳密な一致」という基準が使えることがあります。 BOINC は、リザルトの正しさを確かめるその他の方式 [8] とも整合性があります。

3.3 失敗と再試行の緩和

パブリック・リソース・コンピューティングのプロジェクトは、 何百万人もの参加者と比較的控えめな規模のサーバ複合体との組合わせになるかもしれません。 全ての参加者がもし同時にそのサーバに接続しようとしたら、 多くの場合、思いも寄らない過負荷状態が生じ、長く続いてしまいます。 このようなことが起こらないように、BOINC にはいくつもの仕組みがあります。 クライアント・サーバ間のすべての通信では、通信の失敗が生じたときに、 指数関数的に再試行間隔を長くとります(exponential backoff)。 これにより、 BOINC のサーバが長期に渡る停止から回復したときでも、 [クライアントからの] 接続の頻度は長期的な平均値に収まるでしょう。

この指数関数的に試行間隔を長くとる方式は、計算上の異常についても適用されています。 ある計算機の上で、なんらかの理由でアプリケーションが[実行開始後] すぐに失敗終了したとしても、 BOINC のクライアントはサーバに繰り返し接続をしてしまうことはありません。 その失敗回数に応じて接続時期を遅らせます。

3.4 参加者の好みの設定(preferences)

コンピュータの所有者が分散コンピューティングのプロジェクトに参加するのは、 多くの場合、参加によって不便になることがなく、コストもかからず、 リスクもない場合だけです。 BOINC では、 参加者が自分の持つ資源をどのように使わせるかを、 参加者自身で制御できるようにしました。 この制御を general プレファレンスと呼びます。 参加者は自分のマシンに仕事を溜め込む量について、 時間経過を考慮に入れた上限をこのプレファレンスの中で指定します。 (この指定値で、ネットワーク接続動作の頻度が決まります)。 このほかに指定できるものとしては、マウスやキーボードの操作が行われているときでも BOINC が計算の仕事をしてよいかどうか、 BOINC が計算の仕事をしてよい時間帯、 BOINC が使ってよいディスク量、 BOINC が使ってよいネットワーク帯域幅、などがあります。 これらのプレファレンスは、ウェブインタフェースを使って編集することができ、 そのアカウントで参加している全ての計算機に[編集した] 値が伝播されます。 参加者は、コンピュータの所在、つまり、自宅(home)、仕事場(work)、学校(school) という種別ごとに、別々のプレファレンスを作ることができます。

一見明白ではない制御が、ある部類の参加者にとっては重要であることがあります。 たとえば、いくつかの国では DSLサービスに月ごとの転送量上限があります (典型的には何百メガバイトという値です)。 BOINC では、アップロード量、ダウンロード量、およびその2つの合計値について、 任意の期間における上限値をプレファレンスとして指定できます。 いくつかの BOINC を使ったアプリケーションでは、 とても浮動小数点演算をとても多く使うので、 CPU チップが過熱してしまうことがあります。 BOINC は、このようなアプリケーションを走らせるときに、 処理中となる時間率を参加者が CPU ごとに指定できます。

3.5 功績(Credit)と その計数システム

BOINC の提供する計数システムは、「功績(credit)」というただ１種類の単位を扱います。 この功績とは、計算量、記憶量、ネットワーク転送量を重みづけして合成したものです。 功績の計測のしかたにはいくつものやり方があります。 とくに指定をしなければ、 BOINC のクライアントは各CPUについてベンチマークテストを走らせて [時間あたりの計算量を得ます。 そして]、 計算に要した経過時間とこのベンチマークの結果をもとに、 「申請する功績の大きさ」をリザルトごとに決定します。 上述の冗長コンピューティングによって、 「不正行為」をしても功績を得ることは難しくなっています。 というのは、個々のリザルトはそれぞれの功績の大きさを申請してくるのですが、 付与される功績の大きさは、 正しい計算結果が申請した値の平均値あるいは最小値であるからです (平均なのか最小なのかはプロジェクトごとの方針で決められます)。

SETI@home での我々の経験から、 参加者はこの功績によって強く動機づけられることが分かっています。 とくに他の参加者との相対的な順位に興味をもっています。 この情報は、典型的にはウェブページ上のリーダーボードに載せます。 リーダーボードには、参加者の順位あるいは参加者が組んだチームの順位が表示されます。 リーダーボードの情報に対し、 カテゴリ分け、フィルタリング、並べ換えをして表示しなおすやり方には、 いろいろなやり方があります。 たとえば、 あるリーダーボードには特定の国から参加している人だけを表示していますし、 別のリーダーボードでは 1 台の PC で参加している人だけを対象にしています。 順位づけを功績の合計値で行うか、最近の平均功績で行うかというバリエーションもあります。 このような様々な見せ方の全てを提供するかわりに、 BOINC は、功績に関連したデータを外部提供する仕組みを備えました。 (このデータは、参加者、チーム、計算機のレベルです)。 データは XMLファイルとして提供されるので、 第3者の運営による功績統計表示サイトが、 これらのデータをダウンロードして処理できます。 このようなサイトが現在でもいくつかあります。

この計数システムの一部として、 BOINC はプロジェクトを越えた参加者の識別方法を提供しています。 これにより、同一のメイルアドレスを持つアカウントが、 異なるプロジェクト上にある場合でも、それらを同一のものとして扱うことができます。 しかも、この仕組みではＥ−メイルアドレスの値を[外部から] 推定できません。 リーダーボードを表示するサイトでこの識別方法を使えば、 複数のプロジェクトに渡る功績を合計した形で、統計情報の表示ができます。

参加者は満足感をすぐに得たいと要求してきます。 つまり、 少なくとも毎日、功績の合計が伸びていくのを確かめたいのです。 ですから、長時間かかるワークユニット(気候予測のプロジェクトのような場合です) では、その1つの計算が進んでいく最中に、 功績がすこしずつ積み上がるように付与される必要があります。 BOINC は、トリクル・メッセージという仕組みを提供しています。 これは、通常流れているクライアント・サーバ間 RPC メッセージに便乗する形で動作し、 信頼性と順序性を保ちながら、双方向の非同期メッセージ転送を提供します。 この仕組みは、功績や計算状況のサマリ報告を運ぶのに使えます。 計算状況のサマリ報告をした場合、計算が予想外の進み方をしていたら、 それを中断させるメッセージを応答として送ることもできるでしょう。

いくつかのプロジェクトは、CPUではない資源で計算をします。 たとえば、SETI@home プロジェクトは NVIDIA 社と共同で、 SETI@home の信号処理の主要部を NVIDIA グラフィクス・コプロセサ・チップ上で実行する SETI@homeアプリケーションの版を作成しようと作業しています。 こうするためには、BOINC にも追加要件がでてきます。 資源の利用率を最大化するため、[クライアントの] ローカル・スケジューラは、上記のようなアプリケーションを、 CPU ばかり使うアプリケーションと併行的に走らせ[ることができ] なければなりません。 BOINC API を使って、計算した量を(たとえば、FLOPsの単位で) アプリケーションからコア・クライアントに報告することができるようにしました。 というのも、 もはやベンチマークの結果と CPU 時間とでは、計算量を測れないからです。 BOINC API を使うと、アプリケーションはアーキテクチャに依存した機能 (たとえば、GPU があることや、その型番号) について[サーバ] に情報を伝えることができるようにもしてあります。 これは、この情報をプロジェクトのデータベースに蓄積して、 デバッグや資源分析に使うためです。

3.6 参加者のコミュニティ向け機能

BOINC には以下のような、参加者向けウェブサイトの機能があります。

• チームの創設。
• 参加者のプロファイルの作成・表示。 プロファイルにはテキストと画像を含めることができます。
• 掲示板の機能。 この機能には、 参加者が互いの疑問に答えることを促進するdynamic FAQ システムが含まれます。 これらの道具立ては計数システムと統合されていて、 功績(credit)と長く参加していること(seniority)を尺度にして、 評判システム(reputation system)[12] のかたちを提供します。

これらの機能は、参加者を引きつけ、参加させつづけるために重要です。 また、 プロジェクトのリソースをほんの少ししか使わずに「カストマサポート」 を提供できる仕組みになるという点でも重要です。

3.7 多数のプラットフォームを扱う

パブリック・コンピューティング・リソースの多くは Windows/Intel プラットフォームではありますが、それ以外に、 典型的プロジェクトでは手に入れることがままならないプラットフォームが多数あります。

BOINC は、アプリケーションの実行可能ファイルを配付する方法として、 柔軟かつ斬新なフレームワークを提供します。 通常、アプリケーションの 実行可能ファイルは、そのプロジェクト自身がコンパイルして配付します。 カバーできるプラットフォームの範囲は、特定のものに限られています。 (すなわち、そのプロジェクトが手に入れられる範囲のプラットフォームだけです)。 このやり方でも、ほとんどの参加者には問題ありませんが、 以下のような人達にとっては不適切です。

• セキュリティ上の理由から、 自分自身でコンパイルした実行可能ファイルしか走らせたくないという参加者。
• そのプロジェクトがサポートするプラットフォーム以外のコンピュータを持っている参加者。
• 特定のアーキテクチャにアプリケーションを最適化したいと思っている参加者。

このような要望にそうため、BOINC は 匿名プラットフォーム機構 (anonymous platform mechanism)というものを提供します。 アプリケーションのソースコードを公開しているプロジェクトなら、 この機構を使えます。 参加者はアプリケーションのソースコードをダウンロードしてコンパイルします (あるいは、第三者から実行可能ファイルの供給をうけます)。 そして、 BOINC クライアントに対し、それらのアプリケーションの版の存在を知らせるため、 XML 構成定義ファイルを書きます。 するとクライアントは、 サーバと通信するときにそのプラットフォームは「名前なし」であると伝え、 さらに[そのクライアントで] 走らせることのできるアプリケーションの版の一覧をサーバに提示します。 これに応じて、サーバは(アプリケーションの版そのものは送らず) [一覧で示されたアプリケーションの版に] 適合するワークユニットを送り返します。

3.8 グラフィクスとスクリーンセイバーの振る舞い

BOINC のクライアント・ソフトウエアは、参加者にとっては一枚岩のようにみえますが、 実は、下記のようにいくつかの構成要素から成り立っています。

• コア・クライアント は、 スケジューリング・サーバおよびデータ・サーバと通信を行い、 アプリケーションを起動および監視し、 指定されたプレファレンスが実現されるように取り計らいます。 コア・クライアントは、互いに相互作用を及ぼしあう有限状態機械を、 階層的に組み上げて実装されています。 これにより、 ネットワーク転送と計算の仕事を数に制約なく併行動作させることができ、 かつ、移植性が高いものになっています。
• クライアント GUI は、その計算機が参加しているプロジェクト群、 仕事、実行中のファイル転送動作、およびディスク使用量に対して、 スプレッド・シート型の表示を行います。 さらに、 プロジェクトへその計算機を連結させる操作、あるいは、 離脱させる操作のインタフェースを提供します。 この GUI は、コア・クライアントとの通信に、 ローカルな TCP接続上の XML/RPC を使います。
• APIは、アプリケーションの実行可能ファイルにリンクされて使われます。 コア・クライアントに CPU 使用量やワークユニットの計算完了率を通知したり、 グラフィクス表示のための要求メッセージを処理したり、 'heartbeat'メッセージに関連する機能を提供します。
• スクリーン・セイバー のプログラム (プラットフォームに固有なスクリーン・セイバーの枠組みとともに実装されています)。 これが起動されると、スクリーン・セイバー用のグラフィクスを提供するよう、 コア・クライアントに指示します。 コア・クライアントは多くの場合、 グラフィクス処理能力をもつアプリケーションにその処理を委譲します。 そのようなアプリケーションが存在しなければ、 コア・クライアント自身がグラフィクスを生成します。

BOINC はまた、 個々のプロジェクトに固有な内容をもつ project プレファレンス のための枠組みを提供します。 たとえば、[計算経過の] 可視化グラフィクスの体裁を制御するために、 このプレファレンスを使うことができます。

3.9 ローカル・スケジューリング

BOINC のコア・クライアントは、ワークユニットをいつ取りに行くべきか、 どのプロジェクトに取りに行くべきか、 特定の時点でどの仕事を実行するべきかといったことを決めるにあたって、 「ローカルなスケジューリング方針」を実装しています。 この方針は以下のようないくつかの目標をもって作られています。

• 資源の使用率を最大化すること (つまり、全てのプロセッサを忙しくさせ続けること)
• リザルトの計算期限を守ること
• 参加者が指定した資源占有率にそって、プロジェクト間で資源を割り振ること
• 最低限の「多様性」をプロジェクト間[のスケジューリング] で維持すること。 この目標は、計算に長時間かかるワークユニットがあるときの参加者への見え方の問題に 由来しています。 参加者がいくつか複数のプロジェクトに登録した場合に、 もし1つのプロジェクトの計算だけが何ヶ月も続けて走ってしまったら、 参加者は飽きたり当惑したりするという問題です。

4 結び

この論文では、パブリック・リソース・コンピューティングの考え方について述べた後、 グリッド・コンピューティングとの対比を行いました。 また、 この考えかたを促進するソフトウエアシステム BOINC の設計について紹介しました。 BOINC はいくつかの現存プロジェクトで使われており (SETI@home, Predictor@home, climateprediction.net) さらに、他のいくつかのプロジェクトも [BOINC を使って] 開発中です。

BOINC の設計の多くの局面は不完全なところがあります。 たとえば、 いくつかのプロジェクトでは、効率的なデータの複製が必要です。 Einstein@home は大きな(40 MB) 入力ファイルを使います。 そして、 1つの入力ファイルが多数の計算機に送られることがあります。 (この点で Einstein@home は、個々のファイルが異なる SETI@home のようなプロジェクトとは対照的です)。 Einstein@homeのプロジェクト開始時点では、複製を含むデータ・サーバ群を使って、 大きなファイルでも単純に毎回、各計算機に送るでしょう。 最終的には、ピアー・ツー・ピアー通信を使って効率的なファイル複製をするために、 BitTorrent [3] のような機構を使うつもりです。

我々は、リソース不足状態に対応する方針と仕組みについて研究中です。 (リソース不足状態とは、 BOINC 他のディスク使用が増えてディスクが満杯になった場合、 あるいは、参加者がプレファレンスの変更[をしたためにディスク使用量の上限に達した] 場合です)。 これらの仕組みは、参加者の指定した資源占有率を守るように動く必要があります。 資源占有率や、複製のレベル、プロジェクト固有の優先度などに基づいて、 合理的な順番でファイルを消去しなければなりません。 我々は複数のディスクを使用する場合の課題も研究しています。 というのも、 現在の BOINC は、それがインストールされたディスクあるいはファイルシステムだけを使うからです。 複数のディスクを使用する場合、2つめ以降のディスクを使うかどうか、 もし使うならどのように使うかの好みを、参加者が設定できる必要があります。 さらに、ネットワークで接続された記憶装置(network-attached storage) を複数の計算機が共用しているケースも取り扱える必要があります。

参照文献