Multitenancy dan Azure SQL Database

Solusi multitenant di Azure biasanya menggunakan Azure SQL Database. Artikel ini menjelaskan strategi partisi dan tenansi dan fitur SQL Database untuk solusi multipenyewa.

Baca artikel ini bersama dengan pendekatan Arsitektur untuk penyimpanan dan data dalam solusi multipenyewa, yang menjelaskan pertimbangan dan pendekatan umum yang berlaku di seluruh layanan data.

Strategi partisi dan tenansi

Pilih model tenancy yang memenuhi persyaratan beban kerja terkait skala, isolasi, pemulihan, penyesuaian, dan biaya. Pilih model paling sederhana yang memenuhi persyaratan tersebut. Sharding menambahkan kompleksitas aplikasi dan operasional, jadi jangan memperkenalkannya hanya untuk mengatasi batas yang dapat dipenuhi oleh tingkat layanan yang lebih besar.

Untuk membandingkan tradeoff arsitektur model penyewaan Azure SQL Database umum, lihat Cara memilih model penyewaan yang sesuai.

Memutuskan apakah akan menggunakan satu atau beberapa database

Satu database SQL memiliki kapasitas penyimpanan terbatas. Throughput dan konkurensinya dibatasi oleh tingkat layanan, konfigurasi komputasi, batas koneksi, dan karakteristik beban kerja. Perkirakan persyaratan agregat dan per penyewa untuk penyimpanan, throughput, konkurensi, latensi, isolasi, pemulihan, dan konfigurasi regional sebelum Anda memilih satu database bersama, database untuk setiap penyewa, atau topologi sharding.

Batas database juga menentukan granularitas pencadangan, pemulihan, replikasi geografis, dan operasi failover. Untuk informasi selengkapnya, lihat Praktik terbaik arsitektur untuk Azure SQL Database.

Database multitenant bersama dapat memberikan kepadatan tenant yang tinggi dan biaya per tenant yang rendah, tetapi beberapa database mungkin sesuai sebelum satu database mencapai batas teknisnya jika tenant memerlukan isolasi yang lebih kuat atau konfigurasi serta operasi siklus hidup yang independen.

Anda dapat menggabungkan model tenancy. Misalnya, Anda dapat menempatkan sebagian besar tenant dalam database bersama dan memberikan database khusus kepada tenant dengan permintaan tinggi atau yang diatur ketat. Gunakan katalog penyewa untuk merutekan setiap penyewa ke database yang sesuai.

Evaluasi tingkat layanan Hyperscale saat ukuran database, durasi pencadangan dan pemulihan, peluasan skala baca, atau penskalaan komputasi cepat mendorong desain. Hyperscale mendukung penyimpanan yang bertambah secara otomatis hingga 128 TB untuk database dan hingga 100 TB untuk kumpulan elastis Hyperscale. Jika arsitektur yang ada hanya menggunakan sharding untuk mengatasi batas penyimpanan database, pertimbangkan untuk mengonsolidasikan shard ke dalam database Hyperscale. Validasi throughput tulis, biaya, tujuan pemulihan, isolasi, dan persyaratan operasional sebelum mengonsolidasikan.

Basis data multitenan bersama

Dalam database bersama, simpan pengidentifikasi tenant di setiap tabel yang berisi data milik tenant. Sebarkan identitas pengguna dan tenant yang diautentikasi ke dalam database untuk setiap permintaan. Tetapkan dan validasi konteks ini setiap kali Anda menggunakan kembali koneksi pool alih-alih mengandalkan konteks dari permintaan sebelumnya. Gunakan row-level security sebagai perlindungan yang diberlakukan database terhadap akses data lintas penyewa.

Semua penyewa berbagi komputasi, penyimpanan, pencadangan, pemulihan, dan konfigurasi regional database tersebut. Model ini rentan terhadap antipattern Noisy Neighbor, di mana beban kerja satu penyewa memengaruhi penyewa lain. Memulihkan atau memindahkan satu tenant memerlukan ekstraksi dan validasi data yang dikontrol aplikasi. Gunakan model ini saat kepadatan penyewa dan efisiensi biaya lebih penting daripada konfigurasi khusus penyewa atau isolasi performa yang kuat.

Database untuk setiap penyewa

Gunakan database terpisah untuk setiap penyewa saat penyewa memerlukan isolasi data dan performa yang lebih kuat, pencadangan dan pemulihan independen, kustomisasi skema, penempatan regional, atau atribusi biaya yang lebih jelas. Aplikasi harus mempertahankan pemetaan yang andal dari setiap pengidentifikasi penyewa ke basis datanya dan merutekan koneksi sesuai pemetaan tersebut.

Tempatkan database dengan persyaratan performa dan pemulihan yang kompatibel di elastic pools untuk berbagi komputasi yang disediakan. Gunakan Hyperscale atau kumpulan elastis Hyperscale saat database penyewa individual memerlukan kemampuan penyimpanan, pencadangan, pemulihan, atau skala baca Hyperscale.

Database multitenant terpartisi

Gunakan database multitenan yang di-shard ketika mendistribusikan penyewa ke beberapa database bersama lebih memenuhi persyaratan skala, pemulihan, kepadatan penyewa, atau biaya beban kerja dibandingkan dengan satu database bersama atau topologi satu database per penyewa. Shard adalah database Azure SQL yang menyimpan satu atau beberapa tenant. Gunakan kunci shard stabil, seperti pengidentifikasi penyewa, sehingga aplikasi dapat menentukan database mana yang menyimpan data penyewa.

Perlakukan himpunan data setiap penyewa sebagai unit penempatan. Simpan semua data untuk penyewa dalam satu shard jika memungkinkan sehingga kueri dan transaksi dalam cakupan penyewa tetap berada dalam satu database. Pertahankan pemetaan dari setiap pengidentifikasi tenant ke database yang berisi datanya.

Pemetaan penyewa ke database sering disebut peta shard. Peta shard adalah katalog yang memetakan setiap kunci shard, atau rentang kunci, ke database yang menyimpan data terkait. Terapkan peta shard sebagai metadata aplikasi tahan lama yang memenuhi persyaratan ketersediaan dan konsistensi beban kerja. Instans aplikasi dapat menyimpan entri peta shard untuk mengurangi latensi perutean, tetapi harus me-refresh atau membatalkan entri cache saat pemetaan berubah.

Pastikan peta shard otoritatif memiliki ketersediaan tinggi dan perbarui secara atomik dengan operasi migrasi tenant. Aplikasi ini juga harus memiliki perutean koneksi, penyediaan shard, pemindahan tenant, penyeimbangan ulang, dan penanganan kegagalan. Rencanakan bagaimana aplikasi menangani pemetaan kedaluarsa selama cutover dan rollback. Untuk panduan desain umum, lihat pola Sharding.

Rencanakan operasi lintas database

Rancang setiap basis data sebagai batas transaksi dan integritas yang independen:

  • Pertahankan lokalitas dan integritas data: Simpan data yang digabungkan atau diperbarui aplikasi secara transaksional dalam database yang sama. Jangan membuat integritas referensial, pemicu, atau dependensi prosedur tersimpan antar database. Untuk operasi bisnis yang mencakup database, gunakan eventual consistency atau pola koordinasi tingkat aplikasi lainnya.
  • Kelola skema secara konsisten: Gunakan tabel, kolom, indeks, tampilan, dan prosedur tersimpan yang sama di setiap shard sehingga aplikasi dapat menggunakan logika akses data yang sama setelah merutekan permintaan ke shard apa pun. Otomatiskan penyebaran skema di seluruh armada database dan lacak versi skema setiap database. Jika Anda sengaja mendukung variasi skema, pastikan aplikasi dan proses deployment sadar versi.
  • Kelola data referensi dengan sengaja: Mereplikasi data referensi statis atau yang jarang berubah jika hal itu dapat menghindari operasi lintas database yang sinkron. Tentukan bagaimana aplikasi meneruskan pembaruan dan menangani salinan kedaluarsa.
  • Seimbangkan dan tempatkan shard: Seimbangkan shard menurut volume data dan beban permintaan, tidak hanya berdasarkan jumlah tenant. Rencanakan proses otomatis dan dapat dipulihkan untuk memindahkan tenant antar shard. Tempatkan database sesuai dengan latensi tenant, residensi, dan persyaratan pemulihan bencana.

Gunakan Elastic jobs untuk perubahan skema terjadwal, pemeliharaan, pengumpulan telemetri, dan operasi lainnya di seluruh grup database. Untuk pelaporan dan analitik di seluruh database penyewa, gunakan penyimpanan analitik terpusat, seperti Microsoft Fabric melalui pencerminan untuk Azure SQL Database, atau alur ekstrak, transformasi, dan pemuatan (ETL) seperti Azure Data Factory. Jika aplikasi memerlukan kueri fan-out sinkron, buat lapisan kueri dan agregasi yang menentukan batas waktu, coba lagi, kegagalan parsial, dan perilaku penggabungan hasil.

Fitur SQL Database yang mendukung multitenansi

SQL Database mencakup banyak fitur yang mendukung multitenansi.

Kolam elastis

Elastic pools berbagi sekumpulan sumber daya komputasi yang dikonfigurasi di antara beberapa database di server logis yang sama. Pool dapat mengurangi biaya ketika database penyewa memiliki pemanfaatan rata-rata rendah dan puncak penggunaan yang jarang dan tidak tumpang tindih. Database dengan pemanfaatan menengah-ke-tinggi persisten mungkin lebih cocok untuk komputasi khusus. Anda dapat mengatur batas sumber daya minimum dan maksimum untuk database dalam kumpulan individual untuk membatasi konsumsi sumber daya mereka, tetapi semua database masih berbagi total kapasitas kumpulan. Pantau pemanfaatan pool agregat dan pemanfaatan database individual.

Untuk informasi selengkapnya, lihat sumber daya berikut ini:

Hyperscale

Azure SQL Database Hyperscale memisahkan komputasi dari penyimpanan sehingga Anda dapat menskalakannya secara independen. Gunakan Hyperscale saat database multipenyewa bersama atau database penyewa individual memerlukan batas penyimpanan yang lebih tinggi, pencadangan dan pemulihan yang cepat, atau peluasan skala baca.

Untuk informasi selengkapnya, lihat sumber daya berikut ini:

Pekerjaan elastis

Gunakan Elastic jobs untuk menjalankan skrip Transact-SQL (T-SQL) terjadwal dan tugas pemeliharaan terhadap satu atau banyak database. Grup target dapat mencakup database individual, server logis, kumpulan elastis, dan database di seluruh langganan. Penggunaan multitenant umum termasuk menyebarkan perubahan skema, mengelola kredensial, mengumpulkan telemetri, dan menjalankan tugas pemrosesan data batch di seluruh armada database.

Elastic Jobs tidak menyediakan lapisan kueri aplikasi yang sinkron. Jika permintaan aplikasi harus mengkueri beberapa database dan segera menggabungkan hasilnya, terapkan perilaku tersebut dalam lapisan aplikasi atau analitik.

Untuk informasi selengkapnya, lihat Pekerjaan elastis di Azure SQL Database.

Keamanan tingkat baris

Keamanan tingkat baris membantu penerapan isolasi tingkat penyewa dalam tabel bersama. Untuk informasi selengkapnya, lihat implementasi keamanan tingkat pada Azure SQL.

Manajemen kunci

Azure SQL Database menggunakan enkripsi data transparan (TDE) untuk mengenkripsi data saat disimpan. Jika penyewa harus menyediakan kunci enkripsi mereka sendiri, gunakan database terpisah dan konfigurasikan kunci TDE yang dikelola pelanggan di tingkat database. Gunakan Always Encrypted saat mesin database dan operatornya tidak boleh memiliki akses ke nilai teks biasa dalam kolom sensitif tertentu. Verifikasi kompatibilitas aplikasi dan kueri karena Always Encrypted membatasi beberapa operasi pada kolom terenkripsi.

Kontributor

Microsoft mempertahankan artikel ini. Kontributor berikut menulis artikel ini.

Penulis utama:

  • Paul Burpo | Teknisi Pelanggan Utama, FastTrack untuk Azure
  • John Downs | Insinyur Perangkat Lunak Utama, Pola & Praktik Azure

Kontributor lain:

Untuk melihat profil LinkedIn nonpublik, masuk ke LinkedIn.

Langkah berikutnya

  • Terakhir diperbarui pada