Anycast Routing with Global Load Balancer

Vì sao quan trọng trong production

Anycast là kỹ thuật cho phép single IP address serve từ multiple locations. Global Load Balancer trong GCP sử dụng anycast để:

Announce cùng IP từ tất cả regions
Users tự động route tới vị trí gần nhất (via BGP)
Zero application changes — application chỉ biết về single IP

Điều này cho phép bạn:

Deploy infrastructure ở nhiều chỗ
Users tự động reach nearest endpoint (low latency)
Failover automatic nếu region down
Geo-distribution mà không cần DNS tricks

Internal Model: Anycast Mechanism

Unicast Truyền Thống (1 IP mỗi chỗ)

App: api.example.com

Bản ghi DNS:
├─ api-us.example.com → 35.201.123.45 (vùng Mỹ)
├─ api-eu.example.com → 34.159.123.45 (vùng Âu)
└─ api-ap.example.com → 34.87.123.45 (vùng Á)

Mã App:
```javascript
if (user.location == 'US') {
  fetch('https://api-us.example.com')
} else if (user.location == 'EU') {
  fetch('https://api-eu.example.com')
} // ... logic cho mỗi vùng

Vấn đề: ├─ App phải định vị địa lý người dùng ├─ Phải quản lý đa tên máy ├─ Dự phòng cần thay đổi DNS (chậm) └─ Logic phía khách phức tạp


### Anycast (IP Một, Chỗ Đa)

App: api.example.com

Bản ghi DNS: └─ api.example.com → 35.201.123.45 (IP anycast một)

Quảng cáo BGP (phía sau): ├─ Từ us-central1: "Tôi có 35.201.123.45" (đường AS64512 1) ├─ Từ eu-west1: "Tôi có 35.201.123.45" (đường AS64512 1) └─ Từ asia-southeast1: "Tôi có 35.201.123.45" (đường AS64512 1)

Truy vấn người dùng: ├─ Người dùng San Francisco: Tuyến BGP "35.201.123.45 qua đường-as 1 (us-central1)" ├─ Người dùng Berlin: Tuyến BGP "35.201.123.45 qua đường-as 1 (eu-west1)" ├─ Người dùng Tokyo: Tuyến BGP "35.201.123.45 qua đường-as 1 (asia-southeast1)"

Kết quả: ├─ IP giống cho tất cả người dùng ├─ Định tuyến địa lý tự động qua BGP ├─ App: Tìm nạp đơn('https://api.example.com') └─ Tính minh bạch: Khách không cần biết địa lý


### Quảng Cáo Anycast BGP

GLB GCP quảng cáo tuyến:

Chi tiết quảng cáo: ├─ Tiền tố: 35.201.123.0/24 (chứa 35.201.123.45) ├─ AS Gốc: AS Google (15169) ├─ Từ vùng: us-central1, eu-west1, asia-southeast1 (tất cả quảng cáo) ├─ Số liệu tuyến: Bằng (độ dài đường AS giống) │ └─ Tất cả 3 đường chi phí giống (ECMP có khả năng) │ └─ Bảng định tuyến ISP thấy: ├─ Tuyến 1: 35.201.123.0/24 qua PoP-us (ngắn nhất) ├─ Tuyến 2: 35.201.123.0/24 qua PoP-eu (chi phí bằng) └─ Tuyến 3: 35.201.123.0/24 qua PoP-ap (chi phí bằng)

Lựa chọn tuyến tốt nhất BGP (cho traffic người dùng): ├─ ISP Người dùng: "Tuyến nào tới 35.201.123.45?" ├─ Tất cả 3 độ dài đường AS bằng → dùng chính sách BGP cục bộ ├─ Thường: Ưa tuyến qua PoP gần nhất (chi phí IGP) └─ Kết quả: Traffic người dùng định tuyến địa lý tự nhiên


## Mô hình kiến trúc production

### Mô hình 1: Triển khai đa vùng toàn cầu

Triển khai: ├─ Backend ở us-central1 (Bắc Mỹ) ├─ Backend ở eu-west1 (Châu Âu) ├─ Backend ở asia-southeast1 (Đông Nam Á) │ └─ IP anycast toàn cầu: 35.201.123.45 └─ Quảng cáo từ 3 vùng

Luồng lưu lượng: ┌──────────────────────────────────────────────┐ │ Người dùng Internet (bất kỳ vị trí) │ │ Truy vấn DNS: "api.example.com?" │ │ Phản hồi: 35.201.123.45 │ └──────────────────┬───────────────────────────┘ │ ┌────────────┼────────────┐ │ │ │ ┌────▼─────┐ ┌───▼──────┐ ┌──▼────────┐ │ Dùng Mỹ │ │ Dùng EU │ │ Dùng Á │ └────┬─────┘ └───┬──────┘ └──┬────────┘ │ │ │ (Định tuyến BGP qua PoPs) ┌────▼──────┐ ┌───▼──────┐ ┌──▼────────┐ │ PoP-US │ │ PoP-EU │ │ PoP-ASIA │ └────┬──────┘ └───┬──────┘ └──┬────────┘ │ │ │ └────────┬───┴────┬───────┘ │ │ ┌─────▼──┬─────▼──┬──────────┐ │ Bộ cân │ Tải │ Quyết │ │ bằng │ │ định │ │ toàn │ │ │ │ cầu │ │ │ └─────────┴───────┴──────────┘ │ ┌─────▼──────────┐ │ Backend (3 vùng│ │ đều có thể │ │ nhận lưu lượng)│ └────────────────┘

Kết quả: ├─ Dùng Mỹ → Định tuyến tới us-central1 (qua PoP-US) ├─ Dùng EU → Định tuyến tới eu-west1 (qua PoP-EU) ├─ Dùng Á → Định tuyến tới asia-southeast1 (qua PoP-ASIA) └─ Dự phòng: Nếu vùng down, dùng định tuyến lại tới gần nhất


### Mô hình 2: Hoạt động hai chiều với định tuyến bất đối xứng

Triển khai: ├─ Chính: us-central1 (60% lưu lượng) ├─ Phụ: eu-west1 (40% lưu lượng) │ └─ IP anycast duy nhất có chính sách Traffic Director └─ Nhập: User→GLB định tuyến tới gần nhất └─ Xuất: Có thể thoát từ vùng khác (bất đối xứng)

Ví dụ luồng: ├─ Dùng ở London gửi yêu cầu │ └─ Nhập: PoP-EU định tuyến tới eu-west1 (nhập chính) │ └─ Backend ở eu-west1 xử lý, gửi phản hồi │ └─ Xuất: Phản hồi thoát qua PoP-EU (đường trở lại) │ └─ Kịch bản PoP-EU hỏng: └─ Nhập: PoP-UK định tuyến lại tới us-central1 └─ Backend ở us-central1 xử lý └─ Xuất: Phản hồi thoát qua PoP-US (trở lại bất đối xứng!) └─ Mạng xử lý đường bất đối xứng (kết nối stateful)


### Mô hình 3: Di chuyển lưu lượng từng chút (Triển khai Canary)

Trạng thái ban đầu: 100% lưu lượng tới us-central1 ├─ IP anycast: 35.201.123.45 quảng cáo từ us-central1 thôi ├─ eu-west1 sẵn sàng nhưng không quảng cáo

Di chuyển: ├─ Bước 1: Quảng cáo từ eu-west1 (ưu tiên thấp) │ └─ Chỉ số BGP: đường eu-west1 chi phí cao │ └─ Lưu lượng: ~5% tới eu-west1 │ ├─ Bước 2: Tăng ưu tiên eu-west1 dần dần │ └─ Bước 2a: 10% lưu lượng tới eu-west1 │ └─ Bước 2b: 25% lưu lượng tới eu-west1 │ └─ Bước 2c: 50% lưu lượng tới eu-west1 │ └─ Bước 3: Hoàn thành di chuyển (nếu không có vấn đề) └─ Hủy quảng cáo us-central1, 100% tới eu-west1

Giám sát: ├─ Mỗi bước: Giám sát tỷ lệ lỗi, độ trễ, sức khỏe ├─ Quay lại: Quảng cáo lại us-central1, hoàn nguyên lưu lượng └─ Kết quả: Di chuyển vùng không thời gian chết


## Kịch bản hỏng thực tế

### Kịch bản 1: PoP hỏng (Dự phòng tự động Anycast)

Thiết lập: Triển khai anycast 3 vùng ├─ us-central1, eu-west1, asia-southeast1 └─ Tất cả quảng cáo IP anycast giống

Hỏng: PoP-EU không thể tiếp cận ├─ Dấu hiệu: Dùng ở Âu thấy độ trễ tăng cao ├─ Hội tụ BGP: ISP phát hiện PoP-EU rút ├─ Tuyến mới: Dùng định tuyến lại tới PoP-US hoặc PoP-AP

Dòng thời gian phục hồi: ├─ T+0s: PoP-EU hỏng ├─ T+10-30s: ISP phát hiện hỏng (BGP timeout) ├─ T+30-60s: Lưu lượng dùng định tuyến lại tới PoP khác ├─ T+60-180s: Độ trễ bình thường (dùng trên đường khác) └─ T+5-10 phút: PoP-EU phục hồi, tuyến hội tụ lại

Lợi ích anycast: ├─ Dự phòng tự động: Không can thiệp thủ công ├─ Minh bạch: Dùng không quan tâm backend nào phục vụ └─ Từ từ: Lưu lượng dịch chuyển dần, không mất đột ngột


### Kịch bản 2: Vùng down (Anycast che giấu hỏng)

Hỏng: Trung tâm dữ liệu us-central1 down (sự cố điện)

Unicast bình thường (nhiều IP): ├─ Dùng cố tiếp cận 35.201.123.45 (IP us-central1) → Timeout ├─ Cần: DNS dự phòng thủ công hoặc thay đổi mã └─ Kết quả: Mất kết nối 10-60 giây cho mỗi dùng

Anycast (IP duy nhất): ├─ Dùng tiếp cận 35.201.123.45 (IP anycast) ├─ BGP: Tuyến tới us-central1 rút ├─ Tuyến mới: PoP-US tự động định tuyến lại tới eu-west1 hoặc asia-southeast1 ├─ Độ trễ: Cao hơn (bây giờ liên vùng) nhưng có thể tiếp cận └─ Kết quả: Dự phòng tự động, <1 giây mất kết nối cảm nhận

Lợi ích anycast: └─ Hỏng che giấu tự động, không cần thay đổi ứng dụng


### Kịch bản 3: BGP bị đánh cắp / Rò rỉ tuyến (Bảo mật)

Mối đe dọa: Kẻ tấn công quảng cáo 35.201.123.0/24 từ AS64000 (AS xấu)

Kịch bản bình thường: ├─ Google quảng cáo: 35.201.123.0/24 từ AS15169 (đường AS 1) ├─ Kẻ xấu quảng cáo: 35.201.123.0/24 từ AS64000 (đường AS 1) ├─ Quyết định BGP: Ưa thích đường AS ngắn/tốt hơn ├─ Nếu kẻ xấu có đường ngắn hơn: Lưu lượng bị đánh cắp

Giảm thiểu GCP: ├─ RPKI (Cơ sở hạ tầng khóa công cộng): Xác thực mã hóa ├─ Google ký: "AS15169 có thể quảng cáo 35.201.123.0/24" ├─ Bộ lọc ISP: Từ chối quảng cáo không được ký bởi Google ├─ Kết quả: Quảng cáo xấu bị chặn


## Lỗi thường gặp & Mô hình chống

### Lỗi 1: Kỳ vọng hiệu năng giống qua Anycast

❌ **Suy nghĩ sai**:

"Anycast có nghĩa tất cả dùng có độ trễ giống"


✅ **Hiểu đúng**:
- Anycast định tuyến tới gần nhất (vị trí địa lý)
- Gần nhất ≠ độ trễ tốt nhất (phụ thuộc chỉ số BGP)
- PoP khác nhau có độ trễ khác nhau
- Nếu backend down, lưu lượng có thể định tuyến xa

**Phòng chống**: Giám sát độ trễ mỗi vùng. Cảnh báo khi vùng hỏng.

### Lỗi 2: Không xử lý tuyến bất đối xứng

❌ **Suy nghĩ sai**:

"Yêu cầu và phản hồi luôn cùng một đường"


✅ **Hiểu đúng**:
- Anycast có thể gây định tuyến bất đối xứng
- Nhập: dùng→PoP-A→backend-A
- Xuất: backend-A→PoP-B (khác!)
- Mạng phải xử lý đường bất đối xứng (tường lửa stateful phức tạp)

**Phòng chống**: Kiểm tra kịch bản định tuyến bất đối xứng. Hiểu tác động kết nối TCP/UDP.

### Lỗi 3: Dựa quá lên Anycast cho dự phòng

❌ **Suy nghĩ sai**:

"Anycast xử lý dự phòng tự động, không cần kiểm tra sức khỏe"


✅ **Hiểu đúng**:
- Dự phòng Anycast: Phụ thuộc hội tụ BGP (~10-30 giây)
- Kiểm tra sức khỏe: Có thể phát hiện và dịch chuyển nhanh hơn (giây)
- Kết hợp: Dùng cả hai cho dự phòng nhanh nhất

**Phòng chống**: Bật kiểm tra sức khỏe trên backend. Giám sát thời gian dự phòng.

## Hướng dẫn triển khai GCP

### Thiết lập bộ cân bằng tải toàn cầu với Anycast

```bash
# Tạo IP toàn cầu (anycast theo mặc định)
gcloud compute addresses create global-static-ip \
  --global \
  --address-type=EXTERNAL

# Tạo kiểm tra sức khỏe
gcloud compute health-checks create tcp \
  --name=tcp-health-check \
  --port=443

# Tạo dịch vụ backend mỗi vùng
gcloud compute backend-services create backend-us \
  --global \
  --protocol=HTTPS \
  --health-checks=tcp-health-check

gcloud compute backend-services create backend-eu \
  --global \
  --protocol=HTTPS \
  --health-checks=tcp-health-check

# Thêm backend
gcloud compute backend-services add-backends backend-us \
  --global \
  --instance-group=ig-us-central1 \
  --instance-group-zone=us-central1-a

gcloud compute backend-services add-backends backend-eu \
  --global \
  --instance-group=ig-eu-west1 \
  --instance-group-zone=europe-west1-b

# Tạo bản đồ URL cho định tuyến
gcloud compute url-maps create my-url-map \
  --default-service=backend-us

# Tạo proxy HTTPS
gcloud compute target-https-proxies create my-https-proxy \
  --url-map=my-url-map \
  --ssl-certificates=my-cert

# Tạo quy tắc chuyển tiếp (anycast quảng cáo tự động)
gcloud compute forwarding-rules create my-forwarding-rule \
  --global \
  --target-https-proxy=my-https-proxy \
  --address=global-static-ip \
  --ports=443

# Kết quả: IP duy nhất quảng cáo từ tất cả vùng qua anycast

Giám sát sức khỏe Anycast

bash

# Kiểm tra sức khỏe backend
gcloud compute backend-services get-health backend-us --global

# Giám sát phân phối lưu lượng
gcloud logging read \
  "resource.type=http_load_balancer AND jsonPayload.backend_region" \
  --format='json' | \
  jq -r '.[] | "\(.jsonPayload.backend_region) \(.jsonPayload.bytes_sent)"' | \
  sort | uniq -c

# Kiểm tra nếu tất cả vùng quảng cáo
gcloud compute routes list --filter="dest_range~35.201.123" --format='table(dest_range,next_hop_gateway)'

Tài liệu tham khảo

Cân bằng tải toàn cầu với Anycast — Tài liệu chính thức
Cách Anycast hoạt động trong GCP — Chi tiết kiến trúc
Traffic Director (Anycast nâng cao) — Tính năng anycast nâng cao
Định tuyến BGP trong GCP — Cơ chế định tuyến cơ bản

Tiếp theo: Cold Potato vs Hot Potato Routing — Lựa chọn chiến lược trong chọn đường lưu lượng

Anycast Routing with Global Load Balancer ​

Vì sao quan trọng trong production ​

Internal Model: Anycast Mechanism ​

Unicast Truyền Thống (1 IP mỗi chỗ) ​