Praktik terbaik untuk workload multi-tenant di BigQuery

Dokumen ini memberikan teknik dan praktik terbaik untuk pola umum yang digunakan di platform data multi-tenant dan data mart perusahaan.

Perusahaan komersial, vendor software as a service (SaaS), dan organisasi pemerintah sering kali harus menghosting data internal dan pihak ketiga dengan aman di batas geografis dan administratif. BigQuery adalah alat canggih yang dapat secara konsisten memenuhi persyaratan platform multi-tenant untuk exabyte data dan ratusan ribu konsumen data di berbagai unit bisnis yang berbeda. Dokumen ini ditujukan untuk organisasi yang men-deploy platform multi-tenant di BigQuery dan yang ingin memahami kontrol akses yang tersedia serta fitur pengelolaan performa.

Builder platform multi-tenant sering kali perlu menyeimbangkan pertimbangan untuk hal berikut:

• Isolasi data: Menerapkan kontrol yang kuat untuk mencegah kebocoran data di seluruh tenant.
• Performa yang konsisten: Konfigurasi dan bagi pemesanan BigQuery untuk mempertahankan performa yang konsisten di seluruh tenant.
• Pengelolaan resource: Merencanakan dampak kuota dan batas.
• Distribusi geografis: Temukan data di lokasi geografis yang ditetapkan dan diperlukan. Untuk masalah terkait kepatuhan, lihat penawaran kepatuhan Google Cloud.
• Audit dan keamanan: Lindungi data tenant dari akses yang tidak pantas dan pemindahan yang tidak sah.
• Pengelolaan biaya: Pastikan biaya BigQuery yang konsisten untuk menghosting setiap tenant.
• Kompleksitas Operasional: Meminimalkan jumlah variabilitas sistem yang diperlukan untuk menghosting tenant baru.

Vendor SaaS dengan infrastruktur tenant bersama

Vendor SaaS yang menghosting data pihak ketiga harus memastikan keandalan dan isolasi seluruh armada pelanggan mereka. Pelanggan tersebut mungkin berjumlah puluhan ribu, dan data pelanggan dapat diakses melalui infrastruktur layanan bersama. Beberapa vendor SaaS juga mengelola datastore pusat yang bersih untuk melakukan analisis di seluruh armada tenant mereka.

Desain set data per tenant membantu mengurangi kekhawatiran berikut yang dialami organisasi saat skalanya mencapai ribuan tenant:

• Kompleksitas administratif: jumlah total project baru dan resource cloud per pelanggan
• Latensi menyeluruh: seberapa baru datastore untuk tenant dan solusi analisis lintas-pelanggan
• Ekspektasi performa: memastikan performa tenant tetap dalam batas yang dapat diterima

Mengonfigurasi set data untuk setiap tenant

Dalam project yang dikhususkan untuk menyimpan data pelanggan, setiap data pelanggan dipisahkan oleh set data BigQuery. Dalam organisasi host, Anda menggunakan project kedua untuk men-deploy analisis dan machine learning pada gabungan data pelanggan. Selanjutnya, Anda dapat mengonfigurasi mesin pemrosesan data, Dataflow, untuk melakukan penulisan ganda data yang masuk ke tabel internal dan khusus tenant. Konfigurasi Dataflow menggunakan tabel yang ditulis sepenuhnya, bukan tampilan yang diotorisasi. Penggunaan tabel yang ditulis sepenuhnya memungkinkan penanganan distribusi geografis yang seragam dan membantu menghindari tercapainya batas tampilan resmi saat jumlah tenant diskalakan.

Pemisahan penyimpanan dan komputasi BigQuery memungkinkan Anda mengonfigurasi lebih sedikit project dibandingkan dengan warehouse berbasis cluster untuk menangani masalah seperti tingkat layanan dan isolasi data. Jika Anda tidak perlu mengonfigurasi tenant dengan resource cloud khusus tambahan, sebaiknya pertimbangkan konfigurasi default set data khusus untuk setiap tenant. Diagram berikut menunjukkan contoh konfigurasi project berdasarkan desain yang direkomendasikan ini:

Gambar 1. Sejumlah project konstan menangani data dan kebutuhan pemrosesan seiring bertambahnya jumlah tenant.

Konfigurasi project pada gambar 1 mencakup project berikut:

• Project data pipeline: komponen infrastruktur inti yang menerima, memproses, dan mendistribusikan data tenant, semuanya dikemas ke dalam satu project.
• Project data tenant gabungan: project data inti yang menyimpan set data per pelanggan. Data tenant diharapkan akan diakses melalui project tingkat komputasi.
• Project pengembangan internal: project yang mewakili resource yang dikelola sendiri dan digunakan tim analisis untuk mengevaluasi data tenant dan membuat fitur baru.
• Project aplikasi pengguna akhir: project yang berisi resource yang didesain untuk berinteraksi dengan pengguna akhir. Sebaiknya gunakan akun layanan cakupan tenant untuk mengakses set data tenant, dan gunakan pipeline build yang andal dan aman untuk men-deploy aplikasi.
• Project tingkat komputasi pemesanan: project yang memetakan aktivitas kueri tenant ke pemesanan BigQuery.

Membagikan pemesanan

Pemesanan dalam pendekatan ini mengandalkan algoritma penjadwalan adil yang terintegrasi dalam pemesanan BigQuery. Setiap pemesanan tingkat komputasi ditetapkan ke satu project. Kueri penyewa menggunakan slot penjadwalan yang adil yang tersedia untuk setiap project tingkat komputasi, dan slot yang tidak digunakan dari tingkat mana pun akan otomatis digunakan kembali di tingkat lain. Jika tenant memiliki persyaratan waktu tertentu, Anda dapat menggunakan pasangan pemesanan project yang dikhususkan untuk menyediakan jumlah slot yang tepat.

Mengonfigurasi perimeter Kontrol Layanan VPC

Dalam konfigurasi ini, sebaiknya gunakan perimeter Kontrol Layanan VPC untuk mencegah eksposur set data tenant yang tidak disengaja di luar organisasi Google Cloud Anda dan untuk mencegah penggabungan data tanpa izin dalam organisasi.

Perimeter

Dalam konfigurasi ini, sebaiknya Anda membuat perimeter layanan berikut:

• Data pipeline: perimeter di sekitar project data pipeline harus menerapkan semua layanan yang tidak perlu menerima data tenant.
• Data tenant: perimeter di sekitar project set data tenant dan di sekitar project komputasi BigQuery tenant. Terapkan semua layanan untuk mencegah akses dari luar organisasi.
• Aplikasi internal: terapkan semua layanan dan gunakan tingkat akses untuk memberikan akses resource kepada tim departemen.
• Aplikasi eksternal: perimeter di sekitar aplikasi SaaS Anda. Menerapkan semua layanan yang tidak diperlukan agar aplikasi dapat berfungsi.

Perantara perimeter

Dalam konfigurasi ini, sebaiknya Anda membuat perantara perimeter berikut:

• Data pipeline dan data tenant: memungkinkan pipeline untuk menulis data ke dalam set data tenant.
• Data pipeline dan aplikasi internal: memungkinkan pipeline untuk menulis data ke dalam set data lintas-pelanggan.
• Aplikasi eksternal dan data tenant: memungkinkan aplikasi yang terbuka untuk mengkueri data tenant.
• Aplikasi eksternal dan aplikasi internal: memungkinkan aplikasi eksternal memproses data menggunakan model yang dikembangkan dan di-deploy oleh aplikasi internal.

Vendor SaaS dengan infrastruktur tenant khusus

Dalam skenario yang lebih kompleks, vendor SaaS dapat men-deploy infrastruktur komputasi khusus untuk setiap tenant. Dalam skenario ini, infrastruktur khusus bertanggung jawab atas permintaan data tenant di dalam BigQuery.

Desain infrastruktur tenant khusus menangani masalah umum berikut saat men-deploy infrastruktur untuk setiap tenant bersama BigQuery:

• Akuntabilitas penagihan: melacak biaya infrastruktur yang terkait dengan setiap tenant yang terdaftar.
• Latensi menyeluruh: seberapa baru datastore untuk tenant dan solusi analisis lintas-pelanggan.
• Ekspektasi performa: memastikan performa tenant tetap dalam batas yang dapat diterima.

Menempatkan set data dengan sumber daya khusus

Saat Anda men-deploy infrastruktur tenant khusus, sebaiknya buat folder induk untuk project khusus tenant. Kemudian, tempatkan set data BigQuery tenant di dalam project dengan resource khusus yang mengakses data tersebut atas nama tenant. Untuk meminimalkan latensi menyeluruh untuk data tenant, pipeline Dataflow akan memasukkan data langsung ke set data tenant.

Desain ini menangani pemrosesan dan distribusi data upstream, mirip dengan desain infrastruktur bersama sebelumnya. Namun, data tenant dan aplikasi yang mengakses data tenant diatur dalam project khusus tenant (dan secara opsional diatur dalam folder khusus tenant) untuk menyederhanakan pengelolaan penagihan dan resource. Diagram berikut menunjukkan contoh konfigurasi project berdasarkan desain yang direkomendasikan ini:

Gambar 2. Project data pipeline menangani data untuk satu tenant dari beberapa project lainnya.

Konfigurasi project pada gambar 2 mencakup project berikut:

• Project data pipeline: komponen infrastruktur inti yang menerima, memproses, dan mendistribusikan data tenant, semuanya dikemas ke dalam satu project.
• Project tenant khusus: project yang berisi semua resource cloud yang dikhususkan untuk satu tenant, termasuk set data BigQuery. Sebaiknya gunakan Identity and Access Management (IAM) untuk secara signifikan membatasi cakupan akun dan akun layanan yang dapat mengakses set data pelanggan.
• Project analisis internal: project yang mewakili resource yang dikelola sendiri dan digunakan tim analisis untuk mengevaluasi data tenant dan membuat fitur baru.
• Project jaringan eksternal: project yang menangani dan mengarahkan permintaan tenant ke backend khusus.

Membagikan pemesanan

Pemesanan dalam pendekatan ini mengandalkan algoritma penjadwalan wajar yang dibangun ke dalam pemesanan BigQuery. Dalam konfigurasi ini, pemesanan tingkat komputasi ditetapkan ke setiap project tenant yang menggunakan tingkat tersebut. Jika tenant memiliki persyaratan waktu tertentu, Anda dapat membuat pemesanan khusus untuk memberikan jumlah slot yang tepat ke project tenant.

Menggunakan kontrol IAM dan menonaktifkan pembuatan kunci

Perimeter Kontrol Layanan VPC mungkin tidak sesuai untuk skenario ini. Batas terkait project mencegah organisasi menggunakan batas perimeter di sekitar project yang berinteraksi dengan project tenant. Sebagai gantinya, sebaiknya gunakan kontrol IAM yang ketat dan nonaktifkan pembuatan kunci untuk membantu melindungi dari akses eksternal yang tidak diinginkan.

Data mart dengan otoritas pusat

Data mart adalah tema desain umum yang menyimpan data analisis inti di repositori pusat dan subset dibagikan di sepanjang lini bisnis. Data mart sering kali memiliki puluhan atau ratusan tenant, yang diwakili sebagai lini bisnis untuk dipertimbangkan.

Desain data mart di BigQuery memenuhi kebutuhan berikut:

• Kolaborasi data yang aman: membagikan data dengan kontrol teknis untuk meminimalkan akses yang tidak pantas di seluruh tim.
• Tata kelola data terpusat: memastikan aset data inti yang digunakan untuk laporan bisnis penting telah distandardisasi dan divalidasi.
• Atribusi biaya unit bisnis: melacak dan menyesuaikan penggunaan komputasi berdasarkan unit bisnis.

Menggunakan repositori yang dikelola secara terpusat

Dalam desain ini, data inti ditangkap di repositori yang dikelola secara terpusat. Tampilan yang sah, fungsi yang ditentukan pengguna (UDF) yang sah, dan kebijakan kolom sering digunakan bersamaan untuk berbagi data dengan lini bisnis sekaligus mencegah distribusi data sensitif yang tidak disengaja.

Tim dalam project tenant dapat mengakses set data yang diatur secara terpusat berdasarkan izin akun mereka. Tim menggunakan slot yang dialokasikan ke project mereka sendiri untuk mem-build laporan dan set data turunan. Tim data inti menggunakan tampilan yang diotorisasi untuk mempertahankan kepemilikan penuh kontrol akses atas aset data mart. Dalam konfigurasi ini, sebaiknya jangan membuat beberapa lapisan tampilan di atas objek yang disajikan oleh project data inti. Diagram berikut menunjukkan contoh konfigurasi project berdasarkan desain yang direkomendasikan ini:

Gambar 3. Project data inti mempertahankan data mart terpusat yang dapat diakses dari seluruh organisasi.

Konfigurasi project di gambar 3 mencakup project berikut:

• Project data inti: perimeter tata kelola untuk mengelola akses ke data inti dan tampilan data mart. Anda mempertahankan tampilan yang diotorisasi dalam set data di dalam project ini dan memberikan tampilan yang diotorisasi kepada tim analisis Anda berdasarkan keanggotaan grup.
• Infrastruktur Ekstraksi, transformasi, muat (ETL): infrastruktur untuk memproses sumber data upstream menjadi data inti. Bergantung pada kebutuhan pemisahan administratif, Anda dapat memilih untuk men-deploy infrastruktur ETL sebagai projectnya sendiri atau sebagai bagian dari project data inti.
• Project tim Analytics: konsumen data mart menggunakan project ini, dan menggunakan akses infrastruktur yang mereka sediakan sendiri untuk memproses data dalam data mart. Project tim Analytics diharapkan dapat mem-build set data turunan untuk penggunaan lokal.

Menggunakan desain pemesanan dua tingkat

Saat bekerja dengan data mart, sebaiknya Anda menggunakan desain dua tingkat. Dalam desain dua tingkat, Anda menetapkan resource organisasi sebagai pemesanan yang memiliki sejumlah kecil slot untuk mencakup penggunaan umum. Jika tim memiliki kebutuhan yang lebih besar, tetapkan pemesanan di level project atau folder.

Mengonfigurasi perimeter Kontrol Layanan VPC

Dalam konfigurasi ini, sebaiknya gunakan perimeter Kontrol Layanan VPC untuk mencegah eksposur set data BigQuery yang tidak disengaja di luar organisasi Google Cloud Anda.

Perimeter

Dalam konfigurasi ini, sebaiknya Anda membuat perimeter layanan berikut:

• Data inti: perimeter untuk melindungi data warehouse dan set data data mart.
• Data pipelines: perimeter untuk project infrastruktur ETL. Jika data pipeline perlu membuat permintaan di luar organisasi Google Cloud Anda, sebaiknya pisahkan perimeter ini dari perimeter data inti.
• Analytics: perimeter untuk membuat dan men-deploy aset analisis yang bersifat internal bagi organisasi Anda. Perimeter ini diharapkan memiliki kebijakan akses yang lebih permisif daripada perimeter data inti yang dihubungkan.

Perantara perimeter

Dalam konfigurasi ini, sebaiknya Anda membuat perantara perimeter berikut:

• Data pipelines dan data inti: memungkinkan data pipelines menulis ke dalam project data inti.
• Data dan analisis inti: memungkinkan pengguna dalam project analisis untuk menjalankan kueri tampilan yang diotorisasi.

Menyalin set data untuk konfigurasi multiregional

Karena BigQuery tidak mengizinkan kueri lintas regional, Anda tidak dapat menggunakan strategi segmentasi data dengan tampilan yang diotorisasi saat data mart harus ada di beberapa region. Sebagai gantinya, Anda dapat menggunakan BigQuery Data Transfer Service untuk menyalin set data yang relevan ke region lain. Dalam skenario ini, Anda akan membuat kebijakan kolom dalam katalog data untuk setiap region tambahan tempat data berada. Diagram berikut menunjukkan konfigurasi multiregional:

Gambar 4. Konfigurasi multiregional menggunakan BigQuery Data Transfer Service untuk menyalin set data di seluruh region.

Konfigurasi project pada gambar 4 mencakup project berikut.

• Project data inti: perimeter tata kelola untuk mengelola akses ke data inti dan tampilan data mart. Data disalin dan dikelola ke dalam set data regional yang dapat melayani tim secara global.
• Infrastruktur ETL: infrastruktur untuk memproses sumber data upstream ke dalam data inti. Bergantung pada kebutuhan pemisahan administratif, Anda dapat memilih untuk men-deploy infrastruktur ETL sebagai projectnya sendiri atau sebagai bagian dari project data inti.
• Project tim Analytics: konsumen data mart menggunakan project ini, dan menggunakan infrastruktur yang mereka sediakan sendiri untuk memproses data dalam set data regional data mart. Project tim Analytics diharapkan dapat mem-build set data turunan untuk penggunaan lokal.

BigQuery Data Transfer Service adalah komponen terjadwal tambahan dengan beberapa batasan. Penjadwal layanan bawaan dibatasi pada waktu interval minimum selama 15 menit dan harus menyalin semua tabel dari set data sumber. Tidak ada cara untuk menyematkan skrip tambahan untuk membuat subset data spesifik per wilayah ke dalam penjadwal BigQuery Data Transfer Service.

Jika organisasi Anda memerlukan fleksibilitas lebih, opsi berikut tersedia:

• Tugas Cloud Composer: Anda dapat menjadwalkan tugas Cloud Composer untuk mengirim tugas ETL yang membuat subset regional sebelum memicu BigQuery Data Transfer Service melalui API klien. Jika organisasi Anda dapat mendukung latensi tambahan, sebaiknya gunakan opsi ini.
• Infrastruktur ETL: Infrastruktur ETL, seperti Dataflow, dapat melakukan penulisan ganda subset regional ke region target. Jika organisasi Anda memerlukan latensi data antar-region yang minimal, sebaiknya gunakan opsi ini.

Data mart dengan otoritas terdesentralisasi

Gunakan otoritas terdesentralisasi saat Anda memerlukan pemisahan administratif oleh pemilik sistem, lini bisnis, atau masalah geografis.

Data mart yang terdesentralisasi memiliki beberapa hal berikut dibandingkan dengan data mart standar:

• Kolaborasi data yang aman: membagikan data dengan kontrol teknis untuk meminimalkan akses yang tidak pantas di seluruh tim.
• Visibilitas data: tim harus dapat menemukan dan meminta akses ke set data.
• Data provenance: tanpa tim kurator pusat, tim harus dapat memercayai asal data yang masuk ke produk analisis mereka.

Mendelegasikan administrasi data inti

Desain ini berbeda dengan pendekatan data mart konvensional karena otoritas terdesentralisasi mendelegasikan keputusan administrasi data inti ke subgrup komponen organisasi. Saat menggunakan otoritas terdesentralisasi, Anda mempertahankan kontrol terpusat atas keamanan dan kapasitas BigQuery menggunakan Cloud Key Management Service (Cloud KMS), kebijakan kolom, Kontrol Layanan VPC, dan pemesanan. Oleh karena itu, Anda dapat menghindari kelebaran data yang umum terjadi pada warehouse yang dikelola sendiri. Diagram berikut menunjukkan arsitektur yang menggunakan otoritas terdesentralisasi:

Gambar 5. Project tata kelola inti membantu memastikan keamanan yang konsisten, sementara setiap grup mengelola operasi data mereka.

Konfigurasi project pada gambar 5 mencakup project berikut:

• Project tata kelola inti: project yang bertanggung jawab atas masalah pengelolaan lintas organisasi. Dalam project ini, Anda akan membuat resource keamanan seperti key ring Cloud KMS dan kebijakan kolom katalog data. Project ini berfungsi sebagai project administrasi pemesanan BigQuery, sehingga memungkinkan pembagian slot di seluruh organisasi.
• Project data unit organisasi: pemilik data mart yang dikelola sendiri dalam organisasi yang lebih luas. Project tata kelola inti mengelola cakupan terbatas untuk project data unit organisasi.
• Project tim Analytics: project yang digunakan oleh konsumen data mart. Project ini menggunakan infrastruktur dan slot yang disediakan sendiri untuk mengakses dan memproses data dalam data mart.

Menggunakan desain pemesanan dua tingkat

Sebaiknya data mart terdesentralisasi Anda menggunakan desain dua tingkat yang sama dengan data mart standar. Dalam konfigurasi ini, Anda menetapkan pemesanan yang memiliki jumlah slot kecil untuk penggunaan umum ke resource organisasi. Jika tim memiliki kebutuhan yang lebih besar, tetapkan pemesanan di level project atau folder.

Menggunakan katalog data

Katalog data menyediakan penemuan di seluruh organisasi, pemberian tag metadata, dan konfigurasi kebijakan kolom. Penemuan Dataplex secara otomatis membuat entri metadata untuk semua tabel BigQuery baru di seluruh organisasi Anda. Kemampuan Dataplex juga membantu admin tata kelola data mengidentifikasi aset data baru dengan cepat dan menerapkan kontrol yang sesuai.

Mengonfigurasi perimeter Kontrol Layanan VPC

Dalam konfigurasi ini, sebaiknya gunakan perimeter Kontrol Layanan VPC untuk mencegah eksposur set data BigQuery yang tidak disengaja di luar organisasi Google Cloud Anda.

Perimeter

Dalam konfigurasi ini, sebaiknya Anda membuat perimeter layanan berikut:

• Data inti: perimeter untuk melindungi data warehouse dan set data data mart. Perimeter ini harus mencakup semua project unit organisasi dan project tata kelola data.
• Analytics: perimeter untuk membuat dan men-deploy aset analisis internal ke organisasi. Perimeter ini diharapkan memiliki kebijakan akses yang lebih longgar daripada perimeter data inti yang dihubungkan.

Perantara perimeter

Dalam konfigurasi ini, sebaiknya Anda membuat perantara perimeter berikut:

• Data dan analisis inti: memungkinkan pengguna dalam project analisis untuk menjalankan kueri tampilan yang diotorisasi.

Berbagi data multi-organisasi

Berbagi dengan multi-organisasi adalah pertimbangan desain khusus untuk desain data mart. Desain berbagi data ini ditujukan untuk organisasi yang ingin membagikan set data mereka secara aman dengan entitas lain yang memiliki organisasi Google-nya sendiri.

Berbagi data multi-organisasi mengatasi masalah berikut bagi pembagian data:

• Kerahasiaan berbagi: hanya pihak yang dituju yang dapat mengakses data yang dibagikan.
• Perlindungan dari akses yang tidak pantas: hanya resource yang dimaksudkan untuk diakses yang dapat diakses secara eksternal.
• Pemisahan komputasi: pihak eksternal ditagih untuk kueri yang mereka mulai.

Catatan: Dalam beberapa kasus, kueri yang berasal dari organisasi luar dapat gagal secara tidak terduga. Cloud Customer Care dapat membantu Anda memulai perubahan konfigurasi untuk memperbaiki masalah.

Melindungi project internal dari project data bersama

Desain berbagi data multi-organisasi berfokus pada perlindungan project internal organisasi dari aktivitas dalam project data bersama. Project set data bersama berfungsi sebagai buffering untuk melarang akses ke pemrosesan data internal yang sensitif, sekaligus memberikan kemampuan untuk berbagi data secara eksternal.

Kueri yang dimulai dari project eksternal menggunakan resource komputasi project yang memanggil. Jika semua set data yang dikueri memiliki region Google Cloud yang sama, kueri ini dapat menggabungkan data di seluruh organisasi. Diagram berikut menunjukkan cara set data dibagikan dalam konfigurasi project multi-organisasi:

Gambar 6. Organisasi eksternal membuat kueri data dari beberapa set data dalam project bersama.

Konfigurasi project pada gambar 6 mencakup project berikut:

• Project internal organisasi: project yang berisi data internal yang sensitif. Project internal dapat berbagi data secara eksternal dengan menyalin data yang bersih ke dalam set data project data bersama. Project internal harus memiliki akun layanan yang bertanggung jawab untuk memperbarui data bersama.
• Project data bersama: project yang berisi informasi bersih yang disalin dari project internal. Gunakan grup pengguna eksternal untuk mengelola akses oleh pihak eksternal. Dalam skenario ini, Anda mengelola keanggotaan grup sebagai fungsi administratif dan memberikan izin pelihat kepada akun eksternal sehingga mereka dapat mengakses set data melalui grup ini.

Mengonfigurasi perimeter Kontrol Layanan VPC

Dalam konfigurasi ini, sebaiknya gunakan perimeter Kontrol Layanan VPC untuk berbagi data secara eksternal dan mencegah eksposur set data BigQuery yang tidak disengaja di luar project internal Anda.

Perimeter

Dalam konfigurasi ini, sebaiknya Anda membuat perimeter layanan berikut:

• Data internal: perimeter untuk melindungi aset data inti. Kontrol Layanan VPC menerapkan akses ke BigQuery.
• Data yang dibagikan secara eksternal: perimeter untuk menghosting set data yang dapat dibagikan dengan organisasi luar. Perimeter ini menonaktifkan penerapan akses ke BigQuery.

Perantara perimeter

Dalam konfigurasi ini, sebaiknya Anda membuat perantara perimeter berikut:

• Data internal ke eksternal: perantara perimeter memungkinkan project data internal yang lebih dilindungi mengubah data keluar ke project berbagi data eksternal.

Pertimbangan tambahan dalam sistem multi-tenant

Bagian ini memberikan pembahasan lebih mendalam tentang kasus khusus yang dapat Anda pertimbangkan bersama praktik terbaik sebelumnya.

Batas dan kuota resource Google Cloud

• Akun layanan dibatasi pada kuota sementara sebanyak 100 akun layanan per project. Anda dapat meminta kuota melalui Konsol Google Cloud untuk project yang mengelola akun layanan tenant.
• Konkurensi BigQuery memiliki konkurensi default 100 kueri per project yang mengeluarkan kueri (project yang menyimpan set data tidak memiliki batasan tersebut). Untuk meningkatkan kuota yang tidak fleksibel ini, hubungi Sales Rep Anda.
• Kontrol Layanan VPC memiliki batas 10.000 project dalam perimeter layanan di seluruh organisasi. Jika desain project per tenant Anda mengalami peningkatan skala yang tinggi, sebaiknya gunakan desain set data per tenant.
• Kontrol Layanan VPC memiliki batas 100 perimeter, termasuk perantara, per organisasi.

Menggunakan tampilan yang diotorisasi atau tabel subset terwujud

Untuk mengelola akses tenant ke subkumpulan tabel fakta yang besar, Anda dapat menggunakan tampilan yang diizinkan khusus tenant atau membuat tabel subset khusus tenant. Tabel berikut memberikan perbandingan pendekatan ini:

Fitur	Tampilan yang diberi otorisasi	Tabel subset
Jumlah tenant yang didukung	Ada batas ketat 2.500 resource yang diotorisasi per set data.	Resource yang diotorisasi mencakup tampilan yang diotorisasi, set data yang diotorisasi, dan fungsi yang diotorisasi.Tidak ada batasan jumlah set data dalam project atau tabel dalam set data.
Partisi dan pengelompokan	Tampilan yang diizinkan harus memiliki skema cluster dan partisi umum dari tabel dasar. Untuk meningkatkan performa segmentasi tenant, sebaiknya Anda mengelompokkan tabel induk pada ID tenant.	Anda dapat mempartisi tabel subset dan mengelompokkannya sesuai kebutuhan tenant.
Regionalisasi	Tampilan yang diizinkan tidak dapat melintasi region dan harus berada di region Google Cloud pada tabel dasar. Regionalisasi memengaruhi tenant yang berada jauh secara geografis.	Tabel subset dapat berada di region yang paling sesuai untuk tenant. Biaya tambahan mungkin berlaku.
Penerapan kebijakan kolom	Kebijakan kolom yang diterapkan ke tabel dasar diterapkan ke semua tampilan yang diotorisasi, terlepas dari izin pada tampilan tersebut.	Setiap tabel {i>subset<i} harus menerapkan kebijakan kolom agar dapat diterapkan.
Logging akses data	Log akses data tercermin dalam logging tabel dasar.	Akses ke setiap tabel {i>subset<i} dicatat secara terpisah.
Fleksibilitas transformasi	Tampilan yang diotorisasi memungkinkan desain ulang instan untuk objek yang diakses tenant.	Perubahan skema kompleks diperlukan untuk mengubah tabel subset.

Mengontrol data sensitif

Untuk mencegah akses tidak sah ke data, BigQuery menawarkan beberapa fitur tambahan di luar izin IAM standar.

Enkripsi yang disediakan klien

Enkripsi data klien mencakup kasus saat organisasi hosting menyimpan dan memproses data atas nama tenant, tetapi tidak dapat mengakses sebagian konten data. Misalnya, organisasi hosting mungkin dicegah mengakses data pribadi atau perangkat yang dianggap sensitif.

Sebaiknya pengirim data menggunakan kunci enkripsi AEAD, dari library Tink open source, untuk mengenkripsi data sensitif. Kunci enkripsi AEAD library Tink kompatibel dengan fungsi AEAD BigQuery. Kemudian, tenant dapat mendekripsi data dengan mengakses materi kunci dalam UDF yang diotorisasi atau dengan meneruskan materi kunci tersebut sebagai parameter kueri BigQuery, tempat organisasi host tidak dapat mencatat kunci.

Kebijakan akses kolom

Dalam data mart multi-tenant, kebijakan kolom sering digunakan untuk mencegah konten sensitif bocor secara tidak sengaja antartim yang berkolaborasi. Tampilan yang diotorisasi adalah mekanisme yang lebih disukai untuk berbagi data antartim dalam skenario data mart. Tampilan yang diotorisasi tidak dapat memberikan akses ke kolom yang dilindungi.

Saat menetapkan kebijakan untuk menerapkan kontrol akses, Anda akan mencegah akses bagi pengguna yang belum diberi peran pembaca mendetail ke kebijakan tersebut. Meskipun kebijakan tidak diterapkan, kebijakan akan mencatat semua akses pengguna ke kolom yang dikategorikan.

Perlindungan Data Sensitif

Perlindungan Data Sensitif menyediakan API dan utilitas pemindaian yang membantu Anda mengidentifikasi dan mengurangi konten sensitif yang disimpan di dalam set data BigQuery atau Cloud Storage. Organisasi dalam skenario multi-tenant sering menggunakan DLP API (bagian dari Perlindungan Data Sensitif) untuk mengidentifikasi dan secara opsional membuat token data sensitif sebelum disimpan.

Pengelolaan pemesanan slot

Pengelolaan pemesanan dalam sistem multi-tenant membantu mengontrol biaya saat tenant meningkat skala dan memastikan jaminan performa untuk setiap tenant.

Untuk mengelola pemesanan, sebaiknya buat satu project administratif pemesanan. Komitmen slot yang dibeli dalam project administratif yang sama dapat dibagikan di semua reservations yang berasal dari project administratif. Project yang menggunakan komitmen slot hanya dapat ditetapkan ke satu pemesanan dalam satu waktu. Semua kueri yang berasal dari project membagikan slot berdasarkan resource yang tersedia.

Untuk memastikan tujuan tingkat layanan tenant (SLO) terpenuhi, Anda dapat memantau pemesanan melalui Cloud Logging dan skema informasi BigQuery. Organisasi yang mengalami periode sibuk dari aktivitas analis atau tugas prioritas dapat mengalokasikan kapasitas ekstra menggunakan slot fleksibel.

Pemesanan sebagai tingkat komputasi tenant

Vendor SaaS yang memiliki puluhan hingga ribuan tenant biasanya mengonfigurasi pemesanan BigQuery dalam jumlah terbatas sebagai resource bersama.

Jika Anda adalah vendor SaaS yang memiliki infrastruktur tenant bersama, sebaiknya dedikasikan setiap pemesanan ke satu tenant project dan grup guna membagikan project tersebut untuk komputasi BigQuery. Desain ini mengurangi overhead administratif sehingga memiliki ribuan project dan pemesanan tambahan, sekaligus memungkinkan organisasi Anda mengalokasikan kapasitas slot minimum yang diperlukan untuk memenuhi perkiraan kebutuhan performa. untuk pemesanan.

Jika linimasa pemrosesan data ELT merupakan prioritas utama, sebaiknya Anda mengalokasikan pemesanan untuk menangani pemrosesan tersebut. Untuk mencegah penggunaan slot tambahan yang dapat digunakan untuk workload ad hoc, tetapkan pemesanan ke abaikan slot tidak ada aktivitas.

Berikut adalah contoh cara mengonfigurasi pemesanan sebagai tier komputasi tenant:

• Pemrosesan data: 2.000 slot, abaikan tidak ada aktivitas. Pemesanan ini dikonfigurasi untuk memenuhi SLO pemrosesan data.
• Project internal: 1.000 slot, izinkan tidak ada aktivitas. Pemesanan ini diterapkan ke project yang digunakan untuk analytics internal.Slot akan digunakan kembali jika tersisa dari pemrosesan data atau tingkat komputasi.
• Tingkat komputasi rendah: 2.000 slot, abaikan tidak ada aktivitas. Pemesanan ini diterapkan untuk tenant yang diberi resource yang rendah. Tidak seperti tingkat tinggi, pemesanan ini mengabaikan slot tidak ada aktivitas.
• Tingkat komputasi tinggi: 3.000 slot, izinkan tidak ada aktivitas. Pemesanan ini diterapkan untuk tenant yang diberi resource tinggi. Untuk mempercepat kueri, slot tidak ada aktivitas dari pemesanan lain akan otomatis diterapkan.

Jika tenant Anda beroperasi di infrastruktur khusus, sebaiknya tetapkan folder atau project yang ditetapkan ke pemesanan bersama yang sesuai.

Pemesanan per tim

Saat Anda bekerja dengan tim dalam setelan data mart, sebaiknya buat pemesanan untuk setiap tim yang memerlukan komputasi tambahan. Kemudian, tetapkan pemesanan itu ke folder induk yang berisi project tim. Semua project baru untuk tim tersebut menggunakan slot penjadwalan adil dari alokasi resource yang sama.

Berikut adalah contoh cara mengonfigurasi pemesanan per tim:

• Pemesanan tingkat organisasi: 500 slot, mengizinkan tidak ada aktivitas. Pemesanan ini ditetapkan ke organisasi tingkat teratas, dan memberikan slot untuk setiap pengguna BigQuery yang tidak menggunakan project yang memiliki pemesanan khusus
• Pemrosesan data: 1.000 slot, abaikan tidak ada aktivitas. Pemesanan ini dikonfigurasi untuk memenuhi SLO pemrosesan data minimum.
• Administrasi data inti: 500 slot, izinkan tidak ada aktivitas. Pemesanan ini diterapkan untuk project yang digunakan untuk administrasi internal. Slot digunakan kembali jika merupakan sisa dari pemrosesan data atau tingkat komputasi.
• Pemesanan pemrosesan Analytics: 500 slot, izinkan tidak ada aktivitas. Ini adalah pemesanan khusus yang diberikan kepada tim analisis.

Persyaratan hosting multi-regional

Persyaratan hosting multi-regional biasanya akibat dari kebutuhan untuk mengurangi latensi data bagi konsumen atau untuk memenuhi mandat peraturan.

Project di Google Cloud dianggap global dan dapat menyediakan resource di region mana pun. BigQuery menganggap set data, kebijakan kolom, dan komitmen slot sebagai resource regional. Slot hanya dapat mengakses set data di region lokal, dan kebijakan kolom hanya dapat diterapkan ke tabel dalam set data lokal. Untuk menggunakan harga berdasarkan kapasitas, Anda harus membeli slot di setiap region yang berisi set data.

Untuk mendapatkan panduan tentang cara mematuhi persyaratan peraturan, konsultasikan dengan perwakilan penjualan Anda.

Langkah selanjutnya

• Pelajari praktik terbaik IAM.