X-over Development Conference　個人メモ１

IT

もうだいぶ前になりましたが9/16に日経ＢＰ主催のセミナーに行ってきました。
現時点でもかなり忘れかかってますが、思い出し用にメモを残しておきます。
ご指摘事項などありましたらコメント欄にお願いしますm(__)m

B-1　大規模サイトの性能問題をゼロに　リクルートの成功事例を公開

リクルート：米谷 修氏

背景と問題点

・「ホットペッパー」「リクナビ」「SUUMO」など大規模サイトを数多く抱えている
・アクセス数が加速度的に増加（1999年：15億PV ⇒ 2011年：635億PV）
・高レスポンスの維持が難しい
・各サイトの機能の増加により、改修難易度がupしている
・Google：ページの読み込みが0.5秒遅くなる　⇒　検索数が20％減少
・Amazon：ページの読み込みが0.5秒遅くなる　⇒　売上が1％減少

原因と課題

１．ボトルネックの特定
　　Oracleが遅いと思ったらJavaだった。でもJavaをよく調べたら検索エンジンが遅かったなど
　　問題箇所の特定に時間がかかる。

２．高いスキルを持った技術者の安定的な確保
　　性能問題に関するハイスキルな要員が性能検証時に確保出来なかった
　　⇒ただ、こういったハイスキルな要員は常に必要なわけではない（コスト大）

３．性能問題が発覚するタイミングが遅い
　　性能検証が開発工程の終盤にあるため、問題が発覚した後のアプリ改修時間がない

解決策

１．ボトルネックを可視化するツール『Perform View』を独自に作成
　　・リクエストごとにユニークなIDを発番（フレームワークの機能として実装）
　　・このIDをリクエストログ、SQLログ、検索エンジンログ、Exceptionログに埋め込む
　　・ログファイルをOracleのDBに取り込んで集計
　　・『Perform View』で、リクエストに対してどこで何秒かかっているかを一覧表示
　　・SQLID から Oracle Enterprise Managerの画面も呼び出せる（実行計画の参照等）

２．性能検証チームをプロジェクトと切り離した独立部隊として設立
　　・共通プールに置いて、必要な時にアサインする
　　・プロジェクト単位でアサインするよりコスト効率がいい
　　・プロジェクトを横断したナレッジの蓄積が可能

３．性能検証を標準工程に組み込む
　　・従来はシステムテスト前後で行なっていた性能検証
　　・現在はサブシステム内結合テストの段階で単体モジュールの性能検証を行う

成果

・2010年に10プロジェクト実施　⇒　サービスイン時の性能問題ゼロ！

今後に向けて

１．性能検証ツールのブラッシュアップ
　　⇒他のフレームワークでも

２．保守案件への適用
　　⇒新規開発だけでなく、保守案件へも適用する

３．ナレッジの展開（スキルの平準化）
　　⇒Wikiベースのナレッジポータル『ナレッジベース』を構築
　　⇒障害事例集をプロジェクト横断で共有
　　⇒社内でメルマガを発行して定期的な意識付けを行う

個人的な感想

話し方、資料、内容全てが完璧で感動しました。
内容の充実度もさることながら、要点のまとめ方や
話すテンポにグラフや図の使い方など、『伝え方』が素晴らしいと思いました。

私もかなり性能問題には苦しめられましたので、
これからの参考にしたいと思います。（特に標準工程に組み込む部分とか）