Me-restart layanan EAS atau memperbarui parameternya memicu pembaruan bergulir. Strategi penerapan ini secara bertahap menggantikan replika lama dengan yang baru, sehingga Anda dapat melakukan upgrade layanan tanpa downtime dan dengan ketersediaan tinggi.
Pembaruan bergulir
Selama pembaruan, sistem membuat replika baru dan secara bertahap menggantikan replika lama berdasarkan konfigurasi Anda. Jika replika baru gagal dijalankan, pembaruan dihentikan sementara. Replika yang gagal tidak menerima traffic, dan replika lama yang tersisa terus melayani permintaan, sehingga layanan Anda tidak terganggu. Anda dapat memilih untuk melakukan rollback pembaruan atau memulai pembaruan baru. Pembaruan baru akan memprioritaskan penghapusan replika gagal dari upaya sebelumnya yang belum selesai.
Dua parameter utama mengatur proses pembaruan bergulir:
-
Exceeds the expected number of replicas (parameter JSON:
rolling_strategy.max_surge)-
Description: Jumlah maksimum replika tambahan yang dapat dibuat sistem selama pembaruan. Nilai ini dapat berupa bilangan bulat positif atau persentase. Nilai yang lebih tinggi mempercepat proses pembaruan.
-
Example: Untuk layanan dengan 100 replika, jika Anda mengatur nilai ini menjadi 20, sistem akan membuat 20 replika baru saat pembaruan dimulai.
-
Default: 2% dari jumlah total replika, dengan minimum 1.
PentingJika Exceeds the expected number of replicas diatur terlalu tinggi, sistem akan membawa sejumlah besar replika baru secara online dan langsung menggantikan jumlah replika lama yang setara. Jika replika baru belum di-warm up, lonjakan traffic mendadak dapat memengaruhi stabilitas layanan.
-
-
Maximum Unavailable Replicas (parameter JSON:
rolling_strategy.max_unavailable)-
Description: Jumlah maksimum replika yang diperbolehkan tidak tersedia selama pembaruan. Pengaturan ini membebaskan resource dan mencegah kekurangan resource menghambat pembaruan.
-
Example: Jika Anda mengatur nilai ini menjadi N, sistem akan segera menghentikan N replika lama saat pembaruan dimulai.
-
Default:
-
Untuk dedicated resource group: Default adalah 1 untuk layanan yang dibuat sebelum 1 September 2023. Untuk layanan yang dibuat pada atau setelah 1 September 2023, default adalah 0 jika elastic pool diaktifkan, dan 1 jika tidak.
-
Untuk public resource group: 0.
-
Untuk Lingjun Intelligent Computing Service: Default adalah 0 untuk layanan yang dibuat sebelum 1 September 2023. Untuk layanan yang dibuat pada atau setelah 1 September 2023, default adalah 2% dari jumlah replika, dengan minimum 1.
-
Penting-
Untuk layanan dengan satu replika, jika Anda mengatur Maximum Unavailable Replicas menjadi 1, replika lama akan dihentikan sebelum replika baru dimulai, sehingga layanan menjadi tidak tersedia sementara.
-
Mengatur Maximum Unavailable Replicas terlalu tinggi dapat menyebabkan terlalu banyak replika offline secara bersamaan. Replika yang tersisa mungkin tidak cukup untuk menangani traffic, sehingga menurunkan ketersediaan layanan.
-
Graceful shutdown
Parameter graceful shutdown memengaruhi stabilitas penghentian replika selama pembaruan bergulir.
-
Graceful Shutdown Time (parameter JSON:
eas.termination_grace_period)-
Description: Durasi waktu, dalam detik, yang ditunggu sistem agar replika dapat shutdown secara mulus. Setelah replika memasuki status Terminating, sistem berhenti mengarahkan traffic kepadanya. Sistem kemudian menunggu periode ini untuk memberi replika kesempatan menyelesaikan permintaan yang sedang diproses sebelum dihentikan. Jika permintaan Anda biasanya memiliki waktu pemrosesan yang panjang, kami merekomendasikan untuk menaikkan nilai ini.
-
Default: 30.
PentingMenurunkan nilai ini dapat memengaruhi stabilitas layanan, sedangkan mengaturnya terlalu tinggi dapat memperlambat pembaruan layanan. Kecuali Anda memiliki kebutuhan khusus, jangan ubah parameter ini.
-
-
Send SIGTERM (parameter JSON:
rpc.enable_sigterm)-
Description: SIGTERM adalah sinyal yang menghentikan proses. Parameter JSON ini menerima nilai
trueataufalse.-
false: Sistem tidak mengirim sinyal SIGTERM saat replika keluar. -
true: Sistem segera mengirim sinyal SIGTERM saat replika keluar. Proses utama layanan harus mengimplementasikan logika graceful shutdown khusus dalam signal handler. Jika tidak, sistem dapat langsung menghentikan proses tersebut, sehingga proses graceful shutdown gagal.
-
-
Default: Dinonaktifkan (
false).
-
Secara default, sistem tidak mengirim sinyal SIGTERM. Hal ini karena sebagian besar kontainer aplikasi tidak menangani sinyal SIGTERM secara default. Jika sebuah kontainer menerima sinyal SIGTERM tanpa penanganan yang sesuai, prosesnya akan langsung keluar. Hal ini melewati proses graceful shutdown dan mengganggu layanan Anda.
Untuk layanan dengan variasi waktu pemrosesan permintaan yang sangat besar, kami merekomendasikan untuk mengaktifkan SIGTERM. Misalnya, jika waktu pemrosesan permintaan berkisar dari beberapa detik hingga 30 menit, mengatur waktu graceful shutdown tetap selama 30 menit akan memperlambat pembaruan layanan. Dalam skenario ini, Anda harus mengonfigurasi kontainer aplikasi Anda untuk menangani sinyal SIGTERM, menyelesaikan permintaan yang sedang diproses, lalu keluar. Hal ini memungkinkan kontrol yang lebih fleksibel atas proses shutdown.
Anda tidak perlu mengaktifkan SIGTERM untuk layanan inferensi asinkron. Saat replika keluar, lapisan kontrol EAS secara otomatis menangani sinyal SIGTERM. Lapisan tersebut berhenti berlangganan permintaan baru dan menunggu permintaan yang ada selesai sebelum menghentikan replika.