Latency SLA & Fiber Path Engineering

Vì sao quan trọng trong production

Google công bố latency SLA cho từng region pair. Ví dụ:

• us-central1 → us-east1: <5ms p50
• us-central1 → eu-west1: <80ms p50
• us-central1 → asia-southeast1: <120ms p50

Những con số này không phải ngẫu nhiên — chúng kết quả từ fiber path engineering cẩn thận. Hiểu cách Google achieve chúng giúp bạn:

• Thiết kế realistic SLA cho application (không promise 10ms latency từ Europe)
• Predict latency trong multi-region deployments
• Debug latency issues khi thực tế chậm hơn SLA
• Optimize topology để meet latency requirements

Mô Hình Nội Bộ: Kỹ Thuật Đường Sợi

Cơ Sở Hạ Tầng Sợi Quang Vật Lý

Google sở hữu/hợp tác với nhà cung cấp sợi để xây dựng:

Sợi Lục Địa (xương Google):
├─ Bậc Mỹ: Đa tuyến qua Mỹ
│  ├─ Tuyến Bắc: Seattle → Chicago → New York
│  ├─ Tuyến Trung: Denver → Kansas City → DC
│  └─ Tuyến Nam: Los Angeles → Texas → Miami
│
├─ Đại Tây Dương: Đa hệ thống cáp
│  ├─ Bắc Đại Tây: Cáp A, Cáp B (đa dạng)
│  └─ Nam Đại Tây: Thay thế nếu Bắc sập
│
├─ Thái Bình Dương: Đa hệ thống cáp
│  ├─ Mỹ→Á: Qua Nhật, Đông Nam Á (đa tuyến)
│  └─ Nội Á: Singapore → Tokyo → Úc
│
└─ Nội Vùng: Lưới sợi dày đặc
   ├─ Kết nối tất cả vùng trong vùng
   └─ Độ trễ dưới một ms

Thành Phần Độ Trễ

Độ trễ tổng = truyền sợi + xử lý bộ định tuyến + tắc

Ví dụ: us-central1 (Iowa) → eu-west1 (Bỉ)

1. Truyền sợi (tốc độ ánh sáng)
   └─ Khoảng cách: ~6,500 km
   └─ Tốc độ sợi: ~200,000 km/s (2/3 tốc độ ánh sáng)
   └─ Tối thiểu: 6,500 / 200,000 = 32.5ms

2. Bước bộ định tuyến (xử lý)
   └─ Mỗi bước thêm: 0.1-1ms
   └─ Điển hình: 10-15 bước mỗi tuyến
   └─ Xử lý: 1-15ms

3. Xếp hàng (tắc)
   └─ Tải nhẹ: <1ms
   └─ Tải nặng: 5-20ms
   └─ Nổ: 50-100ms

Ước tính tổng:
└─ Tối thiểu (lý tưởng): 32.5ms
└─ Bình thường (tải nhẹ): 45-65ms
└─ Tải nặng: 65-100ms
└─ Đỉnh: >100ms (Kiểm soát Tắc kích hoạt)

SLA Google: <80ms p50 (bao gồm bình thường + tắc)

Định Tuyến Đa Tuyến (Dự Phòng + Hiệu Suất)

Tuyến us-central1 → eu-west1:

Tuyến A (Chính):
└─ Iowa → Chicago → New York → Cáp Đại Tây → London → Bỉ
   └─ 10 bước, ~80ms độ trễ

Tuyến B (Dự Phòng):
└─ Iowa → Denver → Los Angeles → Cáp Thái Bình (Mỹ-Á) 
   → Singapore → Kênh Suez → Châu Âu
   └─ 15 bước, ~150ms độ trễ (dài hơn)

Tuyến C (Phụ):
└─ Iowa → Chicago → Miami → Cáp Nam Đại Tây → Châu Âu
   └─ 12 bước, ~85ms độ trễ

Quyết định định tuyến:
├─ Bình thường: Dùng Tuyến A (ngắn nhất)
├─ Tuyến A suy giảm: Chuyển Tuyến C
├─ Sự kiện lớn: Dùng Tuyến B (dài nhưng có sẵn)
└─ Kết quả: Giữ <80ms p50 SLA

Production Architecture Patterns

Pattern 1: Database Replication with Latency Guarantees

Primary: us-central1 (Iowa)
└─ Main application tier

Sync replica: us-east1 (South Carolina)
├─ Distance: ~1,400 km
├─ Fiber path: via Chicago
├─ Latency SLA: <10ms p99
├─ Strategy: Synchronous replication (waits for confirmation)

Async replica: eu-west1 (Belgium)
├─ Distance: ~6,500 km
├─ Fiber path: transatlantic cable
├─ Latency: ~80ms p50 (ok for async)
├─ Strategy: Asynchronous, eventual consistency

Design decision:
├─ Sync replica in same region pair (<10ms) → strong consistency
├─ Async replica far away (>80ms) → high availability but eventual consistency
└─ Result: Meeting both low-latency and high-availability requirements

Pattern 2: Global Content Distribution (CDN Strategy)

Users worldwide requesting content:
├─ User in Tokyo
│  └─ Query: asia-southeast1 (Singapore) cache
│  └─ Latency: ~30ms (intra-Asia fiber)
│  └─ Miss: Fetch from us-central1
│     └─ Latency: ~120ms (trans-Pacific)
│
├─ User in São Paulo
│  └─ Query: regional cache (future)
│  └─ Miss: Fetch from us-central1
│     └─ Latency: ~80ms (transatlantic via southern route)
│
└─ User in London
   └─ Query: eu-west1 cache
   └─ Latency: ~5ms (intra-Europe fiber)
   └─ Miss: Fetch from us-central1
      └─ Latency: ~80ms (transatlantic cable)

Result: Cache hit = users get <30ms latency globally

Pattern 3: Anycast Traffic Engineering

Global anycast IP: 35.201.123.45 announced from all regions

User BGP routing:
├─ User in Tokyo sees: "35.201.123.45 via asia-southeast1 (AS path 2)"
├─ User in London sees: "35.201.123.45 via eu-west1 (AS path 2)"
└─ User in São Paulo sees: "35.201.123.45 via us-central1 (AS path 3)"

Result:
├─ User routed to nearest edge
├─ Latency: naturally optimized via BGP
├─ No geographic awareness needed in application
└─ SLA met automatically

Các Kịch Bản Lỗi Thực Tế

Kịch Bản 1: Cắt Cáp Dưới Nước (Đại Tây)

Sự kiện: Mỏ neo tàu cắt sợi Đại Tây

Triệu chứng:
├─ Tất cả traffic us-central1 ↔ eu-west1 độ trễ tăng
├─ Độ trễ: 80ms → 250ms (định tuyến lại qua Thái Bình)
├─ Mất gói: Tối thiểu (định tuyến lại trong ms)
├─ Kéo dài: ~24 giờ (tàu sửa chữa cáp tới)

Ảnh hưởng:
├─ SLA bị phá (80ms → 250ms > SLA)
├─ Hết thời gian app có thể
├─ Người dùng báo chậm

Giảm nhẹ:
├─ Định tuyến đa tuyến: Chính qua Đại Tây, phụ qua Thái Bình
├─ Dự phòng tự động: ECMP phát hiện chính sập, dùng phụ
├─ Kết quả: Độ trễ tăng nhưng trong phạm vi chấp nhận

Phục hồi:
├─ Nhóm sửa chữa: Có thể mất 24-48 giờ tới và sửa
├─ Tạm thời: Dùng dự phòng vệ tinh (đắt, hiếm triển khai)
└─ Dài hạn: Cài cáp dự phòng

Kịch Bản 2: Lỗi Phần Mềm Tạo Vòng Tuyến (Cấu Hình Sai BGP)

Triệu chứng:
├─ Cặp vùng cụ thể thấy tăng độ trễ 10 lần
├─ Ví dụ: us-central1 → asia-northeast1 (Tokyo)
├─ Bình thường: 100ms → Quan sát: 1000ms+

Nguyên nhân gốc:
└─ Cấu hình sai BGP: vòng định tuyến
   └─ Gói: us-central1 → mid1 → mid2 → quay lại us-central1
   └─ Vòng cho tới TTL hết (~128 bước)

Điều tra:
├─ traceroute hiển thị bước dôi (>20)
├─ tcpdump lộ gói quay vòng
├─ Nhật ký BGP hiển thị AS trùng trong tuyến

Sửa:
├─ Quay lại cấu hình BGP
├─ Áp dụng sửa: Lọc tuyến tự tham chiếu
├─ Phục hồi: Trong 30 phút
└─ SLA: Bị phá trong sự cố

Kịch Bản 3: Tắc Lúc DDoS (Độ Trễ Đỉnh)

Sự kiện: Tấn công DDoS nhắm vùng eu-west1

Triệu chứng:
├─ Độ trễ cục bộ eu-west1: Bình thường
├─ Tất cả traffic TỚI eu-west1: Độ trễ tăng
├─ us-central1 → eu-west1: 80ms → 200ms+

Nguyên nhân gốc:
└─ Traffic DDoS bão hóa cáp Đại Tây
   └─ Traffic hợp lệ chậm sau traffic tấn công
   └─ Không mất gói (traffic hình hoạ, không thả tại GCP)

Ảnh hưởng:
├─ Người dùng Mỹ dùng eu-west1: Chậm
├─ Người dùng Âu dùng eu-west1: Bình thường
├─ SLA bị phá cho kết nối qua Đại Tây

Giảm nhẹ:
├─ Lọc DDoS tại PoP: Lọc traffic tấn công sớm
├─ Kỹ Thuật Traffic: Định tuyến lại qua tuyến khác
├─ Kiểm soát nổ: Giới hạn để ngăn tầng

Giải quyết:
├─ Giảm DDoS: Giảm traffic tấn công
├─ Tăng dung lượng: Thêm dung lượng xương
└─ Phục hồi: Trong giờ khi tấn công giảm

Lỗi Thường Gặp & Phản Khuôn

Lỗi 1: Giả Định Độ Trễ Giống Tất Cả Cặp Vùng

❌ Suy sai:

"Tất cả vùng Google độ trễ giống nhau"

✅ Hiểu đúng:

• Độ trễ phụ thuộc khoảng cách và định tuyến sợi
• us-east1 ↔ us-west1: ~40ms
• us-central1 ↔ eu-west1: ~80ms
• us-central1 ↔ asia-northeast1: ~100ms+
• Phải kiểm tra SLA thực cho vùng

Phòng ngừa: Luôn xem bảng điều khiển độ trễ Google. Kiểm tra độ trễ thực trước triển khai.

Lỗi 2: Không Lập Kế Hoạch Đuôi Độ Trễ (p99)

❌ Suy sai:

"Độ trễ 80ms p50 có nghĩa trường hợp xấu là 100ms"

✅ Hiểu đúng:

• p50: 80ms trung bình
• p99: 150-200ms (2-3 lần trung bình)
• p99.9: 300-500ms (lúc đỉnh)
• Phải thiết kế cho p99, không p50

Phòng ngừa: Đặt giá trị hết thời gian dựa p99, không trung bình.

Lỗi 3: Bỏ Qua Tắc Lúc Cao Điểm

❌ Suy sai:

"SLA độ trễ đảm bảo độ trễ nhất quán cả ngày"

✅ Hiểu đúng:

• SLA cho điều kiện bình thường
• Traffic cao điểm tắc
• Độ trễ Black Friday / Năm Mới: Tăng vụt 2-3 lần
• Cần thiết kế với phép nổ

Phòng ngừa: Kiểm tra tải giờ cao điểm. Lập kế hoạch độ trễ 2 lần bình thường.

Hướng Dẫn Triển Khai Gốc GCP

Đo Độ Trễ Thực

# Giữa VM ở vùng khác
gcloud compute ssh vm-us-central1 --zone=us-central1-a

# Bên trong VM: ping VM đích ở eu-west1
ping vm-eu-west1-external-ip

# Đo p50/p99:
for i in {1..1000}; do ping -c 1 target-ip; done | tee ping-results.txt
# Phân tích: sắp xếp thời gian, tính phần trăm

# Tốt hơn: Dùng hping3 cho độ trễ TCP
hping3 -S -p 443 target-ip --fast
# Hiển thị độ trễ TCP SYN-ACK (bao gồm stack app)

Thiết Lập Đa Vùng Để Đảm Bảo Độ Trễ

# Vùng chính (độ trễ thấp người dùng)
gcloud compute instances create app-us-central1 \
  --zone=us-central1-a \
  --machine-type=e2-medium

# Vùng phụ (tính khả dụng cao, độ trễ chấp nhận)
gcloud compute instances create app-eu-west1 \
  --zone=europe-west1-b \
  --machine-type=e2-medium

# Tạo cân bằng tải toàn cầu (tự động dùng định tuyến độ trễ)
gcloud compute backend-services create global-backend \
  --global \
  --protocol=HTTPS \
  --health-checks=tcp-health-check

# Thêm phụ thuộc từ hai vùng
gcloud compute backend-services add-backends global-backend \
  --global \
  --instance-group=ig-us-central1 \
  --instance-group-zone=us-central1-a \
  --balancing-mode=RATE \
  --max-rate-per-instance=1000

gcloud compute backend-services add-backends global-backend \
  --global \
  --instance-group=ig-eu-west1 \
  --instance-group-zone=europe-west1-b \
  --balancing-mode=RATE \
  --max-rate-per-instance=1000

# Kết quả: Traffic tự động định tuyến tới vùng độ trễ thấp

Tài Liệu Tham Khảo

• Báo Cáo Độ Trễ Giữa Vùng — Đo độ trễ thời gian thực
• Chỉ Số Hiệu Suất Mạng GCP — Quy định độ trễ chính thức
• Các Thực Hành Hay Nhất Cân Bằng Tải Toàn Cầu — Kiến trúc đa vùng
• Kết Nối Đám Mây Cho Dung Lượng Đảm Bảo — Cho độ trễ quan trọng nhiệm vụ

---

Tiếp Theo: Định Tuyến Anycast Với Cân Bằng Tải Toàn Cầu — Cách traffic tự động tới vùng gần nhất