【やってみた】New Relicのネットワーク監視(NPM)用コンテナKtranslateをECSで動作させる

記事タイトルとURLをコピーする

この記事は約4分で読めます。

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

前回の続きの記事になりますが、New Relicのネットワーク監視(NPM)を行う際に、監視サーバ(Ktranslate)はECS環境で動くんだっけ?というのを試した記事になります。

blog.serverworks.co.jp

なお、New Relic公式の情報として、ネットワーク監視(NPM)のサポート環境はDockerやコンテナオーケストレーション環境のPodman、またはLinuxサーバに直接インストールのどれかになるため、ECS環境での動作は自己責任でお願いします。

目次

記事の背景

AWS環境でNew Relicのネットワーク監視(NPM)を行う場合、EC2に直接インストールするか、EC2にDockerをインストールしDockerコンテナ上で動作させるのが現実的な選択肢となります。以前はKubernetes環境もサポートされていましたが、EKSのKubernetesバージョンは定期的に更新され各バージョンにはサポート期間があるため、他のシステムでKubernetesを使用されていない場合は、監視サーバ(Ktranslate)のメンテナンス工数に加えて基盤側のメンテナンス工数がのしかかってくる構図となっており、あまり使い勝手がいいという状況ではありませんでした。

現実問題として、ネットワーク監視自体や監視先設定以外に、監視元のDockerやKtranslateが直接インストールされたEC2を面倒みていくのもツライので、そういった部分が少しでも解消できないかというのが検証したきっかけとなります。とはいえ、New Relic公式のサポート構成ではありませんので、そういったリスクを負いたくないという場合やこれから本番でがっつり運用していく場合は、New Relic公式のサポート構成での構築をオススメいたします。

システム構成

この構成は検証目的のため、あまり細かい運用を考えていない構成になります。自己責任でガッツリやっていきたい場合は、設定ファイルをGitHubなどのレポジトリで管理しつつ、CodeBuildやCodeDeploy、CodePipelineなどを組み合わせたCI/CD構成か、GitHub Actionなどで同様の構成を取っていただくと現実問題としてもう少し運用が楽になるかもしれません。今回は主題から逸れるためCI/CD構成なしの環境での構築となります。

やってみた

Amazon ECRへのプッシュまでの流れ

ざっくりした手順としては、先にプッシュ先のAmazon ECRのレポジトリを作成しておき、CloudShellでビルドしたイメージをプッシュするだけです。

Amazon ECRのレポジトリ作成

  1. Amazon ECRを開く
  2. レポジトリを作成するをクリックする
  3. 任意のレポジトリ名を入力
    ※レポジトリ名以外はデフォルト値
  4. 作成をクリック

AWS CloudShellでのイメージビルドとAmazon ECRへプッシュ

  1. AWS CloudShellを開く
  2. 下記に記載のサンプル snmp-base.yaml を作成する
    vi snmp-base.yaml
  3. 下記に記載のサンプル Dockerfile を作成する
    vi Dockerfile
  4. 下記コマンドでイメージをビルドする
    docker build -t <イメージ名>:latest .
  5. 下記コマンドでイメージにタグをつける
    docker tag dev-ktranslate-snmp:latest <AWSアカウントID>.dkr.ecr.ap-northeast-1.amazonaws.com/<イメージ名>:latest
  6. 下記コマンドでAmazon ECRにログインする
    aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin <AWSアカウントID>.dkr.ecr.ap-northeast-1.amazonaws.com
  7. 下記コマンドでAmazon ECRにプッシュする
    docker push <AWSアカウントID>.dkr.ecr.ap-northeast-1.amazonaws.com/dev-ktranslate-snmp:latest
サンプル snmp-base.yaml
devices:
ping_only__10.0.0.10:
device_name: ping_only
device_ip: 10.0.0.10
provider: kentik-ping
ping_only: true
ping_interval_sec: 60
global:
poll_time_sec: 60
mib_profile_dir: /etc/ktranslate/profiles
mibs_enabled:
- IF-MIB
timeout_ms: 3000
retries: 0
サンプル Dockerfile

※ビルドするコンテナイメージに環境変数を埋め込んでいますが、後から上書きするため  ここでは実際のLicenseKeyなどを入力・更新する必要はありません

# Copy the snmp-base.yaml file into the container
COPY snmp-base.yaml /snmp-base.yaml

ENV NEW_RELIC_API_KEY=key_here
ENV NR_ACCOUNT_ID=1234567

# Define the command to run when the container starts
CMD ["-snmp", "/snmp-base.yaml", \
     "-nr_account_id=${NR_ACCOUNT_ID}", \
     "-metrics=jchf", \
     "-tee_logs=true", \
     "-service_name=dev-ktranslate-snmp", \
     "-snmp_discovery_on_start=true", \
     "-snmp_discovery_min=180", \
     "nr1.snmp"]

# Expose the SNMP trap port
#EXPOSE 1620/udp

事前作業

AWS Secrets Managerに送信先New Relicアカウントの情報を保存する

  1. AWS Secrets Managerにログインする
  2. 新規でシークレットを作成し、下記内容で保存する
{"NR_ACCOUNT_ID":"1234567","NEW_RELIC_API_KEY":"api_key_here"}

IAMポリシーの作成

ここではECSタスク実行ロールで使用するポリシーを作成します。

  1. AWS IAMを開き、ポリシーページを開く
  2. ポリシーの作成をクリック
  3. アクセス許可を指定画面でJSONモードに切り替え、下記に記載のポリシーを貼り付け、次へをクリック
  4. ポリシー名に任意の文字列を入れ、ポリシーの作成をクリック
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ecr:GetAuthorizationToken",
                "ecr:BatchCheckLayerAvailability",
                "ecr:GetDownloadUrlForLayer",
                "ecr:BatchGetImage"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": "secretsmanager:GetSecretValue",
            "Resource": [
                "arn:aws:secretsmanager:ap-northeast-1:<AWSアカウントID>:secret:<secret名>"
            ]
        }
    ]
}

IAMロールの作成

タスクロールの作成

※タスクロールは、タスク内で実行されるコンテナがAWSサービスにアクセスするために使用されます。つまりコンテナ内で動作するアプリケーションに与える権限です。

今回の検証ではタスクロールは使用しません。

タスク実行ロールの作成

※タスク実行ロールは、ECSエージェントがAWSサービスと連携するために使用されます。

  1. AWS IAMを開き、ポリシーページを開く
  2. ロールのページを開き、ロールを作成をクリック
  3. 信頼されたエンティティタイプでカスタム信頼ポリシーを選択し、下記カスタム信頼ポリシーを入力し、次へをクリック
  4. 許可を追加の画面で、前項で作成したIAMポリシーを選択し、次へをクリック
  5. ロール名に任意の文字列を入力し、ロールの作成をクリック
カスタム信頼ポリシー
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ecs-tasks.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Amazon Elastic Container Service環境の設定

Amazon ECSクラスタの作成

  1. Amazon ECSを開く
  2. タスク定義を開き、新しいタスク定義の作成をクリック
  3. 下記内容で設定する
    • クラスター設定
      • クラスター名: クラスタ名設定
    • インフラストラクチャ
      • AWS Fargate (サーバーレス):チェック
      • Amazon EC2 インスタンス:チェックしない
    • モニタリング
      • Container Insights を選択
    • 暗号化 - オプション
      • 必要に応じて設定
    • タグ ( - オプション)
      • 必要に応じて設定
  4. 作成をクリック

Amazon ECSタスク定義の作成

  1. Amazon ECSを開く
  2. クラスターを開き、クラスターの作成をクリック
  3. 下記内容で設定する
    • タスク定義の設定
      • タスク定義ファミリー:任意の名前を付ける
    • インフラストラクチャの要件
      • 起動タイプ:AWS Fargate
      • タスクサイズ
        • CPU:0.25 vCPU
        • メモリ:1 GB
      • タスクロール
        • 設定なし
      • タスク実行ロール
        • IAMロールの作成の項で作成したロールを選択
      • フォールトインジェクション
        • 設定なし
    • コンテナ
      • 名前:任意の名前を付ける
      • イメージ URI:ECRのイメージURIを記載
      • 必須コンテナ:はい
      • ポートマッピング:必要に応じて実施
        • SNMP TrapやSyslog、NetFlowを使用する場合は該当ポートを指定
      • 読み取り専用ルートファイルシステム:チェックなし
      • リソース割り当て制限 - (条件付き):指定なし
    • 環境変数 - オプション
      • キー1
        • キー:NEW_RELIC_API_KEY
        • 値のタイプ:ValueFrom
        • 値:SecretのARN
          • ※検証環境では arn:aws:secretsmanager:ap-northeast-1:<AWSアカウントID>:secret:<SecretName>:NEW_RELIC_API_KEY:: を使用
      • キー2
        • キー:NR_ACCOUNT_ID
        • 値のタイプ:ValueFrom
        • 値:SecretのARN
          • ※検証環境では arn:aws:secretsmanager:ap-northeast-1:<AWSアカウントID>:secret:<SecretName>:NR_ACCOUNT_ID:: を使用
  4. 作成をクリック

Amazon ECSのサービスの作成

  1. Amazon ECSを開く
  2. クラスターを開き、サービスタブから作成をクリック
  3. 下記内容で設定する
    • コンピューティング設定 *1
      • コンピューティングオプション:起動タイプ
        • 起動タイプ:FARGATE
        • プラットフォームタイプ:LATEST
    • デプロイ設定
      • アプリケーションタイプ:サービス
      • ファミリー:タスク定義の項で設定したタスク定義ファミリー名を指定
      • リビジョン:最新が選ばれていることを確認
      • サービス名:任意の名前を付ける
      • 必要なタスク:1
      • アベイラビリティーゾーンの再調整:チェックする
    • ネットワーキング
      • VPC:デプロイ先のVPCを選択
      • サブネット:デプロイ先のサブネットを選択
      • セキュリティグループ:監視通信が阻害されないような設定のセキュリティグループを選択
      • パブリック IP:必要に応じて設定
    • ロードバランシング
      • ロードバランシングを使用:必要に応じて設定
  4. 作成をクリック

動作確認

設定は以上で、Amazon ECSのタスク画面でKtranslateのタスクが元気に起動していれば設定は成功です。

まとめ

基本的にはサポートされてないながらも、Amazon ECS環境で動作できました。実環境で動作させるには検討しなければいけない事項がたくさんあるため、多少リスクを取ってもそこまでやるかどうかはそれぞれの事情次第かと思います。なお、当検証内容についてNew Relic社や弊社に問い合わせ頂きましてもご回答できない可能性がございますのでご了承ください。

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

宣伝

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

*1:アドバンスト

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

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