ปริมาณการใช้งานที่ถูกต้องบนเครือข่าย DDoS-Guard เพิ่งเกินหนึ่งร้อยกิกะบิตต่อวินาที ปัจจุบัน 50% ของการเข้าชมทั้งหมดของเราสร้างขึ้นจากบริการเว็บไคลเอ็นต์ โดเมนเหล่านี้เป็นโดเมนหลายหมื่นโดเมน ซึ่งแตกต่างกันมากและในกรณีส่วนใหญ่ต้องใช้แนวทางเฉพาะบุคคล
ด้านล่างคือวิธีที่เราจัดการโหนดด้านหน้าและออกใบรับรอง SSL สำหรับไซต์นับแสนแห่ง
การตั้งค่าด้านหน้าสำหรับไซต์งานเดียว แม้แต่ไซต์ที่ใหญ่มากก็เป็นเรื่องง่าย เราใช้ nginx หรือ haproxy หรือ lighttpd กำหนดค่าตามคำแนะนำแล้วลืมมันไป หากเราจำเป็นต้องเปลี่ยนแปลงบางสิ่ง เราจะทำการโหลดซ้ำแล้วลืมอีกครั้ง
ทุกอย่างจะเปลี่ยนไปเมื่อคุณประมวลผลการรับส่งข้อมูลปริมาณมากได้ทันที ประเมินความถูกต้องของคำขอ บีบอัดและแคชเนื้อหาของผู้ใช้ และในขณะเดียวกันก็เปลี่ยนพารามิเตอร์หลายครั้งต่อวินาที ผู้ใช้ต้องการดูผลลัพธ์บนโหนดภายนอกทั้งหมดทันทีหลังจากที่เขาเปลี่ยนการตั้งค่าในบัญชีส่วนตัวของเขา ผู้ใช้ยังสามารถดาวน์โหลดโดเมนได้หลายพัน (และบางครั้งก็เป็นหมื่น) พร้อมพารามิเตอร์การประมวลผลการรับส่งข้อมูลแต่ละรายการผ่าน API ทั้งหมดนี้ควรใช้งานได้ทันทีในอเมริกาและในยุโรปและในเอเชีย - งานไม่ใช่เรื่องเล็กน้อยที่สุดเมื่อพิจารณาว่าในมอสโกเพียงแห่งเดียวมีโหนดการกรองที่แยกออกจากกันทางกายภาพหลายแห่ง
เหตุใดจึงมีโหนดที่เชื่อถือได้ขนาดใหญ่มากมายทั่วโลก
-
คุณภาพของการบริการสำหรับการรับส่งข้อมูลไคลเอนต์ - คำขอจากสหรัฐอเมริกาจะต้องดำเนินการในสหรัฐอเมริกา (รวมถึงการโจมตี การแยกวิเคราะห์ และความผิดปกติอื่น ๆ ) และไม่ถูกดึงไปที่มอสโกหรือยุโรป ส่งผลให้การประมวลผลล่าช้าอย่างไม่อาจคาดเดาได้
-
ปริมาณการโจมตีจะต้องถูกแปลเป็นภาษาท้องถิ่น - ผู้ดำเนินการขนส่งอาจลดลงในระหว่างการโจมตี ซึ่งมักจะเกิน 1Tbps การส่งข้อมูลการโจมตีผ่านลิงก์ข้ามมหาสมุทรแอตแลนติกหรือข้ามเอเชียไม่ใช่ความคิดที่ดี เรามีกรณีจริงเมื่อผู้ปฏิบัติงานระดับ 1 พูดว่า: “ปริมาณการโจมตีที่คุณได้รับนั้นเป็นอันตรายต่อเรา” นั่นเป็นเหตุผลที่เรายอมรับสตรีมที่เข้ามาใกล้กับแหล่งที่มามากที่สุด
-
ข้อกำหนดที่เข้มงวดเพื่อความต่อเนื่องของการบริการ - ศูนย์ทำความสะอาดไม่ควรขึ้นอยู่กับแต่ละแห่งหรือกิจกรรมในท้องถิ่นในโลกที่เปลี่ยนแปลงอย่างรวดเร็วของเรา คุณได้ตัดไฟทั้ง 11 ชั้นของ MMTS-9 เป็นเวลาหนึ่งสัปดาห์แล้วหรือยัง? - ไม่มีปัญหา. ไม่ใช่ลูกค้ารายเดียวที่ไม่มีการเชื่อมต่อทางกายภาพในสถานที่เฉพาะนี้จะประสบปัญหา และบริการทางเว็บจะไม่ได้รับผลกระทบไม่ว่าในกรณีใด ๆ
จะจัดการทั้งหมดนี้ได้อย่างไร?
การกำหนดค่าบริการควรกระจายไปยังโหนดด้านหน้าทั้งหมดโดยเร็วที่สุด (ควรดำเนินการทันที) คุณไม่สามารถรับและสร้างการกำหนดค่าข้อความใหม่และรีบูต daemons ทุกครั้งที่มีการเปลี่ยนแปลง - nginx เดียวกันจะทำให้กระบวนการปิดตัวลง (ผู้ปฏิบัติงานปิดตัวลง) อีกสองสามนาที (หรืออาจเป็นชั่วโมงหากมีเซสชัน websocket ที่ยาว)
เมื่อโหลดการกำหนดค่า nginx ใหม่ รูปภาพต่อไปนี้ค่อนข้างปกติ:
เกี่ยวกับการใช้หน่วยความจำ:
คนทำงานเก่ากินหน่วยความจำจนหมด รวมถึงหน่วยความจำที่ไม่ขึ้นกับจำนวนการเชื่อมต่อเป็นเส้นตรง ซึ่งถือเป็นเรื่องปกติ เมื่อการเชื่อมต่อไคลเอนต์ถูกปิด หน่วยความจำนี้จะถูกปลดปล่อย
เหตุใดจึงไม่เป็นปัญหาเมื่อ nginx เพิ่งเริ่มต้นใช้งาน ไม่มี HTTP/2, ไม่มี WebSocket, ไม่มีการเชื่อมต่อแบบ Keep-alive ขนาดใหญ่ 70% ของการเข้าชมเว็บของเราคือ HTTP/2 ซึ่งหมายถึงการเชื่อมต่อที่ยาวมาก
วิธีแก้ปัญหานั้นง่ายมาก - ห้ามใช้ nginx ห้ามจัดการส่วนหน้าตามไฟล์ข้อความ และห้ามส่งการกำหนดค่าข้อความซิปผ่านช่องทางข้ามมหาสมุทรแปซิฟิกอย่างแน่นอน แน่นอนว่าช่องต่างๆ นั้นรับประกันและสงวนไว้ แต่นั่นไม่ได้ทำให้ช่องเหล่านั้นมีข้ามทวีปน้อยลง
เรามี front server-balancer ของตัวเอง ซึ่งฉันจะพูดถึงภายในในบทความต่อไปนี้ สิ่งสำคัญที่สามารถทำได้คือใช้การเปลี่ยนแปลงการกำหนดค่าหลายพันรายการต่อวินาทีได้ทันที โดยไม่ต้องรีสตาร์ท โหลดใหม่ การใช้หน่วยความจำเพิ่มขึ้นอย่างกะทันหัน และทั้งหมดนั้น สิ่งนี้คล้ายกับ Hot Code Reload มาก เช่น ใน Erlang ข้อมูลจะถูกจัดเก็บไว้ในฐานข้อมูลคีย์-ค่าที่กระจายตามภูมิศาสตร์ และจะถูกอ่านทันทีโดยตัวกระตุ้นด้านหน้า เหล่านั้น. คุณอัปโหลดใบรับรอง SSL ผ่านเว็บอินเทอร์เฟซหรือ API ในมอสโก และภายในไม่กี่วินาที ใบรับรองก็พร้อมที่จะไปที่ศูนย์ทำความสะอาดของเราในลอสแอนเจลิส หากจู่ๆ สงครามโลกครั้งเกิดขึ้นและอินเทอร์เน็ตหายไปทั่วโลก โหนดของเราจะยังคงทำงานโดยอัตโนมัติและซ่อมแซมสมองที่แตกแยกทันทีที่หนึ่งในช่องทางเฉพาะลอสแองเจลิส-อัมสเตอร์ดัม-มอสโก มอสโก-อัมสเตอร์ดัม-ฮ่องกง- Los-Los พร้อมให้บริการแล้ว Angeles หรืออย่างน้อยหนึ่งข้อมูลสำรอง GRE
กลไกเดียวกันนี้ช่วยให้เราออกและต่ออายุใบรับรอง Let's Encrypt ได้ทันที ง่ายมากมันใช้งานได้ดังนี้:
-
ทันทีที่เราเห็นคำขอ HTTPS อย่างน้อยหนึ่งคำขอสำหรับโดเมนของลูกค้าของเราโดยไม่มีใบรับรอง (หรือมีใบรับรองที่หมดอายุ) โหนดภายนอกที่ยอมรับคำขอจะรายงานสิ่งนี้ไปยังหน่วยงานออกใบรับรองภายใน
-
หากผู้ใช้ไม่ได้ห้ามการออก Let's Encrypt ผู้ออกใบรับรองจะสร้าง CSR รับโทเค็นการยืนยันจาก LE และส่งไปยังทุกฝ่ายผ่านช่องทางที่เข้ารหัส ตอนนี้โหนดใด ๆ ก็สามารถยืนยันคำขอตรวจสอบความถูกต้องจาก LE ได้
-
อีกสักครู่เราจะได้รับใบรับรองและคีย์ส่วนตัวที่ถูกต้องและส่งไปที่แนวหน้าในลักษณะเดียวกัน อีกครั้งโดยไม่ต้องรีสตาร์ท daemons
-
7 วันก่อนวันหมดอายุ ขั้นตอนในการรับใบรับรองใหม่จะเริ่มขึ้น
ขณะนี้เรากำลังหมุนเวียนใบรับรอง 350 ใบแบบเรียลไทม์ ซึ่งโปร่งใสต่อผู้ใช้โดยสิ้นเชิง
ในบทความชุดต่อไปนี้ ฉันจะพูดถึงคุณสมบัติอื่น ๆ ของการประมวลผลปริมาณการใช้ข้อมูลเว็บจำนวนมากแบบเรียลไทม์ - ตัวอย่างเช่นเกี่ยวกับการวิเคราะห์ RTT โดยใช้ข้อมูลที่ไม่สมบูรณ์เพื่อปรับปรุงคุณภาพการบริการสำหรับลูกค้าระบบขนส่งมวลชนและโดยทั่วไปเกี่ยวกับการปกป้องปริมาณข้อมูลการขนส่งสาธารณะจาก การโจมตีเทราบิต เกี่ยวกับการจัดส่งและการรวบรวมข้อมูลการรับส่งข้อมูล เกี่ยวกับ WAF CDN เกือบไม่จำกัด และกลไกมากมายในการเพิ่มประสิทธิภาพการจัดส่งเนื้อหา
เฉพาะผู้ใช้ที่ลงทะเบียนเท่านั้นที่สามารถเข้าร่วมในการสำรวจได้ , โปรด.
คุณอยากจะรู้อะไรก่อน?
-
ลด 14,3%อัลกอริทึมสำหรับการจัดกลุ่มและวิเคราะห์คุณภาพของการเข้าชมเว็บ<3
-
ลด 33,3%ภายในของบาลานเซอร์ DDoS-Guard7
-
ลด 9,5%การป้องกันการจราจรของการขนส่ง L3/L4
-
ลด 0,0%การปกป้องเว็บไซต์เกี่ยวกับการจราจร0
-
ลด 14,3%ไฟร์วอลล์แอปพลิเคชันเว็บ3
-
ลด 28,6%ป้องกันการแยกวิเคราะห์และการคลิก6
ผู้ใช้ 21 คนโหวต ผู้ใช้ 6 รายงดออกเสียง
ที่มา: will.com