本を読む

読書やコンピュータなどに関するメモ

Shibuya.pm TT #12で話を聴いた

recruit_night.jpg

 11月30日に、Perlプログラマの集まるイベント「Shibuya.pm Technical Talk #12」に参加して、発表を聴いてきました。

 中心となったのは「NoSQL vs. NoKVS ライトニングディスカッション」。実際に高速(分散)KVSやRDBMSを開発したり使ったりしている豪華メンバーが壇上に並んで、発表や議論を繰り広げました。

 そのほかの発表も含めて、実開発者による濃い話が面白く語られていました。全体的に、アプリの実行速度にこだわった話が多かったのが印象的です。あと、予定の9時ぴったりに終わったのにもびっくり。

 1週間たっちゃいましたが、以下、自分の復習として、メモをまとめておきます。

Tatsumaki" I/O bound HTTP clients in web frameworks(miyagawa)

 Shibuya.pmといえばこの人、miyagawaさんのセッションです。まず、YAPCで旋風を巻き起こしたPlack/PSGIのその後について解説しました。

 PSGIは、リファレンス実装のPlackのほか、nginxやmod_psgiなどに対応。WAFもCatalyst、Mason、Maypole、CGI::Applicationなど多数に対応。Middleware(モジュールとかプラグインのようなもの)もAccesslogやNYTProfなどさまざまなものが登場しているそうです。

 で、PSGIで非同期なNon-blockingのサーバーがやりたかったので、psgi.streamingを10月に仕様追加したそうです。用途としては、遅延レスポンスや、ストリーミング(twitter streaming API的な意味で)など、マッシュアップとリクエストへのレスポンスとを重ねる例が紹介されました。

 いわく、WebサーバーはたいていCPUバウンドじゃなくてI/Oバウンドで、I/O待ちで待ってる間にマッシュアップとかリアルタイムWeb(Comet等)とかの処理ができる、とのことでした。

 ただし、それ対応のWeb Application Frameworkが(ほぼ)なかったそうです。そこで、最近作ったという「Tatsumaki」が紹介されました。PythonのTornado相当で、AnyEventのepollによるシングルスレッドのイベントドリブン型サーバーです。Shibuya.lispで紹介されていたCommon Lispのteepeedee2もこの仲間かな。いずれも、爆速Webサーバーという評判ですね。

 これをなんと、miyagawaさんは最初1日で作っちゃったそうです。なお、TatsumakiはXSモジュールには依存していないPure Perl実装だそうです。

 使い方は、ハンドラーのクラスを作ってURLにマッピングする方式。そのほか、ほかのWebサーバーにリクエストを投げるTatsumaki::HTTPClient(AnyEvent::HTTPのラッパー)や、AE::timerを使ったComet(Long-poll)、Pure perlのMQであるTatsumaki::MessageQueue、サーバープッシュのエミュレートであるMultipart XHRなどを紹介していました。ただし、AnyEventサーバーがLinuxで固まるバグがあるそうです。

 最後に、59行で書いたというチャットサーバーと、そこにtwitterとのマッシュアップを入れるというのを会場で実際に動かしてデモしていました。twitterは回線の関係でうまく動かなかったようですが。

 最後に、今後の予定として、XMPP/IRC botをWebアプリのように書けるようにするとか、Comet Interfaceとかの計画が語られました。

NoSQL vs. NoKVSライトニングディスカッション

 今回のメインセッションです。いずれも用途を定めてチューニングしていて、どの人も「用途を考えて選んでほしい」と言っていたのが印象的でした。

Tokyo (Cabinet|Tyrant)(mikio)

 すでに名の通った、高速なDBM系(つまり永続化された連想配列)ライブラリであるTokyo Cabinetと、そのRPCラッパーであるTokyo Tyrantを、平林(mikio)さんが紹介しました。1台で6万qps以上さばける(250億PV)そうで、「これで足りないというなら、それ以上のPVを稼いでから」といった自信の発言もありました。mixiでは、カウンタや、データマイニングや転置インデックスの作業領域として使っているそうです。

 壇上では、fsyncしていないからサーバーが落ちるとデータも壊れるんじゃないか、というツッコミもありました。それに対しては、機能はあるが推奨してない、Tokyo Cabinetが必要なケースなら速度優先だろう、という回答でした。

Lux IO (mogwaing)

 全文検索エンジン「Lux」用に用途を絞って、転置インデックスに特化して開発したDBM系ライブラリです。「ラックスアイオー」と読むそうです。特徴は、B+木と配列のみで、ハッシュがないことだそうです。C++で書かれていて、PerlバインディングのLux::IOをantipopさんが作って、はてブの個人検索で使っているという話もありました。

 転置インデックスに特化ということで、非常に長い値(value)を扱うので、disk I/Oが支配的な状況を想定しているそうです。つまり、索引分の構造の違いは無視できるので、B+木ということでした。ほか、索引部は全部オンメモリに置いている(mmap使用)とか、ほかのDBMはclustered indexがほとんどなところをunclustered indexをメインに使っている、とか。

 今後としては、ほかの用途も少し考えて、トランザクション対応とか、mmap以外の方式もオプション対応とかいうことも考えているそうです。ちなみに、壇上のmikioさんがそれを受けて、mmapを使ったKyoto Cabinetというのを作っていると話していました。

毎秒11万回更新できるのはREDISだけ(halt)

 PHPで活躍するhaltさんが、KVSを使う側視点でKVSのREDISを紹介しました。まずREDISの機能を紹介するスライドを飛ばしてw、なにより「PHPプログラマーでも扱える」という部分を強調していました。インストールもwgetしてmakeするだけで、それはTokyo Tyrantでもそうだけど名前が短いぶん有利、とw

 機能としては、KVSなのにデータ型があるとか、値を直接操作するコマンド(加算など)が豊富にあるとか、キーにワイルドカードを指定できるという話が紹介されました。

 発表タイトルにある速度面については、50クライアント同時で10万リクエスト/秒を処理できて速い、同時接続が増えてもパフォーマンスが落ちない、といったデータが紹介されました。ただし、壇上からは、シングルスレッドなのでマルチコアではスケールしないという指摘もあり、対応予定はあるようなので生温かく見守ってほしいとう回答でした。

kumofs(frsyuki)

 えとらぼのfrsyukiさんが、SPFのない分散KVSであるkumofsを紹介しました。いつでもノードを追加できて、追加したぶんだけスケールするのが特徴だそうです。えとらぼのFiciaで使われているという話でした。

 kumofsには、Manager(管理)、Server(データを保存)、Gateway(読み書き)の3種類のノードがある構成だそうです。アプリからはmemcachedプロトコルでアクセスするそうです。ベンチマークでは、memcachedなどに比べてputが速くて、これはGatewayでリクエストをまとめているせいではないかとのことでした。

 本体はC++で書かれてマルチスレッド対応、管理ツールはRubyで書かれているそうです。デモでは、管理ツールのkumotopコマンドを使って、ノードを落としたり追加したりして動的に再構成されるところを見せていました。

Hadoop/hBase(kzk)

 Hadoopで知られるPFIの太田(kzk)さんが、Hadoop BigTableクローンのHadoop/hBaseを紹介しました。Google BigTableはもともとクローラのデータを保持するもので、hBaseも大量行での低レイテンシが特徴とのことです。サーバーを足すしただけ性能が向上するスケーラビリティが特徴で、全部をなめるのも得意だそうです。

 構造は、単純なKVSではなく、Column Storeというのがあるそうです。1つのレコードにrowとcolumn familiesがあって、rowがプライマリキー相当、column familiesがスキーマなデータ相当の部分で、ただし行ごとにスキーマがかわってよい、ということでした。

 Hadoopの分散FSの上で実装されていて、分散ロックシステムZooKeeperを利用。データはリージョンサーバーに保持され、まずmemstoreに書いてバックエンドでfilestoreにマージする構成。Hadoop FSのレイヤーで冗長化しているそうです。

 なお、インストールキットとしてCloudera Distribution for Hadoop 2というのもあって、yumで簡単にインストールできるという話もありました。あと、Amazon EC2でも簡単に使えるそうです。

GoでKVSを書けるのか(moriyoshi)

 ちょっと毛色が変わって、発表されたばかりのGo言語を使ってmoriyoshiさんが分散KVSを作ってみた話でした。はてダで好評だった話をプレゼンにしてみたそうです。

 分散KVSの要素としては、ソケット(リッスン)、セッション維持、プロトコルのハンドル、Key-Valueを保持するバックエンドがあります。まずソケットは、netパッケージで一発だったそうです。また、セッション維持は、pollerを使ったイベント駆動なサーバは(今のところ)書けないので、Goroutineを使ったそうでえす。プロトコルのハンドリングはCと同じくビット演算で、KVバックエンドにはビルトインのmapを使ってアクター指向風に1個のGoroutineとして実装したとのことでした。

 できたところでパフォーマンスをmemcachedのmemslapで計測。遅いけど、意外に善戦しているという結果だそうです。ただし、壇上では、ローカルでやってるからでは(ローカルではコンテクストスイッチが支配的になる)というツッコミもなされていました。

 Go言語で分散KVSを書いてみた感想としては、netパッケージがそうとう適当で、Poll serverにfdを登録する方式では性能が出ないんじゃないか、という話でした。

NoKVSなRDBMS sharding作ってみた(kazuho)

 ここからRDBMS側の発表です。サイボウズラボのkazuhoさんは、まず、KVSではなくRDBMSにする基準として、ACIDの必要性、クエリの種類の多寡、運用手法(KKDでいけるか、情シスが運用するか)、お金などを上げました。

 また、MySQLの単体性能は悪くなくて特にSELECTは十分高速、ただしスケールアウトが問題、と語りました。

 そして、企業システム(グループウェア?)の要件がSNSと違う点として、書き込みが多い、ソーシャルグラフが密、トランザクショナル、画面数が多い、情シス部門が管理できるといった点を上げました。

 それらをふまえて、RDB Shardingによって、RDBMSを分散KVS的に分散させつつACIDな更新を行うソフトとして開発したInclineを紹介しました。サーバーで定義ファイル(DDL)にJSONで記述しておくと、書き込み時のトリガーで自動的に非正規化して適切なshardのみにレプリケーションするそうです。更新は多段で伝搬、表示用の実体化ビューは非同期更新、とのことです。

 また、Inclineと組み合わせる、高速・安全なShard分割ツールとして開発したPacificも紹介しました。

 今後は、アプリの「書きやすさ」を向上するために、SalesForceなどを参考にクエリを抽象化することなどを考えているそうです。

 この発表にはなぜかダントツに質問が集まりました。それによると、キューはMySQLのInnoDB、性能は2層コミットやるよりは速い、書く先はDDLで決まり読む先は自分の属するところ(JOINを使いたいので)、SPF対策はノードのペアを組んで冗長性、とのことでした。

Spider Storage Engine作ってみた(shiba)

 kazuhoさんに続いてRDBMS側から登場。MySQLのストレージエンジンによるRDBMS shardingの「Spider」を紹介しました。利用例としてはチームラボのサグールテレビがあり、インデックスを作るときに1DBあたりの負荷を下げたそうです。

 特徴は、アプリケーションからは透過的に普通のMySQLのテーブルとして見えるので、shardingしても変わらないこと。shardingのサーバー探しなどをSPIDERが肩代りしているそうです。いわく、「RDBをRDBのままshardingするため」とのこと。

 さらに、Vertical Partitioningされたテーブルを透過的に管理する機能も作っていて、組み合わせると、スキーマ変更やreshardingをオンラインで動的にできるという話でした。

Lightning Talks

ああ、柔軟な言語Perlよ(tokuhirom)

 「Perlの柔軟性は異常」ということで、Perlの文法ハックを紹介しました。まず、prototype宣言によるブロック渡しや定数畳みこみを紹介。続いてソースフィルタでPerl中にSQLをそのまま書くFilter::SQLを紹介しました。

 そのまま、構文木組み立てをフックするPL_checkハックを紹介したあと、Perl 5.11.2(開発版)から採用されたPL_Keyword_pluginを紹介しました。これは、キーワードに反応して、そこから先のパース処理をフックできるそうです。

Metaprogramming in Perl internalss(gfx)

 tokuhiromさんに続いて登場したgfxさんもPerlの文法ハックねた。こちらはperly.yに手を加えるという話でした。

 題材は、メソッドコールにブロックを渡せるようにするというねた。「Foo->bar(...) { ... }」のブロックを最後の引数として解釈するというものです。結論は、高度に発達したPerlはRubyと見分けがつかない、とw

Ajax application testing(Yappo)

 Perlの作法でJavaScriptのテストが書けるJSTAPdを作ったという話でした。HTMLタグを書いたりする必要もなく、XHRのテストもできるそうです。JavaScriptのテストは、ブラウザを起動したり、起動しているブラウザに実行させたりして動かしていました。結果出力は、Test::*っぽい形式になるようです。

CouchDBで作ろう!! めちゃうすっレイヤーアプリケーション(z.ohnami)

 CouchDB JPのz.ohnamiさんが、KVSの一種であるCouchDBを紹介しました。RESTなURIによるHTTPメソッドで操作して、レスポンスはJSON。「ドキュメント指向」ということで、テキストや画像、音楽、ソースコードなど「紙一枚にまとめて不自然ではないデータはCouchDB向き」だそうです。データとしてJavaScriptのコードを入れておいて、ブラウザでアクセスしたときにWebアプリとして動作させることもできるというのを、「必殺仕分け人Z」というデモで見せていました。

コメント

コメントの投稿

管理者にだけ表示を許可する

トラックバック

http://emasaka.blog65.fc2.com/tb.php/687-5e30c8fc

 | HOME | 

Categories

Recent Entries

Recent Comments

Recent Trackbacks

Appendix

emasaka

emasaka

フリーター。
連絡先はこのへん

Monthly


FC2Ad