Container Compute Service:Fluid を使用したデータアクセスの高速化

ステップ1：OSS バケット内のデータの準備

1. 次のコマンドを実行して、テストデータをダウンロードします。

   wget https://archive.apache.org/dist/spark/spark-3.0.1/spark-3.0.1-bin-hadoop2.7.tgz

2. ダウンロードしたテストデータを OSS のバケットにアップロードします。

   重要

   この例では、Alibaba Cloud Linux 3.2104 LTS 64 ビットを実行している Elastic Compute Service (ECS) インスタンスを使用して、データを OSS にアップロードする方法を説明します。他のオペレーティングシステムでの手順については、「ossutil クイックスタート」および「ossutil 1.0」をご参照ください。

   1. ossutil のインストール

   2. 次のコマンドを実行して、examplebucket という名前のバケットを作成します。

      説明

      コマンドが ErrorCode=BucketAlreadyExists を返した場合、そのバケット名は既に使用されています。OSS のバケット名はグローバルに一意である必要があるため、examplebucket を一意の名前に置き換えてください。

      ossutil64 mb oss://examplebucket

      期待される出力：

      0.668238(s) elapsed

      この出力は、examplebucket という名前のバケットが作成されたことを示します。

   3. ダウンロードしたテストデータを examplebucket バケットにアップロードします。

      ossutil64 cp spark-3.0.1-bin-hadoop2.7.tgz oss://examplebucket

   4. (オプション) バケットとそのデータのアクセス権限を設定します。詳細については、「アクセスコントロールの概要」をご参照ください。

3. 次の内容で mySecret.yaml という名前のファイルを作成します。

   apiVersion: v1
   kind: Secret
   metadata:
     name: mysecret
   stringData:
     fs.oss.accessKeyId: xxx
     fs.oss.accessKeySecret: xxx

   fs.oss.accessKeyId および fs.oss.accessKeySecret パラメーターは、OSS へのアクセスに使用される AccessKey ID および AccessKey Secret を指定します。

4. 次のコマンドを実行して Secret を作成します。Kubernetes は、作成された Secret が平文で公開されるのを防ぐために自動的にエンコードします。

   kubectl create -f mySecret.yaml

ステップ2：Dataset と JindoRuntime の作成

1. 次の内容で resource.yaml ファイルを作成します。

   • リモートのデータセットと基盤となるファイルシステム (UFS) を記述する Dataset。

   • キャッシングサービスを提供するために JindoFS クラスターを起動する JindoRuntime。

   説明

   kubectl get pods --field-selector=status.phase=Running -n fluid-system コマンドを実行して、ack-fluid コンポーネント内の dataset-controller と jindoruntime-controller が正常に実行されているかを確認できます。

   この例では主に CPU コンピュートパワーを使用します。大規模言語モデル (LLM) サービスの読み込みを高速化するには、クラスター作成時に選択するゾーンが GPU リソースをサポートしていることを確認してください。詳細については、「GPU 高速化コンピューティングインスタンスタイプ」をご参照ください。

   YAML の内容を展開して表示

   apiVersion: data.fluid.io/v1alpha1
   kind: Dataset
   metadata:
     name: hadoop
   spec:
     placement: Shared
     mounts:
         ## サブディレクトリを指定するには、oss:///{oss_path} の形式を使用します。
       - mountPoint: oss://<oss_bucket>       #  をお使いのバケット名に置き換えます。
         options:
           fs.oss.endpoint: <oss_endpoint>    #  をお使いの OSS エンドポイントに置き換えます。
         name: hadoop
         path: "/"
         encryptOptions:
           - name: fs.oss.accessKeyId
             valueFrom:
               secretKeyRef:
                 name: mysecret
                 key: fs.oss.accessKeyId
           - name: fs.oss.accessKeySecret
             valueFrom:
               secretKeyRef:
                 name: mysecret
                 key: fs.oss.accessKeySecret
   ---
   apiVersion: data.fluid.io/v1alpha1
   kind: JindoRuntime
   metadata:
     ## Dataset 名と一致させる必要があります。
     name: hadoop
   spec:
     networkmode: ContainerNetwork
     ## 必要に応じて調整します。
     replicas: 4
     master:
       podMetadata:
         labels:
           alibabacloud.com/compute-class: performance
           alibabacloud.com/compute-qos: default
     worker:
       podMetadata:
         labels:
           alibabacloud.com/compute-class: performance
           alibabacloud.com/compute-qos: default
       resources:
         requests:
           cpu: 24
           memory: 48Gi
         limits:
           cpu: 24
           memory: 48Gi
     tieredstore:
       levels:
         - mediumtype: MEM
           path: /dev/shm
           volumeType: emptyDir
           ## 必要に応じて調整します。
           quota: 48Gi
           high: "0.99"
           low: "0.95"

   次の表にパラメーターを示します。

   パラメーター	説明
   mountPoint	oss://<oss_bucket> は UFS のマウントパスを指定します。<oss_bucket> はお使いの OSS バケットの名前です。例： oss://examplebucket
   fs.oss.endpoint	OSS バケットのエンドポイント。パブリックエンドポイントと内部エンドポイントの両方がサポートされています。例： oss-cn-beijing-internal.aliyuncs.com。詳細については、「OSS のリージョンとエンドポイント」をご参照ください。
   replicas	JindoFS クラスターのワーカーレプリカの数。
   mediumtype	キャッシュメディアの種類。JindoFS は現在、HDD、SSD、または MEM のいずれか 1 つのみをサポートしています。
   path	ストレージパス。単一のパスのみがサポートされています。MEM がキャッシュタイプの場合、ログなどのファイルを保存するためのローカルパスを指定する必要があります。
   quota	最大キャッシュ容量 (GiB 単位)。
   high	ストレージ使用率の高ウォーターマーク。
   low	ストレージ使用率の低ウォーターマーク。

2. JindoRuntime と Dataset を作成します。

   kubectl create -f resource.yaml

3. JindoRuntime と Dataset のデプロイ状況を確認します。

   1. Dataset のデプロイ状況を確認します。

      kubectl get dataset hadoop

      期待される出力：

      NAME     UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
      hadoop   209.74MiB        0.00B    4.00GiB          0.0%                Bound   56s

   2. JindoRuntime のデプロイ状況を確認します。

      kubectl get jindoruntime hadoop

      期待される出力：

      NAME     MASTER PHASE   WORKER PHASE   FUSE PHASE   AGE
      hadoop   Ready          Ready          Ready        2m11s

      この出力は、Dataset と JindoRuntime の準備が完了したことを示しています。

4. 次のコマンドを実行して、永続ボリューム (PV) と永続ボリューム要求 (PVC) の作成状況を確認します。PVC 名には Dataset 名が使用されます。

   kubectl get pv,pvc

   期待される出力：

   NAME                              CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM            STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
   persistentvolume/default-hadoop   100Pi      ROX            Retain           Bound    default/hadoop   fluid          <unset>                          2m5s
   
   NAME                           STATUS   VOLUME           CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
   persistentvolumeclaim/hadoop   Bound    default-hadoop   100Pi      ROX            fluid          <unset>                 2m5s

ステップ3：Dataset のプリロード

データ読み込み速度を大幅に向上させ、データ処理ロジックの正しさを保証するために、Dataset をプリロードする必要があります。

1. OSS 内のデータが変更されない場合は、次の内容で dataload.yaml ファイルを作成し、1 回限りのデータプリロードを実行します。

   apiVersion: data.fluid.io/v1alpha1
   kind: DataLoad
   metadata:
     name: hadoop
   spec:
     dataset:
       name: hadoop
       namespace: default
     loadMetadata: true

2. OSS 内のデータが動的に更新される場合は、定期的なデータプリロードを設定します。詳細については、「シナリオ2：バックエンドストレージで定期的に更新される読み取り専用データ」をご参照ください。

3. DataLoad リソースを作成して、1 回限りのプリロードを実行します。

   kubectl create -f dataload.yaml

4. データプリロードの状況を確認します。

   kubectl get dataload

   期待される出力：

   NAME          DATASET    PHASE       AGE   DURATION
   hadoop        hadoop   Complete      92m   51s

ステップ4：高速化をテストするための Pod の作成

アプリケーション Pod を作成するか、機械学習ジョブを送信することで、JindoFS の高速化サービスをテストできます。次の例では、同じデータに複数回アクセスする Pod を作成します。アクセス時間を比較することで、JindoRuntime によって提供される高速化を確認できます。

1. 次の内容で app.yaml ファイルを作成します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: demo-app
     labels:
       # ACS へのマウントには、Fluid Webhook によるサイドカーインジェクションが必要です。次のラベルを追加します。
       alibabacloud.com/fluid-sidecar-target: acs
   spec:
     containers:
       - name: demo
         image: mirrors-ssl.aliyuncs.com/nginx:latest
         volumeMounts:
           - mountPath: /data
             name: hadoop
         resources:
           requests:
             cpu: 14
             memory: 56Gi
     volumes:
       - name: hadoop
         persistentVolumeClaim:
           ## Fluid Dataset の名前。
           claimName: hadoop
     nodeSelector:
       type: virtual-kubelet
     tolerations:
       - key: virtual-kubelet.io/provider
         operator: Equal
         value: alibabacloud
         effect: NoSchedule

2. 次のコマンドを実行して、アプリケーション Pod を作成します。

   kubectl create -f app.yaml

3. JindoFS キャッシュを利用せずに、ファイルコピーの速度をテストします。

   1. テストファイルのサイズを確認します。

      kubectl exec -it demo-app -c demo -- du -sh /data/spark-3.0.1-bin-hadoop2.7.tgz

      期待される出力：

      210M    /data/spark-3.0.1-bin-hadoop2.7.tgz

   2. ファイルのコピーにかかる時間を確認します。

      time cp /data/spark-3.0.1-bin-hadoop2.7.tgz /dev/null

      期待される出力：

      real    0m1.883s
      user    0m0.001s
      sys     0m0.041s

      ファイルのコピーには 1.883 秒かかりました。

4. Dataset のキャッシュ状況を確認します。

   kubectl get dataset hadoop

   期待される出力：

   NAME     UFS TOTAL SIZE   CACHED      CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
   hadoop   209.74MiB        209.74MiB   4.00GiB          100.0%              Bound   64m

   この出力は、データの 100.0% が JindoFS にキャッシュされたことを示しています。

5. サンプルアプリケーション Pod を削除して再作成し、JindoFS キャッシュを利用した場合のファイルコピーの時間を確認します。

   説明

   ページキャッシュなどの他の要因がテスト結果に影響するのを防ぐため、アプリケーション Pod を削除します。Pod 内にローカルキャッシュが既に存在する場合、コピー操作はデフォルトでそれを使用します。

   次のコマンドを実行して Pod を削除して再作成し、準備が整ったらファイルコピーの時間を測定します。

   # Pod を削除
   kubectl delete pod demo-app
   
   # Pod を再作成
   kubectl create -f app.yaml
   
   # Pod が Running 状態になったら、次のコマンドで時間を測定
   kubectl exec -it demo-app -c demo -- time cp /data/spark-3.0.1-bin-hadoop2.7.tgz /dev/null

   期待される出力：

   real    0m0.203s
   user    0m0.000s
   sys     0m0.047s

   コピー操作にかかる時間は 0.203 秒となり、最初の試行より約 9 倍高速になりました。この速度向上は、JindoFS がキャッシュからファイルを提供するためです。

   重要

   このトピックで提供されるコピー時間は参考値です。実際の結果は環境によって異なる場合があります。