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

24 July 2023
渡辺聖剛＠クラスメソッド株式会社
　F U K U O K A L I V E V E R S I O N

View Slide

#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

View Slide

#devio2023
[PR]
会社説明会でも登壇します！
3

View Slide

#devio2023
みなさん、
監視してますか！？（挨拶

View Slide

#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

View Slide

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

View Slide

#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

View Slide

#devio2023
リソース数
● VM（e.g. EC2）
● コンテナ
コントロールプレーン
● FaaS関数（e.g. Lambda）
● データベース
● ストレージ
● キュー / キャッシュ
● ネットワークリソース
● 外部API
etc ...
8

View Slide

#devio2023
リソース数
● コンテナ
● ストレージ
● 外部API
etc ...
クラウドリソースのコスト効率
アラート (発報)
メール通知 / チャット通知(e.g. Slack) / 電話通知
エスカレーションパス（平⽇‧夜間‧休⽇）
影響範囲確認‧対応判断 / 暫定対応 / 恒久対応
緊急連絡フロー
インシデント管理 (Issue Tracking)
9

View Slide

#devio2023
リソース数
● コンテナ
● ストレージ
● 外部API
etc ...
https://booksbelow.wordpress.com/2010/05/31/on-writing-or-lack-of-it/
Webアクセスログで 4xx / 5xx
※画像はイメージです
10

View Slide

それ、本当に
守れてますか！？！？
https://booksbelow.wordpress.com/2010/05/31/on-writing-or-lack-of-it/ ※画像はイメージです

View Slide

#devio2023
「守りの監視」思考の落とし⽳その1
「全てを⾒張らなければ (監視しなければ) ならない...!」
➡ 監視対象の増加
その全てにアラートを設定する...?
➡ 通知に対する「緊張感」の減少（慣れ）
オオカミ少年問題
12

View Slide

#devio2023
「守りの監視」思考の落とし⽳その2
「何かあったら即通知(メール or 電話)‧即確認‧対応...！」
➡ メール⾒てみたら「すぐ対応しなくて良い」内容
でも無事を確認しないと安⼼出来ない...
➡ オンコール担当者の
燃え尽き症候群
13

View Slide

#devio2023
こわいのが：担当業務はオンコール対応だけ？
ひとり (or ⼩数) の担当者が
なんでもやる体制
● 開発（アプリ‧インフラ）
● 運⽤（アプリ‧インフラ）
● etc
➡ 最終的には
「運⽤でカバー」
➡ オンコール対応の疲れが
機能追加にまで影響...
https://en.wikipedia.org/wiki/Tree_swing_cartoon
https://medium.com/@thx2001r/the-project-cartoon-root-cause-5e82e404ec8a
14

View Slide

#devio2023
「んなこたぁ分かってるんだよ...!」
できることなら何とかしたい
でも、何とかしなくても何とかなる
(なっている(ように⾒える(そう⾔われる(そうしている(...)))))
なにより、
システムを
止めるわけには
いかない
（使命感
AWS re:Invent 2021 - Keynote with Dr. Werner Vogels - YouTube
https://www.youtube.com/watch?v=8_Xs8Ik0h1w
15

View Slide

#devio2023
どうしましょう？
「新しいツールを⼊れたら
解決する？
でも、
試している時間も無いし...」
https://www.ﬂickr.com/photos/thomasleuthard/8459043037/
16

View Slide

#devio2023
「攻め」に転じましょう（提案

View Slide

#devio2023
具体的には？
1「守り」の最適化
2「攻め」に転じる：その準備
18

View Slide

#devio2023
「守り」の最適化
1

View Slide

#devio2023
⽅針
● 即対応が必要なものだけにアラートを仕掛ける
● ⾃動的に(=⼈の⼿を介さずに)復旧させる
● 「MTTRTB」を短くする
20

View Slide

#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

View Slide

#devio2023
⾃動的に (=⼈の⼿を介さずに) 復旧させる
「いや、⾃動化できるところは
もうやってるんだよね」
...と思ってませんか？
https://www.oreilly.co.jp/books/9784873118642/
“アラートに対する代表的なアクションが、既知でかつ用意された
ドキュメントの手順に沿って対応するだけなら、コンピュータに
その手順をやらせない理由はありません。
自動復旧（auto-healing）はアラート疲れを避ける素晴らしい
方法です。システムが巨大なら、それは必須と言っても過言では
ありません（人を増やすのはお金がかかりますからね）。”
————Mike Julian「入門　監視」
22

View Slide

#devio2023
Automation
“⾼度に⾃動化された⼿段によって、ひとの介⼊を最⼩限に抑えつつ
⼿続き(プロセス)を操作または制御する技術‧⽅法‧システム”
❌ （スクリプトなどで）⾃動化すること
⭕ ⼿動で⾏う作業を最⼩化すること
https://www.dictionary.com/browse/automation
➢ the technique, method, or system of operating or controlling
a process by highly automatic means, as by electronic devices,
reducing human intervention to a minimum.
———— dictionary.com
23

View Slide

#devio2023
Automation (cont.)
Automation ≠ オートメーション
とかく「如何にコードで置き換えるか」のような議論になりがちですが...
「その⼿続きは本当に必要なのか？」
「もっと簡素化‧簡略化できるのでは？」
「コードを書かなくても⽅法はあるのでは？」
もっとも効果的な⽅法で「⼿作業を回避」することが重要です
24

View Slide

#devio2023
[PR]
この辺りのことは
先⽇別のイベントで
話した内容と重なるので
こちらも是⾮ご参照ください
https://dev.classmethod.jp/articles/202307-session-sdlc-refactoring-guide-devio2023/
25

View Slide

#devio2023
MTTRTB
“深夜に
オンコールアラートを受けてから
再びベッドの戻るまでの
平均時間”
必要最⼩の時間でベッドに戻れる
(= ⼀次対応を終えられる) ように
➡ドキュメント‧ランブックの整備
➡ 未知事象の調査時間の短縮
https://www.slideshare.net/abeer486/getting-started-with-site-reliability-engineering-sre-121573908
26

View Slide

#devio2023
可観測性 (オブザーバビリティ / Observability)
異常検知‧警報のためではない
「いまシステムがどうであるか」を
把握するための「計測 (Measurement)」
Metric / (Event)Log / Trace / ダッシュボード etc...
➡ そのためのもの！
27
“(オブザーバビリティは) システムがどのような状態に
なったとしても、それがどんなに斬新で奇妙なものであっても、
どれだけ (外部からの観測で) 理解し説明できるかを示す尺度です”
————Charity Majors、Liz Fong-Jones、George Miranda「オブザーバビリティ・エンジニアリング」

View Slide

#devio2023
ここまでのまとめ
● 即対応が必要なものだけにアラートを仕掛ける
○ その必要がないものまで「アラート」しない
● ⾃動的に (=⼈の⼿を介さずに) 復旧させる
○ Automation ≠ オートメーション
○ 復旧⼿順‧復旧機構そのものの⾒直しも
● MTTRTBを短くする
○ 対応時間そのものも短縮を狙おう
○ そのための可観測性 (オブザーバビリティ)
➡「守り」を最適化し、「攻め」るための余裕を作る
28

View Slide

#devio2023
「攻め」へ転じる：その準備
2

View Slide

だが
ここで全てを説明するには
時間が⾜りない

View Slide

#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

View Slide

#devio2023
リソース監視から「サービスレベル監視」へ
最近出版されたこちらの書籍が
超オススメです
32

View Slide

#devio2023
ひとことだけ
CUJに基づくSLI/SLOと
そこから導かれるエラー予算は
サービスを進化させるための
「攻め」の数字です！
https://commons.wikimedia.org/wiki/File:LARP.jpg
33

View Slide

#devio2023
SaaS‧マネージドサービスの積極採⽤を
● OOTB (Out-of-the-box) で
すぐ使える
○ ドキュメントも揃っている
● インフラも運⽤も込み
○ メンテナンスや障害対応に
⼯数を割かなくて良い
● ツール側で勝⼿に進化
○ 意図しない進化のリスクも
● 「継続的な⾒直し」がしやすい
○ 利⽤契約 (OpEx) がほとんど
買い切り (CapEx) ではない
34

View Slide

#devio2023
SaaS‧マネージドサービスの強み
https://forge-vtt.com/features
“SaaS を使えば数分で動く仕組みが
手に入り、しかも始めたタイミングから
ドキュメントなども手に入ります。”
—— Mike Julian 「入門　監視」
35
それらも計算にいれた上で
評価‧判断を！

View Slide

#devio2023
注意
3

View Slide

#devio2023
「監視」は相変わらず重要
「こうなったらダメ、アウト」
それが予め
分かっているところには
積極的に
アラートを仕掛けましょう！
37
https://dev.classmethod.jp/articles/202012-report-reinvent-keynote-observability/
“Monitoring means that
you already know what is important.”
(何が重要でどうなったら異常なのか、
既に分かっている場合に監視は有効だ)
—— Dr. Werner Vogels.

View Slide

#devio2023
さらに：リソース監視も別途重要
● 余剰リソース
➡ コストを押し上げる⼀番の原因
● 定期更新が必要なリソースの対応もれ
➡ 障害に直結
● もちろん、発⽣した障害の調査のためにも必要
即対応のためではなく
根本原因対応やサービス運⽤計画のために
https://www.docswell.com/s/integrated1453/Z6YJ7M-aws-cost-optimization-by-newrelic
38

View Slide

#devio2023
最後に：攻め急いではいけない (変化はゆっくりと)
いきなり始めても、誰も付いてこない (これない)
● 使われていなかった部分から少しずつ、無理なく減らす
● 強化する部分を少しずつ増やす
● 誰もが⾒たがるダッシュボードを作って⾒せびらかす (啓蒙)
➡ 「同じ釜の飯を⾷う」仲間を増やす
● 既存の体制‧やり⽅と連続性をもって
上意下達はギャンブル（押しつけツールへ反発される危険）
⼩さく始めて、
関係者全員を
巻き込むのが⼤事！
39

View Slide

#devio2023
まとめ
4

View Slide

#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

View Slide

#devio2023
参考
5

View Slide

#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

View Slide

#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

View Slide

#devio2023
参考 (書籍)
❏ オブザーバビリティ‧エンジニアリング
❏ SRE サイトリライアビリティエンジニアリング
❏ サイトリライアビリティワークブック
❏ SREの探求
❏ SLO サービスレベル⽬標
45

View Slide

View Slide

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

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

Seigo Watanabe

More Decks by Seigo Watanabe

Featured

Transcript