Menerapkan multi-tenansi di Cloud Spanner

Dokumen ini menjelaskan berbagai cara untuk menerapkan multi-tenant di Cloud Spanner. Bagian ini juga membahas pola pengelolaan data dan pengelolaan siklus penggunaan tenant.

Multi-sewa adalah ketika satu atau beberapa instance aplikasi perangkat lunak melayani beberapa penyewa atau pelanggan. Pola software ini dapat diskalakan dari satu penyewa atau pelanggan hingga ratusan atau ribuan. Pendekatan ini sangat penting untuk platform komputasi awan yang infrastruktur dasarnya digunakan bersama oleh beberapa organisasi.

Anggaplah multi-sewa sebagai bentuk partisi berdasarkan resource komputasi bersama, seperti database. Analoginya adalah penyewa di gedung apartemen: infrastruktur bersama, tetapi ruang penyewa khusus. Multi-tenansi adalah bagian dari sebagian besar, jika tidak semua, aplikasi software-as-a-service (SaaS).

Dokumen ini ditujukan untuk arsitektur database, arsitektur data, dan engineer yang menerapkan aplikasi multi-tenant di Spanner sebagai database relasional mereka. Dengan menggunakan konteks tersebut, laporan ini menguraikan berbagai pendekatan untuk menyimpan data multi-tenant. Istilah "tenant", "pelanggan", dan "organisasi" digunakan secara bergantian di seluruh artikel untuk menunjukkan entitas yang mengakses aplikasi multi-tenant.

Artikel ini menggunakan penyedia SaaS sumber daya manusia (Sumber Daya Manusia) yang menerapkan aplikasi multi-tenant di Google Cloud sebagai contoh. Dalam contoh tersebut, beberapa pelanggan penyedia SaaS Sumber Daya harus mengakses aplikasi multi-tenant. Pelanggan ini disebut penyewa.

Spanner adalah database Google Cloud yang sepenuhnya terkelola, tingkat 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 menyediakan periode non-operasional untuk pemeliharaan terencana atau kegagalan region, dengan SLA ketersediaan sebesar 99,999%. Fitur ini mendukung aplikasi multi-tenant modern dengan menyediakan ketersediaan dan skalabilitas yang tinggi. Artikel ini membahas pendekatan arsitektur yang berbeda untuk menerapkan multi-sewa dengan Spanner.

Kriteria untuk kriteria pemetaan data penyewa

Dalam aplikasi multi-tenant, data masing-masing tenant dipisahkan dalam salah satu dari beberapa pendekatan arsitektur dalam database Spanner yang mendasarinya. Daftar berikut menguraikan berbagai pendekatan arsitektur yang digunakan untuk memetakan data tenant ke Spanner:

  • Instance: Penyewa berada secara eksklusif dalam satu instance Spanner, dengan tepat satu database untuk tenant tersebut.
  • Database: Penyewa berada di database dalam instance Spanner tunggal yang berisi beberapa database.
  • Skema: Penyewa berada di tabel eksklusif dalam database, dan beberapa tenant dapat berada di database yang sama.
  • Tabel: Data tenant adalah baris dalam tabel database. Tabel tersebut dibagikan dengan tenant lain.

Kriteria sebelumnya disebut pola pengelolaan data dan dibahas secara detail di bagian Pola pengelolaan data multi-sewa. Diskusi tersebut didasarkan pada kriteria berikut:

  • Isolasi: Tingkat isolasi data di beberapa tenant adalah pertimbangan utama untuk multi-tenant. Isolasi didorong oleh pilihan yang dibuat untuk kriteria dalam kategori lain — misalnya, persyaratan peraturan dan kepatuhan tertentu dapat menentukan tingkat isolasi yang lebih besar.
  • Ketangkasan: Kemudahan aktivitas orientasi dan orientasi untuk tenant terkait pembuatan instance, database, atau tabel.
  • Operasi: Ketersediaan atau kerumitan penerapan operasi database dan aktivitas administrasi yang khas dan khusus penyewa — misalnya, operasi pemeliharaan rutin, pencatatan, pencadangan, atau pemulihan bencana.
  • Skala: Kemampuan untuk diskalakan dengan lancar untuk memungkinkan pertumbuhan di masa mendatang. Deskripsi setiap pola berisi jumlah tenant yang dapat didukung oleh pola.
  • Kinerja: Kemampuan untuk mengalokasikan sumber daya eksklusif kepada setiap penyewa, mengatasi gejala tetangga yang berisik, dan memungkinkan kinerja baca dan tulis yang dapat diprediksi untuk setiap penyewa.
  • Peraturan dan kepatuhan: Kemampuan untuk memenuhi persyaratan industri dan negara dengan peraturan yang sangat ketat yang memerlukan isolasi lengkap terhadap sumber daya dan operasi pemeliharaan — misalnya, persyaratan izin tinggal di Prancis mewajibkan informasi yang dapat diidentifikasi secara pribadi disimpan secara fisik secara eksklusif di Prancis.

Setiap pola pengelolaan data yang terkait dengan kriteria ini diuraikan di bagian berikutnya. Gunakan kriteria yang sama saat memilih pola pengelolaan data untuk kumpulan tenant tertentu.

Pola pengelolaan data multi-tenansi

Bagian berikut menjelaskan empat pola pengelolaan data utama: instance, database, skema, dan tabel.

Instance

Untuk memberikan isolasi lengkap, pola pengelolaan data instance menyimpan data setiap tenant dalam instance Spanner dan database-nya sendiri. Instance Spanner dapat memiliki satu atau beberapa database. Dalam pola ini, hanya satu database yang dibuat. Untuk aplikasi Sumber Daya Manusia yang 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.

Pola pengelolaan data instance menyimpan rumah dengan satu tenant per instance.

Memiliki instance terpisah untuk setiap tenant memungkinkan penggunaan project Google Cloud terpisah untuk mencapai batas kepercayaan terpisah bagi tenant yang berbeda. Manfaat tambahan adalah bahwa setiap konfigurasi instance dapat dipilih berdasarkan lokasi setiap tenant (baik secara regional atau multi-regional), sehingga mengoptimalkan fleksibilitas dan performa lokasi.

Arsitektur dapat dengan mudah diskalakan ke sejumlah penyewa. Penyedia SaaS dapat membuat sejumlah instance di region yang diinginkan, tanpa batas.

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

Kriteria Instance - satu tenant per pola pengelolaan data instance
Isolasi
  • Tingkat isolasi terbesar
  • Tidak ada resource database yang dibagikan
Ketangkasan
  • Onboarding dan offboarding memerlukan penyiapan atau penghentian yang cukup untuk:
    • Instance Spanner
    • Keamanan khusus instance
    • Konektivitas khusus instance
  • Onboarding dan offboarding dapat diotomatiskan melalui Infrastruktur sebagai Kode (IaC)
Operasi
  • Backup independen untuk setiap tenant
  • Jadwal cadangan terpisah dan terpisah
  • Biaya operasional yang lebih tinggi
    • Sejumlah besar instance untuk dikelola dan dikelola (penskalaan, pemantauan, logging, dan penyesuaian performa)
Skalakan
  • Database yang sangat skalabel
  • Pertumbuhan tak terbatas dengan menambahkan node
  • Jumlah penyewa tidak terbatas
  • Instance Spanner tersedia untuk setiap tenant
Performa
  • Setiap penyewa dalam instance terpisah
  • Tidak ada pertentangan sumber daya
  • Penyesuaian dan pemecahan masalah performa yang disesuaikan untuk setiap tenant
Persyaratan peraturan dan kepatuhan
  • Simpan data di wilayah tertentu
  • Menerapkan proses keamanan, pencadangan, atau pengauditan tertentu seperti yang diwajibkan oleh bisnis atau pemerintah

Singkatnya, hal utama yang perlu diperhatikan adalah:

  • Keuntungan: Tingkat isolasi tertinggi
  • Kekurangan: Biaya operasional terbesar

Pola pengelolaan data instance paling cocok untuk skenario berikut:

  • Penyewa yang berbeda tersebar di berbagai wilayah dan memerlukan solusi yang dilokalkan.
  • Persyaratan peraturan dan kepatuhan untuk beberapa tenant memerlukan tingkat keamanan dan protokol audit yang lebih tinggi.
  • Ukuran tenant bervariasi secara signifikan, sehingga berbagi resource di antara tenant dengan volume tinggi dan traffic tinggi dapat menyebabkan pertengkaran dan saling merusak.

Database

Dalam pola pengelolaan data database, setiap tenant berada dalam database dalam instance Spanner tunggal. Beberapa database dapat berada dalam satu instance. Jika satu instance tidak cukup untuk jumlah tenant, buat beberapa instance. Pola ini menyiratkan bahwa instance Spanner tunggal dibagikan di antara beberapa tenant.

Spanner memiliki batas maksimum sebanyak 100 database per instance. Batas ini berarti bahwa jika penyedia SaaS perlu menskalakan lebih dari 100 pelanggan, mereka harus membuat dan menggunakan beberapa instance Spanner.

Untuk aplikasi Sumber Daya Manusia, 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 memiliki 1 tenant per database.

Pola pengelolaan data database mencapai isolasi logis pada tingkat database untuk data tenant yang berbeda. Namun, karena ini adalah 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 - satu tenant per pola pengelolaan data database
Isolasi
  • Selesaikan isolasi logis pada tingkat database
  • Berbagi resource infrastruktur dasar
Ketangkasan
  • Memerlukan upaya untuk membuat atau menghapus database dan kontrol keamanan tertentu
  • Otomatisasi untuk orientasi dan offboarding berasal dari IaC
Operasi
  • Backup independen untuk setiap tenant
  • Penjadwalan fleksibel
  • Biaya operasional yang lebih sedikit dibandingkan dengan pola instance
    • Satu instance untuk dipantau hingga 100 database
Skalakan
  • Database yang sangat skalabel
  • Instance tak terbatas
  • Mengizinkan ribuan node
  • Batas Batas 100 database per instance
    • Untuk setiap 100 tenant, buat instance Spanner baru
Performa
  • Pertentangan sumber daya di antara beberapa database
    • Database yang tersebar di seluruh node instance Spanner
    • Database berbagi infrastruktur
  • Tetangga yang berisik memengaruhi performa
Persyaratan peraturan dan kepatuhan
  • Region lokasi harus cocok dengan region instance untuk memenuhi persyaratan peraturan residen data tertentu

Singkatnya, hal utama yang perlu diperhatikan adalah:

  • Keuntungan: Tingkat isolasi yang lebih tinggi
  • Kekurangan: Jumlah penyewa terbatas per instance; lokasi yang tidak fleksibel

Pola pengelolaan data database paling cocok untuk skenario berikut:

  • Beberapa pelanggan berada di tempat tinggal data yang sama — misalnya, Prancis, atau Inggris Raya — dan/atau berada di bawah otoritas peraturan yang sama.
  • Penyewa memerlukan pemisahan data berbasis sistem dan pencadangan/pemulihan, namun tidak ada masalah dengan pembagian sumber daya infrastruktur.

Skema

Dalam pola pengelolaan data skema, satu database — yang menerapkan skema tunggal — digunakan untuk beberapa tenant dan sekumpulan tabel terpisah digunakan untuk data masing-masing tenant. Tabel ini dapat dibedakan dengan menyertakan tenant ID dalam nama tabel sebagai awalan atau akhiran.

Pola pengelolaan data ini menggunakan kumpulan tabel terpisah untuk setiap tenant memberikan tingkat isolasi yang jauh lebih rendah dibandingkan dengan opsi sebelumnya (pola pengelolaan database dan instance). Pola ini juga membuat orientasi menjadi sederhana — melibatkan pembuatan tabel baru serta integritas dan indeks referensial terkait.

Satu peringatan yang signifikan adalah bahwa izin akses untuk Spanner melalui Identity and Access Management (IAM) hanya diberikan pada tingkat instance atau database. Izin akses tidak dapat diberikan di tingkat tabel. Ada juga batas 5.000 tabel per database. Bagi banyak pelanggan, batas tersebut membatasi penggunaan aplikasi.

Selain itu, menggunakan tabel terpisah untuk setiap pelanggan dapat menghasilkan backlog operasi pembaruan skema yang besar. Backlog semacam ini membutuhkan waktu penyelesaian yang lama.

Untuk aplikasi Sumber Daya Manusia, 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.

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 penyewa
Isolasi
  • Tingkat isolasi yang rendah
  • Tidak ada keamanan tingkat tabel
Ketangkasan
  • Orientasi pelanggan sepele
    • Membuat tabel baru
    • Buat kunci dan indeks terkait
  • Mengesampingkan pelanggan berarti menghapus tabel
    • Mungkin berdampak negatif terhadap performa sementara pada tenant lain dalam database
Operasi
  • Tidak ada operasi terpisah untuk tenant
  • Pencadangan, pemantauan, dan pencatatan harus diterapkan sebagai fungsi aplikasi terpisah atau sebagai skrip utilitas
Skalakan
  • Ribuan node
  • Pertumbuhan penyewa tak terbatas
  • Satu database hanya dapat memiliki 5.000 tabel
    • Hanya jumlah lantai (5.000 / {tabel angka untuk penyewa) saja dari jumlah penyewa di setiap database
    • Jika database melebihi 5.000 tabel, tambahkan database baru untuk tenant tambahan
Performa
  • Tingkat konflik konten yang tinggi adalah hal yang mungkin
  • Pastikan performa yang baik dengan merancang indeks secara terpisah untuk setiap kumpulan tabel
Persyaratan peraturan dan kepatuhan
  • Wilayah lokasi harus cocok untuk memenuhi persyaratan peraturan tempat tinggal data tertentu
  • Menerapkan kontrol keamanan dan pengauditan tertentu memengaruhi semua tenant yang berada di database yang sama

Singkatnya, hal utama yang perlu diperhatikan adalah:

  • Keuntungan: Orientasi itu mudah
  • Kekurangan: Biaya operasional yang lebih tinggi; tidak ada kontrol keamanan di tingkat tabel

Pola pengelolaan data skema paling cocok untuk skenario berikut:

  • Aplikasi internal yang melayani berbagai departemen di mana isolasi keamanan data yang ketat tidak menjadi perhatian utama jika dibandingkan dengan kemudahan pemeliharaan.
  • Aplikasi multi-tenant yang datanya tidak memerlukan pemisahan ketat berdasarkan persyaratan hukum atau peraturan.

Meskipun memungkinkan untuk membuat beberapa kumpulan tabel (setiap kumpulan yang mewakili penyewa) dalam database, ini adalah pola yang paling tidak ideal dari perspektif database. Alasan utamanya adalah tabel harus mengikuti konvensi penamaan. Aplikasi, dan perkakas basis data apa pun (misalnya, IDE, dan alat migrasi skema), harus memahami konvensi penamaan. Selain itu, jika jumlah tabel cukup besar per penyewa, pola pengelolaan data skema tidak memberikan penskalaan yang signifikan.

Pendekatan yang lebih baik adalah berpindah ke satu database per tenant dan meningkatkan jumlah instance, atau memindahkan ke pola pengelolaan data tabel.

Tabel

Pola pengelolaan data akhir menyajikan beberapa tenant dengan kumpulan tabel umum. Setiap tabel berisi data untuk beberapa tenant. Pola pengelolaan data ini mewakili tingkat multi-tenansi yang ekstrem di mana semuanya — mulai dari infrastruktur, skema, hingga model data — dibagi di antara beberapa tenant. Dalam tabel, baris dipartisi berdasarkan kunci utama, dengan tenant ID sebagai elemen pertama kunci. Dari perspektif penskalaan, Spanner paling mendukung pola ini karena dapat menskalakan tabel tanpa batasan.

Untuk aplikasi Sumber Daya Manusia, 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.

Pola pengelolaan data tabel menggunakan 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 dapat diselesaikan lebih cepat jika setiap penyewa memiliki tabel database sendiri. Untuk sebagian besar, pendekatan ini menyederhanakan orientasi, orientasi, dan operasi.

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

Kriteria Tabel - satu tabel untuk beberapa pola pengelolaan data penyewa
Isolasi
  • Tingkat isolasi terendah
  • Tidak ada keamanan tingkat tenant
Ketangkasan
  • Tidak diperlukan penyiapan di sisi database saat orientasi
    • Aplikasi dapat langsung menulis data ke dalam tabel yang ada
  • Melakukan offboarding berarti menghapus baris pelanggan di tabel
Operasi
  • Tidak ada operasi terpisah untuk tenant, termasuk backup, pemantauan, dan logging
  • Sedikit atau tidak ada biaya tambahan seiring bertambahnya jumlah penyewa
Skalakan
  • Skala untuk ribuan node
  • Dapat mengakomodasi semua tingkat pertumbuhan penyewa
  • Mendukung jumlah penyewa yang tidak terbatas
Performa
  • Pola berfungsi dengan baik dalam konteks Spanner
  • Penyimpanan terdistribusi internal, pemrosesan, dan load balancing dapat dengan mudah bekerja dengan pola ini
  • Jika ruang kunci utama tidak dirancang dengan hati-hati, kemungkinan terjadi konflik sumber daya tingkat tinggi (tetangga yang berisik)
    • Dapat mencegah konkurensi dan distribusi
  • Mengikuti praktik terbaik sangatlah penting
  • Menghapus data tenant dapat berdampak sementara pada pemuatan
Persyaratan peraturan dan kepatuhan
  • Lokasi harus cocok untuk memenuhi persyaratan peraturan tempat tinggal data tertentu
  • Pola tidak dapat menyediakan partisi tingkat sistem (dibandingkan dengan pola instance atau database)
  • Menerapkan kontrol keamanan dan pengauditan tertentu akan memengaruhi semua tenant

Singkatnya, hal utama yang perlu diperhatikan adalah:

  • Keuntungan: Sangat skalabel; memiliki biaya operasional yang rendah
  • Kekurangan: Pertentangan sumber daya yang tinggi; kurangnya kontrol keamanan untuk setiap penyewa

Pola ini paling cocok untuk skenario berikut:

  • Aplikasi internal yang melayani berbagai departemen di mana isolasi keamanan data yang ketat tidak menjadi perhatian utama jika dibandingkan dengan kemudahan pemeliharaan.
  • Pembagian resource maksimum untuk tenant yang menggunakan fungsi aplikasi tingkat bebas saat meminimalkan provisioning resource secara bersamaan.

Pola pengelolaan data dan pengelolaan siklus penyewa

Tabel berikut membandingkan berbagai pola pengelolaan data di seluruh kriteria pada tingkat tinggi.

Instance Database Skema Tabel
Isolasi Selesai Selesai Rendah Terendah
Ketangkasan Rendah Sedang Sedang Tertinggi
Kemudahan operasi Tinggi Tinggi Rendah Rendah
Skala Tinggi Terbatas Mungkin sangat terbatas Tinggi
Kinerja* Tinggi Sedang Sedang Berpeluang tinggi
Peraturan dan kepatuhan Tertinggi Tinggi Rendah Rendah

* Performa sangat bergantung pada desain skema dan praktik terbaik kueri. Nilai di sini hanya merupakan ekspektasi rata-rata.

Pola pengelolaan data terbaik untuk aplikasi multi-tenant tertentu adalah yang memenuhi sebagian besar persyaratannya berdasarkan kriteria. Jika kriteria tertentu tidak diperlukan, Anda dapat mengabaikan barisnya.

Menggabungkan pola pengelolaan data

Sering kali, pola pengelolaan data tunggal cukup untuk memenuhi persyaratan aplikasi multi-tenant. Jika demikian, desain dapat mengasumsikan pola pengelolaan data tunggal.

Beberapa aplikasi multi-tenant memerlukan beberapa pola pengelolaan data secara bersamaan, namun — misalnya, aplikasi multi-tenant yang mendukung tingkat gratis, tingkat reguler, dan tingkat perusahaan.

  • Paket gratis:

    • Harus hemat biaya
    • Harus memiliki batas volume data atas
    • Biasanya mendukung fungsi terbatas
    • Pola pengelolaan data tabel adalah kandidat tingkat bebas yang baik
      • Pengelolaan tenant sangat sederhana
      • Tidak perlu membuat resource penyewa khusus atau eksklusif
  • Tingkat reguler:

    • Cocok untuk klien yang membayar yang tidak memiliki persyaratan penskalaan atau isolasi khusus yang kuat
    • Pola pengelolaan data skema atau pola pengelolaan data database adalah kandidat tingkat reguler yang baik
      • Tabel dan indeks bersifat eksklusif untuk tenant
      • Backup dalam pola pengelolaan data database mudah dilakukan
      • Cadangan tidak didukung untuk pola pengelolaan data skema
        • Cadangan tenant harus diterapkan sebagai utilitas di luar Spanner
  • Tingkat perusahaan:

    • Biasanya tingkat 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 tingkat perusahaan

Praktik terbaiknya adalah mempertahankan pola pengelolaan data yang berbeda di database yang berbeda. Meskipun memungkinkan untuk menggabungkan berbagai pola pengelolaan data dalam database Spanner, hal tersebut akan mempersulit penerapan logika akses aplikasi dan operasi siklus proses.

Bagian Desain aplikasi menguraikan beberapa pertimbangan desain aplikasi multi-tenant yang berlaku saat menggunakan pola pengelolaan data tunggal atau beberapa pola pengelolaan data.

Kelola siklus hidup penyewa

Penyewa memiliki siklus hidup. Oleh karena itu, Anda harus menerapkan operasi pengelolaan yang sesuai dalam aplikasi multi-tenant. Selain operasi dasar dalam membuat, memperbarui, dan menghapus tenant, pertimbangkan operasi tambahan terkait data berikut:

  • Mengekspor data penyewa:

    • Saat menghapus tenant, praktik terbaiknya adalah mengekspor data mereka terlebih dahulu dan mungkin membuat set data yang tersedia bagi mereka.
    • Saat menggunakan pola pengelolaan data tabel atau skema, 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 melakukan backup data untuk setiap tenant, gunakan fungsi ekspor atau backup database.
    • Saat menggunakan pola pengelolaan data skema atau tabel dan mencadangkan data untuk setiap tenant, aplikasi multi-tenant harus menerapkan operasi ini. Database Spanner tidak dapat menentukan data milik penyewa mana.
  • Memindahkan data tenant:

    • Memindahkan tenant dari satu pola pengelolaan data ke yang lain (atau memindahkan tenant dalam pola pengelolaan data yang sama antara instance atau database) memerlukan ekstraksi data dari pola pengelolaan data tabel dan memasukkan data tersebut ke dalam pola pengelolaan data database.

    • Mengurangi situasi tetangga yang berisik adalah alasan lain untuk memindahkan penyewa.

Desain aplikasi

Saat mendesain aplikasi multi-tenant, terapkan logika bisnis yang sadar penyewa. Itu berarti setiap kali aplikasi menjalankan logika bisnis, aplikasi harus selalu dalam konteks penyewa yang dikenal.

Dari perspektif database, desain aplikasi berarti bahwa setiap kueri harus dijalankan terhadap pola pengelolaan data tempat penyewa berada. Bagian berikut menyoroti beberapa konsep utama dari desain aplikasi multi-tenant.

Sambungan penyewa dinamis dan konfigurasi kueri

Memetakan data tenant secara dinamis ke permintaan aplikasi tenant menggunakan konfigurasi pemetaan:

  • Untuk pola pengelolaan data database atau pola pengelolaan data instance, string koneksi 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 membahas konfigurasi koneksi untuk kasus umum aplikasi multi-tenant yang menggunakan semua pola pengelolaan data secara bersamaan. Jika tenant tertentu berada dalam satu pola, beberapa aplikasi multi-tenant menggunakan satu pola pengelolaan data untuk semua tenant. Kasus ini dicakup secara implisit oleh pemetaan berikut.

Jika tenant mengeksekusi logika bisnis (misalnya, karyawan yang login dengan ID tenant mereka), maka logika aplikasi harus menentukan pola pengelolaan data tenant, lokasi data untuk ID tenant tertentu, dan, secara opsional, penamaan tabel konvensi (untuk pola skema).

Logika aplikasi ini memerlukan pemetaan pola tenant-to-data-management. Dalam contoh kode berikut, connection string merujuk ke database tempat data tenant berada. Sampel mengidentifikasi instance Spanner dan database. Untuk instance dan database pola pengelolaan data, kode berikut cukup bagi aplikasi untuk terhubung 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 penyewa memiliki kumpulan tabelnya sendiri. Tabel dibedakan berdasarkan namanya. Tabel mana yang merupakan milik penyewa yang bersifat menentukan.

Salah satu pendekatannya adalah menambahkan nama tabel dengan ID tenant — misalnya, tabel EMPLOYEE disebut T356_EMPLOYEE untuk tenant dengan ID 356. Aplikasi harus menambahkan setiap awalan tabel dengan awalan Ttenant ID sebelum mengirim kueri ke database yang dikembalikan oleh pemetaan.

Pendekatan lain adalah menambahkan table_prefix ke pemetaan yang digunakan oleh kueri sehingga menemukan tabel yang tepat untuk tenant.

Pendekatan campuran juga memungkinkan: jika pola pengelolaan data adalah pola skema, dan awalan tabel kosong, pemetaan default terjadi (tambahkan nama tabel dengan ID tenant).

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 penyewa yang sesuai adalah memiliki kolom yang disebut TENANT di setiap tabel. Nilai kolom adalah tenant ID. Setiap kueri harus menambahkan predikat AND TENANT = tenant ID ke klausul WHERE yang ada atau menambahkan klausul WHERE dengan predikat AND TENANT = tenant ID.

Untuk terhubung ke database dan membuat kueri yang tepat, ID tenant harus tersedia dalam logika aplikasi. Ini dapat diteruskan sebagai parameter atau disimpan sebagai konteks untaian.

Beberapa operasi siklus proses mengharuskan Anda mengubah konfigurasi pemetaan pola tenant-to-data-management-misalnya, saat 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 kueri dan atribusi

Prinsip dasar yang mendasar dari aplikasi multi-tenant adalah beberapa tenant dapat berbagi resource cloud tunggal. Pola pengelolaan data sebelumnya termasuk dalam kategori ini, kecuali untuk kasus ketika tenant tunggal dialokasikan ke instance Spanner tunggal.

Berbagi sumber daya tidak hanya 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 dalam log, maka teks kueri harus diperiksa untuk menentukan penyewa yang kueri dieksekusi. Dalam pola pengelolaan data tabel, Anda harus mengurai predikat. Dalam pola pengelolaan data skema, Anda harus menguraikan 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 membuat kueri tabel pemetaan pola tenant-to-data-management.

Akan lebih mudah untuk menganalisis log dan kueri dengan menentukan tenant untuk kueri tertentu tanpa menguraikan teks kueri. Salah satu cara untuk mengidentifikasi penyewa secara seragam untuk kueri di seluruh 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. Untuk menghindari penguraian sintaks SQL dan mengekstrak ID tenant dari predikat, ID tenant ditambahkan sebagai komentar. Komentar dapat diekstrak tanpa harus menguraikan sintaks 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 yang terpisah dari pola pengelolaan data. Jika tenant dipindahkan dari satu pola pengelolaan data ke yang lain, teks kueri dapat berubah, namun atribusi tetap sama dalam teks kueri.

Contoh kode sebelumnya hanya satu metode. Metode lain adalah menyisipkan objek JSON sebagai komentar, bukan label dan nilai:

select * from T356_EMPLOYEE;
  -- {"TENANT": 356}

Operasi siklus akses tenant tenant

Bergantung pada falsafah desain, aplikasi multi-tenant dapat langsung menerapkan operasi siklus data yang dijelaskan sebelumnya, atau dapat membuat fitur administrasi tenant terpisah.

Terlepas dari strategi penerapan, operasi siklus mungkin harus dijalankan tanpa logika aplikasi berjalan secara bersamaan — misalnya, saat memindahkan tenant dari satu pola pengelolaan data ke pola pengelolaan data lainnya, logika aplikasi tidak dapat berjalan karena data tidak dalam satu database. Saat data tidak berada dalam satu database, data memerlukan dua operasi tambahan dari perspektif aplikasi:

  • Menghentikan penyewa: Menonaktifkan semua akses logika aplikasi saat mengizinkan operasi siklus data.
  • Memulai penyewa: Logika aplikasi dapat mengakses data penyewa sementara operasi siklus proses yang akan mengganggu logika aplikasi dinonaktifkan.

Meskipun tidak sering digunakan, penghentian penyewa darurat mungkin merupakan operasi siklus hidup penting lainnya. Gunakan penonaktifan ini jika Anda mencurigai adanya pelanggaran, dan Anda harus melarang semua akses ke data tenant — tidak hanya logika aplikasi, tetapi juga operasi siklus proses. Pelanggaran dapat berasal dari dalam atau luar database.

Operasi siklus proses yang cocok yang menghapus status darurat juga harus tersedia. Operasi tersebut dapat memerlukan dua administrator atau lebih untuk login sekaligus untuk menerapkan kontrol bersama.

Isolasi aplikasi

Berbagai pola pengelolaan data mendukung berbagai tingkat isolasi data tenant. Dari tingkat yang paling terpencil (instance) hingga tingkat yang paling tidak terisolir (tabel), tingkat isolasi yang berbeda mungkin terjadi.

Dalam konteks aplikasi multi-penyewa, keputusan penerapan yang serupa harus dibuat: apakah semua penyewa mengakses data mereka (dalam pola pengelolaan data yang mungkin berbeda) menggunakan penerapan aplikasi yang sama? Misalnya, cluster Kubernetes tunggal mungkin mendukung semua tenant dan saat tenant mengakses datanya, cluster yang sama menjalankan logika bisnis.

Atau, seperti dalam kasus pola pengelolaan data, penyewa yang berbeda mungkin diarahkan ke penerapan aplikasi yang berbeda. Penyewa besar mungkin memiliki akses ke penerapan aplikasi yang eksklusif bagi mereka, sementara penyewa yang lebih kecil atau penyewa dalam paket gratis berbagi penerapan aplikasi.

Alih-alih 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 penyewa berbagi penerapan aplikasi tunggal. Ada kemungkinan untuk memiliki pola pengelolaan data basis data dan semua penyewa ini berbagi satu penerapan aplikasi.

Multi-tenansi adalah pola pengelolaan aplikasi-desain-data yang penting, terutama saat efisiensi resource memainkan peran penting. Spanner mendukung beberapa pola pengelolaan data — gunakan untuk menerapkan aplikasi multi-tenant. Dengan skalabilitas ekstrem Spanner dan SLA yang ketat, ini adalah database yang ideal untuk penerapan aplikasi multi-tenant yang besar.

Langkah berikutnya

  • Jelajahi arsitektur referensi, diagram, tutorial, dan praktik terbaik tentang Google Cloud. Lihat Pusat Arsitektur Cloud kami.