Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

tshohe

May 29, 2019
Tweet

More Decks by tshohe

Other Decks in Technology

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. マネジメントチーム VPoE GL 採用TL エンジニア人事担当 事業チーム (8) 横断チーム (6) Unit1

    MR君 Unit3 新領域 Unit4 サイトプロモ Unit5 コンシューマ Unit6 キャリア Unit7 BIR Unit9 治験 電カル SRE 基盤 マルデバ AI機械学習 セキュリティ QA • 事業領域ごとにUnitというチームに分割 • 各Unitでサービスを開発 • SREや共用サービスを開発する部門は横断 組織として存在 2019年4月時点 約65人 採用チーム エンジニアリンググループ組織図 6
  4. 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 ふわっとした時期
  5. SREの役割 8 • 従来のインフラチームの作業 ◦ アプリケーション動作環境の整備(インフラセットアップ) ◦ ログの収集と可視化 ◦ システム監視やアラート対応

    ...等 • + SRE本に記載されていることの実践 ◦ 各サービスのSLI/SLOの管理 ◦ Toilの削減 ◦ ソフトウェアエンジニアリングによる問題解決の推進 ...等
  6. SLI / SLO監視をどう進めたか 10 進め方 1. 対象のサービスを決める 2. 計測対象の指標(SLI)設定 3.

    SLI計測 4. 目標値(SLO)設定 5. 可視化 6. アラート設定 7. SLOの定期的な見直し
  7. SLI / SLO監視をどう進めたか 11 進め方 1. 対象のサービスを決める 2. 計測対象の指標(SLI)設定 3.

    SLI計測 4. 目標値(SLO)設定 5. 可視化 6. アラート設定 7. SLOの定期的な見直し
  8. SLI / SLO監視をどう進めたか 13 進め方 1. 対象のサービスを決める 2. 計測対象の指標(SLI)設定 3.

    SLI計測 4. 目標値(SLO)設定 5. 可視化 6. アラート設定 7. SLOの定期的な見直し
  9. 何をSLIとするか 14 • 稼働率 ◦ 単純にヘルスチェックURLを監視して応答が返ってくるかどうかの監視 ◦ DB等の依存先の状態も確認し200応答を返す(入門監視のHealthcheck エンドポイン トパターンのような感じ)

    • レスポンスタイム ◦ サーバサイドのレスポンスタイム ◦ 主に見るのはTOPと全URLへのアクセスの2つ ▪ その他細かい監視は必要に応じて追加する(最初はあまり頑張らない) ◦ クライアントサイドの描画時間まではまだ見れていない 「リクエストの~%以上がレスポンスタイム~ms未満」というように設定にしたほうが SLOの単位と範 囲がすべて同じになるためわかりやすくて良いらしい(まだ出来ていない)
  10. SLI / SLO監視をどう進めたか 15 進め方 1. 対象のサービスを決める 2. 計測対象の指標(SLI)設定 3.

    SLI計測 4. 目標値(SLO)設定 5. 可視化 6. アラート設定 7. SLOの定期的な見直し
  11. SLIの計測 - 稼働率 16 • 既に稼働監視で利用していたNagios, NodePingで計測 ◦ Nagios: 各サーバの監視、バックエンドAPIの監視等

    ◦ NodePing: StatusCakeとかPingdomのようなURL外形監視サービス • ダウンタイムをAPI等で取得しElasticsearchへ収集 ◦ Elasticsearchを選んだ理由はSLOで使うPercentile値の計算が容易で、尚且アクセス ログが既に入っていたため LB APサーバ 監視ツール Elasticsearch 収集スクリプト
  12. SLIの計測 - 稼働率 17 • 値の収集が面倒なので、最近はDatadogの利用を少しずつ拡大中 • 前述のNodePingによる外形監視もSyntheticsのAPI Testに切り替え中 ◦

    ダッシュボードで↓みたいな感じで出せる模様(まだβ) • SLOとかも設定できるようなので良さそう • ちなみにSynthetics機能もTerraformで管理できるようになっている
  13. SLIの計測 - レスポンスタイム 18 • 基本的にはFluentdで収集 • LBを経由しているものはLBのアクセスログでOK ◦ たまにLBではなくアプリ側でLBしているものがあるのでそこは別途収集

    ◦ AWS環境であればCloudWatchでALBのTargetResponseTimeを見る • 長期間のログをElasticsearchで処理するためにAggregatorでサンプリングしている LB APサーバ Elasticsearch Aggregator 基本的にはLB側の アクセスログを利用
  14. SLI / SLO監視をどう進めたか 19 進め方 1. 対象のサービスを決める 2. 計測対象の指標(SLI)設定 3.

    SLI計測 4. 目標値(SLO)設定 5. 可視化 6. アラート設定 7. SLOの定期的な見直し
  15. 目標値(SLO)の設定 - 初回SLOの決め方 20 • 全社的な性能要件的なものが決まっていればまずはそれを設定してみる ◦ エムスリーでは主にこれを全てのサービスの SLOとして利用 ◦

    段階としては標準サービス、被依存サービスというくらいのざっくりとした種別で分けて決 定(判断は厳密ではないですが) • 標準サービス ◦ 月間稼働率: 99.9% ◦ 月間のレスポンスタイムの98~99%ile値が1,000ms未満 • 被依存サービス ◦ 月間稼働率: 99.99% ◦ 月間のレスポンスタイムの99%ile値が600ms ~ 1,000ms とか...
  16. 目標値(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
  17. SLI / SLO監視をどう進めたか 22 進め方 1. 対象のサービスを決める 2. 計測対象の指標(SLI)設定 3.

    SLI計測 4. 目標値(SLO)設定 5. 可視化 6. アラート設定 7. SLOの定期的な見直し
  18. SLI / SLO監視をどう進めたか 24 進め方 1. 対象のサービスを決める 2. 計測対象の指標(SLI)設定 3.

    SLI計測 4. 目標値(SLO)設定 5. 可視化 6. アラート設定 7. SLOの定期的な見直し
  19. アラート設定 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のグラフを 閲覧可能
  20. アラート設定 26 • 月間のSLOを超過したらJIRAにもチケットを作成 • ポリシーのURLと共にSlackで通知を実施 解消条件 - SLOを下回る -

    SLO変更ミーティングにて SLOを緩める or - 長期的なSLI改善施策を検討することで対応 を延期可能(対応期限は 1年以内とする) 担当者は右の条件を満たすまでSLI改善施策の優 先度を上げて対応しなければならない 短期的な改善施策がない場合の救済措置
  21. SLI / SLO監視をどう進めたか 27 進め方 1. 対象のサービスを決める 2. 計測対象の指標(SLI)設定 3.

    SLI計測 4. 目標値(SLO)設定 5. 可視化 6. アラート設定 7. SLOの定期的な見直し
  22. SLOの定期的な見直し 28 • 各サービスの開発陣とSREとでミーティングを実施 ◦ SRE本でプロダクションミーティングと呼ばれているものに近い ◦ 直近の案件の共有、トラフィックやSLIの値の確認を行う ◦ SLOの見直し(3ヶ月に1度くらいの頻度)

    • 最初は隔週とかだったが、今は月1くらいのペースで実施 ◦ SRE本では毎週とあるが... ◦ 対応するチームが多いとミーティングだけで時間が持っていかれる ◦ チームによってトピックの量などに違いがあるので頻度は適宜調整していっ たほうが良さそう
  23. 今後 • SLOの変更ルールを厳密にしていきたい ◦ SRE WorkbookのDecision Matrix的なのがあったほうが良さそう ▪ SLO満たしているけど顧客満足度低い ->

    SLO引き締め...等 ◦ 本の例を真似しようとする場合、顧客満足度を測る必要があり難しい ▪ 一部サービスではNPS測定していたりはする ▪ ただしSLIが評価にどの程度影響しているかどうかは不明 ▪ よほどのことが無い限り機能面のほうが影響が大きい気がする ◦ 単純に SLIの値の改善にかかるコスト > SLI改善による利益 となったらSLOを引き下 げてSLI改善実施、がよい? ◦ 前者はある程度工数で見積もれると思うが、後者が難しい ▪ クリック課金等、稼働時間と収益がある程度比例していれば簡単か
  24. 今後 • アラートがノイジーにならないようにする ◦ オオカミ少年化しないように注意する必要がある ◦ The Site Reliability Workbookで紹介されているバーンレートアラートが良さそう

    ▪ 短期のSLIがSLOを超過したときにアラートを上げるのではなく、Error Budgetの 消費速度によってアラートを上げるか判断するというもの ▪ 3日くらい持つようならTicket扱い(個人端末に発報しない) ◦ http://landing.google.com/sre/workbook/chapters/alerting-on-slos/
  25. 参考 • 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