Dokumen ini menjelaskan berbagai cara untuk mengimplementasikan multi-tenancy di Spanner. Bagian ini juga membahas pola pengelolaan data dan pengelolaan siklus proses tenant.
Multi-tenancy adalah saat satu instance, atau beberapa instance, dari sebuah aplikasi software melayani beberapa tenant atau pelanggan. Pola software ini dapat diskalakan dari satu tenant atau pelanggan hingga ratusan atau ribuan. Pendekatan ini bersifat mendasar untuk platform cloud computing, tempat infrastruktur yang mendasarinya digunakan bersama di beberapa organisasi.
Bayangkan multi-tenancy sebagai bentuk partisi berdasarkan resource komputasi bersama, seperti database. Analoginya adalah tenant di gedung apartemen: infrastruktur bersama, tetapi ruang tenant khusus. Multi-tenancy adalah bagian dari sebagian besar, atau mungkin semua, aplikasi software-as-a-service (SaaS).
Dokumen ini ditujukan untuk arsitek database, arsitek data, dan engineer yang mengimplementasikan aplikasi multi-tenant di Spanner sebagai database relasional mereka. Dengan menggunakan konteks tersebut, dokumen ini menjelaskan berbagai pendekatan untuk menyimpan data multi-tenant. Istilah "tenant", "pelanggan", dan "organisasi" digunakan secara bergantian di seluruh artikel untuk menunjukkan entity yang mengakses aplikasi multi-tenant.
Artikel ini menggunakan penyedia SaaS sumber daya manusia (HR) yang menerapkan aplikasi multi-tenantnya di Google Cloud sebagai contoh. Dalam contoh ini, beberapa pelanggan penyedia SaaS HR harus mengakses aplikasi multi-tenant. Pelanggan ini disebut tenant.
Spanner adalah database Google Cloud yang terkelola sepenuhnya, berkelas perusahaan, terdistribusi, dan konsisten yang menggabungkan manfaat model database relasional dengan skalabilitas horizontal non-relasional. Spanner memiliki semantik relasional—dengan skema, jenis data yang diterapkan, konsistensi yang kuat, transaksi ACID multi-pernyataan, dan bahasa kueri SQL yang menerapkan ANSI 2011 SQL.
Spanner memberikan periode nonaktif nol untuk pemeliharaan terencana atau kegagalan region, dengan SLA ketersediaan 99,999%. Solusi ini mendukung aplikasi multi-tenant modern dengan memberikan ketersediaan dan skalabilitas tinggi. Artikel ini membahas berbagai pendekatan arsitektur untuk mengimplementasikan multi-tenancy dengan Spanner.
Kriteria untuk kriteria pemetaan data tenant
Dalam aplikasi multi-tenant, data setiap tenant diisolasi dalam salah satu dari beberapa pendekatan arsitektur di database Spanner yang mendasarinya. Daftar berikut menguraikan berbagai pendekatan arsitektur yang digunakan untuk memetakan data tenant ke Spanner:
- Instance: Tenant berada secara eksklusif di satu instance Spanner, dengan persis satu database untuk tenant tersebut.
- Database: Tenant berada di database dalam satu instance Spanner yang berisi beberapa database.
- Skema: tenant berada di tabel eksklusif dalam database, dan beberapa tenant dapat ditempatkan di database yang sama.
- Tabel: Data tenant adalah baris dalam tabel database. Tabel tersebut dibagikan kepada tenant lain.
Kriteria sebelumnya disebut pola pengelolaan data dan dibahas secara mendetail di bagian Pola pengelolaan data multi-tenancy. Diskusi tersebut didasarkan pada kriteria berikut:
- Isolasi: Tingkat isolasi data di beberapa tenant adalah pertimbangan utama untuk multi-tenancy. Isolasi didorong oleh pilihan yang dibuat untuk kriteria dalam kategori lain—misalnya, persyaratan peraturan dan kepatuhan tertentu dapat menentukan tingkat isolasi yang lebih tinggi.
- Ketangkasan: Kemudahan aktivitas onboarding dan offboarding untuk tenant sehubungan dengan pembuatan instance, database, atau tabel.
- Operasi: Ketersediaan atau kompleksitas penerapan operasi database standar, khusus tenant, dan aktivitas administrasi, misalnya, pemeliharaan rutin, logging, pencadangan, atau operasi pemulihan dari bencana (disaster recovery).
- Penskalaan: Kemampuan untuk melakukan penskalaan dengan lancar guna mendukung pertumbuhan di masa mendatang. Deskripsi setiap pola berisi jumlah tenant yang dapat didukung pola.
- Performa: Kemampuan untuk mengalokasikan resource eksklusif ke setiap tenant, mengatasi fenomena noisy neighbor, dan memungkinkan performa baca dan tulis yang dapat diprediksi untuk setiap tenant.
- Peraturan dan kepatuhan: Kemampuan untuk memenuhi persyaratan industri dan negara yang diatur dengan ketat yang memerlukan isolasi lengkap resource dan operasi pemeliharaan—misalnya, persyaratan residensi data untuk Prancis mewajibkan informasi identitas pribadi disimpan secara fisik dan eksklusif di Prancis.
Setiap pola pengelolaan data yang berkaitan dengan kriteria ini akan dijelaskan di bagian berikutnya. Gunakan kriteria yang sama saat memilih pola pengelolaan data untuk kumpulan tenant tertentu.
Pola pengelolaan data multi-tenancy
Bagian berikut ini menjelaskan empat pola pengelolaan data utama: instance, database, skema, dan tabel.
Instance
Untuk memberikan isolasi penuh, pola pengelolaan data instance menyimpan data setiap tenant dalam instance dan database Spanner-nya sendiri. Instance Spanner dapat memiliki satu atau beberapa database. Dalam pola ini, hanya satu database yang dibuat. Untuk aplikasi HR yang telah dibahas sebelumnya, instance Spanner yang terpisah dengan satu database dibuat untuk setiap organisasi pelanggan.
Seperti yang terlihat pada diagram berikut, pola pengelolaan data memiliki satu tenant per instance.
Memiliki instance terpisah untuk setiap tenant memungkinkan penggunaan project Google Cloud yang terpisah untuk mencapai batas kepercayaan yang terpisah untuk tenant yang berbeda. Manfaat tambahannya adalah setiap konfigurasi instance dapat dipilih berdasarkan lokasi setiap tenant (baik secara regional maupun multi-regional), yang mengoptimalkan fleksibilitas dan performa lokasi.
Arsitektur ini dapat dengan mudah diskalakan ke berapa pun jumlah tenant. Penyedia SaaS dapat membuat sejumlah instance di region yang diinginkan, tanpa batas ketat.
Tabel berikut menguraikan bagaimana pola pengelolaan data instance memengaruhi berbagai kriteria.
| Kriteria | Instance — pola pengelolaan data satu tenant per instance |
|---|---|
| Isolasi |
|
| Ketangkasan |
|
| Operasi |
|
| Skala |
|
| Performa |
|
| Persyaratan peraturan dan kepatuhan |
|
Singkatnya, hal-hal yang perlu diingat adalah:
- Keuntungan: Tingkat isolasi tertinggi
- Kekurangan: Overhead operasional terbesar
Pola pengelolaan data instance paling cocok untuk skenario berikut:
- Tenant yang berbeda tersebar di berbagai wilayah dan membutuhkan solusi yang dilokalkan.
- Persyaratan peraturan dan kepatuhan untuk beberapa tenant memerlukan tingkat protokol keamanan dan audit yang lebih tinggi.
- Ukuran tenant sangat bervariasi, sehingga berbagi resource di antara tenant dengan traffic tinggi dan bervolume tinggi dapat menyebabkan pertentangan dan penurunan kualitas bersama.
Database
Dalam pola pengelolaan data database, setiap tenant berada di database dalam satu instance Spanner. Beberapa database dapat berada dalam satu instance. Jika satu instance tidak cukup untuk jumlah tenant tersebut, buat beberapa instance. Pola ini menyiratkan bahwa satu instance Spanner dibagikan di antara beberapa tenant.
Spanner memiliki batas ketat 100 database per instance. Batasan ini berarti bahwa jika penyedia SaaS perlu menskalakan lebih dari 100 pelanggan, mereka harus membuat dan menggunakan beberapa instance Spanner.
Untuk aplikasi HR, penyedia SaaS membuat dan mengelola setiap tenant dengan database terpisah dalam instance Spanner.
Seperti yang terlihat pada diagram berikut, pola pengelolaan data memiliki satu tenant per database.
Pola pengelolaan data database mencapai isolasi logis pada level database untuk data tenant yang berbeda. Namun, karena merupakan instance Spanner tunggal, semua database tenant memiliki konfigurasi regional yang sama serta penyiapan komputasi dan penyimpanan yang mendasarinya.
Tabel berikut menguraikan bagaimana pola pengelolaan data database memengaruhi berbagai kriteria.
| Kriteria | Database — pola pengelolaan data satu tenant per database |
|---|---|
| Isolasi |
|
| Ketangkasan |
|
| Operations |
|
| Skala |
|
| Performa |
|
| Persyaratan peraturan dan kepatuhan |
|
Singkatnya, hal-hal yang perlu diingat adalah:
- Keuntungan: Tingkat isolasi yang lebih tinggi
- Kekurangan: Jumlah tenant yang terbatas per instance; infleksibilitas lokasi
Pola pengelolaan data database paling cocok untuk skenario berikut:
- Beberapa pelanggan berada di residensi data yang sama—misalnya, Prancis, atau Inggris Raya—dan/atau berada di bawah otoritas peraturan yang sama.
- Tenant memerlukan pemisahan data berbasis sistem dan pencadangan/pemulihan, tetapi memperbolehkan berbagi resource infrastruktur.
Skema
Dalam pola pengelolaan data skema, satu database—yang menerapkan
satu skema—digunakan untuk beberapa tenant dan kumpulan tabel yang terpisah digunakan
untuk data setiap tenant. Tabel ini dapat dibedakan dengan menyertakan
tenant ID dalam nama tabel sebagai awalan atau akhiran.
Pola pengelolaan data yang menggunakan kumpulan tabel terpisah untuk setiap tenant ini memberikan tingkat isolasi yang jauh lebih rendah dibandingkan dengan opsi sebelumnya (pola pengelolaan instance dan database). Pola ini juga mempermudah proses onboarding; pola ini melibatkan pembuatan tabel baru serta integritas dan indeks referensial yang terkait.
Salah satu peringatan yang signifikan adalah izin akses untuk Spanner melalui Identity and Access Management (IAM) hanya disediakan di tingkat instance atau database. Izin akses tidak dapat diberikan di tingkat tabel. Ada juga batasan 5.000 tabel per database. Untuk banyak pelanggan, batasan tersebut membatasi penggunaan aplikasi oleh mereka.
Selain itu, menggunakan tabel terpisah untuk setiap pelanggan dapat menghasilkan backlog yang besar terkait operasi pembaruan skema. Backlog tersebut membutuhkan waktu lama untuk diselesaikan.
Untuk aplikasi HR, penyedia SaaS dapat membuat kumpulan tabel untuk setiap
pelanggan dengan tenant ID sebagai awalan dalam nama tabel—misalnya,
customer1_employee, customer1_payroll, customer1_department.
Seperti yang terlihat pada diagram berikut, pola pengelolaan data skema memiliki satu kumpulan tabel untuk setiap tenant.
Tabel berikut menguraikan bagaimana pola pengelolaan data skema memengaruhi berbagai kriteria.
| Kriteria | Skema — satu kumpulan tabel untuk setiap pola pengelolaan data tenant |
|---|---|
| Isolasi |
|
| Ketangkasan |
|
| Operasi |
|
| Skala |
|
| Performa |
|
| Persyaratan peraturan dan kepatuhan |
|
Singkatnya, hal-hal yang perlu diingat adalah:
- Kelebihan: Onboarding mudah dilakukan
- Kekurangan: Overhead operasional yang lebih tinggi; tidak ada kontrol keamanan di level tabel
Pola manajemen data skema paling cocok untuk skenario berikut:
- Aplikasi internal yang melayani berbagai departemen, di mana isolasi keamanan data yang ketat bukanlah masalah utama jika dibandingkan dengan kemudahan pemeliharaan.
- Aplikasi multi-tenant yang datanya tidak memerlukan pemisahan ketat berdasarkan persyaratan hukum atau peraturan.
Meskipun Anda dapat membuat beberapa kumpulan tabel (masing-masing kumpulan mewakili tenant) dalam database, model ini adalah pola yang paling tidak ideal dari perspektif database. Alasan utamanya adalah bahwa tabel harus mengikuti konvensi penamaan. Aplikasi dan semua alat database (misalnya IDE, dan alat migrasi skema), harus memahami konvensi penamaan. Selain itu, jika jumlah tabel cukup besar per tenant, pola pengelolaan data skema tidak akan memberikan penskalaan yang signifikan.
Pendekatan yang lebih baik adalah beralih ke satu database per tenant dan meningkatkan jumlah instance, atau beralih ke pola pengelolaan data tabel.
Tabel
Pola pengelolaan data akhir melayani beberapa tenant dengan kumpulan tabel
umum. Setiap tabel berisi data untuk beberapa tenant. Pola pengelolaan data ini
merepresentasikan tingkat multi-tenancy yang ekstrem, di mana segala sesuatu, mulai dari
infrastruktur, skema, hingga model data, dibagikan di antara beberapa tenant. Dalam
tabel, baris dipartisi berdasarkan kunci utama, dengan tenant ID sebagai
elemen pertama kunci tersebut. Dari perspektif penskalaan, Spanner
mendukung pola ini dengan paling baik karena dapat menskalakan tabel tanpa batasan.
Untuk aplikasi HR, kunci utama tabel penggajian dapat berupa kombinasi
customerID dan payrollID.
Seperti yang terlihat pada diagram berikut, pola pengelolaan data tabel memiliki satu tabel untuk beberapa tenant.
Serupa dengan pola skema, akses data dalam pola tabel tidak dapat dikontrol secara terpisah untuk tenant yang berbeda. Menggunakan lebih sedikit tabel berarti operasi pembaruan skema selesai lebih cepat jika setiap tenant memiliki tabel database-nya sendiri. Pendekatan ini pada dasarnya menyederhanakan onboarding, offboarding, dan operasi.
Tabel berikut menguraikan bagaimana pola pengelolaan data tabel memengaruhi berbagai kriteria.
| Kriteria | Tabel — pola pengelolaan data satu tabel untuk beberapa tenant |
|---|---|
| Isolasi |
|
| Ketangkasan |
|
| Operations |
|
| Skala |
|
| Performa |
|
| Persyaratan peraturan dan kepatuhan |
|
Singkatnya, hal-hal yang perlu diingat adalah:
- Kelebihan: Sangat skalabel; memiliki overhead operasional yang rendah
- Kekurangan: Pertentangan resource yang tinggi; tidak ada kontrol keamanan untuk setiap tenant
Pola ini paling cocok untuk skenario berikut:
- Aplikasi internal yang melayani berbagai departemen, di mana isolasi keamanan data yang ketat bukanlah masalah yang utama jika dibandingkan dengan kemudahan pemeliharaan.
- Berbagi resource maksimum untuk tenant yang menggunakan fungsionalitas aplikasi paket gratis saat meminimalkan penyediaan resource secara bersamaan.
Pola pengelolaan data dan pengelolaan siklus proses tenant
Tabel berikut membandingkan berbagai pola pengelolaan data di semua kriteria pada tingkat tinggi.
| Instance | Database | Skema | Tabel | |
|---|---|---|---|---|
| Isolasi | Selesai | Selesai | Rendah | Terendah |
| Ketangkasan | Rendah | Sedang | Sedang | Tertinggi |
| Kemudahan pengoperasian | Tinggi | Tinggi | Rendah | Rendah |
| Menskalakan | Tinggi | Terbatas | Berpotensi sangat terbatas | Tinggi |
| Performa* | Tinggi | Sedang | Sedang | Berpotensi tinggi |
| Peraturan dan kepatuhan | Tertinggi | Tinggi | Rendah | Rendah |
* Performa sangat bergantung pada desain skema dan praktik terbaik kueri. Nilai yang ada di sini hanyalah ekspektasi rata-rata.
Pola pengelolaan data terbaik untuk aplikasi multi-tenant tertentu adalah pola yang memenuhi sebagian besar persyaratannya berdasarkan kriteria. Jika kriteria tertentu tidak diperlukan, Anda dapat mengabaikan baris yang memuatnya.
Pola pengelolaan data gabungan
Sering kali, satu pola pengelolaan data sudah cukup untuk memenuhi persyaratan aplikasi multi-tenant. Ketika demikian, desain dapat mengasumsikan satu pola manajemen data.
Akan tetapi, beberapa aplikasi multi-tenant memerlukan beberapa pola pengelolaan data secara bersamaan, misalnya, aplikasi multi-tenant yang mendukung paket gratis, paket reguler, dan paket enterprise.
Paket gratis:
- Harus hemat biaya
- Harus memiliki batas atas volume data
- Biasanya mendukung fungsi terbatas
- Pola pengelolaan data tabel adalah kandidat paket gratis yang baik
- Pengelolaan tenant bersifat sederhana
- Tidak perlu membuat resource tenant spesifik atau eksklusif
Paket reguler:
- Cocok untuk klien berbayar yang tidak secara khusus memiliki persyaratan penskalaan atau isolasi yang kuat
- Pola pengelolaan data skema atau pola pengelolaan
data database adalah kandidat paket reguler yang baik
- Tabel dan indeks bersifat eksklusif untuk tenant
- Pencadangan mudah dalam pola pengelolaan data database
- Pencadangan tidak didukung untuk pola pengelolaan data skema
- Pencadangan tenant harus diimplementasikan sebagai utilitas di luar Spanner
Paket enterprise:
- Biasanya paket kelas atas dengan otonomi penuh dalam semua aspek
- Tenant memiliki resource khusus yang mencakup penskalaan khusus dan isolasi penuh
- Pola pengelolaan data instance sangat cocok untuk paket perusahaan
Praktik terbaik adalah menyimpan pola manajemen data yang berbeda di dalam database yang berbeda. Meskipun Anda dapat menggabungkan pola pengelolaan data yang berbeda dalam database Spanner, tindakan tersebut akan mempersulit implementasi logika akses dan operasi siklus proses aplikasi.
Bagian Desain aplikasi menguraikan beberapa pertimbangan desain aplikasi multi-tenant yang berlaku saat menggunakan satu pola pengelolaan data atau beberapa pola pengelolaan data.
Mengelola siklus proses tenant
Tenant memiliki siklus proses. Oleh karena itu, Anda harus menerapkan operasi pengelolaan yang sesuai dalam aplikasi multi-tenant Anda. Selain operasi dasar untuk membuat, memperbarui, dan menghapus tenant, pertimbangkan operasi terkait data tambahan berikut:
Mengekspor data tenant:
- Saat menghapus tenant, praktik terbaiknya adalah mengekspor datanya terlebih dahulu dan mungkin menyediakan set data tersebut untuk mereka.
- Saat menggunakan pola pengelolaan data skema atau tabel, sistem aplikasi multi-tenant harus menerapkan ekspor atau memetakannya ke fungsi database (ekspor database).
Mencadangkan data tenant:
- Saat menggunakan pola pengelolaan data instance atau database dan mencadangkan data untuk masing-masing tenant, gunakan fungsi ekspor atau pencadangan database.
- Saat menggunakan pola pengelolaan data skema atau tabel dan mencadangkan data untuk masing-masing tenant, aplikasi multi-tenant harus menerapkan operasi ini. Database Spanner tidak dapat menentukan data mana yang menjadi milik tenant tertentu.
Memindahkan data tenant:
Untuk memindahkan tenant dari satu pola pengelolaan data ke pola lainnya (atau memindahkan tenant dalam pola pengelolaan data yang sama di antara instance atau database), diperlukan ekstrak data dari pola pengelolaan data tabel dan penyisipan data tersebut ke dalam pola pengelolaan data database.
- Jika periode nonaktif aplikasi mungkin terjadi, lakukan ekspor/impor.
- Jika periode nonaktif tidak memungkinkan, lakukan migrasi database dengan periode nonaktif nol.
Mengurangi noisy neighbor adalah alasan lain untuk memindahkan tenant.
Desain aplikasi
Saat mendesain aplikasi multi-tenant, terapkan logika bisnis yang peka tenant. Artinya, setiap kali aplikasi menjalankan logika bisnis, aplikasi harus selalu berada dalam konteks tenant yang diketahui.
Dari perspektif database, desain aplikasi berarti setiap kueri harus dijalankan terhadap pola pengelolaan data tempat tenant berada. Bagian berikut menyoroti beberapa konsep utama dari desain aplikasi multi-tenant.
Koneksi tenant dinamis dan konfigurasi kueri
Pemetaan data tenant secara dinamis ke permintaan aplikasi tenant menggunakan konfigurasi pemetaan:
- Untuk pola pengelolaan data database atau pola pengelolaan data instance, string koneksi sudah cukup untuk mengakses data tenant.
- Untuk pola pengelolaan data skema, nama tabel yang benar harus ditentukan.
- Untuk pola pengelolaan data tabel, kueri harus dijalankan terhadap database. Gunakan predikat yang sesuai untuk mengambil data tenant tertentu.
Tenant dapat berada di salah satu dari empat pola pengelolaan data. Implementasi pemetaan berikut menangani konfigurasi koneksi untuk kasus umum aplikasi multi-tenant yang menggunakan semua pola pengelolaan data secara bersamaan. Saat tenant tertentu berada di satu pola, beberapa aplikasi multi-tenant akan menggunakan satu pola pengelolaan data untuk semua tenant. Kasus ini dicakup secara implisit oleh pemetaan berikut.
Jika tenant menjalankan logika bisnis (misalnya, karyawan login dengan ID tenant-nya), logika aplikasi tersebut harus menentukan pola pengelolaan data tenant, lokasi data untuk ID tenant yang ditentukan, dan, secara opsional, konvensi penamaan tabel (untuk pola skema).
Logika aplikasi ini memerlukan pemetaan pola pengelolaan tenant-ke-data. Dalam
contoh kode berikut, connection string mengacu pada database tempat
data tenant berada. Contoh ini mengidentifikasi instance
Spanner dan database. Untuk database dan instance pola pengelolaan
data, kode berikut sudah cukup bagi aplikasi untuk menghubungkan dan
menjalankan kueri:
tenant id -> (data management pattern,
database connection string,
[table_prefix])
Desain tambahan diperlukan untuk pola pengelolaan data skema dan tabel.
Pola pengelolaan data skema
Untuk pola pengelolaan data skema, ada beberapa tenant dalam database yang sama. Setiap tenant memiliki kumpulan tabelnya sendiri. Tabel-tabel tersebut dibedakan berdasarkan namanya. Tabel mana yang termasuk dalam tenant mana akan bersifat deterministik.
Salah satu pendekatan adalah dengan menambahkan ID tenant pada nama tabel, misalnya,
tabel EMPLOYEE disebut T356_EMPLOYEE untuk tenant dengan ID 356. Aplikasi
harus menambahkan awalan Ttenant ID
pada setiap tabel sebelum mengirim kueri ke database yang
ditampilkan pemetaan.
Pendekatan lainnya adalah dengan menambahkan table_prefix ke pemetaan yang digunakan oleh
kueri agar menemukan tabel yang benar untuk tenant.
Pendekatan campuran juga dapat dilakukan: jika pola pengelolaan data adalah pola skema, dan awalan tabel kosong, pemetaan default akan terjadi (menambahkan ID tenant pada nama tabel).
Pola pengelolaan data tabel
Desain yang serupa diperlukan untuk pola pengelolaan data tabel. Dalam pola ini, ada satu skema. Data tenant disimpan sebagai baris. Untuk mengakses data dengan benar, tambahkan predikat ke setiap kueri untuk memilih tenant yang sesuai.
Salah satu pendekatan untuk menemukan tenant yang sesuai adalah dengan memiliki kolom yang
disebut TENANT di setiap tabel. Nilai kolom adalah tenant ID. Setiap kueri harus menambahkan
predikat AND TENANT = tenant ID ke klausa WHERE yang ada atau menambahkan
klausa WHERE dengan predikat AND TENANT = tenant ID.
Untuk terhubung ke database dan membuat kueri yang tepat, ID tenant harus tersedia di logika aplikasi. Itu dapat diteruskan sebagai parameter atau disimpan sebagai konteks thread.
Beberapa operasi siklus proses mengharuskan Anda mengubah konfigurasi pemetaan pola pengelolaan tenant ke data. Misalnya, saat Anda memindahkan tenant di antara pola pengelolaan data, Anda harus memperbarui pola pengelolaan data dan string koneksi database. Anda mungkin juga harus memperbarui awalan tabel.
Pembuatan dan atribusi kueri
Prinsip dasar dari aplikasi multi-tenant adalah beberapa tenant dapat berbagi satu resource cloud. Pola pengelolaan data sebelumnya termasuk dalam kategori ini, kecuali untuk kasus ketika satu tenant dialokasikan ke satu instance Spanner.
Berbagi sumber daya lebih dari sekadar berbagi data. Pemantauan dan logging juga dibagikan. Misalnya, dalam pola pengelolaan data tabel dan pola pengelolaan data skema, semua kueri untuk semua tenant dicatat dalam log audit yang sama.
Jika kueri dicatat ke dalam log, teks kueri harus diperiksa untuk menentukan tenant mana yang menjalankan kueri tersebut. Dalam pola manajemen data tabel, Anda harus mengurai predikatnya. Dalam pola pengelolaan data skema, Anda harus mengurai salah satu nama tabel.
Dalam pola pengelolaan data database atau pola pengelolaan data instance, teks kueri tidak memiliki informasi tenant. Guna mendapatkan informasi tenant untuk pola ini, Anda harus mengkueri tabel pemetaan pola pengelolaan tenant ke data.
Akan lebih mudah untuk menganalisis log dan kueri dengan menentukan tenant untuk
kueri tertentu tanpa mengurai teks kueri. Salah satu cara untuk mengidentifikasi
tenant secara seragam untuk kueri di semua pola pengelolaan data adalah dengan menambahkan
komentar ke teks kueri yang memiliki tenant ID, dan (opsional) label.
Kueri berikut memilih semua data karyawan untuk tenant yang diidentifikasi oleh
TENANT 356. Agar tidak mengurai sintaksis SQL dan mengekstrak ID tenant dari
predikat, ID tenant ditambahkan sebagai komentar. Komentar dapat diekstrak
tanpa harus mengurai sintaksis SQL.
select * from EMPLOYEE
-- TENANT 356
where TENANT = 'T356';
atau
select * from T356_EMPLOYEE;
-- TENANT 356
Dengan desain ini, setiap kueri yang dijalankan untuk tenant diatribusikan ke tenant tersebut, terlepas dari pola pengelolaan data. Jika tenant dipindahkan dari satu pola pengelolaan data ke pola pengelolaan data lainnya, teks kueri mungkin berubah, tetapi atribusinya tetap sama dalam teks kueri.
Contoh kode sebelumnya hanyalah satu metode. Metode lainnya adalah dengan menyisipkan objek JSON sebagai komentar, bukan label dan nilai:
select * from T356_EMPLOYEE;
-- {"TENANT": 356}
Operasi siklus proses akses tenant
Bergantung pada filosofi desain Anda, aplikasi multi-tenant dapat langsung mengimplementasikan operasi siklus proses data yang dijelaskan sebelumnya, atau dapat membuat alat administrasi tenant terpisah.
Terlepas dari strategi implementasi, operasi siklus proses mungkin harus dijalankan tanpa logika aplikasi yang berjalan secara bersamaan—misalnya, saat memindahkan tenant dari satu pola pengelolaan data ke pola pengelolaan data lainnya, logika aplikasi tidak dapat dijalankan karena data tidak berada di dalam satu database. Jika data tidak berada dalam satu database, diperlukan dua operasi tambahan dari perspektif aplikasi:
- Menghentikan tenant: Menonaktifkan semua akses logika aplikasi dengan tetap mengizinkan operasi siklus proses data.
- Memulai tenant: Logika aplikasi dapat mengakses data tenant, sementara operasi siklus proses yang akan mengganggu logika aplikasi dinonaktifkan.
Meskipun tidak sering digunakan, penonaktifan tenant darurat dapat menjadi operasi siklus proses penting lainnya. Gunakan penonaktifan ini saat Anda mencurigai adanya pembobolan, dan Anda harus melarang semua akses ke data tenant—tidak hanya logika aplikasi, tetapi juga operasi siklus proses. Pembobolan dapat berasal dari dalam atau luar database.
Operasi siklus proses yang cocok yang menghapus status darurat juga harus tersedia. Operasi tersebut dapat mengharuskan dua atau lebih administrator untuk login secara bersamaan untuk menerapkan kontrol bersama.
Isolasi aplikasi
Berbagai pola pengelolaan data mendukung berbagai tingkat isolasi tenant-data. Mulai dari tingkat yang paling terisolasi (instance) hingga tingkat yang paling tidak terisolasi (tabel), tingkat isolasi yang berbeda dapat terjadi.
Dalam konteks aplikasi multi-tenant, keputusan deployment yang serupa harus dibuat: apakah semua tenant mengakses data mereka (dalam pola pengelolaan data yang mungkin berbeda) menggunakan deployment aplikasi yang sama? Misalnya, satu cluster Kubernetes mungkin mendukung semua tenant, dan saat tenant mengakses datanya, cluster yang sama akan menjalankan logika bisnis.
Atau, seperti dalam kasus pola pengelolaan data, tenant yang berbeda mungkin diarahkan ke deployment aplikasi yang berbeda. Tenant besar mungkin memiliki akses ke deployment aplikasi yang eksklusif untuk mereka, sementara tenant yang lebih kecil atau tenant dalam paket gratis menggunakan deployment aplikasi yang sama.
Daripada langsung mencocokkan pola pengelolaan data yang dibahas dalam artikel ini dengan pola pengelolaan data aplikasi yang setara, Anda dapat menggunakan pola pengelolaan data database sehingga semua tenant menggunakan satu deployment aplikasi yang sama. Anda dapat memiliki pola pengelolaan data database dan semua tenant ini menggunakan satu deployment aplikasi yang sama.
Multi-tenancy adalah pola pengelolaan data desain aplikasi yang penting, terutama ketika efisiensi resource memainkan peran penting. Spanner mendukung beberapa pola pengelolaan data. Gunakan untuk menerapkan aplikasi multi-tenant. Dengan skalabilitas ekstrem dan SLA yang ketat, Spanner merupakan database yang ideal untuk deployment aplikasi multi-tenant yang besar.
Langkah selanjutnya
- Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.