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

การดำเนินการโฮสต์ DNS

ไม่นานหลังจากที่ AWS เริ่มให้บริการ ลูกค้า AWS ได้บอกชัดเจนว่าพวกเขาต้องการใช้บริการ Amazon Simple Storage Service (S3), Amazon CloudFront และ Elastic Load Balancing ของเราที่ “ต้นทาง” ของโดเมนของพวกเขา ซึ่งหมายถึงสำหรับชื่ออย่างเช่น “amazon.com” และไม่ใช่สำหรับชื่ออย่างเช่น “www.amazon.com” เท่านั้น
 
ซึ่งมันอาจจะดูง่ายมาก อย่างไรก็ตาม เนื่องจากการตัดสินใจในการออกแบบโปรโตคอล DNS ที่ทำขึ้นในทศวรรษ 1980 มันจึงยากกว่าที่คิด DNS มีคุณสมบัติที่ชื่อ CNAME ซึ่งอนุญาตให้เจ้าของโดเมนออฟโหลดส่วนของโดเมนของตนให้กผู้ให้บริการรายอื่นโฮสต์ได้ แต่ก็ใช้ไม่ได้ผลที่ต้นทางหรือระดับสูงสุดของโดเมน เพื่อสนองความต้องการของลูกค้า เราจึงต้องโฮสต์โดเมนของลูกค้าของเราจริงๆ เมื่อเราโฮสต์โดเมนของลูกค้า เราสามารถส่งค่าที่อยู่ IP ชุดปัจจุบัน ไม่ว่าจะเป็นค่าใดก็ได้สำหรับ Amazon S3, Amazon CloudFront หรือ Elastic Load Balancing บริการเหล่านี้ขยายตัวและเพิ่มที่อยู่ IP อย่างสม่ำเสมอ ดังนั้น ลูกค้าจึงไม่สามารถเขียนโค้ดระบุค่าในการกำหนดค่าโดเมนของตัวเองได้ง่ายๆ
 
การโฮสต์ DNS ไม่ใช่เรื่องเล็กๆ หาก DNS มีปัญหา ธุรกิจทั้งธุรกิจก็สามารถออฟไลน์ได้ อย่างไรก็ตาม หลังจากที่เราได้ระบุความต้องการแล้ว เราก็ได้เริ่มต้นแก้ปัญหาในลักษณะที่พบได้ทั่วไปที่ Amazon อย่างเร่งด่วน เราได้ก่อตั้งทีมวิศวกรขนาดเล็ก แล้วเราก็เริ่มทำงาน

การจัดการกับการโจมตี DDoS

ผู้ให้บริการ 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 และการแบ่งกลุ่มย่อยที่ผสมคละกัน

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

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

สรุป

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

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

แล็บฝึกปฏิบัติจริง

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


เกี่ยวกับผู้เขียน

Colm MacCárthaigh เป็นวิศวกรหลักอาวุโสที่ Amazon Web Services ก่อนที่เขาจะมาทำงานกับ EC2 การเข้ารหัส และระบบเครือข่าย Colm ได้ช่วยสร้าง Amazon CloudFront และ Amazon Route 53 Colm ยังเป็นผู้สนับสนุนโอเพ่นซอร์สอีกด้วย และเป็นหนึ่งในผู้เขียนเว็บเซิร์ฟเวอร์ Apache httpd ตลอดจน Amazon s2n การนำโปรโตคอล SSL/TLS มาใช้งานของ AWS เมื่อไม่ได้ทำงานกับเรื่องทางเทคนิค Colm เป็นนักดนตรีและนักร้อง และเล่นดนตรี ทัวร์ และบันทึกเสียงเพลงไอริชในระดับสากลอยู่บ่อยครั้ง

การหมดเวลา การลองใหม่ และการถอยกลับที่มีความผันแปร