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

リリースから1年7ヶ月で1000万ダウンロードを超えるクラシルの成長を1人目のSREとして支えた話
- kurashiruの軌跡
- 信頼性を高める
- SREガイドライン
- 1人目のSRE

1. 現場で使えるSRE © 2018 Fukao Moto
2. kurashiruの軌跡 SREガイドライン 1人目のSRE 信頼性を高める 現場で使える Site Reliability Engineering
3. プロの料理人（８年） タコライス研究家 宇宙兄弟好き SRE and データ可視化推進室 Fukao Moto 深尾もとのぶ
4. 学生時代にアルバイトしていた 地元岐阜のピッツェリアへ就職 連日1時間待ちの行列 未経験でプログラマになる 半年後に行った現場が Linuxファイルシステム開発 29歳でフリーランスSIerになる 社員5000人規模の グローバル企業でAIX設計・運用 ベンチャーに憧れ 35歳で拠点を東京に移す AWS RedshiftでDMP構築
5. 2016年12月 レシピ動画サービス 「クラシル」を運営する delyに1人目のSRE としてジョイン
7. リリースから１年7ヶ月で 1000万DL達成 2016年5月 2018年 全国TVCM開始 リリース 2017年 1000万突破 ダ ウ ン ロ l ド 数 レシピ動画数世界一 某TV番組で紹介 Webダウン ここでジョイン
8. 成長期 成熟期 衰退期 プロダクトライフサイクル 導入期 now? join 2016年5月
9. プロダクトライフサイクル 導入期 成長期 成熟期 衰退期 インフラ構築 モニタリング 負荷対策 CI/Pipeline リプレイス コスト削減 セキュリティ バックアップ アラート設定 DevOps キャパシティランニング ドキュメンテーション 障害対応 カイゼン ポストモーテム 効率化 join now?
10. 1 人 目 の S R E と し て k u r a s h i r u の 成 長 を ど の よ う に 支 え て き た か ？
11. kurashiruの軌跡 SREガイドライン 1人目のSRE 信頼性を高める 現場で使える Site Reliability Engineering
12. 1 人 目 の S R E と し て プ ロ ダ ク ト 開 発 の 不 確 実 性 に 技 術 ・ 設 計 面 で ど う 対 処 す る か ？
13. プロダクトライフサイクル 導入期 成長期 成熟期 衰退期 インフラ構築 join
14. ス ケ ー ラ ビ リ テ ィ あ と は つ い て く る ？ と り あ え ず ・ ・ ・
15. 画像：Betsy Beyer他(2017) 「SRE サイトリライアビリティエンジニアリング Googleの信頼性を支えるエンジニアリングチーム」 (澤田武男ほか訳) オライリージャパン
16. プロダクト 開発 キャパシティプランニング テスト、リリース手順 ポストモーテム、根本原因分析 インシデント対応 モニタリング サービスの信頼性の階層 参考文献：Betsy Beyer他(2017) 「SRE サイトリライアビリティエンジニアリング Googleの信頼性を支えるエンジニアリングチーム」 (澤田武男ほか訳) オライリージャパン
17. プロダクト 開発 キャパシティプランニング テスト、リリース手順 ポストモーテム、根本原因分析 インシデント対応 モニタリング サービスの信頼性の階層 参考文献：Betsy Beyer他(2017) 「SRE サイトリライアビリティエンジニアリング Googleの信頼性を支えるエンジニアリングチーム」 (澤田武男ほか訳) オライリージャパン Scalability
18. ス ケ ー ラ ビ リ テ ィ と は ？
19. Throughput Servers or Containers リソースを増やすほど スループットが上がる =スケーラビリティ リソースを増やしても スループットが上がらない =ボトルネック
20. ボ ト ル ネ ッ ク を 解 消 す れ ば ス ケ ー ラ ビ リ テ ィ を 確 保 で き る
21. ボ ト ル ネ ッ ク を 分 類 す る た め の 3 つ の 質 問
22. 負 荷 を か け た 時 リ ソ ー ス に 縛 ら れ て い る か ？
23. ど の リ ソ ー ス に 縛 ら れ て い る か ？
24. O S の 外 側 に ボ ト ル ネ ッ ク が あ る か ？
25. 負荷をかけた時 リソースに縛られて いる？いない？ どのリソースに 縛られているか？ いない いる CPU メモリ ディスクI/O ネットワーク/リモート （その他のH/W） 設定/ソフトウェア OSの外側に ボトルネックがあるか？ ボトルネックの５分類 ある ない
26. CPU メモリ ディスクI/O ネットワーク/リモート 設定/ソフトウェア ボトルネックの分類
27. CPU メモリ ディスクI/O ネットワーク/リモート 設定/ソフトウェア 現場で使える Site Reliability Engineering
28. C P U 使 用 率 は 概 ね C P U 負 荷 の 参 考 に な る
29. 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
30. CPU メモリ ディスクI/O ネットワーク/リモート 設定/ソフトウェア 現場で使える Site Reliability Engineering
31. “ 推 測 す る な 、 計 測 せ よ ” 引用：安井 真伸ほか(2008)「[24時間365日] サーバ/インフラを支える技術 」技術評論社
32. メモリ メモリが足りなくなると 　・スワッピングによるディスクI/O 　・ページングのオーバーヘッド 　・ファイルシステムキャッシュ不足 　　　　　　　　　　　　　　　など 同じファイルを何度も読み書きするサーバは ファイルシステムキャッシュが有効的
33. CPUやメモリが足りない場合は スケールアップやスケールアウト！ コードを見直す必要もあるけど 短期的にはサーバを増やして対応 費用対効果やフェーズ次第！！
34. CPU メモリ ディスクI/O ネットワーク/リモート 設定/ソフトウェア 現場で使える Site Reliability Engineering
35. 従 来 の 一 般 的 な シ ス テ ム は デ ィ ス ク I / O が ボ ト ル ネ ッ ク に な る こ と が 多 い
36. ディスクI/O ３つの対応パターン より早いものを使う I/Oの量を減らす 分散させる
37. Provisioned IOPS, SSD, NVMe 圧縮, キャッシュ, アルゴリズム、データ構造 スケールアウト、LVM、RAID0 代表的な対応策 より早いものを使う I/Oの量を減らす 分散させる
38. CDN Nginx memcached kurashiruの ３つのキャッシュ
39. 1 0 年 前 は 1 0 万 倍 あ っ た デ ィ ス ク と メ モ リ の 速 度 差 は ほ と ん ど な く な っ て き て い る 参考文献：伊藤直也ほか(2010) 「Web開発者のための大規模サービス技術入門」 技術評論社
40. S S D や N V M e の 大 容 量 化 、 低 価 格 化 に よ っ て 今 後 ど う 変 わ る の か ？
41. CPU メモリ ディスクI/O ネットワーク/リモート 設定/ソフトウェア 現場で使える Site Reliability Engineering
42. 根 本 原 因 分 析 に は サ ー ビ ス ご と の レ イ テ ン シ や D B の ス ロ ー ク エ リ が 有 用
43. 負荷をかけた時 リソースに縛られて いる？いない？ どのリソースに 縛られているか？ いない いる CPU メモリ ディスクI/O ネットワーク/リモート （その他のH/W） 設定/ソフトウェア OSの外側に ボトルネックがあるか？ ボトルネックの５分類 ある ない
44. プロダクト 開発 キャパシティプランニング テスト、リリース手順 ポストモーテム、根本原因分析 インシデント対応 モニタリング サービスの信頼性の階層 参考文献：Betsy Beyer他(2017) 「SRE サイトリライアビリティエンジニアリング Googleの信頼性を支えるエンジニアリングチーム」 (澤田武男ほか訳) オライリージャパン
45. 4大シグナル レイテンシ トラフィック エラー サチュレーション 参考文献：Betsy Beyer他(2017) 「SRE サイトリライアビリティエンジニアリング Googleの信頼性を支えるエンジニアリングチーム」 (澤田武男ほか訳) オライリージャパン
46. CPU メモリ ディスクI/O ネットワーク/リモート 設定/ソフトウェア 現場で使える Site Reliability Engineering
47. 負荷をかけた時 リソースに縛られて いる？いない？ どのリソースに 縛られているか？ いない いる CPU メモリ ディスクI/O ネットワーク/リモート （その他のH/W） 設定/ソフトウェア OSの外側に ボトルネックがあるか？ ボトルネックの５分類 ある ない
48. O S や ミ ド ル ウ ェ ア 実 行 環 境 や ア プ リ に ボ ト ル ネ ッ ク が 隠 れ て い る
49. 設定/ソフトウェア TCPポート数 バッファサイズ コネクション数 スレッド数 キュー、バックログの上限 など
50. 設定/ソフトウェア 隠れたボトルネックを探すのは困難 いろんな負荷をかけてみると 　同時リクエスト数 　最大サイズ、合計サイズ 解決の糸口が見つかるかも・・・
51. 事例：ボトルネック解消 abコマンドで負荷テスト Unicornは１プロセスで１リクエストずつ捌く CPUもメモリ使用率も低いのに500エラー メモリを使い切るように worker_processesを5から24に増やす 1000リクエスト以上並列に送ると500エラー CPU使用率が50%台まで上がる
52. 事例：ボトルネック解消 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
53. ボ ト ル ネ ッ ク を １ つ ず つ 潰 し て ス ケ ー ラ ビ リ テ ィ を 確 保
54. ス ケ ー ル し に く い サ ー バ
55. RDBMSは シングルマスタが主流 最近はCloud Spannerや AuroraのMulti Masterなど 色々あるけど基本はCAP定理 DBのスケーラビリティ
56. Query Time Time & Data データが増えるほど クエリの実行時間が長くなる =プロダクトがスケールできない データが増えても クエリの実行時間が増えない =プロダクトのスケーラビリティ確保
57. RDBMSの対策 ( デ ィ ス ク I / O の 対 応 策 と 同 じ ） より早いものを使う I/Oの量を減らす 分散させる
58. オンメモリ、Provisioned IOPS 圧縮、インデックス、パーティショニング 水平分割、垂直分割 DBのI/O対策 より早いものを使う I/Oの量を減らす 分散させる 参考Web：「ソーシャルゲーム案件におけるDB分割のPHP実装」 https://www.slideshare.net/infinite_loop/socialgame-db-slice 参照2018-6-24
59. DBの分割はアプリ側の対応が必要 適切なキャパシティプランニング サービスが最速でグロースしても 耐えうるサイジング キャパシティプランニング
60. ・ 信 頼 性 を 高 め る に は ス ケ ー ラ ビ リ テ ィ を 確 保 す る ・ 根 本 原 因 分 析 を し て ボ ト ル ネ ッ ク の 解 消 ・ 成 長 に 耐 え う る キ ャ パ シ テ ィ プ ラ ン ニ ン グ 現場で使える Site Reliability Engineering
61. kurashiruの軌跡 SREガイドライン 信頼性を高める 現場で使える Site Reliability Engineering 1人目のSRE
62. kurashiruの軌跡 SREガイドライン 信頼性を高める 現場で使える Site Reliability Engineering 1人目のSRE
63. 1 人 目 の S R E と し て プ ロ ダ ク ト 開 発 の 不 確 実 性 に 運 用 面 で ど う 対 処 す る か ？
64. 運 用 に お け る S R E の 課 題
65. リ ソ ー ス は 有 限 だ が 不 確 実 性 や 信 頼 性 に は 際 限 が な い
66. Reliability 改善コスト 改善するほど 信頼性は高まるけど 終わりがない しかも効果は だんだん限定的になる
67. “ あ る 一 線 を 越 え る と 、 信 頼 性 を 向 上 さ せ る こ と は サ ー ビ ス に と っ て 、 む し ろ マ イ ナ ス に な る こ と が わ か っ て い ま す 。 ” 参考文献：Betsy Beyer他(2017) 「SRE サイトリライアビリティエンジニアリング Googleの信頼性を支えるエンジニアリングチーム」 (澤田武男ほか訳) オライリージャパン
68. 際 限 が な い な ら 際 限 を 決 め る
69. サ ー ビ ス レ ベ ル 目 標 ( S L O )
70. 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
71. SLOの決め方 • ユーザー体験を守る • SLIの取得にコストをかけ過ぎない • 必要なサービスだけ • 定期的に見直す
72. 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 課題 達成 達成
73. アラート対応 アラートごとに調査、対策 SLOに影響がなければ対応不要 ただし将来影響がありそうなら調査 B e f o r e A f t e r
74. 評価 インシデント件数、アラート件数 SLOを達成したかどうか ＝減点方式 ＝目標達成方式 A f t e r B e f o r e
75. 改善(Issue) B e f o r e 守りのタスクがエンドレス SLOを達成して 攻めのタスクをやる A f t e r
76. 攻 め 守 り 信頼性向上 技術的負債の返済 やらなければいけないこと グロース施策 技術的挑戦 やりたいこと トイル 機能追加 分 け 方 は 人 に よ っ て 異 な る
77. 人によって異なる 攻めと守りのバランスを 各自でコントロールするため バックログやカンバンといった アジャイル開発のFWを応用 攻めと守りのバランス
78. 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
79. SREのタスク(ISSUE)はとりあえず Backlogに入れる 毎週の定例ミーティングで 優先順位の高いISSUEの ステータスをToDoに変える SRE ISSUE
80. 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
81. 担当は基本的に決めないので 自分からISSUEを拾う(Doing) ToDoを優先しつつ Backlogから拾っても良い 自分から拾うことで自分の タスクをコントロールしやすい SRE ISSUE
82. 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
83. SREのISSUEは背景(Why)と スコープ(What)を決めて、担当(Who)や期限 (When), 方法(How)は決めない 背景を共有していれば 優先順位や期限は各自が判断できる （契約案件など期限つきのISSUEもある） SRE ISSUE
84. やり方(How)は担当者が決める 手段の目的化を防ぎ 生産性とモチベーションが上がる 自由に行動するためには ガイドラインが必要 SRE ISSUE
85. S R E ガ イ ド ラ イ ン
86. SREガイドラインとは SREや他のエンジニアが、 自由に行動するために、 守るべき基準を決めたもの 例：EC2サーバはタグで管理 (project, environment, roleは必須)
87. SREガイドライン サービスレベル目標(SLO) SREオンボーディング 構成管理、タスク管理 リスクコントロール インシデント対応、イベント対応 ドキュメント管理
88. ・ S L O で ス コ ー プ を 決 め る ・ バ ッ ク ロ グ や カ ン バ ン を 使 っ て 　 優 先 度 の 高 い タ ス ク を こ な す ・ S R E ガ イ ド ラ イ ン に よ っ て 　 主 体 的 に 行 動 現場で使える Site Reliability Engineering
89. kurashiruの軌跡 SREガイドライン 信頼性を高める 現場で使える Site Reliability Engineering 1人目のSRE
90. kurashiruの軌跡 SREガイドライン 信頼性を高める 現場で使える Site Reliability Engineering 1人目のSRE
91. W h a t S R E I s
92. S R E に は 専 門 ス キ ル が 必 要 ？
93. イ ン フ ラ エ ン ジ ニ ア と S R E
94. D e v O p s と S R E
95. プロダクトライフサイクル 導入期 成長期 成熟期 衰退期 インフラ構築 モニタリング 負荷対策 CI/Pipeline リプレイス コスト削減 セキュリティ バックアップ アラート設定 DevOps キャパシティランニング ドキュメンテーション 障害対応 カイゼン ポストモーテム 効率化
96. 1 人 目 の S R E
97. “ 私 た ち は 、 M I T か ら 出 向 し て ア ポ ロ 計 画 で 働 い た マ ー ガ レ ッ ト ・ ハ ミ ル ト ン こ そ が 最 初 の S R E と し て の あ ら ゆ る 重 要 な 特 性 を 備 え た 人 物 だ と 考 え ま す 。 ” 引用：Betsy Beyer他(2017) 「SRE サイトリライアビリティエンジニアリング Googleの信頼性を支えるエンジニアリングチーム」 (澤田武男ほか訳) オライリージャパン
98. Margaret Hamilton 画像引用：https://ja.wikipedia.org/wiki/マーガレット・ハミルトン_(科学者) 参照2018-6-24
99. な ぜ 彼 女 が 最 初 の S R E だ と 考 え ら れ て い る の か ？
100. “ 宇 宙 飛 行 士 だ っ て 人 間 だ 間 違 い を 犯 し う る の で は な い か ” “ 自 分 た ち プ ロ グ ラ マ ー も 間 違 い を 犯 し う る の で は な い か ” 参考文献：小野雅裕(2018) 「宇宙に命はあるのか 人類が旅した一千億分の八」 鴎来堂
101. 月面着陸の誘導コンピュータに忍び込ま せたプログラム 何らかの原因でコンピュータがフリーズし そうになったら、生死に関わるプログラム だけを自動で再起動しアラームを出す その際のステータスコード「1202」 アラーム1202 参考文献：小野雅裕(2018) 「宇宙に命はあるのか 人類が旅した一千億分の八」 鴎来堂
102. ア ラ ー ム 1 2 0 2 が な か っ た ら ア ポ ロ 1 1 号 は 月 面 に 降 り ら れ な か っ た
103. 誘 導 プ ロ グ ラ ム の 開 発 が 目 的 だ っ た ら ア ラ ー ム 1 2 0 2 は 生 ま れ な い
104. 目的 手段 人類を月に送ること 月面着陸誘導プログラム
105. S R E に と っ て 重 要 な の は 専 門 ス キ ル よ り 目 的 と 主 体 性
106. ア ラ ー ム 1 2 0 2 は i f 文 １ つ で も で き る ! ?
107. W h a t S R E I s
108. ・ 目 的 を 達 成 す る た め に 主 体 性 が あ れ ば 必 ず し も 高 度 な ス キ ル は 必 要 で は な い ・ ア ラ ー ム 1 2 0 2 を 作 る た め に は 多 少 の エ ン ジ ニ ア リ ン グ の ス キ ル は 必 要 現場で使える Site Reliability Engineering
109. © 2018 Fukao Moto アポロ計画の文化の一部は、 想像もつかないような人々やことも含め、 あらゆる人、そしてあらゆることから 学ぶということです。 Margaret Hamilton