Share via

Pendekatan arsitektural untuk jaringan dalam solusi multipenyewa

  • Artikel

Semua solusi yang disebarkan ke Azure memerlukan jaringan. Bergantung pada desain solusi dan beban kerja Anda, cara Anda berinteraksi dengan layanan jaringan Azure mungkin berbeda. Dalam artikel ini, kami memberikan pertimbangan dan panduan untuk aspek jaringan solusi multipenyewa di Azure. Kami menyertakan informasi tentang komponen jaringan tingkat bawah, seperti jaringan virtual, hingga pendekatan tingkat yang lebih tinggi dan tingkat aplikasi.

Catatan

Azure sendiri adalah lingkungan multipenyewa, dan komponen jaringan Azure dirancang untuk multitenansi. Meskipun tidak diperlukan untuk memahami detail untuk merancang solusi Anda sendiri, Anda dapat mempelajari lebih lanjut tentang bagaimana Azure mengisolasi lalu lintas jaringan virtual Anda dari lalu lintas pelanggan lain.

Pertimbangan dan persyaratan utama

Layanan infrastruktur dan platform

Kekhawatiran yang Anda miliki untuk komponen jaringan Anda akan berbeda, tergantung pada kategori layanan yang Anda gunakan.

Layanan infrastruktur

Setiap kali Anda menggunakan layanan infrastruktur, seperti komputer virtual atau Azure Kubernetes Service, Anda perlu mempertimbangkan dan merancang jaringan virtual, atau VNet, yang mendukung konektivitas layanan Anda. Anda juga perlu mempertimbangkan lapisan keamanan dan isolasi lain yang perlu Anda masukkan dalam desain Anda. Hindari mengandalkan kontrol lapisan jaringan secara eksklusif.

Layanan platform

Jika Anda menggunakan layanan platform Azure, seperti App Service, Azure Cosmos DB, atau Azure SQL Database, arsitektur tertentu yang Anda gunakan akan menentukan layanan jaringan yang Anda butuhkan.

Jika Anda perlu mengisolasi layanan platform Anda dari internet, Anda perlu menggunakan VNet. Bergantung pada layanan tertentu yang Anda gunakan, Anda mungkin bekerja dengan titik akhir privat atau sumber daya terintegrasi VNet, seperti Application Gateway. Namun, Anda juga dapat memilih untuk membuat layanan platform Anda tersedia melalui alamat IP publik mereka, dan menggunakan perlindungan layanan itu sendiri seperti firewall dan kontrol identitas. Dalam situasi ini, Anda mungkin tidak memerlukan VNet.

Keputusan apakah akan menggunakan VNet untuk layanan platform didasarkan pada banyak persyaratan, termasuk faktor-faktor berikut:

  • Persyaratan kepatuhan: Anda mungkin perlu memenuhi standar kepatuhan tertentu. Beberapa standar mengharuskan lingkungan Azure Anda dikonfigurasi dengan cara tertentu.
  • Persyaratan penyewa Anda: Bahkan jika organisasi Anda sendiri tidak memiliki persyaratan khusus untuk isolasi atau kontrol lapisan jaringan, penyewa Anda mungkin. Pastikan Anda memiliki pemahaman yang jelas tentang bagaimana penyewa Anda akan mengakses solusi Anda dan apakah mereka memiliki asumsi tentang desain jaringannya.
  • Kompleksitas: Bisa lebih kompleks untuk memahami dan bekerja dengan jaringan virtual. Pastikan tim Anda memiliki pemahaman yang jelas tentang prinsip-prinsip yang terlibat, atau Anda cenderung menyebarkan lingkungan yang tidak aman.

Pastikan Anda memahami implikasi penggunaan jaringan privat.

Ukuran subnet

Saat Anda perlu menyebarkan VNet, penting untuk mempertimbangkan ukuran dan ruang alamat seluruh VNet dan subnet dengan hati-hati dalam VNet.

Pastikan Anda memiliki pemahaman yang jelas tentang bagaimana Anda akan menyebarkan sumber daya Azure ke VNet, dan jumlah alamat IP yang digunakan setiap sumber daya. Jika Anda menyebarkan simpul komputasi khusus penyewa, server database, atau sumber daya lainnya, pastikan Anda membuat subnet yang cukup besar untuk pertumbuhan penyewa yang diharapkan dan penskalaan otomatis horizontal sumber daya.

Demikian pula, ketika Anda bekerja dengan layanan terkelola, penting bagi Anda untuk memahami bagaimana alamat IP dikonsumsi. Misalnya, ketika Anda menggunakan Azure Kubernetes Service dengan Azure Container Networking Interface (Azure CNI), jumlah alamat IP yang digunakan dari subnet akan didasarkan pada faktor-faktor seperti jumlah simpul, cara Anda menskalakan secara horizontal, dan proses penyebaran layanan yang Anda gunakan. Saat Anda menggunakan Azure App Service dan Azure Functions dengan integrasi VNet, jumlah alamat IP yang digunakan didasarkan pada jumlah instans paket.

Tinjau panduan segmentasi subnet saat merencanakan subnet Anda.

Akses publik atau privat

Pertimbangkan apakah penyewa Anda akan mengakses layanan Anda melalui internet atau melalui alamat IP privat.

Untuk akses berbasis internet (publik), Anda dapat menggunakan aturan firewall, daftar alamat IP yang diizinkan dan ditolak, rahasia dan kunci bersama, dan kontrol berbasis identitas untuk mengamankan layanan Anda.

Jika Anda perlu mengaktifkan konektivitas ke layanan Anda dengan menggunakan alamat IP privat, pertimbangkan untuk menggunakan Azure Private Link Service atau peering jaringan virtual lintas penyewa. Untuk beberapa skenario terbatas, Anda mungkin juga mempertimbangkan untuk menggunakan Azure ExpressRoute atau Azure VPN Gateway untuk mengaktifkan akses privat ke solusi Anda. Kami hanya menyarankan agar Anda menggunakan pendekatan ini ketika Anda memiliki sejumlah kecil penyewa, dan menyebarkan VNet khusus untuk setiap penyewa.

Akses ke titik akhir penyewa

Pertimbangkan apakah Anda perlu mengirim data ke titik akhir dalam jaringan penyewa, baik di dalam atau di luar Azure. Misalnya, apakah Anda perlu memanggil webhook yang disediakan oleh pelanggan, atau apakah Anda perlu mengirim pesan real-time ke penyewa?

Jika Anda perlu mengirim data ke titik akhir penyewa, pertimbangkan pendekatan umum berikut:

  • Mulai koneksi dari solusi Anda ke titik akhir penyewa melalui internet. Pertimbangkan apakah koneksi harus berasal dari alamat IP statis. Bergantung pada layanan Azure yang Anda gunakan, Anda mungkin perlu menyebarkan NAT Gateway, firewall, atau load balancer.
  • Sebarkan agen untuk mengaktifkan konektivitas antara layanan yang dihosting Azure dan jaringan pelanggan Anda, terlepas dari lokasinya.
  • Untuk olahpesan satu arah, pertimbangkan untuk menggunakan layanan seperti Azure Event Grid, dengan atau tanpa domain peristiwa.

Pendekatan dan pola yang perlu dipertimbangkan

Di bagian ini, kami menjelaskan beberapa pendekatan jaringan utama yang dapat Anda pertimbangkan dalam solusi multipenyewa. Kita mulai dengan menjelaskan pendekatan tingkat bawah untuk komponen jaringan inti, dan kemudian mengikuti dengan pendekatan yang dapat Anda pertimbangkan untuk HTTP dan masalah lapisan aplikasi lainnya.

VNet khusus penyewa dengan alamat IP yang dipilih penyedia layanan

Dalam beberapa situasi, Anda perlu menjalankan sumber daya khusus yang terhubung dengan VNet di Azure atas nama penyewa. Misalnya, Anda mungkin menjalankan komputer virtual untuk setiap penyewa, atau Anda mungkin perlu menggunakan titik akhir privat untuk mengakses database khusus penyewa.

Pertimbangkan untuk menyebarkan VNet untuk setiap penyewa, dengan menggunakan ruang alamat IP yang Anda kontrol. Pendekatan ini memungkinkan Anda untuk mengintip VNet bersama-sama untuk tujuan Anda sendiri, seperti jika Anda perlu membuat topologi hub dan spoke untuk mengontrol masuk dan keluar lalu lintas secara terpusat.

Namun, alamat IP yang dipilih penyedia layanan tidak sesuai jika penyewa perlu terhubung langsung ke VNet yang Anda buat, seperti dengan menggunakan peering VNet. Kemungkinan ruang alamat yang Anda pilih tidak akan kompatibel dengan ruang alamat mereka sendiri.

VNet khusus penyewa dengan alamat IP yang dipilih penyewa

Jika penyewa perlu mengintip VNet mereka sendiri dengan VNet yang Anda kelola atas nama mereka, pertimbangkan untuk menyebarkan VNet khusus penyewa dengan ruang alamat IP yang dipilih penyewa. Sistem ini memungkinkan setiap penyewa untuk memastikan bahwa rentang alamat IP di VNet sistem Anda tidak tumpang tindih dengan VNet mereka sendiri. Dengan menggunakan rentang alamat IP yang tidak tumpang tindih, mereka dapat memastikan jaringan mereka kompatibel untuk peering.

Namun, pendekatan ini berarti tidak mungkin Anda dapat mengintip VNet penyewa Anda bersama-sama atau mengadopsi topologi hub dan spoke, karena kemungkinan ada rentang alamat IP yang tumpang tindih di antara VNet dari penyewa yang berbeda.

Topologi hub dan spoke

Topologi VNet hub dan spoke memungkinkan Anda mengintip VNet hub terpusat dengan beberapa VNet spoke. Anda dapat mengontrol masuk dan keluar lalu lintas untuk VNet Anda secara terpusat, dan mengontrol apakah sumber daya di setiap VNet spoke dapat berkomunikasi satu sama lain. Setiap VNet spoke juga dapat mengakses komponen bersama, seperti Azure Firewall, dan mungkin dapat menggunakan layanan seperti Azure DDoS Protection.

Saat Anda menggunakan topologi hub dan spoke, pastikan Anda merencanakan batas, seperti jumlah maksimum VNet yang di-peering, dan memastikan bahwa Anda tidak menggunakan ruang alamat yang tumpang tindih untuk VNet setiap penyewa.

Topologi hub dan spoke dapat berguna saat Anda menyebarkan VNet khusus penyewa dengan alamat IP yang Anda pilih. VNet setiap penyewa menjadi spoke, dan dapat berbagi sumber daya umum Anda di VNet hub. Anda juga dapat menggunakan topologi hub dan spoke saat menskalakan sumber daya bersama di beberapa VNet untuk tujuan skala, atau saat Anda menggunakan pola Stempel Penyebaran.

Tip

Jika solusi Anda berjalan di beberapa wilayah geografis, biasanya praktik yang baik untuk menyebarkan hub terpisah dan sumber daya hub di setiap wilayah. Meskipun praktik ini menimbulkan biaya sumber daya yang lebih tinggi, praktik ini menghindari lalu lintas melalui beberapa wilayah Azure yang tidak perlu, yang dapat meningkatkan latensi permintaan dan dikenakan biaya peering global.

Alamat IP statis

Pertimbangkan apakah penyewa Anda memerlukan layanan Anda untuk menggunakan alamat IP publik statis untuk lalu lintas masuk, lalu lintas keluar, atau keduanya. Layanan Azure yang berbeda memungkinkan alamat IP statis dengan cara yang berbeda.

Saat Anda bekerja dengan komputer virtual dan komponen infrastruktur lainnya, pertimbangkan untuk menggunakan load balancer atau firewall untuk alamat IP statis masuk dan keluar. Pertimbangkan untuk menggunakan NAT Gateway untuk mengontrol alamat IP lalu lintas keluar. Untuk informasi selengkapnya tentang menggunakan NAT Gateway dalam solusi multipenyewa, lihat Pertimbangan Azure NAT Gateway untuk multipenyewa.

Saat Anda bekerja dengan layanan platform, layanan tertentu yang Anda gunakan menentukan apakah dan bagaimana Anda dapat mengontrol alamat IP. Anda mungkin perlu mengonfigurasi sumber daya dengan cara tertentu, seperti dengan menyebarkan sumber daya ke VNet dan dengan menggunakan NAT Gateway atau firewall. Atau, Anda dapat meminta sekumpulan alamat IP saat ini yang digunakan layanan untuk lalu lintas keluar. Misalnya, App Service menyediakan API dan antarmuka web untuk mendapatkan alamat IP keluar saat ini untuk aplikasi Anda.

Agen

Jika Anda perlu mengaktifkan penyewa Anda untuk menerima pesan yang dimulai oleh solusi Anda, atau jika Anda perlu mengakses data yang ada di jaringan penyewa sendiri, maka pertimbangkan untuk menyediakan agen (kadang-kadang disebut gateway lokal) yang dapat mereka sebarkan dalam jaringan mereka. Pendekatan ini dapat berfungsi apakah jaringan penyewa Anda berada di Azure, di penyedia cloud lain, atau lokal.

Agen memulai koneksi keluar ke titik akhir yang Anda tentukan dan kontrol, dan menjaga koneksi jangka panjang tetap hidup atau polling secara terputus-putus. Pertimbangkan untuk menggunakan Azure Relay untuk membuat dan mengelola koneksi dari agen Anda ke layanan Anda. Saat agen membuat koneksi, agen mengautentikasi dan menyertakan beberapa informasi tentang pengidentifikasi penyewa sehingga layanan Anda dapat memetakan koneksi ke penyewa yang benar.

Agen biasanya menyederhanakan konfigurasi keamanan untuk penyewa Anda. Ini bisa menjadi kompleks dan berisiko untuk membuka port masuk, terutama di lingkungan lokal. Agen menghindari kebutuhan penyewa untuk mengambil risiko ini.

Contoh layanan Microsoft yang menyediakan konektivitas kepada agen ke jaringan penyewa meliputi:

Layanan Azure Private Link menyediakan konektivitas privat dari lingkungan Azure penyewa ke solusi Anda. Penyewa juga dapat menggunakan layanan Private Link dengan VNet mereka sendiri, untuk mengakses layanan Anda dari lingkungan lokal. Azure dengan aman merutekan lalu lintas ke layanan menggunakan alamat IP privat.

Untuk informasi selengkapnya tentang Private Link dan multitenancy, lihat Multitenancy dan Azure Private Link.

Nama domain, subdomain, dan TLS

Saat Anda bekerja dengan nama domain dan keamanan lapisan transportasi (TLS) dalam solusi multipenyewa, ada sejumlah pertimbangan. Tinjau pertimbangan untuk multitenansi dan nama domain.

Pola Perutean Gateway dan Offloading Gateway

Pola Perutean Gateway dan pola Gateway Offloading melibatkan penyebaran proksi atau gateway terbalik lapisan 7. Gateway berguna untuk menyediakan layanan inti untuk aplikasi multipenyewa, termasuk kemampuan berikut:

  • Permintaan perutean ke backend atau stempel penyebaran khusus penyewa.
  • Menangani nama domain khusus penyewa dan sertifikat TLS.
  • Memeriksa permintaan ancaman keamanan, dengan menggunakan firewall aplikasi web (WAF).
  • Respons penembolokan untuk meningkatkan performa.

Azure menyediakan beberapa layanan yang dapat digunakan untuk mencapai beberapa atau semua tujuan ini, termasuk Azure Front Door, Azure Application Gateway, dan Azure API Management. Anda juga dapat menyebarkan solusi kustom Anda sendiri, dengan menggunakan perangkat lunak seperti NGINX atau HAProxy.

Jika Anda berencana untuk menyebarkan gateway untuk solusi Anda, praktik yang baik adalah terlebih dahulu membangun prototipe lengkap yang mencakup semua fitur yang Anda butuhkan, dan untuk memverifikasi bahwa komponen aplikasi Anda terus berfungsi seperti yang Anda harapkan. Anda juga harus memahami bagaimana komponen gateway akan menskalakan untuk mendukung lalu lintas dan pertumbuhan penyewa Anda.

Pola Hosting Konten Statik

Pola Hosting Konten Statis melibatkan penyajian konten web dari layanan penyimpanan cloud-native, dan menggunakan jaringan pengiriman konten (CDN) untuk menyimpan konten.

Anda dapat menggunakan Azure Front Door atau CDN lain untuk komponen statis solusi Anda, seperti aplikasi JavaScript satu halaman, dan untuk konten statis seperti file gambar dan dokumen.

Bergantung pada bagaimana solusi Anda dirancang, Anda mungkin juga dapat menyimpan file atau data khusus penyewa dalam CDN, seperti respons API berformat JSON. Praktik ini dapat membantu Anda meningkatkan performa dan skalabilitas solusi Anda, tetapi penting untuk mempertimbangkan apakah data khusus penyewa cukup terisolasi untuk menghindari kebocoran data di seluruh penyewa. Pertimbangkan bagaimana Anda berencana untuk menghapus menyeluruh konten khusus penyewa dari cache Anda, seperti saat data diperbarui atau versi aplikasi baru disebarkan. Dengan menyertakan pengidentifikasi penyewa di jalur URL, Anda dapat mengontrol apakah Anda menghapus menyeluruh file tertentu, semua file yang terkait dengan penyewa tertentu, atau semua file untuk semua penyewa.

Antipattern yang perlu dihindari

Gagal merencanakan konektivitas VNet

Dengan menyebarkan sumber daya ke VNet, Anda memiliki banyak kontrol atas bagaimana lalu lintas mengalir melalui komponen solusi Anda. Namun, integrasi VNet juga memperkenalkan kompleksitas tambahan, biaya, dan faktor lain yang perlu Anda pertimbangkan. Efek ini terutama berlaku dengan komponen platform as a service (PaaS).

Penting untuk menguji dan merencanakan strategi jaringan Anda, sehingga Anda mengungkap masalah apa pun sebelum menerapkannya di lingkungan produksi.

Tidak merencanakan batas

Azure memberlakukan sejumlah batasan yang memengaruhi sumber daya jaringan. Batas ini termasuk batas sumber daya Azure dan batas protokol dasar dan platform. Misalnya, saat Anda membangun solusi multipenyewa skala tinggi pada layanan platform, seperti Azure App Service dan Azure Functions, Anda mungkin perlu mempertimbangkan jumlah koneksi TCP dan port SNAT. Ketika Anda bekerja dengan komputer virtual dan load balancer, Anda juga perlu mempertimbangkan batasan untuk aturan keluar dan untuk port SNAT.

Subnet kecil

Penting untuk mempertimbangkan ukuran setiap subnet untuk memungkinkan jumlah sumber daya atau instans sumber daya yang akan Anda sebarkan, terutama saat Anda menskalakan. Saat Anda bekerja dengan sumber daya platform as a service (PaaS), pastikan Anda memahami bagaimana konfigurasi dan skala sumber daya Anda akan memengaruhi jumlah alamat IP yang diperlukan dalam subnetnya.

Segmentasi jaringan yang tidak tepat

Jika solusi Anda memerlukan jaringan virtual, pertimbangkan cara Anda mengonfigurasi segmentasi jaringan untuk memungkinkan Anda mengontrol arus lalu lintas masuk dan keluar (utara-selatan) dan alur dalam solusi Anda (timur-barat). Tentukan apakah penyewa harus memiliki VNet mereka sendiri, atau apakah Anda akan menyebarkan sumber daya bersama di VNet bersama. Mengubah pendekatan bisa sulit, jadi pastikan Anda mempertimbangkan semua kebutuhan Anda, lalu pilih pendekatan yang akan berfungsi untuk target pertumbuhan Anda di masa mendatang.

Hanya mengandalkan kontrol keamanan lapisan jaringan

Dalam solusi modern, penting untuk menggabungkan keamanan lapisan jaringan dengan kontrol keamanan lainnya, dan Anda tidak boleh hanya mengandalkan firewall atau segmentasi jaringan. Ini kadang-kadang disebut jaringan zero-trust. Gunakan kontrol berbasis identitas untuk memverifikasi klien, pemanggil, atau pengguna, di setiap lapisan solusi Anda. Pertimbangkan untuk menggunakan layanan yang memungkinkan Anda menambahkan lapisan perlindungan tambahan. Opsi yang tersedia bergantung pada layanan Azure yang Anda gunakan. Di AKS, pertimbangkan untuk menggunakan jala layanan untuk autentikasi TLS bersama, dan kebijakan jaringan untuk mengontrol lalu lintas timur-barat. Di App Service, pertimbangkan untuk menggunakan dukungan bawaan untuk autentikasi dan otorisasi dan pembatasan akses.

Menulis ulang header host tanpa pengujian

Saat Anda menggunakan pola Gateway Offloading, Anda mungkin mempertimbangkan untuk menulis Host ulang header permintaan HTTP. Praktik ini dapat menyederhanakan konfigurasi layanan aplikasi web backend Anda dengan membongkar domain kustom dan manajemen TLS ke gateway.

Namun, Host penulisan ulang header dapat menyebabkan masalah untuk beberapa layanan backend. Jika aplikasi Anda mengeluarkan pengalihan HTTP atau cookie, ketidakcocokan dalam nama host dapat merusak fungsionalitas aplikasi. Secara khusus, masalah ini dapat muncul saat Anda menggunakan layanan backend yang merupakan multipenyewa, seperti Azure App Service, Azure Functions, dan Azure Spring Apps. Untuk informasi selengkapnya, lihat praktik terbaik pelestarian nama host.

Pastikan Anda menguji perilaku aplikasi anda dengan konfigurasi gateway yang anda rencanakan untuk digunakan.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

  • John Downs | Teknisi Pelanggan Utama, FastTrack untuk Azure

Kontributor lain:

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya