Pola traffic keluar dan masuk dengan akses terbatas menggunakan kombinasi traffic masuk dengan akses terbatas dan akses masuk terbatas untuk skenario yang mengharuskan penggunaan dua arah API yang dipilih antar-beban kerja. Workload dapat berjalan di Google Cloud, di lingkungan lokal pribadi, atau di lingkungan cloud lainnya. Dalam pola ini, Anda dapat menggunakan gateway API, endpoint Private Service Connect, atau load balancer untuk mengekspos API tertentu dan secara opsional menyediakan autentikasi, otorisasi, serta audit panggilan API.
Perbedaan utama antara pola ini dan pola mesh terletak pada penerapannya pada skenario yang hanya memerlukan penggunaan API dua arah atau komunikasi dengan sumber alamat IP dan tujuan tertentu—misalnya, aplikasi yang dipublikasikan melalui endpoint Private Service Connect. Karena komunikasi dibatasi untuk API yang diekspos atau alamat IP tertentu, jaringan di seluruh lingkungan tidak perlu diselaraskan dalam desain Anda. Skenario umum yang berlaku mencakup, tetapi tidak terbatas pada, hal berikut:
- Merger dan akuisisi.
- Integrasi aplikasi dengan partner.
- Integrasi antara aplikasi dan layanan organisasi dengan berbagai unit organisasi yang mengelola aplikasi mereka sendiri dan menghostingnya di lingkungan berbeda.
Komunikasinya berjalan sebagai berikut:
- Workload yang Anda deploy di Google Cloud dapat berkomunikasi dengan gateway API (atau alamat IP tujuan tertentu) menggunakan alamat IP internal. Sistem lain yang di-deploy di lingkungan cloud computing tidak dapat dijangkau.
- Sebaliknya, workload yang Anda deploy di lingkungan komputasi lain dapat berkomunikasi dengan gateway API sisi Google Cloud (atau alamat IP endpoint spesifik yang dipublikasikan) menggunakan alamat IP internal. Sistem lain yang di-deploy di Google Cloud tidak dapat dijangkau.
Arsitektur
Diagram berikut menunjukkan arsitektur referensi untuk pola traffic keluar dengan akses terbatas dan pola traffic masuk dengan gerbang:
Pendekatan desain dalam diagram sebelumnya memiliki elemen-elemen berikut:
- Di sisi Google Cloud, Anda men-deploy workload di VPC (atau VPC bersama) tanpa mengeksposnya langsung ke internet.
- Jaringan lingkungan Google Cloud diperluas ke lingkungan komputasi lainnya. Lingkungan tersebut dapat berada di infrastruktur lokal atau di cloud lain. Untuk memperluas lingkungan, gunakan pola komunikasi konektivitas hybrid dan multicloud yang sesuai untuk memfasilitasi komunikasi antarlingkungan, sehingga keduanya dapat menggunakan alamat IP internal.
- Secara opsional, dengan mengaktifkan akses ke alamat IP target tertentu, Anda dapat menggunakan VPC transit untuk membantu menambahkan lapisan keamanan perimeter di luar VPC aplikasi.
- Anda dapat menggunakan Firewall atau peralatan virtual jaringan (NVA) Cloud Next Generation dengan firewall generasi berikutnya (NGFW) di VPC transit untuk memeriksa traffic dan untuk mengizinkan atau melarang akses ke API tertentu dari sumber tertentu sebelum mencapai VPC aplikasi Anda.
- API harus diakses melalui gateway API atau load balancer untuk menyediakan lapisan proxy, dan abstraksi atau fasad untuk API layanan Anda.
- Untuk aplikasi yang digunakan sebagai API, Anda juga dapat menggunakan Private Service Connect guna memberikan alamat IP internal untuk aplikasi yang dipublikasikan.
- Semua lingkungan menggunakan ruang alamat IP RFC 1918 bebas tumpang-tindih.
Penerapan umum dari pola ini melibatkan deployment backend aplikasi (atau subset backend aplikasi) di Google Cloud saat menghosting komponen backend dan frontend lainnya di lingkungan lokal atau di cloud lainnya (pola hibrida bertingkat atau pola multicloud berpartisi). Seiring aplikasi berkembang dan bermigrasi ke cloud, dependensi dan preferensi untuk layanan cloud tertentu sering kali muncul.
Terkadang, dependensi dan preferensi ini menyebabkan distribusi aplikasi dan backend di berbagai penyedia cloud. Selain itu, beberapa aplikasi mungkin di-build dengan kombinasi resource dan layanan yang didistribusikan di seluruh lingkungan lokal dan beberapa lingkungan cloud.
Untuk aplikasi terdistribusi, kemampuan konektivitas hybrid dan multicloud Cloud Load Balancing eksternal dapat digunakan untuk menghentikan permintaan pengguna dan merutekannya ke frontend atau backend di lingkungan lain. Pemilihan rute ini terjadi melalui koneksi jaringan hybrid, seperti yang diilustrasikan dalam diagram berikut. Integrasi ini memungkinkan distribusi komponen aplikasi secara bertahap di berbagai lingkungan. Permintaan dari frontend ke layanan backend yang dihosting di Google Cloud berkomunikasi dengan aman melalui koneksi jaringan hybrid yang sudah dibuat yang difasilitasi oleh load balancer internal (ILB dalam diagram).
Penggunaan desain Google Cloud dalam diagram sebelumnya akan membantu hal-hal berikut:
- Memfasilitasi komunikasi dua arah antara Google Cloud, lokal, dan lingkungan cloud lainnya menggunakan API yang telah ditetapkan di kedua sisi yang selaras dengan model komunikasi pola ini.
- Guna menyediakan frontend global untuk aplikasi yang terhubung ke internet dengan komponen aplikasi terdistribusi (frontend atau backend), dan untuk mencapai sasaran berikut, Anda dapat menggunakan kemampuan keamanan dan load balancing lanjutan dari Google Cloud yang didistribusikan di titik kehadiran (PoP):
- Kurangi biaya modal dan sederhanakan operasi dengan menggunakan layanan terkelola serverless.
- Optimalkan koneksi ke backend aplikasi secara global untuk mendapatkan kecepatan dan latensi.
- Jaringan Lintas Cloud Google Cloud memungkinkan komunikasi multicloud antara komponen aplikasi melalui koneksi pribadi yang optimal.
- Simpan konten statis dengan permintaan tinggi dan tingkatkan performa aplikasi untuk aplikasi menggunakan Cloud Load Balancing global dengan memberikan akses ke Cloud CDN.
- Amankan frontend global dari aplikasi yang terhubung ke internet menggunakan kapabilitas Google Cloud Armor yang menyediakan firewall aplikasi web (WAF) dan layanan mitigasi DDoS (WAF) yang terdistribusi secara global.
- Secara opsional, Anda dapat menyertakan Private Service Connect ke dalam desain Anda. Tindakan ini akan memungkinkan akses pribadi dan terperinci ke Google Cloud Service API atau layanan yang Anda publikasikan dari lingkungan lain tanpa perlu melewati internet publik.
Variasi
Pola arsitektur traffic keluar dan masuk dengan akses terbatas dapat digabungkan dengan pendekatan lain untuk memenuhi persyaratan desain yang berbeda, sambil tetap mempertimbangkan persyaratan komunikasi pola ini. Pola tersebut menawarkan opsi berikut:
- Gateway API terdistribusi
- Komunikasi API dua arah menggunakan Private Service Connect
- Komunikasi dua arah menggunakan endpoint dan antarmuka Private Service Connect
Gateway API terdistribusi
Dalam skenario seperti yang didasarkan pada pola cloud berpartisi, aplikasi (atau komponen aplikasi) dapat dibangun di berbagai lingkungan cloud, termasuk lingkungan lokal pribadi. Persyaratan umumnya adalah mengarahkan permintaan klien ke frontend aplikasi secara langsung ke lingkungan tempat aplikasi (atau komponen frontend) dihosting. Komunikasi semacam ini memerlukan load balancer lokal atau gateway API. Aplikasi ini dan komponennya mungkin juga memerlukan kemampuan platform API tertentu untuk integrasi.
Diagram berikut menggambarkan bagaimana Apigee dan Apigee Hybrid dirancang untuk memenuhi persyaratan tersebut dengan gateway API yang dilokalkan di setiap lingkungan. Pengelolaan platform API dipusatkan di Google Cloud. Desain ini membantu menerapkan langkah-langkah kontrol akses yang ketat di mana hanya alamat IP yang telah disetujui sebelumnya (API target dan tujuan atau alamat IP endpoint Private Service Connect) yang dapat berkomunikasi antara Google Cloud dan lingkungan lainnya.
Daftar berikut menjelaskan dua jalur komunikasi yang berbeda dalam diagram sebelumnya yang menggunakan gateway API Apigee:
- Permintaan klien tiba di frontend aplikasi secara langsung di lingkungan yang menghosting aplikasi (atau komponen frontend).
- Gateway dan proxy API dalam setiap lingkungan menangani permintaan API klien dan aplikasi dalam arah yang berbeda di beberapa lingkungan.
- Fungsionalitas gateway API di Google Cloud (Apigee) mengekspos komponen aplikasi (frontend atau backend) yang dihosting di Google Cloud.
- Fungsionalitas gateway API di lingkungan lain (Hybrid) mengekspos komponen frontend aplikasi (atau backend) yang dihosting di lingkungan tersebut.
Secara opsional, Anda dapat mempertimbangkan untuk menggunakan VPC transit. VPC transit dapat memberikan fleksibilitas untuk memisahkan masalah serta melakukan pemeriksaan keamanan dan konektivitas hybrid dalam jaringan VPC yang terpisah. Dari sudut pandang keterjangkauan alamat IP, VPC transit (tempat konektivitas hybrid terpasang) memfasilitasi persyaratan berikut untuk mempertahankan keterjangkauan end-to-end:
- Alamat IP untuk API target harus diiklankan ke lingkungan lain tempat klien/peminta dihosting.
- Alamat IP untuk host yang perlu berkomunikasi dengan API target harus diberitahukan ke lingkungan tempat API target berada—misalnya, alamat IP pemohon API (klien). Pengecualiannya adalah jika komunikasi terjadi melalui load balancer, proxy, endpoint Private Service Connect, atau instance NAT.
Untuk memperluas konektivitas ke lingkungan jarak jauh, desain ini menggunakan peering VPC langsung dengan kemampuan pertukaran rute pelanggan. Dengan desain ini, permintaan API tertentu yang berasal dari workload yang dihosting dalam VPC aplikasi Google Cloud dapat dirutekan melalui VPC transit. Atau, Anda dapat menggunakan endpoint Private Service Connect di VPC aplikasi yang dikaitkan dengan load balancer dengan backend grup endpoint jaringan hybrid di VPC transit. Penyiapan tersebut dijelaskan di bagian berikutnya: Komunikasi API dua arah menggunakan Private Service Connect.
Komunikasi API dua arah menggunakan Private Service Connect
Terkadang, perusahaan mungkin tidak perlu segera menggunakan gateway API (seperti Apigee), atau mungkin ingin menambahkannya nanti. Namun, mungkin ada persyaratan bisnis untuk mengaktifkan komunikasi dan integrasi antara aplikasi tertentu di lingkungan yang berbeda. Misalnya, jika perusahaan Anda mengakuisisi perusahaan lain, Anda mungkin perlu mengekspos aplikasi tertentu ke perusahaan tersebut. Mereka mungkin perlu mengekspos aplikasi ke perusahaan Anda. Kedua perusahaan mungkin memiliki workload sendiri yang dihosting di lingkungan berbeda (Google Cloud, lokal, atau di cloud lainnya), dan harus menghindari tumpang tindih alamat IP. Dalam hal ini, Anda dapat menggunakan Private Service Connect untuk memfasilitasi komunikasi yang efektif.
Untuk aplikasi yang digunakan sebagai API, Anda juga dapat menggunakan Private Service Connect untuk memberikan alamat pribadi bagi aplikasi yang dipublikasikan, yang memungkinkan akses aman dalam jaringan pribadi di seluruh region dan melalui konektivitas hybrid. Abstraksi ini memfasilitasi integrasi resource dari beragam cloud dan lingkungan lokal melalui model konektivitas hybrid dan multicloud. Cloud SQL juga memungkinkan perakitan aplikasi di seluruh lingkungan multicloud dan lokal. Hal ini dapat memenuhi persyaratan komunikasi yang berbeda, seperti mengintegrasikan aplikasi aman yang tidak menggunakan gateway API atau tidak direncanakan untuk digunakan.
Dengan menggunakan Private Service Connect dengan Cloud Load Balancing, seperti yang ditunjukkan dalam diagram berikut, Anda dapat mencapai dua jalur komunikasi yang berbeda. Setiap jalur dimulai dari arah yang berbeda untuk tujuan konektivitas terpisah, idealnya melalui panggilan API.
- Semua pertimbangan desain dan rekomendasi Private Service Connect yang dibahas dalam panduan ini berlaku untuk desain ini.
- Jika pemeriksaan Lapisan 7 tambahan diperlukan, Anda dapat mengintegrasikan NVA dengan desain ini (di VPC transit).
- Desain ini dapat digunakan dengan atau tanpa gateway API.
Dua jalur konektivitas yang digambarkan dalam diagram sebelumnya mewakili koneksi independen dan tidak menggambarkan komunikasi dua arah dari satu koneksi atau flow.
Komunikasi dua arah menggunakan endpoint dan antarmuka Private Service Connect
Seperti yang dibahas dalam pola gated ingress, salah satu opsi untuk mengaktifkan komunikasi layanan klien adalah dengan menggunakan endpoint Private Service Connect untuk mengekspos layanan di VPC produsen ke VPC konsumen. Konektivitas tersebut dapat diperluas ke lingkungan lokal atau bahkan lingkungan penyedia cloud lainnya melalui konektivitas hybrid. Namun, dalam beberapa skenario, layanan yang dihosting juga dapat memerlukan komunikasi pribadi.
Untuk mengakses layanan tertentu, seperti mengambil data dari sumber data yang dapat dihosting dalam VPC konsumen atau di luarnya, komunikasi pribadi ini dapat dilakukan antara VPC aplikasi (produsen) dan lingkungan jarak jauh, seperti lingkungan lokal.
Dalam skenario seperti ini, antarmuka Private Service Connect memungkinkan instance VM produsen layanan mengakses jaringan konsumen. Hal ini dilakukan dengan membagikan antarmuka jaringan, sambil tetap mempertahankan pemisahan peran produsen dan konsumen. Dengan antarmuka jaringan di VPC konsumen ini, VM aplikasi dapat mengakses resource konsumen seolah-olah berada secara lokal di VPC produsen.
Antarmuka Private Service Connect adalah antarmuka jaringan yang terpasang pada VPC konsumen (transit). Anda dapat menjangkau tujuan eksternal yang dapat dijangkau dari VPC konsumen (transit) tempat antarmuka Private Service Connect terhubung. Oleh karena itu, koneksi ini dapat diperluas ke lingkungan eksternal melalui konektivitas hybrid seperti lingkungan lokal, seperti yang diilustrasikan dalam diagram berikut:
Jika VPC konsumen adalah organisasi atau entitas eksternal, seperti organisasi pihak ketiga, biasanya Anda tidak akan dapat mengamankan komunikasi ke antarmuka Private Service Connect di VPC konsumen. Dalam skenario seperti ini, Anda dapat menentukan kebijakan keamanan di OS tamu VM antarmuka Private Service Connect. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi keamanan untuk antarmuka Private Service Connect. Atau, Anda dapat mempertimbangkan pendekatan alternatif jika pendekatan tersebut tidak mematuhi standar atau kepatuhan keamanan organisasi Anda.
Praktik terbaik
Jika permintaan klien dari internet harus diterima secara lokal oleh frontend yang dihosting di lingkungan lokal pribadi atau lingkungan cloud lainnya, pertimbangkan untuk menggunakan Hybrid sebagai solusi gateway API.
- Pendekatan ini juga memfasilitasi migrasi solusi ke lingkungan yang sepenuhnya dihosting Google Cloud sambil mempertahankan konsistensi platform API (Apigee).
Guna meminimalkan latensi dan mengoptimalkan biaya untuk transfer data keluar dalam volume tinggi ke lingkungan Anda yang lain saat lingkungan tersebut berada dalam konfigurasi hybrid atau multicloud jangka panjang atau permanen, pertimbangkan hal berikut:
- Menggunakan Cloud Interconnect atau Cross-Cloud Interconnect.
- Untuk menghentikan koneksi pengguna pada frontend yang ditargetkan di lingkungan yang sesuai, gunakan Hybrid.
Jika berlaku untuk persyaratan dan arsitektur Anda, gunakan Adaptor Apigee untuk Envoy dengan Deployment hybrid dengan Kubernetes.
Sebelum mendesain konektivitas dan jalur pemilihan rute, Anda harus terlebih dahulu mengidentifikasi traffic atau permintaan API yang perlu diarahkan ke gateway API lokal atau jarak jauh, beserta lingkungan sumber dan tujuan.
Gunakan Kontrol Layanan VPC untuk melindungi layanan Google Cloud dalam project Anda dan mengurangi risiko pemindahan data yang tidak sah, dengan menentukan perimeter layanan di tingkat project atau jaringan VPC.
- Anda dapat memperluas perimeter layanan ke lingkungan hybrid melalui VPN atau Cloud Interconnect resmi. Untuk mengetahui informasi selengkapnya tentang manfaat perimeter layanan, lihat Ringkasan Kontrol Layanan VPC.
Gunakan aturan firewall Virtual Private Cloud (VPC) atau kebijakan firewall untuk mengontrol akses tingkat jaringan ke resource Private Service Connect melalui endpoint Private Service Connect. Misalnya, aturan firewall keluar di VPC aplikasi (konsumen) dapat membatasi akses dari instance VM ke alamat IP atau subnet endpoint Anda.
Saat menggunakan antarmuka Private Service Connect, Anda harus melindungi komunikasi ke antarmuka dengan mengonfigurasi keamanan untuk antarmuka Private Service Connect.
Jika beban kerja di subnet pribadi memerlukan akses internet, gunakan Cloud NAT untuk menghindari penetapan alamat IP eksternal ke workload dan mengeksposnya ke internet publik.
- Untuk traffic web keluar, gunakan Proxy Web Aman. Proxy ini menawarkan sejumlah manfaat.
Tinjau praktik terbaik umum untuk pola jaringan hybrid dan multicloud.