Heroku Button で webrtc-bbs を容易にデプロイできるようにした
概要
Heroku Button という便利ツールが提供されるようになったので P2P 匿名掲示板 webrtc-bbs をそれに対応させてみました。
詳細
Heroku Button というツールが Heroku のブログで発表されています。
Heroku Button に自分の GitHub 上のプロジェクトを対応させれば、「他の人にそのプロジェクトを Heroku にデプロイしてもらう」といった作業がとても簡単になります。
今回、この Heroku Button に WebRTC を使った P2P 型分散匿名掲示板 webrtc-bbs を対応させてみました。
例えば以下のボタンを押すと、その人の Heroku アカウントで webrtc-bbs をホスティングすることができます。
ボタンを押すと Heroku へのログイン画面の後、アプリケーションの名前等を入力してデプロイする画面が表示されます。そこでデプロイボタンを押せば作業は完了します。簡単。
自分のアプリケーションを Heroku Button に対応させる手順は以下の通りです。
- アプリケーションに Heroku へのデプロイに必要なファイルを設置する (Node.js アプリケーションなら package.json だったり Procfile だったり)
- app.json を用意する
- Heroku Button を設置する
まとめ
Heroku Button に webrtc-bbs を対応させた
Heroku Button でますます広がるポータブル Web アプリケーション
この流れは P2P 型アプリケーションに実にマッチしている (この話は次回)
P2P ファイル共有の発展の鍵は経済学にある
未開社会の経済
アマゾン奥地に見られる未開社会では人々は狩猟により得られた獲物を分け合い生活している。食糧の分配は狩りで獲物を仕留められなかった者や狩りに出なかった者を問わず皆平等に行われる。しかし狩りは常に危険が伴うため、なるべく狩りに出ずに食糧を分け与えてもらおうとする者が現れる。ところが全員が狩りをやめてしまい、やがて食糧が尽きてしまうといったことは起こらない。なぜなら彼らの社会では狩りで獲物を仕留めた者は英雄として称えられ、逆に狩りに出ずに獲物を分け与えてもらってばかりいる者は相応の不名誉を被るからである。
Winny に見られる P2P ファイル共有ネットワークでは人々はファイル交換によって得られたファイルを分け合い生活している。ファイルの交換は頻繁にアップロードしている者やダウンロードに徹する者を問わず皆平等に行われる。しかし違法ファイルのアップロードは常に危険が伴うため、なるべくアップロードせずにダウンロードに徹しようとする者が現れる。ところが全員がアップロードをやめてしまい、やがてファイルの供給が尽きてしまうといったことは起こらない。なぜなら彼らの社会では需要の高いファイルをアップロードした者は ネ申 として称えられ、逆にダウンロードに徹する者は相応の不名誉を被るからである。
ものを交換する経済
経済が発展すると、人々はものを交換することを始めた。ものを効率的に生産するには分業が欠かせない。彼らは自分の得意とするものを生産することに専念し、自分で生産できないものはそれを生産している誰かを見つけ自分の生産物と交換することで得ることができた。
P2P ファイル共有が発展すると、人々は BitTorrent でファイルを交換することを始めた。ファイルを効率的に交換するにはファイルをピースに分割した上での分業が欠かせない。彼らは自分の持っているピースをアップロードし、自分の持っていないピースはそれをアップロードしている誰かを見つけ自分のピースと交換することで得ることができた。
貨幣の経済
さらに経済が発展すると今度は貨幣が登場した。貨幣はものの価値を統一的な尺度で測ることができ、さらにものを貨幣に換えて保存しておくことによって時間を超えてものの交換が行えるようになった。これによりものの交換はさらに広い範囲で行われるようになり、やがて市場が形成されるようになった。
さらに P2P ファイル共有が発展すると今度は貨幣が登場した。貨幣はファイルの価値を統一的な尺度で測ることができ、さらにファイルを貨幣に換えて保存しておくことによって時間を超えてファイルの交換が行えるようになった。これによりファイルの交換はさらに広い範囲で行われるようになり、やがて市場が形成されるようになった。
これまでの経済、これからの P2P
貨幣が登場すると商人が現れる。商人は地理的に離れた社会を行き来し、ものの価値の違いを利用して利益を得る。また貨幣を金利を付けて貸し出す銀行や、インフレ/デフレをコントロールするための経済政策、あるいは労働の対価として賃金を得る労使関係が生まれた。経済に関する思想もいくつも生まれた。
これからの P2P ファイル共有はどのように発展していくだろうか。現時点では経済の歴史における貨幣が生まれた年代にいる。それから経済は幾度も進化を遂げ、複雑怪奇なメカニズムを生み出した。この歴史をなぞるように P2P ファイル共有が進化していくとするならば、その進化をもたらすのは情報科学と経済学の両方に通じた人なのだろう。
参考
- 岩田規久男 経済学を学ぶ ちくま新書 1994
- BitTorrentの仕組み
- Anirudh Ramach, et al., BitStore: An Incentive-Compatible Solution for Blocked Downloads in BitTorrent, 2007
PeerJS でコネクションプールを実装した webrtc-connectionpool を公開しました
概要
WebRTC の定番ライブラリ PeerJS を使ってコネクションプールを実装した webrtc-connectionpool を公開しました。
tsujio/webrtc-connectionpool - GitHub
詳細
WebRTC のデータチャンネルはコネクション指向の通信インターフェースであり、コネクションを確立するためにはシグナリングサーバーによる SDP/ICE メッセージの中継が必要になります。
これでは例えば不特定多数の人とデータチャンネルでやり取りする場合に毎回コネクションを確立したりコネクションを大量に保持しすぎたりといった状況が発生し、パフォーマンスが心配になってしまいます。
そこで確立したコネクションを再利用できるように一定期間保持し、かつ保持するコネクション数を調節できるようにした webrtc-connectionpool を実装し公開しました。
特徴としては以下の通りです。
- WebRTC ライブラリとして PeerJS を利用している
- 一旦確立したコネクションは一定期間保持し、再利用される
- 保持するコネクション数はパラメーターとして指定可能
- コネクションが最大保持数を超えた場合は LRU 方式で破棄される
また、コネクションプール機能以外にもデータの送信とコネクションのクローズが重なった場合の対処など、webrtc-chord で得たノウハウが詰まったライブラリとなっております。
使い方
こんな感じで使えます。
セットアップ
// Setup var connectionFactory = new ConnectionFactory({ // An object to pass to the Peer constructor. // See the PeerJS document for details. peer: { id: 'yourid', options: { host: ..., ... } }, // The capacity of the connection pool. connectionPoolSize: 10 }); connectionFactory.onopen = function(myPeerId) { console.log("Setup ConnectionFactory: " + myPeerId); }; connectionFactory.onconnection = function(connection) { console.log("Connection from " + connection.getRemotePeerId()); connection.ondata = function(data) { console.log("Received data: " + data); }; connection.onerror = function(error) { console.log("ERROR: " + error); }; }; connectionFactory.onerror = function(error) { console.log("ERROR: " + error); };
コネクションの生成とデータの送信
// Create connection and send data connectionFactory.create(peerIdToConnect, function(connection, error) { if (error) { console.log("Failed to create connection: " + error); return; } connection.ondata = function(data) { console.log("Received data: " + data); }; connection.onerror = function(error) { console.log("ERROR: " + error); }; connection.send(data); });
まとめ
PeerJS でデータコネクションをプールするライブラリを書いた
不特定多数の人とコネクションを張る時に使えます
WebRTC を使って大規模な P2P ネットワークを張るサービスを作ろう
P2P 匿名掲示板 webrtc-bbs で伝えたいこと
概要
先日 WebRTC を用いた P2P 型分散匿名掲示板 webrtc-bbs を公開しましたが、これについて私が思っていること、伝えたいことを文章の形で表現してみます。
P2P の悪いイメージ
Peer-to-Peer (P2P) といえばまず思いつくのがファイル共有ソフトです。P2P のアーキテクチャーは大容量のファイルの交換に適している一方、その匿名性ゆえにしばしば著作権を侵害するようなファイルの交換に利用されてきたことは周知のことかと思います。
日本で最も有名なものは金子勇さんによる Winny でしょう。Winny も他の P2P ファイル共有ソフトの例に漏れず、「例外的とはいえない」数のユーザーにより著作権侵害ファイルの交換に利用されました。
その結果、作者の金子さんは著作権侵害行為の幇助の罪で起訴され、およそ 7 年の間検察を相手に法廷で争うことになりました。そして 2011 年、金子さんに著作権侵害幇助の意図はなかったことが最高裁により認められ、裁判は無罪判決で幕を閉じました。
しかし現状として「P2P に関わると逮捕される」「サービスに P2P 技術を導入していることは伏せるべき」さらには「P2P 即ち悪」といった価値観、イメージが P2P に対して定着してしまっていることは否定できないと思います。そしてそれにより P2P で何かを表現したい若者が気後れしてしまい、その機会を失ってしまっている のではないかと思います。
P2P は夢と自由の技術である
確かに著作権を侵害する行為は罰せられるべきですし、Winny は作者の意図に反してその温床となってしまいました。
しかし、Winny や他の P2P ソフトには未来に繋げるべき素晴らしい技術、教訓があるということも事実だと思います。
P2P に見る夢
私たちがインターネットにおいて何かサービスを提供しようとする場合、その多くはクライアント/サーバー型のアーキテクチャーで実現されます。サービス提供者はクライアントをまかなうためのサーバーを用意する必要があり、サービスが大規模になると必然としてサーバー、ネットワーク設備への投資も大きくなりがちです。
これでは学生や非営利の団体のような経済力の大きくない開発者にとって、サービスのアイデアはあっても金銭的な問題によりそのアイデアを諦めなければならない場面が少なからずあると予想されます。
しかし Winny の例を見てみますと、ACCS の調査 によると 2007 年では 30 万のノードがファイル交換に参加していたことが分かります。30 万のノードが同時に大容量のファイルを交換するサービス。これを金子さんは 何も特別なインフラを保持せずに 展開していたのです。
「P2P でなら設計次第で世界中で利用されるサービスを安価に展開できる」という夢を、Winny は私たちに示してくれています。
P2P に見る自由
インターネットは誰にでも自由な情報発信の機会を与えてくれますが、時としてその自由な表現が一部の権力によって規制されてしまうことがあります。そしてそれは常に外国で起こっていることばかりではなくて、日本でも 2008 年の青少年ネット規制法、2013 年の特定秘密保護法などインターネットを規制する動きは存在しています。
「自由」はとても難しい問題です。私自身もまだ確かなことを語ることはできませんが、それでも伝えたいことは、表現の規制や検閲が一部の権力によって行われるのは望ましくないのではないか ということです。
P2P では表現の場はそこにいる人たちで作り上げられます。一部のサーバーを停止させれば場は失われるといったことはなく、「不当な」規制、検閲に対抗できる力を持っています。そして 規制や検閲は場を構成する人たち自身により行われるべきである というのが、今私が考え、試行錯誤していることです。
P2P は自由を表現する力を備えているとともに、真の自由について考えさせてくれる技術です。
まとめ
参考
WebRTC による P2P 型分散匿名掲示板 webrtc-bbs を公開しました
概要
WebRTC を利用した P2P ネットワーク上で動作する分散型匿名掲示板システム webrtc-bbs を開発しています。
また、テストとして現在 Heroku にデプロイしています。
詳細
WebRTC とはサーバーを介さず Web ブラウザー間でリアルタイム通信を行うための規格・API です。
今回この WebRTC による P2P 接続を多数のクライアント間で行い、Web ブラウザーによるオーバーレイネットワークを構築して、その上で動作する掲示板アプリケーションを実装しました。
内部的な仕組みについては別の記事で紹介します。
なお、まだ開発途中のため 匿名性に関する実装は不十分です 。これにより損害等被った場合は自己責任でお願いします。
このアプリケーションの目的
従来のようなクライアント/サーバー型の Web サービスを提供する場合,規模が大きくなるにつれてサーバー・ネットワーク設備への投資が大きくなってしまいがちでした。
そこで今回のようにサービスを P2P 型で実現できれば、サービス提供者側の負担を抑えられ、また設計次第では 学生のような経済力のない開発者でも世界中で利用されるような Web サービスを展開することができる のではと思います。
今回は掲示板という原始的なシステムですが、応用次第では Wiki や SNS のような CGM (Consumer Generated Media) と呼ばれるサービス、さらには CDN (Content Delivery Network) のようなサービスも実現可能です。またマルチメディアを扱える WebRTC の特性を活かして、サーバーレスな P2P ストリーミング配信を行うことも考えられます。
※ まだ夢は書き足りてないのですが長くなるので別記事にします
2014/07/19 追記: 夢の続きを書きました
まとめ
WebRTC で P2P 匿名掲示板作ってます
悪用しないでね
お金がなくても大規模サービスを展開できるインターネットを
参考
WebRTC でカメラからの映像を多段中継して配信するサンプル
概要
WebRTC を用い、カメラからの映像を多段中継して配信するサンプルを書いてみました。
tsujio / webrtc-relay.html - Gist
詳細
WebRTC はサーバーを介さない P2P 通信を Web ブラウザー間で行うことができます。
さらにカメラやマイクから取得したビデオ、オーディオといったマルチメディアをやり取りする機能を WebRTC は持っています。
これらのことから誰もがやりたくなるのが P2P ビデオストリーミング配信 です。
という訳でカメラから取得したビデオを多段中継するサンプルを公開してみました。
- 利用にあたっての注意
- WebRTC をサポートしているブラウザー でご覧ください
- Chrome では URL のスキームが
file://
の時はカメラ等のデバイスにアクセスできないようです
困ったこと
多段中継するに当たって、現状では映像は中継できるのですが音声は中継できないようです。
この問題についてはここに将来的にサポートするよと書いてある気がします。
まとめ
WebRTC でビデオの多段中継サンプル書いたよ
そのうちそれっぽいシステム作りたいよ
早く音声も中継できるようになりたいよ
Immutable Infrastructure はプロセスとして扱うインフラだった
概要
最近話題の Immutable Infrastructure ですが、一体何者だろうと考えたところ「インフラをプロセスのように扱う」ことだという結論に至りました。
Immutable Infrastructure
Immutable Infrastructure とは昨今話題となっているサーバーインフラについての概念で、サーバーを Immutable、つまり状態をなくすことによって主に管理・運用面で様々な恩恵に与ろうというものです。
与れる恩恵については以下のスライドが分かりやすいです。
Immutable Infrastructure #jawsdays by Naoya Ito
この Immutable Infrastructure について一家言持ってみようということで、その意味について考えてみました。
Infrastructure as Code
Infrastructure as Code とはインフラの構成等をプログラムコードの形で記述しておき、そのコードを実行することで目的のインフラを再現できるようにしておきましょうというものです (参考: Infrastructure as Code - naoyaのはてなダイアリー)。
このインフラの構成をプログラムコード化したものをここではレシピと呼ぶことにします。
Immutable Infrastructure のやり方ではこの Infrastructure as Code に倣ってインフラを構築するレシピを用意し、インフラを気軽に作ったり壊したりできるようにした上で、インフラの状態を更新する時はレシピを更新して再度新たなインスタンスを生成します。
Immutable Infrastructure はプロセスである
Infrastructure as Code によってインフラがレシピ化されました。そのレシピを実行するとサーバーというインスタンスが生成されます。
これは丁度プログラムを実行するとプロセスというインスタンスが生成されることのアナロジーとして見ることができます。
Immutable Infrastructure ではインフラに状態を持たせません。つまりインスタンスを破棄すると保持していたデータは消え、何度インスタンスを生成しても同じ状態のものが得られます。
一方プロセスについても、終了するとメモリは解放され、何度同じプログラムを実行しても同じ状態のプロセスが生成されます (環境変数や引数は外部の状態と見なします)。
また、Immutable Infrastructure ではログ等のインフラに状態を持たせる要素を外部 DB に保存するという対策が取られますが、これはプロセスがデータをハードディスクに保存することと同じことだと考えられます。
図にするとこんな感じになります。
この図では「レシピ <---> サーバー」の関係と「プログラム <---> プロセス」の関係を相似と見ることができると思います。対応関係としては次のようになります。
Immutable Infrastructure | プロセス | |
---|---|---|
生成元 | レシピ | プログラム |
外部記憶装置 | 外部 DB | HDD |
一時記憶 | メモリ、HDD | メモリ |
インスタンス間通信 | ネットワーク、DB | ネットワーク、ファイルシステム |
このような考えに立つと、昨今の流行であるレシピのバージョン管理、レビューや Serverspec によるインフラのテスト等、元々プログラム開発で行われていた技法がインフラ開発に取り入れられたのも納得できます。
また、GitHub や Travis CI、Docker Hub のようなサービスを連携させて複雑なシステムを組み上げるのも、プロセスをパイプラインで繋いで複雑な処理を行うようなイメージで捉えることができるかと思います。
まとめ
Immutable Infrastructure はプロセスだった
Immutable Infrastructure ではインスタンス内の HDD は揮発性のメモリと見なそう
Docker はまさしくプロセスで Immutable Infrastructure を実現してる