AWS จัดเตรียมบริการที่ยืดหยุ่นได้อย่างไร การปรับขนาดเครือข่าย

ขนาดของเครือข่าย Amazon Web Services คือ 69 โซนทั่วโลกใน 22 ภูมิภาค: สหรัฐอเมริกา ยุโรป เอเชีย แอฟริกา และออสเตรเลีย แต่ละโซนประกอบด้วยศูนย์ข้อมูลสูงสุด 8 แห่ง - ศูนย์ประมวลผลข้อมูล ศูนย์ข้อมูลแต่ละแห่งมีเซิร์ฟเวอร์นับพันหรือหลายแสนเครื่อง เครือข่ายได้รับการออกแบบในลักษณะที่คำนึงถึงสถานการณ์ไฟดับที่ไม่น่าจะเป็นไปได้ทั้งหมด ตัวอย่างเช่น ทุกภูมิภาคถูกแยกออกจากกัน และโซนการเข้าถึงจะถูกแยกออกจากกันในระยะทางหลายกิโลเมตร แม้ว่าคุณจะตัดสายเคเบิล ระบบจะเปลี่ยนไปใช้ช่องสัญญาณสำรอง และการสูญหายของข้อมูลจะเท่ากับแพ็กเก็ตข้อมูลบางส่วน Vasily Pantyukhin จะพูดคุยเกี่ยวกับหลักการอื่นๆ ที่เครือข่ายสร้างขึ้นและมีโครงสร้างอย่างไร

วาซิลี ปันยูคิน เริ่มต้นจากการเป็นผู้ดูแลระบบ Unix ในบริษัท .ru ทำงานเกี่ยวกับฮาร์ดแวร์ Sun Microsystem ขนาดใหญ่เป็นเวลา 6 ปี และเผยแพร่โลกที่เน้นข้อมูลเป็นศูนย์กลางเป็นเวลา 11 ปีที่ EMC โดยธรรมชาติแล้วพัฒนาไปเป็นคลาวด์ส่วนตัว จากนั้นจึงย้ายไปยังคลาวด์สาธารณะ ปัจจุบันในฐานะสถาปนิกของ Amazon Web Services เขาให้คำแนะนำทางเทคนิคเพื่อช่วยเหลือและพัฒนาในระบบคลาวด์ AWS

ในส่วนก่อนหน้าของ AWS ไตรภาคเดอะลอร์ Vasily เจาะลึกการออกแบบเซิร์ฟเวอร์จริงและการปรับขนาดฐานข้อมูล การ์ด Nitro, ไฮเปอร์ไวเซอร์ที่ใช้ KVM แบบกำหนดเอง, ฐานข้อมูล Amazon Aurora - เกี่ยวกับทั้งหมดนี้ในเนื้อหา "AWS จัดเตรียมบริการที่ยืดหยุ่นได้อย่างไร การปรับขนาดเซิร์ฟเวอร์และฐานข้อมูล" อ่านเพื่อดูบริบทหรือดู บันทึกวีดีโอ สุนทรพจน์

ส่วนนี้จะเน้นไปที่การปรับขนาดเครือข่าย ซึ่งเป็นหนึ่งในระบบที่ซับซ้อนที่สุดใน AWS วิวัฒนาการจากเครือข่ายแบบแบนไปสู่ ​​Virtual Private Cloud และการออกแบบ บริการภายในของ Blackfoot และ HyperPlane ปัญหาของเพื่อนบ้านที่มีเสียงดัง และท้ายที่สุดคือขนาดของเครือข่าย แกนหลัก และสายเคเบิลทางกายภาพ เกี่ยวกับทั้งหมดนี้ภายใต้การตัด

ข้อจำกัดความรับผิดชอบ: ทุกอย่างด้านล่างนี้เป็นความเห็นส่วนตัวของ Vasily และอาจไม่ตรงกับจุดยืนของ Amazon Web Services

การปรับขนาดเครือข่าย

AWS cloud เปิดตัวในปี 2006 เครือข่ายของเขาค่อนข้างดั้งเดิม - มีโครงสร้างเรียบ ช่วงที่อยู่ส่วนตัวเป็นเรื่องปกติของผู้เช่าระบบคลาวด์ทั้งหมด เมื่อเริ่มต้นเครื่องเสมือนใหม่ คุณได้รับที่อยู่ IP ที่พร้อมใช้งานจากช่วงนี้โดยไม่ได้ตั้งใจ

แนวทางนี้นำไปปฏิบัติได้ง่าย แต่โดยพื้นฐานแล้วจำกัดการใช้ระบบคลาวด์ โดยเฉพาะอย่างยิ่ง การพัฒนาโซลูชันไฮบริดที่รวมเครือข่ายส่วนตัวแบบภาคพื้นดินและใน AWS เข้าด้วยกันนั้นค่อนข้างยาก ปัญหาที่พบบ่อยที่สุดคือช่วงที่อยู่ IP ที่ทับซ้อนกัน

คลาวด์ส่วนตัวเสมือน

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

สิ่งแรกที่คุณนึกถึงเมื่อคุณคิดถึงการแยกเครือข่ายคืออะไร แน่นอน VLAN и VRF - การกำหนดเส้นทางและการส่งต่อเสมือน.

น่าเสียดายที่มันไม่ได้ผล VLAN ID มีขนาดเพียง 12 บิต ซึ่งให้เซ็กเมนต์ที่แยกได้เพียง 4096 ส่วนเท่านั้น แม้แต่สวิตช์ที่ใหญ่ที่สุดก็สามารถใช้ VRF ได้สูงสุด 1-2 ตัว การใช้ VRF และ VLAN ร่วมกันทำให้เรามีเครือข่ายย่อยเพียงไม่กี่ล้านรายการ ซึ่งไม่เพียงพอสำหรับผู้เช่าหลายสิบล้านรายอย่างแน่นอน ซึ่งแต่ละรายต้องใช้ซับเน็ตหลายตัวได้

นอกจากนี้เรายังไม่สามารถซื้อกล่องขนาดใหญ่ตามจำนวนที่ต้องการได้ เช่น จาก Cisco หรือ Juniper มีเหตุผลสองประการ: มันมีราคาแพงมาก และเราไม่ต้องการตกเป็นเหยื่อของนโยบายการพัฒนาและการแพตช์ของพวกเขา

มีข้อสรุปเพียงข้อเดียวคือสร้างวิธีแก้ปัญหาของคุณเอง

ในปี 2009 เราได้ประกาศ วี.พี.ซี - คลาวด์ส่วนตัวเสมือน. ชื่อนี้ติดอยู่และตอนนี้ผู้ให้บริการคลาวด์หลายรายก็ใช้ชื่อนี้เช่นกัน

VPC เป็นเครือข่ายเสมือน SDN (เครือข่ายที่กำหนดโดยซอฟต์แวร์) เราตัดสินใจที่จะไม่ประดิษฐ์โปรโตคอลพิเศษที่ระดับ L2 และ L3 เครือข่ายทำงานบนอีเทอร์เน็ตมาตรฐานและ IP สำหรับการส่งข้อมูลผ่านเครือข่าย การรับส่งข้อมูลของเครื่องเสมือนจะถูกรวมไว้ใน Wrapper โปรโตคอลของเราเอง โดยระบุ ID ที่เป็นของ VPC ของผู้เช่า

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

ในเครื่องรุ่นใหม่ การห่อหุ้มจะดำเนินการโดยการ์ด Nitro ที่ระดับฮาร์ดแวร์ ในกรณีเก่า การห่อหุ้มและการแยกแคปซูลจะขึ้นอยู่กับซอฟต์แวร์ 

เรามาดูกันว่ามันทำงานอย่างไรในแง่ทั่วไป เริ่มจากระดับ L2 กันก่อน สมมติว่าเรามีเครื่องเสมือนที่มี IP 10.0.0.2 บนเซิร์ฟเวอร์จริง 192.168.0.3 ส่งข้อมูลไปยังเครื่องเสมือน 10.0.0.3 ซึ่งใช้งานบน 192.168.1.4 คำขอ ARP จะถูกสร้างขึ้นและส่งไปยังการ์ดเครือข่าย Nitro เพื่อความง่าย เราถือว่าเครื่องเสมือนทั้งสองเครื่องอยู่ใน VPC “สีน้ำเงิน” เดียวกัน

แผนที่จะแทนที่ที่อยู่ต้นทางด้วยที่อยู่ของตัวเองและส่งต่อเฟรม ARP ไปยังบริการแผนที่

บริการแผนที่ส่งคืนข้อมูลที่จำเป็นสำหรับการส่งผ่านเครือข่ายทางกายภาพ L2

การ์ด Nitro ในการตอบกลับ ARP จะแทนที่ MAC บนเครือข่ายกายภาพด้วยที่อยู่ใน VPC

เมื่อถ่ายโอนข้อมูล เราจะรวม MAC และ IP แบบลอจิคัลไว้ใน VPC Wrapper เราส่งข้อมูลทั้งหมดนี้ผ่านเครือข่ายทางกายภาพโดยใช้การ์ด IP Nitro ต้นทางและปลายทางที่เหมาะสม

เครื่องฟิสิคัลที่แพ็กเกจถูกกำหนดไว้จะทำการตรวจสอบ นี่เป็นสิ่งจำเป็นเพื่อป้องกันความเป็นไปได้ของการปลอมแปลงที่อยู่ เครื่องส่งคำขอพิเศษไปยังบริการแผนที่และถามว่า: “จากเครื่องจริง 192.168.0.3 ฉันได้รับแพ็กเก็ตที่มีไว้สำหรับ 10.0.0.3 ใน VPC สีน้ำเงิน เขาถูกต้องตามกฎหมายหรือไม่? 

บริการแผนที่จะตรวจสอบตารางการจัดสรรทรัพยากรและอนุญาตหรือปฏิเสธแพ็กเก็ตที่จะผ่าน ในกรณีใหม่ทั้งหมด การตรวจสอบเพิ่มเติมจะฝังอยู่ในการ์ด Nitro เป็นไปไม่ได้ที่จะข้ามมันไปในทางทฤษฎีด้วยซ้ำ ดังนั้น การปลอมแปลงทรัพยากรใน VPC อื่นจะไม่ทำงาน

จากนั้น ข้อมูลจะถูกส่งไปยังเครื่องเสมือนที่ต้องการ 

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

ปรากฎว่าเมื่อส่งแต่ละแพ็กเก็ต เซิร์ฟเวอร์จะหันไปใช้บริการแผนที่ จะจัดการกับความล่าช้าที่หลีกเลี่ยงไม่ได้ได้อย่างไร? เก็บเอาไว้, แน่นอน.

ข้อดีก็คือคุณไม่จำเป็นต้องแคชโต๊ะขนาดใหญ่ทั้งหมด เซิร์ฟเวอร์จริงโฮสต์เครื่องเสมือนจาก VPC จำนวนค่อนข้างน้อย คุณจะต้องแคชข้อมูลเกี่ยวกับ VPC เหล่านี้เท่านั้น การถ่ายโอนข้อมูลไปยัง VPC อื่นในการกำหนดค่า “เริ่มต้น” ยังคงไม่ถูกต้องตามกฎหมาย หากใช้ฟังก์ชันการทำงาน เช่น VPC-เพียร์ ข้อมูลเกี่ยวกับ VPC ที่เกี่ยวข้องจะถูกโหลดลงในแคชเพิ่มเติม 

เราจัดเรียงการถ่ายโอนข้อมูลไปยัง VPC

Blackfoot

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

Blackfoot ลดปริมาณการรับส่งข้อมูลและทำสิ่งที่จำเป็นด้วย ข้อมูลจะถูกส่งไปยังอินเทอร์เน็ตตามที่เป็นอยู่

ข้อมูลจะถูกแยกส่วนและห่อใหม่ใน IPsec เมื่อใช้ VPN

เมื่อใช้ Direct Connect การรับส่งข้อมูลจะถูกแท็กและส่งไปยัง VLAN ที่เหมาะสม

ไฮเปอร์เพลน

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

ในระบบคลาวด์ AWS ข้อกำหนดด้านเวลาแฝงในการส่งข้อมูลสูงมาก นั่นเป็นเหตุผล ไฮเปอร์เพลน สำคัญต่อประสิทธิภาพของเครือข่ายทั้งหมด

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

ไฮเปอร์เพลนเป็นระบบกระจายของเครื่อง EC2 ดังกล่าวจำนวนมาก เครื่องเสมือนแต่ละเครื่องมีแบนด์วิธ 5 GB/s ทั่วทั้งเครือข่ายระดับภูมิภาค ทำให้มีแบนด์วิดท์จำนวนเทราบิตที่น่าทึ่งและช่วยให้สามารถประมวลผลได้ การเชื่อมต่อนับล้านต่อวินาที.

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

เพื่อนบ้านที่มีเสียงดัง

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

แต่เราสร้างสถาปัตยกรรมของเราตามสถานการณ์ที่ไม่น่าเป็นไปได้ 

ความน่าจะเป็นต่ำไม่ได้หมายความว่าเป็นไปไม่ได้

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

วิธีแก้ปัญหาเพื่อนบ้านเสียงดัง? สิ่งแรกที่นึกถึงคือการแบ่งส่วน 8 โหนดของเราแบ่งออกเป็น 4 ส่วนๆ ละ 2 โหนดตามตรรกะ ขณะนี้เพื่อนบ้านที่มีเสียงดังจะรบกวนผู้ใช้เพียงหนึ่งในสี่เท่านั้น แต่จะรบกวนพวกเขาอย่างมาก

มาทำสิ่งที่แตกต่างกันเถอะ เราจะจัดสรรเพียง 3 โหนดให้กับผู้ใช้แต่ละคน 

เคล็ดลับคือการสุ่มกำหนดโหนดให้กับผู้ใช้ที่แตกต่างกัน ในภาพด้านล่าง ผู้ใช้สีน้ำเงินตัดโหนดกับผู้ใช้อีกสองคน - สีเขียวและสีส้ม

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

จำนวนผู้ใช้ที่จะตัดกัน

ความน่าจะเป็นเป็นเปอร์เซ็นต์

0

ลด 18%

1

ลด 54%

2

ลด 26%

3

2%

มาทำให้สถานการณ์เข้าใกล้ความเป็นจริงมากขึ้น - มาเอา 100 โหนดและผู้ใช้ 5 คนบน 5 โหนดกัน ในกรณีนี้ ไม่มีโหนดใดที่จะตัดกันด้วยความน่าจะเป็นที่ 77% 

จำนวนผู้ใช้ที่จะตัดกัน

ความน่าจะเป็นเป็นเปอร์เซ็นต์

0

ลด 77%

1

ลด 21%

2

ลด 1,8%

3

ลด 0,06%

4

ลด 0,0006%

5

ลด 0,00000013%

ในสถานการณ์จริง เนื่องจากมีโหนดและผู้ใช้ HyperPlane จำนวนมาก ผลกระทบที่อาจเกิดขึ้นจากเพื่อนบ้านที่มีเสียงดังต่อผู้ใช้รายอื่นจึงมีน้อยมาก วิธีการนี้เรียกว่า การผสมการแบ่งส่วน - การแบ่งส่วนแบบสุ่ม. จะช่วยลดผลกระทบด้านลบของความล้มเหลวของโหนดให้เหลือน้อยที่สุด

บริการจำนวนมากสร้างขึ้นบนพื้นฐานของ HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway

ขนาดเครือข่าย

ตอนนี้เรามาพูดถึงขนาดของเครือข่ายกันดีกว่า สำหรับเดือนตุลาคม 2019 AWS ให้บริการใน 22 ภูมิภาคและมีแผนอีก 9 รายการ

• แต่ละภูมิภาคประกอบด้วย Availability Zone หลายแห่ง มีทั้งหมด 69 แห่งทั่วโลก
• AZ แต่ละแห่งประกอบด้วยศูนย์ประมวลผลข้อมูล มีทั้งหมดไม่เกิน 8 อัน
• ศูนย์ข้อมูลมีเซิร์ฟเวอร์จำนวนมาก โดยบางเซิร์ฟเวอร์มีมากถึง 300 เครื่อง

ทีนี้มาเฉลี่ยทั้งหมดนี้ คูณแล้วได้ตัวเลขที่น่าประทับใจที่สะท้อนออกมา ระดับคลาวด์ของอเมซอน.

มีการเชื่อมต่อแบบออปติคอลมากมายระหว่าง Availability Zone และศูนย์ข้อมูล ในภูมิภาคที่ใหญ่ที่สุดแห่งหนึ่งของเรา มีการวางช่องสัญญาณ 388 ช่องสำหรับการสื่อสาร AZ ระหว่างกันและศูนย์การสื่อสารกับภูมิภาคอื่น ๆ (ศูนย์ขนส่ง) เท่านั้น โดยรวมแล้วสิ่งนี้ทำให้บ้า 5000 ทีบิต.

Backbone AWS สร้างขึ้นโดยเฉพาะและปรับให้เหมาะกับระบบคลาวด์ เราสร้างมันบนช่อง 100 GB / s. เราควบคุมพวกมันอย่างสมบูรณ์ ยกเว้นภูมิภาคในประเทศจีน การจราจรจะไม่ถูกแชร์กับบริษัทอื่นๆ มากมาย

แน่นอนว่าเราไม่ใช่ผู้ให้บริการคลาวด์รายเดียวที่มีเครือข่ายแกนหลักส่วนตัว บริษัทขนาดใหญ่จำนวนมากขึ้นเรื่อยๆ กำลังเดินตามเส้นทางนี้ ซึ่งได้รับการยืนยันจากนักวิจัยอิสระ เช่น จาก ภูมิศาสตร์โทรเลข.

กราฟแสดงให้เห็นว่าส่วนแบ่งของผู้ให้บริการเนื้อหาและผู้ให้บริการคลาวด์มีการเติบโต ด้วยเหตุนี้ ส่วนแบ่งการรับส่งข้อมูลอินเทอร์เน็ตของผู้ให้บริการแกนหลักจึงลดลงอย่างต่อเนื่อง

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

ฉันสงสัยว่าอินเทอร์เน็ตจะเปลี่ยนไปอย่างไรใน 10 ปีหากแนวโน้มนี้ยังคงอยู่?

ช่องทางทางกายภาพ

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

ในบางภูมิภาคเราต้องใช้สายเคเบิลพิเศษ ตัวอย่างเช่น ในภูมิภาคซิดนีย์ เราใช้สายเคเบิลที่มีสารเคลือบพิเศษป้องกันปลวก 

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

เราควบรวมบริการและเทคโนโลยีคลาวด์ของ Amazon บางส่วน ฉันหวังว่าคุณจะมีความคิดเกี่ยวกับขนาดของงานที่วิศวกรของเราต้องแก้ไข โดยส่วนตัวแล้วฉันพบว่าสิ่งนี้น่าตื่นเต้นมาก 

นี่เป็นส่วนสุดท้ายของไตรภาคจาก Vasily Pantyukhin เกี่ยวกับอุปกรณ์ AWS ใน ครั้งแรก ส่วนที่อธิบายการเพิ่มประสิทธิภาพเซิร์ฟเวอร์และการปรับขนาดฐานข้อมูลและใน ที่สอง — ฟังก์ชั่นไร้เซิร์ฟเวอร์และ Firecracker

На โหลดสูง++ ในเดือนพฤศจิกายน Vasily Pantyukhin จะแชร์รายละเอียดใหม่ของอุปกรณ์ Amazon เขา จะบอก เกี่ยวกับสาเหตุของความล้มเหลวและการออกแบบระบบแบบกระจายที่ Amazon วันที่ 24 ตุลาคม ก็ยังเป็นไปได้ หนังสือ ตั๋วในราคาดีแล้วจ่ายทีหลัง เรากำลังรอคุณอยู่ที่ HighLoad++ มาแชทกันเถอะ!

ที่มา: will.com