Bagikan melalui

Multipenyewaan dan Azure Cosmos DB

  • Artikel

Pada halaman ini, kami menjelaskan beberapa fitur Azure Cosmos DB yang berguna saat Anda bekerja dengan sistem multipenyewa. Kami juga menautkan ke panduan dan contoh cara menggunakan Azure Cosmos DB dalam solusi multipenyewa.

Fitur Azure Cosmos DB yang mendukung multipenyewaan

Partisi

Dengan menggunakan partisi dengan kontainer Azure Cosmos DB, Anda dapat membuat kontainer yang dibagikan di 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 Pemecahan. Dengan kontainer besar, Azure Cosmos DB menyebarkan penyewa Anda di beberapa node fisik untuk mencapai skala tingkat tinggi.

Kami menyarankan agar Anda menjelajahi penggunaan kunci partisi hierarkis untuk meningkatkan performa solusi multipenyewa Anda. Kunci partisi hierarkis memungkinkan Anda membuat kunci partisi yang menyertakan beberapa nilai. Misalnya, Anda mungkin menggunakan kunci partisi hierarkis yang menyertakan pengidentifikasi penyewa dan jenis data yang Anda simpan. Pendekatan ini memungkinkan Anda untuk menskalakan di luar batas partisi logis 20 GB per nilai kunci partisi.

Informasi selengkapnya:

Mengelola unit permintaan

Model harga Azure Cosmos DB didasarkan pada jumlah unit permintaan per detik yang Anda provisikan atau konsumsi. Unit permintaan adalah abstraksi logis dari biaya operasi database atau kueri. Biasanya, Anda menyediakan jumlah unit permintaan yang ditentukan per detik untuk beban kerja Anda, yang disebut sebagai throughput. Azure Cosmos DB menyediakan beberapa opsi untuk cara Anda memprovisikan throughput. Di lingkungan multipenyewa, pilihan yang Anda buat memengaruhi performa dan harga sumber daya Azure Cosmos DB Anda.

Satu model penyewaan untuk Azure Cosmos DB melibatkan penyebaran kontainer terpisah untuk setiap penyewa dalam database bersama. Azure Cosmos DB memungkinkan Anda menyediakan unit permintaan untuk database, dan semua kontainer berbagi unit permintaan. Jika beban kerja penyewa Anda biasanya tidak tumpang tindih, pendekatan ini dapat membantu mengurangi biaya operasional Anda. Namun, pendekatan ini rentan terhadap masalah Noisy Neighbor karena kontainer penyewa tunggal mungkin mengonsumsi jumlah unit permintaan 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 dalam database terus berbagi throughput mereka, tetapi penyewa yang berisik menggunakan throughput khususnya sendiri.

Azure Cosmos DB juga menyediakan tingkat tanpa server, yang cocok untuk beban kerja dengan lalu lintas terputus-terputus atau tidak dapat diprediksi. Atau, penskalaan otomatis memungkinkan Anda mengonfigurasi kebijakan untuk menentukan penskalaan throughput yang disediakan. Selain itu, Anda dapat memanfaatkan kapasitas ledakan Azure Cosmos DB, memaksimalkan pemanfaatan kapasitas throughput yang disediakan, yang akan dibatasi tarifnya. Dalam solusi multipenyewa, Anda dapat menggabungkan semua pendekatan ini untuk mendukung berbagai jenis penyewa.

Catatan

Saat merencanakan konfigurasi Azure Cosmos DB Anda, pastikan Anda mempertimbangkan kuota dan batas layanan.

Untuk memantau dan mengelola biaya yang terkait dengan setiap penyewa, setiap operasi menggunakan API Azure Cosmos DB menyertakan unit permintaan yang digunakan. Anda dapat menggunakan informasi ini untuk mengumpulkan dan membandingkan unit permintaan aktual yang digunakan oleh masing-masing penyewa, dan Anda selanjutnya dapat mengidentifikasi penyewa dengan karakteristik performa yang berbeda.

Informasi selengkapnya:

Kunci yang dikelola pelanggan

Beberapa penyewa mungkin memerlukan penggunaan kunci enkripsinya sendiri. Azure Cosmos DB menyediakan fitur kunci yang dikelola pelanggan. Fitur ini diterapkan pada tingkat akun Azure Cosmos DB, sehingga penyewa yang memerlukan kunci enkripsi mereka sendiri perlu disebarkan menggunakan akun Azure Cosmos DB khusus.

Informasi selengkapnya:

Model isolasi

Saat bekerja dengan sistem multipenyewa yang menggunakan Azure Cosmos DB, Anda perlu membuat keputusan tentang tingkat isolasi yang ingin Anda gunakan. Business-to-business (B2B) mengacu pada penjualan ke bisnis. Business-to-consumer (B2C) mengacu pada penjualan langsung kepada pelanggan individu yang menggunakan produk atau layanan. Azure Cosmos DB mendukung beberapa model isolasi:

Kebutuhan beban kerja Kunci partisi per penyewa Kontainer per penyewa (throughput bersama) Kontainer per penyewa (throughput khusus) Database per penyewa Akun database per penyewa
Kueri di seluruh penyewa Mudah (kontainer bertindak sebagai batas untuk kueri) Cetak Cetak Cetak Cetak
Kepadatan penyewa Tinggi (biaya terendah per penyewa) Medium Kurang Penting Kurang Penting Kurang Penting
Penghapusan data penyewa Cetak Mudah (hilangkan kontainer saat penyewa pergi) Mudah (hilangkan kontainer saat penyewa pergi) Mudah (hilangkan database saat penyewa pergi) Mudah (hilangkan database saat penyewa pergi)
Isolasi keamanan akses data Perlu diimplementasikan dalam aplikasi RBAC Kontainer RBAC Kontainer Database RBAC RBAC
Replikasi lokasi geografis Replikasi geografis per penyewa tidak dimungkinkan Penyewa grup dalam akun database berdasarkan persyaratan Penyewa grup dalam akun database berdasarkan persyaratan Penyewa grup dalam akun database berdasarkan persyaratan Penyewa grup dalam akun database berdasarkan persyaratan
Pencegahan tetangga yang bising Tidak Tidak Ya Ya Ya
Latensi pembuatan penyewa baru Segera Cepat Cepat Medium Lambat
Keuntungan pemodelan data Tidak kolokasi entitas kolokasi entitas Beberapa kontainer untuk memodelkan entitas penyewa Beberapa kontainer dan database untuk memodelkan penyewa
Kunci enkripsi Sama untuk semua penyewa Sama untuk semua penyewa Sama untuk semua penyewa Sama untuk semua penyewa Kunci yang dikelola pelanggan per penyewa
Persyaratan throughput >0 RU per penyewa >100 RU per penyewa >100 RU per penyewa (hanya dengan skala otomatis, jika tidak >, 400 RU per penyewa) >400 RU per penyewa >400 RU per penyewa
Contoh kasus penggunaan Aplikasi B2C Penawaran standar untuk aplikasi B2B Penawaran premium untuk aplikasi B2B Penawaran premium untuk aplikasi B2B Penawaran premium untuk aplikasi B2B

Kunci partisi per penyewa

Saat Anda menggunakan satu kontainer untuk beberapa penyewa, Anda dapat menggunakan dukungan partisi Azure Cosmos DB. Dengan menggunakan kunci partisi terpisah untuk setiap penyewa, Anda dapat dengan mudah mengkueri data untuk satu penyewa. Anda juga dapat mengkueri di beberapa penyewa, meskipun berada di partisi terpisah. Namun, kueri lintas partisi memiliki biaya unit permintaan (RU) yang lebih tinggi daripada kueri partisi tunggal.

Pendekatan ini cenderung berfungsi dengan baik ketika jumlah data yang disimpan untuk setiap penyewa kecil. Ini bisa menjadi pilihan yang baik untuk membangun model harga yang mencakup tingkat gratis, dan untuk solusi bisnis ke konsumen (B2C). Secara umum, dengan menggunakan kontainer bersama, Anda mencapai kepadatan penyewa tertinggi dan karenanya harga terendah per penyewa.

Penting untuk mempertimbangkan throughput kontainer Anda. Semua penyewa akan membagikan throughput kontainer, sehingga masalah Noisy Neighbor dapat menyebabkan tantangan performa jika penyewa Anda memiliki beban kerja yang tinggi atau tumpang tindih. Masalah ini kadang-kadang dapat dikurangi dengan mengelompokkan subset penyewa ke dalam kontainer yang berbeda, dan dengan memastikan bahwa setiap grup penyewa memiliki pola penggunaan yang kompatibel. Atau, Anda dapat mempertimbangkan model multi-penyewa hibrid dan penyewa tunggal. Kelompokkan penyewa yang lebih kecil ke dalam kontainer yang dipartisi bersama, dan berikan kontainer khusus pelanggan besar. Selain itu, ada fitur yang dapat membantu mengontrol masalah tetangga yang bising saat memodelkan penyewa dengan partisi, seperti realokasi throughput, kapasitas ledakan, dan kontrol throughput di Java SDK.

Penting juga untuk mempertimbangkan jumlah data yang Anda simpan di setiap partisi logis. Azure Cosmos DB memungkinkan setiap partisi logis tumbuh 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, daripada memiliki satu kunci partisi dari Contoso, Anda dapat melakukan salt kunci partisi dengan membuat beberapa kunci partisi untuk penyewa, seperti Contoso1, Contoso2, dan sebagainya. Saat Anda mengkueri data untuk penyewa, Anda dapat menggunakan klausa WHERE IN untuk mencocokkan semua kunci partisi. Kunci partisi hierarkis juga dapat digunakan untuk mendukung penyewa besar, dengan penyimpanan lebih besar dari 20 GB, tanpa harus menggunakan kunci partisi sintetis atau beberapa nilai kunci partisi per penyewa.

Pertimbangkan aspek operasional solusi Anda, dan berbagai fase siklus hidup penyewa. Misalnya, saat penyewa berpindah ke tingkat harga khusus, Anda mungkin perlu memindahkan data ke kontainer yang berbeda. Saat penyewa dinonaktifkan, Anda perlu menjalankan kueri hapus pada kontainer untuk menghapus data, dan untuk penyewa besar, kueri ini mungkin akan menghabiskan throughput dalam jumlah besar saat dijalankan.

Kontainer per penyewa

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

Saat menggunakan kontainer untuk setiap penyewa, Anda dapat mempertimbangkan berbagi throughput dengan penyewa lain dengan menyediakan throughput pada tingkat database. Pertimbangkan larangan dan batasan di sekitar jumlah minimum unit permintaan untuk database Anda dan jumlah maksimum kontainer dalam database. Selain itu, pertimbangkan apakah penyewa Anda memerlukan tingkat performa yang terjamin, dan apakah mereka rentan terhadap masalah Noisy Neighbor. 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 ada 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 Noisy Neighbor. Namun, 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, selama semua entitas dapat berbagi kunci partisi yang sama, mereka dapat dikolokasikan dalam kontainer yang sama. Namun, 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 di bawah ini. Lihat artikel kami tentang cara memodelkan dan mempartisi data di Azure Cosmos DB menggunakan contoh dunia nyata untuk panduan selengkapnya.

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

Database per penyewa

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

Seperti model akun per penyewa di bawah ini, pendekatan ini memberikan tingkat isolasi performa tertinggi, tetapi memberikan kepadatan penyewa terendah. Namun, opsi ini adalah yang terbaik ketika setiap penyewa memerlukan model data yang lebih rumit daripada layak dalam model kontainer per penyewa. Atau, Anda harus mengikuti pendekatan ini ketika itu adalah persyaratan untuk pembuatan penyewa baru agar cepat dan/atau bebas dari overhead apa pun untuk membuat akun penyewa di muka. Mungkin juga demikian, untuk kerangka kerja pengembangan perangkat lunak tertentu yang digunakan, database-per-penyewa adalah satu-satunya tingkat isolasi performa yang dikenali dalam kerangka kerja tersebut. Isolasi tingkat entitas (kontainer) dan kolokasi entitas biasanya tidak didukung secara asli dalam kerangka kerja tersebut.

Akun database per penyewa

Azure Cosmos DB memungkinkan Anda menyediakan akun database terpisah untuk setiap penyewa, yang menyediakan tingkat isolasi tertinggi, tetapi kepadatan terendah. Seperti model kontainer per penyewa dan database per penyewa di atas, model ini memberikan isolasi performa yang lebih besar daripada model kunci partition-key-per-tenant. Ini juga menyediakan peningkatan isolasi keamanan akses data melalui Azure RBAC. Selain itu, model ini menyediakan isolasi keamanan enkripsi database di tingkat penyewa melalui kunci yang dikelola pelanggan.

Satu akun database didedikasikan untuk penyewa, yang berarti mereka tidak tunduk pada masalah tetangga yang bising. 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 menggunakan akun Azure Cosmos DB khusus per penyewa, pertimbangkan jumlah maksimum akun Azure Cosmos DB per langganan Azure.

Jika Anda menggunakan model ini, Anda harus mempertimbangkan seberapa cepat aplikasi Anda harus dapat menghasilkan penyewa baru. Pembuatan akun di Azure Cosmos DB dapat memakan waktu beberapa menit, jadi Anda mungkin perlu membuat akun di muka. Jika pendekatan ini tidak layak, pertimbangkan model database per penyewa.

Jika Anda mengizinkan penyewa untuk bermigrasi dari akun bersama ke akun Azure Cosmos DB khusus, pertimbangkan pendekatan migrasi yang akan Anda gunakan untuk memindahkan data penyewa antara akun lama dan baru.

Pendekatan hybrid

Anda dapat mempertimbangkan kombinasi pendekatan di atas agar sesuai dengan persyaratan penyewa yang berbeda dan model harga Anda. Contohnya:

  • Beri uji coba gratis kepada semua pelanggan dalam kontainer bersama, dan gunakan ID penyewa atau kunci partisi kunci sintetis.
  • Tawarkan tingkat Bronze berbayar yang menyebarkan kontainer khusus per penyewa, tetapi dengan throughput bersama pada database.
  • Tawarkan tingkat Silver yang lebih tinggi yang menyediakan throughput khusus untuk kontainer penyewa.
  • Tawarkan tingkat Gold tertinggi, dan sediakan akun database khusus untuk penyewa, yang juga memungkinkan penyewa memilih geografi untuk penyebarannya.

Kontributor

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

Penulis utama:

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

Kontributor lain:

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

Langkah berikutnya

Tinjau pendekatan penyimpanan dan data untuk multi-penyewaan.

Pelajari selengkapnya tentang multitenancy dan Azure Cosmos DB:

Lihat beberapa skenario arsitektur Cosmos DB lainnya: