JindoFS による OSS データアクセスの加速化 - ACK

JindoRuntime は、Alibaba Cloud E-MapReduce (EMR) チームが開発し、C++ で実装された JindoFS の実行エンジンです。Kubernetes クラスター内で Object Storage Service (OSS) データのデータセット管理およびキャッシュ機能を提供します。Alibaba Cloud では、JindoFS に対してクラウドサービスレベルのサポートを提供しています。Fluid は JindoRuntime を管理・スケジュールすることで、可観測性、自動スケーリング、およびデータセットのポータビリティを実現します。

本トピックでは、テストデータセットを OSS にアップロードし、Dataset および JindoRuntime を作成した後、ベンチマーク用 Pod を使用してキャッシュによる加速効果を検証する手順について説明します。

制限事項

JindoRuntime を使用するには、ContainerOS 以外のオペレーティングシステムを実行している ACK Pro マネージドクラスターが必要です。ack-fluid コンポーネントは、現在 ContainerOS をサポートしていません。
オープンソース版 Fluid を既にインストール済みの場合は、ack-fluid コンポーネントをデプロイする前に、その Fluid をアンインストールしてください。両方を同時に実行することはサポートされていません。

前提条件

開始する前に、以下の条件を満たしていることを確認してください。

ContainerOS以外のオペレーティングシステムを実行する ACK Pro マネージドクラスターで、Kubernetes 1.18 以降を実行中です。『ACK Pro マネージドクラスターの作成』を参照してください。
クラスター内に ack-fluid コンポーネントがデプロイ済みであること：
- クラウドネイティブ AI スイートがインストールされていない場合は、スイートをインストールする際に [Fluid 加速] を有効化します。詳細については、「クラウドネイティブ AI スイートのデプロイ」をご参照ください。
- クラウドネイティブ AI スイートが既にインストール済みの場合は、ACK コンソールの クラウドネイティブ AI スイート ページに移動し、ack-fluid コンポーネントをデプロイします。
ACK Pro マネージドクラスターに接続された kubectl クライアント。詳細については、「kubectl を使用してクラスターに接続する」をご参照ください。
OSS の有効化。詳細については、「OSS の有効化」をご参照ください。

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

以下の手順では、Alibaba Cloud Linux 3.2104 LTS 64 ビットを実行している Elastic Compute Service (ECS) インスタンスを使用して、テストデータセットをアップロードします。他のオペレーティングシステムの場合は、ossutil および ossutil 1.0 をご参照ください。

テストデータセットを ECS インスタンスにダウンロードします。
```
wget https://archive.apache.org/dist/spark/spark-3.0.1/spark-3.0.1-bin-hadoop2.7.tgz
```
ECS インスタンスに ossutil のインストールを実行します。
examplebucket という名前の OSS バケットを作成します。
```
ossutil64 mb oss://examplebucket
```
期待される出力：
```
0.668238(s) elapsed
```
テストデータセットをバケットにアップロードします。
```
ossutil64 cp spark-3.0.1-bin-hadoop2.7.tgz oss://examplebucket
```

ステップ 2：Dataset および JindoRuntime の作成

JindoRuntime は Kubernetes Secret から OSS の認証情報を読み取るため、Dataset の作成前に Secret を作成してください。

以下の内容で mySecret.yaml というファイルを作成します。xxx の部分を、ステップ 1 で作成した OSS バケットに対する読み取りアクセス権を持つ AccessKey ID および AccessKey Secret に置き換えてください。
```
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
stringData:
  fs.oss.accessKeyId: xxx
  fs.oss.accessKeySecret: xxx
```
Secret を適用します。Kubernetes は格納された値を暗号化するため、プレーンテキストとして公開されることはありません。
```
kubectl create -f mySecret.yaml
```

以下の内容で resource.yaml というファイルを作成します。このファイルでは、Dataset（ご利用の OSS データを指す）および JindoRuntime（キャッシュクラスターを起動する）を定義します。

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:
  replicas: 2
  tieredstore:
    levels:
      - mediumtype: MEM
        path: /dev/shm
        volumeType: emptyDir
        quota: 2Gi
        high: "0.99"
        low: "0.95"

以下の表に、主なパラメーターを示します。

パラメーター	説明	必須	デフォルト
`mountPoint`	基盤となるファイルシステム (UFS) のパス。形式は `oss://<oss_bucket>/<bucket_dir>` です。OSS エンドポイントは含まれません。	はい	—
`fs.oss.endpoint`	OSS バケットのパブリックまたは内部エンドポイント。詳細については、「リージョンとエンドポイント」をご参照ください。	はい	—
`replicas`	JindoFS キャッシュクラスター内のワーカー数。	はい	—
`mediumtype`	キャッシュ記憶媒体。有効な値： `HDD`、`SSD`、`MEM`。	はい	—
`path`	ワーカーノード上のローカル記憶域のパス。1 つのパスのみ許可されます。`mediumtype` が `MEM` の場合、ログなどのデータを格納するために必須です。	はい	—
`quota`	ワーカーごとの最大キャッシュサイズ。	はい	—
`high`	キャッシュエビクションしきい値（ハイウォーターマーク）。使用量がこの比率を超えると、エビクションが開始されます。	いいえ	—
`low`	キャッシュ保持しきい値（ローウォーターマーク）。使用量がこの比率まで低下すると、エビクションが停止します。	いいえ	—

Dataset および JindoRuntime を作成します。
```
kubectl create -f resource.yaml
```

Dataset がバインドされていることを確認します。

kubectl get dataset hadoop

期待される出力：

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

JindoRuntime が準備完了であることを確認します。

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

すべての位相が Ready であり、PVC のステータスが Bound である場合、Dataset および JindoRuntime は準備完了です。

ステップ 3：データ高速化のテスト

Dataset の PVC をマウントする Pod をデプロイし、データがキャッシュされる前後でのファイル読み取り時間を比較します。

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

apiVersion: v1
kind: Pod
metadata:
  name: demo-app
spec:
  containers:
    - name: demo
      image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
      volumeMounts:
        - mountPath: /data
          name: hadoop
  volumes:
    - name: hadoop
      persistentVolumeClaim:
        claimName: hadoop

Pod をデプロイします。
```
kubectl create -f app.yaml
```

Pod 内でシェルを開き、ファイルサイズを確認します。

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

期待される出力：

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

初期読み取り時間を計測します。このアクセスはキャッシュなしで直接 OSS から行われます。
```
time cp /data/spark-3.0.1-bin-hadoop2.7.tgz /dev/null
```
期待される出力：
```
real    0m18.386s
user    0m0.002s
sys    0m0.105s
```
ファイルの読み取りには約 18 秒かかります。

読み取り後のキャッシュ済みデータを確認します。

kubectl get dataset hadoop

期待される出力：

NAME     UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
hadoop   210.00MiB       210.00MiB    4.00GiB        100.0%           Bound   1h

全 210 MiB がローカル記憶域にキャッシュされました。

OS のページキャッシュをクリアするために Pod を削除・再作成し、次回の読み取りが JindoFS キャッシュ（メモリではなく）から行われるようにします。
```
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 /dev/null
```
期待される出力：
```
real    0m0.048s
user    0m0.001s
sys     0m0.046s
```
JindoFS キャッシュを使用すると、同一ファイルの読み取りが 48 ミリ秒で完了します。これは、OSS への直接アクセスと比較して 300 倍以上高速です。

（任意）クリーンアップ

データ高速化が不要になった場合、Pod、Dataset、および JindoRuntime を削除します。

Pod を削除します：

kubectl delete pod demo-app

Dataset および JindoRuntime を削除します：

kubectl delete dataset hadoop

次のステップ

JindoFS で高速化されたデータを使用する機械学習トレーニングジョブを送信するには、クラウドネイティブ AI スイートのドキュメントをご参照ください。
その他のキャッシュ記憶媒体のオプション（HDD、SSD）を試すには、mediumtype および path フィールドを resource.yaml で更新してください。