Argoワークフローを加速 - Container Service for Kubernetes - Alibaba Cloud ドキュメントセンター

Fluidを使用すると、JindoRuntimeを使用して、サーバーレスクラウドコンピューティングシナリオでObject Storage Service (OSS) に保存されているデータへのアクセスを高速化できます。キャッシュモードとキャッシュモードなしでデータアクセスを高速化できます。このトピックでは、キャッシュモードでArgoワークフローを高速化する方法について説明します。

前提条件

Argoまたはack-workflowコンポーネントがインストールされています。詳細については、「Argo」または「Argoワークフロー」をご参照ください。
仮想ノードはACK Proクラスターにデプロイされます。詳細については、「仮想ノードを介したエラスティックコンテナインスタンスへのポッドのスケジュール」をご参照ください。
非containerOSを使用したContainer Service for Kubernetes (ACK) Proクラスターが作成され、クラスターのKubernetesバージョンが1.18以降になります。詳細については、「ACK Proクラスターの作成」をご参照ください。
重要
ack − fluidコンポーネントは、現在、ContainerOS上でサポートされていない。
Cloud-native AI Suiteがインストールされ、ack-fluidコンポーネントがデプロイされます。
重要
- 既にオープンソースFluidをインストールしている場合は、ack-fluidコンポーネントを展開する前にアンインストールします。
- Cloud-native ai Suiteのack-AI-pipelineとArgoワークフローの互換性の問題により、高速化されたArgoタスクデータアクセス機能を使用するには、Cloud-native ai Suiteのデプロイ中にack-AI-pipelineの選択を解除する必要があります。
- Cloud-native AI Suiteをインストールしていない場合は、スイートのインストール時にData Access AccelerationのFluidを有効にします。詳細については、「クラウドネイティブAI Suiteのデプロイ」をご参照ください。
- Cloud-native AI Suiteを既にインストールしている場合は、ACKコンソールのCloud-native AIコンポーネントセットページに移動し、ack-fluidコンポーネントをデプロイします。
kubectlクライアントがACK Proクラスターに接続されています。詳細については、「kubectlを使用したクラスターへの接続」をご参照ください。
OSSが有効化され、バケットが作成されます。詳細については、「OSSの有効化」および「バケットの作成」をご参照ください。

制限事項

この特徴は、ACKの弾性スケジューリング特徴と相互に排他的である。 ACKのエラスティックスケジューリング機能の詳細については、「優先度ベースのリソーススケジューリングの設定」をご参照ください。

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

サイズが2 GBのテストデータセットを作成します。この例では、テストデータセットが使用されます。
作成したOSSバケットにテストデータセットをアップロードします。
OSSが提供するossutilツールを使用して、データをアップロードできます。詳細については、「ossutilのインストール」をご参照ください。

ステップ2: データセットとJindoRuntimeの作成

ACKクラスターとOSSバケットをセットアップした後、データセットとJindoRuntimeをデプロイする必要があります。デプロイには数分しかかかりません。

次の内容に基づいて、secret.yamlという名前のファイルを作成します。
このファイルには、ossへのアクセスに使用されるfs.oss.accessKeyIdとfs. OSS. accessKeySecretが格納されています。
```
apiVersion: v1
kind: Secret
metadata:
  name: access-key
stringData:
  fs.oss.accessKeyId: ****
  fs.oss.accessKeySecret: ****
```
次のコマンドを実行して、シークレットをデプロイします。
```
kubectl create -f secret.yaml
```

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

YAMLファイルには次の情報が格納されます。

Dataset: リモートデータストアに格納されるデータセットとUnixファイルシステム (UFS) 情報を指定します。
JindoRuntime: クラスターでのデータキャッシュのJindoFSを有効にします。

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: serverless-data
spec:
  mounts:
  - mountPoint: oss://<oss_bucket>/<bucket_dir>
    name: demo
    path: /
    options:
      fs.oss.endpoint: <oss_endpoint>
    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
---
apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: serverless-data
spec:
  replicas: 1
  tieredstore:
    levels:
      - mediumtype: MEM
        volumeType: emptyDir
        path: /dev/shm
        quota: 5Gi
        high: "0.95"
        low: "0.7"

次の表に、上記のコードブロックで指定されたいくつかのパラメーターを示します。

パラメーター	説明
`mountPoint`	UFSファイルシステムがマウントされるパス。パスの形式は`oss://<oss_bucket>/<bucket_dir>` です。パスにエンドポイント情報を含めないでください。例: oss:// mybucket/path/to/dir マウントターゲットを1つだけ使用する場合は、`path`を `/`に設定できます。
`fs.oss.endpoint`	OSSバケットのパブリックエンドポイントまたはプライベートエンドポイント。バケットのプライベートエンドポイントを指定して、データのセキュリティを強化できます。ただし、プライベートエンドポイントを指定する場合は、OSSがアクティブ化されているリージョンにACKクラスターがデプロイされていることを確認してください。たとえば、OSSバケットが中国 (杭州) リージョンで作成されている場合、バケットのパブリックエンドポイントは`oss-cn-hangzhou.aliyuncs.com`で、プライベートエンドポイントは`oss-cn-hangzhou-internal.aliyuncs.com`です。
`fs.oss.accessKeyId`	バケットへのアクセスに使用されるAccessKey ID。
`fs.oss.accessKeySecret`	バケットへのアクセスに使用されるAccessKeyシークレット。
`レプリカ`	JindoFSクラスターに作成されるワーカーの数。
`mediumtype`	キャッシュのタイプ。サポートされているキャッシュタイプは、HDD、SSD、およびMEMです。 mediumtypeの推奨設定の詳細については、「ポリシー2: 適切なキャッシュメディアの選択」をご参照ください。
`volumeType`	キャッシュメディアのボリュームタイプ。有効な値: `emptyDir`および`hostPath`。デフォルト値: `hostPath`。メモリまたはローカルシステムディスクをキャッシュ媒体として使用する場合は、`emptyDir`タイプを使用して、ノード上のキャッシュデータの残留を回避し、ノードの可用性を確保することを推奨します。ローカルデータディスクをキャッシュメディアとして使用する場合は、`hostPath`タイプを使用し、`パス`を設定してホスト上のデータディスクのマウントパスを指定できます。 volumeTypeの推奨設定の詳細については、「ポリシー2: 適切なキャッシュメディアの選択」をご参照ください。
`パス`	キャッシュのパス。指定できるパスは1つだけです。
`クォータ`	キャッシュの最大サイズ。例えば、100 Giは、キャッシュの最大サイズが100 GiBであることを示す。
`高い`	ストレージの上限。
`低い`	ストレージの下限。

重要

デフォルトのアクセスモードは読み取り専用モードです。読み取り /書き込みモードを使用する場合は、「データセットのアクセスモードの設定」をご参照ください。

次のコマンドを実行して、データセットとJindoRuntimeをデプロイします。
```
kubectl create -f dataset.yaml
```
次のコマンドを実行して、データセットがデプロイされているかどうかを確認します。
```
kubectl get dataset serverless-data
```
想定される出力：
```
NAME              UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
serverless-data   1.16GiB          0.00B    5.00GiB          0.0%                Bound   2m8s
```
上記の出力のPHASEに [バインド] が表示されます。これは、データセットがデプロイされていることを示します。
次のコマンドを実行して、JindoRuntimeがデプロイされているかどうかを確認します。
```
kubectl get jindo serverless-data
```
想定される出力：
```
NAME              MASTER PHASE   WORKER PHASE   FUSE PHASE   AGE
serverless-data   Ready          Ready          Ready        2m51s
```
上記の出力のFUSEにReadyが表示されます。これは、JindoRuntimeがデプロイされていることを示します。

(オプション) 手順3: データのプリフェッチ

プリフェッチにより、初回データアクセスを効率的に高速化できます。初めてデータを取得する場合は、この機能を使用することをお勧めします。

次のコンテンツに基づいて、dataload.yamlという名前のファイルを作成します。

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

次のコマンドを実行して、DataLoadをデプロイします。
```
kubectl create -f dataload.yaml
```
次のコマンドを実行して、データプリフェッチの進行状況を照会します。
```
kubectl get dataload
```
想定される出力：
```
NAME                     DATASET           PHASE      AGE     DURATION
serverless-data-warmup   serverless-data   Complete   2m49s   45s
```
出力は、データプリフェッチの持続時間が45秒であることを示す。
次のコマンドを実行して、キャッシュ結果を照会します。
```
kubectl get dataset
```
想定される出力：
```
NAME              UFS TOTAL SIZE   CACHED    CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
serverless-data   1.16GiB          1.16GiB   5.00GiB          100.0%              Bound   5m20s
```
出力は、データがプリフェッチされる前にCACHEDの値が0.0% であることを示します。 CACHEDの値は、データがプリフェッチされた後に100.0% される。

手順4: Argoワークフローを使用してOSSにアクセスするコンテナーを作成する

workflow.yamlという名前のファイルを作成し、次のコンテンツをファイルにコピーします。
アプリケーションポッドをelasticコンテナーインスタンスとしてデプロイする
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: model-serving
spec:
  selector:
    matchLabels:
      app: model-serving
  template:
    metadata:
      labels:
        app: model-serving
        alibabacloud.com/fluid-sidecar-target: eci
        alibabacloud.com/eci: "true"
    spec:
      containers:
        - image: fluidcloudnative/serving
          name: serving
          ports:
            - name: http1
              containerPort: 8080
          env:
            - name: TARGET
              value: "World"
          volumeMounts:
            - mountPath: /data
              name: data
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: serverless-data
```
alibabacloud.com/fluid-sidecar-target=eciラベルをアプリケーションポッドに追加して、エラスティックコンテナインスタンスとして実行されることを示します。アプリケーションポッドが作成されると、Fluidはそれを自動的にエラスティックコンテナインスタンスと互換性のある形式に変換します。ユーザーの介入は必要ありません。
ACSアプリケーションポッドの作成
重要
Alibaba Cloud Container Compute Service (ACS) アプリケーションコンテナのキャッシュされたFluidデータにアクセスするには、クラスターでack-fluid v1.0.11以降を使用していることを確認します。
ACSアプリケーションコンテナでキャッシュされたFluidデータへのアクセスは、ACSポッドの高度な機能に依存します。この機能を有効にするには、サポートチケットを起票してください。
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: model-serving
spec:
  selector:
    matchLabels:
      app: model-serving
  template:
    metadata:
      labels:
        app: model-serving
        alibabacloud.com/fluid-sidecar-target: acs
        alibabacloud.com/acs: "true"
        alibabacloud.com/compute-qos: default
        alibabacloud.com/compute-class: general-purpose
    spec:
      containers:
        - image: fluidcloudnative/serving
          name: serving
          ports:
            - name: http1
              containerPort: 8080
          env:
            - name: TARGET
              value: "World"
          volumeMounts:
            - mountPath: /data
              name: data
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: serverless-data
```
alibabacloud.com/fluid-sidecar-target=acsラベルをアプリケーションポッドに追加して、ACSコンピューティングリソースを使用することを宣言します。アプリケーションポッドが作成されると、Fluidは自動的にACS環境で実行されるように適応し、ユーザーの介入は必要ありません。
次のコマンドを実行して、Argoワークフローを作成します。
```
kubectl create -f workflow.yaml
```
次のコマンドを実行して、コンテナログを印刷します。
```
kubectl logs serverless-workflow-g5knn-3271897614
```
想定される出力：
```
real    0m1.948s
user    0m0.000s
sys     0m0.668s
```
出力のrealフィールドは、Servingファイルの複製に1.948秒 (0m1.948秒) かかったことを示しています。キャッシュなしモードでファイルをレプリケートするのに24.966秒 (0m24.966秒) かかりました。詳細については、「Argoワークフローの加速」をご参照ください。キャッシュなしモードの期間は、キャッシュモードの期間と比較して13倍増加します。

ステップ5: データのクリア

データアクセスの高速化をテストした後、できるだけ早い機会に関連データをクリアします。

次のコマンドを実行して、コンテナーを削除します。
```
kubectl delete workflow serverless-workflow-g5knn
```
次のコマンドを実行して、データセットを削除します。
```
kubectl delete dataset serverless-data
```