Pola traffic keluar dengan akses terbatas dan traffic masuk dengan akses terbatas menggunakan kombinasi traffic keluar dengan akses terbatas dan traffic masuk dengan akses terbatas untuk skenario yang menuntut penggunaan API yang dipilih secara dua arah di antara 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 memberikan autentikasi, otorisasi, dan 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 dan tujuan alamat IP 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 selaras 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 unit organisasi yang berbeda yang mengelola aplikasinya sendiri dan menghostingnya di lingkungan yang berbeda.
Komunikasi ini berfungsi 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 komputasi pribadi tidak dapat dijangkau.
- Sebaliknya, workload yang Anda deploy di lingkungan komputasi lainnya dapat berkomunikasi dengan gateway API sisi Google Cloud (atau alamat IP endpoint tertentu 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 traffic masuk dengan akses terbatas:
Pendekatan desain dalam diagram sebelumnya memiliki 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 lokal atau di cloud lainnya. Untuk memperluas lingkungan, gunakan pola komunikasi konektivitas hibrida dan multi-cloud yang sesuai untuk memfasilitasi komunikasi antar-lingkungan sehingga 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.
- Anda dapat menggunakan Cloud Next Generation Firewall atau virtual appliance jaringan (NVA) dengan firewall generasi berikutnya (NGFW) di VPC transit untuk memeriksa traffic dan mengizinkan atau melarang akses ke API tertentu dari sumber tertentu sebelum mencapai VPC aplikasi Anda.
- API harus diakses melalui API gateway 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 untuk memberikan alamat IP internal untuk aplikasi yang dipublikasikan.
- Semua lingkungan menggunakan ruang alamat IP RFC 1918 yang bebas tumpang-tindih.
Aplikasi umum dari pola ini melibatkan deployment backend aplikasi (atau sebagian backend aplikasi) di Google Cloud sambil menghosting komponen backend dan frontend lainnya di lingkungan lokal atau di cloud lain (pola hybrid bertingkat atau pola multicloud yang dipartisi). Seiring aplikasi berkembang dan dimigrasikan 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 dibuat 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 secara aman melalui koneksi jaringan hybrid yang telah dibuat dan difasilitasi oleh load balancer internal (ILB dalam diagram).
Menggunakan 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 standar di kedua sisi yang selaras dengan model komunikasi pola ini.
- Untuk menyediakan frontend global untuk aplikasi yang menghadap internet dengan komponen aplikasi terdistribusi (frontend atau backend), dan untuk mencapai sasaran berikut, Anda dapat menggunakan kemampuan keamanan dan load balancing lanjutan Google Cloud yang didistribusikan di point of presence (PoP):
- Kurangi belanja modal dan sederhanakan operasi dengan menggunakan layanan terkelola tanpa server.
- Optimalkan koneksi ke backend aplikasi secara global untuk kecepatan
dan latensi.
- Cross-Cloud Network Google Cloud memungkinkan komunikasi multi-cloud antar-komponen aplikasi melalui koneksi pribadi yang optimal.
- Menyimpan konten statis yang banyak diminati ke cache dan meningkatkan performa aplikasi untuk aplikasi yang menggunakan Cloud Load Balancing global dengan memberikan akses ke Cloud CDN.
- Lindungi frontend global aplikasi yang menghadap internet dengan menggunakan kemampuan Google Cloud Armor yang menyediakan layanan mitigasi DDoS dan firewall aplikasi web (WAF) yang didistribusikan secara global.
- Secara opsional, Anda dapat menyertakan Private Service Connect ke dalam desain. Tindakan ini memungkinkan akses pribadi yang terperinci ke API layanan Google Cloud atau layanan yang dipublikasikan dari lingkungan lain tanpa melewati internet publik.
Variasi
Pola arsitektur gate egress dan gate ingress dapat digabungkan dengan pendekatan lain untuk memenuhi persyaratan desain yang berbeda, sambil tetap mempertimbangkan persyaratan komunikasi pola ini. Pola ini 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 multicloud yang dipartisi, aplikasi (atau komponen aplikasi) dapat dibuat di berbagai lingkungan cloud —termasuk lingkungan lokal pribadi. Persyaratan umum adalah merutekan permintaan klien ke frontend aplikasi langsung ke lingkungan tempat aplikasi (atau komponen frontend) dihosting. Jenis komunikasi ini memerlukan load balancer lokal atau API gateway. Aplikasi ini dan komponennya mungkin juga memerlukan kemampuan platform API tertentu untuk integrasi.
Diagram berikut mengilustrasikan cara Apigee dan Apigee Hybrid dirancang untuk memenuhi persyaratan tersebut dengan gateway API yang dilokalkan di setiap lingkungan. Pengelolaan platform API terpusat di Google Cloud. Desain ini membantu menerapkan langkah-langkah kontrol akses yang ketat, dengan hanya alamat IP yang 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 berbagai arah di beberapa lingkungan.
- Fungsi API gateway di Google Cloud (Apigee) mengekspos komponen aplikasi (frontend atau backend) yang dihosting di Google Cloud.
- Fungsi gateway API di lingkungan lain (Hybrid) mengekspos komponen frontend (atau backend) aplikasi yang dihosting di lingkungan tersebut.
Secara opsional, Anda dapat mempertimbangkan untuk menggunakan VPC transit. VPC transit dapat memberikan fleksibilitas untuk memisahkan masalah dan melakukan inspeksi keamanan serta konektivitas hybrid di jaringan VPC terpisah. Dari sudut pandang keterjangkauan alamat IP, VPC transit (tempat konektivitas hybrid dilampirkan) memfasilitasi persyaratan berikut untuk mempertahankan keterjangkauan menyeluruh:
- Alamat IP untuk API target perlu diiklankan ke lingkungan lain tempat klien/peminta dihosting.
- Alamat IP untuk host yang perlu berkomunikasi dengan API target harus diiklankan ke lingkungan tempat API target berada, misalnya, alamat IP pemohon API (klien). Pengecualian terjadi saat 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. Desain ini memungkinkan permintaan API tertentu yang berasal dari beban kerja yang dihosting dalam VPC aplikasi Google Cloud untuk 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 langsung menggunakan gateway API (seperti Apigee), atau mungkin ingin menambahkannya nanti. Namun, mungkin ada persyaratan bisnis untuk memungkinkan 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 masing-masing yang dihosting di lingkungan yang berbeda (Google Cloud, lokal, atau di cloud lain), 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, sehingga memungkinkan akses aman dalam jaringan pribadi di seluruh region dan melalui konektivitas campuran. Abstraksi ini memfasilitasi integrasi resource dari berbagai cloud dan lingkungan on-premise melalui model konektivitas hybrid dan multicloud. Layanan ini juga memungkinkan pembuatan aplikasi di seluruh lingkungan multicloud dan lokal. Hal ini dapat memenuhi berbagai persyaratan komunikasi, seperti mengintegrasikan aplikasi aman saat gateway API tidak digunakan 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 transisi).
- 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 alur.
Komunikasi dua arah menggunakan endpoint dan antarmuka Private Service Connect
Seperti yang telah dibahas dalam pola ingress berpagar, 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 lain 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 tersebut, antarmuka Private Service Connect memungkinkan instance VM produsen layanan mengakses jaringan konsumen. Hal ini dilakukan dengan berbagi antarmuka jaringan, sambil tetap mempertahankan pemisahan peran produsen dan konsumen. Dengan antarmuka jaringan ini di VPC konsumen, VM aplikasi dapat mengakses resource konsumen seolah-olah berada secara lokal di VPC produsen.
Antarmuka Private Service Connect adalah antarmuka jaringan yang dilampirkan ke VPC konsumen (transit). Anda dapat menjangkau tujuan eksternal yang dapat dijangkau dari VPC konsumen (transit) tempat antarmuka Private Service Connect dilampirkan. 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 memiliki kemampuan untuk mengamankan komunikasi ke antarmuka Private Service Connect di VPC konsumen. Dalam skenario tersebut, 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 tidak mematuhi kepatuhan atau standar keamanan organisasi Anda.
Praktik terbaik
Untuk situasi saat permintaan klien dari internet perlu diterima secara lokal oleh frontend yang dihosting di lingkungan cloud lokal atau pribadi lainnya, pertimbangkan untuk menggunakan Hybrid sebagai solusi gateway API.
- Pendekatan ini juga memfasilitasi migrasi solusi ke lingkungan yang sepenuhnya dihosting Google Cloud sekaligus mempertahankan konsistensi platform API (Apigee).
Untuk meminimalkan latensi dan mengoptimalkan biaya untuk transfer data keluar dalam volume tinggi ke lingkungan Anda yang lain saat lingkungan tersebut berada dalam penyiapan hybrid atau multi-cloud jangka panjang atau permanen, pertimbangkan hal berikut:
- Gunakan Cloud Interconnect atau Cross-Cloud Interconnect.
- Untuk menghentikan koneksi pengguna di 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 jalur konektivitas dan pemilihan rute, Anda harus 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 memitigasi 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 yang diotorisasi. 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 beban kerja dan mengeksposnya ke internet publik.
- Untuk traffic web keluar, gunakan Secure Web Proxy. Proxy menawarkan beberapa manfaat.
Tinjau praktik terbaik umum untuk pola jaringan hybrid dan multicloud.