LIFULL HOME'S高速化への道のり

HOME’S高速化への道のり2017/7/11

株式会社LIFULL

LIFULL HOME’S事業本部賃貸事業部UXユニット

水野慎也

自己紹介水野慎也2006年ベンチャー企業に営業として新卒入社2007年エンジニアに転向。2009年 LIFULL中途入社。主にLIFULL HOME‘S事業のエンジニアメンバーとして開発業務に従事。現在は、賃貸マーケットのUX向上をミッションとした部署でエンジニアメンバーを統括しています。趣味：筋トレ、居酒屋めぐり

© LIFULL Co.,Ltd. 本書の無断転載、複製を固く禁じます。3

やったこと


サイト高速化

メンバー高速化経験者がおらず、

手探り状態でいろいろ調査・検討

・サーバ強化

・ミドルウェアの導入

・プログラム言語・FWのバージョンアップ

・プロダクトコードの改修

等々･･･


サイト高速化

調査の結果インフラ・ハード面に関しては既に相当手が入っており、最終的にはコードの改修などソフト面での対応が中心になった。

今回は「すごく泥臭い対応で乗り切った」と言うお話をします。


特に改良の余地が見られなかったハード面

・サーバ強化

AWSインスタンスの台数増加・インスタンスタイプのグレードアップを検討

→既に高級なタイプが利用された上でチューニングされており、以上は費用面から見合わない

・ミドルウェアの導入

APC（オペコードキャッシュ）最適化検討

→開発環境のパフォーマンスが悪く、本番環境にGUIが無くチューニングのために導入したところ本番では特に問題は見当たらなかった



・APC

Hit Rateキャッシュが使われている率

たいてい3桁行くのに1~2桁前半(個人環境が集まって

おり各個人しかアクセスしないキャッシュで占められているからというのはある）

Cache full countキャッシュが満杯になりすべて開放した回数

回数がやけに多い（短いUptimeの中で何度もやっている）

Hits & Misses キャッシュヒット率もっとHitは多くできるはず

Shared MemoryAPCに割り当てられたメモリ量

デフォルトの256。Cache full countしまくってるのでもっと大きくしていいのでは

System Cache Entries

キャッシュできているファイル

参照される頻度の高いphpが検索しても出てこない



・プログラム言語・FWのバージョンアップ

→工数が膨大なため断念。しかしいずれはやらねばならないことのため、導入に関しての準備・工数調査までを行った。


サイト高速化

継ぎ足し継ぎ足しで使い続けた秘伝のソース、

「ここは未開の領域のはず」

→プロダクトコードのボトルネックを調査、改修を中心に対応を進めた。


プロダクトコードのボトルネック撲滅

キャッシュ最適化結果：△～○

・データの寿命に合わせた適切な保持期間で

・「キャッシュすれば早くなるだろう」と安易に実装されていたものなどをヒット率を考慮し改修

通信データを圧縮結果：○

・API通信のgzip圧縮等でデータ通信を高速化

・CPU負荷は増加するのでバランスを

並列処理化結果：△～◎

・順番不問の処理はできるだけ並列で同時に


サイト高速化

無駄なデータのダイエット結果：○

・使わない情報を丸ごと取ってくる処理に適切な絞込みを行う。（駅マスタ、APIの返り値等）

遅延読み込み（ajax、lazyload) 結果：△

・初期表示に支障がなければ一つの手

・クローラーには認識されなくなるなどのリスク踏まえる

不要機能の削除結果：◎

・表示速度に影響のある機能を思い切って切る

・本当に不要だったか？の検証は必要


サイト高速化

カテゴリ PJ 効果備考

不要機能削除物件詳細「最近見た」を除去大

並列処理化 indiv並列処理大全ページに効果あり

通信データ圧縮マスタデータgzip圧縮大

キャッシュ最適化キャッシュ構成の見直しと使用メモリ削減中

マスタ系を県・物件種別単位で適切にキャッシュ。メモリ消費の削減も効果的だった。

キャッシュ最適化Code/Item code:bukkenInfoFilterOemキャッシュ化

中

データダイエット nextraAPI field_set無駄削減中

遅延読み込み「他の取扱い物件」「間取ランキング」ajax化中

キャッシュ最適化 css/js minifileキャッシュバスター小

データダイエット画像SVG化ロゴ画像軽量(SVG) 小

並列処理化 list /individual/系並列処小元のボトルネックが小さい

遅延読み込み画像遅延読み込み小 3G環境では一部悪化

通信データ圧縮 op→image ほぼ無ドメインを散らすがうまくいかず

大：100msec～中：50msec程度小：～数10msec


使ったツールなど


サイト高速化

• GoogleAnalytics

母数が最も多く、信頼性の高い情報が得られる

• Dynatrace

サイトに定期アクセスしデータ蓄積（競合比較）

• 自作速度計測ライブラリの埋め込み

各functionごとのボトルネック調査。

• chromeデベロッパーツール

手軽にざっくりパフォーマンス計測

• zipkin

分散トレースシステム。APIのボトルネック調査


サイト高速化

• GoogleAnalytics

速度指標に利用。

「サーバ平均応答時間」「平均ドキュメントコンテンツ読み込み時間」「平均読み込み時間」

のウォッチ。ユーザ体験として特に平均ドキュメントコンテンツ読み込み時間を注視

• Dynatrace

競合比較に利用

自社・競合サイトの同機能ページ

（物件一覧など）に対して

定期アクセスし、速度データを取得。


サイト高速化

• 自作速度計測ライブラリの埋め込み


やりたかったこと（やれなかったこと）


サイト高速化

やりたかったこと（やれなかったこと）

■HTTP/2化

同時リクエスト数を増やせ、大量に存在する外部タグの呼び出しなどを効率化

→サイト全体をhttps化する必要があり、網羅的な改修が必要だったため見送り

■PHPバージョンアップ(5.4→7)

処理速度の向上

→既存コードのライブラリなどが導入の障壁に。


サイト高速化

新技術導入での解決を図っても、

大抵結局は地道な対応が必要に。

腹を決めて取り掛かる。

おわり

Technology

LIFULL HOME'S高速化への道のり