オブザーバビリティと 開発優先度 との向き合い方 オブザーバビリティ実践までの道のり - Tomonori Hayashi 1 

Tomonori Hayashi ● NTT コミュニケーションズ イノベーションセンター所属 ○ ノーコード時系列分析ツール「 Node-AI」の開発/運用 ○ ソフトウェアエンジニア ■ Front：TypeScript - React/Next.js ■ Infra：Google Cloud ● Google Cloud Partner Top Engineer 2024 ● Google Cloud All Certifications ● コミュニティ ○ Jagu’e’r デジクラ人材育成分科会 ○ Jagu’e’r O11y-SRE 分科会 2 @pHaya72 @t_hayashi 

Node-AI の紹介 ● ノーコードで AI モデルを作成できる WEB アプリケーション ● カードを直感的につなげるだけで 時系列データの前処理から AI モデルの学習・評価までの パイプラインを作成・実行 できる ● 技術スタック ○ TypeScript + React / Next ○ Python + Django ○ C# + ASP.NET Core + SignalR ○ Kubernetes ○ Google Cloud ○ Scikit-learn / Tensorflow / Pytorch 3 

本日お話しすること ● オブザーバビリティの仕組みを導入するにあたり課題であった開発優先度の問題 ● 実際に導入してみての出来ていること・出来ていないこと 本日お話ししないこと ● オブザーバビリティの基礎的な部分 ● オブザーバビリティの仕組みを構築するにあたり課題であった稼働・費用の問題 ● おブザービリティの仕組みの構築のポイント 

チームが直面している課題 サービスに異常が発生したことを 的確に検知することができない 過去の経験からアラートを仕掛けるが 発生する異常はアラートで検知できず発見が遅れる 異常が発生しても歴戦の戦士しか 発生箇所を発見できない 何かあればひたすらログを眺めるが 歴戦の戦士がいないと異常を発見しづらく対応が遅れる 検知や対応が遅れれば ユーザーが満足に利用できない 事態を招く 

オブザーバビリティが高い とは言えない状況 

オブザーバビリティが高い状況とは 7 オブザーバビリティとは “システムがどのような状態になったとしても、それがどんなに斬新で奇妙な ものであっても、どれだけ理解し説明できるかを示す尺度 です。 … もし、新しいコードをデプロイする必要がなく、どんな斬新で奇妙な状態で も理解できるなら、オブザーバビリティがある と言えます。” — 書籍「オブザーバビリティ・エンジニアリング」 1章 オブザーバビリティとは？ 

オブザーバビリティが高い状況とは 8 オブザーバビリティ とは “システムがどのような状態になったとしても、それがどんなに斬新で奇妙な ものであっても、どれだけ理解し説明できるかを示す尺度 です。 … もし、新しいコードをデプロイする必要がなく、どんな斬新で奇妙な状態で も理解できるなら、オブザーバビリティがある と言えます。” — 書籍「オブザーバビリティ・エンジニアリング」 1章 オブザーバビリティとは？ チームメンバーの誰しもが分析を繰り返して 異常の正しい原因を素早く切り分けられる状態 目指すべき状態（方針） 

オブザーバビリティ実践までの道標 9 New Relic のオブザーバビリティ成熟度モデル 自分たちの取り組みがどの程度の立ち位置がいるのかを把握しておくことは、次のステップを検討する上で重要だと考えた いくつかあるオブザーバビリティの成熟度モデルの中でも New Relic のモデルを道標とした ※ 引用：https://speakerdeck.com/newrelic2023/20230523-findy-newrelic-o11y1?slide=30 

オブザーバビリティ実践までの道標 10 New Relic のオブザーバビリティ成熟度モデル 自分たちの取り組みがどの程度の立ち位置がいるのかを把握しておくことは、次のステップを検討する上で重要だと考えた いくつかあるオブザーバビリティの成熟度モデルの中でも New Relic のモデルを道標とした ※ 引用：https://speakerdeck.com/newrelic2023/20230523-findy-newrelic-o11y1?slide=30 方針と道標を元にオブザーバビリティ 実践までの道のりを歩む 

実践までの道のりは険しい 11 チームの開発メンバーは全員 SWE 10 名の開発メンバー（ Dev）は全員ソフトウェアエンジニアとして、内製でアプリケーション開発に取り組んでいる 開発しているアプリケーションを売り出すフェーズにあり、開発に加えて、お客様との打ち合わせなどビジネス面に寄与する取り組みも増え ている 優先度 稼働 費用 ・・・ 開発メンバー （Dev） 

チームの開発メンバーは全員 SWE 10 名の開発メンバー（ Dev）は全員ソフトウェアエンジニアとして、内製でアプリケーション開発に取り組んでいる 開発しているアプリケーションを売り出すフェーズにあり、開発に加えて、お客様との打ち合わせなどビジネス面に寄与する取り組みも増え ている 12 優先度 稼働 費用 ユーザーに価値を提供するための 機能開発が第一優先 オブザーバビリティ関連の 開発の優先度を上げづらい 実践までの道のりは険しい ・・・ 開発メンバー （Dev） 

ユーザーへ提供する価値が高い開発が優先度の上位に アジャイル開発のスクラム方式にのっとり開発に取り組んでいる 開発項目（PBI）の優先度はフェーズに合わせて、プロダクトオーナー（ PO）が最終決定する PBI に関する優先度は開発メンバー（ Dev）から交渉も可能としている チームの開発への取り組み方 13 PBI A PBI B PBI C PBI D プロダクトオーナー （PO） 優先度 高 低 ・・・ 開発メンバー （Dev） 

ユーザーへ提供する価値が高い開発が優先度の上位に アジャイル開発のスクラム方式にのっとり開発に取り組んでいる 開発項目（PBI）の優先度はフェーズに合わせて、プロダクトオーナー（ PO）が最終決定する PBI に関する優先度は開発メンバー（ Dev）から交渉も可能としている チームの開発への取り組み方 14 PBI A PBI B PBI C PBI D PBI Observability プロダクトオーナー （PO） 優先度 高 低 ・・・ 開発メンバー （Dev） 重要度は高いが緊急度が低い PBI は優先度が下がりがち 

ユーザーへ提供する価値が高い開発が優先度の上位に アジャイル開発のスクラム方式にのっとり開発に取り組んでいる 開発項目（PBI）の優先度はフェーズに合わせて、プロダクトオーナー（ PO）が最終決定する PBI に関する優先度は開発メンバー（ Dev）から交渉も可能としている チームの開発への取り組み方 15 PBI A PBI B PBI C PBI D PBI Observability プロダクトオーナー （PO） 優先度 高 低 ・・・ 開発メンバー （Dev） 重要度は高いが緊急度が低い PBI は優先度が下がりがち PO 含めチームに伝えるべきことは・・ 私 

オブザーバビリティに 取り組むことは ユーザーへの価値提供につながる 

オブザーバビリティの実践によるユーザー価値 サービスに異常が発生したことを 的確に検知することができない 異常が発生しても歴戦の戦士しか 発生箇所を発見できない 検知や対応が遅れれば ユーザーが満足に利用できない 事態を招く ユーザーが利用できない時間を最小限にすること （= 常にユーザーが利用できる状態に近づける）は プロダクトの当たり前品質の担保につながる 

デモとして検証環境で実際にやってみる 18 実演することが一番伝わりやすい 検証環境でレスポンスが遅いリクエストのパフォーマンス改善に取り組んでみて、チームメンバー に共有した マイクロサービス間を行き来するリクエストがトレースによって可視化されボトルネックを発見しやす いことを示した “オブザーバビリティツールは、 捉えどころのない問題を素早く発見するた めに設計 されています。 … 新しいイニシアティブを率先して行う場合、比較的早くポイントを獲得すること が重要です。難しい問題や捉えどころのない問題をすぐに解決すること で、価値を示し、好奇心を刺激し、興味を引き付けましょう 。” — 書籍「オブザーバビリティ・エンジニアリング」 10章 オブザーバビリティへの取り組みをチームへ適用する 

二つの取り組みで意義を伝える デモとして検証環境で 実際にパフォーマンス改善をやってみる 検証環境でレスポンスが遅いリクエストの パフォーマンス改善に取り組みチームに共有した 勉強会を開催して SRE やオブザーバビリティの基礎を学ぶ 実際にできることに加えてなぜ必要なのかの 根本を学ぶことで導入後の文化作りにも備えた ユーザーの価値提供につながることに重点を置きつつ オブザーバビリティの必要性をチームに浸透させた 

チームの開発メンバーは全員 SWE 10 名の開発メンバーは全員ソフトウェアエンジニアとして、内製でアプリケーション開発に取り組んでいる 開発しているアプリケーションを売り出すフェーズにあり、開発に加えて、お客様との打ち合わせなどビジネス面に寄与する取り組みも増え ている 実践までの道のりは険しい 20 優先度 稼働 費用 ユーザーに価値を提供するための 機能開発が第一優先 開発者が割ける時間は少ない チームとして使える予算には 限りがある 技術検証や導入に費やせる 費用は多くない ユーザーに価値を提供するための 機能開発が第一優先 オブザーバビリティ関連の 開発の優先度を上げづらい 

チームの開発メンバーは全員 SWE 10 名の開発メンバーは全員ソフトウェアエンジニアとして、内製でアプリケーション開発に取り組んでいる 開発しているアプリケーションを売り出すフェーズにあり、開発に加えて、お客様との打ち合わせなどビジネス面に寄与する取り組みも増え ている 実践までの道のりは険しい 21 優先度 稼働 費用 ユーザーに価値を提供するための 機能開発が第一優先 開発者が割ける時間は少ない チームとして使える予算には 限りがある 技術検証や導入に費やせる 費用は多くない ユーザーに価値を提供するための 機能開発が第一優先 オブザーバビリティ関連の 開発の優先度を上げづらい 稼働と費用についてはこちらの資料で オブザーバビリティ環境を構築する際のポイントを載せています https://speakerdeck.com/phaya72/toarusohutoueaenzinianoxiao-sakushi-meruobuzababiritei 

22 現在のオブザーバビリティ環境 サービス A サービス B 計装 計装 ✔メトリクス ✔ログ ✔トレース ✔ プロファイル オブザーバビリティバックエンド HTTP ステータスコードの 4xx / 5xx の回数や頻度 処理の実行時間（ Duration） 手動計装 PO 含めチームに伝えるべきことは・・ 

23 出来ていること・出来ていないこと New Relic のオブザーバビリティ成熟度モデルと照らし合わせる ◼ 成熟度 0：Getting Started ● パーフォマンス計測 ● スケールする製品の投入計画 ◼ 成熟度 1：Reactive（受動的） ● MTTR(Mean Time To Repair) の改善 ● アプリケーションパフォーマンスの気づき ◼ 成熟度 2：Proactive（積極的） ● MTTD(Mean Time To Discover) の改善 ● サービスレベルの計測 

24 出来ていること・出来ていないこと New Relic のオブザーバビリティ成熟度モデルと 照らし合わせる ◼ 成熟度 0：Getting Started ● パーフォマンス計測 ● スケールする製品の投入計画 ◼ 成熟度 1：Reactive（受動的） ● MTTR(Mean Time To Repair) の改善 ● アプリケーションパフォーマンスの気づき ◼ 成熟度 2：Proactive（積極的） ● MTTD(Mean Time To Discover) の改善 ● サービスレベルの計測 ✅ 応答時間やスループットといったアプリケーション パフォーマンスに関するテレメトリーの収集が可能 ✅ メトリクスやログに加えてトレースの収集も可能となり、 　 ツールでの分析によって異常の発見対応は早くなった 

25 出来ていること・出来ていないこと New Relic のオブザーバビリティ成熟度モデルと 照らし合わせる ◼ 成熟度 0：Getting Started ● パーフォマンス計測 ● スケールする製品の投入計画 ◼ 成熟度 1：Reactive（受動的） ● MTTR(Mean Time To Repair) の改善 ● アプリケーションパフォーマンスの気づき ◼ 成熟度 2：Proactive（積極的） ● MTTD(Mean Time To Discover) の改善 ● サービスレベルの計測 ✅ 応答時間やスループットといったアプリケーション パフォーマンスに関するテレメトリーの収集が可能 ✅ メトリクスやログに加えてトレースの収集も可能となり、 　 ツールでの分析によって異常の発見対応は早くなった ❌ ツールが利用できるのは一部のメンバーのみで、チーム全体 　 での取り組みにはなっていない、スケールに課題がある ❌ アプリケーションパフォーマンス改善は一部のメンバーが気 　 づいた時に取り組む程度、継続性に課題がある ❌ SLI/SLO の定義ができていない 

オブザーバビリティ実践までの道のりは険しい ● オブザーバビリティの仕組みを導入するにあたり課題であった開発優先度の問題 ○ オブザーバビリティに取り組むことはユーザーへの価値提供 = 常にユーザーが利用できる状態に近づけることで当たり前品質の担保 をメッセージに ○ デモとして実際にパフォーマンス改善にやってみせた まだまだ出来ていないことばかり、でも一歩ずつ歩めている ● 実際に導入してみての出来ていること・出来ていないこと ○ New Relic のオブザーバビリティ成熟度モデルを道標に 出来ていること・出来ていないことを 把握 ○ チームの状況に合わせて Next Step を今後も考えていく まとめ 

オブザーバビリティ実践までの道のりは険しい ● オブザーバビリティの仕組みを導入するにあたり課題であった開発優先度の問題 ○ オブザーバビリティに取り組むことはユーザーへの価値提供 = 常にユーザーが利用できる状態に近づけることで当たり前品質の担保 をメッセージに ○ デモとして実際にパフォーマンス改善にやってみせた まだまだ出来ていないことばかり、でも一歩ずつ歩めている ● 実際に導入してみての出来ていること・出来ていないこと ○ New Relic のオブザーバビリティ成熟度モデルを道標に 出来ていること・出来ていないことを 把握 ○ チームの状況に合わせて Next Step を今後も考えていく → オブザービリティは最初の一歩でも大きな価値を得られると思います！ まとめ 

CREDITS: This presentation template was created by Slidesgo, and includes icons by Flaticon, and infographics & images by Freepik Thanks! 28 @pHaya72 @t_hayashi