Bagaimana Cara Kerja NGINX Reload? Mengapa NGINX Tidak Melakukan Hot-Reloading?

Saya baru-baru ini melihat sebuah postingan di Reddit yang bertanya, "Mengapa NGINX tidak mendukung hot reloading?". Anehnya, NGINX, server web terbesar di dunia, tidak mendukung hot reloading? Apakah ini berarti kita semua menggunakan nginx -s reload dengan salah? Dengan pertanyaan ini, mari kita cek bagaimana proses reload NGINX bekerja.

Apa itu NGINX

NGINX adalah server web open-source lintas platform yang dikembangkan dalam bahasa C. Menurut statistik, di antara 1000 situs web dengan lalu lintas tertinggi, lebih dari 40% di antaranya menggunakan NGINX untuk menangani permintaan yang sangat besar.

Mengapa NGINX Sangat Populer

Apa keunggulan NGINX sehingga bisa mengalahkan server web lainnya dan selalu mempertahankan tingkat penggunaan yang tinggi?

Alasan utamanya adalah NGINX dirancang untuk menangani masalah konkurensi tinggi. Oleh karena itu, NGINX dapat memberikan layanan yang stabil dan efisien saat menangani permintaan konkuren yang sangat besar. Selain itu, dibandingkan dengan pesaing sezamannya seperti Apache dan Tomcat, NGINX memiliki banyak desain luar biasa seperti arsitektur berbasis event-driven, mekanisme asinkron penuh untuk menangani IO jaringan, dan sistem manajemen memori yang sangat efisien. Desain-desain luar biasa ini membantu NGINX memanfaatkan sepenuhnya sumber daya perangkat keras server dan menjadikan NGINX sebagai sinonim dari server web.

Selain itu, ada alasan lain seperti:

1. Desain modular yang sangat tinggi membuat NGINX memiliki banyak modul resmi dan pihak ketiga yang kaya fitur.
2. Lisensi BSD yang sangat bebas membuat para pengembang dengan senang hati berkontribusi pada NGINX.
3. Dukungan hot reloading memungkinkan NGINX memberikan layanan 24/7.

Di antara alasan-alasan di atas, hot reloading adalah topik utama kita hari ini.

Apa yang Dilakukan Hot Reload

Apa yang kita harapkan dari hot reloading? Pertama, saya pikir pengguna di sisi klien tidak boleh menyadari bahwa server sedang melakukan reload. Kedua, server atau layanan upstream harus mencapai pemuatan dinamis dan menangani semua permintaan pengguna dengan sukses tanpa downtime.

Dalam situasi apa kita membutuhkan hot reloading? Di era Cloud Native, microservices menjadi sangat populer sehingga semakin banyak skenario aplikasi yang membutuhkan modifikasi sisi server yang sering. Modifikasi-modifikasi ini, seperti online/offline reverse proxy domain, perubahan alamat upstream, dan perubahan daftar izin/blokir IP, terkait dengan hot reloading.

Jadi, bagaimana NGINX mencapai hot reloading?

Prinsip Hot Reloading NGINX

Ketika kita menjalankan perintah hot reload nginx -s reload, itu akan mengirim sinyal HUP ke proses master NGINX. Ketika proses master menerima sinyal HUP, ia akan membuka port listening secara berurutan dan memulai proses worker baru. Oleh karena itu, dua proses worker (lama & baru) akan ada secara bersamaan. Setelah proses worker baru masuk, proses master akan mengirim sinyal QUIT ke proses worker lama untuk mematikannya dengan baik. Ketika proses worker lama menerima sinyal QUIT, ia akan menutup handler listening terlebih dahulu. Sekarang, semua koneksi baru hanya akan masuk ke proses worker baru, dan server akan mematikan proses lama setelah semua koneksi yang tersisa diproses.

Secara teori, apakah hot reloading NGINX dapat memenuhi persyaratan kita dengan sempurna? Sayangnya, jawabannya adalah tidak. Jadi, apa saja kekurangan dari hot reloading NGINX?

Reload NGINX Menyebabkan Downtime

1. Hot reloading yang terlalu sering akan membuat koneksi tidak stabil dan kehilangan data bisnis.

   Ketika NGINX menjalankan perintah reload, proses worker lama akan terus memproses koneksi yang ada dan secara otomatis memutuskan koneksi setelah semua permintaan yang tersisa diproses. Namun, jika klien belum memproses semua permintaan, mereka akan kehilangan data bisnis dari permintaan yang tersisa selamanya. Tentu saja, ini akan menarik perhatian pengguna di sisi klien.

2. Dalam beberapa situasi, waktu daur ulang proses worker lama memakan waktu sangat lama sehingga memengaruhi bisnis reguler.

   Misalnya, ketika kita memproksi protokol WebSocket, kita tidak dapat mengetahui apakah sebuah permintaan telah diproses karena NGINX tidak mem-parsing header frame. Jadi meskipun proses worker menerima perintah quit dari proses master, ia tidak dapat keluar sampai koneksi ini menimbulkan pengecualian, waktu habis, atau terputus.

   Berikut contoh lain, ketika NGINX bertindak sebagai reverse proxy untuk TCP dan UDP, ia tidak dapat mengetahui seberapa sering sebuah permintaan diminta sebelum akhirnya dimatikan.

   Oleh karena itu, proses worker lama biasanya memakan waktu yang lama, terutama di industri seperti live streaming, media, dan pengenalan suara. Terkadang, waktu daur ulang proses worker lama bisa mencapai setengah jam atau bahkan lebih lama. Sementara itu, jika pengguna sering melakukan reload server, itu akan menciptakan banyak proses yang sedang dimatikan dan akhirnya menyebabkan NGINX OOM, yang dapat sangat memengaruhi bisnis.

# selalu ada dalam proses worker lama:
nobody 6246 6241 0 10:51 ? 00:00:00 nginx: worker process
nobody 6247 6241 0 10:51 ? 00:00:00 nginx: worker process
nobody 6247 6241 0 10:51 ? 00:00:00 nginx: worker process
nobody 6248 6241 0 10:51 ? 00:00:00 nginx: worker process
nobody 6249 6241 0 10:51 ? 00:00:00 nginx: worker process
nobody 7995 10419 0 10:30 ? 00:20:37 nginx: worker process is shutting down  <= di sini
nobody 7995 10419 0 10:30 ? 00:20:37 nginx: worker process is shutting down
nobody 7996 10419 0 10:30 ? 00:20:37 nginx: worker process is shutting down

Secara ringkas, kita dapat mencapai hot reloading dengan menjalankan nginx -s reload, yang cukup di masa lalu. Namun, perkembangan pesat microservices dan Cloud Native membuat solusi ini tidak lagi memenuhi persyaratan pengguna.

Jika frekuensi pembaruan bisnis Anda adalah mingguan atau harian, maka NGINX reloading ini masih dapat memenuhi kebutuhan Anda. Namun, bagaimana jika frekuensi pembaruan menjadi per jam atau per menit? Misalnya, jika Anda memiliki 100 server NGINX, dan melakukan reload sekali per jam, maka itu akan membutuhkan 2400 reload per hari; Jika server melakukan reload per menit, maka itu akan membutuhkan 8.640.000 reload per hari, yang tidak dapat diterima.

Kita membutuhkan solusi tanpa proses switching, dan itu juga dapat mencapai pembaruan konten segera.

Hot Reloading yang Langsung Berpengaruh di Memori

Ketika Apache APISIX lahir, ia dirancang untuk menyelesaikan masalah hot reloading NGINX. APISIX dikembangkan berdasarkan tumpukan teknologi NGINX dan Lua, dan merupakan gateway API microservice cloud-native berkinerja tinggi yang sepenuhnya dinamis yang menggunakan etcd sebagai pusat konfigurasi intinya. Tidak perlu me-reboot server untuk memuat ulang konfigurasi server baru, artinya perubahan apa pun pada layanan upstream, rute, atau plugin tidak memerlukan reboot server. Tetapi bagaimana APISIX dapat menghilangkan batasan NGINX untuk mencapai hot reloading yang sempurna berdasarkan fakta bahwa APISIX dikembangkan di atas tumpukan teknologi NGINX?

Pertama, mari kita lihat arsitektur perangkat lunak Apache APISIX:

APISIX dapat mencapai hot reloading yang sempurna karena menempatkan semua konfigurasi ke dalam APISIX Core dan Plugin Runtime sehingga mereka dapat menggunakan penugasan dinamis. Misalnya, ketika NGINX perlu mengonfigurasi parameter di dalam file konfigurasi, setiap modifikasi hanya akan berlaku setelah reload. Untuk mengonfigurasi rute secara dinamis, Apache APISIX hanya mengonfigurasi satu server tertentu dengan hanya satu lokasi. Kita harus menggunakan lokasi ini sebagai pintu masuk utama sehingga semua permintaan akan melewatinya terlebih dahulu, dan kemudian APISIX Core akan secara dinamis menetapkan upstream tertentu untuk mereka. Modul rute Apache APISIX dapat mendukung penambahan/penghapusan, modifikasi, dan penghapusan rute saat server berjalan. Dengan kata lain, itu dapat mencapai reloading dinamis. Tidak ada perubahan ini yang akan menarik perhatian pengguna dan memengaruhi bisnis reguler.

Sekarang, mari kita perkenalkan skenario klasik; misalnya, jika kita ingin menambahkan reverse proxy untuk domain baru, kita hanya perlu membuat upstream di APISIX dan menambahkan rute baru. NGINX tidak perlu reboot selama proses ini. Berikut contoh lain untuk sistem plugin: APISIX dapat menggunakan plugin IP-restriction untuk mencapai fitur daftar izin/blokir IP. Semua pembaruan fitur ini bersifat dinamis dan tidak memerlukan reboot server. Berkat etcd, strategi konfigurasi dapat mencapai pembaruan instan menggunakan add-on, dan semua konfigurasi dapat langsung berlaku dan memberikan pengalaman pengguna terbaik.

Kesimpulan

Hot reloading NGINX akan memiliki satu proses worker lama dan satu baru dalam beberapa situasi, yang menyebabkan pemborosan sumber daya tambahan. Selain itu, hot reloading yang terlalu sering dapat menyebabkan kemungkinan kecil kehilangan total data bisnis. Di latar belakang Cloud Native dan microservices, pembaruan layanan menjadi semakin sering, dan strategi untuk mengelola API juga bervariasi, yang mengarah pada persyaratan baru untuk hot reloading.

Hot reloading NGINX tidak lagi memenuhi persyaratan bisnis. Sudah saatnya beralih ke Apache APISIX, sebuah gateway API dengan strategi hot reloading yang lebih maju di era Cloud Native. Selain itu, setelah beralih ke APISIX, pengguna dapat memiliki manajemen API yang dinamis dan seragam, dan itu dapat secara signifikan meningkatkan efisiensi manajemen.