• /
  • EnglishEspañolFrançais日本語한국어Português
  • 로그인지금 시작하기

사용자의 편의를 위해 제공되는 기계 번역입니다.

영문본과 번역본이 일치하지 않는 경우 영문본이 우선합니다. 보다 자세한 내용은 이 페이지를 방문하시기 바랍니다.

문제 신고

합성 작업 관리자 구성

이 문서는 다음 방법을 보여줌으로써 신세틱스 작업 관리자를 구성하는 과정을 안내합니다.

환경변수를 이용한 설정

환경 변수를 사용하면 특정 환경 및 기능 요구 사항을 충족하도록 합성 작업 관리자 구성을 미세 조정할 수 있습니다.

스크립트 모니터에 대한 사용자 정의 변수

개인 신세틱스 작업 관리자를 사용하면 스크립트된 모니터에 대한 환경 변수를 구성할 수 있습니다. 이러한 변수는 SJM에서 로컬로 관리되며 $env.USER_DEFINED_VARIABLES 통해 액세스할 수 있습니다. 사용자 정의 변수는 두 가지 방법으로 설정할 수 있습니다. 등장에서 JSON 파일을 마운트하거나 SJM에 환경 변수를 제공할 수 있습니다. 둘 다 제공되는 경우 SJM은 환경에서 제공되는 값만 사용합니다.

스크립트에서 사용자 정의 환경 변수에 액세스

구성된 사용자 정의 환경 변수를 참조하려면 예약된 $env.USER_DEFINED_VARIABLES 뒤에 점 표기법을 사용하여 지정된 변수 이름을 입력합니다(예: $env.USER_DEFINED_VARIABLES.MY_VARIABLE).

주의

사용자 정의 환경 변수는 로그에서 삭제되지 않습니다. 민감한 정보에는 보안 자격 증명 기능을 사용하는 것이 좋습니다.

커스텀 노드 모듈

맞춤형 노드 모듈은 분당호출수와 SJM 모두에서 제공됩니다. 이를 통해 사용자 정의된 노드 모듈 세트를 생성하고 이를 신세틱 모델링을 위한 스크립트 모니터(스크립트 API 및 스크립트 브라우저)에서 사용할 수 있습니다.

사용자 정의 모듈 디렉토리 설정

루트 폴더에 npm 공식 지침에 따라 package.json 파일이 포함된 디렉터리를 만듭니다. SJM은 package.json에 나열된 의존성/종속성을 설치합니다. dependencies 필드. 이러한 의존성/종속성은 개인 신세틱스 작업 관리자에서 모니터를 실행할 때 사용할 수 있습니다. 아래의 예를 참조하세요.

예시

이 예에서 사용자 정의 모듈 디렉토리는 다음 구조로 사용됩니다.

/example-custom-modules-dir/
    ├── counter
    │   ├── index.js
    │   └── package.json
    └── package.json            ⇦ the only mandatory file

package.json 는 dependencies 로컬 모듈(예: counter)과 호스팅된 모듈(예: smallest 버전 1.0.1)로 정의합니다.

{
    "name": "custom-modules",
    "version": "1.0.0",                                ⇦ optional
    "description": "example custom modules directory", ⇦ optional
    "dependencies": {
    "smallest": "1.0.1",                               ⇦ hosted module
    "counter": "file:./counter"                        ⇦ local module
    }
}

docker, Podman 또는 Kubernetes용 SJM에 사용자 정의 모듈 디렉토리를 추가합니다.

모듈이 올바르게 설치되었는지 또는 오류가 발생했는지 확인하려면 synthetics-job-manager 컨테이너 또는 파드 로그에서 다음 줄을 찾으세요.

2024-06-29 03:51:28,407{UTC} [main] INFO  c.n.s.j.p.options.CustomModules - Detected mounted path for custom node modules
2024-06-29 03:51:28,408{UTC} [main] INFO  c.n.s.j.p.options.CustomModules - Validating permission for custom node modules package.json file
2024-06-29 03:51:28,409{UTC} [main] INFO  c.n.s.j.p.options.CustomModules - Installing custom node modules...
2024-06-29 03:51:44,670{UTC} [main] INFO  c.n.s.j.p.options.CustomModules - Custom node modules installed successfully.

이제 이 개인 위치로 보내는 모니터의 스크립트 에 "require('smallest');" 을(를) 추가할 수 있습니다.

변화 package.json

로컬 및 호스팅 모듈 외에도 Node.js 모듈 도 활용할 수 있습니다. SJM에서 사용하는 사용자 정의 모듈을 업데이트하려면 package.json 파일을 변경하고 SJM을 다시 시작하세요. 재부팅 프로세스 동안 SJM은 설정 변경을 인식하고 자동으로 정리 및 재설치 작업을 수행하여 업데이트된 모듈이 적용되도록 합니다.

주의

로컬 모듈: package.json 에는 모든 로컬 모듈이 포함될 수 있지만 이러한 모듈은 맞춤 모듈 디렉터리 아래의 트리 내부에 있어야 합니다. 트리 외부에 저장하면 초기화 프로세스가 실패하고 SJM을 시작한 후 docker 로그 에 오류 메시지가 표시됩니다.

영구 데이터 저장

사용자는 user_defined_variables.json 파일을 제공하거나 사용자 정의 노드 모듈을 지원하기 위해 영구 데이터 저장소를 사용하고 싶어할 수 있습니다.

도커

Docker에서 영구 데이터 저장소를 설정하려면:

  1. 작업 관리자를 실행하는 호스트에 디렉터리를 만듭니다. 이것이 소스 디렉터리입니다.

  2. Job Manager에서 소스 디렉터리를 뻐, 목표 디렉터리 /var/lib/newrelic/synthetics 에 마운트합니다.

    예시:

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

포드만

Podman에 영구 데이터 저장소를 설정하려면:

  1. 작업 관리자를 실행하는 호스트에 디렉터리를 만듭니다. 이것이 소스 디렉터리입니다.
  2. Job Manager에서 소스 디렉터리를 뻐, 목표 디렉터리 /var/lib/newrelic/synthetics 에 마운트합니다.

예시:

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

Kubernetes

Kubernetes에 영구 데이터 저장소를 설정하기 위해 사용자에게는 두 가지 옵션이 있습니다.

  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 모니터) 하나당 CPU 코어 1개가 필요합니다. 현재 설정을 진단하거나 향후 설정을 계획하는 경우 필요한 코어 수를 계산하는 데 도움이 되는 두 가지 공식은 다음과 같습니다.

공식 1: 기존 위치 진단

현재 사용하고 있는 가상화 로케이션이 따라잡기 힘들고 작업이 대기하고 있다고 의심되는 경우, 이 공식을 사용하여 실제로 필요한 코어 수를 확인하세요. 이는 시스템의 관찰 가능한 성능에 따라 결정됩니다.

$$ C_est = (R_proc + R_growth) \cdot D_avg,m $$

  • C_estC\_est = 예상 CPU 코어.
  • R_procR\_proc = 분당 처리 되는 중량 작업의 비율 입니다.
  • R_growthR\_growth = jobManagerHeavyweightJobs 대기열이 분당 증가하는 속도 입니다.
  • D_avg,mD\_avg,m = 중량 작업의 평균 소요 시간 (분) 입니다.

이 공식은 시스템에서 처리 중인 작업과 대기열에 쌓여 있는 작업을 합산하여 실제 작업 도착률을 계산합니다. 이 총 부하에 평균 작업 시간을 곱하면 대기열 없이 모든 작업을 처리하는 데 필요한 코어 수를 정확히 알 수 있습니다.

공식 2: 새 위치 또는 미래 위치 예측

새로운 위치 위치를 설정하거나 더 많은 모니터를 추가할 계획이라면 이 공식을 사용하여 요구 사항을 미리 예측하세요.

$$ C_est = N_mon \cdot D_avg,m \cdot \frac1P_avg,m $$

  • C_estC\_est = 예상 CPU 코어.
  • N_monN\_mon = 실행하려는 중량 모니터 의 총 수 입니다.
  • D_avg,mD\_avg,m = 중량 작업의 평균 소요 시간 (분) 입니다.
  • P_avg,mP\_avg,m = 중량 모니터의 평균 기간 (분) (예: 5분마다 실행되는 모니터의 경우 P_avg,m=5P\_avg,m = 5).

이는 기본 원칙, 즉 보유하고 있는 개체 수, 실행 빈도 및 소요 시간을 기반으로 예상 수량을 계산합니다.

중요한 크기 요소

이러한 공식을 사용할 때는 다음 요소를 고려해야 합니다.

  • 작업 기간(D_avg,mD\_avg,m): 평균에는 시간 초과 된 작업(대개 ~3분)도 포함되어야 합니다. 이러한 작업은 전체 기간 동안 핵심을 유지합니다.
  • 작업 실패 및 재시도: 모니터가 실패하면 자동으로 재시도됩니다. 이러한 재시도는 전체 부하를 증가시키는 추가 작업입니다. 지속적으로 실패하고 재시도하는 모니터는 주기를 늘려 처리량에 상당한 영향을 미칩니다.
  • 스케일 아웃: 호스트에 더 많은 코어를 추가하는 것(스케일 업) 외에도 동일한 독립 로케이션 키를 사용하여 추가 신세틱스 작업 관리자를 구현하고 배치하여 여러 환경에 걸쳐 작업의 로드 밸런싱을 수행할 수 있습니다(스케일 아웃).

단일 신세틱스 Job Manager(SJM)는 분당 약 15개의 중량 작업을 처리할 수 있는 처리량 제한이 있다는 점에 유의하는 것이 중요합니다. 이는 SJM당 처리되는 작업의 순수한 개수보다 여러 SJM 간의 작업의 효율적인 경쟁을 선호하는 내부 스레딩 전략 때문입니다. 계산 결과 더 높은 처리량이 필요하다는 것을 나타내는 경우 추가 SJM을 구현, 배포하여 확장 해야 합니다. 작업 대기열이 늘어나는지 확인하여 더 많은 SJM이 필요한지 확인할 수 있습니다.

동일한 위치 위치 키를 사용하여 더 많은 SJM을 추가하면 다음과 같은 이점이 있습니다.

  • 로드 밸런싱: 고립로케이션에 대한 작업은 사용 가능한 모든 SJM에 분산됩니다.
  • 장애 조치 보호: 하나의 SJM 인스턴스가 다운되더라도 다른 인스턴스가 작업을 계속 처리할 수 있습니다.
  • 더 높은 총 처리량: 상대 로케이션에 대한 총 처리량은 각 SJM의 처리량의 합이 됩니다(예: 2개의 SJM은 분당 최대 30개의 작업을 제공합니다).

진단을 위한 NRQL 쿼리

진단 공식에 대한 입력을 얻으려면 쿼리 빌더 에서 이러한 쿼리를 실행할 수 있습니다. 안정적인 평균을 얻으려면 시간 범위를 충분히 길게 설정하세요.

1. 분당 처리된 작업 속도(R_procR\_proc)를 찾습니다. 이 쿼리는 지난 하루 동안 완료된 핑 작업이 아닌 (대용량) 작업 수를 계산하고 분당 평균 속도를 보여줍니다.

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. 분당 대기열 증가율(R_growthR\_growth)을 찾습니다. 이 쿼리는 시계열 차트에서 jobManagerHeavyweightJobs 대기열의 분당 평균 증가율을 계산합니다. 선이 0보다 위에 있으면 대기열이 증가하고 있음을 나타내고, 선이 0보다 아래에 있으면 대기열이 감소하고 있음을 나타냅니다.

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

팁

해당 로그인이 존재하는 계정을 선택하세요. 파생 함수가 크게 달라질 수 있으므로 이 쿼리를 시계열로 보는 것이 가장 좋습니다. 목표는 분당 대기열 증가율을 추정하는 것입니다. 다양한 시간 범위를 적용해 보고 어떤 것이 가장 효과적인지 확인 Play .

3. 고사양 모니터 총 개수 찾기(N_monN\_mon): 이 쿼리는 고사양 모니터의 고유 개수를 찾습니다.

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

4. 평균 작업 지속 시간(분) 찾기(D_avg,mD\_avg,m): 이 쿼리는 완료된 비핑 작업의 평균 실행 지속 시간을 찾고 결과를 밀리초에서 분으로 변환합니다. 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,mP\_avg,m) 찾기: 처리로케이션의 jobManagerHeavyweightJobs 큐가 증가하는 경우 기존 결과에서 평균 감시 기간을 계산하는 것은 정확하지 않습니다. 이는 Synthetic Monitor 페이지의 모니터 목록에서 추산해야 합니다. 올바른 뉴렐릭 계정을 선택했는지 확인하고 privateLocation 로 필터링해야 할 수도 있습니다.

팁

합성 모니터는 여러 하위 계정에 존재할 수 있습니다. 쿼리 빌더에서 선택할 수 있는 하위 계정보다 많은 하위 계정이 있는 경우, 모니터가 가장 많은 계정을 선택하세요.

ping 모니터 및 pingJobs 대기열에 대한 참고 사항

Ping 모니터는 다릅니다. 각각 전체 CPU 코어를 소모하지 않는 가벼운 작업입니다. 대신 별도의 대기열(pingJobs)을 사용하고 작업자 스레드 풀에서 실행됩니다.

ping 작업은 리소스를 덜 사용하지만, 특히 실패하는 작업의 경우 ping 작업량이 많으면 여전히 성능 문제가 발생할 수 있습니다. 다음 사항을 명심하세요.

  • 리소스 모델: Ping 작업은 전용 CPU 코어가 아닌 작업자 스레드를 활용합니다. 이러한 경우에는 작업당 코어 계산이 적용되지 않습니다.
  • 시간 초과 및 재시도: 실패한 ping 작업은 최대 60초 동안 작업자 스레드를 차지할 수 있습니다. 먼저 HTTP HEAD 요청을 시도합니다(제한 시간 30초). 실패하면 즉시 HTTP GET 요청으로 재시도합니다(30초의 시간 초과).
  • 크기 조정: 크기 조정 공식은 다르지만 동일한 원칙이 적용됩니다. 대량의 ping 작업을 처리하고 pingJobs 대기열이 커지는 것을 방지하려면 확장 및/또는 확장이 필요할 수 있습니다. 확장은 호스트나 네임스페이스당 CPU와 메모리 리소스를 늘리는 것을 의미합니다. 확장은 ping 런타임 인스턴스를 더 추가하는 것을 의미합니다. 이는 더 많은 호스트, 더 많은 라벨스페이스 또는 동일한 라벨스페이스 내에서 구현하다, 배포하다 더 많은 작업 관리자를 통해 수행될 수 있습니다. 또는 Kubernetes 의 ping-runtime 을 사용하면 구현, 배포당 더 많은 수의 복제본을 설정할 수 있습니다.

Kubernetes 및 OpenShift의 크기 조정 고려 사항

Kubernetes와 OpenShift 합성 작업 관리자가 사용하는 각 런타임은 helm 차트 에서 값을 설정하여 독립적으로 크기를 조정할 수 있습니다. node-api-runtime 과 node-browser-runtime은 parallelism 및 completions 설정의 조합을 사용하여 독립적으로 크기가 조정됩니다.

  • parallelism 설정은 특정 런타임의 파드가 동시에 실행되는 수를 제어합니다.
  • completions 설정은 CronJob 이 해당 런타임에 대해 다른 Kubernetes Job을 시작하기 전에 완료해야 하는 파드 수를 제어합니다.

구현 크기 조정을 위한 모범 사례, 배포

뉴렐릭에서 볼 수 있는 평균 실행 시간이 정확하지 않을 수 있기 때문에 필요한 병렬 처리 및 완료 값을 정확하게 계산하는 것이 불가능한 경우가 많습니다. 특히 기존 타이머 로케이션이 제대로 작동하지 않는 경우에는 더욱 그렇습니다. 병렬 처리와 자동 완성 기능을 최적화하려면 이 실용적인 접근 방식을 따르십시오. 아래 방정식을 사용하면 대략적인 시작값을 얻을 수 있습니다.

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

$$ 완료율 = \frac5D_avg,m $$

여기서 D_avg,mD\_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 = \fracN_m완료 $$

여기서 N_mN\_m은 5분당 작업 수 입니다. 이 P_estP\_est 값은 예상 병렬 처리량 입니다.

2. Helm 구현, 배포 수행

Helm 구현을 수행하고 예상 병렬 처리 및 완료 값과 노드당 CPU 코어 수와 분당 실행해야 하는 ping 모니터 수를 고려하여 ping-runtime.replicaCount 에 대한 최적의 추측을 배포합니다.

3. 대기열 증가를 모니터링합니다.

작업을 상대 로케이션으로 보내도록 구성된 합성 모니터를 사용하여 pingJobs 및 jobManagerHeavyweightJobs 에 대한 시계열 선 차트에서 대기열 증가를 확인합니다.

  • pingJobs 큐의 기울기가 양수이면 ping-runtime.replicaCount 증가시키고 재배포합니다.
  • jobManagerHeavyweightJobs 큐의 기울기가 양수이면 큐가 더 이상 증가하지 않을 때까지(음의 기울기) parallelism 과 completions 비례적으로 증가시킵니다.

음의 기울기는 작업 관리자가 작업 요구 사항을 처리할 수 있을 만큼 충분한 병렬 처리 능력을 갖추고 있음을 나타냅니다. 결국 음의 기울기로 0에 도달할 것입니다.

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. 파드 실행 상태에 따라 튜닝

큐가 줄어들거나 0이 되면 10분 이상 "실행 중" 상태인 node-api-runtime 및 node-browser-runtime 파드를 확인합니다. 이는 병렬 처리 수준이 너무 높게 설정되어 있어 필요한 것보다 파드가 더 많다는 것을 나타냅니다.

불필요한 자원 낭비를 방지하기 위해 parallelism 과 completions 감소시켜 각 "실행 중인" 런타임 파드의 수명을 줄이십시오. Kubernetes 작업의 실행 시간을 5분으로 설정했다면, 런타임 파드는 5분 이내에 실행 상태를 유지해야 합니다. 즉, 파드가 생성되자마자 실행할 작업을 빠르게 수신하고 완료되어야 합니다.

5. 필요한 경우 규모를 확장하십시오.

대기열이 줄어들지 않고 있는데도 10분 이상 "실행 중" 상태인 파드가 많다면 작업 관리자가 성능 병목현상, 병목지점에 도달했을 가능성이 높습니다. 다음으로 할 일은 병렬 처리를 줄이고 하나 이상의 추가 구현을 통해 확장하는 것입니다.

예를 들어, parallelism: 100, completions: 600 사용하면 큐가 계속 증가하지만 10분 이상 "실행 중" 상태인 파드가 많고 Kubernetes 작업 시간이 20분인 경우... parallelism: 50, completions: 200 설정하고 2개의 추가 구현 배포를 추가하여 수평 확장(확장)합니다. 이로써 총 150개의 병렬 파드가 생성되며, K8의 작업 시간을 20분 미만으로 단축하는 동시에 장시간 실행되는 "실행" 파드의 수도 줄일 수 있습니다. 5~10분의 K8s 작업 기간에 대한 AI 예측.

구현, 배포 추가에 대한 자세한 내용은 여러 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

팁

Kubernetes 작업 주기 횟수를 줄이면 성능도 향상될 수 있습니다. 각 주기가 설정된 완료 횟수에 도달하면 새로운 신세틱스 작업을 수행할 "실행 중인" 파드의 수가 점점 줄어듭니다. 예를 들어, 완료 횟수를 200으로, 병렬 처리를 50으로 설정하면 처음에는 50개의 파드가 실행되지만, 완료 횟수가 150회를 넘어서면서 실행 중인 파드 수가 줄어들기 시작합니다. 199번의 완료 중, 현재 실행 중인 파드는 단 1개만 남았습니다.

완료 값을 더 크게 설정하는 것은 나쁜 생각은 아니지만, cronjob에 대해 TooManyMissedTimes 과 관련된 K8s 경고 이벤트가 발생할 수 있습니다.

여러 SJM 구현으로 확장, 배포

단일 SJM의 분당 약 15개 작업 처리량을 넘어서 확장하려면 여러 개의 개별 SJM Helm 릴리스를 설치해야 합니다.

중요

작업 관리자 확장을 위해 복제본을 사용하지 마십시오. SJM 아키텍처는 런타임 파드와 해당 파드의 상위 SJM 파드 간에 1:1 관계를 요구합니다. 런타임 파드가 결과를 잘못된 SJM 복제본(예: Kubernetes 서비스를 통해)으로 전송하는 경우 해당 결과가 손실됩니다. 하지만 ping-runtime.replicaCount는 사용해도 괜찮습니다.

올바른 전략은 여러 SJM을 구현하고 배포하는 것입니다. 각각은 자체 Helm 릴리스입니다. 각 SJM은 로드 밸런싱, 장애 조치 보호 및 증가된 전체 작업 처리량을 제공하여 동일한 위치의 작업을 놓고 경쟁합니다.

수평적 확장 전략

확장이 필요한 경우 각 SJM 구현 및 배포를 고정 용량 단위로 취급하여 유지 관리를 간소화할 수 있습니다.

  1. 병렬 처리 설정: 각 SJM에 대해 parallelism 단일 SJM이 너무 많은 장기 실행 런타임 파드를 생성하지 않고 처리할 수 있는 최대값으로 설정합니다. 이를 통해 자원을 낭비하지 않고 각 SJM의 잠재적 처리량을 극대화할 수 있습니다.
  2. 집합 완성: 각 SJM에 대해 completions 도 동일한 고정 값으로 설정합니다. 필요에 따라 조정하여 대상, 목표를 런타임별 Kubernetes 작업 유지 시간 5분(예: node-browser-runtime 및 node-api-runtime)으로 설정합니다.
  3. 릴리스 설치: 전체 작업 수요를 처리하는 데 필요한 만큼의 Helm 릴리스를 설치하십시오. 즉, 대기열이 0이 되거나 선 그래프의 기울기가 음수가 될 때까지 설치하십시오.
  4. 감시 및 추가: 반대방향 작업 대기열을 감시합니다. 증가 추세(양의 기울기)를 보이기 시작하면 동일한 고정 설정을 사용하여 다른 Helm 릴리스(예: sjm-delta)를 설치하기만 하면 됩니다.

병렬 처리 및 자동 완성 기능을 고정 값으로 설정함으로써 용량 증가 또는 감소는 Helm 릴리스를 추가하거나 제거하는 간단한 프로세스가 됩니다. 이렇게 하면 SJM이 효과적으로 활용할 수 있는 것보다 높은 병렬 처리 값에 클러스터 리소스가 낭비되는 것을 방지할 수 있습니다.

설치 예시

여러 SJM 릴리스를 설치할 때는 각 릴리스에 고유한 이름을 지정해야 합니다. 모두 동일한 로그로케이션 키로 구성되어야 합니다.

더 짧고 관리하기 쉬운 리소스 이름을 만들려면 fullnameOverride 을 설정하는 것이 좋습니다. 예를 들어, sjm-alpha 과 sjm-beta 라는 이름의 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, 등)을 계속할 수 있습니다.

Copyright © 2026 New Relic Inc.
채용정보서비스 이용약관DMCA 정책특허 고지개인정보 고지쿠키 정책영국 현대판 노예법

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.