Dokumen ini memberikan ringkasan konsep penskalaan otomatis untuk workload AI/ML di Google Kubernetes Engine (GKE).
Dokumen ini ditujukan untuk engineer Machine Learning (ML) yang baru menggunakan GKE. Sebaiknya baca dokumen berikut dalam seri ini untuk mempermudah penggunaan GKE untuk workload AI/ML:
- Alasan menggunakan GKE untuk inferensi AI/ML
- Tentang inferensi model AI/ML di GKE
- Konsep penskalaan otomatis yang disederhanakan untuk workload AI/ML di GKE (dokumen ini)
Sebelum memulai
Anda harus memiliki pemahaman dasar tentang konsep berikut:
- Objek Kubernetes dasar: pahami apa itu container, Pod, dan node, serta bagaimana keterkaitannya satu sama lain.
- Arsitektur cluster GKE dasar: pahami cara berbagai komponen cluster GKE berinteraksi satu sama lain.
Tantangan: memenuhi permintaan puncak
Cymbal Shops, retailer online fiktif, sedang mempersiapkan acara penjualan tahunannya. Mesin rekomendasi berteknologi AI di toko harus memberikan saran yang dipersonalisasi secara real-time kepada banyak pembeli online.
Jika mesin pemberi saran melambat, pengalaman pengguna akan terganggu, dan penjualan akan hilang. Namun, menyediakan kapasitas server yang berlebihan tidak hemat biaya selama periode traffic normal. Tujuannya adalah agar resource diskalakan secara otomatis sebagai respons terhadap permintaan, sehingga memastikan pengalaman pengguna yang baik sekaligus mengontrol biaya.
Solusinya: penskalaan otomatis sesuai permintaan
Penskalaan otomatis GKE berfungsi seperti manajer toko yang bersiap menghadapi lonjakan penjualan. Daripada mempertahankan gedung besar dengan staf lengkap dan selalu menyala, pengelola secara dinamis menyesuaikan seluruh kapasitas toko--staf, ruang lantai, dan peralatan--agar sesuai dengan kebutuhan pembeli pada waktu tertentu.
GKE menerapkan prinsip yang sama: GKE secara otomatis menskalakan resource yang dialokasikan ke aplikasi Anda (baik workload maupun infrastruktur) berdasarkan permintaan real-time.
Manfaat bisnis penskalaan otomatis GKE
Dengan menggabungkan strategi penskalaan horizontal dan vertikal, GKE menawarkan pendekatan yang andal dan memberikan tiga manfaat inti:
- Pengoptimalan biaya: Anda hanya membayar resource komputasi yang Anda gunakan, dan menghindari biaya penyediaan yang berlebihan. Penskalaan otomatis GKE mencegah pemborosan dengan secara otomatis menyesuaikan ukuran aplikasi Anda dengan persyaratan CPU dan memori yang sebenarnya. Hal ini juga dapat menyediakan hardware khusus yang mahal (seperti GPU) hanya saat diperlukan, dan menghapusnya saat tugas selesai.
- Peningkatan keandalan dan performa: aplikasi Anda dapat melakukan penskalaan horizontal (menambahkan lebih banyak salinan) secara otomatis untuk menangani lonjakan traffic yang tiba-tiba, sehingga memastikan stabilitas bagi pengguna Anda. Pada saat yang sama, penskalaan otomatis GKE membantu mencegah error "Out of Memory" (OOM) umum yang dapat menyebabkan aplikasi error. Untuk tugas AI/ML yang berat, fitur ini membantu memastikan bahwa hardware berperforma tinggi yang diperlukan tersedia untuk menjalankan dan menyelesaikan tugas secara efisien tepat waktu.
- Mengurangi overhead operasional: Strategi penskalaan otomatis multidimensi GKE menyederhanakan pengelolaan resource secara signifikan. GKE mengotomatiskan tugas kompleks dalam menyesuaikan permintaan resource dan mengelola node pool khusus untuk hardware yang berbeda. Otomatisasi ini memungkinkan tim engineering Anda berfokus pada pengembangan aplikasi, bukan penyesuaian infrastruktur.
Penskalaan otomatis workload
Penskalaan otomatis workload secara otomatis menyesuaikan daya aplikasi Anda agar sesuai dengan permintaan. GKE menggunakan sistem penskalaan otomatis dua tingkat untuk mengelola resource aplikasi Anda secara efisien.
Horizontal Pod Autoscaler (HPA): menambahkan lebih banyak resource
Horizontal Pod Autoscaler (HPA) memantau penggunaan resource Pod aplikasi Anda. Dalam analogi kami, Pod adalah "tenaga penjualan", dan HPA adalah "pengelola tim" yang mengamati seberapa sibuk tenaga penjualan.
Saat permintaan pada Pod meningkat, HPA akan otomatis menyediakan lebih banyak Pod untuk mendistribusikan beban. Saat permintaan menurun, HPA akan menghentikan Pod yang tidak aktif untuk menghemat resource.
Untuk mengetahui informasi selengkapnya, lihat Penskalaan otomatis Pod horizontal.
Vertical Pod Autoscaler (VPA): membuat resource lebih andal
Meskipun penskalaan horizontal berfokus pada peningkatan jumlah resource, penskalaan vertikal adalah strategi pelengkap yang berfokus pada peningkatan kemampuan resource yang ada. Dalam konteks analogi toko offline kami, hal ini bukan tentang merekrut lebih banyak staf, tetapi tentang meningkatkan kemampuan tim saat ini untuk meningkatkan efisiensi masing-masing.
Pendekatan penskalaan vertikal tingkat Pod ini dikelola oleh Penskalaan Otomatis Pod Vertikal (VPA). VPA menganalisis konsumsi resource aplikasi Anda dan menyesuaikan permintaan CPU dan memori Pod ke atas atau ke bawah agar sesuai dengan penggunaan sebenarnya.
VPA dapat menyesuaikan permintaan dan batas resource Pod, misalnya, dengan memprovisi ulang Pod untuk menskalakan dari 1 CPU dan 16 GB menjadi 4 CPU dan 64 GB. Proses ini melibatkan memulai ulang Pod dengan konfigurasi baru yang lebih mumpuni untuk menangani workload-nya dengan lebih baik.
Untuk informasi selengkapnya, lihat referensi berikut:
HPA dan VPA saling melengkapi. HPA menyesuaikan jumlah Pod sebagai respons terhadap perubahan traffic, dan VPA membantu memastikan setiap Pod tersebut berukuran tepat untuk tugasnya. Strategi penskalaan ini mencegah pemborosan resource, menghindari biaya yang tidak perlu, dan membantu memastikan aplikasi Anda tetap responsif dan tersedia selama fluktuasi traffic. Namun, sebaiknya jangan gunakan HPA dan VPA pada metrik yang sama (CPU dan memori) karena dapat menimbulkan konflik. Untuk mengetahui informasi selengkapnya, lihat Batasan penskalaan otomatis Pod horizontal.
Penskalaan otomatis infrastruktur
Penskalaan otomatis infrastruktur akan otomatis menambahkan atau menghapus hardware agar sesuai dengan permintaan workload Anda.
Autoscaler cluster: pengelola gedung
Autoscaler cluster membantu memastikan bahwa ada infrastruktur dasar yang memadai (VM, atau node dalam konteks GKE) untuk mengakomodasi Pod. Node dapat dibandingkan dengan "lantai" toko, dengan autoscaler cluster sebagai "pengelola gedung".
Jika HPA perlu menambahkan lebih banyak Pod, tetapi node yang ada tidak memiliki kapasitas yang tersedia, autoscaler cluster akan menyediakan node baru. Sebaliknya, jika ada node yang kurang dimanfaatkan, autoscaler cluster akan memindahkan Pod node tersebut ke node lain, dan menghentikan node yang sekarang kosong.
Untuk mengetahui informasi selengkapnya, lihat Penskala otomatis cluster.
Pembuatan otomatis node pool: spesialis otomatisasi
Meskipun autoscaler cluster menambahkan node ke node pool yang ada, pembuatan otomatis node pool memperluas kemampuan Autoscaler cluster dengan memungkinkannya membuat node pool baru secara otomatis yang sesuai dengan kebutuhan spesifik Pod Anda.
Workload AI/ML tertentu memerlukan hardware berperforma tinggi khusus seperti GPU atau TPU yang tidak tersedia di kumpulan node tujuan umum. Pembuatan otomatis node pool sepenuhnya mengotomatiskan penyediaan hardware khusus ini saat workload Anda membutuhkannya. Hal ini membantu memastikan bahwa bahkan tugas yang paling intensif secara komputasi mendapatkan hardware yang mereka butuhkan, saat mereka membutuhkannya.
Untuk mengetahui informasi selengkapnya, lihat Tentang pembuatan otomatis node pool.
Untuk akselerator yang tersedia di GKE, lihat berikut ini:
ComputeClasses: pemicu untuk pembuatan otomatis node pool
Meskipun pembuatan otomatis node pool dapat dipicu oleh permintaan Pod untuk jenis hardware tertentu (seperti nvidia-l4-vws), penggunaan ComputeClass adalah metode yang lebih tangguh dan modern. ComputeClass adalah resource GKE yang Anda tentukan dan bertindak berdasarkan serangkaian aturan untuk mengontrol dan menyesuaikan cara penskalaan otomatis hardware Anda. Meskipun bukan autoscaler itu sendiri, fitur ini berfungsi dengan Autoscaler cluster.
Untuk memperluas analogi, anggap ComputeClass sebagai "formulir permintaan pintar" untuk peralatan toko Anda.
Alih-alih meminta hardware tertentu yang kaku (misalnya, "Saya perlu mesin kasir Model 500 Merek X"), rekan penjualan (Pod Anda) meminta kemampuan menggunakan formulir permintaan (misalnya, "Saya perlu stasiun checkout berkecepatan tinggi"). Formulir—ComputeClass—berisi serangkaian aturan untuk tim pembelian (GKE) tentang cara memenuhi pesanan tersebut.
ComputeClass memisahkan permintaan Pod Anda untuk hardware dari tindakan GKE dalam menyediakan hardware tersebut. Daripada meminta mesin tertentu (seperti a3-highgpu-8g), Pod Anda dapat meminta ComputeClass. ComputeClass itu sendiri menentukan logika "pintar", daftar aturan yang diprioritaskan yang memberi tahu GKE cara memenuhi permintaan tersebut.
Untuk mengetahui informasi selengkapnya, lihat Tentang ComputeClass GKE.
Untuk mempelajari ComputeClass secara mendalam dengan contoh dunia nyata dan konfigurasi YAML, lihat panduan teknis: Mengoptimalkan workload GKE dengan ComputeClass kustom.
Metrik dan pemicu utama untuk penskalaan otomatis
Untuk membuat keputusan penskalaan yang tepat, komponen penskalaan otomatis memantau berbagai sinyal. Tabel berikut menunjukkan perbandingan pemicu penskalaan otomatis berbasis metrik.
| Komponen | Bereaksi terhadap | Sumber sinyal | Proses berpikir | Tindakan GKE |
|---|---|---|---|---|
| HPA | Beban saat ini | Konsumsi real-time, misalnya, CPU saat ini berada pada 90%. | "Pods saat ini kelebihan beban. Kita harus segera mendistribusikan traffic ini." | Menskalakan naik atau turun: mengubah jumlah replika Pod untuk memenuhi permintaan. |
| VPA | Efisiensi penentuan ukuran | Penggunaan historis, misalnya, penggunaan RAM rata-rata selama 24 jam terakhir. | "Kebutuhan resource Pod ini telah berubah, atau perkiraan awal kami salah. Kita perlu menyesuaikan alokasi resource-nya agar sesuai dengan penggunaan sebenarnya" | Meningkatkan atau menurunkan skala: mengubah ukuran (batas CPU atau RAM) Pod agar sesuai dengan ukurannya. |
| Pembuatan otomatis node pool | Ketersediaan hardware | Permintaan yang tidak terpenuhi, misalnya, Pod berstatus "Tertunda" karena tidak ada node GPU. | "Pod ini tidak dapat dimulai karena hardware fisik yang dimintanya tidak ada." | Menyediakan infrastruktur: membuat node pool baru dengan hardware tertentu. |
Pemicu Horizontal Pod Autoscaler (HPA): bereaksi terhadap beban
HPA menskalakan jumlah Pod (menskalakan masuk atau keluar) dengan memantau metrik performa real-time. Misalnya, penggunaan CPU dan memori, metrik mendasar yang menunjukkan beban pemrosesan pada Pod Anda, tersedia langsung untuk HPA.
Namun, beberapa metrik memerlukan konfigurasi eksplisit, seperti berikut:
- Metrik load balancer (Permintaan per detik (RPS)): ukuran langsung traffic aplikasi, yang memungkinkan respons penskalaan lebih cepat. Untuk menggunakan metrik ini, lihat Mengaktifkan load balancing berbasis penggunaan dan profil HPA Performa.
- Metrik kustom: Konfigurasi penskalaan otomatis berdasarkan metrik bisnis kustom, seperti "jumlah pengguna aktif", untuk mengelola resource secara proaktif berdasarkan perkiraan permintaan. Untuk menggunakan metrik kustom, Anda harus menyiapkan pipeline metrik untuk mengeksposnya ke HPA. Untuk mengetahui informasi selengkapnya, lihat Google Cloud Managed Service for Prometheus.
Pemicu Autoscaler Pod Vertikal (VPA): bereaksi terhadap kebutuhan resource
VPA menskalakan ukuran Pod Anda (menskalakan ke atas atau ke bawah) dengan memantau konsumsi resource historisnya:
- Penggunaan CPU dan memori: VPA menganalisis penggunaan Pod di masa lalu untuk menentukan apakah permintaan resource-nya sudah benar. Tujuan utama VPA adalah mencegah perebutan resource dengan menambah atau mengurangi permintaan memori dan CPU Pod agar sesuai dengan kebutuhan sebenarnya.
Pemicu pembuatan otomatis node pool: bereaksi terhadap permintaan hardware
Pembuatan otomatis node pool menyediakan node pool baru dengan hardware khusus. Fitur ini tidak dipicu oleh metrik performa seperti beban CPU. Sebaliknya, CA dipicu oleh permintaan resource Pod:
- Permintaan resource yang tidak dapat dijadwalkan: pemicu utama. Saat dibuat, Pod akan meminta hardware tertentu. Jika cluster tidak dapat memenuhi permintaan ini karena tidak ada node yang ada yang memiliki hardware tersebut, pembuatan otomatis node pool akan dilakukan.
- Permintaan ComputeClass: Pod meminta ComputeClass, misalnya,
cloud.google.com/compute-class: premium-gpu. Jika tidak ada node di cluster yang dapat menyediakan kemampuan "premium-gpu", pembuatan otomatis node pool akan otomatis membuat node pool baru yang dapat menyediakan kemampuan tersebut.
Untuk mempelajari cara menggunakan metrik kustom, Prometheus, dan eksternal untuk mencapai penskalaan otomatis, lihat Tentang penskalaan otomatis workload berdasarkan metrik.
Kesimpulan
Dengan menerapkan strategi penskalaan otomatis ini, Anda dapat mengelola beban kerja AI/ML yang berfluktuasi secara efektif. Sama seperti pengelola toko Cymbal Shops yang mengelola acara penjualan puncak mereka secara fleksibel, Anda dapat menggunakan penskalaan otomatis GKE untuk memperluas dan memperkecil resource infrastruktur dan workload secara otomatis. Hal ini membantu memastikan model Anda tetap berperforma baik selama lonjakan traffic dan hemat biaya selama periode sepi, sehingga lingkungan Anda tetap berukuran tepat.
Langkah berikutnya
- Dapatkan ringkasan workload inferensi AI/ML di GKE.
- Pelajari cara menayangkan LLM terbuka di GKE dengan arsitektur yang telah dikonfigurasi sebelumnya.
- Pelajari cara menerapkan ComputeClass ke Pod secara default.