すこやかrails
DESCRIPTION
2014-11-01 渋谷Ruby会議01 http://regional.rubykaigi.org/shibuya01/TRANSCRIPT
すこやか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
• 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