プロダクション

ML パイプラインを本番環境用に準備するには、次の操作を行う必要があります。

• パイプライン用のコンピューティング リソースをプロビジョニングする
• ロギング、モニタリング、アラートを実装する

コンピューティング リソースのプロビジョニング

ML パイプラインを実行するには、RAM、CPU、GPU/TPU などのコンピューティング リソースが必要です。十分なコンピューティングがないと、パイプラインを実行できません。したがって、パイプラインが本番環境で実行するために必要なリソースをプロビジョニングするのに十分な割り当てを取得してください。

• サービング、トレーニング、検証のパイプライン。これらのパイプラインには、TPU、GPU、CPU が必要です。ユースケースに応じて、異なるハードウェアでトレーニングとサービングを行うことも、同じハードウェアを使用することもできます。たとえば、トレーニングは CPU で行い、サービングは TPU を使用する場合があります。一般的に、大規模なハードウェアでトレーニングを行い、小規模なハードウェアでサービングを行うのが一般的です。

  ハードウェアを選択する際は、次の点を考慮してください。

  • 安価なハードウェアでトレーニングできますか？
  • 別のハードウェアに切り替えるとパフォーマンスは向上しますか？
  • モデルのサイズと、パフォーマンスを最適化するハードウェア
  • モデルのアーキテクチャに基づいて、最適なハードウェアは何ですか？
  注: ハードウェア間でモデルを切り替える場合は、モデルの移行にかかる時間と労力を考慮してください。ハードウェアを切り替えると、モデルの実行コストが安くなる可能性がありますが、そのためのエンジニアリング作業が節約額を上回る可能性があります。また、エンジニアリング作業は他の作業に優先して行う方がよい場合もあります。

• データ パイプライン。データ パイプラインには、RAM と CPU の割り当てが必要です（ネットワーク容量などの他の一般的な Borg リソースも必要です）。 トレーニング データセットとテスト データセットを生成するためにパイプラインに必要な割り当て量を推定する必要があります。

パイプラインごとに割り当てを割り当てない場合があります。代わりに、パイプラインが共有する割り当てを割り当てることができます。このような場合は、すべてのパイプラインを実行するのに十分な割り当てがあることを確認し、単一の誤ったパイプラインがすべての割り当てを消費しないようにモニタリングとアラートを設定します。

割り当ての見積もり

データ パイプラインとトレーニング パイプラインに必要な割り当てを見積もるには、見積もりの基準となる類似のプロジェクトを見つけます。サービング割り当てを概算するには、サービスの 1 秒あたりのクエリ数を予測します。これらのメソッドはベースラインを提供します。テストフェーズでソリューションのプロトタイピングを開始すると、より正確な割り当ての見積もりを取得できるようになります。

割り当てを見積もる際は、本番環境のパイプラインだけでなく、進行中のテストの割り当ても考慮してください。

理解度チェック

予測を提供するハードウェアを選択する場合は、モデルのトレーニングに使用したハードウェアよりも強力なハードウェアを常に選択する必要があります。

誤り

正解です。通常、トレーニングにはサービングよりも大きなハードウェアが必要です。

正しい

ロギング、モニタリング、アラート

本番環境モデルの動作をロギングしてモニタリングすることは非常に重要です。堅牢なモニタリング インフラストラクチャにより、モデルが信頼性の高い高品質な予測を提供していることを確認できます。

適切なロギングとモニタリングの手法は、ML パイプラインの問題を事前に特定し、ビジネスへの影響を軽減するのに役立ちます。問題が発生した場合は、アラートでチームのメンバーに通知され、包括的なログによって問題の根本原因を診断できます。

ロギングとモニタリングを実装して、ML パイプラインの次の問題を検出する必要があります。

パイプライン	モニタリング
サービス提供	トレーニング データと比較したサービング データのスキューまたはドリフト 予測の歪みまたはドリフト データ型の問題（値の欠落や破損など） 割り当て使用量 モデル品質指標 本番環境モデルの品質の計算は、トレーニング中のモデルの品質の計算とは異なります。本番環境では、予測を比較するためのグラウンド トゥルースにアクセスできるとは限りません。代わりに、モデルの品質のプロキシとして機能する指標を取得するカスタム モニタリング インストルメンテーションを作成する必要があります。たとえば、メールアプリでは、どのメールがスパムであるかをリアルタイムで知ることはできません。代わりに、メールユーザーが迷惑メールに移動したメールの割合をモニタリングできます。数値が 0.5% から 3% に急増した場合、モデルに問題がある可能性があります。 プロキシ指標の生の値よりも、その変化を比較する方が有益です。
データ	特徴値のスキューとドリフト ラベル値のスキューとドリフト データ型の問題（値の欠落や破損など） 割り当て使用率 割り当て上限にまもなく達する
トレーニング	トレーニング時間 トレーニングの失敗 割り当て使用量
検証	テスト データセットのスキューまたはドリフト

また、次のロギング、モニタリング、アラートも必要になります。

• レイテンシ。予測の配信にはどのくらいの時間がかかりますか？
• 停止。モデルが予測の配信を停止しましたか？

理解度チェック

ML パイプラインのロギングとモニタリングを行う主な理由は何ですか？

ユーザーに影響が及ぶ前に問題をプロアクティブに検出する

割り当てとリソースの使用状況を追跡する

潜在的なセキュリティ問題を特定する

上記のすべて

正解です。ML パイプラインのロギングとモニタリングを行うことで、問題が深刻になる前に問題を防止して診断できます。

モデルのデプロイ

モデルのデプロイでは、次の内容を文書化します。

• デプロイを開始してロールアウトを増やすために必要な承認。
• モデルを本番環境に移行する方法。
• モデルがデプロイされる場所（ステージング環境やカナリア環境がある場合など）。
• デプロイが失敗した場合の対処方法。
• すでに本番環境にあるモデルをロールバックする方法。

モデル トレーニングを自動化した後は、検証とデプロイを自動化します。デプロイを自動化すると、責任が分散され、デプロイが 1 人の担当者によってボトルネックになる可能性が低くなります。また、潜在的なミスを減らし、効率と信頼性を高め、オンコール ローテーションと SRE サポートを可能にします。

通常、新しいモデルは一部のユーザーにデプロイして、モデルが想定どおりに動作することを確認します。問題がなければ、デプロイを続行します。そうでない場合は、デプロイをロールバックして、問題の診断とデバッグを開始します。