主要なページ単位でグラフ化して週次の報告会で確認しています4。各項目におけるページ単位の推移もグラフ化しています。これらのデータは社員であれば誰でも見ることはできますが、全エンジニアに意識してもらうために毎朝ボットがつぶやいたりもします。移動して原因を調査したり、目標値を達成したときはこの場でお祝いしたりします。可視化できるようにしています。データは色んな観点で取得しており社内で広く使われていますが、パフォーマンス監視の観点で言えば、各アクションのレスポンスタイムをユーザ単位で見ることが出来ます。こちらは主要なアクション別のレスポンスタイムの推移です。週次の報告会で確認していて、変化があったときや新しい機能が追加されたときなどのパフォーマンス変化にすぐに気づけるようにしています。パフォーマンスはデータ数によって左右されるのでサービスの性質上、ユーザ毎に大きくことなる場合があります。ユーザを幾つかのグループに分けて各パフォーマンスの変化を監視しています。併用していてサーバの変化を監視しています。監視方法については割愛しますが、スローログが発生すると権限を持っている一部のエンジニアにメールが飛んで来るようになっています。週次の報告会で発生状況やその対応などの共有を行っています。監視とは若干観点が異なるかもしれませんが、パフォーマンスに関して実際にユーザから意見を頂くこともあります。社内のサポートやセールスの方々はエンジニアよりも実際にサービスを利用することが多く、そちらからも意見を頂きます。最近では我々の活動がエンジニア以外にも浸透してきており、事前にパフォーマンスに関する相談を受けたりなど活発に交流しています。編N+1初歩的ではありますが、気をつけないといつの間にか発生していたりします。利用しており、下記のように開発環境で検知できるようにしています5。`index'例えばこの場合、言われたとおりにするとposts.includes(:comments)のように直せます6。いくつかサービスをリリースしていますが、全てのサービスは共通の認証サーバを経由して認証を行います。認証サーバは認可に必要なロール情報を扱っているため、認証時以外でも問い合わせを行うことがあります。分、認証サーバへの問い合わせが走ります。インパクトが大きく見逃してはいけません。SpeedGunRackアプリケーション用のプロファイリングツールです。下記のように行単位で結果を見れるためどこが遅いか特定するために重宝します7。最新のバージョンに保つようにしています。セキュリティパッチに即座に対応するのはもちろんですが、パフォーマンス改善目的もあります。発生したものは粛々と直します。発行されているか確認するようにしていて、出来る限り発生しないように気をつけています。存在し、パフォーマンス面においても問題を抱えていました。値が大きく改善しました。とあるページにおいて大きな改善が見られます。マーケティングツールやパーフォーマンス監視ツール、チャットツールなど多くの外部サービスを利用しています。利用しているため、エンジニアを通さずに自由に追加することができるようになっています。適切なサービスを使っている分には良いのですが、外部サービスも障害を起こしたり、フロントの処理をブロックしたりするものもあるので利用する上で精査は必要になってきます。現在はまだやってませんが、近いうちに外部サービスが悪影響を及ぼしていないか監視する仕組みを整えようと思っています。テスト改善サービスのパフォーマンス改善に限らず、テストの高速化などもやっています8。これによりテストが遅くなったとき、原因が一目瞭然になります。遅いテストがはっきりするので、思い立ったときにすぐに始められます。並列化していますが、1台で処理するには限界を迎えてきているので、複数台でスケールするような仕組みにしようと考えています。現在取り込んでいるパフォーマンス改善について簡単に説明しました。ボランティアベースでも回ることもありますが、チームのようなものを作って多勢で攻めていく姿勢は大事だと思っています。このようなチームがいることで他のエンジニアやエンジニア以外の社員もパフォーマンスを気にするようになってきており、いい傾向にあると言えます。今後もユーザに対して最速でマジ価値を届けるべくパフォーマンス改善を続けていきます。お楽しみに!突発的な速度低下などの対応を行うこともありますが、それはもはや障害であり、それを起こしたエンジニアがすぐに対応をするのでスコープにはいれてません。縦軸は秒、横軸は時間です。数値は意図的に消してます。ついては以前こんなものを書きました。Adachi@foostan比較的インフラ寄りなエンジニアリングしてます。upLoginユーザーは見つかりませんでした。