Belajar Nginx - Sejarah, Arsitektur Utama & Mengapa Memilih NGINX

#Pendahuluan

Sebelum menulis directive pertama, kalian perlu tahu mengapa NGINX ada dan apa yang membuatnya berbeda. Episode 1 ini membedah sejarah, arsitektur utama, dan alasan mengapa NGINX dipilih hampir di semua perusahaan teknologi besar.

Pemahaman arsitektur bukan sekadar teori. Saat nanti kalian mengatur worker_processes, memilih cache strategy, atau memutuskan apakah NGINX cocok menggantikan Apache, semua keputusan itu berakar pada cara NGINX memproses koneksi. Mari kita mulai dari awal ceritanya.

#Lahirnya NGINX dan C10K Problem

#Asal Usul Tahun 2002

NGINX dibuat oleh Igor Sysoev, seorang engineer asal Rusia. Pekerjaannya saat itu mengelola web server untuk situs dengan trafik sangat tinggi, dan dia merasa web server yang ada tidak cukup efisien.

Masalah utamanya dikenal dengan nama C10K Problem: bagaimana sebuah server bisa menangani 10.000 koneksi simultan dengan sumber daya yang masuk akal? Apache dan server sejenis kewalahan karena satu koneksi berarti satu proses atau satu thread. NGINX dirancang khusus menjawab tantangan ini.

#Rilis Publik dan Adopsi

NGINX dirilis ke publik pada tahun 2004 dengan nama yang dieja "engine-x". Fokusnya satu: menangani ribuan koneksi bersamaan dengan penggunaan memori minimal. Dalam beberapa tahun, NGINX menjadi salah satu web server paling banyak dipakai di dunia, menjadi tulang punggung CDN dan layanan internet skala besar.

#Arsitektur Utama NGINX

#Event-Driven, Asynchronous, Non-Blocking

Kunci NGINX adalah model event-driven. Sebuah event loop memantau ribuan koneksi sekaligus tanpa menunggu satu koneksi selesai. I/O dilakukan secara asynchronous dan non-blocking: satu thread menangani banyak koneksi, berpindah antar koneksi saat ada event baru.

ps -ef | grep nginx

Outputnya menampilkan satu process nginx: master process dan beberapa nginx: worker process. Inilah fondasi desain NGINX.

#Master Process dan Worker Processes

NGINX terdiri dari dua tipe proses:

• Master process: membaca konfigurasi, mengatur worker processes, dan menangani sinyal seperti reload.
• Worker processes: menangani semua koneksi aktual. Setiap worker menjalankan event loop sendiri.

Jumlah worker biasanya diikuti dengan worker_processes auto;, yang membuat NGINX menyesuaikan diri dengan jumlah core CPU. Koneksi dibagi merata ke worker melalui sistem load balancing internal, dan memakai epoll di Linux atau kqueue di BSD/macOS untuk memantau event ribuan file descriptor sekaligus.

Untuk melihat modul dan fitur yang tersedia di build NGINX kalian:

nginx -V

nginx -V menampilkan versi beserta semua module yang terkompilasi, termasuk --with-stream untuk Layer 4 dan --with-http_v3_module jika kalian memakai build yang mendukung HTTP/3.

#NGINX vs Apache HTTPD

#Model Proses per Koneksi

Apache secara tradisional memakai pendekatan process-per-connection (MPM prefork) atau thread-per-connection (MPM worker). Setiap koneksi baru berarti proses atau thread baru. Saat koneksi mencapai ribuan, overhead memori dan switching context melonjak.

#Kenapa NGINX Menang di Koneksi Tinggi

Perbandingan singkatnya:

• Apache membuat resource baru per koneksi; NGINX memakai satu thread untuk ribuan koneksi.
• Memori NGINX per koneksi jauh lebih kecil, sehingga mampu bertahan di trafik tinggi dengan hardware terbatas.
• Apache unggul di fleksibilitas .htaccess per direktori; NGINX mengabaikan fitur ini demi performa dan meminta konfigurasi terpusat.

Bukan berarti Apache buruk. Untuk hosting bersama dengan fleksibilitas tinggi, Apache masih pilihan masuk akal. Tapi untuk web server, reverse proxy, dan load balancer berperforma tinggi, NGINX adalah pilihan yang hampir selalu lebih baik.

#Peran Utama NGINX di Industri

#Empat Peran yang Dominan

NGINX tidak sekadar web server. Di industri, ia dipakai untuk:

• High-Performance Web Server: menyajikan konten statis seperti HTML, CSS, JavaScript, dan gambar dengan sangat cepat.
• Reverse Proxy & API Gateway: menyembunyikan aplikasi backend seperti Node.js, Go, Python, atau Java di balik satu pintu masuk.
• Layer 4 & Layer 7 Load Balancer: membagi trafik ke banyak backend lewat modul stream (L4) dan upstream (L7).
• HTTP Cache & Media Streaming: caching respons dan streaming video dengan HTTP Range dan teknik chunked.

Bahkan ketika NGINX hanya menyajikan file statis, penghematan resource membuat backend aplikasi bebas menangani logika yang benar-benar penting.

#Bukti Adopsi

NGINX dan derivatifnya (seperti OpenResty dan NGINX Unit) melayani sebagian besar situs top dunia, termasuk dipakai sebagai entry point utama CDN dan edge server. curl -I https://example.com dan lihat header Server kalian — besar kemungkinan tertulis nginx.

#Satu Tool untuk Banyak Peran

Keunggulan lain yang membuat NGINX mendominasi: semuanya ada dalam satu binary. Kalian tidak perlu memasang tool terpisah untuk caching, reverse proxy, dan load balancing. Awal dari semuanya adalah config sekecil ini:

worker_processes auto;
 
events {
    worker_connections 1024;
}

Dua blok ini adalah benih dari hampir semua konfigurasi yang akan kita tulis sepanjang series. Arsitektur yang efisien sejak desain membuat NGINX cocok untuk peran apa pun yang kalian berikan.

#Penutup

Episode 1 menjelaskan mengapa NGINX ada: jawaban atas C10K problem yang lahir dari tangan Igor Sysoev pada tahun 2002. Arsitektur event-driven non-blocking dengan satu master dan banyak worker membuatnya mampu melayani ribuan koneksi dengan resource minimal.

Inti yang harus dibawa pulang:

• NGINX lahir tahun 2002 untuk memecahkan C10K problem (10.000 koneksi simultan).
• Arsitekturnya event-driven, asynchronous, dan non-blocking.
• Ada satu master process dan banyak worker processes yang memproses event.
• NGINX menang di koneksi tinggi dibanding Apache yang process-per-connection.
• Peran utamanya: web server, reverse proxy/API gateway, load balancer L4/L7, dan cache/streaming.
• Model worker paling baik diset mengikuti jumlah core CPU.

Di episode 2 selanjutnya kita akan membedah anatomi file konfigurasi nginx.conf dan directives — mulai dari hierarki context main, events, http, server, hingga location, aturan sintaks simple dan block directives, serta modularisasi konfigurasi dengan directive include.