Spritelyは、分散システムにおける3つの基本的な問題、すなわちアクセス制御、プロセス間通信、リソースの命名に取り組むことから、デフォルトで分散型かつ安全なアプリケーションを構築する構想を提示している。これは、Spritely InstituteのエグゼクティブディレクターであるChristine Lemmer-Webberと、同研究所のテクニカルディレクターであるDavid Thompsonが行った講演で示された。
この考え方は、中央集権型サービスは工学的には容易だが、運営者にサービスを変更したり、ユーザーを監視したり、製品を完全に停止したりする大きな権限を与えるという認識から出発する。Spritelyは、中央集権型プラットフォームへの依存によってユーザーの選択肢が限られると考えている。また、大企業を標的に設計された一部の法律が、コンプライアンスを小規模プロジェクトや自己ホスティングにとって高コストにする「立法上の堀」に変わる可能性もあるとしている。
セキュリティは一般的な権限ではなくケイパビリティから始まる
記事は、アクセス制御リストやロールのモデルを批判している。これらは多くの場合、広範なグループや権限、そして委任を付与する中央の管理主体に依存しているためだ。Spritelyが示す代替案はケイパビリティ・セキュリティであり、ケイパビリティとは、リソースの特定と、そのリソースを使用する権限の付与を組み合わせた、偽造不能な参照である。
実際には、プログラムは明示的に渡されたケイパビリティだけを受け取る。信頼できないアプリケーションを実行する場合、ユーザーのすべての権限を与えるのではなく、例えばディスプレイとキーボードだけを扱う権限を与えることができる。このモデルでは、委任時に権限を縮小したり、中央管理者を介さずに別の主体へ渡したりでき、後から無効化することも可能である。
Spritelyは、これらの原則をケイパビリティに基づく安全な分散プログラミング環境であるGoblinsに実装している。記事は、ケイパビリティの受け渡しをプログラミング言語における引数の受け渡しと結び付けている。これにより、リソースへのアクセスは、関数やプロセスが明示的に受け取ったものの直接的な結果となり、暗黙にアクセスできるものの結果ではなくなる。Goblinsは、失敗した操作の際に以前の状態へロールバックする機能を含め、並行性、永続性、トランザクションもサポートしている。
アクターモデルとOCapNプロトコル
プロセス間の通信を整理するため、Spritelyはアクターモデルを採用している。各アクターは一度に1つのメッセージを受け取り、他のアクターへメッセージを送信したり、新しいアクターを作成したり、次のメッセージに向けて自身の振る舞いを変更したりできる。このモデルは、非同期通信と状態管理を組み合わせ、共有ロックへの依存を減らす。
Spritelyは、RESTは基本的にクライアント・サーバー型アプリケーションに適している一方、互いに信頼しない主体で構成されるピアツーピア・ネットワークには適さないと考えている。これに対してOCapN(Object-Capability Network)は、安全な参照の受け渡しをリモートプロシージャコールに追加する。このプロトコルはトランスポート手段から独立しており、WebSockets、Tor onionサービス、その他の手段を介して実行できる。また、2者間の通信や、オブジェクトを第三者へ渡すこともサポートする。
OCapNは、基本層で強制されるスキーマを持たないデータモデルを採用し、非同期呼び出しとpromise値をサポートする。記事によれば、現在Scheme、JavaScript、Dartに実装が存在する。
一般的な名前を盲目的に信頼するのではなくローカルな命名を用いる
Spritelyは、リソースの命名問題をpetnameシステムによって扱う。これは、ユーザーが知っている主体やオブジェクトに対して、ユーザー自身が選ぶローカルな名前を与える仕組みである。これは、フィッシング、名前の乗っ取り、視覚的類似性を利用した攻撃など、ドメイン名に関する問題への対応である。
記事は、この課題を、1つのシステムで人間に理解しやすい名前、分散性、安全性を同時に実現することの難しさを示すZookoの三角形と結び付けている。グローバルな名前をアイデンティティの十分な証拠として提示するのではなく、petnameモデルは、リソースとユーザーとのローカルな関係に重点を置く。
実際には何が変わるのか
Spritelyは、中央集権型サービスに取って代わる完成済みの製品というより、原則とツールのパッケージを提供している。中核的な価値は、分散システムとセキュリティに関する数十年にわたる研究を開発者に再発見させるのではなく、セキュリティと分散性を開発者にとってデフォルトにしようとする点にある。ただし、この講演自体は、広範な採用、ユーザー体験、既存アプリケーションとの互換性、あるいは主体が切断されたり意見を異にしたりした場合のリソース管理方法に関する問題を解決していない。
ソフトウェアアーキテクトにとって、このアプローチの重要性は、きめ細かな権限管理と非同期通信、参照の受け渡しを組み合わせる点にある。開発者にとっては、ツールとプロトコルの成熟度、そして一般的な中央集権型アーキテクチャよりも簡単な運用モデルが利用できるかどうかが、依然として課題となる。
ニュースの出典
InfoQ - Architecture Articles
原文を開く ↗