Container Service for Kubernetes：Praktik terbaik untuk kebijakan pengoptimalan cache data Fluid

Kebijakan 1: Pilih tipe instans ECS untuk sistem cache

Kebijakan 2: Pilih media cache

Bandwidth tersedia dari kluster cache terdistribusi bergantung pada bandwidth maksimum tersedia dari setiap node ECS dalam kluster dan media cache yang digunakan. Untuk meningkatkan kinerja sistem cache terdistribusi, Anda dapat menggunakan tipe instans ECS berbandwidth tinggi serta memori atau SSD lokal sebagai media cache. Di Fluid, Anda dapat mengonfigurasi media cache dan kapasitas cache yang berbeda dengan mengatur parameter spec.tieredstore dari objek resource Runtime.

spec:
  tieredstore:
    levels:
      - mediumtype: MEM
        volumeType: emptyDir
        path: /dev/shm
        quota: 30Gi # Kapasitas cache yang dapat disediakan oleh satu replika Worker cache terdistribusi.
        high: "0.99"
        low: "0.95"

Kebijakan 3: Konfigurasikan afinitas penjadwalan antara cache data dan aplikasi

Saat permintaan akses data mengenai cache, pod aplikasi membaca data dari sistem cache. Oleh karena itu, jika pod aplikasi dan sistem cache dideploy di zona berbeda, aplikasi perlu mengakses data cache lintas zona. Untuk mengurangi dampak fluktuasi jaringan lintas zona terhadap proses akses data, Anda harus mempertimbangkan afinitas penjadwalan antara pod aplikasi dan pod sistem cache terkait. Secara spesifik:

• Deploy pod Worker sistem cache dengan afinitas di zona yang sama bila memungkinkan.

• Deploy pod aplikasi dan pod Worker sistem cache dengan afinitas di zona yang sama bila memungkinkan.

Di Fluid, Anda dapat mengonfigurasi afinitas penjadwalan pod Worker sistem cache dengan mengatur spec.nodeAffinity dari objek resource Dataset, seperti ditunjukkan di bawah ini:

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> # Zona tempat pod berada, misalnya cn-beijing-i.

Konfigurasi di atas men-deploy semua pod Worker sistem cache terdistribusi pada node ECS di zona <ZONE_ID>.

Selain itu, Fluid dapat secara otomatis menyuntikkan informasi afinitas cache yang diperlukan ke dalam pod aplikasi. Hal ini memastikan bahwa pod aplikasi dan pod Worker sistem cache dideploy dengan afinitas di zona yang sama bila memungkinkan. Untuk informasi selengkapnya, lihat Optimalkan penjadwalan berdasarkan afinitas cache data.

Kebijakan 4: Optimalkan konfigurasi parameter untuk skenario baca sekuensial penuh file besar

Banyak skenario intensif data melibatkan mode akses data berupa baca sekuensial penuh pada file besar. Contohnya termasuk pelatihan model berdasarkan set data dalam format TFRecord atau Tar, memuat satu atau beberapa file parameter model saat layanan inferensi model AI dimulai, dan membaca format file Parquet untuk analitik data terdistribusi. Untuk skenario seperti ini, Anda dapat menggunakan kebijakan pra-ambil yang lebih agresif untuk meningkatkan kinerja akses data. Misalnya, Anda dapat meningkatkan konkurensi pra-ambil dan volume data pra-ambil sistem cache secara tepat.

Di Fluid, runtime cache terdistribusi yang berbeda memerlukan konfigurasi parameter yang berbeda untuk kebijakan pra-ambilnya, seperti dijelaskan di bawah ini:

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" # Sekitar 2 GB.

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
  ...

Kebijakan 1: Hindari memasang direktori yang berisi banyak file sebagai sumber data dasar

Sistem cache harus memelihara metadata semua file dalam direktori penyimpanan dasar yang dipasang dan mencatat metadata tambahan, seperti status cache setiap file. Jika sistem cache memasang direktori penyimpanan dasar yang berisi banyak file, seperti direktori root sistem penyimpanan skala besar, sistem cache harus menggunakan sejumlah besar sumber daya memori untuk menyimpan metadata dan lebih banyak sumber daya CPU untuk memproses permintaan akses metadata.

Fluid mendefinisikan Dataset sebagai kumpulan data yang secara logis terkait untuk aplikasi tertentu. Satu Dataset berkorespondensi dengan startup sistem cache terdistribusi. Dataset harus menyediakan layanan akselerasi akses data hanya untuk satu atau beberapa tugas intensif data yang terkait. Oleh karena itu, Anda dapat membuat beberapa Dataset dan mendefinisikan subdirektori berbeda dari sumber data dasar di setiap Dataset. Tingkat subdirektori spesifik bergantung pada pengumpulan data yang dibutuhkan aplikasi bisnis. Aplikasi bisnis berbeda dapat menggunakan sistem cache yang terikat ke Dataset berbeda untuk mengakses data. Hal ini memberikan isolasi yang lebih baik antar aplikasi bisnis serta memastikan stabilitas dan kinerja sistem. Contoh konfigurasi Dataset sebagai berikut:

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

Membuat beberapa sistem cache dapat menyebabkan kompleksitas Operasi dan Pemeliharaan (O&M) tambahan. Anda dapat secara fleksibel memilih solusi arsitektur berdasarkan kebutuhan bisnis aktual Anda. Misalnya:

• Jika set data yang akan dicache disimpan dalam satu sistem penyimpanan backend, berukuran kecil, berisi sedikit file, dan memiliki relevansi kuat, Anda dapat membuat satu Dataset Fluid dan sistem cache terdistribusi untuk menyediakan layanan.

• Jika set data yang akan dicache berukuran besar dan berisi banyak file, Anda dapat membaginya menjadi beberapa Dataset Fluid dan sistem cache terdistribusi berdasarkan logika bisnis direktori data. Pod aplikasi dapat mendeklarasikan satu atau beberapa Dataset Fluid yang akan dipasang ke direktori tertentu.

• Jika set data yang akan dicache berasal dari sistem penyimpanan berbeda untuk beberapa pengguna dan diperlukan isolasi data antar pengguna, Anda dapat membuat Dataset Fluid berumur pendek untuk setiap pengguna atau untuk rangkaian pekerjaan terkait data pengguna. Anda juga dapat mengembangkan Operator Kubernetes untuk mengelola beberapa Dataset Fluid di kluster secara fleksibel.

Kebijakan 2: Gunakan persistensi metadata untuk meningkatkan stabilitas sistem cache

Banyak sistem cache terdistribusi menggunakan arsitektur terdistribusi Master-Worker. Mereka bergantung pada komponen pod Master untuk memelihara metadata file dari direktori penyimpanan backend yang dipasang dan mencatat status cache setiap file. Saat aplikasi mengakses data melalui sistem cache tersebut, aplikasi pertama-tama mendapatkan metadata file dari komponen pod Master, lalu mengambil data dari penyimpanan file dasar atau komponen Worker cache. Oleh karena itu, stabilitas komponen pod Master cache sangat penting untuk ketersediaan tinggi sistem cache.

Jika Anda menggunakan JindoRuntime sebagai runtime cache, Anda dapat menggunakan konfigurasi berikut di Fluid untuk meningkatkan ketersediaan komponen pod Master cache:

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"

Pada contoh YAML di atas, demo-jindo-master-meta adalah klaim volume persisten (PVC) yang telah dibuat sebelumnya. PVC ini menggunakan ESSD sebagai volume persisten (PV), yang berarti metadata yang dikelola oleh komponen pod Master dapat disimpan secara persisten dan dapat dimigrasikan bersama pod. Untuk informasi selengkapnya, lihat Gunakan JindoRuntime untuk mempertahankan status komponen pod Master.

Kebijakan 3: Konfigurasikan sumber daya pod FUSE

Program klien sistem cache berjalan di pod FUSE. Pod FUSE memasang sistem file FUSE pada node. Sistem file ini kemudian dipasang ke jalur tertentu pada pod aplikasi dan mengekspos antarmuka akses file POSIX. Hal ini memungkinkan pod aplikasi mengakses data di sistem penyimpanan remote seolah-olah mengakses penyimpanan lokal tanpa mengubah kode aplikasi, serta mendapatkan manfaat akselerasi cache. Program FUSE memelihara saluran data antara aplikasi dan sistem cache. Oleh karena itu, kami merekomendasikan agar Anda mengonfigurasi sumber daya untuk pod FUSE.

Di Fluid, Anda dapat mengatur penggunaan sumber daya pod FUSE dengan mengonfigurasi field spec.fuse.resources dari objek resource Runtime. Untuk menghindari titik pemasangan file rusak akibat error kehabisan memori (OOM) program FUSE, kami merekomendasikan agar Anda tidak mengatur batas memori untuk pod FUSE, atau mengatur batas memori yang besar. Misalnya, Anda dapat mengatur batas memori pod FUSE mendekati ukuran memori alokasi node ECS.

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

Kebijakan 4: Aktifkan fitur self-healing FUSE untuk meningkatkan ketersediaan klien akses data

Program FUSE memelihara saluran data antara aplikasi dan sistem cache. Secara default, jika program FUSE crash karena perilaku tak terduga, kontainer aplikasi tidak dapat lagi mengakses data melalui titik pemasangan sistem file FUSE tersebut, bahkan setelah program FUSE restart dan pulih. Untuk memulihkan akses data, kontainer aplikasi harus direstart. Restart ini memicu ulang logika bind mount dari titik pemasangan sistem file FUSE ke pod aplikasi. Hal ini memengaruhi ketersediaan pod aplikasi.

Fluid menyediakan mekanisme self-healing FUSE. Saat mekanisme ini diaktifkan, kontainer aplikasi tidak perlu direstart. Akses data ke titik pemasangan FUSE dalam kontainer aplikasi secara otomatis dipulihkan dalam waktu singkat setelah program FUSE restart.

Untuk mengaktifkan dan menggunakan fitur self-healing FUSE, lihat Cara mengaktifkan kemampuan auto-recovery FUSE. Fitur self-healing FUSE memiliki banyak keterbatasan. Kami merekomendasikan agar Anda hanya mengaktifkan fitur ini dalam skenario aplikasi tertentu dengan kebutuhan jelas dan sesuai kebutuhan bisnis. Contohnya termasuk skenario pengembangan pemrograman interaktif di mana Anda menggunakan Notebook online atau lingkungan lain untuk mengembangkan dan men-debug aplikasi secara interaktif.

Skenario 1: Data hanya dibaca dan data penyimpanan backend tidak berubah

Kasus penggunaan: Selama proses pelatihan model AI tunggal, sampel data dibaca dari set data tetap untuk pelatihan model iteratif. Cache data dihapus setelah pelatihan selesai.

Konfigurasi: Skenario ini didukung Fluid secara default. Anda dapat menggunakan konfigurasi Dataset Fluid default atau secara eksplisit mengaturnya ke mode read-only.

Contoh konfigurasi:

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: demo-dataset
spec:
  ...
  # accessModes: ["ReadOnlyMany"] ReadOnlyMany adalah nilai default.

Mengatur accessModes: ["ReadOnlyMany"] memastikan bahwa dataset dipasang dalam mode read-only. Hal ini mencegah modifikasi tidak disengaja terhadap dataset selama proses pelatihan dan menyederhanakan manajemen data serta kebijakan cache.

Skenario 2: Data hanya dibaca dan data penyimpanan backend berubah secara periodik

Kasus penggunaan: Sistem cache berada di kluster Kubernetes. Data terkait bisnis dikumpulkan setiap hari dan disimpan di sistem penyimpanan backend. Pekerjaan analisis data dieksekusi secara rutin pada tengah malam untuk menganalisis dan merangkum data bisnis harian baru. Hasil ringkasan ditulis langsung ke sistem penyimpanan backend, melewati cache.

Konfigurasi: Anda dapat menggunakan konfigurasi Dataset Fluid default atau secara eksplisit mengaturnya ke mode read-only, serta mengeksekusi pra-ambil data secara berkala untuk menyinkronkan perubahan data dari sistem penyimpanan backend.

Contoh konfigurasi:

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: demo-dataset
spec:
  ...
  # accessModes: ["ReadOnlyMany"] ReadOnlyMany adalah nilai default.
---
apiVersion: data.fluid.io/v1alpha1
kind: DataLoad
metadata:
  name: demo-dataset-warmup
spec:
  ...
  policy: Cron
  schedule: "0 0 * * *" # Pra-ambil data setiap pukul 00:00.
  loadMetadata: true # Sinkronkan perubahan data dari sistem penyimpanan backend selama pra-ambil data.
  target:
  - path: /path/to/warmup # Menentukan jalur di sistem penyimpanan backend yang perlu dipra-ambil.

• Dengan mengatur accessModes: ["ReadOnlyMany"], Anda memastikan bahwa dataset terutama digunakan untuk operasi baca. Artinya, data bisnis ditulis langsung ke sistem penyimpanan backend tanpa mengganggu lapisan cache, yang memastikan konsistensi dan integritas data.

• Mengatur policy: Cron dan schedule: "0 0 * * *" memastikan bahwa operasi pra-ambil data dieksekusi secara otomatis setiap tengah malam. Pengaturan loadMetadata: true memastikan bahwa metadata juga disinkronkan selama proses pra-ambil.

Skenario 3: Data hanya dibaca tetapi data penyimpanan backend berubah berdasarkan event bisnis

Kasus penggunaan: Layanan inferensi model memungkinkan Anda mengunggah model AI kustom dan menggunakannya untuk inferensi. Model AI yang diunggah ditulis langsung ke sistem penyimpanan backend tanpa dicache. Setelah model berhasil diunggah, Anda dapat memilihnya untuk melakukan inferensi dan melihat hasilnya.

Konfigurasi: Anda dapat menggunakan konfigurasi Dataset Fluid default atau secara eksplisit mengaturnya ke mode read-only. Atur timeout metadata file untuk Runtime Filesystem in Userspace (FUSE) ke nilai kecil, dan nonaktifkan cache metadata sisi server sistem cache.

Contoh konfigurasi:

Gunakan JindoRuntime sebagai runtime cache:

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: demo-dataset
spec:
  mounts:
    - mountPoint: <MOUNTPOINT>
      name: data
      path: /
      options:
        metaPolicy: ALWAYS # Dengan mengatur metaPolicy: ALWAYS, cache metadata sisi server dinonaktifkan.
---
apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: demo-dataset
spec:
  fuse:
    args:
      - -oauto_cache
      # Atur timeout metadata ke 30 detik. Jika xxx_timeout=0, konsistensi kuat dapat disediakan, tetapi efisiensi baca data mungkin sangat berkurang.
      - -oattr_timeout=30 
      - -oentry_timeout=30
      - -onegative_timeout=30
      - -ometrics_port=0

Dengan mengatur metaPolicy: ALWAYS, cache metadata sisi server dinonaktifkan. Hal ini memastikan bahwa setiap akses langsung menanyakan penyimpanan backend untuk mendapatkan metadata terbaru, yang cocok untuk skenario aplikasi yang memerlukan konsistensi lebih kuat.

Skenario 4: Permintaan baca dan tulis berada di direktori berbeda

Kasus penggunaan: Dalam pelatihan AI terdistribusi skala besar, pekerjaan pelatihan membaca sampel data dari set data di direktori A dan menulis checkpoint model ke direktori B setelah setiap epoch. Karena checkpoint model bisa berukuran besar, caching operasi tulis meningkatkan efisiensi.

Konfigurasi: Buat dua Dataset Fluid. Atur mode akses salah satunya ke read-only dan yang lainnya ke read-write. Pasang kedua Dataset Fluid tersebut ke direktori A dan direktori B, masing-masing, untuk mencapai Pemisahan baca/tulis.

Contoh konfigurasi:

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: train-samples
spec:
  ...
  # accessModes: ["ReadOnlyMany"] ReadOnlyMany adalah nilai default.
---
apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: model-ckpt
spec:
  ...
  accessModes: ["ReadWriteMany"] 

Mengatur set data pelatihan train-samples ke mode akses read-only accessModes: ["ReadOnlyMany"] (pengaturan default) memastikan bahwa semua pekerjaan pelatihan hanya dapat membaca data dari direktori ini. Hal ini menjamin ketidakberubahan sumber data dan menghindari potensi masalah konsistensi yang diperkenalkan oleh operasi tulis selama pelatihan. Sementara itu, direktori checkpoint model (model-ckpt) dikonfigurasi dengan mode read-write (accessModes: ["ReadWriteMany"]). Hal ini memungkinkan pekerjaan pelatihan menulis checkpoint model secara aman setelah setiap iterasi dan meningkatkan efisiensi tulis.

Contoh definisi pod aplikasi sebagai berikut:

apiVersion: v1
kind: Pod
metadata:
  ...
spec:
  containers:
  ...
    volumeMounts:
    - name: train-samples-vol
      mountPath: /data/A
    - name: model-ckpt-vol
      mountPath: /data/B
  volumes:
    - name: train-samples-vol
      persistentVolumeClaim:
        claimName: train-samples
    - name: model-ckpt-vol
      persistentVolumeClaim:
        claimName: model-ckpt

Dengan memasang dua volume berbeda (train-samples-vol dan model-ckpt-vol) ke jalur tertentu (/data/A dan /data/B), hal ini mencapai isolasi fisik antara set data pelatihan dan direktori checkpoint model.

Skenario 5: Permintaan baca dan tulis harus berada di direktori yang sama

Kasus penggunaan: Dalam skenario pengembangan pemrograman interaktif, seperti pengembangan Jupyter Notebook online atau VS Code, Anda memiliki direktori ruang kerja pribadi. Direktori ruang kerja ini menyimpan file seperti set data dan kode, dan Anda mungkin sering menambah, menghapus, atau memodifikasi file-file tersebut.

Konfigurasi: Atur mode akses Dataset ke read-write. Kami merekomendasikan menggunakan sistem penyimpanan dengan kompatibilitas Portable Operating System Interface (POSIX) penuh sebagai implementasi backend.

Contoh konfigurasi:

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: myworkspace
spec:
  ...
  accessModes: ["ReadWriteMany"] 

Mengatur accessModes: ["ReadWriteMany"] memastikan bahwa beberapa pengguna atau proses dapat secara konkuren membaca dari dan menulis ke direktori ruang kerja yang sama.