レガシーすぎるRailsアプリを10倍高速化した組織的なカイゼン活動
•Download as PPTX, PDF•
1 like•1,231 views
20180307 表参道.rb #44 〜Ruby/Railsパフォーマンス〜 株式会社スタディスト 笹木 信吾
Recommended
More Related Content
What's hot
What's hot (20)
Similar to レガシーすぎるRailsアプリを10倍高速化した組織的なカイゼン活動
Similar to レガシーすぎるRailsアプリを10倍高速化した組織的なカイゼン活動 (20)
レガシーすぎるRailsアプリを10倍高速化した組織的なカイゼン活動
- 1. レガシーすぎるRailsアプリを 10倍高速化した 組織的なカイゼン活動 表参道.rb #44 〜Ruby/Railsパフォーマンス〜 株式会社スタディスト 笹木 信吾 2019/03/07
- 2. 自己紹介 • 2015卒(26歳) • Rails/Vuejs がメインのプログラマ • 最近脱SESして自社開発に • @HousouP ← follow Me! ペットのデグー(齧歯類)
- 9. パフォーマンスとユーザ満足度 • ユーザは1秒以上待たされると、 タスクへの関心を失う • ユーザは10秒以上待たされると タスクを中断し、そのまま戻ってこない恐れ 引用 Google Developers Blog「RAIL モデルでパフォーマンスを計測する」 https://developers.google.com/web/fundamentals/performance/rail
- 13. 平均応答時間が1.37秒な日も
- 18. PWGPerformance Working Group パフォーマンス改善のために立ち上がった漢たちの図 (実際は3名以上居ます)
- 19. PWGとは SRE Lounge #2 に登壇してきた 〜Performance Working Group って何 だ？〜https://medium.com/studist-dev/sre-lounge-2- %E3%81%AB%E7%99%BB%E5%A3%87%E3%81%97%E3%81%A6%E3%81%8D%E3%81%9F-performance-working- group-%E3%81%A3%E3%81%A6%E4%BD%95%E3%81%A0-6112f4ec0307 • 株式会社はてな 様で行われている活動のインスパイア • 弊社では、開発部を横断した組織でのパフォーマンス活動のこと • 詳しくは弊社開発ブログにて！
- 23. 本質的な課題 • 問題を明らかにする仕組みがなかった • 問題解決にコミットする体制がなかった 課題: パフォーマンスがすこぶる悪い パフォーマンスが悪い
- 24. 問題を明らかにしてチームでコミット 1. データを収集する 2. データを可視化する 3. KPIを決める 4. チームでKPIにコミットする GoogleAnalytics Redash Kibana
- 25. 徹底的なパフォーマンス改善活動 • N + 1 問題の解決 • 不要クエリの排除 • インデックスの見直し • APIの責務分割 • 非同期化対応 • インフラ構成の見直し
- 31. PWGによる成果は歴然 項目 Before After 応答時間 95パーセンタイル 8〜9秒 1秒未満 日別平均応答時間 1.37秒 0.13秒
- 33. まとめ • 良いシステムでもパフォーマンスが悪いとユーザはどんどん離れていく • 通常業務もある中でパフォーマンスを改善するには、データの可視化と 取り組むための仕組み作りが必要 • １回の成功に留まらず、継続的な取り組みが重要
- 34. ご清聴ありがとうございました @HousouP ← follow Me!
Editor's Notes
- レガシー過ぎるRailsアプリを10倍高速化した組織的なカイゼン活動、始めさせていただきます。
- 自己紹介ですがほぼ飛ばします。 業務ではRailsとVuejs書いてます。
- 今日は弊社の自社サービスで、業務マニュアルの作成編集共有プラットフォームのTeachmeBizのパフォーマンスを改善した話をさせていただきます。
- 登壇にあたって、広報担当から宣伝しておけと言われてこんなスライドも用意してるんですが、多分誰も興味ないと思うのでカットします。
- で、このTeachmeBiz、以前、というかつい最近までパフォーマンスめっちゃ悪かったです。
- その一例として、レスポンス時間のパーセンタイルを可視化したのがこちらです。 一年ちょっと前ですね。
- 赤が99パーセンタイル、紫が95パーセンタイルを表しているので、リクエストの上位5%はレスポンスに8秒ぐらいかかってしまっていることがわかります。
- 上位5%が8-9秒かかることはどれぐらいヤバイのか？？
- こちらはグーグルデベロッパーブログによる、パフォーマンスとユーザ満足度の指標を引用したものです。 ユーザは１秒以上待たされるとタスクへの関心を失い、１０秒以上待たされるとタスクを中断してそのまま戻ってこない恐れがあるそうです。 たしかに、Webサービスを使っていて、ボタンを押してから１０秒間も反応がなかったら、固まったと思ってブラウザを閉じたりしそうですね。
- 今回のTeachmeのケースでは９５パーセンタイルで１０秒弱だったので、 極端に言えば、ユーザが操作するたびに５％の確率でユーザが離れていってしまう、非常に機会損失の大きな危機的状況になっていました。
- ゆーて遅いのは９５パーセンタイルだけで、一部の重い機能が足引っ張ってるだけでしょ？
- ゆーて遅いのは９５パーセンタイルだけで、一部の重い機能が足引っ張ってるだけでしょ？
- 実際はそんなことなく、平均応答時間で見ても、1.37秒もかかっている日がありました。
- 1.37秒というと、ユーザがタスクへの関心を失うボーダーを超えています。 つまり、ユーザはリクエストのたびにサービスに対する関心を失っているのです。
- 以上のように、どんな便利なシステムも、パフォーマンスが悪ければユーザが離れてしまいます
- そんなサービスの危機的状況に、弊社開発部が動き出しました。
- チームの垣根を超えて、パフォーマンスを改善したい漢たちが集まったのです。 弊社のWeb開発チームは、サーバサイド、フロントエンド、SREが在籍しているのですが、それぞれのチームから、代表となるメンバーが一人以上集まり
- PWGという、パフォーマンス改善を行う専門のチームが生まれました。
- このPWGという言葉は、弊社オリジナルではなく、株式会社はてなさんで行われている活動の影響を受けました。 といっても、弊社におけるPWGは、それにアレンジを加えた独特なものになっているので、詳しくはこちらの弊社開発ブログを見てみてください。
- PWGではまず、改善するために何が課題なのかを洗い出すことからはじめました。
- 課題はもちろんパフォーマンスがすこぶる悪いこと
- かと思いましたがこれは違います。これは課題が引き起こした結果です。
- 本質的な課題はその前段階にありました。 パフォーマンスが悪い問題を明らかにする仕組みがなかったことと、 それを解決するための体制がなかったことです。
- なのでPWGでは、問題を明らかにしてチームでコミットするために、データの収集、可視化からはじめました。 そしてそれらのデータを用いて、KPIを作成、チームで問題解決できる仕組み作りをしました。
- 具体的に行った作業はよくある話なので割愛しますが、まぁ元のコードが大概だったのでこれは結構簡単に治すことができました。
- そのようなPWG活動を通常業務と並行して始めた結果
- 元々8,9秒かかっていた95パーセンタイルは
- 全期間で1秒未満になっています。 50パーセンタイルなんだかだとほぼ0.1秒前後ですね。
- 日によっては1.37秒もあった平均応答時間も
- 最大でも0.13秒まで落としました。
- PWGによる成果は歴然で、平均応答時間は10倍高速化しています。タイトルに偽りなしです。
- PWGはその後、当初の目的は達成したのでひとまず解散としました。 ただし、改善のための仕組みづくりは完了しているので、これからは各々がパフォーマンスを監視して、適宜継続的なカイゼン活動を行うようにしています。
- まとめです。 どんなに良いシステムでもパフォーマンスが悪いとユーザはどんどん離れていってしまいます。 しかし、通常業務もある中で、パフォーマンスを改善するためには、データの可視化と取り組むための仕組み作りが必要でした。 そして、1回の成功にとどまらず、継続的な取り組みが重要だとわかったので、今後も積極的に続けていきたいと思っています。
- 以上です。ご清聴ありがとうございました。 短い時間で浅い話しか出来なかったので、何かありましたら本日の懇親会や、こちらのツイッターで是非お願いします！