ビジネスオブザーバビリティとは？（実践編）

ビジネスとシステムの相互作用をリアルタイムに把握できる”ビジネスオブザーバビリティ”。その実現をサポートするNew Relic Pathpointをサンプルアプリ（Petclinic）を使って試し、システムの状態をビジネスの側面から把握する方法をご紹介します。


# ビジネスオブザーバビリティとは？ （おさらい）
企業には社内の業務システムやエンドユーザー向けのシステムなど様々なシステムがありますが、目的はいずれも企業のビジネスゴールを達成することです。システムで問題が発生すると結果的に業績や企業の競争力、市場での評判などに悪影響を及ぼしかねません。従い、システム停止や品質低下がビジネスにどの程度の影響を及ぼしているのか、逆にシステムの改善によってどの程度良い結果をもたらしたのか、そういったことを把握して意思決定していくことが必要と言えます。

システムのパフォーマンスを、業務プロセスやコストや収益などと関連付けて、それらの相互作用をリアルタイムに把握できること、それをNew Relicではビジネスオブザーバビリティと呼んでおり、それをサポートする機能としてPathpointを提供しています。この記事では、実践編としてPathpointを使ってみます。


ビジネスオブザーバビリティとPathpointの概要について復習したい方は👇の記事を先にご一読ください。

https://qiita.com/ktst79/items/f89d1df7744b288e943d



# 前提
### アプリケーション
今回は簡単のため、Javaのサンプルアプリケーションとして有名な***Petclinic***を利用します。複雑なワークフローを持ったり、他システムと連携したりするようなアプリではありませんが、ペットのオーナーの管理やペットの診療予約をするというユーザージャーニーを想定してみます。

https://github.com/spring-projects/spring-petclinic

### システム構成とNew Relic導入範囲
AWS上のEC2インスタンス上でPetclinicを動かします。また、New Relicのエージェントは以下の目的で導入してみます。Petclinicや各種エージェントの導入方法はそれぞれのドキュメントをご参照ください。
- ***Infrastructureエージェント***
ホスト(EC2インスタンス)のリソース消費などを収集
- ***APMエージェント***
バックエンドのJavaアプリケーションの主要なAPIのレスポンスタイム、エラーレートを収集
- ***Browserエージェント***
主要な画面のページロード、Core Web Vitalsを収集
- ***Synthetic***
各種画面のエンドポイントへのアクセス可否を定期的にチェック

### 業務フロー
今回はPetclinicのアプリを使って以下の業務フローを考えてみます。サイトを訪問し、ペットのオーナーを管理（管理者検索・追加・ペット登録）し、ペットの診療日を管理（診療日登録）するという流れです。

- ***サイト訪問*** 
トップ画面へのアクセス
- ***オーナー管理*** 
オーナー画面へのアクセス、ペットのオーナー検索
- ***診療日管理*** 
ペット診療日追加

![Petclinic.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/8e959273-9fe1-a480-340d-9c58bf218912.png)


今回は一つのアプリケーションで閉じる例ですが、Pathpointの利用範囲はそれに限定されません。むしろ異なるシステムや別組織に跨る一連の業務フローの状態を俯瞰して把握できます。例えば、ECサイトでの商品検索から決済に加え、配送や受発注システムのなど関連する業務を入れることもできます。


### 計測指標
上記の業務フローのそれぞれに対応するシステムの要素と、健全性を測るための指標を決めます。これらの指標が悪い場合、ユーザー体験を毀損やビジネスの中断につながるためビジネス影響があると判断できます。ここでは重要なユーザー操作（サイト訪問、検索、診療日登録）に係るバックエンドのAPIのレイテンシーや成功率、画面の読み込み時間（正確にはLargest Contentful Paint）、インフラの稼働、エンドポイントの死活、をそれぞれ指標としてみます。

サービスレベルやアラートはすでに設定済とし、ここでは設定方法については細かく説明しません。

<table>
  <thead>
    <tr>
      <th colspan=2>業務フロー</th>
      <th>コンポーネント</th>
      <th>計測指標</th>
    </tr>
  </thead>
  <!-- サイト訪問 -->
  <tr>
    <td rowspan=4>サイト訪問</td>
    <td rowspan=4>トップ画面へのアクセス</td>
    <td>APM</td>
    <td>トップ画面のAPIレイテンシーと成功率のSLO遵守率</td>
  </tr>
  <tr>
    <td>Browser</td>
    <td>トップ画面のCore Web VitalsのSLO遵守率</td>
  </tr>
  <tr>
    <td>Infrastructure</td>
    <td>Host Not Reportingアラート</td>
  </tr>
  <tr>
    <td>Synthetic</td>
    <td>エンドポイントの死活</td>
  </tr>
  <!-- オーナー管理 -->
  <tr>
    <td rowspan=6>オーナー管理</td>
    <td rowspan=4>オーナー画面へのアクセス</td>
    <td>APM</td>
    <td>オーナー一覧APIレイテンシーと成功率のSLO遵守率</td>
  </tr>
  <tr>
    <td>Browser</td>
    <td>オーナー一覧画面のCore Web VitalsのSLO遵守率</td>
  </tr>
  <tr>
    <td>Infrastructure</td>
    <td>Host Not Reportingアラート</td>
  </tr>
  <tr>
    <td>Synthetic</td>
    <td>エンドポイントの死活</td>
  </tr>
  <tr>
    <td rowspan=2>オーナー検索</td>
    <td>APM</td>
    <td>オーナー検索APIレイテンシーと成功率のSLO遵守率</td>
  </tr>
  <tr>
    <td>Infrastructure</td>
    <td>Host Not Reportingアラート</td>
  </tr>
  <tr>
    <td rowspan=2>診療日管理</td>
    <td rowspan=2>ペット診療日追加</td>
    <td>APM</td>
    <td>診療日追加APIレイテンシーと成功率のSLO遵守率</td>
  </tr>
  <tr>
    <td>Infrastructure</td>
    <td>Host Not Reportingアラート</td>
  </tr>
</table>

今回の例では上記の指標としましたが、業務プロセスやユーザージャーニーにおいて重要な要素や指標については各システムの特徴に応じてPMやビジネス側も交えて議論、決定していくと良いでしょう。

### ビジネスKPI
Petclinicのオリジナルのソースには売り上げなどのデータが存在しないので、簡単のため以下をビジネスの成功を測る指標として定義します。

- ***アクセスユーザー数***
アクセスしたユーザーのユニークセッション数。システム停止していたり、アクセスしにくく離脱が多いとこの数値が下がるという想定です。値はBrowserエージェントから取得しているデータから算出します。
- ***診療日予約数***
診療日の新規予約数。サイトがアクセスしにくかったり、APIの品質が悪い（エラーレートが高い）と診療日予約に失敗したり予約に至らずに離脱するのでこの数値が下がるという想定です。診療日登録のバックエンドAPIが呼び出された回数から算出



今回のビジネスKPIは上記の通りとしましたが、New Relicではカスタムで任意のデータを送ることが可能なので、例えば売上データやその他ビジネスKPIに係る情報を送ることでリアルタイムにビジネス影響を把握ことができるようになります。また、New Relicの各種エージェントが送信するシステムデータと、ビジネスKPIに関するデータが同じデータストアに格納されるのでそれらの相関を理解し、問題の影響把握や改善の意思決定を行うことができます。カスタムでのデータ送信については公式ドキュメントもご参照ください。

https://docs.newrelic.com/jp/docs/data-apis/custom-data/custom-events/report-custom-event-data/

# やってみよう
それでは実際にNew Relicの画面を使い、上記の設計に則ってPathpointの設定をしていきます。なお、説明に出てくる画面イメージやラベルは本記事執筆時点でのものであり、変更される可能性がある点はご了承ください。

### Pathpointの起動
左メニューの「Apps」をクリックすると右ペインにアドオンのアプリケーションの一覧が表示されます。この中にある「Pathpoint V2」を選択します。初めてPathpointを開く場合はどのアカウントで有効にするかを聞かれる場合があるので環境に合わせて選択します。

![0_launch.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/43ae1685-5443-5539-9e03-910446da7500.png)


### フローを新規に作成する
Pathpoint表示直後の画面にて、「Create new flow」ボタンを押下し、新しくフローを作成します。

![1_create_flow_1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/9803d0bb-5e31-c58a-12ba-968f4e38b82d.png)



今回はスクラッチから作成するので「Blank flow」を選択します。

![1_create_flow_2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/1c3199f3-7799-29c3-f516-73ca7d08344b.png)


任意の名称を入れてワークフローを作成します。今回はPetclinicアプリを利用するのでそのままPetclinicとします。

![1_create_flow_3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/0d741890-dbae-9c8d-5829-0056b581c3db.png)



### ステージを追加する
業務フローの最上位のレベルは「Stage」と呼ばれます。ここでは、冒頭で設計したとおり、サイト訪問、オーナー管理、診療日管理の3つをStageとします。ステージの粒度はこれでなくてはならないという一意なものがあるわけではないので、システムの境界や組織構造などに応じて管理のしやすい粒度で定義すると良いでしょう。

「Add a stage」ボタンを押下し、ステージを追加します。

![2_add_stage_1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/e1eb5e03-fa99-dad6-ac69-defae32412b3.png)


ステージの名称を入れます。最初は「サイト訪問」とします。

![2_add_stage_2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/6af08185-a5cb-3737-7dfd-d2b00a9b5bcd.png)


残り2つも合わせて、3つ分一気に作ってしまいましょう。
左から右に流れるような見た目ですが、必ずしも時系列に左から右に依存関係がない業務フローでも大丈夫です。

![2_add_stage_3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/cfff22d0-c2b2-49fe-4194-475554255741.png)


### レベル / ステップを追加する
業務フローの各ステージを構成するステップを追加します。なお、意味のあるステップのまとまりは「レベル」というものでまとめたり、分けたりできますが、一意に決まる普遍的なルールがあるわけではないので、ステージと同様に組織構造やシステムの境界によって管理のしやすい粒度で作ってください。

「Add a level」を押してレベルを作ります。

![3_add_level_1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/e4dd0701-1552-ca81-22a2-0d3c98052610.png)

続いて、「Add a step」を押してステップを作ります。

![3_add_level_2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/9381ecee-ea69-87e7-3bf0-900a2c6ffead.png)



ステージ「サイト訪問」のステップとして「トップ画面アクセス」を追加します。上記の業務フローで設計した内容に則ります。

![3_add_level_3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/7c08df78-4ba6-5f49-1211-18a09055d7c3.png)


オーナー管理のステージのステップは、「オーナー画面アクセス」と「オーナー検索」を追加します。最後のステージにも同様にステップを追加します。これで業務フローの雛形はできました。

![3_add_level_4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/b209540e-4982-9c9b-94e4-b9bcdd07c9c3.png)


### シグナルを追加する
シグナルは、いわばNew Relicで計装し、監視しているシステムの要素です。各ステージ、ステップの健全性を判断するのに利用できる要素を追加します。業務フローのステップの健全性が判断できるものであればシグナルはなんでも良いです。アプリケーションやホストなどのシステムコンポーネント、サービスレベル指標、アラートなどです。

![4_add_signal_1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/e939bf9a-c659-03f1-648d-5b79c8d3e04e.png)


最初に設計した通り「トップ画面アクセス」のシグナルとしては、トップ画面に関するサービスレベル指標を足します。具体的には、バックエンドのAPIレイテンシーや成功率、画面のCore Web Vitals値、ホストの稼働状況、外形監視などです。

「Add signals」を押下すると様々なエンティティからシグナルとして追加するものを選択できます。ここではバックエンドAPIのレイテンシー、APIの成功率、フロントエンドのCore Web Vitals（LCP）に関するサービスレベル指標とその目標値（SLO）を定義済みなのでそれらをシグナルとして足してみます。

![4_add_signal_2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/8a1e9362-6c8b-3034-0752-f35025b644ec.png)



Service Level以外にも足してみます。まずは、定期的にサイトのエンドポイントの稼働をチェックするSynthetic Monitorです。

![4_add_signal_3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/1d55fec4-5225-47f5-ce92-2c5d7f185dce.png)

次にホストの予期せぬ停止を拾うためにHost Not Reportingのアラートも足してみます。

![4_add_signal_4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/81fbd5cb-7c6f-f80d-3ee8-8b7b8883bc9f.png)


APMやBrowser、Service Level定義などのEntityやAlertから選べるので簡単ですね。

シグナルとして追加したものがステップに紐づいたのがわかります。

![4_add_signal_5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/711a12da-85a5-25eb-6df8-f80dc4577027.png)


他のステージも同様に入力します。操作としては同じなので詳細は割愛します。一通り入力すると以下のような感じになります。

![4_add_signal_6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/a8c8edc9-104b-daa4-a07a-dd0ae5761a10.png)


### ビジネスKPIを追加する
上記までで業務フローとシステムを対応づけて、ビジネスに影響のあるシステムの問題が起きていないかは直感的にわかるようになりました。

最後にビジネス上の重要なKPIも合わせてみられるようにします。今回は、アクセス数と診療日登録数とします。

「Crate new KPI」ボタンから追加します。KPIは基本的にNRQLで記述します。エージェントがデフォルトで収集しないデータからKPIを算出する場合は、カスタム属性やカスタムイベントで個別に送信してください。

![5_add_kpi_1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/635e49c4-868f-90a7-513d-c3c1d680917a.png)

![5_add_kpi_2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/e88b2055-414d-c4e1-4b27-3285f95987a9.png)

ここではそれぞれのKPIは以下のようなNRQLで計算することとします。

```sql: 一日当たりの訪問者数のNRQL
FROM PageView 
SELECT uniqueCount(session) 
WHERE appName='Petclinic Prod' 
SINCE 1 day ago
```

```sql: 一日当たりの診療日登録数のNRQL (登録APIコール数）
FROM BrowserInteraction 
SELECT count(*) 
WHERE browserInteractionName like '%/visits/new' 
SINCE 1 day agoo
```

これで設定は終わりです🙌

# 確認してみる
設定が完了すると、シグナルとして登録したエンティティやアラートのステータスが、それと関連するフローのステータスと連動するので、ビジュアルで業務フローのどこに問題が起きていて、何が起因でそれが発生しているかが直感的にわかります。アラートを設定していない場合は灰色になってしまうので、正しくアラートが設定されているかのダブルチェックにもなりますね。

以下の例ではトップ画面のCore Web Vitals（Largest Contentful Paint）がサービスレベル目標に違反して赤くなっており、ユーザージャーニーの最初のステップであるサイト訪問に影響が出ていることがわかります。LCPが悪化し、ページ表示が遅延すれば待てないユーザーが離脱してサイト訪問者や診療日予約数への影響がでることから対策が必要であることがすぐにわかります。

![6_complete.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/a28b2c9d-fe2e-97b8-0915-b0a5e6033025.png)


一旦問題があることがわかると、該当部分をクリックすることで発生している問題の概況を把握し、APM/Browserなどの画面へシームレスにドリルダウンして分析していくことが可能なので効率的にトラブルシュートすることがわかります。
その際、ビジネスKPIへの影響有無なども合わせて確認が可能です。

![7_troubleshoot.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/17818cdc-be46-2704-e868-692f737b9fbb.png)


# まとめ
今回はビジネスオブザーバビリティ（実践編）として、Petclinicを使って業務フローとシステムの関連を可視化し、ビジネス視点でシステムの問題有無を把握、分析する方法をご紹介しました。双方の相関を直感的に把握できるのがイメージできたのではないでしょうか？

業務とシステムの相互作用を可視化することはビジネスサイド、エンジニアサイドの両方にメリットがあります。ビジネスサイドはビジネスの健全性をリアルタイムに把握できるようになり、エンジニアサイドは問題とそのビジネス影響を素早く把握して対応することができるようになります。ビジネスとエンジニア間のコミュニケーションツールとしても利用できるのでコミュニケーション効率も上げることもできるでしょう。

冒頭の通りシステムの目的はビジネスのゴールを達成することであり、どのシステムにもなんらかの形で適用できますので是非お試しいただき、ビジネスオブザーバビリティへの一歩を踏みだしましょう！


ビジネスオブザーバビリティについては以下の公式ドキュメントもご参照ください。

https://newrelic.com/jp/resources/ebooks/six-steps-to-achieve-business-observability

https://docs.newrelic.com/jp/docs/new-relic-solutions/business-observability/introduction-business-observability/

# その他
New Relicでは、**新しい機能やその活用方法**について、QiitaやXで発信しています！
**無料でアカウント作成**も可能なのでぜひお試しください！

:::note info
New Relic株式会社の[X(旧Twitter)](https://x.com/NewRelicJapan) や [Qiita OrganizationOrganization](https://qiita.com/organizations/newrelic)では、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。
:::

:::note info
無料のアカウントで試してみよう！
[New Relic フリープランで始めるオブザーバビリティ！](https://qiita.com/ktst79/items/5ee74b34e6adb8a7a6fa)
:::


:::note info
New Relicへのデモ依頼などのお問い合わせは[こちら](https://newrelic.com/jp/contact-sales)
:::