Menyesuaikan Penskalaan Otomatis Horizontal untuk pipeline streaming

Dalam pipeline streaming dengan volume data input yang tinggi, umumnya ada pertukaran antara biaya dan latensi. Untuk mempertahankan latensi rendah, Dataflow harus menambahkan worker saat volume traffic meningkat. Faktor lainnya adalah seberapa cepat pipeline harus ditingkatkan atau diturunkan skalanya sebagai respons terhadap perubahan kecepatan data input.

Autoscaler Dataflow memiliki setelan default yang cocok untuk banyak workload. Namun, Anda mungkin ingin menyesuaikan perilaku ini untuk skenario tertentu. Misalnya, latensi rata-rata yang lebih tinggi mungkin dapat diterima untuk mengurangi biaya, atau Anda mungkin ingin Dataflow meningkatkan skala lebih cepat sebagai respons terhadap lonjakan traffic.

Untuk mengoptimalkan Penskalaan Otomatis Horizontal, Anda dapat menyesuaikan parameter berikut:

Menetapkan rentang penskalaan otomatis

Saat membuat tugas streaming baru, Anda dapat menetapkan jumlah worker awal dan jumlah worker maksimum. Untuk melakukannya, tentukan opsi pipeline berikut:

Java

  • --numWorkers: jumlah worker awal yang tersedia saat pipeline mulai berjalan
  • --maxNumWorkers: jumlah worker maksimum yang tersedia untuk pipeline Anda

Python

  • --num_workers: jumlah worker awal yang tersedia saat pipeline mulai berjalan
  • --max_num_workers: jumlah worker maksimum yang tersedia untuk pipeline Anda

Go

  • --num_workers: jumlah worker awal yang tersedia saat pipeline mulai berjalan
  • --max_num_workers: jumlah worker maksimum yang tersedia untuk pipeline Anda

Untuk tugas streaming yang menggunakan Streaming Engine, tanda --maxNumWorkers bersifat opsional. Nilai defaultnya adalah 100. Untuk tugas streaming yang tidak menggunakan Streaming Engine, --maxNumWorkers diperlukan saat Penskalaan Otomatis Horizontal diaktifkan.

Nilai awal --maxNumWorkers juga menentukan jumlah Persistent Disk yang dialokasikan untuk tugas tersebut. Pipeline di-deploy dengan kumpulan Persistent Disk tetap, yang jumlahnya sama dengan --maxNumWorkers. Selama streaming, Persistent Disk didistribusikan ulang sehingga setiap worker mendapatkan jumlah disk terlampir yang sama.

Jika Anda menetapkan --maxNumWorkers, pastikan nilai tersebut menyediakan disk yang cukup untuk pipeline Anda. Pertimbangkan pertumbuhan di masa mendatang saat menetapkan nilai awal. Untuk informasi tentang performa Persistent Disk, lihat Mengonfigurasi Persistent Disk dan VM. Dataflow menagih penggunaan Persistent Disk dan memiliki kuota Compute Engine, termasuk kuota Persistent Disk.

Secara default, jumlah worker minimum adalah 1 untuk tugas streaming yang menggunakan Streaming Engine, dan (maxNumWorkers/15), dibulatkan ke atas, untuk tugas yang tidak menggunakan Streaming Engine.

Memperbarui rentang penskalaan otomatis

Untuk tugas yang menggunakan Streaming Engine, Anda dapat menyesuaikan jumlah worker minimum dan maksimum, tanpa menghentikan atau mengganti tugas. Untuk menyesuaikan nilai ini, gunakan pembaruan tugas saat beroperasi. Perbarui opsi tugas berikut:

  • --min-num-workers: jumlah worker minimum.

  • --max-num-workers: jumlah worker maksimum.

gcloud

Gunakan perintah gcloud dataflow jobs update-options:

gcloud dataflow jobs update-options \
  --region=REGION \
  --min-num-workers=MINIMUM_WORKERS \
  --max-num-workers=MAXIMUM_WORKERS \
  JOB_ID

Ganti kode berikut:

  • REGION: ID wilayah endpoint regional tugas
  • MINIMUM_WORKERS: jumlah minimum instance Compute Engine
  • MAXIMUM_WORKERS: jumlah maksimum instance Compute Engine
  • JOB_ID: ID tugas yang akan diperbarui

Anda juga dapat memperbarui --min-num-workers dan --max-num-workers secara terpisah.

REST

Gunakan projects.locations.jobs.update metode:

PUT https://dataflow.googleapis.com/v1b3/projects/PROJECT_ID/locations/REGION/jobs/JOB_ID?updateMask=runtime_updatable_params.max_num_workers,runtime_updatable_params.min_num_workers
{
  "runtime_updatable_params": {
    "min_num_workers": MINIMUM_WORKERS,
    "max_num_workers": MAXIMUM_WORKERS
  }
}

Ganti kode berikut:

  • PROJECT_ID: Google Cloud project ID tugas Dataflow
  • REGION: ID wilayah endpoint regional tugas
  • JOB_ID: ID tugas yang akan diperbarui
  • MINIMUM_WORKERS: jumlah minimum instance Compute Engine
  • MAXIMUM_WORKERS: jumlah maksimum instance Compute Engine

Anda juga dapat memperbarui min_num_workers dan max_num_workers secara terpisah. Tentukan parameter yang akan diperbarui dalam parameter kueri updateMask, dan sertakan nilai yang diperbarui di kolom runtimeUpdatableParams isi permintaan. Contoh berikut memperbarui min_num_workers:

PUT https://dataflow.googleapis.com/v1b3/projects/my_project/locations/us-central1/jobs/job1?updateMask=runtime_updatable_params.min_num_workers
{
  "runtime_updatable_params": {
    "min_num_workers": 5
  }
}

Untuk tugas yang tidak menggunakan Streaming Engine, Anda dapat mengganti tugas yang ada dengan nilai maxNumWorkers yang diperbarui.

Jika Anda memperbarui tugas streaming yang tidak menggunakan Streaming Engine, tugas yang diperbarui akan menonaktifkan Penskalaan Otomatis Horizontal secara default. Untuk mengaktifkan penskalaan otomatis, tentukan --autoscalingAlgorithm dan --maxNumWorkers untuk tugas yang diperbarui.

Menetapkan petunjuk penggunaan worker

Dataflow menggunakan penggunaan CPU rata-rata sebagai sinyal untuk kapan harus menerapkan Penskalaan Otomatis Horizontal. Secara default, Dataflow menetapkan target penggunaan CPU sebesar 0,8. Jika penggunaan berada di luar rentang ini, Dataflow mungkin akan menambahkan atau menghapus worker.

Untuk mengontrol perilaku penskalaan otomatis dengan lebih baik, Anda dapat menetapkan target penggunaan CPU ke nilai dalam rentang [0.1, 0.9].

  • Tetapkan nilai penggunaan CPU yang lebih rendah jika Anda ingin mencapai latensi puncak yang lebih rendah. Nilai yang lebih rendah memungkinkan Dataflow melakukan penskalaan yang lebih agresif sebagai respons terhadap peningkatan penggunaan worker, dan menurunkan skala dengan lebih konservatif untuk meningkatkan stabilitas. Nilai yang lebih rendah juga memberikan headroom yang lebih besar saat pipeline berjalan dalam kondisi stabil, yang umumnya menghasilkan latensi ekor yang lebih rendah. (Latensi ekor mengukur waktu tunggu terlama sebelum data baru diproses.)

  • Tetapkan nilai yang lebih tinggi jika Anda ingin menghemat resource dan menjaga biaya tetap rendah saat traffic melonjak. Nilai yang lebih tinggi mencegah peningkatan skala yang berlebihan, dengan mengorbankan latensi yang lebih tinggi.

Untuk mengonfigurasi petunjuk penggunaan saat Anda menjalankan tugas non-template, tetapkan worker_utilization_hint opsi layanan. Untuk tugas template, perbarui petunjuk penggunaan sebagai gantinya, karena opsi layanan tidak didukung.

Contoh berikut menunjukkan cara menggunakan worker_utilization_hint:

Java

--dataflowServiceOptions=worker_utilization_hint=TARGET_UTILIZATION

Ganti TARGET_UTILIZATION dengan nilai dalam rentang [0.1, 0.9].

Python

--dataflow_service_options=worker_utilization_hint=TARGET_UTILIZATION

Ganti TARGET_UTILIZATION dengan nilai dalam rentang [0.1, 0.9].

Go

--dataflow_service_options=worker_utilization_hint=TARGET_UTILIZATION

Ganti TARGET_UTILIZATION dengan nilai dalam rentang [0.1, 0.9].

Untuk pipeline baru, sebaiknya lakukan pengujian di bawah beban realistis menggunakan setelan default. Kemudian, evaluasi perilaku penskalaan otomatis saat diterapkan ke pipeline Anda dan lakukan penyesuaian jika diperlukan.

Petunjuk penggunaan hanyalah salah satu faktor yang digunakan Dataflow saat memutuskan apakah akan menskalakan worker. Faktor lain seperti backlog dan kunci yang tersedia dapat mengganti nilai petunjuk. Selain itu, petunjuk ini bukanlah target yang ketat. Autoscaler mencoba mempertahankan penggunaan CPU dalam rentang nilai petunjuk, tetapi metrik penggunaan gabungan mungkin lebih tinggi atau lebih rendah. Untuk mengetahui informasi selengkapnya, lihat Heuristik penskalaan otomatis streaming.

Memperbarui petunjuk penggunaan

Untuk memperbarui petunjuk penggunaan saat tugas berjalan, lakukan pembaruan saat beroperasi sebagai berikut:

gcloud

Gunakan gcloud dataflow jobs update-options perintah:

gcloud dataflow jobs update-options \
  --region=REGION \
  --worker-utilization-hint=TARGET_UTILIZATION \
  JOB_ID

Ganti kode berikut:

  • REGION: ID wilayah endpoint regional tugas
  • JOB_ID: ID tugas yang akan diperbarui
  • TARGET_UTILIZATION: nilai dalam rentang [0.1, 0.9]

Untuk mereset petunjuk penggunaan ke nilai default, gunakan perintah gcloud berikut:

gcloud dataflow jobs update-options \
  --unset-worker-utilization-hint \
  --region=REGION \
  --project=PROJECT_ID \
  JOB_ID

REST

Gunakan projects.locations.jobs.update metode:

PUT https://dataflow.googleapis.com/v1b3/projects/PROJECT_ID/locations/REGION/jobs/JOB_ID?updateMask=runtime_updatable_params.worker_utilization_hint
{
  "runtime_updatable_params": {
    "worker_utilization_hint": TARGET_UTILIZATION
  }
}

Ganti kode berikut:

  • PROJECT_ID: project ID tugas Dataflow. Google Cloud
  • REGION: ID wilayah endpoint regional tugas.
  • JOB_ID: ID tugas yang akan diperbarui.
  • TARGET_UTILIZATION: nilai dalam rentang [0.1, 0.9]

Menetapkan petunjuk paralelisme worker

Untuk menangani penskalaan otomatis dengan operasi panjang yang kurang bergantung pada CPU, seperti workload yang intensif ML, Anda dapat menetapkan petunjuk paralelisme worker menggunakan petunjuk resource Apache Beam. Petunjuk ini mengalihkan penskalaan otomatis ke a mode lain yang dioptimalkan untuk workload yang intensif GPU atau transformasi dengan waktu pemrosesan yang lama.

Contoh berikut menunjukkan cara melampirkan petunjuk paralelisme ke transformasi:

Java

pcoll.apply(MyCompositeTransform.of(...)
  .setResourceHints(
      ResourceHints.create()
          .withMaxActiveBundlesPerWorker(TARGET_PARALLELISM_PER_WORKER)))

Ganti TARGET_PARALLELISM_PER_WORKER dengan nilai yang sesuai untuk kasus penggunaan Anda. Untuk panduan umum, lihat cara memilih nilai awal yang baik.

Python

pcoll | MyPTransform().with_resource_hints(
  max_active_bundles_per_worker="TARGET_PARALLELISM_PER_WORKER")

Ganti TARGET_PARALLELISM_PER_WORKER dengan nilai yang sesuai untuk kasus penggunaan Anda. Untuk panduan umum, lihat cara memilih nilai awal yang baik.

Memilih nilai petunjuk paralelisme worker

Untuk kasus penggunaan ML, nilai awal yang baik setara dengan jumlah model yang berjalan secara paralel dalam setiap worker. Nilai ini dibatasi oleh kapasitas akselerator pada worker dan ukuran model.

Untuk kasus penggunaan lainnya, pipeline terikat memori atau terikat CPU. Untuk pipeline yang terikat memori, gunakan batas memori untuk menghitung pemrosesan paralel maksimum. Untuk pipeline yang terikat CPU, sebaiknya pertahankan kebijakan penskalaan otomatis default, bukan memberikan petunjuk paralelisme.

Anda dapat menyetel nilai dengan cermat untuk mengakomodasi kebutuhan pemrosesan tahap lainnya, seperti menulis ke sink. Meningkatkan nilai sebesar 1 atau 2 saat paralelisme model Anda adalah 2 akan membantu mengenali waktu pemrosesan penulisan ke sink yang lebih cepat dengan memberikan lebih banyak kelonggaran untuk memperhitungkan pemrosesan yang dilakukan di tahap lain. Jika pipeline Anda tidak melibatkan shuffle dan transformasi digabungkan menjadi satu tahap, Anda tidak perlu menyesuaikan nilai untuk transformasi lainnya.

Nilai ini juga dapat disesuaikan untuk menyimulasikan efek penundaan backlog yang dapat diterima. Misalnya, jika Anda merasa nyaman dengan penundaan maksimum 10 menit dan waktu pemrosesan rata-rata model Anda adalah 1 menit, Anda dapat memilih untuk meningkatkan nilai sebesar 1 dengan asumsi jumlah worker maksimum Anda ditetapkan ke 10.

Heuristik penskalaan otomatis yang intensif GPU

Dalam setelan yang intensif GPU yang ditunjukkan melalui petunjuk paralelisme setelan, Dataflow mempertimbangkan beberapa faktor saat melakukan penskalaan otomatis. Faktor-faktor ini mencakup:

  • Kunci yang tersedia. Kunci adalah unit dasar paralelisme di Dataflow.
  • Paket aktif maksimum per worker. Hal ini menunjukkan jumlah ideal maksimum paralelisme pemrosesan dalam worker.

Ide umum di balik keputusan penskalaan adalah menghitung worker yang diperlukan untuk menangani beban saat ini seperti yang ditandai oleh kunci yang tersedia. Misalnya, jika ada 100 kunci yang tersedia untuk diproses dan paralelisme maksimum per worker adalah 10, Anda harus menargetkan untuk memiliki total 10 worker.

Jika pipeline Anda kompleks dan memiliki workload yang intensif GPU dan banyak transformasi yang intensif CPU, sebaiknya aktifkan penyesuaian yang tepat. Hal ini memungkinkan layanan membuat perbedaan yang baik antara pekerjaan yang intensif CPU dan yang intensif GPU, lalu menskalakan setiap kumpulan worker dengan tepat.

Menetapkan tingkat latensi

Penskalaan Otomatis Horizontal Dataflow menggunakan durasi backlog untuk menentukan kapan harus menskalakan worker. Secara default, Dataflow menargetkan backlog kurang dari 15 detik, yang cocok untuk workload real-time tetapi dapat mengakibatkan biaya resource yang lebih tinggi.

Untuk tugas streaming yang menggunakan Streaming Engine, Anda dapat mengonfigurasi nilai minimum backlog dengan memilih tingkat latensi. Tingkat latensi dipetakan ke durasi backlog target, sehingga Anda dapat mengonfigurasi sensitivitas autoscaler terhadap durasi backlog. Keputusan penskalaan otomatis hanya dipicu jika durasi backlog melebihi tingkat yang Anda pilih selama beberapa menit.

Tabel berikut menjelaskan tingkat latensi yang tersedia:

Tingkat latensi Perkiraan waktu backlog yang diizinkan Kasus penggunaan yang dimaksudkan
low_latency Kurang dari 15 detik Memprioritaskan peningkatan skala yang cepat untuk menjaga backlog tetap minimal. Nilai default dipilih jika tidak ada tingkat yang ditentukan
medium_latency Kurang dari 2 menit Titik tengah yang seimbang antara latensi dan biaya resource.
high_latency Kurang dari 10 menit Memprioritaskan penghematan biaya dengan mengizinkan backlog terakumulasi. Dirancang untuk workload yang toleran terhadap jeda.

Untuk mengonfigurasi tingkat latensi saat Anda menjalankan tugas, tetapkan tanda eksperimen enable_latency_tier_lightweight_update:

--experiments=enable_latency_tier_lightweight_update=TIER

Ganti TIER dengan salah satu tingkat latensi yang tersedia (misalnya, medium_latency).

Memperbarui tingkat latensi

Untuk memperbarui tingkat latensi saat tugas berjalan, lakukan pembaruan saat beroperasi menggunakan perintah gcloud dataflow jobs update-options:

gcloud dataflow jobs update-options \
  --region=REGION \
  --latency-tier=TIER \
  JOB_ID

Ganti kode berikut:

  • REGION: ID wilayah endpoint regional tugas
  • JOB_ID: ID tugas yang akan diperbarui
  • TIER: tingkat latensi target. Salah satu dari berikut: low_latency, medium_latency, atau high_latency

Untuk mereset tingkat latensi dan kembali ke perilaku latensi rendah default, gunakan perintah berikut:

gcloud dataflow jobs update-options \
  --unset-latency-tier \
  --region=REGION \
  JOB_ID

Heuristik penskalaan otomatis streaming

Untuk pipeline streaming, tujuan Penskalaan Otomatis Horizontal adalah meminimalkan backlog sekaligus memaksimalkan penggunaan dan throughput worker serta bereaksi cepat terhadap lonjakan beban.

Dataflow mempertimbangkan beberapa faktor saat melakukan penskalaan otomatis, termasuk:

  • Backlog. Perkiraan waktu backlog dihitung dari throughput dan byte backlog yang masih akan diproses dari sumber input. Pipeline dianggap memiliki backlog jika perkiraan waktu backlog tetap berada di atas nilai minimum yang dikonfigurasi. Secara default, nilai minimum ini adalah 15 detik. Untuk mengetahui informasi selengkapnya, lihat Menetapkan tingkat latensi.

  • Target penggunaan CPU. Target default untuk penggunaan CPU rata-rata adalah 0,8. Anda dapat mengganti nilai ini.

  • Kunci yang tersedia. Kunci adalah unit dasar paralelisme di Dataflow.

Dalam beberapa kasus, Dataflow menggunakan faktor berikut dalam keputusan penskalaan otomatis. Jika faktor ini digunakan untuk tugas Anda, Anda dapat melihat informasi tersebut di tab metrik **Penskalaan otomatis**.

  • Pembatasan berbasis kunci menggunakan jumlah kunci pemrosesan yang diterima oleh tugas untuk menghitung batas worker pengguna, karena setiap kunci hanya dapat diproses oleh satu worker dalam satu waktu.

  • Peredaman penurunan skala. Jika Dataflow mendeteksi bahwa keputusan penskalaan otomatis yang tidak stabil telah terjadi, Dataflow akan memperlambat kecepatan penurunan skala untuk meningkatkan stabilitas.

  • Peningkatan skala berbasis CPU menggunakan penggunaan CPU yang tinggi sebagai kriteria peningkatan skala.

  • Untuk tugas streaming yang tidak menggunakan Streaming Engine, penskalaan mungkin dibatasi oleh jumlah Persistent Disk. Untuk mengetahui informasi selengkapnya, lihat Menetapkan rentang penskalaan otomatis.

  • Penskalaan otomatis yang intensif GPU, jika diaktifkan dengan menetapkan petunjuk paralelisme worker. Untuk mengetahui informasi selengkapnya, lihat Heuristik penskalaan otomatis yang intensif GPU

Peningkatan skala. Jika pipeline streaming tetap memiliki backlog dengan paralelisme yang cukup pada worker selama beberapa menit, Dataflow akan meningkatkan skala. Dataflow mencoba menghapus backlog dalam waktu sekitar 150 detik setelah peningkatan skala, mengingat throughput saat ini per worker. Jika ada backlog tetapi worker tidak memiliki paralelisme yang cukup untuk worker tambahan, pipeline tidak akan ditingkatkan skalanya. (Menskalakan jumlah worker di luar jumlah kunci yang tersedia untuk pemrosesan paralel tidak membantu memproses backlog lebih cepat.)

Penurunan skala Saat autoscaler membuat keputusan penurunan skala, backlog adalah faktor prioritas tertinggi. Autoscaler menargetkan backlog berdasarkan tingkat latensi. Jika backlog turun cukup jauh di bawah target selama beberapa menit, dan penggunaan worker rata-rata berada di bawah target penggunaan CPU, Dataflow akan menurunkan skala. Selama backlog dapat diterima, autoscaler mencoba mempertahankan penggunaan CPU mendekati target penggunaan CPU. Namun, jika penggunaan sudah cukup dekat dengan target, autoscaler mungkin akan mempertahankan jumlah worker yang tidak berubah, karena setiap langkah penurunan skala memiliki biaya.

Streaming Engine juga menggunakan teknik penskalaan otomatis prediktif berdasarkan backlog timer. Data yang tidak terbatas dalam pipeline streaming dibagi menjadi jendela dikelompokkan berdasarkan stempel waktu. Di akhir jendela, timer akan diaktifkan untuk setiap kunci yang diproses di jendela tersebut. Pengaktifan timer menunjukkan bahwa jendela telah berakhir untuk kunci tertentu. Streaming Engine dapat mengukur backlog timer dan memprediksi jumlah timer yang akan diaktifkan di akhir jendela. Dengan menggunakan backlog timer sebagai sinyal, Dataflow dapat memperkirakan jumlah pemrosesan yang harus terjadi saat timer mendatang diaktifkan. Berdasarkan perkiraan beban di masa mendatang, Dataflow melakukan penskalaan otomatis terlebih dahulu untuk memenuhi permintaan yang diharapkan.

Metrik

Untuk menemukan batas penskalaan otomatis saat ini untuk tugas, kueri metrik berikut:

  • job/max_worker_instances_limit: Jumlah worker maksimum.
  • job/min_worker_instances_limit: Jumlah worker minimum.

Untuk mendapatkan informasi tentang penggunaan worker, kueri metrik berikut:

  • job/aggregated_worker_utilization: Penggunaan worker gabungan.
  • job/worker_utilization_hint: Petunjuk penggunaan worker saat ini.

Untuk mendapatkan insight tentang perilaku autoscaler, kueri metrik berikut:

  • job.worker_utilization_hint_is_actively_used: Menunjukkan apakah autoscaler secara aktif menggunakan petunjuk penggunaan worker. Jika faktor lain mengganti petunjuk saat metrik ini diambil sampelnya, nilainya adalah false.
  • job/horizontal_worker_scaling: Menjelaskan keputusan yang diambil oleh autoscaler. Metrik ini berisi label berikut:
    • direction: Menentukan apakah autoscaler meningkatkan skala, menurunkan skala, atau tidak melakukan tindakan apa pun.
    • rationale: Menentukan alasan keputusan autoscaler.

Untuk mengetahui informasi selengkapnya, lihat Metrik Cloud Monitoring. Metrik ini juga ditampilkan dalam diagram pemantauan penskalaan otomatis.

Langkah berikutnya