Artikel ini juga muncul di blog NGINX. Baca di NGINX>
Secara tradisional, pengembangan web dan hosting dilakukan terutama menggunakan tumpukan LAMP – LAMP adalah kependekan dari L inux (sistem operasi), A pache (server web), M ySQL (database), dan P HP (bahasa pemrograman), komponen inti yang kemudian digunakan untuk menjalankan situs perusahaan.
Karena tumpukan web dan penyeimbang beban menjadi lebih gesit, dan karena kebutuhan bisnis mendikte kinerja dan stabilitas yang lebih baik, menjadi semakin umum untuk mengganti Apache HTTP Server dengan alternatif yang ringan dan sangat skalabel, NGINX. Dengan NGINX, tumpukan tersebut dikenal sebagai LEMP – L inux, (e )NGINX, M ySQL, P HP.
Atlantic.Net menawarkan berbagai solusi yang mencakup penyimpanan, hosting, dan layanan terkelola. Platform VPS Hosting kami memiliki opsi LEMP sekali klik yang membuat tumpukan Anda siap dan berjalan dalam waktu kurang dari 30 detik. Bagi mereka yang lebih suka menjalankan NGINX dari Docker, kami memiliki Server Cloud Linux dan Windows dengan Docker. Kami juga menyediakan layanan terkelola bagi mereka yang menginginkan atau membutuhkan bantuan dalam menyiapkan NGINX.
Kami sering dan kuat menggunakan NGINX tidak hanya sebagai server web, tetapi juga sebagai proxy terbalik dan penyeimbang beban. Kami memutuskan untuk menggunakan NGINX setelah meneliti solusi penyeimbang beban untuk klaster logging terpusat kami. Dengan menggunakan NGINX dalam berbagai kapasitas, kami mencapai ketersediaan tinggi untuk server frontend dan backend kami, sambil mempertahankan footprint yang sangat kecil – semua berkat efisiensi NGINX dalam penggunaan RAM dan CPU.
Dalam hal fungsi spesifik NGINX mana yang paling berguna, beberapa yang menurut kami sangat kuat adalah proxy TCP/UDP dan penyeimbangan beban, kontrol akses, dan handshake SSL tiga arah. Dalam posting blog ini, saya akan menjelaskan bagaimana kami menggunakan setiap kemampuan ini.
Load Balancing Logging Terpusat Kami dengan Aliran NGINX
Karena kebutuhan untuk menyediakan logging untuk audit dan keamanan telah menjadi fokus yang lebih besar, kami di Atlantic.Net mencari proxy yang tepat dan solusi penyeimbang beban – tidak hanya untuk lalu lintas HTTP, tetapi juga untuk syslog. Syslog biasanya dikirim dalam format User Datagram Protocol (UDP), jadi kami membutuhkan sesuatu yang menangani UDP dan juga HTTP.
Di sinilah NGINX stream modul ikut bermain, karena memungkinkan penyeimbangan beban lalu lintas UDP. Load balancing menggunakan sejumlah server backend untuk distribusi lalu lintas jaringan yang efisien. Seperti istilahnya, tujuannya adalah untuk menyebarkan beban kerja secara merata.
Dalam cuplikan berikut, kami mengirim pesan syslog dari infrastruktur jaringan luar ke backend logging kami:
...
stream {
upstream networking_udp {
least_conn;
server 198.51.100.100:5910;
server 198.51.100.101:5910;
server 198.51.100.102:5910;
}
server {
listen 5910 udp;
proxy_timeout 0s;
proxy_bind $remote_addr transparent;
proxy_pass networking_udp;
}
}
... Streaming juga berfungsi dengan baik untuk SSL melalui TCP, seperti yang ditunjukkan pada contoh berikut yang mengirimkan log Filebeat dengan aman:
...
upstream filebeat_tcp {
least_conn;
server 198.51.100.100:5910;
server 198.51.100.101:5910;
server 198.51.100.102:5910;
}
server {
listen 5910 ssl;
ssl_certificate /etc/nginx/ssl/certs/cert.pem;
ssl_certificate_key /etc/nginx/ssl/private/priv-key.pem;
ssl_protocols TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 4h;
ssl_handshake_timeout 30s;
proxy_pass filebeat_tcp;
proxy_ssl on;
proxy_ssl_certificate /etc/nginx/ssl/certs/cert.pem;
proxy_ssl_certificate_key /etc/nginx/ssl/private/priv-key.pem;
proxy_ssl_protocols TLSv1.2;
proxy_ssl_session_reuse on;
proxy_ssl_ciphers HIGH:!aNULL:!MD5;
proxy_ssl_trusted_certificate /etc/nginx/ssl/certs/ca.pem;
}
... Seperti yang Anda lihat, NGINX mampu melakukan proxy dan load balancing lalu lintas UDP dan Transmission Control Protocol (TCP).
Penggunaan proxy terbalik dan penyeimbangan beban sangat membantu ketika Anda memiliki layanan, database, atau program yang berkomunikasi melalui UDP atau TCP. Pada tingkat dasar, metode ini relevan saat Anda memiliki layanan, database, atau instance program yang sama yang berjalan di beberapa server upstream, seperti yang dikelola oleh NGINX. Di Atlantic.Net, kami juga memanfaatkan proxy terbalik NGINX, karena menyediakan lapisan tambahan kebingungan untuk layanan backend penting kami, dengan sedikit overhead.
Kontrol Akses
Langkah penting lainnya untuk mengamankan logging terpusat kami adalah mencegah penghapusan data apa pun. Selain itu, daftar kontrol akses (ACL) sangat berguna untuk membatasi lalu lintas berdasarkan alamat IP. Untuk tujuan kami, kami ingin mengizinkan akses ke data log hanya dari jaringan manajemen internal kami.
NGINX memberi kita cara untuk menggambarkan dengan tepat jenis tindakan HTTP apa yang dapat dibuat dan dari mana, seperti yang dapat dilihat di sini:
...
server {
listen 9200;
client_max_body_size 20M;
location / {
limit_except GET POST PUT OPTIONS {
deny all;
}
allow 198.51.100.0/24;
deny all;
proxy_pass http://elasticsearch_backend;
}
location ~* ^(/_cluster|/_nodes|/_shutdown) {
allow 198.51.100.0/24;
deny all;
proxy_pass http://elasticsearch_backend;
}
}
... NGINX juga mendukung fitur IP transparan yang memungkinkan kami melihat alamat IP asal setelah permintaan melewati proxy. Kemampuan ini membantu melacak dari mana log berasal. NGINX membuat tugas ini sangat mudah:
...
server {
listen 5915 udp;
proxy_timeout 0s;
proxy_bind $remote_addr transparent;
proxy_pass vmware_udp;
}
... Jabat Tangan SSL Tiga Arah
NGINX dengan rapi menangani kedua sisi handoff SSL untuk logging terpusat kami. Implementasi ini sangat penting, karena berarti server internal dan pelanggan dapat berkomunikasi secara aman dengan NGINX. Setiap server yang dicatat memiliki sertifikatnya sendiri untuk komunikasi SSL dua arah, yang selanjutnya mengurangi kerentanan. NGINX kemudian mentransmisikan data dengan aman melalui jaringan internal kami, melalui SSL, ke server logging. Secara total, ada tiga sertifikat SSL yang terlibat untuk setiap komunikasi ujung ke ujung yang mendukung transmisi aman. (Lihat cuplikan konfigurasi kedua di Load Balancing Our Centralized Logging with NGINX Streams untuk penyiapan SSL tiga arah pilihan kami).
Perspektif dan Pengujian NGINX
Berbagai individu dan organisasi telah memuji NGINX selama bertahun-tahun, dan kami telah merasakan manfaat tambahan yang sama dari NGINX yang mereka sebutkan.
Insinyur perangkat lunak Chris Lea dari NodeSource membandingkan Apache dengan Microsoft Word, dengan mencatat bahwa kedua aplikasi memiliki sejumlah besar fitur yang tidak masuk akal, tetapi biasanya hanya sedikit yang diperlukan. Lea lebih memilih NGINX karena memiliki fitur yang Anda butuhkan, tanpa kinerja massal dan jauh lebih baik.
Menurut Thomas Gieselman dari perusahaan modal ventura BV Capital, beberapa organisasi yang mereka danai memperbaiki masalah terkait penskalaan dengan mengubah server mereka ke NGINX. Gieselman melihat NGINX membuat pertumbuhan cepat menjadi lebih sederhana dan dapat diakses oleh lebih banyak organisasi.
Linux Journal melakukan pengujian langsung, menggunakan software benchmark Apache, ab , untuk membandingkan Apache dengan NGINX (masing-masing versi 2.2.8 dan 0.5.22). Program top dan vmstat digunakan untuk memeriksa kinerja sistem saat kedua server berjalan secara bersamaan.
Pengujian menunjukkan bahwa NGINX lebih cepat dari Apache sebagai server konten statis. Kedua server masing-masing berjalan secara optimal, dengan konkurensi yang ditetapkan pada 100. Untuk melayani 6500 permintaan per detik, Apache menggunakan memori 17 MB, 30% CPU, dan 4 proses pekerja (dalam mode berulir). Untuk menayangkan klip yang jauh lebih cepat dari 11.500 permintaan per detik, NGINX hanya membutuhkan 1 MB memori, 15% CPU, dan 1 pekerja.
Bob Ippolito mendirikan platform game Mochi Media, yang pada puncaknya memiliki 140 juta pengguna unik per bulan – jadi dia memahami permintaan akan performa tinggi dengan baik. Ippolito mengatakan pada tahun 2006 bahwa ia menjalankan pengujian di mana ia menggunakan NGINX sebagai proxy terbalik untuk puluhan juta permintaan HTTP per hari (yaitu, beberapa ratus per detik) di satu server.
Saat server NGINX berada pada kapasitas puncaknya, server tersebut menghabiskan sekitar 10% CPU dan 15 MB memori pada penyiapannya, yaitu FreeBSD (OS open source berbasis UNIX). Dengan menggunakan parameter yang sama, Apache menghasilkan 1000 proses dan menghabiskan banyak sekali RAM. Pound membuat utas yang berlebihan dan menggunakan lebih dari 400 MB untuk berbagai tumpukan utas. Sedikit membutuhkan lebih banyak CPU dan bocor lebih dari 20 MB setiap jam.
Coba Atlantic.Net dengan NGINX
Di Atlantic.Net, kami telah menemukan peningkatan kinerja serupa dengan NGINX seperti yang dijelaskan oleh berbagai pihak ini. Kami juga mendapat manfaat dari fitur khusus yang dijelaskan di atas. Jika saat ini Anda menggunakan Apache atau server web lain, Anda mungkin ingin mencoba NGINX, untuk melihat apakah Anda mendapatkan peningkatan serupa yang dapat membantu Anda menangani skalabilitas dengan lebih baik dan kebutuhan akan kecepatan yang terus meningkat. Uji NGINX dengan Server Cloud hari ini.