Synthetics ジョブ マネージャーの構成

変数は、起動時に-e, --env引数を使用して提供されます。

次の表は、synthetics ジョブ マネージャーがサポートするすべての環境変数を示しています。PRIVATE_LOCATION_KEYは必須で、その他の変数はすべてオプションです。

変数は、起動時に-e, --env引数を使用して提供されます。

次の表には、外形監視ジョブ マネージャーがサポートするすべての環境変数が表示されます。 PRIVATE_LOCATION_KEYは必須ですが、その他の変数はオプションです。Podman 環境で外形監視ジョブ マネージャーを実行するには、最小バージョンがリリース 418 以上である必要があります。

変数は、起動時に--set引数を使用して提供されます。

次のリストは、synthetics ジョブ マネージャーがサポートするすべての環境変数を示しています。synthetics.privateLocationKeyは必須で、その他の変数はすべてオプションです。

多数の追加の高度な設定が利用可能であり、Helm チャートの READMEに完全に記載されています。

変数は、起動時に--set引数を使用して提供されます。

次のリストは、synthetics ジョブ マネージャーがサポートするすべての環境変数を示しています。synthetics.privateLocationKeyは必須で、その他の変数はすべてオプションです。

多数の追加の高度な設定が利用可能であり、Helm チャートの READMEに完全に記載されています。

ユーザーは JSON 形式のファイルを作成し、そのファイルが配置されているボリュームを SJM コンテナ内の指定されたターゲット パスにマウントできます。

ファイルには読み取り権限が必要であり、JSON 形式のマップが含まれている必要があります。 ユーザー定義変数ファイルの例:

{
  "KEY": "VALUE",
  "user_name": "MINION",
  "my_password": "PASSW0RD123",
  "my_URL": "https://newrelic.com/",
  "ETC": "ETC"
}

ファイルをホスト上のソース ディレクトリに配置します。 SJM은 파일 이름이 user_define_variables.json이 될 것으로 예상합니다.

Dockerの例です。

想定されるターゲット ディレクトリは次のとおりです。 /var/lib/newrelic/synthetics/variables/

$
docker run ... -v /variables:/var/lib/newrelic/synthetics/variables:rw ...

Podmanの例:

SELinux の場合は、ボリュームを:zまたは:Zで追加でマウントします。詳細については、 Podman のドキュメントを参照してください。想定されるターゲット ディレクトリは次のとおりです。 /var/lib/newrelic/synthetics/variables/

$
podman run ... -v /variables:/var/lib/newrelic/synthetics/variables:rw,z ...

Kubernetesの例。

Kubernetes の SJM ポッドにファイルを提供する場合、ユーザーには 2 つのオプションがあります。 以下の可能性があります:

• ローカルファイルを渡します。
• user_defined_variables.jsonを含む PersistentVolume を提供します。

ローカルファイルを渡す

このオプションは、ConfigMap Kubernetes リソースを作成し、それを SJM ポッドにマウントします。

$
helm install newrelic/synthetics-job-manager ... --set-file "synthetics.userDefinedVariables.userDefinedFile=[local-path]/user_defined_variables.json" ...

マウント PersistentVolume

このオプションでは、ユーザーはuser_defined_variables.jsonファイルを含むPersistentVolumeまたは同じファイルに対するPersistentVolumeClaim指定する必要があります。PersistentVolumeを使用した helm chart インストレーションの詳細については、 永続的なデータ ストレージの手順に従ってください。

ユーザーが下記の説明に従ってPersistentVolumeを準備したら、SJM をリリースし、 user_defined_variables.jsonファイルが配置されているパスを設定し、必要に応じてその他のsynthetics.persistence変数を設定します。

$
helm install newrelic/synthetics-job-manger ... --set synthetics.userDefinedVariables.userDefinedPath="variables"

変数は環境変数を介してそれぞれのコンテナ システムに渡される場合があります。

Dockerの例です。

-eフラグを使用して、 USER_DEFINED_VARIABLESという名前の環境変数を設定し、JSON 形式のマップ文字列の値を指定します。

$
docker run ... -e USER_DEFINED_VARIABLES='{"key":"value","name":"sjm"}' ...

Podmanの例:

-eフラグを使用して、 USER_DEFINED_VARIABLESという名前の環境変数を設定し、JSON 形式のマップ文字列の値を指定します。

$
podman run ... -e USER_DEFINED_VARIABLES='{"key":"value","name":"sjm"}' ...

Kubernetesの例。

JSON 形式の文字列を渡すには、 --set-literalフラグを使用します。

$
helm install newrelic/synthetics-job-manager ... --set-literal synthetics.userDefinedVariables.userDefinedJson='{"key":"value","name":"sjm"}' ...

dockerの場合、リリース SJM はディレクトリを /var/lib/newrelic/synthetics/modules にマウントします。 例えば：

$
docker run ... -v /example-custom-modules-dir:/var/lib/newrelic/synthetics/modules:rw ...

podman の場合は、SJM をリリースして/var/lib/newrelic/synthetics/modulesにディレクトリをマウントします。 SELinux の場合は、 :zまたは:Zを使用してボリュームを追加でマウントします。詳細については、 Podman のドキュメントを参照してください。例えば：

$
podman run ... -v /example-custom-modules-dir:/var/lib/newrelic/synthetics/modules:rw,z ...

Kubernetes の場合、カスタム モジュールを有効にして SJM を起動する前に、 /var/lib/newrelic/synthetics/modulesのディレクトリが PV 上に存在している必要があります。

1 つの方法は、カスタム モジュール ディレクトリを PV にコピーするためだけに PV をマウントするポッドを作成することです。次の例では、Amazon EKS と Amazon EFS を使用します。

ネームスペース、永続ボリューム、および永続ボリューム要求を作成する

1. EFS ファイルシステムがすでにセットアップされており、クラスターにEFS CSI ドライバーがインストールされていることを確認してください。PV のspec.csi.volumeHandleの EFS ファイルシステム ID も必要になります。

   bash

   コピー

   $
   kubectl apply -f - <<EOF
   $
   apiVersion: v1
   $
   kind: Namespace
   $
   metadata:
   $
     name: newrelic
   $
   
   $
   ---
   $
   kind: StorageClass
   $
   apiVersion: storage.k8s.io/v1
   $
   metadata:
   $
     name: efs-sc
   $
   provisioner: efs.csi.aws.com
   $
   
   $
   ---
   $
   apiVersion: v1
   $
   kind: PersistentVolume
   $
   metadata:
   $
     name: custom-modules-pvc
   $
   spec:
   $
     capacity:
   $
       storage: 5Gi
   $
     volumeMode: Filesystem
   $
     accessModes:
   $
       - ReadWriteMany
   $
     persistentVolumeReclaimPolicy: Retain
   $
     storageClassName: efs-sc
   $
     csi:
   $
       driver: efs.csi.aws.com
   $
       volumeHandle: <your-efs-filesystem-id>
   $
   
   $
   ---
   $
   apiVersion: v1
   $
   kind: PersistentVolumeClaim
   $
   metadata:
   $
     name: custom-modules-pvc
   $
     namespace: newrelic
   $
   spec:
   $
     accessModes:
   $
       - ReadWriteMany
   $
     storageClassName: efs-sc
   $
     resources:
   $
       requests:
   $
         storage: 5Gi
   $
   EOF

2. ~/.kube/configのnewrelicネームスペースに切り替えます。

   bash

   コピー

   $
   kubectl config get-contexts
   $
   kubectl config set-context YOUR_CONTEXT --namespace=newrelic
   $
   kubectl config view --minify | grep namespace:

3. この時点で、PVC は RWX アクセス モードで PV にバインドされる必要があります。

   bash

   コピー

   $
   kubectl get pv,pvc
   NAME                                  CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                         STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
   persistentvolume/custom-modules-pvc   5Gi        RWX            Retain           Bound    newrelic/custom-modules-pvc   efs-sc         <unset>                          4m46s
   NAME                                       STATUS   VOLUME               CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
   persistentvolumeclaim/custom-modules-pvc   Bound    custom-modules-pvc   5Gi        RWX            efs-sc         <unset>                 4m10s

   カスタムモジュールディレクトリをコピーするには、 mount-custom-mods-pod作成します。

   bash

   コピー

   $
   kubectl apply -f - <<EOF
   $
   apiVersion: v1
   $
   kind: Pod
   $
   metadata:
   $
     name: mount-custom-mods-pod
   $
   spec:
   $
     containers:
   $
     - name: mount-custom-mods-pod
   $
       image: nginx
   $
       resources:
   $
         requests:
   $
           memory: "64Mi"
   $
           cpu: "250m"
   $
         limits:
   $
           memory: "128Mi"
   $
           cpu: "500m"
   $
       volumeMounts:
   $
         - mountPath: "/var/lib/newrelic/synthetics/modules"
   $
           name: custom-modules-storage
   $
     volumes:
   $
     - name: custom-modules-storage
   $
       persistentVolumeClaim:
   $
         claimName: custom-modules-pvc
   $
   EOF

   この時点で、ボリュームを使用するためにmount-custom-mods-podが作成され、構成される必要があります。

   bash

   コピー

   $
   kubectl describe po mount-custom-mods-pod | grep -A4 Volumes:
   Volumes:
     custom-modules-storage:
       Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
       ClaimName:  custom-modules-pvc
       ReadOnly:   false

   PV、PVC、またはmount-custom-mods-podに関連する警告がないかイベントを確認します。

   bash

   コピー

   $
   kubectl get events --field-selector type=Warning --sort-by='.lastTimestamp'

   カスタムモジュールディレクトリをPVにコピーします

   node_modules npm installの SJM によって生成されるため、コピーする必要はありません。

   bash

   コピー

   $
   cd custom-modules
   $
   rm -rf node_modules && cd ..

4. mount-custom-mods-podが実行中であることを確認してください。

   bash

   コピー

   $
   kubectl get po
   NAME                    READY   STATUS    RESTARTS   AGE
   mount-custom-mods-pod   1/1     Running   0          5m43s

5. PVにコピーします。

   bash

   コピー

   $
   kubectl cp custom-modules newrelic/mount-custom-mods-pod:/var/lib/newrelic/synthetics/modules

6. PV に/var/lib/newrelic/synthetics/modules/custom-modules/package.jsonが存在することを確認してください。

   bash

   コピー

   $
   kubectl exec -it mount-custom-mods-pod -- bash
   root@mount-custom-mods-pod:/# cd /var/lib/newrelic/synthetics/modules/
   root@mount-custom-mods-pod:/var/lib/newrelic/synthetics/modules# ls -l
   total 4
   drwxr-xr-x 2 root root 6144 Jun 29 03:49 custom-modules
   root@mount-custom-mods-pod:/var/lib/newrelic/synthetics/modules# ls -l custom-modules/
   total 4
   -rw-r--r-- 1 501 staff 299 Jun 29 03:49 package.json

   カスタムモジュール機能を有効にしたSJMをリリース

   インストレーション中に、コマンドラインまたは YAML ファイルでpersistence.existingClaimNameとcustomNodeModules.customNodeModulesPathの値を設定します。 customNodeModules.customNodeModulesPath値には、カスタム モジュール ファイルが存在する永続ボリューム上のサブパスを指定する必要があります。例えば：

   bash

   コピー

   $
   helm upgrade --install synthetics-job-manager newrelic/synthetics-job-manager -n newrelic --set global.persistence.existingClaimName=custom-modules-pvc --set global.customNodeModules.customNodeModulesPath=custom-modules --set synthetics.privateLocationKey=YOUR_PRIVATE_LOCATION_KEY
   Release "synthetics-job-manager" does not exist. Installing it now.
   NAME: synthetics-job-manager
   LAST DEPLOYED: Fri Jun 28 16:53:28 2024
   NAMESPACE: newrelic
   STATUS: deployed
   REVISION: 1
   TEST SUITE: None

   custom-modulesディレクトリには、 node_modulesにインストールされたパッケージが含まれるようになりました。

   bash

   コピー

   $
   kubectl exec -it mount-custom-mods-pod -- bash
   root@mount-custom-mods-pod:/# cd /var/lib/newrelic/synthetics/modules/
   root@mount-custom-mods-pod:/var/lib/newrelic/synthetics/modules# ls -l custom-modules/
   total 16
   -rw-r--r--  1 root root   836 Jun 29 03:51 README
   drwxr-xr-x 18 root root  6144 Jun 29 03:51 node_modules
   -rw-r--r--  1  501 staff  299 Jun 29 03:49 package.json
   -rw-r--r--  1 root root   190 Jun 29 03:51 package.json.shasum

   カスタム ノード モジュールが検出されない場合は、 custom-modulesディレクトリとpackage.jsonファイルの権限を調整します。

   bash

   コピー

   $
   kubectl exec -it mount-custom-mods-pod -- bash
   root@mount-custom-mods-pod:/# cd /var/lib/newrelic/synthetics/modules/
   root@mount-custom-mods-pod:/var/lib/newrelic/synthetics/modules# chmod -R 777 custom-modules
   root@mount-custom-mods-pod:/var/lib/newrelic/synthetics/modules# chown -R 2000:2000 custom-modules

Dockerに恒久的なデータ保存を設定するには

1. ジョブ マネージャーを起動するホスト上にディレクトリを作成します。 これがソース ディレクトリです。

2. ジョブ マネージャーをリリースし、ソース ディレクトリをターゲット ディレクトリ/var/lib/newrelic/syntheticsにマウントします。

   例：

   bash

   コピー

   $
   docker run ... -v /sjm-volume:/var/lib/newrelic/synthetics:rw ...

Podman で永続的なデータ ストレージを設定するには:

1. ジョブ マネージャーを起動するホスト上にディレクトリを作成します。 これがソース ディレクトリです。

2. ジョブ マネージャーをリリースし、ソース ディレクトリをターゲット ディレクトリ/var/lib/newrelic/syntheticsにマウントします。

   例：

   bash

   コピー

   $
   podman run ... -v /sjm-volume:/var/lib/newrelic/synthetics:rw,z ...

Kubernetes

Kubernetes に永続的なデータ ストレージを設定するには、ユーザーには 2 つのオプションがあります。

1. 既存の PersistentVolume (PV) に既存の PersistentVolumeClaim (PVC) を指定して、 synthetics.persistence.existingClaimName構成値を設定してください。例：

   bash

   コピー

   $
   helm install ... --set synthetics.persistence.existingClaimName=sjm-claim ...

2. 既存の PersistentVolume (PV) 名を指定して、 synthetics.persistence.existingVolumeName構成値を設定してください。Helm はユーザー用の PVC を生成します。ユーザーはオプションで次の値も設定できます。

• synthetics.persistence.storageClass: 既存の PV のストレージ クラス。指定されない場合、Kubernetes はデフォルトのストレージ クラスを使用します。

• synthetics.persistence.size: 請求のサイズ。設定されていない場合、デフォルトは現在 2Gi です。

  bash

  コピー

  $
  helm install ... --set synthetics.persistence.existingVolumeName=sjm-volume --set synthetics.persistence.storageClass=standard ...

プライベートロケーションを効率的に実行するには、監視ワークロードを処理するのに十分な CPU リソースをホスト上にプロビジョニングする必要があります。 サイズはさまざまな要因によって左右されますが、ニーズはすぐに見積もることができます。重量級のモニター (シンプル ブラウザー、スクリプト ブラウザー、スクリプト API モニターなど) ごとに 1 つの CPU コアが必要になります。現在のセットアップを診断する場合でも、将来のセットアップを計画する場合でも、必要なコアの数を計算するのに役立つ 2 つの式を以下に示します。

公式1：既存の場所の診断

現在のプライベートロケーションを維持するのが難しく、ジョブがキューに登録されているのではないかと思われる場合は、この式を使用して実際に必要なコアの数を調べてください。 これは、システムの観測可能なパフォーマンスに基づいています。

$$ C_{est} = (R_{proc} + R_{growth}) \cdot D_{avg,m} $$

• C\_\{est} =推定 CPU コア数。

• R\_\{proc} = 1 分あたりに処理される重量ジョブのレート。

• R\_\{growth} = jobManagerHeavyweightJobsキューが1分あたりに増加する**割合**。

• D\_\{avg,m} = 重量級ジョブの平均所要時間**（分）** 。

  この式は、システムが処理しているジョブとキューに蓄積されているジョブを追加して、実際のジョブ到着率を計算します。この合計負荷に平均ジョブ継続時間を掛けると、キューに入れずにすべての作業をクリアするために必要なコア数が正確にわかります。

  公式2: 新しい場所または将来の場所の予測

  新しいプライベートロケーションを設定している場合、またはモニターの追加を計画している場合は、この公式を使用して事前にニーズを予測してください。

  $$ C_{est} = N_{mon} \cdot D_{avg,m} \cdot \frac{1}P_{avg,m} $$

• C\_\{est} =推定 CPU コア数。

• N\_\{mon} = 実行予定のヘビーウェイトモニターの総数。

• D\_\{avg,m} = 重量級作業の平均所要時間**（分）** 。

• P\_\{avg,m} =分単位の重量モニターの平均期間(たとえば、5 分ごとに実行されるモニターの場合、P\_\{avg,m} = 5)。

  これは、基本的な原則（モニターの数、実行頻度、実行時間）から予想されるワークロードを計算します。

  重要なサイズ決定要因

  これらの数式を使用する場合は、次の要素を考慮してください。

• ジョブの所要時間（D\_\{avg,m}）: これらは所要時間全体にわたってコアを保持するため、平均にはタイムアウトするジョブ（多くの場合3分）を含める必要があります。

• ジョブの失敗と再試行:モニターが失敗すると、自動的に再試行されます。これらの再試行は、合計負荷に追加される追加のジョブです。継続して失敗し再試行するモニターは、実質的にその期間が倍増し、スループットに大きな影響を与えます。

• スケールアウト:ホストにコアを追加する (スケールアップ) ことに加えて、同じプライベートロケーションキーを持つ追加の外部監視ジョブマネージャーを展開して、複数の環境間でジョブの負荷を分散する (スケールアウト) ことができます。

  単一の外形監視ジョブ マネージャー (SJM) には、1 分あたり約 15 の重量ジョブというスループット制限があることに注意することが重要です。 これは、SJM ごとに処理されるジョブの数よりも、複数の SJM 間でのジョブの効率的な競争を優先する内部スレッド戦略によるものです。計算により、より高いスループットが必要であることが示された場合は、追加の SJM を展開してスケールアウトする必要があります。 ジョブ キューが大きくなっているかどうかを確認し、さらに SJM が必要かどうかを判断できます。

  同じプライベートロケーションキーを持つ SJM を追加すると、いくつかの利点が得られます。

• 負荷分散: プライベートロケーションのジョブは、利用可能なすべての SJM に分散されます。

• フェイルオーバー保護: 1 つの SJM インスタンスがダウンしても、他のインスタンスがジョブの処理を続行できます。

• より高い合計スループット: プライベートロケーションの合計スループットは、各SJMからのスループットの合計になります（例：2つのSJMで最大30ジョブ/分を提供します）。

  診断用のNRQL書き込み

  これらの書き込みを書き込みビルダーで実行して、診断式の入力を取得できます。 安定した平均値を得るために、時間範囲を十分に長い期間に設定してください。

  1. 1 分あたりに処理されたジョブのレート (R\_\{proc}) を検索します。このクエリは、過去 1 日に完了した非 ping (ヘビーウェイト) ジョブの数をカウントし、1 分あたりの平均レートを表示します。

  FROM SyntheticCheck
  SELECT rate(uniqueCount(id), 1 minute) AS 'job rate per minute'
  WHERE location = 'YOUR_PRIVATE_LOCATION' AND type != 'SIMPLE'
  SINCE 1 day ago

  コピー

  2. 1 分あたりのキュー増加率 (R\_\{growth}) を求めます。このクエリは、時系列チャート上でjobManagerHeavyweightJobsキューの 1 分あたりの平均増加率を計算します。ゼロより上の線は待ち行列が増加していることを示し、ゼロより下の線は待ち行列が減少していることを示します。

  FROM SyntheticsPrivateLocationStatus
  SELECT derivative(jobManagerHeavyweightJobs, 1 minute) AS 'queue growth rate per minute'
  WHERE name = 'YOUR_PRIVATE_LOCATION'
  TIMESERIES SINCE 1 day ago

  コピー

  ヒント

  必ずプライベートロケーションが存在するアカウントを選択してください。 微分関数は大きく変化する可能性があるため、このクエリを時系列として表示するのが最適です。目標は、1 分あたりのキューの増加率を推定することです。さまざまな時間範囲をPlayて、最も効果的な方法を見つけてください。

  3. 重量級モニターの総数 (N\_\{mon}) を検索します。このクエリは、重量級モニターの一意の数を検索します。

  FROM SyntheticCheck
  SELECT uniqueCount(monitorId) AS 'monitor count'
  WHERE location = 'YOUR_PRIVATE_LOCATION' AND type != 'SIMPLE'
  SINCE 1 day ago

  コピー

  4. ジョブの平均実行時間を分単位で取得します (D\_\{avg,m}) : このクエリは、完了した非pingジョブの平均実行時間を取得し、結果をミリ秒から分に変換します。executionDurationジョブがホスト上で実行された時間を表します。

  FROM SyntheticCheck
  SELECT average(executionDuration)/60e3 AS 'avg job duration (m)'
  WHERE location = 'YOUR_PRIVATE_LOCATION' AND type != 'SIMPLE'
  SINCE 1 day ago

  コピー

  5. 平均ヘビーウェイト モニター期間 (P\_\{avg,m}) を見つける:プライベートロケーションのjobManagerHeavyweightJobsキューが増大している場合、既存の結果から平均モニター期間を計算することは正確ではありません。 これは、合成モニターページのモニターのリストから推定する必要があります。 正しい New Relic アカウントを選択していることを確認してください。また、 privateLocationでフィルタリングする必要があるかもしれません。

  ヒント

  合成モニターは複数のサブアカウントに存在する場合があります。書き込みビルダーで選択できる数を超えるサブアカウントがある場合は、モニター数が最も多いアカウントを選択してください。

  ping モニターとpingJobsキューに関する注意

  Pingモニターは異なります。 これらは、それぞれ CPU コアを完全に消費しない軽量ジョブです。代わりに、別のキュー ( pingJobs ) を使用し、ワーカー スレッドのプールで実行されます。

  リソースの消費量は少なくなりますが、大量の ping ジョブ、特に失敗するジョブは、パフォーマンスの問題を引き起こす可能性があります。次の点に留意してください。

• リソース モデル: Ping ジョブは専用の CPU コアではなくワーカー スレッドを利用します。これらにはジョブあたりのコア数の計算は適用されません。

• タイムアウトと再試行:失敗した ping ジョブは、最大60 秒間ワーカー スレッドを占有する可能性があります。最初に HTTP HEAD リクエスト (30 秒のタイムアウト) を試行します。これが失敗した場合は、HTTP GETリクエストを使用してすぐに再試行します (さらに 30 秒のタイムアウト)。

• スケーリング:サイズ設定の式は異なりますが、同じ原則が適用されます。大量の ping ジョブを処理し、 pingJobsキューが拡大しないようにするには、スケールアップまたはスケールアウト (あるいはその両方) が必要になる場合があります。スケールアップとは、ホストまたはネームスペースあたりの CPU リソースとメモリ リソースを増やすことを意味します。 スケール アウトとは、ping ランタイムのインスタンスを追加することを意味します。これは、より多くのホスト、より多くのネームスペース、または同じネームスペース内でさらに多くのジョブ マネージャーをデプロイすることによって実行できます。 あるいは、Kubernetes のping-runtime使用すると、デプロイメントごとにより多くのレプリカを設定できます。

Kubernetes および OpenShift 合成ジョブ マネージャーによって使用される各ランタイムは、 Helm チャートで値を設定することで個別にサイズを変更できます。node-api-runtimeとnode-browser-runtime は、 parallelismとcompletions設定の組み合わせを使用して個別にサイズ設定されます。

• parallelism設定は、特定のランタイムのポッドが同時にいくつ実行されるかを制御します。

• completions設定は、 CronJobがそのランタイムに対して別の Kubernetes ジョブを開始する前に完了する必要があるポッドの数を制御します。

  デプロイメントのサイジングに最適なプラクティス

  New Relicに表示される平均期間は正確ではない可能性があり、特に既存のプライベートロケーションがうまく機能していない場合は、必要な並列処理と完了の値を正確に計算できないことがよくあります。 並列処理と補完を調整するには、この実用的なアプローチに従ってください。以下の式を使用すると、開始時の大まかな値を取得できます。

  1. 完了と並列性を見積もる

  平均実行時間と 5 分あたりのジョブ数をできるだけ見積もってください。これにより、次のステップの大まかな開始点が提供されます。次のステップでは、動作中のクラスターで並列処理と完了の値を調整するために試行錯誤を行うことになります。たとえば、デフォルトの 1 と 6 から 10 と 60 に変更するなど、必ず比例して拡大縮小してください。

  推定完了数: 5 分間のジョブ ロードが完了するまでにかかる時間を決定します。

  -- Get average execution duration in minutes
  FROM SyntheticCheck
  SELECT average(executionDuration / 60e3) AS 'Avg Duration (min)'
  WHERE type != 'SIMPLE' AND location = 'YOUR_PRIVATE_LOCATION'
  SINCE 1 hour ago

  コピー

  $$ Completions = \frac{5}D_{avg,m} $$

  ここで、D\_\{avg,m} はジョブの平均実行時間（分）です。

  推定並列処理: 5 分間のジョブ負荷を処理するために同時に実行する必要があるワーカー (ポッド) の数を決定します。

  -- Get jobs per 5 minutes
  FROM SyntheticCheck
  SELECT rate(uniqueCount(id), 5 minutes) AS 'Number of monitor jobs per 5 minutes'
  WHERE type != 'SIMPLE' AND location = 'YOUR_PRIVATE_LOCATION'
  SINCE 1 hour ago

  コピー

  $$ P_{est} = \frac{N_m}{Completions} $$

  ここで、$N\_m$は5分あたりのジョブ数です。この P\_\{est} 値は、推定並列度です。

  2. Helmデプロイを実行する

  推定された並列処理と完了値、およびノードあたりの CPU コア数と 1 分あたりに実行する必要がある ping モニターの数に基づいて、 ping-runtime.replicaCount最適な推測を使用して Helm デプロイを実行します。

  3. キューの増加を監視する

  プライベートロケーションにジョブを送信するように合成モニターを構成し、 pingJobsとjobManagerHeavyweightJobsの時系列折れ線グラフでキューの増加を確認します。

• pingJobsキューの傾きが正の場合、 ping-runtime.replicaCountを増やして再デプロイします。

• jobManagerHeavyweightJobsキューの傾きが正の場合、キューの成長が止まるまで（負の傾き） parallelismとcompletions比例して増やします。

  負の傾きは、ジョブ マネージャーがジョブの要求を処理するのに十分な並列処理能力を持っていることを示します。最終的には負の傾きでゼロに達します。

  FROM SyntheticsPrivateLocationStatus
  SELECT average(jobManagerHeavyweightJobs) AS 'Heavyweight Queue Growth', average(pingJobs) AS 'Ping Queue Growth'
  WHERE name = 'YOUR_PRIVATE_LOCATION'
  SINCE 1 day ago TIMESERIES

  コピー

  4. ポッドの実行状態に基づいて調整する

  キューが減少しているかゼロになっている場合は、10 分以上「実行中」状態にあるポッドnode-api-runtimeとnode-browser-runtimeをチェックします。これは、並列処理が高すぎる設定になっており、必要以上のポッドがあることを示しています。

  不必要にリソースを浪費しないようにするには、 parallelismとcompletionsを減らして、各「実行中」ランタイム ポッドの存続期間を短縮します。Kubernetes ジョブの経過時間を 5 分にすることを目標としている場合、ランタイム ポッドが実行状態にある時間は 5 分未満である必要があります。つまり、ポッドが作成され、実行するジョブをすぐに受信して完了している必要があります。

  5. 必要に応じてスケールアウトする

  キューが減少していないのに、10 分以上「実行中」状態にあるポッドが多数ある場合は、ジョブ マネージャーがパフォーマンスのボトルネックになっている可能性があります。次に行うことは、並列処理を減らし、1 つ以上の追加デプロイメントでスケール アウトすることです。

  たとえば、 parallelism: 100 、 completions: 600ではキューがまだ増え続けていますが、10 分以上「実行中」状態のポッドが多数あり、Kubernetes ジョブの経過時間は 20 分です... parallelism: 50 、 completions: 200を設定し、さらに 2 つのデプロイメントを追加して水平方向にスケールアウトします。これにより、合計 150 個の並列ポッドが生成され、K8s ジョブの存続期間が 20 分未満に短縮されるとともに、長期間「実行中」のポッドの数も削減されます。K8s ジョブの AI モニタリングは 5 ～ 10 分です。

  デプロイメントの追加の詳細については、 「複数の SJM デプロイメントによるスケールアウト」を参照してください。

  ヒント

  次のクエリを使用すると、スケールアウトする必要があるかどうかを判断できます。

  注:モニターは複数のサブアカウントに存在できます。

  -- monitors per minute per SJM
  FROM SyntheticCheck SELECT
    round(rate(uniqueCount(id), 1 minute)/uniqueCount(minionId),0.1) AS 'heavy jobs per minute per SJM',
    uniqueCount(minionId) AS 'number of SJMs (namespaces)',
    round(rate(uniqueCount(id), 1 minute),0.1) AS 'heavy jobs per minute total'
  WHERE minionContainerSystem = 'KUBERNETES' AND minionDeploymentMode = 'private' AND location = 'YOUR_PRIVATE_LOCATION' AND type != 'SIMPLE' FACET location SINCE 1 hour ago TIMESERIES

  コピー

  ヒント

  K8s ジョブ サイクルの数を減らすと、パフォーマンスも向上します。各サイクルが設定された完了数に達するにつれて、新しい外形監視ジョブを引き受ける「実行中の」ポッドはますます少なくなります。 たとえば、完了数を 200 に設定し、並列処理を 50 に設定すると、最初は 50 個のポッドが実行されますが、完了数が 150 を超えるとこの数は減少し始めます。199 回の完了で、実行中のポッドは 1 つだけ残ります。

  補完に大きな値を設定することは悪い考えではありませんが、K8s で cronjob のTooManyMissedTimesに関する警告イベントが発生する可能性があります。

  複数の SJM デプロイメントによるスケールアウト

  単一のSJMの15ジョブ/分のスループットを超えてスケールするには、複数の個別のSJM Helmリリースをインストールする必要があります。

  重要

  ジョブ マネージャー ポッドをスケーリングするためにレプリカを使用しないでください。SJMアーキテクチャーでは、ランタイムPodとその親SJM Podの間に1:1の関係が必要です。 ランタイム ポッドが間違った SJM レプリカ (Kubernetes サービス経由など) に結果を送り返すと、その結果は失われます。ただし、ping-runtime.replicaCount は使用しても問題ありません。

  正しい戦略は、それぞれ独自の Helm リリースとして複数の SJM インスタンスをデプロイすることです。各 SJM は同じプライベート ロケーションからのジョブを巡って競合し、負荷分散、フェイルオーバー保護、および合計ジョブ スループットの増加を実現します。

  水平スケーリング戦略

  スケールアウトする必要がある場合は、各 SJM デプロイメントを固定容量ユニットとして扱うことでメンテナンスを簡素化できます。

1. 並列処理の設定:*各*SJM について、 parallelism 、長期間実行される「実行中」のランタイム ポッドをあまり多く作成せずに単一の SJM が処理できるのと同じ最大値に設定します。これにより、リソースを無駄にすることなく、各 SJM の潜在的なスループットが最大化されます。

2. 設定の完了:*各*SJM に対して、 completionsも同じ固定値に設定します。必要に応じて調整し、ランタイム (node-browser-runtime と node-api-runtime) ごとに 5 分の Kubernetes ジョブの経過時間をターゲットにします。

3. リリースのインストール:ジョブの総需要を処理するために必要な数の個別の Helm リリースをインストールします。つまり、キューをゼロにしたり、折れ線グラフを負の傾きにしたりします。

4. 監視および追加:プライベートロケーション ジョブ キューを監視します。 増加し始めた場合 (正の傾き)、同じ固定設定を使用して別のHelmリリース (例: sjm-delta) をインストールするだけです。

   並列処理と完了を静的な値に固定することで、容量の増減がHelm リリースの追加または削除のプロセスとして簡単になります。これにより、SJM が効果的に利用できる並列処理値よりも高い並列処理値でクラスター リソースが無駄に消費されることを回避できます。

   インストレーション例

   複数の SJM リリースをインストールする場合は、リリースごとに一意の名前を付ける必要があります。すべてのインスタンスは同じプライベートロケーションキーを使用して構成する必要があります。

   より短く、管理しやすいリソース名を作成するには、 fullnameOverrideを設定することを強くお勧めします。たとえば、 sjm-alphaとsjm-betaという名前の 2 つの SJM をnewrelicネームスペースにインストールするには (両方とも固定並列処理と補完で同じvalues.yaml を使用します):

   bash

   コピー

   $
   # Install the first SJM deployment
   $
   helm upgrade --install sjm-alpha newrelic/synthetics-job-manager \
   >
     -n newrelic \
   >
     -f values.yaml \
   >
     --set fullnameOverride=sjm-alpha \
   >
     --set ping-runtime.fullnameOverride=sjm-alpha-ping \
   >
     --set node-api-runtime.fullnameOverride=sjm-alpha-api \
   >
     --set node-browser-runtime.fullnameOverride=sjm-alpha-browser

   bash

   コピー

   $
   # Install the second SJM deployment to add capacity
   $
   helm upgrade --install sjm-beta newrelic/synthetics-job-manager \
   >
     -n newrelic \
   >
     -f values.yaml \
   >
     --set fullnameOverride=sjm-beta \
   >
     --set ping-runtime.fullnameOverride=sjm-beta-ping \
   >
     --set node-api-runtime.fullnameOverride=sjm-beta-api \
   >
     --set node-browser-runtime.fullnameOverride=sjm-beta-browser

   ジョブ キューが拡大しないように、必要な数の SJM に対してこのパターン (sjm-charlie 、 sjm-deltaなど) を継続できます。