SRE Lounge #9 エムスリーはどのようにしてSREを始めたか

https://sre-lounge.connpass.com/event/129214/

Transcript

1. Copyright © 2015 M3, Inc. All Rights Reserved エムスリーはどのようにして
 SREを始めたか
 2019/05/29 SRE Lounge #9 登壇資料
 M3 Inc. SRE Shohei Takahashi
 

2. 2 • Shohei Takahashi @tshohe1 ◦ エムスリー株式会社 ◦ エンジニアリンググループ SREチーム所属 • エムスリーSRE第一号 • 非リーダーなのでマネジメントはよくわからない • Ansible / Terraform書いたり、監視設定とかログ収集 周りを主に管理してます 自己紹介
3. アジェンダ 1. エムスリー及びSREチーム概要 2. SLI / SLO監視をどう進めたか 3. まとめ 4. 今後 3
4. エムスリー及びSREチーム概要 4
5. エムスリー株式会社とは 5 エムスリーではテクノロジーを活 用し医療業界にイノベーションを 起こすことを目指しています。 日本の医師の約27万人以上、世界 で500万人の医師が集まるプラット フォームを生かし最新技術を駆使し て医療現場・患者さんの問題解決 に取り組んでいきます。
6. マネジメントチーム VPoE GL 採用TL エンジニア人事担当 事業チーム （8） 横断チーム （6） Unit1 MR君 Unit3 新領域 Unit4 サイトプロモ Unit5 コンシューマ Unit6 キャリア Unit7 BIR Unit9 治験 電カル SRE 基盤 マルデバ AI機械学習 セキュリティ QA • 事業領域ごとにUnitというチームに分割 • 各Unitでサービスを開発 • SREや共用サービスを開発する部門は横断 組織として存在 2019年4月時点 約65人 採用チーム エンジニアリンググループ組織図 6
7. SREチーム 7 • インフラチーム配下のポジション？として新設 • 途中からインフラチーム全体をSREチームに改称 ◦ Blog: https://www.m3tech.blog/entry/2018/how-sre-team-started • リーダー1, メンバー4, セキュリティチーム兼任1の計6名 ◦ 海外サービスは担当外だが、最近 USにSREメンバーが行ったりもしている インフラチーム配下SRE ポジみたいな形で新設 2017/11 インフラチーム改めSREチーム リーダーも参画！ 2018/04 ふわっとした時期
8. SREの役割 8 • 従来のインフラチームの作業 ◦ アプリケーション動作環境の整備（インフラセットアップ） ◦ ログの収集と可視化 ◦ システム監視やアラート対応 ...等 • + SRE本に記載されていることの実践 ◦ 各サービスのSLI/SLOの管理 ◦ Toilの削減 ◦ ソフトウェアエンジニアリングによる問題解決の推進 ...等
9. SRE新設時の状態 9 • アプリケーションの品質改善の判断が曖昧 ◦ 何らかの問題が発生 or 開発者が遅いと感じたときに改善を実施 ◦ 判断が非常に主観的 とりあえずSLI / SLO監視をしよう！
10. SLI / SLO監視をどう進めたか 10 進め方 1. 対象のサービスを決める 2. 計測対象の指標（SLI）設定 3. SLI計測 4. 目標値（SLO）設定 5. 可視化 6. アラート設定 7. SLOの定期的な見直し
11. SLI / SLO監視をどう進めたか 11 進め方 1. 対象のサービスを決める 2. 計測対象の指標（SLI）設定 3. SLI計測 4. 目標値（SLO）設定 5. 可視化 6. アラート設定 7. SLOの定期的な見直し
12. 対象のサービスを決める 12 • SLOを設定する対象のアプリケーション数はバックエンドのAPI等を含めると結構 な数がある • 最初から全サービスに対して妥当なSLOを設定するのは辛い... • 小さく始めてから範囲を広げていくアプローチが良さそう • 主要サービスからスタート ◦ 売上の大きいサービス ◦ 共通パーツを返す重要な被依存サービス ◦ 認証サービス ...等
13. SLI / SLO監視をどう進めたか 13 進め方 1. 対象のサービスを決める 2. 計測対象の指標（SLI）設定 3. SLI計測 4. 目標値（SLO）設定 5. 可視化 6. アラート設定 7. SLOの定期的な見直し
14. 何をSLIとするか 14 • 稼働率 ◦ 単純にヘルスチェックURLを監視して応答が返ってくるかどうかの監視 ◦ DB等の依存先の状態も確認し200応答を返す（入門監視のHealthcheck エンドポイン トパターンのような感じ） • レスポンスタイム ◦ サーバサイドのレスポンスタイム ◦ 主に見るのはTOPと全URLへのアクセスの2つ ▪ その他細かい監視は必要に応じて追加する（最初はあまり頑張らない） ◦ クライアントサイドの描画時間まではまだ見れていない 「リクエストの~%以上がレスポンスタイム~ms未満」というように設定にしたほうが SLOの単位と範 囲がすべて同じになるためわかりやすくて良いらしい（まだ出来ていない）
15. SLI / SLO監視をどう進めたか 15 進め方 1. 対象のサービスを決める 2. 計測対象の指標（SLI）設定 3. SLI計測 4. 目標値（SLO）設定 5. 可視化 6. アラート設定 7. SLOの定期的な見直し
16. SLIの計測 - 稼働率 16 • 既に稼働監視で利用していたNagios, NodePingで計測 ◦ Nagios: 各サーバの監視、バックエンドAPIの監視等 ◦ NodePing: StatusCakeとかPingdomのようなURL外形監視サービス • ダウンタイムをAPI等で取得しElasticsearchへ収集 ◦ Elasticsearchを選んだ理由はSLOで使うPercentile値の計算が容易で、尚且アクセス ログが既に入っていたため LB APサーバ 監視ツール Elasticsearch 収集スクリプト
17. SLIの計測 - 稼働率 17 • 値の収集が面倒なので、最近はDatadogの利用を少しずつ拡大中 • 前述のNodePingによる外形監視もSyntheticsのAPI Testに切り替え中 ◦ ダッシュボードで↓みたいな感じで出せる模様（まだβ） • SLOとかも設定できるようなので良さそう • ちなみにSynthetics機能もTerraformで管理できるようになっている
18. SLIの計測 - レスポンスタイム 18 • 基本的にはFluentdで収集 • LBを経由しているものはLBのアクセスログでOK ◦ たまにLBではなくアプリ側でLBしているものがあるのでそこは別途収集 ◦ AWS環境であればCloudWatchでALBのTargetResponseTimeを見る • 長期間のログをElasticsearchで処理するためにAggregatorでサンプリングしている LB APサーバ Elasticsearch Aggregator 基本的にはLB側の アクセスログを利用
19. SLI / SLO監視をどう進めたか 19 進め方 1. 対象のサービスを決める 2. 計測対象の指標（SLI）設定 3. SLI計測 4. 目標値（SLO）設定 5. 可視化 6. アラート設定 7. SLOの定期的な見直し
20. 目標値（SLO）の設定 - 初回SLOの決め方 20 • 全社的な性能要件的なものが決まっていればまずはそれを設定してみる ◦ エムスリーでは主にこれを全てのサービスの SLOとして利用 ◦ 段階としては標準サービス、被依存サービスというくらいのざっくりとした種別で分けて決 定（判断は厳密ではないですが） • 標準サービス ◦ 月間稼働率: 99.9% ◦ 月間のレスポンスタイムの98~99%ile値が1,000ms未満 • 被依存サービス ◦ 月間稼働率: 99.99% ◦ 月間のレスポンスタイムの99%ile値が600ms ~ 1,000ms とか...
21. 目標値（SLO）の設定 - 初回SLOの決め方 21 • The Site Reliability Workbook参考になりそうな記述あり • 個別に設定するのは大変なので下記のように分類ごとの SLOを決めると良いとか クラス 概要 可用性 90%ile Latency(ms) 99%ile Latency(ms) CRITICAL ユーザーがサービスにログインしたときの要求など、最も重要な要求の種類 99.99% 100 200 HIGH_FAST 高可用性と低遅延の要件を備えた要求、コアとなる機能 99.9% 100 200 HIGH_SLOW 待ち時間に左右されない重要な機能 99.9% 1,000 5,000 LOW ある程度の可用性を必要とするが、ユーザーに影響を与えずに長期間失敗する可能性が ある、停止がユーザーにはほとんど見えない要求 99% None None NO_SLO ユーザーにはまったく見えない機能や実験的な機能 None None None URL: https://landing.google.com/sre/workbook/chapters/alerting-on-slos/#request_class_buckets_according_to_simila
22. SLI / SLO監視をどう進めたか 22 進め方 1. 対象のサービスを決める 2. 計測対象の指標（SLI）設定 3. SLI計測 4. 目標値（SLO）設定 5. 可視化 6. アラート設定 7. SLOの定期的な見直し
23. • SLI / SLOを一覧出来るKibanaダッシュボードを整備 ◦ AWS環境のものは今の所Grafana • SLO一覧をまとめたページからリンク 可視化 23 SLIの時系列グラフがまとまった ダッシュボード
24. SLI / SLO監視をどう進めたか 24 進め方 1. 対象のサービスを決める 2. 計測対象の指標（SLI）設定 3. SLI計測 4. 目標値（SLO）設定 5. 可視化 6. アラート設定 7. SLOの定期的な見直し
25. アラート設定 25 • Elasticsearchにpacentile aggregationを投げるスクリプトを作成し定期実行 • SLOを超過していればアラートをSlackに通知するように設定 <サービス名>: channel: #hoge_channel # 通知チャンネル dashboard: <dashboard url> slo: <稼働率SLI名>: template: <稼働率クエリ用テンプレート >.j2 index: <稼働率インデックス >-* operator: ">=" value: <SLO> <レスポンスタイム SLI名>: template:<クエリは種別ごとにテンプレート化 >.j2 index: <Index名>-* operator: "<=" value: <SLO> var: query_list: - '<追加の検索条件 >' SLIのグラフを 閲覧可能
26. アラート設定 26 • 月間のSLOを超過したらJIRAにもチケットを作成 • ポリシーのURLと共にSlackで通知を実施 解消条件 - SLOを下回る - SLO変更ミーティングにて SLOを緩める or - 長期的なSLI改善施策を検討することで対応 を延期可能（対応期限は 1年以内とする） 担当者は右の条件を満たすまでSLI改善施策の優 先度を上げて対応しなければならない 短期的な改善施策がない場合の救済措置
27. SLI / SLO監視をどう進めたか 27 進め方 1. 対象のサービスを決める 2. 計測対象の指標（SLI）設定 3. SLI計測 4. 目標値（SLO）設定 5. 可視化 6. アラート設定 7. SLOの定期的な見直し
28. SLOの定期的な見直し 28 • 各サービスの開発陣とSREとでミーティングを実施 ◦ SRE本でプロダクションミーティングと呼ばれているものに近い ◦ 直近の案件の共有、トラフィックやSLIの値の確認を行う ◦ SLOの見直し（3ヶ月に1度くらいの頻度） • 最初は隔週とかだったが、今は月1くらいのペースで実施 ◦ SRE本では毎週とあるが... ◦ 対応するチームが多いとミーティングだけで時間が持っていかれる ◦ チームによってトピックの量などに違いがあるので頻度は適宜調整していっ たほうが良さそう
29. まとめ • 簡単なSLO超過監視の仕組みが作れた • 明確な閾値を双方同意の上決めているので改善を促しやすく なった • まだまだ手探り状態...
30. 今後 • SLOの変更ルールを厳密にしていきたい ◦ SRE WorkbookのDecision Matrix的なのがあったほうが良さそう ▪ SLO満たしているけど顧客満足度低い -> SLO引き締め...等 ◦ 本の例を真似しようとする場合、顧客満足度を測る必要があり難しい ▪ 一部サービスではNPS測定していたりはする ▪ ただしSLIが評価にどの程度影響しているかどうかは不明 ▪ よほどのことが無い限り機能面のほうが影響が大きい気がする ◦ 単純に SLIの値の改善にかかるコスト > SLI改善による利益 となったらSLOを引き下 げてSLI改善実施、がよい？ ◦ 前者はある程度工数で見積もれると思うが、後者が難しい ▪ クリック課金等、稼働時間と収益がある程度比例していれば簡単か
31. 今後 • アラートがノイジーにならないようにする ◦ オオカミ少年化しないように注意する必要がある ◦ The Site Reliability Workbookで紹介されているバーンレートアラートが良さそう ▪ 短期のSLIがSLOを超過したときにアラートを上げるのではなく、Error Budgetの 消費速度によってアラートを上げるか判断するというもの ▪ 3日くらい持つようならTicket扱い（個人端末に発報しない） ◦ http://landing.google.com/sre/workbook/chapters/alerting-on-slos/
32. M3 Tech Blogの紹介 32 弊社エンジニアの記事がものすごい 更新頻度で綴られています https://www.m3tech.blog/
33. 33 We are hiring! https://m3.recruitment.jp/engineer/
34. 参考 • Site Reliability Engineering: How Google Runs Production Systems ◦ Production Meeting ◦ https://landing.google.com/sre/sre-book/chapters/communication-and-collaboration/ • The Site Reliability Workbook ◦ 2章 Decision Matrix ◦ https://landing.google.com/sre/workbook/chapters/implementing-slos/ ◦ 5章 SLO ◦ https://landing.google.com/sre/workbook/chapters/alerting-on-slos/#request_class_buc kets_according_to_simila • 優れたSLOを策定するには ◦ https://cloudplatform-jp.googleblog.com/2017/11/building-good-SLOs-CRE-life-lessons .html