การวัดจริงของโหนดหลักสามโหนดของ AWS Asia Pacific: ฮ่องกงโตเกียวและสิงคโปร์จะเลือกธุรกิจในต่างประเทศได้อย่างไร?

ในขณะที่คลื่นของบริษัทจีนที่ไปต่างประเทศทวีความรุนแรงขึ้นไม่ว่าจะเป็นอีคอมเมิร์ซข้ามพรมแดนการเผยแพร่เกมบริการซอฟต์แวร์ SaaS หรือ Web3และเทคโนโลยีทางการเงิน

AWS(Amazon Web Services)

ยังคงเป็นหนึ่งในผู้ให้บริการระบบคลาวด์ที่ต้องการสำหรับการปรับใช้โครงสร้างพื้นฐาน

และในภูมิภาคเอเชียแปซิฟิก

ฮ่องกง (ap-east-1)

、

โตเกียว (ap-northeast-1)

และ

สิงคโปร์ (ap-southeast-1)

เป็น "โหนดสีทอง" ที่คลาสสิกที่สุดและเปรียบเทียบบ่อยที่สุดสามแห่ง

สถาปนิกหลายคนมักมีส่วนร่วมในการคัดเลือก:

ต้องการดูแลทั้งในประเทศและเอเชียตะวันออกเฉียงใต้ฮ่องกงหรือสิงคโปร์?

เกมไปญี่ปุ่นคุณภาพเครือข่ายสาธารณะของโหนดโตเกียวมีเสถียรภาพแค่ไหน?

ความแตกต่างระหว่างความล่าช้าในการเชื่อมต่อระหว่างภูมิภาคและปริมาณงานระหว่างโหนดหลักสามโหนดคืออะไร?

เพื่อให้ทีมเทคนิคมีการอ้างอิงการเลือกจริงและตรงตามวัตถุประสงค์เราใช้เครื่องมือต่างๆเช่น MTR, Iperf3, Sysbench เป็นต้นในการกำหนดค่าเดียวกัน (EC2

C6i .xlarge

ตัวอย่างขีดจำกัดแบนด์วิดท์10Gbps) โหนดหลักสามโหนดของ AWS ฮ่องกงโตเกียวและสิงคโปร์

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

การวัดความลึก

1.สภาพแวดล้อมการทดสอบและคำอธิบายวิธีการ

ตัวอย่างการทดสอบการกำหนดค่า: AWS EC2 c6i .xlarge(4vCPU / 8GB / Amazon Linux 2023)

แบนด์วิดท์เครือข่าย: แบนด์วิดท์ต่อเนื่องสูงสุด12.5 Gbps รับประกันแบนด์วิดท์พื้นฐาน

เครื่องมือทดสอบ: ping / mtr (การสูญเสียแพ็กเก็ตและการติดตามเส้นทาง), iperf3(TCP/UDP ทรูพุต), curl(HTTP เวลาตอบสนอง)

การกระจายตัวอย่างลูกค้า: ผู้ให้บริการรายใหญ่3รายในจีนแผ่นดินใหญ่ (Telecom CN2/163, China Unicom 9929/4837, Mobile CMI) ประเทศในเอเชียตะวันออกเฉียงใต้ที่สำคัญ (ผู้ให้บริการ Tier-1ในท้องถิ่นในอินโดนีเซียเวียดนามและไทย) ในเอเชียตะวันออก (ISP หลักในญี่ปุ่นและเกาหลีใต้)

2.ความล่าช้าของเครือข่ายสาธารณะและการวิเคราะห์ลิงก์การกำหนดเส้นทาง

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

การเปรียบเทียบความล่าช้าโดยเฉลี่ยและอัตราการสูญเสียแพ็คเก็ต

:

1.ตารางความล่าช้าของเครือข่ายสาธารณะจากแต่ละโหนดไปยังตลาดเป้าหมาย (หน่วย: ms)

พื้นที่เข้าถึงเป้าหมาย

โหนดฮ่องกง (ap-east-1)

โตเกียวโหนด (ap-northeast-1)

โหนดสิงคโปร์ (ap-southeast-1)

จีนตอนใต้ (กวางโจว/เซินเจิ้น)

12 - 25

60 - 75

40 - 55

จีนตะวันออก (เซี่ยงไฮ้/หางโจว)

35 - 50

35 - 45

65 - 80

จีนตอนเหนือ (ปักกิ่ง)

45 - 60

55 - 65

80-

95

ญี่ปุ่น (โตเกียว/โอซาก้า)

45 - 55

5 - 12

65 - 75

เกาหลีใต้ (โซล)

50 - 65

25 - 35

80 - 90

สิงคโปร์ท้องถิ่น

35 - 45

65 - 75

3 - 8

อินโดนีเซีย/เวียดนาม/ไทย

30 - 45

70 - 90

15 - 30

อเมริกาเหนือ (ลอสแองเจลิสตะวันตก)

150 - 160

100 - 110

170 - 180

2.การตีความลักษณะการกำหนดเส้นทางของโหนดหลักสามโหนด

🇭🇰โหนดฮ่องกง (

Ap-east-1

): ใกล้กับจีนแผ่นดินใหญ่มากที่สุดแต่กลยุทธ์การกำหนดเส้นทางมีความซับซ้อนมากขึ้น

ข้อดี: ความล่าช้าในการเยี่ยมชม AWS ของฮ่องกงในจีนตอนใต้ (กวางตุ้งฝูเจี้ยนฯลฯ) นั้นต่ำมากและเทียบได้กับการเยี่ยมชมระหว่างจังหวัดในประเทศ

ข้อเสีย: AWS HongKong ไม่ใช่ "สายการเชื่อมต่อโดยตรง" เมื่อการรับส่งข้อมูลเครือข่ายสาธารณะกลับไปยังประเทศจีนการสื่อสารโทรคมนาคมมักจะข้าม NTT หรือ Telstra ในขณะที่ China Unicom และ China Mobile ขึ้นอยู่กับลิงก์ส่งคืนที่เฉพาะเจาะจงในช่วงเวลาเร่งด่วนตอนเย็น (20:00-23:00น.) IP เครือข่ายสาธารณะทั่วไปจะพบกับระดับความแออัดและการสูญเสียแพ็กเก็ตที่แตกต่างกัน (ประมาณ3% ~ 8%)

คู่มือการหลีกเลี่ยงหลุม: หากผู้ใช้ธุรกิจหลักอยู่ในแผ่นดินใหญ่ขอแนะนำให้ใช้ AWS Global Accelerator(GA, Global Accelerator) หรือ CloudFront CDN ซึ่งสามารถลดทางอ้อมและการสูญเสียแพ็กเก็ตได้อย่างมาก

🇯🇵โหนดโตเกียว (

Ap-northeast-1

): East Asia Computing Center โครงสร้างพื้นฐานมีเสถียรภาพมาก

ข้อดี: โครงสร้างพื้นฐานเครือข่ายท้องถิ่นของญี่ปุ่นนั้นยอดเยี่ยมและความล่าช้าในการเชื่อมต่อระหว่างญี่ปุ่นเกาหลีใต้และชายฝั่งตะวันตกของอเมริกาเหนือ (สายเคเบิลออปติคอลใต้น้ำทรานส์แปซิฟิก) มีข้อได้เปรียบอย่างมาก

ผลการดำเนินงานของการกลับมาของจีนแผ่นดินใหญ่: จีนตะวันออก (เซี่ยงไฮ้) และจีนตอนเหนือ (ปักกิ่ง) เชื่อมต่อโดยตรงกับโตเกียวผ่าน China Telecom CN2หรือ China Unicom 4837ความล่าช้าโดยทั่วไปอยู่ที่35-50ms และอัตราการสูญเสียแพ็คเก็ตต่ำกว่าเครือข่ายสาธารณะทั่วไปในช่วงเย็นของฮ่องกงอย่างมีนัยสำคัญ

สถานการณ์ที่ใช้งานได้: สำหรับญี่ปุ่นเกาหลีใต้อเมริกาเหนือหรือธุรกิจที่ต้องคำนึงถึงผู้ใช้ในภาคเหนือของจีน

🇸🇬โหนดสิงคโปร์ (

Ap-southeast-1

): เอเชียตะวันออกเฉียงใต้ "ฮับดิจิทัล" ตลาดพื้นฐานในต่างประเทศ

ข้อดี: แผ่กระจายไปทั่วทั้งสิบประเทศในอาเซียน (TikTok, Shopee และแพลตฟอร์มอื่นๆในเอเชียตะวันออกเฉียงใต้) ความล่าช้าทางกายภาพของเครือข่ายที่เชื่อมต่ออินโดนีเซียมาเลเซียไทยเวียดนามและประเทศอื่นๆนั้นต่ำมาก

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

สถานการณ์ที่ใช้งานได้: ธุรกิจท้องถิ่นในเอเชียตะวันออกเฉียงใต้โหนดหน้าสำหรับการไปต่างประเทศในอินเดีย/ตะวันออกกลาง

3.การทดสอบเครือข่ายกระดูกสันหลังข้ามภูมิภาคภายใน AWS (VPC Peering)

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

AWS ระหว่างภูมิภาค (Inter-Region)

ประสิทธิภาพเครือข่ายกระดูกสันหลัง

กำหนดความเป็นไปได้ของสถาปัตยกรรมหลายภูมิภาค

เราได้สร้างอุโมงค์ที่ปลอดภัยผ่าน VPC Peering ข้ามภูมิภาคโดยใช้ Iperf3เพื่อทดสอบประสิทธิภาพการเชื่อมต่ออินทราเน็ตระหว่างสามโหนด:

------------------ เครือข่ายกระดูกสันหลังส่วนตัวข้ามภูมิภาค (VPC Peering) ------------------

| AWS ฮ่องกงโหนด | <===============================================> | AWS โตเกียวโหนด |

| (Ap-east-1) | RTT: ~ 48 ms | (ap-northeast-1) |

------------------ ------------------

^ ^

| | | | |

|| RTT: ~ 33 ms || RTT: ~ 66 ms

\/ \/

-----------------------------------------------------------------------------------------------

| AWS โหนดสิงคโปร์ |

| (Ap-southeast-1) |

------------------------------------

--------------------------------------------- +

ข้อมูลหลักที่วัดได้:

ฮ่องกง $ \ leftrightarrow $ สิงคโปร์: อินทราเน็ต RTT อยู่ที่ประมาณ32.5 ms และปริมาณงาน TCP single-flow สามารถรักษาได้อย่างเสถียรที่850 Mbps-1.2 Gbps โดยมีความผันผวนน้อยมาก

ฮ่องกง $ \ leftrightarrow $ Tokyo: อินทราเน็ต RTT อยู่ที่ประมาณ47.8 ms,TCP ประสิทธิภาพการรับส่งข้อมูลแบบสองทางนั้นยอดเยี่ยมและการกระวนกระวายใจล่าช้า (Jitter) น้อยกว่า0.5ms

โตเกียว $ \ leftrightarrow $ สิงคโปร์: อินทราเน็ต RTT อยู่ที่ประมาณ65.2 ms เนื่องจากระยะทางไกลสตรีม TCP เดียวจึงถูกจำกัดด้วยขนาดหน้าต่างได้ง่ายขอแนะนำให้เปิดอัลกอริธึมการควบคุมความแออัด TCP BBR ซึ่งสามารถเพิ่มปริมาณงานได้มากกว่า40%

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

4.การเลือกโครงสร้างการตัดสินใจ: เลือกฮ่องกงโตเกียวหรือสิงคโปร์?

นอกเหนือจากพารามิเตอร์ทางเทคนิคแล้วให้ยืน

เชื่อมโยงไปถึงธุรกิจ

จากมุมมองคุณสามารถเลือกตามตรรกะการตัดสินใจต่อไปนี้:

1.ฉาก [AWS HongKong] ที่ต้องการ:

ธุรกิจหลัก: อีคอมเมิร์ซข้ามพรมแดนเทคโนโลยีทางการเงิน Web3และเซิร์ฟเวอร์ API สำหรับบริษัทในต่างประเทศในจีนตอนใต้

ข้อกำหนดสำคัญ: ต้องมีความล่าช้าในการเข้าถึงจีนแผ่นดินใหญ่ต่ำมาก (โดยมีการกำหนดค่าการเร่งความเร็ว CDN/GA หรือสายเฉพาะ)

หมายเหตุ: ฮ่องกงเป็นส่วนหนึ่งของภูมิภาค Opt-in ของ AWS (ต้องเปิดด้วยตนเอง) และราคาต่อหน่วยบิล (เช่น EC2และ EBS) สูงกว่าโตเกียวและสิงคโปร์เล็กน้อย5% ~ 10%

2.[AWS Tokyo] ฉากที่ต้องการ:

ธุรกิจหลัก: การออกเกมมือถือในญี่ปุ่นและเกาหลีใต้แอปสองมิติ/ความบันเทิงสำหรับอเมริกาเหนือและเอเชียตะวันออกการซื้อขายความถี่สูง

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

หมายเหตุ: ในแง่ของการปฏิบัติตามกฎระเบียบญี่ปุ่นมีข้อกำหนดที่เข้มงวดเกี่ยวกับความเป็นส่วนตัวของข้อมูล (APPI Act) และต้องให้ความสำคัญกับนโยบายการออกข้อมูล

3.ฉาก [AWS Singapore] ที่ต้องการ:

ธุรกิจหลัก: อีคอมเมิร์ซท้องถิ่นในเอเชียตะวันออกเฉียงใต้, การถ่ายทอดสดความบันเทิง, เกมในต่างประเทศ (เซิร์ฟเวอร์สิงคโปร์/เอเชียตะวันออกเฉียงใต้), FinTech

ข้อกำหนดสำคัญ: AWS มีระบบนิเวศที่สมบูรณ์ที่สุดในสิงคโปร์ (เช่น Local Zones, Wavelength) และบริการ SaaS ของบุคคลที่สามมีการบูรณาการในระดับสูง

หมายเหตุ: ไม่เป็นมิตรกับผู้ใช้ในภาคเหนือของจีนและมีความล่าช้าสูง

5.คำแนะนำเชิงปฏิบัติ3ประการเพื่อเพิ่มประสิทธิภาพประสบการณ์เครือข่าย AWS Asia Pacific

ไม่ว่าคุณจะเลือกอันไหน

โหนดกลยุทธ์การเพิ่มประสิทธิภาพสถาปัตยกรรมสามประการต่อไปนี้สามารถ "เพิ่มประสิทธิภาพเครือข่ายของคุณเป็นสองเท่า":

เปิด TCP BBR:AWS โดยใช้อัลกอริทึม cubic สำหรับเคอร์เนล Linux เริ่มต้นภายใต้ท่อเพิ่มน้ำหนักที่มีเวลาแฝงสูงข้ามชาติ (LFN) อัลกอริธึมการควบคุมความแออัดของเคอร์เนลจะถูกแก้ไขเป็น bbr ซึ่งสามารถเพิ่มความเร็วในการส่ง TCP ทางไกลได้30% ~ 200%

ใช้ AWS Global Accelerator (GA): หากผู้ใช้ของคุณกระจายอยู่ทั่วเอเชียแปซิฟิก (เช่นทั้งจีนแผ่นดินใหญ่และเอเชียตะวันออกเฉียงใต้) คุณสามารถปรับใช้ GA ล่วงหน้าได้การรับส่งข้อมูลของผู้ใช้จะเข้าสู่เครือข่ายกระดูกสันหลังภายในของ AWS โดยตรงที่ AWS Edge Location ที่ใกล้ที่สุดหลีกเลี่ยงการสูญเสียแพ็กเก็ตและการกำหนดเส้นทางของเครือข่ายสาธารณะ

การใช้ CloudFront อย่างสมเหตุสมผลสำหรับการเร่งความเร็วแบบคงที่และแบบไดนามิก: CloudFront ไม่เพียงแต่สามารถแคชไฟล์แบบคงที่ได้เท่านั้นแต่กลไกการเร่งความเร็ว WebSocket / API แบบไดนามิก (โดยการรักษาการเชื่อมต่อที่ยาวนานจากโหนดขอบไปยังไซต์ต้นทาง) สามารถลดเวลาตอบสนอง p99ของ API ได้มากกว่า40%

สรุป

ในเกมของสามโหนดหลักของ AWS Asia Pacific:

ฮ่องกงชนะ "ใกล้แผ่นดินใหญ่" โตเกียวชนะ "การเชื่อมต่อคุณภาพสูงกับอเมริกาเหนือ" สิงคโปร์ชนะ "รังสีเอเชียตะวันออกเฉียงใต้"

。

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

สิงคโปร์เป็นศูนย์ข้อมูลหลัก (ฐานข้อมูลและธุรกิจหลัก)

, ซ้อนทับ

ฮ่องกง/โตเกียวขอบเร่งโหนด

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