プライベートロケーションの機能

プライベートロケーションは、完全に管理下のインフラストラクチャ上で実行されます：

• プライベートロケーションには、任意の数のSJMを含めることができます。UIでモニターをロケーションに割り当てると、SJMがジョブをプルし、結果をNew Relicに報告します。

• SJMは、単一のイメージ（newrelic/synthetics-job-manager）からDocker、Podman、Kubernetes、およびOpenShift上で実行されます。

• チェックごとのサンドボックス化：スクリプト化されたチェックまたはブラウザチェックごとに、SJMは新しいランタイムコンテナまたはポッドを起動してから破棄し、実行を互いに分離します。

• SJMが管理するランタイム：

  • synthetics-ping-runtime — pingモニター（軽量）
  • synthetics-node-api-runtime — スクリプト化されたAPI、リンク切れ、証明書チェック
  • synthetics-node-browser-runtime — シンプルおよびスクリプト化ブラウザモニター（Chrome）

• アウトバウンドのみ: SJMはHordeエンドポイント（UShttps://synthetics-horde.nr-data.net/、EUhttps://synthetics-horde.eu01.nr-data.net/、JPhttps://synthetics-horde.jp.nr-data.net/）に到達する必要があります。以下との接続をテストします：

  bash

  コピー

  $
  curl -X GET https://synthetics-horde.nr-data.net/synthetics/api/v1/ping

  設定については、プライベートロケーションの概要およびジョブマネージャーのインストールを参照してください。

  ランタイムバージョンを制御できます。プライベートロケーションでは、ランタイムバージョンはSJMがデプロイするランタイムイメージによって完全に決定されます — DESIRED_RUNTIMES（DockerおよびPodman）またはsynthetics.desiredRuntimes（Kubernetes）を使用して設定します。Docker Hubから現在サポートされているランタイムイメージを実行するには、latestタグを使用します — これがプライベートロケーションの推奨セットアップです。アップグレードを採用する前に検証する必要がある場合は、代わりに特定の公開されたイメージタグを固定できます。いずれにせよ、イメージはSJMの起動時にプルされるため、変更を適用するにはSJMを再起動または再デプロイします。

  一般設定のBrowserおよびRuntimeバージョンのドロップダウンはプライベートロケーションには影響しません。また、SyntheticCheckのruntimeTypeVersionはプライベートジョブのランタイムを特定する信頼できる方法ではありません — 代わりにnr.runtimeVersionをクエリしてください。現在のランタイムは、Chrome 147以降を搭載したNode.js 22です。古いNode.js 16およびChrome 134のランタイムはサポートを終了しました。詳細については、ランタイムへの移行ガイドを参照してください。

SJMはマウントされた証明書を自動検出し、生成するすべてのランタイムに（読み取り専用で）伝播するため、カスタムランタイムイメージは必要ありません。

• フォーマット: PEM、.pem拡張子付き、UID 2000で読み取り可能。SJMはCA:TRUEの基本制約を持つ証明書のみをロードし、リーフ証明書を無視します。
• Docker: /var/lib/newrelic/synthetics/certsに読み取り専用でマウントします。
• Kubernetes: Secretを作成し、global.customCertificates.volume.secret.secretNameで参照します。

モニターは、スクリプトを変更することなく、ホスト名ごとに正しい証明書を自動的に提示します。

• ホスト名をPEM証明書/キーファイルにマッピングするcert-map.jsonを指定します（一致の優先順位：完全一致 → ワイルドカード*.domain.com → default → 証明書なし）。

• Docker:クライアント証明書ディレクトリを/var/lib/newrelic/synthetics/client-certに読み取り専用でマウントします。

• Kubernetes: cert-map.jsonと証明書/キーファイルを含むSecret（Kubernetesリソースタイプ）を作成し、global.clientCertificates.volume.secret.secretNameで参照します。

• mTLSは相互であるため、モニターもサーバーを信頼する必要があります。エンドポイントの証明書がプライベートCAによって発行されている場合は、そのCAをカスタムCA証明書としてマウントします（Docker:/var/lib/newrelic/synthetics/certs、Kubernetes:global.customCertificates.volume.secret.secretName）。

• ランタイム内のDNS経由でmTLSホスト名を解決できない場合は、カスタムホスト名でマッピングします。

  証明書サポートの制限事項

  カスタムCAおよびmTLS証明書は、スクリプト化APIおよびスクリプト化ブラウザモニターにのみ適用されます（pingモニターは影響を受けません）。証明書はコンテナの起動時に読み込まれるため、証明書を追加、削除、またはローテーションした後は、ジョブマネージャー（またはKubernetes上のランタイムポッド）を再起動してください。mTLSの場合、各クライアント証明書には一意のSubject CNが必要です — Chromeはこれを使用して、ホスト名ごとに正しい証明書を自動選択します。

SJMはデフォルトでrootとして実行されます（実行はサンドボックス化されているため安全です）が、非rootユーザーとしての実行もサポートしています。

• Docker: ユーザーはdockerグループに属している（またはDOCKER_HOST経由でDocker TCPソケットを使用する）必要があり、マウントされたボリュームへの読み取り/書き込みアクセス権を持っている必要があります。その後、-u UID:GIDで実行します。
• ランタイムコンテナは常にUID 2000として実行されます。
• Kubernetesは、runAsUser、runAsNonRoot、およびfsGroupに対してpodSecurityContext Helm値を公開します。Podmanは完全なルートレスモデルをサポートしています。

ロケーションにスクリプトを割り当てたり、SJMを追加したりする前に、パスフレーズを設定する必要があります。VSEはスクリプト化されたモニターにのみ適用されることに注意してください。スクリプト化されていないモニター（単純なpingなど）は、パスフレーズの入力が免除されます。

• VSE_PASSPHRASE（Docker/Podman）またはsynthetics.vsePassphrase/synthetics.vsePassphraseSecretName（Kubernetes）を使用してパスフレーズを設定し、ロケーションの編集メニューでVSEを有効にして、各モニターのパスフレーズを入力します。

  注意

  New RelicはVSEパスフレーズを保存することはなく、誰も — New Relicサポートを含め — それを復元することはできません。紛失した場合は、SJMでリセットし、そのロケーションに割り当てられているすべてのモニターを再認証する必要があります。

共有はロケーションごとに制御されるため、どのアカウントがインフラストラクチャにジョブを送信できるかを決定できます。

• sharedをtrueに設定すると、組織内のすべてのアカウントでロケーションを使用できるようになります。
• 親アカウントで作成されたロケーションは、その子アカウントで使用できます。子アカウントで作成されたロケーションは、そのアカウントに対してプライベートなままになります。
• 他のアカウントのモニターがまだ使用している間は、ロケーションの共有を解除できません — まずそれらのモニターを移行してください。

$secure.MY_KEYを使用して、スクリプト内の保存されたシークレットを参照します。

• 保存時にAES-GCM 256ビット暗号化を使用し、AWS Key Management Service (KMS)がキーを管理します。値を読み戻すことはできません — 参照することのみ可能です。

• New Relicは、すべての結果とアラート（パーセントエンコードされた形式を含む）から値をスクラブし、それらを_SECURECREDENTIAL_に置き換えます。

• スクリプトブラウザ、API、およびステップモニターで利用できます。1アカウントあたりの認証情報の制限は1,000個です。管理者は、作成、表示、削除、および使用の権限を制御します。

  重要

  プライベートロケーションで実行されているモニターが侵害された場合は、そのセキュアな認証情報をローテーションし、プライベートロケーションキーをローテーションします。

外形監視がFedRAMPプログラムにどのように適合するかは以下のとおりです：

• New RelicはFedRAMP認定（Moderate）を受けており、外形監視はその対象範囲内です — 対象外のサービスリストには含まれていません。
• 個別のgov-外形監視Hordeエンドポイントはありません。New Relicのエンドポイントルールに従い、エンドポイントが個別にリストされておらず、スコープ外でもないサービスは、標準エンドポイントでFedRAMP要件を満たします。FedRAMPアカウントのプライベートロケーションSJMは、標準のHordeエンドポイントを使用します。
• 顧客の義務には、New Relicが承認したアカウント、Data Plusを備えたエンタープライズエディション（または承認された代替手段）、FedRAMP指定のエンドポイントに設定されたエージェントとサービス、およびFedRAMP認定機能のみの使用が含まれます。FedRAMPは子アカウントに継承されます。

製品内にトグルはありません — SJMはホストまたはクラスタネットワークからデュアルスタック機能を継承し、最小イメージバージョンによって制限されます：

• ジョブマネージャー519以降、pingランタイム1.65.0以降、および現在のNode APIとブラウザランタイムイメージ — latestタグを使用します。
• Docker: ホストとDockerデーモンでIPv6が有効になっている必要があります。
• Kubernetes: クラスタは、デュアルスタックが有効になっているv1.20以降である必要があります。

ジョブマネージャーで以下の変数を設定します：

• Docker/Podman: HORDE_API_PROXY_HOST、HORDE_API_PROXY_PORT、HORDE_API_PROXY_USERNAME、HORDE_API_PROXY_PW、およびHORDE_API_PROXY_ACCEPT_SELF_SIGNED_CERT。

• Kubernetes: synthetics.apiProxyHost、synthetics.apiProxyPort、synthetics.hordeApiProxyUsername、synthetics.hordeApiProxyPw、およびsynthetics.hordeApiProxySelfSignedCert。

  ヒント

  これらの変数は、SJMからNew Relicへのトラフィックを制御します。任意のモニターからターゲットへのトラフィックに対する、文書化された汎用プロキシ変数はありません。

Dockerデプロイメントでは、ジョブマネージャーでRUNTIME_EXTRA_HOSTSを設定すると、生成されるすべてのランタイムコンテナにマッピングが渡されるため、スクリプトはアプリケーションと同じホスト名を使用できます。

• フォーマット:カンマ区切りのhostname:ipペア、たとえばapi.internal.example.com:10.0.0.1,svc.internal:10.0.0.2。
• 内部名がランタイムから解決できない場合に便利です — これにはcert-map.jsonで参照されるmTLSターゲットも含まれます。

スクリプトAPIおよびブラウザモニターでrequire()と一緒に使用するために、独自のnpmパッケージ（ホスト型またはローカル）をバンドルします。

• ルートがpackage.jsonのディレクトリを指定すると、SJMは起動時にnpm installを実行します。
• /var/lib/newrelic/synthetics/modulesにマウントします（Docker/Podman、読み取り/書き込み）。Kubernetesでは、global.customNodeModules.customNodeModulesPathを介してPersistentVolume（ポッド間で共有する場合はReadWriteMany）を使用します。

$env.USER_DEFINED_VARIABLES.MY_VARIABLEを使用して、スクリプト内の挿入された値にアクセスします。USER_DEFINED_VARIABLES（JSON文字列）を設定するか、user_defined_variables.jsonファイルをマウントします。

プライベートロケーションは、監視負荷に合わせてスケーリングします：

• ジョブタイプ:ヘビーウェイトジョブ（シンプルおよびスクリプト化されたブラウザ、スクリプト化されたAPI）は、同時ジョブごとに約1つのCPUコアを使用します。軽量ジョブ（ping）は、それぞれフルコアではなくワーカースレッドプールで実行されます。
• SJMあたりのスループット: 設計上、1分あたり15個のヘビーウェイトジョブと1分あたり75個のpingチェックの制限があります。パフォーマンスに影響を与える要因の詳細については、ヘビーウェイトジョブ、pingジョブを参照してください
• スケールアウト（水平）: 同じプライベートロケーションキーを使用して、より多くのSJMをデプロイします。ジョブはそれらの間でロードバランシングされ、スループットは加算され、フェイルオーバーが得られます。
• スケールアップ（垂直）: ホストにCPUとメモリを追加するか、Helmチャートで各ランタイムのサイズを個別に設定します（APIおよびブラウザランタイムの場合はparallelism/completions、pingの場合はreplicaCount）。
• 健全性とオブザーバビリティ: 各SJMにはステータスインジケーターが表示されます。NRQLイベントSyntheticsPrivateLocationStatusおよびSyntheticsPrivateMinionはキューとリソースのメトリクスを公開し、New Relicは事前構築済みの"外形監視ジョブマネージャー"ダッシュボードを提供します。
• キュー管理:UIで滞留したキューをクリアするか、NerdGraphミューテーションsyntheticsPurgePrivateLocationQueueを使用してパージします。
• キーのローテーション: キーをインプレースでローテーションすることはできません。新しいロケーションを作成し、モニターをそこに移行し、新しいキーでSJMを再デプロイしてから、古いロケーションを削除します。モニターが使用したセキュアな認証情報をローテーションします。

プログラムでプライベートロケーションを作成および管理できます：

• NerdGraph API: syntheticsCreatePrivateLocation、syntheticsUpdatePrivateLocation、syntheticsPurgePrivateLocationQueue、およびsyntheticsDeletePrivateLocation、さらに安全な認証情報のミューテーション。ロケーションを作成すると、guidが返されます。
• Terraform: newrelic_synthetics_private_locationリソース（必須のnameとdescription；オプションのsharedとverified_script_execution）。SJMに提供するkeyをエクスポートするため、1つのパイプラインでロケーションをプロビジョニングし、ランタイムを接続できます。