Jaringan layanan untuk aplikasi terdistribusi di Cross-Cloud Network

Last reviewed 2024-05-31 UTC

Dokumen ini adalah bagian dari seri panduan desain untuk Jaringan Lintas Cloud.

Rangkaian ini terdiri dari bagian berikut:

Dokumen ini menjelaskan cara menyusun aplikasi dari serangkaian layanan komponen yang dipilih atau dibuat. Sebaiknya baca seluruh dokumen sekali sebelum mengikuti langkah-langkahnya.

Dokumen ini memandu Anda melalui keputusan berikut:

  • Apakah Anda membuat layanan individual sendiri atau menggunakan layanan pihak ketiga
  • Apakah layanan tersedia secara global atau regional
  • Apakah layanan digunakan dari lokal, dari cloud lain, atau tidak dari keduanya
  • Apakah Anda mengakses endpoint layanan melalui VPC layanan bersama atau mendistribusikan endpoint melalui semua VPC aplikasi yang relevan

Dokumen ini akan memandu Anda melalui langkah-langkah berikut:

  1. Menentukan apakah aplikasi Anda bersifat global atau regional
  2. Memilih layanan terkelola pihak ketiga atau membuat dan memublikasikan layanan Anda sendiri
  3. Menyiapkan akses pribadi ke endpoint layanan menggunakan mode bersama atau khusus
  4. Merakit layanan ke dalam aplikasi agar cocok dengan arketipe global atau regional

Developer menentukan lapisan jaringan layanan untuk Cross-Cloud Network. Pada tahap ini, administrator telah mendesain lapisan konektivitas untuk Jaringan Lintas Cloud yang memungkinkan fleksibilitas dalam opsi jaringan layanan yang dijelaskan dalam dokumen ini. Dalam beberapa kasus, batasan dari transitivitas lintas VPC terbatas ada. Kami menjelaskan batasan ini jika dapat memengaruhi keputusan desain.

Menentukan apakah aplikasi Anda bersifat regional atau global

Tentukan apakah pelanggan aplikasi yang Anda buat memerlukan arketipe deployment regional atau global. Anda dapat mencapai ketahanan regional dengan menyebarkan beban di seluruh zona dalam satu region. Anda dapat mencapai ketahanan global dengan mendistribusikan beban di seluruh region.

Pertimbangkan faktor-faktor berikut saat memilih arketipe:

  • Persyaratan ketersediaan aplikasi
  • Lokasi tempat aplikasi digunakan
  • Biaya

Untuk mengetahui detailnya, lihat arketip deployment Google Cloud.

Panduan desain ini membahas cara mendukung arketipe deployment berikut:

Dalam aplikasi terdistribusi lintas cloud, berbagai layanan aplikasi tersebut dapat dikirim dari berbagai penyedia layanan cloud (CSP) atau pusat data pribadi. Untuk membantu memastikan struktur ketahanan yang konsisten, tempatkan layanan yang dihosting di CSP yang berbeda ke dalam pusat data CSP yang secara geografis berdekatan.

Diagram berikut menunjukkan stack aplikasi global yang didistribusikan di seluruh cloud dan berbagai layanan aplikasi di-deploy di CSP yang berbeda. Setiap layanan aplikasi global memiliki instance beban kerja di berbagai region CSP yang sama.

Stack aplikasi global yang didistribusikan di seluruh cloud.

Menentukan dan mengakses layanan aplikasi

Untuk menyusun aplikasi, Anda dapat menggunakan layanan terkelola pihak ketiga yang ada, membuat dan menghosting layanan aplikasi Anda sendiri, atau menggunakan kombinasi keduanya.

Menggunakan layanan terkelola pihak ketiga yang ada

Tentukan layanan terkelola pihak ketiga yang dapat Anda gunakan untuk aplikasi Anda. Tentukan layanan mana yang dibuat sebagai layanan regional atau layanan global. Selain itu, tentukan opsi akses pribadi yang didukung oleh setiap layanan.

Setelah mengetahui layanan terkelola yang dapat digunakan, Anda dapat menentukan layanan mana yang perlu dibuat.

Membuat dan mengakses layanan aplikasi

Setiap layanan dihosting oleh satu atau beberapa instance workload yang dapat diakses sebagai satu endpoint atau sebagai grup endpoint.

Pola umum untuk layanan aplikasi ditampilkan dalam diagram berikut. Layanan aplikasi di-deploy di seluruh kumpulan instance beban kerja. (Dalam hal ini, instance workload dapat berupa VM Compute Engine, cluster Google Kubernetes Engine (GKE), atau beberapa backend lain yang menjalankan kode.) Instance workload diatur sebagai kumpulan backend yang terkait dengan load balancer.

Diagram berikut menunjukkan load balancer umum dengan sekumpulan backend.

Load balancer dengan backend.

Untuk mencapai distribusi beban yang dipilih dan mengotomatiskan failover, grup endpoint ini menggunakan load balancer frontend. Dengan menggunakan grup instance terkelola (MIG), Anda dapat meningkatkan atau mengurangi kapasitas layanan secara fleksibel dengan menskalakan endpoint yang membentuk backend load balancer secara otomatis. Selain itu, bergantung pada persyaratan layanan aplikasi, load balancer juga dapat menyediakan autentikasi, penghentian TLS, dan layanan khusus koneksi lainnya.

Menentukan cakupan layanan - regional atau global

Tentukan apakah layanan Anda memerlukan dan dapat mendukung ketahanan regional atau global. Layanan software regional dapat dirancang untuk sinkronisasi dalam anggaran latensi regional. Layanan aplikasi global dapat mendukung failover sinkron di seluruh node yang didistribusikan di seluruh region. Jika aplikasi Anda bersifat global, Anda mungkin ingin layanan yang mendukungnya juga bersifat global. Namun, jika layanan Anda memerlukan sinkronisasi di antara instance-nya untuk mendukung failover, Anda harus mempertimbangkan latensi antar-region. Untuk situasi Anda, Anda mungkin harus mengandalkan layanan regional dengan redundansi di region yang sama atau di dekatnya, sehingga mendukung sinkronisasi latensi rendah untuk failover.

Cloud Load Balancing mendukung endpoint yang dihosting dalam satu region atau didistribusikan di seluruh region. Dengan demikian, Anda dapat membuat lapisan layanan global yang ditampilkan kepada pelanggan yang berkomunikasi dengan lapisan layanan global, regional, atau hibrida. Pilih deployment layanan Anda untuk memastikan bahwa failover jaringan dinamis (atau load balancing di seluruh region) selaras dengan status ketahanan dan kemampuan logika aplikasi Anda.

Diagram berikut menunjukkan cara layanan global yang dibuat dari load balancer regional dapat menjangkau backend di region lain, sehingga memberikan failover otomatis di seluruh region. Dalam contoh ini, logika aplikasi bersifat global dan backend yang dipilih mendukung sinkronisasi di seluruh region. Setiap load balancer terutama mengirimkan permintaan ke region lokal, tetapi dapat beralih ke region jarak jauh.

Load balancer dengan backend di berbagai region.

  • Backend global adalah kumpulan backend regional yang diakses oleh satu atau beberapa load balancer.
  • Meskipun backend bersifat global, frontend setiap load balancer bersifat regional.
  • Dalam pola arsitektur ini, load balancer terutama mendistribusikan traffic hanya dalam regionnya, tetapi juga dapat menyeimbangkan traffic ke region lain jika resource di region lokal tidak tersedia.
  • Kumpulan frontend load balancer regional, yang masing-masing dapat diakses dari region lain dan masing-masing dapat menjangkau backend di region lain, membentuk layanan global gabungan.
  • Untuk menyusun stack aplikasi global, seperti yang dibahas dalam Mendesain stack aplikasi global, Anda dapat menggunakan perutean DNS dan health check untuk mencapai failover frontend lintas wilayah.
  • Frontend load balancer itu sendiri dapat diakses dari region lain menggunakan akses global (tidak ditampilkan dalam diagram).

Pola yang sama ini dapat digunakan untuk menyertakan layanan yang dipublikasikan dengan penggantian layanan global. Diagram berikut menggambarkan layanan yang dipublikasikan yang menggunakan backend global.

Load balancer yang dapat diakses dari berbagai region.

Dalam diagram, perhatikan bahwa layanan yang dipublikasikan memiliki failover global yang diterapkan di lingkungan produsen. Penambahan failover global di lingkungan konsumen memungkinkan ketahanan terhadap kegagalan regional di infrastruktur load balancing konsumen. Failover lintas-regional layanan harus diterapkan dalam logika aplikasi layanan dan dalam desain load balancing produsen layanan. Mekanisme lain dapat diterapkan oleh produsen layanan.

Untuk menentukan produk Cloud Load Balancing mana yang akan digunakan, Anda harus terlebih dahulu menentukan jenis traffic yang harus ditangani oleh load balancer. Pertimbangkan aturan umum berikut:

  • Menggunakan Load Balancer Aplikasi untuk traffic HTTP(S).
  • Menggunakan Load Balancer Jaringan proxy untuk traffic TCP non-HTTP(S). Load balancer proxy ini juga mendukung offload TLS.
  • Gunakan Load Balancer Jaringan passthrough untuk mempertahankan alamat IP sumber klien di header, atau untuk mendukung protokol tambahan seperti UDP, ESP, dan ICMP.

Untuk panduan mendetail tentang cara memilih load balancer terbaik untuk kasus penggunaan Anda, lihat Memilih load balancer.

Layanan dengan backend serverless

Layanan dapat ditentukan menggunakan backend serverless. Backend di lingkungan produser dapat diatur dalam NEG Tanpa Server sebagai backend untuk load balancer. Layanan ini dapat dipublikasikan menggunakan Private Service Connect dengan membuat lampiran layanan yang terkait dengan frontend load balancer produsen. Layanan yang dipublikasikan dapat digunakan melalui endpoint Private Service Connect atau backend Private Service Connect. Jika layanan memerlukan koneksi yang dimulai produsen, Anda dapat menggunakan konektor Akses VPC Serverless untuk mengizinkan lingkungan Cloud Run, App Engine standar, dan Cloud Functions mengirim paket ke alamat IPv4 internal resource dalam jaringan VPC. Akses VPC Serverless juga mendukung pengiriman paket ke jaringan lain yang terhubung ke jaringan VPC yang dipilih.

Metode untuk mengakses layanan secara pribadi

Aplikasi Anda dapat terdiri dari layanan terkelola yang disediakan oleh Google, layanan pihak ketiga yang disediakan oleh vendor luar atau grup sejawat di organisasi Anda, dan layanan yang dikembangkan oleh tim Anda. Beberapa layanan tersebut mungkin dapat diakses melalui internet menggunakan alamat IP publik. Bagian ini menjelaskan metode yang dapat Anda gunakan untuk mengakses layanan tersebut menggunakan jaringan pribadi. Jenis layanan berikut tersedia:

  • API publik Google
  • API serverless Google
  • Layanan terkelola yang dipublikasikan dari Google
  • Layanan terkelola yang dipublikasikan dari vendor dan rekan
  • Layanan yang dipublikasikan

Perhatikan opsi ini saat membaca bagian berikutnya. Bergantung pada cara mengallokasikan layanan, Anda dapat menggunakan satu atau beberapa opsi akses pribadi yang dijelaskan.

Organisasi (atau grup dalam organisasi) yang menyusun, memublikasikan, dan mengelola layanan disebut sebagai produsen layanan. Anda dan aplikasi Anda disebut sebagai konsumen layanan.

Beberapa layanan terkelola dipublikasikan secara eksklusif menggunakan akses layanan pribadi. Desain jaringan yang direkomendasikan di Konektivitas internal dan jaringan VPC mengakomodasi layanan yang dipublikasikan dengan akses layanan pribadi dan Private Service Connect.

Untuk mengetahui ringkasan opsi guna mengakses layanan secara pribadi, lihat Opsi akses pribadi untuk layanan.

Sebaiknya gunakan Private Service Connect untuk terhubung ke layanan terkelola jika memungkinkan. Untuk mengetahui informasi selengkapnya tentang pola deployment untuk Private Service Connect, lihat Pola deployment Private Service Connect.

Ada dua jenis Private Service Connect, dan layanan yang berbeda dapat dipublikasikan sebagai salah satu jenis:

Layanan yang dipublikasikan sebagai endpoint Private Service Connect dapat digunakan langsung oleh beban kerja lain. Layanan ini mengandalkan otentikasi dan resiliensi yang disediakan oleh produsen layanan. Jika menginginkan kontrol tambahan atas autentikasi dan ketahanan layanan, Anda dapat menggunakan backend Private Service Connect untuk menambahkan lapisan load balancing untuk autentikasi dan ketahanan di jaringan konsumen.

Diagram berikut menunjukkan layanan yang diakses melalui endpoint Private Service Connect:

Mengakses layanan melalui endpoint Private Service Connect.

Diagram menunjukkan pola berikut:

  • Endpoint Private Service Connect di-deploy di VPC konsumen, yang membuat layanan produsen tersedia untuk VM dan node GKE.
  • Jaringan konsumen dan produsen harus di-deploy di region yang sama.

Diagram sebelumnya menunjukkan endpoint sebagai resource regional. Endpoint dapat dijangkau dari region lain karena akses global.

Untuk mengetahui informasi selengkapnya tentang pola deployment, lihat Pola deployment Private Service Connect.

Backend Private Service Connect menggunakan load balancer yang dikonfigurasi dengan backend grup endpoint jaringan (NEG) Private Service Connect. Untuk daftar load balancer yang didukung, lihat Tentang backend Private Service Connect.

Backend Private Service Connect memungkinkan Anda membuat konfigurasi backend berikut:

  • Domain dan sertifikat milik pelanggan di depan layanan terkelola
  • Failover yang dikontrol konsumen di antara layanan terkelola di region yang berbeda
  • Konfigurasi keamanan terpusat dan kontrol akses untuk layanan terkelola

Dalam diagram berikut, load balancer global menggunakan NEG Private Service Connect sebagai backend yang membangun komunikasi ke penyedia layanan. Tidak diperlukan konfigurasi jaringan lebih lanjut dan data dikirim melalui fabric SDN Google.

Load balancer global menggunakan grup endpoint jaringan.

Sebagian besar layanan dirancang untuk koneksi yang dimulai oleh konsumen. Saat layanan perlu memulai koneksi dari produsen, gunakan antarmuka Private Service Connect.

Pertimbangan utama saat men-deploy akses layanan pribadi atau Private Service Connect adalah transitivitas. Layanan yang dipublikasikan umumnya tidak dapat dijangkau melalui koneksi Peering Jaringan VPC atau melalui Network Connectivity Center. Lokasi subnet atau endpoint akses layanan dalam topologi VPC menentukan apakah Anda mendesain jaringan untuk deployment layanan bersama atau khusus.

Opsi seperti VPN dengan ketersediaan tinggi (HA) dan proxy yang dikelola pelanggan menyediakan metode untuk memungkinkan komunikasi transitif antar-VPC.

Endpoint Private Service Connect tidak dapat dijangkau melalui Peering Jaringan VPC. Jika Anda memerlukan jenis konektivitas ini, deploy load balancer internal dan NEG Private Service Connect sebagai backend, seperti yang ditunjukkan dalam diagram berikut:

Menggunakan NEG untuk memberikan keterjangkauan.

Google API dapat diakses secara pribadi menggunakan endpoint dan backend Private Service Connect. Penggunaan endpoint umumnya direkomendasikan karena produsen Google API menyediakan ketahanan dan autentikasi berbasis sertifikat.

Buat endpoint Private Service Connect di setiap VPC tempat layanan perlu diakses. Karena alamat IP konsumen adalah alamat IP global pribadi, satu pemetaan DNS untuk setiap layanan diperlukan, meskipun ada instance endpoint di beberapa VPC, seperti yang ditunjukkan dalam diagram berikut:

Private Service Connect dengan Google API.

Menentukan pola penggunaan layanan

Layanan dapat berjalan di berbagai lokasi: jaringan VPC Anda, jaringan VPC lain, di pusat data lokal, atau di cloud. Terlepas dari tempat workload layanan berjalan, aplikasi Anda menggunakan layanan tersebut dengan menggunakan titik akses, seperti salah satu dari berikut:

  • Alamat IP di subnet akses layanan pribadi
  • Endpoint Private Service Connect
  • VIP untuk load balancer yang menggunakan NEG Private Service Connect

Titik akses konsumen dapat dibagikan di seluruh jaringan atau dikhususkan untuk satu jaringan. Tentukan apakah akan membuat titik akses konsumen bersama atau khusus berdasarkan apakah organisasi Anda mendelegasikan tugas pembuatan titik akses layanan konsumen ke setiap grup aplikasi atau mengelola akses ke layanan secara gabungan.

Pengelolaan akses layanan melibatkan aktivitas berikut:

  • Membuat titik akses
  • Men-deploy titik akses di VPC yang memiliki jenis keterjangkauan yang sesuai
  • Mendaftarkan alamat IP dan URL titik akses konsumen di DNS
  • Mengelola sertifikat keamanan dan ketahanan untuk layanan di ruang konsumen, saat menambahkan load balancing di depan titik akses konsumen

Untuk beberapa organisasi, mungkin dapat menetapkan pengelolaan akses layanan ke tim pusat, sementara organisasi lainnya mungkin disusun untuk memberikan lebih banyak independensi kepada setiap konsumen atau tim aplikasi. Produk sampingan dari pengoperasian dalam mode khusus adalah beberapa elemen direplikasi. Misalnya, layanan didaftarkan dengan beberapa nama DNS oleh setiap grup aplikasi dan mengelola beberapa kumpulan sertifikat TLS.

Desain VPC yang dijelaskan dalam Segmentasi dan konektivitas jaringan untuk aplikasi terdistribusi di Jaringan Lintas Cloud memungkinkan keterjangkauan untuk men-deploy titik akses layanan dalam mode bersama atau khusus. Titik akses konsumen bersama di-deploy di VPC layanan, yang dapat diakses dari VPC lain atau jaringan eksternal. Titik akses konsumen khusus di-deploy di VPC aplikasi, yang hanya dapat diakses dari resource dalam VPC aplikasi tersebut.

Perbedaan utama antara VPC layanan dan VPC aplikasi adalah konektivitas transit titik akses layanan yang diaktifkan oleh VPC layanan. VPC layanan tidak terbatas untuk menghosting titik akses konsumen. VPC dapat menghosting resource aplikasi, serta titik akses konsumen bersama. Dalam hal ini, VPC harus dikonfigurasi dan ditangani sebagai VPC layanan.

Akses layanan terkelola bersama

Untuk semua metode penggunaan layanan, termasuk Private Service Connect, pastikan Anda melakukan tugas berikut:

  • Men-deploy titik akses konsumen layanan di VPC layanan. VPC layanan memiliki keterjangkauan transitif ke VPC lain.
  • Iklankan subnet untuk titik akses konsumen sebagai iklan rute kustom dari Cloud Router yang terhubung ke jaringan lain melalui HA-VPN. Untuk Google API, iklankan alamat IP host API.
  • Perbarui aturan firewall multi-cloud untuk mengizinkan subnet akses layanan pribadi.

Khusus untuk akses layanan pribadi, pastikan Anda dapat memenuhi persyaratan tambahan berikut:

Untuk akses layanan serverless, pastikan Anda dapat memenuhi persyaratan berikut:

  • Konektor akses memerlukan subnet reguler /28 khusus
  • Cloud Router mengiklankan subnet reguler secara default
  • Membuat aturan firewall masuk untuk mengizinkan semua subnet akses VPC dalam VPC
  • Memperbarui aturan firewall multi-cloud untuk mengizinkan subnet konektor akses VPC
  • Buat aturan firewall masuk untuk mengizinkan subnet akses layanan pribadi ke VPC aplikasi

Akses layanan terkelola khusus

Pastikan Anda melakukan tugas berikut:

  • Di setiap VPC aplikasi tempat akses diperlukan, deploy aturan penerusan untuk layanan guna membuat titik akses.
  • Untuk akses layanan pribadi, buat aturan firewall masuk untuk mengizinkan subnet akses layanan pribadi ke VPC aplikasi.

Untuk akses layanan serverless, pastikan Anda dapat memenuhi persyaratan berikut:

  • Konektor akses memerlukan subnet reguler /28 khusus
  • Buat aturan firewall traffic masuk untuk mengizinkan subnet konektor Akses VPC dalam VPC aplikasi

Merakit stack aplikasi

Bagian ini menjelaskan cara menyusun stack aplikasi regional atau global.

Mendesain stack aplikasi regional

Jika aplikasi mengikuti arketipe deployment regional atau multi-regional, gunakan stack aplikasi regional. Stack aplikasi regional dapat dianggap sebagai penyambungan lapisan layanan aplikasi regional. Misalnya, lapisan layanan web regional yang berkomunikasi dengan lapisan aplikasi di region yang sama, yang pada gilirannya berkomunikasi dengan lapisan database di region yang sama, adalah stack aplikasi regional.

Setiap lapisan layanan aplikasi regional menggunakan load balancer untuk mendistribusikan traffic di seluruh endpoint lapisan di region tersebut. Keandalan dicapai dengan mendistribusikan resource backend di tiga zona atau lebih di region.

Lapisan layanan aplikasi di CSP lain atau pusat data lokal harus di-deploy di region yang setara di jaringan eksternal. Selain itu, buat layanan yang dipublikasikan tersedia di region stack. Untuk menyelaraskan stack aplikasi dalam suatu region, URL lapisan layanan aplikasi harus di-resolve ke alamat IP regional frontend load balancer tertentu. Pemetaan DNS ini didaftarkan di zona DNS yang relevan untuk setiap layanan aplikasi.

Diagram berikut menunjukkan stack regional dengan ketahanan aktif-siaga:

Stack regional dengan ketahanan aktif-siaga.

Instance lengkap stack aplikasi di-deploy di setiap region di seluruh pusat data cloud yang berbeda. Jika terjadi kegagalan regional di salah satu lapisan layanan aplikasi, stack di region lain akan mengambil alih pengiriman seluruh aplikasi. Failover ini dilakukan sebagai respons terhadap pemantauan out-of-band dari berbagai lapisan layanan aplikasi.

Saat kegagalan dilaporkan untuk salah satu lapisan layanan, frontend aplikasi akan ditautkan ulang ke stack cadangan. Aplikasi ditulis untuk mereferensikan kumpulan data nama regional yang mencerminkan stack alamat IP regional di DNS sehingga setiap lapisan aplikasi mempertahankan koneksinya dalam region yang sama.

Mendesain stack aplikasi global

Jika aplikasi mengikuti arketipe deployment aplikasi global, setiap lapisan layanan aplikasi akan menyertakan backend di beberapa region. Menyertakan backend di beberapa region akan memperluas kumpulan ketahanan untuk lapisan layanan aplikasi di luar satu region dan memungkinkan deteksi dan rekonvergensi failover otomatis.

Diagram berikut menunjukkan stack aplikasi global:

Stack global menggunakan project hub dan project aplikasi.

Diagram sebelumnya menunjukkan aplikasi global yang dirakit dari komponen berikut:

  • Layanan yang berjalan di pusat data lokal dengan frontend load balancer. Titik akses load balancer dapat dijangkau melalui Cloud Interconnect dari VPC transit.
  • VPC transit menghosting koneksi hybrid antara pusat data eksternal dan VPC aplikasi.
  • VPC aplikasi yang menghosting aplikasi inti yang berjalan di instance workload. Instance beban kerja ini berada di belakang load balancer. Load balancer dapat dijangkau dari region mana pun dalam jaringan dan dapat menjangkau backend di region mana pun dalam jaringan.
  • VPC layanan yang menghosting titik akses untuk layanan yang berjalan di lokasi lain, seperti di VPC pihak ketiga. Titik akses layanan ini dapat dijangkau melalui koneksi HA-VPN antara VPC layanan dan VPC transit.
  • VPC pembuat layanan yang dihosting oleh organisasi lain atau organisasi utama dan aplikasi yang berjalan di lokasi lain. Layanan yang relevan dapat dijangkau oleh backend Private Service Connect yang di-deploy sebagai backend global ke load balancer regional yang dihosting di VPC layanan. Load balancer regional dapat dijangkau dari region lain.

Jika ingin aplikasi yang dibuat dapat dijangkau dari internet, Anda dapat menambahkan Load Balancer Aplikasi eksternal global yang mengarah ke workload aplikasi di VPC aplikasi (tidak ditampilkan dalam diagram).

Untuk mendukung stack aplikasi global, kami menggunakan backend global untuk setiap lapisan aplikasi. Hal ini memungkinkan pemulihan dari kegagalan semua endpoint backend di satu region. Setiap region memiliki frontend load balancer regional untuk setiap lapisan layanan aplikasi. Saat terjadi failover regional, frontend load balancer regional internal dapat dijangkau di seluruh region, karena menggunakan akses global. Karena stack aplikasi bersifat global, kebijakan perutean geolokasi DNS digunakan untuk memilih frontend regional yang paling sesuai untuk permintaan atau alur tertentu. Jika terjadi kegagalan frontend, health check DNS dapat digunakan untuk mengotomatiskan failover dari satu frontend ke frontend lainnya.

Layanan yang dipublikasikan menggunakan backend Private Service Connect mendapatkan manfaat dari akses global Private Service Connect. Fitur ini memungkinkan backend Private Service Connect dapat dijangkau dari region mana pun dan mengurangi gangguan dari kegagalan lapisan layanan aplikasi. Artinya, backend Private Service Connect dapat dimanfaatkan sebagai backend global seperti yang dijelaskan dalam Menentukan cakupan Layanan - regional atau global.

Memberikan akses pribadi ke layanan yang dihosting di jaringan eksternal

Anda mungkin ingin memublikasikan titik akses lokal untuk layanan yang dihosting di jaringan lain. Dalam hal ini, Anda dapat menggunakan load balancer proxy TCP regional internal menggunakan NEG campuran. Anda dapat membuat layanan yang dihosting di infrastruktur lokal atau di lingkungan cloud lain yang tersedia untuk klien di jaringan VPC Anda, seperti yang ditunjukkan dalam diagram berikut:

Titik akses lokal menggunakan NEG hybrid.

Jika ingin menyediakan layanan hybrid di jaringan VPC selain jaringan yang menghosting load balancer, Anda dapat menggunakan Private Service Connect untuk memublikasikan layanan. Dengan menempatkan lampiran layanan di depan load balancer proxy TCP regional internal, Anda dapat mengizinkan klien di jaringan VPC lain menjangkau layanan hibrida yang berjalan di lokal atau di lingkungan cloud lainnya.

Dalam lingkungan lintas cloud, penggunaan NEG hybrid memungkinkan komunikasi aplikasi ke aplikasi yang aman.

Jika organisasi lain memublikasikan layanan aplikasi, gunakan NEG hybrid untuk memperluas abstraksi akses pribadi untuk layanan tersebut. Diagram berikut mengilustrasikan skenario ini:

NEG hybrid di depan layanan di jaringan lain.

Pada diagram sebelumnya, lapisan layanan aplikasi sepenuhnya disusun di CSP tetangga, yang ditandai di bagian diagram yang tidak berwarna abu-abu. Load balancer hybrid digunakan bersama dengan lampiran layanan Private Service Connect sebagai mekanisme untuk memublikasikan layanan aplikasi eksternal untuk konsumsi pribadi dalam Google Cloud. Load balancer hybrid dengan NEG hybrid dan lampiran layanan Private Service Connect berada di VPC yang merupakan bagian dari project produsen layanan. Project produsen layanan ini biasanya mungkin merupakan VPC yang berbeda dengan VPC transisi, karena berada dalam cakupan administratif organisasi atau project produsen, sehingga terpisah dari layanan transisi umum. VPC produsen tidak perlu terhubung melalui peering VPC atau VPN dengan ketersediaan tinggi (HA-VPN) dengan VPC konsumen (yaitu VPC Bersama Layanan dalam diagram).

Memusatkan akses layanan

Akses layanan dapat dipusatkan ke jaringan VPC dan diakses dari jaringan aplikasi lain. Diagram berikut menunjukkan pola umum yang memungkinkan sentralisasi titik akses:

VPC layanan khusus.

Diagram berikut menunjukkan semua layanan yang diakses dari VPC layanan khusus:

VPC layanan khusus dengan load balancer terpusat.

Saat layanan di-frontend dengan load balancer aplikasi, Anda dapat menggabungkan load balancer menjadi lebih sedikit dengan menggunakan peta URL untuk mengarahkan traffic untuk backend layanan yang berbeda, bukan menggunakan load balancer yang berbeda untuk setiap layanan. Pada prinsipnya, stack aplikasi dapat disusun sepenuhnya menggunakan satu load balancer aplikasi ditambah backend layanan dan pemetaan URL yang sesuai.

Dalam implementasi ini, Anda harus menggunakan NEG campuran di seluruh VPC untuk sebagian besar jenis backend. Pengecualian adalah NEG atau backend Private Service Connect, seperti yang dijelaskan dalam Rantai Eksplisit Load Balancer L7 Google Cloud dengan Private Service Connect.

Penggunaan NEG hybrid di seluruh VPC akan mengorbankan perbaikan otomatis dan penskalaan otomatis untuk backend. Layanan yang dipublikasikan sudah memiliki load balancer di tenant produsen yang menyediakan penskalaan otomatis. Oleh karena itu, Anda hanya akan mengalami batasan NEG campuran jika memusatkan fungsi load balancing untuk lapisan layanan yang disusun secara native, bukan digunakan dari publikasi.

Saat menggunakan pola jaringan layanan ini, ingatlah bahwa layanan digunakan melalui lapisan load balancing tambahan.

Gunakan load balancing proxy untuk mendapatkan manfaat skala konektivitas spoke VPC Network Connectivity Center di seluruh VPC, sekaligus memberikan konektivitas transitif ke layanan yang dipublikasikan melalui load balancer proxy.

Endpoint layanan Private Service Connect dan aturan penerusan untuk akses layanan pribadi tidak dapat dijangkau di seluruh VPC spoke Network Connectivity Center. Demikian pula, jaringan di balik koneksi hybrid (Cloud Interconnect atau HA-VPN) tidak dapat dijangkau di seluruh spoke VPC Network Connectivity Center karena rute dinamis tidak disebarkan melalui Network Connectivity Center.

Kurangnya transitivitas ini dapat diatasi dengan men-deploy load balancer proxy dengan resource non-transitif yang ditangani sebagai NEG hybrid. Dengan demikian, kita dapat men-deploy load balancer proxy di depan frontend layanan dan di depan beban kerja yang dapat dijangkau di seluruh koneksi hybrid.

Frontend proxy load balancer di-deploy di subnet VPC yang di-propagate di seluruh spoke VPC Network Connectivity Center. Penyebaran ini memungkinkan keterjangkauan resource non-transitif melalui Network Connectivity Center melalui load balancer proxy.

Mode terpusat menambahkan lapisan load balancing di sisi konsumen layanan. Saat menggunakan mode ini, Anda juga perlu mengelola sertifikat, ketahanan, dan pemetaan DNS tambahan di project konsumen.

Pertimbangan lainnya

Bagian ini berisi pertimbangan untuk produk dan layanan umum yang tidak tercakup secara eksplisit dalam dokumen ini.

Pertimbangan bidang kontrol GKE

Bidang kontrol GKE di-deploy di project tenant yang dikelola Google yang terhubung ke VPC pelanggan menggunakan Peering Jaringan VPC. Karena Peering Jaringan VPC tidak bersifat transitif, komunikasi langsung ke bidang kontrol melalui topologi jaringan peering VPC hub dan spoke tidak dapat dilakukan.

Saat mempertimbangkan opsi desain GKE, seperti terpusat atau terdesentralisasi, akses langsung ke bidang kontrol dari sumber multi-cloud adalah pertimbangan utama. Jika GKE di-deploy di VPC terpusat, akses ke bidang kontrol tersedia di seluruh cloud dan dalam Google Cloud. Namun, jika GKE di-deploy di VPC yang terdesentralisasi, komunikasi langsung ke panel kontrol tidak dapat dilakukan. Jika persyaratan organisasi memerlukan akses ke bidang kontrol GKE selain mengadopsi pola desain terdesentralisasi, administrator jaringan dapat men-deploy agen koneksi yang bertindak sebagai proxy, sehingga mengatasi batasan peering non-transitif ke bidang kontrol GKE.

Keamanan - Kontrol Layanan VPC

Untuk beban kerja yang melibatkan data sensitif, gunakan Kontrol Layanan VPC untuk mengonfigurasi perimeter layanan di sekitar resource VPC Anda dan layanan yang dikelola Google, serta kontrol pergerakan data di seluruh batas perimeter. Dengan menggunakan Kontrol Layanan VPC, Anda dapat mengelompokkan project dan jaringan lokal Anda ke dalam satu perimeter yang mencegah akses data melalui layanan yang dikelola Google. Aturan traffic masuk dan keluar Kontrol Layanan VPC dapat digunakan untuk mengizinkan project dan layanan dalam perimeter layanan yang berbeda untuk berkomunikasi (termasuk jaringan VPC yang tidak berada di dalam perimeter).

Untuk arsitektur deployment yang direkomendasikan, proses orientasi yang komprehensif, dan praktik terbaik operasional, lihat Praktik terbaik untuk Kontrol Layanan VPC bagi perusahaan dan Blueprint Dasar Keamanan.

DNS untuk API/Layanan

Produsen layanan dapat memublikasikan layanan dengan menggunakan Private Service Connect. Produsen layanan dapat mengonfigurasi nama domain DNS untuk dikaitkan dengan layanan secara opsional. Jika nama domain dikonfigurasi, dan konsumen layanan membuat endpoint yang menargetkan layanan tersebut, Private Service Connect dan Direktori Layanan akan otomatis membuat entri DNS untuk layanan di zona DNS pribadi di jaringan VPC konsumen layanan.

Langkah selanjutnya

Kontributor

Penulis:

Kontributor lainnya: