Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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.

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

© 2024 SPLUNK INC. Splunk Observability すべてのユーザーに 探索的なアプローチを提供

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

© 2024 SPLUNK INC. オブザーバビリティを 広げていく

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

© 2024 SPLUNK INC. Getting Started まずは、あるチーム・あるシステムでオブザーバビリティに取り組む システム ユーザー Devチーム Opsチーム Trace Metric Log 開発/計装, 問題調査・対応 よく聞くあのツールを試してみよう… エージェント入れてみて… いい感じのダッシュボードを見てみて… ぼちぼちっとアラートも設定してみて… APMというのがあるらしい… エージェントをアプリと一緒に動かして… へえ、こんな感じなのね…

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

© 2024 SPLUNK INC. Getting Started まずは、あるチーム・あるシステムでオブザーバビリティに取り組む システム ユーザー Devチーム Opsチーム Trace Metric Log 開発/計装, 問題調査・対応 いい感じのものができた!! めでたし、めでたし (完)

Slide 14

Slide 14 text

© 2024 SPLUNK INC. Getting Started まずは、あるチーム・あるシステムでオブザーバビリティに取り組む システム ユーザー Devチーム Opsチーム Trace Metric Log 開発/計装, 問題調査・対応 いい感じのものができた!! めでたし、めでたし (完) ❓❓❓

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

© 2024 SPLUNK INC. 組織的に取り組む オブザーバビリティと Splunk Observability

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

© 2024 SPLUNK INC. OpenTelemetry 準拠の重要性

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

© 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/

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

© 2024 SPLUNK INC. OpenTelemetryによって得られる柔軟性 Gatewayモードを活用して、テレメトリーを集約・管理する システムA アプリケーション OpenTelemetry Collector (Agent Mode) システムB アプリケーション OpenTelemetry Collector (Agent Mode) OpenTelemetry Collector (Gateway Mode) 機能面でのニーズにあわせて 一括でバックエンドを 切り替えることも可能 もうすこし 高度な分析機能が欲しい

Slide 54

Slide 54 text

© 2024 SPLUNK INC. OpenTelemetryによって得られる柔軟性 Gatewayモードを活用して、テレメトリーを集約・管理する システムA アプリケーション OpenTelemetry Collector (Agent Mode) システムB アプリケーション OpenTelemetry Collector (Agent Mode) OpenTelemetry Collector (Gateway Mode) 環境別・システム別などで データを送り分けることも可能 開発環境では OSSでコスト抑制 本番環境は 商用サービスで

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

© 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にも、ベストエフォートのサポートを提供)

Slide 58

Slide 58 text

© 2024 SPLUNK INC. テレメトリーとコストを コントロール

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

© 2024 SPLUNK INC. 組織的な実践を 進めていく

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

© 2024 SPLUNK INC. 組織的な取り組み 皆様のオブザーバビリティの実践を 成功させるために、 さまざまなご支援を行っています Splunkエンジニアが伴走支援します

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

© 2024 SPLUNK INC. まとめ

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

© 2024 SPLUNK INC. すこしだけ告知: OpenTelemetry Meetup #3 2024/06/25 @渋谷 https://opentelemetry.connpass.com/event/317170/

Slide 75

Slide 75 text

© 2024 SPLUNK INC. Thank you 本セッションの感想をお待ちしています