Pola penyewaan database SaaS multipenyewa
Berlaku untuk: 
Azure SQL Database
Artikel ini menjelaskan berbagai model penyewaan yang tersedia untuk aplikasi SaaS multipenyewa.
Saat merancang aplikasi SaaS multipenyewa, Anda harus dengan hati-hati memilih model penyewaan yang paling sesuai dengan kebutuhan aplikasi Anda. Model penyewaan menentukan bagaimana data setiap penyewa dipetakan ke penyimpanan. Pilihan model penyewaan Anda berdampak pada desain dan manajemen aplikasi. Beralih ke model yang berbeda di lain waktu kadang-kadang dapat lebih mahal.
J. Konsep dan terminologi SaaS
Dalam model Software as a Service (SaaS), perusahaan Anda tidak menjual lisensi ke perangkat lunak Anda. Sebaliknya, setiap pelanggan melakukan pembayaran sewa ke perusahaan Anda, sehingga setiap pelanggan menjadi penyewa di perusahaan Anda.
Sebagai imbalan untuk membayar sewa, setiap penyewa menerima akses ke komponen aplikasi SaaS Anda, dan memiliki data yang disimpan dalam sistem SaaS.
Istilah model penyewaan mengacu pada cara pengelolaan data penyewa yang disimpan:
- Penyewa tunggal: Setiap database menyimpan data hanya dari satu penyewa.
- Multi-penyewaan: Setiap database menyimpan data dari beberapa penyewa terpisah (dengan mekanisme untuk melindungi privasi data).
- Model penyewaan hibrid juga tersedia.
B. Cara memilih model penyewaan yang sesuai
Secara umum, model penyewaan tidak memengaruhi fungsi aplikasi, tetapi kemungkinan berdampak pada aspek lain dari solusi keseluruhan. Kriteria berikut digunakan untuk menilai setiap model:
Skalabilitas:
- Jumlah penyewa.
- Penyimpanan per penyewa.
- Penyimpanan secara agregat.
- Beban kerja.
Isolasi penyewa: Isolasi dan performa data (apakah beban kerja satu penyewa memengaruhi yang lain).
Biaya per penyewa: Biaya database.
Kompleksitas pengembangan:
- Perubahan pada skema.
- Perubahan pada kueri (diperlukan oleh pola).
Kompleksitas operasional:
- Pemantauan dan pengelolaan performa.
- Pengelolaan skema.
- Memulihkan penyewa.
- Pemulihan bencana.
Kemampuan penyesuaian: Kemudahan mendukung penyesuaian skema yang khusus untuk penyewa atau khusus untuk kelas penyewa.
Diskusi penyewaan difokuskan pada lapisan data. Namun, pertimbangkan sejenak tentang lapisan aplikasi. Lapisan aplikasi diperlakukan sebagai entitas monolitik. Jika Anda membagi aplikasi menjadi banyak komponen kecil, pilihan model penyewaan Anda mungkin berubah. Anda dapat memperlakukan beberapa komponen secara berbeda dari yang lain terkait penyewaan dan teknologi penyimpanan atau platform yang digunakan.
C. Aplikasi penyewa tunggal mandiri dengan database penyewa tunggal
Isolasi tingkat aplikasi
Dalam model ini, seluruh aplikasi dipasang secara berulang, sekali untuk setiap penyewa. Setiap instance aplikasi adalah instans mandiri, jadi tidak pernah berinteraksi dengan instans mandiri lainnya. Setiap instans aplikasi hanya memiliki satu penyewa, sehingga hanya dibutuhkan satu database. Penyewa memiliki keseluruhan database di dalamnya.
Setiap instans aplikasi dipasang dalam grup sumber daya Azure terpisah. Baik vendor perangkat lunak atau penyewa dapat memiliki langganan yang memiliki grup sumber daya. Dalam kedua kasus tersebut, vendor dapat mengelola perangkat lunak untuk penyewa. Setiap instans aplikasi dikonfigurasi untuk tersambung ke database yang sesuai.
Setiap database penyewa digunakan sebagai database tunggal. Model ini menyediakan isolasi database terbesar. Namun, isolasi mengharuskan setiap database memiliki alokasi sumber daya yang memadai untuk menangani beban puncaknya. Di sini penting bahwa kumpulan elastis tidak dapat digunakan untuk database yang disebarkan dalam grup sumber daya yang berbeda atau ke langganan yang berbeda. Batasan ini membuat model aplikasi penyewa tunggal mandiri menjadi solusi termahal dari perspektif biaya database keseluruhan.
Manajemen vendor
Vendor dapat mengakses semua database di semua instans aplikasi mandiri, bahkan jika instans aplikasi dipasang di langganan penyewa yang berbeda. Akses dicapai melalui koneksi SQL. Dengan akses lintas instans ini, vendor dapat memusatkan manajemen skema dan kueri lintas database untuk tujuan pelaporan atau analitik. Jika manajemen terpusat semacam ini diinginkan, katalog harus disebarkan yang memetakan pengidentifikasi penyewa ke pengidentifikasi sumber daya seragam database (URI). Azure SQL Database menyediakan pustaka sharding yang digunakan bersama-sama untuk menyediakan katalog. Nama resmi pustaka sharding ini adalah Elastic Database Client Library.
D. Aplikasi multipenyewa dengan database per penyewa
Pola berikutnya ini menggunakan aplikasi multipenyewa dengan banyak database, semuanya menjadi database penyewa tunggal. Database baru disediakan untuk setiap penyewa baru. Tingkat aplikasi ditingkatkan skalanya secara vertikal dengan menambahkan lebih banyak sumber daya per simpul. Atau aplikasi disebarkan skalanya secara horizontal dengan menambahkan lebih banyak simpul. Penskalaan didasarkan pada beban kerja, dan tidak bergantung dengan jumlah atau skala database individu.
Melakukan penyesuaian untuk penyewa
Seperti pola aplikasi mandiri, penggunaan database penyewa tunggal memberikan isolasi penyewa yang kuat. Dalam aplikasi apa pun yang modelnya hanya menentukan database penyewa tunggal, skema untuk database yang diberikan dapat disesuaikan dan dioptimalkan untuk penyewanya. Penyesuaian ini tidak memengaruhi penyewa lain di aplikasi. Penyewa mungkin memerlukan data di luar bidang data dasar yang dibutuhkan semua penyewa. Selanjutnya, bidang data tambahan mungkin memerlukan indeks.
Dengan database per penyewa, penyesuaian skema untuk satu atau beberapa penyewa individu mudah dicapai. Vendor aplikasi harus merancang prosedur agar penyesuaian skema dalam skala besar dapat dikelola dengan cermat.
Kumpulan database elastis
Ketika database disebar dalam grup sumber daya yang sama, database dapat dikelompokkan ke dalam kumpulan database elastis. Kumpulan menyediakan cara hemat biaya untuk berbagi sumber daya di banyak database. Opsi kumpulan ini lebih murah daripada mengharuskan setiap database memiliki ukuran yang cukup besar guna mengakomodasi penggunaan puncak. Meskipun database yang dikumpulkan membagikan akses ke sumber daya, database tersebut masih dapat mencapai tingkat isolasi performa yang tinggi.
Azure SQL Database menyediakan alat yang diperlukan untuk mengonfigurasi, memantau, dan mengelola fitur berbagi. Metrik performa tingkat kumpulan dan tingkat database tersedia di portal Microsoft Azure, dan melalui log Azure Monitor. Metrik dapat memberikan wawasan hebat terkait performa khusus penyewa dan agregat. Database individual dapat dipindahkan di antar kumpulan untuk menyediakan sumber daya yang dikhususkan untuk penyewa tertentu. Dengan alat ini, Anda dapat memastikan performa yang baik dengan cara yang hemat biaya.
Skala operasi untuk database per penyewa
Azure SQL Database memiliki banyak fitur manajemen yang dirancang untuk mengelola database dalam jumlah besar dalam skala besar, seperti lebih dari 100.000 database. Fitur-fitur ini membuat pola database per penyewa menjadi masuk akal.
Misalnya, sistem memiliki database 1000 penyewa sebagai satu-satunya database. Database mungkin memiliki 20 indeks. Jika sistem mengonversi menjadi memiliki 1.000 database penyewa tunggal, kuantitas indeks naik menjadi 20.000. Di Azure SQL Database sebagai bagian dari Penyetelan otomatis, fitur pengindeksan otomatis diaktifkan secara default. Pengindeksan otomatis mengelola semua 20.000 indeks dan pengoptimalan pembuatan dan penurunannya yang berkelanjutan. Tindakan otomatis ini terjadi dalam database individual, dan tidak dikoordinasikan atau dibatasi oleh tindakan serupa di database lain. Pengindeksan otomatis memperlakukan indeks secara berbeda dalam database yang sibuk daripada dalam database yang kurang sibuk. Jenis kustomisasi manajemen indeks ini akan menjadi tidak praktis pada skala database-per-penyewa jika tugas manajemen besar ini harus dilakukan secara manual.
Fitur manajemen lain yang melakukan penskalaan dengan baik termasuk yang berikut:
- Pencadangan bawaan.
- Ketersediaan tinggi.
- Enkripsi di disk.
- Telemetri performa.
Automation
Operasi manajemen dapat ditulis dan ditawarkan melalui model devops. Operasi bahkan dapat diotomatisasi dan diekspos dalam aplikasi.
Misalnya, Anda dapat mengotomatiskan pemulihan penyewa tunggal ke titik waktu sebelumnya. Pemulihan hanya perlu memulihkan satu database penyewa tunggal yang menyimpan penyewa. Pemulihan ini tidak berdampak pada penyewa lain, yang menegaskan bahwa operasi manajemen berada pada tingkat granular halus dari setiap penyewa individu.
E. aplikasi multipenyewa dengan database multipenyewa
Pola lain yang tersedia adalah menyimpan banyak penyewa dalam database multipenyewa. Instans aplikasi dapat memiliki sejumlah database multipenyewa. Skema database multipenyewa harus memiliki satu atau beberapa kolom pengidentifikasi penyewa sehingga data dari penyewa tertentu dapat diambil secara selektif. Selanjutnya, skema mungkin memerlukan beberapa tabel atau kolom yang hanya digunakan oleh subkumpulan penyewa. Namun, kode statis dan data referensi hanya disimpan sekali dan dibagikan oleh semua penyewa.
Isolasi penyewa dikorbankan
Data: Database multipenyewa selalu mengorbankan isolasi penyewa. Data beberapa penyewa disimpan bersama-sama dalam satu database. Selama pengembangan, pastikan bahwa kueri tidak pernah mengekspos data dari lebih dari satu penyewa. SQL Database mendukung keamanan tingkat baris, yang dapat menegakkan data yang dikembalikan dari kueri yang dicakup ke satu penyewa.
Pemrosesan: Database multipenyewa berbagi sumber daya komputasi dan penyimpanan di semua penyewanya. Database secara keseluruhan dapat dipantau untuk memastikan database berfungsi dengan baik. Namun, sistem Azure tidak memiliki cara bawaan untuk memantau atau mengelola penggunaan sumber daya ini oleh penyewa individu. Oleh karena itu, database multipenyewa membawa peningkatan risiko menghadapi tetangga yang berisik, di mana beban kerja satu penyewa yang terlalu aktif berdampak pada pengalaman performa penyewa lain dalam database yang sama. Pemantauan tingkat aplikasi lainnya dapat memantau performa tingkat penyewa.
Biaya lebih rendah
Secara umum, database multipenyewa memiliki biaya per penyewa terendah. Biaya sumber daya untuk satu database lebih rendah daripada untuk kumpulan database elastis berukuran sama. Selain itu, untuk skenario saat penyewa hanya membutuhkan penyimpanan terbatas, kemungkinan ada jutaan penyewa dapat disimpan dalam satu database. Tidak ada kumpulan database elastis yang dapat berisi jutaan database. Namun, solusi yang berisi 1.000 database per kumpulan, dengan 1.000 kumpulan, dapat mencapai skala jutaan dengan risiko menjadi tidak berat untuk dikelola.
Dua variasi model database multipenyewa dibahas dalam hal berikut, dengan model multipenyewa yang dipecah menjadi yang paling fleksibel dan dapat diskalakan.
F. Aplikasi multipenyewa dengan satu database multipenyewa
Pola database multipenyewa paling sederhana menggunakan database tunggal untuk menghosting data untuk semua penyewa. Karena semakin banyak penyewa ditambahkan, database akan ditingkatkan dengan lebih banyak penyimpanan dan sumber daya komputasi. Peningkatan skala ini mungkin semua yang diperlukan, meskipun selalu ada batas skala akhir. Namun, jauh sebelum batas itu tercapai, pengelolaan database menjadi sulit.
Operasi manajemen yang berfokus pada penyewa individu lebih kompleks untuk diterapkan dalam database multipenyewa. Dalam skala besar, proses operasi ini mungkin dapat sangat lambat. Salah satu contohnya adalah pemulihan data di waktu tertentu hanya untuk satu penyewa.
G. Aplikasi multipenyewa dengan database multipenyewa pecahan
Sebagian besar aplikasi SaaS mengakses data hanya satu penyewa pada satu waktu. Pola akses ini memungkinkan data penyewa didistribusikan di beberapa database atau shard, di mana semua data untuk satu penyewa berada dalam satu shard. Dikombinasikan dengan pola database multipenyewa, model pecahan memungkinkan skala yang hampir tak terbatas.
Mengelola shard
Sharding menambah kompleksitas baik pada desain maupun manajemen operasional. Katalog diperlukan untuk mempertahankan pemetaan antara penyewa dan database. Selain itu, prosedur manajemen diperlukan untuk mengelola shard dan populasi penyewa. Misalnya, prosedur harus dirancang untuk menambahkan dan menghapus shard, dan untuk memindahkan data penyewa di antara shard. Salah satu cara untuk menskalakan adalah dengan menambahkan shard baru dan mengisinya dengan penyewa baru. Di lain waktu, Anda mungkin membagi shard yang terisi penuh menjadi dua shard yang kurang terisi penuh. Setelah beberapa penyewa dipindahkan atau dihentikan, sebaiknya gabungkan shard yang jarang diisi. Penggabungan ini akan menghasilkan pemanfaatan sumber daya yang lebih hemat biaya. Penyewa juga dapat dipindahkan di antar shard untuk menyeimbangkan beban kerja.
SQL Database menyediakan alat pisah/gabung yang berfungsi dengan pustaka sharding dan database katalog. Aplikasi yang disediakan dapat membagi dan menggabungkan shard, dan dapat memindahkan data penyewa di antara pecahan. Aplikasi ini juga mempertahankan katalog selama operasi ini, menandai penyewa yang terpengaruh sebagai offline sebelum memindahkannya. Setelah pemindahan, aplikasi akan memperbarui katalog lagi dengan pemetaan baru, dan menandai penyewa sebagai kembali online.
Database yang lebih kecil lebih mudah dikelola
Dengan mendistribusikan penyewa di beberapa database, solusi multipenyewa yang dipecah menghasilkan database yang lebih kecil yang lebih mudah dikelola. Misalnya, memulihkan penyewa tertentu ke titik waktu sebelumnya kini melibatkan pemulihan satu database yang lebih kecil dari cadangan, bukan database yang lebih besar yang berisi semua penyewa. Ukuran database, dan jumlah penyewa per database, dapat dipilih untuk menyeimbangkan beban kerja dan upaya manajemen.
Pengidentifikasi penyewa dalam skema
Tergantung pada pendekatan sharding yang digunakan, batasan tambahan dapat diberlakukan pada skema database. Aplikasi pemisahan/penggabungan SQL Database mengharuskan skema menyertakan kunci sharding, yang biasanya merupakan pengidentifikasi penyewa. Pengidentifikasi penyewa adalah elemen terdepan dalam kunci utama semua tabel shard. Dengan pengidentifikasi penyewa, aplikasi pemisahan/penggabungan dapat menemukan dan memindahkan data yang terkait dengan penyewa tertentu dengan cepat.
kumpulan database elastis untuk shard
Database multipenyewa yang dipecah dapat ditempatkan di kumpulan elastis. Secara umum, memiliki banyak database penyewa tunggal dalam kumpulan sama hemat biayanya dengan memiliki banyak penyewa dalam beberapa database multipenyewa. Database multipenyewa menguntungkan ketika ada sejumlah besar penyewa yang relatif tidak aktif.
H. Model database multipenyewa pecahan hibrid
Dalam model hibrid, semua database memiliki pengidentifikasi penyewa dalam skemanya. Semua database mampu menyimpan lebih dari satu penyewa, dan database dapat di-shard. Jadi dalam arti skema, mereka semua database multipenyewa. Namun dalam praktiknya, beberapa database ini hanya berisi satu penyewa. Terlepas dari itu, jumlah penyewa yang disimpan dalam database tertentu tidak berpengaruh pada skema database.
Memindahkan penyewa
Kapan saja, Anda dapat memindahkan penyewa tertentu ke database multipenyewanya sendiri. Anda juga dapat mengubah pikiran dan memindahkan penyewa kembali ke database yang berisi beberapa penyewa. Anda juga bisa menetapkan penyewa ke database penyewa tunggal baru saat Anda menyediakan database baru.
Model hibrid sangat menonjol ketika ada perbedaan besar antara kebutuhan sumber daya kelompok penyewa yang dapat diidentifikasi. Misalnya, penyewa yang berpartisipasi dalam uji coba gratis tidak dijamin tingkat performa tinggi yang sama dengan penyewa yang berlangganan. Kebijakan ini mungkin untuk penyewa dalam fase uji coba gratis untuk disimpan dalam database multipenyewa yang dibagikan di antara semua penyewa uji coba gratis. Ketika penyewa uji coba gratis berlangganan ke tingkat layanan dasar, penyewa dapat dipindahkan ke database multipenyewa lain yang mungkin memiliki lebih sedikit penyewa. Pelanggan yang membayar tingkat layanan Premium dapat dipindahkan ke database penyewa tunggal barunya sendiri.
Kumpulan
Dalam model hibrid ini, database penyewa tunggal untuk penyewa yang berlangganan dapat ditempatkan di pusat sumber daya untuk mengurangi biaya database per penyewa. Hal ini juga dilakukan dalam model database per penyewa.
I. Perbandingan model penyewa
Tabel berikut ini merangkum perbedaan antara model penyewaan utama.
| Pengukuran | Aplikasi mandiri | Database per penyewa | Multipenyewa pecahan |
|---|---|---|---|
| Sisik | Sedang (1-100 dtk) | Tinggi (1-100.000 dtk) | Tidak terbatas (1-1.000.000s) |
| Isolasi penyewa | Sangat Penting | Sangat Penting | Rendah; kecuali untuk penyewa tunggal (yang sendirian dalam database MT). |
| Biaya database per penyewa | Tinggi; ukuran disesuaikan untuk puncak penggunaan. | Rendah; kumpulan digunakan. | Terendah, untuk penyewa kecil dalam database MT. |
| Pemantauan dan manajemen performa | Per-penyewa saja | Agregat + per penyewa | Agregat; meskipun per penyewa hanya untuk tunggal. |
| Kompleksitas pengembangan | Kurang Penting | Kurang Penting | Sedang; karena sharding. |
| Kompleksitas operasional | Rendah-Tinggi. Sederhana secara individual, kompleks dalam skala besar. | Rendah-Sedang. Pola mengatasi kompleksitas dalam skala besar. | Rendah-Tinggi. Manajemen penyewa individu bersifat kompleks. |