Multitenansi dan Azure Cosmos DB

Artikel ini menjelaskan fitur Azure Cosmos DB yang dapat Anda gunakan untuk sistem multipenyewa. Ini memberikan panduan dan contoh tentang cara menggunakan Azure Cosmos DB dalam solusi multipenyewa.

Persyaratan multitenansi

Saat Merencanakan solusi multipenyewa, Anda memiliki dua persyaratan utama:

• Membantu memastikan isolasi yang kuat antara penyewa, dan memenuhi persyaratan keamanan yang ketat bagi mereka yang membutuhkannya.
• Pertahankan biaya rendah per penyewa. Sebagai penyedia, pastikan bahwa biaya untuk menjalankan aplikasi tetap berkelanjutan saat diskalakan.

Kedua kebutuhan ini seringkali dapat bertentangan dan memperkenalkan trade-off di mana Anda harus memprioritaskan satu di atas yang lain. Panduan dalam artikel ini dapat membantu Anda lebih memahami trade-off yang harus Anda lakukan untuk mengatasi kebutuhan ini. Artikel ini membantu Anda menavigasi pertimbangan ini sehingga Anda dapat membuat keputusan berdasarkan informasi saat merancang solusi multipenyewa Anda.

Model isolasi

Tentukan tingkat isolasi yang Anda butuhkan di antara penyewa Anda. Azure Cosmos DB mendukung berbagai model isolasi, tetapi untuk sebagian besar solusi, kami sarankan Anda menggunakan salah satu strategi berikut:

• Kunci partisi per tenant sering digunakan untuk solusi multitenant sepenuhnya, seperti layanan perangkat lunak bisnis-ke-konsumen (B2C SaaS).
• Akun database per penyewa sering digunakan untuk solusi SaaS business-to-business (B2B).

Untuk memilih model isolasi yang paling tepat, pertimbangkan model bisnis Anda dan persyaratan penyewa. Misalnya, isolasi performa yang kuat mungkin bukan prioritas untuk beberapa model B2C di mana bisnis menjual produk atau layanan langsung ke pelanggan individu. Namun, model B2B mungkin memprioritaskan keamanan dan isolasi performa yang kuat dan mungkin mengharuskan penyewa memiliki akun database yang disediakan sendiri.

Anda juga dapat menggabungkan beberapa model agar sesuai dengan kebutuhan pelanggan yang berbeda. Misalnya, Anda membangun solusi SaaS B2B yang Anda jual kepada pelanggan perusahaan, dan Anda menyediakan uji coba gratis untuk calon pelanggan baru. Anda dapat menyebarkan akun database terpisah untuk penyewa perusahaan berbayar yang membutuhkan jaminan keamanan dan isolasi yang kuat. Dan Anda mungkin berbagi akun database dan menggunakan kunci partisi untuk mengisolasi pelanggan uji coba.

Model isolasi yang direkomendasikan

Model partition-key-per-tenant dan model database-account-per-tenant adalah model isolasi yang paling umum untuk solusi multipenyewa. Model ini memberikan keseimbangan terbaik antara isolasi penyewa dan efisiensi biaya.

Model kunci partisi per penyewa

Jika Anda mengisolasi pengguna dengan kunci partisi, throughput dibagikan kepada semua pengguna dan dikelola dalam wadah yang sama.

Keuntungan

• Efisiensi biaya: Anda menempatkan semua penyewa dalam satu kontainer, yang dipartisi oleh ID penyewa. Pendekatan ini hanya memiliki satu sumber daya yang dapat ditagih yang menyediakan dan berbagi RU di antara beberapa penyewa. Model ini biasanya lebih hemat biaya dan lebih mudah dikelola daripada memiliki akun terpisah untuk setiap penyewa.

• Manajemen yang disederhanakan: Anda memiliki lebih sedikit akun Azure Cosmos DB untuk dikelola.

Pertukaran

• Perselisihan sumber daya: Throughput bersama (RU/dtk) di seluruh penyewa yang berada dalam kontainer yang sama dapat menyebabkan perselisihan selama penggunaan puncak. Pertikaian ini dapat menciptakan masalah tetangga yang bising dan tantangan performa jika penyewa Anda memiliki beban kerja yang tinggi atau tumpang tindih. Gunakan model isolasi ini untuk beban kerja yang memerlukan RU terjamin pada satu penyewa dan dapat berbagi throughput.

• Isolasi terbatas: Pendekatan ini menyediakan isolasi logis, bukan isolasi fisik. Ini mungkin tidak memenuhi persyaratan isolasi yang ketat dari perspektif performa atau keamanan.

• Kurang fleksibilitas: Anda tidak dapat menyesuaikan fitur tingkat akun, seperti replikasi geografis, pemulihan pada titik waktu tertentu, dan kunci yang dikelola oleh pelanggan, untuk setiap penyewa jika Anda mengisolasi dengan kunci partisi atau berdasarkan basis data atau wadah.

Fitur Azure Cosmos DB untuk multitenansi

• Kontrol throughput Anda: Jelajahi fitur yang dapat membantu mengontrol masalah tetangga yang berisik saat Anda menggunakan kunci partisi untuk mengisolasi penyewa. Gunakan fitur seperti realokasi throughput, kapasitas ledakan, dan kontrol throughput di Java SDK.

• Kunci partisi hierarkis: Gunakan Azure Cosmos DB sehingga setiap partisi logis dapat meningkatkan ukuran hingga 20 GB. Jika Anda memiliki satu penyewa yang perlu menyimpan lebih dari 20 GB data, pertimbangkan untuk menyebarkan data di beberapa partisi logis. Misalnya, alih-alih memiliki satu kunci Contosopartisi , Anda mungkin mendistribusikan kunci partisi dengan membuat beberapa kunci partisi untuk penyewa, seperti Contoso1 dan Contoso2.

  Saat Anda mengkueri data untuk penyewa, Anda bisa menggunakan WHERE IN klausul untuk mencocokkan semua kunci partisi. Anda juga dapat menggunakan kunci partisi hierarkis untuk menyediakan penyewa besar dengan penyimpanan yang lebih besar dari 20 GB jika Anda memiliki kardinalitas penyewa yang tinggi. Anda tidak perlu menggunakan kunci partisi sintetis atau beberapa nilai kunci partisi per penyewa untuk metode ini.

  Misalkan Anda memiliki beban kerja yang mengisolasi penyewa berdasarkan kunci partisi. Satu penyewa, Contoso, lebih besar dan memiliki beban penulisan lebih berat dibandingkan yang lain, dan ukurannya terus bertambah. Untuk menghindari risiko tidak dapat menyerap lebih banyak data untuk penyewa ini, Anda dapat menggunakan kunci partisi hierarkis. Tentukan TenantID sebagai kunci tingkat pertama, lalu tambahkan tingkat kedua seperti UserId. Jika Anda mengantisipasi kombinasi TenantID dan UserID yang menghasilkan partisi logis melebihi batas 20 GB, Anda dapat mempartisi lebih lanjut ke tingkat berikutnya, seperti SessionID. Kueri yang menentukan TenantID atau keduanya TenantID dan UserID secara efektif dirutekan hanya ke subset partisi fisik yang berisi data yang relevan, yang menghindari kueri fan-out penuh. Jika kontainer memiliki 1.000 partisi fisik tetapi nilai tertentu TenantId hanya ada pada lima partisi fisik, kueri dirutekan ke jumlah partisi fisik yang relevan yang lebih kecil.

  Jika tingkat pertama Anda tidak memiliki kardinalitas yang cukup tinggi, dan Anda mencapai batas partisi logis 20 GB pada kunci partisi Anda, pertimbangkan untuk menggunakan kunci partisi sintetis alih-alih kunci partisi hierarkis.

Model satu akun basis data untuk setiap penyewa

Jika Anda mengisolasi penyewa berdasarkan akun database, setiap penyewa memiliki throughput sendiri yang disediakan di tingkat basis data atau tingkat kontainer.

Keuntungan

• Isolasi tinggi: Pendekatan ini menghindari pertikaian atau gangguan karena akun dan kontainer Azure Cosmos DB khusus yang telah menyediakan RU per penyewa unik.

• Perjanjian tingkat layanan kustom (SLA): Setiap penyewa memiliki akunnya sendiri, sehingga Anda dapat menyediakan sumber daya khusus yang disesuaikan, SLA yang berorientasi pada pelanggan, dan jaminan karena Anda dapat menyesuaikan akun database setiap penyewa secara mandiri dalam hal throughput.

• Keamanan yang ditingkatkan: Isolasi data fisik membantu memastikan keamanan yang kuat karena pelanggan dapat mengaktifkan kunci yang dikelola pelanggan pada tingkat akun per penyewa. Data setiap penyewa diisolasi berdasarkan akun, daripada berada dalam kontainer yang sama.

• Fleksibilitas: Penyewa dapat mengaktifkan fitur tingkat akun seperti replikasi geografis, pemulihan titik waktu, dan kunci yang dikelola pelanggan sesuai kebutuhan.

Timbal Balik

• Peningkatan manajemen: Pendekatan ini lebih kompleks karena Anda mengelola beberapa akun Azure Cosmos DB.

• Biaya yang lebih tinggi: Lebih banyak akun berarti Anda harus menyediakan throughput pada setiap sumber daya, seperti database atau kontainer, dalam akun untuk setiap penyewa. Setiap kali sumber daya memprovisikan RU, biaya Azure Cosmos DB Anda meningkat.

• Batasan kueri: Semua penyewa berada di akun yang berbeda, sehingga aplikasi yang meminta beberapa penyewa memerlukan beberapa panggilan dalam logika aplikasi.

Fitur Azure Cosmos DB untuk multitenansi

• Fitur keamanan: Model ini menyediakan peningkatan isolasi keamanan akses data melalui Azure RBAC. Model ini juga menyediakan isolasi keamanan enkripsi database di tingkat penyewa melalui kunci yang dikelola pelanggan.

• Konfigurasi kustom: Anda dapat mengonfigurasi lokasi akun database sesuai dengan persyaratan penyewa. Anda juga dapat menyetel konfigurasi fitur Azure Cosmos DB, seperti replikasi geografis dan kunci enkripsi yang dikelola pelanggan, agar sesuai dengan persyaratan setiap penyewa.

Saat Anda menggunakan akun Azure Cosmos DB khusus per penyewa, pertimbangkan jumlah maksimum akun Azure Cosmos DB per langganan Azure.

Daftar lengkap model isolasi

Model kontainer untuk setiap penyewa

Anda dapat menyediakan kontainer khusus untuk setiap penyewa. Kontainer khusus berfungsi dengan baik ketika Anda dapat menggabungkan data yang Anda simpan untuk penyewa Anda ke dalam satu kontainer. Model ini memberikan pemisahan kinerja yang lebih besar daripada model partition-key-per-tenant. Ini juga menyediakan peningkatan isolasi keamanan akses data melalui Azure RBAC.

Saat Anda menggunakan kontainer untuk setiap penyewa, pertimbangkan untuk berbagi throughput dengan penyewa lain dengan menyediakan throughput di tingkat database. Pertimbangkan batasan dan batasan untuk jumlah minimum RU untuk database Anda dan jumlah maksimum kontainer dalam database. Pertimbangkan juga apakah penyewa Anda memerlukan tingkat performa yang terjamin dan apakah mereka rentan terhadap masalah tetangga yang bising. Saat Anda berbagi throughput di tingkat database, beban kerja atau penyimpanan di semua kontainer harus relatif seragam. Jika tidak, Anda mungkin memiliki masalah tetangga yang bising jika Anda memiliki satu atau beberapa penyewa besar. Jika perlu, rencanakan untuk mengelompokkan penyewa ini ke dalam database berbeda yang didasarkan pada pola beban kerja.

Atau, Anda dapat menyediakan throughput khusus untuk setiap kontainer. Pendekatan ini berfungsi dengan baik untuk penyewa yang lebih besar dan untuk penyewa yang berisiko terhadap masalah tetangga yang bising. Tetapi throughput dasar untuk setiap penyewa lebih tinggi, jadi pertimbangkan persyaratan minimum dan implikasi biaya dari model ini.

Jika model data penyewa Anda memerlukan lebih dari satu entitas, dan jika semua entitas dapat berbagi kunci partisi yang sama, Anda dapat menkolokasikannya dalam kontainer yang sama. Tetapi jika model data penyewa lebih kompleks, dan memerlukan entitas yang tidak dapat berbagi kunci partisi yang sama, pertimbangkan model database-per-penyewa atau database-account-per-tenant. Untuk informasi selengkapnya, lihat Model dan data partisi di Azure Cosmos DB.

Manajemen siklus hidup umumnya lebih sederhana ketika Anda mendedikasikan kontainer untuk penyewa. Anda dapat dengan mudah memindahkan penyewa antara model throughput bersama dan khusus. Dan ketika Anda mendeprovisi penyewa, Anda dapat dengan cepat menghapus kontainer.

Model database untuk setiap penyewa

Anda dapat menyediakan database untuk setiap penyewa di akun database yang sama. Seperti model kontainer per penyewa, model ini memberikan isolasi kinerja yang lebih besar daripada model partition-key per penyewa. Ini juga menyediakan peningkatan isolasi keamanan akses data melalui Azure RBAC.

Mirip dengan model akun per penyewa, pendekatan ini memberikan tingkat isolasi performa tertinggi, tetapi memberikan kepadatan penyewa terendah. Gunakan opsi ini jika setiap penyewa memerlukan model data yang lebih rumit daripada yang memungkinkan dalam model kontainer per penyewa. Atau ikuti pendekatan ini jika pembuatan penyewa baru harus cepat atau bebas dari beban di awal. Untuk beberapa kerangka kerja pengembangan perangkat lunak, model database per penyewa mungkin menjadi satu-satunya tingkat isolasi performa yang didukung kerangka kerja. Kerangka kerja tersebut biasanya tidak mendukung isolasi tingkat entitas (kontainer) dan kolokasi entitas.

Fitur Azure Cosmos DB yang mendukung multipenyewaan

Pembagian Partisi

Gunakan partisi dengan kontainer Azure Cosmos DB Anda untuk membuat kontainer yang dibagikan beberapa penyewa. Biasanya Anda menggunakan pengidentifikasi penyewa sebagai kunci partisi, tetapi Anda mungkin juga mempertimbangkan untuk menggunakan beberapa kunci partisi untuk satu penyewa. Strategi partisi yang terencana dengan baik secara efektif menerapkan pola Sharding. Ketika Anda memiliki kontainer besar, Azure Cosmos DB menyebarkan penyewa Anda di beberapa simpul fisik untuk mencapai tingkat skala yang tinggi.

Pertimbangkan kunci partisi hierarkis untuk membantu meningkatkan kinerja solusi Anda yang multipenyewa. Gunakan kunci partisi hierarkis untuk membuat kunci partisi yang menyertakan beberapa nilai. Misalnya, Anda mungkin menggunakan kunci partisi hierarkis yang menyertakan pengidentifikasi penyewa, seperti GUID kardinalitas tinggi, untuk memungkinkan skala yang hampir tidak terbatas. Atau Anda dapat menentukan kunci partisi hierarkis yang menyertakan properti yang sering digunakan kueri. Pendekatan ini membantu Anda menghindari kueri lintas partisi. Gunakan kunci partisi hierarkis untuk menskalakan melampaui batas partisi logis sebesar 20 GB per nilai kunci partisi dan untuk membatasi kueri fan-out yang mahal.

Untuk informasi selengkapnya, lihat sumber daya berikut:

• Partisi dan skala horizontal di Azure Cosmos DB
• Kunci partisi hierarkis

Kelola RU

Model harga Azure Cosmos DB didasarkan pada jumlah RU/dtk yang Anda provisikan atau konsumsi. Azure Cosmos DB menyediakan beberapa opsi untuk menyediakan throughput. Di lingkungan multipenyewa, pilihan Anda memengaruhi performa dan harga sumber daya Azure Cosmos DB Anda.

Untuk penyewa yang memerlukan jaminan performa dan isolasi keamanan, kami sarankan Anda mengisolasi penyewa berdasarkan akun database dan mengalokasikan RU ke penyewa. Untuk penyewa yang memiliki persyaratan yang kurang ketat, kami sarankan Anda mengisolasi penyewa dengan kunci partisi. Gunakan model ini untuk berbagi RU di antara penyewa Anda dan optimalkan biaya per penyewa.

Model penyewaan alternatif untuk Azure Cosmos DB melibatkan penyebaran kontainer terpisah untuk setiap penyewa dalam database bersama. Gunakan Azure Cosmos DB untuk menyediakan RU untuk database sehingga semua kontainer berbagi RU. Jika beban kerja penyewa Anda biasanya tidak tumpang tindih, pendekatan ini dapat membantu mengurangi biaya operasional Anda. Tetapi pendekatan ini rentan terhadap masalah tetangga yang bising karena kontainer penyewa tunggal mungkin mengonsumsi jumlah RU yang disediakan bersama yang tidak proporsional. Untuk mengurangi masalah ini, pertama-tama identifikasi penyewa yang berisik. Kemudian, Anda dapat secara opsional mengatur throughput yang disediakan pada kontainer tertentu. Kontainer lain di dalam database tetap berbagi kapasitas throughput mereka, tetapi pengguna yang berisik menggunakan throughput khusus mereka sendiri.

Azure Cosmos DB juga menyediakan tingkat tanpa server, yang sesuai dengan beban kerja yang memiliki lalu lintas terputus-terputus atau tidak dapat diprediksi. Atau, Anda dapat menggunakan penskalaan otomatis untuk mengonfigurasi kebijakan yang menentukan penskalaan throughput yang disediakan. Anda juga dapat memanfaatkan kapasitas ledakan Azure Cosmos DB untuk memaksimalkan penggunaan kapasitas throughput yang disediakan, yang dibatasi oleh batas tarif. Dalam solusi multipenyewa, Anda mungkin menggabungkan semua pendekatan ini untuk mendukung berbagai jenis penyewa.

Untuk memantau dan mengelola biaya yang terkait dengan setiap penyewa, ingatlah bahwa setiap operasi yang menggunakan API Azure Cosmos DB mencakup RU yang digunakan. Anda dapat menggunakan informasi ini untuk menggabungkan dan membandingkan RU aktual yang digunakan setiap penyewa. Anda kemudian dapat mengidentifikasi penyewa yang memiliki karakteristik performa yang berbeda.

Untuk informasi selengkapnya, lihat sumber daya berikut:

• Throughput yang disediakan
• Autoscale
• Serverless
• Mengukur biaya RU dari suatu permintaan
• Kuota layanan Azure Cosmos DB
• Kapasitas maksimum

Kunci yang dikelola pelanggan

Beberapa penyewa mungkin memerlukan penggunaan kunci enkripsinya sendiri. Azure Cosmos DB menyediakan fitur kunci yang dikelola pelanggan. Anda menerapkan fitur ini di tingkat akun Azure Cosmos DB. Jadi, jika penyewa memerlukan kunci enkripsi mereka sendiri, Anda harus menggunakan akun Azure Cosmos DB khusus untuk menyebarkan penyewa.

Untuk informasi selengkapnya, lihat Mengonfigurasi kunci yang dikelola pelanggan untuk akun Azure Cosmos DB Anda dengan Azure Key Vault.

Kontributor

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

Penulis utama:

• Tara Bhatia | Manajer Program, Azure Cosmos DB
• Paul Burpo | Teknisi Pelanggan Utama, FastTrack untuk Azure
• John Downs | Insinyur Perangkat Lunak Utama

Kontributor lain:

• Mark Brown | Manajer PM Utama, Azure Cosmos DB
• Deborah Chen | Manajer Program Utama
• Theo van Kraay | Manajer Program Senior, Azure Cosmos DB
• Arsen Vladimirskiy | Teknisi Pelanggan Utama, FastTrack untuk Azure
• Thomas Weiss | Manajer Program Utama
• Vic Perdana | Arsitek Solusi Cloud, Azure ISV

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

Langkah berikutnya

Pelajari selengkapnya tentang multitenancy dan Azure Cosmos DB:

• Merancang dan membangun aplikasi SaaS multipenyewa dalam skala besar dengan Azure Cosmos DB: Sesi di Build 2024 yang membimbing Anda melalui cara merancang untuk multitenansi di Azure Cosmos DB dan mempelajari praktik terbaik dari vendor perangkat lunak independen yang nyata.
• Azure Cosmos DB dan sistem multipenyewa: Posting blog yang membahas cara membangun sistem multipenyewa yang menggunakan Azure Cosmos DB.
• Video: Aplikasi-aplikasi multipenyewa dengan Azure Cosmos DB
• Video: Membangun SaaS multipenyewa dengan Azure Cosmos DB dan Azure: Studi kasus dunia nyata tentang bagaimana Whally, startup SaaS multipenyewa, membangun platform modern dari awal di Azure Cosmos DB dan Azure. Whally menunjukkan keputusan desain dan implementasi yang mereka buat yang berkaitan dengan partisi, pemodelan data, multitenansi yang aman, performa, serta streaming real-time dari umpan perubahan ke SignalR. Semua solusi ini menggunakan ASP.NET Core di Azure App Service.

Sumber daya terkait

Lihat beberapa skenario arsitektur Azure Cosmos DB lainnya:

• Pendekatan penyimpanan dan data untuk multitenancy
• Pola Outbox Transaksional dengan Azure Cosmos DB