🎃

New RelicでSLI/SLOの設定をTerraform化してみた

に公開
New Relic
tech

本記事はTechBull Advent Calender 2025の14日目の記事になります。

はじめに

こんにちは、Iwakiです。
かなり久しぶりの投稿になりますが、最近はObserbabilityに関して学習しており、その中でもSLI/SLO周りのキャッチアップをしています。

そこで今回は、学習の中でNew Relicを使ったSLI/SLOの設定をTerraformでIaC化してみたのでこちらの内容をブログにしたいと思います。

SLI/SLOの策定

SLI/SLOの定義について簡単にそれぞれ以下に説明します。

  • SLI：サービスの性能や信頼性を測定する具体的な指標。
    • 例：レスポンスタイム、ステータスコード、スループットなど
    • 求め方：SLI = Good Event / Valid Event ✖️ 100
  • SLO：SLIに基づいて設定される目標値
    • 例：成功したリクエストの割合が過去30日間で99%以上

自分で構築したWordpress環境をNew Relicで監視しており、今回は例として以下をSLI/SLOとして策定してみました。

  • SLI：トップページのHTTP Status Code 2xx〜4xx以外の割合
  • SLO：99%以上のトップページへのリクエストがHTTP Status Code 2xx〜4xxであること

New RelicのService Levels Management

New RelicのService Levels Managementという機能でアプリケーションのパフォーマンスやレスポンスタイムなど任意のメトリクスを用いてSLI/SLOを定義することが可能です。今回は前段で定義したSLI/SLOの設定をTerraform公式ドキュメントを参考に設定してみました。

servicelevel_top_statuscode.tf
resource "newrelic_service_level" "top_statuscode" {
  guid        = "Service Levelを適用したい対象エンティティのGUID"
  name        = "Top page HTTP Status Code"
  description = "Top page HTTP Status Code"

  events {
    account_id = var.newrelic_id
    valid_events {
      from  = "Transaction"
      where = "name ='WebTransaction/Uri/index.php'"
    }
    good_events {
      from  = "Transaction"
      where = "name ='WebTransaction/Uri/index.php' AND http.statusCode < 500"
    }
  }

  objective {
    target = 99.00
    time_window {
      rolling {
        count = 1
        unit  = "DAY"
      }
    }
  }
}

PHP-FPMをAPMとして監視しているので、GUIDはこちらのエンティティのものを指定しています。
各ブロックでは以下を設定しています。

  • events：SLIを計算するためのブロック
    • valid_events：計測対象のすべての有効なイベント
    • good_events：成功とみなすイベント

eventsブロック全体としては「SLI = good_events/valid_events × 100」を計算しています。
今回はイベントタイプがトランザクションで、トップページへのすべてのステータスコードのうち、2XX~4XXの割合がどれくらいかを計算しています。

  • objective：SLIの目標値(SLO)
    • time_window：評価期間
      • rolling：ローリングウィンドウ方式

実行結果

実行されるとService Levels > Summary画面で以下の項目が表示されます。

それぞれの表示項目は以下を表しています。

  • SLO compliance：SLOをどれだけ達成できているか
  • SLI comliance overtime：SLIが時系列でどう変化しているか
  • Remaining error Budget：エラーバジェットの残量
  • Good and bad events：成功・失敗のイベント数

上記のようなSLI/SLOの進捗やエラーバジェットの残量をエンジニア以外のビジネスサイド側とも共有することにより、ユーザがサービスを利用できているかを全員が把握できたり、SLOの管理方針を決めておけば、エラーバジェットが消費されてきたらどのようなアクションをするかの判断を即座に下せると思いました。

最後に

今回はSLI/SLOの設定のみを書きましたが、このSLI/SLOの設定からバーンレートアラートといったサービスがエラーバジェットをどのくらいのスピードで消費しているかを監視できるので、こちらについてもTerraformでコード化してみたいと思います。
ここまで読んでいただきありがとうございました。

Discussion