GCP Edge Mạng & PoP (Điểm Có Mặt)

Tại sao quan trọng trong sản xuất

Người dùng internet ở Hà Nội kết nối tới app của bạn ở GCP. Câu hỏi: Traffic của người dùng vào GCP thế nào?

Câu trả lời: Qua PoP (Điểm Có Mặt) — các nút edge Google giữ khắp thế giới để:

1. Kết thúc SSL/TLS gần người dùng (tiết kiệm độ trễ)
2. Tiếp nhận traffic từ ISP người dùng
3. Định tuyến traffic vào mạng GCP cốt lõi
4. Dự trữ phản hồi (cho khách CDN đám mây)

Hiểu chiến lược PoP giúp bạn:

• Dự báo độ trễ từ địa lý cụ thể
• Tối ưu cân bằng tải toàn cầu
• Gỡ rối "người dùng vùng X chậm"
• Thiết kế phục hồi khẩn cấp (PoP thay thế)

Mô hình nội bộ: Kiến trúc PoP

Bậc PoP

┌──────────────────────────────────────┐
│      Xương sống Internet              │
│  (ISP, Nhà cung cấp Truyền tải)      │
└────────────────────────────────────┬─┘
                    │
         ┌──────────┴──────────┐
         │                    │
    ┌────▼─────┐         ┌────▼─────┐
    │ PoP      │         │ PoP       │
    │(Đông TĐN)│         │(Tây EU)   │
    └────┬─────┘         └────┬─────┘
         │                    │
         └────────┬───────────┘
                  │
         ┌────────▼─────────┐
         │ Xương sống toàn  │
         │ cầu GCP          │
         │ (Sợi quang riêng)│
         └────────┬─────────┘
                  │
    ┌─────────────┼─────────────┐
    │             │             │
┌───▼───┐    ┌───▼───┐    ┌───▼───┐
│ Vùng  │    │ Vùng  │    │ Vùng  │
│US-C1  │    │EU-W1  │    │AP-SE1 │
└───────┘    └───────┘    └───────┘

PoP là Điểm Hội Tụ Traffic

Một PoP có thể phục vụ traffic từ nhiều ISP/nhà cung cấp:

PoP: Ashburn (Bắc Virginia)
├─ ISP thượng #1: Verizon, Level 3
├─ ISP thượng #2: AT&T, CenturyLink
├─ ISP thượng #3: Cogent, Điện Sét
│
└─ Ghép nối: Kết nối trực tiếp với nhà cung cấp lớn

Tại sao nhiều thượng?

• Dự phòng: Nếu ISP sập, traffic vẫn tới PoP
• Dung lượng: Mỗi ISP có thể đóng góp băng
• Chi phí: Ghép nối trực tiếp với nhà cung cấp lớn = tuyến ưa
• Hiệu suất: Tuyến đa dạng tới internet đảm bảo độ trễ thấp

Tuyến Traffic: Người dùng Internet → PoP → GCP

1. Trình duyệt (Hong Kong, 223.26.0.0/16)
   └─ Truy vấn DNS: "myapp.com ở đâu?"
   └─ Phản: "IP Anycast 35.201.123.45" (IP công của Google)

2. Người dùng → PoP gần nhất (Tuyến Anycast qua BGP)
   ├─ Bảng tuyến ISP (học qua BGP):
   │  └─ 35.201.123.45/32 → PoP-Hong Kong (chi tiết)
   │  └─ 35.0.0.0/8 → PoP-Singapore (kém chi tiết)
   │  └─ 0.0.0.0/0 → thượng mặc định
   ├─ Gói tin tới PoP-Hong Kong (tuyến AS ngắn)

3. PoP nhận traffic đến
   ├─ GFE (Đầu Trước Toàn Cầu) kết thúc SSL/TLS
   ├─ Giải mã luồng HTTP/2
   └─ Chuyển tiếp tới app qua xương GCP

4. Xương GCP mang traffic tới vùng
   └─ Liên kết sợi quang từ PoP tới vùng

5. Trung tâm dữ liệu (ví dụ, us-central1)
   ├─ Bộ định tuyến nhập nhận
   ├─ Tuyến tới app (VM/LB/App)
   └─ Trả phản hồi cùng tuyến (hoặc PoP ra khác)

Insight chính: Traffic từ người dùng tới PoP dùng internet công (mạng ISP), nhưng traffic từ PoP tới trung tâm dùng sợi riêng Google.

Chiến Lược Phân Bố PoP

Google triển khai PoP không chỉ ở các trung tâm ISP, mà chiến lược:

PoP Lớn (Bậc 1):
├─ Ashburn, Mỹ (trung tâm Mỹ lớn)
├─ London, UK (trung tâm EU lớn)
├─ Singapore (trung tâm Á lớn)
├─ Tokyo, Nhật (trung tâm Á lớn)
├─ Sydney, Úc

PoP Vùng (Bậc 2):
├─ Bangkok, Manila, Jakarta (Đông Nam Á)
├─ Dubai (Trung Đông, Phi Châu)
├─ Johannesburg (Phi Châu)
├─ São Paulo (Nam Mỹ)

PoP Edge (Bậc 3):
├─ Triển khai qua hợp tác ISP/CDN
├─ Cơ sở hạ tầng dùng chung với nút CDN
├─ Ưu tiên bao phủ địa lý hơn dung lượng

Chiến lược: Traffic của người dùng phải tới PoP trong <10ms, sau đó xương mang tới vùng đích.

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

Khuôn 1: Cân Bằng Tải Anycast Toàn Cầu

Triển khai app:
├─ Triển khai A: us-central1 (app + LB)
├─ Triển khai B: eu-west1 (app + LB)
├─ Triển khai C: asia-southeast1 (app + LB)
│
└─ IP Anycast toàn cầu: 35.201.123.45 (công bố từ 3 vùng)

Định tuyến traffic:
├─ Người dùng Mỹ → BGP thấy 35.201.123.45 từ us-central1 (khoảng AS nhỏ)
│  └─ PoP-Ashburn → xương GCP → Trung tâm US-C1
│
├─ Người dùng EU → BGP thấy 35.201.123.45 từ eu-west1
│  └─ PoP-London → xương GCP → Trung tâm EU-W1
│
└─ Người dùng Á → BGP thấy 35.201.123.45 từ asia-southeast1
   └─ PoP-Singapore → xương GCP → Trung tâm AP-SE1

Kết quả: Traffic tự động định tuyến địa lý tới có mặt Google gần nhất

Khuôn 2: Chiến Lược PoP Bậc Cao vs Tiêu Chuẩn

Bậc Cao (Hiệu Suất Cao):
├─ Đến: Traffic vào PoP gần người dùng nhất
├─ PoP: Triển khai ở nhiều chỗ (200+)
├─ Định tuyến: Tối ưu, tuyến ngắn nhất tới đích
└─ Ví dụ: Người dùng Bangkok
   └─ Có thể vào PoP-Bangkok hoặc PoP-Singapore (gần)

Bậc Tiêu Chuẩn (Chi Phí Tối Ưu):
├─ Đến: Traffic vào PoP gần vùng đích nhất
├─ PoP: Ít hơn, chỉ gần các vùng lớn
├─ Định tuyến: Trực tiếp tới vùng phụ thuộc
└─ Ví dụ: Người dùng Bangkok dùng us-central1
   └─ Traffic vào PoP-Ashburn (gần đích)
   └─ Dùng internet công từ Bangkok tới Ashburn
   └─ Rồi xương GCP riêng tới us-central1
   
Kết quả: Bậc Tiêu Chuẩn độ trễ cao hơn nhưng rẻ (tuyến công rẻ hơn xương)

Khuôn 3: Dự Phòng Qua PoP Thay Thế

Bình thường: Người dùng → PoP-A → Trung tâm-1
┌─────────────────────────┐
│ Người dùng (mạng ISP)   │
└──────────┬──────────────┘
           │
    ┌──────▼──────┐
    │ PoP-A       │
    │ (chính)     │
    └──────┬──────┘
           │
    ┌──────▼──────────────┐
    │ Xương GCP           │
    └──────┬──────────────┘
           │
    ┌──────▼──────────┐
    │ Trung tâm-1     │
    │ (xử lý)         │
    └─────────────────┘

Lỗi: PoP-A sập hoặc tải quá
┌─────────────────────────┐
│ Người dùng (mạng ISP)   │
└──────────┬──────────────┘
           │ (BGP hội tụ)
    ┌──────▼──────┐
    │ PoP-B       │
    │ (dự phòng)  │
    └──────┬──────┘
           │
    ┌──────▼──────────────┐
    │ Xương GCP           │
    └──────┬──────────────┘
           │
    ┌──────▼──────────┐
    │ Trung tâm-1     │
    │ (xử lý)         │
    └─────────────────┘

Phục hồi: Tự động qua dự phòng BGP (giây)

Khuôn 4: Giảm DDoS Tại PoP

Tấn công: 100Gbps traffic nhắm app
┌──────────────────────────┐
│ Kẻ tấn công (mạng Bot)   │
└──────────┬───────────────┘
           │ (100Gbps tấn công)
    ┌──────▼──────┐
    │ PoP-X       │
    │ Lọc         │
    │ (Giảm DDoS)
    └──────┬──────┘
           │ (Sau lọc: 5Gbps traffic hợp lệ)
    ┌──────▼──────────────┐
    │ Xương GCP           │
    │ (bảo vệ)            │
    └──────┬──────────────┘
           │
    ┌──────▼──────────┐
    │ Trung tâm       │
    │ (không bị ảnh)  │
    └─────────────────┘

Kết quả: Bảo vệ DDoS Google tại PoP ngăn bão hóa phụ thuộc

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

Kịch Bản 1: Mất Gói Tại PoP (Tắc ISP Thượng)

Triệu chứng:
├─ Người dùng vùng cụ thể báo mất gói (3-5%)
├─ Độ trễ: Bình thường
├─ Mô hình vùng: Chỉ từ vùng Nam Mỹ

Nguyên nhân gốc:
└─ PoP-São Paulo thấy tắc ISP
   └─ Giờ cao điểm, mạng ISP thả 1% gói
   └─ Một số người dùng gửi lại → dường như chậm
   └─ Nhưng xương tốt

Điều tra:
├─ Kiểm tra bản ghi CDN/LB: Thấy mô hình địa lý
├─ Phương sai RTT cao tại PoP-São Paulo
├─ Làm việc với nhóm Mạng Google tăng dung lượng PoP
│  (thêm sợi vào PoP São Paulo, thêm PoP ở Nam Mỹ)

Phòng ngừa:
└─ Chiến lược đa PoP: Định tuyến traffic tới PoP dự phòng nếu chính tắc

Kịch Bản 2: Cắt Sợi PoP (Mất Kết Nối Xương)

Triệu chứng:
├─ Người dùng toàn vùng Á: Lỗi (hết thời gian kết nối)
├─ Độ trễ: Rất cao hoặc kết nối bị từ chối
├─ Tất cả vùng bị ảnh hưởng cùng lúc

Nguyên nhân gốc:
└─ Cắt sợi giữa PoP-Singapore và Trung tâm
   └─ Tuyến chính gãy
   └─ Dự phòng tuyến phụ (qua xương Mỹ)
   └─ Độ trễ: 200ms → 400ms (quá chậm cho tác vụ đồng bộ)

Điều tra:
├─ Nhóm Mạng: "Cắt sợi phát hiện tại dấu UTC+8"
├─ Kiểm tra tuyến dự phòng hoạt động
├─ Hỏi người dùng bị ảnh hưởng (tất cả từ Đông Nam Á)

Phục hồi:
├─ Khẩn cấp: Traffic tới phụ thuộc Mỹ, độ trễ cao nhưng có sẵn
├─ Sửa chữa: Sợi định tuyến lại (có thể mất giờ)
├─ Triển khai: Thêm dự phòng cục bộ (bản sao app ở Á)

Phòng ngừa:
└─ Tuyến xương đa dạng giữa PoP và trung tâm
   └─ Dự phòng sợi kép/ba
   └─ Triển khai đa vùng (không phụ thuộc tuyến một)

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

Lỗi 1: Giả Định Traffic Luôn Chọn Tuyến Ngắn

❌ Suy sai:

"Người dùng Bangkok dùng vùng Mỹ: Traffic qua PoP gần nhất (Singapore)"

✅ Hiểu đúng:

• Định tuyến phụ thuộc quảng cáo BGP
• Bậc Cao: Tuyến tối ưu (có thể Singapore)
• Bậc Tiêu Chuẩn: Tuyến qua định tuyến ISP (có thể PoP Mỹ trước)
• BGP động: Có thể thay đổi theo thỏa thuận peer thượng

Phòng ngừa: Kiểm tra tuyến thực tế dùng traceroute từ địa lý khác. Theo dõi xu hướng độ trễ.

Lỗi 2: Không Lập Kế Hoạch Dung Lượng PoP

❌ Suy sai:

"PoP có dung lượng không hạn chế cho traffic đến"

✅ Hiểu đúng:

• Mỗi PoP có dung lượng tuyến hạn (thường 100-400Gbps)
• Traffic đỉnh có thể cạn dung lượng
• Tràn cần dự phòng PoP phụ
• Lập kế hoạch dung lượng: ước tính traffic đỉnh cặp vùng

Phòng ngừa: Liên hệ Google lấy thông tin dung lượng PoP. Lập kế hoạch giới hạn hợp lý.

Lỗi 3: Bỏ Qua Độ Trễ PoP Trong SLA

❌ Suy sai:

"SLA độ trễ GCP chỉ quan trọng trong trung tâm, không PoP-tới-PoP"

✅ Hiểu đúng:

• Độ trễ đầu cuối gồm: người dùng→PoP + PoP→trung tâm
• Độ trễ PoP: 10-50ms tùy khoảng cách
• Độ trễ trung tâm: <1ms
• Tổng: Thường độ trễ PoP chiếm ưu thế

Phòng ngừa: Chia độ trễ: đo người dùng→PoP riêng dùng RUM (Theo Dõi Người Dùng Thực).

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

Xác Nhận Nhập PoP

# Cân bằng tải HTTP(S) toàn cầu tự động dùng anycast tới PoP
gcloud compute backend-services create my-backend \
  --global \
  --protocol=HTTPS \
  --health-checks=http-health-check

gcloud compute url-maps create my-url-map \
  --default-service=my-backend

gcloud compute target-https-proxies create my-https-proxy \
  --url-map=my-url-map \
  --ssl-certificates=my-cert

gcloud compute forwarding-rules create my-forwarding-rule \
  --global \
  --target-https-proxy=my-https-proxy \
  --address=my-global-static-ip

# Kết quả: IP anycast toàn cầu công bố từ tất cả vùng
# Người dùng tự động định tuyến tới PoP gần nhất

Theo Dõi Hiệu Suất PoP

# Dùng Báo Cáo Độ Trễ Mạng xem độ trễ cấp PoP
# Có sẵn tại: Google Cloud Bảng điều khiển → Mạng → Báo Cáo Độ Trễ Mạng

# Hoặc truy vấn qua API:
gcloud compute network-peering-routes list --network=my-vpc

# Kiểm tra độ trễ PoP cụ thể dùng traceroute từ VM trong vùng:
# SSH tới VM ở asia-southeast1:
gcloud compute ssh vm-in-asia --zone=asia-southeast1-a

# Bên trong VM:
traceroute -m 30 my-backend-ip
# Tìm bước đi qua mạng GCP riêng

Triển Khai Bậc Cao vs Tiêu Chuẩn

# Tạo IP Vùng (có thể là Bậc Tiêu Chuẩn)
gcloud compute addresses create regional-ip \
  --region=us-central1 \
  --network-tier=standard

# Tạo IP Toàn Cầu (phải là Bậc Cao)
gcloud compute addresses create global-ip \
  --global \
  --network-tier=premium

# Bậc Tiêu Chuẩn giới hạn cân bằng tải vùng
gcloud compute forwarding-rules create standard-forwarding-rule \
  --region=us-central1 \
  --address=regional-ip \
  --target-http-proxy=regional-proxy

# Bậc Cao kích hoạt cân bằng tải toàn cầu
gcloud compute forwarding-rules create premium-forwarding-rule \
  --global \
  --address=global-ip \
  --target-https-proxy=global-https-proxy

Tài Liệu Tham Khảo

• Kiến Trúc Cân Bằng Tải Toàn Cầu GCP — Cách traffic vào qua PoP
• Tài Liệu Định Tuyến Bậc Dịch Vụ Mạng — Chiến lược PoP Bậc Cao vs Tiêu Chuẩn
• Bảng Điều Khiển Hiệu Suất Mạng Google Cloud — Theo dõi độ trễ PoP
• Kiến Trúc CDN Đám Mây — Dự trữ dựa PoP
• Các Thực Hành Hay Nhất Cân Bằng Tải Toàn Cầu — Dự phòng đa vùng qua PoP

---

Tiếp Theo: Xương Toàn Cầu GCP: Bậc Cao vs Tiêu Chuẩn — Sau khi traffic vào PoP, nó tới trung tâm của bạn như thế nào?