Ethna@GREE 〜大規模サイト運用事例〜
EthnaをGREEに!
GREEは、2006年3月現在で30万人以上のユーザが利用するソーシャルネットワーキングサービスです。筆者が実際にサービスに関わり始めたのは2005年初頭で、当時から既に登録ユーザ数は10万人を超えていましたが、そこからわずか一年で3倍以上の成長を遂げています(*1)。
そしてGREEの提供するサービス自体も、開始当初のピュアSNSと呼べるサービスから、レビュー、日記、フォト、コミュニティ...と多様化しています。こういった拡張を短期間でクオリティを保ちながら行うには、やはりアプリケーション自体が統一されたフレームワークに沿って動作していることが重要だと筆者は考えています。その理由は、リリースサイクルの短さと技術進歩の速さ、そしてセキュリティです。
特にコンシューマ向けにサービスを提供するウェブアプリケーションは、極端にリリースサイクルが短く、機能追加が非常に短期間で行われていく傾向にあります。実際にGREEでも、ほぼ毎日何らかの機能追加、修正のリリースが行われています。さらに、ウェブアプリケーションのトレンドや技術はまさに日進月歩といった趣で進んでいて、周辺のサービスを見渡すと常に羨ましい機能や実装が転がっている、という状況です。開発者としては下手をするとそうした技術を理解するのが精一杯、という状況になりかねません。ここで、フレームワークがそういった機能をサポートしていき続けてくれれば、アプリケーション側は割と簡単にそういった新技術を取り込んでいけるかも、という野望が生まれるわけです。
一方で、ウェブアプリケーションはセキュリティホールの宝庫でもあります。もちろん、ウェブアプリケーション以外にセキュリティホールがない訳はありませんし、アプリケーション以外の部分(例えばOSなどのより低いレイヤ、あるいはソーシャルな側面など...)で注意しなければならない点は山ほどあるのですが、特に「ウェブアプリケーション」において注意が必要なセキュリティホールは、XSS、各種インジェクション、セッションハイジャックにフィクセーションをはじめとして一々気にしていられないほどの数があります(*2)。こういったことをアプリケーションを作るたびに気にしていたのではキリがありません。ですので、フレームワークという枠組みにアプリケーションを乗せることで、既知の問題に関してはフレームワークに面倒を見させる、という解が出てくるわけです(*3)。
上記のような事情で、GREEにもなんらかのウェブアプリケーションフレームワークを、そしてせっかくなので筆者の開発しているEthnaを導入しよう、ということになりました、というかしました。それが2005年の8月のことです。
(*1) そしてソーシャルネットワーキングサービスという語彙の説明が不要なくらいに、サービス自体が一般的なものとなりました。 (*2) 実際に、ウェブアプリケーションのセキュリティを専門に扱うWASF(Web Application Security Forum)という団体があるくらいです (*3) もちろんフレームワークが全ての問題を解決してくれるわけはないのですが:)
Ethna導入の実際
手順
Ethnaの導入を決めた2005年8月にはGREEのユーザ数はすでに20万人近くを数え、少しの不具合が多くのユーザの方のご迷惑となりますし、一方で機能改善なども継続的に行い続けている状況でしたので、「一気にフレームワークを移行」というのは、開発コスト、時間、障害のリスクなどを考慮すると難しい状況にありました。
幸いGREEではEthna導入前からフロントコントローラ+(それらしい)MVC構造に則って動作していました。そこで、実際には以下のような手順で、開発を止めることなく、限りなく低いリスクでフレームワークの移行を行いました(fig. 1)。
1. まずEthnaのコントローラである、Ethna_Contollerクラスを継承したGREE用コントローラを準備しました。GREEのソースコードのディレクトリ構造や実行するアクションの取得方法はEthnaデフォルトのものとは異なっていたのですが（自分で言うのも何なのですが）そのあたりの柔軟性はEthna側で確保されていたので、ディレクトリ定義等を書き換えたり、一部のメソッドをオーバーライドすることで問題なく動作させることが可能でした。
2. 次に、旧コントローラで記述された「前処理」や「後処理」(実行時間の計測や各種ログの出力など)をEthnaのアプリケーションフィルタとして実装しました。これで移行の準備は完了です。
3. 準備が出来たら、移行対象とするアクションを1つずつEthnaのアクションとして再実装します。実際には、「べた書き」されていた処理を適宜アプリケーションのクラスとして再構築する、といったリファクタリングを行いつつアクションを再実装するという作業になりました。
4. 最後に、旧コントローラに「Ethna Hook」（このアクションはEthnaでハンドリングする、というフラグ）を追加してアクションの移行が完了します。あとは、ただひたすらに3.〜4.を繰り返すことで、サービスに影響を与えずに移行を3.〜4.を繰り返すことで、サービスに影響を与えずに移行を3.〜4.を繰り返すことで、サービスに影響を与えずに移行を行うことが出来ます(*4)。
(*4) 実はまだ一部のアクションの移行が完了しません...がこの原稿が紙になるころには完了していることでしょう
メリット
実際にアプリケーションをウェブアプリケーションフレームワークEthnaに載せかえてみて、やはりコストに見合うメリットは十分に得られたと思っています。
まず、移行を通じて必然的にリファクタリングが行われた点があります。リファクタリングのメリットについては誌面やテーマの都合もあってここではご説明できませんが、ここで書くまでもなくあちこち、主にXP周辺の書籍やサイトで数多挙げられています(*4)。が、実際にはデグレードのリスク（これはインターフェース設計やテスティングでカバーするところですよね）や、特にぱっと見のコストといった理由でなかなか難しかったりはするのが現状だったりします。そこに、フレームワークに載せかえるという単純なリファクタリングだけでは得られない価値を出すことで、周りの人や上司の方を説得できるかもしれません（笑）
次に、これはフレームワーク全体に言えるメリットですが、統一されたプラットフォームにアプリケーションを移行することでソースコードの見通しがよくなったり、Ethna（あるいはそれに類似した、あるいはEthna「が」類似しているフレームワーク）の知識がある方の導入コストが下げられたこともあります。さらには前述のように、Ethna自体の改善がそのままアプリケーションの改善にフィードバックされたり、その逆でGREEでの改善がEthnaの改善にフィードバックされてそれがEthnaを利用されているみなさまにフィードバックされたり、といったスパイラルが出来る土壌に乗れたという点も大きいと思います。さらに、XSSといった割と単純ですが面倒な問題への対応ができた点も挙げられます。
(*5) なによりリファクタリングはやっていて気持ちいいです
考慮すべきポイント
実のところ、GREEのような一定以上の規模のサービスにEthnaを導入するのは初めての経験でしたので、いくつか考慮しておかなければならない点がありました。具体的には、(細かくはいろいろあるのですが)主にはパフォーマンスと障害リスクの2つです。
結論から言えば、GREEに関していえば上記2点とも特には問題になっていません。フレームワークを導入すると、どうしても処理量自体は増加するためパフォーマンスの劣化を多少懸念していたのですが、実際にはデータベースアクセスやディスク、ネットワークI/O、そしてアプリケーションのロジックが1リクエストあたりのほとんどの時間を取っているため、Ethnaの利用するリソースは誤差範囲にとどまっています。ですので、例えば「hello world」を表示するだけ、といった単純なアクションだけで構成されているアプリケーションでない限り、最近のサーバでしたらパフォーマンスについては問題ないと考えられると思います。
また、各アクションをEthnaへ移行する際にデグレードが発生するかも、という懸念につきましても、（もちろん一通りのテストを経てリリースする、という手順を踏むことで）発生した障害は想定よりもかなり少ない数にとどまっています(全く無かった、とはいえないのですが...)し、特に致命的な問題には至らずに全ての問題を解決できています。
Ethna@EveryWhere
PHPは、その出自からして、特に小中規模のウェブアプリケーションを非常に作りやすい言語だと思います。そして、よくある話として「いくつかアプリケーションを作った中で自分なりに機能をまとめた『自分フレームワーク』」がどの言語よりも多く存在する、そんな言語のような印象も受けています。
ただ、これはウェブアプリケーション全体を見渡すとやはりちょっと勿体ない話かな、とも思いますので、この際Ethnaに限らずSymfonyでもMojaviでもMapleでも、お好みのフレームワークを利用して、不満な点はどんどん改良してフィードバックしていくことでよりよいフレームワークを一緒に作り上げていければいいな、と思っています(*5)。そういった意味でも、本稿がフレームワーク導入の一助となれば幸いでございます。