Synthetics プライベートロケーションのセットアップ

本ブログでは、Synthetic Monitoring でのプライベートロケーションを用いた外形監視の利用方法についてご説明いたします。プライベートロケーションを未体験の方を対象にパブリックロケーションとの違いや選択可能な実装方法、設定時に注意することなどについてご紹介いたします。

本ブログは 2023/09 時点での機能をもとに記載しております。機能の更新・廃止および推奨値が変更している可能性がありますので、最新情報もご確認ください。

プライベートロケーションの概要

New Relic の外形監視サービスである Synthetic Monitoring には、New Relic が管理するパブリックロケーションから対象サイトにアクセスを行う方法とお客様環境からアクセスを行うプライベートロケーションの２種類のロケーションを選択することができます。

プライベートロケーションはお客様にて、外形監視の実行環境を構築いただくことで、監視の実行ロケーションとして、パブリックロケーションとともにご利用いただくことができます。実行環境は Kubernetes あるいは Docker コンテナ環境にて、Synthetic monitoring を実行するコンテナアプリケーションをインストールいただくことで、Synthetics UI を通じて設定されたジョブを受け取り、管理・実行されます。

プライベートロケーションを用いるとイントラネット環境にある Web サイトやアプリケーションまたはセキュリティの制約上 パブリックロケーションからのアクセスを許可できない場合でも、外形監視を実施することができます。

パブリックロケーションとの設定項目の違い

プライベートロケーションは、パブリックロケーションと同様にすべてのモニタータイプで、モニター試行を実行することができます。
ただし、実装方式によっては実行できないモニタータイプ (SSL証明書有効期限監視やリンク切れ検出、ステップモニター) や実行できるランタイムのバージョンが異なります。
単一の実装方式でプライベートロケーションを構築する場合、実行したいモニタータイプやランタイムバージョンが実行できるかを確認しておく必要があります。

各モニタータイプで設定可能な項目は、パブリックロケーションと同じ項目で設定が可能^*1で、パブリックロケーションとプライベートロケーションの両方をロケーションとして選択することも可能です。
UI 上では、ロケーションの選択画面で、自分で作成したロケーションも選択できるようになるという違いしかありません。付随するアラート設定やダッシュボードなどもパブリックロケーションと区別なく利用が可能です。

*1 プライベートロケーション独自の機能として Scripted Browser/API のコード変更時にパスワードに認証を設定できる VSE 機能がございます、詳細は後述。

VSE (Verified script execution) について

プライベートロケーションでは、Scripted browser および Scripted API において利用するスクリプトソースの変更時にパスワード認証を設定することができます。
他のメンバーが設定者のプライベートロケーションで、スクリプト付きのモニターを割り当てすることができないようにするためのセキュリティ機能です。
各プライベートロケーションごとにパスフレーズ、有効・無効を設定することができます。
Scripted browser や Scripted API タイプモニターにて実行ロケーションとして、VSE が有効なプライベートロケーションを選択している場合、スクリプトソースの変更時に、パスフレーズの入力を求められます。
(本ブログ執筆時点では、ジョブマネージャー方式のプライベートロケーションではサポートされておりません。最新の状況はドキュメントをご確認ください)

また、誤ったパスワードを入力してしまった場合は、モニター実行時に下記などのエラーが出力されます。

HMAC MISMATCH ERROR: HMAC mismatch between saved HMAC and calculated HMAC at job run time

HMAC MISMATCH ERROR: HMAC expected but missing from Job metadata

(HMACエラー)

プライベートロケーションの実行環境と実装方式

プライベートロケーションでの実装方式には、2022/09 にローンチされた Synthetics ジョブマネージャー (SJM) と従来のプライベートミニオン (コンテナ化プライベートミニオン: CPM) の 2つの方式があります。どちらも Docker コンテナベースのアプリケーションで、Synthetics UI 経由でセットアップされたジョブを受け取り、Synthetics のモニター試行を管理、実行します。

ネットワーク要件:

SJM/CPM どちらの方式でもジョブ情報を受信して処理するために、Syntheticモニタリング群のエンドポイントに接続できる必要があります。アウトバウンドルールとして、エンドポイントへのアクセスを許可されるよう設定ください。また、ファイアウォールのルールにより直接アクセスが許可されていないなどの場合は、プロキシアクセスを設定する必要があります。

サポートランタイムの違い:

SJM では、新しいランタイム (Chrome 100+, Node 16) に対応しており、逆に CPM では、レガシーランタイム (Chrome 72, Node 10) のみに対応しています。
ランタイムが選択できる Simple Browser、Scripted Brwoser、Scripted API で、採用するランタイムが決まっている場合は、SJM とするか CPM とするかを意識し、ロケーションの作成を行う必要があります。
また、SJM と CPM の両方方式の実行環境を同じプライベートロケーションで構成することも可能で、従来のランタイムのモニター試行は CPM で実行され、新しいランタムのモニター試行は SJM で実行されます。
また、同じホスト内で複数のロケーションコンテナーを実行すると、ポートの競合が発生してしまうため、各SJN、CPM は別ホストで稼働させるよう構築する必要があります。両方式に対応するロケーションを作成する場合、その分ホストが必要になります。

モニタータイプの違い:

SJM 方式では、レガシーランタイムに対応していないため、以下のモニタータイプは、実行することはできません。

• Certificate Check (SSL 証明書の有効期限チェック)
• Broken Links Monitor (リンク切れモニター)
• Step Monitor (ステップモニター)

CPM 方式では、すべてのモニタータイプのモニターを実行することができます。

実行環境:

SJM/CPM どちらの方式も Dockerコンテナシステム環境または Kubernetes コンテナオーケストレーションシステム環境で動作します。
それぞれのシステム要件を満たす実行環境が構築されている必要がありますので、構築前には必ずシステム要件を確認ください。

• Synthetics Job Manager (SJM)
  • Kubernetes コンテナオーケストレーション環境要件
  • Docker コンテナ環境要件
• Private Minion (Legacy) (CPM)
  • Kubernetes コンテナオーケストレーション環境要件
  • Docker コンテナ環境要件

また、SJM/CPM どちらの方式でも Docker コンテナ環境の場合は、AWS ECS、Docker Swarm、Apache Mesos、Azure Container Instances などのコンテナーオーケストレーターで使用するようには設計されておりません。コンテナオーケストーレーションを使用される場合は Kubernetes 環境での構築を検討ください。

メモリ使用量の推奨値:

CPU やメモリなどのリソースが不足しているとモニター試行が実行されない、Scripted Browser/API では、バリデーションが終了しないなど、正常に稼働しない状況が発生いたします。特に Scripted Browser/API  では ping モニターと比較するとリソース消費が大きくなるため、メモリが不足していると実行されないことがあります。初期構築時は下記の値などを参考に少し余裕をもって構築し、実行するモニターのリソース使用状況を確認したあとで、実行環境のリソース調整を実施する方がよろしいかと思います。
また、推奨値は更新されることがありますので、最新情報をご確認ください。

SJM および CPM のメモリ割り当ての推奨値。

• CPM
  • Docker
    • CPU コアあたり2.5Gi
  • Kubernetes
    • heavy worker (Scripted Browser/API モニター) あたり 3 Gi
    • healthcheck ポッド あたり 3 Gi
    • ミニオンポッドの場合 1.6 Gi
• SJM
  • Docker
    • CPU コアあたり 2.5 Gi
  • Kubernetes
    • ジョブ マネージャー ポッドの場合 1.6 Gi
    • ping ランタイム ポッドの場合 1.0 Gi
    • API ランタイム ポッドあたり 2 Gi
    • Browser ランタイム ポッドあたり 3 Gi

また、各ミニオンの物理メモリ使用量やジョブの実行状況は SyntheticsPrivateMinion を NRQL でクエリすることで確認することができます。

利用できるカスタマイズ:

CPM でできるカスタマイズ

• カスタム npm モジュール
  • 任意の npm モジュールのセットを導入することで、スクリプトモニターで利用でき、導入したモジュールを利用することができます
• データ保持
  • 通常 CPM はステートレスアプリケーションであるため、デフォルトでは以前のリクエストやセッション情報は保持しませんが
    永続的なデータストレージを有効にするカスタマイズを行うことで、起動間でデータの保持が可能となります
• ユーザー定義変数の利用
  • ユーザーが定義した変数を json 形式で起動時に環境変数として CPM に提供することができます

• 環境変数の利用
  • Docker 環境、Kubernetes 環境で利用できる環境変数を起動時に指定することで  CPM 構成の微調整が可能となります
    • タイムアウト
      デフォルト: ping モニターは 65秒、その他は 180秒 で動作するモニターのタイムアウト値を 1~900秒の間で変更ができます
    • プロキシ設定
      プロキシを介して NewRelic との通信を行う場合、プロキシホスト・ポート・ユーザー・パスワードなどを設定できます
    • 同時実行ワーカー数
      heavy モニター (Scripted browser/API モニター) 用の設定値や lightweight モニター (ping, simple モニター) 用の実行数をそれぞれ指定することができます
    • ログレベル
      デフォルトでは INFO レベルの出力ですが、DEBUG や TRACE などより詳細なログを出力を制御できます
    • など

SJM でできるカスタマイズ

• 環境変数の利用
  • Docker 環境、Kubernetes 環境で利用できる環境変数を起動時に指定することで  SJM 構成の微調整が可能となります
    • タイムアウト
      デフォルト: ping モニターは 65秒、その他は 180秒 で動作するモニターのタイムアウト値を 1~900秒の間で変更ができます
    • プロキシ設定
      プロキシを介して NewRelic との通信を行う場合、プロキシホスト・ポート・ユーザー・パスワードなどを設定できます
    • ログレベル
      デフォルトでは INFO レベルの出力ですが、DEBUG や TRACE などより詳細なログを出力を制御できます
    • など

• サイジング (Kubernetes)
  • helm chart を介してパラメータの調整することで、各ランタイムのサイズを調整することができます
    • ping モニターは ping-runtime.replicaCount にて調整できます
    • Scripted Browser や API などのランタイムは、parallelism と completions によって、調整が可能となります
    • パフォーマンスの調査方法や調整例はドキュメントを参照
  • 同一プライベートロケーションに複数の SJM が存在する場合は、ジョブの負荷を分散することができます

プライベートロケーションの作成〜実行

Kubernetes または Docker コンテナの実行環境の構築後、プライベートロケーションを作成します。

ロケーションの作成からモニターの実行までは、下記の 2ステップです。

1.  UI 操作でロケーションを作成
   • ロケーション名、説明、VSE の有効・無効を入力
   • プライベートロケーションキーが作成されます
2.  実行環境で、SJM または CPM をデプロイ
   • SJM/CPM を選択すると Kubernetes/Docker それぞれのデプロイコマンドがプライベートキー付きで出力されます
   • デプロイコマンドを実行環境で実行し、インストール、アプリケーションを起動します

デプロイ後に UI にて 作成したプライベートロケーションを実行ロケーションとして設定したモニターを実行すると、プライベートロケーションからモニターが実行されるようになります。

プライベートロケーションの作成

UI より “Synthetic Monitoring” > “Private Locations” と進み、右上の “Create private location” から作成を開始します。

PRIVATE LOCATION NAME (ロケーション名) と DESCRIPTION (説明) を入力します (VSE を有効にする場合は、チェックをつけます)。
”Generate key” ボタンを押下すると、ロケーションキーが作成されます。
(この操作で UI 上は、プライベートロケーションが作成されます。後続操作が不要な場合や、やり直しがしたい場合は UI 上から削除や編集が可能です)

次の画面では、導入する SJM または CPM のデプロイコマンドがロケーションキーが追加された形で４種類表示されます。
SMJ (Kubernetes, Docker)、CPM (Kubernetes, Docker) 。

Docker コンテナの場合

表示されたコマンドを実行するとデプロイが開始されます。CPM の Docker イメージを取得し、コンテナが起動します。

• CPM
  
  docker run -e MINION_PRIVATE_LOCATION_KEY=NRSP-********  -d --restart unless-stopped -v /tmp:/tmp:rw -v /var/run/docker.sock:/var/run/docker.sock:rw quay.io/newrelic/synthetics-minion:latest
   
• SJM
  
  docker run -e PRIVATE_LOCATION_KEY=NRSP-******** -d --restart unless-stopped -v /var/run/docker.sock:/var/run/docker.sock:rw newrelic/synthetics-job-manager

カスタマイズとして、ユーザー定義変数や環境変数を設定する場合は、オプションを docker run コマンドに追記して、起動させます。
また、CPM で VSE やデータ保持を利用する場合は、同様にオプションを docker run コマンドに追記して、起動させます。

ミニオンコンテナのログにて、実行準備が完了した旨の出力があれば、デプロイ完了です (スペックにもよりますが、数分程度かかります)。

Kuberbetes の場合

名前空間が未設定の場合は、表示されたコマンドの実行前に名前空間を設定し、その後に表示されたコマンドを実行します。
また、コマンド内に記載されたロケーションキー以外の大文字部分は、ご自身で設定いただく名前です。
(具体的には、YOUR_REPO_NAME、YOUR_CPM_NAME YOUR_REPO_NAME、YOUR_JOB_MANAGER_NAME  が該当します)

• CPM/SJM
  
  kubectl create namespace YOUR_NAMESPACE
  
  (YOUR_NAMESPACE は、ご自身で設定いただきます)
• CPM
  
  helm repo add YOUR_REPO_NAME https://helm-charts.newrelic.com

helm install YOUR_CPM_NAME YOUR_REPO_NAME/synthetics-minion -n YOUR_NAMESPACE --set synthetics.privateLocationKey=NRSP-******** 
  
  (表示コマンド内の大文字で書かれた YOUR_REPO_NAME、YOUR_CPM_NAME はご自身で設定いただく名前です。YOUR_NAMESPACE は、作成いただいた名前空間名です。)
• SJM
  
  helm repo add YOUR_REPO_NAME https://helm-charts.newrelic.com

helm install YOUR_JOB_MANAGER_NAME YOUR_REPO_NAME/synthetics-job-manager -n YOUR_NAMESPACE --set synthetics.privateLocationKey=NRSP-********  
  
  (表示コマンド内の大文字で書かれた YOUR_REPO_NAME、YOUR_JOB_MANAGER_NAME はご自身で設定いただく名前です。YOUR_NAMESPACE は、作成いただいた名前空間名です。)

ポッド情報を取得し status にて、起動を確認します  (スペックにもよりますが、数分程度かかる場合がございます)。

デプロイ後に、UI ウィザードの "View Private Location" ボタンにて、作成したプライベートロケーションページに遷移します。
ミニオンまたはポッドが起動すると、プライベートロケーションと通信し始めると、ミニオンの情報が表示されます。

UI にて モニターを新作成または既存のロケーションの編集を行い、作成したプライベートロケーションを実行ロケーションに設定したモニターを作成すると、作成したプライベートロケーションでモニター試行が実行されるようになります。

プライベートロケーションの管理

作成したプライベートロケーションの状況は、SyntheticsPrivateLocationStatus イベントをクエリすることで確認することができます。
実行状況を確認できる項目として checkPending  (実行予約キュー) がよく用いられます、これはスケジュールされたモニターのうちでまだ実行されていないキューの数を示します。
実行対象のモニター数に対してコンピュータリソースが足りない場合や実行環境に障害が発生するとキューが捌けずに滞留してしまうことがあります。
この値を定期的にウォッチすることで、スケジュール通りにモニターが行えているかを確認することができます。

SELECT average(checksPending) FROM SyntheticsPrivateLocationStatus WHERE name = 'YOUR_LOCATION_ID' TIMESERIES

ジョブクリア操作

未実行キューの滞留は、リソースが足りない状況だけでなく、設定ミスなどでも増加します。
下記は間違ったモニター設定をしてしまった際の例です。
具体的には、CPM のみが稼働するプライベートロケーションにて、Scripted Browser の Chrome100+ (新しいランタイム) でモニター実行を登録してしまった場合です。

対象ランタイムは、サポートしていないので実行されることはありません。
しかし、指定したポーリングのたびに実行予約が行われるため、未実行キュー (CheckPending) の値は直線的に増加します。

滞留が開始された時刻などに着目して、モニターの設定の間違いに気がつき、モニター設定を修正または停止などの対応を行います。
しかし、修正・停止などを行ったとしても未実行キューは増加しなくなるだけで、無くなりはしません。
このような場合は、該当プライベートロケーションのキューのクリア操作を行う必要があります。

キューのクリアは、UI のプライバシーロケーションのページから実行することができます。

キューのクリア後は、停滞していたキューは削除されます。その後に増加することがないことを確認します。

実行待ちキューが増加しているという状況は、該当プライベートロケーションでのモニター実行がスケジュール通りに行われていないことを示します。
実行されていないモニターがある場合は設定ミスやロケーション障害の可能性やリソース不足などの可能性がありますので、対応を行なって解消する必要があります。
プライベートロケーションの障害だった場合、登録していた Synthetics のモニターが実行できていないという状況となるので、監視対象である Web 側の障害や不具合の検知に影響がでてしまう可能性もあります。

プライベートロケーションの監視

checkPending の推移にはアラートを設定し、監視することを推奨します。ロケーションの障害時だけでなく、ロケーションのリソース不足や設定ミスあるいは一般的な誤動作があった場合にも気がつくことができます。
また特定の項目のアラート設定だけでなく、プライベートロケーション用のプレビルドダッシュボードなどを導入することで、スムーズに状況を確認、分析できるようにもなります。

Add Data から “Synthetics Private Minions” ダッシュボードを追加します。

(ダッシュボードを追加して、実行予約キューが溜まっているプライベートロケーションが存在することに気がつきました。)

まとめ

Synthetics のプライベートロケーションのセットアップ方法や注意点について、ご紹介いたしました。
ジョブマネージャー方式とプライベートミニオン方式、または Kubernetes 環境と Docker コンテナ環境と4種類の方式がある点やそれぞれの方式でのでること・できないことがある点にご注意ください。本内容やドキュメントなどを参考にぜひ Synthetics プライベートロケーションの作成をお試しください。