監視・ログ分析を最初から始めるイマドキの事情と理由・その1（混乱編）

https://dev.classmethod.jp/articles/202007-devio2020-monitoring-1-2
https://www.youtube.com/watch?v=OspNL5jYpio

Transcript

1. 後回しに しない ❗ 1 監視･ログ分析を最初から始める イマドキの事情と理由・その 〜 俯 瞰 混 乱 編 〜 渡辺聖剛 ソリューションアーキテクト AWS事業本部 パートナーアライアンス部 2020.07.03
2. 2 監視回　その1 https://dev.classmethod.jp/news/developers-io-2020/ イマココ
3. 3 Agenda
4. 4 Agenda まえおき - 前提となる話 50:50 - SREの話 SかMか - 監視の話 3-4-3 - 可観測性（o11y）の話 それから? →以下、その2へ続く
5. 5 本日のゴール
6. 6 本日のゴール Modern Application Development 急にモダンなアプリケーションをデベロップメントする ことになっても、 「え、監視とかどうすれば・・？」 と悩まずにすむようになること https://www.irasutoya.com/2015/12/blog-post_51.html
7. 7 免責事項 時間が限られているので すごくざっくりした話しかしません 流れをつかんでもらうのが目的です
8. 8 免責事項　その2 時間が限られているので スライドに書いてあること全てを話しません 興味がわいたらあとから読んで頂けますと！
9. 9 自己紹介 渡辺聖剛 ( Seigo Watanabe ) • クラスメソッド株式会社 AWS 事業本部 パートナーアライアンス部 • 前職までは 所謂インフラエンジニア • 運用・監視(Monitoring) • 好きな AWS サービス ◦ ACM, Route 53 ◦ AWS Systems Manager https://dev.classmethod.jp/author/watanabe-seigo/
10. 10 ※未承諾広告 モニタリングまわりの記事を担当 AWSにかなり限定した内容に なってます 重複するところは多いですが、 本ではかけなかった話 ＋アップデートを話します https://gihyo.jp/book/2020/978-4-297-11329-2
11. 11 本題
12. 12 モダンな監視を語る上で外せない 前提となる話
13. 13 前提となる話 • アーキテクチャとコンピュート能力 • ビジネス要件と開発・運用体制 これらの変化について
14. 14 アーキテクチャとコンピュート能力 モノリシックからマイクロサービスへ - Container, k8s, FaaS ... コンピュート性能の爆発的向上 - 計算・I/O性能、ストレージコストは低減 - 超高速ネットワーク - 仮想化技術などの技術革新 Software Defined X (SDx) - X = Network, Infrastructure ... - 従来ハードウェアだったものがソフトウェアで 置き換えられていく
15. 15 ビジネス要件と開発・運用体制 より早いサイクルでのサービス向上が求められる 開発・運用体制 - ウォーターフォールからDevOps - DevOpsからSRE https://pixnio.com/ja/media/ja-2227252 https://www.irasutoya.com/2016/07/blog-post_807.html
16. 16 つまり現在は… 扱う対象は複雑化し数も膨大になり 速度と変化と信頼性のバランスが 求められる世の中 https://commons.wikimedia.org/wiki/File:Rubik's_cube_almost_solved.svg https://www.pexels.com/photo/cargo-container-lot-906494/ https://ja.wikipedia.org/wiki/DevOps https://www.irasutoya.com/2014/10/blog-post_89.html
17. 17 SREの話 50:50
18. 18 監視なのになぜSRE？ いまの世の中避けて通れない SREの文脈を抑えておくことで ベストプラクティスが見えてくるから
19. 19 SREってなんぞ Site Reliability Engineering（または 〜Engineer） 技術であり、そのためのエンジニアロール SREの目的は「信頼性の向上」 - 変化し続けるサイト（システム）を前提に、 そのサイトで安定的に「サービスを提供すること」 - サイトを「安定稼働させること」ではない ちゃんと動いているかどうかを知ることが必要 従来との違い → SREは攻めの運用
20. 20 GoogleにおけるSRE ”SREは、これまで運用チームが行ってきたことをソフ トウェアの専門性を持つエンジニアが行い、エンジニア が人手による管理を自動化するソフトウェアを設計し実 装する能力を持ち、それをいとわないということから成 り立っています“ - “SRE サイトリライアビリティエンジニアリング” https://www.oreilly.co.jp/books/9784873117911/
21. 21 GoogleにおけるSRE(cont.) • 仕事の半分はコードを書くこと ◦ 自動化、Infrastructure as Code ◦ 必要なメトリックを収集する仕組みの組み込み ◦ プルリク ◦ その他「信頼性をあげる」ために必要なこと • 残りの半分で、 チケット、オンコール、手作業といった運用業務 観念ではなく、明確に工数を分ける
22. 22 つまりSREとは コードを書くことがSREの仕事（の半分） SREは運用業務を自動化で減らし、サイトの信頼性を 上げつつ、コードを書く時間を捻出する必要がある “You Build It, You Run It.” - Werner Vogels, Amazon CTO - とってもDevOps https://dl.acm.org/doi/pdf/10.1145/1142055.1142065
23. CALMS - DevOpsの哲学のキーポイント - Culture - Automation - Lean - Measurement - Sharing DevOpsにとってMeasurementは 重視されるべきもの 23 DevOpsの文化 https://www.oreilly.co.jp/books/9784873119137/
24. SREがサイトの「信頼性」を維持するためには、 何が起こっているかを監視しなくてはならない → SREの文脈に沿って「監視」を行うことが 　いまのベストプラクティス 24 つまり
25. 25 「監視」の話 S or M
26. 26 そもそも「監視」とは？ システムを常時観測・計測し 異常が検知できたら それに対して対処する 対処 Respond / Resolve 検知 Detect 計測 Measurement https://www.irasutoya.com/
27. 27 監視と言えば　入門「監視」 発行：2019.01 一大監視ブームを巻き起こした うなずくことが多い一方で、 読んでいてどこか違和感がある 文句なしの良書ではあるけど、 ぼくの知ってる監視とは何か違う… https://www.oreilly.co.jp/books/9784873118642/
28. 28 Q あなたの監視は「S」ですか？ それとも「M」ですか？
29. 29 再掲：監視とは システムを常時観測・計測し 異常が検知できたら それに対して対処する 対処 Respond / Resolve 検知 Detect 計測 Measurement
30. 30 あなたの監視はSかMか？ 検知を重視 = 「問題が起こらないこと」 = S（Surveillance）な監視 対処 Respond / Resolve 検知 Detect 計測 Measurement
31. 31 あなたの監視はSかMか？ 計測を重視 = 「何が起こっているのか」 = M（Monitoring）な監視 注：監視のSとかMとか言ってるのは独自研究です 対処 Respond / Resolve 検知 Detect 計測 Measurement
32. 32 辞書的な定義 monitorもsurveillanceもobserveもsuperviseも、 日本語にするとみんな「監視」になる 一方で、日本語の「監視」には「S」な意味合いが強い • 監視カメラ : Video surveillance, CCTV • 監視社会 : surveillance society, watchdog society • PCモニタのことを「監視装置」とは訳さない https://pixnio.com/ja/ https://flic.kr/p/3iapit
33. 33 トラディショナルな監視の定義 Nagiosまではそんなに違和感なかった • チェック監視 = Nagios リソース監視 = Cacti • Zabbixは両方できる ◦ 当時はそれが画期的でもあった ◦ そのあたりから混乱が始まってる感 （個人の感想です） 可観測性までくると違いが際立ってくる https://commons.wikimedia.org/
34. 34 Sな監視「も」必要であり適切 「ちゃんと作ればちゃんと出来る」時には有効 ◦ 建築や製造業など ◦ 守ること・事故を起こさないことそのものが目的 ◦ 単純な閾値チェック 本来の「サーベイランス」はそうであるべき ◦ 収監、検疫など ◦ 単純化による判断・対処の迅速化 ◦ 命に関わるものはそれが最優先 https://pixnio.com/ja/
35. 35 一方で、 • ソフトウェアでは「ちゃんと作る」と時間がかかる • 不具合のないソフトウェアを作ることはもはやムリ • 仮に「ちゃんと出来」たとしても、 あっという間に古くなる • 検知にだけ注目すると、単純な閾値チェックで 事足りる -> コンテキストが失われる 複雑化したモダンアプリにおいて、 「S」な監視を行っていては追いつかない https://torange.biz/jp/fx/background-modular-modern-blue-abstract-arrows-creative-215352
36. 36 monitorの意味 “to watch and check something over a period of time in order to see how it develops, so that you can make any necessary changes.” - Oxford Learner's Dictionary 「必要な変更を加えることが出来るように、ある期間に わたって、それがどのようにして発展したかを把握する 目的で、見て、そしてチェックすること」 https://www.oxfordlearnersdictionaries.com/definition/english/monitor_1?q=monitor
37. 37 つまり：M（Monitoring）な監視では 計測結果が対処とワンセットに ◦ 「まず世に出してから修正する」には こっちがハマる “Done is better than perfect” ◦ Mark Elliot Zuckerberg, CEO of Facebook, Inc. ◦ 「完全なものなどないという前提のもと、完全に近づく ために細かな継続的改善・反復が重要だ」ということ ◦ 現状の把握（Monitoring）なしでは為しえない https://medium.com/@amachino/done-is-better-than-perfect-%E3%81%AE%E6%84%8F%E5%91%B3-dc2c74069ece https://commons.wikimedia.org/wiki/File:Mark_Zuckerberg_F8_2018_Keynote.jpg
38. 38 古典「推測するな、計測せよ」 Notes on Programming in C “ルール1: （略）どこがボトルネックなのかをはっきり させるまでは、推測を行ったり、スピードハックをして はならない” “ルール2: 計測すべし。計測するまでは速度のための調 整をしてはならない。（後略）” - Robert "Rob" C. Pike https://ja.wikipedia.org/wiki/UNIX%E5%93%B2%E5%AD%A6 http://www.lysator.liu.se/c/pikestyle.html
39. 39 入門「監視」による言及 “そう言った人たちは、何か問題がおきた時にアラートを 出すことが監視システムの目的だと信じているのです。 （中略）監視にはもっと高い目的があります。 「監視は、質問を投げかけるためにある。」” “監視とはアラートを出すために存在しているのでは ありません。アラートは結果の1つの形でしかないのです” 邦題：入門「監視」 原題：Practical Monitoring https://www.oreilly.com/library/view/practical-monitoring/9781491957349/
40. 40 つまり：今どきの監視とは アラートのためではない、 よい運用を行うための情報収集(monitoring) • パフォーマンスチューニング • トラブルシューティング →次の開発サイクル（Iteration）のため https://www.flickr.com/photos/fcrippa/7967994338/
41. 41 収集してどうする？ 人間が受け取る：手動で対処 ◦ Devがうけとる：コードの修正 ◦ Opsがうけとる：メンテナンス、リソースマネジメント 機械が受け取る：自動処理のトリガー ◦ AutoScaling ◦ AutoRecovery ◦ Failover ◦ Retry
42. 42 ここまでのまとめ 変化にあわせて意識もかえよう SREが必要としているのはM
43. 43 可観測性 Observability (o11y) 3-4-3
44. 44 じゃあ具体的に何をモニタリングしましょう おさらい： SREの目的は「信頼性の向上」 信頼性（Reliability）とは？
45. 45 Failure mode, SLI, SLO ENT308-S - Build your next microservices application with modern AWS services https://youtu.be/msxD0bTFu2A?t=2505 https://dev.classmethod.jp/articles/201912-report-reinvent-2019-ent308/
46. 46 Failure mode, SLI, SLO (cont.) failure mode SLI SLO SLA 何をもって 故障とするか それの重要度 (RRN)はどの くらいか 何を使ったら それが測れる か それが具体的 にどんなとき に「正常」と するのか それをどう 顧客と約束す るか・しない か（見せるか 見せないか） 例) サイトの 表示が遅い 表示速度の p95 99%が 7秒以下 99.99% https://youtu.be/msxD0bTFu2A?t=2505 https://dev.classmethod.jp/articles/201912-report-reinvent-2019-ent308/
47. 47 つまり まず「異常（信頼性が損なわれた状態）」を定義 SLI = 定めた「異常」を計る上でキーとなる指標 SLO = そのSLIに対して、どうである時を正常あるいは 異常(故障)と判断するかを定義したもの “SREの日々のタスクやプロジェクトは、 SLOによって駆動されます” - サイトリライアビリティワークブック
48. 48 つまり 正常な判断のためには、SLI/SLOにつながる監視を • なんでもかんでも見る必要はない • 見る意味のあるデータについてだけ観れば良い 一方で、 「見る意味があるものは何か？」を知る必要がある ◦ 本と検索エンジンの話に似ている
49. 49 基本方針：全体を見ましょう 全体をみて方針を決め ドリルダウンして対処する その材料としてデータの収集を ※その2で詳しく話します https://www.pexels.com/photo/cargo-container-lot-906494/
50. 50 着目点 3 Pillars 4 Golden Signals 3 Dimensions
51. 51 The Three Pillars of Observability Metrics（数値、低コンテキスト） Event Logs（含メタデータ、高コンテキスト） Tracing（事象の関連性・分散トレーシング） - Distributed Systems Observability https://www.oreilly.com/library/view/distributed-systems-observability/9781492033431/ch04.html
52. 52 The Four Golden Signals Latency (パフォーマンス・遅延) Traffic (トラフィック量) Errors (エラー発生率) Saturation (利用率、キャパシティ) - SREサイトリライアビリティエンジニアリング https://landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems/
53. 53 Three dimensions Functionally (その機能が正しく動いているか) Availability (その機能が使えるか) Speed (遅くないか) - Best Practices for Monitoring E-Commerce Performance https://newrelic.com/resources/tutorials/best-practices-for-monitoring-ecommerce-performance
54. 54 雑な関連 Metric 数値 Event Log 高コンテキスト Trace 関連性 Latency 遅延 Traffic 流量 Errors エラー Saturation キャパシティ Functionally 機能の正常性 Availability 可用性 Speed 速度・性能 何を取得するか シグナル 観点 ※線がないから取れない・関係がない、というわけではありません 遅すぎる⇔使えない 情報量の違い
55. 55 SRE的な観点 • 「エラーバジェット」という考え方 • MTTR
56. 56 「エラーバジェット」という考え方 サイトリライアビリティを語る上で欠かせない概念 エラーバジェットを使って何をするか？ • ひとつの考え方 ◦ 「試験は通ったが本番で動かない」ケース ◦ どうせなら、本番稼働で検知して即対応できたほうが 良いのでは？ ▪ →誰よりも早く運営チームが気付く必要性 • もうひとつの考え方 ◦ エラーバジェットが許す範囲で復旧できたらいい
57. 57 MTTRも気にしよう Mean Time To Repair = 復旧までの最小平均時間 Mean Time To Resolution = 解決までの最小平均時間 SLO 99.9% = 毎月30〜40分止まっても許される？ ◦ 「1回の停止は5分以内」のような定義も必要 ◦ SLOを日単位、時間単位でも設定する ▪ 99.9%/day = 8.64sec.
58. 58 ここまでのまとめ • SREはSLOによって駆動される • SLOを求めるには計測(監視)しかない • ここでいう監視はMのこと
59. 59 可観測性 = 広義の「可視化」その性能 見えなかったものを見えるようにする - つながり・連続性の可視化 = (分散)トレース - 数値表現から図示・グラフ化 = ダッシュボード 可観測性（Observability） = そのシステムがそなえている性質・性能 - Availability, Capability, Scalability ...
60. 60 何に着目するか 3-4-3（前述） Metric Event Log Trace Latency Traffic Errors Saturation Functionally Availability Speed
61. 61 何に着目するか（cont.） 3-4-3（前述） Metric Event Log Trace Latency Traffic Errors Saturation Functionally Availability Speed
62. 62 「性能は機能」 つまるところ「速いは正義」 • 使えない = ユーザーから見たら「無限に遅い（帰ってこない）」 = タイムアウト • 応答時間と離脱率には相関がある レスポンスタイムを上げることが業績に繋がる
63. 63 「監視エージェント入れたら性能下がりました^^」 よく聞く話ですが。。。 例） - エージェントいれたらCPU負荷が10%増えた - PageSpeed Insightsのスコアが20下がった ※あとでお話しします
64. 64 ログの話
65. 65 そもそも「ログ」とは トラディショナルなイメージ • 取りあえず出力されるもの • /var/log/ほげほげ • ほっとくとディスクを食い潰す • たまにエラーが吐かれてて気をつけなきゃならない • デバッグログが大量に出ているが放置 https://help.sumologic.com/01Start-Here/Quick-Start-Tutorials/Set-Up-Sumo-Logic-Tutorial
66. 66 可観測性では 「コンテキスト豊かな監視データ」と捉える - 高コンテキスト = 情報量が多い、事象の背景 - 正規化・非正規化どちらもある - 正規化ログ = JSON（Stack Traceなど） - 非正規化ログ = テキスト1行（Apacheなど）
67. 67 Event Log（Events）？ • メタデータが正規化されたログ、 あるいはコンテキスト豊富なメトリック • 一方で、メトリックにメタデータを付与するような 動きもあり ◦ Prometheus, OpenMetrics（後述） • 境界がグレーになってきている ◦ メトリックとイベントの境、イベントとログの境 ◦ 厳密なものではなく、感覚で捉えていいと思う
68. 68 ログをどう使う？ 2つの方向性（従来から大きくは変わっていない） • ログからキーワードをひろう • イベント発生時にどんなログが出ていたかを掘り起 こせるように収集する 死活監視・リソース監視と考え方は同じ トレースログなどはログとして扱うのではなく、 分散トレース（APM）で扱う
69. 69 具体的には ツールにため込んで可視化 保存 重要度別に通知・アラート
70. 70 ログの可視化 コンテキストが多い = ぱっとみよく分からん 有望有効な情報が埋もれているかもしれない →もったいない 可視化・有益なデータを掘り起こす そのための分析ツール ※その2で詳しく
71. 71 長期保存と中・短期保存 長期 = アーカイブ、記録や監査のため ◦ 日単位、数年単位 ◦ 何かあったときに掘り起こせれば良い 中期 = 傾向の把握（短期との比較） ◦ 時間単位、数日〜1週間〜数ヶ月、13ヶ月 ◦ シーズナルな影響をどうみる？ 短期 = 「いま」何が起きているか ◦ 分単位、〜数日 ◦ 時代は準リアルタイム（秒単位）へ
72. 72 重要度 Lambdaのログレベル方針について、チームで話して明 文化してみた | Developers.IO https://dev.classmethod.jp/articles/lambda-log-level/
73. 73 So, since when? (で、いつから？)
74. 74 前提：監視とは “監視とは継続的なテストである” - 監視とは継続的なテストである、という話 (もしくは cronlog とテストスクリプトを組み合わせた監視手法につい て) - https://planet.mysql.com/entry/?id=23085 “監視とは、あるシステムやそのシステムのコンポーネ ントの振る舞いや出力を観察しチェックし続ける行為で ある。” - 入門「監視」
75. 75 いつから取り始めればよい？ “世界中のディベロッパーの42%以上が、 開発ライフサイクルにおけるテストのタイミングが 遅すぎると回答” - DevSecOpsに関するグローバルアニュアル調査の 結果を発表：ソフトウェア開発チームの役割の 変化が明らかに｜GitLab Inc.のプレスリリース https://prtimes.jp/main/html/rd/p/000000003.000056974.html
76. 76 いつから取り始めればよい？(cont.) (再掲)正常な判断のためには、なんでもかんでもデー タを見る必要はない、見る意味のあるデータについてだ け観れば良い • そのためには、「見る意味があるものは何か？」を 知る必要がある ◦ 大量のデータをみておく必要性
77. 77 いつから取り始めればよい？(cont.) 予め「取れるだけとっておく」ことが大切 ◦ あとから「あれを見ておけばよかった」となった時のこ とを考えておく ◦ 観測コストも保存コストも、年々安くなっている ◦ ※法的な保存期間についての議論はまた別の話 それが判断できるのはいつか？本番稼働後でいい？ ◦ 開発段階でも有効な情報が得られるのでは？ ◦ そもそも、運用と開発を明確なフェーズに分けられる時 代じゃないですよね？ →可観測性を高めるため、計測できる状態に作り上げる
78. 78 W-Aによる言及 “ワークロードを設計する際には、すべてのコンポーネ ントにわたって内部状態 (メトリクス、 ログ、トレース など) を理解するために必要な情報が送出されるように します。これにより、 適時に必要な応答を提供できる ようになります” - Well-Architected 「運用上の優秀性」 設計段階から用意しましょう https://aws.amazon.com/jp/blogs/news/aws-well-architected-whitepaper/
79. 79 (再掲)「監視エージェント入れたら性能下がりました^^」 • 本末転倒、ミイラ取りがミイラ • 二度と入れたくならない
80. 80 (再掲)「監視エージェント入れたら性能下がりました^^」 ベースとなる性能の設定（基準）がおかしい エージェント込みで性能評価する必要 • 計測している状態が基準 計測していない状態はただの追い風参考記録 ◦ 安全装置はずして世界記録だして楽しいですか？ そのためには最初からエージェントを前提に 「計器のない車はありえない」 ※影響を減らすための工夫の仕方はあります（後述）
81. 81 本日のまとめ
82. 82 まとめ SREはMonitoringする生き物 SLI/SLOを計測する 計測（エージェントの組み込み）は最初から
83. 83 Q 大量の情報を 最初から取ってると どうなる？ https://pixnio.com/ja/
84. 84 A あふれます 続きはその2で！ https://booksbelow.wordpress.com/2010/05/31/on-writing-or-lack-of-it/