GKE에서 강화 학습 워크로드 모니터링

Autopilot Standard

이 문서에서는 Google Kubernetes Engine (GKE)에서 실행되는 Python 기반 강화 학습 (RL) 애플리케이션의 주요 측정항목과 trace를 내보내고, 수집하고, 보는 방법을 보여줍니다.

이 문서에서는 다음을 수행하는 방법을 보여줍니다.

측정항목과 trace를 내보내도록 RL 애플리케이션을 계측합니다. 사용되는 계측은 OpenTelemetry 형식을 따르는 측정항목과 trace를 위한 것입니다.
애플리케이션이 GKE에서 실행될 때 측정항목과 trace를 수집합니다. 데이터는 GKE용 관리형 OpenTelemetry (미리보기)를 사용하여 수집됩니다.
Cloud Monitoring에서 수집된 측정항목을 보고 Cloud Trace에서 trace를 확인합니다.
OpenTelemetry 시맨틱 규칙 및 골든 신호를 기반으로 중요한 RL 측정항목을 식별하고 이해합니다. 골든 신호 는 서비스의 상태에 대한 개요를 제공하는 서비스의 4가지 주요 측정항목(지연 시간, 트래픽, 오류, 포화도)입니다.

시작하기 전에

측정항목 및 trace 데이터를 사용하여 모니터링할 Python 기반 RL 애플리케이션이 있어야 합니다.
결제가 사용 설정된 Google Cloud 프로젝트가 있어야 합니다.
GKE 버전 1.34.1-gke.2178000 이상을 실행하는 GKE 클러스터가 필요합니다. 이러한 버전에서 GKE용 관리형 OpenTelemetry (미리보기)를 사용할 수 있습니다.
다음 Google Cloud API를 사용 설정합니다.
- container.googleapis.com (GKE)
- monitoring.googleapis.com (Monitoring)
- cloudtrace.googleapis.com (Trace)
- telemetry.googleapis.com (OpenTelemetry 원격 분석 API)
gcloud를 사용하여 이러한 API를 사용 설정할 수 있습니다.
```
gcloud services enable \
    container.googleapis.com \
    monitoring.googleapis.com \
    cloudtrace.googleapis.com \
    telemetry.googleapis.com
```
OpenTelemetry SDK 설치: Python RL 애플리케이션의 환경에서 OpenTelemetry SDK 및 OTLP 내보내기 도구를 설치합니다.
```
pip install opentelemetry-sdk \
            opentelemetry-exporter-otlp-proto-grpc \
            opentelemetry-api
```
RL 앱에서 사용하는 프레임워크의 계측 라이브러리(예: opentelemetry-instrumentation-flask)도 필요할 수 있습니다.

비용

에 원격 분석 데이터를 전송하면 수집량에 따라 요금이 청구됩니다. Google Cloud측정항목은 Google Cloud Managed Service for Prometheus 가격 책정을 사용하여 청구되고, 로그는 Cloud Logging 가격 책정을 사용하여 청구되며, trace는 Cloud Trace 가격 책정을 사용하여 청구됩니다.

trace, 로그, Google Cloud Managed Service for Prometheus 측정항목 수집과 관련된 비용에 대한 자세한 내용은 Google Cloud Observability 가격 책정을 참조하세요.

OpenTelemetry를 사용하여 애플리케이션 계측

OpenTelemetry 측정항목을 내보낼 수 있도록 Python RL 애플리케이션 코드를 계측합니다. 애플리케이션을 계측하려면 다음 안내를 따르세요.

애플리케이션에 다음 코드를 추가하여 OpenTelemetry를 초기화합니다.

import os
import time
from opentelemetry import metrics, trace
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader
from opentelemetry.exporter.otlp.proto.grpc.metric_exporter import OTLPMetricExporter
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.resources import Resource
from opentelemetry.metrics import Counter, Histogram, UpDownCounter

resource = Resource.create({
    "service.name": "rl-training-service",
    "service.namespace": "opentelemetry-demo",
})

# Initialize Metrics
reader = PeriodicExportingMetricReader(
    OTLPMetricExporter(
        endpoint=os.environ.get("OTEL_EXPORTER_OTLP_METRICS_ENDPOINT", "localhost:4317"),
        insecure=True
    )
)
meter_provider = MeterProvider(metric_readers=[reader], resource=resource)
metrics.set_meter_provider(meter_provider)
meter = metrics.get_meter("rl-training-meter")

# Initialize Tracing
trace_provider = TracerProvider(resource=resource)
trace_processor = BatchSpanProcessor(
    OTLPSpanExporter(
        endpoint=os.environ.get("OTEL_EXPORTER_OTLP_TRACES_ENDPOINT", "localhost:4317"),
        insecure=True
    )
)
trace_provider.add_span_processor(trace_processor)
trace.set_tracer_provider(trace_provider)
tracer = trace.get_tracer("rl-training-tracer")

각 측정항목의 기기를 만들고 애플리케이션에서 내보낼 값을 기록합니다. 관련 시맨틱 규칙을 속성으로 연결합니다.

애플리케이션에 계측할 측정항목을 결정하는 데 도움이 되도록 시맨틱 규칙 및 골든 신호 목록을 사용합니다.

다음은 특정 측정항목의 기기 예시입니다.

# Latency Histograms
rl_loop_duration = meter.create_histogram(
    name="rl.loop.duration", description="Duration of a single RL loop iteration.", unit="ms"
)
rl_sample_duration = meter.create_histogram(
    name="rl.sample.duration", description="Duration of the sampling phase.", unit="ms"
)
rl_train_duration = meter.create_histogram(
    name="rl.train.duration", description="Duration of the training phase.", unit="ms"
)
# ... create other duration histograms (reward, train, sync, step)

# Throughput Counters
rl_sample_samples = meter.create_counter(
    name="rl.sample.samples", description="Number of samples generated.", unit="{samples}"
)
rl_train_steps = meter.create_counter(
    name="rl.train.steps", description="Number of training steps completed.", unit="{steps}"
)
# ... create other counter metrics (rl.sample.episodes, rl.train.tokens)

# Performance/Saturation Gauges (using UpDownCounter)
rl_reward_mean = meter.create_up_down_counter(
    name="rl.environment.reward.mean", description="Mean reward observed.", unit="1"
)
rl_train_loss = meter.create_up_down_counter(
    name="rl.train.loss", description="Current training loss.", unit="1"
)
rl_train_mfu = meter.create_up_down_counter(
    name="rl.train.mfu", description="Model Flop Utilization.", unit="1"
)
_rl_reward_mean_val, _rl_train_loss_val = 0.0, 0.0

def get_common_attributes(rl_system, rl_run_id, rl_algorithm, rl_env_name, rl_model_name):
    return {
        "rl.system": rl_system,
        "rl.run.id": rl_run_id,
        "rl.algorithm": rl_algorithm,
        "rl.environment.name": rl_env_name,
        "rl.model.name": rl_model_name,
    }

# Example Usage within your RL code:
common_attrs = get_common_attributes("MyPPO", "run-42", "PPO", "Acrobot-v1", "PolicyModelV1")

# Inside the main RL loop:
with tracer.start_as_current_span("rl_loop_iteration", attributes={**common_attrs, "rl.loop.iteration": 5}) as span:
    loop_start_time = time.perf_counter()
# --- Sampling Phase ---
sample_start = time.perf_counter()
# ... perform sampling ...
sampled_count = 1024
rl_sample_samples.add(sampled_count, attributes={**common_attrs, "rl.sample.batch_size": 128})
rl_sample_duration.record((time.perf_counter() - sample_start) * 1000, attributes=common_attrs)

# --- Training Phase ---
train_start = time.perf_counter()
# ... perform training step ...
rl_train_steps.add(1, attributes={**common_attrs, "rl.loop.iteration": 5})
current_loss = 0.125
rl_train_loss.add(current_loss - _rl_train_loss_val, attributes=common_attrs) # Record current loss
_rl_train_loss_val = current_loss
rl_train_duration.record((time.perf_counter() - train_start) * 1000, attributes=common_attrs)

# --- Record Mean Reward ---
current_mean_reward = -5.5
rl_reward_mean.add(current_mean_reward - _rl_reward_mean_val, attributes=common_attrs)
_rl_reward_mean_val = current_mean_reward

loop_duration = (time.perf_counter() - loop_start_time) * 1000
rl_loop_duration.record(loop_duration, attributes={**common_attrs, "rl.loop.iteration": 5})

# Ensure metrics are pushed before application exit in short-lived scripts
# For long-running services, PeriodicExportingMetricReader handles this.
# meter_provider.shutdown()

이제 OpenTelemetry를 초기화하고 특정 측정항목의 기기를 만들었으므로 애플리케이션이 실행될 때 지정된 원격 분석 데이터를 내보냅니다.

GKE에서 측정항목 및 trace 데이터 수집 사용 설정

애플리케이션이 실행되는 동안 내보내는 원격 분석 데이터를 수집하려면 GKE용 관리형 OpenTelemetry (미리보기)를 사용하면 됩니다. 이 기능은 측정항목 및 trace와 같은 원격 분석 데이터를 수집하고 데이터를 Google Cloud Observability로 전송합니다.

GKE용 관리형 OpenTelemetry를 사용 설정하고 구성하려면 다음 안내를 따르세요.

애플리케이션이 실행되는 클러스터에서 GKE용 관리형 OpenTelemetry를 사용 설정합니다. 이렇게 하려면 클러스터에서 GKE용 관리형 OpenTelemetry 사용 설정의 단계를 따르세요.

환경 변수로 애플리케이션 배포에 주석을 달아 OpenTelemetry SDK가 원격 분석 데이터를 관리형 수집기의 OTLP 엔드포인트로 전송하도록 안내합니다. Python 기반 RL 애플리케이션의 경우 GKE용 관리형 OpenTelemetry의 자동 구성 기능을 사용할 수 없습니다.

대신 배포 매니페스트의 컨테이너 사양에 다음 env 섹션을 추가합니다.

env:
  - name: OTEL_COLLECTOR_NAME
    value: 'opentelemetry-collector'
  - name: OTEL_COLLECTOR_NAMESPACE
    value: 'gke-managed-otel'
  - name: OTEL_EXPORTER_OTLP_METRICS_ENDPOINT
    value: $(OTEL_COLLECTOR_NAME).$(OTEL_COLLECTOR_NAMESPACE).svc.cluster.local:4317
  - name: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT
    value: $(OTEL_COLLECTOR_NAME).$(OTEL_COLLECTOR_NAMESPACE).svc.cluster.local:4317
  - name: OTEL_SERVICE_NAME
    value: 'rl-training-service'
  - name: OTEL_RESOURCE_ATTRIBUTES
    value: service.namespace=opentelemetry-demo

이제 애플리케이션이 계측되고 관리형 수집기가 사용 설정되고 구성되었으므로 애플리케이션이 GKE 클러스터에서 실행될 때 측정항목과 trace가 Google Cloud Observability로 전송됩니다.

Monitoring 및 Trace에서 이 원격 분석 데이터를 볼 수 있습니다.

Monitoring에서 측정항목 보기

관리형 OpenTelemetry가 사용 설정된 상태로 RL 애플리케이션이 GKE에서 실행되면 측정항목이 Monitoring으로 전송됩니다. 측정항목은 일반적으로 prometheus.googleapis.com/ 도메인에서 사용할 수 있습니다.

Monitoring에서 커스텀 RL 측정항목을 보려면 다음 안내를 따르세요.

대시보드에서 RL 측정항목을 보려면 다음 중 하나를 수행하면 됩니다.
- 콘솔에서 콘솔의 측정항목 탐색기를 엽니다. Google Cloud Google Cloud
  
  측정항목 탐색기 페이지로 이동
- RL 워크로드 성능 대시보드를 사용합니다.
대시보드의 측정항목 필드에서 prometheus.googleapis.com/로 시작하는 측정항목을 검색합니다. 사용 가능한 측정항목은 애플리케이션에서 계측한 측정항목에 해당합니다. 이러한 측정항목의 예는 다음과 같습니다.
- prometheus.googleapis.com/rl_loop_duration_histogram/
- prometheus.googleapis.com/rl_sample_samples_total/
- prometheus.googleapis.com/rl_environment_reward_mean_total/
필터링 및 그룹화: 측정항목 탐색기의 필터를 사용하여 속성으로 추가한 시맨틱 규칙을 활용할 수 있습니다. 예를 들어 다음은 특정 실행 및 알고리즘의 루프 기간을 지정합니다.
- 필터: metric.label."rl_run_id" == "run-42"
- 필터: metric.label."rl_algorithm" == "PPO"
- 그룹화 기준: metric.label."rl_environment_name"을 사용하여 환경 전반의 성능을 비교합니다.

Trace에서 trace 보기

분산 trace는 작업 타임라인을 제공하고 RL 시스템 내에서 실행 흐름을 디버깅하는 데 도움이 됩니다.

콘솔에서 콘솔의 Trace 탐색기 를 엽니다. Google Cloud Google Cloud

Trace 탐색기 페이지로 이동
trace를 쿼리하고 필터링할 수 있습니다. "service.name": "rl-training-service"를 리소스 속성으로 설정했으므로 resource.labels.service_name="rl-training-service"로 trace를 필터링할 수 있습니다.

trace 내의 개별 스팬은 RL 워크로드의 여러 부분을 나타냅니다. 이러한 스팬에는 애플리케이션에서 trace를 계측한 방법에 따라 외부 서비스 호출 또는 RL 루프의 여러 단계가 포함될 수 있습니다.

RL 시맨틱 규칙 및 골든 신호

이 섹션에는 RL 애플리케이션이 GKE에서 실행될 때 발생하는 문제를 식별하는 데 도움이 되는 OpenTelemetry 측정항목이 나열되어 있습니다.

이 섹션의 정보를 사용하여 다음을 수행합니다.

애플리케이션에 수집할 측정항목과 trace를 결정합니다.
애플리케이션에서 수집한 측정항목과 trace 데이터를 보고 사용하는 방법을 결정합니다.

OpenTelemetry를 사용하여 RL 워크로드를 효과적으로 모니터링하려면 '골든 신호'에 집중하는 것이 좋습니다. 골든 신호는 서비스의 상태에 대한 개요를 제공하는 서비스의 4가지 주요 측정항목(지연 시간, 트래픽, 오류, 포화도)입니다. 이러한 측정항목으로 RL 애플리케이션을 계측하면 성능 문제를 빠르게 이해하고 디버깅할 수 있습니다.

다음 섹션에는 RL 컨텍스트에서 나타내는 골든 신호별로 분류된 시맨틱 규칙과 측정항목 이름 이 있습니다.

RL 시맨틱 규칙

다음은 측정항목의 속성입니다. 이러한 속성은 Monitoring에서 필터링 및 분석을 위한 컨텍스트를 제공합니다.

RL_SYSTEM = "rl.system": RL 시스템 또는 프레임워크의 이름 (예: 'MyCustomRL')
RL_SYSTEM_VERSION = "rl.system.version": RL 시스템 버전
RL_RUN_ID = "rl.run.id": 특정 학습 실행의 고유 식별자
RL_ALGORITHM = "rl.algorithm": 사용 중인 RL 알고리즘 (예: 'PPO', 'DQN')
RL_ENVIRONMENT_NAME = "rl.environment.name": RL 환경의 이름 (예: 'CartPole-v1')
RL_MODEL_NAME = "rl.model.name": 정책/값 모델의 이름 또는 식별자
RL_LOOP = "rl.loop": 기본 학습 루프의 식별자
RL_LOOP_ITERATION = "rl.loop.iteration": RL 루프의 현재 반복 횟수
RL_SAMPLE = "rl.sample": 샘플링 단계의 컨텍스트
RL_SAMPLE_EPISODES = "rl.sample.episodes": 샘플링된 에피소드 수
RL_SAMPLE_STEPS = "rl.sample.steps": 샘플링된 단계 수
RL_SAMPLE_BATCH_SIZE = "rl.sample.batch_size": 샘플링 중에 사용된 배치 크기
RL_REWARD = "rl.reward": 보상 계산의 컨텍스트
RL_REWARD_BATCH_SIZE = "rl.reward.batch_size": 보상 계산의 배치 크기
RL_REWARD_SANDBOX = "rl.reward.sandbox": 보상 계산 샌드박스의 식별자
RL_TRAIN = "rl.train": 학습 단계의 컨텍스트
RL_TRAIN_STEPS = "rl.train.steps": 학습 단계 수
RL_TRAIN_BATCH_SIZE = "rl.train.batch_size": 학습 중에 사용된 배치 크기
RL_TRAIN_TOKENS = "rl.train.tokens": 학습 중에 처리된 토큰 수
RL_SYNC = "rl.sync": 동기화 작업의 컨텍스트
RL_SYNC_BYTES = "rl.sync.bytes": 동기화 중에 전송된 바이트
RL_SYNC_SOURCE = "rl.sync.source": 동기화 소스
RL_SYNC_DESTINATION = "rl.sync.destination": 동기화 대상

골든 신호 및 RL 측정항목

다음 섹션에는 4가지 골든 신호(지연 시간, 트래픽, 오류, 포화도)와 관련된 RL 측정항목이 나열되어 있습니다.

골든 신호에 대한 자세한 내용은 4가지 골든 신호를 Google 사이트 안정성 엔지니어링 (SRE) 교재의 6장에서 참조하세요.

지연 시간

주요 작업을 완료하는 데 얼마나 걸리나요? 지연 시간이 길면 주요 작업을 완료할 때 지연이 발생할 수 있습니다. 다음 측정항목은 RL 애플리케이션이 GKE에서 실행될 때 발생하는 지연 시간 문제를 식별하는 데 도움이 될 수 있습니다.

rl.loop.duration (히스토그램): 루프 기간이 길면 전체 학습 프로세스의 속도가 느려집니다. 이를 모니터링하면 RL 주기의 모든 부분에서 성능 회귀를 식별하는 데 도움이 됩니다.
rl.sample.duration (히스토그램): 샘플링 속도가 느리면 학습을 위해 새 데이터가 생성되는 속도에 직접적인 영향을 미칩니다.
rl.reward.duration (히스토그램): 보상 계산은 복잡할 수 있습니다. 지연 시간을 추적하면 이 중요한 단계를 최적화하는 데 도움이 됩니다.
rl.train.duration (히스토그램): 학습 시간은 반복 속도에 매우 중요합니다. 여기에서 급증하면 학습 알고리즘 또는 하드웨어의 문제를 나타낼 수 있습니다.
rl.sync.duration (히스토그램): 효율적인 동기화는 분산 RL에서 매우 중요합니다. 동기화 시간이 길면 오래된 데이터가 발생하고 학습 속도가 느려질 수 있습니다.
rl.step.duration (히스토그램): 개별 환경 단계의 세분화된 지연 시간입니다.

트래픽 및 처리량

얼마나 많은 작업이 진행되고 있나요? 처리량이 낮으면 리소스 사용이 비효율적일 수 있습니다. 다음 측정항목은 RL 애플리케이션이 GKE에서 실행될 때 발생하는 트래픽 또는 처리량 문제를 식별하는 데 도움이 될 수 있습니다.

rl.sample.samples (카운터): 수집된 경험 데이터의 양을 나타냅니다. 드롭은 샘플링 프로세스의 문제를 나타냅니다.
rl.sample.episodes (카운터): 실행된 완료된 에피소드 수를 추적합니다.
rl.train.steps (카운터): 최적화 단계 측면에서 학습 진행률을 측정합니다.
rl.train.tokens (카운터): 처리된 총 토큰을 추적합니다. 이 측정항목은 대규모 모델 RL과 관련이 있습니다.
rl.tokens.rate / rl.tokens.rate_per_gpu (게이지/비율): 특히 토큰 기반 모델에서 학습 속도와 효율성을 직접 측정합니다.
rl.samples.rate / rl.samples.rate_per_gpu (게이지/비율): 시스템이 새 샘플을 수집하는 속도를 측정합니다.

오류

성능 또는 실행 오류가 있나요? RL에서 '오류'는 예기치 않은 동작 또는 성능 저하로 나타날 수 있습니다. 다음 측정항목은 RL 애플리케이션이 GKE에서 실행될 때 발생하는 오류를 식별하는 데 도움이 될 수 있습니다.

rl.environment.reward.mean (게이지): 기존 오류는 아니지만 평균 보상이 급격히 감소 하는 것은 에이전트 또는 환경 상호작용에 문제가 있음을 나타내는 중요한 신호입니다. 이 측정항목은 학습 진행률과 에이전트 성능을 직접 반영합니다.
rl.environment.episode.length.mean (게이지): 보상과 마찬가지로 에피소드 길이의 예기치 않은 변경은 문제를 나타낼 수 있습니다.
rl.train.loss (게이지): 학습 손실의 갑작스러운 증가 또는 불규칙한 동작은 모델이 효과적으로 학습하지 못하고 있음을 나타냅니다. 학습 안정성과 성공의 기본 지표입니다.

포화도

시스템이 오버로드되었나요? 포화도가 높으면 성능이 저하될 수 있습니다. 다음 측정항목은 RL 애플리케이션이 GKE에서 실행될 때 발생하는 포화도 문제를 식별하는 데 도움이 될 수 있습니다.

rl.train.mfu (게이지): 모델 Flop 사용률 (MFU)입니다. 학습 중에 컴퓨팅 리소스 (예: GPU 또는 TPU)가 얼마나 효과적으로 사용되고 있는지 나타냅니다. MFU가 낮으면 활용도가 낮거나 병목 현상이 있음을 나타냅니다.

GKE에서 강화 학습 워크로드 모니터링 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.