Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Seigo Watanabe

July 03, 2020
Tweet

More Decks by Seigo Watanabe

Other Decks in Technology

Transcript

  1. 後回しに しない ❗ 2 監視・ログ分析を最初から始める イマドキの事情と理由・その 〜 解 決 編

    〜 渡辺聖剛 ソリューションアーキテクト AWS事業本部 パートナーアライアンス部 2020.07.03
  2. 3 自己紹介 渡辺聖剛 ( Seigo Watanabe ) • クラスメソッド株式会社 AWS

    事業本部 パートナーアライアンス部 • 前職までは 所謂インフラエンジニア • 運用・監視(Monitoring) • 好きな AWS サービス ◦ ACM, Route 53 ◦ AWS Systems Manager https://dev.classmethod.jp/author/watanabe-seigo/
  3. 23 代表値でとらえる 個々を見るのではなく、全体の動作で把握する • サイト全体のSLI/SLO • AutoScaling Group • フロントエンド監視

    ◦ Synthetic Monitoring(シンセティック監視・合成監視) ◦ Real-User Monitoring(RUM・リアルユーザー監視) • Apdex(Application Performance Index) • ビジネスKPI https://www.flickr.com/photos/epeirogenic/with/3070203272/
  4. 27 フロントエンド監視(cont.) シンセティクス = 見たいところを定期的に監視 RUM = 実際にユーザが見た時・見たところを監視 “最良のモニタリング戦略は、フロントエンドとバック エンドのソリューションを組み合わせたもの”

    - リアルユーザモニタリング(RUM) vs 合成モニタリン グ: 顧客体験を改善するにはどうしたらいいか - New Relic公式ブログ https://blog.newrelic.co.jp/uncategorized/synthetic-versus-real-user-monitoring/
  5. 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としてデータ収集 ・ホワイトボックス監視
  6. 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
  7. 32 統計値でとららえる 数値の上下に一喜一憂せず、数値の「意味」を取り出す 統計値・統計分析 ◦ 複数のメトリクスを数値計算して可視化 ◦ 移動平均や線形予測など パーセンタイル(分位数)p80,p99など ◦

    単位時間当たりの全ての数字を昇順ソートして、 全体のパーセンテージにあたる値 ◦ 平均とは違い、突発的なスパイクを除外できる https://stopcovid19.metro.tokyo.lg.jp/
  8. 33 動的な閾値設定 外れ値(Outlier)検知 ふるまい(Anomaly)検知 - 通常の傾向から外れた動きの検知 - 急激な増加・減少、ルーティンとは違う動き - 統計的手法や機械学習による分類手法

    閾値の設定を固定とせず、 状況に応じた検出・通知を行う https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ CloudWatch_Anomaly_Detection.html
  9. 38 可視化 = 情報を素早く把握するための方法 “データ可視化の主なメリットは三つがあります: 1. 現状を把握し、課題やその原因を発見することで、 迅速な対応が可能になる 2. 社内にデータをオープンに利用可能に、

    情報を早く共有し、業務の効率を上げる 3. 社内の様々なデータを統合することで、 予測分析を行い、トレンドの洞察を得られる” データ可視化とは?その必要性と基本手法を解説 https://kirikuroda.github.io/datareporting/introduction.html
  10. 40 工夫 = 効率を上げる 「見なくて良いものは見ない」は正しいか? ◦ 例) CPU利用率ってアラート投げる必要ある? ◦ 明らかに不要なものは言うまでもない

    (クラウドなのにH/W RAIDエラーとか…) →見なくても取っておこう ◦ 分析するときには必要 ◦ 収集したデータをふるい分けする 「いま見るべきもの」と「あとで見る/見そうなもの」 ◦ いま見なくて良いもの→通知もしなくて良い
  11. 41 分類例 • 即応が必要なもの (on-call alert) • 対応は必要だが即応不要なもの (chat notice)

    • 対応は要らないが知っておきたいもの (log info) • 監査や障害調査のために (log-archive debug) 参考(再掲): Lambdaのログレベル方針について、チームで話して 明文化してみた | Developers.IO https://dev.classmethod.jp/articles/lambda-log-level/
  12. 42 だれに通知する? 人間に通知する→ITSやChatに直接通知 ◦ 初動を早くする 機械に通知する→自動化 • 誰も気付かなければ障害ではない • 無事復旧できたのならオンコールは不要

    • TCP/IPの再送も自動的な復旧のひとつ ◦ 許容範囲内に収まるならいちいち監視しない (逆説的に)障害であるのなら、気付けるようにすべき
  13. 44 「海岸線の正確な長さを測定しなさい」 1kmの物差しを使うと、小さな入り江や岬が測れない 100mの物差しを使うと、ゴツゴツの岩肌が測れない 10m、1m ... スケールを変えると、いままで測れていな かったものが見えてくる 1mm、0.1mm ...

    砂粒の起伏をどうやって測る? そもそも波や、潮の満ち引きがあるなかで、 どこまで測る意味がある? https://pixnio.com/ja/ https://www.irasutoya.com/2017/03/blog-post_421.html
  14. 51 ダッシュボード = 「ひと目で分かる」 “企業内の各種ビジネスデータから重要な要点を抽出し て、ひと目で分かるように視覚化したもの” “自動車の計器盤のメタファー” - デジタルダッシュボード, Wikipedia

    多くの監視・モニタリングツールは ダッシュボードのカスタマイズに対応 - CloudWatch Dashboardsなどなど https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/GettingStarted.html
  15. 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
  16. 59 Chaos Engineering 「GameDayを定期的・定常的に行う」もの - 日常的に「制御された」障害が発生する - システム・運用チームはそれに対処する - 対処

    = SLO内で完結させる • 予告なし(抜き打ち)訓練 ◦ 運用担当(人間)チームが対応できるか ◦ 自動対処・リカバリ(機械)は意図通りに機能するか https://www.gremlin.com/
  17. 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
  18. 65 ご紹介 ❖ CloudWatchファミリー ❖ Mackerel ❖ New Relic ❖

    Sumo Logic ❖ その他 (基本的に弊社で扱っているもの)
  19. 67 CloudWatchファミリー ※X-RayなどCloudWatchを冠さないものも含む • 全ての基本 • サードパーティ製品はCloudWatchに依存 • 最初から用意されている •

    使いこなすために頑張る必要がある ◦ 個々の機能が完全に統合されていない、 ダッシュボード機能の不足など • 完全にAWS特化 出来ることと、他のもので補えるもの・ 補うと楽なもの・補うべきものを認識して使う https://aws.amazon.com/jp/cloudwatch/
  20. 68 Mackerel • 純国産。はじめの一歩 • 楽に始められる、それでいて見た目や操作性も 良い、拡張性も分かりやすい • 監視をしっかりやりたい、でもどこから? となっているひと向け

    ◦ Sな監視をしていた方々が入りやすいと思われる • 使っていくと物足りなくなってくるところはある 次の一手:拡張・作り込む、単分野SaaSと組み合わせ る、統合型SaaSに乗り換える https://mackerel.io/ja/
  21. 69 New Relic • 自他共に認める「可観測性プラットフォーム」 • 可視化、パフォーマンスチューニングの強い味方 • なんでもそろってる。 全ての機能はAPMのためにある

    ◦ なので、例えばインフラ監視だけのために入れるメリッ トは薄い(ないわけではもちろん無い) • 逆にいうと、全体像の把握や使いこなしに力が要る • Lambdaやk8sにももちろん対応 目的のために邁進できる強い組織の強い味方 https://newrelic.co.jp/
  22. 70 Sumo Logic • 純SaaS型SIEM • 一方でLambdaやk8sのダッシュボードもある ◦ SIEMとして入れて応用するのはよさそう •

    ありとあらゆるプラットフォームのログを収集して 一元管理・可視化 • メトリック収集機能もある ◦ ただしログ分析の補助的なものにとどまる ログ収集・集積・可視化 + 脅威評価・分析 https://www.sumologic.jp/
  23. 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
  24. 72 その他にもSaaSはたくさん Datadog インフラエンジニアが持ち得る最強のツール 全方位に隙なし Cloud Monitor(旧Stackdriver) Googleの考える最強の監視システム Pingdom フロントエンド監視特化

    SignalFx, Instana APM特化。リアルタイム指向 Sysdig monitor セキュリティ用途強め。クローズドボックス監視 AirBreak トレースログに特化。OSS実装のerrbitも Epsagon 分散トレーシング特化。エージェントレス 他にも Humio, AppDynamics, Dynatrace ...(書き切れません) 各ツールは独自の特徴と特色、UI/UX、出自と得意分野をもっています。 いろいろ試して自分たちにあったものを!
  25. 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/
  26. 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/
  27. 81 テクニックとしては考えられるが、それによって取得で きるデータに制限がでたり、データそのものの有効性に 疑問符が付くようでは本末転倒 - Q : Real-User Monitoring用のJavaScriptを   lazy

    load(遅延読込)できないか? - A : できはするけど、本当に? まず各ベンダが推奨するBest practiceにそって 組み込もう 影響の少ない組み込み方は?
  28. 84