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 menyusun aplikasi dari serangkaian layanan komponen yang dipilih atau dibuat. Sebaiknya baca seluruh dokumen sekali sebelum mengikuti langkah-langkah tersebut.

Dokumen ini memandu Anda melalui keputusan berikut:

  • Baik 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 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 layanan
  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. Di beberapa dalam beberapa kasus, batasan dari transitivitas lintas VPC terbatas ada. Kita menjelaskan batasan ini jika dapat memengaruhi keputusan desain.

Tentukan apakah aplikasi Anda bersifat regional atau global

Tentukan apakah pelanggan aplikasi yang Anda buat membutuhkan atau arketipe deployment global. Anda bisa mencapai ketahanan regional dengan menyebarkan pemuatan di seluruh zona dari 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 Deployment Google Cloud arketipe.

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 di-{i>host <i}di CSP yang berbeda ke pusat data CSP yang lokasinya berdekatan satu sama lain.

Diagram berikut menunjukkan stack aplikasi global yang didistribusikan di berbagai {i>cloud<i} dan berbagai layanan aplikasi di-deploy di berbagai CSP. Masing-masing layanan aplikasi global memiliki instance workload di berbagai region pada CSP yang sama.

Stack aplikasi global yang didistribusikan di yang dihosting di Google 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.

Jika mengetahui layanan terkelola yang dapat digunakan, Anda dapat menentukan layanan 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 ditunjukkan dalam gambar berikut seperti diagram. Layanan aplikasi di-deploy ke kumpulan workload instance Compute Engine. (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 sekumpulan backend yang terkait dengan load balancer.

Diagram berikut menunjukkan load balancer generik 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 elastis dengan menskalakan endpoint yang membentuk backend load balancer. Selanjutnya, bergantung pada persyaratan layanan aplikasi, load balancer juga dapat memberikan otentikasi, penghentian TLS, dan koneksi tertentu.

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 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 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 dibangun dari beban regional dapat menjangkau backend di region lain, sehingga memberikan failover otomatis di seluruh region. Dalam contoh ini, logika aplikasi 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 region yang berbeda.

  • Backend global adalah kumpulan backend regional yang diakses oleh satu load balancer atau lebih.
  • 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 lintas-regional dari 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. 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 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 beban 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 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 oleh produser, Anda dapat menggunakan Akses VPC Serverless agar Cloud Run, App Engine menjadi standar, dan Lingkungan 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 layanan yang disediakan oleh vendor atau grup sejawat di luar 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. Jenis layanan berikut ada:

  • 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. Tergantung cara Anda mengalokasikan layanan, Anda dapat menggunakan satu atau lebih akses pribadi opsi yang dijelaskan.

Organisasi (atau kelompok dalam suatu organisasi) yang mengumpulkan, menerbitkan, dan mengelola layanan disebut sebagai produsen layanan. Anda dan aplikasi 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 ringkasan opsi untuk mengakses layanan secara pribadi, lihat Pribadi opsi akses 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 Deployment Private Service Connect yang sama.

Ada dua jenis Private Service Connect, layanan dapat dipublikasikan sebagai salah satu jenis berikut:

Layanan yang dipublikasikan sebagai endpoint Private Service Connect dapat digunakan langsung oleh beban kerja lain. Layanan mengandalkan otentikasi dan ketahanan yang disediakan oleh produsen layanan. Jika Anda menginginkan kontrol atas otentikasi dan ketahanan layanan, Anda dapat menggunakan Backend Private Service Connect untuk menambahkan lapisan load balancing untuk otentikasi 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 konsumen VPC, 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 Deployment Private Service Connect yang sama.

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 dengan 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. Jika layanan perlu memulai koneksi dari produsen, gunakan Private Service Connect antarmuka.

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 Pusat Konektivitas Jaringan. 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 dengan menggunakan Endpoint dan backend Private Service Connect. Penggunaan endpoint umumnya direkomendasikan karena Produsen API menyediakan ketahanan dan autentikasi berbasis sertifikat.

Membuat endpoint Private Service Connect di setiap VPC tempat layanan perlu diakses. Karena alamat IP konsumen bersifat global, Alamat IP, pemetaan DNS tunggal untuk setiap layanan diperlukan, bahkan jika ada di beberapa VPC, seperti yang ditampilkan dalam diagram:

Private Service Connect dengan Google API.

Menentukan pola pemakaian layanan

Layanan dapat berjalan di berbagai lokasi: jaringan VPC Anda, jaringan VPC lain jaringan, di pusat data lokal, atau di cloud. Di mana pun workload layanan berjalan, aplikasi Anda memakai layanan tersebut dengan menggunakan titik akses pengguna, 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 didedikasikan untuk jaringan tunggal. 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 (AP) di VPC yang memiliki jenis keterjangkauan
  • Mendaftarkan alamat IP dan URL titik akses konsumen di DNS
  • Mengelola sertifikat keamanan dan ketahanan untuk layanan di konsumen, saat menambahkan load balancing di hadapan akses konsumen poin

Untuk beberapa organisasi, mungkin layak untuk menetapkan pengelolaan akses layanan ke pusat sementara yang lain mungkin disusun untuk memberikan lebih banyak kemandirian kepada setiap konsumen atau tim aplikasi. Produk sampingan dari beroperasi dalam mode khusus adalah bahwa 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 kasus semacam itu, VPC harus dikonfigurasi dan ditangani sebagai layanan Jaringan VPC.

Akses layanan terkelola bersama

Untuk semua metode pemakaian 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 rute kustom iklan dari Cloud Router yang di-peering 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:

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

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

  • 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 multicloud untuk mengizinkan subnet konektor akses VPC
  • Membuat aturan firewall masuk untuk mengizinkan subnet akses layanan pribadi ke dalam 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 persyaratan:

  • 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 merakit stack aplikasi regional atau global.

Mendesain stack aplikasi regional

Saat aplikasi mengikuti deployment regional atau multi-regional arketipe, gunakan stack aplikasi regional. Stack aplikasi regional dapat dianggap sebagai penyambungan lapisan layanan aplikasi regional. Sebagai misalnya, lapisan layanan web regional yang berinteraksi dengan lapisan aplikasi di region yang sama, yang kemudian berhubungan dengan lapisan database di region yang sama, stack aplikasi regional.

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

Lapisan layanan aplikasi di CSP lain atau data lokal harus ditempatkan di region yang setara dalam 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-siaga.

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

Ketika kegagalan dilaporkan untuk salah satu lapisan layanan, frontend aplikasi ditempatkan ulang ke tumpukan 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

Ketika sebuah aplikasi mengikuti arketipe deployment aplikasi global, masing-masing 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 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. Tujuan titik akses load balancer dapat dijangkau melalui Cloud Interconnect dari VPC umum.
  • VPC transit menghosting koneksi hybrid pusat data eksternal dan VPC aplikasi.
  • VPC aplikasi yang menghosting aplikasi inti yang berjalan pada workload instance Compute Engine. Instance beban kerja ini berada di belakang load balancer. Beban dapat dijangkau dari region mana pun di jaringan dan bisa 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 yang dapat dijangkau melalui koneksi HA-VPN antara VPC layanan dan VPC umum.
  • VPC pembuat layanan yang dihosting oleh organisasi lain atau organisasi utama dan aplikasi yang berjalan di lokasi lain. Konten yang relevan layanan dibuat dapat dijangkau oleh backend Private Service Connect di-deploy sebagai backend global ke load balancer regional yang dihosting di VPC umum layanan. Load balancer regional dapat dijangkau dari region lain.

Jika Anda 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 region 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. Hal ini berarti 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 mempublikasikan titik akses lokal untuk layanan yang dihosting di jaringan. 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.

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

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.

Dalam diagram sebelumnya, lapisan layanan aplikasi sepenuhnya terdiri dari CSP yang berdekatan, yang disoroti di bagian diagram yang tidak berwarna abu-abu. Load balancer hybrid digunakan bersama lampiran layanan Private Service Connect sebagai mekanisme untuk mempublikasikan layanan aplikasi eksternal untuk konsumsi pribadi dalam Google Cloud. Load balancer hybrid dengan NEG campuran dan Lampiran layanan Private Service Connect berada di VPC yang 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 VPC peering atau HA-VPN dengan VPC konsumen (yaitu VPC Bersama 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 campuran di seluruh VPC mengorbankan hal-hal yang telah disebutkan 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 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, ingat 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 bisa men-deploy load balancer proxy di depan frontend layanan dan di depan 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 melalui Network Connectivity Center dari resource non-transitif melalui proxy dengan load balancer Jaringan Passthrough Eksternal Regional.

Mode terpusat menambahkan lapisan load balancing di sisi konsumen layanan. Saat Anda menggunakan mode ini, Anda juga perlu mengelola sertifikat, ketahanan, dan pemetaan DNS tambahan dalam proyek 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 cloud dan di 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 model pola desain ini, administrator jaringan dapat men-deploy koneksi koneksi agen yang bertindak sebagai proxy, sehingga mengatasi batasan peering non-transitif untuk 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. Kontrol Layanan VPC masuk dan keluar aturan dapat digunakan untuk mengizinkan project dan layanan di berbagai perimeter layanan untuk komunikasi (termasuk jaringan VPC yang tidak berada dalam keliling).

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, Private Service Connect dan Direktori Layanan membuat entri DNS secara otomatis untuk layanan di zona DNS pribadi di jaringan VPC konsumen layanan.

Langkah selanjutnya

Kontributor

Penulis:

Kontributor lainnya: