THINKING MEGANE

情報要求を取り巻く技術とプロセスモデル

情報検索にまつわる開発を行っていると、情報検索や情報推薦の技術詳細、つまりシステム側に注目しがちである。しかしながら前回のエントリで触れたように、情報探索のプロセスには、これを駆動する主体である利用者が存在する。

情報要求を取り巻く技術とプロセスモデルの関連を以下のように図に起こしてみた。

association_chart

利用者は何らかの情報要求をクエリなりの具体的な要求の形でシステムに問い合わせを行い、システムはシステムの持つ文書集合から検索や推薦などの技術を用いて最適と思われる結果を応答し、必要に応じクエリ修正と再問い合わせといった一連のインタラクションサイクルを繰り返す。

狭義の情報検索技術は、静的な情報要求から作られた相互に関連を持たないクエリ集合に対しての適合性を評価される。これは上図で言う所のインタフェースより右側のみで完結するため定量的な評価が行いやすかった。一方で、利用者サイドを中心とした情報探索のプロセスモデルに関する先行研究により、情報要求は、探索プロセスのステージや個々人の戦略、検索結果など様々な文脈により変化していくことがわかっている。

これは、文脈により最適と考えられる応答が変わっていくということである。すなわち情報検索技術間での優位性を比較するのではなく、情報要求の背後にある利用者の文脈や状況、課題設定を把握して、適切な情報検索技術を選定するようなアプローチが考えられる。

また、利用者の存在を意識すると、情報要求を形にするまでの認知的な負荷を下げるため、曖昧だったり、人間的な感覚に近い問い合わせに対しても少ない試行回数でたどり着けることが重要となってくる。より先進的には、課題設定自体の明確化を支援する仕組みも必要かもしれない。

これらをまとめると、利用者の取りうる行動が文脈により変化すると仮定した上で、精緻な文脈の把握並びに課題設定の明確化支援を通して、直感的な問い合わせに応答できる仕組みが求められると考えられる。

そのため、まずは自身の課題環境において、

  1. 文脈により応答の評価が変わることを確認
  2. 利用者の文脈のパターン分類と識別手法の確立
  3. 必要に応じて直感的な問い合わせに応答できる検索情報技術の導入
  4. 課題設定の明確化支援の検討

のようになりそうである。

なお、こういった利用者の背景を踏まえた評価は適切性や有用性といった観点での定性的な評価が必要となってくるそうで、別途文献をあたりたい。

参考文献

情報探索プロセスのモデルについて: 「情報検索のためのユーザインタフェース」を読んで

商品検索や推薦に対する課題感から、「情報検索のためのユーザインタフェース」を読んだ。検索という行為を分類整理した上でユーザインタフェースについて検討しているため非常に納得感があった。特に情報探索プロセスのモデルとして整理されている部分が、自分の課題に対して役立ちそうなのでまとめておく。

情報探索プロセスのモデル

この文献では、探索プロセスの代表的なモデルとして「標準的モデル」「認知モデル」「ダイナミックモデル」「ステージごとの情報探索」「戦略プロセスとしての情報探索」「意味形成」の6つを紹介している。それぞれのモデルの関係は以下のようになると思う。

model

以下、簡単に各モデルの概要を述べる

情報探索の標準的モデル

情報探索のプロセスを「情報要求の特定」「クエリ指定」「結果の精査」「クエリ修正」と言ったインタラクションのサイクルであるとみなす。 研究者によってインタラクションの定義は様々だが、これらが元となる情報要求を満たすまで繰り返し、クエリを精緻化するという基礎的仮説に立つ

情報探索の認知モデル

標準的モデルを(Norman, 1988)の一般タスク性能の影響モデルを用いて認知的な側面から説明する。

ダイナミックモデル(ベリー採集モデル)

標準的モデルの元となる情報要求を満たすまでという基礎的仮説に対し、検索者のインタラクションの継続に伴い情報要求そのものが変化するという観察的研究から得られた発見に基づく立場に立つ。 ベリー採集モデルは(Bates, 1989)、検索プロセスの進行に伴い、情報要求とクエリが連続的に変化する、そして情報要求は連続した選択と過程で得られる断片的情報によって満たされるとした。

ステージごとの情報探索

情報プロセスの継続の中で、情報プロセスがどのように発達するかを検証する。(Kuhkthau, 1991)の研究では複雑な情報探索タスクを対象として、検索プロセスが、開始、選択、探索、作成、収集、プレゼンテーションと言ったステージを経ること、そしてそれぞれのステージにおける感情的パターンがあることを見出した。

後段のステージは収集した情報を解釈整理しているフェーズとも取れるので図では中間に位置付けてみた。

戦略プロセスとしての情報探索

検索プロセスを戦略の選択として捉える。

(Bates)は戦略を方策の集まりであると定義する。方策は、クエリ語の修正や具体化、情報構造を辿ると言った検索行為と結果に対する方策と、モニタリングと呼ばれる現状の把握があるとした。モニタリングはコスト利益分析や目標との隔たり評価などを通して戦略の切り替えもしくは検索の停止などを行う。

モニタリング方策は詳細に研究され(O’Day, Jeffries, 1993, Russellら, 1993)、有用性に基づく戦略の判断が行われているとした。(Pirolli, Card, 1999)による情報採餌理論は食糧採集のメカニズムを転用した情報探索、発見、消費といったタスクに転用することで、検索と閲覧のコストに対して価値ある情報比率を最大化するように戦略を発達させるとした。

また、共通する検索戦略として、(Marchionini, 1995, Bates, 1990)は検索者が、完璧なクエリではなく、不確かなクエリを発行し、興味ある情報に接近することを繰り返す。(O’Day, Jeffries, 1993)はオリエンテーリングと呼びこれを説明した。 この行為は心理学でアンカーリングと呼ばれる、初期のクエリを捨てられないといった大胆な調整が行えない状況も招く(Hertzum, Frokjaer, 1996)

意味形成: より大きなプロセスの一部としての検索

情報アクセスのプロセスは大きく、検索とブラウジングを行う情報検索と、情報結果の分析と統合を行う二つのコンポーネントに分割できる。これは意味形成というプロセスと呼ばれる。(Russellら, 1993) すなわち意味形成は、大量の情報を検索、解釈を繰り返しながら概念表象を形式化していくプロセスである。検索がこのプロセスの一部であることを意識した上で、解釈を支援することが求められるとした。


まとめ

この文献では、検索システムを利用するユーザーの行動や認知を詳細に分類し、情報探索モデルとしてまとめた。通常、検索システム側の観点から議論してしまいがちだが、両面からの観点が重要であることがわかる。

システム側では、情報要求がダイナミックに変更していくとすると、状況に応じて求められる検索結果も変わると考えられる。すなわち、情報要求が現在どの状況にあるか把握し、それらに応じた結果の提示、そして評価の結果、柔軟に探索を軌道修正できるような仕組みが求められるだろう。文献ではユーザインタフェースの観点からこれらの取り組みに関する先行研究も紹介されている。

ただし、情報要求は多種多様であり、先行研究が前提としている要求と自身の課題の要求分類が合致するか加味しながら参考にしなければならない。この辺りは、実際に適用、評価の中で見出していきたい。

2018, 認知的転回

2018年が始まる。今年の抱負などをまとめておきたい。

こだわらない

昨年は、ふりかえりにあったように、人生最高潮に達したあらゆるものに対する固執が目を曇らせ、足を引っ張っていたように思う。他の人からすごいと思われたい、あっと驚く成果を短期的に努力している風を見せずにいきなり出したい、全てOSSにして世間から認められたい、エトセトラエトセトラ…

今年は、特に外的な動機で反応的に動くのをやめようと思う。大きく目標を見据えて、目先の手段や方法論にこだわらずに、一歩づつ、でも着実に必要なことを進めていきたい。

まずは昨年の類似画像検索を、なめらかなシステムから見る情報要求の照合として位置付けた上で、評価考察して、ジャーナルに向けて進めたい。 最終的には、なめらかなシステムから見る情報要求の照合を体系化しながら、個別技術を順々に適用しつつ育てていくという風にできたらなあと考えている。

思考の言語化に努める

現状の自分の限界から一つ進むために確実にやらないといけないことは、思考の言語化であり、これができないと論文で新規性も語れないし、そもそも進むべき道も与えられることでしか見えてこない。

実際は、何年も課題意識を持ちながらも打つ手がない状態だったのであるが、昨年読んだエントリや同僚の論文システムを読むとやはり量が前提であるというのがわかる。これまではなんかよく思われたいという見栄からだんだんと腰が重くなっていたので、数をこなすというのが一つ。しかしながら、熟考というのも同時に必要だろうとは思う。

そこで、思考を言語化するに当たって、数を打つのは、エッセイ的な気楽さのエントリを続けることで慣らしながら、研究会に向けては都度議論の上で考えを深めた成果を発表していくという二本立てでやってみたいと思う。特に気楽なエントリは自分にこびりついたよく見られたいというエゴをそぎ落とすような感覚を持ちながら、書いていくことでこだわらないも支援できたらいいなと考えている。

人生の解像度を上げる

ここ数年、近視眼的に過ごしてきたことで、なんだか味気がなかった気がする。何かを学んでもその場限りで、イベントも参加しながらもこなすだけ、見ているようで見ていない、そんな気分だった。プライベートも同様で、それなりに平和に暮らせたと思うけども特に何の思い出もない気がしている。

外部刺激のうち解釈側に影響を与えることができたものを情報というらしい。外部からの評価やその場限りのノリだけは自分を揺さぶったけども、もう少し小さな穏やかな刺激にも反応できるようになりたいと思うし、それが周りを見る余裕になるはずである。

思考の言語化に対する取り組みがその一助になるとは思うけども、相手のことを思いながら過ごす時間というのを大切にしたい。

だから新しいカメラが欲しいです。


何だか昨年までと比べてこれはこれで極端だなあと思いながら、いろいろ試しながらやっていきたいと思います。2018年もどうぞよろしくお願いいたします。

2017年, 12月のライオン

2017年が終わる。今年は大いに迷った年だったと思う。

これまで携わってきたサービス運用開発から念願の研究所に移動になった僕はとにかく意気込んでいた。最初の半年間は、研究と開発が一体となって事業を差別化する技術を作り出すという研究所のミッションに従い、サービス開発の経験を生かして、現場の課題を解決する技術を習得し、導入することで実際に成果を上げていった。研究報告という形で査読なしではあるものの論文を2本書いた。201705,201706

研究員になって一番変わったことは、結果を論文をまとめる工程が発生したことだ。これまで技術ブログやOSSという形で成果物を発表してきたが、論文にまとめるのは難易度が違った。Wikipediaによれば研究の目的とは 突き詰めれば新しい事実や解釈の発見 であり、それゆえ、成果に対して、新規性、有用性を論文という形で示す必要がある。僕の場合、この新規性の部分に苦しんだ。新規性を証明するためには、その手法にまつわる既存の多くの研究についての知識の収集と、それらを自身の手法を導いた思考の構造のうちに組み込み体系化した上で理論的に差分を導く理詰めの作業が求められる。少なくとも自分自身のアウトプットに対してそのような訓練は積んでいなかったため、論文の研究所内でのレビューではその辺りを徹底的に指摘された。

それでも上期2本はなんとか勢いだけで書けた。サービス時代に抱えていた課題と自分の習得した技術がうまくマッチしたことで、両方とも成果が出ており、有用性の部分を主としつつ、自分なりに導いた新規性も指摘盛りだくさんながら書き上げた。

問題は下期である。いうても30代後半のそれなりに技術に対してプライドを持ってやってきた自分である。下期こそは、サービスとしての成果と論文としての成果が両立するようなバリューを出してやろうと臨んだのが勇み足の始まりだった。当時、僕の課題解決アプローチは既知の機械学習手法とサービスを連携させることであったため、サービス適用における知見はありつつも新規性としては示しにくいと考えていた。考えていたというのはその知見でも十分に既存の研究と比較した上で新規性を導くことができれば問題ないのではある。しかしながら、上期の指摘と自身への評価を挽回するため、自意識の肥大した僕は、もっと革命的な、もっと同僚も上司もが納得するようなバリューを追い求め出していた。

ある種、歪んだ動機は、固執を呼び、本来の目標を忘れさせ、堂々巡りを繰り返させる。下期をかけて新しいこと、今まで取り組んでなかったことを盲目的に探し、試し、そして撃沈していった。指針なく手当たり次第やるものだから、体系的な知識は蓄えられず、案に固執しているので客観的な評価もできず、それにより、納得する議論もできない。時間だけが過ぎていくから、より短時間で効果が出るものを求め、悪循環が始まる。次第に意固地になり、相手の意見も聞かず、独りよがりの自称研究として、本を読み、意図もないOSSを書く。それをやっている時だけは後ろめたさから解放された気がした。

ある日、迷走する近況報告のやりとりの中の冷静な指摘に対し、僕は、もうどうしたらいいのか分からないのだと伝え、周りを困らせた。僕の研究がなぜうまくいかないのか話す機会が設けられ、客観的に上記の状態を認識し、サーベイ、考察、評価を短いサイクルで繰り返す環境を整える必要性などを指摘された。これらは冷静になりさえすれば分かったことだとは思うのだが、最も効いたことが、研究に向けてのサーベイや基礎文献の調査量の違いを見せつけられたことである。下期の迷走期は別にして上期などは自分なりにサーベイしたつもりだったが、新規性にたどり着くための知識の土台は生半可なものでは太刀打ちできないということを痛感した。「巨人の肩に乗る」だけでも大変だからこそ、そこに積み上げた小石が大きな意味を持つ、当たり前のことではあるが、結局はそこから逃げていたのだと思い至り、自分を恥じた。

同じ頃行われたWSA研も研究に対する取り組み方を見直す良い機会となった。WSA研は、Webを中心とした様々な技術要素および要素のつながりを含む系全体のアーキテクチャを議論 をする意欲的な場であり、参加者は皆自分の思い描く最高の世界に向けて、それを実現するためのアーキテクチャを語っていた。自身は色々手を出したものの一つを発表したので、やはり満足いく発表とはならなかったが、この会で、tomomiiさんから「道をつくる」という、研究やコミュニティのあり方を東洋思想的な道という概念を使って考察する話があって感銘を受けたのを覚えている。

これらを通して、僕は研究を目的でも手段でもなく、「過程」なのだと漠然と考えるようになった。自分の思い描く世界に至るための過程。その理想はこれまで存在しないものであるだろうし、もし理想像が朧げに見えたとしてもそこに至る方法もまた未知のものであるだろう。それは、これまでの研究や知識を着実に学んで、意味のある構造で組み直し、未知の道の敷石をつなぐことで見えるものであって、そこは新規性や有用性を逃げずに練ることだけでしか辿り着けない。論文にまとめるということはそのための最適な訓練であり道中に標石を設置することなのだろう。

そんなことは最初から言ってたよと研究所の人たちから怒られそうではある。今になって思えば、研究所の面々は常に僕に「つまりこういう世界が来るということですね、いいじゃないすか〜」「サーベイはこれだけですか」「無理をしないよう」と一貫して、目標を作ること、巨人の肩に乗ること、道半ばで倒れるなと変わらぬ態度で研究の在りようを示してくれていた。が、挑み、努力する対象を見誤ませるほどに虚栄心が自分に根を張っているとは思わなかった。自分の現状を納得いく形で理解した上で次に進むためにやることが見えたのは今年唯一の収穫である。半年間、本当に辛くて家で泣いたりしたのだが、変わらぬ態度で接してくれた研究所の面々、そして支えてくれた家族には感謝の気持ちしかない。

2018年は、専門知識を深め、そこに見えた新しき世界へ向けてただ一歩づつ進んでいければと思う。成果は自ずとついて来るだろう。来年もどうぞよろしくお願いいたします。

  • 3月のライオンという将棋を題材にした漫画は、弱さを受け入れ、迷いながらもただひたすらに自分の道を信じて進んでいく棋士たちの物語で、もちろんフィクションなのだが、自分と向き合う大切さというのは今年かけて学んだことに近いなあと思ってタイトルに入れた。

WEB+DB PRESS Vol.102で「サービス改善につながるログ活用基盤の構築」を執筆させていただきました

WEB+DB PRESS Vol.102で「サービス改善につながるログ活用基盤の構築」を執筆させていただきました。この記事は連載「実践! 先進的インフラ運用」の第四回目の担当記事です。

サービスにとって重要なログをFluentd、Rackミドルウェア、Treasure Dataなどを用いて収集し、ワークフローと組み合わせて分析、さらにサービスと連携させることで活用していく。そんなログ活用基盤の楽しさを詰め込んだ記事となっております。ぜひ年末年始のお供として手に取ってみてください。

wdpress_102

商業誌への執筆はいつかやりたいと思っていたことだったので、とても嬉しいです。実際に書籍として手にとるとニコニコしてしまいますね。えへへ。

分散アプリケーションにおける複数端末利用を考慮したプライベートデータの管理

このエントリは、第一回 Web System Architecture 研究会 (WSA研)の予稿です。

1. はじめに

ブロックチェーン技術の登場により、インターネットを経由した個人間での直接の価値交換が容易となりつつある。

これまで、インターネット上での個人間での価値交換の場を提供してきた、マーケットプレイス型のECサイトや、シェアリングエコノミーの代表である、AirbnbUberは、一旦情報を集約し提供する仲介者としてのビジネスを行ってきた。これらのビジネスはニーズのマッチングと取引の信頼性の提供の二つの側面で価値を提供している。一方、ブロックチェーンは、非中央集権的な台帳管理をトランザクションの順序性を明確にするデータ構造とブロック生成と検証に系が正しく回るような仕組みを組み込むことで、信頼性の提供を実現する。このように中央集権的な存在を介さないブロックチェーン上で動作するBitCoinやEthereumが通貨や契約機構としての役割を備えることでボーダレスかつ多様性を持った直接の価値交換が可能な仕組みが整ってきた。

実際に、StorjFilecoinといったストレージの空き容量を価値へと交換する分散型ファイルストレージサービスや、P2P上でマーケットプレイスを開設しBitCoinで支払いを行うOpenBazzarなどが登場している。

これらの価値交換プラットフォームは自律しており、中央集権的な運用やサーバーが存在しない。言い換えれば参加者全員がサーバーでありクライアントである。このような非中央集権的な価値交換プラットフォームの登場は従来型のWebサービス提供者に対してパラダイムシフトを迫るものである。

本研究報告では、非中央集権的な価値交換プラットフォームにおけるアプリケーション実装の考察を行い、用途別データ管理、特にプライベートデータの取り扱いの方式について検討する。

2. 分散アプリケーションにおけるプライベートデータ管理の課題

非中央集権的な価値交換プラットフォームにおけるアプリケーション実装は、中央集権的なサーバーが存在しないため、従来のアプリケーション実装方式は適用できない。そこで、本章でははじめに、非中央集権的なアプリケーション実装の方式とそれらの課題について述べる。

なお、本章以降、非中央集権的な価値交換プラットフォームにおけるアプリケーション、すなわち中央の管理を受けない自律分散型のアプリケーションのことを分散アプリケーションと呼ぶこととする。DAppsとして提唱されている分散アプリケーションとは異なることに留意されたい。

2.1 分散アプリケーションの実装と用途別データ管理

従来の中央集権的なサービスは、サーバー、クライアント方式をとるが、分散アプリケーションではアプリケーションやデータはその分散ネットワークに参加する個々の端末に分散される。

例えば、P2PファイルシステムとBitCoinを用いたマーケットプレイスを提供する分散アプリケーションであるOpenBazzarの構成は以下のようになる。

  1. 商取引の履歴はブロックチェーン上に保存
  2. 商品の情報はP2Pファイルシステム上に保存
  3. 利用者の情報は端末に保存
  4. アプリケーションはローカルで起動し、上記のデータをつなぐ

ブロックチェーンはその信頼性から、分散アプリケーションが重要とみなす取引の履歴を保存する。しかしながら、台帳記載に手数料がかかること、ブロックの確定にタイムラグがあることなどから重要度の低いデータや更新の多い情報はブロックチェーンの外側で管理される。また、取引自体が発生しないマスタデータなども台帳管理としては不適切である。つまり、分散アプリケーションでは用途に応じて管理されるデータを組み合わせて利用する必要がある。

2.2 分散アプリケーションにおけるプライベートデータ共有の課題

分散アプリケーションに必要なデータの多くは非中央集権な仕組みで分散されるため、その分散ネットワークに参加できる環境において、どの端末からも比較的容易にアクセス可能である。一方、利用者の情報は各端末に保存されるため、複数端末で環境を揃えるためには端末間でデータを共有する必要がある。本研究では、従来のデータ共有モデルの検討を通して、分散アプリケーションにおけるプライベートなデータ共有の課題を示す。

2.2.1 分散ファイルシステムとデータベース

マウント処理を通してサーバー上のデータ操作を透過的に行うことができるNFSや、端末上で操作したファイルがサーバー上に自動的に同期されるDropboxのようなアプリケーション、そしてデータを一元管理するデータベースサーバーなどは典型的な中央集権的なデータ共有であると言える。また、URLによって相互にドキュメントを参照する広大なドキュメントベースシステムとして捉えるとWWWもデータ共有の仕組みとみなすことができるが、各ドキュメントはサーバー単位で管理されており、これもまた、中央集権的なデータ共有となっている。

これらの手法は中央集権的なアプリケーション実装において利用されているが、非中央集権的な構成をとる分散アプリケーションの実装においては、これらの中央集権的な仕組みに依存しないことが望ましい。

2.2.2 P2P型データベース

Amazon DynamoDBやApache CassandraはP2P型の分散データベースであり、クラスタリングされた各ノードがデータを分散して保存する。これらのデータベースへのノード追加やデータアクセスは中央集権的にコントロールされており、基本的には閉じた専用のネットワークとして構築、運用される。

分散アプリケーションの実装においては、中央集権的な仕組みに依存しない開けたP2P型のネットワークであることが望ましい。また、そのネットワークは耐障害性や利便性の観点から参加ノードの多い、普及したネットワークであるとより良い。

2.2.3 P2P型分散ファイルシステム

非中央集権的なデータ共有としてP2Pネットワークを用いた分散ファイルシステムがある。データはP2Pネットワーク上のノードに分散して保存され、利用者は何らかのポインタによりそれらにアクセスする。IPFS(InterPlanetary File System)は、P2Pネットワークを用いたドキュメントベースのデータ共有モデルである。データの分散保存とデータ内容に基づくアドレッシングにより、従来のWWWのサーバー依存を取り除き、非中央集権的なデータ共有を可能にしている。また、IPFSはディレクトリ構造も扱うことができるため、端末のデータ構造との親和性が高いことも特徴である。

データ内容に基づくアドレッシングの場合、内容の変更がアドレスの変更につながるため、利用者は最新のアドレスを保持しておくことが求められる。なお、IPFSではIPNSと呼ばれる、固定アドレスと任意のアドレスを紐づけることができる名前解決の仕組みも提供することでこの問題の解決を図っている。

また、IPFSを始めとするP2P型分散ファイルシステムは、ネットワーク参加者にデータの内容が参照されてしまう。プライベートデータの共有のためには、データ参照を制限する仕組みが求められる。

2.2.4 P2P分散ファイルシステム上のデータストア

汎用的なP2P型分散ファイルシステム上でデータベースファイルを管理することでデータ共有を行う手法がある。IPFSを始めとするP2P型分散ファイルシステムはデータ内容に基づくアドレッシングを行うため、ファイル内容の一部変更であっても別データと見なされる。そのため、Sqliteなどの従来のデータベースファイルを直接配置すると変更の度に全データがP2P上に保存し直されることになる。これはデータ容量が大きくなるにつれて深刻なオーバーヘッドとなる。

そのため、P2P型分散ファイルシステムの特性を考慮したデータベースが必要となる。つまり変更の局所化であり、修正内容に対するP2P上への保存量が少ないほど良い。OrbitDBはIPFS上で動作するデータストアであり、データストアへのデータ追加更新削除などの操作内容履歴の一つづつをIPFS上にファイルとして保存することで変更を局所化する。

また、複数端末での利用を考えると、データの競合への対処が必要となる。分散データ管理におけるCAP定理では、CAPの全てを満たすことは難しいとされているが、このうち、APを満たすデータ構造であるCRDTが知られている。CRDTはデータが順不同であることを前提とし、データ操作を可換なものに限定することで参照整合性を提供する。先ほど紹介したOrbitDBも複数のデータストア種別においてこれをサポートしている。

なお、参照時はこれらの可換な操作の履歴を統合したものが利用されるが、履歴の増加に伴い参照時のオーバーヘッドが発生する。実運用ではメモリ上に展開しておくなどの工夫が必要となる。

3. 分散アプリケーションにおけるプライベートデータ管理手法の提案

ここまで、従来のデータ共有モデルを比較しながら、分散アプリケーションにおけるプライベートデータ管理に求められる要件を抽出した。要件は以下の通りである。

  • 1. 非中央集権的な構成であること
  • 2. 分散保存されるデータに対して参照制限をかけれること
  • 3. 開かれた普及しているP2P型ネットワークを用いること
  • 4. 最新のアドレスを保持または解決できること
  • 5. 変更が局所化されていること
  • 6. 変更の競合に対応できること
  • 7. 参照時のオーバーヘッドが少ないこと

3.以降はP2P型分散ファイルシステム利用にあたって必要となる要件である。本研究報告では、これらを満たす手法としてKaleidoscopeと名付けたOSSを実装、公開した。以降、Kaleidoscopeの構造と機能を示していく。

なお、文中の[*N]は上記要件番号と対応するものとする。

3.1 提案手法の構造

KaleidoscopeはP2P分散ファイルシステム上で動作するKey-Value Storeである。データ共有モデルとしては、前述のP2P分散ファイルシステム上のデータストアに分類される[*1]。また、P2PネットワークとしてはIPFSを想定している[*3]。

Kaleidoscopeのデータ構造は至ってシンプルである。データストア名、キー名をディレクトリとし、内容をファイルとするディレクトリ構造をIPFS上に保存する。データはタイムスタンプ等のメタデータと内容を合わせて暗号化が成される。暗号化は公開鍵方式で行われるため、秘密鍵の所有者以外は内容を把握できない[*2]。

├── __database_name
├── key1
│   └── value
└── key2
    └── value

Kaleidoscopeはデータストアと対応するディレクトリ構造の変更を内部で保持するだけでなく、IPNSを用いて固定されたデータストアのアドレスから最新のアドレスを解決する[*4]。

以上の仕組みにより、利用者はKaleidoscopeを用いて、キーとディレクトリアドレスとの対応、暗号化と復号化、最新のアドレスの解決を意識することなく、透過的に個人用のKey-Value Storeを扱うことができる。

次に、KaleidoscopeがP2P分散ファイルシステム上のデータストアの課題を解決する手法を紹介する。従来のP2P分散ファイルシステム上のデータストアは、ファイルシステムの特性を考慮しないファイルベース差分方式とOrbitDBに代表されるオペレーションベース差分方式と考えることができる。

Kaleidoscopeはデータストアをディレクトリ構造で表現することでこれを解決するディレクトリベース差分方式を提案、採用する。

ディレクトリベース差分方式での値の更新はキー単位に分離されており、データストア全体のデータ容量に依存しない[*5]。また、更新後のディレクトリ構造のアドレスを参照するため、常に最新の値を更新履歴に依存せず取得することができる[*7]。さらに値を表現するファイル内容にタイムスタンプを持つことで、ディレクトリ構造としての統合が可能になる[*6]。CRDTの思想に添えば、順不同な可換な操作を統合できればよく、必ずしも全履歴を保持する必要はないためである。

3.2 提案手法の機能

Kaleidoscopeの基本的な利用方法を以下に示す。

# IPFSデーモンの起動
$ ipfs daemon

# Kaleidoscope CLIによるIPFS操作
$ kes
> create my-db
# => データストア用の鍵ペアの作成とディレクトリをIPFSに登録
>
> set key1 value1
# => IPFSに暗号化して保存
>
> get key1
value1
# => IPFSの該当するディレクトリ構造からファイルを取得し復号化する
>
> save
# => 最新のハッシュ値でIPNSを更新する

端末間の共有に対してはuseコマンドを利用し、最新のハッシュ値を得ることができる。

$ kes
> use my-db
# => IPNSから最新のハッシュ値を得る

ただし、現状の実装ではIPNS更新に数秒かかるため、リアルタイムに端末間でデータを同期することが難しい。そこで、IPFSのPubSub機能を利用して変更の操作履歴を共有するsyncコマンドを実験的に用意した。

# PubSubオプションを指定してIPFSデーモンの起動
$ ipfs daemon --enable-pubsub-experiment

$ kes
> sync
# => 以降、オンラインの他の自身の端末からの操作履歴が共有される

現状、syncコマンドは操作履歴としてコマンド並びに対象となったファイルのハッシュ値をPubSub経由で送信する。受信側は、自身の操作にそれらの操作を差し込みながら順番に処理を行う。正確な実装ではタイムスタンプまで考慮した統合が必要であり、今後の対応案件である。

また、マージ処理は現状未実装であり、これも今後の対応案件である。

4. 評価

4.1 差分方式による更新時間の比較

まず、差分方式による更新時間の差を比較する。シナリオとして、1MBの値を繰り返し登録した際のIPFS上への登録時間を計測した(単位は秒)。ファイルベース差分方式では、値の蓄積に伴いファイル容量が増加するため当然ながら登録処理が遅くなる。オペレーションベースとディレクトリベースでは変更が局所化しているため、データストア全体の値の蓄積に処理時間が依存しないことがわかる。

size(MB) file-based ope-based dir-based
1 0.017593 0.021435 0.028095
2 0.040661 0.023311 0.031242
3 0.048258 0.026174 0.030879
4 0.073272 0.023378 0.026437
5 0.101438 0.022118 0.040008
6 0.073841 0.028761 0.032161
7 0.093803 0.025831 0.038100
8 0.092051 0.023874 0.026611
9 0.110011 0.026290 0.026626
10 0.116614 0.025109 0.031673

なお、ディレクトリベースでは、値の更新時にルートディレクトリの更新処理が発生するため、その追加処理分だけ、オーバーヘッドが発生していることから、ファイルベース差分と比較して時間がかかっていると考えられる。

4.2 差分方式による初期起動時間の比較

次に、差分方式による初期起動時間の差を比較する。シナリオとして、1MBの値が繰り返し登録されている状態のデータストアに対して初期起動の時間を計測した(単位は秒)。ファイルベースとオペレーションベースでは現在の情報を一旦読み込む必要があるため、蓄積されたデータに初期起動時間が比例する。ただし、オペレーションベース差分方式では、各操作履歴の取得は並行できるので、実装の工夫により短縮することは可能である。

size(MB) file-based ope-based dir-based
1 0.003264 0.002369 0
2 0.004155 0.005634 0
3 0.006680 0.007669 0
4 0.007542 0.011732 0
5 0.008023 0.012052 0
6 0.019605 0.015466 0
7 0.072510 0.019542 0
8 0.013462 0.018007 0
9 0.011672 0.027935 0
1 0.021468 0.026011 0

なお、ディレクトリベース差分方式では、最新のデータストアがIPFS上に存在するため、初期起動時の読み込みは不要である。

4.3 差分方式によるマージ時間の比較

現時点で未実装。ディレクトリベースでは競合するデータベースごとに最新の値を持っているので、操作ログを全て比較するオペレーションベースに対して優位であると想定する。

5. まとめ

非中央集権的な直接の価値交換プラットフォームの進出により、分散アプリケーションの実装が増えるに伴い課題となるプライベートデータ共有について、従来手法を比較し、最も適していると考えられるP2P分散ファイルシステムを用いたデータストアが抱える課題をディレクトリベース差分方式により解決する手法を提案した。 ディレクトリベースのデータ構造は単純なKey-Valueだけでなくサブディレクトリを設けることで利用可能なデータ構造の拡張が見込めるため今後の実装を進めていきたい。 また、現在の実装ではデータ共有をIPNS更新とPubSubによるリアルタイム同期で行なっているが、それぞれ、保存処理に時間がかかること、対応する端末が常にネットワークに存在する必要があるという課題がある。今後、最新のアドレス履歴をバッファリングされて時間差で参照できるような仕組みにより、より快適に利用できる仕組みを検討していきたい。

参考文献

  • Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Avinash Lakshman, Alex Pilchin, Swaminathan Sivasubramanian, Peter Vosshall and Werner Vogels, Dynamo: Amazon’s Highly Available Key-value Store, In Proceedings of twenty-first ACM SIGOPS symposium on Operating systems principles, ACM Press New York, NY, USA, pp. 205–220, 2007
  • Julian Browne, Brewer’s CAP Theorem - The kool aid Amazon and Ebay have been drinking, 2009
  • Mihai Letia and Nuno M. Preguiça and Marc Shapiro, CRDTs: Consistency without concurrency control, CoRR, 2009

発表を終えて

時間調整をミスって持ち時間のうちほとんどを発表に当ててしまい、議論を存分にできなかったのが心残り。実際に発表の練度が低かったので、前提の共有もうまく行かず失敗したなあとしばらく落ち込んでしまった。次回はきちんと仕上げてきます。

『やさしく学ぶ機械学習を理解するための数学のきほん』をいただきました

著者の@tkengoより『やさしく学ぶ機械学習を理解するための数学のきほん』をいただきました。ありがとうございます。

本書は、機械学習の基本を会話形式で学びながら、都度必要となる数学の知識を得ていく構成となっています。丁寧に噛み砕いて説明されており、機械学習に興味があるけれども数式に苦手意識がある人や、ニューラルネットワークのライブラリを使いこなすために、その技術背景を基礎の基礎から学び始めたい人などにオススメではないかと思います。

いわゆる文系の人が数学の補助輪を外すために読む本

僕はこの本を機械学習の勉強に特化したものだとは思っていなくて、公式を覚えただけだった高校の数学を、目的のために使いこなす数学という道具であると認識しなおすための本だと思っています。

僕はちょうど1年半ほど前に機械学習を学ぶために高校の参考書を使って数学を勉強しなおしました。ところがいざ論文どころか機械学習系の技術書を読んでも数式がやっぱりわからない。そんなときに元同僚である著者の@tkengoに数式の不明な箇所を相談していました。

彼は僕の初歩的な質問に嫌な顔ひとつせず(いや、ひとつぐらいしてたかもしれない)丁寧に数式をひとつひとつ展開し、変形し、具体的な値を入れながら数式の表さんとしていることを一緒に考えてくれました。数式は圧縮記述したプログラムであってprint debugしながら根気よく解きほぐしていけば理解できると思えるようになったのは彼のおかげです。

彼の教え方のエッセンスがつまった本書は、高校数学の参考書の次の段階として、機械学習という目的に向けて、数学を使っていく力がつく本だと思います。そしてその力は機械学習だけでなくこれから数学を必要とする技術習得に必ず役に立つと思います。

あわせて読みたい本

本書は基本的な機械学習として回帰や分類、評価の方法を解説しており、付録にも微分、偏微分、合成関数などの解説もありますが、本書で数学の必要性、そしておもしろさに目覚めて基本からやり直したいと考えている人には、マセマ出版社の初めから始める数学シリーズ(通称はじはじ)の数学Ⅰ, 数学A, 数学Ⅱ, 数学Bぐらいをやると適度に練習問題もあって良い復習になると思います。時間がなければⅠ-1章 数と式、同3章 2次関数、A-1章 場合の数と確率、Ⅱ-1章 方程式・式と証明、同3章の三角関数、同4章 指数関数・対数関数、同5章 微分法と積分法、Bの1-4章(ベクトル、数列、確率分布)はやっておくとよいと思います。(注: 改訂2時点の章構成です)

深層学習の理解を進めたい場合は、ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装が良いと思います。本書とセットで読めば偏微分や合成関数の理解がより深まり、誤差逆伝播法の理解の助けとなるでしょう。

まとめ

本書にはレビュアーとして参加させてもらいました。レビューにあたっては数学苦手意識ある側の視点を心がけて、説明を端折りすぎていないかなどを細かく指摘させていただきました。是非、本書を手にとって数学の苦手意識を取り除いてみてください。

Archives