Document Actions
ArielFrameworkのメカニズム
- 概要
------
アリエルネットワーク株式会社(http://www.ariel-networks.com 、以下アリエルと略)は、P2Pシステムによる情報共有アプリケーションのアリエルプロジェクトA（以下、プロジェクトAと略）とアリエルマルチスケジューラ（通称、「マルスケ」）を開発・販売しています。これらのアプリケーションの共通のP2P基盤となるのがArielFramework(以下 afwと略、「アフー」と呼びます)です。afwの開発は、2001年にアリエルプロジェクトAとともに始まり、現在のバージョンは2.1です。本記事では、 afwの歴史的な経緯を交えながら、そのメカニズムについて解説します。
table: afwの系譜
|バージョン|リリース時期|対応プロジェクトA|特徴|
|0.9 |2002/05 |デモ用 |プロトタイプ実装|
|1.0 |2002/09 |1.0 |P2P基本フレームワークの提供|
|1.2 |2003/03 | |リソースの依存関係解決、関連リソースの同時取得|
|1.4 |2003/09 |2.0 |ブロードキャストコマンド|
|1.6 |2004/03 |3.0 |APIの整備、afw単体発売
|2.0 |2005/02 |3.1.5 |セキュアネットワーク、ADEXバージョン2.0|
|2.1 |2005/07 |4.1 |ブルームフィルタなどによるネットワーク負荷低減、ノードグルーピングなど|
|3.0 |未定 |
- アリエルプロジェクトAとマルチスケジューラ
-------------------------------------
アリエルでは、アリエルプロジェクトA(Fig:http://www.ariel-networks.com/product/project_a/images/function_img.gif) とマルチスケジューラを開発・販売しています。プロジェクトAは、P2P型のグループウェアです。基本機能として、スケジュール共有機能、TODO管理機能、掲示板機能、定型文書(日報報告、出張報告、議事録)の共有機能、ファイル共有機能、プロジェクト管理機能があります。一方のマルチスケジューラは、同じアプリケーション基盤を使ったスケジュール共有機能のみを提供する無料版です。誰でも無料で試せますので、この機会に一度、 P2P型グループウェアの世界に触れてみてください。また、プロジェクトAも2週間の試用期間があります(table: ProjectA and MultiScheduler)。スケジュール機能やTODO機能では、Microsoft Outlookとのデータの同期が可能になっています。既にOutlookでスケジュール管理やTODO管理をしている場合は、Outlookを使いながら手軽にスケジュールを共有することができます。また、プロジェクトAやマルチスケジューラでは、従来のグループウェア機能やスケジュール共有機能を後述する個人の視点で捉えなおしたアプリケーションですが、さらに、無料IP電話ソフト「スカイプ」(http://www.skype.com/) と連携することができます。スカイプをインストール、セットアップさえ行えば、自動でスカイプと連動します。スカイプとの連携により、プロジェクトAのユーザリスト(コンタクトリスト)をスカイプと共有しながら、プロジェクトAから直接スカイプで電話をかけたり、テキストチャットを始めることができます。
table: ProjectA and MultiScheduler
|機能 | ProjectA | MultiScheduler |
|スケジュール | ○ | ○ |
|TODO | ○ | × |
|掲示板 | ○ | × |
|定型文書 | ○ | × |
|ファイル共有 | ○ | × |
|プロジェクト | ○ | × |
|Outlook同期 | ○ | ○ |
|スカイプ連携 | ○ | ○ |
|試用期間 | 2週間 | 無料 ｜
P2P型グループウェアのメリットのひとつは、ネットワークを意識しない情報共有が可能になることです。ふたつ目はクライアント・サーバ型にはないフォルトトレランス性、スケーラビリティがあります。3つ目は、組織や企業を越えた情報共有が可能になることです。
まず、ネットワークを意識しない情報共有では、クライアントサーバ型でのネットワーク上の位置の問題を解決します。サーバ型のグループウェアの場合、サーバの設置場所、つまり、イントラネット内にあるのか、インターネット上にあるサーバなのかを意識する必要がありました。サーバがイントラネット内にある場合は、外出先などインターネットを経由してアクセスするためにVPNなどの設定が必要で、繁雑な作業になります。また、サーバがインターネット上からアクセスできるようにするために、別途ASPなどの外部サービスと契約する必要があったり、自社ですべて運用する場合は、ファイヤウォールの設定を変更して細心の注意を払ってセキュリティを維持する必要があります。P2Pでグループウェアのシステム構築する場合は、これらのネットワークの構成をユーザが意識することなく、ネットワークに接続しさえすれば常に最新の情報にアクセスすることができます。ただし、企業のユーザの中には、P2Pでインターネット経由で情報がやりとりすることに不快感を感じる管理者の方もいます。こうしたユーザにも使用してもらうために、後述する管理サービスによって、インターネット経由でのデータ転送やアクセスを禁止する管理機能も提供しています。
また、ネットワークを意識しないことの付加価値として、オフラインでの利用があります(Fig:http://www.ariel-networks.com/product/project_a/scene/images/mobile_01.gif)。サーバ型と違い、ネットワークに接続していない(できない)状態でも既にPCにコピーされたデータをもとに、情報の参照や追加、更新ができます。更新されたデータはネットワークに接続し直すと、他のPCと自動で同期をとることができます。
ふたつ目のフォルトトレランス性は、個々のPCのプロジェクトAが自律的に動作するので、負荷がサーバに集中しません (そもそもサーバが存在しませんが)。ネットワーク負荷やCPU負荷が一点に集中せずに分散されるので、ボトルネックが発生しません。サーバ型では、サーバを購入直後は軽快に動作してもユーザ数の増加とともに負荷が増大するなど、初期投資の見積りが難しい側面があります。P2P型では、こうした点を考える必要がないため、気軽に導入することができます。
また、サーバ型の場合は、システム管理者はバックアップ体制に気を使う必要があります。データがサーバに集中するため、サーバが支障をきたすと、サーバ上の全てのデータが失われる可能性があります。プロジェクトAでは、すべてのデータは各PCに分散されるため、ユーザが特に意識することなくデータのバックアップがとられます。たとえ、PCがクラッシュした場合でも、他のPCにデータのコピーが存在するため、必要に応じてデータを収集してきてくれます。
3つ目の利点として、組織や企業を越えてプロジェクト単位で簡単に情報共有が始められことです。企業内の情報共有として掲示板を導入する場合でも、情報管理部門に依頼して手続きを踏む必要がありました(前文とのつなぎがいまいちです)。こうした管理機能は各PCに分散されるため、必要に応じて情報共有の単位を作成して情報共有することができます。また、組織間だけでなく、企業間でのデータ交換を行う場合、サーバ型の場合はサーバを設置する必要があります。ASPを利用するケースもありますが、そうした場合、どちらの企業が作業を行うか、また、運用に際して発生する費用は誰が負担するかなどの問題があります。P2Pでは、各クライアントにインストールするだけですので、負担費用も各企業の人員分ですみ、作業の切り分けも明確になります。
特に企業間でのデータ交換で懸念される事項としては、セキュリティや情報共有の単位があります。プロジェクトAでは、P2Pのフレームワークのレイヤー、afwでセキュリティを確保しています。全てのデータはPKIベースで暗号化されているため、例え、データを盗まれたとしてもデータを読むことはできません。また、P2Pで接続されたPC間を流れるデータも暗号化されています。
情報共有の単位は、プロジェクトAではルームという概念を使っています。ルームとは、1つの組織やプロジェクトを表します。組織やプロジェクトごとにルームを作成し、そのルームにメンバーを招待することで、ルーム単位で情報共有を開始することができます(Fig:http://www.ariel-networks.com/product/project_a/scene/images/room_01.gif)。また、各ルームで作成した情報は、そのルームに所属しているメンバーしか閲覧ができないようになっているため、情報のアクセス・セキュリティ管理は万全です。
開発当初はルームという概念は存在しませんでした。すべてをグループとACLで管理しようとしていました。元々は、Lotus NotesのグループやACLの概念をそのままプロジェクトAに持ち込むことを考えていました。しかし、この方法でプロジェクトAを作成すると、情報共有の単位が不明確になり、また、必要以上に複雑なACLの管理が発生します。実際にLotus Notesでも複雑なACLを設定するケースは稀なことから、もう少し割り切って、ルームをグループとACLに紐付けるようにしました。
P2P 型のシステムを導入することでデメリットも発生します。P2P型のシステムを開発、販売することはこのデメリットを克服することでもあります。後述するようにデータが複数のPCに自動的に分散配置されますが、データの分散配置には若干の時間がかかります。データの作成直後などは、作成したPC上にしかデータが存在しないこともあります。データを作成した直後に、PCをネットワークから切り離した場合などです。こうしたケースに対応するためにワークグループノードというサーバ的なノードがあります。「サーバ的」と表現しているのは、サーバはそれが稼働していないとシステム全体が動作しませんが、「サーバ的」なノードでは、そのノードはシステムを補完するためのものだからです。そして、そのノードが稼働していない状況でもシステムは運用しつづけることができます。ワークグループノードは、他のサーバのように特殊なシステムではなく、クライアントであるプロジェクトAの特殊なノード(役割を持ったノード)と位置づけています。このため、ハイスペックなハードウェアを要求することはありません。通常のプロジェクトAが動く環境であれば、ワークグループノードを動作させることができます。また、ネットワーク的にも固定IPを必要としません。通常のDHCPなどの環境で動作できます。インターネット経由でアクセスする場合も、現在のネットワーク環境を変更することなく運用できます。
プロジェクトAでデータを作成した直後にデータをワークグループノードにプッシュします。このため、ワークグールプノードには常に最新のデータが全て保持されています。ワークグループノードが稼働し、ネットワーク的につながっていれば、常に最新の情報にアクセスできることを保証しています。
もう一つのデメリットとして、P2Pシステムの管理体制があげられます。P2Pシステムを導入したいが社外との情報共有は一切行いたくないユーザや、ルームの作成権限などユーザにあたえず、一元管理したいというユーザがいます。導入規模が小さい場合は、こうした管理機能を必要としませんが、規模が大きくなるにつれて管理体制の不備が指摘されます。こうしたユーザ層にも安心して利用していただくために、最新のプロジェクトAでは管理機能が追加されています。具体的にはWebで管理サービス(Fig:http://www.ariel-networks.com/product/project_a/images/support.gif) にアクセスすると、管理下にあるプロジェクトAやマルチスケジューラの利用状況が確認でき、ルームの作成、編集権限などが制御できます。また、P2Pネットワークトポロジーを特定のLANに限定させる設定などを一元的に管理できます。このサービスは最近始まったばかりのもので、今後も機能追加されていきます。こうした管理機能が必要ないユーザには、今まで通りのアドホックなシステム運用ができます。
- プロジェクトAの視点
---------------------
P2P アプリケーションとしてのプロジェクトAの初期（アリエル創業当時）の開発コンセプトとして、個人を中心とした情報分類、検索システムを目指していました。これは、井上メソッド(アリエルの社内用語)と呼ばれる、情報を検索するときには自分が見たり書いたりした情報(自分が関係した情報）を起点に検索を行うという経験則に基づいています。例えば、社内に複数の掲示板が乱立している状況で、全ての掲示板に対して全文検索を行って必要な情報を見付けるよりも、自分が見たり書いたりしたものを検索して、そこを糸口に関連ある文書を芋づる式に探す方が効率的なことが多いです。また、自分の書いた情報でも、どこかに書いた覚えはあるが、どこに書いたかを思い出せない場合など、個人の視点でのビュー（フィルタ）があれば、把握しやすくなります。
井上メソッドのもう一つの特徴としては、時系列でのビューに力点を置いていることです。どこに書いたかと言うことは忘れることが多いです。その一方で、いつごろ書いたか、いつごろ閲覧したかと言う時系列での記憶は持っていることが多いです。自分の関連した情報を時間軸に沿って見直すことで、情報の発見は効率的になります。井上メソッドの考案時には、blogと言うシステムはまだ存在していませんでした。井上メソッドと個人の視点での時系列での表現であるblogのシステムは、お互いに通じるところがあるかもしれません。
その後、プロジェクトという視点からアプリケーションが特徴付けられ始めました。プロジェクトと言う視点にも井上メソッドは効果を発揮しています。現在の開発コンセプトは、井上メソッドによりチームの中の個人が、現状の仕事、TODO のステータスを管理し、自分の今やるべき仕事を整理、管理するものです。プロジェクト管理機能は、プロジェクトマネージャがプロジェクト全体の進捗を管理、一覧するものですが、プロジェクトの個々のタスク(仕事)の管理はチーム内の各個人が管理します。各個人はにアサインされたタスクは、他のTODOと同系列で扱われます。これは、一度に複数のプロジェクトに属している場合や、プロジェクト以外のなんらかのタスクを抱えている場合などで威力を発揮します。複数のプロジェクトや個人のTODOが同じように扱われるため、全体を串刺しで見ることがでます。そのため、自分が今やるべきことや全体の仕事量が把握しやすくなります。また、与えられたタスクを複数のサブタスクに分割することで、自分の仕事の内容を各個人で実際の作業レベルまでブレークダウンして管理できます。
各個人は、ブレークダウンされたタスクを優先順位順にこなして、ステータスを変更していきます。この時に各個人はプロジェクトということは意識しません。プロジェクトのタスクも、個人のTODOも同じように扱われるためです。プロジェクト管理画面では自動的に個人のタスクのステータスを集計します。プロジェクト管理者はこのプロジェクト管理画面をみれば、日々のプロジェクトの遅れや進捗を管理できます。プロジェクト全体が順調な場合は問題ありませんが、タスクの進捗が芳しくない場合などは、各個人は簡単にアラートをあげ、プロジェクトマネージャとコンタクトをとることができます。
今後の井上メソッドの実践として、TODOのビューとスケジュールのビューの統合があります。現状のプロジェクトAでは、TODOとスケジュールは同時表示することができません。個人の視点からとらえた場合、例えば、その日にやるべき仕事ということでは、その日のスケジュールとTODOは同じところに順位付けされて表示される方が便利です。また、スケジュールの中にタスクやTODOなども同時表示された方が便利なケースもあります。このように、アプリケーションを個人の視点を中心に全体を連携、統合させ、同じデータでも様々なビューを提供することで付加価値を高めていきます。
P2Pが一時期、Peer to Peerでなく、Person to Personの略であると言われたこともありました。これは、人と人のコミュニケーションというだけでなく、コミュニケーションをシステムから Person、つまり、人という視点で捉え直したとも言えます。井上メソッドも個人の視点からシステムを捉え直すことで、Person to Personに通じるものがあるとも言えます。
それでは、上で説明したアリエルのプロジェクトAやマルチスケジューラのアプリケーションのP2P基盤であるafwについて具体的に見ていきます。
- 基本戦略
--------
afw はリソースという単位で処理を行います。リソースとは、P2Pファイル共有システムではファイルとしてとらえることができますが、afwではファイルだけでなくP2Pネットワーク上のさまざまなサービスを総称してリソースと呼びます。afwバージョン1.0では、このリソースをP2Pネットワーク内で検索して、発見するプロセスと、実際にそのリソースを持っているノードにアクセスして、リソースを要求、取得するプロセスに大別されます。これは、ちょうどインターネット上のDNSのシステムに似ています。例えばWebでhttpでファイルを要求する場合、DNSによる名前解決(リソースの検索)のプロセスと、その後、httpサーバへアクセスしてファイルを転送するプロセスに対応できます。その後、afwの検索・発見のプロセスは、リソース自体を見付けることよりも、リソースを持っているノードを見付けて、発見したノードとの緊密な連携をする方向に発展しました(後述)。
現状のafwでは、リソースは2種類に大別されています。一つが静的リソースで、もう一つが動的リソースです。これもWebシステムと対比させると、静的リソースは通常のファイルとしてWebサーバ上に格納されている静的なファイルに対比できます。プロジェクトAでは、個々の予定や掲示板の各文書などになります。これらのデータは、XMLのファイルとして各ノードのデータベース上に配置されています。静的リソースは多くのノードに転送されていく傾向があります。動的リソースとは、サーブレットのようなものです。特定のリソースを持つノード上で処理を行うことが可能になります。プロジェクトAでは、動的リソースは、更新状況や予定表の出席情報の通知などに使用されています。Skypeなどように、インスタントなピア同士の通話などもafwでは動的リソースに分類しています。動的リソースは、同じリソースがごく小数のノード上でしか提供していないようになっています。
先月号の特集のBitTorrent のようなファイル配信システムなどの場合は、お互いのノードは等価でした。つまり、接続先ノードの貢献度に応じて自ノードの他ノードへの貢献度が変化するシステムです。ファイルを単に取得するだけのノードは冷遇されます。一方、afwでの各ノードは役割に偏りがあります。プロジェクトAのワークグループノードのようにサーバ的な役割を担うノードも存在します。
プロジェクトAでリソースが作成されると、ワークグープノードにそのリソースのキャッシュを配信します。そのため、そのリソースを作成したノードがP2Pネットワークからリソース作成後にすぐに離脱した場合でも、そのリソースを他のノードが参照できるようになります。P2Pアプリケーションでは、サーバのようなノードは否定され、サーバ的なノードを必要とするなら最初からクライアント・サーバモデルで十分だという議論がかつてありました。けれども、クライアント・サーバモデルとP2Pシステムを組み合わせることで、お互いの短所を埋めあわせることができます。クライアント・サーバモデルでは、サーバが停止している状況では、クライアントは何も操作できませんが、P2Pシステムと組み合わせることで、サーバが停止してもユーザは意識することなく作業を継続できるようになり、可用性が広がります。また、クライアント・サーバモデルでは、ユーザは自分のネットワークの状態を意識する必要がありました。つまり、社外からイントラネット内のサーバにアクセスすることはできませんでした。P2Pシステムにより、現在のネットワークのインフラを変更することなく、社外からイントラネット内のワークグループノードへアクセスできます。
afw ではノード間の役割に差があるため、基本的な戦略は単純です。静的リソースでは、「取れやすそうなところからまとめて取れ」という戦略を取っています。戦略自体は単純ですが、実際のアプリケーションでの動作から、現実世界でもっとも効率的に動くモデルを模索しています。
次に動的リソースは、そのリソースを提供しているノードが限定的になるため、P2Pネットワーク内である特定のノードを見付けることにフォーカスしています。特定のノードを見付けた後は、アプリケーションに制御が移り、afwはネットワークレイヤを隠蔽しています。
それでは、具体的なメカニズムについて見ていきます。
- 静的リソース同期メカニズム
-------------------------
分散されたノード間でのリソースの同期は、afwでもっとも難しい領域の一つです。難しさの要因の一つが、ネットワーク負荷を抑えながら効率的にノード間で情報を伝搬させる必要があることです。もう一つが、複数のノードで同一のリソースが更新される可能性があるため、別々のノードで更新されたリソースを効率的にマージすることです。これらの問題を解決しながら、静的リソースの同期処理が実装されています。
-- ノード選択の方法
~~~~~~~~~~~~~~~~~
アプリケーションは、定期的、または、ユーザ操作により特定のリソースに対してP2Pネットワーク内を検索します。リソースは、リソースIDとリビジョン番号の組合せで管理されています。つまり、同じリソースIDでも、複数の異なるリビジョンを保持しています。リビジョン番号は、日時とそのリビジョンを作成したユーザIDによって特定されます。また、基本戦略でも述べたように、リソースはそのリソースを作成したノードだけではなく複数のノードがキャッシュを保持しています。そのため、リソースの同期をとる場合、どのノードからリソースを取得するかが重要になります。ネットワーク的に遠いノード（遅いノード）からリソースを取得しようとすると効率が悪くなります。
P2Pネットワーク内を検索すると、リソースのキャッシュを保持するノードから、そのノードが保持するリビジョン情報とノード情報が返されます。複数のノードが同一のキャッシュを保持している場合は、複数のノードから情報が返されます。afwでは、P2Pネットワークの負荷を低減するために、同じリソースに対する検索に対しては、検索コマンドが全てのノードに送られるのではなく、一度検索コマンドを受けたノードは一定期間、検索結果をキャッシュしています。そのため、検索結果は常にネットワークの最新の状態を反映しているわけではありません。これは、リソースの更新頻度とネットワーク負荷のトレードオフになりますが、通常の環境ではリソースの更新頻度はそれほど高くないという経験から問題になることはあまりありません。また、リソースを持っているノードがネットワークから離脱している場合も検索キャッシュにヒットしてしまうことがありますが、その場合も実際のリソースの転送時に相手ノードに接続できない場合は、再度、検索結果キャッシュを無視してネットーワーク内を検索し直すなどの対策をとっています。
検索結果が取得できると、次にどのノードに接続してデータを取得するか、と言うノード選択を行います。ノード選択の基準は複数あり、順番に処理されます。
ノードの選択には、すでにTCP/IPのコネクションが張られているノードが存在する場合は、そのコネクションが最優先されます。これは、常に各ノードがネットワークに参加・離脱を繰り返すような環境では、確実にデータを転送できるノードを優先させるためです。また、新たにTCP/IPのコネクションを確立するのはネットワーク的にコストがかかるというのも理由の一つです。
次の基準は、同じリソースIDであればもっともリビジョン番号の大きい (最新の)リソースを優先させます。これは、各ノードは自律的に独立してリソースの同期を行うため、各ノードが保持するリソースのリビジョンにバラツキが生じますが、最新のリビジョンほど他のリソースが保持している確率は低いので、なるべく速く最新のリビジョンをキャッシュしているノードを増やす戦略の一つです。
次に、同じリソースID、リビジョンを持つ複数のノードがある場合は、ネットワーク状態などを考慮して最適なノードを選択します。まず、そのノードに最後にアクセスした時の状況が考慮されます。そのノードに最後にアクセスした時に失敗しているケースで、アクセスした時間が一定時間以内であれば、次にアクセスするときも失敗する可能性があるので、ノード選択の優先度を低く設定します。失敗した理由はいくつか考えられます。単にそのノードが P2Pネットワークから離脱した場合もあります。そのノードが処理過多の状態にあったり、そのノードに接続しているノードが一定数(Windowsの場合は、TCP/IPのコネクション数が10に制限されている）を越えている場合などもあります。
次に、同一LAN内かをチェックします。同一 LAN内であればインターネット経由でリソースを取得するよりはるかに効率的であるためです。同一LAN内でも、かつてのノードへのアクセス状況を確認して、以前アクセスに成功しているノードが優先されます。これは、以前成功していたノードは、今後も成功する可能性が高いという経験則から来ています。
最後にインターネット経由のノードが選択されます。インターネット経由の場合のデータ転送は、様々な要因でネットワーク状態が左右されます。現状は各ノードが自己申告したインターネットとの接続スピードを元にノード選択を行います。これは単に、より速いノードを選択しているだけです。モバイル環境などネットワーク帯域が小さい環境で、他のノードが自ノードへアクセスさせたくない時に、ネットワークスピードを低く設定しておくと効果が得られます。
インタネット越しのリソース同期を行うノードを選択するときに、過去のそのノードとの接続状況や実際のデータ転送速度時の転送速度からノード選択を行うなど、より効率的なノード選択を今後拡張していく予定です。また、ノードの役割(ロール)は現状、考慮されていません。ノードの役割に応じて、優先的に接続するノードを選択できるようにすることで、ノード間の連携がよりスムーズになるように計画されています。
-- データの依存関係と関連データの取得(peek)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BitTorrent などのP2Pファイル配信アプリケーションの場合、一つのファイルを効率的に複数のノードに分散させるかということを念頭に設計されています。afwでは、一つのファイルではなく、複数のファイル(リソース)からなるファイルセットの配布に最適化されています。イメージ的には、一つのWebサイトまるごと配信することに似ているかもしれません。
ファイルセットの配信のために、ファイルをドキュメント本体とインデックス情報の2種類に分類しています。ドキュメント本体もインデックスもそれぞれ独立したP2Pネットワーク内のリソースとして扱われます。インデックスとドキュメントに分類することで、更新されたリソースを発見しやすくなります。ドキュメント本体を更新することで、インデックス情報も最新情報に更新(リビジョンが更新)されます。通常は最新のインデックス情報をネットワーク内を検索だけで最新のインデックスとドキュメントが取得できます。
初期のafw(バージョン1.0)には、インデックス情報とドキュメント本体は分離されていましたが、リソースの取得のタイミングは互いに独立していました。インデックス情報を取得した後、ユーザ操作によってのみドキュメント本体を取得していました。実際のユーザ操作では、インデックス情報を取得した後に、ドキュメント本体を続けて取得していました。このため、afwバージョン1.2では、ドキュメントとインデックス情報、また、ドキュメント間に依存関係をもたせ、関連するリソースは、まとめて取得するようなりました。これらの依存関係のモデルとして、Debian GNU/Linuxのパッケージ管理システムaptや、Gentoo Linuxのパッケージ管理システムのportageが参考にされています。
リソースの転送途中で、相手ノードが離脱するなどネットワークが切断されると、リソースの同期が不完全な状態で完了します。この場合、インデックスの情報とドキュメント本体の間で不整合が生じます。ドキュメントとインデックスの間に不整合が発見されると、不整合があるドキュメントに対して、再度ネットワーク内を検索し直し、最新のドキュメントを取得する仕組が実装されています。
プログラム的には、依存関係の解決のためにafwはアプリケーションに問い合わせて、アプリケーション側で依存関係を解決しています。aptやportageは、メタ情報としてパッケージに依存関係を持たせています。しかし、afwはリソースに依存関係解決のためのメタ情報を保持していません。これは後方互換性のためですが、そのために、アプリケーションとしての処理が繁雑になっているのも事実です。依存関係をメタ情報をとしてリソース自体に持たせるべきかどうかは、社内でも議論されていますが、結論はまだ出ていません。
具体的にプロジェクトAのスケジュールで、リソースの依存関係がどのように解決されているかをみてみます。プロジェクトAのスケジュールのリソースは、月ごとのスケジュール一覧を格納したインデックスリソースと、個々のスケジュールに対応したリソース、個々のスケジュールに対する出席、欠席のステータスを保存しているステータスリソース、添付ファイルの 4つに大別されます。個々のスケジュールは、インデックスに依存しています。ステータスリソースは、スケジュールリソースとインデックスリソースに依存して、添付ファイルはスケジュールリソースに依存するように設計されています。インデックスが更新されていることを検知すると、通常は、依存関係の上から下へ向かう形でリソースを取得します。ステータスリソースだけが更新されていることを検知すると、ステータスリソースを取得した後に、スケジュールリソースとインデックスリソースを最新のリソースを取得します。依存関係の上下両方に対してリソースを取得する所が、参考にしているaptやportageとは決定的に違います。
-- Arel Delta Engine for XML(ADEX)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
afw では、分散された環境で同じリソースがそれぞれのノードで更新されます。これは、CVSやSubversionなどのソースコード履歴管理システムに似ているかもしれません。ソースコードの管理システムは中央にサーバが存在するために、最新のリビジョンはサーバ上に存在しており、ローカルでマージ処理が行われます。一方、afwでは、中央サーバが存在しないため、個々のノード上でリビジョン間のデルタ・マージ作業を行っています。P2Pネットワーク全体としてリビジョンの整合性を保つことが重要になります。afwにおいては、ファイルなどのバイナリデータ以外のほとんどのデータはXMLとして扱われています。そのため、アリエルではAriel Delta Engine for XML(ADEX)として、XMLに特化した独自のデルタ・マージエンジンを開発しました。
afwで扱われるXMLは、インデックス専用のXMLとドキュメント用のXML(汎用のXML)の2種類に分類しています。これは、パフォーマンスのために2種類に分けています。それぞれにデルタ・マージを生成、処理するアルゴリズムが異なります。
インデックス用のXMLは、afw内のリソースのコレクションになり、基本構成として次のような形式を取ります。
<index>
<item>
<id>リソースID</id>
<rev>リビジョン番号</rev>
</item>
:
</index>
形式がXMLであるため、アプリケーションでインデックスを独自に拡張することができます。デルタは各item要素単位で作成されます。item要素のid がユニークになるように、item要素のidの一覧としてリビジョン間で差分をとり、デルタファイルが生成されます。インデックスは基本的には、追加、更新のみが行われます。ドキュメント用のXMLリソースを削除した場合でも、リソース自体が消えるわけではなく、「削除した」というリビジョンが生成されます。この思想は、CVSにファイルの削除と同じ考え方です。インデックス用のXMLは追加、更新のみなので、ファイルサイズは増加しつづけます。そのため、一定期間以前に削除されたリソースに関するエントリは、一定期間毎にパージ（削除）しています。
次にドキュメント用XML(汎用XML)での、デルタ・マージ処理です。インデックス用のデルタ・マージ処理に比較して重い処理になっています。汎用XMLデルタ・マージ処理エンジンは、レーベンシュタイン距離（Levenshtein Distance、http://www.merriampark.com/ld.htm ）アルゴリズムに基づいて実装されました。レーベンシュタイン距離とは、二つの文字列がどの程度異なっているかを示す数値です。具体的には、文字の挿入や削除、置換によって、一つの文字列を別の文字列に変形するのに必要な手順の最小回数として与えられます。ADEXでは、XMLの各要素に対してレーベンシュタイン距離を算出しています。距離が0でない要素に対しては、デルタファイルを作成します。デルタファイルには、追加・削除に関する情報とXML的な位置情報が格納されています。
-- リソース同期のタイミング
~~~~~~~~~~~~~~~~~~~~~~~~
リソースを発見してからリソースを同期するメカニズムは、afwではライブラリとして既に組み込まれています。アプリケーションは、リソースの同期についてはほとんど意識する必要はありませんが、リソースを同期するタイミング、つまり、ネットワークを検索することは、アプリケーションが制御します。
プロジェクトAやマルチスケジューラでは、リソースの同期のタイミングは、一定期間毎、または、ユーザ操作によって行われます。ユーザ操作とは、プロジェクトAのエントランス画面から「すべて最新」ボタンを押した場合や、スケジュール一覧の画面を開いたタイミングで行われます。このとき、全てのリソースに対して最新のリビジョンが存在するか検索を行うのではなく、インデックスリソースに対してのみ検索が行われます。これは、ネットワーク負荷を軽減するためです。ネットワーク負荷を軽減するために、これ以外にも様々な工夫がされています。次に、これらの仕組みについて解説します。
--- 隠れマルコフ連鎖による確率ルックアップ
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
afw では、各リソースは所有者（または、作成者）が存在します。つまり、一部、例外はありますが、各リソースは特定のユーザに結びつけられています。例えば、 AさんのスケジュールのインデックスはAさんの所有物で、Aさんに関連づけれています。この時、Aさんは、自分のスケジュールを頻繁に更新している場合は、検索を頻繁に行う必要があります。もし、Aさんが一月に一度しかスケジュールを更新しない場合にも、頻繁にネットワーク内を検索することは、無駄な作業になります。
afwバージョン2.1では、過去のリソースの更新頻度をベースにネットワーク内を検索する頻度を調整します(図)。これは、よく更新されるリソースは、今後も頻繁に更新される可能性が高いためです。現在の不確定な状況から更新されているかを判断するために、隠れマルコフモデルが参考にされています。ネットワークを検索するときに、過去のリビジョンの更新日時を調べて、現在時間と更新時間の間隔に応じてネットワーク内を検索するかどうかの確率を変動させています。
FIG:更新期間と検索の確率
( 縦軸：検索コマンドを発行する確率
横軸：過去のリソースの更新期間)
| ------
| /
| /
| /
|---
+---------->
old new
この確率ルックアップにより、最近更新されたリソースは、より多くの頻度でネットワーク内を検索しますが、更新頻度が少ないリソースは、次第にネットワーク内を検索する頻度が低下していきます。
--- ブルームフィルタ
-----------------
ブルームフィルタ(http://portal.acm.org/citation.cfm?id=362692&dl=ACM&coll=portal)は、afw2.1で実装された新機能です。ブルームフィルタには、次のような特性があります。
- 少ないデータを転送するだけで、存在チェックのヒントを相手に渡せる
- Bloom filterの和は、ビット和を取るだけでできる
- 秘密を保ったまま、自分の手札をさらせる
- ブルームフィルタ同士を比較することで、近さの判定ができる
ことがあげられます。
P2P ネットワークでは、参加するノードが増えるとP2Pネットワークを維持するためのトラフィックも増加します。afwでのトラフィックは、最大、 100kbps程度で通常のブロードバンド環境であれば問題ないレベルですが、モバイル端末では、このトラフィックを維持することは現状ではまだ難しいです。こうしたネットワーク帯域が限られた環境でも動作するようにするためにブルームフィルタが実装されました。
afwでは、接続しているノードに対して、ブルームフィルタを登録します。フィルタには、2種類のフィルタが用意されています。一つが自分が関係しているユーザのユーザIDによるフィルタです。このフィルタを登録することで、接続先から自ノードに送られるコマンド群は自分が関係するユーザが発行したものだけになります。例えば、プロジェクトAでは自分が所属しているルームのメンバーからのコマンドだけにフィルタすることが可能になります。
もう一つがリソースIDによるフィルタです。これにより、自分が持っているリソースへの検索コマンドだけをリモートのノードから伝搬させることができるようになりますが、現在のプロジェクトAではまだ、利用されれていません。
--- 告知モデル
~~~~~~~~~~~~
リソースの同期のタイミングとしては、前述の定期的、または、ユーザ操作により行うことが基本です。けれでも、実際のプロジェクトAでの運用では、定期的、またはユーザ操作のタイミングだけでデータを同期するだけでは、リソースを作成、更新してから取得するまでのタイムラグが問題になりました。
このタイムラグの問題を解決するために、告知モデルが採用されました。告知モデルとは、リソースが作成されたタイミングでネットワークにリソースが作成されたことをブロードキャストすることで、そのリソースを必要としているノードに「告知」するための仕組です。
告知モデルには2種類存在します。明示的な告知モデルと暗黙的な告知モデルです。
暗黙的な告知モデルは、afw1.2で実装されたものです。これは、リソースが検索されるときに検索コマンドが発行されます。この検索コマンドに特定のリビジョンを指定している場合、そのリビジョンのリソースがネットワーク上にある確率が高いことを利用しています。ネットワーク上を流れる検索コマンドを解析して、更新されているリソースを発見したら、そのリソースを取得します。これは、既にあるコマンドを流用して、アプリケーションは意識することなくリソースを告知できるために、暗黙的な告知モデルと呼んでいます。この暗黙的な告知モデルを多用しすぎると特定のノードに負荷が集中しすぎることがあるため、暗黙的な告知モデルを用いてリソースを同期するのは、現状はワークグループノードに限定されています。今後(afw3.0)は、暗黙的な告知モデルで新たなリソース・リビジョンを発見すると、ネットワークの負荷が特定のノードに集中しないように、多少のタイムラグを発生させて同期を行う仕組が予定されています。これにより、より速やかなリソースの同期が可能になります。
明示的な告知モデルは、アプリケーション側が明示的にネットワーク内にブロードキャストして、リソースの更新を告知します。告知を受け取ったノードも、そのリソースを同期するかは、そのノードに任されています。つまり、アプリケーションが判断する必要があります。暗黙的な告知モデルは、以前のネットワーク負荷を増大させることなく告知できるのに対して、明示的な告知モデルでは、ネットワーク負荷が増えます。現状のプロジェクトAやワークグループノードでは、明示的な告知モデルは利用されていません。今後は、LAN内限定など、ネットワーク的に限定された範囲内でリソースを告知することで、ネットワーク全体としてのトラフィックが急増することなく、効果的にリソースを同期する仕組が考えられています。
- 動的リソースによるノード間連繋
----------------------------
次に動的リソースによるノード関連系について解説します。
動的リソースは、WebのJavaサーブレットやRPC(Remote Procedure Call)をイメージするとわかりやすいです。P2Pネットワーク内を検索して、動的リソースを発見するプロセスは静的リソースと同様です。動的リソースの場合は、リソースの発見後にそのノードにアクセスを行います。そして、相手先ノード上に処理を依頼して実行します。静的リソースでは発見されるノードが複数であることが考慮されていますが、動的リソースでは発見されるノードは単一であることを前提に実装されていました(afw1.0の通知システム)。後述するPOSTシステムにおいては、通知システムの実装上の反省から、発見されるノードが複数存在することを前提に開発されました。
-- 通知システム
~~~~~~~~~~~~~
通知システムとは、afw0.9では、リソースの作成、更新の告知モデルの一つとして実装されました。現在のプロジェクトAにおいても特定のユーザに対しての告知モデルとして利用されています。例えば、プロジェクトAの掲示板において文書を作成すると、現在ログイン中のルームメンバに対して通知が行われます。通知を受け取った各ノードは、P2Pネットワーク内を検索して、作成・更新されたリソースを取得します。
その後のafw1.0において、ノードの発見後にそのノード上で処理を実行するという動的リソースのノード間連携機能が強化されていきました。例えば、プロジェクトAやマルスケの予定表で他のユーザを参加者に加えた場合、そのユーザに対して通知が作成されて送信されます(図）。通知を受け取ったノードは、そのノード上で、予定のコンテンツを解析して、自分の予定インデックス情報を書き換え、その予定を自分のリソースとして保存し直します。次に予定の「参加」ボタンを押すことで、予定のオリジナルの作成者に参加通知が送信されます。参加通知を受け取ると、インデックス情報を更新して、予定本体のリソースにそのユーザの「参加」ステータスを書き込み処理を行います。このように、単にリソースの告知モデルとしてではなく、通知の送信先ノード上で処理を実行させることが可能になります。
FIG:マルチスケジューラでの予定の通知の流れ
ユーザA ユーザB
1. 予定作成
2. 予定の通知 ----->
3. インデックス情報更新
リソースの更新
4. 予定に「参加」
5. <----- 「参加」通知
6. インデックス情報更新
予定リソースの更新
--- 通知モデルの変遷
~~~~~~~~~~~~~~~~~~
通知モデルは、afwの発展とともに大きく変化したもの一つです。この変化は、複雑なものからよりシンプルなモデルへの変化でした。通常のノード(平ノード)同士で通知が送られることは、afwのどのバージョンを通しても共通のモデルです。ただし、この場合は、お互いの平ノード同士がオンライン状態でなければなりません。これは、通知システムが相手先ノードで処理を行うという性格上、必然のことです。けれども、通常のユーザの利用では、お互いが同時にオンラインにならないことも多々あります。そのための回避策が通知モデルを大きく変遷させた要因です．
afw1.0では、相手先の平ノードがP2Pから離脱している状態でも通知がとどくように、24時間稼働しつづける特殊なノード、エージェントキューノードが用意されていました。送信元平ノードは一定期間、送信先ノードに通知を試行しますが、その期間に通知が成功しなかった場合は、お互いが同時にオンラインになることはないと判断して、エージェントキューノードに通知の代行を依頼します。通知の代行依頼も通知で行われます。エージェントキューノードは、通常のプロジェクトAと同様に相手先ノードへの通知を代行します。エージェントキューによる代行も一定期間続き、その間に送信できない通知は、エラーとして送信元に送り返されます。このモデルでは、通知の現在の状況がユーザに把握し憎い、通知のステータス管理が繁雑になりすぎる、一時的にアリエルのサーバ上にデータが保存されることを嫌うユーザがいたため、afw1.2ではエージェントキューの使用を止めました。
FIG:通常の通知
ユーザA ---> ユーザB
通知
FIG:エージェントキューノードモデル
ユーザA -----+代行依頼通知
↑ ↓
| エージェントキューノード --> ユーザB
| | 通知
+--------------+
失敗した場合は、失敗通知
エージェントキューモデルを破棄した直後は、相手と自分が同時にオンラインにならないと通知が送られない期間が続きました。この時はすでに、ワークグループノード構想ができあがり、実際にワークグループノード上で静的リソースをキャッシュする仕組がユーザに提供されていました。ワークグループノードはエージェントキューノードと同様に24時間稼働しつづけることを前提としたノードです。エージェントキューモデルの次に採用されたのがワークグループノードによる代理応答(秘書機能)モデルです。これは、プロジェクトAのバージョン3.0以降です。
代理応答モデルは、ワークグループノード上でユーザがログオフ状態になったことを検知すると、そのユーザに代わって、動的リソースを作成（利用できるように）します。次に、そのユーザに対する通知をワークグループノードが受け取って、通常のプロジェクトAでの処理と同様の処理をワークグループノード上で実行します。ログオフ状態のユーザがP2P ネットワークに参加しなおすと、後述するPOSTによるノード間連携の更新情報の取得メカニズムで、最新の状態にアップデートし直します。このため、通知の送信元は、相手のネットワーク状態を気にする必要がなくなり、通知の受信先ノードでは、ネットワーク接続し直せば、最新の状態が保たれるようになります。
--- 通知のスケジューリング
~~~~~~~~~~~~~~~~~~~~~~~
通知システムの実装の話になりますが、通知のスケジューリングの方法は、afw1.0からafw1.2への進化の過程で大きく見直され、afw1.4でさらに変化しました。
通知キューリソースは送信先のユーザがオンライン状態のときだけ、P2Pネットワーク内に存在します。これは、送信先のユーザが本当にオンライン状態の時、または、ワークグループノード上で、代理応答状態になっている場合の2種類がありますが、afwから見た場合はどちらも同じオンライン状態として判断されます。ユーザがオンライン状態、または、代理応答状態の場合は、定期的にユーザのプレゼンスがネットワーク内にブロードキャストされます。現在の通知のスケジューリングモデルでは、このユーザのプレゼンスに依存したモデルになっています。ユーザのプレゼンスを受け取ると、通知の送信リストから、そのユーザに対する通知項目を取り出し、逐次、通知項目を相手ノードに送信していきます。
このモデルでは、送信元ノードが一定期間稼働しつづけている場合は、すべてのプレゼンスのブロードキャスト情報を取得できますが、起動直後は、ブロードキャスト情報が取得できないことがあります。プレゼンスは定期的に送信されるため、プレゼンスの送信直後にアプリケーションを起動した場合は、次のプレゼンスの送信まで待たないと通知データは送信されません。通常の環境であれば、このタイムラグは最大20分になります。このタイムラグは一見問題にならないように見えますが、このタイムラグのために通知データがなかなか送信されないという感想が多く寄せられました。このタイムラグの解消のため、最初の20分はユーザのプレゼンスに依存せずに通知データを送信する戦略をとっています。
-- ノード間の連繋(POST)
~~~~~~~~~~~~~~~~~~~~~
通知以外のノード関連携の方法として、POSTがあります。HTTPプロトコルと対比すると、リソースの同期はGETメソッド、通知はPUTメソッドで、POSTはPOSTメソッドに対応します。POSTでは、相手先ノードにデータを送信して処理を依頼することは通知と同様ですが、POSTではその後、相手ノードからの応答が期待されます。通知が、処理を一方的に依頼するだけなのに対して、POSTでは相手ノードとより協調した作業が可能になります。
FIG:通知とPOSTの違い
ノードA ノードB
通知 ---->
処理を依頼
POST ---->
<----
---->
<----
双方向でデータのやりとりが行われるため、緊密な連繋が可能
/FIG:
通知システムによるノード間連携は、POSTシステムの一部ともとらえることができ、POSTシステムで統一することも可能です。統一されていない理由は、通知システムがafw1.0で開発されたのに対してPOSTシステムがafw1.2で対応されたためです。このため、後方互換性のために通知システムが残っています。
現在のプロジェクトAでは、ワークグループノードとのトランザクションにこのPOSTシステムが利用されています。ワークグループノードがユーザAの代理応答をして、通知データを一時格納します。ユーザAがオンライン状態になると、プロジェクトAがワークグループノードに接続して格納されている通知データを取得します。通知データを取得して、通知データの完全性が確認されると、プロジェクトAはワークグループに一時格納されていた通知データの破棄を依頼して終了します。
-- 双方向通信メカニズム
~~~~~~~~~~~~~~~~~~~~~
現状のプロジェクトAのシステムでは、ノード間連携は先ほどの通知システムとPOSTシステムの併用で十分実現されています。ただ、POSTシステムでは、接続元ノードが接続先ノードにデータを転送したタイミングで、接続先ノードから情報を取得できるだけです。データ転送の経路が確立された後、接続先ノードから接続元ノードへ能動的にデータ転送を行うことはできません。
現在はまだ実装中ですが、一度データ転送の経路が確立されると、TCP/IP接続のように、接続先ノードからも接続元ノードからも非同期でデータ転送が行える仕組を追加しようとしています。これは、afwは最初は大量のファイルセットの交換を目標に作成されてていたため、Skypeのような1対1のリアルタイム通信には弱いとされていた分野です。この機能が実装されると、よりリアルタイム性の強いアプリケーションが開発可能になります。
- ノードグルーピング
------------------
afw では、基本的に大きな単一のP2Pネットワーク上でブロードキャスト、リソースの発見などを行います。これは、P2Pネットワークが小規模な場合は問題になりませんが、ノード数が増えてくると指数関数的にトラフィックが増大します。P2Pネットワーク内を流れるブロードキャスト情報はほとんどのノードにとっては無意味なものかもしれません。また、少数のノード群と綿密なデータ交換をブロードキャスト的に行うことは、大多数のノードにとって余分な負荷となります。このため、afw2.1からノードグルーピングが実装されました。
ノードグルーピングとは、単一のP2Pネットワークからグルーピングに必要なノード群を選び出し、そのノード群に対して、新たな小規模なP2Pネットワークを創出するしくみです。小規模なネットワーク内でお互いの情報を逐次ブロードキャストしあうことで、綿密なデータ連携が可能になります。
これは、現在開発中のアプリケーションからの要望として実装されました。リソースが更新されると逐次ブロードキャストされるため、リアルタイムアプリケーションの開発も可能になります。また、ノード間連繋が1対1の通信であるのに対し、ノードグルーピングは多対多の通信を可能にします。
- Ariel P2P Frameworkバージョン3.0へ
-----------------------------------
今後のafwの拡張は、よりノードの役割を明確化して、特定のノードやノード群と綿密に協調作業する方向性が考えられています。例えば、現状のワークグループノードの場合、ルーム内のリソースはすべて、ワークグループノードがキャッシュする仕組になっています。プロジェクトAのリソース検索時、ネットワーク内を均一に検索しますが、すでにワークグループノードがそのリソースをもっていると分かっている場合、最初にワークグループノードに接続してリソースを取得することで、ネットワークトラフィックを抑えるこうかが期待できます(プロアクティベーション機能)。ワークグループノードが存在しないときは、従来通りの動作になります。関心のあるユーザが、ネットワークのどの辺にいるかを把握しておき、無駄な探索を減らすのも構想にあります。プロアクティベーション機能が有効の場合、P2Pシステムによるサーバ不要のメリットはなくなるように感じられるかもしれませんが、ユーザはネットワーク環境を意識することなく作業が継続できるメリットがあります。また、ワークグループノードが落ちている場合でも、従来のP2Pシステムにシームレスに移行されるので、サーバの状態に左右されることはありません。
二つ目の拡張は、ワークグループノードのクラスタリング化です。ワークグループノードがクラッシュした環境でも作業を継続できるのがP2Pシステムのメリットですが、ユーザがより快適な作業を継続するために、動作しつづけることが望まれます。さまざまな要因でワークグループノードが落ちることもあるため、複数のワークグープノードをクラスタリング化してデータのミラーリングやワークグループノード自体の複製を行うことが期待されています。
3つ目の機能拡張としては、履歴管理があげられます。現状のafwでも履歴管理がされていますが、ソースコードのバージョン管理システムと比べると見劣りします。今後、CVSやSubversionと同等の履歴管理のシステムを開発し、CVSやSubversionの代替としても機能するように拡張していきたいです．
4つ目としては、afwではなくアプリケーションの領域になりますが、afwのP2Pシステム自体をより管理可能な状態にすることです。P2Pシステムの場合、多くの企業からP2Pシステムの無秩序性や管理の難しさを指摘されました。その中のいくつかは、多くのP2P型のファイル共有システムからうける誤解もありました。そうした管理者の方にも安心して使っていただけるような管理機能 (Managed Secure P2Pシステム)が計画されています。
Maneged Secure P2Pシステムとしては、ユーザ管理、ネットワークに参加するノード管理、ネットワークに偏在するリソースの管理とリソースの伝搬経路管理などがあります。また、P2Pネットワークを社内LAN内だけに限定する機能や、社外と接続する場合でも、そのネットワーク負荷の制御やフィルタリングを行う機能などが考えられています。
afwでP2Pアプリケーションを開発するには敷居が高いのが現状です。5つ目の機能としては、afwを使ってアプリケーションを一から作成するのではなく、プロジェクトAやマルチスケジューラなどをプラットフォーム化して、プロジェクトAのプラグインとして簡単にP2Pアプリケーションの構築ができるようにすることも検討されています。
最後に、afwはまだまだ発展途上のライブラリ、フレームワークです。今後も活発な開発が計画されています。この特集を読んで、もし、一緒に開発に参加してみたいと感じた方は、是非、一緒に開発していきましょう。