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

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

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

9296e3361ab10019de475c5f8c33c861?s=128

Fukao Moto

June 28, 2018
Tweet

Transcript

  1. 現場で使えるSRE © 2018 Fukao Moto

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

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

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

    35歳で拠点を東京に移す AWS RedshiftでDMP構築
  5. 2016年12月 レシピ動画サービス 「クラシル」を運営する delyに1人目のSRE としてジョイン

  6. None
  7. リリースから1年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の外側に ボトルネックがあるか? ボトルネックの5分類 ある ない
  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 3つの対応パターン より早いものを使う I/Oの量を減らす 分散させる

  37. Provisioned IOPS, SSD, NVMe 圧縮, キャッシュ, アルゴリズム、データ構造 スケールアウト、LVM、RAID0 代表的な対応策 より早いものを使う

    I/Oの量を減らす 分散させる
  38. CDN Nginx memcached kurashiruの 3つのキャッシュ

  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の外側に ボトルネックがあるか? ボトルネックの5分類 ある ない
  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の外側に ボトルネックがあるか? ボトルネックの5分類 ある ない
  48. O S や ミ ド ル ウ ェ ア 実

    行 環 境 や ア プ リ に ボ ト ル ネ ッ ク が 隠 れ て い る
  49. 設定/ソフトウェア TCPポート数 バッファサイズ コネクション数 スレッド数 キュー、バックログの上限 など

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

  51. 事例:ボトルネック解消 abコマンドで負荷テスト Unicornは1プロセスで1リクエストずつ捌く 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エラー

    参考:「1台あたり10,000人を捌くRails製Webサーバのチューニング」http://tech.dely.jp/entry/2017/06/21/191832 参照2018-6-24
  53. ボ ト ル ネ ッ ク を 1 つ ず

    つ 潰 し て ス ケ ー ラ ビ リ テ ィ を 確 保
  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 文 1 つ で も で き る ! ?
  107. W h a t S R E I s

  108. ・ 目 的 を 達 成 す る た め

    に 主 体 性 が あ れ ば 必 ず し も 高 度 な ス キ ル は 必 要 で は な い ・ ア ラ ー ム 1 2 0 2 を 作 る た め に は 多 少 の エ ン ジ ニ ア リ ン グ の ス キ ル は 必 要 現場で使える Site Reliability Engineering
  109. © 2018 Fukao Moto アポロ計画の文化の一部は、 想像もつかないような人々やことも含め、 あらゆる人、そしてあらゆることから 学ぶということです。 Margaret Hamilton