การแสดงภาพเวลาแฝงของศูนย์ข้อมูล AWS
(benjdd.com)- เป็นหน้าการแสดงภาพที่แสดง เวลาแฝง ระหว่างศูนย์ข้อมูล AWS โดยแบ่งเป็น 3 ช่วง ms
- คำอธิบายสัญลักษณ์แบ่งเป็น ต่ำกว่า 100ms, 100~200ms และมากกว่า 200ms ทำให้เปรียบเทียบระดับความหน่วงได้อย่างรวดเร็ว
- จากข้อมูลที่ให้มาเพียงอย่างเดียว ไม่สามารถยืนยันได้ว่ามีศูนย์ข้อมูลหรือรีเจียนใดบ้างที่รวมอยู่
- ไม่มีการระบุวิธีการวัด ช่วงเวลาที่วัด หรือค่าความหน่วงรายคู่ระหว่างศูนย์ข้อมูล
- ดังนั้น ขอบเขตที่ยืนยันได้จากสรุปนี้จึงจำกัดอยู่ที่ เกณฑ์การแบ่งช่วง ของการแสดงภาพ
คำอธิบายสัญลักษณ์ของเวลาแฝง
- X < 100ms: ต่ำกว่า 100ms
- X 100ms - 200ms: 100ms~200ms
- X > 200ms: มากกว่า 200ms
รายละเอียดที่ไม่สามารถยืนยันได้
- ไม่มีการระบุรายการ ศูนย์ข้อมูล AWS หรือชื่อภูมิภาคอย่างเฉพาะเจาะจง
- ไม่สามารถยืนยันวิธีการวัด ช่วงเวลาที่วัด และค่าความหน่วงระหว่างศูนย์ข้อมูลแต่ละแห่งได้
2 ความคิดเห็น
ดูเหมือนว่า
us-east-1จะเป็นตำแหน่งที่ดีที่สุดสำหรับฝั่งตะวันตกนะความคิดเห็นใน Hacker News
แทนที่จะแสดงแค่ค่า ping อยากให้แสดงด้วยว่าแย่กว่า ค่าที่เหมาะสมที่สุดเชิงทฤษฎี มากแค่ไหน
เท่าที่รู้ ความเร็วของแสงในตัวกลางใยแก้วนำแสงช้ากว่าแสงในสุญญากาศประมาณ 30%
เคยมีหลายครั้งที่ในการประชุมสถาปัตยกรรมมีคนบ่นเรื่องเวลาแฝงระหว่างดาต้าเซ็นเตอร์ แต่ภายหลังพบว่าจริง ๆ แล้วมันค่อนข้างใกล้กับค่าที่เป็นไปได้ในทางทฤษฎีตั้งแต่แรก
เวลาลูกค้าออกแบบระบบ high availability หรือ disaster recovery สิ่งสำคัญคือไม่ให้เผลอเลือกรีเจียนหรือโซนหลักกับรีเจียน/โซนที่มีเวลาแฝงสูง “โดยจงใจ”
บริษัทปัจจุบันเชี่ยวชาญด้านการย้าย SAP ขึ้นคลาวด์ และหลังจากเคยเจอเวลาแฝงที่ยอมรับไม่ได้เพราะสมมติฐานผิด ๆ ในอดีต ตอนนี้เราจะต้องคุยเรื่องนี้กับผู้เชี่ยวชาญเครือข่ายของ AWS และ GCP ในขั้นตอนประเมินราคาและกำหนดขอบเขตงานเสมอ
เป็นวิธีเชื่อมต่อ socket stream ผ่าน tcp/443 ไม่ใช่ ICMP ping
ping อาจไม่เหมาะจะใช้เป็นตัวชี้วัด
https://github.com/mda590/cloudping.co/blob/8918ee8d7e632765...
แสงในสายใยแก้วนำแสงเดินทางที่ราว 70% ของความเร็วแสง หรือประมาณ 210,000km/s
เส้นรอบวงโลกประมาณ 40,000km และเส้นทางตรงไปยังอีกฟากหนึ่งของโลกจะอยู่ที่ประมาณ 100ms เที่ยวเดียว หรือประมาณ 200ms ไปกลับ
แน่นอนว่าในทางทฤษฎีถ้าใช้ ใยแก้วนำแสงแบบแกนกลวง และเส้นทางใยแก้วนำแสงที่ใกล้เป็นเส้นตรง ก็อาจปรับปรุงได้อีกประมาณ 40% แต่มีไม่กี่แห่งที่อยากจ่ายค่าใช้จ่ายนั้น
อยากรู้ว่ามีแหล่งข้อมูลดี ๆ สำหรับคำนวณค่านี้อย่างแม่นยำไหม
ผมเป็นตาบอดสีแดง-เขียว เลยแยกเส้น ต่ำกว่า 100ms กับเส้น เกิน 200ms ได้ยากหรือแทบเป็นไปไม่ได้
คิดเป็นประมาณ 8% ของประชากรชาย ถ้าเพิ่มโหมดสำหรับคนตาบอดสีน่าจะดี
ตัว visualization เองดีมาก
ใน Developer Tools ให้เพิ่มกฎ
filter: hue-rotate(60deg);ที่องค์ประกอบbodyหรือรันjavascript:void(document.body.style.filter='hue-rotate(60deg)')ในแถบที่อยู่ก็ได้ถ้ามีตัวอย่างที่ดีที่สุดที่เคยเห็นในการแก้ปัญหานี้ได้ดีในอดีต อยากรู้ และถ้ามีลิงก์ก็ช่วยแชร์ด้วย
ค่อนข้างสับสน
เช่นฟิลเตอร์ที่เปลี่ยนสีทั้งหน้าจอด้วยวิธีใดวิธีหนึ่งเพื่อให้แยกแยะได้
สัดส่วนนั้นต่ำกว่านั้น และแม้แต่ในหมู่คนตาบอดสี การรับรู้สีก็แตกต่างกัน
การที่คนหนึ่งมองเห็นชัดไม่ได้แปลว่าอีกคนจะเห็นชัดด้วย และในทางกลับกันก็เช่นกัน
ก่อนหน้านี้เคยวางแผนเรื่องที่เกี่ยวข้องให้ลูกค้ารายหนึ่ง
ระหว่างวัดเวลาแฝงของ AWS พอวัด ความยาวสายเคเบิลใต้น้ำ คร่าว ๆ เป็นกิโลเมตรแล้วหารด้วย 150 ก็ตรงกับเวลาแฝงจริงภายใน 10%
ไม่ถึงกับน่าตกใจ แต่สม่ำเสมอมาก และภายหลังเหมือนจะพบว่าค่าคือ 155
https://www.ibiblio.org/harris/500milemail.html
“ผ่าน LabVIEW คำนวณความเร็วของแสงในใยแก้วนำแสงได้ประมาณ 2.054 x 10^8 m/s ซึ่งเป็นค่าทั่วไปที่สอดคล้องกับดัชนีหักเห n ≈ 1.4606”
https://web.phys.ksu.edu/posters/2009/juma-Adv-Lab-S09.pdf
สงสัยว่าคำอธิบายทางคณิตศาสตร์ของ rule of thumb นั้นประมาณนี้หรือเปล่า
https://news.ycombinator.com/user?id=Hikikomori ช่วยแก้ความเร็วแสงในตัวกลางใยแก้วนำแสงว่าไม่ใช่ 3e5 แต่เป็น 2e5
ความเร็วแสงคือ 2e5km/s หรือประมาณ 2e2km/ms และจะอยู่ในรูป ความยาว(km) / 200(km/ms) สุดท้ายจึงได้เวลาแฝง(ms) ≈ K' × ความยาว(km)
ตรงนี้สงสัยว่า K อยู่ที่ประมาณ 1.3, K' คือ 1/155 และรวมปัจจัยอย่างระยะทางที่ไม่ใช่เส้นตรง, overhead และ switching ของเครือข่าย, ความคลาดเคลื่อนของการวัดแบบไปกลับไว้ด้วยหรือเปล่า
น่าสนใจ คลิกวงกลมสีน้ำเงินที่แทนดาต้าเซ็นเตอร์แล้วจะแสดงเวลาแฝงไปยังดาต้าเซ็นเตอร์อื่น ๆ
ผมใช้เวลาสักพักกว่าจะรู้ ดังนั้นถ้าเพิ่มคำแนะนำบนไซต์อย่าง คลิกดาต้าเซ็นเตอร์เพื่อเลือก ก็น่าจะดี
รีเจียนประกอบด้วยองค์ประกอบเครือข่ายและคอมพิวต์หลายระดับของ abstraction ปะปนกัน เช่น ดาต้าเซ็นเตอร์ จุดติดตั้ง edge เป็นต้น
แม้ภายในรีเจียนเอง แต่ละโซนก็มีความผันผวนมาก ดังนั้นระเบียบวิธีการวัดจึงสำคัญ
AWS ให้ตัวเลข latency ระหว่างรีเจียน ระหว่าง Availability Zone และภายใน Availability Zone ใน Network Manager
มีประโยชน์สำหรับตั้ง baseline ของ latency และดูว่ามีปัญหาฝั่ง AWS หรือไม่
https://docs.aws.amazon.com/network-manager/latest/infrastru...
การทำ visualization และแนวคิดนั้นเจ๋ง แต่ถ้าสีเป็น gradient ต่อเนื่องแทนที่จะเป็นแบบ แบ่งช่วง ก็น่าจะดี
วิธีปัจจุบันทำให้ 100ms ดูแย่กว่า 99ms มาก ทั้งที่ก็ดูเหมือนกับ 200ms
เช่น ถ้าคลิก us-east-1 ค่า latency ของดาต้าเซ็นเตอร์ในยุโรปตะวันตกจะดูต่างกันพอสมควร โดย eu-central-1 กับ eu-south-1 ต่างกันแค่ประมาณ 9ms แต่ดูต่างกันโดยสิ้นเชิง ส่วน eu-north-1 กับ ap-south-1 ต่างกันประมาณ 88ms แต่กลับดูเหมือนกัน
มีคนพูดถึงการเทียบค่าที่วัดได้กับ latency ต่ำสุดที่เป็นไปได้เมื่อเทียบกับความเร็วแสงด้วย แต่ปัญหาคือความเร็วแสงในสุญญากาศ c ไม่ใช่ความเร็วในการส่งข้อมูลภายในใยแก้วนำแสง
ค่าที่ดีที่สุดในเชิงทฤษฎีจริง ๆ แค่ดูความเร็วแสงในตัวกลางก็ยากจะเกิน 70% ของ c แล้ว และยังมีปัจจัยที่ไม่รู้แน่ชัดอีกมาก เช่น delay จาก repeater
visualization ปัจจุบันทำให้ latency 90ms ดูเหมือน “ดี” แต่ในความเป็นจริงเป็นค่าที่ยอมรับไม่ได้เลยสำหรับหลายแอปพลิเคชัน
โดยเฉพาะกรณีที่ต้อง round-trip หลายครั้งเพื่อประมวลผล request เดียว
อยากรู้ว่าเลือกอย่างไรว่าจะรวมดาต้าเซ็นเตอร์ใดบ้าง
ตัวอย่างเช่นสเปนซึ่งเป็น eu-south-2 ไม่ได้อยู่ในนั้น
ก่อนหน้านี้เคยทำโปรเจกต์ที่ latency ระหว่างดาต้าเซ็นเตอร์ต้องต่ำกว่า 30ms และต้องใช้ eu-west-1 ไอร์แลนด์กับ eu-south-2
แต่ latency จริงใกล้ 42ms และเหตุผลหลักคือไม่มีสายเคเบิลใต้ทะเลระหว่างไอร์แลนด์กับแผ่นดินใหญ่ยุโรป จึงต้อง routed ไปอังกฤษก่อน แล้วข้ามอังกฤษไปยังสายเคเบิลฝั่งแผ่นดินใหญ่
ถ้าเข้าไปดู CloudPing จะเห็นว่าใน dataset ไม่มี eu-south-2
repository GitHub ของ CloudPing ไม่มีการเปลี่ยนแปลงโค้ดมา 4 ปีแล้ว ดังนั้นอาจมีรีเจียนใหม่ ๆ หลายแห่งเกิดขึ้นหลังจากช่วงที่มีการพัฒนาครั้งล่าสุด
แค่อยากรู้จริง ๆ ว่ามีข้อมูลเผยแพร่ไว้ที่ไหน
ข้อมูลมีประโยชน์มากและลูกโลกก็ดูน่าประทับใจ แต่ในแง่การใช้งานจริง ผมคิดว่า แผนที่โลกแบบแบน น่าจะดีกว่า
น่าจะแสดงดาต้าเซ็นเตอร์ทั้งหมดได้ในครั้งเดียว และเส้นต่าง ๆ ก็ไม่เบียดกันจนอ่านยากเกินไป
https://en.wikipedia.org/wiki/Azimuthal_equidistant_projecti...
ถ้ามีตัวเลือกสลับระหว่างสองแบบน่าจะดีกว่า
ปัจจัยที่ใหญ่ที่สุดของ latency แน่นอนคือระยะทาง
แต่แม้แต่รีเจียนที่ค่อนข้างใกล้กัน บางครั้ง latency ก็แย่เพราะไม่มีใยแก้วนำแสงเชื่อมตรง เช่นเส้นทางที่ผ่านแถบขั้วโลก
อยากรู้ว่ามีตัวอย่างรีเจียนที่ละเมิด อสมการสามเหลี่ยม อย่างมากหรือไม่
กล่าวคือ latency A–C แย่กว่า latency A–B + B–C ที่ดีที่สุดมาก
แค่ด้วยความอยากรู้อยากเห็น ผมก็สงสัยว่าจะใช้ไอเดียนี้อนุมานได้ไหมว่าดาต้าเซ็นเตอร์ใดมีแนวโน้มสูงที่จะเชื่อมต่อกันโดยตรงด้วยใยแก้วนำแสง แล้วแสดงเฉพาะการเชื่อมต่อเหล่านั้น
โดยพื้นฐานคือหาคู่ probe ที่เวลาไป-กลับระหว่าง probe A กับ C มากกว่า A–B + B–C
วิธีนี้มีปัญหาทั่วไปของการวัด ICMP/เวลาไป-กลับ และมีปัญหาว่า traffic ไม่ได้ถูก route ผ่าน probe “ตัวกลาง” จริง ๆ แต่คู่แบบนั้นมีอยู่จริง
มีตัวอย่างในหน้า 84 ของ https://theses.hal.science/tel-03666771/document ถ้าอ่านภาษาฝรั่งเศสได้
ถ้าเส้นทาง “อ้อม” ผ่าน B เป็นเส้นทางที่ ICMP packet ไปถึงได้ถูกที่สุด จริง ๆ แล้วก็น่าจะเลือกเส้นทางนั้น
กลับกัน ถ้าลองหาจุดที่ A–C เกือบเท่ากับ A–B + B–C ก็น่าจะเห็นจุดที่เกิดเรื่องแบบนั้นได้
นอกจากการขาดใยแก้วนำแสงแล้ว ยังอาจเกิดจากเหตุผลทางการเงิน เช่นสัญญา peering ที่ได้เปรียบกว่า
เท่าที่ผมรู้ จากมุมไบไปทางตอนใต้ของรัสเซีย ระยะทางไม่ได้ไกลมากนัก แต่ latency สูงจนน่าประหลาดใจ
ตัวอย่างเช่นสูงกว่าจากแฟรงก์เฟิร์ตไปมอสโกมาก และผมไม่แน่ใจว่าถึงขั้นละเมิดอสมการสามเหลี่ยมระหว่างแฟรงก์เฟิร์ต–มอสโก–มุมไบหรือไม่
https://www.submarinecablemap.com/
เนื่องจากต้นทุนการวางสายเคเบิลใต้ทะเลสูงมาก โอกาสที่จะมีสายเคเบิลที่ไม่เปิดเผยต่อสาธารณะจึงต่ำมาก
โดยรวมแล้ว packet loss ก็มักจะสูงกว่าด้วย
ไม่กี่วันก่อนผมกำลังใช้สิ่งนี้อยู่
https://aws-latency-test.com/