CNDS2024 - 組織をまたいで実践するオブザーバビリティの勘所

© 2024 SPLUNK INC. 組織をまたいで実践するオブザーバビリティの勘所 2024-06-15 14:20-15:00 @Track B
CloudNative Days Summer 2024

© 2024 SPLUNK INC. 中上健太朗 (Kentaro Nakagami) Solutions Architect,
Observability Splunk Services Japan 　X(Twitter): @_knakagami_

Forward- looking statements This presentation may contain forward-looking statements regarding
future events, plans or the expected financial performance of our company, including our expectations regarding our products, technology, strategy, customers, markets, acquisitions and investments. These statements reflect management’s current expectations, estimates and assumptions based on the information currently available to us. These forward-looking statements are not guarantees of future performance and involve significant risks, uncertainties and other factors that may cause our actual results, performance or achievements to be materially different from results, performance or achievements expressed or implied by the forward-looking statements contained in this presentation. For additional information about factors that could cause actual results to differ materially from those described in the forward-looking statements made in this presentation, please refer to our periodic reports and other filings with the SEC, including the risk factors identified in our most recent quarterly reports on Form 10-Q and annual reports on Form 10-K, copies of which may be obtained by visiting the Splunk Investor Relations website at www.investors.splunk.com or the SEC's website at www.sec.gov. The forward-looking statements made in this presentation are made as of the time and date of this presentation. If reviewed after the initial presentation, even if made available by us, on our website or otherwise, it may not contain current or accurate information. We disclaim any obligation to update or revise any forward-looking statement based on new information, future events or otherwise, except as required by applicable law. In addition, any information about our roadmap outlines our general product direction and is subject to change at any time without notice. It is for informational purposes only and shall not be incorporated into any contract or other commitment. We undertake no obligation either to develop the features or functionalities described, in beta or in preview (used interchangeably), or to include any such feature or functionality in a future release. Splunk, Splunk> and Turn Data Into Doing are trademarks and registered trademarks of Splunk Inc. in the United States and other countries. All other brand names, product names or trademarks belong to their respective owners. © 2024 Splunk Inc. All rights reserved. © 2024 SPLUNK INC.

© 2024 SPLUNK INC. Splunk Observability APM アプリケーション監視 Splunk Cloud/Enterprise
Log Observer Connect ログ監視・調査 Infrastructure Monitoring インフラ監視 Synthetic Monitoring 外形監視／合成監視フロントエンドからバックエンドまで、インシデントの検知から解消まで、問題解決を End to End で支援 RUM 実ユーザのUX監視 OnCall 障害検知時のオンコール

© 2024 SPLUNK INC. © 2024 SPLUNK INC. 今日お伝えしたいことオブザーバビリティに
“ちゃんと” 取り組んでいくためにオブザーバビリティを「組織的に・継続的に実践していく」という観点から捉えなおそう「なんとなく始めてみた」「とりあえずエージェントを導入した」で止まっていませんか？オブザーバビリティの実践、ちゃんと続けられていますか？システム全体・ビジネス全体でのオブザーバビリティ、高められていますか？

© 2024 SPLUNK INC. 本日お話しする内容 1. オブザーバビリティを広げていく 2. 組織的に取り組むオブザーバビリティと Splunk
Observability 3. 組織的な実践を進めていく

© 2024 SPLUNK INC. オブザーバビリティとは “ 私たちが考えるソフトウェアシステムの「オブザーバビリティ」とは、システムがどのような状態になったとしても、それがどんなに斬新で奇妙なものであっても、
どれだけ理解し説明できるかを示す尺度です” https://www.oreilly.co.jp/books/9784814400126/ 『オブザーバビリティ・エンジニアリング』　 1章「オブザーバビリティとは？」 by 『オブザーバビリティ・エンジニアリング』

© 2024 SPLUNK INC. Getting Started まずは、あるチーム・あるシステムでオブザーバビリティに取り組むシステムユーザー Devチーム
Opsチーム Trace Metric Log 開発/計装, 問題調査・対応

Opsチーム Trace Metric Log 開発/計装, 問題調査・対応よく聞くあのツールを試してみよう… エージェント入れてみて… いい感じのダッシュボードを見てみて… ぼちぼちっとアラートも設定してみて… APMというのがあるらしい… エージェントをアプリと一緒に動かして… へえ、こんな感じなのね…

Opsチーム Trace Metric Log 開発/計装, 問題調査・対応いい感じのものができた！！

Opsチーム Trace Metric Log 開発/計装, 問題調査・対応いい感じのものができた！！めでたし、めでたし（完）

Opsチーム Trace Metric Log 開発/計装, 問題調査・対応いい感じのものができた！！めでたし、めでたし（完） ❓❓❓

© 2024 SPLUNK INC. 「オブザーバビリティを広げていく」とはお客様まずは先行プロジェクトとして、あるシステムをサンプルにオブザーバビリティを試していきたいその取り組みで得た知見や成果をもとに、全システムにオブザーバビリティを広げていきたい
• ビジネスに対するシステムの貢献や影響を把握したい • システム全体としての信頼性を高めていきたい

© 2024 SPLUNK INC. オブザーバビリティを管理する必要性「はじめてみる」と「広げていく」の質的な違いあるエンドユーザーが使用するあるシステムに対してそのシステムの担当チームがそのシステムに固有の課題を解決するために
そのシステムに閉じた形で試行錯誤をしながら取り組むオブザーバビリティをはじめてみるさまざまなエンドユーザーが使用するさまざまなシステムに対して各システムを担当する複数のチームがそのシステム固有の課題だけではなくシステム間連携などを含めた形でできるだけ効率的に取り組むオブザーバビリティを広げていく

そのシステムに閉じた形で試行錯誤をしながら取り組むオブザーバビリティをはじめてみるさまざまなエンドユーザーが使用するさまざまなシステムに対して各システムを担当する複数のチームがそのシステム固有の課題だけではなくシステム間連携などを含めた形でできるだけ効率的に取り組むオブザーバビリティを広げていく特定のシステムにフォーカスした取り組み

そのシステムに閉じた形で試行錯誤をしながら取り組むオブザーバビリティをはじめてみるさまざまなエンドユーザーが使用するさまざまなシステムに対して各システムを担当する複数のチームがそのシステム固有の課題だけではなくシステム間連携などを含めた形でできるだけ効率的に取り組むオブザーバビリティを広げていく特定のシステムにフォーカスした取り組みより広い範囲を対象にした組織的な取り組み

© 2024 SPLUNK INC. 先行プロジェクト・システムオブザーバビリティをはじめてみた直後ユーザー Trace Metric Log
開発/計装, 問題調査・対応先行プロジェクト担当チーム

© 2024 SPLUNK INC. 展開先システム先行プロジェクト・システムオブザーバビリティを広げていくと… ユーザー Trace Metric
Log 開発/計装, 問題調査・対応 Trace Metric Log 展開先システム展開先システム担当チーム開発/計装, 問題調査・対応 CxO 先行プロジェクト担当チーム展開先システム担当 … … サポート部門オペレータ営業カスタマーサクセス先行プロジェクトのナレッジに基づく新たな取り組み利害関係者の増加継続的な取り組み対象となるエンドユーザの増加

© 2024 SPLUNK INC. 展開先システム先行プロジェクト・システムこれまでとは異なる観点 Trace Metric Log
開発/計装, 問題調査・対応 Trace Metric Log 展開先システム展開先システム担当チーム開発/計装, 問題調査・対応 CxO 先行プロジェクト担当チーム展開先システム担当 … … サポート部門オペレータ営業カスタマーサクセスユーザー異なるエンドユーザー • サービスに対する期待・要求が異なる • システムトラブルが及ぼすビジネス的な影響が異なる

開発/計装, 問題調査・対応 Trace Metric Log 展開先システム展開先システム担当チーム開発/計装, 問題調査・対応 CxO 先行プロジェクト担当チーム展開先システム担当 … … サポート部門オペレータ営業カスタマーサクセス異なるサービスの性質異なるアーキテクチャユーザー • サービスが異なれば、提供すべき品質も異なる • サービスに合わせた構成やアーキテクチャを採用している

開発/計装, 問題調査・対応 Trace Metric Log 展開先システム展開先システム担当チーム開発/計装, 問題調査・対応 CxO 先行プロジェクト担当チーム展開先システム担当 … … サポート部門オペレータ営業カスタマーサクセスユーザー異なるチーム構成異なる課題異なる開発・運用体制異なるオブザーバビリティに対する理解度や関心 • スキル・経験などのバックグラウンドの違い • 各システムの課題や興味関心の違い • チームにおけるルールや文化・考え方の違い • まだオブザーバビリティを体感しておらず、関心や理解の度合いが異なる

開発/計装, 問題調査・対応 Trace Metric Log 展開先システム展開先システム担当チーム開発/計装, 問題調査・対応 CxO 先行プロジェクト担当チーム展開先システム担当 … … サポート部門オペレータ営業カスタマーサクセスユーザー異なるビジネスニーズ • よりビジネス観点での判断が求められる（敢えて変えたくないものもあるはず） • ビジネス環境の変化に応じて、組織、システムを変えていくことを考える必要がある

開発/計装, 問題調査・対応 Trace Metric Log 展開先システム展開先システム担当チーム開発/計装, 問題調査・対応 CxO 先行プロジェクト担当チーム展開先システム担当 … … サポート部門オペレータ営業カスタマーサクセス異なるアーキテクチャ異なるサービスの性質ユーザー異なるエンドユーザー異なるチーム構成異なる課題異なる開発・運用体制異なるオブザーバビリティに対する理解度や関心異なるビジネスニーズ

© 2024 SPLUNK INC. 展開先システム先行プロジェクト・システム発生するかもしれない課題ユーザー Trace Metric
Log 開発/計装, 問題調査・対応 Trace Metric Log 展開先システム展開先システム担当チーム開発/計装, 問題調査・対応 CxO 先行プロジェクト担当チーム展開先システム担当 … … サポート部門オペレータ営業カスタマーサクセスオブザーバビリティ？何それ美味しいの？いま困っていないなぜやる必要があるの？運用を変えるのは大変（やりたくない）メリットが理解されないと、取り組まれない抵抗感につながる

Log 開発/計装, 問題調査・対応 Trace Metric Log 展開先システム展開先システム担当チーム開発/計装, 問題調査・対応 CxO 先行プロジェクト担当チーム展開先システム担当 … … サポート部門オペレータ営業カスタマーサクセス何をどうするべきか分からない先行チームでやったことがよく分からないナレッジが共有されないと取り組みの効率が上がらない

Log 開発/計装, 問題調査・対応 Trace Metric Log 展開先システム展開先システム担当チーム開発/計装, 問題調査・対応 CxO 先行プロジェクト担当チーム展開先システム担当 … … サポート部門オペレータ営業カスタマーサクセス先行システムが使ったツールや実装がこちらでは、うまく使えない担当のシステムにあわせて、独自実装した連携先システムの状態が分からないツールや実装が異なると、システム全体としての可観測性が高まらない結局、システム全体の状態は分からない

Log 開発/計装, 問題調査・対応 Trace Metric Log 展開先システム展開先システム担当チーム開発/計装, 問題調査・対応 CxO 先行プロジェクト担当チーム展開先システム担当 … … サポート部門オペレータ営業カスタマーサクセス取り組みがうまくいかないと、投資対効果が低くなり、コストに注目が集まってしまう取り組んでみたけど、システム全体の状態やビジネスインパクトは把握できなさそう監視の延長でしかないなら、そこまでコストをかけるべきではない結局、エンドユーザーにとって何かいいことがあったの？特にユーザー体験がよくなった感触はない

Log 開発/計装, 問題調査・対応 Trace Metric Log 展開先システム展開先システム担当チーム開発/計装, 問題調査・対応 CxO 先行プロジェクト担当チーム展開先システム担当 … … サポート部門オペレータ営業カスタマーサクセスこれまでの計装は、全部やり直しか…。コスト削減のためにツールを乗り換える体制変更、システム面も見直しをしていく将来起きるかもしれない、ビジネス・組織体制・システムの変化に振り回されるせっかく知識もついたのに覚えなおしが必要なのか…

© 2024 SPLUNK INC. 展開先システム先行プロジェクト・システム先行チームの知見に基づく協力は必要ですが… ユーザー Trace Metric
Log 開発/計装, 問題調査・対応 Trace Metric Log 展開先システム展開先システム担当チーム開発/計装, 問題調査・対応 CxO 先行プロジェクト担当チーム展開先システム担当 … … サポート部門オペレータ営業カスタマーサクセス継続的な取り組みアピール意向を聞く普及ナレッジ共有

© 2024 SPLUNK INC. 展開先システム先行プロジェクト・システム先行チームの知見に基づく協力は必要ですが… ユーザー Trace Metric
Log 開発/計装, 問題調査・対応 Trace Metric Log 展開先システム展開先システム担当チーム開発/計装, 問題調査・対応 CxO 先行プロジェクト担当チーム展開先システム担当 … … サポート部門オペレータ営業カスタマーサクセス継続的な取り組みアピール普及ナレッジ共有意向を聞く全部やるのは無理！

© 2024 SPLUNK INC. 組織横断の取り組みへ展開先システム先行プロジェクト・システムユーザー Trace Metric
Log 開発/計装, 問題調査・対応 Trace Metric Log 展開先システム展開先システム担当チーム開発/計装, 問題調査・対応 CxO 先行プロジェクト担当チーム展開先システム担当 … … サポート部門オペレータ営業カスタマーサクセスプラットフォームチームプラットフォームエンジニアリング組織横断的な支援

© 2024 SPLUNK INC. 組織横断の取り組みへ展開先システム先行プロジェクト・システムユーザー Trace Metric
Log 開発/計装, 問題調査・対応 Trace Metric Log 展開先システム展開先システム担当チーム開発/計装, 問題調査・対応 CxO 先行プロジェクト担当チーム展開先システム担当 … … サポート部門オペレータ営業カスタマーサクセスプラットフォームチーム組織横断的な支援プラットフォームエンジニアリングメリットを高めるコストを最適化するベストプラクティスの採用・実装中長期的・継続的な取り組みコストコントロール関係者を巻き込み理解を促す

© 2024 SPLUNK INC. オブザーバビリティの取り組みを管理するプラットフォームチームは、どんなことをやっていくか • オブザーバビリティのベストプラクティスを理解し、準拠していく
• 短期的に、効率的にオブザーバビリティの取り組みを広げていくための仕組みを作る • 中長期的な視点から、オブザーバビリティの取り組みが継続可能な戦略、ロードマップ、アーキテクチャを選択する • 計装を継続的に深め、オブザーバビリティを高めていく中長期的・継続的な取り組みコストコントロール関係者を巻き込み理解を促すベストプラクティスの採用・実装 • 予期せぬコスト発生を防ぐ管理と仕組みで、予算を守る • 活用の頻度に応じて、取得するテレメトリーデータを管理し、コスト最適化を進める • ビジネスへの貢献や成果をアピールし、取り組む仲間を増やす • 新たなニーズやフィードバックを得て、次の取り組みに活かす

• 短期的に、効率的にオブザーバビリティの取り組みを広げていくための仕組みを作る • 中長期的な視点から、オブザーバビリティの取り組みが継続可能な戦略、ロードマップ、アーキテクチャを選択する • 計装を継続的に深め、オブザーバビリティを高めていく中長期的・継続的な取り組みコストコントロール関係者を巻き込み理解を促すベストプラクティスの採用・実装 • 予期せぬコスト発生を防ぐ管理と仕組みで、予算を守る • 活用の頻度に応じて、取得するテレメトリーデータを管理し、コスト最適化を進める • ビジネスへの貢献や成果をアピールし、取り組む仲間を増やす • 新たなニーズやフィードバックを得て、次の取り組みに活かす例えば、、、 • 印象やトライアルだけで採用しない ◦ 「いい感じの見た目」「安い」「使いやすい・分かりやすい」は重要だが、それだけで判断するべきではない ◦ どのソリューションでも、大体同じ課題を解決できる • 組織的な取り組みに必要な要件にも目を向ける ◦ ユーザビリティだけでなく、拡張性・管理性、ツールの運用性を考える

• 短期的に、効率的にオブザーバビリティの取り組みを広げていくための仕組みを作る • 中長期的な視点から、オブザーバビリティの取り組みが継続可能な戦略、ロードマップ、アーキテクチャを選択する • 計装を継続的に深め、オブザーバビリティを高めていく中長期的・継続的な取り組みコストコントロール関係者を巻き込み理解を促すベストプラクティスの採用・実装 • 予期せぬコスト発生を防ぐ管理と仕組みで、予算を守る • 活用の頻度に応じて、取得するテレメトリーデータを管理し、コスト最適化を進める • ビジネスへの貢献や成果をアピールし、取り組む仲間を増やす • 新たなニーズやフィードバックを得て、次の取り組みに活かす例えば、、、 • ナレッジを集約し、共有していく ◦ 利用ガイド、活用事例集、設定ガイド作成・公開 ◦ はじめて取り組む人のハードルを下げる • 標準化と自動化を進める ◦ テレメトリー取得方式・設定、利用するバックエンド設定の標準化 ◦ 命名規則・規約の整理 ◦ 標準設定を構成管理ツールによって管理・自動反映

• 短期的に、効率的にオブザーバビリティの取り組みを広げていくための仕組みを作る • 中長期的な視点から、オブザーバビリティの取り組みが継続可能な戦略、ロードマップ、アーキテクチャを選択する • 計装を継続的に深め、オブザーバビリティを高めていく中長期的・継続的な取り組みコストコントロール関係者を巻き込み理解を促すベストプラクティスの採用・実装 • 予期せぬコスト発生を防ぐ管理と仕組みで、予算を守る • 活用の頻度に応じて、取得するテレメトリーデータを管理し、コスト最適化を進める • ビジネスへの貢献や成果をアピールし、取り組む仲間を増やす • 新たなニーズやフィードバックを得て、次の取り組みに活かす例えば、、、 • 目指していくオブザーバビリティの姿を考える ◦ 本当は何が理解できるようになりたいか • 「ビジネス／システム／組織が変わったら…」を想定する ◦ どういう選択をすれば、将来困らずに済むか ◦ 移行性・運用保守性などの観点を必要 • 「導入したら終わり」ではない ◦ オブザーバビリティは “0 or 1” の概念ではない

• 短期的に、効率的にオブザーバビリティの取り組みを広げていくための仕組みを作る • 中長期的な視点から、オブザーバビリティの取り組みが継続可能な戦略、ロードマップ、アーキテクチャを選択する • 計装を継続的に深め、オブザーバビリティを高めていく中長期的・継続的な取り組みコストコントロール関係者を巻き込み理解を促すベストプラクティスの採用・実装 • 予期せぬコスト発生を防ぐ管理と仕組みで、予算を守る • 活用の頻度に応じて、取得するテレメトリーデータを管理し、コスト最適化を進める • ビジネスへの貢献や成果をアピールし、取り組む仲間を増やす • 新たなニーズやフィードバックを得て、次の取り組みに活かす例えば、、、 • コストの発生状況を確認する ◦ まずは何より、現状把握を行う • 予期せぬコスト発生を抑える仕組みを整える ◦ 機能的な上限設定 ◦ 運用的なライセンス消費までのルールやプロセス • 不要なテレメトリーを抑制する ◦ 大規模利用時には、参照頻度が低いメトリクスやディメンション・属性などが含まれることが多い

• 短期的に、効率的にオブザーバビリティの取り組みを広げていくための仕組みを作る • 中長期的な視点から、オブザーバビリティの取り組みが継続可能な戦略、ロードマップ、アーキテクチャを選択する • 計装を継続的に深め、オブザーバビリティを高めていく中長期的・継続的な取り組みコストコントロール関係者を巻き込み理解を促すベストプラクティスの採用・実装 • 予期せぬコスト発生を防ぐ管理と仕組みで、予算を守る • 活用の頻度に応じて、取得するテレメトリーデータを管理し、コスト最適化を進める • ビジネスへの貢献や成果をアピールし、取り組む仲間を増やす • 新たなニーズやフィードバックを得て、次の取り組みに活かす例えば、、、 • 社内・社外に活用事例を公開する ◦ 課題意識や解決策、その効果を共有しあう ◦ 同僚の取り組みは、親近感を得やすい＆刺激になる ◦ 社外でのプレゼンス向上は、社内の評判にもつながる ◦ 社外コミュニティからの学びを得る • ビジネスインパクトの定量的な評価を行う ◦ 定性評価に止まらず、定量的に活動の成果を語る ◦ コストは分かりやすいが、メリットは測りづらい（ＭＴＴD/MTTR削減、障害時に発生する運用コスト削減、開発品質向上に伴うコスト削減・ビジネス貢献…） • 現在の取り組みを振り返る ◦ オブザーバビリティ成熟度、システム利用者満足度…

• 短期的に、効率的にオブザーバビリティの取り組みを広げていくための仕組みを作る • 中長期的な視点から、オブザーバビリティの取り組みが継続可能な戦略、ロードマップ、アーキテクチャを選択する • 計装を継続的に深め、オブザーバビリティを高めていく中長期的・継続的な取り組みコストコントロール関係者を巻き込み理解を促すベストプラクティスの採用・実装 • 予期せぬコスト発生を防ぐ管理と仕組みで、予算を守る • 活用の頻度に応じて、取得するテレメトリーデータを管理し、コスト最適化を進める • ビジネスへの貢献や成果をアピールし、取り組む仲間を増やす • 新たなニーズやフィードバックを得て、次の取り組みに活かす

• 短期的に、効率的にオブザーバビリティの取り組みを広げていくための仕組みを作る • 中長期的な視点から、オブザーバビリティの取り組みが継続可能な戦略、ロードマップ、アーキテクチャを選択する • 計装を継続的に深め、オブザーバビリティを高めていく中長期的・継続的な取り組みコストコントロール関係者を巻き込み理解を促すベストプラクティスの採用・実装 • 予期せぬコスト発生を防ぐ管理と仕組みで、予算を守る • 活用の頻度に応じて、取得するテレメトリーデータを管理し、コスト最適化を進める • ビジネスへの貢献や成果をアピールし、取り組む仲間を増やす • 新たなニーズやフィードバックを得て、次の取り組みに活かす技術的・機能的に対応できるものはどんどん実装・活用していく組織的な実践にフォーカスしていくナレッジやルールを整理し、文化を醸成する

© 2024 SPLUNK INC. オブザーバビリティの取り組みを管理するプラットフォームチーム観点での技術的・機能的なニーズを取り入れる • オブザーバビリティのベストプラクティスを理解し、準拠していく
• 短期的に、効率的にオブザーバビリティの取り組みを広げていくための仕組みを作る • 中長期的な視点から、オブザーバビリティの取り組みが継続可能な戦略、ロードマップ、アーキテクチャを選択する • 計装を継続的に深め、オブザーバビリティを高めていく中長期的・継続的な取り組みコストコントロール関係者を巻き込み理解を促すベストプラクティスの採用・実装 • 予期せぬコスト発生を防ぐ管理と仕組みで、予算を守る • 活用の頻度に応じて、取得するテレメトリーデータを管理し、コスト最適化を進める • ビジネスへの貢献や成果をアピールし、取り組む仲間を増やす • 新たなニーズやフィードバックを得て、次の取り組みに活かす組織的な実践にフォーカスしていくナレッジやルールを整理し、文化を醸成する技術的・機能的に対応できるものはどんどん実装・活用していく

• 短期的に、効率的にオブザーバビリティの取り組みを広げていくための仕組みを作る • 中長期的な視点から、オブザーバビリティの取り組みが継続可能な戦略、ロードマップ、アーキテクチャを選択する • 計装を継続的に深め、オブザーバビリティを高めていく中長期的・継続的な取り組みコストコントロール関係者を巻き込み理解を促すベストプラクティスの採用・実装 • 予期せぬコスト発生を防ぐ管理と仕組みで、予算を守る • 活用の頻度に応じて、取得するテレメトリーデータを管理し、コスト最適化を進める • ビジネスへの貢献や成果をアピールし、取り組む仲間を増やす • 新たなニーズやフィードバックを得て、次の取り組みに活かす OpenTelemetryに準拠する重要性

© 2024 SPLUNK INC. OpenTelemetry準拠の重要性 • メトリクス、ログ、トレースなどのテレメトリーデータを生成・収集・管理・送信するAPI, SDK, ツールのコレクション
• CNCFでKubernetesに次いで2番目に活発なプロジェクト ◦ クラウドサービスプロバイダを含め、さまざまな会社が貢献 • ベンダーニュートラルで、業界標準のテレメトリー管理を目指すオブザーバビリティにおけるテレメトリー取得の業界標準

© 2024 SPLUNK INC. The Best (and Worst) Reasons to
Adopt OpenTelemetry 1. Bringing Gaps with Manual Instrumentation 自動計装でカバーできないケースにおいて、手動計装を組み合わせて利用しやすい - OpenTelemetryのベンダー中立なAPIの活用 2. Sending Data to Multiple Vendors 組織のすべてのユースケースを1つのツールでカバーできるわけではない - オープンな計装、柔軟なデータパイプライン 3. Gaining Insight Into Third-Party Libraries and Services コミュニティーベースで、各サービスプロバイダ、ライブラリが計装をサポートしていく - オブザーバビリティベンダー各々で、あらゆる3rd Partyライブラリ・サービスに対応するのは冗長・非合理的 https://devops.com/the-best-and-worst-reasons-to-adopt-opentelemetry/

© 2024 SPLUNK INC. OpenTelemetryによって得られる柔軟性独自規格に基づく計装は、テレメトリー取得・管理・送信においてベンダーロックインを発生させるアプリケーション独自エージェント独自ライブラリ/SDK 独自の
オブザーバビリティバックエンドベンダーロックインサーバー/VM Kubernetes/ コンテナ 3rd Party ライブラリやツール顧客固有のデータソース他のバックエンド

© 2024 SPLUNK INC. OpenTelemetry準拠のバックエンドを自由に選択 OpenTelemetryによって得られる柔軟性テレメトリー取得・管理手法と、送信先となる分析用のバックエンドを疎結合な関係にアプリケーションサーバー/VM
Kubernetes/ コンテナ 3rd Party ライブラリやツール顧客固有のデータソース OpenTelemetry Collector オープンな計装とデータパイプラインを活用必要なデータを柔軟に取得・加工・送信することが可能

© 2024 SPLUNK INC. OpenTelemetryによって得られる柔軟性 Gatewayモードを活用して、テレメトリーを集約・管理するシステムA アプリケーション OpenTelemetry Collector
(Agent Mode) システムＢアプリケーション OpenTelemetry Collector (Agent Mode) OpenTelemetry Collector (Gateway Mode) テレメトリーを集約し加工や送信を一括管理管理が大変…

(Agent Mode) システムＢアプリケーション OpenTelemetry Collector (Agent Mode) OpenTelemetry Collector (Gateway Mode) 機能面でのニーズにあわせて一括でバックエンドを切り替えることも可能もうすこし高度な分析機能が欲しい

(Agent Mode) システムＢアプリケーション OpenTelemetry Collector (Agent Mode) OpenTelemetry Collector (Gateway Mode) 環境別・システム別などでデータを送り分けることも可能開発環境では OSSでコスト抑制本番環境は商用サービスで

© 2024 SPLUNK INC. OpenTelemetryによって得られる柔軟性 OpenTelemetryにしておけば、不確実な未来でも困らないシステムA アプリケーション OpenTelemetry Collector
(Agent Mode) システムＢアプリケーション OpenTelemetry Collector (Agent Mode) OpenTelemetry Collector (Gateway Mode) テレメトリー取得・管理のための計装のレイヤーとバックエンドサービスを分離使いたいサービスを自由に選択できる柔軟性を獲得何が変わるか分からない未来でも困らない選択肢

© 2024 SPLUNK INC. OpenTelemetryに基づく標準化命名規約などによって標準化しておかないと… • メトリクスやトレース量の把握・管理などが難しくなる • ダッシュボードやアラート設定の際にノイズとなる
• 似た名前だけど違う値を示すメトリクスにより、混乱をきたす Semantic Conventionsでは、テレメトリーデータに対する命名や属性(Attribute)の付与に関する標準ルールを定める • 例えば、Attributeに関しては、、、 ◦ service.version のように、名前空間を分けることで命名が重複することを避ける ◦ 名前を再利用することを避ける ◦ … ◦ … トレース、メトリクス、属性などの標準化を、Semantic Conventionに準拠して進めていく

© 2024 SPLUNK INC. OpenTelemetryとSplunk Splunkは最大のContributorであり、サポートを提供しています https://opentelemetry.devstats.cncf.io/d/5/companies-table?orgId=1&var-period_name=Last%20year&var-metric=contributions https://docs.splunk.com/observability/ja/gdi/opentelemetry/opentelemetry.html#collector-distros-splunk Splunk Observability
Cloud は　　独自エージェントを持たない　　　　　　OpenTelemetry完全準拠　　　　　　　　　　　　　　　　　　　　　　のオブザーバビリティバックエンドです Splunk Distribution of OpenTelemetry Collectorをサポート以下のような設定が事前に含まれています • Splunk製品へのデータ取り込みなどに関するデフォルト設定 • メトリクスソースの自動検出および構成（Upstream OpenTelemetry Collectorにも、ベストエフォートのサポートを提供）

• 短期的に、効率的にオブザーバビリティの取り組みを広げていくための仕組みを作る • 中長期的な視点から、オブザーバビリティの取り組みが継続可能な戦略、ロードマップ、アーキテクチャを選択する • 計装を継続的に深め、オブザーバビリティを高めていく中長期的・継続的な取り組みコストコントロール関係者を巻き込み理解を促すベストプラクティスの採用・実装 • 予期せぬコスト発生を防ぐ管理と仕組みで、予算を守る • 活用の頻度に応じて、取得するテレメトリーデータを管理し、コスト最適化を進める • ビジネスへの貢献や成果をアピールし、取り組む仲間を増やす • 新たなニーズやフィードバックを得て、次の取り組みに活かすテレメトリーとコストをコントロール

© 2024 SPLUNK INC. テレメトリーとコストをコントロールライセンスに関係するメトリクスを確認して、現状を把握 OOTBダッシュボードによってライセンス関連のメトリクスの推移を確認 PlanとUsageを確認
詳細な利用状況レポートも出力可能

© 2024 SPLUNK INC. テレメトリーとコストをコントロールデータ取得時に使用するトークン単位で上限管理ホスト数・コンテナ数・カスタムメトリクス数に基づいてトークン単位で上限を指定予期せぬライセンス消費が発生することを避ける（例：
急激な負荷によるスケールアウト、操作ミス...)

© 2024 SPLUNK INC. テレメトリーとコストをコントロールシステムや担当チーム単位でトークンを設定することで、きめこまやかにライセンスを管理チームＡチームＢチームＣ担当システムA
担当システムＢ担当システムＣ担当システムＤトークンＡトークンＢトークンＣトークンＤホスト数上限： 10 カスタムメトリクス上限： 30 コンテナ数上限： 200 カスタムメトリクス上限： 4000 … … … …

© 2024 SPLUNK INC. テレメトリーとコストをコントロールメトリクス数の集約・削減・アーカイブ化によって、テレメトリー量を抑制現在取得されている時系列メトリクス数（Metric Timeseries)
メトリクス集約により生成されるメトリクス数最終的な時系列メトリクス数

© 2024 SPLUNK INC. テレメトリーとコストをコントロールメトリクス数の集約・削減・アーカイブ化によって、テレメトリー量を抑制アーカイブ化により、必要な時だけ参照できるように安価なバックエンドストレージにメトリクスを保管参照が不要な場合は、対象のメトリクスを
破棄することで、MTSを減らす

© 2024 SPLUNK INC. テレメトリーとコストをコントロールメトリクス数の集約・削減・アーカイブ化によって、テレメトリー量を抑制集約・削減・アーカイブ化いずれの場合でも、対象となるメトリクスを属性に基づいて指定可能メトリクスに含まれる特定の
ディメンションを維持（Keep）または削除（Drop）ディメンションごとの MTS数や、Keep/Drop 対象の選択はGUIからも可能

© 2024 SPLUNK INC. テレメトリーとコストをコントロールトレースサンプリング戦略と、トレースボリュームのコントロール https://opentelemetry.io/blog/2022/tail-sampling/ サンプリングを考慮する背景 • オブザーバビリティバックエンドへのデータ取り込みコスト管理
• 調査すべきトレースへのフォーカス • ノイズとなる情報の除去もちろん必要に応じて、OpenTelemetry仕様に基づいた一般的なサンプリング戦略も採用が可能（Head-Based, Tail-Based, Probability Sampling…） Splunk Observabilityが提供する NoSampling に耐えるバックエンドと高い分析性能

• 短期的に、効率的にオブザーバビリティの取り組みを広げていくための仕組みを作る • 中長期的な視点から、オブザーバビリティの取り組みが継続可能な戦略、ロードマップ、アーキテクチャを選択する • 計装を継続的に深め、オブザーバビリティを高めていく中長期的・継続的な取り組みコストコントロール関係者を巻き込み理解を促すベストプラクティスの採用・実装 • 予期せぬコスト発生を防ぐ管理と仕組みで、予算を守る • 活用の頻度に応じて、取得するテレメトリーデータを管理し、コスト最適化を進める • ビジネスへの貢献や成果をアピールし、取り組む仲間を増やす • 新たなニーズやフィードバックを得て、次の取り組みに活かす技術的・機能的に対応できるものはどんどん実装・活用していく組織的な実践にフォーカスしていくナレッジやルールを整理し、文化を醸成する

© 2024 SPLUNK INC. 組織的な取り組み 10章『オブザーバビリティへの取り組みをチームへ適用する』 “ 私たちにとって、この章は特に書きにくいものです。この道を歩き始める多くのチームを支援してきた私たちは、成功のための普遍的なレシピが存在しないことを知っています。
… オブザーバビリティへの旅は、あなたやあなたのチームにとってもっとも適切な問題、既存のツールとのギャップ、組織の他の部門からのサポートと賛同のレベル、チームのサイズ、その他の考慮事項などといった特殊性に左右されるのです ” 言うは易く、行うは難し

© 2024 SPLUNK INC. お気軽にお声がけください！ • Splunk Observability 無料トライアルが可能です •
導入に向けたご相談、具体的な課題にあわせたコンサルティングにも対応しています • トライアル時のガイド支援、個別のワークショップなども対応可能です Splunkエンジニアが伴走支援します ←無料トライアルはこちらから https://www.splunk.com/ja_jp/download/o11y-cloud-free-trial.html

© 2024 SPLUNK INC. システム全体のオブザーバビリティを高める実践を組織的・継続的に推進していく必要がある • 「はじめてみる」と「広げていく」は、まったく異なる性質の取り組みである • プラットフォームエンジニアリングに代表される、
組織的・継続的な取り組みとして管理・推進していく必要がある • オブザーバビリティの取り組みを管理する機能にも注目・活用する必要がある • Splunkは、組織的・継続的なオブザーバビリティの実践を支える特長と、エンジニアによる伴走支援によって、オブザーバビリティの実践を支援する

CNDS2024 - 組織をまたいで実践するオブザーバビリティの勘所

CNDS2024 - 組織をまたいで実践するオブザーバビリティの勘所

More Decks by Kentaro Nakagami

Other Decks in Technology

Featured

Transcript