Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

5 前回のあらすじ

Slide 6

Slide 6 text

6 前回のあらすじ（おさらい） SREはMonitoringする生き物 SLI/SLOを計測する 計測（エージェントの組み込み）は最初から

Slide 7

Slide 7 text

7 前回のあらすじ（cont.） 大量の情報を 最初から取ってると どうなる？ https://pixnio.com/ja/

Slide 8

Slide 8 text

8 前回のあらすじ（cont.） あふれます 続きはその2で！ https://booksbelow.wordpress.com/2010/05/31/on-writing-or-lack-of-it/

Slide 9

Slide 9 text

9 本日のゴール

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

11 本日のゴール そのためには道具が必要ですよね？ ・・・という話をします

Slide 12

Slide 12 text

12 Agenda

Slide 13

Slide 13 text

13 Agenda 「あふれる問題」について 2つの解決策 ・運用でカバー ・物理でカバー Tips・注意点 まとめ

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

16 免責事項　その3 ここで話す「監視」とは M（Monitoring）のことです 詳細はその1参照のこと https://www.oreilly.com/library/view/practical-monitoring/9781491957349/

Slide 17

Slide 17 text

17 あふれる問題

Slide 18

Slide 18 text

18 ログも監視データもアラートもあふれる 監視データ(正規化・コンテキスト低) ログデータ(非正規化・コンテキスト高) アラート(24x7) なぜ？ - 時代はマイクロサービス - リソースの爆発的増加 - 監視頻度も上昇 - 取得データは詳細化 https://www.pexels.com/photo/cargo-container-lot-906494/

Slide 19

Slide 19 text

19 あふれたらどうなるか あふれる = それこそ可観測性に関わる問題 昔からあるオオカミ少年化問題 https://www.irasutoya.com/2016/10/blog-post_173.html

Slide 20

Slide 20 text

20 解決策1 : 運用 工夫でカバー

Slide 21

Slide 21 text

21 ❌運用　⭕工夫 「頑張る」だけは必ず回避しましょう - 継続できなければ続かない よくある「頑張る」の例 - 見なくていいものにひとつずつフィルタ - 通知された複数の値を脳内で結合

Slide 22

Slide 22 text

22 工夫でカバーその1 代表値でとらえる

Slide 23

Slide 23 text

23 代表値でとらえる 個々を見るのではなく、全体の動作で把握する ● サイト全体のSLI/SLO ● AutoScaling Group ● フロントエンド監視 ○ Synthetic Monitoring（シンセティック監視・合成監視） ○ Real-User Monitoring（RUM・リアルユーザー監視） ● Apdex（Application Performance Index） ● ビジネスKPI https://www.flickr.com/photos/epeirogenic/with/3070203272/

Slide 24

Slide 24 text

24 Load Averageも代表値 単位時間あたりの実行待ちとI/O待ちのプロセスの数で システムの負荷を表現したもの 待ちが多い = 負荷が高い 分散システムだと扱いづらい値ではあるが、 使いどころによってはまだ有効 https://www.techscore.com/blog/2017/12/08/how_is_load_average_calculated/

Slide 25

Slide 25 text

25 フロントエンド監視

Slide 26

Slide 26 text

26 フロントエンド監視 ユーザ・クライアントが体験する機能や動作を計測 APMと付き合わせて挙動を明らかにする https://www.irasutoya.com 合成監視 アクセスを機械的に シミュレート RUM ユーザがアクセスし た際にデータを収集 APM Application Performance Management / Monitoring

Slide 27

Slide 27 text

27 フロントエンド監視(cont.) シンセティクス = 見たいところを定期的に監視 RUM = 実際にユーザが見た時・見たところを監視 “最良のモニタリング戦略は、フロントエンドとバック エンドのソリューションを組み合わせたもの” - リアルユーザモニタリング（RUM） vs 合成モニタリン グ: 顧客体験を改善するにはどうしたらいいか - New Relic公式ブログ https://blog.newrelic.co.jp/uncategorized/synthetic-versus-real-user-monitoring/

Slide 28

Slide 28 text

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としてデータ収集 ・ホワイトボックス監視

Slide 29

Slide 29 text

29 Apdex

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

31 工夫でカバーその2 統計値でとらえる

Slide 32

Slide 32 text

32 統計値でとららえる 数値の上下に一喜一憂せず、数値の「意味」を取り出す 統計値・統計分析 ○ 複数のメトリクスを数値計算して可視化 ○ 移動平均や線形予測など パーセンタイル（分位数）p80,p99など ○ 単位時間当たりの全ての数字を昇順ソートして、 全体のパーセンテージにあたる値 ○ 平均とは違い、突発的なスパイクを除外できる https://stopcovid19.metro.tokyo.lg.jp/

Slide 33

Slide 33 text

33 動的な閾値設定 外れ値（Outlier）検知 ふるまい（Anomaly）検知 - 通常の傾向から外れた動きの検知 - 急激な増加・減少、ルーティンとは違う動き - 統計的手法や機械学習による分類手法 閾値の設定を固定とせず、 状況に応じた検出・通知を行う https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ CloudWatch_Anomaly_Detection.html

Slide 34

Slide 34 text

34 ビジネスKPIも大事なメトリクス 政治層のひとが見てくれるダッシュボードを整備するこ とで、「上司に報告」という重大な業務が効率化できる ○ サービスを見るのはエンジニアも必要な視点 ○ SLOの判断基準になる ※事例を後述

Slide 35

Slide 35 text

35 工夫でカバーその3 可視化 Visualization

Slide 36

Slide 36 text

36 可視化 = データの意味づけ コンテキストに基づいて情報を整理 Information（情報）から Intelligence（分析された知識）へ https://www.history.com/topics/us-government/history-of-the-cia

Slide 37

Slide 37 text

37 可視化 = 情報を素早く把握するための方法 アンスコムの例（Anscombe’s quartet） 可視化することで特徴が見えてくる https://ja.wikipedia.org/wiki/アンスコムの例

Slide 38

Slide 38 text

38 可視化 = 情報を素早く把握するための方法 “データ可視化の主なメリットは三つがあります： 1. 現状を把握し、課題やその原因を発見することで、 迅速な対応が可能になる 2. 社内にデータをオープンに利用可能に、 情報を早く共有し、業務の効率を上げる 3. 社内の様々なデータを統合することで、 予測分析を行い、トレンドの洞察を得られる” データ可視化とは？その必要性と基本手法を解説 https://kirikuroda.github.io/datareporting/introduction.html

Slide 39

Slide 39 text

39 工夫でカバーその4 その他の工夫

Slide 40

Slide 40 text

40 工夫 = 効率を上げる 「見なくて良いものは見ない」は正しいか？ ○ 例) CPU利用率ってアラート投げる必要ある？ ○ 明らかに不要なものは言うまでもない （クラウドなのにH/W RAIDエラーとか…） →見なくても取っておこう ○ 分析するときには必要 ○ 収集したデータをふるい分けする 「いま見るべきもの」と「あとで見る/見そうなもの」 ○ いま見なくて良いもの→通知もしなくて良い

Slide 41

Slide 41 text

41 分類例 ● 即応が必要なもの (on-call alert) ● 対応は必要だが即応不要なもの (chat notice) ● 対応は要らないが知っておきたいもの (log info) ● 監査や障害調査のために (log-archive debug) 参考（再掲）： Lambdaのログレベル方針について、チームで話して 明文化してみた | Developers.IO https://dev.classmethod.jp/articles/lambda-log-level/

Slide 42

Slide 42 text

42 だれに通知する？ 人間に通知する→ITSやChatに直接通知 ○ 初動を早くする 機械に通知する→自動化 ● 誰も気付かなければ障害ではない ● 無事復旧できたのならオンコールは不要 ● TCP/IPの再送も自動的な復旧のひとつ ○ 許容範囲内に収まるならいちいち監視しない （逆説的に）障害であるのなら、気付けるようにすべき

Slide 43

Slide 43 text

43 どこまで細かく求めるか？ “1秒間のダウンタイムを計測するには、1秒未満の間隔 でデータを収集する必要があります” - 入門　監視 「波形を捉えるには、その波形の最大周波数の2倍を超 えた周波数で標本化する必要がある」 - シャノンの定理（標本化定理） https://pixnio.com/ja/

Slide 44

Slide 44 text

44 「海岸線の正確な長さを測定しなさい」 1kmの物差しを使うと、小さな入り江や岬が測れない 100mの物差しを使うと、ゴツゴツの岩肌が測れない 10m、1m ... スケールを変えると、いままで測れていな かったものが見えてくる 1mm、0.1mm ... 砂粒の起伏をどうやって測る？ そもそも波や、潮の満ち引きがあるなかで、 どこまで測る意味がある？ https://pixnio.com/ja/ https://www.irasutoya.com/2017/03/blog-post_421.html

Slide 45

Slide 45 text

45 基準を与えるのがSLI/SLO →SLOに必要なだけのSLIを、 　必要十分な粒度で測定しましょう https://pixnio.com/ja/ https://www.irasutoya.com/2013/03/blog-post_1704.html

Slide 46

Slide 46 text

46 ところで ここまでやっても、 やっぱり運用でカバーつらくないですか？

Slide 47

Slide 47 text

47 解決策2 : 物理 ツールで解決

Slide 48

Slide 48 text

48 「ツール」とは ソフトウェアだけに限らず、 世にあふれるメソッドも「ツール」の ひとつ 「巨人の肩の上に立つ」 巨人 = 偉大な先人の知恵を 積極的に借りよう https://en.wikipedia.org/wiki/Standing_on_the_shoulders_of_giants https://www.irasutoya.com/2019/01/blog-post_43.html

Slide 49

Slide 49 text

49 ここで紹介する「ツール」 ダッシュボード AIOps/MLOps カオスエンジニアリング SaaS ほかにもいっぱいある！ その1で引用したものも「ツール」「巨人」です

Slide 50

Slide 50 text

50 ダッシュボード

Slide 51

Slide 51 text

51 ダッシュボード = 「ひと目で分かる」 “企業内の各種ビジネスデータから重要な要点を抽出し て、ひと目で分かるように視覚化したもの” “自動車の計器盤のメタファー” - デジタルダッシュボード, Wikipedia 多くの監視・モニタリングツールは ダッシュボードのカスタマイズに対応 - CloudWatch Dashboardsなどなど https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/GettingStarted.html

Slide 52

Slide 52 text

52 ダッシュボードも進化する 対象と役割が変化すれば、 最適なダッシュボードの形態も変化する 2000 2020 https://spaceflight.nasa.gov/gallery/images/shuttle/sts-101/html/jsc2000e10522.html https://www.youtube.com/watch?v=won6Ap9JnVw

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

54 ダッシュボードはみんなのために 分かりやすく可視化 = データの民主化 “開発委託先が月に一度の運用レポートを、専門家では ない担当社員に届けるといういままでの体制から、毎分 更新される最新の運用情報が、普段慣れ親しんだビジネ ス指標と一緒に届くことで、自分たちがサービスを届け ているというライブ感とユーザーの反応をダイレクトに 共有できる” 大規模キャンペーンでの Mackerel活用で ビジネス上のKPIもダッシュボードで可視化 ～クレディセゾン～ https://mackerel.io/ja/blog/entry/customers/credit-saison

Slide 55

Slide 55 text

55 AIOps / MLOps

Slide 56

Slide 56 text

56 AIOps・MLOps AI（機械学習によるパターン認識・分類）で 情報をふるい分け・利用者にリコメンド - 予測検知 - トリアージ、ノイズの軽減 - RootCauseのサジェスト AIOpsは絶賛進化中 プレーヤーは続々 - New Relic, IBM Watson, moogsoft etc...

Slide 57

Slide 57 text

57 GameDay Chaos Engineering

Slide 58

Slide 58 text

58 GameDay あるシチュエーションを設定し、 本番さながらの環境を用意して、 日頃の備えやスキルがうまく回るかを測るもの （あるいはそれ競技化したもの） ● 自動車の衝突実験（制御された事故） + 消防訓練（経験を通じて本番に備える） + 予防接種（耐性を付ける） https://awsgamedaymicroservicestokyo.splashthat.com/ https://www.mlit.go.jp/jidosha/anzen/02assessment/car_h21/test_crash.html

Slide 59

Slide 59 text

59 Chaos Engineering 「GameDayを定期的・定常的に行う」もの - 日常的に「制御された」障害が発生する - システム・運用チームはそれに対処する - 対処 = SLO内で完結させる ● 予告なし（抜き打ち）訓練 ○ 運用担当（人間）チームが対応できるか ○ 自動対処・リカバリ（機械）は意図通りに機能するか https://www.gremlin.com/

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

61 ※未承諾広告 New Relic + Classmethod カオスエンジニアリング やってます https://classmethod.jp/news/200414-newrelic/ https://cloud.watch.impress.co.jp/docs/news/1247030.html

Slide 62

Slide 62 text

62 SaaS

Slide 63

Slide 63 text

63 運用のためのツールの運用を頑張る？ その「頑張ってる」ものは業務の本筋ですか？ 頑張ることで失っているものはありませんか？ ○ 時間 ○ 稼働 頑張らない → SaaSをいれて楽になろう

Slide 64

Slide 64 text

64 「SaaSいれて楽になろう」？ 正確に言えば、 ● SaaSだからといって、頑張らなくてよくなる わけではない ● 頑張るところが変わるだけ 本来集中したいところに集中 ● →責任共有モデル（by AWS） https://aws.amazon.com/jp/compliance/shared-responsibility-model/

Slide 65

Slide 65 text

65 ご紹介 ❖ CloudWatchファミリー ❖ Mackerel ❖ New Relic ❖ Sumo Logic ❖ その他 （基本的に弊社で扱っているもの）

Slide 66

Slide 66 text

66 免責事項　その4 完全に適材適所・ケースバイケースの世界なので、 正解は「まず使ってみる」 SaaSは日々開発が続き進歩しているので、いまの情報 が明日正しいとは限らない なんとなく「この辺かな？」と当たりを付けるときにご 参照頂ければ

Slide 67

Slide 67 text

67 CloudWatchファミリー ※X-RayなどCloudWatchを冠さないものも含む ● 全ての基本 ● サードパーティ製品はCloudWatchに依存 ● 最初から用意されている ● 使いこなすために頑張る必要がある ○ 個々の機能が完全に統合されていない、 ダッシュボード機能の不足など ● 完全にAWS特化 出来ることと、他のもので補えるもの・ 補うと楽なもの・補うべきものを認識して使う https://aws.amazon.com/jp/cloudwatch/

Slide 68

Slide 68 text

68 Mackerel ● 純国産。はじめの一歩 ● 楽に始められる、それでいて見た目や操作性も 良い、拡張性も分かりやすい ● 監視をしっかりやりたい、でもどこから？ となっているひと向け ○ Sな監視をしていた方々が入りやすいと思われる ● 使っていくと物足りなくなってくるところはある 次の一手：拡張・作り込む、単分野SaaSと組み合わせ る、統合型SaaSに乗り換える https://mackerel.io/ja/

Slide 69

Slide 69 text

69 New Relic ● 自他共に認める「可観測性プラットフォーム」 ● 可視化、パフォーマンスチューニングの強い味方 ● なんでもそろってる。 全ての機能はAPMのためにある ○ なので、例えばインフラ監視だけのために入れるメリッ トは薄い（ないわけではもちろん無い） ● 逆にいうと、全体像の把握や使いこなしに力が要る ● Lambdaやk8sにももちろん対応 目的のために邁進できる強い組織の強い味方 https://newrelic.co.jp/

Slide 70

Slide 70 text

70 Sumo Logic ● 純SaaS型SIEM ● 一方でLambdaやk8sのダッシュボードもある ○ SIEMとして入れて応用するのはよさそう ● ありとあらゆるプラットフォームのログを収集して 一元管理・可視化 ● メトリック収集機能もある ○ ただしログ分析の補助的なものにとどまる ログ収集・集積・可視化 + 脅威評価・分析 https://www.sumologic.jp/

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

72 その他にもSaaSはたくさん Datadog インフラエンジニアが持ち得る最強のツール 全方位に隙なし Cloud Monitor（旧Stackdriver） Googleの考える最強の監視システム Pingdom フロントエンド監視特化 SignalFx, Instana APM特化。リアルタイム指向 Sysdig monitor セキュリティ用途強め。クローズドボックス監視 AirBreak トレースログに特化。OSS実装のerrbitも Epsagon 分散トレーシング特化。エージェントレス 他にも Humio, AppDynamics, Dynatrace ...（書き切れません） 各ツールは独自の特徴と特色、UI/UX、出自と得意分野をもっています。 いろいろ試して自分たちにあったものを！

Slide 73

Slide 73 text

73 ※未承諾広告 気になったSaaSは Developers.IOで検索❗ https://dev.classmethod.jp/

Slide 74

Slide 74 text

74 押さえておきたい ● Prometheus + Grafana ● OpenTelemetry, OpenMetrics

Slide 75

Slide 75 text

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/

Slide 76

Slide 76 text

76 OpenTelemetry, OpenMetrics トレース情報・メトリック情報のCNCFによる標準化 ※現在ベータ・Coming soon https://opentelemetry.io/ https://openmetrics.io/

Slide 77

Slide 77 text

77 Tips・注意点

Slide 78

Slide 78 text

78 Zabbixは？ まだまだ現役。進化も開発も続いている ‘20/07現在でZabbix5.0 必要なのは、どのツールが一番合うかを考えること - 監視対象、運用体制 - 盲目的に「あれがいい」「これはダメ」というのは やめよう - （その点で、SaaSは始めやすく止めやすい） https://www.zabbix.com/jp

Slide 79

Slide 79 text

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/

Slide 80

Slide 80 text

80 監視エージェントの影響を最小限に コスト的にも性能的にも、 エージェントが足を引っ張っては意味がない いち案：サンプリングという考え方 ○ 同一集団のなかで1つだけエージェントを動かす ○ あるいは、トラフィック全体の一部を計測用に流す ● 特定条件にあう場合においてのみエージェントを 導入 or 起動する仕組み

Slide 81

Slide 81 text

81 テクニックとしては考えられるが、それによって取得で きるデータに制限がでたり、データそのものの有効性に 疑問符が付くようでは本末転倒 - Q : Real-User Monitoring用のJavaScriptを 　　lazy load（遅延読込）できないか？ - A : できはするけど、本当に？ まず各ベンダが推奨するBest practiceにそって 組み込もう 影響の少ない組み込み方は？

Slide 82

Slide 82 text

82 まとめ

Slide 83

Slide 83 text

83 まとめ 監視(Monitoring)は守りのためでなく、 いまのシステム・サイトをより良くするためのもの 本来の目的に注力するために、 巨人の肩に積極的に乗りましょう ※弊社もお手伝いします！ https://www.irasutoya.com/2019/01/blog-post_43.html

Slide 84

Slide 84 text

84