監視エージェントのユースケース¶

監視エージェントを適用する方法の例については、以下の監視ユースケースを参照してください。

• 大規模監視を有効にする
• 大規模なワークロードに対する高度なエージェントメモリーチューニングの実行
• Report accuracy for challengers
• 指標のレポート
• Sparkの環境のモニタリング
• MLOps CLIを使用したモニタリング

大規模監視を有効にする¶

大規模な監視をサポートするために、MLOpsライブラリは、クライアント側で元のデータから統計情報を計算する方法を提供します。 そして、DataRobot MLOpsサービスに元の特徴量と予測値を報告する代わりに、クライアントは特徴量と予測データを含まない匿名化された統計情報を報告することができます。 クライアント側で計算された予測データの統計情報を報告することは、元データの報告と比較して、特に大規模な場合（数十億行の特徴量と予測値）に最適（かつ高パフォーマンスな）方法です。 また、クライアント側の集計では、特徴量値の集計を送信するだけなので、実際の特徴量値を公開したくない環境に適しています。

大規模監視機能を有効にするには、特徴量型の設定のいずれかを行う必要があります。 この設定ではデータセットの特徴量型を指定しますが、コード内でプログラム的に（セッターを使用して）、または環境変数を定義することによって行います。

mlops = MLOps() \
    .set_stats_aggregation_feature_types_filename("/tmp/feature_types.json") \
    .set_aggregation_max_records(10000) \
    .set_prediction_timestamp_column("ts", "yyyy-MM-dd HH:mm:ss") \
    .set_segment_attributes("country") \
    .init() 

mlops = MLOps() \
    .set_stats_aggregation_feature_types_json([{"name": "feature_name_f1","feature_type": "date", "format": "%m-%d-%y",}]) \
    .set_aggregation_max_records(10000) \
    .set_prediction_timestamp_column("ts", "yyyy-MM-dd HH:mm:ss") \
    .set_segment_attributes("country") \
    .init() 

大規模な監視機能は、Python、Javaソフトウェア開発キット（SDK）、およびMLOps Spark Utilsライブラリで利用できます。

report_aggregated_predictions_data(
   self, 
   features_df,
   predictions, 
   class_names,
   deployment_id, 
   model_id
) 

reportAggregatePredictionsData(
    Map<String, 
    List<Object>> featureData,
    List<?> predictions,
    List<String> classNames
) 

PredictionStatisticsParameters.Builder()
        .setChannelConfig(channelConfig)
        .setFeatureTypes(featureTypes)
        .setDataFrame(df)
        .build();
predictionStatisticsParameters.report(); 

サポートされている特徴量タイプのマッピング¶

現在、大規模な監視では、数値およびカテゴリーの特徴量がサポートされています。 この監視方法を設定する際には、各特徴量名を対応する特徴量タイプ（数値またはカテゴリー）にマッピングする必要があります。 特徴量タイプを特徴量名にマッピングする場合、スコアリングコードモデル用のメソッドと、それ以外のすべてのモデル用のメソッドがあります。

大規模なワークロードに対する高度なエージェントメモリーチューニングの実行¶

監視エージェントのデフォルト設定は、平均的なワークロードでうまく機能するように調整されています。ただし、DataRobot MLOpsに転送するためにエージェントがグループ化するレコード数を増やすと、エージェントの総メモリー使用量がワークロードの増加に対応するために着実に増加します。 エージェントがユースケースのワークロードに確実に対応できるようにするには、エージェントの総メモリー使用量を見積もった後、エージェントのメモリー割り当て量を設定するか、最大レコードグループのサイズを設定します。

エージェントでのメモリー使用量の見積もり¶

監視エージェントのおおよそのメモリー使用量（バイト単位）を見積もるときは、報告される各特徴量が平均10 bytesのメモリーを必要とすることを想定してください。 次に、報告された特徴量数（num_samplesで表示）とサンプル数（num_featuresで表示）から生の予測データを含む各メッセージのメモリー使用量を推定できます。 各メッセージは約10 bytes × num_features × num_samplesのメモリーを使用します。

一度に多数のレコードをグループ化する場合は、エージェントがagentMaxAggregatedRecords設定で設定された上限に達するまでメッセージをグループ化することを考慮に入れてください。 さらに、その時点で、エージェントはhttpConcurrentRequest設定で上限設定されたメモリーにメッセージを保持します。

上記の計算を組み合わせて、次の式でエージェントのメモリー使用量 （および必要なメモリー割り当て量）を見積もることができます。

memory_allocation = 10 bytes × num_features × num_samples × max_group_size × max_concurrency

変数は次のように定義されています。

• num_features：データセット内の特徴量（列）数。

• num_samples：MLOpsレポート関数の1回の呼び出しで報告される行数。

• max_group_size： エージェント設定ファイルのagentMaxAggregatedRecordsによって設定された各HTTPリクエストに集約されたレコード数。

• max_concurrency： エージェント設定ファイルのhttpConcurrentRequestによって設定された同時HTTPリクエスト数。

上記のデータセットとエージェント設定情報を使用して必要なエージェントのメモリー割り当てを計算すると、エージェント設定をファインチューニングして、パフォーマンスとメモリー使用のバランスを最適化するのにこの情報が役に立ちます。

エージェントのメモリー割り当ての設定¶

ユースケースに対するエージェントのメモリー要件がわかったら、MLOPS_AGENT_JVM_OPT 環境変数を使用して、エージェントのJava仮想マシン（JVM）のメモリー割り当て量を増やすことができます。

MLOPS_AGENT_JVM_OPT=-Xmx2G 

グループの最大サイズの設定¶

または、ユースケースのエージェントのメモリー要件を減らすために、 エージェント設定ファイルのagentMaxAggregatedRecordsによって設定された、エージェントの最大グループサイズ制限を減らすことができます。

# Maximum number of records to group together before sending to DataRobot MLOps
agentMaxAggregatedRecords: 10 

この設定を1に下げると、エージェントによるレコードのグループ化が無効になります。

Report accuracy for challengers¶

Because the agent may send predictions with an association ID, even if the deployment in DataRobot doesn’t have an association ID set, the agent's API endpoints recognize the __DataRobot_Internal_Association_ID__ column as the association ID for the deployment. This enables accuracy tracking for models reporting prediction data through the agent; however, the __DataRobot_Internal_Association_ID__ column isn't available to DataRobot when predictions are replayed for challenger models, meaning that DataRobot MLOps can't record accuracy for those models due to a missing association ID. To track accuracy for challenger models through the agent, set the association ID on the deployment to __DataRobot_Internal_Association_ID__ during deployment creation or in the accuracy settings. Once you configure the association ID with this value, all future challenger replays will record accuracy for challenger models.

指標のレポート¶

予測環境をDataRobotにネットワーク接続できない場合、代わりに監視エージェントのレポートをオフラインで使用できます。

1. 予測環境で、filesystemスプーラータイプを使用するように、MLOpsライブラリを設定します。 MLOpsライブラリは、/disconnected/predictions_dirなどの設定されたディレクトリに指標を報告します。

2. DataRobotにネットワーク接続されているマシンで監視エージェントを実行します。

3. FILESYSTEMスプーラータイプを使用し、ローカルディレクトリから入力を受け取るようにエージェントを設定します。例：/connected/predictions_dir。

4. ディレクトリの内容を/disconnected/predictions_dir接続先の環境に移行します/connected/predictions_dir。

スコアリングコードモデルのレポート¶

監視エージェントのレポートを使用して、ダウンロードしたスコアリングコードモデルの監視指標をDataRobotに送信することもできます。 このユースケースの例を、examples/java/CodeGenExampleのMLOpsエージェントtarballで参照してください。

Sparkの環境のモニタリング¶

監視エージェントの一般的なユースケースは、Spark環境でのスコアリングのモニタリングで、スコアリングはSparkで行われ、予測と特徴量をDataRobotにレポートしたいと考えています。 通常、Sparkは複数ノードセットアップを使用するため、共有の一貫性のあるファイルシステムはSparkのインストールでは一般的ではなく、エージェントのfileystemスプーラーチャネルを使用することは困難です。

これを回避するには、RabbitMQまたはAWS SQSのようなネットワークベースのチャネルを使用します。 これらのチャネルは、複数のライターおよび単一（または複数）のリーダーと連携できます。

以下の例では、MLOps Spark Utilモジュールを使用して、Sparkシステム上でエージェント監視を設定する方法を説明し、Sparkフレームワークで行われたスコアリング結果を報告する方法を提供します。 MLOpsのJavaサンプルディレクトリexamples/java/SparkUtilsExample/にあるMLOpsSparkUtilsモジュールのドキュメントを参照してください。

Sparkサンプルのソースコードは、次の3つのステップを実行します。

1. スコアリングJARファイルを指定すると、データをスコアリングし、データフレームで結果を提供します。
2. 特徴量のデータフレームと予測結果を単一のデータフレームに統合します。
3. mlops_spark_utils.MLOpsSparkUtils.reportPredictionsヘルパーを呼び出し、マージされたデータフレームを使用して予測をレポートします。

関数がデータフレームを介してデータを取得する限り、任意のモデルで生成された予測をmlops_spark_utils.MLOpsSparkUtils.reportPredictionsを使用してレポートできます。

通信チャネルとしてRabbitMQを使用したこの例には、チャネル設定が含まれています。 Sparkは分散フレームワークであるため、DataRobotではワーカーが実行されているノードに関係なく、Sparkワーカーが監視データを同じチャネルに送信できるようにするために、RabbitMQやAWS SQSなどのネットワークベースのチャネルを必要とします。

Sparkの前提条件¶

次の手順は、Sparkの監視ユースケースを実行するために必要な前提条件の概要を示しています。

1. コンテナ内でスプーラー（この例ではRabbitMQ）を実行します。

   • このコマンドは、RabbitMQの管理コンソールも実行します。
   • ブラウザーからhttp://localhost:15672（ユーザー名 =guest、パスワード =guest）でコンソールにアクセスできます。

   • コンソールで、以下の./run_example.shスクリプトを実行したときのメッセージキューの動作を確認します。

     docker run -d -p 15672:15672 -p 5672:5672 --name rabbitmq-spark-example rabbitmq:3-management 
     

2. 監視エージェントを設定して開始します。

   • エージェントtarballで提供されるクイックスタートガイドに従ってください。
   • RabbitMQと通信するようにエージェントを設定します。

   • 以下に一致するようにエージェントチャネル設定を編集します。

     - type: "RABBITMQ_SPOOL"
         details: {name: "rabbit", queueUrl: "amqp://localhost:5672", queueName: "spark_example"} 
     

3. mvnを使用する場合は、サンプルをテストする前にを実行して、datarobot-mlops JARをローカルのmvnリポジトリにインストールします。

   ./examples/java/install_jar_into_maven.sh 
   

   このコマンドは、シェルスクリプトを実行して、使用しているSparkバージョン（<version>はエージェントバージョンを表す）に応じて、mlops-utils-for-spark_2-<version>.jarまたはmlops-utils-for-spark_3-<version>.jarファイルのいずれかをインストールします。

4. サンプルのJARファイルを作成し、JAVA_HOME環境変数を設定してから、makeを実行してコンパイルします。

   • Spark2/Java8の場合：export JAVA_HOME=$(/usr/libexec/java_home -v 1.8)
   • Spark3/Java11の場合：export JAVA_HOME=$(/usr/libexec/java_home -v 11)

5. Sparkをローカルにインストールして実行します。

   • Hadoop 3.3+用に構築されたSpark 2（2.x.x）またはSpark 3（3.x.x）の最新バージョンをダウンロードします。 最新のSpark 3バージョンをダウンロードするには、 Apache Sparkのダウンロードページを参照してください。

     備考

     以下のコマンドおよびディレクトリの<version>プレースホルダーを、使用しているSparkおよびHadoopのバージョンに置き換えます。

   • tarball（tar xvf ~/Downloads/spark-3.2.<version>-bin-hadoop<version>.tgz）を解凍します。

   • spark-<version>-bin-hadoop<version>ディレクトリで、Sparkクラスターを起動します。

     sbin/start-master.sh -i localhost`
     sbin/start-slave.sh -i localhost -c 8 -m 2G spark://localhost:7077 
     

   • インストールが成功したことを確認します。

     bin/spark-submit --class org.apache.spark.examples.SparkPi --master spark://localhost:7077 --num-executors 1 --driver-memory 512m --executor-memory 512m --executor-cores 1 examples/jars/spark-examples_*.jar 10 
     

   • Sparkビンディレクトリを$PATHに追加します。

     env SPARK_BIN=/opt/ml/spark-3.2.1-bin-hadoop3.*/bin ./run_example.sh 
     

   備考

   監視エージェントはSpark2もサポートしています。

Sparkのユースケース¶

上記の前提条件を満たした後、Sparkのサンプルを実行します。

1. モデルパッケージを作成し、デプロイを初期化します。

   ./create_deployment.sh 
   

   DataRobot UIを使用して、外部モデルパッケージを作成し、デプロイすることもできます。

2. デプロイの環境変数と、デプロイの作成時に返されたモデルを、コピーしてシェルに貼り付けることにより設定します。

   export MLOPS_DEPLOYMENT_ID=<deployment_id>
   export MLOPS_MODEL_ID=<model_id> 
   

3. 予測を生成し、統計をDataRobotにレポートします。

   run_example.sh 
   

4. スプーラータイプ（Sparkジョブと監視エージェント間の通信チャネル）を変更する場合：

   • src/main/scala/com/datarobot/dr_mlops_spark/Main.scalaにあるScalaコードを編集します。

   • 次の行を変更して、必要なチャネル設定を含めます。

     val channelConfig = "output_type=rabbitmq;rabbitmq_url=amqp://localhost;rabbitmq_queue_name=spark_example" 
     

   • makeを実行してコードを再コンパイルします。

MLOps CLIを使用したモニタリング¶

MLOpsは、MLOpsアプリケーションと対話するためのコマンドラインインターフェイス（CLI）をサポートしています。 CLIは、デプロイとモデルパッケージの作成、データセットのアップロード、予測と実測に関する指標のレポートなど、ほとんどのMLOpsアクションに使用できます。

使用可能な操作と構文例のリストについては、MLOps CLIヘルプページを使用してください。

mlops-cli [-h]