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