AWS จัดเตรียมบริการที่ยืดหยุ่นได้อย่างไร การปรับขนาดเซิร์ฟเวอร์และฐานข้อมูล

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

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

เกี่ยวกับวิทยากร: Vasily Pantyukhin (ไก่) เริ่มต้นจากการเป็นผู้ดูแลระบบ Unix ของบริษัท .ru ทำงานเกี่ยวกับฮาร์ดแวร์ Sun Microsystem ขนาดใหญ่เป็นเวลา 6 ปี และเผยแพร่โลกที่เน้นข้อมูลเป็นศูนย์กลางที่ EMC เป็นเวลา 11 ปี โดยธรรมชาติแล้วพัฒนาไปเป็นระบบคลาวด์ส่วนตัว และในปี 2017 ได้ย้ายไปใช้ระบบคลาวด์สาธารณะ ตอนนี้เขาให้คำแนะนำทางเทคนิคเพื่อช่วยเหลือและพัฒนาในระบบคลาวด์ AWS

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

ทำไมฉันถึงพูดถึงอุปกรณ์ Amazon?

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

ทุกอย่างดีมาก ยกเว้นสิ่งหนึ่ง - ติดอยู่ในรถติด ดูเหมือนคุณกำลังนั่งเฉยๆ ไม่ทำอะไรเลย แต่คุณเปลี่ยนเกียร์อยู่ตลอดเวลา กดคลัตช์ แก๊ส และเบรก มันทำให้คุณเหนื่อยมาก ปัญหารถติดคลี่คลายได้บางส่วนเมื่อครอบครัวมีรถยนต์เกียร์อัตโนมัติ ขณะขับรถ ฉันมีเวลาคิดเกี่ยวกับบางสิ่งบางอย่างและฟังหนังสือเสียง

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

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

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

สิ่งที่เราจะพูดคุยเกี่ยวกับ

ฉันเลือกแนวทางที่หลากหลาย - ฉันเลือกบริการที่น่าสนใจ 4 รายการที่ควรค่าแก่การพูดถึง

การเพิ่มประสิทธิภาพเซิร์ฟเวอร์. เมฆชั่วคราวที่มีรูปลักษณ์ทางกายภาพ: ศูนย์ข้อมูลทางกายภาพที่มีเซิร์ฟเวอร์ทางกายภาพที่ส่งเสียงฮัม เพิ่มความร้อน และกะพริบด้วยแสงไฟ

ฟังก์ชั่นไร้เซิร์ฟเวอร์ (แลมบ์ดา) น่าจะเป็นบริการที่ปรับขนาดได้มากที่สุดในระบบคลาวด์

การปรับขนาดฐานข้อมูล. ฉันจะบอกคุณเกี่ยวกับวิธีที่เราสร้างฐานข้อมูลที่ปรับขนาดได้ของเราเอง

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

บันทึก. บทความนี้จะกล่าวถึงการเพิ่มประสิทธิภาพเซิร์ฟเวอร์และการปรับขนาดฐานข้อมูล เราจะพิจารณาการปรับขนาดเครือข่ายในบทความถัดไป ฟังก์ชั่นไร้เซิร์ฟเวอร์อยู่ที่ไหน? มีการเผยแพร่บันทึกแยกต่างหากเกี่ยวกับพวกเขา”ตัวเล็กแต่ฉลาด แกะกล่อง Firecracker microvirtual" โดยจะพูดถึงวิธีการปรับขนาดต่างๆ หลายวิธี และกล่าวถึงรายละเอียดเกี่ยวกับโซลูชัน Firecracker ซึ่งเป็นการผสมผสานคุณสมบัติที่ดีที่สุดของเครื่องเสมือนและคอนเทนเนอร์

เซิร์ฟเวอร์

เมฆนั้นอยู่เพียงชั่วคราว แต่ความชั่วคราวนี้ยังคงมีรูปลักษณ์ทางกายภาพ - เซิร์ฟเวอร์ ในตอนแรกสถาปัตยกรรมของพวกเขาเป็นแบบคลาสสิก ชิปเซ็ต x86 มาตรฐาน, การ์ดเครือข่าย, Linux, ไฮเปอร์ไวเซอร์ Xen ที่รันเครื่องเสมือน

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

การเพิ่มประสิทธิภาพฮาร์ดแวร์และไฮเปอร์ไวเซอร์

ทำทุกอย่างพร้อมกันแล้วทำได้ดีจะไม่เกิดผล สิ่งที่ "ดี" ก็ไม่ชัดเจนในตอนแรกเช่นกัน

เราตัดสินใจที่จะใช้แนวทางเชิงวิวัฒนาการ - เราเปลี่ยนองค์ประกอบที่สำคัญอย่างหนึ่งของสถาปัตยกรรมและนำไปปฏิบัติจริง

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

การเปลี่ยนแปลงเริ่มขึ้นในปี 2013 โดยมีสิ่งที่ซับซ้อนที่สุด นั่นก็คือเครือข่าย ใน S3 อินสแตนซ์ การ์ด Network Accelerator พิเศษถูกเพิ่มลงในการ์ดเครือข่ายมาตรฐาน เชื่อมต่ออย่างแท้จริงด้วยสายลูปแบ็คสั้นที่แผงด้านหน้า ไม่สวยแต่มองไม่เห็นในเมฆ แต่การโต้ตอบโดยตรงกับฮาร์ดแวร์ทำให้ความกระวนกระวายใจและปริมาณงานเครือข่ายดีขึ้นโดยพื้นฐาน

ต่อไป เราตัดสินใจปรับปรุงการเข้าถึงบล็อกการจัดเก็บข้อมูล EBS - Elastic Block Storage เป็นการผสมผสานระหว่างเครือข่ายและการจัดเก็บข้อมูล ปัญหาคือแม้ว่าจะมีการ์ด Network Accelerator อยู่ในตลาด แต่ไม่มีทางเลือกให้ซื้อฮาร์ดแวร์ Storage Accelerator เราจึงหันมาทำธุรกิจสตาร์ทอัพ อันนะปุรณะแล็บผู้พัฒนาชิป ASIC พิเศษให้กับเรา พวกเขาอนุญาตให้ติดตั้งไดรฟ์ข้อมูล EBS ระยะไกลเป็นอุปกรณ์ NVMe

ในบางกรณี C4 เราแก้ไขปัญหาสองข้อแล้ว ประการแรกคือเราได้วางรากฐานสำหรับอนาคตของเทคโนโลยี NVMe ที่มีแนวโน้มดีแต่เป็นเทคโนโลยีใหม่ในขณะนั้น ประการที่สอง เราได้ยกเลิกการโหลดโปรเซสเซอร์กลางอย่างมีนัยสำคัญโดยการโอนการประมวลผลคำขอไปยัง EBS ไปยังการ์ดใหม่ ผ่านไปด้วยดี ดังนั้นตอนนี้ Annapurna Labs จึงเป็นส่วนหนึ่งของ Amazon

ภายในเดือนพฤศจิกายน 2017 เราตระหนักว่าถึงเวลาที่ต้องเปลี่ยนไฮเปอร์ไวเซอร์แล้ว

ไฮเปอร์ไวเซอร์ใหม่ได้รับการพัฒนาโดยใช้โมดูลเคอร์เนล KVM ที่ได้รับการดัดแปลง

ทำให้สามารถลดค่าใช้จ่ายในการจำลองอุปกรณ์โดยพื้นฐานและทำงานร่วมกับ ASIC ใหม่ได้โดยตรง ตัวอย่าง S5 เป็นเครื่องเสมือนเครื่องแรกที่มีไฮเปอร์ไวเซอร์ใหม่ทำงานภายใต้ประทุน เราตั้งชื่อเขาว่า Nitro.

วิวัฒนาการของอินสแตนซ์บนไทม์ไลน์

เครื่องเสมือนประเภทใหม่ทั้งหมดที่ปรากฏตั้งแต่เดือนพฤศจิกายน 2017 ทำงานบนไฮเปอร์ไวเซอร์นี้ อินสแตนซ์ Bare Metal ไม่มีไฮเปอร์ไวเซอร์แต่เรียกอีกอย่างว่าไนโตร เนื่องจากใช้การ์ดไนโตรพิเศษ

ในอีกสองปีข้างหน้า จำนวนประเภทอินสแตนซ์ Nitro เกินสองสามโหล: A1, C5, M5, T3 และอื่นๆ

ประเภทอินสแตนซ์

เครื่องจักร Nitro สมัยใหม่ทำงานอย่างไร

พวกเขามีองค์ประกอบหลักสามส่วน: ไฮเปอร์ไวเซอร์ Nitro (ตามที่กล่าวไว้ข้างต้น) ชิปรักษาความปลอดภัย และการ์ด Nitro

ชิปรักษาความปลอดภัย รวมเข้ากับเมนบอร์ดโดยตรง ควบคุมฟังก์ชันที่สำคัญหลายอย่าง เช่น การควบคุมการโหลดระบบปฏิบัติการโฮสต์

การ์ดไนโตร - มีสี่ประเภทด้วยกัน ทั้งหมดได้รับการพัฒนาโดย Annapurna Labs และใช้ ASIC ทั่วไป เฟิร์มแวร์บางตัวก็เป็นเรื่องปกติเช่นกัน

การ์ด Nitro สี่ประเภท

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

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

ระบบของการ์ด Nitro, ไฮเปอร์ไวเซอร์ และชิปรักษาความปลอดภัยถูกรวมเข้ากับเครือข่าย SDN หรือ ซอฟต์แวร์ที่กำหนดเครือข่าย. รับผิดชอบในการจัดการเครือข่ายนี้ (Control Plane) การ์ดคอนโทรลเลอร์.

แน่นอนว่าเรายังคงพัฒนา ASIC ใหม่อย่างต่อเนื่อง ตัวอย่างเช่น เมื่อปลายปี 2018 พวกเขาได้เปิดตัวชิป Inferentia ซึ่งช่วยให้คุณทำงานด้านแมชชีนเลิร์นนิงได้อย่างมีประสิทธิภาพมากขึ้น

ชิปประมวลผลการเรียนรู้ของเครื่อง Inferentia

ฐานข้อมูลที่ปรับขนาดได้

ฐานข้อมูลแบบดั้งเดิมมีโครงสร้างแบบชั้น เพื่อให้ง่ายขึ้นอย่างมาก ระดับต่อไปนี้จึงมีความโดดเด่น

• SQL — ลูกค้าและผู้มอบหมายงานร้องขอทำงาน
• บทบัญญัติ การทำธุรกรรม - ทุกอย่างชัดเจนที่นี่ กรด และทั้งหมดนั้น
• เก็บเอาไว้ซึ่งจัดทำโดยบัฟเฟอร์พูล
• การบันทึก — จัดทำบันทึกการทำซ้ำ ใน MySQL เรียกว่า Bin Logs ใน PosgreSQL - Write Ahead Logs (WAL)
• การเก็บรักษา – บันทึกลงดิสก์โดยตรง

โครงสร้างฐานข้อมูลแบบชั้น

มีวิธีต่างๆ ในการปรับขนาดฐานข้อมูล: การแบ่งส่วน สถาปัตยกรรมที่ไม่มีการแบ่งปัน ดิสก์ที่แชร์

อย่างไรก็ตาม วิธีการทั้งหมดนี้ยังคงรักษาโครงสร้างฐานข้อมูลแบบเสาหินเดียวกัน นี่เป็นการจำกัดขนาดอย่างมาก เพื่อแก้ปัญหานี้เราได้พัฒนาฐานข้อมูลของเราเอง - อเมซอน ออโรร่า. มันเข้ากันได้กับ MySQL และ PostgreSQL

อเมซอน ออโรร่า

แนวคิดทางสถาปัตยกรรมหลักคือการแยกระดับการจัดเก็บและการบันทึกออกจากฐานข้อมูลหลัก

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

ระดับการบันทึกและการจัดเก็บแยกจากฐานข้อมูล

DBMS แบบดั้งเดิมจะเขียนข้อมูลไปยังระบบจัดเก็บข้อมูลในรูปแบบของบล็อก ที่ Amazon Aurora เราได้สร้างพื้นที่จัดเก็บข้อมูลอัจฉริยะที่สามารถพูดภาษาได้ ทำซ้ำบันทึก. ภายในพื้นที่จัดเก็บข้อมูลจะเปลี่ยนบันทึกเป็นบล็อคข้อมูล ตรวจสอบความสมบูรณ์ของบันทึก และสำรองข้อมูลโดยอัตโนมัติ

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

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

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

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

เราได้ทำการจัดเรียงที่เก็บข้อมูลแล้ว

วิธีปรับขนาดระดับ DBMS

ในกรณีนี้ การปรับสเกลแนวนอนจะยากกว่ามาก งั้นเราไปตามเส้นทางที่ถูกตีกันเถอะ มาตราส่วนแนวตั้งแบบคลาสสิก.

สมมติว่าเรามีแอปพลิเคชันที่สื่อสารกับ DBMS ผ่านโหนดหลัก

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

ต่อไปเราจะสลับแอปพลิเคชันจากโหนดหลักเก่าไปเป็นโหนดใหม่ ปัญหาเกิดขึ้น

• สิ่งนี้จะต้องมีการหยุดทำงานของแอปพลิเคชันอย่างมีนัยสำคัญ
• โหนดหลักใหม่จะมีแคชเย็น ประสิทธิภาพของฐานข้อมูลจะสูงสุดหลังจากที่แคชอุ่นเครื่องแล้วเท่านั้น

จะปรับปรุงสถานการณ์ได้อย่างไร? ตั้งค่าพร็อกซีระหว่างแอปพลิเคชันและโหนดหลัก

สิ่งนี้จะให้อะไรเราบ้าง? ตอนนี้แอปพลิเคชันทั้งหมดไม่จำเป็นต้องเปลี่ยนเส้นทางไปยังโหนดใหม่ด้วยตนเอง สวิตช์สามารถทำได้ภายใต้พรอกซีและเร็วกว่าโดยพื้นฐาน

ดูเหมือนว่าปัญหาได้รับการแก้ไขแล้ว แต่ไม่ เรายังต้องทนทุกข์ทรมานจากความจำเป็นในการอุ่นเครื่องแคช นอกจากนี้ยังเกิดปัญหาใหม่ - ตอนนี้พร็อกซีเป็นจุดที่อาจเกิดความล้มเหลว

โซลูชันสุดท้ายกับ Amazon Aurora แบบไร้เซิร์ฟเวอร์

เราแก้ไขปัญหาเหล่านี้ได้อย่างไร?

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

เพิ่มกลุ่มโหนดอุ่นขนาดต่างๆ. ดังนั้นหากจำเป็นต้องจัดสรรโหนดใหม่ให้มีขนาดใหญ่ขึ้นหรือเล็กลง ก็พร้อมใช้งานได้ทันที ไม่จำเป็นต้องรอให้โหลด

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

พร็อกซีแบบกระจาย อินสแตนซ์ warm และการตรวจสอบ

มีโหนดที่มีกำลังไฟที่ต้องการ บัฟเฟอร์พูลจะถูกคัดลอกไปที่นั้น และระบบจะเริ่มรอช่วงเวลาที่ปลอดภัยเพื่อเปลี่ยน

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

ทำงานกับฐานข้อมูลเรซูเม่

จากกราฟแสดงว่าช่วงล่างสั้นมากจริงๆ กราฟสีน้ำเงินแสดงภาระ และขั้นตอนสีแดงแสดงช่วงเวลาที่ปรับขนาด การลดลงในระยะสั้นในกราฟสีน้ำเงินถือเป็นการดีเลย์ระยะสั้นนั่นเอง

อย่างไรก็ตาม Amazon Aurora ช่วยให้คุณประหยัดเงินได้อย่างสมบูรณ์และปิดฐานข้อมูลเมื่อไม่ได้ใช้งาน เช่น ในวันหยุดสุดสัปดาห์ หลังจากหยุดโหลด DB จะค่อยๆลดกำลังลงและปิดไประยะหนึ่ง เมื่อโหลดกลับมาก็จะเพิ่มขึ้นอย่างราบรื่นอีกครั้ง

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

На โหลดสูง++ Vasily Pantyukhin จะรายงาน”ฮูสตันพวกเรามีปัญหา. การออกแบบระบบสำหรับความล้มเหลว รูปแบบการพัฒนาสำหรับบริการคลาวด์ภายในของ Amazon" นักพัฒนา Amazon ใช้รูปแบบการออกแบบสำหรับระบบแบบกระจายอะไร อะไรคือสาเหตุของความล้มเหลวในการบริการ สถาปัตยกรรมแบบเซลล์คืออะไร Constant Work, Shuffle Sharding - มันจะน่าสนใจ น้อยกว่าหนึ่งเดือนก่อนการประชุม - จองตั๋วของคุณ. 24 ตุลาคม ขึ้นราคาครั้งสุดท้าย

ที่มา: will.com