絶賛、反省発売中。
IT屋全力反省会が書籍になりました！
ご購入はこちら
ITは本当に世の中の役に立っているのか？そもそもITなんていらないのではないか？……といった本質的な問いを胸に秘めながらも、第一線で活躍する二人のIT屋が、バズワードについて、Slerの幸せについて、データベースについて、クラウドについて、エンジニアのキャリアパスについておおいに反省したりしなかったり……エンタープライズITの現場の実情が立ち上る生々しい対話です。
Webでは読めない、神林飛志さん、井上誠一郎さんによる渾身のオリジナルまえがき、あとがき付き！
ぜひご反省ください！
P2Pの黒歴史
編集部 前回の終わりに次のお題の候補として出てきたのが、分散or集中、クラウド、SI、人材育成、トランザクション、Fintech、ブロックチェーン…といったあたりになっております。今回はどうしましょうか。
神林 個人的にはブロックチェーンについて、井上さんに聞きたいですね。というのも井上さんはずっとP2Pでしょ。だから言いたいことが山ほどあると思うんですよね。それをいろいろ聞いてみたい。
井上 ブロックチェーンだけではそんなに時間がもたないかもしれないので、分散集中の絡みで話せばいいかと。
神林 分散処理の話から入るのだったら、井上さんが今までどんな風に分散処理の流れを見てきて、この先どうなると思っているっていうところから、やっぱりおたずねしたい気がします。ずっと、井上さんは分散じゃないですか、キャリア的に。
井上 まあ、そうですね。
神林 P2Pから来て、今、ワークスのプラットフォームをCassandraに大幅に変更するところですよね。歴史の流れとか、それぞれのコンテキストでなぜ必要だったのか。そのとき必要とされている環境とか、エンジニアとして勉強していかなきゃいけないこととか変わってきていると思うんですけど、これをどのように見ているか、先達としてどんな感じかなっていうあたりを聞きたいです。
井上 神林さんも分散系じゃないですか。
神林 僕もそうですね。ただ、僕がはじめたのはHadoopのちょっと前くらいなので、それより以前のものっていうのは、まあ、漏れ伝わって聞いていた限りだと、日本的には、「すごいけど使い物にならない」っていうのが相場でしたっていうのは聞いていて。Gridなんかは形は出たけどパフォーマンスが出ずにギブアップでしたとかですね、そういう話を聞いているだけなので、そのあたりの、過去の流れから理論的なやつとか、表向きの話はともかく、実態としてこんな感じだったみたいなところが……
井上 じゃあ、P2Pの話からいきますか。
神林 P2Pの話からじゃないですかね。やっぱりP2Pの話はちゃんと、誰かまとめたほうがいいですよ！（笑）
井上 黒歴史かもしれない……(笑)
神林 黒歴史でしょ、どう見ても。だから絶対表に出ないし。たとえば、Notes時代のP2P、それから僕らからするとそのあとNapsterとか、ああいうものが最大手っていうか、話題になったし、使っている人も当然いたし、あの辺の時代から見ると、今の見え方って違うと思うんですよね。そのへんをおうかがいしたいですよね。ぜひ。
井上 なるほど。これ、結構話が長くなりそうだな（笑）。P2Pはそもそも、まあ、最近またブラウザ間でやったりとか、本当にかつてのNapsterの時代とか知らない世代もいるかもしれないですけど、NotesはP2Pじゃないですね。
神林 そうなんですか。
井上 うーんと、まあP2Pもいろいろ定義があって、前回もいろいろ定義したんですけど(笑）。Notesの特徴が分散、というのはあります。非同期的なレプリケーションで、マスターマスターなので基本的にはコーディネーションがなければコンフリクターを切ると。実際、コンフリクトを起こしてしまって、コンフリクトをユーザーに見せて解決するというある種の割り切り。ただ一方で、だいたいの業務アプリ、特に申請系は動いていた。あとはまあ、メールだったり、比較的ウェルパーティショニングにデータができればだいたいうまくいってたのが、90年代。だいたい証明していたな、と。
ただ、それってあんまり流れ的にはP2Pは技術的に言うと関係なくて。人の流れでいうと、レイ・オジー、Notesの会社を作った人間が、Groove Networksという会社を作って、ちょうどまさにアメリカでNotesを作っていたころ、Grooveを作って、Notes作ってた開発者がどんどんGrooveに抜けていった時代なんですけど、あれが本当にP2Pの流れですね。で、時代をさかのぼると、それより前にNapsterはあったかな、確かに。
神林 それより若干前じゃないですかね。
井上 歴史の順序があいまいになっている……（笑）。Napsterがあって、Gnutellaとかがあって……Notesはもっと前ですね、85年くらいからあって。Napsterは90年代なのかな……95年とかそれくらいですね。で、ファイル共有の世界では大爆発して、WinMXとか、Winnyとか、ファイル共有の世界ではうまくいくことがある程度実証されていて。
ビジネス方面で言うと、レイ・オジーがはじめたGrooveがあって、日本で言うと、我々みたいなアリエルがあって、そのあとSkypeが現れたりですね。さらにアカデミックのほうで、そのあとにDHT、分散ハッシュテーブルが出たのが2000年前半、というのがだいたいP2Pの流れ。分散ハッシュテーブルが出たころにはアカデミック的にはある程度理論は整理されていましたけれども、商用的にうまくいったのはSkypeぐらいだったかな。Skypeと、あとはBitTorrentが比較的うまくいった実例。それ以外はGrooveも結果的にMicrosoftに買収されて、ほぼ消え去って、アリエルもビジネス的にはいまいちだったからワークスと一緒にやることになったり。
神林 後進から見ていると、当時の分散の理論的な、たとえばLamportとか活躍した時代って80年代じゃないですか。そのときの理論と、そのときの現実の分散のシステムというか、あり方ってかなり乖離があるっていう印象を受けるんですが、その当時はどういう風に見られていたんですか。
井上 いわゆるトランザクション管理を、その当時はけっこう割り切っていた感じがしますね。Notesもそうですし、ファイル共有もコンフリクトしたら.1とか.2とかで打っちゃえばいいじゃんっていうレベルだし、Skypeとかになると逆にもうデータの整合性はないので、単なるメッセージング。なので、もともとあった分散のトランザクション系の話と、当時のP2Pはあんまり連携していなかったですね。
神林 なるほど。今後もすごく話題になると思うんですけど、複数のノードがあって、部分的に更新されてしまっていて、どっちが正しいかわからないというようなことっていうのは当然、理論的には解きづらいし、いまだに、解けたという人もいるんですが、結果、ほとんど9割がたの人は解けてないでしょっていうのが現状の結論で、その問題っていうのは話題になったんですかね？LamportのByzantine障害とか、あのあたりですが。
井上 あったんですけど、さっきも言ったように比較的、コーディネーションよりは、マージして一定のところに落ち着けばいいっていう結構現実的なところで、それでコンフリクト来たら.1と.2みたいに2つ持てばいいじゃんって割り切っていましたね。
神林 なるほど。それは、そういう実際の現実の運用からしてみた時の結論は、コーディネーションを最終的にはヒューリスティックにやりなさいって話じゃないですか。それがそうせざるを得ないのか、それとも環境が変わってくれば、ある程度そういうこともやらずに、なんらかの手法で、割り切ってオートマティカルに正しいほうに振るのか、それができればそれに越したことはないとは思うんですけど、そういう風になるような感じがしますかね？
井上 あんまりしてないですね。あんまりしてないですけど、まあ、状況としても、マージもなんとなくアプリケーションレイヤーでやっていたものがCRDTみたいにオペレーションとしてきちっと形式化されるとかの進歩はあるかもしれないですけど、それ以上はちょっと、Quorumによる結果整合性、Paxosを使うCAS操作みたいなものがある程度レイヤーとしてできて……ぐらいが、本当に分散を問い詰めるなら、限界点かなという気がします。
