Menerapkan multi-tenancy di Spanner

Halaman ini menjelaskan berbagai cara untuk menerapkan multi-tenancy di Spanner. Bagian ini juga membahas pola pengelolaan data dan pengelolaan siklus proses tenant. 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. Contoh yang diberikan di halaman ini didasarkan pada implementasi aplikasi multi-tenant penyedia SaaS sumber daya manusia (HR) di Google Cloud. Salah satu persyaratannya adalah beberapa pelanggan penyedia SaaS HR harus mengakses aplikasi multi-tenant. Pelanggan ini disebut tenant.

Multi-tenancy

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: tenant berbagi infrastruktur, seperti pipa air dan saluran listrik, tetapi setiap tenant memiliki ruang tenant khusus di apartemen. Multi-tenancy adalah bagian dari sebagian besar, atau mungkin semua, aplikasi software-as-a-service (SaaS).

Spanner adalah database terkelola sepenuhnya, berkelas perusahaan, terdistribusi, dan konsisten dari Google Cloudyang 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. Layanan ini memberikan periode nonaktif nol untuk pemeliharaan terencana atau kegagalan region, dengan SLA ketersediaan 99,999%. Spanner juga mendukung aplikasi multi-tenant modern dengan memberikan ketersediaan dan skalabilitas tinggi.

Kriteria untuk kriteria pemetaan data tenant

Catatan: Jika Anda telah membaca versi sebelumnya dari halaman ini, perhatikan bahwa kami telah melakukan beberapa perubahan terminologi. Pola pengelolaan data "skema" sebelumnya telah diganti namanya menjadi "tabel", dan pola pengelolaan data "tabel" sebelumnya telah diganti namanya menjadi "baris". Penamaan baru ini lebih akurat dan lebih konsisten dengan cara kami menggunakan pola pengelolaan data instance dan database di Spanner.

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.
• Tabel: Tenant berada di tabel eksklusif dalam database, dan beberapa tenant dapat ditempatkan di database yang sama.
• Baris: 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 data: Tingkat isolasi data di beberapa tenant adalah pertimbangan utama untuk multi-tenancy. Misalnya, apakah data perlu dipisahkan secara fisik atau logis, dan apakah ada ACL (Daftar Kontrol Akses) independen yang dapat ditetapkan untuk data setiap tenant. Isolasi didorong oleh pilihan yang dibuat untuk kriteria dalam kategori lainnya. Misalnya, persyaratan peraturan dan kepatuhan tertentu mungkin menentukan tingkat isolasi yang lebih tinggi.
• Ketangkasan: Kemudahan aktivitas onboarding dan offboarding untuk tenant sehubungan dengan pembuatan instance, database, tabel, atau baris.
• Operasi: Ketersediaan atau kompleksitas penerapan operasi database standar, khusus tenant, dan aktivitas administrasi. Misalnya, pemeliharaan rutin, logging, pencadangan, atau operasi pemulihan dari bencana.
• Penskalaan: Kemampuan untuk melakukan penskalaan dengan lancar guna mendukung pertumbuhan di masa mendatang. Deskripsi setiap pola berisi jumlah tenant yang dapat didukung pola.
• Performa:
  • Isolasi resource: Kemampuan untuk mengalokasikan resource eksklusif ke setiap tenant, mengatasi fenomena noisy neighbor, dan memungkinkan performa baca dan tulis yang dapat diprediksi untuk setiap tenant.
  • Sumber daya minimum per tenant: Jumlah minimum rata-rata sumber daya per tenant. Hal ini tidak berarti Anda harus membayar setidaknya jumlah ini untuk setiap penyewa, tetapi Anda harus membayar setidaknya N * jumlah ini untuk semua N penyewa secara bersamaan.
  • Efisiensi resource: Kemampuan untuk menggunakan resource idle milik tenant lain untuk menghemat biaya secara keseluruhan.
  • Pemilihan lokasi untuk pengoptimalan latensi: Kemampuan untuk memilih topologi replikasi tertentu untuk setiap tenant sehingga data untuk setiap tenant dapat ditempatkan di lokasi yang memberikan latensi terbaik untuk tenant tersebut.
• Peraturan dan kepatuhan: Kemampuan untuk memenuhi persyaratan industri dan negara yang sangat diatur yang memerlukan isolasi lengkap resource dan operasi pemeliharaan. Misalnya, persyaratan residensi data untuk Prancis mengharuskan informasi identitas pribadi disimpan secara fisik secara eksklusif di Prancis. Industri keuangan biasanya memerlukan kunci enkripsi yang dikelola pelanggan (CMEK), dan setiap tenant mungkin ingin menggunakan kunci enkripsinya sendiri.

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, tabel, dan baris.

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 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 projectGoogle 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 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 data	Tingkat isolasi data tertinggi Penyimpanan data dipisahkan secara fisik ACL diberikan secara terpisah untuk setiap instance
Ketangkasan	Onboarding dan offboarding memerlukan penyiapan atau penghapusan yang signifikan untuk: Instance Spanner Keamanan khusus instance Konektivitas khusus instance Onboarding dan offboarding dapat diotomatiskan melalui Infrastructure as Code (IaC)
Operations	Pencadangan independen untuk setiap tenant Jadwal pencadangan yang terpisah dan fleksibel Overhead operasional yang lebih tinggi Instance dalam jumlah besar untuk dikelola dan dipelihara (penskalaan, pemantauan, logging, dan penyesuaian performa)
Skala	Database yang sangat skalabel Pertumbuhan tanpa batas dengan menambahkan node Jumlah tenant tidak terbatas Instance Spanner tersedia untuk setiap tenant
Performa	Isolasi resource: Tidak ada pertentangan resource Resource minimum per tenant: Resource minimum per tenant adalah 1 node jika menggunakan instance yang lebih besar, dan 100 PU (1/10 node) jika menggunakan instance terperinci Efisiensi resource: Tidak dapat menggunakan resource tidak ada aktivitas milik tenant lain Pemilihan lokasi untuk pengoptimalan latensi: Tempatkan setiap tenant dalam instance terpisah dan sesuaikan topologi replikasi untuk setiap tenant
Persyaratan peraturan dan kepatuhan	Menyimpan data di region tertentu Menerapkan proses keamanan, pencadangan, atau audit tertentu yang diwajibkan oleh bisnis atau pemerintah

Singkatnya, poin-poin pentingnya adalah:

• Keuntungan: Tingkat isolasi tertinggi
• Kekurangan: Overhead operasional terbesar dan berpotensi lebih tinggi biayanya karena minimum 100 PU per tenant. Berbagi resource di seluruh tenant tidak didukung.

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 topologi replikasi yang sama serta penyiapan komputasi dan penyimpanan yang mendasarinya, kecuali jika fitur geo-partitioning digunakan. Anda dapat menggunakan fitur partisi geografis Spanner untuk membuat partisi instance di lokasi yang berbeda dan menggunakan partisi instance yang berbeda untuk database yang berbeda dalam instance yang sama.

Tabel berikut menguraikan bagaimana pola pengelolaan data database memengaruhi berbagai kriteria.

Kriteria	Database — pola pengelolaan data satu tenant per database
Isolasi data	Menyelesaikan isolasi logis pada level database Penyimpanan data dipisahkan secara fisik Anda dapat memberikan ACL ke semua database dalam instance, atau Anda dapat memberikannya secara terpisah ke setiap database
Ketangkasan	Memerlukan upaya untuk membuat atau menghapus database dan kontrol keamanan tertentu Otomatisasi untuk onboarding dan offboarding dilakukan melalui Infrastructure as Code (IaC)
Operasi	Pencadangan independen untuk setiap tenant Jadwal pencadangan yang terpisah dan fleksibel Overhead operasional yang lebih sedikit dibandingkan dengan pola instance Satu instance untuk dipantau hingga 100 database
Skala	Database yang sangat skalabel Batas 100 database per instance. Untuk setiap 100 tenant, buat instance Spanner baru. Instance tanpa batas Jumlah node per instance tidak terbatas
Performa	Isolasi resource: pertentangan di antara beberapa database Database yang tersebar di seluruh node instance Spanner Database saling berbagi infrastruktur Noisy neighbor memengaruhi performa Resource minimum per tenant: Karena ada batas 100 database per instance, kapasitas komputasi minimum untuk 100 database (atau 100 tenant) adalah 1 node. Bahkan untuk instance terperinci, kapasitas komputasi minimum per 100 tenant tetap 1 node. Meskipun setiap instance terperinci dapat menggunakan serendah 100 unit pemrosesan, Spanner hanya mengizinkan batas 10 database per 100 unit pemrosesan. Efisiensi resource: Tenant berbagi resource satu instance. Tenant dapat menggunakan resource tidak ada aktivitas milik tenant lain. Pemilihan lokasi untuk pengoptimalan latensi: Jika Anda tidak menggunakan fitur partisi geografis, lokasi database akan sama dengan konfigurasi instance. Anda tidak dapat menyesuaikan lokasi database untuk setiap tenant. Namun, jika menggunakan fitur partisi geografis, Anda dapat membuat partisi instance di lokasi yang berbeda, dan Anda dapat menempatkan data di lokasi yang berbeda menggunakan kunci penempatan baris. Penggunaan geo-partisi mengoptimalkan latensi untuk setiap tenant.
Persyaratan peraturan dan kepatuhan	Jika Anda tidak menggunakan fitur partisi geografis, lokasi database sama dengan konfigurasi instance untuk memenuhi persyaratan peraturan residensi data. Namun, jika menggunakan fitur partisi geografis, Anda dapat membuat partisi instance di lokasi yang berbeda, dan Anda dapat menempatkan data di lokasi yang berbeda menggunakan kunci penempatan per baris. Setiap database dapat menggunakan CMEK-nya sendiri untuk enkripsi data.

Singkatnya, poin-poin pentingnya adalah:

• Keuntungan: Tingkat isolasi data dan isolasi resource sedang; tingkat efisiensi resource sedang; setiap tenant dapat memiliki pencadangan dan CMEK sendiri.
• Kekurangan: Jumlah tenant yang terbatas per instance; infleksibilitas lokasi jika tidak menggunakan fitur partisi geografis.

Pola pengelolaan data database paling cocok untuk skenario berikut:

• Beberapa pelanggan berada di residensi data yang sama atau berada di bawah otoritas peraturan yang sama.
• Tenant memerlukan pemisahan data berbasis sistem dan kemampuan untuk mencadangkan dan memulihkan data mereka, tetapi memperbolehkan berbagi resource infrastruktur.
• Tenant memerlukan CMEK mereka sendiri.
• Biaya adalah pertimbangan penting. Sumber daya minimum yang diperlukan per tenant lebih rendah daripada biaya instance. Tenant sebaiknya menggunakan resource tidak ada aktivitas tenant lain.

Tabel

Dalam pola pengelolaan data tabel, 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, akhiran, atau sebagai skema bernama.

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). Proses orientasi melibatkan pembuatan tabel baru serta integritas dan indeks referensial yang terkait.

Ada batas 5.000 tabel per database. Untuk sebagian pelanggan, batas tersebut dapat 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, dan customer1_department. Atau, mereka dapat menggunakan ID tenant sebagai skema bernama dan memberi nama tabel mereka sebagai customer1.employee, customer1.payroll, dan customer1.department.

Seperti yang terlihat pada diagram berikut, pola pengelolaan data tabel memiliki satu set tabel untuk setiap tenant.

Tabel berikut menguraikan bagaimana pola pengelolaan data tabel memengaruhi berbagai kriteria.

Kriteria	Tabel — satu kumpulan tabel untuk setiap pola pengelolaan data tenant
Isolasi data	Tingkat isolasi data sedang. Data dipisahkan secara logis, tetapi dapat disimpan secara fisik dalam file yang sama di penyimpanan persisten. ACL dibagikan secara default, tetapi dapat diberikan secara terpisah menggunakan kontrol akses terperinci (FGAC).
Ketangkasan	Memerlukan upaya untuk membuat atau menghapus tabel baru, indeks terkait, dan kontrol keamanan yang dibuat melalui FGAC Offboarding pelanggan berarti menghapus tabel Dapat berdampak negatif sementara pada tenant lain dalam database
Operations	Tidak ada operasi terpisah untuk tenant Pencadangan, pemantauan, dan logging harus diterapkan sebagai fungsi aplikasi terpisah atau sebagai skrip utilitas
Skala	Satu database hanya dapat memiliki 5.000 tabel Hanya jumlah 5.000/<jumlah tabel untuk tenant> tenant di setiap database Jika database melebihi 5.000 tabel, menambahkan database baru untuk tenant tambahan
Performa	Penyekatan resource: Resource infrastruktur dasar bersama. Pertentangan resource tingkat tinggi mungkin terjadi. Noisy neighbor memengaruhi performa. Resource minimum per tenant: Karena ada batas 100 database per instance, dan 5.000 tabel per database, kapasitas komputasi minimum yang diperlukan per 500.000 tenant adalah satu node. Efisiensi resource: Tenant berbagi resource satu instance. Setiap tenant dapat menggunakan resource tidak ada aktivitas dari tenant lain. Pemilihan lokasi untuk pengoptimalan latensi: Jika Anda tidak menggunakan fitur partisi geografis, lokasi database akan sama dengan konfigurasi instance. Anda tidak dapat menyesuaikan lokasi database untuk setiap tenant. Namun, jika menggunakan fitur partisi geografis, Anda dapat membuat partisi instance di lokasi yang berbeda, dan Anda dapat menempatkan data di lokasi yang berbeda menggunakan kunci penempatan baris. Penggunaan geo-partisi mengoptimalkan latensi untuk setiap tenant.
Persyaratan peraturan dan kepatuhan	Jika Anda tidak menggunakan fitur partisi geografis, lokasi database sama dengan konfigurasi instance untuk memenuhi persyaratan peraturan residensi data. Namun, jika menggunakan fitur partisi geografis, Anda dapat membuat partisi instance di lokasi yang berbeda, dan Anda dapat menempatkan data di lokasi yang berbeda menggunakan kunci penempatan per baris. Tabel yang berbeda dalam database yang sama harus menggunakan CMEK yang sama untuk enkripsi data di setiap region.

Singkatnya, poin-poin pentingnya adalah:

• Keuntungan: Tingkat skalabilitas dan efisiensi resource sedang.
• Kekurangan:
  • Tingkat isolasi data dan isolasi resource sedang.
  • Lokasi tidak fleksibel jika tidak menggunakan fitur partisi geografis baru.
  • Tidak dapat memantau tenant secara terpisah. Satu-satunya info penggunaan resource tingkat tabel yang tersedia adalah statistik ukuran tabel.
  • Tenant tidak dapat memiliki CMEK dan cadangan sendiri.

Pola pengelolaan data tabel paling cocok untuk skenario berikut:

• Aplikasi multi-tenant yang secara hukum tidak memerlukan pemisahan data, tetapi Anda menginginkan pemisahan logis dan kontrol keamanan.
• Biaya adalah pertimbangan penting. Biaya minimum per tenant lebih murah daripada biaya per database.

Baris

Pola pengelolaan data akhir melayani beberapa tenant dengan kumpulan tabel umum, dengan setiap baris dimiliki oleh tenant tertentu. 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 baris memiliki satu tabel untuk beberapa tenant.

Tidak seperti semua pola lainnya, akses data dalam pola baris 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 baris memengaruhi berbagai kriteria.

Kriteria	Baris — pola pengelolaan data satu set baris untuk setiap tenant
Isolasi data	Tingkat isolasi data terendah Tidak ada keamanan tingkat tenant
Ketangkasan	Tidak perlu penyiapan di sisi database saat onboarding Aplikasi dapat langsung menulis data ke dalam tabel yang ada Offboarding berarti menghapus baris pelanggan dalam tabel
Operations	Tidak ada operasi terpisah untuk tenant, termasuk pencadangan, pemantauan, dan logging Sedikit atau tidak ada overhead seiring dengan peningkatan jumlah tenant
Skala	Dapat mengakomodasi semua tingkat pertumbuhan tenant Mendukung tenant dalam jumlah yang tidak terbatas
Performa	Isolasi resource: Semua masalah isolasi resource yang terjadi dalam pola database juga berlaku untuk pola ini. Jika ruang kunci utama tidak didesain dengan hati-hati, pertentangan resource tingkat tinggi dapat terjadi (noisy neighbor). Dapat mencegah konkurensi dan distribusi Mengikuti praktik terbaik itu penting Menghapus data tenant mungkin akan berdampak sementara pada beban Sumber daya minimum per tenant: Tidak ada sumber daya minimum per tenant Efisiensi resource: Tenant berbagi resource satu instance. Setiap tenant dapat menggunakan resource tidak ada aktivitas tenant lain. Pemilihan lokasi untuk pengoptimalan latensi: Jika Anda tidak menggunakan fitur partisi geografis, lokasi database akan sama dengan konfigurasi instance. Anda tidak dapat menyesuaikan lokasi database untuk setiap tenant. Namun, jika menggunakan fitur partisi geografis, Anda dapat membuat partisi instance di lokasi yang berbeda, dan Anda dapat menempatkan data di lokasi yang berbeda menggunakan kunci penempatan baris. Penggunaan geo-partisi mengoptimalkan latensi untuk setiap tenant.
Persyaratan peraturan dan kepatuhan	Jika Anda tidak menggunakan fitur partisi geografis, lokasi database sama dengan konfigurasi instance untuk memenuhi persyaratan peraturan residensi data. Namun, jika menggunakan fitur partisi geografis, Anda dapat membuat partisi instance di lokasi yang berbeda, dan Anda dapat menempatkan data di lokasi yang berbeda menggunakan kunci penempatan per baris. Pola tidak dapat menyediakan partisi tingkat sistem (dibandingkan dengan pola instance atau database). Menerapkan kontrol keamanan dan audit tertentu akan memengaruhi semua tenant.

Singkatnya, poin-poin pentingnya adalah:

• Keuntungan: Sangat skalabel; memiliki overhead operasional yang rendah; pengelolaan skema yang disederhanakan.
• Kekurangan: Pertentangan resource yang tinggi; tidak ada kontrol keamanan dan pemantauan 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 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	Tabel	Baris
Isolasi data	Selesai	Tinggi	Sedang	Rendah
Ketangkasan	Rendah	Sedang	Sedang	Tertinggi
Kemudahan pengoperasian	Tinggi	Tinggi	Rendah	Rendah
Menskalakan	Tinggi	Terbatas (kecuali menggunakan instance tambahan saat mencapai batas)	Terbatas (kecuali menggunakan database tambahan saat mencapai batas)	Tertinggi
Performa^1 - Isolasi resource	Tinggi	Rendah	Rendah	Rendah
Performa^1 - Sumber daya minimum per tenant	Tinggi	Sedang Tinggi	Sedang	Tidak ada minimum per tenant
Performa^1 - Efisiensi resource	Rendah	Tinggi	Tinggi	Tinggi
Performa^1 - Pemilihan lokasi untuk pengoptimalan latensi	Tinggi	Sedang	Sedang	Sedang
Peraturan dan kepatuhan	Tertinggi	Tinggi	Sedang	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.

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 fitur terbatas
  • Pola pengelolaan data baris adalah kandidat paket gratis yang baik
    • Pengelolaan tenant sangat mudah
    • 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 tabel 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 tabel.
      • 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 baris atau tabel, sistem aplikasi multi-tenant harus menerapkan ekspor atau memetakannya ke fitur database (ekspor database), dan menerapkan logika kustom untuk mengambil bagian data yang sesuai dengan tenant.

• 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 tabel atau baris 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 satu pola pengelolaan data dan penyisipan data tersebut ke dalam pola pengelolaan data baru.

    • 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 tabel, nama tabel yang benar harus ditentukan.
• Untuk pola pengelolaan data baris, 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 tabel).

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)

Desain tambahan diperlukan untuk pola pengelolaan data tabel dan baris.

Pola pengelolaan data tabel

Untuk pola pengelolaan data tabel, 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 menempatkan tabel setiap tenant dalam namespace yang dinamai sesuai dengan tenant, dan sepenuhnya memenuhi syarat nama tabel Anda dengan namespace.name. Misalnya, Anda menempatkan tabel EMPLOYEE di dalam namespace T356 untuk tenant dengan ID 356, dan aplikasi Anda dapat menggunakan T356.EMPLOYEE untuk menangani permintaan ke tabel.

Pendekatan lainnya adalah dengan menambahkan ID tenant pada nama tabel. Misalnya, tabel EMPLOYEE disebut T356_EMPLOYEE untuk tenant dengan ID 356. Aplikasi harus menambahkan awalan tenant ID pada setiap tabel sebelum mengirim kueri ke database yang ditampilkan pemetaan.

Jika ingin menggunakan teks lain, bukan ID tenant, Anda dapat mempertahankan pemetaan dari ID tenant ke namespace skema bernama atau ke awalan tabel.

Untuk menyederhanakan logika aplikasi, Anda dapat memperkenalkan satu tingkat pengalihan. Misalnya, Anda dapat menggunakan library umum dengan aplikasi untuk secara otomatis melampirkan awalan namespace atau tabel untuk panggilan dari tenant.

Pola pengelolaan data baris

Desain yang serupa diperlukan untuk pola pengelolaan data baris. 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. Untuk isolasi data yang lebih baik, nilai kolom ini harus menjadi bagian dari kunci utama. 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 baris, 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 pengelolaan data baris, Anda harus mengurai predikat. Dalam pola pengelolaan data tabel, Anda harus mengurai salah satu nama tabel.

Dalam pola pengelolaan data database atau pola pengelolaan data instance, teks kueri tidak memiliki informasi tenant. Untuk 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}

Anda juga dapat menggunakan tag untuk mengatribusikan kueri ke tenant, dan melihat statistik di tabel spanner_sys bawaan.

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 (baris), 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 dokumen 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. Layanan ini memberikan periode nonaktif nol untuk pemeliharaan terencana atau kegagalan region, dengan SLA ketersediaan 99,999%. Solusi ini juga mendukung aplikasi multi-tenant modern dengan memberikan ketersediaan dan skalabilitas tinggi.