Y社のぶっちゃけ話と研究者・エンジニアのクロスロード

今月号は濃いという話を聞いたので、

WEB+DB PRESS Vol.53

を読む。確かに濃い。(一応断っておくと自分は Y 社のオークションの人たちとつながりはない)

特に面白いのは「特集2 Yahoo! オークション構築・運用ノウハウ大公開」の

• 第1章 Yahoo! オークションの10年とシステム構成の変遷
• 第2章 Yahoo! オークションの設計思想
• 第3章 日本独自のシステムで目指したこと

の3点。Yahoo! Japan はどうも Yahoo! Inc. の受け売り(ローカライズ程度)だと思われがちだが、全然そんなことなくて、かなり日本独自のことをやっている。なんだかんだ言っても日本の検索エンジンとしてシェア1位は伊達じゃない(Google のほうがすごいと思いたがる人は多いが、まだ現状はヤフーのほうがシェア高いってことは認めないと……)のだが、その裏側はいろいろとあることがうかがい知れる。たとえば第3章。

　オークションの summary が mmap で共有メモリに載せられていることはすでにお話しましたが、当時のマシン性能で問題なく mmap できるサイズは 1.4G バイト程度、summary 1つのサイズが約320バイトでしたので、この状況では、440万件程度しかオークションを保持できない状態でした。さらに、サーバは機能の役割ごとに分割されているにもかかわらず、summary はすべてのサーバで同じデータを保持していました。
　急激に増え続けるオークション数は、システムの限界値に肉薄しており、近い将来にサービスが破綻することは誰の目から見ても明らかでした。

技術的にどこにどういう問題があって、どの程度の人がそれを認識していて、実際どうやって切り抜けたか、という話。あれだけの規模のインターネット企業でこれほど綱渡りな運用・開発をしているのか、とちょっと初めて読んだ人はびっくりするかもしれないが、どこもこんな感じなのかもしれない(と書くと怒られそうだが)。

　システム以外にも問題はありました。規模が増加するにつれ、ヤフオクのシステム開発者の数も増え、この当時は、数十人規模で1つのソースファイルに修正を加えていきました。しかしそのソースはほぼ手動でバージョン管理され、ソースに修正を加えるたびに、自ら diff を取り、マスターソースを手動更新していました。さらにソースの内部も、何を更新したのか記録するために、修正番号が直接記され、可読性の著しく低い、開発者泣かせのプログラムでした。このようなことは開発環境ではありがち(？)な話だとは思いますが、当然のように、システムを説明するようなドキュメントも何もありませんでした。新しくメンバーになった開発者は、来る日も来る日も10万行を超えるスパゲッティプログラムを解読する作業を行わなければなりませんでした。

自分ひとりでプログラムや論文のソースを管理するときですら、RCS や CVS や Subversion を使わないと無理(たとえば1年以上前にしたことは忘れている)なのだが、数十人でバージョン管理システム使わずに開発していたとは、すごい話だ……。一応名誉のために付け加えておくと、上記の話は2003年当時の状態であり、現在は改善されているとのことだ。どのように改善したのかは本文を参照してもらうとして(そういう意味では上記の内容を聞いて「これは自分の想像していた Y! とは違う」と思った人はちゃんと買って記事を読んだほうがいい)、よくこれ内部チェック通ったな、と。続きを読みたい人は売り切れる前に入手しないと！

閑話休題。本当はこの特集を読みたかったのではなく、特集3の O 野原くんによる「[速習]サーチエンジン」を読みたくて、この号がほしかったのであった。検索エンジンの話から圧縮接尾辞配列やランキング学習の話まで、手を抜かない(笑)　しかしこういう一般技術書に研究の話を書いて紹介するのは非常に大事だ。O 野原くん(@hillbig)は(自分と同じ D3 なのに)いつもこういう記事を書いていて、心底すごいと思う。1ページに2,3本論文へのリファレンスがあるところもナイス(笑)　自分も半分くらい知らない話だ。うーん、勉強になる。

最近今後どういう研究しようかと考えることが多いのだが、p103の図9、検索対象のデータの量と技術的困難性の関係を描いた図を見ながら、やっぱり数台での分散に力を入れた方がいいかなと思ったりする。あまり突っ込みすぎるとどんどん自然言語処理から離れていってしまうので気をつけないといけないが、全部メモリ上に載せて1台の計算機で実験するならみんなやっている話だろうし、実用上はメモリに載りきらないところから戦いが始まるわけで、そこを狙っていくのがいいのかなと思う。メモリが一気に安く大容量になってしまったので、これから研究する人は全部メモリに載せて計算するトレンドになるだろうが(それは正しいとも思うが)、そのうちまたメモリも頭打ちになるはずなので、ここは全力でみんなと反対側に走っておくのがいいのかな、と……(かといって超大規模側に走ることができないのが研究者としては悲しいところ)

というようなことを、今月の人工知能学会誌の定兼さんによる "Succincter" という論文(2008年)の紹介を見て思った。これは(O 野原くんも専門である)データ圧縮で最近ホットな「簡潔データ構造」についての論文で、ここ数年この分野は理論がとても発展して、これから実用化されていくのではないか、という話がいろいろ書いてあって、参考になった。(あと田中穂積先生の追悼文もたくさんの方が書かれているので、自然言語処理分野専門の人はこの号は読むといいと思う)

メモリといえば

WEB+DB PRESS Vol.52

も @taroleo さんが特集3で「〜SSD投入で何が変わるのか？〜データベースシステム基本解剖」と題して SSD を使ったベンチマークといろいろ理論的な話題も紹介してらして、やっぱり研究者として一般のエンジニアの人たちが読む本に書くのは大事だなぁとまた思うのであった。