現場で使えるSRE / How to Survive as The First SRE

by Fukao Moto

Slide 1

Slide 1 text

Slide 2

Slide 2 text

kurashiruの軌跡 SREガイドライン 1人目のSRE 信頼性を高める現場で使える Site Reliability Engineering

Slide 3

Slide 3 text

プロの料理人（８年）タコライス研究家宇宙兄弟好き SRE and データ可視化推進室 Fukao Moto 深尾もとのぶ

Slide 4

Slide 4 text

学生時代にアルバイトしていた地元岐阜のピッツェリアへ就職連日1時間待ちの行列未経験でプログラマになる半年後に行った現場が Linuxファイルシステム開発 29歳でフリーランスSIerになる社員5000人規模のグローバル企業でAIX設計・運用ベンチャーに憧れ 35歳で拠点を東京に移す AWS RedshiftでDMP構築

Slide 5

Slide 5 text

2016年12月レシピ動画サービス「クラシル」を運営する delyに1人目のSRE としてジョイン

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

リリースから１年7ヶ月で 1000万DL達成 2016年5月 2018年全国TVCM開始リリース 2017年 1000万突破ダウンロ l ド数レシピ動画数世界一某TV番組で紹介 Webダウンここでジョイン

Slide 8

Slide 8 text

成長期成熟期衰退期プロダクトライフサイクル導入期 now? join 2016年5月

Slide 9

Slide 9 text

プロダクトライフサイクル導入期成長期成熟期衰退期インフラ構築モニタリング負荷対策 CI/Pipeline リプレイスコスト削減セキュリティバックアップアラート設定 DevOps キャパシティランニングドキュメンテーション障害対応カイゼンポストモーテム効率化 join now?

Slide 10

Slide 10 text

1 人目の S R E として k u r a s h i r u の成長をどのように支えてきたか？

Slide 11

Slide 11 text

kurashiruの軌跡 SREガイドライン 1人目のSRE 信頼性を高める現場で使える Site Reliability Engineering

Slide 12

Slide 12 text

1 人目の S R E としてプロダクト開発の不確実性に技術・設計面でどう対処するか？

Slide 13

Slide 13 text

プロダクトライフサイクル導入期成長期成熟期衰退期インフラ構築 join

Slide 14

Slide 14 text

スケーラビリティあとはついてくる？とりあえず・・・

Slide 15

Slide 15 text

画像：Betsy Beyer他(2017) 「SRE サイトリライアビリティエンジニアリング Googleの信頼性を支えるエンジニアリングチーム」 (澤田武男ほか訳) オライリージャパン

Slide 16

Slide 16 text

プロダクト開発キャパシティプランニングテスト、リリース手順ポストモーテム、根本原因分析インシデント対応モニタリングサービスの信頼性の階層参考文献：Betsy Beyer他(2017) 「SRE サイトリライアビリティエンジニアリング Googleの信頼性を支えるエンジニアリングチーム」 (澤田武男ほか訳) オライリージャパン

Slide 17

Slide 17 text

Slide 18

Slide 18 text

スケーラビリティとは？

Slide 19

Slide 19 text

Throughput Servers or Containers リソースを増やすほどスループットが上がる =スケーラビリティリソースを増やしてもスループットが上がらない =ボトルネック

Slide 20

Slide 20 text

ボトルネックを解消すればスケーラビリティを確保できる

Slide 21

Slide 21 text

ボトルネックを分類するための 3 つの質問

Slide 22

Slide 22 text

負荷をかけた時リソースに縛られているか？

Slide 23

Slide 23 text

どのリソースに縛られているか？

Slide 24

Slide 24 text

O S の外側にボトルネックがあるか？

Slide 25

Slide 25 text

負荷をかけた時リソースに縛られている？いない？どのリソースに縛られているか？いないいる CPU メモリディスクI/O ネットワーク/リモート（その他のH/W）設定/ソフトウェア OSの外側にボトルネックがあるか？ボトルネックの５分類あるない

Slide 26

Slide 26 text

CPU メモリディスクI/O ネットワーク/リモート設定/ソフトウェアボトルネックの分類

Slide 27

Slide 27 text

CPU メモリディスクI/O ネットワーク/リモート設定/ソフトウェア現場で使える Site Reliability Engineering

Slide 28

Slide 28 text

C P U 使用率は概ね C P U 負荷の参考になる

Slide 29

Slide 29 text

CPU負荷を見分ける • CPUに空きがあってもiowaitが上がればidle が下がる（見た目のCPU使用率が上がる） • ロードアベレージはCPUの負荷でもI/Oの負荷でも上がる • topやsarコマンドのCPU使用率はコア数で割られるがロードアベレージはコア数で割られない • user+sysが100%だと、I/O負荷があっても iowaitは上がらない参考Web：「マルチコア時代のロードアベレージの見方」http://d.hatena.ne.jp/naoya/20070518/1179492085 参照2018-6-24 「I/O負荷の正確な状況はiowaitでは分かりません」https://qiita.com/kunihirotanaka/items/a536ee35d589027e4a5a 参照2018-6-24

Slide 30

Slide 30 text

CPU メモリディスクI/O ネットワーク/リモート設定/ソフトウェア現場で使える Site Reliability Engineering

Slide 31

Slide 31 text

“ 推測するな、計測せよ ” 引用：安井真伸ほか(2008)「[24時間365日] サーバ/インフラを支える技術」技術評論社

Slide 32

Slide 32 text

メモリメモリが足りなくなると　・スワッピングによるディスクI/O 　・ページングのオーバーヘッド　・ファイルシステムキャッシュ不足　　　　　　　　　　　　　　　など同じファイルを何度も読み書きするサーバはファイルシステムキャッシュが有効的

Slide 33

Slide 33 text

CPUやメモリが足りない場合はスケールアップやスケールアウト！コードを見直す必要もあるけど短期的にはサーバを増やして対応費用対効果やフェーズ次第！！

Slide 34

Slide 34 text

CPU メモリディスクI/O ネットワーク/リモート設定/ソフトウェア現場で使える Site Reliability Engineering

Slide 35

Slide 35 text

従来の一般的なシステムはディスク I / O がボトルネックになることが多い

Slide 36

Slide 36 text

ディスクI/O ３つの対応パターンより早いものを使う I/Oの量を減らす分散させる

Slide 37

Slide 37 text

Provisioned IOPS, SSD, NVMe 圧縮, キャッシュ, アルゴリズム、データ構造スケールアウト、LVM、RAID0 代表的な対応策より早いものを使う I/Oの量を減らす分散させる

Slide 38

Slide 38 text

CDN Nginx memcached kurashiruの３つのキャッシュ

Slide 39

Slide 39 text

1 0 年前は 1 0 万倍あったディスクとメモリの速度差はほとんどなくなってきている参考文献：伊藤直也ほか(2010) 「Web開発者のための大規模サービス技術入門」技術評論社

Slide 40

Slide 40 text

S S D や N V M e の大容量化、低価格化によって今後どう変わるのか？

Slide 41

Slide 41 text

CPU メモリディスクI/O ネットワーク/リモート設定/ソフトウェア現場で使える Site Reliability Engineering

Slide 42

Slide 42 text

根本原因分析にはサービスごとのレイテンシや D B のスロークエリが有用

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

4大シグナルレイテンシトラフィックエラーサチュレーション参考文献：Betsy Beyer他(2017) 「SRE サイトリライアビリティエンジニアリング Googleの信頼性を支えるエンジニアリングチーム」 (澤田武男ほか訳) オライリージャパン

Slide 46

Slide 46 text

CPU メモリディスクI/O ネットワーク/リモート設定/ソフトウェア現場で使える Site Reliability Engineering

Slide 47

Slide 47 text

Slide 48

Slide 48 text

O S やミドルウェア実行環境やアプリにボトルネックが隠れている

Slide 49

Slide 49 text

設定/ソフトウェア TCPポート数バッファサイズコネクション数スレッド数キュー、バックログの上限など

Slide 50

Slide 50 text

設定/ソフトウェア隠れたボトルネックを探すのは困難いろんな負荷をかけてみると　同時リクエスト数　最大サイズ、合計サイズ解決の糸口が見つかるかも・・・

Slide 51

Slide 51 text

事例：ボトルネック解消 abコマンドで負荷テスト Unicornは１プロセスで１リクエストずつ捌く CPUもメモリ使用率も低いのに500エラーメモリを使い切るように worker_processesを5から24に増やす 1000リクエスト以上並列に送ると500エラー CPU使用率が50%台まで上がる

Slide 52

Slide 52 text

事例：ボトルネック解消 NginxとUnicornの間のUNIXソケット backlog: 1024 (default) unicorn.sockのbacklog=8192 CPU使用率が100% 負荷に合わせてスケールアウトスケーラビリティを確保 1000リクエスト以上同時に送ると500エラー参考：「１台あたり10,000人を捌くRails製Webサーバのチューニング」http://tech.dely.jp/entry/2017/06/21/191832 参照2018-6-24

Slide 53

Slide 53 text

ボトルネックを１つずつ潰してスケーラビリティを確保

Slide 54

Slide 54 text

スケールしにくいサーバ

Slide 55

Slide 55 text

RDBMSはシングルマスタが主流最近はCloud Spannerや AuroraのMulti Masterなど色々あるけど基本はCAP定理 DBのスケーラビリティ

Slide 56

Slide 56 text

Query Time Time & Data データが増えるほどクエリの実行時間が長くなる =プロダクトがスケールできないデータが増えてもクエリの実行時間が増えない =プロダクトのスケーラビリティ確保

Slide 57

Slide 57 text

RDBMSの対策 ( ディスク I / O の対応策と同じ）より早いものを使う I/Oの量を減らす分散させる

Slide 58

Slide 58 text

オンメモリ、Provisioned IOPS 圧縮、インデックス、パーティショニング水平分割、垂直分割 DBのI/O対策より早いものを使う I/Oの量を減らす分散させる参考Web：「ソーシャルゲーム案件におけるDB分割のPHP実装」 https://www.slideshare.net/infinite_loop/socialgame-db-slice 参照2018-6-24

Slide 59

Slide 59 text

DBの分割はアプリ側の対応が必要適切なキャパシティプランニングサービスが最速でグロースしても耐えうるサイジングキャパシティプランニング

Slide 60

Slide 60 text

・信頼性を高めるにはスケーラビリティを確保する・根本原因分析をしてボトルネックの解消・成長に耐えうるキャパシティプランニング現場で使える Site Reliability Engineering

Slide 61

Slide 61 text

kurashiruの軌跡 SREガイドライン信頼性を高める現場で使える Site Reliability Engineering 1人目のSRE

Slide 62

Slide 62 text

kurashiruの軌跡 SREガイドライン信頼性を高める現場で使える Site Reliability Engineering 1人目のSRE

Slide 63

Slide 63 text

1 人目の S R E としてプロダクト開発の不確実性に運用面でどう対処するか？

Slide 64

Slide 64 text

運用における S R E の課題

Slide 65

Slide 65 text

リソースは有限だが不確実性や信頼性には際限がない

Slide 66

Slide 66 text

Reliability 改善コスト改善するほど信頼性は高まるけど終わりがないしかも効果はだんだん限定的になる

Slide 67

Slide 67 text

“ ある一線を越えると、信頼性を向上させることはサービスにとって、むしろマイナスになることがわかっています。 ” 参考文献：Betsy Beyer他(2017) 「SRE サイトリライアビリティエンジニアリング Googleの信頼性を支えるエンジニアリングチーム」 (澤田武男ほか訳) オライリージャパン

Slide 68

Slide 68 text

際限がないなら際限を決める

Slide 69

Slide 69 text

サービスレベル目標 ( S L O )

Slide 70

Slide 70 text

SLOの運用 SLO SLI 1st week 2nd week 3rd week 4th week API稼働率 99.99% 100% 100% 100% 100% APIレイテンシ(95p) 500msec 0 1 0 0 検索レイテンシ(99p) 300msec 1 3 2 0 ログ欠損率 1%/day 0 1 0 0

Slide 71

Slide 71 text

SLOの決め方 • ユーザー体験を守る • SLIの取得にコストをかけ過ぎない • 必要なサービスだけ • 定期的に見直す

Slide 72

Slide 72 text

SLOの運用 SLO SLI 1st week 2nd week 3rd week 4th week API稼働率 99.99% 100% 100% 100% 100% APIレイテンシ(95p) 500msec 0 1 0 0 検索レイテンシ(99p) 300msec 1 3 2 0 ログ欠損率 1%/day 0 1 0 0 課題達成達成

Slide 73

Slide 73 text

アラート対応アラートごとに調査、対策 SLOに影響がなければ対応不要ただし将来影響がありそうなら調査 B e f o r e A f t e r

Slide 74

Slide 74 text

評価インシデント件数、アラート件数 SLOを達成したかどうか＝減点方式＝目標達成方式 A f t e r B e f o r e

Slide 75

Slide 75 text

改善(Issue) B e f o r e 守りのタスクがエンドレス SLOを達成して攻めのタスクをやる A f t e r

Slide 76

Slide 76 text

攻め守り信頼性向上技術的負債の返済やらなければいけないことグロース施策技術的挑戦やりたいことトイル機能追加分け方は人によって異なる

Slide 77

Slide 77 text

人によって異なる攻めと守りのバランスを各自でコントロールするためバックログやカンバンといったアジャイル開発のFWを応用攻めと守りのバランス

Slide 78

Slide 78 text

ToDo Issue Backlog Doing Done Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue

Slide 79

Slide 79 text

SREのタスク(ISSUE)はとりあえず Backlogに入れる毎週の定例ミーティングで優先順位の高いISSUEのステータスをToDoに変える SRE ISSUE

Slide 80

Slide 80 text

ToDo Backlog Doing Done Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue

Slide 81

Slide 81 text

担当は基本的に決めないので自分からISSUEを拾う(Doing) ToDoを優先しつつ Backlogから拾っても良い自分から拾うことで自分のタスクをコントロールしやすい SRE ISSUE

Slide 82

Slide 82 text

ToDo Backlog Doing Done Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue Issue

Slide 83

Slide 83 text

SREのISSUEは背景(Why)とスコープ(What)を決めて、担当(Who)や期限 (When), 方法(How)は決めない背景を共有していれば優先順位や期限は各自が判断できる（契約案件など期限つきのISSUEもある） SRE ISSUE

Slide 84

Slide 84 text

やり方(How)は担当者が決める手段の目的化を防ぎ生産性とモチベーションが上がる自由に行動するためにはガイドラインが必要 SRE ISSUE

Slide 85

Slide 85 text

S R E ガイドライン

Slide 86

Slide 86 text

SREガイドラインとは SREや他のエンジニアが、自由に行動するために、守るべき基準を決めたもの例：EC2サーバはタグで管理 (project, environment, roleは必須)

Slide 87

Slide 87 text

SREガイドラインサービスレベル目標(SLO) SREオンボーディング構成管理、タスク管理リスクコントロールインシデント対応、イベント対応ドキュメント管理

Slide 88

Slide 88 text

・ S L O でスコープを決める・バックログやカンバンを使って　優先度の高いタスクをこなす・ S R E ガイドラインによって　主体的に行動現場で使える Site Reliability Engineering

Slide 89

Slide 89 text

kurashiruの軌跡 SREガイドライン信頼性を高める現場で使える Site Reliability Engineering 1人目のSRE

Slide 90

Slide 90 text

kurashiruの軌跡 SREガイドライン信頼性を高める現場で使える Site Reliability Engineering 1人目のSRE

Slide 91

Slide 91 text

W h a t S R E I s

Slide 92

Slide 92 text

S R E には専門スキルが必要？

Slide 93

Slide 93 text

インフラエンジニアと S R E

Slide 94

Slide 94 text

D e v O p s と S R E

Slide 95

Slide 95 text

プロダクトライフサイクル導入期成長期成熟期衰退期インフラ構築モニタリング負荷対策 CI/Pipeline リプレイスコスト削減セキュリティバックアップアラート設定 DevOps キャパシティランニングドキュメンテーション障害対応カイゼンポストモーテム効率化

Slide 96

Slide 96 text

1 人目の S R E

Slide 97

Slide 97 text

“ 私たちは、 M I T から出向してアポロ計画で働いたマーガレット・ハミルトンこそが最初の S R E としてのあらゆる重要な特性を備えた人物だと考えます。 ” 引用：Betsy Beyer他(2017) 「SRE サイトリライアビリティエンジニアリング Googleの信頼性を支えるエンジニアリングチーム」 (澤田武男ほか訳) オライリージャパン

Slide 98

Slide 98 text

Margaret Hamilton 画像引用：https://ja.wikipedia.org/wiki/マーガレット・ハミルトン_(科学者) 参照2018-6-24

Slide 99

Slide 99 text

なぜ彼女が最初の S R E だと考えられているのか？

Slide 100

Slide 100 text

“ 宇宙飛行士だって人間だ間違いを犯しうるのではないか ” “ 自分たちプログラマーも間違いを犯しうるのではないか ” 参考文献：小野雅裕(2018) 「宇宙に命はあるのか人類が旅した一千億分の八」鴎来堂

Slide 101

Slide 101 text

月面着陸の誘導コンピュータに忍び込ませたプログラム何らかの原因でコンピュータがフリーズしそうになったら、生死に関わるプログラムだけを自動で再起動しアラームを出すその際のステータスコード「1202」アラーム1202 参考文献：小野雅裕(2018) 「宇宙に命はあるのか人類が旅した一千億分の八」鴎来堂

Slide 102

Slide 102 text

アラーム 1 2 0 2 がなかったらアポロ 1 1 号は月面に降りられなかった

Slide 103

Slide 103 text

誘導プログラムの開発が目的だったらアラーム 1 2 0 2 は生まれない

Slide 104

Slide 104 text

目的手段人類を月に送ること月面着陸誘導プログラム

Slide 105

Slide 105 text

S R E にとって重要なのは専門スキルより目的と主体性

Slide 106

Slide 106 text

アラーム 1 2 0 2 は i f 文１つでもできる ! ?

Slide 107

Slide 107 text

W h a t S R E I s

Slide 108

Slide 108 text

・目的を達成するために主体性があれば必ずしも高度なスキルは必要ではない・アラーム 1 2 0 2 を作るためには多少のエンジニアリングのスキルは必要現場で使える Site Reliability Engineering