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

© 2023 New Relic, Inc. All rights reserved
オブザーバビリティ最前線  
〜事例LTから学ぶ、オブザーバビリティの成熟
度〜
 
伊藤覚宏 
Senior Technical Support Engineer 

View Slide

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

View Slide

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)

View Slide

What is New Relic ?
L e w　C i r n e
N e w　R e l i c

View Slide

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

View Slide

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

View Slide

オブザーバビリティの
成熟度モデル 
 
 監視からオブザーバビリティへ 

View Slide

システムの異常を知るための仕組み: 監視
サーバー異常、停止人が検知
監視さえできていれば、システム障害を防ぎ安定稼働を実現できる？
監視(Monitoring): あるシステムやそのシステムのコンポーネントの振る舞いや出力を観察
しチェックし続ける行為
通知
出典: 入門監視(O’reilly, 2019)

View Slide

その答えは、NO
“アマゾンはシステム管理のプロセス
を改善するために25年もの旅をして
きました。そして、システムを管理す
るには「監視するだけで充分」という
考えを捨てました。
大量のデータやログをどのように分
析するか、問題が発生したときにどの
ように問題を解決し話し合うかに至る
まで、業務に対する全体的なアプ
ローチに乗り出しています。
まさにそれこそが「オブザーバビリ
ティ (可観測性) 」なのです。”
Dr. Werner Vogels
Vice President and CTO of Amazon

View Slide

なぜ監視だけでは不十分なのか？
これ以降の内容
ITシステムの歴史と監視の変化
オブザーバビリティという概念の登場背景と監視との相違点
オブザーバビリティの実現方法

View Slide

ITシステムの進化と監視の変化

View Slide

ITシステムの進化と役割の変化
1960年〜 1980年〜 2000年〜 2010年〜 2020年〜
メインフレームオープンシステムサーバー仮想化クラウドコンテナ・サーバレス
モード1：既存業務の維持
モード2：価値の提供
業務効率化業務拡張事業創造
メールやドキュメントなどインターネット検索や eコマースシステム = ビジネス
システム＝ビジネス
そのものになる時代へ
業務処理
会計処理など

View Slide

ITシステムの進化の背景
VM VM VM VM
一部の社員社員全員世界中の人
取引先
安定稼働
利用者少多
重視されて
いること
安定稼働新機能追加
システムに対する需要が読めない → より簡単にスケールする仕組みへ
市場ニーズに対する早急な対応や新規需要の創出を目指す
　→　基盤のコード化(IaC)やマイクロサービス化へ

View Slide

ITシステムの進化に伴う監視の変化
VM VM VM VM
サーバー仮想マシンコンテナ
クラウドリソース
監視対象
の数
少多
監視の観点システム内部ユーザー体験
監視対象はより多く、より複雑に
ユーザー視点の監視が重視されるように
監視対象
の状態
静的動的
監視対象は常に変化するように

View Slide

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

View Slide

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

View Slide

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

View Slide

監視から
オブザーバビリティへ

View Slide

近年のシステム監視　3つの特徴
システムの構成要素が多い
システムの変化が当たり前
ユーザー体験が重要
1
2
3

View Slide

監視にまつわる新たな課題
監視を1つ1つ網羅的に 
設定する労力が甚大
アラートが出ても、 
解釈と原因特定が困難
ブラウザ
アプリ
モバイル
アプリ
アプリ 
ロジック
DB 
サーバー
コンテナ
クラウド
？

View Slide

新機能などを既存の 
監視設定でカバーできない
想定外のアクセスなど前例の 
ない問題への対処が困難
従来の機能新機能
？

View Slide

ユーザー体験の計測方法の確立が
難しい
ユーザー体験の悪化の原因の 
調査が困難
ユーザーの手元で今起こってい
ることを知りたい
？

View Slide

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

View Slide

解決策: オブザーバビリティ(可観測性)
システム全体を可視化し、異
常を知らせる
ありとあらゆるコン
ポーネントの稼働
状況を取得可能な
状態にし、リアルタ
イムで収集する
データの関連付け
を行う
システムの異常にすぐに気づき、素早く原因にたどり着くことが可能

View Slide

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

View Slide

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

View Slide

• 監視では障害通知があると、 CPUやメモリなどの値を確認します。
死活監視反応があるか Ping
Metric 体温・血圧 CPU使用率/メモリ使用率
Log 「頭が痛い」 Errorメッセージ
原因はわからないけど、異常は見られないので頭痛薬飲んでおきましょう
＞とりあえず再起動

View Slide

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

View Slide

監視ツールとオブザーバービリティの違い
アプリケーション
監視
インフラ
監視
ネットワーク
監視
顧客体験
監視
オブザーバビリティ
ビジネス
監視
監視は個々のデータを必
要に応じて収集するが、
オブザーバビリティは全て
を収集する

View Slide

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での監視率
● データの量
成熟度

View Slide

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

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

New Relic

More Decks by New Relic

Other Decks in Technology

Featured

Transcript