Data sering dianggap sebagai bagian paling berharga dari solusi, karena mewakili - dan pelanggan Anda ' - informasi bisnis yang berharga. Jadi, penting untuk mengelola data Anda dengan hati-hati. Saat merencanakan komponen penyimpanan atau data untuk sistem multipenyewa, Anda perlu memutuskan pendekatan untuk berbagi atau mengisolasi data penyewa Anda.
Dalam artikel ini, kami memberikan panduan tentang pertimbangan dan persyaratan utama yang penting untuk arsitek solusi saat memutuskan pendekatan untuk menyimpan data dalam sistem multipenyewa. Kami kemudian menyarankan beberapa pola umum untuk menerapkan multitenancy untuk penyimpanan dan layanan data, dan beberapa antipola untuk menghindari. Akhirnya, kami menyediakan panduan yang ditargetkan untuk beberapa situasi tertentu.
Pertimbangan dan persyaratan utama
Penting untuk mempertimbangkan pendekatan yang Anda gunakan untuk penyimpanan dan layanan data dari sejumlah perspektif, yang kira-kira selaras dengan pilar Kerangka Kerja Well-Architected Azure.
Skala
Saat bekerja dengan layanan yang menyimpan data, Anda harus mempertimbangkan jumlah penyewa yang Anda miliki, dan volume data yang Anda simpan. Jika Anda memiliki sejumlah kecil penyewa (seperti lima atau kurang), dan Anda menyimpan sejumlah kecil data untuk setiap penyewa, maka itu mungkin merupakan upaya yang sia-sia untuk merencanakan pendekatan penyimpanan data yang sangat terukur, atau untuk membangun pendekatan otomatis sepenuhnya untuk mengelola sumber daya data Anda. Tetapi saat Anda tumbuh, Anda semakin mendapat manfaat dari memiliki strategi yang jelas untuk menskalakan data dan sumber daya penyimpanan Anda, dan untuk menerapkan otomatisasi ke manajemen mereka. Bila Anda memiliki 50 penyewa atau lebih, atau jika Anda berencana untuk mencapai tingkat skala tersebut, maka sangat penting untuk merancang pendekatan data dan penyimpanan Anda, dengan skala sebagai pertimbangan utama.
Pertimbangkan sejauh mana Anda berencana untuk menskalakan, dan rencanakan dengan jelas pendekatan arsitektur penyimpanan data Anda untuk memenuhi tingkat skala tersebut.
Prediktabilitas kinerja
Data multitenant dan layanan penyimpanan sangat rentan terhadap masalah Tetangga yang Bising. Penting untuk mempertimbangkan apakah penyewa Anda mungkin memengaruhi performa satu sama lain. Misalnya, apakah penyewa Anda memiliki puncak yang tumpang tindih dalam pola penggunaan mereka dari waktu ke waktu? Apakah semua pelanggan Anda menggunakan solusi Anda pada waktu yang sama setiap hari, atau apakah permintaan didistribusikan secara merata? Faktor-faktor tersebut akan memengaruhi tingkat isolasi yang perlu Anda rancang, jumlah sumber daya yang perlu Anda sediakan, dan sejauh mana sumber daya dapat dibagi di antara penyewa.
Penting untuk mempertimbangkan sumber daya Azure dan meminta kuota sebagai bagian dari keputusan ini. Sebagai contoh, Anda menggunakan satu akun penyimpanan untuk menampung semua data penyewa Anda. Jika Anda melebihi jumlah tertentu saat operasi penyimpanan per detik, Azure Storage akan menolak permintaan aplikasi Anda, dan semua penyewa Anda akan terpengaruh. Ini disebut perilaku pelambatan, Penting bagi Anda untuk memantau permintaan yang dibatasi. Untuk informasi selengkapnya, lihat Panduan percobaan ulang untuk layanan Azure.
Isolasi data
Saat merancang solusi yang berisi layanan data multitenant, biasanya ada opsi dan tingkat isolasi data yang berbeda, masing-masing dengan manfaat dan trade off-nya sendiri. Contohnya:
- Saat menggunakan Azure Cosmos DB, Anda bisa menyebarkan wadah terpisah untuk setiap penyewa, dan Anda bisa berbagi database dan akun di antara beberapa penyewa. Atau, Anda dapat mempertimbangkan untuk menggunakan database yang berbeda atau bahkan akun untuk setiap penyewa, bergantung pada tingkat isolasi yang diperlukan.
- Saat menggunakan Azure Storage untuk data blob, Anda bisa menyebarkan wadah blob terpisah untuk setiap penyewa, atau Anda bisa menggunakan akun penyimpanan terpisah.
- Saat menggunakan Azure SQL, Anda dapat menggunakan tabel terpisah dalam basis data bersama, atau Anda dapat menerapkan basis data atau server terpisah untuk setiap penyewa.
- Di semua layanan Azure, Anda dapat mempertimbangkan untuk menyebarkan sumber daya dalam satu langganan Azure bersama, atau Anda dapat menggunakan beberapa langganan Azure - bahkan mungkin satu per penyewa.
Tidak ada solusi tunggal yang bekerja untuk setiap situasi. Opsi yang Anda pilih tergantung pada sejumlah faktor dan persyaratan penyewa Anda. Misalnya, jika penyewa Anda harus memenuhi standar kepatuhan atau peraturan tertentu, Anda mungkin perlu menerapkan tingkat isolasi yang lebih tinggi. Demikian pula, Anda mungkin memiliki persyaratan komersial untuk mengisolasi data pelanggan Anda secara fisik, atau Anda mungkin perlu menegakkan isolasi untuk menghindari masalah Noisy Neighbor. Selain itu, jika penyewa perlu menggunakan kunci enkripsi mereka sendiri, mereka memiliki kebijakan pencadangan dan pemulihan individual, atau mereka perlu menyimpan data mereka di lokasi geografis yang berbeda, Anda mungkin perlu mengisolasi mereka dari penyewa lain, atau mengelompokkannya dengan penyewa yang memiliki kebijakan serupa.
Kompleksitas implementasi
Penting untuk mempertimbangkan kompleksitas implementasi Anda. Ini adalah praktik yang baik untuk menjaga gambaran Anda sesederhana mungkin, sambil tetap memenuhi kebutuhan Anda. Hindari berkomitmen pada arsitektur yang akan menjadi semakin kompleks seiring skala Anda, atau arsitektur yang tidak memiliki sumber daya atau keahlian untuk Anda kembangkan dan pelihara.
Demikian pula, jika solusi Anda tidak perlu skala ke sejumlah besar penyewa, atau jika Anda tidak memiliki kekhawatiran seputar kinerja atau isolasi data, maka lebih baik untuk menjaga solusi Anda sederhana dan menghindari menambahkan kompleksitas yang tidak perlu.
Perhatian khusus untuk solusi data multitenant adalah tingkat penyesuaian yang Anda dukung. Misalnya, dapatkah penyewa memperluas model data Anda atau menerapkan aturan data khusus? Pastikan Anda merancang untuk persyaratan ini di muka. Hindari forking atau menyediakan infrastruktur kustom untuk masing-masing penyewa. Infrastruktur yang disesuaikan menghambat kemampuan Anda untuk menskalakan, untuk menguji solusi Anda, dan untuk menyebarkan pembaruan. Sebagai gantinya, pertimbangkan untuk menggunakan bendera fitur dan bentuk konfigurasi penyewa lainnya.
Kompleksitas manajemen dan operasi
Pertimbangkan bagaimana Anda berencana untuk mengoperasikan solusi Anda, dan bagaimana pendekatan multitenancy Anda mempengaruhi operasi dan proses Anda. Contohnya:
- Manajemen: Pertimbangkan operasi manajemen lintas penyewa, seperti aktivitas pemeliharaan rutin. Jika Anda menggunakan beberapa akun, server, atau basis data, bagaimana Anda akan memulai dan memantau operasi untuk setiap penyewa?
- Pemantauan dan pengukuran: Jika Anda memantau atau mengukur penyewa, pertimbangkan bagaimana solusi Anda melaporkan metrik, dan apakah mereka dapat dengan mudah ditautkan ke penyewa yang memicu permintaan.
- Pelaporan: Melaporkan data dari seluruh penyewa yang terisolasi mungkin mengharuskan setiap penyewa menerbitkan data ke gudang data terpusat, daripada menjalankan kueri pada setiap database satu per satu lalu menggabungkan hasilnya.
- Pembaruan skema: Jika Anda menggunakan database yang memberlakukan skema, rencanakan bagaimana Anda akan menyebarkan pembaruan skema di seluruh properti Anda. Pertimbangkan bagaimana aplikasi Anda mengetahui versi skema mana yang akan digunakan untuk kueri database penyewa tertentu.
- Persyaratan: Pertimbangkan persyaratan ketersediaan tinggi penyewa Anda (misalnya, perjanjian tingkat layanan waktu aktif, atau SLA) dan persyaratan pemulihan bencana (misalnya, tujuan waktu pemulihan, atau RTO, dan tujuan titik pemulihan, atau RPO). Jika penyewa memiliki harapan yang berbeda, apakah Anda dapat memenuhi persyaratan masing-masing penyewa?
- Migrasi: Bagaimana Anda akan memigrasikan penyewa jika mereka perlu pindah ke jenis layanan yang berbeda, penyebaran yang berbeda, atau wilayah lain?
Biaya
Umumnya, semakin tinggi kepadatan penyewa ke infrastruktur penyebaran Anda, semakin rendah biaya untuk menyediakan infrastruktur itu. Namun, infrastruktur bersama meningkatkan kemungkinan masalah seperti masalah Noisy Neighbor , jadi pertimbangkan pengorbanannya dengan hati-hati.
Pendekatan dan pola yang perlu dipertimbangkan
Beberapa pola desain dari Azure Architecture Center relevansi dengan penyimpanan multipenyewa dan layanan data. Anda dapat memilih untuk mengikuti satu pola secara konsisten. Atau, Anda dapat mempertimbangkan pencampuran dan pencocokan pola. Misalnya, Anda mungkin menggunakan database multitenant untuk sebagian besar penyewa Anda, tetapi menerapkan stempel penyewa tunggal untuk penyewa yang membayar lebih atau memiliki persyaratan yang tidak biasa. Demikian pula, sering kali merupakan praktik yang baik untuk menskalakan dengan menggunakan stempel penerapan, bahkan saat Anda menggunakan database multitenant atau database sharded di dalam stempel.
Pola Stempel Penyebaran
Untuk informasi selengkapnya tentang bagaimana pola Deployment Stamps dapat digunakan untuk mendukung solusi multitenant, lihat Gambaran Umum.
Database multitenant bersama dan penyimpanan file
Anda dapat mempertimbangkan untuk menerapkan database multitenant bersama, akun penyimpanan, atau berbagi file, dan membagikannya di semua penyewa Anda.
Pendekatan ini memberikan kepadatan penyewa tertinggi untuk infrastruktur, sehingga cenderung datang dengan biaya terendah dari pendekatan apa pun. Ini juga sering mengurangi overhead manajemen, karena ada satu database atau sumber daya untuk mengelola, mencadangkan, dan mengamankan.
Namun, ketika Anda bekerja dengan infrastruktur bersama, ada beberapa peringatan yang perlu dipertimbangkan:
- Batas skala: Saat Anda mengandalkan satu sumber daya, pertimbangkan skala dan batas sumber daya yang didukung. Misalnya, ukuran maksimum satu database atau penyimpanan file, atau batas throughput maksimum, pada akhirnya akan menjadi hard blocker, jika arsitektur Anda bergantung pada satu database. Pertimbangkan dengan cermat skala maksimum yang perlu Anda capai, dan bandingkan dengan batas Anda saat ini dan masa depan, sebelum Anda memilih pola ini.
- Tetangga yang berisik:Masalah Tetangga yang berisik mungkin menjadi faktor, terutama jika Anda memiliki penyewa yang sangat sibuk atau menghasilkan beban kerja yang lebih tinggi daripada yang lain. Mempertimbangkan untuk menerapkan pola Throttling atau pola Rate Limiting dalam mengurangi efek ini.
- Memantau setiap penyewa: Anda mungkin mengalami kesulitan memantau aktivitas dan mengukur konsumsi untuk satu penyewa. Beberapa layanan, seperti Azure Cosmos DB, menyediakan pelaporan penggunaan sumber daya dalam setiap permintaan, sehingga informasi ini dapat dilacak untuk mengukur konsumsi setiap penyewa. Layanan lain tidak memberikan tingkat detail yang sama. Misalnya, metrik Azure File untuk kapasitas file tersedia per dimensi berbagi file, hanya saat Anda menggunakan pembagian premium. Namun, tingkat standar menyediakan metrik hanya di tingkat akun penyimpanan.
- Persyaratan penyewa: Penyewa mungkin memiliki persyaratan yang berbeda untuk keamanan, pencadangan, ketersediaan, atau lokasi penyimpanan. Jika hal ini tidak cocok dengan konfigurasi sumber daya tunggal, Anda mungkin tidak dapat mengakomodasinya.
- Kustomisasi skema: Saat Anda bekerja dengan database relasional, atau situasi lain di mana skema data penting, maka penyesuaian skema tingkat penyewa sulit.
Pola sharding
Pola Sharding melibatkan penyebaran beberapa database terpisah, yang disebut shard, yang masing-masing berisi satu atau beberapa data penyewa. Tidak seperti stempel penyebaran, pecahan tidak menyiratkan bahwa seluruh infrastruktur diduplikasi. Anda dapat melakukan sharding database tanpa menduplikasi atau membagi infrastruktur lain dalam solusi Anda.
Sharding terkait erat dengan partisi, dan istilah ini sering digunakan secara bergantian. Pertimbangkan panduan partisi data Horizontal, vertikal, dan fungsional.
Pola Sharding dapat menskalakan ke jumlah penyewa yang sangat besar. Selain itu, tergantung pada beban kerja Anda, Anda mungkin dapat mencapai kepadatan penyewa yang tinggi hingga pecahan, sehingga biayanya bisa menarik. Pola Sharding juga dapat digunakan untuk mengatasi kuota, batasan, dan batasan langganan dan layanan Azure.
Beberapa penyimpanan data, seperti Azure Cosmos DB, menyediakan dukungan asli untuk sharding atau partisi. Saat Anda bekerja dengan solusi lain, seperti Azure SQL, mungkin lebih kompleks untuk membangun infrastruktur sharding dan merutekan permintaan ke shard yang benar, untuk penyewa tertentu.
Sharding juga menyulitkan dukungan perbedaan konfigurasi tingkat penyewa, dan untuk memungkinkan pelanggan menyediakan kunci enkripsi mereka sendiri.
Aplikasi multitenant dengan database khusus untuk setiap penyewa
Pendekatan umum lainnya adalah menyebarkan aplikasi multitenant tunggal, dengan database khusus bagi setiap penyewa.
Dalam model ini, data masing-masing penyewa diisolasi dari yang lain, dan Anda mungkin dapat mendukung beberapa tingkat penyesuaian untuk setiap penyewa.
Karena Anda menyediakan sumber daya data khusus untuk setiap penyewa, biaya untuk pendekatan ini bisa lebih tinggi daripada model hosting bersama. Namun, Azure menyediakan beberapa opsi yang dapat Anda pertimbangkan, untuk berbagi biaya hosting sumber daya data individual di beberapa penyewa. Misalnya, saat Anda bekerja dengan Azure SQL, Anda dapat mempertimbangkan elastic pools. Untuk Azure Cosmos DB, Anda dapat menyediakan throughput untuk database dan keluaran dibagi di antara wadah dalam database tersebut, meskipun pendekatan ini tidak sesuai saat Anda memerlukan jaminan performa untuk setiap wadah.
Dalam pendekatan ini, karena hanya komponen data yang digunakan secara individual untuk setiap penyewa, Anda mungkin dapat mencapai kepadatan tinggi untuk komponen lain dalam solusi Anda dan mengurangi biaya komponen tersebut.
Penting untuk menggunakan pendekatan penerapan otomatis saat Anda menyediakan database untuk setiap penyewa.
Pola geode
Pola Geode dirancang khusus untuk solusi yang didistribusikan secara geografis, termasuk solusi multitenant. Pola ini mendukung beban tinggi dan tingkat ketahanan yang tinggi. Jika Anda menerapkan pola Geode, tingkat data Anda harus dapat mereplikasi data di seluruh wilayah geografi, dan itu harus mendukung penulisan multi-geografi.
Azure Cosmos DB menyediakan penulisan multi-master untuk mendukung pola ini, dan Cassandra mendukung klaster multi-wilayah. Layanan data lain umumnya tidak dapat mendukung pola ini, tanpa penyesuaian yang signifikan.
Antipattern yang perlu dihindari
Saat Anda membuat layanan data multipenyewa, penting untuk menghindari situasi yang menghambat kemampuan Anda untuk menskalakan.
Untuk database relasional, pola ini termasuk:
- Isolasi berbasis tabel. Saat Anda bekerja dalam satu database, hindari membuat tabel individual untuk setiap penyewa. Basis data tunggal tidak akan dapat mendukung penyewa dalam jumlah yang sangat besar saat Anda menggunakan pendekatan ini, dan akan semakin sulit untuk membuat kueri, mengelola, dan memperbarui data. Sebagai gantinya, pertimbangkan untuk menggunakan satu set tabel multitenant dengan kolom pengenal penyewa. Atau, Anda dapat menggunakan salah satu pola yang dijelaskan di atas untuk menyebarkan database terpisah untuk setiap penyewa.
- Kustomisasi penyewa tingkat kolom. Hindari menerapkan pembaruan skema yang hanya berlaku untuk penyewa tunggal. Misalnya, Anda memiliki database multitenant tunggal. Hindari menambahkan kolom baru untuk memenuhi persyaratan penyewa tertentu. Hal ini mungkin dapat diterima untuk sejumlah kecil penyesuaian, tetapi dengan cepat menjadi tidak dapat dikelola ketika Anda memiliki banyak penyesuaian untuk dipertimbangkan. Sebagai gantinya, pertimbangkan untuk merevisi model data Anda dalam melacak data khusus untuk setiap penyewa dalam tabel khusus.
- Perubahan skema manual. Hindari memperbarui skema database Anda secara manual, bahkan jika Anda hanya memiliki satu database bersama. Sangat mudah untuk kehilangan jejak pembaruan yang telah Anda terapkan, dan jika Anda perlu menskalakan ke lebih banyak database, sulit untuk mengidentifikasi skema yang benar untuk diterapkan. Sebagai gantinya, buat saluran otomatis untuk menerapkan perubahan skema Anda, dan gunakan secara konsisten. Lacak versi skema yang digunakan untuk setiap penyewa dalam database khusus atau tabel pencarian.
- Ketergantungan versi. Hindari aplikasi Anda bergantung pada satu versi skema database Anda. Saat Anda menskalakan, Anda mungkin perlu menerapkan pembaruan skema pada waktu yang berbeda untuk penyewa yang berbeda. Sebagai gantinya, pastikan versi aplikasi Anda kompatibel dengan setidaknya satu versi skema, dan hindari pembaruan skema yang merusak.
Database
Ada beberapa fitur yang bisa berguna untuk multitenancy. Namun, fitur tersebuti tidak tersedia di semua layanan database. Pertimbangkan apakah Anda memerlukan ini, ketika Anda memutuskan layanan yang akan digunakan untuk skenario Anda:
- Keamanan Row-level dapat mnyediakan isolasi keamanan untuk data penyewa tertentu dalam database multitenant bersama. Fitur ini tersedia di Azure SQL dan Postgres Flex, tetapi tidak tersedia di database lain, seperti MySQL atau Azure Cosmos DB.
- Enkripsi Tenant-level mungkin diperlukan untuk mendukung penyewa yang menyediakan kunci enkripsi mereka sendiri untuk data mereka. Fitur ini tersedia di Azure SQL sebagai bagian dari Always Encrypted. Azure Cosmos DB menyediakan kunci yang dikelola pelanggan di tingkat akun dan juga mendukung Always Encrypted.
- Pengumpulan sumber daya menyediakan kemampuan untuk berbagi sumber daya dan biaya, antara beberapa database atau wadah. Fitur ini tersedia di kumpulan elastis Azure SQL dan instans terkelola dan di throughput database Azure Cosmos DB, meskipun setiap opsi memiliki batasan yang harus Anda ketahui.
- Sharding dan partisi memiliki dukungan asli yang lebih kuat di beberapa layanan daripada yang lainnya. Fitur ini tersedia di Azure Cosmos DB, dengan menggunakan partisi logis dan fisiknya, dan di PostgreSQL Hyperscale. Meskipun Azure SQL tidak secara asli mendukung sharding,ia menyediakan alat sharding untuk mendukung jenis arsitektur ini.
Selain itu, ketika Anda bekerja dengan database relasional atau database berbasis skema lainnya, pertimbangkan di mana proses peningkatan skema harus dipicu, ketika Anda mempertahankan armada database. Di sejumlah kecil database, Anda dapat mempertimbangkan untuk menggunakan pipeline penerapan untuk menerapkan perubahan skema. Saat Anda berkembang, mungkin lebih baik bagi tingkat aplikasi Anda untuk mendeteksi versi skema untuk database tertentu dan untuk memulai proses pemutakhiran.
Penyimpanan file dan blob
Pertimbangkan pendekatan yang Anda gunakan untuk mengisolasi data dalam akun penyimpanan. Misalnya, Anda dapat menerapkan akun penyimpanan terpisah untuk setiap penyewa, atau Anda dapat berbagi akun penyimpanan dan menggunakan penampung individual. Atau, Anda dapat membuat wadah blob bersama, lalu Anda bisa menggunakan jalur blob untuk memisahkan data untuk setiap penyewa. Pertimbangkan batas dan kuota langganan Azure , dan rencanakan pertumbuhan Anda dengan cermat untuk memastikan skala sumber daya Azure Anda untuk mendukung kebutuhan Anda di masa mendatang.
Jika Anda menggunakan wadah bersama, rencanakan strategi autentikasi dan otorisasi Anda dengan hati-hati, untuk memastikan bahwa penyewa tidak dapat mengakses data satu sama lain. Pertimbangkan pola Kunci Valet, saat Anda memberi klien akses ke sumber daya Azure Storage.
Alokasi biaya
Pertimbangkan bagaimana Anda akan mengukur konsumsi dan mengalokasikan biaya bagi penyewa , untuk penggunaan layanan data bersama. Jika memungkinkan, gunakan metrik bawaan alih-alih menghitung sendiri. Namun, dengan infrastruktur bersama, menjadi sulit untuk membagi telemetri untuk penyewa individual, dan Anda harus mempertimbangkan pengukuran kustom tingkat aplikasi.
Secara umum, layanan cloud-native, seperti Azure Cosmos DB dan Azure Blob Storage, menyediakan metrik yang lebih terperinci untuk melacak dan memodelkan penggunaan untuk penyewa tertentu. Misalnya, Azure Cosmos DB menyediakan throughput yang dikonsumsi untuk setiap permintaan dan respons.
Kontributor
Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.
Penulis utama:
- John Downs | Teknisi Pelanggan Utama, FastTrack untuk Azure
Kontributor lain:
- Paul Burpo | Teknisi Pelanggan Utama, FastTrack untuk Azure
- Daniel Scott-Raynsford | Strategi Teknologi Mitra
- Arsen Vladimirskiy | Teknisi Pelanggan Utama, FastTrack untuk Azure
Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.
Langkah berikutnya
Untuk informasi selengkapnya tentang multitenancy dan layanan Azure tertentu, lihat: