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

監視からオブザーバビリティへ〜オブザーバビリティの成熟度/From Monitoring to...

監視からオブザーバビリティへ〜オブザーバビリティの成熟度/From Monitoring to Observability - Maturity of Observability

2023/5/23開催「オブザーバビリティ最前線 〜 事例LTから学ぶ、オブザーバビリティの成熟度〜」

New Relic

May 23, 2023
Tweet

More Decks by New Relic

Other Decks in Technology

Transcript

  1. © 2023 New Relic, Inc. All rights reserved オブザーバビリティ最前線 


    〜 事例LTから学ぶ、オブザーバビリティの成熟 度〜 
 伊藤 覚宏
 Senior Technical Support Engineer

  2. © 2023 New Relic, Inc. All rights reserved ゴール
 •

    オブザーバビリティについての全体ステップ がわかり、今自社がどのフェーズにいるの かわかる
 • オブザーバビリティの次のアクションがわか る
 • オブザーバビリティについてどのように指標 を計測することができるか、セキュリティへ の取り組みについても理解できる

  3. © 2023 New Relic, Inc. All rights reserved New Relic

    会社概要 日本法人 設立 代表者 シェア 本社 事業内容 設立 代表者 上場 従業員数 顧客数 売上 New Relic 株式会社 2018年8月 小西 真一朗(代表取締役社長) 国内オブザーバビリティ市場シェア No.1* New Relic, Inc. (HQ: サンフランシスコ、USA) オブザーバビリティ・プラットフォームの提供 2008年 ビル・ステイプルズ(Bill Staples - CEO) ニューヨーク証券取引所: NEWR 約2,200人 15,000 以上 $786M(2022年3月末) 3 *出典:株式会社テクノ・システム・リサーチ 創業者 ルー・サーニー (Lew Cirne)
  4. © 2022 New Relic, Inc. All rights reserved © 2023

    New Relic, Inc. All rights reserved What is New Relic ? L e w C i r n e N e w R e l i c
  5. © 2023 New Relic, Inc. All rights reserved 自己紹介 伊藤

    覚宏 (いとう あきひろ) New Relic 株式会社 シニアテクニカルサポートエンジニア • OSS監視ソリューションのテクニカルサポート、クラウド環境の構築・設計、運用設 計の経験を活かしお客様をサポートいたします。 – 専門:監視、クラウドアーキテクト、AWS、 VMware、Zabbix • インフラエンジニア • クラウドエンジニア • サポートエンジニア
 

  6. © 2023 New Relic, Inc. All rights reserved Agenda
 01


    オブザーバビリティの成熟度モデルと 監視からオブザーバビリティ へ
 02
 サービスレベル管理 (SLM) とは? - 計測すべき指標と活用につい て-
 03
 DevSecOpsへの展開 - 全てのチームの能力を最大限に引き出す

  7. © 2023 New Relic, Inc. All rights reserved システムの異常を知るための仕組み: 監視

    サーバー異常、停止 人が検知 監視さえできていれば、システム障害を防ぎ安定稼働を実現できる? 監視(Monitoring): あるシステムやそのシステムのコンポーネントの振る舞いや出力を観察 しチェックし続ける行為 通知 出典: 入門監視(O’reilly, 2019)
  8. その答えは、NO “アマゾンはシステム管理のプロセス を改善するために25年もの旅をして きました。そして、システムを管理す るには 「監視するだけで充分」 という 考えを捨てました。 大量のデータやログをどのように分 析するか、問題が発生したときにどの

    ように問題を解決し話し合うかに至る まで、業務に対する全体的なアプ ローチに乗り出しています。 まさにそれこそが「オブザーバビリ ティ (可観測性) 」なのです。” Dr. Werner Vogels Vice President and CTO of Amazon
  9. © 2023 New Relic, Inc. All rights reserved なぜ監視だけでは不十分なのか? これ以降の内容

    ITシステムの歴史と監視の変化 オブザーバビリティという概念の登場背景と監視との相違点 オブザーバビリティの実現方法
  10. © 2023 New Relic, Inc. All rights reserved ITシステムの進化と役割の変化 1960年〜

    1980年〜 2000年〜 2010年〜 2020年〜 メインフレーム オープンシステム サーバー仮想化 クラウド コンテナ・サーバレス モード1:既存業務の維持 モード2:価値の提供 業務効率化 業務拡張 事業創造 メールやドキュメントなど インターネット検索や eコマース システム = ビジネス システム=ビジネス そのものになる時代へ 業務処理 会計処理など
  11. © 2023 New Relic, Inc. All rights reserved ITシステムの進化の背景 VM

    VM VM VM メインフレーム オープンシステム サーバー仮想化 クラウド コンテナ・サーバレス 一部の社員 社員全員 世界中の人 取引先 安定稼働 利用者 少 多 重視されて いること 安定稼働 新機能追加 システムに対する需要が読めない → より簡単にスケールする仕組みへ 市場ニーズに対する早急な対応や新規需要の創出を目指す  → 基盤のコード化(IaC)やマイクロサービス化へ
  12. © 2023 New Relic, Inc. All rights reserved ITシステムの進化に伴う監視の変化 VM

    VM VM VM メインフレーム オープンシステム サーバー仮想化 クラウド コンテナ・サーバレス サーバー 仮想マシン コンテナ クラウドリソース 監視対象 の数 少 多 監視の観点 システム内部 ユーザー体験 監視対象はより多く、より複雑に ユーザー視点の監視が重視されるように 監視対象 の状態 静的 動的 監視対象は常に変化するように
  13. © 2023 New Relic, Inc. All rights reserved 監視の対象と観点が変化する
 過去のシステム


    アプリ
 (モノリシック)
 基盤
 (オンプレ)
 近年のシステム
 基盤
 (オンプレ・ クラウド)
 リソース抽象化
 (仮想化、コンテナ 等)
 アプリ
 (マイクロ サービス)
 • 構成要素がシンプル
 • システム変更が少ない
 • 基盤を監視していればアプリの振る舞いと サービスの状態も予測できる
 • 構成要素が複雑
 • 新機能リリースなど変化が当たり前 
 • 基盤を監視してもサービスの状態を把握 できない→ユーザー体験の監視へ 新機能
  14. © 2023 New Relic, Inc. All rights reserved クラウドの システムモデル

    • 1台のサーバを見るので は無く無数のサーバをク ラスタとして管理する • アプリはクラスタメン バーの個々のサーバー 内で動作する • オートスケールやオート ヒーリングを適切に動作 させる事が重要  オンプレミスからIaaSへ • APIによる連携 • オートヒーリングやオー トスケールは基本機能と して組み込まれており ユーザーは意識しない • 個々のコンテナでは無く システム集合が動作し ていることが重要 IaaSからコンテナへ
  15. © 2023 New Relic, Inc. All rights reserved IT環境のシステムモデルの遷移 •

    ペットモデル・キャトルモデル Microsoft Bill Baker 提唱 オルガノモデル New Relic 伊藤 覚宏 提唱 • 小数の個別サーバーを管理する • 大事なペットを守るような運用 • システムはステートフル • モノリシックな実装 ペットモデル • 同じ機能を持った複数のサーバーをクラス タとして運用 • 家畜のように群れとしての運用 • AutoScalingやAutoHealingを設定して システムの堅牢性を確保 • アプリサーバーやDBサーバーは分離され ているが、実装自体はモノリシックに近い キャトルモデル(家畜) • コンテナによるオーケストレーション • コンテナの数やスペックはマニュフェストに より定義され、問題があれば自動的に再 配置される • 臓器のように個々のコンテナ(細胞)が複 製やアポトーシスを行う • 個々のコンテナの死活では無くシステム自 体が機能を提供している事が重要 オルガノモデル(臓器)※
  16. © 2023 New Relic, Inc. All rights reserved 監視にまつわる新たな課題 監視を1つ1つ網羅的に


    設定する労力が甚大 アラートが出ても、
 解釈と原因特定が困難 ブラウザ アプリ モバイル アプリ アプリ
 ロジック DB
 サーバー コンテナ クラウド ?
  17. © 2023 New Relic, Inc. All rights reserved 監視にまつわる新たな課題 新機能などを既存の


    監視設定でカバーできない 想定外のアクセスなど前例の
 ない問題への対処が困難 従来の機能 新機能 ?
  18. © 2023 New Relic, Inc. All rights reserved 監視にまつわる新たな課題 ユーザー体験の計測方法の確立が

    難しい ユーザー体験の悪化の原因の
 調査が困難 ユーザーの手元で今起こってい ることを知りたい ?
  19. © 2023 New Relic, Inc. All rights reserved 従来の監視の限界 システムがビジネスに寄与する割合は大きくなっているため、

    ビジネス影響は甚大に 予め対象を決めて監視を
 することの限界
 アラートから原因を特定し
 迅速に復旧することの限界
 問題に気づかず、復旧のための 
 初動が遅れる
 復旧に時間がかかり、ダウンタイムが長 引く

  20. © 2023 New Relic, Inc. All rights reserved 解決策: オブザーバビリティ(可観測性)

    システム全体を可視化し、異 常を知らせる ありとあらゆるコン ポーネントの稼働 状況を取得可能な 状態にし、リアルタ イムで収集する データの関連付け を行う システムの異常にすぐに気づき、素早く原因にたどり着くことが可能
  21. © 2023 New Relic, Inc. All rights reserved 監視からオブザーバビリティへ •

    まずは全てのデータを収集する • データの関連付けと可視化を自動で行い、シ ステムの全容を把握できる • いつもと異なる振る舞いを自動で認識 監視 オブザーバビリティ • あらかじめ見るものを決め、それに合わせてデー タを収集する • 個々のデータは独立 • 一定のしきい値を超えたら異常とするよう設定
  22. © 2023 New Relic, Inc. All rights reserved 監視からオブザーバビリティへ •

    各種センサー、記録係を付けて生活する • データは自動で分析され可視化される • いつもと異なる値が出たら生活に注意する 監視 オブザーバビリティ • 明らかに病気の症状が出る • 症状が出たら医者にかかる
  23. © 2023 New Relic, Inc. All rights reserved 監視からオブザーバビリティへ •

    監視では障害通知があると、 CPUやメモリなどの値を確認します。 死活監視 反応があるか Ping Metric 体温・血圧 CPU使用率/メモリ使用率 Log 「頭が痛い」 Errorメッセージ 原因はわからないけど、異常は見られないので頭痛薬飲んでおきましょう >とりあえず再起動
  24. © 2023 New Relic, Inc. All rights reserved 監視からオブザーバビリティへ •

    オブザーバビリティではより多くの情報を収集し、何が起こったのかを明らかにして根本原因に対処し ます。 • 障害ではなくて「いつもと違う」を検知して対処します。 Metric 気温・気圧・湿度・体温・血圧 CPU/メモリ使用率・プロセス・ User満足度 ・応答時間 Event 昨日19時から2時まで飲みに行った リクエスト数・プログラム処理時間 (トランザクション) Log 「今朝から頭が痛い」 Errorlog、スタックトレース Trace 飲み屋でBさんとテキーラ10杯飲んだ DB呼び出し、API呼び出し 二日酔いですね、この頭痛薬と胃腸薬を飲みましょう 深酒しちゃだめですよ、節制しましょう >原因の究明と、システムの改善
  25. © 2023 New Relic, Inc. All rights reserved 監視ツールとオブザーバービリティの違い アプリケーション

    監視 インフラ 監視 ネットワーク 監視 顧客体験 監視 オブザーバビリティ ビジネス 監視 監視は個々のデータを必 要に応じて収集するが、 オブザーバビリティは全て を収集する
  26. © 2022 New Relic, Inc. All rights reserved Observability成熟度モデル Data

    Driven • データドリブンによる経営判断 • 素早い市場投入 • CSAT/Netスコアの改善 Predictive 予測的 Proactive 積極的 Reactive 受動的 • 顧客満足度 • SLOによる経営計画と判断 • 市場投入数 特徴 KPI Getting Started 4 2 3 0 1 • New Relicによる運用 • 顧客体験の改善 • ちょうどよいスケーリング • MTTD(Mean Time To Discover)の改善 • サービスレベルの計測 • デジタル顧客体験の策定 • MTTR(Mean Time To Repair)の改善 • アプリケーションパフォーマンスの気付き • 顧客に影響がある事象への対応の改善 • パフォーマンス計測 • スケールする製品の投入計画 • サービスレベルの維持 • 重大な障害率 • エラーバジェット消費率 • SLOに関連するアラート率 • ビジネスメトリックの改善率 • 平均MTTD • SLOが定義されているサービスの割合 • クリティカル・ケイパビリティの策定の割合 • 平均MTTR • パフォーマンス低下を伴う障害率 • サービス停止を伴う障害率 • New Relicでの監視率 • データの量 成熟度