การซื้อบัญชี AWS: ใช้การกำหนดเส้นทางล่าช้าของ Amazon Route 53และการกำหนดเส้นทางความผิดพลาดเพื่อเพิ่มประสิทธิภาพการเข้าถึงของผู้ใช้ทั่วโลก

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

ประสบการณ์การเยี่ยมชมของผู้ใช้ทั่วโลกแตกต่างกันมาก

。

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

ในระบบนิเวศของ AWS (Amazon Cloud Technology) ผู้บัญชาการที่ดีที่สุดในการแก้ปัญหาการระบายน้ำทั่วโลกและการเพิ่มประสิทธิภาพเครือข่ายเรียกว่า

Amazon Route 53

。

วันนี้เราไม่ได้พูดถึงทฤษฎีทางการที่ว่างเปล่าและปฏิเสธที่จะพูดเราเริ่มต้นโดยตรงจากการต่อสู้จริงและสอนวิธีรวมและใช้สองกลยุทธ์หลักของ Route 53-

เส้นทางล่าช้า (Latency Routing) และ Failover (เรียกอีกอย่างว่าเส้นทางการถ่ายโอนล้มเหลว)

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

ขั้นตอนแรก: การกำหนดเส้นทางล่าช้า (Latency Routing)-ให้เครือข่ายเลือกเส้นทางที่เหมาะสมที่สุด

หลายคนมีความเข้าใจผิดว่าควรใช้ "Geolocation Routing" เพื่อเบี่ยงเบนความสนใจของผู้ใช้ทั่วโลกตัวอย่างเช่นผู้ใช้ชาวจีนไปที่เซิร์ฟเวอร์ฮ่องกงและผู้ใช้ชาวอเมริกันไปที่เซิร์ฟเวอร์โอเรกอน

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

ตรรกะพื้นฐานของการกำหนดเส้นทางล่าช้านั้นฉลาดมาก

โหนดขอบของ AWS ทั่วโลกจะวัดความล่าช้าของเครือข่ายจริง (Latency) ของส่วน IP ที่แตกต่างกันไปยังภูมิภาค AWS ต่างๆ (ภูมิภาค) เป็นประจำ

เมื่อผู้ใช้ชาวญี่ปุ่นเยี่ยมชมเว็บไซต์ของคุณ Route 53จะตรวจสอบตลาดอินเทอร์เน็ตในปัจจุบันและพบว่าความล่าช้าของ Tokyo Region คือ20ms และแม้แต่ U.S. Region คือ150ms ดังนั้น Route 53จะชี้การแก้ปัญหาชื่อโดเมนไปยังเซิร์ฟเวอร์โตเกียวในไม่กี่วินาทีวิธีการระบายน้ำแบบ "พูดด้วยความเร็วอินเทอร์เน็ตจริง" นี้เป็นการเบี่ยงเบนที่ชาญฉลาดอย่างแท้จริง

การต่อสู้จริง: กำหนดค่าเครือข่ายการเปลี่ยนเวลาแฝงทั่วโลก

เราถือว่า: ธุรกิจของคุณในโตเกียว (ap-northeast-1)

และ

เวอร์จิเนีย (เรา-1) ใช้ชุดเว็บเซิร์ฟเวอร์เดียวกัน

ลงชื่อเข้าใช้คอนโซล AWS ค้นหาและเข้าสู่ Route 53。

คลิกเข้าสู่ "โฮสต์โซน" ของคุณแล้วคลิก "สร้างบันทึก"

สร้างบันทึกแรก (ชี้ไปที่โตเกียว): ชื่อบันทึก: เช่น api.yourdomain.com กลยุทธ์การกำหนดเส้นทาง: เลือกเมนูแบบเลื่อนลงโดยไม่ลังเล

เลือก "Latency" ภูมิภาค: เลือก ap-northeast-1 (โตเกียว) เป้าหมายการกำหนดเส้นทางมูลค่า/การรับส่งข้อมูล: กรอก IP สาธารณะของเซิร์ฟเวอร์โตเกียวของคุณ (หรือชื่อโดเมนของ Tokyo ALB Load Equalizer) ID บันทึก: ตั้งชื่อที่เข้าใจได้เช่น Tokyo-Server

สร้างระเบียนที่สอง (ชี้ไปที่สหรัฐอเมริกา): ชื่อของบันทึกยังคงเหมือนเดิมและยังคงเป็น api.yourdomain.com กลยุทธ์การกำหนดเส้นทางยังเลือก "Latency" ภูมิภาค: คราวนี้ฉันเลือก us-1 (เวอร์จิเนีย) เป้าหมายการกำหนดเส้นทางมูลค่า/การรับส่งข้อมูล: กรอกชื่อโดเมน IP หรือ ALB ของเซิร์ฟเวอร์สหรัฐอเมริกา ID บันทึก: ชื่อ US-Server

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

ขั้นตอนที่สอง: Failover Routing-การประกันภัยสองเท่าสำหรับการจราจรทั่วโลก

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

เพื่อป้องกันภัยพิบัติระดับภูมิภาคนี้เราต้องกำหนดระดับบนพื้นฐานของการกำหนดเส้นทางที่ล่าช้า

เส้นทาง Failover (Failover)

。

ตรรกะของการกำหนดเส้นทางความผิดพลาดคือ

"ระบบกำจัดหลักและสำรอง"

(Active-Passive) มันจ้องไปที่เซิร์ฟเวอร์ของคุณผ่านการตรวจสุขภาพ (Health Check) ตราบใดที่เซิร์ฟเวอร์หลักเปิดเป็นสีแดงระบบจะตัดการรับส่งข้อมูลทันทีและตัดทั้งหมดไปยังเซิร์ฟเวอร์สำรอง

ปัญหาหลัก: จะรวมการกำหนดเส้นทางล่าช้าและการกำหนดเส้นทางเอกซ์เรย์ได้อย่างไร?

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

โซลูชันมาตรฐานของ Dachang คือ:

ใช้ "Traffic Flow" ของ Route 53เพื่อสร้างภาพผ้าใบหรือใช้วิธี "บันทึกซ้อนหลายชั้น"

。ที่นี่ฉันจะสอนวิธีที่เข้าใจง่ายที่สุดและไม่ใช้เงินผิด

วิธีการบันทึกซ้อนกัน

。

ขั้นตอนที่1: สร้างการตรวจสุขภาพสำหรับสองภูมิภาค

ในเมนูด้านซ้ายของ Route 53คลิก "Health Checks"-> "สร้างการตรวจสุขภาพ"

สร้าง Tokyo-Health เพื่อจ้องไปที่พอร์ตของเซิร์ฟเวอร์โตเกียว (เช่น80หรือ443) สร้าง US-Health อีกอันเพื่อจ้องไปที่เซิร์ฟเวอร์ของสหรัฐอเมริกาตั้งค่าการตรวจจับทุกๆ10วินาที

ขั้นตอนที่2: ประกอบลอจิกซ้อนขั้นสูง

เราต้องการสร้างตรรกะ:

"เราเตอร์ล่าช้า" ขั้นสูงสำหรับผู้ใช้ทั่วโลก

“

"เราเตอร์ล่าช้า" นำชาวเอเชียไปที่ "Tokyo Fault Checkpoint"

การตรวจสอบ "Tokyo Fault Checkpoint" พบว่าเซิร์ฟเวอร์ของโตเกียวยังมีชีวิตอยู่และได้รับการปล่อยตัวหากโตเกียวตายมันจะเปลี่ยนผู้คนไปยังดิสก์สำรองของสหรัฐอเมริกา (Secondary) โดยอัตโนมัติ

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

วิธีที่ง่ายและทันสมัยคือการใช้ Route 53โดยตรง

"นโยบายการจราจร"

อินเทอร์เฟซแบบกราฟิก:

คลิก "กลยุทธ์การเข้าชม"-> "สร้างกลยุทธ์การเข้าชม"

กฎชั้นแรก: เพิ่มกฎความล่าช้า (กฎ Latency)

ภายใต้สาขาความล่าช้าของโตเกียวอย่ากรอก IP โดยตรงแต่คลิกเพื่อเพิ่มกฎ Failover: หลัก: กรอกเซิร์ฟเวอร์โตเกียวและผูก Tokyo-Health รอง (Secondary): กรอกข้อมูลลงในเซิร์ฟเวอร์ของสหรัฐอเมริกา

ภายใต้สาขาความล่าช้าของสหรัฐอเมริกาจะมีการเพิ่มกฎ Failover: Primary: กรอกข้อมูลในเซิร์ฟเวอร์ของสหรัฐอเมริกาและผูก US-Health Secondary: กรอกข้อมูลลงในเซิร์ฟเวอร์โตเกียว

สถาปัตยกรรมที่ยอดเยี่ยมนี้อยู่ที่ไหน? โดยปกติทุกคนจะไปตามความล่าช้าเมื่อ Tokyo Region ล่มสลายกฎ Failover ของสาขาโตเกียวจะถูกเรียกใช้ทันทีโดยเปลี่ยนผู้ใช้ชาวเอเชียที่เดิมไปโตเกียวและบังคับให้เปลี่ยนเครื่องในสหรัฐอเมริกา

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

ขั้นตอนที่สาม: การตรวจสอบออนไลน์และการฝึกซ้อมในสถานที่จริง

หลังจากจับคู่โครงสร้างตุ๊กตาชุดนี้แล้วอย่าทิ้งมันไปที่นั่นโดยตรงเราต้องตรวจสอบว่ามันใช้งานได้จริงหรือไม่

1.ตรวจสอบความล่าช้าในการแยกอัจฉริยะ

ค้นหาเพื่อนสองสามคนจากภูมิภาคต่างๆหรือใช้เครื่องมือ Ping ระดับโลก (เช่น

Ping .pe

หรือ

Itdog

):

ให้โหนดในญี่ปุ่นหรือฮ่องกงไปที่ g api.yourdomain.com พินเพื่อดูว่า IP ที่ส่งคืนนั้นอยู่ในห้องคอมพิวเตอร์ของโตเกียวหรือไม่

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

2.จำลองการฝึกซ้อมภัยพิบัติ (ไฮไลต์)

เลือกตอนดึกที่มีคนไม่กี่คนมาทดสอบเส้นทางเอกซ์เรย์:

ลงชื่อเข้าใช้เซิร์ฟเวอร์โตเกียวหยุดบริการ Nginx หรือ Apache ด้วยตนเองหรือบล็อกพอร์ต80/443ในกลุ่มความปลอดภัยโดยตรงและเรียกใช้การตรวจสุขภาพล้มเหลว

จับตาดูคอนโซลการตรวจสุขภาพของ Route 53ประมาณ30วินาทีถึง1นาที Toky

แสงสีเขียวของ o-Health จะเปลี่ยนเป็นแสงสีแดง

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

หลังจากการฝึกซ้อมสิ้นสุดลงบริการในโตเกียวจะเริ่มต้นใหม่ทันทีหลังจากตรวจพบ Route 53ที่ฟื้นคืนชีพระบบจะรับการจราจรในเอเชียโดยอัตโนมัติและกระบวนการทั้งหมดจะราบรื่น

ขั้นตอนที่สี่: ต้นทุนและประวัติการหลีกเลี่ยงเลือดและน้ำตาภายใต้สถาปัตยกรรมโลก

ทางเลือกของ TTL (เวลาอยู่รอด): ความละเอียด DNS ถูกแคชเมื่อสร้างบันทึกการกำหนดเส้นทางขั้นสูงเหล่านี้ TTL จะต้องไม่ใหญ่เกินไป (ค่าเริ่มต้น300วินาทีหรือหลายชั่วโมงจะใช้ไม่ได้อย่างแน่นอน) แนะนำให้ตั้งค่า TTL มาตรฐานสำหรับการผันอัจฉริยะระดับองค์กรเป็น60วินาทีหากการตั้งค่ามีขนาดใหญ่เกินไปหลังจากเซิร์ฟเวอร์โตเกียวถูกวางสายแม้ว่าพื้นหลัง Route 53จะถูกตัดไปยังสหรัฐอเมริกาเบราว์เซอร์ของผู้ใช้ยังคงแคชที่อยู่เก่าและเวลาในการกู้คืนความล้มเหลว (RTO) จะขยายออกไปเรื่อยๆ

ค่าใช้จ่ายในการซิงโครไนซ์ของฐานข้อมูลมัลติแอคทีฟ: การแยกเครือข่ายฟรอนต์เอนด์และเลเยอร์การประมวลผลนั้นง่ายมากแต่อย่าลืมเลเยอร์ข้อมูลเนื่องจากเซิร์ฟเวอร์ทั้งสองสามารถรับลูกค้าได้จะซิงโครไนซ์ข้อมูลที่เขียนลงในฐานข้อมูลทั้งสองด้านได้อย่างไร? คุณต้องร่วมมือกับ Amazon Aurora Global Database (ฐานข้อมูลทั่วโลก) หรือเทคโนโลยีการจำลองแบบหลายต้นแบบมิฉะนั้นข้อมูลจะไม่ถูกต้องและไม่ว่าการแบ่งส่วนหน้าจะสวยงามเพียงใดก็เป็นปราสาทบนท้องฟ้า

ลูกคิดการเรียกเก็บเงิน: ค่าธรรมเนียมการวิเคราะห์พื้นฐานของ Route 53นั้นถูกมาก ($0.5ต่อเดือนสำหรับพื้นที่ดูแล) แต่กลยุทธ์การจราจรขั้นสูงและการวิเคราะห์ปริมาณที่เชื่อมโยงกับการตรวจสุขภาพจะคำนวณแยกกันอย่างไรก็ตามเมื่อเทียบกับความสูญเสียจำนวนมากที่เกิดจากการระงับธุรกิจทั่วโลกและการสูญเสียลูกค้าเนื่องจากการตัดการเชื่อมต่อของห้องคอมพิวเตอร์ค่าธรรมเนียมการกำหนดเส้นทางนี้แทบจะไม่สำคัญเลย

สรุป

การใช้ Amazon Route 53เพื่อเล่นกับการเข้าชมทั่วโลกหัวใจหลักอยู่ที่"

ใช้การกำหนดเส้นทางที่ล่าช้าเพื่อไล่ตามความเร็วสูงสุดใช้การกำหนดเส้นทางที่ผิดพลาดเพื่อรักษาบรรทัดล่างที่มีความพร้อมสูง

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