株式会社アイスタイルのクラウド推進グループに所属させてもらっている土居です。
今回は、社内で利用するNew Relicのガイドラインをリニューアルした時の思い出について記事を書きたいと思います。
ガイドライン作成前のNew Relic経験
ガイドラインを作成するプロジェクトに取り組む前の私のNew Relicの利用経験は、3ヶ月くらいでした。
社内で使われているNew Relic APIキーの棚卸しをしたことが、最もNew Relicに触れた機会だったと思います。
New Relicから発報されるアラートが表示されるSlackチャンネルには2年ほど属していたので、「New Relic」というキーワードにはほぼ毎日触れていましたが、アラートのURLをクリックしても中身を見ることができない（New Relicユーザーの権限の問題だと認識しています）こともあり、興味深くウォッチはしていませんでした。
それぞれの用語の理解レベルで言うと、
Dashboard：名前からその目的を推測できる
APM：文字から意味を理解できない（円盤が回転する速度かなんか？というイメージ）
Browser：New Relicの用語としては聞いたことがない
Mobile：同上
Infrastructure：同上
Log：同上
Synthetics：CloudWatchで見たことある気がするが、スペルの読み方が分からない
NRQL：社内の詳しい人たち会話を見るに、クエリのようだが、監視でクエリが必要な理由は分からない
という感じでした。
他の監視ツールの利用経験
Zabbixならそこそこあるという感じでした。
アイテム、トリガー、アクションの役割と使い方を理解しており、お客様のシステム環境の監視設定を能動的に構築・運用したことがあります。（現在もしています）
ミッション
New Relic利用ガイドライン作成のミッションは以下のような感じでした。
- 導入状況確認（2024年3月～4月なるはや）
- 導入手順書作成（1の確認が完了次第～ ※1）
- 監視項目の整理（スタンダード作成）（※2）
- 監視設定方法まとめ（※2）
※1 No1にてほとんど導入できているようであればスキップ
※2 2024年7月に実施予定だがNo2がスキップであれば2024年4月からに前倒し
2024年3月末に、本プロジェクトに従事する担当者がチーム内で募られました。
チームではAWSの利用ルール決め、整備の業務が主であり、その学習を長期間してきたメンバーが多かったため、New Relicのタスクに手を挙げる人が少ないと予想し、手を挙げてみました。（全員が均一に業務知識を持った状態にするというチーム運営方針があったことも理由の一つです）
まず実施したこと
「導入状況確認」（社内のNew Relic利用状況の把握）をすることも序盤の大きなタスクでしたが、それよりもリニューアル中のガイドライン（社内で閲覧するNew Relic利用ナレッジ等をまとめたConfluence記事群）の作成方針をキャッチアップすることに苦労した記憶があります。
先述の通り、New Relicについての知識が乏しく、社内でのNew Relic利用文化についてもほとんど把握していなかったので、すでに切られていたいくつかのチケット（ガイドライン更新にあたって子タスクの実施内容や方針を記載したBacklogチケット）を読んでも、ある程度知っている人がタスクを実施する前提で記載されていたので、何をしたらよいかイメージが湧きませんでした。
かといって、チケットの起票者に事細かくヒアリングすることは、ボトルネックではないと直感的に感じたので、あえてそれを行わず、チケットの内容理解や既存の資料（すでに社内に存在しているNew RelicナレッジをまとめたConfluence記事群やリニューアルの方針検討資料）を眺めました。
例えば、検討資料として以下のようなものがありました。
| アウトライン案 | 既存資料 | 記載内容 | 書いてないこと |
|---|---|---|---|
| NewRelicについて（概要） | NewRelic | … 機能一覧 … 禁止事項 各種リンク |
|
| 用語集 | 無し | ||
| NRQL | NewRelicのデータ活用 | … NRQL概要 NRQLが利用可能なアカウント … |
|
| NewRelicのユーザータイプと出来ること | NewRelic | … Fullアカウント: 全機能 Basicアカウント: Dashboard, Log, … |
|
| Dashboardsの見方、作成方法 | NewRelicのデータ活用 | … ダッシュボードの作成や閲覧ができるアカウント ダッシュボードの構成 … |
具体的なNRQL … サンプル的なダッシュボード … |
| … |
ミッションクリアまでのロードマップ
2024年7月くらいには、各開発者の手元に新ガイドラインが届けられたら...といったオーダーでした。目標工期としては実質3ヶ月程度でした。
結果的に、それを2ヶ月程度超えた2024年9月には、手元に届けられる状態を達成できたのですが、ロードマップが固まるまでは、そのような期間でできるとは思えませんでした。
我々クラウド推進グループでは、チーム運営にスクラム制を採用していて、スプリント（2週間で1スプリントとしています）ごとに、一定のストーリーポイントを各タスクに振り分けて実施しています。（スクラム開発の用語については、割愛します）
そのストーリーポイントを各タスクで取り合うような形になってしまうため、今回のミッションに割り当てられるポイントを予測しづらい面がありました。それによって、どの時期にどのくらい完成しているかを計画しづらく、割り当てられるリソースに応じて成果物の質を変えるという戦略もとりづらくなるため、惰性でプロジェクトが進んでしまう懸念がありました。
惰性でプロジェクトが進むと、自然消滅（気づいたらそのプロジェクトに取り組まなくなっていた）することをこれまでに何度か見てきたので、それは避けようと思いました。
なので、本ミッションに割り当て可能なストーリーポイントを仮決めし、チームメンバーにできるだけそうなるようにリファインメントやプラニング時にお願いをしていました。
スケジュール以外の面（ガイドラインに書く内容の目標）については、既存の検討資料やチケットを活用し、タスクの一覧化とそれぞれ目標を言語化しました。
以下のようなイメージのタスク一覧を作成しました。
| 子チケット | やること | 必要ポイント | 割り当てポイント | 過不足 | スプリント5 | スプリント6 | スプリント7 | … |
|---|---|---|---|---|---|---|---|---|
| New Relic導入状況確認 | 各システムのNew Relic導入状況を確認する | 2 | 2 | 0 | 2 | |||
| 監視設定状況確認 | よく監視されているメトリクスを把握する | 5 | 5 | 0 | 5 | |||
| New Relicへの情報転送手順作成 | 各AWSサービスとNew Relicを連携する方法を記載する | 6 | 6 | 0 | 3 | … | ||
| ログの情報転送手順作成 | ログをNew Relicに連携する方法を記載する | 4 | 4 | 0 | … | |||
| … |
結果と期待すること
出来上がったガイドラインは大きく以下の章に分かれる形となりました。
-
基本事項
→APIキーの運用方針や権限ごとにできることのまとめ -
監視導入手順
→インフラやアプリケーションからNew Relicに情報を送るための設定手順 -
監視設定ガイドライン
→New Relic側での設定手順（ダッシュボードやアラートの設定）
ミッションのうち「2. 導入手順書作成」を「2. 監視導入手順」に、「3. 監視項目の整理（スタンダード作成）」と「4. 監視設定方法まとめ」を「3. 監視設定ガイドライン」に割り当てる形となっています。
オーダーの内容を比較的シンプルに階層化できたため、依頼側とスムーズに合意形成できたと考えています。
ただ、ガイドラインの閲覧数を計測できていないことが心残りです。依頼側（プロジェクトオーナー）にて、重要システムへの通知設定状態の一覧化の依頼を行なっているようですが、そのような施策を講じないとガイドラインが読まれないと判断されたのかもしれません。
また、月並みですが、ガイドラインを作成した側にナレッジが溜まったことは最も大きな収穫だと言えます。今後、ガイドラインが閲覧され、フィードバックループが回ることを期待したいと思います。
ガイドラインの階層構造はこのようになりました(一部抜粋）
苦労した点
アプリケーションモニタリングという概念があることを知らなかったことが大きいです。（今もあまり理解できていませんが）
「監視」のイメージとして、CPUやメモリの使用率の監視、監視サーバーからWebアクセスする外形監視しか持っていませんでした。
それによって、APM / Browser / MobileなどのNew Relicの機能に苦手意識を持ったままプロジェクトに臨むことになりました。ガイドラインを作り終えた時には、その苦手意識も薄らいでいましたが、個人的には、プロジェクトを進める上でのボトルネックだったと振り返ります。
技術的にハマったこと
APMからNew Relicにログを連携できない
Fluent Bitなどのツールを用いるとNew Relicにログを連携することはできますが、APMの機能だけを用いてNew Relicにログを送ることができませんでした。
Node.jsベースでコードを書いていたのですが、原因は、require('newrelic');という構文をpinoのimport文よりも後に書いてしまっていたことでした。
Node.jsに熟達した人であれば、すぐに気づけたかもしれませんが、やはりここでもインフラエンジニアのアイデンティティに固執しすぎた故か、解決まで3ヶ月を要しました。（New Relicの製品部門の方から指摘をいただき、気づくことができました）
※このように修正して解決しました（修正前はnrPinoを使用していて、修正後はPinoを使用している点は、原因とは関係ありません）
Lambdaのトレース情報を連携しようとするとエラーになる
こちらもアプリケーション面の不備が原因で起きた事象です。
Node.jsのESM形式でコードを書く場合、Lambda環境変数にてESMの有効化が必要というものでした。
Lambda関数を作成してとりあえず、New Relicとの連携を試してみようとすると、デフォルトのLambda関数のコードがESM形式で書かれており、New Relicトレース情報連携用のレイヤーがどうやらデフォルトではCommonJSに対応しているようで、以下画像のようにESMを使用する旨を明示的に設定しないといけないようです。
こちらもインフラエンジニアとしては難しく感じるポイントでした。
ハマったことから分かること
アプリケーションエンジニアとして活躍した業務経験の少なさが苦労した要因の一つでしたが、今回の経験によって、エンジニアとしてのやり残しを一つ消化できた気がしています。
まとめ
知識や経験がどうであれ、しっかりとロードマップを作って定期的に進捗確認と方向修正をしていけばなんとかなるということが分かりました。
納期が必達であれば、有識者に助けを求め、余裕があるなら自分で勉強するというスタンスで仕事に望めば、迷惑かけている感覚も少なくなるし、プロジェクトが遅延し続けることも少なくなるのではないかと思います。
今回、New Relic利用ガイドライン作成プロジェクトに取り組んでみて、ざっくりと感じたのは、New Relicはインフラエンジニアよりもアプリケーションエンジニアの方が習得しやすいのではないかということです。
SREなどという用語が当たり前に使われるようになってきた昨今、SaaSやクラウドサービスを運用するのであれば、旧来のインフラエンジニアのアイデンティティのままでいると、しんどい部分があるのだろうと心に留めつつ、今回の記事の筆を擱こうと思います。