開発環境の利用状況をNew Relicで可視化する

この記事はヤプリ Advent Calendar 2023 & New Relic Advent Calendar 2023の16日目の記事です。

こんにちは！New Relic大好きSREグループの三橋です。
本日は開発環境の利用状況をNew Relicのダッシュボードを使って可視化している話について記載します。

想定する読者

• New Relicの活用事例についてご興味のある方
• アナログな手法での開発環境の利用状況管理にお悩みの方
• Yappliの裏側にご興味のある方

どんなダッシュボードを作ったか

下記の3つのタブで構成されるダッシュボードを作成し1年ほど運用しています。
詳細については後続のセクションにて解説します。

• 全体概要: 開発環境全体の利用状況を可視化する
• 個別環境: 個別の開発環境の利用状況を可視化する
• APM: 開発環境用のなんちゃってAPM

全体概要

個別環境

APM

背景

前提として開発環境は以下のようになっています。

• YappliのインフラリソースはAWS上に複数分散して存在するため、開発用としてそれらをひとまとめにした環境を複数用意している (これを社内ではreview環境と呼んでいる)
• review環境には番号を振っており、番号によって用意するインフラリソースも微妙に変えて運用している (コストやセキュリティ的な事情)
• slackコマンドを使用して、review環境立ち上げ、自動起動停止の有効化/無効化の切り替え、最新DBデータの同期等ができるようになっている
• APMを閲覧可能なNew Relicユーザが限られている

また下記のような課題感がありました。

• 各review環境を利用する場合はConfluence上にあるドキュメントに利用者と利用期限を書いて利用する運用になっていたが、ドキュメントが更新されていない、利用期限が無期限となっているということがあり、環境が常に空いていない(ように見える)
• 開発メンバーからreview環境追加依頼が頻繁に発生し利用料が増加する
• 環境の立ち上げ失敗時に実施したslackコマンドを都度ヒアリングする必要がある
• コスト最適化でインフラリソースの共通化などを実施する際は基本的に営業時間後になる
• オブザーバビリティの効果を開発メンバーに実感していただきたいが閲覧権限がない

作成したダッシュボードの解説

それではこれらの課題を解決するために作成したダッシュボードを解説いたします。

ダッシュボード解説 - 全体概要タブ

構成要素

• 環境利用率: インフラ構成が異なる環境ごとの利用率
  • この情報をもとにreview環境を追加するか判断できるようにしている
• review環境稼働状況: 各review環境の3時間ごとの稼働状況
  • 全体の利用状況の概観を確認できるだけでなく、停止忘れの環境がないかを確認するためにも利用している
• CMS最終ログイン時刻
  • アプリケーションレイヤーで利用している人がいないか確認するために利用している
• slackコマンド実行履歴: 実行ユーザと実行コマンドの履歴
  • いつ環境を立ち上げようとしたかなどが確認できるのでトラブルシューティングなどに利用している

ポイント

• review環境稼働状況については見やすさの観点からあえてTIMESERIESで3時間に設定している
• 同様にSINCEも1週間を明示的に指定している(これは休日のサーバ稼働状況を確認するためでもある)
• CMS最終ログイン時刻はアプリケーションのログからreview環境ごとにlatestのログインログを持ってきている(ログインユーザ名は取れなかったので断念)
• slackコマンドの履歴は、各種操作をlambda上で動かす仕組みになっているのでそのログを持ってきてparseしている

ダッシュボード解説 - 個別環境タブ

構成要素

• CMS最終ログイン時刻
• 最終push: そのreview環境で利用しているリポジトリの最終pushの記録
  • 開発が行われているか確認するために利用している
• slackコマンド実行履歴
  • その環境が利用されているか確認するために利用している
• ECSサービス過剰状況
  • 環境が正常に立ち上がっているか、またいつから起動しているか確認するために利用している

ポイント

• review環境ごとにダッシュボードを動的に切り替えられるようにするためtemplate variablesを利用している (画面左上のreviewXXの欄)
• template variablesの値はNRQLで引っ張ってきて選択式にしている)
• それぞれのチャートはtempalte variablesの値をWHERE句に入れることで関心のある環境情報のみを表示できるようにしている
• 最終pushのデータはCircleCIのログから持ってきている
• ECSサービス稼働状況はサービスごとに表示するようにすることで、その環境に用意されているECSサービスがわかるようにしている

ダッシュボード解説 - APM

基本的にはAPMと同様のチャートで構成されます。
これはAPMの画面を閲覧する権限がない方向けにオブザーバビリティがどのような恩恵をもたらすか体感していただきたいという想いで作成したダッシュボードになります。

構成要素

• Web transaction time(ms): APMと同様のチャート
• Error rate(%): APMと同様のチャート
• Call count top10: APMと同様のチャート
• Error rate(%) top10: APMと同様のチャート
• Traceデータ: Transaction名, TraceId, Sampled, Errorの履歴
• Spanデータ: Spanデータの全アトリビュートの履歴

ポイント

• template variablesとして下記を定義している
  • ecs_service: 可視化したいECSサービスを選択できるように用意(NRQLで引っ張って選択式にしている)
  • error: Traceデータの履歴に表示するデータをerrorのみにするか否か(デフォルト: falseでtrue/falseの二択にしている)
  • traceId: 追いたいTransactionのtraceIdをここに入力することで対象のtraceIdが付与されたSpanデータを表示できるようにしている

ダッシュボードを1年間利用してみての感想

このダッシュボードを利用してみて下記の効果を実感しています。

• 実際の環境の空き状況がわかるようになり、使ってなさそうな環境を見つけて声掛けができるようになった
• 利用状況がわかるので日中にインフラ構成変更がしやすくなった
• review環境は大量にあるが意外と使われてないことが判明し、リソースの効率化の余地がありそうなことがわかった
• 環境の立ち上げ等に苦戦してそうなメンバーを見つけてフォローすることができるようになった

一方で、APMについてはあまり使われていないような印象を受けています(New Relic上からはダッシュボードの活用状況がわからないため主観です)。これには下記の理由があると考えています。

• ダッシュボードがイケてない
  • 文字情報が多いなど
• そもそも使うメリットがイマイチわからない
  • デモは行ったが実際の開発プロセスでどのように活用するかまでは取り上げていない
• 開発環境から送られるテレメトリデータが不十分
  • 現状ECSのトレース、メトリクスしか取れない
• 後から入社したメンバーはそもそもダッシュボードの存在自体を知らない

まとめ

開発環境の利用状況をNew Relicのダッシュボードを使って可視化している話について記載いたしました。すでにNew Relicに連携しているデータを活用して、ダッシュボードを作成したことでコストをかけずに抱えた様々な課題をまとめて解決することに成功しました。まだまだ課題はありますが少しずつ改善していきたいと思います。NRQL最高！！