GKE で強化学習ワークロードをモニタリングする

Autopilot Standard

このドキュメントでは、Google Kubernetes Engine（GKE）で実行されている Python ベースの強化学習（RL）アプリケーションの主要な指標とトレースを生成、収集、表示する方法について説明します。

このドキュメントでは、次の方法について説明します。

RL アプリケーションを計測して、指標とトレースを出力します。使用される計測は、OpenTelemetry 形式に従う指標とトレース用です。
アプリケーションが GKE で実行されているときに指標とトレースを収集します。データは、GKE 用 Managed OpenTelemetry（プレビュー）を使用して収集されます。
収集された指標を Cloud Monitoring で、トレースを Cloud Trace で表示します。
OpenTelemetry のセマンティック規約とゴールデンシグナルに基づいて、重要な RL 指標を特定して理解します。ゴールデンシグナルは、サービスの健全性の概要を示す 4 つの主要な指標（レイテンシ、トラフィック、エラー、飽和度）です。

始める前に

指標とトレースデータを使用してモニタリングする Python ベースの RL アプリケーションがあることを確認します。
課金が有効になっている Google Cloud プロジェクトがあることを確認します。
GKE バージョン 1.34.1-gke.2178000 以降を実行している GKE クラスタが必要です。これは、GKE 用マネージド OpenTelemetry（プレビュー）が利用可能なバージョンです。
次の Google Cloud API を有効にします。
- container.googleapis.com（GKE）
- monitoring.googleapis.com（モニタリング）
- cloudtrace.googleapis.com（トレース）
- telemetry.googleapis.com（OpenTelemetry Telemetry API）
これらの API は gcloud を使用して有効にできます。
```
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 の料金で課金され、トレースは Cloud 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 で指標とトレースデータの収集を有効にする

アプリケーションの実行中にアプリケーションが生成するテレメトリーデータを収集するには、Managed OpenTelemetry for GKE（プレビュー）を使用します。この機能は、指標やトレースなどのテレメトリーデータを収集し、Google Cloud Observability に送信します。

GKE 用マネージド OpenTelemetry を有効にして構成するには、次の操作を行います。

アプリケーションが実行されるクラスタで、GKE 用 Managed OpenTelemetry を有効にします。これを行うには、クラスタで GKE 用マネージド OpenTelemetry を有効にするの手順に沿って操作します。

環境変数を使用してアプリケーションの Deployment にアノテーションを付け、OpenTelemetry SDK がマネージドコレクタの OTLP エンドポイントにテレメトリーデータを送信するようにします。Python ベースの RL アプリケーションの場合、GKE 用マネージド OpenTelemetry の自動構成機能は使用できません。

代わりに、Deployment マニフェストのコンテナ仕様に次の 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 クラスタで実行されたときに、指標とトレースが Google Cloud Observability に送信されます。

このテレメトリーデータは、モニタリングとトレースで確認できます。

Monitoring で指標を表示する

マネージド OpenTelemetry が有効になっている GKE で RL アプリケーションが実行されると、指標が Monitoring に送信されます。通常、指標は prometheus.googleapis.com/ ドメインで使用できます。

Monitoring でカスタム RL 指標を表示する手順は次のとおりです。

ダッシュボードで RL 指標を表示するには、次のいずれかを行います。
- Google Cloud コンソールで、 Google Cloud コンソールの [Metrics Explorer] を開きます。
  
  [Metrics Explorer] ページに移動
- 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/
フィルタリングとグループ化: Metrics Explorer のフィルタを使用して、属性として追加したセマンティック規約を活用できます。たとえば、次の例では、特定の実行とアルゴリズムのループ期間を指定しています。
- フィルタ: metric.label."rl_run_id" == "run-42"
- フィルタ: metric.label."rl_algorithm" == "PPO"
- グループ化: metric.label."rl_environment_name" を使用して、環境間のパフォーマンスを比較します。

Trace でトレースを表示する

分散トレースはオペレーションのタイムラインを提供し、RL システム内の実行フローのデバッグに役立ちます。

Google Cloud コンソールで、 Google Cloud コンソールの [Trace エクスプローラ] を開きます。

[Trace エクスプローラ] ページに移動
トレースをクエリしてフィルタできます。"service.name": "rl-training-service" をリソース属性として設定したため、resource.labels.service_name="rl-training-service" でトレースをフィルタできます。

トレース内の個々のスパンは、RL ワークロードのさまざまな部分を表します。これらのスパンには、アプリケーションでトレースを計測する方法に応じて、外部サービスへの呼び出しや RL ループのさまざまなフェーズが含まれる場合があります。

RL セマンティック規約とゴールデンシグナル

このセクションでは、GKE で RL アプリケーションの実行中に発生する問題を特定するのに役立つ OpenTelemetry 指標の一覧を示します。

このセクションの情報を使用して、次の操作を行います。

アプリケーションで収集する指標とトレースを決定します。
アプリケーションから収集された指標とトレースデータの表示方法と使用方法を決定します。

OpenTelemetry を使用して RL ワークロードを効果的にモニタリングするには、「ゴールデンシグナル」に注目するとよいでしょう。ゴールデンシグナルは、サービスの健全性の概要を示す 4 つの重要な指標（レイテンシ、トラフィック、エラー、飽和度）です。これらの指標を使用して RL アプリケーションを計測することで、パフォーマンスの問題をすばやく把握してデバッグできます。

以降のセクションでは、RL コンテキストで表されるセマンティック規約とゴールデンシグナル別に分類された指標名について説明します。

RL セマンティック規約

指標の属性は次のとおりです。これらの属性は、モニタリングでのフィルタリングと分析のコンテキストを提供します。

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 指標を一覧表示します。

ゴールデンシグナルの詳細については、Google のサイト信頼性エンジニアリング（SRE）に関する書籍の第 6 章の4 つのゴールデンシグナルをご覧ください。

レイテンシ

キーオペレーションの完了にはどのくらいの時間がかかりますか？レイテンシが高い場合は、主要なオペレーションの完了に遅延が発生している可能性があります。次の指標は、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（ゲージ）: トレーニング損失の急激な増加や不安定な動作は、モデルが効果的に学習していないことを示します。トレーニングの安定性と成功を示す基本的な指標。

飽和度

システムが過負荷状態になっていないか確認します。飽和度が高いと、パフォーマンスが低下する可能性があります。次の指標は、GKE で RL アプリケーションを実行したときに発生する飽和状態の問題を特定するのに役立ちます。

rl.train.mfu（ゲージ）: モデルの FLOP 使用率（MFU）。トレーニング中にコンピューティングリソース（GPU や TPU など）がどれだけ効果的に使用されているかを示します。MFU が低い場合は、使用率が低いか、ボトルネックが発生している可能性があります。

GKE で強化学習ワークロードをモニタリングする コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。