Container Service for Kubernetes:Fluid のキャッシュ最適化ポリシーのベストプラクティス

ポリシー 1: 適切な ECS インスタンスタイプを選択する

パフォーマンスの見積もり

分散キャッシュシステムは、異なるノードのストレージリソースと帯域幅リソースを集約し、上位層アプリケーションにより大きなキャッシュ容量とより高い帯域幅を提供できます。キャッシュシステムのキャッシュ容量、キャッシュ帯域幅、およびポッドの最大帯域幅は、次の式に基づいて計算できます。

• キャッシュシステムのキャッシュ容量 = 各キャッシュシステムワーカーポッドのキャッシュ容量 × キャッシュシステムワーカーポッドの数

• キャッシュ帯域幅 = キャッシュシステムワーカーポッドの数 × min{ワーカーポッドの ECS 最大帯域幅、ワーカーポッドで使用されるキャッシュメディアの I/O スループット} キャッシュ帯域幅は、キャッシュアクセスのための実際の帯域幅と同じではありません。実際の帯域幅は、クライアント ECS インスタンスの帯域幅と、シーケンシャルリードまたはランダムリードなどのアクセスモードによって異なります。

• ポッドの最大帯域幅 = min{ホスティング ECS インスタンスの帯域幅、キャッシュ帯域幅} 複数のポッドが同時にキャッシュにアクセスする場合、キャッシュ帯域幅はポッド間で共有されます。

例

ecs.g7nex.8xlarge タイプの 2 つの ECS インスタンスが Container Service for Kubernetes (ACK) クラスタに追加され、分散キャッシュシステムが構築されるとします。キャッシュシステムは、それぞれ 100 GiB のメモリキャッシュを提供する 2 つのワーカーポッドで構成されています。ポッドは異なる ECS インスタンスで実行されます。アプリケーションポッドは、ecs.gn7i-c8g1.2xlarge タイプの ECS インスタンスにデプロイされます。インスタンスは、8 vCPU、30 GiB のメモリ、および 16 Gbit/s の帯域幅を提供します。キャッシュシステムのキャッシュ容量、キャッシュ帯域幅、およびポッドの最大帯域幅は、次の式に基づいて計算できます。

• キャッシュシステムのキャッシュ容量 = 100 GiB × 2 = 200 GiB

• キャッシュ帯域幅 = 2 × min{40 Gbit/s, メモリ I/O スループット} = 80 Gbit/s

• キャッシュヒットが発生した場合のポッドの最大帯域幅 = min{80 Gbit/s, 16 Gbit/s} = 16 Gbit/s

推奨される ECS インスタンスタイプ

分散キャッシュクラスタの帯域幅は、クラスタ内の ECS インスタンスの最大帯域幅と、クラスタで使用されるキャッシュメディアによって異なります。分散キャッシュシステムのパフォーマンスを向上させるには、高帯域幅を提供する ECS インスタンスを選択し、メモリ、ローカルハードディスクドライブ (HDD)、およびローカル SSD をキャッシュメディアとして使用することをお勧めします。次の ECS インスタンスタイプを選択することをお勧めします。

ECS インスタンスファミリーの詳細については、「インスタンスファミリーの概要」をご参照ください。

ポリシー 2: 適切なキャッシュメディアを選択する

分散キャッシュクラスタの帯域幅は、クラスタ内の ECS インスタンスの最大帯域幅と、クラスタで使用されるキャッシュメディアによって異なります。分散キャッシュシステムのパフォーマンスを向上させるには、高帯域幅を提供する ECS インスタンスを選択し、メモリまたはローカル SSD をキャッシュメディアとして使用することをお勧めします。Fluid では、キャッシュランタイムの spec.tieredstore パラメータを使用して、異なるキャッシュメディアと対応するキャッシュ容量を構成できます。

spec:
  tieredstore:
    levels:
      - mediumtype: MEM
        volumeType: emptyDir
        path: /dev/shm
        quota: 30Gi # 分散キャッシュシステムの各ワーカーポッドによって提供されるキャッシュ容量。
        high: "0.99"
        low: "0.95"

ポリシー 3: キャッシュアフィニティに基づいてポッドをスケジュールする

キャッシュヒットが発生すると、アプリケーションポッドはキャッシュシステムからデータを読み取ります。この場合、ポッドとキャッシュシステムが異なるゾーンにデプロイされていると、ポッドはゾーン間でキャッシュにアクセスする必要があります。ゾーン間のアクセス中にネットワークジッターが発生する可能性があります。ネットワークジッターを回避するには、アプリケーションポッドとキャッシュシステムポッドの間にアフィニティルールを構成できます。詳細：

• アフィニティルールを構成して、キャッシュシステムのワーカーポッドを同じゾーンにデプロイします。

• アフィニティルールを構成して、キャッシュシステムのワーカーポッドがデプロイされているゾーンにアプリケーションポッドをデプロイします。

Fluid では、データセットの spec.nodeAffinity パラメータを使用して、キャッシュシステムのワーカーポッドのアフィニティルールを指定できます。サンプルコード：

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: demo-dataset
spec:
  ...
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: topology.kubernetes.io/zone
              operator: In
              values:
                - <ZONE_ID> # キャッシュシステムのワーカーポッドをデプロイするゾーンの ID。例: cn-beijing-i.

上記のコードブロックを使用して、指定されたゾーン (ゾーン ID: <ZONE_ID>) 内の ECS インスタンスにキャッシュシステムのワーカーポッドをスケジュールできます。

さらに、Fluid はキャッシュアフィニティルールをアプリケーションポッドの仕様に自動的に挿入します。アフィニティルールに基づいて、システムはアプリケーションポッドをキャッシュシステムのワーカーポッドがデプロイされているゾーンにスケジュールしようとします。詳細については、「キャッシュアフィニティに基づいてポッドをスケジュールする」をご参照ください。

ポリシー 4: 大容量ファイルのフルシーケンシャルリードのためにキャッシュシステムパラメータを最適化する

大容量ファイルのフルデータシーケンシャルリードは、データ集約型シナリオで使用されます。たとえば、TFRecord または TAR 形式のデータセットを使用してモデルを学習する場合、推論サービスの起動中に 1 つ以上のモデルファイルをロードする場合、または Parquet ファイルからデータを読み取って分散データ分析を実装する場合に、大容量ファイルのフルデータシーケンシャルリードが必要になります。上記のシナリオでは、プリフェッチを有効にしてデータアクセスを高速化できます。たとえば、プリフェッチの同時実行性とプリフェッチデータのサイズを増やすことができます。

プリフェッチの構成に使用できるパラメータは、Fluid で使用するキャッシュランタイムによって異なります。

kind: JindoRuntime
metadata:
  ...
spec:
  fuse:
    properties:
      fs.oss.download.thread.concurrency: "200"
      fs.oss.read.buffer.size: "8388608"
      fs.oss.read.readahead.max.buffer.count: "200"
      fs.oss.read.sequence.ambiguity.range: "2147483647" # 約 2G。

kind: JuiceFSRuntime
metadata:
  ...
spec:
  fuse:
    options:
      buffer-size: "2048"
      cache-size: "0"
      max-uploads: "150"
  worker:
    options:
      buffer-size: "2048"
      max-downloads: "200"
      max-uploads: "150"
  master:
    resources:
      requests:
        memory: 2Gi
      limits:
        memory: 8Gi
  ...

ポリシー 1: 大規模なディレクトリを基盤となるデータソースにマウントしない

キャッシュシステムは、キャッシュシステムにマウントされたディレクトリ内のすべてのファイルのメタデータを保持し、キャッシュステータスなど、ファイルに関する追加情報を記録します。大規模なストレージシステムのルートディレクトリなど、大規模なディレクトリがキャッシュシステムにマウントされている場合、キャッシュシステムはマウントされたディレクトリ内のファイルのメタデータを格納するために大量のメモリリソースを消費し、メタデータへのアクセスを処理するために追加の CPU リソースを消費します。

Fluid はデータセットの概念を定義します。データセットは、上位層アプリケーション向けの論理的に関連するデータのコレクションです。データセットは、分散キャッシュシステムに対応します。データ集約型アプリケーションまたは関連タスクのデータアクセスを高速化するには、個別のデータセットを使用することをお勧めします。複数のアプリケーションを実行する必要がある場合は、アプリケーションごとに個別のデータセットを作成し、基盤となるデータソースの異なるサブディレクトリを異なるデータセットにマウントすることをお勧めします。マウントされたサブディレクトリには、サブディレクトリがマウントされているアプリケーションに必要なデータが含まれています。これにより、異なるアプリケーションがマウントされたデータセットのキャッシュシステムを使用してデータにアクセスする場合のデータ分離が向上します。また、キャッシュシステムの安定性とパフォーマンスも確保されます。データセットの構成例：

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: demo-dataset
spec:
  ...
  mounts:
  - mountPoint: oss://<BUCKET>/<PATH1>/<SUBPATH>/
    name: sub-bucket

複数のキャッシュシステムは、メンテナンスの複雑さを増大させる可能性があります。ビジネス要件に基づいて柔軟なキャッシュシステムアーキテクチャを選択できます。

• 使用するデータセットのサイズが小さく、相互に強く依存しており、同じストレージシステムに格納されており、ファイル数が少ない場合は、1 つの Fluid データセットと 1 つの分散キャッシュシステムを作成することをお勧めします。

• 使用するデータセットのサイズが大きく、多数のファイルが含まれている場合は、複数の Fluid データセットと複数の分散キャッシュシステムを作成することをお勧めします。1 つまたは複数の Fluid データセットをアプリケーションポッドにマウントできます。

• 使用するデータセットが異なるユーザーの異なるストレージシステムに属しており、ユーザー間のデータ分離が必要な場合は、各ユーザーまたは関連するデータ処理ジョブに対して個別の短命の Fluid データセットを作成することをお勧めします。Kubernetes オペレーターを開発して、複数の Fluid データセットを管理できます。

ポリシー 2: メタデータを永続化してキャッシュシステムの安定性を向上させる

ほとんどの分散キャッシュシステムは、マスターワーカーアーキテクチャを採用しています。マスターポッドは、キャッシュシステムにマウントされたディレクトリ内のすべてのファイルのメタデータを保持し、ファイルのキャッシュステータスを記録する役割を担います。アプリケーションがこのようなキャッシュシステムを使用してファイルにアクセスする場合、アプリケーションはまずマスターポッドからファイルのメタデータを取得し、次にメタデータを使用して基盤となるストレージまたはキャッシュシステムのワーカーポッドからファイルを取得する必要があります。したがって、マスターポッドの安定性は、キャッシュシステムの高可用性にとって非常に重要です。

JindoRuntime を使用する場合、次の構成を使用してマスターポッドの可用性を向上させることができます。

apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: sd-dataset
spec:
  ...
  volumes:
    - name: meta-vol
      persistentVolumeClaim:
        claimName: demo-jindo-master-meta
  master:
    resources:
      requests:
        memory: 4Gi
      limits:
        memory: 8Gi
    volumeMounts:
      - name: meta-vol
        mountPath: /root/jindofs-meta
    properties:
      namespace.meta-dir: "/root/jindofs-meta"

上記の YAML ファイルは、demo-jindo-master-meta という名前の既存の永続ボリューム要求 (PVC) を使用します。これは、ESSD をボリュームとしてマウントするために使用されます。これは、マスターポッドによって保持されるメタデータが永続化され、ポッドとともに移行できることを意味します。詳細については、「JindoRuntime を使用して JindoFS マスターのストレージを永続化する」をご参照ください。

ポリシー 3: FUSE ポッドに適切にリソースを割り当てる

キャッシュシステムクライアントは FUSE ポッドで実行されます。FUSE ポッドは、FUSE ファイルシステムをホスト上のアプリケーションポッドの指定されたパスにマウントし、POSIX (Portable Operating System Interface) を使用してデータを公開します。これにより、アプリケーションコードを変更することなく、アプリケーションポッドからのデータアクセスを高速化できます。リモートストレージへのアクセスは、ローカルストレージへのアクセスと同じくらい高速です。FUSE ポッドは、アプリケーションとキャッシュシステム間のデータトンネルの維持を担当します。FUSE ポッドに適切にリソースを割り当てることをお勧めします。

Fluid では、キャッシュランタイムの spec.fuse.resources パラメータを使用して、FUSE ポッドにリソースを割り当てることができます。FUSE ポッドでメモリ不足 (OOM) エラーが発生した場合、FUSE ファイルシステムがアプリケーションポッドからアンマウントされる可能性があります。この問題を防ぐために、FUSE ポッドのメモリ制限を指定しないか、FUSE ポッドの高いメモリ制限を指定することをお勧めします。たとえば、メモリ制限を ECS インスタンスによって提供されるメモリ量に近い値に設定できます。

spec:
  fuse:
    resources:
      requests:
        memory: 8Gi
    # limits:
    #   memory: <ECS_ALLOCATABLE_MEMORY>

ポリシー 4: FUSE コンポーネントの自動修復を有効にしてクライアントの可用性を向上させる

FUSE ポッドは、アプリケーションとキャッシュシステム間のデータトンネルの維持を担当します。デフォルトでは、予期しない理由で FUSE ポッドがクラッシュした場合、FUSE ポッドが再起動して正常に実行されても、アプリケーションポッドは FUSE ファイルシステムを使用してデータにアクセスできなくなります。この問題を解決するには、アプリケーションポッドを再起動してデータアクセスを復元する必要があります。ポッドが再起動されると、FUSE ファイルシステムがポッドに再マウントされます。ただし、これはアプリケーションの可用性に影響を与える可能性があります。

Fluid は、FUSE の自動修復機能を提供します。この機能は、FUSE ポッドの再起動後、特定の期間内にアプリケーションポッドの FUSE ファイルシステムへのデータアクセスを自動的に復元できます。さらに、アプリケーションポッドを再起動する必要はありません。

FUSE の自動修復機能を有効にする方法の詳細については、「FUSE の自動修復を有効にする方法」をご参照ください。FUSE の自動修復機能には一定の制限があります。したがって、オンラインノートブックやその他のインタラクティブなプログラミング環境を使用してアプリケーションを開発するインタラクティブなプログラム開発シナリオなど、適切なシナリオでのみこの機能を有効にすることをお勧めします。