今回，弾さんが訪問したのは，（⁠株）ミクシィ。検索エンジン開発からアプリケーション運用まで，ミクシィを作り上げ，支えている4人のエンジニアの方々に逢ってきました。

自己紹介

弾：では，さっそく自己紹介から。

津久井（以下，津）⁠：mixiアプリケーション開発グループマネージャーの津久井です。仕事内容としては，マネジメントが主です。

弾：ちらっと紹介しておくと，かつて僕がマネージャーで津久井さんにコードを書いてもらったことがあります。大昔の話です（笑）（⁠注1）⁠。

平林（以下，平）⁠：平林です。研究開発グループのマネージャーをしていまして，研究開発グループ自体は僕を含めて5人です。仕事としては，マネジメントは2～3割くらいに抑えて，あとはだいたいコードを書いています。

長野（以下，長）⁠：システム運用グループアプリケーション運用チームの長野です。システム運用グループは，mixiと，Find Job!のインフラをやっているチームと…。

弾：じゃあ，データセンター担当みたいな。

長：アプリケーション運用チームは，データセンターに行かない運用チームなので，監視だとか，障害対応，セキュリティ系の実務ですね。アプリケーションのデプロイメントとサーバの設定もやっています。

弾：要は，ロジカルなホストのデプロイメント…。だいたいどんな感じでやっていますか？ すでにOSだけ入ったのが，ずらっと並んでてっていうようなイメージ？

長：インフラ（部隊）にやってもらうのはOSのインストールまでなので，IPリーチャブルになってる状態までで，そこから先はこっちでやります。

大窪（以下，大）⁠：私は開発部のタンポポ開発グループという…。

弾：タンポポ開発グループ…？ まさか刺身タンポポ開発グループということですか（笑）⁠。

大：はい。タンポポ開発グループという名前のグループにいるんですが，チーム名の由来は刺身にタンポポをのせるような仕事をなくすための…（注2）⁠。

弾：あ，名前の由来は刺身タンポポなんだ（笑）⁠。マジ？（笑）

大：そういう作業をなくすためのアプリケーションの裏方的な，たとえばライブラリ的な側面や，案件と直接絡まないけど，影響範囲がでかいというようなものの改修を行うグループに属しています。

弾：ミクシィには今，エンジニアって何人くらいいらっしゃるんですか？

津：mixiの開発をやっているメンバーだけで60前後です。運用も含めると80，社内システムとかデザイナも含めると100人くらいです。

注1）

（⁠株⁠）オン・ザ・エッヂ在籍時の2000年当時。

注2）

ハムスター速報2ろぐ「刺身の上にタンポポのせる仕事の採用試験に受かったお！！！！！」

お気に入りのシステム・ソフトウェア

弾：これまでやってきたシステムで自分の一番お気に入りは？

津：僕はマネジメントが10割で，コードは一切書いていないので，手がけたシステムっていうのがないんです。しいて言えば，最近話題になっているmixiアプリは僕のチームが手がけているもので，間接的に僕も関わっているところなので，mixiアプリが今，一番気に入っています。

弾：平林さんは？

平：検索システム系はだいたい僕が作っているのですが，その中で気に入ったというか，手こずったのが，ユーザ検索機能です。僕が作ったんじゃないんですけど，mixiがまだ小さい時代から仕様があって，名前とかニックネームとかで検索できるだけでなく，血液型で絞り込んだりとか，出身地で絞り込んだりとか，それを県単位，市単位とかってやっていました。普通の検索システムではないような，いわゆるRDB向けの検索項目がいっぱい並んでるのを，2,000万エントリに近づきつつある規模で動かさなければならないという課題がありました。Hyper Estraierというのを昔作っていて，それをそのまま動かしてて，だいたいユーザ数が1,000万以下くらいのときは問題なく動いていました。ですが，そろそろ東京都全員を抽出するみたいなクエリを投げられるようになると固まってしまうようになってきて。それで急遽，Tokyo Dystopiaっていう検索エンジンを作りました。それはまさにユーザ検索をなんとか持ちこたえさせるためだけに作っていて，全部オンメモリで処理をするとか，インデックスをすごい圧縮して持たせるとかをいちいち作ったので，それのおかげで今はほとんどストレスなく使えるようになっています。その割にはすごく台数が少なくて済んでいて，かつ速くなるだけじゃなくて，検索の適合性も，スコアリングを改善することによってそこそこいい検索結果を出せるようになっているんです。それは単に検索するだけじゃなくて，ユーザのグラフ分析を行っていて，自分からネットワーク的に近いユーザを出すことができるんです。それもすごい計算量がかかるんですけれども，それもTokyo Cabinetのオンメモリモードっていうのを使ってなんとか動くようにしていて。それのおかげで相当複雑な検索なんだけど，ほとんどそれを感じさせない。そのへんはかなり気に入っています。

長：一番は，memcachedをどうやって動かすか（注3）っていうのと，Q4M（注4）という，奥一穂さんが作られたメッセージキューのしくみを導入したり，あとは画像配信全般ですね。画像が一番苦労しているかなと思います。

弾：画像のどの部分ですか？ あんまりメモリに載らないとか？

長：画像のファイルが10億くらいあります。あとプロフィール画像のアイコンを1ページ50個表示したりというのが普通に行われるので，それをどうやって配信するか。プロフィール画像としては数千万なんですけど，アクセス数がものすごいたいへんなことになります。それをどうやってさばくかというので，Squid（注5）を多階層にしたりしています。

弾：大窪さんは？

大：少し昔なんですけど，まだエンジニアの人数が少なくいろいろ試行錯誤していた時期に，昔ライブドアにあこがれていたこともあって，宮川さんのSledge（注6）とかを参考にして社内の簡単なフレームワークを作りました。今も使われているんですがそれを実験する意味で動画のサービスを作ったりして，そのあたりが一番お気に入りです。

注3）

本誌Vol.47 特集2「mixi，ニコニコ動画，livedoor［実例から学ぶ］memcachedベストプラクティス」に執筆のほか，弊社gihyo.jpでも「memcachedを知り尽くす」をミクシィ前坂徹さんと共著。

注4）

http://labs.cybozu.co.jp/blog/kazuho/archives/2008/01/q4m.php，奥さんはサイボウズ-ラボ勤務。

注5）

キャッシュ機能付きプロキシサーバ。

注6）

PerlのWebアプリケーションフレームワーク。現在はシックス・アパート（⁠株⁠）執行役員の宮川達彦さんが中心になって開発したもので，名付け親は津久井さん。