My Awesome Project

Appearance

Global Access & DNS Automation cho PSC ​

Tại Sao Hai Tính Năng Này Quan Trọng ​

PSC endpoint cơ bản là một resource regional trỏ tới một IP. Ở quy mô nhỏ điều này đủ dùng, nhưng production thật đặt ra hai câu hỏi mà endpoint thuần không trả lời được:

  1. "Workload của tôi ở nhiều region, làm sao chúng dùng chung một service ở một region khác — và làm sao có HA khi region đó chết?" → đây là bài toán global access.
  2. "IP endpoint khác nhau ở mỗi VPC, làm sao app không phải hardcode IP?" → đây là bài toán DNS automation.

Hai tính năng này không phải "tính năng phụ" — chúng là điều kiện để PSC dùng được ở quy mô multi-region và multi-VPC. File này giải thích cơ chế của từng cái và trade-off đi kèm, để bạn dùng đúng chứ không bật bừa.

Global Access: Vượt Qua Ràng Buộc Regional ​

Mặc định: endpoint chỉ phục vụ same-region ​

Theo thiết kế, một PSC endpoint là regional và mặc định chỉ phục vụ client cùng region trong cùng VPC (About accessing published services through endpoints). Một VM ở us-west1 mặc định không dùng được endpoint nằm ở us-central1, dù cùng VPC. Đây là hệ quả của bản chất regional forwarding rule.

Cơ chế global access ​

Global access mở rộng phạm vi: khi bật, "resource ở bất kỳ region nào đều gửi traffic được tới endpoint" (About accessing published services through endpoints). Các tính chất cốt lõi của cơ chế:

  • Thuần consumer-side. Không cần cấu hình gì ở phía producer/service attachment. Producer thậm chí không biết consumer bật global access. Đây là một lựa chọn của riêng consumer trên forwarding rule của mình.
  • Bật/tắt bất kỳ lúc nào, không gián đoạn. Bật global access không làm gián đoạn connection đang chạy. Đây là một thay đổi an toàn về mặt vận hành.
  • Cấu hình trên forwarding rule: ví dụ gcloud compute forwarding-rules update ENDPOINT_NAME --allow-psc-global-access --region=REGION.

Lưu ý phân biệt: endpoint cho service attachment mặc định regional và cần global access để cross-region. Endpoint cho Google APIs (file 03) thì đã là global internal IP sẵn — không cần global access. Đừng nhầm hai loại.

HA Pattern: nhiều endpoint regional + global access ​

Đây là pattern quan trọng nhất mà global access mở khóa. Khi producer publish service ở nhiều region (mỗi region một service attachment), consumer có thể:

  1. Tạo một endpoint per region, mỗi cái trỏ tới service attachment cùng region (latency thấp nhất khi region khỏe).
  2. Bật global access trên các endpoint đó.
  3. Khi region chính của consumer chết, traffic vẫn tới được endpoint ở region khác — đạt HA cross-region không cần single global IP (About accessing published services through endpoints).

Theo tài liệu, global access dùng để "cung cấp HA across service hosted ở nhiều region, hoặc cho phép client truy cập service không cùng region với client". Đây là cơ chế nền cho các kiến trúc DR consume managed service đa region (ví dụ Cloud SQL Enterprise Plus với cross-region replica).

Trade-off: latency và data residency ​

Global access không miễn phí về mặt kiến trúc:

  • Latency. Nếu client ở asia-southeast1 truy cập endpoint ở us-central1 qua global access, traffic băng qua backbone toàn cầu — latency tăng đáng kể. Global access nên là cơ chế failover/HA, không phải pattern truy cập thường xuyên cross-region. Pattern đúng là "ưu tiên endpoint cùng region, fallback sang region khác".
  • Data residency / compliance. Cho phép traffic cross-region có thể vi phạm yêu cầu data residency (dữ liệu phải ở trong một khu vực pháp lý). Trong môi trường bị ràng buộc GDPR/chủ quyền dữ liệu, bật global access tùy tiện có thể tạo ra đường đi dữ liệu vi phạm. Phải cân nhắc trước khi bật.

DNS Automation: Vì Sao Không Hardcode IP ​

Vấn đề gốc: IP endpoint là local per-VPC ​

Như đã thấy ở file 04, cùng một service attachment được nhiều consumer kết nối, mỗi consumer chọn IP endpoint riêng trong VPC mình. Vì vậy không tồn tại một IP duy nhất đại diện cho service trên toàn cục — IP phụ thuộc vào từng VPC. Hardcode IP là anti-pattern (xem file 04).

DNS giải quyết bằng cách cho mỗi VPC một tên ổn định, phân giải về đúng IP endpoint local của VPC đó.

Cơ chế tự tạo DNS entry ​

Khi service attachment của producer khai báo một DNS domain name, thì lúc consumer tạo endpoint tới service đó, "nếu service có DNS domain name được cấu hình, private DNS entry tự động được tạo trong VPC của consumer cho endpoint" (About accessing published services through endpoints).

Cụ thể, GCP tạo:

  • Một private DNS zone (qua Cloud DNS / Service Directory) cho domain mà producer khai báo.
  • Một A record trỏ tên service về IP của endpoint trong VPC consumer đó.

Nhờ vậy, app trong consumer VPC gọi tên DNS (ví dụ myservice.example.com), DNS phân giải về IP endpoint local, traffic đi qua PSC. Cùng tên đó ở VPC khác phân giải về IP endpoint khác — abstraction hoàn hảo cho multi-VPC.

Service Directory như backend ​

Với endpoint cho Google APIs, DNS automation dùng Service Directory: tạo zone p.googleapis.com và record cho các API (xem file 03). Với endpoint cho published service có domain, cơ chế tương tự — private zone được tạo và quản lý tự động. Điểm chung: Service Directory/Cloud DNS là nơi DNS record sống, và GCP đồng bộ chúng theo vòng đời endpoint (tạo endpoint → tạo record; xóa endpoint → xóa record).

Khi producer KHÔNG khai báo domain ​

Nếu service attachment không khai báo DNS domain, không có DNS entry tự động. Lúc này consumer phải tự quản DNS: tự tạo một private zone và A record trỏ tên nội bộ của mình về IP endpoint. Đây là trường hợp thường gặp với service nội bộ tự publish — và là lý do nhiều team "quên" rằng phải tự dựng DNS, rồi rơi vào anti-pattern hardcode IP.

Pattern: Multi-Region Consumer Với DNS + Global Access Kết Hợp ​

Một kiến trúc HA hoàn chỉnh kết hợp cả hai tính năng:

  1. Producer publish service ở us-central1 và us-east1, mỗi region một service attachment, cùng khai báo domain api.internal.example.com.
  2. Consumer tạo endpoint ở cả hai region; DNS automation tạo A record cho mỗi endpoint.
  3. Consumer dùng DNS-based routing (ví dụ Cloud DNS routing policy theo geo/health) để client ưu tiên endpoint cùng region.
  4. Bật global access trên cả hai endpoint để khi một region chết, DNS có thể trỏ sang endpoint region còn lại và traffic vẫn tới được.

Bài học cơ chế: DNS giải quyết "gọi tên gì", global access giải quyết "tới được region nào". Hai cái bù trừ cho nhau — DNS chọn endpoint, global access đảm bảo endpoint được chọn (kể cả khác region) thực sự nhận được traffic. Thiếu một trong hai, HA cross-region không hoàn chỉnh.

Anti-Pattern: Bật Global Access Như Một Mặc Định "Cho Chắc" ​

Vì sao sai về cơ chế: global access cho phép traffic cross-region. Bật nó "cho chắc" trên mọi endpoint nghĩa là bạn vô tình cho phép client ở region xa truy cập endpoint, tạo ra đường đi latency cao âm thầm — và quan trọng hơn, mở ra đường đi dữ liệu cross-region mà compliance có thể cấm.

Hệ quả ở scale: một sự cố DNS hoặc routing có thể khiến phần lớn traffic đột nhiên đi cross-region qua backbone, làm latency tăng vọt mà không ai hiểu vì sao (vì "nó vẫn hoạt động" trước đó nhờ same-region). Với data residency, bạn có thể đã vi phạm mà không hề biết, vì global access không phát cảnh báo gì.

Cách đúng: chỉ bật global access khi có nhu cầu HA/failover cross-region rõ ràng và đã xác nhận compliance cho phép. Mặc định để tắt; bật có chủ đích trên đúng endpoint cần failover, và kết hợp DNS routing để same-region vẫn là đường đi ưu tiên.

References ​