はじめに

今回、新規サービスの構築にあたってEKS環境にNew Relicを導入する機会がありましたので、感想文として残しておきたいと思います。
※本記事は主にインフラ観点での内容となります。

アーキテクチャ概要

インフラ構成は以下のような形で構築しています。
AWSにEKSを構築してアプリケーション実行環境とし、データベースにはAuroraを採用しました。比較的オーソドックスな構成かなと思います。

New Relicへのデータ収集は、以下の2つの方法で実施しています

EKS環境からの収集
- 各Node上で動作するNew Relic Agentを通じて、ログとメトリクスを転送
その他AWSサービスからの収集
- CloudWatch経由でData Firehoseを使って転送

また、New Relic については以下も導入しています

Synthetics MonitoringのScripted Browser/APIによる外形監視
TeamsやSlackへのアラート通知連携
Dashboard での管理

設計・構築フェーズの話

今回インフラの環境構築は主に Terraform + Terragrunt を利用しました。
( Terragrunt は Gruntwork 社が公開している Terraform の wrapper ツールで、簡単に module の管理が出来たり、state を小さく分割することができるイカしたツールです)

AWSの各サービスからNew Relicの監視設定までほぼすべて IaC にて構築することができたので、一部抜粋してどう実装したかをご紹介します。

Terragruntを利用し各サービスを module で管理

今回構築するAWSやNew Relicのサービスについて、module としてディレクトリを分割して管理しています。
(以下は New Relic の設定箇所から一部抜粋)

├── modules
│ ├── newrelic ... New Relic アカウントとのリンクや CloudWatch 関連の設定を管理
│ │ ├── firehose.tf
│ │ ├── iam.tf
│ │ ├── link_account.tf
│ │ ├── metrics_stream.tf
│ │ └── variables.tf
│ │ 
│ ├── monitoring ... New Relic 側の監視やダッシュボードの設定を管理
│ │ ├── synthetics_script
│ │ │ ├── xxx.tftpl
│ │ │ └── xxx_api.tftpl
│ │ ├── dashboard
│ │ │ └── dashboard.tftpl
│ │ ├── monitoring_logs.tf
│ │ ├── monitoring_metrics.tf
│ │ ├── monitoring_synthetics.tf
│ │ ├── variables.tf
│ │ └── workflow.tf
│ │

Terragrunt によってディレクトリごとに state を分割することができるため、巨大な state で管理が煩雑になることがなく、チームで開発する際にも競合が発生しづらく快適に開発を行うことが出来ました。

環境分離

環境分離については、本番/ステージング/開発と環境面ごとにディレクトリを分け、以下の構成で管理しています(一部省略)

└── env
   ├── prod
   │ ├── monitoring
   │ │ └── terragrunt.hcl ... module に input する変数の定義
   │ ├── newrelic
   │ │ └── terragrunt.hcl ... module に input する変数の定義
   │ ├── variables.hcl ... 本番環境固有の変数
   │
   ├── stag
   │ ├── monitoring
   │ │ └── terragrunt.hcl ... module に input する変数の定義
   │ ├── newrelic
   │ │ └── terragrunt.hcl ... module に input する変数の定義
   │ ├── variables.hcl ... ステージング環境固有の変数
   │
   └── terragrunt.hcl ... 環境共通の設定(providerやremote_state)

Terragrunt を利用すると remote_state の置き場の S3 も一緒に作成することができて地味に便利でした。

Kubernetes 環境

Kubernetes 上のコンテナの管理についてはみんな大好き Helm を利用し管理しています。
また、New Relic Agentのインストールについては nri-bundleという便利な Helm Chart が公開されているため、必要なコンポーネントを一括でインストールすることが出来ました！

今回 New Relic 含め構築環境のほぼすべてをIaC で構築することができたので、更新反映や環境管理を非常にシンプルにスムーズに行うことが出来ました。メンテナンスも楽々！

試験フェーズの話

負荷試験ではAWSが提供している Distributed Load Testing on AWSを利用しました。
Distributed Load Testing on AWS は CloudFormation で負荷試験の実行環境を一括デプロイしてくれる AWS のソリューションで、今回は JMeterのシナリオを利用し試験を実施しています。

K8s のオブザーバビリティ向上

Kubernetes環境は Pod が増えていくにつれ環境の複雑度が増し、運用コストが上がっていくものですが、New Relic導入によってオブザーバビリティ(可観測性)が飛躍的に上がったと感じました。

特にNew Relic の Dashboard機能により各NodeやPodに関連するメトリクスを時系列で確認することができ、障害解析やリソース使用量の把握を素早く行うことが出来ました。
New Relic では Pre-built Dashboard という形で事前に定義されたテンプレートが公開されているため、そのまま使うことも可能ですしカスタマイズするのもブラウザもしくは json から簡単に行うことが出来ます。

また、ログについても Log UIから簡単にドリルダウンを行うことができ、こちらも快適でした。
New Relicでは NRQL (New Relic Query Language) という SQLライクな言語でログやメトリクスをクエリすることができますが、Log UIでの検索ログ内容をNRQLへの変換も行ってくれるので、SQLに慣れていない人でもすぐに使いこなせると思います。

また、普段あまり集計してみることのない Kubernetes Events についても集計結果を見ることができ興味深かったです。

まとめ

今回は主にEKS環境へのNew Relicの導入を行っていきました。New Relic を導入することで、サービスに簡単にオブザーバビリティを実装することができ、設計・構築・試験にて活用することがで来たと思います。

また課題として、何でもかんでもデータを送信していたらデータ取り込み量が増大してしまったため、今後データ量を減らすよう改善していきたいです...