すこやかRails

2014-11-01 渋谷Ruby会議01

Transcript

1. すこやかRails ～クソと戦うサービス運用～ 2014-11-01 渋谷Ruby会議01 大仲 能史 a.k.a. @onk
2. self 1
3. self 大仲 能史 RubyKaja 2013 – Rails勉強会@東京 仕事 – アプリケーションエンジニア – 主にサーバサイドの設計・開発を担当 2 @onk
4. self.company 2006年12月 中途入社 2009年4月よりRailsアプリに関わる – Rails暦5年半 3
5. 運用中サービスの稼働年数 4 0年 1年 2年 3年 4年
6. 今日の話 世界はクソ力(ちから)に満ち溢れ ていて、サービスを運用している と必ず健康状態が悪化していきま す。 5
7. クソ力(ちから)の例 • データの蓄積によるレスポンス速度悪化 • 仕様変更による設計の無理 • ライブラリの更新への追随を怠る • 突然応答しなくなるサーバ • 人の流動によるノウハウの低下 • クソクエリ・クソコードの混入 • 技術のブラックボックス化 6
8. 現状を維持していると クソな状態になる 7
9. 今日の話 実装が苦手なエンジニア でもアプリの健康状態を 維持できる仕組みづくり 8
10. アジェンダ 1. 検知する/計測する 2. 改善の手助けをする 9
11. 検知する/計測する 10
12. 検知する/計測する • infra – zabbix – Mine • error – Sentry • User –CommunityWat cher 11 • Performance – MySQL • generalist – Rails • New Relic • CodeStyle – rake stats – metric_fu – rails_best_practices – rubocop
13. Mine 12
15. 14 http://www.slideshare.net/KenichiMitsuki/ss-35379098
16. Mine • 1300台向けにセットアップしたくない – Pushでメトリクスを通知させたい • DCごとに構築したくない • rrdつらぽよ • 見た目が気に入らない 15
17. CommunityWatcher 16
18. • Twitter • 2ch • AppStoreやGooglePlayのレビュー • SNS上のコミュニティ • アプリ内の会話 17 ユーザの生の声を収集するbotたち
19. 生の声を直接見ていると • 検知が早い • ユーザの気持ちに 立って開発できる • リリースの手ごた えを得られる 18 • ノイズが多い • あまりに生すぎて 心が折れる • ユーザの声に流さ れて大勢を見失う
20. Generalist 19
21. 20 http://blog.father.gedow.net/2014/02/25/service-quality-improvement/
22. MySQLのgeneral log + EXPLAIN 21
23. クエリ品質の可視化 22
24. クエリの定量評価 • DQP (Dirty Query Point) –1秒当たりのクソクエリポイント • DUP (Dirty Update Point) –1秒当たりのIO負荷 • DIP (Dirty Index Point) –不要な Index のサジェスト 23
25. クエリの定量評価 基本式 QPS * rows * type係数 * EXTRA係数 24
26. クソクエリは必ず生まれる • データベースの気持ちになって ActiveRecordを操れる人は少ない • サービスを日々改善する。アプリケー ションも日々デプロイする。 • 想定漏れがどうしても出てくる • フリーザ様級 (DQP:53万) のクエリがたま に出てくる 25
27. 今日の話 1. 検知する/計測する 2. 改善の手助けをする 26
28. 改善する手助けをする • CI – Jenkins • MySQL – DQPAnalyzer • Rails – ReliqRefactor 27 • CodeStyle – pront • Development – QueryTracer • Badge • Ranking – Gemicom
29. 戦略1: 目標を目立たせる 28
30. DQPAnalyzer 29
33. ReliqRefactor 32
37. 人間が論理的に 考えていることは コードに落とせる 36
38. 戦略2: プライドをくすぐる 37
39. Badge 38
40. 39 http://sue445.hatenablog.com/entry/2014/08/11/123000
42. 戦略3: 競争を煽る 41
43. 運用中サービスの稼働年数 42 0年 1年 2年 3年 4年 DAU、成長率等はバラバラ
46. gemicom 45 http://rubykaigi.org/2014/presentation/S-TakumiMiura
47. 戦略4: ナビキャラに言わせる 46
48. ｶｰﾁｬﾝJ( 'ｰ`)し • 静的解析bot (pront) • 厳しいのでキャラクター化しないと 心が折れる 47
49. 48 http://sue445.hatenablog.com/entry/2014/10/10/111601
50. 改善を手助けする戦略 1. 目標を目立たせる 2. プライドをくすぐる 3. 競争を煽る 4. ナビキャラに言わせる 49
51. まさにソーシャル ゲームの手口ッ！ 50
52. 改善する手助けをする 51
53. 開発と改善 52
54. 開発：収益を増やす 改善：損失を減らす 53
55. 改善も大事だが 本質ではない 54
56. 改善にかけるコストを 削減していく • 一目でクソだと分からせる • 強くない人でも改善できるよう サジェストする • 意識を無理やり高めるために テクニックを使う • 1人が改善すればみんなが幸せになるよう 共通化する 55
57. 共通化 • RubyKaigi 2014 - “Gem of this week” 56 http://rubykaigi.org/2014/presentation/S-TakumiMiura
58. 今後の課題 57
59. 今後の課題 • 職種間の溝を埋める –フロントエンド⇔サーバサイド –Nativeクライアント⇔サーバ –企画者⇔開発者 • リリース前に検知する 58
60. REPL-client • APIエンドポイントのインタフェースを YAMLで持ち、REPL からリクエストを簡 単に発行するツール • 通信を暗号化しているので簡単に CURL できないという問題を解決 • インタフェースの明文化と、柔軟なチー ト生活に役立つ 59
61. QueryTracer • ARProxyを使って開発中に 問題点を見つ ける • where 1=0 とかパーティションの絞り込み ができていないクエリとか 60
62. まとめ 61
63. 現状維持は悪化の一途 クソ力(ちから)は強大 検知する/計測する ユーザにストレスを強く与えるところ 開発者にストレスを強く与えるところ 改善効率を上げる 判断できるものはシステム化できる 価値の本質に注力しよう 62
64. すこやかとは 健康が維持できていて 改善するのにコストが かからない状態 63