Kubernetes上の機械学習プラットフォームの実践

背景

これまで、音楽アルゴリズムのモデルトレーニングタスクは、物理マシン上で開発、デバッグ、スケジュールされていました。各アルゴリズムチームは独自の独立した物理マシンを使用しているため、いくつかの問題が発生します。たとえば、物理マシンは分散しており、統一された管理がないため、マシンの使用状況や所有権の記録は主にドキュメント内のテーブルに依存しています。企業間でマシンリソースを割り当てるには、異なるコンピュータールームにマシンを再配置する必要がある場合があり、これには時間と労力がかかります。また、開発やスケジュールのタスクを複数人で分担して行うため、環境がお互いに影響を及ぼし、リソースの競合も発生します。現状を踏まえると、問題点は以下のようにまとめられます。

リソース使用率が低い: 一部のマシンのリソース使用率が低いため、各ビジネスのさまざまな段階に応じてシステムを迅速かつ動的にスケールアップおよびスケールダウンして、合理的なリソース割り当てを実現し、全体的なリソース使用率を向上させることが不可能です。
環境の相互影響: 複数の人が分離せずに同じ開発マシンを共有、テスト、スケジュールすると、環境と共有リソースの相互影響と競合が発生する可能性があります。
監視とアラームの欠如: 物理マシンモードでは、タスクの監視とアラーム機能がないため、タスクを操作および保守できないか、効率が低下します。

リソースがグローバルに統一的かつ合理的に割り当てられない場合、負荷の不均衡が発生し、リソースを最大限に活用できなくなります。

Kubernetesへの試み

Kubernetes とその関連拡張機能は、急速な拡張と縮小、環境の分離、リソースの監視などの問題をうまく解決できます。ここで、物理マシンを集めて Kubernetes クラスターを構築します。アルゴリズムの同僚たちのこれまでの作業方法を分析することにより、機械学習プラットフォーム (GoblinLab) は、Kubernetes に基づく 2 つのソリューション、つまり、それぞれタスク開発とタスクスケジューリングの 2 つのシナリオを対象とした、オンライン開発およびデバッグコンテナー環境とコンテナー化されたタスクスケジューリングを提供することにしました。

タスク開発

アルゴリズムの同僚を物理マシンからコンテナ化された環境に移行する際の学習コストを最小限に抑えるために、GoblinLab システムでは基本的に Kubernetes コンテナをクラウドホストとして使用します。コンテナイメージは、さまざまなバージョンの Tensoflow イメージ (基礎レイヤーは Ubuntu) に基づいており、ビッグデータ開発環境 (Hadoop、Hive、Spark などのクライアント) を統合し、よく使用されるソフトウェアをインストールします。また、コンテナ環境では使いやすさを考慮して、Jupyter Lab、SSH ログイン、コードサーバー (VSCode) の 3 つの使用方法を提供しています。

GoblinLab でコンテナ化された新しい開発環境を作成するのは比較的簡単です。イメージを選択し、必要なリソースとマウントする必要がある外部ストレージを入力するだけです (タスク開発用の環境を以下、開発インスタンスと呼びます)。

新しい環境設定を作成したら、「インスタンスの開始」をクリックします。コンテナが初期化されると、Jupyter lab、SSH、および CodeServer が自動的に起動します。

Jupyterラボ:

コードサーバー:

SSHログイン:

アルゴリズムは、上記のいずれかの方法を選択してタスクを開発またはデバッグできます。 Code Server (VSCode) が提供されているため、より良いエクスペリエンスを得ることができます。

タスク開発に使用されるコンテナ化された環境は、基盤となる Kubernetes 上の StatefulSet 型を通じて実装されます。対応するリソースオーケストレーションファイルは次のとおりです (詳細は簡略化されています)。

種類: ステートフルセット
APIバージョン: アプリ/v1
メタデータ:
名前: ${名前}
名前空間: "${namespace}"  
仕様:
レプリカ: 1
セレクタ：
一致ラベル:
  ステートフルセット: ${ name }
  システム/アプリ: ${名前}
テンプレート：
仕様:
  <#if (gpu > 0)>
  許容範囲:
      - 効果: NoSchedule
キー: nvidia.com/gpu
        値: "true"  
  </#if>
  <#usePrivateRepository == "true"の場合>
  イメージプルシークレット:
    -名前: registrykey-myhub
  </#if>
  ボリューム:
    -名前: 現地時間
      ホストパス:
        パス: /etc/localtime
    <#if MountPVCs?? && (MountPVCs?サイズ> 0)>
    <#MountPVCs?keysをリストする キー>
    -名前: "${key}"  
      永続ボリュームクレーム:
        クレーム名: "${key}"  
    </#リスト>
  コンテナ:
    -名前:ノートブック
      画像: ${image}
      イメージプルポリシー: IfNotPresent
      ボリュームマウント:
        -名前: 現地時間
          マウントパス: /etc/localtime
        <#if readMountPVCs?? && (readMountPVCs?サイズ> 0)>
        <#list readMountPVCs?keys as  キー>
        -名前: "${key}"  
          マウントパス: "${readMountPVCs[キー]}"  
          読み取り専用: true  
        </#リスト>
        </#if>
        <#if writeMountPVCs?? && (writeMountPVCs?サイズ> 0)>
        <#list writeMountPVCs?keys as  キー>
        -名前: "${key}"  
          マウントパス: "${writeMountPVCs[key]}"  
        </#リスト>
        </#if>
      環境:
        -名前: NOTEBOOK_TAG
          値: "${name}"  
        -名前: HADOOP_USER
          値: "${hadoopUser}"  
        -名前:パスワード 
          値: "${password}"  
      リソース：
        リクエスト:
          CPU: ${CPU}
          メモリ: ${memory}Gi
          <#if (gpu > 0)>
          nvidia.com/gpu: ${gpu}
          </#if>
        制限:
          CPU: ${CPU}
          メモリ: ${memory}Gi
          <#if (gpu > 0)>
          nvidia.com/gpu: ${gpu}
          </#if>

現在、GolbinLab は Tensoflow のさまざまなバージョンに基づいた 11 個の CPU および GPU 汎用イメージと、複数のカスタマイズされたイメージを提供しています。

タスクのスケジュール

コンテナ化された環境を使用する前、アルゴリズムの同僚は GPU 物理マシン上でタスクを開発し、スケジュールしていました。スケジュールは通常、タイマーまたは crontab コマンドを通じて行われていました。障害、タイムアウト、その他のアラームはなく、再試行メカニズムもなく、基本的に関連するタスク操作および保守ツールはありませんでした。

コンテナ内で開発されたタスクをオンラインでスケジュールする方法を紹介する前に、まずは GoblinLab のシステムアーキテクチャについて簡単に紹介します。

上の図は、GoblinLab の簡略化されたシステムアーキテクチャを示しています。これは、上から下に向かって主に 4 つのレイヤーに分かれています。

アプリケーション層: ユーザーに直接機械学習開発プラットフォームを提供する (GoblinLab)
中間層: 中間層は主に統合されたスケジュール、アラーム、構成サービスに接続します。
ウィザード実行サービス: Kubernetes、Spark、Jar などのさまざまなタスクの送信と実行を含む、統合された実行サービスを提供します。プラグイン、急速な拡張をサポート
インフラストラクチャ: 主に Kubernetes クラスター、Spark クラスター、通常のサーバーを含む基盤となるインフラストラクチャ。

スケジュールされたタスクの安定性を確保するために、GolbinLab はタスクの開発とスケジュールを分割し、以前のアルゴリズムを変更して物理マシン上で直接タスクを開発し、タイマーまたは crontab を通じてタスクをスケジュールします。上図に示すように、開発が完了した後、タスクフロー内のコンテナ化されたタスクスケジューリングコンポーネントを通じてタスクスケジューリングが実装されます。ユーザーは、コンポーネントの関連パラメータ (コードが配置されている PVC とパス、構成イメージなど) を入力し、タスクフローのスケジューリング機能を通じてタスクスケジューリングを実装する必要があります。タスク開発とは異なり、各スケジューリングタスクは独立したコンテナで実行されるため、タスク間の分離が確保されます。同時に、後述するリソース分離ソリューションにより、オンラインスケジューリングタスクに必要なリソースに優先順位を付けることができます。

タスクスケジューリング実行の一般的なプロセスは次のとおりです。

タスクスケジューリングが実行される際の Kubernetes 上のリソースオーケストレーションファイル (詳細は簡略化されています):

 APIバージョン: batch/v1
種類: 仕事
メタデータ:
名前: ${名前}
名前空間: ${namespace}
仕様:
テンプレート：
仕様:
  コンテナ:
    -名前: jupyter-job
      画像: ${image}
      環境:
        -名前: ENV_TEST
          値: ${envTest}
      コマンド: [ "/bin/bash" , "-ic" , "cd ${workDir} && \
        ${execCommand} /root/${entryPath} ${runArgs}"]
      ボリュームマウント:
        - マウントパス: "/root"  
名前: "ルートディレクトリ"  
      リソース：
        リクエスト:
          CPU: ${CPU}
          メモリ: ${memory}Gi
          <#if (gpu > 0)>
          nvidia.com/gpu: ${gpu}
          </#if>
        制限:
          CPU: ${CPU}
          メモリ: ${memory}Gi
          <#if (gpu > 0)>
          nvidia.com/gpu: ${gpu}
          </#if>
  ボリューム:
    -名前: "ルートディレクトリ"  
      永続ボリュームクレーム:
        クレーム名: "${pvc}"  
バックオフ制限: 0

権限制御

コンテナ化された開発環境が構成され、起動されると、ユーザーは SSH ログイン、CodeServer、または JupyterLab を通じてそれを使用できるようになります。 GoblinLabでは、コンテナ化された開発環境が他人に利用されることを防ぐために、メソッドごとに統一されたキーを設定し、起動のたびにキーをランダムに生成します。

1. パスワードをランダムに生成する

2. アカウントパスワード（SSHログインパスワード）を設定する

echo "root:${password}" | chpasswd

3. コードサーバーのパスワードを設定する (VSCode)

 #環境変数PASSWORDを設定する
環境:
 -名前:パスワード        
値: "${password}"

4. Jupyter Labのパスワードを設定する

jupyterノートブック--generate-config、~/.jupyterディレクトリにjupyter_notebook_config.pyを生成し、コードを追加します。  
インポートOS
 IPython.libからpasswdをインポートする
c = c # pylint:disable=未定義変数
c.NotebookApp.ip = '0.0.0.0' # https://github.com/jupyter/notebook/issues/3946 c.NotebookApp.port = int (os.getenv( 'PORT' , 8888)) c.NotebookApp.open_browser = False  
 PASSWORDの場合パスワードを設定します は セット 環境において
'パスワード'の場合  os.environ内:
パスワード= os.environ[ 'パスワード' ]
パスワードの場合:
 c.NotebookApp.password = passwd (パスワード)
それ以外：
 c.NotebookApp.password = ''       
 c.NotebookApp.token = ''     
 os.environ[ 'パスワード' ]を削除します

データの永続性

Kubernetes コンテナでは、特に設定しない限り、コンテナ内のデータは保持されません。つまり、コンテナが削除または再起動されると、データが失われます。対応するソリューションは比較的簡単です。永続化する必要があるディレクトリの外部ストレージをマウントするだけです。 GoblinLab では、デフォルトの外部ストレージ PVC がユーザーごとに自動的に作成され、コンテナの /root ディレクトリにマウントされます。さらに、ユーザーは外部ストレージのマウントをカスタマイズすることもできます。

自動的に作成される PVC に加えて、ユーザーは独自の PVC を作成し、作成した PVC を読み取り専用モードまたは読み取り/書き込みモードで他のユーザーと共有することもできます。

さらに、PVC 内のデータも Goblinlab 上で管理できます。

サービス露出

Kubernetes クラスター内に作成されたサービスには、クラスター外部から直接アクセスすることはできません。GoblinLab は、Nginx Ingress + Gateway を使用して、クラスター内のサービスにアクセスし、外部に公開します。

コンテナ化された開発環境のサービスリソースオーケストレーションファイルは次のとおりです (詳細は簡略化されています)。

 APIバージョン: v1
種類: サービス
メタデータ:
名前: ${名前}
名前空間: ${namespace}
仕様:
クラスターIP: なし
ポート:
 -名前: ポートノートブック
  ポート: 8888
  プロトコル: TCP
  ターゲットポート: 8888
 -名前: port-sshd
  ポート: 22
  プロトコル: TCP
  ターゲットポート: 22
 -名前: ポート-vscode
  ポート: 8080
  プロトコル: TCP
  ターゲットポート: 8080
 -名前: port-tensofboard
  ポート: 6006
  プロトコル: TCP
  ターゲットポート: 6006
 <#if ポート?? && (ポート?サイズ> 0)>
 <# ポートをポートとしてリストする>
 -名前: ポート-${port}
  ポート: ${port}
  ターゲットポート: ${port}
 </#リスト>
 </#if>
セレクタ：
ステートフルセット: ${ name }
タイプ: ClusterIP

ユーザーがコンテナ化された開発環境を起動するたびに、GoblinLab はインターフェースを通じて Nginx Ingress 構成を自動的に変更し、ユーザーが使用できるようにサービスを公開します。Ingress 転送構成は次のとおりです。

 APIバージョン: v1
種類: ConfigMap
メタデータ:
名前: tcp-services
名前空間: kube-system
データ：
 "20000" : ns/ノートブックテスト:8888
 "20001" : ns/ノートブックテスト:8080
 "20002" : ns/ノートブックテスト:22

リソース管理

リソースの使用率を向上させるために、GoblinLab の基盤となる Kubernetes のリソースは基本的に共有方式で使用され、一定の割合で過剰に販売されます。ただし、複数のチームが固定の総リソース量を持つクラスターを共有する場合は、各チームがリソースを公平に共有できるように、リソースを管理および制御する必要があります。 Kubernetes では、リソースクォータがこの問題を解決するためのツールとなります。現在、GoblinLab が管理する必要があるリソースには、主に CPU、メモリ、GPU、ストレージが含まれます。プラットフォームは、各チームの実際のニーズを考慮した上で、リソースを複数のキュー（Kubernetes での概念は名前空間）に分割し、各チームに提供します。

 APIバージョン: v1
種類: リソースクォータ
メタデータ:
名前: スキフクォータ
名前空間: テスト
仕様:
難しい：
制限.CPU: "2"  
メモリ制限: 5Gi
リクエスト.CPU: "2"  
リクエストメモリ: 5Gi
リクエスト.nvidia.com/gpu: "1"  
リクエストストレージ: 10Gi

クラスターでは、最も一般的なリソースは CPU とメモリです。これらは過剰販売 (オーバーコミット) される可能性があるため、制限とリクエストの 2 つのクォータ制限があります。また、その他のリソースは拡張型であり、オーバーコミットが許可されていないため、リクエストのクォータのみが制限されます。パラメータの説明:

limits.cpu: 非ターミナル状態のすべてのポッド全体で、CPU 制限の合計がこの値を超えることはできません。
limits.memory: 非ターミナル状態のすべてのポッド全体で、メモリ制限の合計がこの値を超えることはできません。
request.cpu: 非ターミナル状態のすべてのポッド全体で、CPU リクエストの合計はこの値を超えることはできません。
request.memory: 非ターミナル状態のすべてのポッド全体で、メモリ要求の合計がこの値を超えることはできません。
http://requests.nvidia.com/gpu: 非ターミナル状態のすべてのポッド全体で、GPU 要求の合計はこの値を超えることはできません。
request.storage: すべての永続ボリューム要求にわたって、ストレージ要求の合計がこの値を超えることはできません。

クォータで制御できるリソースはCPU、メモリ、ストレージ、GPUだけではありません。他の種類については公式ドキュメントを参照してください: https://kubernetes.io/docs/con ... otas/

リソースの分離

GoblinLab のリソース分離とは、GPU マシンリソースの分離やオンラインタスクとテストタスクの分離など、同じ Kubernetes クラスター内のスケジュールレベルでのリソースの相対的な分離を指します。

GPUマシンリソースの分離

Kubernetes クラスターでは、GPU マシンのリソースは CPU マシンよりも貴重です。そのため、GPU の使用率を向上させるために、CPU タスクを GPU マシンにスケジュールすることは禁止されています。

GPU ノードの汚染設定: GPU ノードでの一般的なタスクのスケジュールを禁止する

キー: nvidia.com/gpu
値:真  
効果: NoSchedule

汚染効果のオプション構成:

NoSchedule: ポッドは、汚染としてマークされたノードにスケジュールされません。
PreferNoSchedule: NoSchedule のソフトポリシーバージョン。許容できない汚染があるノードにポッドをスケジュールすることは避けてください。
NoExecute: このオプションは、Taint が有効になると、ノードで実行されている Pod に対応する Tolerate 設定がない場合、その Pod が直接削除されることを意味します。

GPUタスク設定許容範囲（Toleration）：GPUタスクをGPUノードでスケジュールできるようにする

<#if (gpu > 0)>
許容範囲:
 - 効果: スケジュールなし
キー: nvidia.com/gpu
値: "true"     
 </#if>

オンラインタスクとテストタスクの分離

オンラインタスクとテストタスク（GolbinLab におけるオンラインタスクとテストタスクは、定期的なスケジュールタスクと開発およびテストタスクを指す、ビジネスレベルで定義されます）は同じ Kubernetes クラスターを使用しますが、オンラインタスクのリソースを保護するために、一部のマシンノードはオンラインタスク専用のリソースプールとして特別に設定されます。オンラインタスクが実行されると、最初にオンラインノードでスケジュールされます。オンラインリソースプールにリソースがない場合は、非オンラインノードでスケジュールすることもできます。

オンラインリソースプールノードを汚染する: オンラインリソースプールでの一般的なタスクスケジュールを禁止する

キー: node.netease.com/node-pool
価値: オンライン
効果: NoSchedule

オンラインタスクに許容範囲を追加: オンラインタスクをオンラインリソースプールにスケジュールできるようにしますが、オンラインリソースプールにスケジュールする必要はありません。

許容範囲:
 - 効果: NoSchedule
キー: node.netease.com/node-pool
値: "オンライン"           
演算子: 等しい

オンラインリソースプール内のマシンノードのラベルを設定し、オンラインタスクのノードアフィニティを設定します。オンラインリソースプール内のオンラインタスクのスケジュールを優先しますが、オンラインリソースプールにリソースがない場合は、他のノードでスケジュールすることもできます。

オンラインリソースプール内のノードにはラベルが付けられます。便宜上、ラベルの名前はテイントと同じになります。

 node.netease.com/node-pool:オンライン

オンラインタスクのノードアフィニティを設定する: オンラインタスクはオンラインリソースプールで最初にスケジュールされます

親和性:
ノードアフィニティ:
優先スケジュール中は無視実行中:
  ノードセレクタ用語:
    - 一致する表現:
    -キー: node.netease.com/node-pool
    演算子:                 
値：
    - オンライン

現在、ノードアフィニティには次の戦略があります。公式ドキュメントの「affinity-and-anti-affinity」を参照してください。

requiredDuringSchedulingIgnoredDuringExecution は、条件を満たすノードに Pod をデプロイする必要があることを意味します。条件を満たすノードがない場合、継続的に再試行されます。 IgnoreDuringExecution は、Pod がデプロイされ実行されているときに、ノードラベルが変更され、Pod によって指定された条件を満たさなくなった場合でも、Pod は引き続き実行されることを意味します。
requiredDuringSchedulingRequiredDuringExecution は、条件を満たすノードに Pod をデプロイする必要があることを意味します。条件を満たすノードがない場合、継続的に再試行されます。 RequiredDuringExecution は、デプロイ後に Pod が実行されているときに、ノードラベルが変更され、Pod によって指定された条件を満たさなくなった場合に、要件を満たすノードが再選択されることを意味します。
preferredDuringSchedulingIgnoredDuringExecution は、条件を満たすノードにデプロイメントが優先されることを意味します。条件を満たすノードがない場合、これらの条件は無視され、通常のロジックに従ってデプロイメントが実行されます。
preferredDuringSchedulingRequiredDuringExecution は、条件を満たすノードにデプロイメントが優先されることを示します。条件を満たすノードがない場合、これらの条件は無視され、通常のロジックに従ってデプロイメントが実行されます。 RequiredDuringExecution は、後続ノードのラベルが変更され、条件が満たされた場合、条件を満たすノードに再スケジュールされることを意味します。

ポリシーが有効になった後の効果は、次の図に示されています。オンラインタスクは、最初にオンラインリソースプールノードで実行されますが、オンラインリソースプールにアイドルリソースがない場合、オンラインタスク Job5 は通常のノードのリソースも使用できます。

中間結果

現在までに、音楽機械学習プラットフォーム (GoblinLab) はコンテナ化の実験をしばらく行っており、いくつかの初期結果を達成しています。

クラスター構築

現在の音楽データプラットフォームのKubernetesは、試行期間を経て、ますます多くのビジネスとKubernetesベースのビッグデータコンピューティングプラットフォーム（Flinkなど）の実装があり、今後は大量のCPUリソースが追加され、その安定性が比較的大きな課題になります。

ユーザーの使用

タスク移行：現在、アルゴリズムの同僚はタスク移行の80％を完了しています。

タスク開発

ユーザーの状況: アルゴリズムの学生の60%が開発インスタンスのコンテナ化された環境を使用しています。ユーザーソースには、音楽推奨アルゴリズム、ソーシャルビデオ推奨アルゴリズム、検索アルゴリズム、オーディオとビデオ、データアプリケーション、リアルタイムコンピューティングアルゴリズムなどのチームが含まれます。
開発インスタンス: プラットフォームでは、グループ内での開発インスタンスの共有を推奨しており、各ユーザーが作成できる開発インスタンスは最大 3 つに制限されています。
タスクのスケジューリング: クラウド音楽推奨、ソーシャルビデオ推奨アルゴリズム、検索アルゴリズム、オーディオとビデオ、データアプリケーション、リアルタイムコンピューティングアルゴリズムなど、複数のチームをカバーします。

コンテナ化の利点

アルゴリズム担当者にとって、物理マシンから機械学習プラットフォームによって提供されるコンテナ化された環境に移行すると、次のようなメリットが得られます。

より多くのリソース: リソース使用率の向上により、物理マシンのみを使用して以前よりも多くのリソースを取得できるようになります。さらに、リソースの拡張と縮小のサイクルが数日から数秒に短縮されます。
より良いエクスペリエンス：ビッグデータとGit環境を接続し、多様な利用方法（SSHとオンラインIDE）を提供し、機械学習プラットフォームが環境イメージを統一的に維持することで、各チームが独自に環境を構築して維持しなければならないという手間を回避します。
より完全なタスクスケジューリング: GoblinLab のスケジューリングは、より完全なアラーム、再試行、依存関係チェックなどの機能を提供し、既存の PS および Ironbaby タスクと統合して、タスクフローで統一されたスケジューリングを実現できます。
より優れた隔離: 環境の隔離はコンテナ化の自然な利点です。さらに、スケジューリングレベルでのリソースの分離により、オンラインタスクをより適切に保証できます。
入口の統一：開発入口を統一することで、運用の余地が広がります。たとえば、一般的なサービス (依存関係のチェック、スケジュール、アラームの監視など)、データの共有、イメージの更新、その後の継続的なサポートサービスは抽象化され、プラットフォームによって直接提供されます。

その後の計画

現在、音楽機械学習プラットフォームは、コンテナ化された開発のための完全な基本機能を提供できます。クラスターのリソース使用率をさらに向上させ、運用と保守の効率を高めるために、その後の最適化計画は、リソーススケジューリング戦略の最適化（プリエンプションなど）、より豊富なリソース監視、およびその他の側面から始まり、さらなる最適化が図られます。

著者: 王俊正、NetEase Cloud Music、データインテリジェンス部門、データプラットフォームグループ

<<: AIが建設現場の安全性を向上させる10の方法

>>: 2020 年の最もクールな機械学習スタートアップ 12 社