みなさんこんにちは。マネージドサービス部MSS課の塩野（正）です。 プライベートサブネットにあるWebシステムの監視ってどうしていますか？
今回はNew Relicを使ったプライベート環境のURL監視のお話です。
当たり前すぎるためあえてここで話をする必要はないのかもしれませんが、今回の記事の大前提としてプライベート環境とパブリック環境について先に定義しておきます。 当記事では、パブリック環境とはグローバルIPをもってインターネット側からアクセスができるサーバのことを指し、プライベート環境とはグローバルIPを持たずにプライベートIPのみ保有しており、インターネット側からアクセスができないサーバのことを指しています。ここでこの定義をしている理由は制限のあるパブリック環境についての話を本文で触れているため、明確にこの環境ではこのパターンをいうのを表現しやすくするためのものとなります。
それでは本題に進んでいきましょう。
目次
概要
New RelicでURL監視を行う場合は、プライベート環境の場合でもパブリック環境の場合でもMinion（またはSyntheticsジョブマネージャー）というシステムを使用して監視を行います。 一般的にパブリック環境の場合、New Relicの中に設置してあるNew Relic社が管理しているMinionを使用して監視をおこないます。この環境では、インターネットに接続しているサーバであれば特に制限なく監視をおこなうことができます。
とはいえ、パブリック環境に面しているサーバでもアクセス元IPアドレスを制限しているケースも存在するでしょう。こういったケースやプライベート環境などの場合については、ユーザー環境にMinion（またはSyntheticsジョブマネージャー）を設置して、そのMinionを経由してURL監視を行います。前者のNew Relic社管理のMinionをPublic Minion、後者のユーザー管理のMinionをPrivate Minionと呼んでいました。現在は、このMinionという表現を無くし、プライベート環境の監視についてはプライベートロケーション監視と表現しているようです。
整理すると下記の表のようになります。
| ネットワーク環境 | アクセス元 | 監視システム |
|---|---|---|
| パブリック環境 | すべてのインターネット環境からアクセス | パブリックロケーション監視 |
| パブリック環境 | 特定のソースIPアドレスからアクセス | プライベートロケーション監視 |
| プライベート環境 | プライベート環境内でのアクセス | プライベートロケーション監視 |
パブリック環境の構成
一般的なパブリック環境での監視を行う場合は、下記のような構成となります。
プライベート環境の構成
プライベート環境や、アクセス元が制限されたパブリック環境の場合は、下記のような構成となります。
検証環境の構築
それでは、実際にプライベートロケーション環境を構築してみましょう。 今回は最小限の環境で構築していますので、本番環境で構築する場合は冗長性やセキュリティなど考慮の上で構築してください。
ECS on EC2での設定概要
今回の検証では、ECS on EC2 環境にて構築を行っています。New Relicのドキュメント上ではECSで動作するといったような記載は見当たりませんでしたので、本筋ならEC2にDockerをインストールしてPrivate Minionを起動するかEKSでの構築となる点、ご留意ください。ちなみにFargate環境でもタスク自体は起動しているものの、セキュリティ周りの制約によってMinionのコアコンポーネントとして動作している内部のJavaアプリケーションが強制シャットダウンされている状況でしたので、おそらくFargateでの動作させるのは難しいと推測しております。
EC2環境の設定
ECS on EC2を使う上でのポイントは、使用するイメージの選択を間違えないことと、ECS用のIAMロールを適用すること、ECSのクラスタ名を事前に仕込んでおくことの３点になります。
１．まず使用するイメージの選択ですが、ECS用のEC2を起動したいリージョン（今回は東京リージョン）でcloudshellを起動し、下記コマンドを実行します。
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/recommended/image_id --region ap-northeast-1
下記のようにAMIのIDを取得することができますので、AMI IDをメモします。
[cloudshell-user@hogehoge ~]$ aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/recommended/image_id --region ap-northeast-1
{
"Parameters": [
{
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/recommended/image_id",
"Type": "String",
"Value": "ami-0038727bc19be9974",
"Version": 156,
"LastModifiedDate": "2024-08-16T15:55:02.490000+00:00",
"ARN": "arn:aws:ssm:ap-northeast-1::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/recommended/image_id",
"DataType": "text"
}
],
"InvalidParameters": []
}
２．次に、EC2>インスタンスの画面を開き、インスタンスの起動をクリックします。
３．名前とタグの欄で任意の名前を入力し、アプリケーションおよび OS イメージ (Amazon マシンイメージ) の欄で「その他のAMIを閲覧する」を開きます。
４．コミュニティAMIを開き、先ほどのcloudshellのコマンド結果で得られたAMIのIDを入力して検索します。対象のイメージがフィルタされますので、選択を押してイメージを選択します。
５．次に、インスタンスタイプは t2.large 以上のものを選択します。
理由としては、New RelicのMinionの動作環境がコアあたり2.5GBのメモリを要求しているため、t2.mediumではその要件を満たさないからです。とはいえ、検証など「とりあえず動けばいいや」といった用途であれば t2.medium を選択したとしてもMinionの動作自体は問題なくできますので、今回の検証では t2.medium を使用しました。
Minionの要件や制約事項については下記のドキュメントをご参照ください。
５．ネットワーク環境は基本的にはNAT Gateway配下を推奨しますが、今回の検証では検証時の短時間のみの起動やインバウンドのSecurity Groupの開放をおこなわない条件で、パブリックサブネットにて構築しました。
６．IAM インスタンスプロフィールはECSタスクを動作するための権限の付与が必要となります。権限の詳細については、下記の項目で個別に説明します。
７．最後にユーザーデータに下記の内容を記載してインスタンスを起動します。下記の設定はECS用EC2インスタンスがどのECSクラスターに所属するかを定義する設定となりますので、必ず設定してください。また、下記の設定では、「newrelic-minion-cluster」というECSクラスターに自動登録する設定となっております。
#!/bin/bash echo ECS_CLUSTER=newrelic-minion-cluster >> /etc/ecs/ecs.config
IAMロールとIAMポリシーの設定
他のAWSリソースへのアクセスが不要な場合は、AmazonECSTaskExecutionRolePolicy をIAMロールに適用することでECSタスク実行ロールを設定することもできます。今回は AmazonECSTaskExecutionRolePolicy で定義されている権限に加えて、Systems Manager Parameter Storeにアクセスするための権限も付与しています。下記の内容でIAMロールを作成します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetParameters",
"ecr:GetAuthorizationToken",
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}
ECS環境の設定
ECSコンテナを動作させるための環境が整いましたので、次にコンテナ側の設定を実施していきましょう。コンテナ側の設定の注意点としては、Systems Manager Parameter Storeを使用しないと、Private location Keyがタスク定義にべた書きとなってしまうため、Secure String形式でSystems Manager Parameter Storeを使用します。
Systems Manager Parameter Storeの設定
１．New Relicの管理画面にログインします。
２．Synthetic Monitoring > Private locations を開きます。
３．Create private locationをクリックします。
４．任意の名前を入力し、Generate keyをクリックします。
５．View Private Locationをクリックします。
６．edit private locaionをクリックします。
７．Private location keyをコピーし、テキストエディタなどに記録しておきます。
８．AWS環境に切り替え、Systems Manager Parameter Storeの画面を開き、パラメータの作成をクリックします。
９．名前に /newrelic/private_location_key と入力します。
１０．タイプに 安全な文字列 を選択します。
１１．値のところに項７でメモした Private location Key を入力します。
１２．パラメータを作成をクリックします。
Systems Manager Parameter Storeの設定は以上ですが、後ほど作成したパラメータのARNと名前を使用しますので、テキストエディタなどにメモしておきます。
ECSクラスタの設定
１． Amazon Elastic Container Serviceの画面を開き、クラスターの作成をクリックします。
２． クラスター名の欄にCloudformationの設定画面で入力したクラスタ名を入力します。
３． そのまま作成ボタンをクリックします。
数分程度待つと、新規作成したクラスタ名が一覧に表示されます。作成されたクラスタを開くとEC2環境の設定で作成したコンテナ起動用インスタンスが表示されているのが確認できます。
ECSタスクの設定
１．Amazon Elastic Container Service > タスク定義 を開き、JSONを使用した新しいタスク定義の作成をクリックする。
２．中身を全部削除して下記のものに置き換える。置き換える際に「
{
"family": "newrelic-synthetics-job-manager",
"containerDefinitions": [
{
"name": "newrelic-synthetics-job-manager",
"image": "newrelic/synthetics-job-manager",
"cpu": 512,
"memory": 1024,
"portMappings": [
{
"containerPort": 8080,
"hostPort": 8080,
"protocol": "tcp"
},
{
"containerPort": 8180,
"hostPort": 8180,
"protocol": "tcp"
}
],
"essential": true,
"environment": [],
"mountPoints": [
{
"sourceVolume": "docker-sock",
"containerPath": "/var/run/docker.sock",
"readOnly": false
}
],
"volumesFrom": [],
"secrets": [
{
"name": "PRIVATE_LOCATION_KEY",
"valueFrom": "<Systems Manager Parameter Storeのarnをここに設定>"
}
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/newrelic-synthetics-job-manager",
"awslogs-region": "ap-northeast-1",
"awslogs-stream-prefix": "ecs"
}
},
"systemControls": []
}
],
"executionRoleArn": "<タスク実行ロールとして作成したIAMロールのarnをここに設定>",
"networkMode": "bridge",
"volumes": [
{
"name": "docker-sock",
"host": {
"sourcePath": "/var/run/docker.sock"
}
}
],
"placementConstraints": [
{
"type": "memberOf",
"expression": "attribute:ecs.availability-zone in [ap-northeast-1c]"
}
],
"requiresCompatibilities": [
"EC2"
]
}
３．Amazon Elastic Container Service > クラスターを開き、ECSクラスタの設定で作成したクラスタを開きます。
４．サービスタグの中の作成をクリックします。
５．コンピューティング設定のコンピューティングオプションは、起動タイプを選択します。起動タイプは、EC2を選択します。
６．アプリケーションタイプはサービスを選択します。
７．ファミリーはタスク定義名「newrelic-synthetics-job-manager」を選択します。
８．サービス名は任意の名前を設定します。
９．サービスタイプはデーモンを選択します。
１０．必要なタスクはデフォルトのままとします。
１１．下記は必要に応じて設定しますが、今回は設定しません。作成ボタンをクリックしてサービスを作成します。
１２．設定に問題がない場合は、下記のようにサービスが自動的にデプロイされて起動します。
サービスと同様にタスクも下記のように起動します。
New Relicの画面でもMinionの数が１と表示され、起動しているMinionがレポートされます。
New Relic側の設定
１．New Relicの管理画面にログインし、Synthetic Monitiring > Monitorから Create monitorをクリックします。
２．Availability Pingを選択します。
※今回はPingを選択していますが、Ping以外でもPublic Minionと同様に監視することができます。
３．任意の名前と監視対象を入力します。今回はプライベート環境の監視ということで同じプライベート環境にあるインスタンスを監視してみます。
４．Private locationsに表示されている監視元Private Minionを選択し、Save Monitorをクリックします。
５．ResultやSummaryの画面から監視状況が確認できます。なお、最初にいくつかFAILEDとなっているのは、監視先サーバのnginxの起動を忘れていたという凡ミスの影響です（汗
まとめ
New Relicを使用してプライベート環境にあるWebサーバの死活監視をしてみました。プライベートロケーション監視のためのPrivate Minionの構築は若干クセが強めとなっていますが、ECSやEKSのようなコンテナ環境でも動作できますし、EC2にdockerをインストールして実行することもできますので、もしプライベート環境のURL監視をおこないたいとお考えの場合はお試しいただければと思います。
どなたかのお役に立てれば幸いでございます。
関連記事
宣伝
弊社では、お客様環境のオブザーバビリティを加速するためのNew Relic導入支援サービスなどもご提供しております。 もしご興味をお持ちの方は、こちらのサービスご紹介ページの一番下にあるお問合せフォームよりお問合せ頂けましたら幸いでございます。
