Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
すこやかRails
Search
Takafumi ONAKA
PRO
November 01, 2014
Technology
0
12
すこやかRails
2014-11-01 渋谷Ruby会議01
Takafumi ONAKA
PRO
November 01, 2014
Tweet
Share
More Decks by Takafumi ONAKA
See All by Takafumi ONAKA
強いチームと開発生産性
onk
PRO
40
16k
ADRを運用して3年経った僕らの現在地
onk
PRO
21
21k
1文字エイリアスのすゝめ
onk
PRO
0
33
すこやかなサービス運営のための PWG (Performance Working Group)
onk
PRO
0
620
オブザーバビリティの Primary Signals
onk
PRO
2
5k
Cache Stampede
onk
PRO
1
2.1k
ORM - Object-relational mapping
onk
PRO
2
3.6k
デュアルトラックアジャイルとの向き合い方
onk
PRO
5
12k
技術記事を書く&楽しむチームの作り方
onk
PRO
0
1.7k
Other Decks in Technology
See All in Technology
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
20k
移行できそうでやりきれなかった 10年超えのシステムを葬るための戦略 / phper-kaigi-2025-ryu
carta_engineering
0
690
グループポリシー再確認
murachiakira
0
170
職種に名前が付く、ということ/The fact that a job title has a name
bitkey
1
240
パスキーでのログインを 実装してみよう!
hibiki_cube
0
670
OCI見積もり入門セミナー
oracle4engineer
PRO
0
120
モンテカルロ木探索のパフォーマンスを予測する Kaggleコンペ解説 〜生成AIによる未知のゲーム生成〜
rist
4
1.1k
「ラベルにとらわれない」エンジニアでいること/Be an engineer beyond labels
kaonavi
0
130
SSH公開鍵認証による接続 / Connecting with SSH Public Key Authentication
kaityo256
PRO
2
220
コンソールで学ぶ!AWS CodePipelineの機能とオプション
umekou
2
110
Road to SRE NEXT@仙台 IVRyの組織の形とSLO運用の現状
abnoumaru
0
390
ウェブアクセシビリティとは
lycorptech_jp
PRO
0
260
Featured
See All Featured
Embracing the Ebb and Flow
colly
85
4.6k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
16
1.1k
What's in a price? How to price your products and services
michaelherold
245
12k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
30
1.1k
Adopting Sorbet at Scale
ufuk
75
9.3k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.4k
Into the Great Unknown - MozCon
thekraken
36
1.7k
Making Projects Easy
brettharned
116
6.1k
How to Think Like a Performance Engineer
csswizardry
22
1.5k
Product Roadmaps are Hard
iamctodd
PRO
52
11k
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
• 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