Container Service for Kubernetes:Argo ジョブ向けデータアクセスの高速化

制限事項

本機能は ACK のエラスティックスケジューリング機能と相互排他です。ACK のエラスティックスケジューリング機能の詳細については、「優先度に基づくリソーススケジューリングの設定」をご参照ください。

手順 1：テストデータセットを OSS バケットにアップロード

1. サイズ 2 GB のテストデータセットを作成します。本例では、テスト データセットを使用します。

2. 作成済みの OSS バケットにテストデータセットをアップロードします。

   OSS が提供する ossutil ツールを使用してデータをアップロードできます。詳細については、「ossutil のインストール」をご参照ください。

手順 2：Dataset および JindoRuntime の作成

ACK クラスターおよび OSS バケットの準備が完了したら、Dataset および JindoRuntime をデプロイします。このデプロイには数分程度かかります。

1. 以下の内容に基づいて、secret.yaml という名前のファイルを作成します。

   このファイルには、OSS バケットへのアクセスに使用される fs.oss.accessKeyId および fs.oss.accessKeySecret が含まれます。

   apiVersion: v1
   kind: Secret
   metadata:
     name: access-key
   stringData:
     fs.oss.accessKeyId: ****
     fs.oss.accessKeySecret: ****

2. 以下のコマンドを実行して Secret をデプロイします：

   kubectl create -f secret.yaml

3. 以下の内容に基づいて、resource.yaml という名前のファイルを作成します。

   この YAML ファイルには、以下の情報が格納されます：

   • Dataset：リモートデータストアに格納された Dataset および UNIX ファイルシステム（UFS）の情報を指定します。

   • JindoRuntime：クラスター内でのデータキャッシュに JindoFS を有効化します。

   apiVersion: data.fluid.io/v1alpha1
   kind: Dataset
   metadata:
     name: serverless-data
   spec:
     mounts:
     - mountPoint: oss://large-model-sh/
       name: demo
       path: /
       options:
         fs.oss.endpoint: oss-cn-shanghai.aliyuncs.com
       encryptOptions:
         - name: fs.oss.accessKeyId
           valueFrom:
             secretKeyRef:
               name: access-key
               key: fs.oss.accessKeyId
         - name: fs.oss.accessKeySecret
           valueFrom:
             secretKeyRef:
               name: access-key
               key: fs.oss.accessKeySecret
     accessModes:
       - ReadWriteMany
   ---
   apiVersion: data.fluid.io/v1alpha1
   kind: JindoRuntime
   metadata:
     name: serverless-data
   spec:
     master:
       disabled: true
     worker:
       disabled: true

   上記コードブロックで指定されたパラメーターの一部について、以下の表に説明を示します。

   パラメーター	説明
   mountPoint	UFS ファイルシステムをマウントするパス。パスの形式は oss://<oss_bucket>/<bucket_dir> です。 パス内にエンドポイント情報を含めないでください。<bucket_dir> は、バケットに直接アクセス可能な場合に省略可能です。
   fs.oss.endpoint	OSS バケットのパブリックエンドポイントまたはプライベートエンドポイント。 データセキュリティを強化するために、バケットのプライベートエンドポイントを指定できます。ただし、プライベートエンドポイントを指定する場合は、ACK クラスターが OSS が有効化されているリージョンにデプロイされていることを確認してください。たとえば、OSS バケットが中国 (杭州) リージョンに作成されている場合、そのパブリックエンドポイントは oss-cn-hangzhou.aliyuncs.com、プライベートエンドポイントは oss-cn-hangzhou-internal.aliyuncs.com となります。
   fs.oss.accessKeyId	バケットへのアクセスに使用する AccessKey ID。
   fs.oss.accessKeySecret	バケットへのアクセスに使用する AccessKey Secret。
   accessModes	アクセスモード。有効な値は ReadWriteOnce、ReadOnlyMany、ReadWriteMany、および ReadWriteOncePod です。デフォルト値は ReadOnlyMany です。
   disabled	master ノードおよび worker ノードの両方でこのパラメーターを true に設定すると、キャッシュなしモードが使用されます。

4. 以下のコマンドを実行して Dataset および JindoRuntime をデプロイします：

   kubectl create -f resource.yaml

5. 以下のコマンドを実行して、Dataset が正しくデプロイされたかを確認します：

   kubectl get dataset serverless-data

   期待される出力：

   NAME              UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
   serverless-data                                                                  Bound   1d

   出力の Bound が PHASE 列に表示される場合、Dataset が正常にデプロイされたことを示します。

6. 以下のコマンドを実行して、JindoRuntime が正しくデプロイされたかを確認します：

   kubectl get jindo serverless-data

   期待される出力：

   NAME              MASTER PHASE   WORKER PHASE   FUSE PHASE   AGE
   serverless-data                                 Ready        3m41s

   出力の Ready が FUSE 列に表示される場合、JindoRuntime が正常にデプロイされたことを示します。

手順 3：OSS へのアクセスを行う Argo ジョブの作成

JindoFS 加速サービスを利用するには、アプリケーションコンテナを作成するか、機械学習ジョブを送信します。本トピックでは、OSS にアクセスする Argo ジョブを例として使用します。

1. 以下の内容で workflow.yaml という名前のファイルを作成します。

   apiVersion: argoproj.io/v1alpha1
   kind: Workflow
   metadata:
     generateName: serverless-workflow-
   spec:
     entrypoint: serverless-workflow-example
     volumes:
     - name: datadir
       persistentVolumeClaim:
         claimName: serverless-data
   
     templates:
     - name: serverless-workflow-example
       steps:
       - - name: copy
           template: copy-files
       - - name: check
           template: check-files
   
     - name: copy-files
       metadata:
         labels:
          alibabacloud.com/fluid-sidecar-target: eci
          alibabacloud.com/eci: "true"
         annotations:
            k8s.aliyun.com/eci-use-specs: ecs.g7.4xlarge
       container:
         image: debian:buster
         command: [bash, -c]
         args: ["time cp -r /data/ /tmp"]
         volumeMounts:
         - name: datadir
           mountPath: /data
   
     - name: check-files
       metadata:
         labels:
           alibabacloud.com/fluid-sidecar-target: eci
           alibabacloud.com/eci: "true"
         annotations:
            k8s.aliyun.com/eci-use-specs: ecs.g7.4xlarge
       container:
         image: debian:buster
         command: [bash, -c]
         args: ["du -sh /data; md5sum /data/*"]
         volumeMounts:
         - name: datadir
           mountPath: /data

2. 以下のコマンドを実行してワークフローを作成します。

   kubectl create -f workflow.yaml

3. 以下のコマンドを実行して起動ログを表示します。

   kubectl logs serverless-workflow-85sbr-4093682611

   期待される出力：

   real    0m24.966s
   user    0m0.009s
   sys     0m0.677s

   出力から、ファイルコピー時間（real）が 0m24.966s であることがわかります。このコピー時間はネットワーク遅延および帯域幅に依存します。データアクセスをさらに高速化するには、「キャッシュモードを用いた Argo ジョブ向けデータアクセスの高速化」をご参照ください。

4. Fluid によって読み込まれたファイルがローカルファイルと一致しているかを確認します。

   1. 以下のコマンドを実行して、Fluid によって読み込まれたファイルの MD5 検証値を表示します。

      kubectl logs serverless-workflow-85sbr-1882013783

      期待される出力：

      1.2G    /data
      871734851bf7d8d2d1193dc5f1f692e6  /data/wwm_uncased_L-24_H-1024_A-16.zip

   2. 以下のコマンドを実行して、ローカルファイルの MD5 検証値を表示します。

      md5sum ./wwm_uncased_L-24_H-1024_A-16.zip

      期待される出力：

      871734851bf7d8d2d1193dc5f1f692e6  ./wwm_uncased_L-24_H-1024_A-16.zip

      出力から、MD5 検証値が同一であることが確認できます。これは、Fluid によって読み込まれたファイルがローカルファイルと一致していることを示します。

手順 4：環境のクリーンアップ

データアクセス機能を今後使用しない場合は、速やかに環境をクリーンアップしてください。そのためには、以下の手順を実行します：

1. 以下のコマンドを実行してアプリケーションコンテナを削除します。

   kubectl delete workflow serverless-workflow-85sbr

2. 以下のコマンドを実行して Dataset を削除します。

   kubectl delete dataset serverless-data