Untuk memenuhi kebutuhan pengguna dalam berbagai skenario, Function Compute menyediakan empat tipe fungsi: Event Function, Web Function, Task Function, dan GPU Function. Untuk alur kerja pengembangan yang berbeda, Function Compute menyediakan tiga lingkungan runtime: Built-in Runtimes, Custom Runtimes, dan Custom Images. Untuk mengakomodasi kebutuhan pemanfaatan sumber daya dan preferensi penagihan yang berbeda, Function Compute hanya menyediakan Elastic Instance untuk fungsi CPU, serta menyediakan tiga tipe instans untuk fungsi GPU: Elastic Instance, Provisioned Instance, dan Provisioned + Elastic Instance (Mixed Mode). Topik ini menjelaskan fitur-fitur Function Compute beserta skenario penggunaannya guna membantu Anda memilih teknologi yang tepat.
Ikhtisar pemilihan
Saat menggunakan Function Compute, Anda dapat memilih tipe fungsi dan runtime yang sesuai berdasarkan skenario bisnis dan preferensi tumpukan teknologi Anda, serta menggunakan tipe instans untuk mengoptimalkan kinerja dan biaya.
Aplikasi web dan layanan API: Kami merekomendasikan menggunakan Web Function dengan Custom Runtime. Tipe fungsi ini mendukung berbagai framework aplikasi web populer dan dapat diakses langsung melalui browser atau URL.
Pemrosesan file dan pemrosesan aliran data: Kami merekomendasikan menggunakan Event Function dengan Built-in Runtimes. Anda dapat mengonfigurasi pemicu event untuk mengintegrasikan berbagai layanan Alibaba Cloud, seperti Object Storage Service, ApsaraMQ for RocketMQ, dan Simple Log Service (SLS).
Chatbot, generasi teks-ke-gambar, dan skenario inferensi AI lainnya: Kami merekomendasikan menggunakan GPU Function dengan Custom Container. Anda dapat dengan cepat membangun layanan inferensi model AI menggunakan gambar kontainer dari proyek AI populer, seperti ComfyUI, RAG, dan TensorRT.
Tugas asinkron: Kami merekomendasikan menggunakan Task Function dengan Built-in Runtimes untuk menangani pekerjaan berdurasi panjang, seperti tugas terjadwal serta transkoding audio atau video.
Baik Built-in Runtimes maupun Custom Runtime diterapkan sebagai paket kode dan ideal untuk aplikasi ringan.
Untuk penerapan berbasis kontainer, Anda harus menggunakan Custom Container. GPU Function hanya mendukung Custom Container.
Pemilihan tipe fungsi
Item perbandingan | Event Function | Web Function | Task Function | GPU Function |
Deskripsi | Memproses file dan aliran data. Dapat dipicu oleh event dari berbagai layanan cloud, seperti OSS triggers, Kafka triggers, dan SLS triggers. | Mendukung framework aplikasi web populer. Dapat diakses dari browser atau dipanggil melalui URL. | Memproses permintaan asinkron. Dapat melacak dan menyimpan status setiap tahap pemanggilan asinkron. | Mendukung gambar kontainer dari proyek AI populer, seperti Stable Diffusion WebUI, ComfyUI, RAG, dan TensorRT, untuk membangun layanan inferensi model AI secara cepat. |
Kasus penggunaan |
|
|
|
|
Runtime | Direkomendasikan: Built-in Runtime | Direkomendasikan: Custom Runtime | Direkomendasikan: Built-in Runtime | Hanya mendukung Custom Image |
Nonaktif secara default | Nonaktif secara default | Aktif secara default | Nonaktif secara default |
Pemilihan lingkungan runtime
Item perbandingan | Built-in runtime | Custom runtime | Custom image |
Alur kerja pengembangan | Tulis penanganan permintaan menggunakan antarmuka yang didefinisikan oleh Function Compute. | Kembangkan aplikasi menggunakan templat framework web dan langsung lihat hasilnya di titik akhir publik. | Unggah gambar kustom ke ACR lalu terapkan fungsinya, atau gunakan gambar yang sudah ada di ACR. |
Tipe instans yang didukung | Instans CPU | Instans CPU | Instans CPU dan instans GPU |
Tidak didukung | Didukung | Didukung | |
Paling cepat. Paket kode tidak mencakup runtime, sehingga waktu cold start paling singkat. | Cepat. Paket kode berupa server HTTP lebih besar tetapi tidak perlu menarik gambar, sehingga cold start tetap cepat. | Lebih lambat. Memerlukan penarikan gambar, sehingga cold start lebih lambat. | |
Format paket kode | ZIP, JAR (Java), atau folder | Gambar Kontainer | |
Ukuran maksimum adalah 500 MB di beberapa wilayah (seperti Hangzhou) dan 100 MB di wilayah lainnya. Catatan Anda dapat mengonfigurasi Layers untuk menambahkan dependensi dan mengurangi ukuran paket kode. |
Catatan Untuk aplikasi inferensi AI, Anda dapat menyimpan model besar di NAS atau OSS untuk mengurangi ukuran gambar. | ||
Bahasa pemrograman yang didukung | Node.js, Python, PHP, Java, C#, Go | Tidak ada batasan | Tidak ada batasan |
Pemilihan tipe instans
Untuk fungsi CPU, hanya Elastic Instance yang didukung. Untuk GPU Function, Anda dapat memilih tipe instans yang paling sesuai berdasarkan tingkat pemanfaatan sumber daya, sensitivitas latensi, dan kebutuhan stabilitas biaya bisnis Anda. Anda dapat beralih antara ketiga tipe instans tersebut kapan saja tanpa gangguan layanan.
Anda hanya dapat mengikat Provisioned Instance ke GPU Function yang termasuk dalam seri Ada, Ada.2, Ada.3, Hopper, atau Xpu.1.
Elastic Instance
Jika jumlah minimum instans suatu fungsi diatur menjadi 0, instans akan secara otomatis diskalakan berdasarkan volume permintaan dan dilepas saat tidak ada permintaan. Hal ini menerapkan model bayar sesuai penggunaan, di mana Anda hanya dikenai biaya atas sumber daya yang digunakan, sehingga memaksimalkan penghematan biaya. Frekuensi permintaan yang lebih tinggi menghasilkan pemanfaatan sumber daya yang lebih baik dan penghematan biaya yang lebih besar dibandingkan mesin virtual.
Perilaku cold start
Ya, cold start dapat terjadi. Untuk beban kerja yang sensitif terhadap latensi, Anda dapat mengurangi dampak cold start dengan mengatur jumlah minimum instans menjadi 1 atau lebih. Hal ini mengalokasikan sumber daya elastis secara awal, sehingga instans dapat diaktifkan dengan cepat untuk menangani permintaan masuk.
Penagihan (Bayar sesuai penggunaan)
Biaya fungsi mencakup biaya untuk Elastic Instance aktif dan Elastic Instance dalam mode Shallow Hibernation. Jika jumlah minimum instans diatur menjadi 1 atau lebih, kami merekomendasikan mengaktifkan mode Shallow Hibernation. Dalam keadaan ini, Anda tidak dikenai biaya untuk sumber daya vCPU, sedangkan sumber daya GPU hanya dikenai biaya seperlima dari tarif aktif, sehingga secara signifikan menurunkan biaya dibandingkan instans elastis aktif.
Untuk informasi lebih lanjut tentang kasus penggunaan keadaan aktif dan Shallow Hibernation, lihat Elastic Instance.
Provisioned Instance
Tipe instans ini hanya berlaku untuk GPU Function. Anda terlebih dahulu membeli Provisioned Resource Pool, lalu mengalokasikan sejumlah dan tipe tertentu dari instans yang disediakan ke fungsi Anda. Pendekatan ini memberikan biaya tetap yang dapat diprediksi dan ideal untuk beban kerja dengan pemanfaatan sumber daya tinggi, persyaratan latensi ketat, atau kebutuhan penagihan yang stabil.
Setelah membeli kolam sumber daya yang disediakan bulanan, platform mengalokasikan kuota tertentu dari instans boost selain instans yang disediakan berdasarkan langganan Anda. Kuota instans boost ini tidak dikenai biaya.
Perilaku cold start
Tidak, tidak ada cold start. Saat menggunakan Provisioned Instance, permintaan dalam kapasitas yang dialokasikan menerima respons real-time. Jumlah maksimum permintaan konkuren yang dapat ditangani fungsi dihitung sebagai: (Jumlah Provisioned Instance yang dialokasikan) × (Konkurensi instans)+ kuota instans boost. Permintaan yang melebihi batas ini akan mengalami pengendalian aliran (throttle).
Penagihan (Langganan)
Biaya fungsi adalah total biaya langganan untuk semua kolam sumber daya yang disediakan yang telah dibeli. Kuota instans boost tidak dikenai biaya.
Provisioned Instance dan Elastic Instance (Mixed Mode)
Mode ini hanya berlaku untuk GPU Function. Mode ini menggabungkan manfaat Provisioned Instance dan Elastic Instance, sehingga ideal untuk beban kerja dengan fluktuasi trafik signifikan. Sistem pertama-tama menggunakan kolam sumber daya yang disediakan untuk menangani trafik kondisi stabil. Ketika permintaan melebihi kapasitas kolam yang disediakan, sistem secara otomatis melakukan penskalaan dengan meluncurkan instans elastis. Pendekatan ini menjamin kapasitas dasar yang stabil sekaligus mengelola lonjakan trafik secara efektif.
Perilaku cold start
Sebagian. Permintaan yang ditangani oleh kolam sumber daya yang disediakan (hingga jumlah minimum instans) diproses secara real-time tanpa cold start. Namun, saat trafik memicu auto-scaling dan instans elastis baru diluncurkan, instans baru tersebut akan mengalami cold start.
Penagihan
Biaya dalam Mixed Mode terdiri dari komponen langganan dan bayar sesuai penggunaan:
Bagian yang disediakan: Ditagih berdasarkan kuota Provisioned Resource Pool yang telah dibeli.
Bagian elastis: Instans yang diluncurkan melebihi kuota yang disediakan ditagih berdasarkan model bayar sesuai penggunaan, dengan tarif yang sama seperti instans elastis aktif dan shallow hibernation.