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

守りの監視から攻めの監視へシフトしよう #devio2023

Seigo Watanabe
July 24, 2023
950

守りの監視から攻めの監視へシフトしよう #devio2023

Seigo Watanabe

July 24, 2023
Tweet

More Decks by Seigo Watanabe

Transcript

  1. #devio2023 ⾃⼰紹介 ▸ クラスメソッド株式会社 アライアンス事業部 エンジニアG ◦ DevOpsソリューション ◦ Google

    Cloud ▸ 出⾝:⻑崎 ▸ 好きなAWSサービス : ACM‧Route 53‧ CloudWatch Metric Stream ▸ 好きなGoogle Cloudサービス : Compute Engine Live Migration 2 渡辺聖剛 (Seigo Watanabe) https://dev.classmethod.jp/author/watanabe-seigo/ https://www.credly.com/users/seigo-watanabe.29d196c2 https://www.credential.net/profile/seigowatanabe992008/wallet
  2. #devio2023 監視(システム監視) https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html 対処 Respond / Resolve 検知 Detect 計測

    Measurement システムを常時観測‧計測し 異常が検知されたら それに対して対処する “監視とは 情報収集を行った結果に応じて 適切な宛先に発報すること” ———— IPA 非機能要求グレード 2018 04_項目一覧 C.1.3.1「運用監視」 5
  3. #devio2023 つまり:監視とは システムを 可能な限り 正常 に 稼動 させ 続けるためのもの システム上で展開している

    サービスの「守り」 • 死活監視 / エラー監視 • リソース監視 / コスト監視 • 性能監視 File:Dubrovnik sa Križa.JPG - Wikimedia Commons https://commons.wikimedia.org/wiki/File:Dubrovnik_sa_Kri%C5%BEa.JPG 6
  4. #devio2023 つまり:監視とは (cont.) システムを 可能な限り 正常 に 稼動 させ 続けるためのもの

    システム上で展開している サービスの「守り」 • 死活監視 / エラー監視 • リソース監視 / コスト監視 • 性能監視 File:Dubrovnik sa Križa.JPG - Wikimedia Commons https://commons.wikimedia.org/wiki/File:Dubrovnik_sa_Kri%C5%BEa.JPG あらゆるIPアドレスに対してPing監視 あらゆるTCP/UDPポートに対してOpen監視 あらゆるプロセスに対して起動監視 全てのサーバ上でメトリック監視 CPU利⽤率 / メモリ利⽤率 / ロードアベレージ ディスク利⽤率 / ディスクI/O / ライセンス期限 様々なログに対してキーワード監視 ERROR / WARN / FATAL / CRITICAL / LIMIT / Down... HTTPレスポンスコード 4xx / 5xx Dead Letter Queue数 クラウドリソースの従量課⾦ 応答(レスポンス)性能 / スループット キュー待ち⾏列 / 単位時間当たりの処理数 7
  5. #devio2023 つまり:監視とは (cont.) リソース数 • VM(e.g. EC2) • コンテナ コントロールプレーン

    • FaaS関数(e.g. Lambda) • データベース • ストレージ • キュー / キャッシュ • ネットワークリソース • 外部API etc ... あらゆるIPアドレスに対してPing監視 あらゆるTCP/UDPポートに対してOpen監視 あらゆるプロセスに対して起動監視 全てのサーバ上でメトリック監視 CPU利⽤率 / メモリ利⽤率 / ロードアベレージ ディスク利⽤率 / ディスクI/O / ライセンス期限 様々なログに対してキーワード監視 ERROR / WARN / FATAL / CRITICAL / LIMIT / Down... HTTPレスポンスコード 4xx / 5xx Dead Letter Queue数 クラウドリソースの従量課⾦ 応答(レスポンス)性能 / スループット キュー待ち⾏列 / 単位時間当たりの処理数 8
  6. #devio2023 つまり:監視とは (cont.) リソース数 • VM(e.g. EC2) • コンテナ コントロールプレーン

    • FaaS関数(e.g. Lambda) • データベース • ストレージ • キュー / キャッシュ • ネットワークリソース • 外部API etc ... あらゆるIPアドレスに対してPing監視 あらゆるTCP/UDPポートに対してOpen監視 あらゆるプロセスに対して起動監視 全てのサーバ上でメトリック監視 CPU利⽤率 / メモリ利⽤率 / ロードアベレージ ディスク利⽤率 / ディスクI/O / ライセンス期限 様々なログに対してキーワード監視 ERROR / WARN / FATAL / CRITICAL / LIMIT / Down... HTTPレスポンスコード 4xx / 5xx Dead Letter Queue数 クラウドリソースのコスト効率 応答(レスポンス)性能 / スループット キュー待ち⾏列 / 単位時間当たりの処理数 アラート (発報) メール通知 / チャット通知(e.g. Slack) / 電話通知 エスカレーションパス(平⽇‧夜間‧休⽇) 影響範囲確認‧対応判断 / 暫定対応 / 恒久対応 緊急連絡フロー インシデント管理 (Issue Tracking) 9
  7. #devio2023 つまり:監視とは (cont.) リソース数 • VM(e.g. EC2) • コンテナ コントロールプレーン

    • FaaS関数(e.g. Lambda) • データベース • ストレージ • キュー / キャッシュ • ネットワークリソース • 外部API etc ... https://booksbelow.wordpress.com/2010/05/31/on-writing-or-lack-of-it/ あらゆるIPアドレスに対してPing監視 あらゆるTCP/UDPポートに対してOpen監視 あらゆるプロセスに対して起動監視 全てのサーバ上でメトリック監視 CPU利⽤率 / メモリ利⽤率 / ロードアベレージ ディスク利⽤率 / ディスクI/O / ライセンス期限 様々なログに対してキーワード監視 ERROR / WARN / FATAL / CRITICAL / LIMIT / Down... Webアクセスログで 4xx / 5xx Dead Letter Queue数 クラウドリソースの従量課⾦ 応答(レスポンス)性能 / スループット キュー待ち⾏列 / 単位時間当たりの処理数 ※画像はイメージです 10
  8. #devio2023 こわいのが:担当業務はオンコール対応だけ? ひとり (or ⼩数) の担当者が なんでもやる体制 • 開発(アプリ‧インフラ) •

    運⽤(アプリ‧インフラ) • etc ➡ 最終的には 「運⽤でカバー」 ➡ オンコール対応の疲れが 機能追加にまで影響... https://en.wikipedia.org/wiki/Tree_swing_cartoon https://medium.com/@thx2001r/the-project-cartoon-root-cause-5e82e404ec8a 14
  9. #devio2023 即対応が必要なものだけにアラートを ⼀⾒ Midium や Low にみえても 予防措置が即時必要なら それは High

    です (でも、本当に必要なのですか?) https://response.pagerduty.com/oncall/alerting_principles/ https://ueokande.github.io/incident-response-docs-ja/oncall/alerting_principles/ (邦訳版) “Anything that wakes up a human in the middle of the night should be immediately human actionable.” (深夜に人を叩き起こすものは、 すぐに人が対応できるものであるべきです) ———— Alerting Principles - PagerDuty Incident Response Documentation 21
  10. #devio2023 ⾃動的に (=⼈の⼿を介さずに) 復旧させる 「いや、⾃動化できるところは  もうやってるんだよね」 ...と思ってませんか? https://www.oreilly.co.jp/books/9784873118642/ “アラートに対する代表的なアクションが、既知でかつ用意された ドキュメントの手順に沿って対応するだけなら、コンピュータに

    その手順をやらせない理由はありません。 自動復旧(auto-healing)はアラート疲れを避ける素晴らしい 方法です。システムが巨大なら、それは必須と言っても過言では ありません(人を増やすのはお金がかかりますからね)。” ————Mike Julian「入門 監視」 22
  11. #devio2023 MTTRTB “深夜に オンコールアラートを受けてから 再びベッドの戻るまでの 平均時間” 必要最⼩の時間でベッドに戻れる (= ⼀次対応を終えられる) ように

    ➡ドキュメント‧ランブックの整備 ➡ 未知事象の調査時間の短縮 https://www.slideshare.net/abeer486/getting-started-with-site-reliability-engineering-sre-121573908 26
  12. #devio2023 可観測性 (オブザーバビリティ / Observability) 異常検知‧警報のためではない 「いまシステムがどうであるか」を 把握するための「計測 (Measurement)」 Metric

    / (Event)Log / Trace / ダッシュボード etc... ➡ そのためのもの! https://www.oreilly.co.jp/books/9784814400126/ 27 “(オブザーバビリティは) システムがどのような状態に なったとしても、それがどんなに斬新で奇妙なものであっても、 どれだけ (外部からの観測で) 理解し説明できるかを示す尺度です” ————Charity Majors、Liz Fong-Jones、George Miranda「オブザーバビリティ・エンジニアリング」
  13. #devio2023 ここまでのまとめ • 即対応が必要なものだけにアラートを仕掛ける ◦ その必要がないものまで「アラート」しない • ⾃動的に (=⼈の⼿を介さずに) 復旧させる

    ◦ Automation ≠ オートメーション ◦ 復旧⼿順‧復旧機構そのものの⾒直しも • MTTRTBを短くする ◦ 対応時間そのものも短縮を狙おう ◦ そのための可観測性 (オブザーバビリティ) ➡「守り」を最適化し、「攻め」るための余裕を作る 28
  14. #devio2023 なのでキーワードだけ • リソース監視から「サービスレベル監視」へ ◦ CUJ (Critical User Journey) ◦

    SLI (サービスレベル指標) / SLO (同⽬標) ◦ エラー予算(バジェット) ◦ SRE(≠ インフラエンジニア2.0) • ⼿のかからない (= 必要以上にトイルを⽣まない) ツールの選択 ◦ マネージドサービス ◦ SaaS https://cloud.google.com/blog/ja/products/devops-sre/how-to-design-good-slos-according-to-google-sres 31
  15. #devio2023 SaaS‧マネージドサービスの積極採⽤を • OOTB (Out-of-the-box) で すぐ使える ◦ ドキュメントも揃っている •

    インフラも運⽤も込み ◦ メンテナンスや障害対応に ⼯数を割かなくて良い • ツール側で勝⼿に進化 ◦ 意図しない進化のリスクも • 「継続的な⾒直し」がしやすい ◦ 利⽤契約 (OpEx) がほとんど 買い切り (CapEx) ではない 34
  16. #devio2023 さらに:リソース監視も別途重要 • 余剰リソース ➡ コストを押し上げる⼀番の原因 • 定期更新が必要なリソースの対応もれ ➡ 障害に直結

    • もちろん、発⽣した障害の調査のためにも必要 即対応のためではなく 根本原因対応やサービス運⽤計画のために https://www.docswell.com/s/integrated1453/Z6YJ7M-aws-cost-optimization-by-newrelic 38
  17. #devio2023 最後に:攻め急いではいけない (変化はゆっくりと) いきなり始めても、誰も付いてこない (これない) • 使われていなかった部分から少しずつ、無理なく減らす • 強化する部分を少しずつ増やす •

    誰もが⾒たがるダッシュボードを作って⾒せびらかす (啓蒙) ➡ 「同じ釜の飯を⾷う」仲間を増やす • 既存の体制‧やり⽅と連続性をもって 上意下達はギャンブル(押しつけツールへ反発される危険) ⼩さく始めて、 関係者全員を 巻き込むのが⼤事! 39
  18. #devio2023 成功させるには “短距離⾛ではなく、マラソンである” “Remember: it's a marathon, not a sprint”

    41 https://cloud.google.com/blog/ja/products/gcp/sre-success-starts-with-getting-leadership-on-board
  19. #devio2023 参考 (1) ❏ Alerting Principles - PagerDuty Incident Response

    Documentation https://response.pagerduty.com/oncall/alerting_principles/ ❏ PagerDuty Incident Responseの邦訳版を公開しました https://i-beam.org/2020/09/22/pagerduty-incident-response/ ❏ SREチームがNew Relicを使って AWSコスト最適化に貢献した話 https://www.docswell.com/s/integrated1453/Z6YJ7M-aws-cost-optimization-by-newrelic ❏ システム構築の上流⼯程強化(⾮機能要求グレード)紹介ページ | アーカイブ | IPA 独⽴⾏政法⼈ 情報処理推進機構 https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html ❏ オペレーション、監視(Monitoring)、可観測性(Observability)… AmazonのCTOはAWS re:Invent 2020のキーノー トでどう語ったか? キーワードを拾ってみた #reinvent | DevelopersIO https://dev.classmethod.jp/articles/202012-report-reinvent-keynote-observability/ ❏ SRE を成功させるには、まず計画を⽴てることが⼤事 | Google Cloud 公式ブログ https://cloud.google.com/blog/ja/products/gcp/sre-success-starts-with-getting-leadership-on-board ❏ [資料公開] DevOpsとSREのために知るべき3つの原則 〜忙しすぎるエンジニアのための開発環境リファクタリングガ イド〜 #devio2023 | DevelopersIO https://dev.classmethod.jp/articles/202307-session-sdlc-refactoring-guide-devio2023/ 43
  20. #devio2023 参考 (2) ❏ CALMS フレームワーク | Atlassian https://www.atlassian.com/ja/devops/frameworks/calms-framework ❏

    DevOps Culture (Part 1) - IT Revolution https://itrevolution.com/articles/devops-culture-part-1/ ❏ DevOps の原則 | Atlassian https://www.atlassian.com/ja/devops/what-is-devops ❏ DevOps ⽂化 | Atlassian https://www.atlassian.com/ja/devops/what-is-devops/devops-culture ❏ Google Cloud で実⾏されている DevOps 組織の有効性を評価する | Google Cloud 公式ブログ https://cloud.google.com/blog/ja/products/gcp/another-way-to-gauge-your-devops-performance-accordin g-to-dora ❏ OPEX(オペックス)とは? 意味やCAPEX(キャペックス)との違いを解説 | クラウドERP実践ポータル https://www.clouderp.jp/blog/what-is-capex-opex ❏ Platform Engineeringへの招待 - Speaker Deck https://speakerdeck.com/jacopen/platform-engineeringhenozhao-dai?slide=8 44
  21. #devio2023 参考 (書籍) ❏ オブザーバビリティ‧エンジニアリング https://www.oreilly.co.jp/books/9784814400126/ ❏ SRE サイトリライアビリティエンジニアリング https://www.oreilly.co.jp/books/9784873117911/

    ❏ サイトリライアビリティワークブック https://www.oreilly.co.jp/books/9784873119137/ ❏ SREの探求 https://www.oreilly.co.jp/books/9784873119618/ ❏ SLO サービスレベル⽬標 https://www.oreilly.co.jp/books/9784814400348/ 45