การแยกส่วนปริมาณงานโดยแบ่งกลุ่มย่อยที่ผสมคละกัน

ในปัจจุบัน Amazon Route 53 โฮสต์เว็บไซต์ของธุรกิจที่ใหญ่ที่สุดและได้รับความนิยมมากที่สุดของโลกเป็นจำนวนมาก แต่จุดเริ่มต้นห่างไกลจากนั้นมาก

ผู้ให้บริการ DNS ไม่ว่ารายใดต่างก็รู้ดีว่าความท้าทายที่ยิ่งใหญ่ที่สุดของพวกเขาคืออะไร พวกเขาบอกได้เป็นเสียงเดียวกันเลยว่า มันคือการโจมตีโดยปฏิเสธการให้บริการ (DDOS) DNS สร้างอยู่บนโปรโตคอล UDP ซึ่งหมายความว่าการปลอมคำขอ DNS นั้นสามารถทำได้บนอินเทอร์เน็ต เนื่องจาก DNS เป็นโครงสร้างพื้นฐานที่มีความสำคัญสูงเช่นกัน ทั้งหมดนี้จึงกลายเป็นเป้าหมายที่น่าสนใจของผู้ไม่ประสงค์ดีที่พยายามขู่กรรโชกธุรกิจต่างๆ รวมถึงเหล่า “บูทเตอร์” ที่ตั้งเป้าเพื่อกระตุ้นให้เกิดการล้มเหลวด้วยเหตุผลต่างๆ นานา และผู้ก่อกวนที่สร้างความเข้าใจผิด ซึ่งดูเหมือนว่าจะไม่ตระหนักว่าพวกเขากำลังกระทำอาชญากรรมร้ายแรงที่มีผลกระทบต่อบุคคลจริงๆ ไม่ว่าจะด้วยเหตุผลใดก็ตาม ในปัจจุบัน มีผู้โจมตี DDOS หลายพันรายที่มุ่งโจมตีโดเมนอยู่

วิธีการหนึ่งในการบรรเทาการโจมตีเหล่านี้คือการใช้สมรรถภาพของเซิร์ฟเวอร์ในปริมาณมหาศาล ถึงแม้ว่าการมีจุดเริ่มต้นที่ดีสำหรับสมรรถภาพจะมีความสำคัญ แต่วิธีการนี้ก็ปรับขยายหรือลดขนาดไม่ค่อยจะได้ เซิร์ฟเวอร์แต่ละเครื่องที่ผู้ให้บริการเพิ่มเข้ามามีต้นทุนมหาศาล แต่ผู้โจมตีสามารถเพิ่มไคลเอ็นต์ปลอมด้วยเงินเพียงน้อยนิด หากพวกเขาใช้บอทเน็ตที่เป็นภัย สำหรับผู้ให้บริการ การเพิ่มสมรรถภาพของเซิร์ฟเวอร์ในปริมาณมหาศาลเป็นกลยุทธ์ที่พ่ายแพ้

ในเวลาที่เราสร้าง Amazon Route 53 เทคนิคที่ล้ำสมัยสำหรับการป้องกัน DNS คืออุปกรณ์เครือข่ายเฉพาะทางที่สามารถใช้กลวิธีต่างๆ นานาในการ “ล้าง” ปริมาณข้อมูลในอัตราที่สูงมาก เรามีอุปกรณ์เหล่านี้เป็นจำนวนมากที่ Amazon สำหรับบริการ DNS ภายในที่มีอยู่ของเรา และเราได้พูดคุยกับผู้ขายฮาร์ดแวร์ว่ามีอะไรอย่างอื่นที่ใช้งานได้บ้าง เราพบว่าการซื้ออุปกรณ์ในจำนวนมากพอที่จะครอบคลุมทุกๆ โดเมนบน Route 53 ได้อย่างสมบูรณ์จะต้องใช้เงินหลายสิบล้านดอลลาร์ และเวลาอีกนานหลายเดือนเพื่อส่งมอบ ติดตั้ง และทำให้เซิร์ฟเวอร์เหล่านั้นทำงานได้ ซึ่งไม่ได้สอดคล้องกับความเร่งด่วนของแผนของเราหรือความพยายามของเราที่จะประหยัดเลย เราจึงไม่เคยพิจารณาอุปกรณ์เหล่านั้นอย่างจริงจัง เราจำเป็นต้องค้นหาวิธีในการใช้ทรัพยากรเพื่อป้องกันโดเมนที่กำลังถูกโจมตีจริงๆ เท่านั้น เราจึงกลับไปสู่หลักการเก่าแก่ที่บอกว่าความจำเป็นเป็นบ่อเกิดของการประดิษฐ์ ความจำเป็นของเราคือการสร้างบริการ DNS ที่ใช้งานได้ 100 เปอร์เซ็นต์ระดับโลกอย่างรวดเร็วโดยใช้ทรัพยากรเพียงเล็กน้อย ประดิษฐกรรมของเราคือการแบ่งกลุ่มย่อยที่ผสมคละกัน

การแบ่งกลุ่มย่อยที่ผสมคละกันเป็นวิธีการที่ง่ายแต่มีประสิทธิภาพ โดยมีประสิทธิภาพมากกว่าที่เรารับรู้ในครั้งแรกเสียอีก เราได้นำมาใช้ครั้งแล้วครั้งเล่า และได้กลายมาเป็นรูปแบบหลักที่ทำให้ AWS สามารถส่งมอบบริการแบบผู้เช่าหลายรายที่คุ้มค่า ซึ่งให้ลูกค้าแต่ละรายได้รับประสบการณ์แบบผู้เช่ารายเดียว

เพื่อดูว่าการแบ่งกลุ่มย่อยที่ผสมคละกันทำงานอย่างไร เราจะมาพิจารณาก่อนว่าการแบ่งกลุ่มย่อยแบบธรรมดาสามารถทำให้ระบบปรับขนาดและฟื้นตัวได้มากขึ้นได้อย่างไร สมมติว่ามีระบบหรือบริการที่ปรับขนาดได้ในแนวนอน ซึ่งประกอบด้วยผู้ปฏิบัติงานแปดคน รูปต่อไปนี้แสดงให้เห็นผู้ปฏิบัติงานและคำขอของพวกเขา ผู้ปฏิบัติงานอาจเป็นเซิร์ฟเวอร์ หรือคิว หรือฐานข้อมูลก็ได้ “สิ่งใด” ก็ตามที่ประกอบเป็นระบบของคุณ

หากไม่มีการแบ่งกลุ่มย่อยใดๆ กลุ่มผู้ปฏิบัติงานจะจัดการงานทั้งหมด ผู้ปฏิบัติงานแต่ละคนจะต้องสามารถจัดการคำขอใดๆ ก็ได้ ซึ่งเป็นสิ่งที่ดีสำหรับประสิทธิภาพและระบบสำรอง หากผู้ปฏิบัติงานคนหนึ่งทำงานไม่ได้ อีกเจ็ดคนก็สามารถรองรับงานได้ ดังนั้นระบบจึงจำเป็นต้องมีสมรรถภาพในการรับภาระงานค้างอยู่บ้าง อย่างไรก็ตาม ปัญหาใหญ่จะเกิดขึ้นโดยไม่คาดหมาย หากความล้มเหลวถูกกระตุ้นโดยคำขอแบบใดแบบหนึ่ง หรือคำขอในปริมาณมหาศาล เช่น การโจมตี DDoS สองรูปต่อไปนี้แสดงการขยายตัวของการโจมตีดังกล่าว

ปัญหาจะทำให้ผู้ปฏิบัติงานคนแรกที่ได้รับผลกระทบทำงานไม่ได้ แล้วลุกลามต่อไปยังผู้ปฏิบัติงานคนอื่นๆ เมื่อผู้ปฏิบัติงานที่เหลือเข้ามาทำงานแทน ปัญหาสามารถทำให้ผู้ปฏิบัติงานทุกคนและบริการทั้งหมดหยุดทำงานลงได้อย่างรวดเร็ว

ขอบเขตผลกระทบสำหรับความล้มเหลวชนิดนี้ครอบคลุม “ทุกสิ่งทุกอย่างและทุกคน” บริการทั้งหมดหยุดทำงาน ลูกค้าทุกรายได้รับผลกระทบ อย่างที่พวกเราพูดกันในวิศวกรรมความพร้อมใช้งาน: มันไม่ได้ถูกปรับให้เหมาะสม

ด้วยการแบ่งกลุ่มย่อยปกติ เราสามารถทำได้ดีกว่านี้ หากเราแบ่งกลุ่มผู้ปฏิบัติงานเป็น 4 กลุ่มย่อย เราสามารถแลกเปลี่ยนประสิทธิภาพกับขอบเขตผลกระทบได้ สองรูปต่อไปนี้แสดงให้เห็นว่าการแบ่งกลุ่มย่อยสามารถจำกัดผลกระทบของการโจมตี DDoS ได้อย่างไร

ในตัวอย่างนี้ แต่ละกลุ่มย่อยมีผู้ปฏิบัติงาน 2 คน เราแบ่งทรัพยากรต่างๆ เช่น โดเมนลูกค้า ลงในกลุ่มย่อยต่างๆ เรายังคงมีระบบสำรอง แต่เนื่องจากมีผู้ปฏิบัติงานเพียง 2 คนต่อกลุ่มย่อย เราจึงจำเป็นต้องรักษาสมรรถภาพในการรับภาระงานค้างมากขึ้นในระบบ เพื่อจัดการกับความล้มเหลวใดๆ ซึ่งส่งผลให้ขอบเขตผลกระทบลดลงมากพอสมควร

ในโลกของการแบ่งกลุ่มย่อยนี้ ขอบเขตผลกระทบลดลงตามจำนวนของกลุ่มย่อย สำหรับ 4 กลุ่มย่อยที่มีอยู่นี้ หากลูกค้าประสบปัญหา กลุ่มย่อยที่โฮสต์ลูกค้าเหล่านั้นก็อาจได้รับผลกระทบได้ รวมทั้งลูกค้าอื่นๆ ทั้งหมดบนกลุ่มย่อยนั้น อย่างไรก็ตาม กลุ่มย่อยเป็นตัวแทนเพียงหนึ่งในสี่ของบริการโดยรวม ผลกระทบ 25 เปอร์เซ็นต์ย่อมดีกว่าผลกระทบ 100 เปอร์เซ็นต์มาก ด้วยการแบ่งกลุ่มย่อยที่ผสมคละกัน เราสามารถทำได้ดีกว่าเป็นทวีคูณ

ด้วยการแบ่งกลุ่มย่อยที่ผสมคละกัน เราสามารถสร้างกลุ่มย่อยเสมือนที่มีผู้ปฏิบัติงาน 2 คนในแต่ละกลุ่ม แล้วเราจะมอบหมายลูกค้าหรือทรัพยากร หรืออะไรก็ได้ที่เราต้องการแยกส่วน ให้กับกลุ่มย่อยเสมือนเหล่านั้น

รูปต่อไปนี้แสดงแผนผังตัวอย่างการแบ่งกลุ่มย่อยที่ผสมคละกันที่มีผู้ปฏิบัติงาน 8 คนและลูกค้า 8 ราย ซึ่งแต่ละรายมอบหมายให้กับผู้ปฏิบัติงาน 2 คน ปกติ เราจะมีลูกค้ามากกว่าผู้ปฏิบัติงานมาก แต่ถ้าเรารักษาจำนวนให้น้อย ก็จะติดตามได้ง่ายขึ้น เราจะเน้นที่ลูกค้าสองราย ลูกค้าเรนโบว์และลูกค้าโรส

ในตัวอย่างของเรา เรามอบหมายลูกค้าเรนโบว์ให้กับผู้ปฏิบัติงานคนที่ 1 และผู้ปฏิบัติงานคนที่ 4 การนำผู้ปฏิบัติงาน 2 คนมาคละกันจะประกอบเป็นกลุ่มย่อยที่ผสมคละกันของลูกค้า ลูกค้าอื่นๆ จะไปที่กลุ่มย่อยเสมือนอื่นๆ โดยมีผู้ปฏิบัติงาน 2 คนที่คละกัน ตัวอย่างเช่น ลูกค้าโรสถูกมอบหมายให้กับผู้ปฏิบัติงานคนที่ 1 แต่ผู้ปฏิบัติงานอีกคนคือผู้ปฏิบัติงานคนที่ 8

ถ้าลูกค้าเรนโบว์ที่มอบหมายให้กับผู้ปฏิบัติงาน 1 และ 4 มีปัญหา (เช่น คำขอที่เป็นอันตราย หรือคำขอในปริมาณมหาศาล) ปัญหานั้นจะกระทบกลุ่มย่อยเสมือน แต่จะไม่กระทบกลุ่มย่อยที่ผสมคละกันอื่นใดอย่างเต็มที่ ความจริงแล้ว ผู้ปฏิบัติงานอย่างมาก 1 คนของกลุ่มย่อยที่ผสมคละกันอีกกลุ่มจะได้รับผลกระทบ หากผู้ขอยอมรับข้อผิดพลาดได้และสามารถทำงานต่อไปได้ (โดยมีการลองใหม่ เป็นต้น) บริการก็สามารถดำเนินการต่อไปโดยไม่หยุดชะงักสำหรับลูกค้าหรือทรัพยากรบนกลุ่มย่อยที่เหลือ ตามที่รูปต่อไปนี้แสดงให้เห็น

หรืออีกนัยหนึ่ง ในขณะที่ผู้ปฏิบัติงานทั้งหมดที่ให้บริการเรนโบว์อาจกำลังประสบปัญหาหรือพบการโจมตี ผู้ปฏิบัติงานคนอื่นๆ จะไม่ได้รับผลกระทบใดๆ เลย สำหรับลูกค้า นั่นหมายความว่าถึงแม้ลูกค้าโรสและลูกค้าซันฟลาวเวอร์จะใช้ผู้ปฏิบัติงานเดียวกับเรนโบว์ก็ตาม พวกเขาไม่ได่รับผลกระทบเลย ลูกค้าโรสสามารถได้รับบริการจากผู้ปฏิบัติงาน 8 และซันฟลาวเวอร์สามารถได้รับบริการจากผู้ปฏิบัติงาน 6 ตามที่แสดงในรูปต่อไปนี้

เมื่อปัญหาเกิดขึ้น เรายังสามารถเสียบริการไปหนึ่งในสี่ของทั้งหมด แต่วิธีการที่มอบหมายลูกค้าหรือทรัพยากรทำให้ขอบเขตผลกระทบกับการแบ่งกลุ่มย่อยที่ผสมคละกันดีกว่ามากพอสมควร ด้วยผู้ปฏิบัติงาน 8 คน สามารถผสมกลุ่มย่อยที่มีผู้ปฏิบัติงาน 2 คนคละกันได้ 28 รูปแบบโดยไม่ซ้ำกัน ซึ่งหมายความว่าจะมีกลุ่มย่อยที่ผสมคละกันได้ 28 กลุ่ม หากเรามีลูกค้าหลายร้อยรายหรือมากกว่านั้น และเรามอบหมายลูกค้าแต่ละรายให้กับกลุ่มย่อยที่ผสมคละกัน ขอบเขตผลกระทบอันเกิดจากปัญหาก็จะมีเพียง 1/28 ซึ่งดีกว่าการแบ่งกลุ่มย่อยปกติถึง 7 เท่า

มันเป็นความรู้สึกที่น่าตื่นเต้นที่ได้เห็นตัวเลขดีขึ้นเป็นทวีคูณ เมื่อคุณมีผู้ปฏิบัติงานและลูกค้ามากขึ้น ปัญหาในการปรับขนาดส่วนใหญ่ยากขึ้นในขนาดเหล่านั้น แต่การแบ่งกลุ่มย่อยที่ผสมคละกันทำให้มีประสิทธิผลยิ่งขึ้นได้ ความจริงแล้ว ถ้ามีผู้ปฏิบัติงานเพียงพอ ก็จะมีกลุ่มย่อยที่ผสมคละกันได้มากกว่าจำนวนลูกค้า และสามารถแยกส่วนลูกค้าแต่ละรายได้

ทั้งหมดนี้ช่วย Amazon Route 53 ได้อย่างไร ด้วย Route 53 เราตัดสินใจที่จะจัดเตรียมสมรรถภาพของเราในเซิร์ฟเวอร์ชื่อเสมือนทั้งหมด 2048 เครื่อง เซิร์ฟเวอร์เหล่านี้เป็นเซิร์ฟเวอร์เสมือน เพราะไม่ตรงกับเซิร์ฟเวอร์จริงที่โฮสต์ Route 53 เราสามารถย้ายไปมาได้เพื่อช่วยจัดการสมรรถภาพ จากนั้น เราจะมอบหมายโดเมนลูกค้าทุกรายให้กับกลุ่มย่อยที่ผสมคละกันของเซิร์ฟเวอร์ชื่อเสมือน 4 เครื่อง ด้วยจำนวนดังกล่าว จะมีกลุ่มย่อยที่ผสมคละกันที่เป็นไปได้ถึง 7.3 แสนล้านกลุ่มที่เป็นไปได้ เรามีกลุ่มย่อยที่ผสมคละกันที่เป็นไปได้มากมายเสียจนเราสามารถมอบหมายกลุ่มย่อยที่ผสมคละกันที่ไม่ซ้ำกันให้กับทุกๆ โดเมนได้ ความจริงแล้ว เราสามารถไปได้มากกว่านี้อีก และแน่ใจได้ว่าจะไม่มีโดเมนลูกค้าใดๆ ที่จะใช้เซิร์ฟเวอร์ชื่อเสมือนร่วมกันมากกว่า 2 เซิร์ฟเวอร์กับโดเมนลูกค้าอื่นใด

ผลที่ได้รับนั้นเหลือเชื่อมาก หากโดเมนลูกค้าเป็นเป้าหมายสำหรับการโจมตี DDoS เซิร์ฟเวอร์ชื่อเสมือน 4 ตัวที่มอบหมายให้กับโดเมนนั้นจะมีปริมาณงานพุ่งขึ้นสูง แต่โดเมนของลูกค้าอื่นๆ จะไม่สามารถสังเกตเห็นได้ เราจะไม่ยอมปล่อยให้ลูกค้าที่ตกเป็นเป้าต้องเผชิญกับการโจมตีโดยเด็ดขาด การแบ่งกลุ่มย่อยที่ผสมคละกันทำให้เราสามารถระบุและแยกส่วนลูกค้าที่ตกเป็นเป้าไปยังสมรรถภาพที่กำหนดให้เป็นพิเศษสำหรับการโจมตีได้ นอกจากนี้ เรายังได้พัฒนาโปรแกรมล้างปริมาณข้อมูล AWS Shield ซึ่งเป็นกรรมสิทธิ์ของเราเอง อย่างไรก็ตาม การแบ่งกลุ่มย่อยที่ผสมคละกันทำให้เกิดความแตกต่างอย่างมหาศาลในการทำให้แน่ใจว่าประสบการณ์ลูกค้า Route 53 โดยรวมเป็นไปอย่างราบรื่น แม้ในขณะที่เหตุการณ์เหล่านี้กำลังเกิดขึ้น

เราได้ดำเนินการฝังการแบ่งกลุ่มย่อยที่ผสมคละกันไว้ภายในระบบอื่นๆ ของเราจำนวนมาก นอกจากนี้ เรายังมีการปรับปรุงให้ละเอียดยิ่งขึ้น เช่น การแบ่งกลุ่มย่อยที่ผสมคละกันแบบเวียนซ้ำ ซึ่งเราจะแบ่งกลุ่มย่อยรายการในหลายเลเยอร์ ทำให้เกิดการแยกส่วนลูกค้าของลูกค้า การแบ่งกลุ่มย่อยที่ผสมคละกันสามารถปรับแต่งได้อย่างมากมาย โดยเป็นวิธีที่ชาญฉลาดในการจัดเตรียมทรัพยากรที่มีอยู่ ซึ่งโดยทั่วไปจะไม่มีต้นทุนเพิ่มเติมอีกด้วย จึงเป็นการปรับปรุงที่ยอดเยี่ยมที่สามารถเกิดขึ้นได้จากความประหยัดมัธยัสถ์

หากคุณสนใจในการใช้การแบ่งกลุ่มย่อยที่ผสมคละกัน สามารถตรวจดูไลบรารี Route 53 Infima แบบโอเพ่นซอร์สของเราได้ ไลบรารีดังกล่าวประกอบด้วยการนำการแบ่งกลุ่มย่อยที่ผสมคละกันมาใช้งานที่แตกต่างกันจำนวนมาก ซึ่งสามารถใช้ในการมอบหมายหรือจัดเตรียมทรัพยากรได้

ลองใช้หลักการที่คุณได้เรียนรู้ที่นี่ด้วยแล็บฝึกปฏิบัติจริง