はじめに
はじめまして。スマートキャンプでエンジニアをしています井上です。
皆さんパフォーマンス改善でうまくいかなかった経験や失敗した経験はないでしょうか? 今回は自分の経験からパフォーマンス改善に役立ちそうなポイントを5つご紹介したいと思います
- はじめに
- 1. 解決すべきパフォーマンスとは
- 2. パフォーマンス改善の目的を明確にする
- 3. パフォーマンス改善と普通の開発プロセスとの違い
- 4. ボトルネックを上手に知るためには
- 5. 上手にパフォーマンス改善するには
- 最後に
1. 解決すべきパフォーマンスとは
パフォーマンスにはいくつかのパターンが存在します。 この中で自分がどのパフォーマンスを改善するかを知ることはどの計測が必要かにつながる大事なポイントの1つです
スパイクに対するパフォーマンス
⇒ 1分間などで大量のアクセスにどれだけ耐えられるかのパフォーマンスが求められます。
ストレスに対するパフォーマンス
⇒ アクセス数などが徐々に増えていった時にどれだけのアクセス数まで耐えられるかというパフォーマンスが求められます。
サービスに対するパフォーマンス
⇒ サービス・サービスの機能に対するパフォーマンス、すなわちUXやCVなどに必要なパフォーマンスが求められます
2. パフォーマンス改善の目的を明確にする
通常のタスクと同じように、パフォーマンス改善にも明確な理由が必要です。 スピード改善によりUXの向上、SEOの向上などそのページのどの部分を改善することでどんな効果があるのかを定義してパフォーマンス改善が何の目的でやっているかを明確にしましょう。
私は以下のようにまとめることが多いです。
目的
本来のパフォーマンス改善の目的を記載します。
対象
パフォーマンスを改善すべき対象ページ・機能
対象
db index、キャッシュなどの改善手段
目的: SEO向上のためのスピード改善 対象: 記事ページ 手段: レンダリングが遅い箇所をキャッシュ対応
開発の指標
パフォーマンス改善の指標は測定するツール・パフォーマンス改善の目的により異なります
SEOのための指標
Google Page Speed Insight - Googleが提供しているページ速度の点数
サービス改善のための指標
- New Relic APM
- Transactionやその内訳等
- Chrome 開発者ツール
- Perfomenace、Networkタブなどでの計測時間
自分たちがなにを改善したいかによって、ここで採用するべきKPIは変わるでしょう。
3. パフォーマンス改善と普通の開発プロセスとの違い
推測するな計測せよ(Mesure, Don’t Guess)という言葉があるようにパフォーマンス改善作業のほとんどは計測です。 そのため、パフォーマンス改善と通常の開発を同じ考えでやるとハマりがちです。
実装より計測のほうが時間がかかる
大きく通常の開発と異なるのは、実装の時間より計測のための時間の方が圧倒的に長くなる というところです。 改善しては計測を繰り返して効果がある手段を特定するためにほとんど時間を費やします。
工数は長めに見積もる
計測している過程で原因が想定と異なる場合、再度計測が必要になるなど意外と時間取られることが多いです。 想定工数 + 1,2日を目安に見積りしましょう。
4. ボトルネックを上手に知るためには
どんなに正しいプロセスをたどってもボトルネックを正しく把握できなければ意味がありません。 また、ボトルネックはさまざまなツールから出したデータを元に仮説を立てて検証していく必要があります。 パフォーマンスの課題には下記のような問題と解決策があります。
インフラ的改善
- HTTP2対応
- HTTP pipeliningが有効な場合があります
- 圧縮対応
バックエンド側改善
- 単純に時間のかかる処理をリファクタリングする
- N+1問題
- データベースのインデックスについて見直す
フロントエンド側改善
- JS, CSSを圧縮する
- レンダリングブロックの解消
- 画像のサイズ圧縮
- WEBフォント表示・読み込みの非同期化
これ以外にもパフォーマンス問題はありますが、パフォーマンス問題がこの問題のどれに当たるのかを特定するのが計測の目的です。 問題の種類を把握しておくことで、1つの計測に失敗した場合の次のアクションが間違いにくくなります。
計測方法を知る
これらを1つ1つ確認していると膨大な時間がかかります。 必要なのは計測ツールの特性を知り適切な計測を行い、それにより知ることができるデータが何かを把握することです。
私が計測でよく使うツールの一部をご紹介します。
一般的なツール
- NewRelic APM
- slow queryやactionごとの処理にかかった時間などが把握でき、どの処理が鈍重かを把握できます
- LightHouse
- Google Speed Insightでも採用されているツールでフロント側のボトルネックの計測に必要なデータが計測可能
- Chromeの開発者ツール
- 主にフロント側のレンダリングの計測に使用する
前述の通り、これらで得られる値をKPIとして採用することもあるでしょう。
Railsの計測用のGem
RailsではこれらのGemを利用できます。
- rack-mini-profiler
- 発行されたSQLとそれぞれにかかっている時間が表示されます
- rack-lineprof
- controllerやviewを行単位で時間の計測が可能です
- bullet
- N+1問題の計測が可能です
5. 上手にパフォーマンス改善するには
パフォーマンス改善でよくあるのが、頑張って改善した割には効果が薄い・効果なかったなどかと思います。
実際に改善するためには下記のような手法をよくとります。
1. 本番環境に近いデータ量・インフラ環境で計測する 本番のデータ量によってパフォーマンスが低下している問題や 本番環境の設定によりパフォーマンスが低下している場合、問題の特定が難しいためできる限り本番に近い状態で計測しましょう
2. さまざまな改善手段の仮説で計測する 改善や計測の手段が1つだけですと、パフォーマンス改善は難しく改善する際にフロントのみを計測し続けたが実はインフラだったなど回り道をしがちです。 インフラ面、バックエンド、フロントそれぞれパフォーマンス改善方法に特別なものは多くないため基礎的な改善手段は把握しておきましょう
最後に
今回はパフォーマンス改善に関する手法の基礎的な部分をまとめてみました。
パフォーマンス改善の取り組み方などで少しでも助けになれたらうれしいです。