Pola penyewa database SaaS multi-penyewa

Berlaku untuk:Azure SQL Database

Artikel ini berisi penjelasan berbagai model penyewaan yang tersedia untuk aplikasi SaaS multi-penyewa.

Saat merancang aplikasi SaaS multi-penyewa, Anda harus cermat 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 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 berdampak pada 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. Grup sumber daya dapat menjadi milik langganan yang dimiliki oleh vendor perangkat lunak atau penyewa. 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. Penting bahwa kumpulan database elastis tidak dapat digunakan untuk database yang disebar 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 menginginkan manajemen terpusat semacam ini, sebuah katalog harus disebar guna memetakan pengidentifikasi penyewa ke URI database. 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 multi-penyewa dengan database-per-penyewa

Pola berikut ini menggunakan aplikasi multi-penyewa 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 dikonversi menjadi memiliki 1000 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 multi-penyewa dengan database multi-penyewa

Pola lain yang tersedia adalah menyimpan banyak penyewa dalam database multi-penyewa. Instans aplikasi dapat memiliki sejumlah database multi-penyewa. Skema database multi-penyewa harus memiliki satu atau beberapa kolom pengidentifikasi penyewa agar 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 multi-penyewa 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.

Memproses: Database multi-penyewa berbagi sumber daya komputasi dan penyimpanan di semua penyewanya. Database secara keseluruhan dapat dipantau untuk memastikan performanya dapat diterima. Namun, sistem Azure tidak memiliki cara bawaan untuk memantau atau mengelola penggunaan sumber daya ini oleh penyewa individu. Oleh karena itu, database multi-penyewa membawa peningkatan risiko menghadapi efek "tetangga yang berisik" (noisy neighbors), di mana beban kerja satu penyewa yang terlalu aktif berdampak pada pengalaman kinerja penyewa lain dalam database yang sama. Pemantauan tingkat aplikasi tambahan dapat memantau performa tingkat penyewa.

Biaya lebih rendah

Secara umum, database multi-penyewa 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 1000 database per kumpulan, dengan 1000 kumpulan, bisa mencapai skala jutaan dengan risiko pengelolaan yang sulit.

Dua variasi model database multi-penyewa dibahas dalam hal berikut, dengan model multi-penyewa yang di-shard menjadi yang paling fleksibel dan dapat diskalakan.

F. Aplikasi multi-penyewa dengan database multi-penyewa tunggal

Pola database multi-penyewa paling sederhana menggunakan satu database guna menghosting data untuk semua penyewa. Karena semakin banyak penyewa ditambahkan, database akan ditingkatkan dengan lebih banyak penyimpanan dan sumber daya komputasi. Mungkin yang diperlukan hanyalah peningkatan, meskipun selalu ada batas skala akhir. Namun, jauh sebelum batas itu tercapai, pengelolaan database menjadi sulit.

Operasi manajemen yang difokuskan pada penyewa individu lebih kompleks untuk diterapkan dalam database multi-penyewa. 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 multi-penyewa dengan database multi-penyewa yang di-shard

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 multi-penyewa, model shard memungkinkan penskalaan 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 pemecahan/penggabungan yang berfungsi bersama 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 multi-penyewa dengan sharding menghasilkan database yang lebih kecil dan 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

Bergantung 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 multi-penyewa yang di-sharding dapat ditempatkan di kumpulan database elastis. Secara umum, memiliki banyak database penyewa tunggal dalam kumpulan sama hematnya seperti memiliki banyak penyewa dalam beberapa database multi-penyewa. Database multi-penyewa sangat bermanfaat saat ada sejumlah besar penyewa yang relatif tidak aktif.

H. Model database multi-penyewa hibrid yang di-shard

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 merupakan database multi-penyewa. 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

Anda dapat memindahkan penyewa tertentu ke database multi-penyewanya sendiri kapan saja. 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, misalkan penyewa yang berpartisipasi dalam uji coba gratis tidak dijamin mendapatkan performa tinggi sama seperti penyewa yang berlangganan. Kebijakan ini mungkin untuk penyewa dalam fase uji coba gratis yang akan disimpan dalam database multi-penyewa yang dibagikan di antara semua penyewa uji coba gratis. Ketika penyewa uji coba gratis berlangganan tingkat layanan dasar, penyewa dapat dipindahkan ke database multi-penyewa 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	Multi-penyewa yang di-shard
Skala	Medium 1-100	Sangat tinggi 1-100.000	Tidak Terbatas 1-1.000.000
Isolasi penyewa	Sangat tinggi	Tinggi	Rendah; kecuali untuk penyewa tunggal (yang satu-satunya berada di dalam MT db).
Biaya database per penyewa	Tinggi; ukuran disesuaikan untuk puncak penggunaan.	Rendah; kumpulan digunakan.	Terendah, untuk penyewa kecil di MT DB.
Pemantauan dan manajemen performa	Per-penyewa saja	Agregat + per penyewa	Agregat; meskipun per penyewa hanya untuk tunggal.
Kompleksitas pengembangan	Rendah	Rendah	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.

Langkah berikutnya

• Menyebarkan dan menjelajahi aplikasi Wingtip multi-penyewa yang menggunakan model SaaS database per penyewa - Azure SQL Database

• Selamat datang di aplikasi penyewa Wingtip Tickets sample SaaS Azure SQL Database