My Awesome Project

Appearance

Kiến Trúc & Components của Private Service Connect ​

Tại Sao Phần Này Là Nền Tảng ​

Mọi hiểu lầm về Private Service Connect đều bắt nguồn từ việc người dùng cố gắng ánh xạ nó vào một mô hình quen thuộc sai: hoặc là "một dạng VPC peering gọn hơn", hoặc là "một load balancer public nhưng private". Cả hai đều dẫn đến quyết định kiến trúc sai và những giờ debug vô ích.

PSC là một mô hình riêng, và để reason đúng về nó, bạn phải nắm chính xác state nằm ở đâu, NAT xảy ra ở đâu, và resource nào thuộc về ai. Khi đã có mental model đúng ở tầng datapath, mọi thứ ở các file sau — Google APIs, Cloud SQL, GKE, approval, DNS — chỉ là các cấu hình khác nhau của cùng một bộ máy. File này xây dựng bộ máy đó từ gốc.

Internal Model: PSC Là Một Cặp Resource Bất Đối Xứng Qua NAT ​

Hai phía, không phải hai mạng ngang hàng ​

Điểm bản chất đầu tiên: PSC không kết nối hai VPC như hai peer ngang hàng. Nó định nghĩa một quan hệ producer–consumer bất đối xứng:

  • Producer là bên sở hữu và publish một service. Producer tạo một service attachment — một điểm "công bố" trỏ tới một internal load balancer (ILB) đứng trước service thật của họ.
  • Consumer là bên muốn dùng service đó. Consumer tạo một endpoint — một forwarding rule với một internal IP nằm trong VPC của chính consumer, trỏ tới service attachment của producer.

Theo tài liệu Google Cloud, traffic giữa hai bên hoàn toàn nằm trong mạng Google và "không có shared dependency" giữa hai network — không cần phối hợp IP, không chia sẻ route table (Private Service Connect Overview).

Sự bất đối xứng này là chìa khóa. Trong peering, hai bên thấy nhau như nhau. Trong PSC, consumer chỉ thấy đúng một IP (IP của endpoint), và IP đó được NAT sang service attachment của producer. Producer không thấy gì về internal topology của consumer cả — họ chỉ thấy traffic đến từ một dải NAT IP do chính họ cấp phát.

Bốn loại resource — và vai trò của từng cái ​

PSC có bốn primitive. Hiểu rõ ranh giới giữa chúng là điều kiện để không nhầm lẫn khi đọc tài liệu hay debug:

1. Service Attachment (phía producer) ​

Service attachment là resource trung tâm phía producer. Nó tham chiếu tới một producer load balancer (thường là internal passthrough/proxy LB) và định nghĩa ba thứ:

  1. NAT subnet(s) — dải IP dùng để NAT traffic từ consumer (giải thích chi tiết bên dưới).
  2. Connection preference — chấp nhận tự động mọi consumer (ACCEPT_AUTOMATIC) hay chỉ chấp nhận consumer trong accept list (ACCEPT_MANUAL).
  3. DNS domain (tùy chọn) — domain name để tự động tạo DNS entry phía consumer.

Service attachment chính là "mặt tiền" service: consumer không bao giờ chạm trực tiếp vào ILB hay backend của producer, họ chỉ chạm vào service attachment qua endpoint.

2. Endpoint (phía consumer) ​

Endpoint là một forwarding rule trong VPC của consumer, với một internal IP lấy từ một subnet thường (regular subnet) của consumer. Theo tài liệu, "client kết nối tới endpoint bằng internal IP, và PSC thực hiện NAT để route request tới service" (About accessing published services through endpoints).

Một số tính chất quan trọng của endpoint:

  • IP của endpoint lấy từ subnet thường và tính vào quota static internal IP của consumer.
  • Endpoint là regional resource và phải được tạo cùng region với service attachment đích.
  • Endpoint phải nằm ở VPC khác với VPC chứa service đích (không thể tự trỏ vào chính mình).
  • Phiên bản IP (IPv4/IPv6) của endpoint quyết định nó kết nối được tới loại published service nào.

3. Backend (phía consumer, biến thể nâng cao của endpoint) ​

Backend dùng Network Endpoint Group (NEG) loại Private Service Connect, đặt sau một load balancer của consumer. Thay vì consumer trỏ thẳng endpoint vào service attachment, consumer đặt service attachment làm backend của một LB. Điều này mở khóa những thứ mà endpoint thuần không làm được:

  • Custom domain & certificate do consumer kiểm soát.
  • Regional failover giữa nhiều service attachment.
  • Centralized security controls (Cloud Armor, header rewrite...) trước khi traffic ra producer.

Nói cách khác: endpoint là cách kết nối tối giản (1 IP → 1 service attachment); backend là cách kết nối khi consumer cần một lớp LB của riêng mình ở giữa.

4. Interface (phía producer — kết nối ngược chiều) ​

Đây là primitive ít gặp nhưng quan trọng về mặt khái niệm. PSC interface là "một loại network interface đặc biệt tham chiếu tới một network attachment", cho phép producer chủ động khởi tạo connection sang VPC của consumer — tức là ngược chiều so với endpoint (Private Service Connect Overview).

Đây là điểm quan trọng để hiểu transitivity: endpoint chỉ cho phép consumer → producer. Nếu producer cần gọi ngược vào consumer (ví dụ: managed service cần callback, hoặc Apigee cần gọi backend của khách hàng), họ dùng PSC interface. Và interface có tính bắc cầu trong một phạm vi giới hạn: workload trong producer network có thể khởi tạo connection tới các workload khác đang kết nối vào consumer VPC qua interface — điều mà endpoint không làm được.

NAT: Trái Tim Cho Phép Overlapping IP Ranges ​

Tại sao NAT là yếu tố quyết định ​

Câu hỏi cốt lõi mà PSC trả lời: làm sao để VPC của consumer (giả sử dùng 10.0.0.0/16) kết nối tới service của producer (cũng có thể dùng 10.0.0.0/16) mà không xung đột IP? Với VPC Peering, điều này là bất khả thi — peering yêu cầu IP range không trùng, vì route được trao đổi trực tiếp và một địa chỉ 10.0.0.5 phải là duy nhất trên cả hai bên.

PSC giải bài toán này bằng một lớp NAT do producer cấp phát. Theo tài liệu Google Cloud, kiến trúc dùng NAT để "không có sự phối hợp địa chỉ IP hay shared resource dependency nào tồn tại giữa consumer và producer VPC" (Private Service Connect Overview).

Cơ chế NAT subnet ​

Khi producer tạo service attachment, họ phải chỉ định một hoặc nhiều NAT subnet (còn gọi là PSC subnet, với purpose PRIVATE_SERVICE_CONNECT). Quy tắc vận hành:

  • Mỗi connection từ một endpoint/backend tiêu thụ đúng một IP từ NAT subnet (Manage published services).
  • Khi traffic từ consumer đi vào, Andromeda dịch source IP của packet (vốn là IP nội bộ của consumer, có thể trùng với producer) sang một IP trong NAT subnet. Nhờ đó, từ góc nhìn của producer ILB, mọi traffic đến từ dải NAT subnet — luôn duy nhất trong producer VPC.
  • Kích thước NAT subnet quyết định số lượng consumer connection tối đa. Một NAT subnet có bốn IP không dùng được (giống subnet thường): ví dụ /29 có 4 IP dùng được, /24 có 252 IP dùng được. Nếu cạn IP trong NAT subnet, mọi connection mới sẽ fail (Manage published services).

Đây là một con số phải tính toán nghiêm túc ở scale: nếu bạn là producer của một SaaS với 1000 khách hàng, mỗi khách 1 endpoint, một /24 NAT subnet (252 IP) sẽ không đủ — bạn cần /23 hoặc nhiều NAT subnet.

Vì sao consumer có thể trùng IP nhưng producer NAT subnet thì không ​

Điểm tinh tế: PSC cho phép consumer VPC trùng IP với producer VPC, nhưng NAT subnet phải là một dải IP duy nhất trong producer VPC (vì nó là subnet thật trong producer VPC). Lý do: NAT chỉ dịch source của consumer thành IP NAT — phía producer cần các IP NAT này phân biệt được với nhau để track connection và route return traffic. Source IP gốc của consumer bị "che" hoàn toàn sau NAT, nên việc nó trùng với gì cũng không quan trọng.

Hệ quả thực tế quan trọng: vì source IP của consumer bị NAT, producer không nhìn thấy IP thật của client. Nếu producer cần biết client IP gốc (cho logging, rate limiting theo IP, audit), họ phải bật PROXY protocol trên service attachment để truyền metadata connection (gồm IP gốc và PSC connection ID) ở đầu mỗi connection.

PSC connection ID ​

Mỗi connection PSC mang một PSC connection ID duy nhất. Đây là định danh mà producer dùng để phân biệt từng consumer connection — kể cả khi tất cả đều đi qua cùng dải NAT subnet. Khi bật PROXY protocol, connection ID này được nhúng vào header để application phía producer có thể attribute traffic về đúng consumer. Đây là cơ chế nền tảng cho multi-tenant accounting: một SaaS producer biết request đến từ tenant nào nhờ connection ID, không phải nhờ IP.

Data Flow Chi Tiết: Một Request Đi Qua PSC ​

Hãy theo dõi một packet TCP từ một VM consumer tới một service producer, để cố định mental model ở tầng datapath.

Consumer VPC (10.0.0.0/16)                 Producer VPC (có thể cũng 10.0.0.0/16)
┌──────────────────────────┐              ┌────────────────────────────────────┐
│  VM consumer             │              │   NAT subnet 10.100.0.0/24          │
│  10.0.0.5                │              │   (purpose=PRIVATE_SERVICE_CONNECT) │
│      │                   │              │                                     │
│      ▼                   │              │   Service Attachment                │
│  PSC Endpoint            │   Andromeda  │      │                              │
│  10.0.0.50 ──────────────┼──── NAT ─────┼──▶  ILB (producer)                  │
│  (forwarding rule)       │   (in fabric)│      │                              │
│                          │              │      ▼                              │
└──────────────────────────┘              │   Backend (VM / NEG / managed svc)  │
                                           └────────────────────────────────────┘

Bước 1 — Client gửi tới endpoint IP. VM consumer 10.0.0.5 mở connection tới 10.0.0.50 (IP của endpoint). Với client, đây chỉ là một internal IP bình thường trong VPC của họ. Không có gì "đặc biệt" lộ ra.

Bước 2 — Andromeda nhận diện đây là PSC forwarding rule. Endpoint là một forwarding rule với target là service attachment. Andromeda (lớp SDN của GCP) biết phải đẩy traffic này qua PSC datapath thay vì route thông thường.

Bước 3 — NAT tại fabric. Andromeda dịch source 10.0.0.5 thành một IP trong NAT subnet của producer (ví dụ 10.100.0.10), và đưa traffic tới service attachment. Quá trình này xảy ra in-line trong fabric, không qua VM proxy hay gateway tập trung.

Bước 4 — ILB của producer nhận traffic. Từ góc nhìn producer, request đến từ 10.100.0.10 (NAT IP), không phải 10.0.0.5. ILB phân phối tới backend thật (VM, container NEG, hoặc managed service).

Bước 5 — Return traffic. Response đi ngược lại theo connection tracking, được NAT ngược về 10.0.0.50 → 10.0.0.5. Toàn bộ phiên là stateful và đối xứng về đường đi.

Tại sao PSC đạt line-rate và không có single point of failure ​

Điểm dễ hiểu sai nhất: người ta tưởng tượng service attachment là một "gateway" mà mọi traffic phải chen qua, tạo bottleneck. Sai. Giống Cloud NAT (xem Chương 23), NAT của PSC được thực hiện phân tán trong Andromeda, ngay tại các physical host. Theo tài liệu, connectivity đạt "line-rate performance" vì traffic route trực tiếp giữa các physical host thực hiện NAT, tối thiểu latency (Private Service Connect Overview).

Hệ quả thực tế:

  • Service attachment không phải một VM hay appliance — không có throughput ceiling của riêng nó để bạn lo lắng (giới hạn nằm ở ILB và backend của producer).
  • Không có single point of failure trên đường NAT.
  • Bandwidth của connection bị giới hạn bởi backend producer và VM consumer, không phải bởi "PSC".

Endpoint vs Backend: Khi Nào Cần Load Balancer Ở Giữa ​

Một quyết định kiến trúc thường gặp. Cả endpoint và backend đều là cách consumer tiếp cận service attachment, nhưng phục vụ nhu cầu khác nhau:

ChiềuPSC EndpointPSC Backend (NEG)
Cấu trúcForwarding rule → service attachmentNEG → LB của consumer → service attachment
IP1 internal IP cố địnhIP của LB consumer
Custom domain/certKhôngCó (consumer kiểm soát)
Cloud Armor / WAFKhôngCó
Multi-region failoverCần global access (xem file 06)LB tự failover giữa nhiều service attachment
Độ phức tạpTối thiểuCao hơn

Mental model: dùng endpoint khi bạn chỉ cần "một IP nội bộ trỏ vào managed service" (đây là 90% trường hợp — Cloud SQL, Memorystore, một SaaS đơn giản). Dùng backend khi consumer cần áp một lớp LB của riêng mình: custom TLS termination, WAF, hoặc gom nhiều regional service attachment phía sau một global LB cho HA.

Constraints & Failure Modes Quan Trọng ​

Tổng hợp các ràng buộc bản chất (chi tiết hơn ở các file sau):

  1. Region affinity (endpoint). Endpoint phải cùng region với service attachment. Đây là nguồn lỗi phổ biến nhất: tạo endpoint ở us-west1 trỏ vào service attachment ở us-central1 → connection không bao giờ thành công. (Endpoint cho Google APIs là ngoại lệ — xem file 03.)

  2. NAT subnet exhaustion. Mỗi connection tốn 1 IP NAT. NAT subnet cạn → connection mới fail im lặng. Đây là bài toán capacity planning bắt buộc cho producer ở scale.

  3. Non-transitivity của endpoint. Endpoint chỉ đến được đúng producer VPC. Nó không truyền connectivity sang network peered với consumer, và không cho producer kết nối ngược (cần interface cho việc đó). Ngoại lệ: qua Network Connectivity Center hub, connection có thể được propagate tới các consumer VPC spoke khác cùng hub.

  4. Source IP bị che sau NAT. Producer không thấy client IP thật trừ khi bật PROXY protocol. Quên điều này → logging/rate-limiting theo IP ở phía producer trở nên vô nghĩa.

  5. Protocol hỗ trợ. Service attachment thường dùng cho TCP. Endpoint cho Google APIs chỉ hỗ trợ HTTP-based protocol (HTTP/HTTPS/HTTP2), không hỗ trợ ICMP/MQTT (About accessing Google APIs through endpoints).

Anti-Pattern: Tưởng Service Attachment Là Một Proxy Có Throughput Riêng ​

Một sai lầm về cơ chế thường thấy: team capacity-plan cho PSC như thể service attachment là một NAT gateway tập trung, rồi lo lắng "service attachment chịu được bao nhiêu Gbps". Hiểu lầm này dẫn tới việc tạo nhiều service attachment "để chia tải" một cách không cần thiết.

Vì sao sai về bản chất: NAT của PSC phân tán trong Andromeda; không có một thiết bị trung tâm nào để bão hòa. Giới hạn thật nằm ở (a) NAT subnet size — giới hạn số connection, không phải throughput; và (b) ILB + backend của producer — giới hạn throughput thật. Capacity planning đúng phải nhắm vào hai chỗ này, không phải vào một "throughput của service attachment" không tồn tại.

Hệ quả ở scale: team tạo dư service attachment làm phình DNS, accept list, và độ phức tạp vận hành — trong khi vẫn không giải quyết bottleneck thật (nằm ở backend). Đúng ra phải mở rộng NAT subnet và scale backend/ILB.

References ​