Bagaimana Snorkel AI mencapai penghematan biaya lebih dari 40% melalui penskalaan beban kerja machine learning menggunakan Amazon EKS

Startup machine learning (ML) sering kali merupakan pengguna komputasi yang besar karena mereka melatih model besar menggunakan GPU kelas atas dan melakukan deployment model tersebut dalam skala besar untuk pengambilan kesimpulan. AWS Startups berpartner dengan startup sejak awal hingga IPO, dan telah membantu ribuan pendiri dan inovator kecerdasan buatan (AI) membangun bisnis mereka di Amazon Elastic Kubernetes Service (Amazon EKS). Amazon EKS merupakan pilihan populer untuk membangun dan melakukan host model ML karena memberikan fleksibilitas Kubernetes dengan keamanan dan ketahanan sebagai layanan terkelola AWS yang dioptimalkan untuk membangun beban kerja terkontainer yang sangat tersedia.

Snorkel AI adalah salah satu perusahaan yang mendapatkan manfaat dari Amazon EKS. Snorkel AI melengkapi perusahaan Fortune 500, agen federal, dan inovator AI untuk membangun, mengadaptasi, dan menyaring model fondasi (FM) dan model bahasa besar (LLM) agar dapat bekerja dengan akurasi tinggi pada set data khusus domain. Dengan menggunakan pendekatan yang berpusat pada data dari Snorkel untuk pengembangan AI, organisasi telah membangun layanan AI yang siap produksi untuk berbagai kasus penggunaan, termasuk pemrosesan klaim asuransi, penyebaran keuangan, analitik uji klinis, dan percepatan manajemen sumur proaktif untuk pengeboran lepas pantai.

Selama beberapa bulan terakhir, tim Snorkel telah bekerja keras mengatasi tantangan unik dalam merancang infrastruktur yang efisien untuk mendukung beban kerja pengembangan ML tanpa meningkatkan tagihan infrastruktur, menurunkan kecepatan developer, atau mengganggu pengalaman pengguna. Tujuan utama mereka adalah mengurangi pengeluaran komputasi klaster untuk Snorkel Flow, platform ML menyeluruh mereka, hingga lebih dari 40%.

Gambaran umum mengenai Snorkel Flow

Dengan platform pengembangan data AI Snorkel Flow milik Snorkel, tim data dapat membangun aplikasi AI secara cepat menggunakan loop berulang pelabelan terprogram, pelatihan model cepat, dan analisis kesalahan. Setiap proyek dimulai ketika pengguna membuat sejumlah kecil fungsi pelabelan.

Fungsi pelabelan menggunakan heuristik sederhana, basis data eksternal, model warisan, atau bahkan panggilan ke model bahasa yang besar untuk menerapkan label pada petak data yang tidak berlabel berdasarkan intuisi ahli yang dienkodekan. Algoritma pengawasan yang lemah dari platform ini menggabungkan fungsi-fungsi berbasis aturan ini untuk menentukan label yang paling mungkin untuk setiap catatan. Pengguna kemudian melatih model sederhana berdasarkan titik-titik data probabilistik ini dan menilai dampak dari setiap fungsi pelabelan. Pada tahap analisis, pengguna menyelidiki potongan data yang memiliki model dengan performa buruk. Kemudian mereka membangun atau mengubah fungsi pelabelan, melatih model cepat lainnya, dan melanjutkan perulangan. Ketika pengguna puas dengan kualitas label mereka, mereka membangun model akhir pada arsitektur dari kebun binatang model,mulai dari regresi logistik hingga FM, dan mengekspornya untuk deployment.

Karena sifat alur kerja ini, infrastruktur Snorkel Flow mengalami berbagai periode penggunaan komputasi tinggi. Biaya operasi secara alami meningkat seiring dengan meningkatnya basis pelanggan dan kemampuan produk ML Snorkel Flow. Untuk mencapai pertumbuhan yang efisien, Snorkel bertujuan untuk memahami cara meningkatkan margin sembari mengoperasikan perangkat lunak ML canggih. Snorkel menerapkan praktik berikut untuk mencapai pengurangan biaya komputasi klaster hingga lebih dari 40%.

Solusi untuk optimisasi biaya cloud 

Startup perangkat lunak sebagai layanan (SaaS) sering kali memiliki peluang untuk mengoptimalkan pengeluaran cloud mereka. Memahami faktor-faktor unik yang mendorong biaya-biaya ini sangatlah penting.

Untuk Snorkel, terdapat dua faktor penting:

1. Beban kerja pengembangan ML sering membutuhkan perangkat keras khusus dan mahal, seperti GPU. Biasanya, beban kerja ini bersifat “melonjak”.
2. Perusahaan Fortune 500 dan lembaga federal besar menggunakan Snorkel, termasuk lembaga keuangan utama dengan departemen IT canggih yang memiliki persyaratan deployment dan privasi data khusus, dengan menggunakan platform terkontainer.

Tim Snorkel tertarik untuk menciptakan sistem yang memungkinkan penskalaan yang efisien tanpa peningkatan linier dalam biaya infrastruktur. Akibatnya, Snorkel mengembangkan solusi penskalaan otomatis komprehensif yang disesuaikan untuk beban kerja ML mereka di Amazon EKS untuk mengatasi masalah pengeluaran cloud. Solusi ini tidak hanya mempercepat beban kerja yang memerlukan komputasi lonjakan, tetapi juga mencapai tujuan pengurangan biaya mereka.

Selain solusi penskalaan otomatis, strategi utama yang berkontribusi pada pengurangan biaya cloud lebih dari 40% meliputi:

• Kolaborasi dengan para pemimpin rekayasa dan tim AWS untuk mengadopsi Savings Plans melalui optimisasi konfigurasi cloud.
• Pengaturan ukuran sumber daya dengan memantau penggunaan simpul dengan Prometheus dan konsultasi dengan rekayasawan backend untuk mengukur kebutuhan komponen platform.
• Peralihan ke tipe mesin virtual (VM) hemat biaya di Amazon EKS dan pemanfaatan instans Amazon Elastic Compute Cloud (Amazon EC2) multi-GPU untuk meningkatkan performa harga.
• Pelaksanaan modifikasi proses internal di mana para rekayasawan berkolaborasi dengan tim yang berhadapan dengan pelanggan untuk meminimalkan komputasi idle.

Dalam posting ini, Snorkel membagikan proses untuk mengatasi tantangan penskalaan ini guna membantu memfasilitasi desain infrastruktur yang lebih baik untuk sistem ML. Jika Anda baru mengenal Kubernetes, baca posting Pengantar Kubernetes untuk mempelajari selengkapnya mengenai dasar-dasar dan Machine learning di Kubernetes: kebijaksanaan yang dipelajari di posting Snorkel untuk mempelajari selengkapnya mengenai perjalanan mereka dengan Kubernetes sejauh ini.

Seperti apa Snorkel Flow di AWS

Dalam praktiknya, interaksi Snorkel Flow dengan AWS mengikuti urutan yang diuraikan sebagai berikut. Karena platform Snorkel Flow sangat bergantung pada kontainer, migrasi ke AWS nyaris berjalan tanpa hambatan.

• Pengguna mencapai instans Snorkel Flow mereka melalui peramban web mereka, yang memetakan ke aturan di Amazon Route 53.
• Route 53 meneruskan permintaan ke Penyeimbang Beban Aplikasi.
• Penyeimbang Beban Aplikasi kemudian meneruskan permintaan ke pod Snorkel Flow yang berjalan pada klaster EKS bersama. Snorkel mengalihkan tipe instans EC2 dari m5 ke m6a untuk mengoptimalkan biaya sehingga menghasilkan penghematan komputasi sebesar 10% dengan dampak performa yang dapat diabaikan berdasarkan biaya per jam untuk CPU dan RAM yang sama.
• Selain itu, mereka meningkatkan dari satu instans GPU g4dn.8xlarge ke intans multi-GPU g4dn.12xlarge, yang memungkinkan untuk melayani 4x lebih banyak pod GPU.
• Setiap instans Snorkel Flow menggunakan volume Amazon Elastic File System (Amazon EFS) untuk menyimpan file pada disk.
• Antrean Redis yang dilakukan host sendiri pada pod di instans EC2 menampung tugas yang masuk, sementara menunggu pod pekerja mengambilnya.
• Metrik EKS didorong ke Amazon CloudWatch, dan skrip khusus memantau log untuk anomali performa klaster.

Arsitektur ini telah menghasilkan pengalaman yang stabil dan cepat bagi pengguna Snorkel Flow.

Memikirkan kembali cara menskalakan

Sebelum arsitektur yang dijelaskan pada Gambar 1, iterasi awal infrastruktur Snorkel menggunakan sumber daya tetap. Para pengguna Snorkel mengatakan bahwa menyelesaikan beban kerja yang melonjak ini bisa memakan waktu terlalu lama sehingga berdampak negatif pada pengalaman mereka.

Penskalaan manual sumber daya komputasi terbukti tidak dapat diskalakan dan rawan kesalahan, yang menyebabkan biaya cloud tetap tinggi bahkan selama periode penggunaan rendah. Ini adalah hal terburuk dari kedua hal tersebut: efisiensi biaya cloud yang rendah dan performa yang lebih lambat dari yang dibutuhkan.

Untuk mengatasi tantangan ini, Snorkel menerapkan penskalaan otomatis di berbagai tingkatan dalam infrastruktur mereka, seperti yang dibahas di bagian berikut.

Merancang infrastruktur yang dapat diskalakan dengan mempertimbangkan efisiensi biaya

Distribusi Kubernetes dari Snorkel Flow melibatkan serangkaian deployment yang berjalan di klaster EKS yang berisi pod yang menjalankan berbagai komponen platform.

Seperti yang ditunjukkan pada Gambar 2, untuk mengatasi tantangan unik dari bekerja dengan beban kerja komputasi yang melonjak, tim Snorkel memperkenalkan konsep baru untuk pod Kubernetes: mengategorikannya secara semantik sebagai “tetap” atau “fleksibel.”

• Pod yang diperbaiki tidak dapat dipindahkan dengan aman dari simpul ke simpul, baik karena mereka akan kehilangan status penting dalam memori (seperti tugas komputasi yang sedang berlangsung tanpa checkpoint) atau untuk meminimalkan waktu henti yang dapat dihindari untuk komponen platform dasar (misalnya, orkestrator untuk klaster Ray).
• Pod yang fleksibel dapat dipindahkan dengan aman ke simpul baru. Perbedaan ini sangat berarti dalam konteks penskalaan otomatis karena simpul penurunan skala melibatkan pemindahan pod dari simpul yang kurang dimanfaatkan saat dihentikan.

Kerangka kerja yang tetap/fleksibel ini memberikan Snorkel sarana khusus domain untuk mengaktifkan penurunan skala klaster otomatis sehingga mereka dapat mengaktifkan autoscaler klaster di Amazon EKS tanpa harus mengirim pesan kepada departemen keuangan mereka setiap jam.

Pendekatan awal Snorkel adalah melakukan deployment podDisruptionBudgets pada klaster EKS untuk mencegah autoscaler klaster memindahkan pod fleksibel pada siang hari dan memindahkan pod tetap sekaligus. Meskipun efektif, pendekatan ini membuat tim Snorkel tidak puas karena memperkecil ukuran simpul yang jauh lebih kecil daripada ukuran yang secara teoretis optimal.

Untuk mengatasi hal ini, Snorkel melapisi optimisasi penjadwalan pod yang mengisolasi pod tetap ke kelompok kecil simpul tetap. Snorkel menjadwalkan pod fleksibel dan pekerja (yang dianggap sebagai pod tetap, tetapi bersifat sementara karena penskalaan otomatis simpul pekerja) dalam kelompok simpul fleksibel yang tersisa.

Dengan perubahan ini, Snorkel dapat menurunkan skala simpul fleksibel secara efisien di malam hari, ketika sudah aman untuk bergerak di sekitar pod fleksibel dan menurunkan sebagian besar pod pekerja.

Dengan mengaktifkan penurunan skala yang efisien dari sebagian besar simpul klaster (yaitu, simpul fleksibel), Snorkel memenuhi target mereka untuk mengurangi biaya cloud untuk melakukan host Snorkel Flow lebih dari 40%.

Detail selengkapnya mengenai solusi penskalaan otomatis Snorkel

Snorkel membagi implementasi solusi yang dijelaskan pada bagian sebelumnya menjadi tiga upaya berurutan:

1. Pertama, Snorkel menerapkan “penskalaan otomatis pekerja,” yaitu layanan penskalaan otomatis berbasis Redis khusus yang memungkinkan pod pekerja mereka untuk menaikkan dan menurunkan skala berdasarkan tugas dalam antrean pekerja.
2. Kedua, mereka menerapkan “penskalaan otomatis klaster” dengan mengonfigurasi ulang deployment Kubernetes mereka untuk memungkinkan autoscaler klaster Kubernetes menurunkan skala simpul, selain menaikkan skala simpul.
3. Ketiga, Snorkel menerapkan “optimisasi penurunan skala simpul” dengan mengelompokkan pod tetap ke dalam kelompok kecil simpul tetap untuk mencegah pod tetap mengganggu penurunan skala simpul yang tersisa.

Penskalaan otomatis pekerja

Platform Snorkel Flow mengabstraksi komputasi menjadi paradigma di mana tugas menunggu dalam antrean Redis dan pekerja berjalan sebagai proses di pod pekerja.

Snorkel menerapkan solusi penskalaan otomatis pekerja (Gambar 3) untuk pod pekerja dengan menjalankan fungsi berulang di API backend Snorkel Flow. Setiap beberapa detik, fungsi ini memeriksa klaster Kubernetes dan Redis untuk kelayakan peningkatan dan penurunan skala.

Jika ada tugas yang menunggu dalam satu atau beberapa antrean berbasis Redis yang relevan, fungsi akan meminta API Kubernetes untuk menyediakan pod pekerja tambahan untuk memproses tugas ini. Jika antrean Redis kosong dan tidak ada tugas yang sedang berjalan di registri tugas, antrean tersebut akan meminta API Kubernetes untuk menghancurkan pod pekerja guna membebaskan sumber daya CPU dan RAM yang dicadangkan.

Seperti yang ditunjukkan pada Gambar 4, dengan diluncurkannya implementasi penskalaan otomatis pekerja ini, pod pekerja Snorkel Flow menjadi bersifat sementara, hanya muncul di klaster saat tugas perlu diproses.

Penskalaan otomatis klaster

Sumber daya PodDisruptionBudget melindungi pod tertentu dari gangguan (misalnya, restart secara sengaja) dengan mengizinkan spesifikasi jumlah maksimum replika pod yang mungkin tidak tersedia pada waktu tertentu. Seperti yang ditunjukkan pada Gambar 5, mengatur nilai deployment secara eksplisit ke 0 memastikan bahwa klaster autoscaler tidak akan menurunkan skala simpul yang menjalankan pod deployment.

Menerapkan sumber daya ini pada instans Snorkel Flow yang dilakukan host dengan aman memungkinkan klaster autoscaler menurunkan skala simpul yang kurang dimanfaatkan. Namun, penghematan biaya yang direalisasikan Snorkel masih kecil. Snorkel masih tidak dapat menurunkan sebagian besar simpul mereka karena semua pod Snorkel Flow dilindungi oleh podDisruptionBudget terkait.

Setelah diperiksa lebih dekat, tim Snorkel menyadari bahwa perlindungan ini tidak perlu ada sepanjang waktu. Beban kerja melonjak dan sebagian besar interaksi pengguna dengan Snorkel Flow terjadi selama hari kerja pelanggan, yang berarti aman untuk melonggarkan perlindungan ini di luar jam kerja. Mirip dengan penskalaan otomatis pekerja, Snorkel menerapkan fungsi berulang yang mengubah podDisruptionBudgets menjadi “nonaktif” dalam semalam untuk pod fleksibel instans dengan mengatur jumlah maksimum replika pod yang tidak tersedia, naik dari 0 (Gambar 6) menjadi 1. Solusi penskalaan otomatis pekerja sebelumnya yang dikombinasikan dengan fitur ClusterAutoscaler dan PodDisruptionBudget mampu menurunkan lebih banyak simpul pekerja yang kurang dimanfaatkan daripada sebelumnya. Pelanggan yang melakukan deployment Snorkel Flow di cloud mereka dapat mengonfigurasi ini sesuai kebutuhan.

Optimisasi penurunan skala simpul

Bahkan dengan perbaikan ini, Snorkel melihat bahwa sebagian besar simpul yang kurang dimanfaatkan tidak diturunkan skalanya sama sekali.

Setelah penyelidikan lebih lanjut, Snorkel menyadari bahwa masalah tersebut berasal dari pod tetap dan fleksibel yang menempati simpul yang sama. Hal ini bermasalah karena pod tetap, yang ditugaskan secara acak semu ke simpul yang berisi pod fleksibel, akan “menyematkan” simpul itu dan mencegah skalanya diturunkan, bahkan saat simpul tersebut kurang dimanfaatkan. Kurangnya kontrol atas penjadwalan pod tetap ini menyebabkan periode di mana sebagian besar simpul klaster tidak dapat diturunkan skalanya, meskipun simpul tersebut mewakili daya komputasi yang jauh lebih banyak daripada yang dibutuhkan pada saat itu.

Snorkel memanfaatkan sumber daya Kubernetes podAffinities untuk mengatasi hal ini, yang memungkinkan mereka membatasi simpul mana yang layak untuk dijalankan oleh pod berdasarkan labelpod lain yang sudah berjalan pada simpul tertentu. Snorkel menambahkan label ke pod untuk membedakan antara pod tetap dan pod fleksibel, serta menambahkan bait podAntiAffinityke konfigurasi deployment-nya untuk memastikan bahwa pod tetap tidak dijadwalkan pada simpul yang menjalankan pod fleksibel, dan sebaliknya.

Implementasi podAffinities ini memungkinkan Snorkel AI untuk membagi simpul menjadi dua grup fungsional: grup simpul tetap yang berisi pod tetap, yang tidak pernah dapat dipindahkan dengan aman antar simpul (misalnya, Redis karena cache), dan grup simpul fleksibel yang berisi pod “fleksibel” yang bersifat sementara (seperti pod pekerja) atau aman untuk dipindahkan di luar jam kerja (seperti semalam penuh).

Meskipun intervensi manual dapat dilakukan selama pemeliharaan platform, Snorkel tidak dapat secara otomatis menurunkan simpul tetap. Namun, solusi ini memungkinkan Snorkel untuk secara otomatis menurunkan skala simpul fleksibel karena mereka kini telah mengisolasi pod yang tidak dapat dipindahkan ke dalam simpul tetap.

Penutup

Tim Snorkel dan AWS Startups berharap bahwa berbagi proses pemikiran dan solusi ini akan membantu startup lain membangun infrastruktur yang lebih baik untuk beban kerja ML, yang dengan cepat menjadi semakin penting seiring ML, model bahasa besar, dan FM lainnya memasuki tahap produksi untuk semua organisasi di seluruh dunia.

Menghadiri AWS Re:Invent 2023? Deployment ini akan disorot sebagai bagian dari sesi Snorkel Menavigasi masa depan AI: Melakukan deployment model generatif di Amazon EKS(sesi CON312). Pastikan untuk memeriksanya!

Terima kasih banyak kepada David Hao, Edmond Liu, dan Alec Xiang karena telah membantu mewujudkan visi teknis ini untuk Snorkel. Terima kasih khusus kepada pihak-pihak yang disebutkan di atas serta Matt Casey, Henry Ehrenberg, Anthony Bishopric, dan seluruh tim rekayasa infrastruktur Snorkel atas umpan balik mereka yang bijaksana mengenai artikel ini.