Azure menyediakan banyak opsi untuk mengatur sumber daya Anda. Dalam solusi multipenyewa, ada tradeoff khusus yang perlu dipertimbangkan saat Anda merencanakan strategi organisasi sumber daya Anda. Dalam artikel ini, kami meninjau dua elemen inti untuk mengatur sumber daya Azure Anda: isolasi penyewa dan peluasan skala di beberapa sumber daya. Kami menjelaskan beberapa pendekatan penyebaran umum yang dapat mendukung model isolasi penyewa yang berbeda. Kami juga menjelaskan cara bekerja dengan batas dan kuota sumber daya Azure, dan cara menskalakan solusi Anda di luar batas ini.
Pertimbangan dan persyaratan utama
Persyaratan isolasi penyewa
Saat Anda menyebarkan solusi multipenyewa di Azure, Anda perlu memutuskan apakah Anda mendedikasikan sumber daya untuk setiap penyewa atau berbagi sumber daya di antara beberapa penyewa. Sepanjang pendekatan multitenansi dan bagian panduan khusus layanan dari seri ini, kami menjelaskan opsi dan trade-off untuk banyak kategori sumber daya. Secara umum, ada berbagai opsi untuk isolasi penyewa. Tinjau model Penyewaan untuk dipertimbangkan untuk solusi multipenyewa untuk panduan selengkapnya tentang cara memutuskan model isolasi Anda.
Sisik
Sebagian besar sumber daya Azure, serta grup sumber daya dan langganan, memberlakukan batasan yang dapat memengaruhi kemampuan Anda untuk menskalakan. Anda mungkin perlu mempertimbangkan penskalaan keluar atau kemasan bin untuk memenuhi jumlah penyewa yang direncanakan atau beban sistem terencana Anda.
Jika Anda tahu dengan pasti bahwa Anda tidak akan tumbuh ke sejumlah besar penyewa atau ke beban tinggi, jangan overengineer rencana peluasan skala Anda. Tetapi jika Anda merencanakan solusi Anda untuk tumbuh, pertimbangkan dengan cermat rencana peluasan skala Anda. Pastikan Anda merancang untuk skala, dengan mengikuti panduan dalam artikel ini.
Jika Anda memiliki proses penyebaran otomatis dan perlu menskalakan di seluruh sumber daya, tentukan bagaimana Anda akan menyebarkan dan menetapkan penyewa di beberapa instans sumber daya. Misalnya, bagaimana Anda akan mendeteksi bahwa Anda mendekati jumlah penyewa yang dapat ditetapkan ke sumber daya tertentu? Apakah Anda berencana untuk menyebarkan sumber daya baru tepat pada waktunya ketika Anda membutuhkannya? Atau, apakah Anda akan menyebarkan kumpulan sumber daya sebelumnya sehingga siap digunakan saat Anda membutuhkannya?
Tip
Pada tahap awal desain dan pengembangan, Anda mungkin tidak memilih untuk menerapkan proses peluasan skala otomatis. Anda masih harus mempertimbangkan dan mendokumen dengan jelas proses yang diperlukan untuk menskalakan saat Anda tumbuh. Dengan mendokumenkan proses, Anda mempermudah diri Anda untuk mengotomatiskannya jika kebutuhan muncul di masa depan.
Penting juga untuk menghindari membuat asumsi apa pun di seluruh kode dan konfigurasi Anda yang dapat membatasi kemampuan Anda untuk menskalakan. Misalnya, Anda mungkin perlu meluaskan skala ke beberapa akun penyimpanan di masa mendatang, jadi saat Anda membangun tingkat aplikasi, pastikan akun penyimpanan dapat secara dinamis mengalihkan akun penyimpanan yang terhubung berdasarkan penyewa aktif.
Pendekatan dan pola yang perlu dipertimbangkan
Isolasi penyewa
Sumber daya Azure disebarkan dan dikelola melalui hierarki. Sebagian besar sumber daya disebarkan ke dalam grup sumber daya, yang terkandung dalam langganan. Grup manajemen secara logis mengelompokkan langganan bersama-sama. Semua lapisan hierarkis ini dikaitkan dengan penyewa Microsoft Entra.
Saat Anda menentukan cara menyebarkan sumber daya untuk setiap penyewa, Anda mungkin mengisolasi pada tingkat yang berbeda dalam hierarki. Setiap opsi berlaku untuk jenis solusi multipenyewa tertentu, dan dilengkapi dengan manfaat dan tradeoff. Juga umum untuk menggabungkan pendekatan, menggunakan model isolasi yang berbeda untuk komponen solusi yang berbeda.
Isolasi dalam sumber daya bersama
Anda dapat memilih untuk berbagi sumber daya Azure di antara beberapa penyewa, dan menjalankan semua beban kerja mereka pada satu instans. Tinjau panduan khusus layanan untuk layanan Azure yang Anda gunakan untuk memahami pertimbangan atau opsi spesifik yang mungkin penting.
Saat Menjalankan satu instans sumber daya, Anda perlu mempertimbangkan batas layanan, batas langganan, atau kuota apa pun yang mungkin tercapai saat Anda menskalakan. Misalnya, ada jumlah maksimum simpul yang didukung oleh kluster Azure Kubernetes Service (AKS), dan ada batas atas jumlah transaksi per detik yang didukung oleh akun penyimpanan. Pertimbangkan bagaimana Anda akan menskalakan ke beberapa sumber daya bersama saat Anda mendekati batas ini.
Anda juga perlu memastikan kode aplikasi Anda sepenuhnya menyadari multitenansi, dan membatasi akses ke data untuk penyewa tertentu.
Sebagai ilustrasi pendekatan sumber daya bersama, misalkan Contoso sedang membangun aplikasi SaaS multipenyewa yang mencakup aplikasi web, database, dan akun penyimpanan. Mereka mungkin memutuskan untuk menyebarkan sumber daya bersama untuk melayani semua pelanggan mereka. Dalam diagram berikut, satu set sumber daya dibagikan oleh semua pelanggan.
Memisahkan sumber daya dalam grup sumber daya
Anda juga dapat menyebarkan sumber daya khusus untuk setiap penyewa. Anda dapat menyebarkan seluruh salinan solusi Anda untuk satu penyewa. Atau, Anda mungkin berbagi beberapa komponen antar penyewa sementara komponen lain didedikasikan untuk penyewa tertentu. Pendekatan ini dikenal sebagai pemartisian horizontal.
Sebaiknya Anda menggunakan grup sumber daya untuk mengelola sumber daya dengan siklus hidup yang sama. Dalam beberapa sistem multitenant, masuk akal untuk menyebarkan sumber daya kepada beberapa penyewa ke dalam satu kelompok sumber daya atau satu set kelompok sumber daya.
Penting bagi Anda untuk mempertimbangkan bagaimana Anda menyebarkan dan mengelola sumber daya ini, termasuk apakah penyebaran sumber daya khusus penyewa dimulai oleh alur penyebaran atau aplikasi Anda. Anda juga perlu menentukan bagaimana Anda akan dengan jelas mengidentifikasi sumber daya tertentu yang terkait dengan penyewa tertentu. Pertimbangkan untuk menggunakan strategi konvensi penamaan yang jelas, tag sumber daya, atau database katalog penyewa.
Ini adalah praktik yang baik untuk menggunakan grup sumber daya terpisah untuk sumber daya yang Anda bagikan antara beberapa penyewa dan sumber daya yang Anda sebarkan untuk penyewa individual. Namun, untuk beberapa sumber daya, Azure membatasi jumlah sumber daya dari satu jenis yang dapat disebarkan ke dalam grup sumber daya. Batas ini berarti Anda mungkin perlu menskalakan di beberapa grup sumber daya saat Anda tumbuh.
Misalkan Contoso memiliki tiga pelanggan (penyewa): Adventure Works, Fabrikam, dan Tailwind. Mereka mungkin memilih untuk berbagi aplikasi web dan akun penyimpanan antara tiga penyewa, lalu menyebarkan database individual untuk setiap penyewa. Diagram berikut ini memperlihatkan grup sumber daya yang berisi sumber daya bersama dan grup sumber daya yang berisi database setiap penyewa.
Pisahkan grup sumber daya dalam langganan
Saat Anda menyebarkan sekumpulan sumber daya untuk setiap penyewa, pertimbangkan untuk menggunakan grup sumber daya khusus penyewa khusus. Misalnya, saat Anda mengikuti pola Stempel Penyebaran, setiap stempel harus disebarkan ke dalam grup sumber dayanya sendiri. Anda dapat mempertimbangkan untuk menyebarkan beberapa grup sumber daya khusus penyewa ke dalam langganan Azure bersama, yang memungkinkan Anda mengonfigurasi kebijakan dan aturan kontrol akses dengan mudah.
Anda dapat memilih untuk membuat sekumpulan grup sumber daya untuk setiap penyewa, dan juga berbagi grup sumber daya untuk sumber daya bersama apa pun.
Saat Anda menyebarkan grup sumber daya khusus penyewa ke langganan bersama, ketahui jumlah maksimum grup sumber daya di setiap langganan, dan batas tingkat langganan lainnya yang berlaku untuk sumber daya yang Anda sebarkan. Saat Anda mendekati batas ini, Anda mungkin perlu menskalakan di beberapa langganan.
Dalam contoh kami, Contoso mungkin memilih untuk menyebarkan stempel untuk setiap pelanggan mereka dan menempatkan stempel dalam grup sumber daya khusus dalam satu langganan. Dalam diagram berikut, langganan, yang berisi tiga grup sumber daya, dibuat untuk setiap pelanggan.
Langganan terpisah
Dengan menyebarkan langganan khusus penyewa, Anda dapat sepenuhnya mengisolasi sumber daya khusus penyewa. Selain itu, karena sebagian besar kuota dan batasan berlaku dalam langganan, menggunakan langganan terpisah per penyewa memastikan bahwa setiap penyewa memiliki penggunaan penuh kuota yang berlaku. Untuk beberapa jenis akun penagihan Azure, Anda dapat membuat langganan secara terprogram. Anda juga dapat menggunakan reservasi Azure dan paket penghematan Azure untuk komputasi di seluruh langganan.
Ketahuilah jumlah langganan yang dapat Anda buat. Jumlah maksimum langganan mungkin berbeda, hal ini tergantung pada hubungan komersial Anda dengan Microsoft atau mitra Microsoft, seperti jika Anda memiliki suatu perjanjian perusahaan.
Namun, mungkin lebih sulit untuk meminta penambahan kuota, ketika Anda bekerja di sejumlah besar langganan. API Kuota menyediakan antarmuka terprogram untuk beberapa jenis sumber daya. Namun, untuk banyak jenis sumber daya, peningkatan kuota harus diminta dengan memulai kasus dukungan. Mungkin juga sulit untuk bekerja dengan perjanjian dukungan Azure dan kasus dukungan, saat Anda bekerja dengan banyak langganan.
Pertimbangkan untuk mengelompokkan langganan khusus penyewa Anda ke dalam hierarki grup manajemen, untuk memungkinkan manajemen aturan dan kebijakan kontrol akses yang mudah.
Misalnya, Contoso memutuskan untuk membuat langganan Azure terpisah untuk masing-masing dari tiga pelanggan mereka, seperti yang ditunjukkan dalam diagram berikut. Setiap langganan berisi grup sumber daya, dengan sekumpulan sumber daya lengkap untuk pelanggan tersebut.
Setiap langganan berisi grup sumber daya, dengan sekumpulan sumber daya lengkap untuk pelanggan tersebut.
Mereka menggunakan grup manajemen untuk menyederhanakan manajemen langganan mereka. Dengan menyertakan Produksi dalam nama grup manajemen, mereka dapat dengan jelas membedakan penyewa produksi apa pun dari penyewa non-produksi atau pengujian. Penyewa non-produksi akan menerapkan aturan dan kebijakan kontrol akses Azure yang berbeda.
Semua langganan mereka dikaitkan dengan satu penyewa Microsoft Entra. Menggunakan satu penyewa Microsoft Entra berarti bahwa identitas tim Contoso, termasuk pengguna dan perwakilan layanan, dapat digunakan di seluruh properti Azure mereka.
Memisahkan langganan di penyewa Microsoft Entra terpisah
Dimungkinkan juga untuk membuat penyewa Microsoft Entra individual secara manual untuk setiap penyewa Anda, atau untuk menyebarkan sumber daya Anda ke dalam langganan dalam penyewa Microsoft Entra pelanggan Anda. Namun, bekerja dengan beberapa penyewa Microsoft Entra membuatnya lebih sulit untuk diautentikasi, mengelola penetapan peran, menerapkan kebijakan global, dan melakukan banyak operasi manajemen lainnya.
Peringatan
Kami menyarankan untuk tidak membuat beberapa penyewa Microsoft Entra untuk sebagian besar solusi multipenyewa. Bekerja di seluruh penyewa Microsoft Entra memperkenalkan kompleksitas ekstra dan mengurangi kemampuan Anda untuk menskalakan dan mengelola sumber daya Anda. Biasanya, pendekatan ini hanya digunakan oleh penyedia layanan terkelola (MSP), yang mengoperasikan lingkungan Azure atas nama pelanggan mereka.
Sebelum Anda berupaya untuk menyebarkan beberapa penyewa Microsoft Entra, pertimbangkan apakah Anda dapat mencapai kebutuhan Anda dengan menggunakan grup manajemen atau langganan dalam satu penyewa sebagai gantinya.
Dalam situasi di mana Anda perlu mengelola sumber daya Azure dalam langganan yang terkait dengan beberapa penyewa Microsoft Entra, pertimbangkan untuk menggunakan Azure Lighthouse untuk membantu mengelola sumber daya Anda di seluruh penyewa Microsoft Entra Anda.
Misalnya, Contoso dapat membuat penyewa Microsoft Entra terpisah dan memisahkan langganan Azure untuk setiap pelanggan mereka, seperti yang ditunjukkan dalam diagram berikut.
Penyewa Microsoft Entra dikonfigurasi untuk setiap penyewa Contoso, yang berisi langganan dan sumber daya yang diperlukan. Azure Lighthouse terhubung ke setiap penyewa Microsoft Entra.
Kemasan bin
Terlepas dari model isolasi sumber daya Anda, penting untuk mempertimbangkan kapan dan bagaimana solusi Anda akan memperluas skala di beberapa sumber daya. Anda mungkin perlu menskalakan sumber daya saat beban pada sistem Anda meningkat, atau seiring bertambahnya jumlah penyewa. Pertimbangkan pengemasan bin untuk menyebarkan jumlah sumber daya yang optimal untuk kebutuhan Anda.
Tip
Dalam banyak solusi, lebih mudah untuk menskalakan seluruh set sumber daya Anda bersama-sama, alih-alih menskalakan sumber daya satu per satu. Pertimbangkan untuk mengikuti pola Stempel Penyebaran.
Batas Sumber Daya
Sumber daya Azure memiliki batas dan kuota yang harus dipertimbangkan dalam perencanaan solusi Anda. Misalnya, sumber daya mungkin mendukung jumlah maksimum permintaan bersamaan atau pengaturan konfigurasi khusus penyewa.
Cara Anda mengonfigurasi dan menggunakan setiap sumber daya juga memengaruhi skalabilitas sumber daya tersebut. Misalnya, jika, mengingat sejumlah sumber daya komputasi tertentu, aplikasi Anda dapat berhasil menanggapi jumlah transaksi yang ditentukan per detik. Di luar titik ini, Anda mungkin perlu meluaskan skala. Pengujian performa membantu Anda mengidentifikasi titik di mana sumber daya Anda tidak lagi memenuhi kebutuhan Anda.
Catatan
Prinsip penskalaan ke beberapa sumber daya berlaku bahkan ketika Anda bekerja dengan layanan yang mendukung beberapa instans.
Misalnya, Azure App Service mendukung penskalaan jumlah instans paket Anda, tetapi ada batasan seberapa jauh Anda dapat menskalakan satu paket. Dalam aplikasi multipenyewa skala tinggi, Anda mungkin melebihi batas ini dan perlu menyebarkan lebih banyak paket App Service agar sesuai dengan pertumbuhan Anda.
Saat berbagi beberapa sumber daya antar penyewa, Anda harus terlebih dahulu menentukan jumlah penyewa yang didukung sumber daya, saat dikonfigurasi sesuai dengan kebutuhan Anda. Kemudian, sebarkan sumber daya sebanyak yang Anda butuhkan untuk melayani jumlah total penyewa Anda.
Misalnya, Anda menyebarkan Azure Application Gateway sebagai bagian dari solusi SaaS multipenyewa. Anda meninjau desain aplikasi Anda, menguji performa gateway aplikasi di bawah beban, dan meninjau konfigurasinya. Kemudian, Anda menentukan bahwa satu sumber daya gateway aplikasi dapat dibagikan di antara 100 pelanggan. Menurut rencana pertumbuhan organisasi Anda, Anda berharap untuk onboarding 150 pelanggan di tahun pertama Anda, jadi Anda perlu merencanakan untuk menyebarkan beberapa gateway aplikasi untuk melayani beban yang Diharapkan.
Dalam diagram sebelumnya, ada dua gateway aplikasi. Gateway pertama didedikasikan untuk pelanggan 1 hingga 100, dan yang kedua didedikasikan untuk pelanggan 101 hingga 200.
Batas grup sumber daya dan langganan
Baik Anda bekerja dengan sumber daya bersama atau khusus, penting untuk memperhitungkan batasan. Azure membatasi jumlah sumber daya yang dapat disebarkan ke dalam grup sumber daya dan ke dalam langganan Azure. Saat Anda mendekati batas ini, Anda perlu merencanakan untuk menskalakan di beberapa grup sumber daya atau langganan.
Misalnya, Anda menyebarkan gateway aplikasi khusus, untuk setiap pelanggan Anda, ke dalam grup sumber daya bersama. Untuk beberapa sumber daya, Azure mendukung penyebaran hingga 800 sumber daya dengan jenis yang sama ke dalam satu grup sumber daya. Jadi, ketika Anda mencapai batas ini, Anda perlu menyebarkan gateway aplikasi baru ke grup sumber daya lain. Dalam diagram berikut, ada dua grup sumber daya. Setiap grup sumber daya berisi 800 gateway aplikasi.
Penyewa paket bin di seluruh grup sumber daya dan langganan
Anda juga dapat menerapkan konsep pengemasan bin di seluruh sumber daya, grup sumber daya, dan langganan. Misalnya, ketika Anda memiliki sejumlah kecil penyewa, Anda mungkin dapat menyebarkan satu sumber daya dan membagikannya di antara semua penyewa Anda. Diagram berikut menunjukkan kemasan bin ke dalam satu sumber daya.
Saat Anda tumbuh, Anda mungkin mendekati batas kapasitas untuk satu sumber daya, dan meluaskan skala ke beberapa sumber daya (R). Diagram berikut menunjukkan kemasan bin di beberapa sumber daya.
Seiring waktu, Anda mungkin mencapai batas jumlah sumber daya dalam satu grup sumber daya, dan Kemudian Anda akan menyebarkan beberapa sumber daya (R) ke dalam beberapa grup sumber daya (G). Diagram berikut menunjukkan kemasan bin di beberapa sumber daya, dalam beberapa grup sumber daya.
Dan saat Anda tumbuh lebih besar, Anda dapat menyebarkan di beberapa langganan (S), masing-masing berisi beberapa grup sumber daya (G) dengan beberapa sumber daya (R). Diagram berikut menunjukkan pengemasan bin di beberapa sumber daya, dalam beberapa grup sumber daya dan langganan.
Dengan merencanakan strategi peluasan skala, Anda dapat menskalakan ke sejumlah besar penyewa dan mempertahankan beban tingkat tinggi.
Tag
Tag sumber daya memungkinkan Anda menambahkan metadata kustom ke sumber daya Azure Anda, yang dapat berguna untuk biaya manajemen dan pelacakan. Untuk detail selengkapnya, lihat Mengalokasikan biaya dengan menggunakan tag sumber daya.
Tumpukan penyebaran
Tumpukan penyebaran memungkinkan Anda mengelompokkan sumber daya bersama-sama berdasarkan masa pakai umum, bahkan jika mereka menjangkau beberapa grup sumber daya atau langganan. Tumpukan penyebaran berguna saat Anda menyebarkan sumber daya khusus penyewa, terutama jika Anda memiliki pendekatan penyebaran yang mengharuskan penyebaran berbagai jenis sumber daya ke tempat yang berbeda karena masalah skala atau kepatuhan. Tumpukan penyebaran juga memungkinkan Anda untuk dengan mudah menghapus semua sumber daya yang terkait dengan satu penyewa dalam satu operasi, jika penyewa tersebut di-offboarding. Untuk informasi selengkapnya, lihat Tumpukan penyebaran.
Antipattern yang perlu dihindari
- Tidak merencanakan skala. Pastikan Anda memiliki pemahaman yang jelas tentang batas sumber daya yang akan Anda sebarkan, dan batas mana yang mungkin menjadi penting, saat beban atau jumlah penyewa Anda meningkat. Rencanakan bagaimana Anda akan menyebarkan sumber daya tambahan saat menskalakan, dan menguji paket.
- Tidak berencana untuk bin pack. Bahkan jika Anda tidak perlu segera berkembang, rencanakan untuk menskalakan sumber daya Azure Anda di beberapa sumber daya, grup sumber daya, dan langganan dari waktu ke waktu. Hindari membuat asumsi dalam kode aplikasi Anda, seperti ada satu sumber daya ketika Anda mungkin perlu menskalakan ke beberapa sumber daya di masa mendatang.
- Menskalakan banyak sumber daya individual. Jika Anda memiliki topologi sumber daya yang kompleks, mungkin sulit untuk menskalakan setiap komponen satu per satu. Seringkali lebih mudah untuk menskalakan solusi Anda sebagai unit, dengan mengikuti pola Stempel Penyebaran.
- Menyebarkan sumber daya terisolasi untuk setiap penyewa, jika tidak diperlukan. Dalam banyak solusi, lebih hemat biaya dan efisien untuk menyebarkan sumber daya bersama untuk beberapa penyewa.
- Gagal melacak sumber daya khusus penyewa. Jika Anda menyebarkan sumber daya khusus penyewa, pastikan Anda memahami sumber daya mana yang dialokasikan untuk penyewa mana. Informasi ini penting untuk tujuan kepatuhan, untuk melacak biaya, dan untuk mendeprovisi sumber daya jika penyewa di-offboarding. Pertimbangkan untuk menggunakan tag sumber daya untuk melacak informasi penyewa tentang sumber daya, dan pertimbangkan untuk menggunakan tumpukan penyebaran untuk mengelompokkan sumber daya khusus penyewa bersama-sama ke dalam unit logis terlepas dari grup sumber daya atau langganan tempat mereka berada.
- Menggunakan penyewa Microsoft Entra terpisah. Secara umum, tidak dapat dihindari untuk menyediakan beberapa penyewa Microsoft Entra. Mengelola sumber daya di seluruh penyewa Microsoft Entra sangatlah kompleks. Lebih mudah untuk menskalakan di seluruh langganan yang ditautkan ke satu penyewa Microsoft Entra.
- Overarchitecting ketika Anda tidak perlu menskalakan. Dalam beberapa solusi, Anda tahu dengan pasti bahwa Anda tidak akan pernah tumbuh melebihi tingkat skala tertentu. Dalam skenario ini, tidak perlu membangun logika penskalakan yang kompleks. Namun, jika organisasi Anda berencana untuk tumbuh, maka Anda harus siap untuk menskalakan—berpotensi dalam waktu singkat.
Kontributor
Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.
Penulis utama:
- John Downs | Insinyur Perangkat Lunak Utama
Kontributor lain:
- Jason Beck | Insinyur Pelanggan Senior, FastTrack untuk Azure
- Bohdan Cherchyk | Insinyur Pelanggan Senior, FastTrack untuk Azure
- Laura Nicolas | Insinyur Pelanggan Senior, FastTrack untuk Azure
- Arsen Vladimirskiy | Teknisi Pelanggan Utama, FastTrack untuk Azure
- Joshua Waddell | Insinyur Pelanggan Senior, FastTrack untuk Azure
Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.