Jaringan layanan untuk aplikasi terdistribusi di Cross-Cloud Network

Last reviewed 2025-01-30 UTC

Dokumen ini adalah bagian dari rangkaian panduan desain untuk Cross-Cloud Network.

Rangkaian ini terdiri dari bagian berikut:

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

Dokumen ini memandu Anda dalam mengambil 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 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. Menggabungkan layanan ke dalam aplikasi agar sesuai dengan prototipe global atau regional

Developer menentukan lapisan jaringan layanan untuk Cross-Cloud Network. Pada tahap ini, administrator telah mendesain lapisan konektivitas untuk Cross-Cloud Network 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.

Tentukan apakah aplikasi Anda bersifat regional atau global

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

Pertimbangkan faktor-faktor berikut saat memilih arketipe:

  • Persyaratan ketersediaan aplikasi
  • Lokasi tempat aplikasi digunakan
  • Biaya

Untuk mengetahui detailnya, lihat arketipe deploymentGoogle Cloud .

Panduan desain ini membahas cara mendukung arketipe deployment berikut:

Dalam aplikasi terdistribusi lintas cloud, berbagai layanan aplikasi tersebut dapat dikirimkan 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 pusat data CSP yang berdekatan secara geografis.

Diagram berikut menunjukkan tumpukan aplikasi global yang didistribusikan di seluruh cloud dan berbagai layanan aplikasi di-deploy di berbagai CSP. Setiap layanan aplikasi global memiliki instance workload di berbagai region CSP yang sama.

Stack aplikasi global didistribusikan di seluruh cloud.

Menentukan dan mengakses layanan aplikasi

Untuk merakit aplikasi, Anda dapat menggunakan layanan terkelola pihak ketiga yang sudah 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 mana yang dibangun sebagai layanan regional atau layanan global. Selain itu, tentukan opsi akses pribadi yang didukung setiap layanan.

Setelah mengetahui layanan terkelola yang dapat Anda gunakan, Anda dapat menentukan layanan 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 workload. (Dalam hal ini, instance workload dapat berupa VM Compute Engine, cluster Google Kubernetes Engine (GKE), atau backend lain yang menjalankan kode.) Instance workload dikelompokkan sebagai sekumpulan backend yang terkait dengan load balancer.

Diagram berikut menunjukkan load balancer umum dengan serangkaian 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 elastis dengan melakukan penskalaan otomatis pada endpoint yang membentuk backend load balancer. Selain itu, bergantung pada persyaratan layanan aplikasi, load balancer juga dapat menyediakan otentikasi, penghentian TLS, dan layanan khusus koneksi lainnya.

Tentukan 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 sekitar, sehingga mendukung sinkronisasi latensi rendah untuk failover.

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

Diagram berikut menunjukkan cara layanan global yang dibangun dari load balancer regional dapat menjangkau backend di region lain, sehingga menyediakan 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 melakukan failover ke region jarak jauh.

Load balancer dengan backend di region yang berbeda.

  • 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 saat resource di region lokal tidak tersedia.
  • Serangkaian 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 lintas-region frontend.
  • 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 failover 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 telah menerapkan failover global di lingkungan produsen. Penambahan failover global di lingkungan konsumen memungkinkan ketahanan terhadap kegagalan regional dalam infrastruktur load balancing konsumen. Failover lintas region layanan harus diterapkan baik dalam logika aplikasi layanan maupun dalam desain load balancing produsen layanan. Mekanisme lain dapat diterapkan oleh produsen layanan.

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

  • Gunakan Load Balancer Aplikasi untuk traffic HTTP(S).
  • Gunakan 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 produsen 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 Tanpa Server untuk mengizinkan lingkungan Cloud Run, App Engine standar, dan fungsi Cloud Run 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 eksternal atau grup rekan 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 peer
  • Layanan yang dipublikasikan

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

Organisasi (atau grup dalam organisasi) yang merakit, 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 dalam Konektivitas internal dan jaringan VPC mengakomodasi layanan yang dipublikasikan dengan akses layanan pribadi dan Private Service Connect.

Untuk mengetahui ringkasan opsi untuk 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 berbagai layanan dapat dipublikasikan sebagai salah satu jenis:

Layanan yang dipublikasikan sebagai endpoint Private Service Connect dapat digunakan secara langsung oleh beban kerja lain. Layanan ini mengandalkan otentikasi dan ketahanan 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 mengetahui 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 membuat komunikasi ke penyedia layanan. Tidak diperlukan konfigurasi jaringan lebih lanjut dan data ditransfer melalui infrastruktur SDN Google.

Load balancer global menggunakan grup endpoint jaringan.

Sebagian besar layanan dirancang untuk koneksi yang dimulai konsumen. Jika 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. Titik akses konsumen Private Service Connect dapat dijangkau melalui Network Connectivity Center. Layanan yang dipublikasikan tidak dapat dijangkau melalui koneksi Peering Jaringan VPC untuk titik akses konsumen Private Service Connect atau akses layanan pribadi. Jika tidak ada transitivitas antar-VPC untuk semua titik akses konsumen layanan, lokasi subnet atau endpoint akses layanan dalam topologi VPC akan menentukan apakah Anda mendesain jaringan untuk deployment layanan bersama atau khusus.

Opsi seperti HA VPN 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 menyediakan kemampuan menjangkau.

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 konsumsi untuk layanan yang dipublikasikan

Layanan yang dipublikasikan 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 ini:

  • 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 akses layanan, yaitu 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 lebih baik menetapkan pengelolaan akses layanan ke tim pusat, sementara organisasi lain mungkin terstruktur untuk memberikan lebih banyak independensi kepada setiap tim konsumen atau 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 set 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 akses layanan, yang dapat diakses dari VPC atau jaringan eksternal lainnya. Titik akses konsumen khusus di-deploy di VPC aplikasi, yang hanya dapat diakses dari resource dalam VPC aplikasi tersebut.

Perbedaan utama antara VPC akses layanan dan VPC aplikasi adalah konektivitas transitif titik akses layanan yang diaktifkan oleh VPC akses layanan. VPC akses layanan tidak terbatas pada hosting titik akses konsumen. VPC dapat menghosting resource aplikasi, serta titik akses konsumen bersama. Dalam kasus seperti itu, 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:

  • Deploy titik akses konsumen layanan di VPC layanan. VPC layanan memiliki kemampuan jangkauan transitif ke VPC lain.
  • Jika VPC akses layanan terhubung dengan VPN dengan ketersediaan tinggi (HA), iklankan subnet untuk titik akses konsumen sebagai iklan rute kustom dari Cloud Router yang melakukan peering ke jaringan lain melalui VPN dengan ketersediaan tinggi (HA). Untuk Google API, iklankan alamat IP host API.
  • Perbarui aturan firewall multicloud untuk mengizinkan subnet akses layanan pribadi.

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

  • Mengekspor rute kustom ke jaringan produsen layanan. Untuk mengetahui informasi selengkapnya, lihat Host lokal tidak dapat berkomunikasi dengan jaringan produsen layanan
  • Buat aturan firewall masuk untuk mengizinkan subnet akses layanan pribadi ke VPC aplikasi
  • Buat aturan firewall masuk untuk mengizinkan subnet akses layanan pribadi ke VPC layanan

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

  • Konektor akses memerlukan subnet reguler /28 khusus
  • Cloud Router memberitahukan subnet reguler secara default
  • Buat aturan firewall masuk untuk mengizinkan semua subnet akses VPC dalam VPC
  • Perbarui aturan firewall multicloud 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 yang memerlukan akses, deploy aturan penerusan untuk layanan guna membuat titik akses.
  • Untuk akses layanan pribadi, buat aturan firewall ingress 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

Menyusun stack aplikasi

Bagian ini menjelaskan cara merakit stack aplikasi regional atau global.

Mendesain stack aplikasi regional

Jika aplikasi mengikuti pola dasar deployment regional atau multi-regional, gunakan stack aplikasi regional. Stack aplikasi regional dapat dianggap sebagai gabungan 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 dalam 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-standby:

Stack regional dengan ketahanan aktif-standby.

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

Jika kegagalan dilaporkan untuk salah satu lapisan layanan, frontend aplikasi akan dipindahkan kembali ke stack cadangan. Aplikasi ditulis untuk mereferensikan sekumpulan 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

Saat aplikasi mengikuti arketipe deployment aplikasi global, setiap lapisan layanan aplikasi mencakup backend di beberapa region. Menyertakan backend di beberapa region akan memperluas kumpulan ketahanan untuk lapisan layanan aplikasi di luar satu region dan memungkinkan deteksi failover otomatis dan penyatuan kembali.

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 di jaringan dan dapat menjangkau backend di region mana pun di 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 VPN dengan ketersediaan tinggi (HA) antara VPC layanan dan VPC transit.
  • VPC produsen 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 failover regional terjadi, 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, pemeriksaan kondisi DNS dapat digunakan untuk mengotomatiskan failover dari satu frontend ke frontend lain.

Layanan yang dipublikasikan menggunakan backend Private Service Connect diuntungkan dari akses global Private Service Connect. Fitur ini memungkinkan backend Private Service Connect dapat dijangkau dari region mana pun dan mengurangi gangguan akibat 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 di-hosting di jaringan lain. Dalam kasus ini, Anda dapat menggunakan load balancer proxy TCP regional internal menggunakan NEG hibrida. Anda dapat membuat produsen layanan yang dihosting secara lokal atau di lingkungan cloud lain yang tersedia untuk konsumen layanan (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 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 lain.

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

Saat 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.

Dalam 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 penggunaan pribadi dalamGoogle 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 menggunakan VPC yang berbeda dengan VPC transit, karena berada dalam cakupan administratif organisasi atau project produsen, dan oleh karena itu terpisah dari layanan transit umum. VPC produsen tidak perlu terhubung melalui peering VPC atau VPN dengan ketersediaan tinggi (HA) dengan VPC konsumen (yang merupakan VPC Bersama Layanan dalam diagram).

Memusatkan akses layanan

Akses layanan dapat dipusatkan ke dalam 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 ke lebih sedikit load balancer dengan menggunakan peta URL untuk mengarahkan traffic untuk berbagai backend layanan, bukan menggunakan load balancer yang berbeda untuk setiap layanan. Pada prinsipnya, stack aplikasi dapat sepenuhnya disusun menggunakan satu load balancer aplikasi ditambah backend layanan dan pemetaan URL yang sesuai.

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

Penggunaan NEG hybrid di seluruh VPC mengorbankan penyembuhan 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 hybrid jika Anda memusatkan fungsi load balancing untuk lapisan layanan yang disusun secara native, bukan yang digunakan dari publikasi.

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

Endpoint layanan Private Service Connect dapat dijangkau di seluruh VPC spoke Network Connectivity Center.

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 secara eksplisit dibahas dalam dokumen ini.

Pertimbangan bidang kontrol GKE

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

Saat mempertimbangkan opsi desain GKE, seperti terpusat atau terdesentralisasi, akses langsung ke bidang kontrol dari sumber multicloud adalah pertimbangan utama. Jika GKE di-deploy di VPC terpusat, akses ke bidang kontrol tersedia di seluruh cloud dan dalamGoogle Cloud. Namun, jika GKE di-deploy di VPC yang terdesentralisasi, komunikasi langsung ke bidang 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 mengontrol 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 aktivasi 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 Service Directory secara otomatis membuat entri DNS untuk layanan di zona DNS pribadi di jaringan VPC konsumen layanan.

Langkah berikutnya

Kontributor

Penulis:

Kontributor lainnya: