- 2025/10/27
- https://o11ycon.jp/
- #o11yconjp
Affordable Observability: Strategy to Implementation
Liz Fong-Jonesさん(Field CTO, honeycomb.io)
- データはSREやDevOpsに効果的
- データが無ければ何もできない
- クラウドになってプロダクションで効果的なデバッグはできない
- o11yに費用を書けるが期待する結果がでないことも
- otelを使うとデータ収集は簡単にできそう
- 可視化ツールも多くある
- 難しいのは保存と収集
- 開発者が知りたいのはユーザのトランザクションがどうなっていて同機能しているか
- 最も効果的な方法は何かという視点で考えるのがいい
- 自前で作ると保守運用コストが大きすぎる
- それ自体がビジネス目的ではないことに注意
- まずはユーザの体験の測定から
- 利用者にとってのシステム利用の成功とはなんなのか
- 上手く使えているかエラーが起きてるかどう判断すれば良いのか
- それらを踏まえると何が知りたいかが分かる
- メトリクスで解決できないからといってログやツールを増やすのはコストの増加につながる
- ログの保存などのコスト
- ツールの費用
- 認知負荷
- o11yでもreuse/reduce/recycle
- エラーの記録
- 全てのエラーと遅いクエリは必ず記録したい
- 分散トレーシングだとサンプリングとの兼ね合いが仕組み上難しい
- telemetryはinsightではない
- Open Telemetry
- コミュニティドリブン
- ベンダーニュートラル
- ベンダーやCNCFにサポートされている
- 利用者からのフィードバックも歓迎している
- 私達の目的
- 開発者が本番環境を理解し問題を迅速に解決できること
- ユーザへの影響を最小限に抑えること
- コードをはやくリリースできること
- o11yをチームの文化に
- プロセスに組み込む
- 変更したときにドキュメント化されてるか
- 本番デプロイしたときにメトリクスを確認するリンクを見れるか
- 数値が上がるか下がるか予測できているか
- o11yの導入
- 一度に導入するのは難しい
- 個々のチームから始めて価値を実感する
- チームごとに成功を定義して成果を計れるように
- 隣のチームへ広げていく
- Otel Collector
- o11y導入の基盤となる
- 設定管理やで^た変換、フィルタリングなど可能
- エージェントモード
- サンプリングの設定もコードではなくここで
- 全てのデータを受け取った上で処理するから
- 高額請求を避けるためにサンプリングは事前に積極的に
可観測性は開発環境から、開発環境にもオブザーバビリティ導入のススメ
Yuzuru Ohiraさん(LayerX)
https://speakerdeck.com/layerx/dev-environment-observability-guide
- Ai Workflow
- LayerXのサービス
- 開発環境
- ローカル - dev - stg - prod
- devはマージ後に反映される環境という前提
- o11y検討段階
- ADRやDesighnDocは整理されていた
- 優先度の問題でなかなか進まない
- サービス特性としての課題
- これまではAIのワークフロー
- これからはエージェント
- o11yが必要とされる課題
- OpenAIにつながらない
- Redisなどに接続できない
- Azure使ってるが経験者が少なくトラブルシューティングの方法がない
- 開発環境からやる意思決定
- 問題が深刻なので足下をはやく整理したい
- 開発環境で整備されてないと全体のボトルネックになる
- 開発で整理し尽くされていれば本番も容易にいけるのでは
- まずは見える化
- 開発環境でトレースを優先
- サンプリングされても自分のアクセスを大抵確認できる
- ログとメトリクスは補助
- 導入の成果
映えないObservability
Kazuki Iwanagaさん(株式会社MonotaRO)
https://speakerdeck.com/monotaro/observability-conference-2025-monotaro-legacy-observability
- モノタロウ
- BtoB向け
- 関節資材
- ロングテール/多品種/複雑な購買
- 買う頻度が少ないものを手間なく買えるように
- 商品がある/すぐ見つかる/すぐ届く
- 事業の成長に伴う複雑性の増加
- レガシーな基幹システム
- モダナイズの取り組みで解消されるがまだまだ時間はかかる
- リプレイス後の方は自然とo11yは進んでいく
- 残っているレガシーは意図的に対応していかないと
- o11yで解決したい課題を具体的にしていくところから
- これからやろうとしてること
- ビジネスの成長サイクルが回せているかを知るためのo11y
- どの最適化がどれくらいの効果を得たかの理解
- 手動での対応も含めた追跡
- サプライチェーン管理の部門も含めた議論
Observability文化はなぜ根付かないのか 〜よくある失敗とその回避策〜
佐野 浩也さん(ULSコンサルティング株式会社)
- 技術 + プロセス + 組織 = 文化
- ツールを入れただけなど一部分だけでは浸透しない
- よくある失敗
制約下の医療LLM Observability〜セキュアなデータ活用と専門家による改善サイクルの実現〜
保坂 桂佑さん(株式会社カケハシ)
https://speakerdeck.com/kakehashi/building-trust-in-medical-llms
- 医療向けアプリでのLLM活用
- o11yが難しい
- 厳格なデータ保護
- 高い出力品質の要求
- o11yが難しい
医療システムのObservability向上のためのOpenTelemetry活用
山田 佑亮さん(株式会社ispec)
- 医療DX
- ITインフラがレガシーすぎる
- インターネットにつながらない環境
- 組織業務の硬直化
- 業務の改善が進まない
- ITインフラがレガシーすぎる
- CloudSail
- 閉域PCからクラウドへのアクセス
- サーバ上で動かすアプリ
- アプリ提供ベンダーがテレメトリを確認できないといけない
- 複数ベンダーのテレメトリが混ざらないように
- ベンダー側がテレメトリのサンプリングやフィルタリングを制御できるように
- ベンダー用のCollectorを一段挟んで各ベンダーへ送る
ピーク時165万スパン/秒に立ち向かえ！オブザーバビリティコストを効率化する ABEMA におけるトレースサンプリングの実践的事例
山本 哲也さん(株式会社AbemaTV)
逆井 啓佑さん(Datadog Japan)
https://speakerdeck.com/tetsuya28/abema-trace-sampling-observability-cost-optimization-f4d43a88-8257-4bc1-be03-5c9b2333c8da
- トレースの保存
- 全てを保存するのはコストに見合わない
- 大量の正常系
- ヘルスチェック
- トレースのサンプリング
- Datadogのトレースサンプリング
- ヘッドベースサンプリング
- パスごとに割合を設定できる
- テイルベースサンプリング
- エラーがあったらとか条件をUI上で設定
- Datadogにデータさえ送ればいい感じにやってくれる
- ヘッドベースサンプリング
- Abemaのオブザーバビリティ
- コストとオブザーバビリティの天秤
- トレースを全部見るのは現実的じゃない
- 必要なデータだけを安く見たい
- 何をサンプリングするか
- サンプリングをどのようにするか
- マイクロサービス - Datadog Agent - Otel Collector - Datadog
- Datadogに送信する前
- 取り込んだ量に対して課金されるのでこのタイミングで減らす必要あり
- テイルベースサンプリング
- マイクロサービスからは全部をDatadogAgentへ
- DDOTでOtel Collectorへ
- Otel Collectorでルールに応じてデータをドロップさせ送信
- Datadogに送信した後
- 送信後は事前に削ってるので基本残していく
- Retention Filterで絞り込み
- Intelligent retention filter
- Datadogが判断した必要なトレースを残してくれる
- サンプリングの導入でコストが10%以下になった
- トレースを全部見るのは現実的じゃない
ゼロコード計装導入後のカスタム計装でさらに可観測性を高めよう
Eiji Maedaさん(Sansan株式会社)
https://speakerdeck.com/sansantech/20251027
- BillOne
- TypeScriptとKotlin
- マイクロサービス20くらい
- GoogleCloud
- 自動計装とカスタム計装
- 今はゼロベース計装とコードベース計装という
- 前者は導入だけで勝手に送られる
- 後者は自分で実装して送る
- APM導入の経緯
- アプリのレイテンシ悪化で問題が起きた
- 数カ月かかって原因を突き止めた
- 自動計装入れた後にカスタム計装をどこからやっていくといいか
- 日々の運用で役立つところ
- プロダクトで重要な機能
- BFFでの計装
- ユーザ情報を計装したい
- 各FEからのアクセスが来るところがBFF
- ユーザIDやルーティングなど
- middlewareなどとして処理を挟めばOK
- 特定のマイクロサービスでの計装
- 検索機能の計装をしたい
- 請求書を検索してそこから利用が始まるので重要な機能
- レイテンシの悪化や検索の利用状況についてデータが何もないなどの問題があった
- 検索のパラメータは大量すぎる
- レイテンシに影響出そうな項目の当たりをつけてデータをとる
- この例では日付の範囲が広いとレイテンシが悪化するという結果だった
- ユーザが指定したデータをそのまま出力しても意味がなかった
- 具体的な日付が見えても4/1でも7/1でも違いは小さい
- 開始のみしか指定してないとか範囲が90日間とかそういう情報の方が有用
- 非同期処理の計装
- 受け取る方と送る方の両方
- キューが100以上あってトピックが100近くある
- 知りたいこと
- キューが詰まってないかとか
- どこに送ったか/どこから送られてきた
- どれだけ時間がかかったか
- 自動計装だけではトレースが途切れてしまう
- HTTPのコンテキスト伝播は自動でやってくれてる
- 非同期はやってくれてないかおら途切れてしまう
- 自前で実装すればつなげられる
オブザーバビリティ成熟度モデルの企画から社内導入まで：複数サービスでの評価を通じた組織変革の軌跡
- o11yを実践する中での課題
- チーム感での理解や実践のばらつき
- 知識や対応が個人に属人化した運用
- 現状が把握できず改善の停滞
- 成熟度モデルの設計
- モデル設計の3原則
- シンプル
- 段階的
- 比較可能性
- CMMIに準拠
- レベル1: 属人的
- レベル2 :基本管理
- レベル3: 標準化
- レベル4: 定量管理
- レベル5: 継続改善
- 6項目をそれぞれ5段階で評価
- データ収集と可視化
- システムのデータを網羅的に収集しリアルタイムで可視化分析ができる能力
- アラート最適化と障害対応
- システムの異常を検知し対応を実現する能力
- システムの信頼性管理
- 障害対応復旧プロセスの整備と指標による改善を継続
- 開発運用プロセスの整備と最適化
- コード品質を維持したまま予測可能で安定したデリバリー
- ユーザ行動の理解と最適化
- ユーザの行動/ニーズを把握し改善を継続的に推進
- 継続的な改善と最適化
- モニタリング等による継続的改善をチーム組織で推進
- データ収集と可視化
- モデル設計の3原則
- 実践的な評価の導入
- アンケートで自己評価
- 個人の主観ではなくチームで議論した回答
- 該当しない項目は無回答OK
- アンケートで自己評価
- レベル別の改善アクションプラン
- 6項目の各レベルごとに次に行くには何をするといいかまとめてる
- 導入後の課題
- 改善の停滞
- 優先度の問題
- 継続性の課題
- 継続する仕組みと長期的な改善サイクルがないこと
- 改善の停滞
- 導入後の変化
- 共通言語ができた
- 議論のきっかけに
- データドリブンな改善
- 評価の位置づけ
- スコアの高低ではない
- 現状の理解と未来を考えるための指針
オブザーバビリティと共に育てたID管理・認証認可基盤の歩み
高井 真人さん(株式会社カミナシ)
https://speakerdeck.com/kaminashi/the-journey-of-an-id-management-authentication-and-authorization-platform-nurtured-with-observability
- カミナシのサービス
- マルチテナント
- それぞれのテナントで複数のサービスを使ってる
- 認証認可は共通的に必要
- 認証認可基盤の特性
- Kalman Filter
- 入力に対する出力
- 真のシステム状態の時の真の出力がある状態で
- システム状態を推測し推測の出力から誤差を埋めていくことで内部状態を推測できる
- 入力に対する出力
- OAuthクライアント認証の性能低下の事例
- ライブラリがDBアクセスを何度もしていて負荷が高い
- ハッシュ計算でCPU負荷向上
- ライブラリには手を入れたくないので外側で解決策を模索
- ライブラリの計装が不十分なケースはローカルで手を入れたりプロファイラを駆使したり
- サービスレビュー
- 週次でレポートを作成し傾向の確認
- パフォーマンス
- 先週と比較
- 長期的なトレンド
- 問題が起きたエンドポイント
- エラー
- 想定がいエラー
- 不要なエラー
- パフォーマンスと関連するエラー
- コスト
- 先週と比較
- 長期的な傾向
- 特にコストの掛かるサービス
- 対処を入れたサービス
- パフォーマンス
- チーム内で理解や勘所を継承していく
- 週次でレポートを作成し傾向の確認
クロージングキーノート: これからのオブザーバビリティ(仮)
大谷 和紀さん(Cisco Systems)
- カンファレンス振り返り
- セッション25
- 現地参加444名
- オンライン視聴590名
- セッション振り返り
- オブザーバビリティの価値
- 始め方と広め方
- 効果的なオブザーバビリティ
- AI for o11yとo11y for AI
- これからのオブザーバビリティ
オブザーバビリティが育む開発者のシステム理解と好奇心
Toshiya Katoさん(LINEヤフー株式会社)
https://speakerdeck.com/maruloop/observability-for-the-system-understanding-and-curious-by-developers
オブザーバビリティの効果を可視化するIncident Response Metricsの実践
高村 成道さん(株式会社Topotal)
https://speakerdeck.com/nari_ex/observability-extending-into-incident-response
現場の壁を乗り越えて、「計装注入」が拓くオブザーバビリティ
Kento Kimuraさん(Datadog Japan)
https://speakerdeck.com/aoto/beyond-the-field-barriers-instrumentation-injection-and-the-future-of-observability
AIスパコン「さくらONE」のオブザーバビリティ
Yuuki Tsubouchiさん(さくらインターネット研究所)
https://speakerdeck.com/yuukit/observability-for-ai-supercomputer-sakuraone
OpenCensusと歩んだ7年間
田中 篤志さん(ウォンテッドリー株式会社)
https://speakerdeck.com/bgpat/opencensustobu-nda7nian-jian
エンタープライズBPMプラットフォームにおけるO11y
蒲生 廣人さん(Dress Code)
https://speakerdeck.com/gamonges_dresscode/entapuraizubpmpuratutohuomuniokeruo11y
LLMオブザーバビリティにおけるトレースの拡張
Yoshitaka Fujiiさん(LINEヤフー株式会社)
Shuhei Kawamuraさん(Kong K.K.)
https://www.docswell.com/s/shukawam/K74MX6-observability-conference-tokyo-2025
SRE × マネジメントレイヤーが挑戦した組織・会社のオブザーバビリティ改革 ― ビジネス価値と信頼性を両立するリアルな挑戦
外接に惑わされない自システムの処理時間SLIをOpenTelemetryで実現した話
新 浩太朗さん(株式会社NTTデータグループ)
https://speakerdeck.com/kotaro7750/wai-jie-nihuo-wasarenaizi-sisutemunochu-li-shi-jian-sliwoopentelemetrydeshi-xian-sitahua
