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

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

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 オブザーバビリティの 成熟度モデル
 
 
監視からオブザーバビリティへ

8. © 2023 New Relic, Inc. All rights reserved システムの異常を知るための仕組み: 監視 サーバー異常、停止 人が検知 監視さえできていれば、システム障害を防ぎ安定稼働を実現できる？ 監視(Monitoring): あるシステムやそのシステムのコンポーネントの振る舞いや出力を観察 しチェックし続ける行為 通知 出典: 入門監視(O’reilly, 2019)
9. その答えは、NO “アマゾンはシステム管理のプロセス を改善するために25年もの旅をして きました。そして、システムを管理す るには 「監視するだけで充分」 という 考えを捨てました。 大量のデータやログをどのように分 析するか、問題が発生したときにどの ように問題を解決し話し合うかに至る まで、業務に対する全体的なアプ ローチに乗り出しています。 まさにそれこそが「オブザーバビリ ティ (可観測性) 」なのです。” Dr. Werner Vogels Vice President and CTO of Amazon
10. © 2023 New Relic, Inc. All rights reserved なぜ監視だけでは不十分なのか？ これ以降の内容 ITシステムの歴史と監視の変化 オブザーバビリティという概念の登場背景と監視との相違点 オブザーバビリティの実現方法
11. © 2023 New Relic, Inc. All rights reserved ITシステムの進化と監視の変化
12. © 2023 New Relic, Inc. All rights reserved ITシステムの進化と役割の変化 1960年〜 1980年〜 2000年〜 2010年〜 2020年〜 メインフレーム オープンシステム サーバー仮想化 クラウド コンテナ・サーバレス モード1：既存業務の維持 モード2：価値の提供 業務効率化 業務拡張 事業創造 メールやドキュメントなど インターネット検索や eコマース システム = ビジネス システム＝ビジネス そのものになる時代へ 業務処理 会計処理など
13. © 2023 New Relic, Inc. All rights reserved ITシステムの進化の背景 VM VM VM VM メインフレーム オープンシステム サーバー仮想化 クラウド コンテナ・サーバレス 一部の社員 社員全員 世界中の人 取引先 安定稼働 利用者 少 多 重視されて いること 安定稼働 新機能追加 システムに対する需要が読めない → より簡単にスケールする仕組みへ 市場ニーズに対する早急な対応や新規需要の創出を目指す 　→　基盤のコード化(IaC)やマイクロサービス化へ
14. © 2023 New Relic, Inc. All rights reserved ITシステムの進化に伴う監視の変化 VM VM VM VM メインフレーム オープンシステム サーバー仮想化 クラウド コンテナ・サーバレス サーバー 仮想マシン コンテナ クラウドリソース 監視対象 の数 少 多 監視の観点 システム内部 ユーザー体験 監視対象はより多く、より複雑に ユーザー視点の監視が重視されるように 監視対象 の状態 静的 動的 監視対象は常に変化するように
15. © 2023 New Relic, Inc. All rights reserved 監視の対象と観点が変化する
 過去のシステム
 アプリ
 (モノリシック)
 基盤
 (オンプレ)
 近年のシステム
 基盤
 (オンプレ・ クラウド)
 リソース抽象化
 (仮想化、コンテナ 等)
 アプリ
 (マイクロ サービス)
 • 構成要素がシンプル
 • システム変更が少ない
 • 基盤を監視していればアプリの振る舞いと サービスの状態も予測できる
 • 構成要素が複雑
 • 新機能リリースなど変化が当たり前 
 • 基盤を監視してもサービスの状態を把握 できない→ユーザー体験の監視へ 新機能
16. © 2023 New Relic, Inc. All rights reserved クラウドの システムモデル • 1台のサーバを見るので は無く無数のサーバをク ラスタとして管理する • アプリはクラスタメン バーの個々のサーバー 内で動作する • オートスケールやオート ヒーリングを適切に動作 させる事が重要 　オンプレミスからIaaSへ • APIによる連携 • オートヒーリングやオー トスケールは基本機能と して組み込まれており ユーザーは意識しない • 個々のコンテナでは無く システム集合が動作し ていることが重要 IaaSからコンテナへ
17. © 2023 New Relic, Inc. All rights reserved IT環境のシステムモデルの遷移 • ペットモデル・キャトルモデル Microsoft Bill Baker 提唱 オルガノモデル New Relic 伊藤 覚宏 提唱 • 小数の個別サーバーを管理する • 大事なペットを守るような運用 • システムはステートフル • モノリシックな実装 ペットモデル • 同じ機能を持った複数のサーバーをクラス タとして運用 • 家畜のように群れとしての運用 • AutoScalingやAutoHealingを設定して システムの堅牢性を確保 • アプリサーバーやDBサーバーは分離され ているが、実装自体はモノリシックに近い キャトルモデル（家畜） • コンテナによるオーケストレーション • コンテナの数やスペックはマニュフェストに より定義され、問題があれば自動的に再 配置される • 臓器のように個々のコンテナ（細胞）が複 製やアポトーシスを行う • 個々のコンテナの死活では無くシステム自 体が機能を提供している事が重要 オルガノモデル（臓器）※
18. © 2023 New Relic, Inc. All rights reserved 監視から オブザーバビリティへ
19. © 2023 New Relic, Inc. All rights reserved 近年のシステム監視　3つの特徴 システムの構成要素が多い システムの変化が当たり前 ユーザー体験が重要 1 2 3
20. © 2023 New Relic, Inc. All rights reserved 監視にまつわる新たな課題 監視を1つ1つ網羅的に
 設定する労力が甚大 アラートが出ても、
 解釈と原因特定が困難 ブラウザ アプリ モバイル アプリ アプリ
 ロジック DB
 サーバー コンテナ クラウド ？
21. © 2023 New Relic, Inc. All rights reserved 監視にまつわる新たな課題 新機能などを既存の
 監視設定でカバーできない 想定外のアクセスなど前例の
 ない問題への対処が困難 従来の機能 新機能 ？
22. © 2023 New Relic, Inc. All rights reserved 監視にまつわる新たな課題 ユーザー体験の計測方法の確立が 難しい ユーザー体験の悪化の原因の
 調査が困難 ユーザーの手元で今起こってい ることを知りたい ？
23. © 2023 New Relic, Inc. All rights reserved 従来の監視の限界 システムがビジネスに寄与する割合は大きくなっているため、 ビジネス影響は甚大に 予め対象を決めて監視を
 することの限界
 アラートから原因を特定し
 迅速に復旧することの限界
 問題に気づかず、復旧のための 
 初動が遅れる
 復旧に時間がかかり、ダウンタイムが長 引く

24. © 2023 New Relic, Inc. All rights reserved 解決策: オブザーバビリティ(可観測性) システム全体を可視化し、異 常を知らせる ありとあらゆるコン ポーネントの稼働 状況を取得可能な 状態にし、リアルタ イムで収集する データの関連付け を行う システムの異常にすぐに気づき、素早く原因にたどり着くことが可能
25. © 2023 New Relic, Inc. All rights reserved 監視からオブザーバビリティへ • まずは全てのデータを収集する • データの関連付けと可視化を自動で行い、シ ステムの全容を把握できる • いつもと異なる振る舞いを自動で認識 監視 オブザーバビリティ • あらかじめ見るものを決め、それに合わせてデー タを収集する • 個々のデータは独立 • 一定のしきい値を超えたら異常とするよう設定
26. © 2023 New Relic, Inc. All rights reserved 監視からオブザーバビリティへ • 各種センサー、記録係を付けて生活する • データは自動で分析され可視化される • いつもと異なる値が出たら生活に注意する 監視 オブザーバビリティ • 明らかに病気の症状が出る • 症状が出たら医者にかかる
27. © 2023 New Relic, Inc. All rights reserved 監視からオブザーバビリティへ • 監視では障害通知があると、 CPUやメモリなどの値を確認します。 死活監視 反応があるか Ping Metric 体温・血圧 CPU使用率/メモリ使用率 Log 「頭が痛い」 Errorメッセージ 原因はわからないけど、異常は見られないので頭痛薬飲んでおきましょう ＞とりあえず再起動
28. © 2023 New Relic, Inc. All rights reserved 監視からオブザーバビリティへ • オブザーバビリティではより多くの情報を収集し、何が起こったのかを明らかにして根本原因に対処し ます。 • 障害ではなくて「いつもと違う」を検知して対処します。 Metric 気温・気圧・湿度・体温・血圧 CPU/メモリ使用率・プロセス・ User満足度 ・応答時間 Event 昨日19時から2時まで飲みに行った リクエスト数・プログラム処理時間 （トランザクション） Log 「今朝から頭が痛い」 Errorlog、スタックトレース Trace 飲み屋でBさんとテキーラ10杯飲んだ DB呼び出し、API呼び出し 二日酔いですね、この頭痛薬と胃腸薬を飲みましょう 深酒しちゃだめですよ、節制しましょう ＞原因の究明と、システムの改善
29. © 2023 New Relic, Inc. All rights reserved 監視ツールとオブザーバービリティの違い アプリケーション 監視 インフラ 監視 ネットワーク 監視 顧客体験 監視 オブザーバビリティ ビジネス 監視 監視は個々のデータを必 要に応じて収集するが、 オブザーバビリティは全て を収集する
30. © 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での監視率 • データの量 成熟度