Skip to content

GCP Global Backbone: Premium vs Standard Tier

Vì sao quan trọng trong production

Sau khi traffic từ user vào PoP, câu hỏi tiếp theo: Cách nào traffic từ PoP đến application của bạn?

Premium Tier: Qua Google's private global fiber network (low latency, high reliability, high cost) Standard Tier: Qua public internet từ PoP đến region (higher latency, lower reliability, low cost)

Lựa chọn đúng tier có ảnh hưởng lớn trên:

  • Performance: 10-100ms difference
  • Reliability: 99.99% vs 99.9% SLA
  • Cost: 2-3x difference per GB

Production systems cần hiểu trade-off này để tối ưu hóa.

Internal Model: Premium vs Standard Routing

Bậc Cao: Xương Riêng Google

Người dùng (Bangkok)
│ (Internet công)
└─→ PoP-Singapore
    │ (Sợi riêng Google)
    └─→ Mạng Xương Google
        └─→ Kết nối tất cả trung tâm GCP
            └─→ App (us-central1)
                └─→ Phản hồi qua xương giống

Đặc tính:
├─ Đến: PoP gần người dùng (qua anycast BGP)
├─ Xương: Sợi riêng, sở hữu/vận hành Google
├─ Tuyến xương: Tối ưu độ trễ (tuyến ngắn)
├─ Dung lượng: Dung lượng riêng, không chia sẻ
├─ Định tuyến: Đa tuyến chi phí bằng (ECMP)
└─ SLA: 99.99% vùng Mỹ, 99.95% đa vùng

Bậc Tiêu Chuẩn: Định Tuyến Internet

Người dùng (Bangkok)
│ (Internet công tới PoP cụ thể vùng)
└─→ PoP-gần-us-central1 (có thể Ashburn PoP)
    │ (Internet công qua ISP)
    └─→ App (us-central1)
        │ (Internet công ra)
        └─→ Phản hồi qua tuyến ISP

Đặc tính:
├─ Đến: Traffic định tuyến đến vùng, không người dùng
├─ Tuyến: Internet công, tuỳ định tuyến ISP
├─ Dung lượng: Chia sẻ traffic internet khác
├─ Định tuyến: Tuyến một (không ECMP), dự phòng hạn
├─ Độ tin cây: Phụ thuộc chất lượng mạng ISP
└─ SLA: 99.9% vận hành (thấp hơn Cao)

So Sánh Cạnh Nhau

Khía cạnhBậc CaoBậc Tiêu Chuẩn
Chiến Lược Định TuyếnTâm người dùng (PoP gần)Tâm vùng (PoP gần phụ thuộc)
XươngSợi riêng GoogleInternet công qua ISP
Loại TuyếnĐa tuyến chi phí bằng (ECMP)Tuyến ưa thích một
Độ Trễ5-50ms (PoP tới vùng)20-150ms (độ trễ internet)
Mất Gói<0.01% SLATuỳ ISP (thường 0.1-1%)
Chi Phí mỗi GB$0.12/GB (cao)$0.04/GB (tiêu chuẩn)
Đa VùngHỗ trợ (LB toàn cầu)Chỉ vùng một
Cloud CDNHỗ trợKhông hỗ trợ

Ví Dụ Tuyến Mạng

Người dùng Tokyo dùng us-central1 (Cao):

ISP Tokyo (203.0.113.0/24)
    ↓ (Tuyến BGP ngắn nhất)
PoP-Tokyo (hoặc PoP-Singapore)
    ↓ (Sợi riêng Google, ~160ms)
Trung tâm us-central1
    ↓ (Xương GCP riêng)
App (VM ở Iowa)
    ↓ (Phản hồi theo tuyến)
Người dùng Tokyo

Người dùng Tokyo dùng us-central1 (Tiêu Chuẩn):

ISP Tokyo (203.0.113.0/24)
    ↓ (Qua định tuyến internet công)
PoP-Ashburn (gần us-central1)
    ↓ (Internet công Tokyo→Virginia, ~280ms)
Trung tâm us-central1
    ↓ (Internet công)
App (VM ở Iowa)

Kiến Trúc Sản Xuất Các Khuôn

Khuôn 1: SaaS Toàn Cầu (Khuyến Bậc Cao)

Triển khai: Cân bằng tải toàn cầu, phụ thuộc đa vùng
├─ Vùng 1: us-central1
├─ Vùng 2: eu-west1
├─ Vùng 3: asia-southeast1

└─ IP anycast toàn cầu (Bậc Cao):
   └─ Tokyo → PoP-Tokyo → Xương → asia-southeast1 (10ms)
   └─ London → PoP-London → Xương → eu-west1 (5ms)
   └─ São Paulo → PoP-São Paulo → Xương → us-central1 (50ms)

Lợi ích:
├─ Độ trễ: Tối ưu toàn cầu (5-50ms)
├─ Dự phòng: Vùng sập, traffic tới vùng tiếp
├─ Mở rộng: Phục vụ hàng triệu người dùng đồng thời

Chi phí: Bậc Cao = $0.12/GB (nhưng cần cho hiệu năng)

Khuôn 2: App Vùng (Bậc Tiêu Chuẩn Chấp Nhận)

Triển khai: Vùng một (us-central1), cân bằng tải vùng
└─ IP ngoài vùng (Bậc Tiêu Chuẩn):
   └─ Người dùng từ internet dùng định tuyến vùng
   └─ Độ trễ Châu Âu: ~150ms
   └─ Độ trễ Á: ~250ms

Chấp nhận vì:
├─ App không nhạy độ trễ (xử lý hàng loạt, báo cáo)
├─ Không có cơ sở người dùng toàn cầu (tập trung địa lý)
├─ Tiết kiệm chi phí: $0.04/GB vs $0.12/GB Cao

Yêu cầu:
└─ Tất cả phụ thuộc trong cùng vùng (ràng buộc Tiêu Chuẩn)

Khuôn 3: Lai Đa Vùng (Trộn Cao + Tiêu Chuẩn)

Tài nguyên Bậc Cao:
├─ Cân bằng tải App toàn cầu (chỉ Cao)
├─ Phụ thuộc đa vùng (có thể ở bất kỳ đâu)
└─ Chi phí: $0.12/GB

Tài nguyên Bậc Tiêu Chuẩn:
├─ Cân bằng tải App vùng (mỗi vùng, Tiêu Chuẩn)
├─ Phụ thuộc vùng một
└─ Chi phí: $0.04/GB

Chiến lược:
├─ Dùng ALB Toàn Cầu (Cao) cho tuyến nhạy độ trễ
├─ Dùng ALB Vùng (Tiêu Chuẩn) cho traffic bên trong
└─ Kết quả: Chi phí tối ưu, giữ SLA cho luồng quan trọng

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

Kịch Bản 1: Suy Giảm Tuyến ISP (Ảnh Hưởng Tiêu Chuẩn)

Triệu chứng: Người dùng ISP cụ thể báo kết nối chậm
├─ Độ trễ: 200ms → 800ms
├─ Mất gói: 0% → 3%
├─ Kéo dài: 30 phút

Nguyên nhân gốc: Thay đổi định tuyến ISP
└─ Tuyến ISP us-central1 → eu-west1 → us-central1 (tuyến xấu)
└─ Thay vì tuyến trực tiếp, traffic quay vòng

Ảnh hưởng:
├─ Bậc Cao: Không bị ảnh (xương Google định tuyến lại PoP khác)
├─ Bậc Tiêu Chuẩn: Bị ảnh nặng (kẹt tuyến xấu ISP)

Giải quyết:
├─ Cao: Tự động (dự phòng ECMP trong giây)
├─ Tiêu Chuẩn: Thủ công (liên hệ ISP, có thể mất giờ)

Kịch Bản 2: Tắc Xương Cao (Vào Lúc Cao Điểm)

Triệu chứng: Mọi người thấy độ trễ tăng vụt vào Black Friday
├─ Độ trễ: 30ms → 120ms toàn cầu
├─ Mất gói: Không
├─ Tất cả vùng ảnh hưởng cùng lúc

Nguyên nhân gốc: Overscripti xương
└─ Traffic đỉnh (cao 50% bình thường)
└─ Dung lượng xương Google căng
└─ Traffic hình hoạ/chậm tại bước

Ảnh hưởng:
├─ Người dùng Bậc Cao: Chậm nhưng chấp nhận (giữ SLA)
├─ Người dùng Bậc Tiêu Chuẩn: Tốt hơn (dùng vòng internet)

Kết quả:
└─ Google cấp dung lượng xương thêm
└─ Tạm thời: Dùng nổ Cloud NAT cho ra cao hơn
└─ Dài hạn: Lập kế hoạch dung lượng đỉnh

Kịch Bản 3: Tiêu Chuẩn Vô Tình Trên LB Toàn Cầu (Phản Khuôn)

Lỗi: Triển khai LB toàn cầu với cấu hình Tiêu Chuẩn vô tình
(Ghi chú: Điều này không thể — LB toàn cầu phải Cao, nhưng tương tự vùng)

Triệu chứng:
├─ Độ trễ: Biến thiên cao (50-300ms cùng ISP)
├─ Kiểm tra sức khỏe thất bại (hết thời gian dài)
├─ Một số vùng hoàn toàn không thể tiếp cận

Nguyên nhân gốc: Traffic định tuyến kém
└─ Định tuyến Tiêu Chuẩn kém cho đa vùng

Giải quyết:
├─ Di chuyển sang Bậc Cao
├─ Hoặc thiết kế lại vùng một với Tiêu Chuẩn (chấp nhận)

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

Lỗi 1: Dùng Tiêu Chuẩn Khi Cần LB Toàn Cầu

Suy sai:

"Tiêu Chuẩn rẻ, dùng cho tất cả"

Hiểu đúng:

  • LB Toàn Cầu cần Bậc Cao
  • Phụ thuộc đa vùng cần Bậc Cao
  • CDN Đám Mây cần Bậc Cao
  • Tiêu Chuẩn chỉ vùng một

Phòng ngừa: Bảng điều khiển GCP ngăn tạo LB trên Tiêu Chuẩn (cường thực tại API).

Lỗi 2: Không Lập Kế Hoạch Tắc Xương

Suy sai:

"Xương Google dung lượng vô hạn, không cần lập kế hoạch"

Hiểu đúng:

  • Dung lượng xương dùng chung tất cả người dùng Cao
  • Lúc cao điểm tắc tạm thời
  • Cần lập kế hoạch traffic nổ cẩn thận
  • Chia phép nổ NAT Đám Mây hạn

Phòng ngừa: Theo dõi xu hướng sử dụng xương. Lập kế hoạch dùm traffic trước.

Lỗi 3: Bỏ Qua Chi Phí Bậc Cao

Suy sai:

"Độ trễ là tất cả, dùng Cao cho mọi traffic"

Hiểu đúng:

  • Bậc Cao: $0.12/GB (3x Tiêu Chuẩn)
  • Dung lượng cao, chi phí có thể vượt chi phí tính toán
  • Nhiều app không cần độ trễ Cao
  • Tiêu Chuẩn đủ cho hầu hết tác vụ không tương tác

Phòng ngừa: Phân tích mô hình traffic. Dùng Tiêu Chuẩn nếu độ trễ không quan trọng.

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

Tạo Tài Nguyên Bậc Cao

bash
# Địa chỉ IP toàn cầu (luôn Cao)
gcloud compute addresses create global-ip \
  --global \
  --address-type=EXTERNAL

# Địa chỉ IP vùng (có thể Cao hoặc Tiêu Chuẩn)
gcloud compute addresses create premium-regional-ip \
  --region=us-central1 \
  --network-tier=premium \
  --address-type=EXTERNAL

# Tạo cân bằng tải toàn cầu (ngầm Cao)
gcloud compute target-https-proxies create global-https-proxy \
  --url-map=my-url-map \
  --ssl-certificates=my-cert

gcloud compute forwarding-rules create global-forwarding-rule \
  --global \
  --target-https-proxy=global-https-proxy \
  --address=global-ip \
  --ports=443

Theo Dõi Hiệu Suất Xương

bash
# Kiểm tra độ trễ giữa vùng (qua Bảng Hiệu Suất Mạng)
# URL: https://lookerstudio.google.com/c/u/0/reporting/fc733b10-9744-4a72-a502-92290f608571

# Hoặc truy vấn qua gcloud:
gcloud compute network-peering-routes list \
  --network=my-vpc \
  --format='value(dest_range,next_hop_gateway)'

# Theo dõi độ trễ qua vùng:
gcloud compute ssh vm-in-us-central1 --zone=us-central1-a
# Bên trong VM: ping vm-in-eu-west1 (đo RTT)

Ước Tính Chi Phí

bash
# Tiêu Chuẩn: $0.04/GB ra
# Bậc Cao: $0.12/GB ra

# Ví dụ: 100TB/tháng ra
# Tiêu Chuẩn: 100 * 1000 * $0.04 = $4,000
# Cao: 100 * 1000 * $0.12 = $12,000

# Tính toán ROI:
# Nếu cải thiện độ trễ tiết kiệm 2% chi phí hạ tầng
# Hòa vốn tại: chi phí Cao thêm < chi phí hạ tầng * 0.02

Tài Liệu Tham Khảo


Tiếp Theo: Độ Trễ SLA & Kỹ Thuật Đường Sợi — Cách Google đảm bảo độ trễ dự đoán được