はじめに
この記事はBASEアドベントカレンダー2025の19日目の記事です。
こんにちは。BASEのプロダクト開発チームでバックエンドエンジニアをしている大塚です。
この記事ではNew Relicのダッシュボードを「動く仕様書」にするために、機能ごとに標準化されたダッシュボードをTerraformで手軽に出来るようにする取り組みを紹介させていただきます。
まだまだ構想と検証段階なので、こんなことしようとしているよというニュアンスで紹介させていただきます！
New RelicとTerraformについて
取り組みについての紹介に入る前に、New RelicとTerraformについて簡単に紹介させていただきます。
New Relicとは
New Relicは、アプリケーションパフォーマンス監視(APM)やインフラストラクチャ監視を提供するクラウドベースの可観測性プラットフォームです。
主な特徴:
- リアルタイム監視: アプリケーションやインフラストラクチャのパフォーマンスをリアルタイムで可視化
- 分散トレーシング: マイクロサービスアーキテクチャにおけるリクエストの流れを追跡
- カスタムダッシュボード: NRQLというクエリ言語を使って、独自のダッシュボードを作成可能
- アラート機能: 異常検知時に通知を送信し、迅速な対応をサポート
Terraformとは
Terraformは、HashiCorpが開発したInfrastructure as Code(IaC)ツールです。コードでインフラストラクチャを定義し、バージョン管理や自動化を実現してくれます。
主な特徴:
- 宣言的な記法: HCL(HashiCorp Configuration Language)を使って、あるべき状態を定義
- マルチクラウド対応: AWS、GCP、Azureなど、様々なクラウドプロバイダーに対応
- 状態管理: インフラの現在の状態を追跡し、差分を検出
- 豊富なプロバイダー: New Relicを含む多くのサービスに対応したプロバイダーが存在
New Relic × Terraformの組み合わせ
TerraformのNew Relicプロバイダーを使用することで、ダッシュボード、アラートポリシーなどをコードで管理できます。
これにより以下のようなことが実現できます。
- ダッシュボードの構成をGitで管理し、レビューや変更履歴の追跡が可能に
- 環境ごと(開発、ステージング、本番)に同じ構成のダッシュボードを簡単に展開
- チーム全体で標準化されたダッシュボードを共有
- 手動操作によるミスを削減
これらのメリットを活かして、BASEではNew Relicのダッシュボードを「動く仕様書」として機能させる取り組みを進めています。
ただ、メリットがある一方、Terraform化には以下のような課題もあります。
- 全リソースを管理できないため、手動での管理とTerraformでの管理のリソースが混在
- Terraform管理のリソースを手動で変更することによる競合
これらの課題は、Terraform管理するリソースを絞ることで回避しています。
今後Terraform管理のリソースを増やしていく想定なので、これらの課題に対しての対応も合わせて検討を進めていく予定です。
なぜやるのか
課題
BASEでは各機能のパフォーマンスや挙動を監視するためにNew Relicのダッシュボードを活用していますが、以下のような課題がありました。
- ダッシュボードの属人化: 個々のエンジニアが必要に応じて手動でダッシュボードを作成するため、レイアウトや粒度がバラバラになりがち
- メンテナンスの困難さ: 機能追加や変更があった際、ダッシュボードの更新が漏れたり、誰がメンテナンスすべきか不明確になっている
- 標準化の欠如: 新しい機能を追加する際に「どんなメトリクスを見るべきか」の指針がなく、監視の抜け漏れが発生しやすい
解決策
これらの課題を解決するために、Terraformを使ってダッシュボードをコード化することで、以下を実現できると考えました。
課題の解決に加えオブザーバビリティを向上させるためにも有効だと考えています。
1. ダッシュボードを「動く仕様書」に
各機能に対して標準化されたダッシュボードレイアウトを定義することで、そのダッシュボード自体が機能の仕様や監視すべきポイントを示す「動く仕様書」として機能します。新しくジョインしたメンバーも、ダッシュボードを見れば「この機能で何を監視すべきか」や「どのように動作しているか」が一目でわかる。
2. コードレビューによる品質担保
ダッシュボードの構成をコードで管理することで、Pull Requestを通じたレビュープロセスを導入できます。これにより、チーム全体で監視項目の妥当性を検討し、知見を共有できる。
構成
New RelicのダッシュボードをTerraform管理する用のリポジトリを用意してコードを管理しています。
構成としてはざっくり以下のようになっています。
├── main.tf # New Relic provider の設定だけを持つルートモジュール ├── variables.tf # New Relic アカウント情報など共通変数 ├── modules/ # 再利用可能な Terraform module 群 │ └── dashboard/ │ └── standard_feature_dashboard/ │ ├── main.tf # ダッシュボード共通レイアウトの実装 │ └── outputs.tf # 作成したダッシュボードの URL / ID を出力 │ ├── dashboards/ # ダッシュボード定義 │ └── ⚪︎⚪︎⚪︎_dashboard.tf # ⚪︎⚪︎⚪︎ダッシュボード │ └── .github/ └── ISSUE_TEMPLATE/ └── standard_feature_dashboard.yml # ダッシュボード作成依頼用の Issue Form
ルートには New Relic provider と共通変数だけを置き、実際のダッシュボード定義はmodules/dashboard/...の共通 module dashboards/... 配下の各tfファイルから呼び出す構成にしています。
これにより、ダッシュボードのレイアウトを 1 箇所で統一しつつ、機能単位では URL やトランザクション名などの差分だけを記述すればよい運用になっています。
運用
BASEの機能開発は複数ある開発チームが並行で進めています。
開発の後半でNew Relicのダッシュボードや監視項目の検討、アラートの設定などを実施している開発チームが多いので、その際に標準ダッシュボードを作成するフローを検討しています。
現状、各チームのエンジニアがダッシュボード用のtfファイルをいじるのではなく、知見を持っているメンバーが開発チームの依頼を受けてtfファイルを作成するというフローを採用しています。
GitHub Issue Form と組み合わせることで、「依頼 → Terraform 化 → New Relic 反映」までをスムーズに回せるようにしているのもポイントです。
成果物
Terraformで出力されるダッシュボードは以下のようなダッシュボードです。
複数ページに分かれていますが、例としてbackendアプリケーションのページを紹介します。
汎用的なダッシュボードにするために、グラフの種類などはかなり少なめで、アプリケーションの動態が分かる最低限の内容にしています。
- トランザクション一覧
- スループット
- エラーレート
- など
Markdownで自由に記載できる項目も用意し、機能のページや仕様書へのリンクなどを置けるようになっています。
おわりに
New Relicのダッシュボードを機能ごとの汎用的な「動く仕様書」としてTerraformで出力し、組織のオブザーバビリティを高める活動を紹介させていただきました。
まだ検証段階ですが、こちらの取り組みを組織に広げることで組織のオブザーバビリティを向上させていきたいと思っています。
New RelicとTerraformはダッシュボード以外にも色々なことが出来るので、皆さんもぜひ試してみてください。
BASEでは組織のオブザーバビリティを向上させる様々な取り組みを実施中です。
ご興味のある方は以下のリンクから採用情報などもみていただけると幸いです。
