DataLoad ジョブをスケジュールしてデータセットを定期的に更新 - ACK

OSS 内のソースデータが定期的に変更される場合、JindoRuntime キャッシュに依存するアプリケーションポッドは、キャッシュのリフレッシュ間で古いデータを提供してしまう可能性があります。スケジュールされた DataLoad ジョブを使用すると、アプリケーションポッドを再起動することなく、OSS から最新のデータを JindoRuntime キャッシュへ自動的にプルできます。本トピックでは、JindoFS を例として説明します。

前提条件

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

ACK マネージドクラスター Pro エディション（バージョン 1.18 以降）が利用可能であること。詳細については、「ACK マネージドクラスター Pro エディションの作成」をご参照ください。
クラウドネイティブ AI スイートがインストール済みであり、ack-fluid コンポーネント（バージョン 1.0.3）がデプロイ済みであること。
重要
オープンソース版 Fluid をインストール済みの場合は、ack-fluid をデプロイする前にアンインストールしてください。ack-fluid をインストールするには、「クラウドネイティブ AI スイートのインストール」をご参照ください。または、Cloud-native AI Suite ページから ACK コンソールでデプロイします。
kubectl がクラスターに接続するように構成されています。詳細については、「kubectl ツールを使用してクラスターに接続する」をご参照ください。
ossutil がインストール済みであり、OSS バケットが作成済みであること。詳細については、「ossutil のインストール」をご参照ください。

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

テストファイルをダウンロードします。

wget https://archive.apache.org/dist/hbase/2.5.2/RELEASENOTES.md

ファイルを OSS バケットへアップロードします。

ossutil64 cp RELEASENOTES.md oss://<bucket>/<path>/RELEASENOTES.md

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

OSS 認証情報を格納するため、以下の内容で mySecret.yaml というファイルを作成します。

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
stringData:
  fs.oss.accessKeyId: ****** # AccessKey ID を入力してください。
  fs.oss.accessKeySecret: ****** # AccessKey Secret を入力してください。

シークレットを作成します。
```
kubectl create -f mySecret.yaml
```
期待される出力：
```
secret/mysecret created
```

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

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: demo
spec:
  mounts:
    - mountPoint: oss://<bucket-name>/<path>
      options:
        fs.oss.endpoint: <oss-endpoint>
      name: hbase
      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
  accessModes:
    - ReadOnlyMany
---
apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: demo
spec:
  replicas: 1
  tieredstore:
    levels:
      - mediumtype: MEM
        path: /dev/shm
        quota: 2Gi
        high: "0.99"
        low: "0.8"
  fuse:
   args:
    - -okernel_cache
    - -oro
    - -oattr_timeout=60
    - -oentry_timeout=60
    - -onegative_timeout=60

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

リソース	パラメーター	説明
Dataset	`mountPoint`	基盤となるファイルシステム（UFS）へのパスで、形式は `oss://<bucket>/<path>` です。このパスにはエンドポイント情報は含まれません。
Dataset	`fs.oss.endpoint`	OSS バケットのエンドポイントです。パブリックエンドポイントおよびプライベートエンドポイントの両方がサポートされます。
Dataset	`accessModes`	Dataset のアクセスモードです。
JindoRuntime	`replicas`	JindoFS クラスター内のワーカーノード数です。
JindoRuntime	`mediumtype`	キャッシュ記憶媒体です。有効な値は `HDD`、`SSD`、`MEM` です。
JindoRuntime	`path`	ローカル記憶域のパスです。`mediumtype` が `MEM` の場合、ログなどのファイル用にローカルパスを指定します。
JindoRuntime	`quota`	最大キャッシュ容量です。UFS 内のデータサイズに基づいて設定してください。
JindoRuntime	`high`	キャッシュ記憶容量のハイウォーターマークです。
JindoRuntime	`low`	キャッシュ記憶容量のローウォーターマークです。
JindoRuntime	`fuse.args`	オプションの FUSE クライアントマウントパラメーターです。構成は Dataset のアクセスモードによって異なります： - ReadOnlyMany：読み取りパフォーマンス向上のため、カーネルキャッシュを有効化する `kernel_cache` を設定します。`attr_timeout`（ファイル属性キャッシュ）、`entry_timeout`（ファイル名検索キャッシュ）、`negative_timeout`（失敗したファイル名検索キャッシュ）を設定します。すべてのデフォルト値は 7200 秒です。 - ReadWriteMany：デフォルト構成を使用します：`-oauto_cache`、`-oattr_timeout=0`、`-oentry_timeout=0`、`-onegative_timeout=0`。`auto_cache` オプションは、ファイルサイズまたは最終変更時刻が変更された際にキャッシュを無効化します。

dataset.yaml をデプロイして、Dataset および JindoRuntime を作成します。
```
kubectl create -f dataset.yaml
```
期待される出力：
```
dataset.data.fluid.io/demo created
jindoruntime.data.fluid.io/demo created
```

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

kubectl get dataset

期待される出力：

NAME    UFS TOTAL SIZE   CACHED      CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
demo    588.90KiB        0.00B       10.00GiB         0.0%                Bound   2m7s

PHASE フィールドに Bound と表示されれば、Dataset が準備完了です。

ステップ 3：スケジュールされた DataLoad ジョブの作成

デフォルトでは、DataLoad ジョブは対象 Dataset 内のすべてのデータを読み込みます。特定のパスのみ読み込む、または読み込み前にメタデータを同期するなど、より詳細な制御が必要な場合は、「詳細な DataLoad 構成」をご参照ください。

DataLoad では、以下の 2 種類の実行ポリシーがサポートされています。

Once：ジョブが 1 回だけ実行されます。
Cron：ジョブが定期スケジュールで繰り返し実行されます。

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

apiVersion: data.fluid.io/v1alpha1
kind: DataLoad
metadata:
  name: cron-dataload
spec:
  dataset:
    name: demo
    namespace: default
  policy: Cron
  schedule: "*/2 * * * *" # 2 分ごとに実行

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

パラメーター	説明
`dataset`	読み込む Dataset の名前および名前空間です。
`policy`	実行ポリシーです。スケジュールされたジョブの場合は `Cron` を指定します。
`schedule`	ジョブのスケジュール用のcron 式です。詳細については、「cron スケジュール構文」をご参照ください。

DataLoad ジョブをデプロイします。

kubectl apply -f dataload.yaml

期待される出力：

dataload.data.fluid.io/cron-dataload created

DataLoad ジョブのステータスを確認します。
```
kubectl get dataload
```
PHASE が Complete と表示された場合、データがキャッシュへ正常に読み込まれています。
```
NAME            DATASET   PHASE      AGE   DURATION
cron-dataload   demo      Complete   68s   8s
```
データがキャッシュされていることを確認します。
```
kubectl get dataset
```
期待される出力：
```
NAME    UFS TOTAL SIZE   CACHED      CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
demo    588.90KiB        588.90KiB   10.00GiB         100.0%              Bound   5m50s
```
CACHED PERCENTAGE が 100 % であることは、OSS からのすべてのデータがキャッシュへ読み込まれていることを示します。

ステップ 4：アプリケーションポッドからのデータアクセス

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

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - mountPath: /data
          name: demo-vol
  volumes:
    - name: demo-vol
      persistentVolumeClaim:
        claimName: demo

アプリケーションポッドを作成します。
```
kubectl create -f app.yaml
```
期待される出力：
```
pod/nginx created
```
ポッドが準備完了になった後、OSS 内のデータを一覧表示します。
```
kubectl exec -it nginx -- ls -lh /data
```
期待される出力：
```
total 589K
-rwxrwxr-x 1 root root 589K Jul 31 04:20 RELEASENOTES.md
```
RELEASENOTES.md に 1 行を追加して、データ更新をシミュレートします。
```
echo "hello, crondataload." >> RELEASENOTES.md
```

更新されたファイルを OSS へ再アップロードします。

ossutil64 cp RELEASENOTES.md oss://<bucket-name>/<path>/RELEASENOTES.md

プロンプトが表示されたら、上書きを確認するために y を入力します。期待される出力：

cp: overwrite "oss://<bucket-name>/<path>/RELEASENOTES.md"(y or N)? y
Succeed: Total num: 1, size: 21. OK num: 1(upload 1 files).

次のスケジュールされた DataLoad 実行を待機した後、ジョブのステータスを確認します。

kubectl describe dataload cron-dataload

期待される出力（関連フィールド）：

Status:
  Conditions:
    Last Probe Time:       2023-08-24T06:44:08Z
    Last Transition Time:  2023-08-24T06:44:08Z
    Status:                True
    Type:                  Complete
  Duration:                8s
  Last Schedule Time:      2023-08-24T06:44:00Z # 最後に DataLoad ジョブがスケジュールされた時刻。
  Last Successful Time:    2023-08-24T06:44:08Z # 最後に DataLoad ジョブが完了した時刻。
  Phase:                   Complete

更新されたファイルがキャッシュされていることを確認します。
```
kubectl get dataset
```
期待される出力：
```
NAME    UFS TOTAL SIZE   CACHED      CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
demo    588.90KiB        1.15MiB     10.00GiB         100.0%              Bound   10m
```
CACHED 値が増加しており、これは更新されたファイルがキャッシュへ読み込まれたことを示しています。
アプリケーションポッドが更新されたコンテンツを読み取れることを確認します。
```
kubectl exec -it nginx -- tail /data/RELEASENOTES.md
```
期待される出力：
```
hello, crondataload.
```

詳細な DataLoad 構成

以下の構成により、デフォルト動作を超えた DataLoad の動作を制御できます。

読み込み前のメタデータ同期

OSS 内のファイルが変更された場合、JindoFS のメタデータビューが同期されていないために古いデータが提供されることがあります。loadMetadata: true を設定すると、DataLoad ジョブ実行前にメタデータを同期できます。

spec:
  ...
  loadMetadata: true

特定のパスのみ読み込む

デフォルトでは、DataLoad は Dataset 内のすべてのデータを読み込みます。サブセットのみを読み込む場合は、1 つ以上のターゲットパスを指定します。

spec:
  ...
  target:
    - path: <path1>
      replicas: 1
    - path: <path2>
      replicas: 2

各ターゲット下の replicas フィールドは、そのパスに対するキャッシュレプリカ数を設定します。

複合的な詳細構成

以下の例では、すべての詳細構成フィールドを参考としてまとめています。

apiVersion: data.fluid.io/v1alpha1
kind: DataLoad
metadata:
  name: cron-dataload
spec:
  dataset:
    name: demo
    namespace: default
  policy: Cron
  schedule: "* * * * *"
  loadMetadata: true
  target:
    - path: <path1>
      replicas: 1
    - path: <path2>
      replicas: 2

（任意）クリーンアップ

データアクセラレーションの設定が不要になった場合は、アプリケーションポッドおよび Dataset を削除します。

kubectl delete -f app.yaml
kubectl delete -f dataset.yaml

期待される出力：

pod "nginx" deleted
dataset.data.fluid.io "demo" deleted
jindoruntime.data.fluid.io "demo" deleted