2014-11-01 渋谷Ruby会議01 http://regional.rubykaigi.org/shibuya01/

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

14. 13

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

31. 30

32. 31

33. ReliqRefactor
32

34. 33

35. 34

36. 35

37. 人間が論理的に
考えていることは
コードに落とせる
36

38. 戦略2:
プライドをくすぐる
37

39. Badge
38

40. 39
http://sue445.hatenablog.com/entry/2014/08/11/123000

41. 40

42. 戦略3:
競争を煽る
41

43. 運用中サービスの稼働年数
42
0年
1年
2年
3年
4年
DAU、成長率等はバラバラ

44. 43

45. 44

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