Save 37% off PRO during our Black Friday Sale! »

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

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

E39a62a5c1f1829cc6ce0ec642424947?s=128

Seigo Watanabe

July 03, 2020
Tweet

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/

  85. 85