Change Trackingを使って変更管理をしながら、変化に即座に気づけるようにする

:::note info
最新のアップデートの詳細はこちら。[New Relic アップデート(2023年9月)
](https://newrelic.com/jp/blog/nerdlog/new-relic-update-202309 "New Relic アップデート(2023年9月)")
:::

# はじめに
『あれはどこにいった？いつもの所に置いてないな・・・。最後に使ったのいつだっけ？』こんな経験を日常生活の中で、一度も言ったことはないんじゃないでしょうか？
もし『あ、そうだそうだ。昨日の夜に帰ってきた時いつもの鍵を置いておく場所じゃなくて、テーブルの上に置いたままだった。』と聞くしていれば、いつもの場所に鍵がなくても、慌てる時間はその時だけで、すぐに鍵を見つけることができますよね。
それと同じで、システムにおける変更情報を記録しておくと、いつもと違うぞという事象に遭遇した際に、その記録を振り返ることで何が起きているかをとても簡単に推測することができるようになります。
New Relicでは、[Change Tracking](https://docs.newrelic.com/jp/docs/change-tracking/change-tracking-introduction/)という仕組みを提供しており、これにより様々な変更情報を管理することができるようになっています。

# どんな仕組み？
## どうやって登録する？
詳細は[公式ドキュメント](https://docs.newrelic.com/jp/docs/change-tracking/change-tracking-graphql/)に取りまとめられているので、是非一読してもらうことをおすすめしますが、[NerdGraph](https://docs.newrelic.com/jp/docs/apis/nerdgraph/get-started/introduction-new-relic-nerdgraph/)というGraphQL APIを介して、変更に関する情報をNew Relic上に登録することができるようになっています。

**補足:** APIを利用する際は、**API-Key**というヘッダにAPI Keyの値を設定頂く必要があります。API Keyの取得には[こちらのブログ](https://newrelic.com/jp/blog/how-to-relic/api-key-generation-steps)を参照して下さい。

変更情報をNerdGraph経由で登録する場合、以下のフィールドが必須となっています。
 - **entityGuid**: New Relicに登録されているどの管理対象に関連した変更であるかを指定します。
 - **version**: 『値は何でもよい』とあるので、管理のし易いフォーマットを採用して下さい。例えば、**ver01**や**00.00.01**といた情報を指定します。

その他に、**changelog**や**description**といったオプションの属性を用いることで、より詳細な変更に関する情報をNew Relicに登録することができます。

```
mutation {
    changeTrackingCreateDeployment(
        deployment: {
            version: "0.0.1",
            entityGuid: "ここにentityGuidの文字列を設定する" }
    )
    {
        deploymentId
        entityGuid
    }
}
```

## 登録内容をどこで確認する？
New Relicポータルの主要機能(**APM & Services**, **Browser**, **Mobile**, **Synthetic Monitoring**, Infrastructureの**Hosts** など)のUIにアクセスするとメニューに**Change Tracking**が現れるので、そちらから登録した変更作業前後のデータを参照することが可能です。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3534647/48cbcea6-a47b-dd73-ca6d-5ca081723178.jpeg">

**補足**: 確認する限りだと、メニュー名は共通でしたが、メニュー自体の配置されるグループは機能ごとに異なっていました。活用の際はご注意下さい。

この**Change Tracking**メニューにアクセスすると、登録された変更の記録がリストとして表示され、その一覧から参照したい記録を選択することで詳細情報を確認することが可能です。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3534647/cc026417-e362-de31-516f-d9130575c389.jpeg">

**補足**: 手元の環境で試してみたところ、APIを介して登録する際に**entityGuid**で指定する管理対象のタイプによって表示されるデータが変わる様です。


## なにが見えるの？
変更管理の詳細画面ですが、はじめに管理対象のタイプに関わらず共通のデータが表示されます。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3534647/508f155b-d99a-5cee-e3ee-7607b7deca96.jpeg">


デフォルトで以下に関する情報を確認することができます。
- 管理対象に関連づいているエラーの発生数
- 発生した分間のログ発生数
- 管理対象に関連づいたアラートの発生数

また、画面上から参照したいメトリックやイベント情報を追加することも可能です。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3534647/f69107f8-ead3-db6d-965b-38d492d26953.jpeg">

続いて、APM/Infrastructure/Browserの主要エージェントでは次のデータが表示されます。

### バックエンドアプリケーション(APM)
APMのデータとして、変更前後でトランザクションがどの様に改善されたか、また、応答時間、スループット(分毎のリクエスト処理数)、エラー発生率、CPU利用率、Apdexスコア、メモリ利用率、データベースへアクセスするトランザクション割合といったパフォーマンス指標が表示されます。

**トランザクションのパフォーマンスの改善**を確認することができます。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3534647/254549f5-0994-d57a-8e53-09186d3f651a.jpeg">


バックエンドアプリケーションの**主要なパフォーマンス指標の変化**を確認することができます。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3534647/22a5c80e-a4d5-c8f7-2a3e-59df8e79046f.jpeg">

### サーバ(Infrastructure)
Infrastructureのデータとして、
- CPU利用率
- メモリ利用率
- ストレージ利用率
- データ入出量(bits/sec)

の変化を確認することができます。

### フロントエンドアプリケーション(Browser)
Browserのデータとして、
- 分間あたりのページビュー数
- LCP(75パーセンタイル)
- FID(75パーセンタイル)
- 発生エラー数
- ページ読み込み時間
- 分間あたりのAJAXリクエスト数

の変化を確認することができます。

# どんな使い方ができるのか
各管理対象に紐づいて変更情報を登録できるので、管理対象自身の変更情報を残すという使い方が主な目的となるかと思います。例えば、バックエンドアプリケーションの新バージョンをリリースしたですとか、サーバのキャパシティを増強したなどです。

一方で、Change Trackingの画面では変更が発生した時間を指定して登録を行うことができるので、管理対象自身ではなくその周辺の変更も併せて記録することで、周辺の変更が管理対象にどの様な影響を与えたのかという観点での記録も可能です。例えばですが、バックエンドアプリケーションの前段のロードバランサやセキュリティソリューションの変更、CDNのキャッシュ設定の変更といったものがあるかと思います。まだまだ他にもあるかと思いますが、挙げさえて頂いた例は、変更を行うことで管理対象へ多大な影響を与える可能性があるものです。そういった潜在的な影響を及ぼす周辺の変更についても管理対象に紐づけて変更記録をつけ、パフォーマンスやキャパシティの負荷に変化がないのか、影響があった場合でも許容できる範囲なのかという観点で集めたデータを活用することができます。

これらの変更を1つ1つデータとして記録していくことで、あっては欲しくないですが、突然の障害やパフォーマンスの劣化が確認された際に、確認すべき箇所を狭めることができ、過去に遡りながら原因を特定していくことができる様になりますね。


# まとめ
**Change Tracking**は、すごく便利そうですね。是非、この機能を用いて、システムやサービスに適切な確認すべきチェックポイントをデータに埋め込んでいきましょう。そうすることで、何か想定外なことが起きた場合、変更の記録1つ1つを戻りながら変化の起点を探し当てることができるよういになります。その結果、原因を解決するためのスピードは早くなることが期待できますし、原因調査の時間が圧縮した分を再発防止のための時間であったり、より良いものに改善するための時間に充てることができるようになりますね。

New Relicを用いて実現できるとても便利な機能は他にもたくさんあります。ご興味がある方は、下のリンクにアクセスしたり、無料アカウントを是非トライしてみて下さい。

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

:::note info
無料アカウントの詳細は[こちら](https://docs.newrelic.com/jp/docs/accounts/accounts-billing/account-setup/create-your-new-relic-account/)です。
:::