Linuxカーネル解読室輪読（第６章）
【遅】新年のご挨拶（※OctoTigerのイラストは某M下女史寄贈）
OctoTiger（虎蛸）：動物界軟体動物門哺乳綱八腕形上目ネコ科ヒョウ属に分類される食肉類。OctoCatと姉妹関係にある。イラストは某M下女史寄贈の力作。
新年明けましておめでとうございます（遅）。
私事ですが、昨年11月末でランゲート株式会社CTOの職を辞すことになりました。
退職後は、かねてからの目標である、高度な英文自動校正技術の実用化を成功させるべく、個人プロジェクト「Lingo」を立ち上げ、一人研究室状態で開発を進めていきたいと思っています。
このLingoプロジェクト、運良く2009年の未踏下期で拾っていただけたこともあり、これから本年８月までの半年余り、完全に専念するつもりでいます。プロジェクトの詳細については、追々このblogでもご紹介させていただきますし、DEMOサイトもできるかぎり早期に準備したいと思っています。
以上、簡単な近況報告ですが、たまにこのblogをチェックしてくださる方に向け、謹んで新春のご挨拶とさせていただきます。
2010年1月31日、関西Vim勉強会(#5)会場 京都西陣町家スタジオにて
松本 一輝
KVSをWebアプリのメインストレージにしたら、集計バッチをMapReduceでやるはめになったでござるの巻
という題で、RubyKansai勉強会#39で発表させていただきました。
内容はMapReduceとKVSの関係、および自作のMapReduce処理系であるTinyMapReduceの紹介について。実装にはDRubyを使っています。といってもTinyMapReduceはコードサイズ200行以下で、対障害性もなくサンプルの域を出ないものですが。。
TinyMapReduce標準添付のSampleは、１〜100万までの自然数の中に2の倍数と3の倍数がそれぞれいくつ含まれるかカウントするタスクです（結果保存にSimpleResourceを使っており、別途導入が必要）。Workerの数を増やしていくことで、タスクの実行時間がシームレスに短縮することがわかると思います。
というわけで、使用したスライドを置いておきます。
TinyMapReduce on ruby
View more presentations from kazuki83.
Webアプリをとりまく最近のKVS事情、雑感
RDBの復権はしばらくないと思う
最近目にしたのは、「これからRDBが十分速くなっていくので、memcachedに代わってRDBがまた使われるようになる」という意見。これはしばらくの間は無いんじゃないかと思う。全データがオンメモリだったとしても、KVSはRDBより一桁以上速い（Memcachedで100,000req/sec出せるマシンで、MySQLのpkeyによる単純なSELECTをした場合、10,000req/sec出るかどうか）。SQLパーサやらなんやらを捨てない限りこの速さには対抗できない。RDBには、１コネクション１スレッドというモデルが持つ、接続数がスケールしないという制約もある。
また、memcacheプロトコルは、get_multiが使える。get_multiを効果的に活用した場合、RDBとの差はさらに広がると思う。
RDBで大丈夫なアプリも
Viewキャッシュが効果的なアプリ（blogタイプ）と、そうでないアプリ（SNSタイプ）で、RDBの遅さを許容できるかどうかが左右される。ちなみにLang-8は後者。以下後者のタイプを前提に話を進めます。
KVSなクラウドDBは？
GAEのBigtable, AmazonのSimpleDBあたりが利用できるけれども、レイテンシがかなり大きいとか。一クエリ10msとか普通にかかるらしく、これは許容しがたい。。当分はクラウド利用を諦めて、手元でサーバをセットアップして使うしかないのか。。
レンジクエリ？
KVS上でレンジクエリは利用できるのか？ いろいろアイデアがあるようだが、今すぐにプロダクトへ採用できる状況ではなさそう。クエリの制約も大きく、SQLを代替できるものではない。
レンジクエリが使えない場合、インデックス構造自体をKVS上の１レコードとして持つ必要がある。これで案外いける。各レコードへの参照を並べるだけのListなので、アプリ側で適切に分割した場合、レコードサイズが1MB（Memcachedの制約）を超えることはまずない（例：Lang-8のフレンドリストや、個人ごとの最新日記リスト）
1MB以上になりそうな場合は、レコード末尾に続きのインデックスへの参照を置き、数珠つなぎに引っ張り出す等、アプリ側で工夫する。（泥臭い。。）
排他ロック
KVSをメインストレージに採用する場合、書き込みの競合によるデータ欠損を防ぐため、レコード単位でのmutexが必要。拙作KVS支援ライブラリ、SimpleResourceでは、ライブラリ側の機能として提供した。
スキーマレス
スキーマレスが普通になっていく。スキーマレスのメリットは非常に大きい。SimpleResourceや、SimpleResource上で再構築したLang-8でも、すべてのレコードはスキーマレスにした。
RDBが部分的に補助
どうしてもKVSでは処理できない検索クエリだけRDBで処理するというスタイル。RDB上のデータはただのインデックスという位置づけであり、マスタデータではない。Lang-8の場合は任意のパラメータによる日記・プロフィール検索等でこのスタイルを使っている
トランザクション？
諦める。関連する複数のレコードのうち一部だけ書き換えられても破綻しないように、アプリ側で工夫する。
Lang-8でSimpleResourceを全面的に採用した件
KOFに参加、関西Ruby会議LTで話をさせてもらいました。
使用スライド張っておきます。
SimpleResourceのリポジトリはこちら(↓)
http://github.com/KazkiMatz/SimpleResource
Lang-8 got updated on SimpleResource
View more presentations from kazuki83.
LiveCoding#7に参加しました
11月2日に開催されたLiveCoding#7に参加させてもらい、トップバッターで登板、撃沈しました:D
作りたかったものは、拙作SimpleResourceを利用してハッシュKVS(TokyoTyrant)にデータを蓄積するTwitterクローンのモデル部分。RDBではなくKVSでもそれほど手間無くタイムライン生成ができることを示したいなと、思ったわけですが。自分で作ったライブラリの詳細を忘れ、設定に戸惑った結果、時間切れであえなく撃沈。
その後、nankiさんにライフゲーム（Game of Life）について色々教えてもらい、こんな世界があったのかと驚く。
しかし僕は撃沈しましたが、他の第一級コーダたちのコーディングは見てるだけでかなり勉強になり、とても楽しかったです。LiveCodingかなりおすすめです :)
Twitterは、自社のサーバソフトを売ってマネタイズすべし、という記事
Twitterがマネタイズするには、自社のマイクロブログサーバを、世界中の企業に販売すればよい - ちょうどMicrosoftがメールサーバのMS Exchange Serverを企業に売りつけているように - という記事がTechCrunchに出ていた。
Twitter Should Decentralize (And Make Money) Via Twitter Server
※追記 上記記事の和訳版が既に公開されていた。→ Twitterはスケールしない―MS Exchangeのように分散化してサーバを売るべきだ
記事ではまず、Twitterは現状「サービスの耐障害性」と「マネタイズ」の二つに問題を抱えており、これを解決するためには、そのアーキテクチャを中央集権型から分散型に移行すべし、と指摘。
We believe decentralizing Twitter solves two problems – it will help the service scale infinitely. And it is potentially a very lucrative source of revenue.
Twitterはスケールがやばいやばいと言われ続けて一年以上、以前と比べて格段に規模が大きくなった現時点でも特に問題なく動いている。が、そのアーキテクチャは中央集権型で、EメールやDNSのような分散型ではない。これでは攻撃に晒されたときに簡単にダウンしてしまう。もはや公の役割を担いつつあるTwitterは、その役割に答えるだけの耐障害性を併せ持つべきだ、ということなのだろう。
そして、分散型アーキテクチャを採用したTwitterは、なんとマネタイズでも活路を開けるという、以下の主張。
Twitter should look at how email, and commercial email servers such as Microsoft Exchange Server, developed. The business generates $2 billion or more in revenue for Microsoft, and powers the majority of corporate office functions (email, calendar, etc.). Businesses pay a few hundred dollars for Exchange, plust $50 or so per year per user. Plus, the businesses handle all the infrastructure costs (servers, bandwidth, etc.).
Twitter should sell Twitter Server just like Microsoft sells Exchange Server. They’d then run their own Twitter node on their own hardware.
[拙訳]
Twitterは、Eメール、そしてMS Exchange Serverのような商用Eメールサーバソフトが、どのように開発されているのかを参考にすべきだ。このビジネスはMicrosoftに20億ドル以上の収益をもたらしており、企業業務の中心であるEメールやカレンダーといったツールを提供している。企業はExchange Serverを導入するために数百ドルを支払い、さらに従業員一人に付き年50ドルを支払っている。また、サーバや回線帯域といったインフラコストも別途必要になる。
Twitterは、ちょうどMicrosoftがExchange Serverを売っているように、Twitterサーバを売るべきなのだ。顧客は自分たちのハードウェア上で自分のTwitterノードを稼動させることができるようになる。
「ああ、企業内Twitterのためのサーバソフトを販売すればいいって話ね。でもそれ、顧客にサーバを準備させるんじゃなくて、SaaSでやればいいじゃない。どうせブラウザ上で利用するアプリケーションなんだし。ていうかもう既にSaaSタイプのYammerがあるし」
と、思ってしまった人はミスリードしている。
これはそういう話ではなく、マイクロブログをPOP、PUSHするプロトコルを標準化して、分散型マイクロブログシステムを世界に広げればいい、という話だ。組織の数だけマイクロブログネットワークを作るのではなく、それぞれの組織の間でメッセージがやり取りされ、全体としてインターネット上にひとつのマイクロブログネットワークを作る、という話。Eメールがまさにそうであるように。
分散型アーキテクチャに移行することで、個々の組織がマイクロブログサーバを乱立させることができ、それらが協調して機能するようになる。そして耐障害性も上昇すれば、マイクロブログサーバソフト市場という新しい市場が生まれる。企業向けEメールサーバ市場と同じだ。
事実上マイクロブログのデファクトスタンダードとなったTwitterだけが取り得る一手。現状の独占の上にあぐらをかくのではなく、あえて門戸を開き、新しい市場を作り出すべし、ということだろう。これはおもしろい！
この道をとった場合、直接の競合としてGoogleWaveと全面衝突することになりそうだ。マイクロブログはたしかオープンソースプロジェクトもいくつかあったと思うので、一社独占を防ぐためにもプロトコルの企画は是非RFC化してほしいところですね。
