🎃
Observability Conference 2025視聴メモ
Observability Conference 2025
Observability Conference 2025 を視聴したメモを残していきます。
今回はオンライン参加。
個人的なメモなので全部網羅的に書くことは目指してないです。
視聴予定
12:10 - 12:40 現場の壁を乗り越えて、「計装注入」が拓くオブザーバビリティ
- 現在のアプリケーションシステムの課題
- システムの多様化が進む
- 大規模組織では足並みが揃えにくい
- o11yの習熟度も異なる
- システムの多様化が進む
- レガシーシステムの残存、負債
- 過去資産の塩漬け
- どんな機能かわからない
- 判断できない
- 過去資産の塩漬け
- o11yをはじめる
- 計装→転送→保存→可視化
- 多言語、分散システム
- 依存関係がみたい
- レガシーシステム
- ブラックボックスの可視化
- 現場の壁
- 分散
- 言語ごとに方法が異なる
- トレースが繋がらない
- レガシー
- コード変更が重い
- 複数の環境に同時にコードの変更を伴わずに適用したい
- 計装注入
- 手動計装
- 直接API/SDKをたたく
- 自動計装
- 関数をラップしてSDK
- 計装注入
- コンテナ、プロセス単位でシステム機能を利用する
- 言語の違いを意識せずに広く適用できる
- 手動計装
- 計装注入
- 分散
- Otelから学ぶ
- できること
- テレメトリーの計装」、生成、送信ができるフレームワークとツールキット
- 計装：API
- 転送：collector
- 仕様：OTLP
- 考えることを減らす→計装注入
- OTEL telemetry
- 自動計装ツールをポッドに組み込む
- OTEL Injector
- Linuxの共有ライブラリ
- 共有設定をプリロード
- OTEL telemetry
- yamlテンプレートかhelmでインストール
- mutating admission webhookでリソースが永続化される前に変更を加える
- podのyaml定義が勝手に変わる
- OTEL Injector
- Zigで書かれてる、
- 自動計装エージェント
- どうやってアプリケーション言語を区別してるのか？
- 計装注入の構造
- システムコールされると動的リンカが起動
- どのプロセスが動いても必ず実行される
- getenvのときに自動計装に必要な環境変数が設定される
- できること
- 計装注入が最も導入コストが低い
- コードに手を加えない
-制限 - できる環境に制限がある
- K8sはLinuxを操作される
- 攻撃手法としての使われ方も把握していく
- 単純な計装に比べると柔軟性に劣る
- 細かい指定ができない
- 模索中で標準化されていない
- コードに手を加えない
- セキュリティ
- バックドアの注入
- 動的リンクハイジャック
- オブザーバビリティを高めて検出できる体制を整えること
- eBPF計装でも同じようなことができる？
感想
- 計装注入される仕組みまで深堀りして解説されているところが理解しやすくて良かった
- PJ自体はまだ初期のようなので様子見が必要。計装注入でどの粒度で取れるかは気になる
- XX注入で最近きいた話は依存性注入（Dependency Injection)。まったく違う観点だった。
12:50 - 13:10 Observability文化はなぜ根付かないのか 〜よくある失敗とその回避策〜
- ツールが活用されていない
- ツールを導入するだけではo11yは実践できない
- ツール参照の機会を増やす必要がある
- 日常のプロセスにツールを見るタイミングを組み込む
- ツール参照の機会を増やす必要がある
- ツールを導入するだけではo11yは実践できない
- チーム同士が連携できていない
- 関心ごとを少しずつ分散していく
- SERが開発チームを支援していく
- 開発チームには新機能のリリースに集中してもらう
- 関心ごとを少しずつ分散していく
- 対話が成立しない
- 共通言語を順番に整理していく
- 事実整理(システム用語)→意味づけ(〃)→問題合意(ビジネス用語)
- 事実のテンプレート化：何を判断するためにどんな事実が必要か
- フレームワークで意味づけ
- 合意形成
- トップダウンアプローチが必要(yotube)
- 事実整理(システム用語)→意味づけ(〃)→問題合意(ビジネス用語)
- 共通言語を順番に整理していく
- 失敗、懸念が隠蔽されて学びが促進されない
- 平常→予兆→問題
- 失敗、懸念で評価が下げる文化が問題
- 失敗こそ社内共有してほしい
- という心理的安全性の確保が重要、経営層の協力も不可欠
感想
日常のプロセスにツールを見るタイミングを組み込む
- 新しいことではないけど、チームによって注力する観点は違うのでそこを意識して継続していくしかないと改めて思った
13:40 - 14:10 プロファイルとAIエージェントによる効率的なデバッグ
- profile
- 一定期間の統計的な数値
- メトリクス、トレース、ログだけでは判定できない場合がある際に有効
- どの行でパフォーマンスが悪いかを計測できる
- 従来の実装方法
- 常時稼働Serviceの場合継続的プロファイルが有効
- profileをみてどこを修正するかすぐ分からない
- AIエージェントによる支援
- テレメトリー=コンテキスト
- 保存したprofileデータにたいしてAI解析をかける
感想
- これはやってみたい。
- profileをみてすぐにパフォーマンスチューニングするにはかなりハードルが高い。
14:30 - 15:00 反省から紐解くオブザーバビリティとして本当に必要だったテレメトリ
- 課題2：コスト
- テレメトリが不足すると分析できない
- 収集しても
- 思ったような分析ができない
- コストの問題
- 結論
- これだけ取っておけば良いというものはない
- コストとのバランスを見て継続的に見直し、育てていく
- これだけ取っておけば良いというものはない
- ここから始める
- 4大シグナル
- アプリケーションログ、インフラログ
- クラウド標準メトリクス
- 分散トレース
- 反省１：ユーザー目線の欠落
- インフラメトリクスのみを監視していた
- ユーザーの不満が高まっていった
- ゴールデンシグナルとは
- レイテンシー
- レスポンスタイム
- トラフィック
- 秒間リクエスト数
- エラー
- 飽和度
- CPU使用率
- レイテンシー
- シンプルさ
- ユーザー中心
- 反省２：モダナイゼーションの失敗
- マイクロサービスに移行したことでカスタムメトリクスの料金が増加
- クラウドの標準メトリクスで対応
- 反省３：モバイルアプリの複雑さ
- 特定のユーザーのみの問題に対処できなかった
- SPAでもテレメトリの収集が必要
- core web vital
- jsのログ
- リソース読み込み時間など
- 新しいテレメトリデータを取得する前に今あるデータで見えるかも必要
- 追加する際も段階的に追加する。追加→分析→必要性の再確認のサイクルで
- コストバランスは調整できる
感想
- テレメトリの収集も段階的な改善を進めるサイクルが重要
- 一度設定してもそれが使われているかどうかは定期的に見直す
- 目的に合わせたテレメトリの収集を行う
15:20 - 15:50 ゼロコード計装導入後のカスタム計装でさらに可観測性を高めよう
- トレース中心にアプリケーションへの計装実装について
- splunk apm
- kotlin nodejsを中心
- 分散トレーシングはもともとあり
- アプリケーション全体のレイテンシが悪化した際の調査が困難だった
- APMの導入を決定→OTELへ
- どこからカスタム計装するか
- 重要度の軸
- ユーザー情報の計装
- 検索機能
- 非同期処理
- ユーザー情報
- BFFで計装
- ユーザー種別
- ユーザーID
- どのサービスにルーティングしたか
- 一般的な注意点
- 個人情報を取得しないように
- BFFで計装
- 検索機能
- 元の原因
- レイテンシの悪化
- 検索の利用状況について回答できてない
- レイテンシの悪化しそうなところを洗い出した
- ユーザーが入れた値をそのまま検索しても意味ないケースが有る
- ユーザーが指定したパラメータを分解して計装
- 相対日付など
- APMでインデックスを貼る
- 必要ならロジックを書こう
- ユーザーが指定したパラメータを分解して計装
- 非同期処理の計装
- 自動計装では対応できない
- コンテキストが伝播されない
- HTTPのコンテキストの伝播はOTELがやってくれるため
- 元の原因
- 重要度の軸
感想
- 自動計装に頼らずに目的にテレメトリになるようにロジックを書けば良いのは学びになった。
16:10 - 16:40 オブザーバビリティ成熟度モデルの企画から社内導入まで：複数サービスでの評価を通じた組織変革の軌跡
- 成熟度モデルの設計
- 導入プロセス
- 組織変革
- 3step
- 直面していた課題
- チーム間のばらつき
- 属人化した運用
- 改善の停滞
- SREが主導
- 組織横断として活用できるため
- 全体最適化の追伸
- 全社的な影響力
- 成熟度モデルの設計
- シンプルでわかりやすい
- 段階的導入
- XX
- 理論的基盤と５段階成熟度モデル
- オブザーバビリティエンジニアリング２１章およびCMMI
- ６項目で各５段階の評価
- 重点項目：データ収集と可視化
- あらゆるデータを収集しリアルタイムで可視化
- 重点項目：アラート最適かと障害対応
- 以上を適切に検知しノイズを抑えながらジンそうな対応を実現する
- 残りの評価
- システムの信頼性管理
- 開発、運用プロセスの整備と最適か
- ユーザー行動の理解と最適か
- 継続的な改善と最適化
- 実践的な導入
- チーム内での合意を重視
- 明確な評価基準
- N/A選択肢の用意
- レベル別改善アクションプランの価値
- 期待通りにいかなかったこと
- 改善停滞 → 段階的アプローチ、レベル＋１を目指す
- 継続性の課題 → 成功体験の積み重ね
- 組織に生まれた変化
- 共通言語の形成
- 対話のきっかけ
- データドリブンな改善ができるようになった
- 評価は出発点である
- 改善の積み重ねを受信する姿勢
- 査定ではなく現状把握
- 長期視点で取り組む
- 今後の展望
- 継続可能な評価サイクル
- 定量的な指標を把握
- 中期的な振り返り体制
- 組織的な対話
- 継続可能な評価サイクル
- 明日からの実践
- アンケートで現状把握
- グラフで可視化
- レベル＋１への具体的な技術実装
感想
- 体系的な成熟度評価を定義されていて横断組織として機能させているところが学びになった。
- あらためてオブザーバビリティエンジニアリングの書籍を読み返したい
17:00 - 17:30 外接に惑わされない自システムの処理時間SLIをOpenTelemetryで実現した話
- 既存のSLIをだれも見ていない
- 課題１：個々の処理ロジックの違いを無視したメトリクス
- 個別機能の品質が判断できない
- ごちゃまぜ無意味
- 課題２：外接品質のゆらぎ
- 自システムの品質を判断できないSLI
- SLI設計の見直し
- ゴールを検討
- 全員が品質を同じ言葉で確認できる
- ゴールを検討
- 見直し１：ラベリングをして異なるロジックを識別できるようなグルーピング
- 見直し２：外接を除いた純粋な自システム部分のみを集計
- 見た人が判断を取れるようなSLIを実現
- 技術的なチャレンジ
- SLIを収集死体コンポーネント
- クライアントに近い箇所で取得
- SLIに必要な情報が分かるコンポーネント
- ↑とは違う箇所
- コンポーネント間で情報を統合・伝達できる仕組みが必要
- SLIを収集死体コンポーネント
- OTELで実現
- Baggage
- サービス間でメタデータのやり取りを行う
- Baggage
- 組織がどう変わったか
- 自システムの処理時間を基に会話できるようになった
- まとめ
- SLIは誰がどのような判断に活用するのか
- Baggageでコンポーネント間で情報を伝播できる
感想
- Baggageでコンポーネント間で情報を伝播するのは今後活躍しそうなのでおさえておきたい。
17:40 - 18:00 クロージングキーノート: これからのオブザーバビリティ（仮）
- オブザーバビリティの価値
- 始め方と広め方
- 効果的なオブザーバビリティ
- AI for o11y, o11y for AI
- ボトムアップ
- 次に何ができそうか
- トップダウン
- 今の課題は何か
全体の感想
- すべてo11lyに特化したテーマで技術的に深堀りしたものから組織適用の話まで幅広く聞けたので参加して良かった。
- 自分たちの組織でも活用できるテーマが多く有用だった。
- 実装手法にはOTELベースで語られている点が多かったので、どこの環境でも通用しそうで、自分たちとしてもOTELベースで実装していく必要があるかと感じた。
Discussion