Trực quan hóa độ trễ trung tâm dữ liệu AWS

 (benjdd.com)
3 điểm bởi GN⁺ 2024-10-25 | 2 bình luận | Chia sẻ qua WhatsApp
  • Đây là trang trực quan hóa hiển thị độ trễ giữa các trung tâm dữ liệu AWS theo 3 khoảng ms
  • Chú giải được chia thành dưới 100ms, 100~200ms và trên 200ms, giúp so sánh nhanh mức độ trễ
  • Chỉ với thông tin được cung cấp thì không thể xác định những trung tâm dữ liệu hay region nào được bao gồm
  • Không có thông tin về phương pháp đo, thời điểm đo hay các giá trị độ trễ riêng lẻ giữa các trung tâm dữ liệu
  • Vì vậy, phạm vi có thể xác nhận từ bản tóm tắt này chỉ giới hạn ở các ngưỡng phân loại của phần trực quan hóa

Chú giải độ trễ

  • X < 100ms: dưới 100ms
  • X 100ms - 200ms: 100ms~200ms
  • X > 200ms: trên 200ms

Chi tiết không thể xác nhận

  • Không có danh sách cụ thể các trung tâm dữ liệu AWS hay tên khu vực nào được cung cấp
  • Không thể xác nhận phương pháp đo, thời điểm đo hay giá trị độ trễ giữa từng cặp trung tâm dữ liệu riêng lẻ

Bài viết liên quan

2 bình luận

 
devenv 2024-10-25

Có vẻ us-east-1 là vị trí tốt nhất nếu hướng tới phương Tây.
 
GN⁺ 2024-10-25
Ý kiến trên Hacker News

  • Thay vì chỉ hiển thị giá trị ping, sẽ hay hơn nếu cũng cho thấy nó tệ hơn bao nhiêu so với giá trị tối ưu về mặt lý thuyết
    Theo tôi biết, tốc độ ánh sáng trong môi trường cáp quang chậm hơn ánh sáng trong chân không khoảng 30%
    Đã nhiều lần trong các cuộc họp kiến trúc có người phàn nàn về độ trễ giữa các trung tâm dữ liệu, nhưng sau đó nhìn lại thì hóa ra ngay từ đầu nó đã khá gần với giá trị khả dĩ về mặt lý thuyết

    • Trong nội bộ các hyperscaler và các nhà cung cấp colocation/hosting lớn, có lẽ họ đã nắm rất rõ các chỉ số như thế này
      Khi khách hàng thiết kế hệ thống tính sẵn sàng cao hoặc khôi phục thảm họa, điều quan trọng là tránh để họ vô tình chọn region hoặc zone có độ trễ “nhân tạo” quá lớn so với vùng chính
      Công ty hiện tại của tôi chuyên về chuyển SAP lên cloud, và kể từ sau khi từng bị ảnh hưởng bởi độ trễ không thể chấp nhận do các giả định sai trong quá khứ, chúng tôi luôn có cuộc trao đổi này với các chuyên gia mạng của AWS và GCP ở giai đoạn báo giá và xác định phạm vi
    • Cái này có vẻ không phải ping thực sự, và như vậy lại tốt hơn
      Thay vì ICMP ping, nó dùng cách mở kết nối socket stream qua tcp/443
      Ping có thể không phù hợp để làm chỉ số
      https://github.com/mda590/cloudping.co/blob/8918ee8d7e632765...
    • Muốn làm vậy thì phải lập bản đồ toàn bộ tuyến cáp
      Ánh sáng trong cáp quang di chuyển xấp xỉ 70% tốc độ ánh sáng, khoảng 210.000km/s
      Chu vi Trái Đất khoảng 40.000km, và tuyến thẳng sang phía đối diện Trái Đất sẽ vào khoảng 100ms một chiều, khoảng 200ms khứ hồi
    • Thử bấm trên bản đồ thì cũng không thấy nhiều trường hợp độ trễ lệch quá lớn so với khoảng cách
      Tất nhiên, nếu dùng cáp quang lõi rỗng và các tuyến cáp quang gần đường thẳng thì về lý thuyết có thể cải thiện thêm khoảng 40%, nhưng hiếm nơi nào muốn trả chi phí đó
    • Tôi là tác giả. Rất thú vị, và trên X cũng có người đề xuất cùng ý tưởng
      Tôi tò mò không biết có tài liệu tốt nào để tính chính xác giá trị này không

  • Tôi bị mù màu đỏ-lục nên khó, hoặc không thể, phân biệt đường dưới 100ms với đường trên 200ms
    Tình trạng này chiếm khoảng 8% dân số nam, nên sẽ tốt nếu thêm chế độ cho người mù màu
    Bản thân phần trực quan hóa thì rất tốt

    • Cách xử lý nhanh là áp CSS filter cho toàn trang
      Trong công cụ dành cho nhà phát triển, thêm quy tắc filter: hue-rotate(60deg); vào phần tử body, hoặc chạy javascript:void(document.body.style.filter='hue-rotate(60deg)') trên thanh địa chỉ là được
    • Tôi là tác giả. Cảm ơn góp ý
      Nếu có ví dụ nào từng giải quyết vấn đề này tốt nhất trong quá khứ, tôi muốn biết; nếu có link thì hãy chia sẻ
    • Tôi hoàn toàn không thấy các đường, chỉ thấy các chấm xanh biểu thị lặp lại các trung tâm dữ liệu
      Khá gây bối rối
    • Tôi tự hỏi có công cụ hỗ trợ tiếp cận nào cho mục đích như vậy không
      Kiểu một bộ lọc thay đổi màu toàn màn hình theo cách nhất định để có thể phân biệt được
    • Với tư cách người mù màu, việc cân nhắc người mù màu khi chọn màu là quan trọng, nhưng thực tế không phải toàn bộ 8% nam giới đều không phân biệt được hai màu đó
      Tỷ lệ đó thấp hơn, và ngay cả giữa những người mù màu thì cảm nhận màu sắc cũng khác nhau
      Việc một người nhìn rõ không có nghĩa là người khác cũng nhìn rõ, và ngược lại cũng vậy

  • Trước đây tôi từng lập kế hoạch liên quan đến việc này cho một khách hàng
    Khi đo độ trễ AWS, chỉ cần đo xấp xỉ chiều dài cáp biển theo km rồi chia cho 150 là kết quả khớp với độ trễ thực tế trong phạm vi 10%
    Không đến mức đáng kinh ngạc, nhưng rất nhất quán; sau này nhìn lại thì hình như con số là 155

    • Điều này làm tôi nhớ đến câu chuyện email 500 dặm
      https://www.ibiblio.org/harris/500milemail.html
    • Tôi nghĩ đây là do tốc độ ánh sáng trong môi trường truyền dẫn
      “Thông qua LabVIEW, tốc độ ánh sáng trong cáp quang được tính vào khoảng 2,054 x 10^8 m/s, một giá trị điển hình tương ứng với chiết suất n ≈ 1,4606”
      https://web.phys.ksu.edu/posters/2009/juma-Adv-Lab-S09.pdf
    • Trong việc mô hình hóa thế giới thực, có nhiều trường hợp bất ngờ là chỉ với phép nhân và phép cộng cũng đạt được độ chính xác thỏa đáng
    • Trang này được làm rất tốt dưới dạng bản đồ tương tác, và tôi xem rất thích
      Tôi tự hỏi lời giải thích toán học cho quy tắc kinh nghiệm đó có đại khái như sau không
      https://news.ycombinator.com/user?id=Hikikomori đã sửa tốc độ ánh sáng trong môi trường cáp quang từ 3e5 thành 2e5
      Tốc độ ánh sáng là 2e5km/s, tức khoảng 2e2km/ms, nên có dạng chiều dài(km) / 200(km/ms), và cuối cùng độ trễ(ms) ≈ K' × chiều dài(km)
      Tôi tò mò liệu ở đây K vào khoảng 1,3, K' là 1/155, và nó bao gồm các yếu tố như khoảng cách không theo đường thẳng, overhead mạng và switching, sai số đo khứ hồi hay không
    • Nhìn vào phần trực quan hóa, phần lớn, hoặc tất cả, các đường màu đỏ tương ứng với tuyến dài như từ Bắc Mỹ đến Nam Phi

  • Thú vị. Khi bấm vào vòng tròn màu xanh biểu thị trung tâm dữ liệu, độ trễ tới các trung tâm dữ liệu khác sẽ được hiển thị
    Tôi mất một lúc mới phát hiện ra điều này, nên sẽ tốt nếu trên trang có thêm hướng dẫn như bấm vào trung tâm dữ liệu để chọn

    • Nói một cách nghiêm ngặt, đây không phải là trung tâm dữ liệu mà là tổng hợp theo region
      Một region được tạo thành từ nhiều mức trừu tượng của các thành phần mạng và compute, tức là sự pha trộn giữa trung tâm dữ liệu, điểm triển khai edge, v.v.
      Ngay cả trong cùng một region, mức biến động giữa các zone cũng lớn, nên phương pháp đo là rất quan trọng

  • AWS cung cấp các số liệu độ trễ giữa các Region, giữa các Availability Zone và bên trong Availability Zone trong Network Manager
    Hữu ích để thiết lập đường cơ sở độ trễ và xem có vấn đề từ phía AWS hay không
    https://docs.aws.amazon.com/network-manager/latest/infrastru...

    • AWS cũng cung cấp dashboard hiển thị sự cố Region hoặc dịch vụ, nhưng nhìn lại quá khứ thì có thể thấy khó tin hoàn toàn vào những dashboard như vậy vì đúng lý do tương tự

  • Phần trực quan hóa và ý tưởng rất hay, nhưng sẽ tốt hơn nếu màu là gradient liên tục thay vì theo khoảng
    Cách hiện tại khiến 100ms trông tệ hơn 99ms rất nhiều, trong khi lại trông giống 200ms
    Ví dụ khi bấm vào us-east-1, độ trễ của các data center ở Tây Âu trông khá khác nhau: eu-central-1 và eu-south-1 chỉ chênh khoảng 9ms nhưng trông hoàn toàn khác, còn eu-north-1 và ap-south-1 chênh khoảng 88ms lại trông giống nhau
    Cũng có ý kiến đề xuất so sánh giá trị đo được với độ trễ tối thiểu khả dĩ so với tốc độ ánh sáng, nhưng vấn đề là tốc độ ánh sáng c trong chân không không phải là tốc độ truyền thông tin trong cáp quang
    Mức tốt nhất về mặt lý thuyết trong thực tế, chỉ xét tốc độ ánh sáng trong môi trường truyền, cũng khó vượt quá 70% của c, và còn nhiều yếu tố chưa biết như độ trễ của repeater

    • Tôi là tác giả. Gradient thực sự là một ý tưởng rất hay
      Trực quan hóa hiện tại khiến độ trễ 90ms trông như “tốt”, nhưng thực tế đó là giá trị hoàn toàn không chấp nhận được với nhiều ứng dụng
      Đặc biệt là trong trường hợp cần nhiều lượt round-trip để xử lý một request

  • Tôi tò mò không biết họ chọn đưa những data center nào vào bằng cách nào
    Ví dụ Tây Ban Nha, tức eu-south-2, bị thiếu
    Trước đây tôi từng làm một dự án yêu cầu độ trễ giữa các data center dưới 30ms, và phải dùng eu-west-1 Ireland cùng eu-south-2
    Nhưng độ trễ thực tế gần 42ms; lý do chính là không có cáp ngầm giữa Ireland và lục địa châu Âu, nên phải đi qua Anh rồi lại băng qua Anh để định tuyến sang cáp phía lục địa

    • Ở cuối trang có ghi là dữ liệu được scrape từ CloudPing, và cũng có link tới dataset của CloudPing
      Nếu vào CloudPing thì sẽ thấy dataset không có eu-south-2
    • Tôi là tác giả. Tôi chỉ dùng những gì có sẵn tại https://www.cloudping.co, và đúng là có một số nơi bị thiếu
      Kho GitHub của CloudPing đã 4 năm không có thay đổi code, nên có thể sau lần cuối còn được phát triển tích cực đã có thêm vài Region mới
    • Tôi tò mò làm sao bạn biết là không có cáp giữa Ireland và lục địa châu Âu
      Tôi thật sự muốn biết thông tin đó được công khai ở đâu
    • Bản đồ đó thiếu khá nhiều data center
    • Israel il-central-1 cũng bị thiếu

  • Dữ liệu rất hữu ích và quả địa cầu cũng ấn tượng về mặt thị giác, nhưng về mặt sử dụng thực tế thì bản đồ thế giới phẳng có lẽ sẽ tốt hơn
    Có thể hiển thị tất cả data center cùng lúc, và các đường cũng không bị quá sát nhau nên dễ đọc hơn

    • Tôi nhớ trong giới radio nghiệp dư, phép chiếu phương vị cách đều kiểu này khá phổ biến
      https://en.wikipedia.org/wiki/Azimuthal_equidistant_projecti...
    • Bản đồ thế giới 2D có thể không cho cảm giác các vị trí thực sự cách nhau bao xa
      Có tùy chọn chuyển đổi giữa hai kiểu thì tốt hơn
    • Đồng ý. Nhìn thì đẹp, nhưng không phải trực quan hóa tốt nhất để đọc dữ liệu thực tế
    • Tôi là tác giả. Cần cân bằng cẩn thận giữa đẹp mắt và hữu dụng

  • Yếu tố lớn nhất của độ trễ hiển nhiên là khoảng cách
    Nhưng ngay cả giữa các Region tương đối gần nhau, đôi khi không có cáp quang nối trực tiếp, nên độ trễ lại tệ, ví dụ như các tuyến đi qua vùng cực
    Tôi tò mò liệu có trường hợp Region nào vi phạm mạnh bất đẳng thức tam giác không
    Tức là độ trễ A–C tệ hơn nhiều so với độ trễ tối ưu A–B + B–C
    Chỉ vì tò mò, tôi cũng muốn biết liệu có thể dùng ý tưởng này để suy luận data center nào có khả năng cao được nối trực tiếp bằng cáp quang, rồi chỉ hiển thị các kết nối đó hay không

    • Tôi không thể nói trực tiếp về AWS, nhưng trong luận án tiến sĩ của mình, tôi đã tìm được khá nhiều trường hợp như vậy bằng cách dùng các probe RIPE Atlas
      Về cơ bản là tìm các cặp probe mà thời gian round-trip giữa probe A và C lớn hơn A–B + B–C
      Cách này có các vấn đề thông thường của việc đo ICMP/thời gian round-trip, và còn vấn đề là lưu lượng thực tế không được định tuyến “trung chuyển” qua probe kia, nhưng những cặp như vậy có tồn tại
      Có ví dụ ở trang 84 của https://theses.hal.science/tel-03666771/document, nếu bạn đọc được tiếng Pháp
    • Do cách định tuyến, tôi nghĩ điều này khó xảy ra ở quy mô lớn
      Nếu tuyến “vòng” qua B là tuyến rẻ nhất để gói ICMP tới đích, thì thực tế nó cũng sẽ chọn tuyến đó
      Có lẽ nếu tìm những nơi A–C gần bằng A–B + B–C thì sẽ thấy những điểm xảy ra chuyện đó
      Ngoài thiếu cáp quang, cũng có thể do lý do tài chính như các thỏa thuận peering có lợi hơn
    • Khu vực giữa Nga, Mông Cổ và Ấn Độ có rất ít cáp và chất lượng cũng không tốt
      Theo tôi biết, từ Mumbai đến miền nam Nga xét về khoảng cách thì không xa lắm, nhưng độ trễ lại cao đáng ngạc nhiên
      Ví dụ cao hơn nhiều so với từ Frankfurt đến Moscow, còn có vi phạm bất đẳng thức tam giác giữa Frankfurt–Moscow–Mumbai hay không thì tôi không rõ
    • Bản đồ cáp quang toàn cầu thì cứ xem ở đây là được
      https://www.submarinecablemap.com/
      Vì chi phí đặt cáp ngầm rất lớn, khả năng có cáp không được công khai là rất thấp
    • Có những Region khét tiếng vì chất lượng mạng kém như Nam Mỹ và Nam Á
      Nhìn chung tỷ lệ mất gói cũng cao hơn

  • Vài ngày trước tôi đang dùng cái này
    https://aws-latency-test.com/

    • Tôi là tác giả. Khi tìm dữ liệu để dùng cho trực quan hóa này, tôi đã thấy site đó, và nó khá ổn