現場で使えるSRE / How to Survive as The First SRE
by
Fukao Moto
Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
現場で使えるSRE © 2018 Fukao Moto
Slide 2
Slide 2 text
kurashiruの軌跡 SREガイドライン 1人目のSRE 信頼性を高める 現場で使える Site Reliability Engineering
Slide 3
Slide 3 text
プロの料理人(8年) タコライス研究家 宇宙兄弟好き 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
リリースから1年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
プロダクト 開発 キャパシティプランニング テスト、リリース手順 ポストモーテム、根本原因分析 インシデント対応 モニタリング サービスの信頼性の階層 参考文献:Betsy Beyer他(2017) 「SRE サイトリライアビリティエンジニアリング Googleの信頼性を支えるエンジニアリングチーム」 (澤田武男ほか訳) オライリージャパン Scalability
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の外側に ボトルネックがあるか? ボトルネックの5分類 ある ない
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 3つの対応パターン より早いものを使う I/Oの量を減らす 分散させる
Slide 37
Slide 37 text
Provisioned IOPS, SSD, NVMe 圧縮, キャッシュ, アルゴリズム、データ構造 スケールアウト、LVM、RAID0 代表的な対応策 より早いものを使う I/Oの量を減らす 分散させる
Slide 38
Slide 38 text
CDN Nginx memcached kurashiruの 3つのキャッシュ
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
負荷をかけた時 リソースに縛られて いる?いない? どのリソースに 縛られているか? いない いる CPU メモリ ディスクI/O ネットワーク/リモート (その他のH/W) 設定/ソフトウェア OSの外側に ボトルネックがあるか? ボトルネックの5分類 ある ない
Slide 44
Slide 44 text
プロダクト 開発 キャパシティプランニング テスト、リリース手順 ポストモーテム、根本原因分析 インシデント対応 モニタリング サービスの信頼性の階層 参考文献:Betsy Beyer他(2017) 「SRE サイトリライアビリティエンジニアリング Googleの信頼性を支えるエンジニアリングチーム」 (澤田武男ほか訳) オライリージャパン
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
負荷をかけた時 リソースに縛られて いる?いない? どのリソースに 縛られているか? いない いる CPU メモリ ディスクI/O ネットワーク/リモート (その他のH/W) 設定/ソフトウェア OSの外側に ボトルネックがあるか? ボトルネックの5分類 ある ない
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は1プロセスで1リクエストずつ捌く 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エラー 参考:「1台あたり10,000人を捌くRails製Webサーバのチューニング」http://tech.dely.jp/entry/2017/06/21/191832 参照2018-6-24
Slide 53
Slide 53 text
ボ ト ル ネ ッ ク を 1 つ ず つ 潰 し て ス ケ ー ラ ビ リ テ ィ を 確 保
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 文 1 つ で も で き る ! ?
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
Slide 109
Slide 109 text
© 2018 Fukao Moto アポロ計画の文化の一部は、 想像もつかないような人々やことも含め、 あらゆる人、そしてあらゆることから 学ぶということです。 Margaret Hamilton