とあるソフトウェアエンジニアの 小さく始めるオブザーバビリティ ゆる SRE 勉強会 #6 - 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 ● Favorite Word ○ class SRE implements DevOps 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

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

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

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

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

方針は決まった！ しかし、チーム状況に 大きなネックが

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

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

限られたリソース（= 稼働や費用） の中で目指す状態を実現したい 小さく始めて大きな価値を！

オブザーバビリティの用語整理 12 — 「Observability Whitepaper」 分析対象となる要素 テレメトリー 要素を収集 サービス A サービス B 計装 計装 ✔メトリクス ✔ログ ✔トレース ✔プロファイル テレメトリーを収集する仕組み をサービスに組み込む 計装 テレメトリー オブザーバビリティ バックエンド

小さく始める：どこを見るべきか 13 ユーザー視点での監視 最小限の監視範囲で異常発生を的確に検知するためにはどうしたらよいか？ “まず監視を追加すべきなのは、ユーザーが あなたのアプリケーションとやり 取りをするところです。 ... 最も効果的な監視ができる方法の 1 つが、シンプルに HTTP レスポンスコー ド（特に HTTP 5xx 番台）を使うことです” — 書籍「入門 監視」2章 監視のデザインパターン

小さく始める：どこを見るべきか 14 ユーザー視点での監視 最小限の監視範囲で異常発生を的確に検知するためにはどうしたらよいか？ “まず監視を追加すべきなのは、ユーザーが あなたのアプリケーションとやり 取りをするところです。 ... 最も効果的な監視ができる方法の 1 つが、シンプルに HTTP レスポンスコー ド（特に HTTP 5xx 番台）を使うことです” — 書籍「入門 監視」2章 監視のデザインパターン ユーザー体験に影響がある部分にフォーカスできる

15 コードに手を入れずに情報取得 最小限のセットアップで実務に役立つテレメトリー収集はどうすればよいか？ 小さく始める：どのように情報を得るか “あなたのサービス、エンドポイント、依存関係をオブザーバビリティシステム に伝え、洞察を得られるようにするにはどうしたよいでしょうか。 … そのために、OpenTelemetryは自動計装を用意しており、ユーザーが最短 の時間で最初の価値を得られるようにしています 。” — 書籍「オブザーバビリティ・エンジニアリング」 7章 OpenTelemetry を使った計装

16 コードに手を入れずに情報取得 最小限のセットアップで実務に役立つテレメトリー収集はどうすればよいか？ 小さく始める：どのように情報を得るか “あなたのサービス、エンドポイント、依存関係をオブザーバビリティシステム に伝え、洞察を得られるようにするにはどうしたよいでしょうか。 … そのために、OpenTelemetryは自動計装を用意しており、ユーザーが最短 の時間で最初の価値を得られるようにしています 。” — 書籍「オブザーバビリティ・エンジニアリング」 7章 OpenTelemetry を使った計装 OpenTelemetry の活用でテレメトリー収集を最短で実現する

OpenTelemetry の概要 17 オブザーバビリティのための フレームワークとツールキット トレース、メトリック、ログといったテレメトリデータを扱う ための包括的な仕組みを提供 自動計装のサポート 計装のためのコードの追加を最小限に抑え、 アプリケーションの可観測性を容易に向上 ベンダー・ツール非依存 特定のベンダーやツールに縛られず、様々なバックエン ドと組み合わせて利用 “OpenTelemetry is an Observability framework and toolkit designed to create and manage telemetry data such as traces, metrics, and logs.” — 「OpenTelemetry Document」 What is OpenTelemetry アウトオブザボックスな特性 「箱から出してすぐに使える」ということを指す

18 “OpenTelemetry is an Observability framework and toolkit designed to create and manage telemetry data such as traces, metrics, and logs.” — 「OpenTelemetry Document」 What is OpenTelemetry オブザーバビリティのための フレームワークとツールキット トレース、メトリック、ログといったテレメトリデータを扱う ための包括的な仕組みを提供 自動計装のサポート 計装のためのコードの追加を最小限に抑え、 アプリケーションの可観測性を容易に向上 ベンダー・ツール非依存 特定のベンダーやツールに縛られず、様々なバックエン ドと組み合わせて利用 OpenTelemetry の概要 アウトオブザボックスな特性 「箱から出してすぐに使える」ということを指す

OpenTelemetry の自動計装 19 計測のハードルが下がり素早い一歩を “Automatic instrumentation with Python uses a Python agent that can be attached to any Python application. It dynamically injects bytecode to capture telemetry from many popular libraries and frameworks.” — 「OpenTelemetry Document」 Language APIs & SDKs/Python/Automatic Instrumentation ※自動計装について非常に参考になる記事： https://speakerdeck.com/k6s4i53rx/getting-started-auto-instrumentation-with-opentelemetry Pythonエージェントによる 動的なバイトコード挿入 実行時に動的にバイトコードを挿入し、 コード変更なく、テレメトリーのキャプチャが可能 開発者の負担軽減と オブザーバビリティの促進 計測のハードルが下がることで多くのアプリケーションでシステ ムの健全性監視が容易に 豊富なライブラリと フレームワークのサポート 広く普及しているものを使用している場合でも 容易にアプリケーションの可視化を実現

OpenTelemetry の自動計装 20 計測のハードルが下がり素早い一歩を “Automatic instrumentation with Python uses a Python agent that can be attached to any Python application. It dynamically injects bytecode to capture telemetry from many popular libraries and frameworks.” — 「OpenTelemetry Document」 Language APIs & SDKs/Python/Automatic Instrumentation Setup Configure the Agent $ pip install opentelemetry-distro opentelemetry-exporter-otlp $ opentelemetry-bootstrap -a install $ opentelemetry-instrument --traces_exporter otlp --service_name your-service-name --exporter_otlp_endpoint 0.0.0.0:4317 python myapp.py

21 最小限の学習コストで分析できる環境を 取り得る選択肢の中で目指す状態を実現できるオブザービリティバックエンドは？ 小さく始める：何で分析するか Google Cloud Stack (Trace, Logging, Monitoring) Grafana Stack + Prometheus (OSS : Grafana,Tempo, Loki) 機能性 接続性 運用性 費用 ※ 当時の検証やスキルなどを踏まえた評価結果です、一般的なものとは異なる点をご了承ください テレメトリーデータを分析する上では Grafana の方が優れていると感じた Google Cloud Stack ではマネージドな分 面倒を見なくてよい点は助かる SaaS はというと・・・ 社内事情で導入可否の判断が 長引く可能性があった

22 小さく始める：何で分析するか Google Cloud Stack (Trace, Logging, Monitoring) Grafana Stack + Prometheus (OSS : Grafana,Tempo, Loki) 機能性 接続性 運用性 費用 ※ 当時の検証やスキルなどを踏まえた評価結果です、一般的なものとは異なる点をご了承ください テレメトリーデータを分析する上では Grafana の方が優れていると感じた 最小限の学習コストで分析できる環境を 取り得る選択肢の中で目指す状態を実現できるオブザービリティバックエンドは？ Google Cloud Stack ではマネージドな分 面倒を見なくてよい点は助かる SaaS はというと・・・ 社内事情で導入可否の判断が 長引く可能性があった

23 小さく始めるオブザーバビリティ サービス A サービス B 計装 計装 ✔メトリクス ✔ログ ✔トレース ✔ プロファイル オブザーバビリティバックエンド HTTP ステータスコードの 4xx / 5xx の回数や頻度 処理の実行時間（Duration） Cloud Logging Cloud Monitoring Cloud Trace 自動計装

24 小さく始めるオブザーバビリティ

25 実際に使ってみて ❏ 4xx / 5xx に対するアラートによってユーザー影 響のある異常検知がしやすくなった ❏ 4xx / 5xx となったトレースを見ていくこと異常の 発生地点を見極めやすくなった ❏ サービスへの詳しさには比較的依存せずに異常 の原因探索が可能となった Pros Cons 課題とした状況から 一歩ずつ前進できている ❏ アラートで異常を検知してから異常が発生したト レースを検索がスムーズにいかない ❏ クエリのようにトレースの集合に対して詳細な分析 はできない ❏ 特に注目したい処理の情報量が足りない場合があ る（スパンに情報を付与したい） オブザーバビリティをより高めるには やれることがまだありそう ・カスタムスパンやイベントの追加 ・SaaS 含めたオブザーバビリティバックエンドの調査

まとめ 小さく始めるオブザーバビリティ どこを見るべきか 最小限の監視範囲として、 ユーザーとアプリのやりとりにフォーカス どのように情報を得るか コードに手を入れずに情報取得するため、 OpenTelemetry で自動計装 何で分析をするか スキルセットや機能性・運用性を考慮した、 Google Cloud Stack で可視化・分析 まだまだ改善の余地はあるが、 限られたリソースの中でも オブザーバビリティを始められて高い状況に近づける！

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

参考文献 ★ オブザーバビリティ・エンジニアリング ★ 入門 監視 ★ OpenTelemetry ドキュメント ○ https://opentelemetry.io/docs/ ★ 可観測性ガイダンス ○ オブザーバビリティについて非常に参考になる記事 ○ https://speakerdeck.com/nwiizo/ke-guan-ce-xing-kaitansu ★ 計測の手間を省きたい！ OpenTelemetry に見る”自動計装”のイマ ○ 自動計装について非常に参考になる記事 ○ https://speakerdeck.com/k6s4i53rx/getting-started-auto-instrumentation-with-opentelemetry ★ 勘に頼らず原因を ⾒つけるためのオブザーバビリティ ○ 理想デバックについて非常に参考になる記事 ○ https://speakerdeck.com/sansantech/sansan-20230929 28