Networking layanan untuk aplikasi terdistribusi di Jaringan Lintas Cloud

Last reviewed 2024-05-31 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 sekumpulan layanan komponen yang dipilih atau dibuat. Sebaiknya baca seluruh dokumen satu kali sebelum mengikuti langkah-langkahnya.

Dokumen ini memandu Anda untuk mengambil keputusan berikut:

  • Baik Anda membuat layanan individual sendiri maupun menggunakan layanan pihak ketiga
  • Apakah layanan tersedia secara global atau regional
  • Apakah layanan digunakan dari infrastruktur lokal, dari cloud lain, atau dari keduanya
  • Apakah Anda mengakses endpoint layanan melalui VPC layanan bersama atau mendistribusikan endpoint melalui

Dokumen ini memandu Anda melakukan 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. Menyusun 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 Cross-Cloud Network yang memungkinkan fleksibilitas dalam opsi jaringan layanan yang dijelaskan dalam dokumen ini. Dalam beberapa kasus, ada batasan dari transitivitas lintas VPC terbatas. Kami menjelaskan kendala-kendala ini ketika mereka dapat memengaruhi keputusan desain.

Tentukan 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 suatu region. Anda bisa mencapai ketahanan global dengan menyebarkan beban antar-region.

Pertimbangkan faktor-faktor berikut saat memilih arketipe:

  • Persyaratan ketersediaan aplikasi
  • Lokasi tempat aplikasi digunakan
  • Biaya

Untuk mengetahui detailnya, lihat arketipe deployment Google 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 dalam berbagai CSP ke pusat data CSP yang secara geografis dekat satu sama lain.

Diagram berikut menunjukkan stack 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 pada 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. Tentukan layanan mana yang dibuat sebagai layanan regional atau layanan global. Selain itu, tentukan opsi akses pribadi yang didukung setiap layanan.

Jika mengetahui layanan terkelola yang dapat digunakan, 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 endpoint tunggal atau sebagai grup endpoint.

Pola umum untuk layanan aplikasi ditampilkan dalam diagram berikut. Layanan aplikasi di-deploy di 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 diatur sebagai sekumpulan backend yang dikaitkan 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 grup instance terkelola (MIG), Anda dapat meningkatkan atau mengurangi kapasitas layanan secara elastis dengan menskalakan otomatis endpoint yang membentuk backend load balancer. 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 membutuhkan dan dapat mendukung ketahanan regional atau global. Layanan software regional dapat dirancang untuk sinkronisasi dengan anggaran latensi regional. Layanan aplikasi global dapat mendukung failover sinkron di seluruh node yang didistribusikan di berbagai region. Jika aplikasi Anda bersifat global, Anda mungkin ingin layanan yang mendukungnya juga bersifat global. Namun, jika layanan Anda memerlukan sinkronisasi antar-instance-nya untuk mendukung failover, Anda harus mempertimbangkan latensi antar-region. Dalam situasi ini, Anda mungkin harus mengandalkan layanan regional dengan redundansi di region yang sama atau terdekat, sehingga mendukung sinkronisasi latensi rendah untuk failover.

Cloud Load Balancing mendukung endpoint yang dihosting dalam satu region atau didistribusikan di beberapa region. Dengan demikian, Anda dapat membuat lapisan global yang berhubungan langsung dengan pelanggan, yang berhubungan dengan lapisan layanan global, regional, atau hybrid. Pilih deployment layanan Anda untuk memastikan bahwa failover jaringan dinamis (atau load balancing lintas region) selaras dengan status ketahanan 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 utamanya 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.
  • Pada 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.
  • 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 lintas-regional dari frontend.
  • Frontend load balancer 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 menunjukkan 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 dalam infrastruktur load balancing konsumen. Failover lintas region layanan harus diterapkan dalam logika aplikasi layanan dan dalam desain load balancing dari produsen layanan. Mekanisme lain dapat diterapkan oleh produsen layanan.

Untuk menentukan produk Cloud Load Balancing 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 TLS offload.
  • 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 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 Serverless NEG sebagai backend ke 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, dan Cloud Functions mengirim paket ke alamat IPv4 internal resource di 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 atau grup pembanding luar di organisasi Anda, dan layanan yang dikembangkan 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. Ada jenis layanan berikut:

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

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

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

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

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

Ada dua jenis Private Service Connect, dan berbagai layanan dapat dipublikasikan sebagai salah satu jenis tersebut:

Layanan yang dipublikasikan sebagai endpoint Private Service Connect dapat digunakan langsung oleh workload lain. Layanan mengandalkan autentikasi 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 dalam 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 sehingga layanan produser 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 antara layanan terkelola di berbagai region
  • Konfigurasi keamanan terpusat dan kontrol akses untuk layanan terkelola

Dalam diagram berikut, load balancer global menggunakan NEG Private Service Connect sebagai backend yang menetapkan komunikasi ke penyedia layanan. Tidak diperlukan konfigurasi jaringan lebih lanjut dan data dibawa melalui fabric 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. Layanan yang dipublikasikan biasanya tidak dapat dijangkau di seluruh 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 HA-VPN dan proxy yang dikelola pelanggan menyediakan metode untuk memungkinkan komunikasi transitif antar-VPC.

Private Service Connect Endpoints 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 pada 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 tiap 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 pemakaian layanan

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

  • Alamat IP di subnet akses layanan pribadi
  • Endpoint Private Service Connect
  • VIP untuk load balancer 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 membuat titik akses layanan konsumen ke setiap grup aplikasi, atau mengelola akses ke layanan secara terkonsolidasi.

Pengelolaan akses layanan melibatkan aktivitas berikut:

  • Membuat titik akses
  • Men-deploy titik akses di VPC yang memiliki jenis jangkauan 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 menetapkan pengelolaan akses layanan ke tim pusat, sementara yang lain mungkin terstruktur untuk memberikan kemandirian yang lebih besar kepada setiap tim konsumen atau aplikasi. Produk sampingan dari operasi dalam mode khusus ini adalah beberapa elemen direplikasi. Misalnya, layanan didaftarkan dengan beberapa nama DNS oleh setiap grup aplikasi dan mengelola beberapa rangkaian 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 transitif titik akses layanan yang dimungkinkan oleh VPC layanan. VPC Layanan tidak terbatas hanya untuk menghosting titik akses konsumen. VPC dapat menghosting resource aplikasi, serta titik akses konsumen bersama. Dalam kasus semacam itu, VPC harus dikonfigurasi dan ditangani sebagai VPC layanan.

Akses layanan terkelola bersama

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

  • 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 melakukan peering ke jaringan lain melalui HA-VPN. Untuk Google API, iklankan alamat IP host API.
  • Perbarui aturan firewall multicloud untuk mengizinkan layanan pribadi mengakses subnet.

Khususnya 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 mengiklankan subnet reguler secara default
  • Membuat aturan firewall masuk untuk semua mengizinkan subnet akses VPC dalam VPC
  • Memperbarui 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 bagi layanan untuk 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 masuk untuk mengizinkan subnet konektor Akses VPC dalam VPC aplikasi

Merakit stack aplikasi

Bagian ini menjelaskan cara merakit stack aplikasi regional atau global.

Mendesain stack aplikasi regional

Saat 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 kemudian 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 atau pusat data lokal lain harus di-deploy di region yang setara di jaringan eksternal. Selain itu, siapkan layanan yang dipublikasikan 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 terdaftar di zona DNS yang relevan untuk setiap layanan aplikasi.

Diagram berikut menunjukkan stack regional dengan ketahanan aktif dalam mode standby:

Stack regional dengan ketahanan aktif-standby.

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

Jika kegagalan dilaporkan untuk salah satu lapisan layanan, frontend aplikasi akan ditempatkan ulang ke stack cadangan. Aplikasi ini 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

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

Diagram berikut menunjukkan stack aplikasi global:

Stack global menggunakan project hub dan project aplikasi.

Diagram sebelumnya menunjukkan aplikasi global yang disusun 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 pada instance workload. Instance workload tersebut berada di balik load balancer. Load balancer dapat dijangkau dari region mana pun di 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 VPN dengan ketersediaan tinggi (HA) antara VPC layanan dan VPC transit.
  • VPC produsen layanan yang dihosting oleh organisasi lain atau organisasi dan aplikasi utama 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. Cara 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.

Menyediakan akses pribadi ke layanan yang dihosting di jaringan eksternal

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

Titik akses lokal menggunakan NEG campuran.

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 memungkinkan klien di jaringan VPC lain menjangkau layanan hybrid yang berjalan di infrastruktur lokal atau di lingkungan cloud lainnya.

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

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

NEG campuran di depan layanan di jaringan lain.

Dalam diagram sebelumnya, lapisan layanan aplikasi sepenuhnya tersusun sepenuhnya 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 guna digunakan secara 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 dapat berupa VPC yang berbeda dengan VPC transportasi umum, karena berada dalam cakupan administratif organisasi atau project produsen, sehingga terpisah dari layanan transportasi umum umum. VPC produsen tidak perlu dihubungkan melalui peering VPC atau VPN HA-VPN dengan VPC konsumen (yang merupakan 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 pemusatan 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-frontasi dengan load balancer aplikasi, Anda dapat menggabungkan agar lebih sedikit load balancer menggunakan peta URL untuk mengarahkan traffic untuk backend layanan yang berbeda, daripada 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 campuran di seluruh VPC untuk sebagian besar jenis backend. Pengecualiannya adalah NEG atau backend Private Service Connect, seperti yang dijelaskan dalam Perang Eksplisit Load Balancer Google Cloud L7 dengan Private Service Connect.

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

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

Gunakan load balancing proxy untuk mendapatkan manfaat skala dari Network Connectivity Center yang menampilkan konektivitas VPC di seluruh VPC, sekaligus menyediakan 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 yang mengaktifkan Network Connectivity Center. Demikian pula, jaringan di balik koneksi hybrid (Cloud Interconnect atau HA-VPN) tidak dapat dijangkau di seluruh VPC yang menggunakan 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 disebarkan di seluruh VPC yang telah diucapkan dengan Network Connectivity Center. Penerapan ini memungkinkan keterjangkauan melalui Network Connectivity Center dari resource non-transitif 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 dalam project konsumen.

Pertimbangan lainnya

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

Pertimbangan bidang kontrol GKE

Bidang kontrol GKE di-deploy di project tenant terkelola Google yang 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 dan hub VPC tidak dimungkinkan.

Saat mempertimbangkan opsi desain GKE, seperti terpusat atau terdesentralisasi, akses langsung ke bidang kontrol dari sumber multicloud merupakan pertimbangan utama. Jika GKE di-deploy di VPC terpusat, akses ke bidang kontrol tersedia di cloud dan dalam Google 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 workload yang melibatkan data sensitif, gunakan Kontrol Layanan VPC untuk mengonfigurasi perimeter layanan di sekitar resource VPC dan layanan yang dikelola Google, serta mengontrol perpindahan data melintasi 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 masuk dan keluar Kontrol Layanan VPC dapat digunakan agar project dan layanan di perimeter layanan yang berbeda dapat 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 Security Foundations Blueprint.

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 dalam jaringan VPC konsumen layanan.

Langkah selanjutnya

Kontributor

Penulis:

Kontributor lainnya: