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

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

Transcript

1. 後回しに しない ❗ 2 監視･ログ分析を最初から始める イマドキの事情と理由・その 〜 解 決 編 〜 渡辺聖剛 ソリューションアーキテクト AWS事業本部 パートナーアライアンス部 2020.07.03
2. 2 監視回　その2 https://dev.classmethod.jp/news/developers-io-2020/ イマココ
3. 3 自己紹介 渡辺聖剛 ( Seigo Watanabe ) • クラスメソッド株式会社 AWS 事業本部 パートナーアライアンス部 • 前職までは 所謂インフラエンジニア • 運用・監視(Monitoring) • 好きな AWS サービス ◦ ACM, Route 53 ◦ AWS Systems Manager https://dev.classmethod.jp/author/watanabe-seigo/
4. 4 ※未承諾広告 モニタリングまわりの記事を担当 AWSにかなり限定した内容に なってます 重複するところは多いですが、 本ではかけなかった話 ＋アップデートを話します https://gihyo.jp/book/2020/978-4-297-11329-2
5. 5 前回のあらすじ
6. 6 前回のあらすじ（おさらい） SREはMonitoringする生き物 SLI/SLOを計測する 計測（エージェントの組み込み）は最初から
7. 7 前回のあらすじ（cont.） 大量の情報を 最初から取ってると どうなる？ https://pixnio.com/ja/
8. 8 前回のあらすじ（cont.） あふれます 続きはその2で！ https://booksbelow.wordpress.com/2010/05/31/on-writing-or-lack-of-it/
9. 9 本日のゴール
10. 10 本日のゴール ・・・という晴れやかな気持ちになること、 https://booksbelow.wordpress.com/2010/05/31/on-writing-or-lack-of-it/ https://flic.kr/p/8jmS1F https://www.irasutoya.com/2018/11/blog-post_109.html
11. 11 本日のゴール そのためには道具が必要ですよね？ ・・・という話をします
12. 12 Agenda
13. 13 Agenda 「あふれる問題」について 2つの解決策 ・運用でカバー ・物理でカバー Tips・注意点 まとめ
14. 14 免責事項（再掲） 時間が限られているので すごくざっくりした話しかしません 流れをつかんでもらうのが目的です
15. 15 免責事項　その2（再掲） 時間が限られているので スライドに書いてあること全てを話しません 興味がわいたらあとから読んで頂けますと！
16. 16 免責事項　その3 ここで話す「監視」とは M（Monitoring）のことです 詳細はその1参照のこと https://www.oreilly.com/library/view/practical-monitoring/9781491957349/
17. 17 あふれる問題
18. 18 ログも監視データもアラートもあふれる 監視データ(正規化・コンテキスト低) ログデータ(非正規化・コンテキスト高) アラート(24x7) なぜ？ - 時代はマイクロサービス - リソースの爆発的増加 - 監視頻度も上昇 - 取得データは詳細化 https://www.pexels.com/photo/cargo-container-lot-906494/
19. 19 あふれたらどうなるか あふれる = それこそ可観測性に関わる問題 昔からあるオオカミ少年化問題 https://www.irasutoya.com/2016/10/blog-post_173.html
20. 20 解決策1 : 運用 工夫でカバー
21. 21 ❌運用　⭕工夫 「頑張る」だけは必ず回避しましょう - 継続できなければ続かない よくある「頑張る」の例 - 見なくていいものにひとつずつフィルタ - 通知された複数の値を脳内で結合
22. 22 工夫でカバーその1 代表値でとらえる
23. 23 代表値でとらえる 個々を見るのではなく、全体の動作で把握する • サイト全体のSLI/SLO • AutoScaling Group • フロントエンド監視 ◦ Synthetic Monitoring（シンセティック監視・合成監視） ◦ Real-User Monitoring（RUM・リアルユーザー監視） • Apdex（Application Performance Index） • ビジネスKPI https://www.flickr.com/photos/epeirogenic/with/3070203272/
24. 24 Load Averageも代表値 単位時間あたりの実行待ちとI/O待ちのプロセスの数で システムの負荷を表現したもの 待ちが多い = 負荷が高い 分散システムだと扱いづらい値ではあるが、 使いどころによってはまだ有効 https://www.techscore.com/blog/2017/12/08/how_is_load_average_calculated/
25. 25 フロントエンド監視
26. 26 フロントエンド監視 ユーザ・クライアントが体験する機能や動作を計測 APMと付き合わせて挙動を明らかにする https://www.irasutoya.com 合成監視 アクセスを機械的に シミュレート RUM ユーザがアクセスし た際にデータを収集 APM Application Performance Management / Monitoring
27. 27 フロントエンド監視(cont.) シンセティクス = 見たいところを定期的に監視 RUM = 実際にユーザが見た時・見たところを監視 “最良のモニタリング戦略は、フロントエンドとバック エンドのソリューションを組み合わせたもの” - リアルユーザモニタリング（RUM） vs 合成モニタリン グ: 顧客体験を改善するにはどうしたらいいか - New Relic公式ブログ https://blog.newrelic.co.jp/uncategorized/synthetic-versus-real-user-monitoring/
28. 28 フロントエンド監視(cont.) Google Analytics (GA) や外形監視とは目的が異なる - GA : サイト訪問者の動向分析・広告効果測定・SEO - 外形 : ポート監視・API監視・ヘルスチェック 重複する領域が多いため同一視されやすい印象 外形監視 ・「外部から」の監視 ・Web、DB、SMTP ・応答をチェック ・ブラックボックス監視 https://www.atmarkit.co.jp/ait/articles/0403/20/news010.html https://takehora.hatenadiary.jp/entry/2019/07/05/012036 https://devops.com/black-box-vs-white-box-monitoring-what-you-need-to-know/ シンセティック監視 ・「外部から」の監視 ・Web、REST API ・応答のみならず 　一連のシーケンスなども 　APMとしてデータ収集 ・ホワイトボックス監視
29. 29 Apdex
30. 30 Apdex（Application Performance Index） ユーザー体験の快適さ・満足度を、レスポンスタイムを 指標に数値で表現したもの 仮に「0.5秒以内にレスポンスがあること」 を満足と定義する（T=0.5） ※SLOとは別に定義（ex) 0 < SLO ≦ 4T） https://www.apdex.org/index.php/about/ https://blog.newrelic.com/product-news/how-to-choose-apdex-t/ Satisfied（満足） 0〜0.5秒 n ≦ T Tolerated（許容範囲） 0.5〜2.0秒 T < n ≦ 4T Frustrated（不満） 2.0秒〜 4T < n
31. 31 工夫でカバーその2 統計値でとらえる
32. 32 統計値でとららえる 数値の上下に一喜一憂せず、数値の「意味」を取り出す 統計値・統計分析 ◦ 複数のメトリクスを数値計算して可視化 ◦ 移動平均や線形予測など パーセンタイル（分位数）p80,p99など ◦ 単位時間当たりの全ての数字を昇順ソートして、 全体のパーセンテージにあたる値 ◦ 平均とは違い、突発的なスパイクを除外できる https://stopcovid19.metro.tokyo.lg.jp/
33. 33 動的な閾値設定 外れ値（Outlier）検知 ふるまい（Anomaly）検知 - 通常の傾向から外れた動きの検知 - 急激な増加・減少、ルーティンとは違う動き - 統計的手法や機械学習による分類手法 閾値の設定を固定とせず、 状況に応じた検出・通知を行う https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ CloudWatch_Anomaly_Detection.html
34. 34 ビジネスKPIも大事なメトリクス 政治層のひとが見てくれるダッシュボードを整備するこ とで、「上司に報告」という重大な業務が効率化できる ◦ サービスを見るのはエンジニアも必要な視点 ◦ SLOの判断基準になる ※事例を後述
35. 35 工夫でカバーその3 可視化 Visualization
36. 36 可視化 = データの意味づけ コンテキストに基づいて情報を整理 Information（情報）から Intelligence（分析された知識）へ https://www.history.com/topics/us-government/history-of-the-cia
37. 37 可視化 = 情報を素早く把握するための方法 アンスコムの例（Anscombe’s quartet） 可視化することで特徴が見えてくる https://ja.wikipedia.org/wiki/アンスコムの例
38. 38 可視化 = 情報を素早く把握するための方法 “データ可視化の主なメリットは三つがあります： 1. 現状を把握し、課題やその原因を発見することで、 迅速な対応が可能になる 2. 社内にデータをオープンに利用可能に、 情報を早く共有し、業務の効率を上げる 3. 社内の様々なデータを統合することで、 予測分析を行い、トレンドの洞察を得られる” データ可視化とは？その必要性と基本手法を解説 https://kirikuroda.github.io/datareporting/introduction.html
39. 39 工夫でカバーその4 その他の工夫
40. 40 工夫 = 効率を上げる 「見なくて良いものは見ない」は正しいか？ ◦ 例) CPU利用率ってアラート投げる必要ある？ ◦ 明らかに不要なものは言うまでもない （クラウドなのにH/W RAIDエラーとか…） →見なくても取っておこう ◦ 分析するときには必要 ◦ 収集したデータをふるい分けする 「いま見るべきもの」と「あとで見る/見そうなもの」 ◦ いま見なくて良いもの→通知もしなくて良い
41. 41 分類例 • 即応が必要なもの (on-call alert) • 対応は必要だが即応不要なもの (chat notice) • 対応は要らないが知っておきたいもの (log info) • 監査や障害調査のために (log-archive debug) 参考（再掲）： Lambdaのログレベル方針について、チームで話して 明文化してみた | Developers.IO https://dev.classmethod.jp/articles/lambda-log-level/
42. 42 だれに通知する？ 人間に通知する→ITSやChatに直接通知 ◦ 初動を早くする 機械に通知する→自動化 • 誰も気付かなければ障害ではない • 無事復旧できたのならオンコールは不要 • TCP/IPの再送も自動的な復旧のひとつ ◦ 許容範囲内に収まるならいちいち監視しない （逆説的に）障害であるのなら、気付けるようにすべき
43. 43 どこまで細かく求めるか？ “1秒間のダウンタイムを計測するには、1秒未満の間隔 でデータを収集する必要があります” - 入門　監視 「波形を捉えるには、その波形の最大周波数の2倍を超 えた周波数で標本化する必要がある」 - シャノンの定理（標本化定理） https://pixnio.com/ja/
44. 44 「海岸線の正確な長さを測定しなさい」 1kmの物差しを使うと、小さな入り江や岬が測れない 100mの物差しを使うと、ゴツゴツの岩肌が測れない 10m、1m ... スケールを変えると、いままで測れていな かったものが見えてくる 1mm、0.1mm ... 砂粒の起伏をどうやって測る？ そもそも波や、潮の満ち引きがあるなかで、 どこまで測る意味がある？ https://pixnio.com/ja/ https://www.irasutoya.com/2017/03/blog-post_421.html
45. 45 基準を与えるのがSLI/SLO →SLOに必要なだけのSLIを、 　必要十分な粒度で測定しましょう https://pixnio.com/ja/ https://www.irasutoya.com/2013/03/blog-post_1704.html
46. 46 ところで ここまでやっても、 やっぱり運用でカバーつらくないですか？
47. 47 解決策2 : 物理 ツールで解決
48. 48 「ツール」とは ソフトウェアだけに限らず、 世にあふれるメソッドも「ツール」の ひとつ 「巨人の肩の上に立つ」 巨人 = 偉大な先人の知恵を 積極的に借りよう https://en.wikipedia.org/wiki/Standing_on_the_shoulders_of_giants https://www.irasutoya.com/2019/01/blog-post_43.html
49. 49 ここで紹介する「ツール」 ダッシュボード AIOps/MLOps カオスエンジニアリング SaaS ほかにもいっぱいある！ その1で引用したものも「ツール」「巨人」です
50. 50 ダッシュボード
51. 51 ダッシュボード = 「ひと目で分かる」 “企業内の各種ビジネスデータから重要な要点を抽出し て、ひと目で分かるように視覚化したもの” “自動車の計器盤のメタファー” - デジタルダッシュボード, Wikipedia 多くの監視・モニタリングツールは ダッシュボードのカスタマイズに対応 - CloudWatch Dashboardsなどなど https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/GettingStarted.html
52. 52 ダッシュボードも進化する 対象と役割が変化すれば、 最適なダッシュボードの形態も変化する 2000 2020 https://spaceflight.nasa.gov/gallery/images/shuttle/sts-101/html/jsc2000e10522.html https://www.youtube.com/watch?v=won6Ap9JnVw
53. 53 New Relic One プログラマブルダッシュボード Reactコンポーネントを使って 独自のダッシュボードを 作成可能 ※既存のカスタマイズ機能に 　飽き足らないひと向け https://docs.newrelic.com/docs/new-relic-one/use-new-relic-one/build-new-relic-one/ new-relic-one-build-your-own-custom-new-relic-one-application
54. 54 ダッシュボードはみんなのために 分かりやすく可視化 = データの民主化 “開発委託先が月に一度の運用レポートを、専門家では ない担当社員に届けるといういままでの体制から、毎分 更新される最新の運用情報が、普段慣れ親しんだビジネ ス指標と一緒に届くことで、自分たちがサービスを届け ているというライブ感とユーザーの反応をダイレクトに 共有できる” 大規模キャンペーンでの Mackerel活用で ビジネス上のKPIもダッシュボードで可視化 ～クレディセゾン～ https://mackerel.io/ja/blog/entry/customers/credit-saison
55. 55 AIOps / MLOps
56. 56 AIOps・MLOps AI（機械学習によるパターン認識・分類）で 情報をふるい分け・利用者にリコメンド - 予測検知 - トリアージ、ノイズの軽減 - RootCauseのサジェスト AIOpsは絶賛進化中 プレーヤーは続々 - New Relic, IBM Watson, moogsoft etc...
57. 57 GameDay Chaos Engineering
58. 58 GameDay あるシチュエーションを設定し、 本番さながらの環境を用意して、 日頃の備えやスキルがうまく回るかを測るもの （あるいはそれ競技化したもの） • 自動車の衝突実験（制御された事故） + 消防訓練（経験を通じて本番に備える） + 予防接種（耐性を付ける） https://awsgamedaymicroservicestokyo.splashthat.com/ https://www.mlit.go.jp/jidosha/anzen/02assessment/car_h21/test_crash.html
59. 59 Chaos Engineering 「GameDayを定期的・定常的に行う」もの - 日常的に「制御された」障害が発生する - システム・運用チームはそれに対処する - 対処 = SLO内で完結させる • 予告なし（抜き打ち）訓練 ◦ 運用担当（人間）チームが対応できるか ◦ 自動対処・リカバリ（機械）は意図通りに機能するか https://www.gremlin.com/
60. 60 GameDay・Chaos Engineeringは Design for failureの原則に従っているかの実地検査 “Everything fails all the time” 全ては障害を起こすもの、 という前提から逆算した設計 ・SPOFの排除 ・H/Wが故障してもAppには影響を 　及ぼさないように そうすれば、 真に壊れるものはなくなる AWS re:Invent 2019 - Keynote with Dr. Werner Vogels https://www.youtube.com/watch?v=OdzaTbaQwTg
61. 61 ※未承諾広告 New Relic + Classmethod カオスエンジニアリング やってます https://classmethod.jp/news/200414-newrelic/ https://cloud.watch.impress.co.jp/docs/news/1247030.html
62. 62 SaaS
63. 63 運用のためのツールの運用を頑張る？ その「頑張ってる」ものは業務の本筋ですか？ 頑張ることで失っているものはありませんか？ ◦ 時間 ◦ 稼働 頑張らない → SaaSをいれて楽になろう
64. 64 「SaaSいれて楽になろう」？ 正確に言えば、 • SaaSだからといって、頑張らなくてよくなる わけではない • 頑張るところが変わるだけ 本来集中したいところに集中 • →責任共有モデル（by AWS） https://aws.amazon.com/jp/compliance/shared-responsibility-model/
65. 65 ご紹介 ❖ CloudWatchファミリー ❖ Mackerel ❖ New Relic ❖ Sumo Logic ❖ その他 （基本的に弊社で扱っているもの）
66. 66 免責事項　その4 完全に適材適所・ケースバイケースの世界なので、 正解は「まず使ってみる」 SaaSは日々開発が続き進歩しているので、いまの情報 が明日正しいとは限らない なんとなく「この辺かな？」と当たりを付けるときにご 参照頂ければ
67. 67 CloudWatchファミリー ※X-RayなどCloudWatchを冠さないものも含む • 全ての基本 • サードパーティ製品はCloudWatchに依存 • 最初から用意されている • 使いこなすために頑張る必要がある ◦ 個々の機能が完全に統合されていない、 ダッシュボード機能の不足など • 完全にAWS特化 出来ることと、他のもので補えるもの・ 補うと楽なもの・補うべきものを認識して使う https://aws.amazon.com/jp/cloudwatch/
68. 68 Mackerel • 純国産。はじめの一歩 • 楽に始められる、それでいて見た目や操作性も 良い、拡張性も分かりやすい • 監視をしっかりやりたい、でもどこから？ となっているひと向け ◦ Sな監視をしていた方々が入りやすいと思われる • 使っていくと物足りなくなってくるところはある 次の一手：拡張・作り込む、単分野SaaSと組み合わせ る、統合型SaaSに乗り換える https://mackerel.io/ja/
69. 69 New Relic • 自他共に認める「可観測性プラットフォーム」 • 可視化、パフォーマンスチューニングの強い味方 • なんでもそろってる。 全ての機能はAPMのためにある ◦ なので、例えばインフラ監視だけのために入れるメリッ トは薄い（ないわけではもちろん無い） • 逆にいうと、全体像の把握や使いこなしに力が要る • Lambdaやk8sにももちろん対応 目的のために邁進できる強い組織の強い味方 https://newrelic.co.jp/
70. 70 Sumo Logic • 純SaaS型SIEM • 一方でLambdaやk8sのダッシュボードもある ◦ SIEMとして入れて応用するのはよさそう • ありとあらゆるプラットフォームのログを収集して 一元管理・可視化 • メトリック収集機能もある ◦ ただしログ分析の補助的なものにとどまる ログ収集・集積・可視化 + 脅威評価・分析 https://www.sumologic.jp/
71. Sumo Logic New Relic 71 各SaaSの得意分野図 App OS インフラ (AWS) Event Log Metric Trace (APM) Frontend Synthetics RUM S3, CWLogs CloudWatch X-Ray CWSynthetics k8s, FaaS Mackerel ※面積の広さと製品の優劣は無関係です ※製品動向の全てを表現しているわけではありません。2次元の図では表現しきれません… ML AIOps
72. 72 その他にもSaaSはたくさん Datadog インフラエンジニアが持ち得る最強のツール 全方位に隙なし Cloud Monitor（旧Stackdriver） Googleの考える最強の監視システム Pingdom フロントエンド監視特化 SignalFx, Instana APM特化。リアルタイム指向 Sysdig monitor セキュリティ用途強め。クローズドボックス監視 AirBreak トレースログに特化。OSS実装のerrbitも Epsagon 分散トレーシング特化。エージェントレス 他にも Humio, AppDynamics, Dynatrace ...（書き切れません） 各ツールは独自の特徴と特色、UI/UX、出自と得意分野をもっています。 いろいろ試して自分たちにあったものを！
73. 73 ※未承諾広告 気になったSaaSは Developers.IOで検索❗ https://dev.classmethod.jp/
74. 74 押さえておきたい • Prometheus + Grafana • OpenTelemetry, OpenMetrics
75. 75 Prometheus + Grafana OSSモニタリングツールの現在の代表格 CNCF・Docker・k8sでは業界標準 各社「Prometheus形式のメトリクス」に 対応を開始 - Datadog Prometheus Check - New Relic Prometheus integrations - Amazon CloudWatch ... https://docs.datadoghq.com/ja/integrations/prometheus/ https://docs.newrelic.com/docs/integrations/prometheus-integrations https://aws.amazon.com/jp/about-aws/whats-new/2020/05/amazon-cloudwatch-now- monitors-prometheus-metrics-now-in-beta/
76. 76 OpenTelemetry, OpenMetrics トレース情報・メトリック情報のCNCFによる標準化 ※現在ベータ・Coming soon https://opentelemetry.io/ https://openmetrics.io/
77. 77 Tips・注意点
78. 78 Zabbixは？ まだまだ現役。進化も開発も続いている ‘20/07現在でZabbix5.0 必要なのは、どのツールが一番合うかを考えること - 監視対象、運用体制 - 盲目的に「あれがいい」「これはダメ」というのは やめよう - （その点で、SaaSは始めやすく止めやすい） https://www.zabbix.com/jp
79. 79 CI/CDも監視対象にしよう いつDeployしたか？その前後で傾向に変化は？ Deployにどのくらい時間がかかっているか？ コンテナイメージのサイズは？ 見るべきポイントはたくさんあります - Top 5 container and Kubernetes best practices re:Invent 2019 https://dev.classmethod.jp/articles/reinvent2019-container-best-practices/ https://dev.classmethod.jp/articles/201912-report-con307-reinvent2019/
80. 80 監視エージェントの影響を最小限に コスト的にも性能的にも、 エージェントが足を引っ張っては意味がない いち案：サンプリングという考え方 ◦ 同一集団のなかで1つだけエージェントを動かす ◦ あるいは、トラフィック全体の一部を計測用に流す • 特定条件にあう場合においてのみエージェントを 導入 or 起動する仕組み
81. 81 テクニックとしては考えられるが、それによって取得で きるデータに制限がでたり、データそのものの有効性に 疑問符が付くようでは本末転倒 - Q : Real-User Monitoring用のJavaScriptを 　　lazy load（遅延読込）できないか？ - A : できはするけど、本当に？ まず各ベンダが推奨するBest practiceにそって 組み込もう 影響の少ない組み込み方は？
82. 82 まとめ
83. 83 まとめ 監視(Monitoring)は守りのためでなく、 いまのシステム・サイトをより良くするためのもの 本来の目的に注力するために、 巨人の肩に積極的に乗りましょう ※弊社もお手伝いします！ https://www.irasutoya.com/2019/01/blog-post_43.html