1. はじめに
この記事は、以下アドベントカレンダーの24日目です。
New Relic × Terraformで監視設定の「見えないコスト」を削減するアプローチをご紹介します。
まだまだ構想と検証段階ですが、今回のテンプレートは実際の導入案件で活用することを想定して設計しました。
利用料ではなく、導入・設定にかかる作業工数の削減がテーマです。
2. 課題・背景
監視設定の「見えないコスト」
New Relicを導入する際、設定作業にどのくらい時間をかけていますか？
利用料削減は意識されがちですが、実は監視設定にかかる作業コストも見逃せません。
実質的な利用料の削減にはつながらないものの、導入・運用にかかる工数は確実に発生しているコストと考えます。
💸 時間コスト
- 10台のEC2に同じアラート設定 → GUIで1台ずつポチポチ
- ダッシュボード複製 → JSONエクスポート → ホスト名書き換え → インポート
- 1案件数時間 × クライアント数 = 膨大な工数
💸 品質コスト
- 担当者ごとに閾値がバラバラ → 後から見て「なぜこの値？」
- 設定漏れ・タイポに気づかず本番へ → 手戻り発生
- 特定の人しか設定できない → 属人化
💸 管理コスト
- 誰がいつ何を変えたか追えない
- GUI操作は事前レビュー不可能 → ミスが本番直行
- 「あの人に聞かないとわからない」 → 引き継ぎ困難
これらは 利用料には現れないけど、確実に発生しているコスト です。
3. 解決アプローチ
3-1. 目指すゴール
- 作業時間の短縮：手動より速く
- 品質の標準化：誰がやっても一定水準の設定ができる
- 変更管理：Gitで履歴を追える、PRでレビューできる
3-2. 作業者にとってのメリット
- tfvarsの編集だけで複数リソースを一括作成。GUI操作の繰り返しが不要
- 「どこに何を書くか」が明確で、APIやNRQLの深い知識がなくても設定可能
- Git管理＋PRレビューで、ミスの早期発見と変更履歴の追跡が可能
つまり、New RelicやTerraformに詳しくない人でも簡単に設定作業ができ、ミスも減らせる状態を目指しました。
4. 設計・構成
4-1. 前提条件
Terraform + GitHub Actions + S3（tfstate管理）の環境を前提としています。
APIキーやS3の認証情報はtfvarsに書かず、GitHub Secretsで管理し、コードに機密情報が残らない構成にしています。
4-2. 設計で意識したこと
4-2-1. 触るファイルを最小限に （属人化防止）
作業者が編集するのは tfvarsファイルだけ 。
モジュール呼び出しや変数定義は別ファイルに切り出し、本当に必要な値だけをtfvarsに集約しています。
| 階層 | 説明 | 役割 |
|---|---|---|
Environments/ |
環境ごとのデプロイ先（Dev/Prd） | 作業者が触る。tfvarsを編集してPR |
Modules/ |
再利用可能なモジュール群 | 基本触らない。テンプレート改善時のみ |
4-2-2. tfvarsを役割ごとに分離
役割ごとにファイルを分けることで、レビュー時に変更箇所が明確になり、拡張も該当ファイルへの追記だけで済みます。
| ファイル | 内容 | 必須/任意 |
|---|---|---|
00_common.tfvars |
通知先 | 必須 |
01_nonsap.tfvars |
標準的なインフラ監視設定 | 必須 |
02_dashboard.tfvars |
ダッシュボード定義 | 必須 |
03_sap.tfvars |
SAP固有の監視項目 | 任意 |
04_cloud.tfvars |
クラウド連携監視 | 任意 |
05_observability.tfvars |
APM、Synthetics等 | 任意 |
09_*.tf |
backend、variables、main等 | 編集不要 |
4-3. フォルダ構成
フォルダ構成（抜粋）
├─Environments
│ ├─Dev # 開発環境向け設定
│ └─Prd # 本番環境向け設定
│ │ 00_common.tfvars # 作業者が編集：通知先
│ │ 01_nonsap.tfvars # 作業者が編集：監視対象
│ │ 02_dashboard.tfvars # 作業者が編集：ダッシュボード
│ │ 03_sap.tfvars # 作業者が編集：SAP監視（任意）
│ │ 04_cloud.tfvars # 作業者が編集：クラウド連携（任意）
│ │ 05_observability.tfvars # 作業者が編集：APM等（任意）
│ │ 00_alert-muting.tf # 運用フェーズ時に使用予定
│ │ 09_*.tf # 基本触らない：変数宣言、モジュール呼び出し等
│ │
│ └─synthetics_script
│ script_api.js # Synthetics用スクリプト
│
└─Modules # 基本触らない：テンプレート改善時のみ
├─00_common
│ └─notifications
│ ├─alert-destination # 通知先（今回はEventBridgeで一本化）
│ ├─alert-notification-channel # 通知チャンネル
│ └─alert-workflow # ワークフロー
│ main.tf # プロバイダー設定
│ variables.tf # 入力変数定義
│ resource.tf # リソース定義
│ outputs.tf # 出力定義
│ # ※各モジュール同様の構成
├─01_nonsap
│ ├─alert-policy # アラートポリシー
│ └─alert-condition # アラート条件
│
├─02_dashboard
│ └─json
│ nonsap_os_template.json # OSダッシュボードテンプレート
│ sap_template.json # SAPダッシュボードテンプレート
│
├─03_sap # SAP固有の監視設定
├─04_cloud # AWSインテグレーション等
└─05_observability # APM、ServiceLevel、Synthetics
5. 実践：具体的なユースケース
5-1. 複数ホストのアラート一括設定
10台のEC2に同じ監視設定を入れたい場合、GUIだと1台ずつ繰り返し作業が必要です。
Terraformなら、tfvarsにホスト情報を追加するだけ。
# 追加したい分だけコピペして値を変えるだけ
# Condition definitions
nonsap_ec2_instances = [
{
name = "ec2_monitoring_1"
resource_name = "aaaaaaaaa"
hostname = "aaaaaaaaa"
process_names = ["newrelic-infra", "httpd"]
},
# ... 中略（ec2_monitoring_2 〜 9 も同様の構成） ...
{
name = "ec2_monitoring_10"
resource_name = "zzzzzzzzz"
hostname = "zzzzzzzzz"
process_names = ["newrelic-infra", "httpd"]
},
]
# Policy definitions
nonsap_policies = [
{
name = "nonsaptest-AlertPolicy"
incident_preference = "PER_CONDITION"
},
]
Github Actionsの実行時間 （※リソースの作成変更削除数は差分あり）
実際に作成されたポリシーとコンディション数
一括で110個ものコンディションのリソースを作成することができました！
Before/After
| Before（GUI） | After（Terraform） | |
|---|---|---|
| 作成数（例） | 110個（1台あたり11定義 × 10台） | 同左 |
| 作業内容 | 1台ずつポチポチ | tfvars編集 → PR → apply |
| 時間 | 2時間以上 | 約5分（実行は1分未満） |
| 品質担保 | 手作業で確認 | テンプレート化で統一 |
※作成数は一例。ホスト数に応じてスケールします。
5-2. ダッシュボードページ（タブ）の一括複製
複数ホストを含むダッシュボードを作成する場合、JSONテンプレートを使う方法もありますが、ホスト数が増えるとJSONの行数が膨大になり（今回はapply実行時の出力が約31,000行）、修正箇所の特定や変更管理が困難になり、品質を担保しにくくなります。
Terraformなら、tfvarsにホスト名を列挙するだけ
os_dashboards = [
{
json_file = "nonsap_os_template.json"
dashboard_name = "nonsap-os-monitoring"
account_id = xxxxxxx
hostnames = [
"hostnameA",
"hostnameB",
# ... 中略 ...
"hostnameV",
]
},
]
今回ダッシュボード変数は使用せず、ホストごとにダッシュボードのページ（タブ）を生成する方針です。
- ダッシュボードあたり最大25ページ
- ページあたり最大150ウィジェット
Github Actionsの実行時間 （※リソースの作成変更削除数は差分あり）
実際に作成したダッシュボードとページタブ
正しく複数ページ（タブ）が作成されていました！
Before/After
| Before（GUI / JSON手動編集） | After（Terraform） | |
|---|---|---|
| 作成数（例） | 23ページ（1ホスト1ページ × 23台） | 同左 |
| 作業内容 | JSONコピペ＆編集 or GUI操作 | tfvars編集 → PR → apply |
| 時間 | 1時間以上 | 約5分（実行は1分未満） |
| 品質担保 | 手作業で確認 | テンプレート化で統一 |
※作成数は一例。ホスト数に応じてスケールします。
6. 導入して見えたこと
6-1. 良かった点
- ホスト台数が多いほど効果を発揮
- New Relicの知見が浅い人でも一定の品質を担保できた
- レビュー対象がtfvarsだけなので、確認箇所が明確
6-2. 課題・注意点
- 環境準備（S3、GitHub Actions等）が前提として必要
- 導入後、GUI操作が増えると設定が乖離する可能性あり
- テンプレート改善は結局属人化しがち
- Terraform学習コストとのトレードオフ
7. おわりに
まだまだ改善の余地はありますが、「tfvars編集だけで監視設定が完了する」仕組みは形にできました。
今後取り組みたいこと：
- 他モジュール（SAP、Cloud、Observability等）の充実
- 実際の導入案件での効果検証
- 導入時だけでなく運用フェーズへの拡張（ドリフト検出、設定変更のTerraform管理徹底など）
監視設定の「見えないコスト」に悩んでいる方の参考になれば幸いです。