🎛️
「そのオブザーバビリティツール、どう活かした？実践例と効果の全貌」イベントレポート
公開
2025-03-05
文章量
約5066字
Yard 編集部
Yardの編集部が、テック業界の最新トレンドや知見について発信します。
目次
イベント概要とゴール
1. 「まずは実践！エラーバジェット活用による気づきと学び」
林 知範 氏（NTTコミュニケーションズ）
■ハニカム導入とトリガー設定
■エラーバジェットと“偽装エラー”
■ディテクトアノマリーズとガードレール
2. 「Datadog Workflow Automation で圧倒的価値提供」
伊藤 勝梧 氏（株式会社Degica）
■従来の課題：アラートは飛ぶが十分な情報がない
■Workflow Automationで一次調査を自動化
■Tips：小さく試作して実績を示す
3. 「Grafana の organizations を使ってマルチテナント構成を考えてみた」
間瀬 真 氏（クラウドエース株式会社）
■複数顧客への可視化ダッシュボード
■organizationsで権限を分離
4. 「エラーからパフォーマンスまで監視！新規プロダクトでのSentry活用法」
林 優太 氏（ファインディ株式会社）
■エラートラッキングと一括管理
■Pandas的に使える？ 分散トレースの威力
■Web Vitalsとサードパーティフィルタ
5. 「New Relicで解決するNewsPicksの本番障害。厳選N選（N≧3？）」
飯野 卓見 氏（株式会社ユーザベース）
■事例1：N+1クエリでSLOアラート
■事例2：プッシュ通知で急に重いAPI
■事例3：コネクションプール枯渇
全体の感想──“オブザーバビリティ”は最強の保険
イベント全体を踏まえた感想
2025年2月26日、Findy Tools主催によるオンラインイベント「そのオブザーバビリティツール、どう活かした？実践例と効果の全貌」が開催されました。
巷で数多く語られる「オブザーバビリティ」ですが、そのツールを実際の本番環境でどう運用し、どんなチーム体制で成果を上げているのか——そこが本イベントの大きな焦点。
本レポートでは、5名の登壇者が語ってくれた事例とノウハウをまとめ、ご紹介します。
イベント概要とゴール
複雑化が進むシステム構成において、監視データの可視化や深い分析力を持つことは、問題解決や運用効率を劇的に高めるカギになります。
本イベントでは、Datadog・Grafana・Sentry・New Relic・Honeycombなど、さまざまなオブザーバビリティツールを導入・活用する5名が事例を披露。「どんな課題があって、どのツールをどう使ったか」「どんな効果が得られたのか」を赤裸々に語り合う場となりました。
1. 「まずは実践！エラーバジェット活用による気づきと学び」
林 知範 氏（NTTコミュニケーションズ）
最初に登壇したのは、ノーコードAIツール「Node-AI」の開発・運用に携わる林氏。NTTコミュニケーションズでは、本番のサービス品質を保つための“エラーバジェット”活用を模索した結果、Honeycombを中心にオブザーバビリティの仕組みを整備しているそうです。
■ハニカム導入とトリガー設定
林氏によれば、Honeycombは比較的スモールスタートしやすく「数分でトレース送信まで行える手軽さ」が魅力。最初はサービス異常検知を目的に「特定の500エラーが増えたらSlackへ通知する」トリガーを設定していたものの、単発エラーが多すぎてノイズ化する場面があったそうです。
■エラーバジェットと“偽装エラー”
さらにチームがエラーバジェットを導入すると、想定外に「偽装エラー」がバジェットを消費する事態が発生。そもそも不要な500を返している実装ミスがあり、それを原因にエラーが急増していたと言います。結果的に「エラーバジェットが減る＝本番障害とは限らない」と学び、運用ではスキルと割り切りが重要だと感じたとのこと。
■ディテクトアノマリーズとガードレール
Honeycombで特に林氏が気に入っているのは「ディテクトアノマリーズ（旧クイック・バブルアップ）」。エラー率の高い区間を選択すると、基準期間との差分を自動算出し、潜在的なパフォーマンス劣化や異常な属性を提示してくれます。こうした自動化で、“原因究明の手がかりを高速に得る” のがエラーバジェット運用をスムーズに回すコツだと強調されました。
2. 「Datadog Workflow Automation で圧倒的価値提供」
伊藤 勝梧 氏（株式会社Degica）
続いて、SREとして多国籍チームを率いる伊藤氏は、Datadog Workflow Automationの活用事例を披露。「従来のDatadogアラートに、さらに“一次調査を自動化”するステップを加えるだけで、オンコールの効率が飛躍的に向上する」と語ります。
■従来の課題：アラートは飛ぶが十分な情報がない
アプリの“400エラーが急増”のようなシンプルなアラートは、一見すると問題に気づきやすいものの、それが深刻なのかどうか、どのエンドポイントか、すぐには判断しづらいと伊藤氏。実際、オンコール対応時に「とりあえずPCを立ち上げないと原因が分からない」といった状況はよくある話です。
■Workflow Automationで一次調査を自動化
伊藤氏が導入したのが、Datadogの比較的新しい機能「Workflow Automation」。アラートが発火したら、その対象メトリックスやログを参照して、どのエンドポイントが悪化しているかなどの概要をSlackに投稿してくれるフローを設定。結果、オンコール担当は通知メッセージを見るだけで“緊急度”を把握できるように。時間外対応の煩雑さが「10分→1分」に短縮されたとのことで、チーム内での満足度も高いそうです。
■Tips：小さく試作して実績を示す
新しいツール導入を組織で定着させるポイントとして、「まずは自分が手を動かし、周囲が“おっ、便利そう”と思う実績を作る」のがコツと伊藤氏は言います。少人数向けに小さな成功例を積み重ねると自然に利用者が広がっていくそうです。
3. 「Grafana の organizations を使ってマルチテナント構成を考えてみた」
間瀬 真 氏（クラウドエース株式会社）
3人目は、クラウドエースにてGoogle Cloudの導入支援や新規ビジネス立ち上げに携わる間瀬氏。複数顧客の運用保守を行う際に「Grafanaをマルチテナントで使う」ためのポイントを語ってくれました。
■複数顧客への可視化ダッシュボード
クラウドエース社では、顧客ごとに運用を代行する「運用保守サービス」の一部として、コスト最適化やリソース状況を可視化するダッシュボードを提供。しかし、各顧客のデータが混じってしまうと大問題。しかも、Grafanaを顧客数分まるごとインスタンスを立てる方法だと、DNS設定やインフラ管理コストが膨大になる。
■organizationsで権限を分離
そこで活用したのが、Grafana OSSでも使えるorganizations機能。組織（organization）を顧客単位で分割し、そこにダッシュボードやデータソースを紐づけることで、他顧客の情報が一切見えなくなる構成を実現。さらに、自社のアドミンがまとめて管理しやすいように、全顧客を1つのGrafanaインスタンスに集約したまま、顧客ごとに閲覧範囲だけをしっかり制御できるそうです。
4. 「エラーからパフォーマンスまで監視！新規プロダクトでのSentry活用法」
林 優太 氏（ファインディ株式会社）
4番目に発表した林氏は、新規プロダクト「Findy Tools」の立ち上げ当初からSentryを導入・運用してきた経験を紹介。「Sentryは単なるエラー監視に留まらず、分散トレースやWeb Vitals計測まで柔軟に担える」と評価しています。
■エラートラッキングと一括管理
Sentryの特徴は「同じエラーを一周単位でまとまり管理できる」点。エラーが増えすぎて埋もれがちな現場でも、週1ペースでSentryのリストを整理し、修正が必要なものとそうでないものを仕分ける運用を実践。エラー増加時にはSlack通知も行っており、新規サービスの予期せぬエラーがすぐ把握できるそう。
■Pandas的に使える？ 分散トレースの威力
とりわけ、フロント（NEXT.js）からバックエンド（Rails）に至る分散トレースが大助かりだったとのこと。ユーザーの画面でエラーが起きた場合、フロントの情報だけでなくAPIのレスポンス状況までワンストップで確認しやすい。林氏は「バラバラのツールを使うより、Sentryひとつで全体を追えるのが新規プロダクトにぴったり」とコメント。
■Web Vitalsとサードパーティフィルタ
Webのパフォーマンス指標「Web Vitals」を計測し、遅延が大きくなったタイミングをモニタする活用例にも注目。また、ブラウザ拡張機能などの雑多なエラーをノイズとして排除するための「サードパーティフィルタ」機能が登場し、ノイズ削減にも大きく役立っているそうです。
5. 「New Relicで解決するNewsPicksの本番障害。厳選N選（N≧3？）」
飯野 卓見 氏（株式会社ユーザベース）
トリを飾ったのはNewsPicksのSREチームに所属する飯野氏。New Relicを用いた本番障害の解決事例を3つ（+α）紹介し、どのように速やかに原因特定と対策を進めたかを語りました。
■事例1：N+1クエリでSLOアラート
特定のAPIレスポンスが急遽遅くなり、SLOアラートが連発したケース。APMのリリーストラッキングで、遅延が発生し始めたタイミングに施されたリリースを簡単に特定できたそうです。さらにデータベースタブでN+1を発見し、該当リリースをロールバック→修正の王道フローで解決。
■事例2：プッシュ通知で急に重いAPI
「プッシュ通知後にみんなが一斉にアプリ起動→特定APIが大負荷に」という現場あるある。New RelicのAPM・データベースページで“異常にアクセスが集中したテーブル”をすぐに発見し、負荷急増の根本要因（アプリ側の画面変更）まで到達。APIを高速化・呼び出し数削減することで安定化できたそうです。
■事例3：コネクションプール枯渇
裏側で「禁断API」と呼ばれる超重い操作が呼ばれ、コネクションプールが尽きてしまうケース。全APIが巻き添えで落ちるため大きな影響がありましたが、APMのデータベース分析で“怪しいAPI”を特定。ダッシュボードを後から作り、プール使用率を可視化して監視しているとのこと。
全体の感想──“オブザーバビリティ”は最強の保険
複数のオブザーバビリティツール活用例を眺めると、どれもが異なるアプローチや特徴を持ちつつ、「本番トラブルをいかに高速に検知し、原因追求できるか」という共通の狙いに集約されるのが印象的です。
- Honeycomb：イベントドリブンな分析ループとエラーバジェットを軸に運用効率を高める
- Datadog Workflow Automation：単なるアラートから一歩進んで“一次調査結果”まで自動化
- Grafana：マルチテナント機能で、複数顧客向けダッシュボードを安全に提供
- Sentry：エラー管理を軸に、分散トレースやパフォーマンス計測まで統合
- New Relic：APM・データベース監視を中心に、高度なリリーストラッキングやSLI管理を実現
導入のしやすさ、使い勝手、エコシステムとの相性など細かな違いこそあれ、どのツールも“現場視点”の機能が充実し、ちょっとした一工夫で強力な味方になり得る印象です。また、「導入しても周りが使ってくれなければ意味がない」という課題は、どの事例でも共通していました。だからこそ、「まずは自分が試し、結果を周囲に見せる」——こうした地道なエバンジェリズムが欠かせないようです。
イベント全体を踏まえた感想
全体を通じて、オブザーバビリティがもたらす価値は「障害対応の効率化」だけではない、と強く感じました。障害が起きたときの原因究明が格段に早まるのはもちろん、新しい機能の影響度合いを察知し、そこからパフォーマンスや設計上のボトルネックを可視化し、最適化のヒントを得られるのも大きい。
特に、多様な観点のデータをまとめて見られる“分散トレース”や“ダッシュボードのマルチテナント運用”などは、従来の監視ツールでは得にくかった新たな運用スタイルを拓いているように映ります。
「ツール自体を使うことが目的ではなく、最終的にはユーザーへの価値を生み出すためにどう役立てるか」。どの登壇者も口をそろえていたのは、「結局はビジネス上のインパクトをどう高めるか」という姿勢でした。
ツールはあくまで一部であり、チームが協力してそのツールを使いこなし、習慣化することがポイント。そのためには、まずは“小さな成功”を示し、周囲に説得力を持たせる——これが欠かせないと、多くの事例から学べたのではないでしょうか。
本イベントを機に、皆さんも自社プロダクトや組織の状況に合わせて、新たなオブザーバビリティツールの活用にチャレンジしてみてはいかがでしょうか。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
