เว็บเซิร์ฟเวอร์
nginx: เว็บเซิร์ฟเวอร์ที่ขยายตัวได้ด้วยลูปเหตุการณ์
nginx รับมือทราฟฟิกบนเว็บมากกว่าเซิร์ฟเวอร์ตัวอื่น ด้วยเหตุผลเชิงโครงสร้าง: มันแก้ปัญหา C10K ด้วยโมเดลแบบ event-driven และ asynchronous แทนที่จะเป็น thread ต่อการเชื่อมต่อหนึ่งรายการ ในทางปฏิบัติมันทำสองหน้าที่พร้อมกัน คือเป็นเซิร์ฟเวอร์ไฟล์สแตติกที่เบา และเป็น reverse proxy ที่วงการเลือกใช้เป็นค่าเริ่มต้น และงานติดตั้งจริงส่วนใหญ่คือหน้าที่ที่สอง วินัยในการดูแลรักษา ทั้งการทดสอบคอนฟิก การเฝ้าดู log และการทำ TLS อัตโนมัติ เป็นตัวตัดสินว่าพลังนั้นจะเงียบสงบหรือเปราะบาง
ประเด็นสำคัญ
- สถาปัตยกรรมแบบ event loop คือเหตุผลทั้งหมด: กระบวนการ worker จำนวนน้อยรับมือการเชื่อมต่อหลายพันรายการด้วยการสลับ context ที่ราคาถูก นี่คือเหตุผลที่ nginx เก่งเรื่อง proxy ลูกค้าที่ช้าเป็นจำนวนมาก (ไฟล์สแตติก ผู้ใช้มือถือปลายทาง) โดยไม่กินหน่วยความจำต่อการเชื่อมต่อแบบที่การออกแบบ thread ต่อคำขอทำ
- สองบทบาทในไบนารีเดียว: บล็อก server ให้บริการเนื้อหาสแตติกและใช้ rewrite ส่วนบล็อก proxy_pass ทำ TLS termination และส่งต่อไปยังบริการ upstream พร้อมพฤติกรรมเกี่ยวกับสุขภาพของ upstream (max_fails, timeouts, buffering) ที่เป็นการตั้งค่าไม่ใช่โมดูล ซึ่งคือการเปลี่ยนนิสัยครั้งใหญ่ที่สุดเมื่อเทียบกับวิธีคิดแบบ Apache
- วินัยเรื่องคอนฟิกน่าเบื่อแต่บังคับ: รัน nginx -t ทุกครั้งหลังแก้ไฟล์ หนึ่งไฟล์ include ต่อหนึ่งเว็บเพื่อให้ย้อนกลับได้ตรงจุด และใช้ reload (ไม่ใช่ restart) เป็นการเปลี่ยนแปลงขณะให้บริการ การปล่อยคอนฟิกที่ทดสอบ syntax ไม่ผ่านออกไปคือ outage ที่กินเวลาครึ่งวันแต่ป้องกันได้ทั้งหมด
- TLS เป็นชั้นที่ต้องทำให้จริงจัง: เลือกโปรโตคอลที่ทันสมัย ตั้ง session resumption และ OCSP stapling พร้อมให้ acme.sh หรือ certbot ออกใบรับรองอัตโนมัติ hook ต่ออายุที่พังเงียบ ๆ หกสิบวันคือ outage แบบคลาสสิกของ nginx ดังนั้นควรตั้งแจ้งเตือนตามอายุใบรับรอง ไม่ใช่รอจนใกล้หมดอายุ
- ขีดจำกัดที่ต้องยอมรับ: ไม่มีระบบโมดูลแบบไดนามิกเหมือน Apache (โมดูลถูกคอมไพล์ตอน build ดังนั้นฟีเจอร์จากบุคคลที่สามต้อง rebuild หรือใช้แพ็กเกจของดิสโทร) และขอบเขต reverse proxy ถูกออกแบบให้เรียบง่าย เพราะคำตอบของ nginx ต่อความซับซ้อนมักคือ 'เอาเครื่องมืออื่นมาวางข้างหน้า' (rate limiting ใน nginx บวก WAF ในชั้นแบบ modsecurity)
- งานด้านประสิทธิภาพเริ่มจากความจริง ไม่ใช่ความเชื่อ: worker_processes = auto, worker_connections ให้พอดีกับหน่วยความจำและภาระ, เข้าใจ proxy_buffering (เปิด buffering เป็นค่าเริ่มต้นและถูกต้องสำหรับ API ส่วนใหญ่ด้วย), เปิด gzip/brotli สำหรับชนิดข้อความ และอ่าน log เพื่อดู spike ของ 499/504 ก่อนที่แดชบอร์ดจะส่งสัญญาณเตือน
บันทึกจากหน้างาน
คอนฟิก nginx ที่สอนลูกค้าได้มากที่สุดคือไฟล์เดียว: reverse proxy ที่มี HSTS, header cache ที่ตรงไปตรงมา และบล็อก server แยกตามบริการ ทั้งหมดไม่ถึง 200 บรรทัด สแตกเดิมของพวกเขามี include ซ้ำ ๆ 4,000 บรรทัดและการ reload ที่ทำอะไรพังทุกไตรมาส การดูแลคอนฟิกให้เป็นระเบียบก็นับเป็นงานวิศวกรรม
คำถามที่พบบ่อย
nginx กับ Apache ควรเลือก nginx เมื่อไร
การ reverse proxy ที่มี concurrency สูง ทราฟฟิกที่เน้นไฟล์สแตติก และ TLS termination ในระดับใหญ่ event loop ได้ผลตรงจุดนั้นพอดี สำหรับ shared hosting ที่พึ่ง .htaccess และคอนฟิกรายไดเรกทอรี Apache ยังสบายใจกว่า (บทความ nginx-vs-apache ของเราพูดถึงข้อแลกเปลี่ยนนี้อย่างตรงไปตรงมา)
กฎ reload กับ restart ต่างกันอย่างไร
reload (แบบ graceful คือ worker เก่าเสิร์ฟการเชื่อมต่อเดิมให้จบขณะที่คอนฟิกใหม่เข้ามาทำงาน) คือการกระทำประจำวัน ส่วน restart ใช้เมื่อเปลี่ยนเวอร์ชันเอนจินและสิ่งใดก็ตามที่ reload จับไม่ได้ และทั้งสองอย่างไม่ใช่ข้ออ้างให้ข้ามการรัน nginx -t ก่อน
ทำไมบางเว็บวาง Apache ไว้หลัง nginx
คือสแตกไฮบริดคลาสสิก: nginx ปิด TLS เสิร์ฟสแตติกได้เร็ว และ proxy คำขอไดนามิกไปให้ Apache ที่ซึ่ง .htaccess และเครื่องมือแบบ mod_php คาดหวังพฤติกรรมเดิม ต้นทุนคือชิ้นส่วนที่ต้องเฝ้าดูและตั้งค่าให้สอดคล้องกันเพิ่มอีกหนึ่งชิ้น
สามความผิดพลาดแรกเรื่องการจูนที่ควรเลี่ยง
การก๊อปค่าปรับ worker/buffer จากบล็อกโพสต์โดยไม่ทดสอบภาระจริง การปิด proxy_buffering เพราะได้ยินว่ามันช้า (ปกติ buffering คือค่าที่เร็วกว่า) และการข้ามการทดสอบคอนฟิกก่อน reload ทั้งสามอย่างป้องกันได้ด้วยวินัยข้างต้น
Kinetikatech ช่วยเรื่อง เว็บเซิร์ฟเวอร์ ได้อย่างไร
เราเคยรับเรื่องแบบนี้มาเป็นร้อยครั้ง: การตั้งค่า การปรับแต่ง และความปลอดภัยของเว็บเซิร์ฟเวอร์ในสภาพแวดล้อมโปรดักชันและงานพัฒนา กับ การเพิ่มความเร็วเว็บไซต์และการจัดการเซิร์ฟเวอร์ คุณได้วงจรครบ ตั้งแต่เราประเมิน ลงมือทำ เฝ้าดูตลอดเวลา และรับเรื่องภายใน 30 นาทีเมื่อจำเป็น