【New Relic】New Relicで実現するコスト管理方法～データ取り込み量削減/AWS Cost Explorer/Cost Optimization Hubの可視化～

はじめに
New Relicの課金体系について
New Relicのデータ転送の流れについて
データ取り込み量削減方法①：不要なデータの取り込みを除外する
データ取り込み量削減方法②：Drop filtersを利用する
Drop filtersの設定例：「Metric Streams」での疑似的なタグフィルター設定
コスト使用状況の可視化
まとめ
おまけ
宣伝

はじめに

こんにちは。マネージドサービス部の福田です。
今回はNew Relicで実現できるコスト管理のお話になります。

前半にNew Relicデータ取り込み量削減方法、後半にCost ExplorerおよびCost Optimization Hubなどのコスト情報に関するダッシュボード例の紹介をさせていただきます。

New Relicの課金体系について

New Relicの課金体系としては「ユーザー数」「データ転送量」になります。
課金体系の詳細については以下ブログを見ていただければと思います。

blog.serverworks.co.jp

New Relicのデータ転送の流れについて

New Relicのデータ転送の流れとしては以下になります。

データ転送で課金が発生する主な内容は以下になります

AWS側
- CloudWatchの料金
- Amazon DataFirehoseの料金
New Relic側
- データ取り込み料金

ここからはデータ取り込み量の削減方法についてご紹介させていただきます。

データ取り込み量削減方法①：
不要なデータの取り込みを除外する

New Relic Agentのサンプリングレートの調整

New Relic Agentデフォルトのデフォルト設定では以下の特徴があります。

データ収集間隔が短く設定されている
基本的にAgentで取得できるデータはほぼ全て転送される設定

システム全体を可視化するにはデータないと始まらないので
データを取得しないより取得したほうがいいという考えだと思います。

データ収集間隔に関するパラメーター例
- プロセス情報収集タイミング(infrastructure agent)
metrics_process_sample_rate:xx

-スタックトレース収集タイミング(APM Agent)
transaction_tracer.stack_trace_threshold:xx

個人的にon-host Integrationsに関するデフォルト設定は結構収集間隔が短い印象あるので注意が必要かなと思います。
- on-host Integrationsについては以下記事をご覧ください
- (記事内でもinterval: 15sと15秒での収集間隔になっておりました）

qiita.com

infrastructure agentのログ転送設定ファイルの修正

infrastructure agentのログ設定はデフォルトだと様々なログを転送する設定になっているので infrastructure agentによるログ転送をしない場合は
以下のログ設定ファイルの中身を削除するなど対応が必要になります。

Linux：/etc/newrelic-infra/logging.d/logging.yml
Windows：C:\Program Files\New Relic\newrelic-infra\logging.d\logs.yml

所感

その他APMのログ転送設定もそうですが各New RelicAgentの設定ファイルを確認し転送するデータの調整作業はやはり重要だと思いました。

データ取り込み量削減方法②：
Drop filtersを利用する

削減方法①の場合はデータ転送元でNew Relicへ送るデータをフィルタリングする方法になります。
とはいえ場合によってはデータ転送元でフィルタリングしきれないこともあるかと思います。

例えば New Relicの連携方法での一つである「Metric Streams」はAWSのCloudWatch Metric Streamsを利用した連携方法になります。
ただ、CloudWatch Metric Streamsではメトリクスの名前空間、メトリクス名までしかフィルタリングができないので
「API Polling」では実現できるタグ単位でのフィルタリングを実現することが出来ません。
そのため不要なリソースのメトリクスもNew Relicに収集されNew Relic側の料金が上がってしまいます。

そこで登場するのが「 Drop filters」という機能になります。

「Metric Streams」のフィルタリング画面

メトリクス名までしか指定が出来ない

Drop filtersとは

Drop filtersは、指定された条件に一致するデータをNew Relic DB(NRDB)に保存される前に除外することが出来る機能になります。

New Relic DBに保存されないのでNew Relic側のデータ取り込み量のコストが発生しません。

docs.newrelic.com

Drop filtersの設定方法

GUI上の設定画面

Partitions
- 適用対象とする partition を選択。複数選択可。
Filter logs based on NRQL
- 対象のログをフィルタリングする
Filter type
- Drop logs：ログ自体を破棄する
- Drop attributes：ログ自体を破棄するのではなく、ログ内の特定の属性情報のみを破棄する
  - 機密情報が含まれているログがあった場合、機密情報のみを破棄することが出来ます

NerdGraphの設定画面

GUIではログに対してのみ設定が可能になりますがNerdGraphを利用するとログ以外のすべてのデータを設定可能になります。

Apps からNerdGraph API Explorer へ移動します

設定に必要なフィールドを選択していくと自動的に右側に実行コマンドが作成されていきます
- フィールドを選択せずに直接右側にコマンドを記載することも可能です。

Drop filtersの設定例：「Metric Streams」での疑似的なタグフィルター設定

今回は Drop filtersを使用して「Metric Streams」でもタグフィルターのような内容を実装していこうと思います。
実装するDrop filterルールの内容は以下です。

「nr-app-test」というNameタグのみ「Metric Streams」経由のメトリクスを収集する
- ルール反映後はEC2一台の情報のみ収集される想定
メトリクスに対するDrop filtersなのでNerdGraphを用いてルールを設定します。

Drop filtersを作成するNerdGraphクエリ例

mutation {
  nrqlDropRulesCreate(accountId: ★NRアカウントID★, rules: {
    action: DROP_DATA,
    description: "任意の説明文",
    nrql: "FROM Metric SELECT * WHERE collector.name = 'cloudwatch-metric-streams' AND tags.Name != '★Nameタグ（例：nr-app-test）★'",
    source: "Metrics"
  }) {
    successes {
      accountId
      source
    }
    failures {
      error {
        reason
      }
    }
  }
}

設定されているDrop filtersを確認するNerdGraphクエリ例

{
  actor {
    account(id: ★NRアカウントID★) {
      nrqlDropRules {
        list {
          rules {
            nrql
            source
            id
          }
        }
      }
    }
  }
}

設定されているDrop filtersを削除するNerdGraphクエリ例

mutation {
  nrqlDropRulesDelete(accountId: ★NRアカウントID★, ruleIds: ["★ドロップフィルターのID★"]) {
    successes {
      id
    }
    failures {
      error {
        description
      }
    }
  }
}

設定後の結果

NRQLより対象のタグ（nr-app-test）が含まれているEC2のみ情報が取得されていることを確認

Infrastructure画面より収集されているメトリクスの名前空間が一つに減っていることを確認

コスト使用状況の可視化

構成図

今回の可視化（ダッシュボード）の仕組みの構成は以下になります。
※詳細な設定内容は長くなるので次回以降にブログを書きたいと思っております。

上記構成のポイントとしては以下になります。

現状のコスト使用状況を知りたい
- 現状を把握しないとコスト削減の必要性すらわからないため
コスト削減に関する推奨事項を知りたい
- 推奨事項があると対応方針決めやすいため（運用楽したい）
可視化した情報（ダッシュボード）を手軽に見たい
- ダッシュボード見るためにNew RelicやAWSにわざわざ入るのがめんどくさい（運用楽したい）

まとめると現状を知り、なるべく楽してコスト削減の方針を決めることができる構成にしました。

現状のコスト使用状況を知りたい

現状のコスト使用状況の判断内容とそれぞれ可視化した内容は以下になります。

AWS側の料金
- AWS Cost Explorerの可視化
New Relic側の料金
- データ取り込み量の可視化

Cost Explorerを可視化についてはNew Relicさんの「Parsing Rule」を利用して実現するという以下記事があるのですが
「Parsing Rule」に癖があり思ったようにいかなかったので上記の構成通り「Lambda」を使用しCost ExplorerのAPI経由で取得した情報をNew Relicに送る方式にしております。

newrelic.com

New Relicで作成したAWS Cost Explorerのダッシュボード

現在のコストと予測コストを表示
サービス別のコスト分布を表示
週間のコスト推移を表示

New Relic「取り込むデータ量」の内容

アカウント別・データソース別の使用量を表示
月間のデータ転送量推移を表示

コスト削減に関する推奨事項を知りたい

Cost Optimization Hubの情報を可視化することで実現させました。
Cost Optimization Hubはコスト最適化推奨事項を一元的に管理するサービスで、コスト削減に関する推奨事項を把握することができます。

推奨事項の例：
- 未使用のEBSボリュームの削除
- 使用率が低いEC2インスタンスのサイズを下げる
- Savings Plansの購入による長期的なコスト削減

New Relicで実現したCost Optimization Hubのダッシュボード

削減可能額と具体的な改善内容案を表示
削減可能なリソースタイプの把握および削減可能額を表示
各推奨事項を実装難易度含め表示

可視化した情報（ダッシュボード）を手軽に見たい

ダッシュボードを作成してもわざわざNew Relicへアクセスして確認するのめんどうだなーと思うときもあると思います。
New Relicのダッシュボードを定期的にslackへ連携することでそのような課題も解消することが出来ます
定期的に送るのではなくコスト使用状況に対して設定したアノマリー監視のアラート起因によって連携することも可能です。
そうすることで急激なコスト使用に気が付き、かつ詳細な情報もダッシュボードで確認することができます。

Slackに連携されたダッシュボード

なおダッシュボード変数を使用したダッシュボードはSlackへ連携する設定によっては表示されないので注意が必要です。

参考：【New Relic】New Relic ダッシュボード活用テンプレート変数編 - サーバーワークスエンジニアブログ

まとめ

オブザーバビリティを導入する際にやみくもにデータを収集するとコストも上がってしまいますのでコスト管理の考え方も重要になります。

まずは現状や改善箇所を把握するためにダッシュボードによる「可視化」が第一歩かと思います。
可視化をすることで過剰なデータ転送量に気がづきNew Relic AgentおよびDrop filtersのフィルリング等による「データ量の削減」に繋げることが出来ます。

とはいえコスト削減が目的になり本当に必要な情報を活用できなくなってしまったら意味がありません。難しい内容ではありますが重要なのは、「システムの状態を適切に把握するために本当に必要なデータは何か」を見極めることだと思います。

本ブログ記事が誰かのお役に立てれば幸いです。

おまけ

AWS PrivateLink 経由で New Relic データを送信することで「AWSからNew Relicへのアウトバウンド通信にかかる費用」の削減が可能になります。

現在New Relicでサポートされている AWS PrivateLink エンドポイントは us-east-1 、 us-east-2 、 us-west-2 、 eu-central-1なのでそれ以外のリージョンではVPCピアリング等が別途必要でした。