Fluidを使用してOSSオブジェクトへのアクセスを高速化する方法 -

Fluidは、ビッグデータアプリケーションやAIアプリケーションなど、クラウドネイティブシナリオでのデータ集約型アプリケーション向けの、オープンソースのKubernetesネイティブ分散データセットオーケストレータおよびアクセラレータです。 JindoRuntimeは、Alibaba Cloud E-MapReduce (EMR) チームによって開発されたJindoFSの実行エンジンです。 JindoRuntime は C++ ベースで、データセットの管理とキャッシングを行います。 JindoRuntime は、Object Storage Service (OSS) にも対応しています。 Fluidは、JindoRuntimeの管理とスケジューリングにより、データセットの可観測性、自動スケーリング、移植性を実現します。このトピックでは、登録済みクラスターでFluidを使用してOSSオブジェクトへのアクセスを高速化する方法について説明します。

仕組み

次の図は、OSSオブジェクトへのアクセスを高速化するためにFluidを使用する方法を示しています。访问oss.png

前提条件

外部クラスターは、登録済みクラスターを介してContainer Service for Kubernetes (ACK) に登録されます。詳細については、「ACKコンソールでの登録済みクラスターの作成」および「onectlを使用した登録済みクラスターの作成」をご参照ください。
kubectlクライアントが登録済みクラスターに接続されています。詳細については、「クラスターのkubeconfigファイルを取得し、kubectlを使用してクラスターに接続する」をご参照ください。
OSSが有効化され、バケットが作成されます。詳細については、「OSSの有効化」および「バケットの作成」をご参照ください。

ステップ1: ack-fluidをインストールする

onectlの使用

オンプレミスマシンにonectlをインストールします。詳細については、「Use onectl to manage registered clusters」をご参照ください。
次のコマンドを実行してack-fluidをインストールします。
```
onectl addon install ack-fluid --set pullImageByVPCNetwork=false
```
pullImageByVPCNetwork: オプション。このパラメーターは、仮想プライベートクラウド (VPC) を介してコンポーネントイメージをプルするかどうかを指定します。
期待される出力:
```
Addon ack-fluid, version **** installed.
```

コンソールの使用

ACKコンソールにログインします。左側のナビゲーションウィンドウで、[Marketplace] > [Marketplace] を選択します。
[アプリカタログ] タブで、[ack-fluid] を見つけてクリックします。
ページの右上で、[デプロイ] をクリックします。
[デプロイ] パネルで [クラスター] を指定し、[名前空間] と [リリース名] のデフォルト設定を維持し、[次へ] をクリックします。
[チャートバージョン] を最新バージョンに設定し、コンポーネントパラメーターを設定し、[OK] をクリックします。

ステップ2: データを準備する

次のコマンドを実行して、テストデータセットをダウンロードします。
```
wget https://archive.apache.org/dist/spark/spark-3.0.1/spark-3.0.1-bin-hadoop2.7.tgz
```
テストデータセットをOSSバケットにアップロードします。 OSSが提供するクライアントossutilを使用して、データセットをアップロードできます。詳細については、「ossutilのインストール」をご参照ください。

手順3: 外部Kubernetesクラスターのノードにラベルを追加する

次のコマンドを実行して、外部Kubernetesクラスターのすべてのノードにdemo-oss=trueラベルを追加します。ラベルは、JindoRuntimeのマスターコンポーネントとワーカーコンポーネントをデプロイできるノードを制限する制約を追加します。

kubectl label node **** demo-oss=true

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

mySecret.yamlという名前のファイルを作成し、次の内容をファイルに追加します。
このファイルは、ossのfs.oss.accessKeyIdおよびfs. OSS. accessKeySecretを格納するために使用されます。 Dataset CustomResource (CR) を作成する前に、このファイルを作成する必要があります。
```
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
stringData:
  fs.oss.accessKeyId: ****
  fs.oss.accessKeySecret: ****
```
次のコマンドを実行してmySecretファイルをデプロイし、Secretを生成します。
```
kubectl create -f mySecret.yaml
```
Kubernetesは秘密を自動的に暗号化し、機密データを平文で開示しないようにします。

resource.yamlという名前のファイルを作成し、次の内容をファイルに追加します。このファイルには、Dataset CRとJindoRuntime CRが含まれています。

データセット: バケットに格納されているデータセットと、基になるファイルシステム (UFS) について説明します。

JindoRuntime: キャッシュサービスを提供するためにJindoFSクラスターを起動します。

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: hadoop
spec:
  mounts:
    - mountPoint: oss://<oss_bucket>/<bucket_dir>
      options:
        fs.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:
  # Make sure that the cache runtime runs only on the nodes in the external Kubernetes cluster. 
  master:
    nodeSelector:
      demo-oss: "true"
  worker:
    nodeSelector:
      demo-oss: "true"
  fuse:
    nodeSelector:
      demo-oss: "true"
  replicas: 2
  tieredstore:
    levels:
      - mediumtype: HDD
        path: /mnt/disk1
        quota: 100G
        high: "0.99"
        low: "0.8"

リソース	パラメーター	説明
データセット	mountPoint	`oss://<oss_bucket>/<bucket_dir>` は、マウントするUFSのパスを指定します。パスにエンドポイントを含める必要はありません。
データセット	fs.oss.endpoint	OSSバケットのパブリックエンドポイントまたはプライベートエンドポイント。
JindoRuntime	レプリカ	JindoFSクラスター内のワーカーの数。
	mediumtype	キャッシュのタイプ。 JindoRuntimeテンプレートを作成するときに、JindoFSにHDD、SSD、またはMEMを選択できます。
	パス	キャッシュパス。指定できるパスは1つだけです。キャッシュタイプとしてMEMを選択した場合、ログを保存するローカルパスを指定する必要があります。
	クォータ	キャッシュの最大サイズ。 (単位：GB)
	high	ストレージ容量の上限。
	low	ストレージ容量の下限。

次のコマンドを実行して、Dataset CRとJindoRuntime CRを作成します。
```
kubectl create -f resource.yaml
```

次のコマンドを実行して、Dataset CRのデプロイを照会します。

kubectl get dataset hadoop

期待される出力:

NAME     UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
hadoop        210MiB       0.00B    100.00GiB              0.0%          Bound   1h

次のコマンドを実行して、JindoRuntime CRのデプロイを照会します。

kubectl get jindoruntime hadoop

期待される出力:

NAME     MASTER PHASE   WORKER PHASE   FUSE PHASE   AGE
hadoop   Ready          Ready          Ready        4m45s

次のコマンドを実行して、永続ボリューム (PV) および永続ボリューム要求 (PVC) のステータスを照会します。

kubectl get pv,pvc

期待される出力:

NAME                      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM            STORAGECLASS   REASON   AGE
persistentvolume/hadoop   100Gi      RWX            Retain           Bound    default/hadoop                           52m

NAME                           STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/hadoop   Bound    hadoop   100Gi      RWX                           52m

出力は、DatasetおよびJindoRuntime CRが作成されたことを示します。

手順5: コンテナー化アプリケーションを作成してアクセラレーションサービスを検証する

コンテナ化されたアプリケーションを作成するか、機械学習ジョブを送信してJindoFSアクセラレーションサービスを確認できます。このセクションでは、コンテナ化されたアプリケーションを作成して同じデータセットに複数回アクセスし、消費時間を比較してアクセラレーションサービスを検証する方法について説明します。

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

apiVersion: v1
kind: Pod
metadata:
  name: demo-app
spec:
  containers:
    - name: demo
      image: fluidcloudnative/serving
      volumeMounts:
        - mountPath: /data
          name: hadoop
  volumes:
    - name: hadoop
      persistentVolumeClaim:
        claimName: hadoop

次のコマンドを実行して、コンテナ化アプリケーションを作成します。
```
kubectl create -f app.yaml
```

次のコマンドを実行して、アクセスするファイルのサイズを照会します。

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

期待される出力:

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

次のコマンドを実行して、ファイルのコピーに必要な時間を照会します。
```
time cp /data/spark-3.0.1-bin-hadoop2.7.tgz /test
```
期待される出力:
```
real    1m2.374s
user    0m0.000s
sys     0m0.256s
```
出力は、ファイルのコピーに62秒かかることを示しています。
次のコマンドを実行して、データセットのキャッシュ情報を照会します。
```
kubectl get dataset hadoop
```
期待される出力:
```
NAME     UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
hadoop   209.74MiB       209.74MiB    100.00GiB        100.0%           Bound   1h
```
出力は、データのMiBがキャッシュされ209.7ことを示します。
次のコマンドを実行して、現在のアプリケーションを削除し、同じアプリケーションを作成します。
説明
この操作は、ページキャッシュなどの他の要因が検証結果に与える影響を排除するのに役立ちます。
```
kubectl delete -f app.yaml && kubectl create -f app.yaml
```
次のコマンドを実行して、ファイルのコピーに必要な時間を照会します。
```
kubectl exec -it demo-app -- bash
time cp /data/spark-3.0.1-bin-hadoop2.7.tgz /test
```
期待される出力:
```
real	0m3.454s
user	0m0.000s
sys	  0m0.268s
```
出力は、ファイルをコピーするのに3秒かかることを示します。これは、元の時間の18分の1です。これは、ファイルがJindoFSによってキャッシュされているためです。キャッシュされたファイルにアクセスする方がはるかに高速です。

(オプション) ステップ6: 環境をクリアする

アクセラレーションサービスが不要になった場合は、次のコマンドを実行して環境をクリアします。

次のコマンドを実行して、JindoRuntimeとアプリケーションを削除します。
```
kubectl delete jindoruntime hadoop
```
次のコマンドを実行して、データセットを削除します。
```
kubectl delete dataset hadoop
```