はい、というわけで自分のトークです：
昨年12月頃から関わってるlivedoorBlogのコードを触っていた時の憤りをスライドにぶつけてみました。
追記：スライドに「ログにマーカーをつける」というのは、（コード読んでないけど）多分こちらのエントリにあるLog::Minimal::Indentとだいたい同じ感じのヤツです
ところでWeb上で見かける感想の中でこんなのがありました：
実はビジネス的にも意味はあるんだなー。
なかなか書くことができなかったんだけど、その内容というのがこちらと→ ブログのお引っ越し機能を大幅に強化しました！ （この中の「記事URLの引き継ぎを可能に」というのがポイント）、あともうひとつ、こちら→ブログ内のURLを自由に設定できるようになりました です
エンジニアの方でしたらちょっと考えるとこれがどういう事なのかわかるかと思います。記事URLが自由になるってことは・・・もうパターン固定のディスパッチングができないのですね。元々のディスパッチング機構はApacheモジュールとして書かれていて、mod_perlの実装はこのApacheモジュールとべったりだった。これをPSGIにしたらApache側と分離したおかげできれいに実装できた、と。
(まぁ本当の事言うとPSGI化してたら「これならできるじゃん！」ということがわかってやったのだけど。)
ということでPSGIに変えたいためだけに変えたってわけではなくて、PSGIにすることによって格段に自由度が増す事がわかっていたのでそれをベースに新機能がリリースできた、というところです。
実はこの機能のリリースがもう少し早かったらこれについても話せたのだけど、 ギリギリのところで含められなかったので、mod_perl → PSGIまでで話が終わった（時間もなかった）
昨年12月頃から関わってるlivedoorBlogのコードを触っていた時の憤りをスライドにぶつけてみました。
追記：スライドに「ログにマーカーをつける」というのは、（コード読んでないけど）多分こちらのエントリにあるLog::Minimal::Indentとだいたい同じ感じのヤツです
ところでWeb上で見かける感想の中でこんなのがありました：
今年個人的に一番衝撃的だったのはやっぱ、livedoor blogのPlack化です。技術的な側面もさることながら、ああいう近視眼的には何のメリットもないし、逆にデメリットの方が大きそうな案件にリソースを割くジャッジができる会社としての姿勢が本当に凄いなと。
実はビジネス的にも意味はあるんだなー。
なかなか書くことができなかったんだけど、その内容というのがこちらと→ ブログのお引っ越し機能を大幅に強化しました！ （この中の「記事URLの引き継ぎを可能に」というのがポイント）、あともうひとつ、こちら→ブログ内のURLを自由に設定できるようになりました です
エンジニアの方でしたらちょっと考えるとこれがどういう事なのかわかるかと思います。記事URLが自由になるってことは・・・もうパターン固定のディスパッチングができないのですね。元々のディスパッチング機構はApacheモジュールとして書かれていて、mod_perlの実装はこのApacheモジュールとべったりだった。これをPSGIにしたらApache側と分離したおかげできれいに実装できた、と。
(まぁ本当の事言うとPSGI化してたら「これならできるじゃん！」ということがわかってやったのだけど。)
ということでPSGIに変えたいためだけに変えたってわけではなくて、PSGIにすることによって格段に自由度が増す事がわかっていたのでそれをベースに新機能がリリースできた、というところです。
実はこの機能のリリースがもう少し早かったらこれについても話せたのだけど、 ギリギリのところで含められなかったので、mod_perl → PSGIまでで話が終わった（時間もなかった）
ついでに今回のレガシーコードと戦ったまとめ・感想：
PSGI化について
PSGI化については以前ブログのエントリで書いたこともあったけど、とにかくリファクタリングに次ぐリファクタリングをしてmod_perlべったり部分を直してデプロイした。実質作業は1ヶ月半くらい、1500コミット前後。livedoorBlogの仕組みが全然わかってないところから始めたからスライドにもあるとおり自分が触る部分にものすごい量のログを突っ込んでそもそもこのコードは何をしているのか把握するのから始めたりしたので大変だった。
まぁともあれ、それは3月くらいにデプロイした。 大変満足している。
URL自由化について
URL自由化は6月くらいから1ヶ月くらいで配信側の大枠を作った。実は8月くらいにはlivedoorBlogの全てのURLはこのシステムから配信されてました。その後CMS側とかを作ってもらって今回の公開に至った次第。
おおざっぱな仕組みはそれまでApache側で処理していたURL→ハンドラのマッピングをPSGI側に移した。以前は「/archives/123456.html」というURLがあればそれが「Article」ハンドラのID 123456を表示、みたいなマッピングをパターンに応じてApache側のクソ長いRewriteRuleで解決してたのだけど、それをPSGI側で処理するようにした。しかも同じようにパターンから解決するのではなく、全てのリクエストに対して毎回マッピングを解決している。もちろんキャッシュだ云々はやって、本当にリクエストごとに毎回マッピングを全て解決してるわけではないが、理論的にはそういうことをしている。
このデータを入れているところというのが豪勢な事にioDrive 。豪勢なハードウェアなので豪勢に数億個のURL→ハンドラ、IDを入れて、豪勢にINSERT/SELECTを発行しまくってる。URL自由化が本番化されてもioDriveのロードアベレージはまだ1どころか0.5にも達しません！豪勢ですね！
ちなみに実はPSGI化した後に作ったからミドルウェア追加して微調整するだけで全部済んだからすげぇ楽だった。もちろんそれだけじゃなくて実は色々小さい変更が入っていて、それらと現システムとの整合性を取るために他にも色んなPSGIミドルウェアを書いてそれらの実装をしています。
次の10年を戦うために
10年を戦ってきたシステムは色々な煤やゴミがたまってオーバーホールを必要としていました。YAPC::Asia Tokyo 2013での発表はその掃除の最初のステップである「mod_perlからPSGI」という部分を説明しました。
PSGIにしたら単純にシステムがキレイになったというだけでなく、コードの導線がなめらかになり、動作を変えたいと思った時に変更を入れる部分がはっきりと見えるようになりました。そこでこれまでは不可能だった変更への道筋がくっきりと映し出されてきたわけです。
今回のYAPCでの発表はあくまで最初のレガシーコードとの戦いにフォーカスした話でした。でも実はこれまでの作業は今回のこのURL自由化などを含めこれまで10年戦ってきたシステムが次の10年を戦えるようにするための布石だったわけです。
レガシーコードと戦うってのはそういうことなんだ。ただ単にエンジニアが気分良くなるためじゃない。
・・・って一通り戦い終わってから思いました。
PSGI化について
PSGI化については以前ブログのエントリで書いたこともあったけど、とにかくリファクタリングに次ぐリファクタリングをしてmod_perlべったり部分を直してデプロイした。実質作業は1ヶ月半くらい、1500コミット前後。livedoorBlogの仕組みが全然わかってないところから始めたからスライドにもあるとおり自分が触る部分にものすごい量のログを突っ込んでそもそもこのコードは何をしているのか把握するのから始めたりしたので大変だった。
まぁともあれ、それは3月くらいにデプロイした。 大変満足している。
URL自由化について
URL自由化は6月くらいから1ヶ月くらいで配信側の大枠を作った。実は8月くらいにはlivedoorBlogの全てのURLはこのシステムから配信されてました。その後CMS側とかを作ってもらって今回の公開に至った次第。
おおざっぱな仕組みはそれまでApache側で処理していたURL→ハンドラのマッピングをPSGI側に移した。以前は「/archives/123456.html」というURLがあればそれが「Article」ハンドラのID 123456を表示、みたいなマッピングをパターンに応じてApache側のクソ長いRewriteRuleで解決してたのだけど、それをPSGI側で処理するようにした。しかも同じようにパターンから解決するのではなく、全てのリクエストに対して毎回マッピングを解決している。もちろんキャッシュだ云々はやって、本当にリクエストごとに毎回マッピングを全て解決してるわけではないが、理論的にはそういうことをしている。
このデータを入れているところというのが豪勢な事にioDrive 。豪勢なハードウェアなので豪勢に数億個のURL→ハンドラ、IDを入れて、豪勢にINSERT/SELECTを発行しまくってる。URL自由化が本番化されてもioDriveのロードアベレージはまだ1どころか0.5にも達しません！豪勢ですね！
ちなみに実はPSGI化した後に作ったからミドルウェア追加して微調整するだけで全部済んだからすげぇ楽だった。もちろんそれだけじゃなくて実は色々小さい変更が入っていて、それらと現システムとの整合性を取るために他にも色んなPSGIミドルウェアを書いてそれらの実装をしています。
次の10年を戦うために
10年を戦ってきたシステムは色々な煤やゴミがたまってオーバーホールを必要としていました。YAPC::Asia Tokyo 2013での発表はその掃除の最初のステップである「mod_perlからPSGI」という部分を説明しました。
PSGIにしたら単純にシステムがキレイになったというだけでなく、コードの導線がなめらかになり、動作を変えたいと思った時に変更を入れる部分がはっきりと見えるようになりました。そこでこれまでは不可能だった変更への道筋がくっきりと映し出されてきたわけです。
今回のYAPCでの発表はあくまで最初のレガシーコードとの戦いにフォーカスした話でした。でも実はこれまでの作業は今回のこのURL自由化などを含めこれまで10年戦ってきたシステムが次の10年を戦えるようにするための布石だったわけです。
レガシーコードと戦うってのはそういうことなんだ。ただ単にエンジニアが気分良くなるためじゃない。
・・・って一通り戦い終わってから思いました。
