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

JindoRuntime は C++ をベースとしており、データセット管理、データキャッシング、OSS でのデータストレージをサポートしています。 Fluid は、JindoRuntime を管理およびスケジューリングすることにより、データセットの可観測性、自動スケーリング、および移植性を実現します。このトピックでは、ACS 計算能力が使用されるシナリオで、Fluid を使用してデータアクセスを高速化する方法について説明します。

前提条件

Object Storage Service (OSS) がアクティブ化されています。詳細については、「OSS をアクティブ化する」をご参照ください。
ack-fluid 1.0.11-* 以後がインストールされています。詳細については、「Helm を使用して ACS でアプリケーションを管理する」をご参照ください。
ACS ポッドに対して特権モードが有効になっています。
説明
Fluid を使用してデータアクセスを高速化するには、特権モードが必要です。このモードを有効にするには、submit a ticket してください。

手順

ステップ 1： OSS にデータをアップロードする

次のコマンドを実行して、テストデータをダウンロードします。
```
wget https://archive.apache.org/dist/spark/spark-3.0.1/spark-3.0.1-bin-hadoop2.7.tgz
```
テストデータセットを OSS バケットにアップロードします。
重要
この例では、Alibaba Cloud Linux 3.2104 LTS 64 ビットオペレーティングシステムを実行している 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. (オプション) バケットおよびデータにアクセスするための権限を設定します。詳細については、「権限制御」をご参照ください。
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 シークレット を指定します。
次のコマンドを実行してシークレットを作成します。 Kubernetes は、プレーンテキストで機密データが公開されないように、シークレットを自動的に暗号化します。
```
kubectl create -f mySecret.yaml
```

ステップ 2：データセットと JindoRuntime を作成する

resource.yaml という名前のファイルを作成し、次の内容をファイルに追加します。

リモートストレージ内のデータセットと基盤となるファイルシステム (UFS) に関する情報を指定するデータセットを作成します。
データキャッシング用の 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_bucket>/{oss_path} を設定します。
    - mountPoint: oss://<oss_bucket>       # <oss_bucket> を実際の値に置き換えます。
      options:
        fs.oss.endpoint: <oss_endpoint>    # <oss_endpoint> を実際の値に置き換えます。
      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:
  ## データセットの名前を指定します。
  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	キャッシュのタイプ。 JindoRuntime テンプレートを作成する場合、JindoFS は `HDD`、`SDD`、`MEM` のいずれか 1 つのキャッシュタイプのみをサポートします。
path	ストレージパス。 1 つのパスのみを指定できます。 mediumtype を `MEM` に設定した場合、ログなどのデータを格納するためのオンプレミスストレージのパスを指定する必要があります。
quota	キャッシュデータの最大サイズ。単位：GB。
high	ストレージ容量の上限。
low	ストレージ容量の下限。

次のコマンドを実行して、データセットと JindoRuntime を作成します。
```
kubectl create -f resource.yaml
```
JindoRuntime とデータセットのデプロイメントを表示します。
1. データセットのデプロイメントを表示します。
```
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
```
  上記の出力は、データセットと JindoRuntime が作成されたことを示しています。

次のコマンドを実行して、永続ボリューム (PV) と永続ボリューム要求 (PVC) が作成されているかどうかを確認します。 PVS はデータセットの名前を使用します。

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： DataLoad リソースを作成する

データの読み込みを高速化し、データ処理ロジックの有効性を確保するには、データセットを一度プリロードする必要があります。

OSS バケットに格納されているモデルデータが静的な場合、dataload.yaml という名前のファイルを作成し、次の内容をファイルに追加してデータをプリロードします。
```
apiVersion: data.fluid.io/v1alpha1
kind: DataLoad
metadata:
  name: hadoop
spec:
  dataset:
    name: hadoop
    namespace: default
  loadMetadata: true
```
OSS バケットに格納されているモデルデータが動的な場合、データを定期的にプリロードする必要があります。詳細については、「シナリオ 2：バックエンドストレージ内のデータは読み取り専用だが定期的に変更される」をご参照ください。
DataLoad リソースを作成して、モデルデータを一度プリロードします。
```
kubectl create -f dataload.yaml
```

プリロードのステータスを表示します。

kubectl get dataload

予期される結果：

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

ステップ 4：データアクセラレーションを検証するためのポッドを作成する

ポッドを作成するか、機械学習ジョブを送信して、JindoFS データアクセラレーションサービスを検証できます。この例では、同じデータへのアクセスをテストするために、コンテナーにアプリケーションがデプロイされます。テストは複数回実行され、時間消費量が比較されます。

次の YAML テンプレートを使用して、app.yaml という名前のファイルを作成します。

apiVersion: v1
kind: Pod
metadata:
  name: demo-app
  labels:
    # ACS ポッドをマウントするには、Fluid webhook を使用して Fluid 関連コンポーネントをサイドカーコンテナーとして挿入します。 次のラベルを設定する必要があります。
    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 データセットの名前。
        claimName: hadoop
  nodeSelector:
    type: virtual-kubelet
  tolerations:
    - key: virtual-kubelet.io/provider
      operator: Equal
      value: alibabacloud
      effect: NoSchedule

次のコマンドを実行して、アプリケーションポッドを作成します。
```
kubectl create -f app.yaml
```
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 秒かかったことを示しています。
データセットキャッシュを表示します。
```
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 によってキャッシュされていることを示しています。
サンプルポッドを削除し、ファイルコピ-時間表示します。
説明
ページキャッシュなどの他の要因の影響を排除するには、サンプルポッドを削除する必要があります。ポッドに既にローカルキャッシュが含まれている場合、システムはローカルキャッシュからファイルをコピーすることが優先されます。
次のコマンドを実行して、ファイルのコピーに必要な時間をクエリします。
```
kubectl exec -it demo-app -c demo -- bash
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 によってキャッシュされているためです。キャッシュされたファイルへのアクセスははるかに高速です。
重要
このトピックで提供されているコピ-時間は参考値です。

ACK Pro マネージドクラスターで ACS 計算能力を使用する

このトピックでは、ACS クラスタに基づいて JindoFS を使用してファイルコピー操作を高速化する方法について説明します。また、ACK マネージドクラスターで ACS 計算能力を使用して操作を完了することもできます。詳細については、「ACK Pro マネージドクラスターで ACS の計算能力を使用する」をご参照ください。

ACK マネージドクラスターでデータアクセラレーションを検証するには、次の調整を行います。

ACK マネージドクラスターに ack-fluid コンポーネントをインストールします。詳細については、「Helm を使用してアプリケーションデプロイを簡素化する」をご参照ください。

次の内容に基づいてデータセットと JindoRuntime を作成します。

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: hadoop
spec:
  mounts:
      ## サブディレクトリを指定するには、oss://<oss_bucket>/{oss_path} を設定します。
    - mountPoint: oss://<oss_bucket>       # <oss_bucket> を実際の値に置き換えます。
      options:
        fs.oss.endpoint: <oss_endpoint>    # <oss_endpoint> を実際の値に置き換えます。
      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:
  name: hadoop
spec:
  ## 必要に応じて変更します。
  replicas: 4
  tieredstore:
    levels:
      - mediumtype: MEM
        path: /dev/shm
        volumeType: emptyDir
        quota: 48Gi
        high: "0.99"
        low: "0.95"

ACK マネージドクラスターと ACS クラスタの違い：

ACS クラスタのノードは仮想ノードであるため、ACK クラスタと同じ方法でスケーリングすることはできません。したがって、.spec.placement: Shared および networkmode を設定する必要があります。
Fluid ワーカーには高い帯域幅が必要です。 ACS クラスタに十分な帯域幅があることを確認する必要があります。これを行うには、compute-class: performance および resources を設定して、ACS ポッドに十分な帯域幅があることを確認します。