New Relicで実現する実践的オブザーバビリティ：課題解決から始める導入ガイド

はじめに

オブザーバビリティツールを導入したものの、「何を見ればいいのか分からない」「データ量が増えてコストが膨らんでいる」「チーム間でうまく連携できていない」といった悩みを抱えていませんか。

実は、これらの課題は多くの組織が共通して直面している問題です。ツールを導入しただけでは、その価値を十分に引き出せません。重要なのは、導入後にどう活用するかという点にあります。

この記事では、New Relicの具体的な機能を活用して、オブザーバビリティ導入時の典型的な課題を解決する実践的なアプローチを紹介します。Service Levelsでビジネス指標を明確にする方法から、Pipeline Controlによるコスト最適化、Workloadsを使った組織連携まで、実務で役立つ知識をお届けします。

1. オブザーバビリティ導入で直面する3つの壁

まず、多くのチームがオブザーバビリティツール導入後に直面する主要な課題を整理しましょう。

1.1 「何を見ればいいか分からない」という戦略の欠如

最も多く見られる悩みが、監視すべき指標が明確でないという問題です。DatadogやNew Relicといったツールを導入したものの、デフォルトのダッシュボードを眺めるだけで終わってしまい、異常の予兆検知や原因特定に活かせていないケースが少なくありません。

CPUやメモリといったインフラ指標は正常なのに、実際にはユーザー側でエラーが発生しているという状況も起こりがちです。これは、技術的に取得できるデータと、ビジネスにとって本当に重要な指標との間にギャップがあるためです。

1.2 膨大なデータとコストの増大

オブザーバビリティを高めようとすればするほど、収集するデータ量が増え、それに伴ってコストも増加します。トレースやカスタムメトリクスを増やしすぎた結果、SaaSの利用料金が予想以上に膨らんでしまい、削減対応に追われるという事態も珍しくありません。

さらに、大量のログやアラートが生成されることで、本当に重要な障害情報が通知の山に埋もれてしまう「アラート疲れ」も深刻な問題です。情報が多すぎると、かえって重要なシグナルを見逃してしまうわけです。

1.3 組織への浸透とチーム間の壁

技術的な問題よりも、組織文化や役割分担に関する課題の方が根深いかもしれません。「監視はSREの仕事」という認識が定着してしまい、開発チームが自分たちのコードがどう動いているかに関心を持たないケースがあります。

また、計装作業が「機能開発を遅らせる面倒な作業」と捉えられ、協力が得られないこともあります。オブザーバビリティの運用がSREチームに丸投げされると、組織全体での改善サイクルが回らなくなってしまうのです。

2. Service Levelsで「見るべき指標」を定義する

それでは、「何を見ればいいか分からない」という最初の壁を、New RelicのService Levels機能でどう乗り越えるか見ていきましょう。

2.1 SLI/SLOの基本とビジネス価値

Service Level Indicator（SLI）とService Level Objective（SLO）は、サービスの信頼性を測る重要な指標です。SLIは実際の測定値、SLOはその目標値を指します。

New Relicの公式ドキュメントでは、ユーザーがビデオの読み込みに数秒かかることは許容しても、それが頻繁に起これば信頼を失うと説明されています。だからこそ、ユーザーにとって最も重要なパフォーマンス面についてSLIを定義し、そのサービスが期待を満たしているかをSLOで追跡する必要があるのです。

2.2 New RelicのService Levels機能の特徴

New RelicのService Levels機能には、いくつかの優れた特徴があります。

まず、作成が簡単です。ワンクリックで設定できるモードから、上級ユーザー向けの完全カスタマイズ可能なモードまで、複数の複雑度レベルで作成できます。APMサービスやブラウザアプリケーションに対しては、New Relicが最新のデータを分析してベースラインを自動計算してくれるため、すぐに利用を始められます。

次に、New Relicの各種機能と統合されています。Navigator、Workloads、ミニ概要など、ほとんどのNew Relic観測ツールでサービスレベルを可視化して作業できます。

さらに、アラートサポートも充実しています。注意を払うべき劣化について警告するアラートを作成できるため、問題が大きくなる前に対処可能です。

2.3 エラーバジェットによる意思決定の仕組み

エラーバジェットは、SLOを別の角度から見た指標です。これは、SLO期間中にまだ許容できる不良レスポンスの割合を示します。

New Relicでは、残りのエラーバジェットがパーセンテージで表示されます。25%以上であれば緑色で表示され、SLOは良好な状態です。25%を下回ると黄色に変わり、予算を使い切る寸前であることを示します。この段階では、新しいデプロイや変更により慎重になり、信頼性向上の作業を計画すべきタイミングです。

エラーバジェットが完全に使い切られると赤色で表示され、その期間のSLOを達成できていないことを意味します。この仕組みにより、「今は攻めのリリースができる」「今は信頼性に集中すべき」といった、データに基づいた意思決定が可能になります。

2.4 アラート連携で異常を素早く検知

New RelicのService Levelsは、アラート機能と連携して異常を素早く検知できます。

ファストバーン（Fast-burn）アラートは、Googleの推奨事項に従い、2%のSLO予算消費を1時間以内に検知します。これは、放置すると50時間でエラーバジェットを完全に消費してしまうペースです。急激で重大な消費の変化を警告し、すぐに対処できるようにします。

スローバーン（Slow-burn）アラートは、5%のSLO予算消費を6時間以内に検知します。これは、放置すると5日間でエラーバジェットを使い切るペースです。緩やかですが、コンプライアンス期間が終わる前にエラーバジェットを使い切る変化を警告してくれます。

このように、New RelicのService Levels機能を活用することで、バラバラなメトリクスを見るのではなく、ビジネス価値と直結した明確な指標で判断できるようになります。

3. Pipeline Controlでコストを最適化する

次に、データとコストの増大という2つ目の壁を、New RelicのPipeline Control機能で解決する方法を見ていきましょう。

3.1 データ管理が重要な理由

オープンプラットフォームとして、New Relicは大量のメトリクス、イベント、ログ、トレースを取り込めます。しかし、データを無制限に送信すると、それに伴うコストも増大します。

重要なのは、「全部のログを送る」という考え方から脱却し、「価値のあるデータだけにお金を払う」という視点に切り替えることです。New Relicの公式ブログでは、データ超過を望んでいるわけではなく、チームがNew Relicのオープンプラットフォームを最大限活用しながら、ボリュームやコンプライアンスの目的でデータを適切に管理できるようにしたいと述べられています。

3.2 Pipeline Controlの概要

Pipeline Controlは、New Relic Controlのデータ管理コンポーネントです。価値の低いデータをNew Relicプラットフォームに取り込む前にフィルタリングして破棄できます。

Pipeline Controlには2つのサブコンポーネントがあります。1つ目は「Pipeline Control Gateway」で、データがネットワークを離れる前にフィルタリングするよう設計されています。2つ目は「Pipeline Cloud Rules」で、New Relicクラウド内で処理を実行します。どちらのシナリオでも、Pipeline Controlは同一のNRQLクエリ構文を使用してデータを処理します。

Gatewayを使用するには環境で設定する必要がありますが、Cloud Rulesは設定不要です。これにより、チームは自分たちの環境や要件に最適な方法を選択できます。

3.3 Pipeline Cloud Rulesでデータを削減

Pipeline Cloud Rulesを使うと、取り込みパイプラインでデータを削除できます。この機能には重要なメリットがいくつかあります。

まず、アカウントに関連するデータのみを保存することでコストを削減できます。次に、個人を特定できる情報（PII）を削除することで、プライバシーとセキュリティを保護します。そして、無関係なイベントや属性を削除することで、ノイズを減らせます。

Cloud Ruleは、NRQLクエリに基づいてデータをマッチングします。ルールが作成された時点から到着するデータに適用され、すでに取り込まれたデータは削除しません。削除されたデータはバックエンドに到達しないため、クエリできません。つまり、データは完全に消去され、復元できないのです。

3.4 価値あるデータの見極め方

どのデータを保持し、どのデータを削除するかは、各チームや組織によって異なる判断になります。あるチームにとって価値のあるデータが、別のチームには不要かもしれません。

Pipeline Control UIまたはNerdGraph APIエクスプローラーを使用してルールを作成・編集できます。NerdGraph APIを使えば、特定の条件に基づいてイベントをフィルタリングするCloud Ruleを簡単に設定できます。

3.5 データ取り込み量の可視化と分析

New Relicの「Manage your data」画面では、どのデータが課金の原因になっているかを特定できます。この情報を基に、Pipeline Controlを使って不要なデータを削除する設定を行うことで、エンジニアはコストを気にせず、本当に必要な「異常検知のためのデータ」に集中できるようになります。

デバッグ用の詳細すぎるログなどは、Pipeline Controlで削除する設定にすることで、データ取り込み量を大幅に削減可能です。こうした最適化により、浮いた予算で新しい技術検証に取り組めるようになるでしょう。

4. Workloadsとダッシュボードで組織連携を促進する

3つ目の壁である組織間の連携を、New RelicのWorkloads機能で解決していきます。

4.1 Workloads機能の概要

New RelicのWorkloads機能は、関連するエンティティをビジネスやチームの単位でグループ化し、監視できる機能です。

New Relicは、クライアント側のアプリケーションからバックエンドAPI、基盤となるインフラまで、幅広いエンティティとデータを監視します。この大規模なデータセットを理解するために、Workloads機能が提供されています。ビジネスユニットやチームなど、自分たちにとって意味のある方法でエンティティをグループ化できるのです。

例えば、サーバーレスアプリケーション（APIゲートウェイ、サーバーレス関数、マネージドデータベースとストレージを含む）や、ブラウザアプリケーションとそれを支えるバックエンドAPIなどを1つのワークロードとして定義できます。

4.2 チーム横断の可視化と共通言語の構築

Workloadsを使うことで、フロントエンドからバックエンドサービスまで、システム全体にわたるヘルスステータスとアクティビティの集約ビューを得られます。これにより、ビジネスロジックがどのように機能しているかをよりよく理解できます。

ワークロードのステータスは、そこに含まれるエンティティのアラート状態に基づいて計算されます。ワークロードは、Operational（正常動作中）、Degraded（パフォーマンス低下）、Critical/Disrupted（重大な問題）、Unknown（ステータス未設定）のいずれかの状態を持ちます。

このステータスにより、システムがどのように動作しているかを一目で把握でき、チーム間で共通の言語を持つことができます。他のチームがあなたのサービスやインフラに依存している場合、そのチームはシステムアーキテクチャの詳細を理解したり、カスタムダッシュボードを見たりしなくても、ワークロードのステータスを確認できるのです。

4.3 カスタムダッシュボードの活用

Workloadsには、カスタムダッシュボードをリンクすることも可能です。チームにとって関連性の高いデータを表示するダッシュボードがすでにある場合、それらをワークロードからリンクできます。

さらに、ダッシュボードにフィルタを設定して、ワークロード固有のコンテキストにスコープすることもできます。ワークロードからそのダッシュボードを選択すると、フィルタがすでに適用された状態で開きます。

4.4 データドリブンな意思決定の文化醸成

Workloadsは、障害対応時の拠点となります。New Relicの公式ドキュメントでは、ピーク需要時には、チームの全員が役割に関係なく、同じワークロードから始めて、インシデントについてコミュニケーションする際にはそこを参照すべきだと推奨されています。

チームを同じデータセットの周りに整列させることで、誤解を避け、障害をより速く解決できるようになります。これは、「SREの仕事」から「チーム全体の共通認識」へと監視の位置づけを変える重要なステップです。

まとめ

この記事では、New Relicの具体的な機能を活用して、オブザーバビリティ導入時の典型的な課題を解決する方法を紹介しました。

Service Levels機能を使えば、「何を見ればいいか分からない」という悩みを解消し、ビジネス価値と直結した明確な指標で判断できます。エラーバジェットという概念により、「今は攻めのリリースができる」「今は信頼性に集中すべき」といった、データに基づいた意思決定が可能になります。

Pipeline Control機能により、コストの増大という課題に対処できます。価値のあるデータだけを保存することで、エンジニアはコストを気にせず、本当に必要な異常検知に集中できるようになるのです。Cloud RulesとGatewayという2つの選択肢があり、チームの環境や要件に合わせて最適な方法を選べます。

Workloads機能は、組織間の壁を取り払います。チーム全体が同じデータセットを見ることで、共通言語が生まれ、誤解を避けて迅速に問題を解決できます。監視が「SREの仕事」から「チーム全体の共通認識」へと変わるのです。

New Relicは単なる監視ツールではなく、データを元にチーム間の合意を作るプラットフォームです。導入することをゴールにするのではなく、これらの機能を活用して継続的に改善していくことが重要です。Service Levels、Pipeline Control、Workloadsという3つの柱を理解し、自分たちのチームや組織の課題に合わせて活用していきましょう。

自信を持ってコードをリリースし、週末にアラートで起こされることなく、ユーザーを笑顔にする。そのために、New Relicの各機能がどのように役立つかを理解し、実践していくことが大切です。

この記事がどなたかのお役に立てれば幸いです。