Pendekatan arsitektur untuk penyebaran dan konfigurasi solusi multitenant

Terlepas dari arsitektur Anda dan komponen yang Anda gunakan untuk mengimplementasikannya, Anda perlu menyebarkan dan mengonfigurasi komponen solusi Anda. Dalam lingkungan multitenant, penting untuk mempertimbangkan bagaimana Anda menyebarkan sumber daya Azure Anda, terutama ketika Anda menyebarkan sumber daya khusus untuk setiap penyewa, atau ketika Anda mengonfigurasi ulang sumber daya berdasarkan jumlah penyewa di sistem Anda. Pada halaman ini, kami menyediakan panduan kepada arsitek solusi tentang penerapan solusi multitentant, dan kami menunjukkan beberapa pendekatan untuk dipertimbangkan saat Anda merencanakan strategi penerapan Anda.

Pertimbangan dan persyaratan utama

Penting untuk memiliki gagasan yang jelas tentang kebutuhan Anda, sebelum Anda merencanakan strategi penyebaran Anda. Pertimbangan-pertimbangan tertentu mencakup hal berikut:

• Skala yang diharapkan: Apakah Anda berharap untuk mendukung sejumlah kecil penyewa (seperti lima atau kurang), atau akankah Anda tumbuh untuk sejumlah besar penyewa?
• Orientasi otomatis atau dukungan: Ketika penyewa siap untuk ditempatkan, apakah mereka dapat menyelesaikan prosesnya sendiri dengan mengikuti prosedur otomatis? Atau, apakah penyewa baru mengajukan permintaan, dan Anda memasukkannya secara manual setelah Anda menerima permintaan? Apakah ada langkah persetujuan manual yang diperlukan dari tim Anda, seperti untuk mencegah penyalahgunaan layanan Anda?
• Waktu penyediaan: Ketika penyewa siap untuk bergabung, seberapa cepat proses orientasi harus diselesaikan? Jika Anda tidak memiliki jawaban yang jelas, pertimbangkan apakah hal ini harus diukur dalam hitungan detik, menit, jam, atau hari.
• Azure Marketplace: Apakah Anda berencana menggunakan Azure Marketplace untuk memulai penerapan? Jika Anda melakukannya, adakah persyaratan yang perlu Anda penuhi untuk menambahkan penyewa baru.

Anda juga harus mempertimbangkan langkah-langkah orientasi dan penyediaan, otomatisasi, dan tanggung jawab manajemen sumber daya.

Langkah-langkah orientasi dan penyediaan

Pertimbangkan semua yang perlu Anda lakukan saat melakukan orientasi penyewa, dan dokumentasikan daftar dan alur kerja ini, meskipun dilakukan secara manual. Alur kerja orientasi biasanya mencakup hal berikut:

• Menerima perjanjian komersial.
• Mengumpulkan informasi yang Anda butuhkan untuk mengkonfigurasi sistem Anda untuk penyewa baru.
• Langkah persetujuan manual, misalnya, untuk mencegah penipuan atau penyalahgunaan layanan Anda.
• Menyediakan sumber daya di Azure.
• Membuat atau mengonfigurasi nama domain.
• Lakukan tugas konfigurasi pasca-penyebaran, seperti membuat akun pengguna pertama untuk penyewa dan mengirimkan kredensialnya dengan aman ke penyewa.
• Perubahan konfigurasi manual, seperti perubahan catatan DNS.

Mendokumentasikan dengan jelas alur kerja yang diperlukan untuk menaiki penyewa baru.

Selain itu, pertimbangkan sumber daya Azure spesifik yang perlu Anda sediakan bagi penyewa. Bahkan jika Anda tidak menyediakan sumber daya khusus untuk setiap penyewa, pertimbangkan apakah terkadang Anda perlu menerapkan sumber daya saat penyewa baru sudah aktif. Ini mungkin terjadi saat penyewa memerlukan data mereka untuk disimpan di wilayah tertentu, atau saat Anda mendekati batas stempel atau komponen dalam solusi Anda dan perlu membuat instans lain untuk kumpulan penyewa berikutnya.

Pertimbangkan apakah proses berorientasi kepada kemungkinan akan mengganggu penyewa lain, terutama bagi mereka yang memiliki infrastruktur yang sama. Misalnya, jika Anda perlu memodifikasi database bersama, apakah proses ini dapat menyebabkan dampak performa yang perlu diperhatikan penyewa lain? Pertimbangkan apakah Anda dapat menghindari efek ini, atau mencegahnya dengan melakukan proses onboarding di luar jam operasional normal.

Automation

Penerapan otomatis selalu disarankan untuk solusi yang dihosting di cloud. Saat bekerja dengan solusi multitenant, otomatis penyebaran menjadi lebih penting karena alasan berikut:

• Skala: Proses penyebaran manual menjadi semakin kompleks dan memakan waktu, karena populasi penyewa Anda meningkat. Pendekatan penyebaran otomatis lebih mudah diskalakan saat jumlah penyewa bertambah.
• Berulang: Dalam lingkungan multitenant, gunakan proses yang konsisten untuk penyebaran di semua penyewa. Proses manual mengenalkan kemungkinan kesalahan, atau langkah-langkah yang dilakukan untuk beberapa penyewa dan bukan yang lain. Proses manual ini membuat lingkungan Anda dalam keadaan tidak konsisten, yang membuatnya lebih sulit bagi tim Anda untuk mengelola solusi.
• Dampak pemadaman: Penyebaran manual secara signifikan lebih berisiko dan rentan terhadap pemadaman daripada penyebaran otomatis. Dalam lingkungan multitenant, dampak pemadaman seluruh sistem (karena kesalahan penyebaran) bisa tinggi, karena setiap penyewa bisa terpengaruh.

Saat Anda menerapkan ke lingkungan multitenant, Anda harus menggunakan jalur penyebaran, dan menggunakan infrastruktur sebagai teknologi kode (IaC), seperti Bicep, template JSON ARM, Terraform, atau Azure SDK.

Jika Anda berencana untuk menawarkan solusi Anda melalui Azure Marketplace, Anda harus menyediakan proses onboarding otomatis sepenuhnya untuk para penyewa baru. Proses ini dijelaskan dalam dokumentasi API pemenuhan SaaS.

Kapasitas sumber daya maksimum

Saat Anda secara terprogram menerapkan sumber daya penyewa ke sumber daya bersama, pertimbangkan batas kapasitas untuk setiap sumber daya. Saat mendekati batas itu, Anda mungkin perlu membuat instance sumber daya lain untuk mendukung skala lebih lanjut. Pertimbangkan batas setiap sumber daya yang Anda terapkan, dan kondisi yang akan memicu Anda untuk menerapkan instance lain.

Misalnya solusi Anda menyertakan server logis Azure SQL, dan solusi Anda menyediakan database khusus di server tersebut untuk setiap penyewa. Satu server logis memiliki batasan, yang mencakup jumlah maksimum database yang didukung oleh server logis. Jika Anda mendekati batas ini, Anda mungkin perlu menyediakan server baru sehingga Anda dapat melanjutkan penyewa onboard. Pertimbangkan apakah Anda mengotomatisasi proses ini atau memantau pertumbuhan secara manual.

Tanggung jawab manajemen sumber daya

Dalam beberapa solusi multitenant, Anda menggunakan sumber daya Azure khusus untuk setiap penyewa, misalnya database untuk setiap penyewa. Atau, Anda bisa memilih sejumlah penyewa untuk menampung satu contoh sumber daya, sehingga jumlah penyewa yang Anda miliki menentukan kumpulan sumber daya yang Anda sebarkan ke Azure. Dalam solusi lainnya, Anda menyebarkan satu set sumber daya bersama, dan Anda kemudian mengonfigurasi ulang sumber daya ketika Anda menempatkan penyewa baru.

Setiap model ini mensyaratkan Anda untuk menyebarkan dan mengelola sumber daya dengan cara yang berbeda, dan Anda harus mempertimbangkan bagaimana Anda akan mengerahkan dan mengelola siklus hidup sumber daya yang Anda sediakan. Dua pendekatan yang umum adalah sebagai berikut:

• Untuk memperlakukan penyewa sebagai konfigurasi sumber daya yang Anda sebarkan, dan gunakan alur pipa penyebaran Anda untuk menyebarkan dan mengonfigurasi sumber daya tersebut.
• Untuk memperlakukan penyewa sebagai data, dan memiliki penyediaan sarana kontrol dan mengonfigurasi infrastruktur untuk penyewa Anda.

Diskusi lebih lanjut dari pendekatan ini disediakan di bawah ini.

Pengujian

Rencanakan untuk menguji solusi Anda secara teliti selama dan setelah setiap penerapan. Anda dapat menggunakan pengujian otomatis untuk memverifikasi perilaku fungsi dan non-fungsi solusi Anda. Pastikan Anda menguji model isolasi penyewa Anda, dan pertimbangkan untuk menggunakan alat seperti Azure Chaos Studio yang sengaja memperkenalkan kesalahan untuk mensimulasikan pemadaman dunia nyata dan memverifikasi bahwa solusi Anda berfungsi bahkan ketika komponen tidak tersedia atau tidak berfungsi.

Pendekatan dan pola untuk dipertimbangkan

Sebagian pola desain Azure Architecture Center, dan komunitas yang lebih luas, relevan dengan penyebaran dan konfigurasi solusi multitenant.

Pola Stempel Penyebaran

Pola Deployment Stamps melibatkan penerapan infrastruktur khusus untuk penyewa atau sekelompok penyewa. Satu stempel mungkin terdiri dari beberapa penyewa, atau mungkin didedikasikan bagi penyewa tunggal. Anda dapat memilih untuk menyebarkan stempel tunggal, atau Anda dapat mengkoordinasikan penyebaran di beberapa stempel. Jika Anda menyebarkan stempel khusus untuk setiap penyewa, Anda juga dapat mempertimbangkan menyebarkan seluruh stempel secara pemrograman.

Jaringan penyebaran

Jaringan penyebaran memungkinkan Anda meluncurkan pembaruan ke berbagai kelompok infrastruktur pada waktu yang berbeda. Pendekatan ini umumnya digunakan dengan pola Stempel Penyebaran, dan grup stempel dapat ditetapkan ke cincin yang berbeda berdasarkan preferensi penyewa, jenis beban kerja, dan pertimbangan lainnya. Untuk informasi selengkapnya, lihat Cincin penyebaran.

Gunakan bendera fitur

Bendera fitur memungkinkan Anda untuk secara progresif mengekspos fitur atau versi solusi baru Anda ke penyewa yang berbeda, sementara Anda mempertahankan basis kode tunggal. Pertimbangkan untuk menggunakan Azure App Configuration untuk mengelola bendera fitur Anda. Untuk informasi selengkapnya, lihat Bendera fitur.

Terkadang Anda harus secara selektif mengaktifkan fitur tertentu bagi pelanggan tertentu. Misalnya, Anda mungkin memiliki tingkat harga berbeda yang memungkinkan akses ke kemampuan tertentu. Feature flags biasanya bukan pilihan yang tepat untuk skenario ini. Sebaliknya, pertimbangkan untuk membangun sebuah proses untuk melacak dan menegakkan hak lisensi yang dimiliki setiap pelanggan.

Antipattern yang perlu dihindari

Saat Anda deploy dan mengonfigurasi solusi multitenant, penting untuk menghindari situasi yang menghambat kemampuan Anda untuk menskalakan. Manfaatnya meliputi:

• Deployment dan pengujian manual. Seperti dijelaskan di atas, proses penerapan manual menambah risiko dan memperlambat kemampuan Anda untuk menerapkan. Pertimbangkan untuk menggunakan alur untuk penyebaran otomatis, pembuatan sumber daya secara terprogram dari kode solusi Anda, atau kombinasi keduanya.
• Kustomisasi khusus untuk penyewa. Hindari penerapan fitur atau konfigurasi yang hanya berlaku untuk penyewa tunggal. Pendekatan ini menambah kompleksitas pada penyebaran dan pengujian Anda. Sebagai gantinya, gunakan jenis sumber daya dan basis kode yang sama untuk setiap penyewa, dan gunakan strategi seperti feature flags untuk perubahan sementara atau untuk fitur yang diluncurkan secara progresif, atau gunakan tingkatan harga yang berbeda dengan hak lisensi untuk mengaktifkan fitur secara selektif bagi penyewa yang membutuhkannya. Gunakan proses deployment yang konsisten dan otomatis, bahkan untuk penyewa yang memiliki sumber daya terisolasi atau khusus.

Daftar penyewa sebagai konfigurasi atau data

Anda dapat mempertimbangkan dua pendekatan saat menerapkan sumber daya dalam solusi multitenant:

• Gunakan jalur penerapan otomatis untuk menerapkan setiap sumber daya. Saat penyewa baru ditambahkan, konfigurasikan saluran Anda untuk menyediakan sumber daya untuk setiap penyewa.
• Gunakan saluran penyebaran otomatis untuk menyebarkan sumber daya bersama yang tidak bergantung pada jumlah penyewa. Untuk sumber daya yang diterapkan bagi setiap penyewa, buat sumber daya tersebut dalam aplikasi Anda.

Saat mempertimbangkan dua pendekatan, Anda harus membedakan antara memperlakukan daftar penyewa Anda sebagai sebuahkonfigurasi atau sebagai data. Perbedaan ini juga penting ketika Anda mempertimbangkan cara membangun sarana kontrol untuk sistem Anda.

Daftar penyewa sebagai konfigurasi

Saat Anda memperlakukan daftar penyewa sebagai konfigurasi, Anda menyebarkan semua sumber daya dari alur penyebaran terpusat. Saat penyewa baru bergabung, Anda mengonfigurasi ulang pipeline atau parameternya. Biasanya, konfigurasi ulang terjadi melalui perubahan manual, seperti yang digambarkan dalam diagram berikut.

Proses untuk memasukkan penyewa baru mungkin serupa dengan yang berikut ini:

1. Perbarui nama penyewa. Hal ini biasanya terjadi secara manual dengan mengkonfigurasi pipeline itu sendiri, atau dengan memodifikasi file parameter yang disertakan dalam konfigurasi pipeline.
2. Pemicu eksekusi alur.
3. Pipeline menerapkan ulang set lengkap sumber daya Azure Anda, termasuk sumber daya khusus penyewa baru.

Pendekatan ini cenderung bekerja dengan baik untuk sejumlah kecil penyewa, dan untuk arsitektur di mana semua sumber daya digunakan bersama. Hal ini adalah pendekatan sederhana karena semua sumber daya Azure Anda dapat digunakan dan dikonfigurasi dengan menggunakan satu proses.

Namun, ketika Anda mendekati sejumlah besar penyewa, katakanlah 5 hingga 10 atau lebih, hal ini menjadi rumit untuk mengkonfigurasi ulang aliran saat Anda menambahkan penyewa. Waktu yang dibutuhkan untuk menjalankan aliran deployment sering meningkat secara signifikan juga. Pendekatan ini juga tidak dengan mudah mendukung pembuatan penyewa mandiri, dan waktu tenggang sebelum penyewa ditempatkan dapat lebih lama karena Anda perlu memicu saluran pipa untuk berjalan.

Daftar penyewa sebagai data

Saat Anda memperlakukan daftar penyewa sebagai data, Anda masih menerapkan komponen bersama dengan menggunakan saluran. Namun, untuk sumber daya dan pengaturan konfigurasi yang perlu diterapkan untuk setiap penyewa, Anda secara imperatif menerapkan atau mengonfigurasi sumber daya Anda. Misalnya, sarana kontrol Anda dapat menggunakan Azure SDK untuk membuat sumber daya tertentu atau untuk memulai penyebaran templat berparameter.

Proses untuk mengaktifkan penyewa baru mungkin mirip dengan yang berikut ini, dan akan terjadi secara tidak sinkron:

1. Minta penyewa di-onboarding, seperti dengan memulai permintaan API ke sarana kontrol sistem Anda.
2. Komponen alur kerja menerima permintaan pembuatan dan mengatur langkah-langkah yang tersisa.
3. Alur kerja memulai penyebaran sumber daya khusus penyewa ke Azure. Ini dapat dicapai dengan menggunakan model pemrograman imperatif, seperti dengan menggunakan SDK Azure, atau dengan secara imperatif memicu penyebaran template Bicep atau Terraform.
4. Ketika penyebaran selesai, alur kerja menyimpan detail penyewa baru ke katalog penyewa pusat. Data yang disimpan untuk setiap penyewa dapat mencakup ID penyewa dan ID sumber daya untuk semua sumber daya khusus penyewa yang dibuat alur kerja.

Dengan melakukan ini, Anda dapat menyediakan sumber daya bagi penyewa baru tanpa memindahkan seluruh solusi Anda. Waktu yang terlibat dalam penyediaan sumber daya baru untuk setiap penyewa cenderung lebih pendek, karena hanya sumber daya tersebut yang perlu di-deploy.

Namun, pendekatan ini sering lebih menyita waktu untuk membangun, dan upaya yang Anda habiskan perlu dibenarkan oleh jumlah penyewa atau kerangka waktu yang Anda perlukan untuk dipenuhi.

Untuk informasi selengkapnya tentang pendekatan ini, lihat Pertimbangan untuk sarana kontrol multipenyewa.

Contoh

Contoso menjalankan solusi multitenant untuk para pelanggannya. Saat ini, mereka memiliki enam penyewa, dan mereka berharap untuk tumbuh menjadi 300 penyewa dalam 18 bulan ke depan. Contoso mengikuti aplikasi Multitenant dengan database khusus untuk setiap pendekatan penyewa. Mereka telah di-deploy satu set sumber daya App Service dan server logis Azure SQL yang dibagikan di antara semua penyewa, dan mendeploy khusus database Azure SQL untuk setiap penyewa, seperti yang ditunjukkan pada diagram berikut.

Contoso menggunakan Bicep untuk mendeploy sumber daya Azure mereka.

Opsi 1 - Gunakan aliran penyebaran untuk semuanya

Contoso mungkin mempertimbangkan untuk men-deploy semua sumber daya mereka dengan menggunakan aliran deployment. Pipa mereka menyebarkan file Bicep yang mencakup semua sumber daya Azure mereka, termasuk database Azure SQL untuk setiap penyewa. Berkas parameter mendefinisikan daftar penyewa, dan berkas Bicep menggunakan loop sumber daya untuk men-deploy database bagi setiap penyewa yang terdaftar, seperti yang ditunjukkan dalam diagram berikut.

Jika Contoso mengikuti model ini, maka mereka perlu memperbarui berkas parameter mereka sebagai bagian dari onboarding penyewa baru. Kemudian mereka perlu menjalankan kembali pipa mereka. Selain itu, mereka perlu melacak secara manual apakah mereka mendekati batas apa pun, seperti jika mereka tumbuh dengan kecepatan tinggi yang tidak terduga dan mendekati jumlah maksimum database yang didukung pada satu server logis Azure SQL.

Opsi 2 - Gunakan kombinasi jalur penyebaran dan pembuatan sumber daya penting

Atau, Contoso mungkin mempertimbangkan untuk memisahkan tanggung jawab untuk pen-deployment Azure.

Contoso menggunakan berkas Bicep yang menentukan sumber daya bersama yang harus disebarkan. Sumber daya bersama mendukung semua penyewa mereka dan menyertakan database peta penyewa, seperti yang ditunjukkan dalam diagram berikut.

Tim Contoso kemudian membangun sarana kontrol yang mencakup API onboarding penyewa. Ketika tim penjualan mereka telah menyelesaikan penjualan ke pelanggan baru, Microsoft Dynamics memicu API untuk memulai proses orientasi. Contoso juga menyediakan antarmuka web swalayan untuk digunakan pelanggan, dan itu juga memicu API.

API secara asinkron memulai alur kerja yang mengaktifkan penyewa baru mereka. Alur kerja memulai deployment database Azure SQL baru, yang mungkin dilakukan dengan salah satu pendekatan berikut:

• Gunakan Azure SDK untuk memulai deployment berkas Bicep kedua yang mendefinisikan database Azure SQL.
• Gunakan Azure SDK untuk membuat database Azure SQL secara imperatif, dengan menggunakan perpustakaan manajemen.

Setelah database disebarkan, alur kerja menambahkan penyewa ke database daftar penyewa, seperti yang diperlihatkan dalam diagram berikut.

Pembaruan skema database yang sedang berlangsung diinisiasi oleh tingkat aplikasi mereka.

Kontributor

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

Penulis utama:

• John Downs | Teknisi Pelanggan Utama, FastTrack untuk Azure

Kontributor lainnya:

• Bohdan Cherchyk | Teknisi Pelanggan Senior, FastTrack untuk Azure
• Arsen Vladimirskiy | Teknisi Pelanggan Utama, FastTrack untuk Azure

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

Langkah berikutnya

• Tinjau pertimbangan untuk memperbarui solusi multitenant.
• Pertimbangkan pendekatan arsitektular untuk penyimpanan dan data.
• Pertimbangkan cara menggunakan Azure Resource Manager dalam solusi multitenant.