トップ > New Relic > New Relic監視設定の自動化を始めよう - Terraform × CI/CDツール比較ガイド

New Relic監視設定の自動化を始めよう - Terraform × CI/CDツール比較ガイド

New Relic Terraform GitHub Actions CI/CD AWS CodePipeline AWS CodeBuild DevOps
記事タイトルとURLをコピーする

みなさんこんにちは。マネージドサービス課の塩野です。

New Relicで監視設定を手動で管理していると、設定ミスのリスクや環境間の設定差異、特定の担当者に依存する属人化といった課題に直面します。アラート条件を本番環境だけ設定し忘れたり、開発環境と本番環境で閾値が異なってしまったりする経験は、多くのインフラエンジニアが持っているのではないでしょうか。

Terraformによる自動化を導入すれば、これらの課題を解決できます。

設定をコードとして管理することで、バージョン管理システムで変更履歴を追跡でき、環境間の一貫性も確保できるようになるでしょう。また、CI/CDツールと組み合わせれば、手動実行から脱却しレビュープロセスを組み込んだ安全な本番展開も実現することが可能です。この記事では、GitHub ActionsとAWS CodePipelineという2つの代表的なCI/CDツールを使ったNew Relic設定の自動展開方法を比較してみました。

それぞれの特徴や展開フロー、仕組みを理解することで、自分の環境に合った選択をしてみてはいかがでしょうか。

目次

New Relic監視設定の自動化とは

New Relicで自動化できる監視設定には、さまざまな種類があります。例えば、以下のような項目を自動化することもできます。

  • アラートポリシーと条件（閾値設定、NRQL条件）
  • ダッシュボード（カスタムダッシュボード、ウィジェット）
  • 通知チャネル（Slack、PagerDuty、Email、Webhook）
  • 合成監視（Pingモニター、シンプルブラウザ、スクリプトブラウザ、APIテスト）
  • ワークロード（サービスのグルーピング、ヘルスステータス）
  • タグとラベル（エンティティへのタグ付け）

これらの設定をコードで管理することで、環境ごとの設定差異をなくし、変更履歴を追跡できるようになります。

これらの設定をTerraformで管理する理由は、Infrastructure as Codeの考え方にあります。Terraformは宣言的な記述で「あるべき姿」を定義するツールで、冪等性が保証されているため、何度実行しても同じ結果が得られます。状態管理の仕組み（tfstate）により、現在の設定と定義の差分を自動的に検出することもできます。

ここで紹介するCI/CDツールは、コード変更から展開までを自動化する役割を担います。

terraform planによる事前確認で実際に適用される変更内容を確認した後で、terraform applyの実行を自動化することで、手動実行時のミスを防げるかもしれません。また、承認フローを組み込めば本番環境への変更を慎重に進められます。複数環境への段階的展開も、CI/CDツールの設定次第で柔軟に対応することができるでしょう。

GitHub Actionsを使った展開方法

GitHub ActionsはGitHubに統合されたCI/CDサービスです。ワークフローをYAMLファイルで定義し、リポジトリ内の.github/workflowsディレクトリに配置します。PushやPull Requestといったイベントをトリガーに、自動的に処理が実行される仕組みです。

基本構成

要素 説明
ワークフロー 自動化の一連の流れ全体
ジョブ 並列または順次実行される作業単位
ステップ 個別のコマンドやアクション
ランナー 実行環境（GitHub提供またはセルフホスト）

展開フロー

New Relic設定を展開する際の流れは以下の通りです。

Step1 terraform plan実行までの流れ

  %%{init:{'theme':'base',
    'themeVariables': {
        'lineColor': '#F8B229'
      },
    'flowchart':{'rankSpacing':80}}
  }%%
graph LR
    A[plan用ブランチにプッシュ] --> B[terraform init]
    B --> C[terraform plan]
    C --> D[plan結果をActionsのログで確認]

Step2 terraform applyまでの流れ

  %%{init:{'theme':'base',
    'themeVariables': {
        'lineColor': '#F8B229'
      },
    'flowchart':{'rankSpacing':80}}
  }%%
graph LR
    A[レビュー・承認] --> B[Mainブランチにマージ]
    B --> C[terraform apply]
    C --> D[New Relic設定反映]

リポジトリにはTerraformのコードとworkflowファイルを配置します。plan用ブランチにプッシュすると、terraform planで変更内容が確認され、結果がワークフローのアーティファクトとして保存されます。レビュアーはアーティファクトからレビューを行います。その後、Mainブランチにマージすることで、terraform applyが実行されて実際に設定が展開されます。

押さえておきたいポイント

認証情報管理

GitHub SecretsにNew Relic APIキーを保存します。AWSを利用する場合は、OIDC（OpenID Connect）を使った認証が推奨されます。長期的な認証情報を保存せずに済むため、セキュリティリスクを低減できます。

環境別展開

GitHub Environmentsという機能を使えば、環境ごとにシークレットを分離できます。

tfstate管理

S3バックエンドを使って状態ファイルを保存します。GitHub Actionsの場合は同時実行することもできますので本番運用ではDynamoDBを用いたState Lockingの実装が推奨されますが、本記事では簡易化のため省略します。S3に保管するtfstateファイルは、バケットポリシーとKMS暗号化を工夫することでセキュリティを強化することもできます。

AWS CodePipeline/CodeBuildを使った展開方法

AWS CodePipelineとCodeBuildは、AWSが提供するマネージドCI/CDサービスです。CodePipelineはワークフロー全体を管理し、CodeBuildは実際のビルドやテストを実行します。ビルド処理はbuildspec.ymlファイルで定義します。

基本構成と役割分担

CodePipeline/CodeBuildでは、各AWSサービスが以下の役割を担います。

サービス 役割 具体的な処理
CodePipeline ワークフロー全体の制御 ステージの順序制御、GitHub連携、SNS通知
CodeBuild Terraformコマンドの実行 terraform init/plan/applyの実行
S3 tfstate保存 Terraform状態ファイルの保存
Secrets Manager 認証情報管理 New Relic APIキーの保存
CloudWatch Logs ログ管理 実行ログの保存と監査

展開フロー

New Relic設定を展開する際のパイプライン構成は以下の通りです。

  %%{init:{'theme':'base',
    'themeVariables': {
        'lineColor': '#F8B229'
      },
    'flowchart':{'rankSpacing':80}}
  }%%
graph LR
    A["Sourceステージ<br/>(CodePipeline)<br/>GitHubからコード取得"] --> B["Buildステージ<br/>(CodeBuild)<br/>terraform plan実行"]
    B --> C["Buildステージ<br/>(CodeBuild)<br/>terraform apply実行"]
    C --> D["New Relic設定反映"]

パイプラインは、CodePipelineがワークフロー全体を制御します。まずGitHubからコードを取得し、CodeBuildでterraform planを実行して変更内容を確認します。続けてCodeBuildでterraform applyを実行して設定を展開する流れです。変更内容の承認を組み込みたい場合、下記のようにCodePipelineのワークフローに承認（Manual Approval）プロセスを追加することで制御することも可能です。

  %%{init:{'theme':'base',
    'themeVariables': {
        'lineColor': '#F8B229'
      },
    'flowchart':{'rankSpacing':80}}
  }%%
graph LR
    A["Sourceステージ<br/>(CodePipeline)<br/>GitHubからコード取得"] --> B["Buildステージ<br/>(CodeBuild)<br/>terraform plan実行"]
    B --> C["Approvalステージ<br/>(CodePipeline)<br/>実行内容の確認・承認"]
    C --> D["Deployステージ<br/>(CodeBuild)<br/>terraform apply実行"]
    D --> E["New Relic設定反映"]

押さえておきたいポイント

認証情報管理

IAMロールによる権限管理が基本です。Secrets ManagerにNew Relic APIキーを保存し、CodeBuildから安全に取得できます。

環境別展開

Parameter Store（Systems Manager）で環境別の変数を管理すれば、同じコードで異なる環境に展開できます。複数のパイプラインを用意して環境を分離する方法もあります。環境別のNew Relicアカウントの場合、APIキーを使い分けることで対応できます。

tfstate管理

S3バックエンドで状態ファイルを保存します。CI/CDパイプラインで自動実行する場合は、順次実行されるため同時実行の心配はありません。バケットポリシーとKMS暗号化でセキュリティを強化できます。

New Relic設定展開における比較

New Relic監視設定をTerraformで展開する際の、GitHub ActionsとCodePipeline/CodeBuildの比較です。

比較項目 GitHub Actions CodePipeline/CodeBuild
初期構築の手軽さ YAMLファイル1つで開始可能 IAMロール、CodePipeline、CodeBuild等の設定が必要
Terraform実行環境 GitHubホストランナー（Ubuntu/Windows/macOS） CodeBuild（カスタムDockerイメージも可）
New Relic APIキー管理 GitHub Secrets Secrets Manager
tfstate保存先 S3バックエンド（OIDC経由でアクセス） S3バックエンド（IAMロール経由でアクセス）
変更内容の確認 ワークフローのアーティファクトとして保存 CloudWatch Logsで確認
承認プロセス ブランチを分けたAction実行 CodePipelineでの承認プロセス
複数環境への展開 GitHub Environmentsで環境分離 複数パイプラインまたはParameter Store
VPC内リソースへのアクセス セルフホストランナーが必要 標準機能で対応可能
実行ログの確認 GitHub UI上で完結 CloudWatch Logsで確認

どちらを選ぶべきか

GitHub Actionsが向いているケース

New Relicの監視設定の目的だけなら、設定範囲が少なく管理する箇所が少ないので、この選択肢の中ではGitHub Actions1択です。New Relic以外のインフラリソースの展開にも展開する予定がある場合は、小〜中規模までの環境で迅速に導入したい場合に適していると思います。plan結果がワークフローのアーティファクトとして保存されるため、変更内容を確実に確認できるのも利点です。

CodePipeline/CodeBuildが向いているケース

New Relicの監視設定の目的だけなら、設定箇所が多いためあまりオススメはしません。New Relic以外のインフラリソースの展開にも展開する予定がある場合で、AWS中心のインフラ環境の展開を検討している場合や、既存のAWS CI/CDパイプラインに統合したい場合などに適していると思います。GitHub ActionsもEnvironment protection rulesで承認フローを設定できますが、CodePipelineは承認アクションがパイプラインの標準機能として統合されており、監査ログとの連携も容易です。

選定時の考慮ポイント

構築の容易さでは、GitHub ActionsがYAMLファイル1つで開始できるのに対し、CodePipelineは複数のAWSサービス設定が必要になります。New Relic設定の自動化を初めて導入する場合は、GitHub Actionsの方が取り組みやすいでしょう。

既存環境との親和性は、利用しているツールチェーンによって変わります。GitHub Actionsは、GitHubでTerraformコードを管理している場合に最適です。一方、CodePipelineはAWS中心のインフラ環境で真価を発揮します。特にエンタープライズのユースケースではこちらの方に軍配が上がるケースも多くあるでしょう。

コスト構造としては、GitHub Actionsは無料枠が充実しており、高頻度に更新しないようなNew Relic設定の展開程度であれば無料枠内で収まる可能性が高そうです。CodePipelineはパイプライン単位の月額料金に加えて、CodeBuildの実行時間に応じた課金が発生します。小規模な環境では、GitHub Actionsの方がコストを抑えることができそうです。

まとめ

New Relic監視設定の自動化は、設定ミスの削減、環境間の一貫性確保、変更履歴の可視化といった価値をもたらします。Terraformでコード管理し、CI/CDツールで自動展開することで、手動管理の課題から解放されます。CI/CDツールの選び方は環境や要件次第で、GitHub Actionsは迅速な導入と設定の手軽さに優位性があり、CodePipelineはAWS統合とエンタープライズレベルの監査ログ取得や承認フローなどの対応に優れています。

こうした自動化により運用負荷を軽減し、本質的な監視設計により多くの時間を割けるようになります。段階的に自動化範囲を広げてみてはいかがでしょうか。

こちらの記事がどなたかのお役に立てれば幸いです。

宣伝

弊社では、お客様環境のオブザーバビリティを加速するためのNew Relicアカウント開設を含めた伴走型のNew Relic導入支援サービスをご提供しております。 もしご興味をお持ちの方は、こちらのお問合せフォームよりお問合せ頂けましたら幸いでございます。

関連記事

blog.serverworks.co.jp blog.serverworks.co.jp

◆　塩野　正人
◆　マネージドサービス部　所属
◆　X（Twitter）：@shioccii
◆　過去記事はこちら

前職ではオンプレミスで仮想化基盤の構築や運用に従事。現在は運用部隊でNew Relicを使ってサービス改善に奮闘中。New Relic User Group運営。