Arsitektur Multi-tenant untuk SaaS – CodeOpinion

Saat membangun Perangkat Lunak sebagai Layanan (SaaS), Anda sering kali perlu menggunakan Arsitektur Multi-penyewa. Ada banyak cara berbeda untuk memisahkan komputasi dan penyimpanan data dalam arsitektur multi-penyewa. Penyimpanan data bisa dalam silo atau dipartisi. Compute dapat dikumpulkan atau di-silo. Dan keduanya bersama-sama Anda dapat membuat jalur untuk grup penyewa. Dalam arsitektur ini, memiliki identitas setiap permintaan sangat penting untuk dapat merutekan permintaan hingga ke layanan dan sumber daya yang tepat.

Youtube

Lihat saluran YouTube saya tempat saya memposting semua jenis konten yang menyertai posting saya termasuk video ini yang menampilkan semua yang ada di posting ini.

Arsitektur penyewa tunggal

Pertama, mari kita bicara tentang arsitektur penyewa tunggal. Ini tidak berarti ini bukan lingkungan multi-pengguna, hanya saja semua pengguna termasuk dalam penyewa atau organisasi yang sama.

App (Compute) mengacu pada komputasi untuk menjalankan aplikasi Anda. Ini bisa menjadi beban seimbang atau berjalan sebagai beberapa contoh pada beberapa node. DB (Penyimpanan) adalah database Anda dan dependensi infrastruktur lainnya seperti cache, dll.

Dengan jenis topologi ini, jika Anda perlu pindah ke arsitektur multi-penyewa, opsi yang paling umum adalah mereplikasi komputasi dan penyimpanan untuk setiap penyewa baru.

Ini berarti setiap penyewa memiliki komputasi dan penyimpanannya sendiri. Tidak ada apa-apa.

Keuntungannya adalah setiap penyewa benar-benar tertutup. Mereka tidak berbagi apa-apa. Tidak ada kekhawatiran untuk data yang terkena penyewa yang salah. Setiap penyewa dapat ditingkatkan secara mandiri. Tidak ada “tetangga yang berisik”, yang berarti satu penyewa tidak dapat memonopoli atau menghabiskan sumber daya komputasi secara berlebihan yang memengaruhi penyewa lainnya.

Kerugiannya adalah mengelola lebih banyak infrastruktur, yang mencakup penerapan aplikasi dan penyimpanan perubahan terkait. Biaya berpotensi memiliki lebih banyak komputasi dan penyimpanan daripada yang dibutuhkan oleh penyewa. Jika penyewa hampir tidak menggunakan aplikasi dan hanya menghabiskan 5% dari komputasi, Anda hanya membuang-buang sumber daya dan masih harus membayar biaya sumber daya tersebut.

Arsitektur penyewa tunggal

Langkah logis berikutnya untuk sebagian besar adalah berbagi komputasi tetapi tetap memisahkan penyimpanan. Ini memungkinkan Anda untuk memisahkan data untuk mencegah memaparkan data ke penyewa yang salah tetapi berbagi sumber daya komputasi.

Arsitektur Multi-penyewa untuk SaaS

Hal ini memungkinkan Anda untuk memaksimalkan penggunaan dan penskalaan komputasi bila diperlukan, namun tetap memisahkan data. Untuk mencapai ini, aplikasi Anda sekarang harus mengetahui penyewa yang membuat permintaan aplikasi sehingga Anda dapat merutekan ke database/penyimpanan yang benar.

Pilihan lainnya adalah berbagi komputasi dan penyimpanan.

Arsitektur Multi-penyewa untuk SaaS

Dalam situasi ini, penggunaan komputasi dan penyimpanan Anda dimaksimalkan. Namun, ini berarti bahwa data tidak lagi silo. Ini berarti Anda harus menggunakan kunci partisi di tabel skema atau dokumen Anda untuk menunjukkan penyewa data tersebut. Dalam database relasional, ini berarti menambahkan TenantId ke tabel Anda.

Pada contoh di atas, baris pertama dan ketiga adalah milik Tenant1. Saat melakukan kueri apa pun ke database, Anda harus memfilter berdasarkan TenantId.

Identitas

Jika Anda berbagi komputasi atau penyimpanan dan menggunakan kunci partisi, Anda harus mengetahui siapa yang membuat permintaan ke aplikasi Anda sehingga Anda dapat merutekan ke database yang benar atau menggunakan kunci partisi. Identitas penting untuk mengelola ini.

Saat Anda memiliki pengguna yang masuk ke aplikasi Anda melalui cara apa pun, token yang dikembalikan ke klien/pengguna harus berisi beberapa pengidentifikasi Penyewa tempat pengguna tersebut berada.

Kemudian setiap permintaan yang dibuat ke aplikasi akan meneruskan token yang berisi TenantId. Ini kemudian dapat digunakan dalam kueri apa pun untuk memastikannya memfilter dan memilih data untuk penyewa tersebut.

Arsitektur Multi-penyewa untuk SaaS

Jika database dibungkam maka itu juga akan menggunakan TenantId dalam token untuk menentukan skema atau contoh database mana yang akan digunakan.

Arsitektur Multi-penyewa untuk SaaS

Sebagai contoh dari apa yang tampak seperti menggunakan Entity Framework Core adalah Anda dapat menggunakan HasQueryFilter saat membangun model agar DbContext secara otomatis menambahkan filter pada setiap kueri.

Ada banyak cara dan teknik yang berbeda untuk melakukan ini sehingga saat menulis kode aplikasi, Anda tidak perlu berpikir banyak untuk menulis filter yang sebenarnya. Anda tidak ingin harus berpikir untuk menulis logika ini sama sekali. Saya merekomendasikannya berada di level yang lebih tinggi atau diabstraksi sehingga ketika Anda menulis kode aplikasi, Anda merasa seperti berada dalam arsitektur penyewa tunggal dan bukan arsitektur multi penyewa.

hipermedia

Pilihan lain adalah menggunakan Hypermedia. Jika Anda sedang mengembangkan HTTP API, maka saat aplikasi klien Anda mengautentikasi dengan layanan Identity, itu juga akan menentukan host yang berinteraksi dengan Anda. Artinya itu akan memberi tahu klien saat runtime host mana yang akan membuat Permintaan HTTP.

Dengan hypermedia, Anda tidak membangun URI melainkan server menyediakannya kepada Anda sebagai tanggapan. Jika Anda ingin detail lebih lanjut tentang memanfaatkan hypermedia, lihat posting saya tentang membangun Aplikasi Halaman Tunggal yang Lebih Cerdas dengan REST API

Jika Anda mengembangkan aplikasi web yang dirender di sisi server, hal yang sama berlaku dengan mengarahkan pengguna ke host yang benar setelah login.

Apa yang disediakan ini adalah “jalur” yang berbeda. Mungkin ada banyak penyewa yang tergabung dalam satu jalur. Setiap jalur memiliki komputasi dan penyimpanannya sendiri. Ini benar-benar seperti campuran dan kecocokan dari segala sesuatu yang dijelaskan dalam posting ini.

Arsitektur Multi-penyewa untuk SaaS

Jalur memberi Anda beberapa fleksibilitas dalam cara Anda menerapkan. Anda dapat menerapkan pembaruan ke satu jalur sebagai penyebaran kenari. Anda dapat menerapkan ke satu jalur, memverifikasi bahwa perubahan berfungsi dengan benar dan semuanya stabil, dan jika demikian, terapkan ke lebih banyak jalur.

Pilihan

Mudah-mudahan, ini menggambarkan bahwa ada banyak cara untuk mengimplementasikan arsitektur multi-tenant. Anda dapat sepenuhnya silo dan memiliki penyewa yang memiliki komputasi dan penyimpanan sendiri. Penyewa dapat berbagi komputasi tetapi masih memiliki penyimpanan tersembunyi, atau Anda dapat berbagi komputasi dan penyimpanan dengan kunci partisi. Dengan semua opsi ini, Anda dapat memisahkan lebih jauh dengan menambahkan jalur.

tautan yang berhubungan

Ikuti @CodeOpinion di Twitter