hiroohiのメモ

はてななのでITやスタートアップ周りの話（ほとんどが自分への備忘録だけど）を書いています。

Ruby on Railsで書き直したYellowPages.com

RailsConf2008 LEAN Web2.0 Web

http://mtl.recruit.co.jp/blog/2008/06/railsconf2008ruby_on_railsyell.htmlからの転載です。

RailsConf2008で興味深かったセッションの一つが、 「Surviving the Big Rewrite: Moving YELLOWPAGES.COM to Rails」です。

大規模な"legacy"WEBサイトをRailsで書き直して運用しているということで、フロアに入りきれないほどの人が集まりました。

YELLOWPAGES.COMの概要

  • 月間２３００万ユニーク訪問者。
  • １日２００万の検索。
  • 約4800万リクエスト／日、1500リクエスト／秒

これがRailsで動いている。

書き直しの背景

  • アプリケーションサーバを変えたい
    スケーリングの際のセッション管理の問題など　
  • サイトデザインを変えたい
    2003年から本質的にかわってなく、ウィンドウがいっぱい開く等プアなユーザー体験しか提供できてない。
  • プログラムがもう収集つかない
    • いくつかの状態保持機能のバグ
    • SEO的にプア
    • テストコードがない
    • ソースコードのコピー＆修正の繰り返しで肥大化
    • リクエストやフォーム、DBのハンドリングが時代遅れ

などで新機能の追加が困難

約１年間かけてサイト検討、アーキテクチャ選定をしていき、実際の開発は４ヶ月間。

どんなことをした？

書き直す際のルールを決めた
  • SEOに最適化されるURI
  • セッション管理をしない
  • アジャイル開発（必要最小限のコードを書いて、早い実装をする）
チームビルディング
  • 複数の機能を持つ２０人程度のチーム
    　広告、コミュニティ機能、コンテンツ、開発、PM、サーチ、SEO、ユーザー体験
  • チーム全体で同じフロアに席を持った。
  • 週に数回、チーム結束のためにみんなでランチ
  • マイルストーンごとにチームで祝う

この結果、重要な要件を逃さないようにできた。

また４人の非常にスキルのある開発者によるコア開発チームを作ることで、新技術を用いているときは特にコミュニケーションロスが減るし、管理負荷も減る。

どんな手順で書き換えた？

技術の選択

プロトタイプをRailsやEJBで書いてみた結果、WebレイヤーとサービスレイヤーにRailsを選択。（サーチ層はPython）その決め手は、

  • Javaフレームワークの中にすべてのURL構造を満たすものがなかった。
    WEBレイヤーをRailsとDjangoで比較して
    • 自動テストの実装
    • より多くのプラットフォームで動く
    • 必要に応じてCで書き直す方法が明らか
    • 開発者の経験

でRailsを選択。

  • また元々サービス層はEJBで考えていたけど、RubyやPythonとの本当の優位性を見いだせなかったため、Web層からサービス層まで統一した実装にした方が利点があるので、ここでもRailsを選んだ。
調査フェーズ（全員で）

ウィッシュリストをシェアして、既存サイトや機能についてたくさんディスカッション。

また経営層とのミーティングを重ねたが、いろんな意見が出ちゃうことでかえってディスカッションは低レベルになり、決定はできないは過剰な期待を抱く人はいるわでうまくまわすのが難しかった（＝我々もよく経験しますね）

開発フェーズ
  • プロジェクトリーダーが経営層との橋渡しをし、旧サイトの開発を凍結、また意見がまとまらない機能は現状維持というルールを制定して、新サイトの開発を推進。
  • 約１ヶ月ごとにβ版リリースというサイクルでまわした。その間、ベータサイト等で常に進捗を見えるかしたり、週ごとのマイルストンを設定したりしていった。
  • 営業チームとは早い段階でコミュニケーションをしてベータサイトを触ってもらい、意見を吸い上げ。
  • こうすることで経営層もCTOもハッピーに事が進んだ。

実際のサイト構造

YELLOWPAGES_COM

  • すべてのレベルでstatelessなhttpコミュニケーション
  • サービスレイヤーはRESTで返す。レスポンスはJSON
  • サービスレイヤーでmemcached使用
  • 台数はテストにより決定

パフォーマンスのノウハウ

  • ページパフォーマンスが遅いのはフレームワークの遅さよりもダウンロード時間が原因のことが多い。
  • Yahoo!パフォーマンスガイドを参考にしてる。
  • 画像保管はAkamai edge cacheに移動した。
  • Apacheが遅いのでNginxに置き換えた。

まとめ

プロジェクトは大変だったけど大成功だった。成功の要因を挙げるとすると、

  • 少人数でハイレベルな開発チーム。
  • アプリケーションとプラットフォーム互換性を注意して技術を選択した。
  • 多様な観点を持つメンバーとの近いコミュニケーション。
  • 「決められないものは変更しない」ルール。
  • 頻繁なベータリリースは進捗の見える化に貢献。
  • CTOがRailsに賭けただけでなくそのアイデアに興奮していたこと。

雑感

大企業でもアジャイル開発、XPで言われていることを取り入れることで大きな成果が出せること、また技術に関しては保守的にならず挑戦することでいい結果につながるという好例で、説得力のある話を聞けて、勇気づけられました。はい。