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

#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

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

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

#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

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

#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

#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

#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

#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

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

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

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

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

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

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

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

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

#devio2023 「守り」の最適化 1

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

#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

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

#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

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

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

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

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

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

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

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

#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

#devio2023 リソース監視から「サービスレベル監視」へ 最近出版されたこちらの書籍が 超オススメです https://www.oreilly.co.jp/books/9784814400348/ 32

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

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

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

#devio2023 注意 3

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

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

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

#devio2023 まとめ 4

#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

#devio2023 参考 5

#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

#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

#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

No content