Tweet
Tweet

Slide 1

Slide 1 text

後回しに しない ❗ 1 監視･ログ分析を最初から始める イマドキの事情と理由・その 〜 俯 瞰 混 乱 編 〜 渡辺聖剛 ソリューションアーキテクト AWS事業本部 パートナーアライアンス部 2020.07.03

Slide 2

Slide 2 text

2 監視回　その1 https://dev.classmethod.jp/news/developers-io-2020/ イマココ

Slide 3

Slide 3 text

3 Agenda

Slide 4

Slide 4 text

4 Agenda まえおき - 前提となる話 50:50 - SREの話 SかMか - 監視の話 3-4-3 - 可観測性（o11y）の話 それから? →以下、その2へ続く

Slide 5

Slide 5 text

5 本日のゴール

Slide 6

Slide 6 text

6 本日のゴール Modern Application Development 急にモダンなアプリケーションをデベロップメントする ことになっても、 「え、監視とかどうすれば・・？」 と悩まずにすむようになること https://www.irasutoya.com/2015/12/blog-post_51.html

Slide 7

Slide 7 text

7 免責事項 時間が限られているので すごくざっくりした話しかしません 流れをつかんでもらうのが目的です

Slide 8

Slide 8 text

8 免責事項　その2 時間が限られているので スライドに書いてあること全てを話しません 興味がわいたらあとから読んで頂けますと！

Slide 9

Slide 9 text

9 自己紹介 渡辺聖剛 ( Seigo Watanabe ) ● クラスメソッド株式会社 AWS 事業本部 パートナーアライアンス部 ● 前職までは 所謂インフラエンジニア ● 運用・監視(Monitoring) ● 好きな AWS サービス ○ ACM, Route 53 ○ AWS Systems Manager https://dev.classmethod.jp/author/watanabe-seigo/

Slide 10

Slide 10 text

10 ※未承諾広告 モニタリングまわりの記事を担当 AWSにかなり限定した内容に なってます 重複するところは多いですが、 本ではかけなかった話 ＋アップデートを話します https://gihyo.jp/book/2020/978-4-297-11329-2

Slide 11

Slide 11 text

11 本題

Slide 12

Slide 12 text

12 モダンな監視を語る上で外せない 前提となる話

Slide 13

Slide 13 text

13 前提となる話 ● アーキテクチャとコンピュート能力 ● ビジネス要件と開発・運用体制 これらの変化について

Slide 14

Slide 14 text

14 アーキテクチャとコンピュート能力 モノリシックからマイクロサービスへ - Container, k8s, FaaS ... コンピュート性能の爆発的向上 - 計算・I/O性能、ストレージコストは低減 - 超高速ネットワーク - 仮想化技術などの技術革新 Software Defined X (SDx) - X = Network, Infrastructure ... - 従来ハードウェアだったものがソフトウェアで 置き換えられていく

Slide 15

Slide 15 text

15 ビジネス要件と開発・運用体制 より早いサイクルでのサービス向上が求められる 開発・運用体制 - ウォーターフォールからDevOps - DevOpsからSRE https://pixnio.com/ja/media/ja-2227252 https://www.irasutoya.com/2016/07/blog-post_807.html

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

17 SREの話 50:50

Slide 18

Slide 18 text

18 監視なのになぜSRE？ いまの世の中避けて通れない SREの文脈を抑えておくことで ベストプラクティスが見えてくるから

Slide 19

Slide 19 text

19 SREってなんぞ Site Reliability Engineering（または 〜Engineer） 技術であり、そのためのエンジニアロール SREの目的は「信頼性の向上」 - 変化し続けるサイト（システム）を前提に、 そのサイトで安定的に「サービスを提供すること」 - サイトを「安定稼働させること」ではない ちゃんと動いているかどうかを知ることが必要 従来との違い → SREは攻めの運用

Slide 20

Slide 20 text

20 GoogleにおけるSRE ”SREは、これまで運用チームが行ってきたことをソフ トウェアの専門性を持つエンジニアが行い、エンジニア が人手による管理を自動化するソフトウェアを設計し実 装する能力を持ち、それをいとわないということから成 り立っています“ - “SRE サイトリライアビリティエンジニアリング” https://www.oreilly.co.jp/books/9784873117911/

Slide 21

Slide 21 text

21 GoogleにおけるSRE(cont.) ● 仕事の半分はコードを書くこと ○ 自動化、Infrastructure as Code ○ 必要なメトリックを収集する仕組みの組み込み ○ プルリク ○ その他「信頼性をあげる」ために必要なこと ● 残りの半分で、 チケット、オンコール、手作業といった運用業務 観念ではなく、明確に工数を分ける

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

CALMS - DevOpsの哲学のキーポイント - Culture - Automation - Lean - Measurement - Sharing DevOpsにとってMeasurementは 重視されるべきもの 23 DevOpsの文化 https://www.oreilly.co.jp/books/9784873119137/

Slide 24

Slide 24 text

SREがサイトの「信頼性」を維持するためには、 何が起こっているかを監視しなくてはならない → SREの文脈に沿って「監視」を行うことが 　いまのベストプラクティス 24 つまり

Slide 25

Slide 25 text

25 「監視」の話 S or M

Slide 26

Slide 26 text

26 そもそも「監視」とは？ システムを常時観測・計測し 異常が検知できたら それに対して対処する 対処 Respond / Resolve 検知 Detect 計測 Measurement https://www.irasutoya.com/

Slide 27

Slide 27 text

27 監視と言えば　入門「監視」 発行：2019.01 一大監視ブームを巻き起こした うなずくことが多い一方で、 読んでいてどこか違和感がある 文句なしの良書ではあるけど、 ぼくの知ってる監視とは何か違う… https://www.oreilly.co.jp/books/9784873118642/

Slide 28

Slide 28 text

28 Q あなたの監視は「S」ですか？ それとも「M」ですか？

Slide 29

Slide 29 text

29 再掲：監視とは システムを常時観測・計測し 異常が検知できたら それに対して対処する 対処 Respond / Resolve 検知 Detect 計測 Measurement

Slide 30

Slide 30 text

30 あなたの監視はSかMか？ 検知を重視 = 「問題が起こらないこと」 = S（Surveillance）な監視 対処 Respond / Resolve 検知 Detect 計測 Measurement

Slide 31

Slide 31 text

31 あなたの監視はSかMか？ 計測を重視 = 「何が起こっているのか」 = M（Monitoring）な監視 注：監視のSとかMとか言ってるのは独自研究です 対処 Respond / Resolve 検知 Detect 計測 Measurement

Slide 32

Slide 32 text

32 辞書的な定義 monitorもsurveillanceもobserveもsuperviseも、 日本語にするとみんな「監視」になる 一方で、日本語の「監視」には「S」な意味合いが強い ● 監視カメラ : Video surveillance, CCTV ● 監視社会 : surveillance society, watchdog society ● PCモニタのことを「監視装置」とは訳さない https://pixnio.com/ja/ https://flic.kr/p/3iapit

Slide 33

Slide 33 text

33 トラディショナルな監視の定義 Nagiosまではそんなに違和感なかった ● チェック監視 = Nagios リソース監視 = Cacti ● Zabbixは両方できる ○ 当時はそれが画期的でもあった ○ そのあたりから混乱が始まってる感 （個人の感想です） 可観測性までくると違いが際立ってくる https://commons.wikimedia.org/

Slide 34

Slide 34 text

34 Sな監視「も」必要であり適切 「ちゃんと作ればちゃんと出来る」時には有効 ○ 建築や製造業など ○ 守ること・事故を起こさないことそのものが目的 ○ 単純な閾値チェック 本来の「サーベイランス」はそうであるべき ○ 収監、検疫など ○ 単純化による判断・対処の迅速化 ○ 命に関わるものはそれが最優先 https://pixnio.com/ja/

Slide 35

Slide 35 text

35 一方で、 ● ソフトウェアでは「ちゃんと作る」と時間がかかる ● 不具合のないソフトウェアを作ることはもはやムリ ● 仮に「ちゃんと出来」たとしても、 あっという間に古くなる ● 検知にだけ注目すると、単純な閾値チェックで 事足りる -> コンテキストが失われる 複雑化したモダンアプリにおいて、 「S」な監視を行っていては追いつかない https://torange.biz/jp/fx/background-modular-modern-blue-abstract-arrows-creative-215352

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

39 入門「監視」による言及 “そう言った人たちは、何か問題がおきた時にアラートを 出すことが監視システムの目的だと信じているのです。 （中略）監視にはもっと高い目的があります。 「監視は、質問を投げかけるためにある。」” “監視とはアラートを出すために存在しているのでは ありません。アラートは結果の1つの形でしかないのです” 邦題：入門「監視」 原題：Practical Monitoring https://www.oreilly.com/library/view/practical-monitoring/9781491957349/

Slide 40

Slide 40 text

40 つまり：今どきの監視とは アラートのためではない、 よい運用を行うための情報収集(monitoring) ● パフォーマンスチューニング ● トラブルシューティング →次の開発サイクル（Iteration）のため https://www.flickr.com/photos/fcrippa/7967994338/

Slide 41

Slide 41 text

41 収集してどうする？ 人間が受け取る：手動で対処 ○ Devがうけとる：コードの修正 ○ Opsがうけとる：メンテナンス、リソースマネジメント 機械が受け取る：自動処理のトリガー ○ AutoScaling ○ AutoRecovery ○ Failover ○ Retry

Slide 42

Slide 42 text

42 ここまでのまとめ 変化にあわせて意識もかえよう SREが必要としているのはM

Slide 43

Slide 43 text

43 可観測性 Observability (o11y) 3-4-3

Slide 44

Slide 44 text

44 じゃあ具体的に何をモニタリングしましょう おさらい： SREの目的は「信頼性の向上」 信頼性（Reliability）とは？

Slide 45

Slide 45 text

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/

Slide 46

Slide 46 text

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/

Slide 47

Slide 47 text

47 つまり まず「異常（信頼性が損なわれた状態）」を定義 SLI = 定めた「異常」を計る上でキーとなる指標 SLO = そのSLIに対して、どうである時を正常あるいは 異常(故障)と判断するかを定義したもの “SREの日々のタスクやプロジェクトは、 SLOによって駆動されます” - サイトリライアビリティワークブック

Slide 48

Slide 48 text

48 つまり 正常な判断のためには、SLI/SLOにつながる監視を ● なんでもかんでも見る必要はない ● 見る意味のあるデータについてだけ観れば良い 一方で、 「見る意味があるものは何か？」を知る必要がある ○ 本と検索エンジンの話に似ている

Slide 49

Slide 49 text

49 基本方針：全体を見ましょう 全体をみて方針を決め ドリルダウンして対処する その材料としてデータの収集を ※その2で詳しく話します https://www.pexels.com/photo/cargo-container-lot-906494/

Slide 50

Slide 50 text

50 着目点 3 Pillars 4 Golden Signals 3 Dimensions

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

52 The Four Golden Signals Latency (パフォーマンス・遅延) Traffic (トラフィック量) Errors (エラー発生率) Saturation (利用率、キャパシティ) - SREサイトリライアビリティエンジニアリング https://landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems/

Slide 53

Slide 53 text

53 Three dimensions Functionally (その機能が正しく動いているか) Availability (その機能が使えるか) Speed (遅くないか) - Best Practices for Monitoring E-Commerce Performance https://newrelic.com/resources/tutorials/best-practices-for-monitoring-ecommerce-performance

Slide 54

Slide 54 text

54 雑な関連 Metric 数値 Event Log 高コンテキスト Trace 関連性 Latency 遅延 Traffic 流量 Errors エラー Saturation キャパシティ Functionally 機能の正常性 Availability 可用性 Speed 速度・性能 何を取得するか シグナル 観点 ※線がないから取れない・関係がない、というわけではありません 遅すぎる⇔使えない 情報量の違い

Slide 55

Slide 55 text

55 SRE的な観点 ● 「エラーバジェット」という考え方 ● MTTR

Slide 56

Slide 56 text

56 「エラーバジェット」という考え方 サイトリライアビリティを語る上で欠かせない概念 エラーバジェットを使って何をするか？ ● ひとつの考え方 ○ 「試験は通ったが本番で動かない」ケース ○ どうせなら、本番稼働で検知して即対応できたほうが 良いのでは？ ■ →誰よりも早く運営チームが気付く必要性 ● もうひとつの考え方 ○ エラーバジェットが許す範囲で復旧できたらいい

Slide 57

Slide 57 text

57 MTTRも気にしよう Mean Time To Repair = 復旧までの最小平均時間 Mean Time To Resolution = 解決までの最小平均時間 SLO 99.9% = 毎月30〜40分止まっても許される？ ○ 「1回の停止は5分以内」のような定義も必要 ○ SLOを日単位、時間単位でも設定する ■ 99.9%/day = 8.64sec.

Slide 58

Slide 58 text

58 ここまでのまとめ ● SREはSLOによって駆動される ● SLOを求めるには計測(監視)しかない ● ここでいう監視はMのこと

Slide 59

Slide 59 text

59 可観測性 = 広義の「可視化」その性能 見えなかったものを見えるようにする - つながり・連続性の可視化 = (分散)トレース - 数値表現から図示・グラフ化 = ダッシュボード 可観測性（Observability） = そのシステムがそなえている性質・性能 - Availability, Capability, Scalability ...

Slide 60

Slide 60 text

60 何に着目するか 3-4-3（前述） Metric Event Log Trace Latency Traffic Errors Saturation Functionally Availability Speed

Slide 61

Slide 61 text

61 何に着目するか（cont.） 3-4-3（前述） Metric Event Log Trace Latency Traffic Errors Saturation Functionally Availability Speed

Slide 62

Slide 62 text

62 「性能は機能」 つまるところ「速いは正義」 ● 使えない = ユーザーから見たら「無限に遅い（帰ってこない）」 = タイムアウト ● 応答時間と離脱率には相関がある レスポンスタイムを上げることが業績に繋がる

Slide 63

Slide 63 text

63 「監視エージェント入れたら性能下がりました^^」 よく聞く話ですが。。。 例） - エージェントいれたらCPU負荷が10%増えた - PageSpeed Insightsのスコアが20下がった ※あとでお話しします

Slide 64

Slide 64 text

64 ログの話

Slide 65

Slide 65 text

65 そもそも「ログ」とは トラディショナルなイメージ ● 取りあえず出力されるもの ● /var/log/ほげほげ ● ほっとくとディスクを食い潰す ● たまにエラーが吐かれてて気をつけなきゃならない ● デバッグログが大量に出ているが放置 https://help.sumologic.com/01Start-Here/Quick-Start-Tutorials/Set-Up-Sumo-Logic-Tutorial

Slide 66

Slide 66 text

66 可観測性では 「コンテキスト豊かな監視データ」と捉える - 高コンテキスト = 情報量が多い、事象の背景 - 正規化・非正規化どちらもある - 正規化ログ = JSON（Stack Traceなど） - 非正規化ログ = テキスト1行（Apacheなど）

Slide 67

Slide 67 text

67 Event Log（Events）？ ● メタデータが正規化されたログ、 あるいはコンテキスト豊富なメトリック ● 一方で、メトリックにメタデータを付与するような 動きもあり ○ Prometheus, OpenMetrics（後述） ● 境界がグレーになってきている ○ メトリックとイベントの境、イベントとログの境 ○ 厳密なものではなく、感覚で捉えていいと思う

Slide 68

Slide 68 text

68 ログをどう使う？ 2つの方向性（従来から大きくは変わっていない） ● ログからキーワードをひろう ● イベント発生時にどんなログが出ていたかを掘り起 こせるように収集する 死活監視・リソース監視と考え方は同じ トレースログなどはログとして扱うのではなく、 分散トレース（APM）で扱う

Slide 69

Slide 69 text

69 具体的には ツールにため込んで可視化 保存 重要度別に通知・アラート

Slide 70

Slide 70 text

70 ログの可視化 コンテキストが多い = ぱっとみよく分からん 有望有効な情報が埋もれているかもしれない →もったいない 可視化・有益なデータを掘り起こす そのための分析ツール ※その2で詳しく

Slide 71

Slide 71 text

71 長期保存と中・短期保存 長期 = アーカイブ、記録や監査のため ○ 日単位、数年単位 ○ 何かあったときに掘り起こせれば良い 中期 = 傾向の把握（短期との比較） ○ 時間単位、数日〜1週間〜数ヶ月、13ヶ月 ○ シーズナルな影響をどうみる？ 短期 = 「いま」何が起きているか ○ 分単位、〜数日 ○ 時代は準リアルタイム（秒単位）へ

Slide 72

Slide 72 text

72 重要度 Lambdaのログレベル方針について、チームで話して明 文化してみた | Developers.IO https://dev.classmethod.jp/articles/lambda-log-level/

Slide 73

Slide 73 text

73 So, since when? (で、いつから？)

Slide 74

Slide 74 text

74 前提：監視とは “監視とは継続的なテストである” - 監視とは継続的なテストである、という話 (もしくは cronlog とテストスクリプトを組み合わせた監視手法につい て) - https://planet.mysql.com/entry/?id=23085 “監視とは、あるシステムやそのシステムのコンポーネ ントの振る舞いや出力を観察しチェックし続ける行為で ある。” - 入門「監視」

Slide 75

Slide 75 text

75 いつから取り始めればよい？ “世界中のディベロッパーの42%以上が、 開発ライフサイクルにおけるテストのタイミングが 遅すぎると回答” - DevSecOpsに関するグローバルアニュアル調査の 結果を発表：ソフトウェア開発チームの役割の 変化が明らかに｜GitLab Inc.のプレスリリース https://prtimes.jp/main/html/rd/p/000000003.000056974.html

Slide 76

Slide 76 text

76 いつから取り始めればよい？(cont.) (再掲)正常な判断のためには、なんでもかんでもデー タを見る必要はない、見る意味のあるデータについてだ け観れば良い ● そのためには、「見る意味があるものは何か？」を 知る必要がある ○ 大量のデータをみておく必要性

Slide 77

Slide 77 text

77 いつから取り始めればよい？(cont.) 予め「取れるだけとっておく」ことが大切 ○ あとから「あれを見ておけばよかった」となった時のこ とを考えておく ○ 観測コストも保存コストも、年々安くなっている ○ ※法的な保存期間についての議論はまた別の話 それが判断できるのはいつか？本番稼働後でいい？ ○ 開発段階でも有効な情報が得られるのでは？ ○ そもそも、運用と開発を明確なフェーズに分けられる時 代じゃないですよね？ →可観測性を高めるため、計測できる状態に作り上げる

Slide 78

Slide 78 text

78 W-Aによる言及 “ワークロードを設計する際には、すべてのコンポーネ ントにわたって内部状態 (メトリクス、 ログ、トレース など) を理解するために必要な情報が送出されるように します。これにより、 適時に必要な応答を提供できる ようになります” - Well-Architected 「運用上の優秀性」 設計段階から用意しましょう https://aws.amazon.com/jp/blogs/news/aws-well-architected-whitepaper/

Slide 79

Slide 79 text

79 (再掲)「監視エージェント入れたら性能下がりました^^」 ● 本末転倒、ミイラ取りがミイラ ● 二度と入れたくならない

Slide 80

Slide 80 text

80 (再掲)「監視エージェント入れたら性能下がりました^^」 ベースとなる性能の設定（基準）がおかしい エージェント込みで性能評価する必要 ● 計測している状態が基準 計測していない状態はただの追い風参考記録 ○ 安全装置はずして世界記録だして楽しいですか？ そのためには最初からエージェントを前提に 「計器のない車はありえない」 ※影響を減らすための工夫の仕方はあります（後述）

Slide 81

Slide 81 text

81 本日のまとめ

Slide 82

Slide 82 text

82 まとめ SREはMonitoringする生き物 SLI/SLOを計測する 計測（エージェントの組み込み）は最初から

Slide 83

Slide 83 text

83 Q 大量の情報を 最初から取ってると どうなる？ https://pixnio.com/ja/

Slide 84

Slide 84 text

84 A あふれます 続きはその2で！ https://booksbelow.wordpress.com/2010/05/31/on-writing-or-lack-of-it/

Slide 85

Slide 85 text

85