Sistem AI agentic multi-tenant

Last reviewed 2026-06-18 UTC

Dokumen ini memberikan arsitektur referensi untuk membantu Anda mendesain dan men-deploy sistem AI agentik multi-tenant di Google Cloud. Seiring dengan peningkatan skala deployment AI generatif di organisasi Anda, berbagai unit bisnis memerlukan agen AI khusus yang mengakses alat unik, mengikuti aturan operasional tertentu, dan memproses data sensitif. Unit bisnis dapat mengembangkan silo aplikasi yang terfragmentasi dalam organisasi, yang dapat menyebabkan overhead operasional yang tinggi, kesenjangan tata kelola yang parah, dan risiko eksposur data. Arsitektur ini menunjukkan cara membangun sistem terpusat yang memungkinkan Anda mendukung tim yang terdesentralisasi dengan kemampuan AI yang otonom sekaligus mempertahankan keamanan dan kepatuhan yang terpadu.

Audiens yang dituju untuk dokumen ini mencakup arsitek, developer, dan administrator yang membangun dan mengelola sistem multi-agen tingkat perusahaan di cloud. Dokumen ini mengasumsikan bahwa Anda memiliki pemahaman dasar tentang konsep AI, ML, dan LLM, serta AI agentic.

Bagian deployment dalam dokumen ini memberikan strategi penerapan untuk membantu Anda membangun dan men-deploy sistem AI agentik multi-tenant.

Arsitektur

Diagram berikut menunjukkan arsitektur untuk sistem AI agentik multi-tenant yang mengikuti model hub-and-spoke. Model hub-and-spoke adalah desain jaringan dengan lingkungan pusat, yang dikenal sebagai hub, yang terhubung ke beberapa lingkungan terisolasi, yang dikenal sebagai spoke.

Arsitektur yang menunjukkan sistem AI agentik multi-tenant.

Arsitektur ini terdiri dari komponen berikut:

Komponen Deskripsi
Kontrol Layanan VPC Arsitektur ini menggunakan Kontrol Layanan VPC untuk mengonfigurasi perimeter layanan di tingkat organisasi. Perimeter layanan ini memberikan batas keamanan yang ketat dan mencegah pemindahan data yang tidak sah.
Hub pemilihan rute

Hub perutean bertindak sebagai titik masuk pusat untuk arsitektur dan mencakup komponen berikut:

  • Load Balancer Aplikasi Eksternal: Bertindak sebagai titik ingress pusat untuk pengguna eksternal atau internal. Load balancer memastikan bahwa hanya traffic yang terautentikasi dan aman yang mencapai portal frontend.
  • Google Cloud Armor dan Model Armor: Load balancer mengintegrasikan Cloud Armor dan Model Armor untuk memeriksa dan membersihkan perintah berbahaya di edge jaringan. Hub perutean menggunakan Service Extensions di Load Balancer Aplikasi eksternal untuk mengintegrasikan Model Armor secara langsung ke dalam alur permintaan.
  • Identity-Aware Proxy (IAP): Menerapkan model zero-trustuntuk memverifikasi identitas dan konteks pengguna sebelum permintaan apa pun mencapai aplikasi.
  • Portal frontend: Aplikasi Cloud Run serverless yang bertindak sebagai mesin perutean untuk merutekan permintaan ke project tenant terisolasi yang sesuai.
Hub keamanan dan tata kelola terpusat

Hub keamanan dan tata kelola pusat adalah Google Cloud project khusus yang menyediakan Pengelolaan Akses dan Identitas (IAM), pencatatan aktivitas, pemantauan, dan keamanan terpusat untuk seluruh platform. Hub ini mencakup komponen berikut:

  • Security Command Center: Layanan yang memantau seluruh sistem AI agentik multi-tenant untuk mengetahui risiko keamanan.
  • IAM: Framework kontrol akses yang mengelola identitas dan izin di seluruh hub bersama dan project tenant. Komponen ini menyediakan tata kelola terpusat untuk semua identitas manusia dan mesin.
  • Cloud Logging: Sistem yang mengagregasi log dari hub bersama dan dari project tenant terisolasi ke dalam hub keamanan dan tata kelola pusat.
Project tenant

Setiap project tenant adalah project Google Cloud khusus untuk setiap unit bisnis. Project tenant individual adalah lingkungan terisolasi yang mencakup komponen berikut:

Alur agentic

Contoh sistem multi-tenant dalam arsitektur sebelumnya memiliki alur berikut:

  1. Permintaan pengguna dirutekan melalui Load Balancer Aplikasi eksternal. Dalam hub perutean, pemeriksaan ini diselesaikan untuk membantu memastikan bahwa hanya traffic yang diautentikasi dan aman yang mencapai portal frontend:
    1. Cloud Armor menerapkan kebijakan keamanan untuk menyerap serangan distributed denial-of-service (DDoS) awal berbasis protokol jaringan Lapisan 4. Cloud Armor memeriksa permintaan dan memfilter traffic berbahaya, seperti injeksi SQL (SQLi), pembuatan skrip lintas situs (XSS), dan tanda tangan bot yang diketahui.
    2. Model Armor mencegat payload untuk mendeteksi dan menolak serangan injeksi perintah atau niat jahat.
    3. Jika salah satu lapisan ini mendeteksi ancaman atau akses tidak sah, load balancer akan membatalkan permintaan di edge jaringan.
    4. Jika lapisan keamanan tidak mendeteksi ancaman dan memvalidasi akses pengguna, load balancer akan merutekan traffic ke layanan backend.
  2. Jika permintaan lulus semua pemeriksaan, load balancer akan merutekan permintaan ke platform frontend, yang melakukan tindakan berikut:
    1. Mengekstrak identitas pengguna, seperti ID unit bisnis atau ID tenant pengguna.
    2. Menggunakan IAP untuk memverifikasi identitas perusahaan dan kesehatan perangkat pengguna.
    3. Menggunakan registry yang dikelola secara dinamis untuk mengidentifikasi target tenant yang benar.
  3. Portal frontend merutekan permintaan ke tenant. Untuk memastikan bahwa agen tidak dapat mengakses project tenant lain atau layanan yang tidak sah, Google Cloud Agent Runtime menggunakan Kebijakan PAB untuk membatasi resource yang dapat diakses agen.
  4. Model Armor menggunakan Sensitive Data Protection untuk memeriksa dan menyamarkan secara dinamis informasi identitas pribadi (PII) atau konten yang dilarang. Model Armor melakukan pemeriksaan tambahan untuk injeksi perintah berbahaya dari permintaan guna memastikan bahwa agen hanya memproses data yang aman.

  5. Gemini melakukan tugas berikut untuk membuat respons:

    1. Melakukan proses penalaran awal untuk memahami niat pengguna.
    2. Jika Gemini menentukan bahwa Gemini tidak memiliki fakta spesifik, maka Gemini akan membuat rencana untuk memanggil alat data spesifik tenant:
      1. Untuk memverifikasi apakah pengguna memiliki izin untuk mengakses resource data, agen memverifikasi identitas pengguna dan pengikatan peran IAM.
      2. Untuk mengambil konteks, agen menjalankan panggilan alat melalui server MCP ke datastore tenant.
      3. Agen membuat respons berisi rujukan dengan menggabungkan logika internalnya dengan fakta spesifik per tenant yang baru diambil.

    Jika tidak memerlukan fakta tambahan, Gemini akan membuat respons dan mengirimkannya ke Model Armor.

  6. Model Armor memeriksa dan secara dinamis menyamarkan PII atau konten terlarang, lalu mengirimkan respons yang sudah disanitasi ke agen tenant. Pemeriksaan akhir ini membantu memastikan tidak ada kebocoran data sensitif dalam output.

  7. Respons dikirim kembali ke pengguna, dari agen tenant melalui platform frontend, lalu melalui load balancer.

Produk yang digunakan

Arsitektur referensi ini menggunakan produk dan alat open source berikut Google Cloud dan dipilih karena sifat serverless, skalabilitas, dan fitur keamanannya:

Kasus penggunaan

Sistem AI agentic multi-tenant cocok untuk organisasi perusahaan yang ingin menskalakan deployment AI generatif di luar satu aplikasi. Untuk mengidentifikasi kasus penggunaan yang sesuai dengan arsitektur ini, analisis proses bisnis Anda dan identifikasi berbagai tim yang memerlukan agen AI khusus mereka sendiri yang mengakses alat unik dan data sensitif. Pendekatan ini membantu Anda memberdayakan tim yang terdesentralisasi dengan kemampuan AI otonom sekaligus mempertahankan keamanan terpadu dan kepatuhan perusahaan.

Berikut adalah contoh kasus penggunaan untuk sistem AI agentik multi-tenant.

Layanan pelanggan di seluruh perusahaan

Anda dapat menyesuaikan arsitektur referensi ini untuk menyediakan layanan pelanggan yang didukung AI di berbagai divisi bisnis yang berbeda. Misalnya, untuk mendukung divisi elektronik dan divisi perlengkapan rumah, Anda men-deploy agen elektronik dan agen perlengkapan rumah sebagai dua agen terpisah dalam project tenant terpisah. Agen AI khusus ini bertindak sebagai asisten cerdas yang menangani pertanyaan dukungan khusus divisi dengan mengakses spesifikasi teknis, garansi, atau kebijakan pengembalian yang unik. Otomatisasi ini memungkinkan tim dukungan manusia berfokus pada eskalasi pelanggan yang lebih kompleks.

Untuk kasus penggunaan ini, arsitektur memberikan manfaat berikut:

  • Isolasi data yang ketat: Desain multi-tenant memastikan bahwa pengetahuan dukungan untuk setiap divisi diisolasi secara ketat. Kebijakan PAB menyediakan pembatasan yang membantu memastikan bahwa identitas agen di satu tenant tidak dapat mengakses data di tenant lain.
  • Pengetahuan agen khusus: Karena setiap agen berada di project tenant yang terisolasi, agen hanya mengambil konteks dari datastore khusus divisi. Pengambilan yang ditargetkan ini memastikan akurasi yang tinggi dan mencegah agen mengacaukan kebijakan berbagai unit bisnis.
  • Mengurangi risiko lintas domain: Arsitektur ini membantu menghilangkan risiko eksposur data antar-unit bisnis. Meskipun identitas agen disusupi, agen tidak dapat mengakses resource yang tidak sah. Google Cloud

Arsitektur ini ideal untuk organisasi dan perusahaan retail besar yang mengelola beberapa merek atau unit bisnis yang berbeda dan yang memerlukan kedaulatan data yang ketat.

Alternatif desain

Bagian ini menyajikan pendekatan desain alternatif yang dapat Anda pertimbangkan untuk deployment AI agentic multi-tenant di Google Cloud.

Deployment akses pribadi

Dalam arsitektur yang dijelaskan dalam dokumen ini, pengguna mengakses sistem AI multi-tenant dan berbasis agen melalui internet publik melalui Load Balancer Aplikasi eksternal yang diekspos secara terpusat. Jika organisasi Anda memerlukan sistem yang tetap tidak dapat diakses dari internet publik, Anda dapat menyesuaikan arsitektur untuk menggunakan salah satu strategi akses pribadi berikut.

Memblokir traffic dengan kebijakan keamanan edge

Untuk mengizinkan traffic hanya dari alamat IP perusahaan terverifikasi organisasi Anda, Anda dapat mengonfigurasi kebijakan keamanan Cloud Armor untuk menolak traffic lainnya. Aturan keamanan berprioritas tinggi ini memblokir semua permintaan yang tidak sah di edge jaringan. Untuk lapisan keamanan tambahan, Anda dapat menggunakan IAP untuk mewajibkan sesi identitas perusahaan yang valid dan Anda dapat mengonfigurasi izin IAM untuk semua pengguna.

Dengan pendekatan ini, Anda dapat memanfaatkan kebijakan keamanan edge Cloud Armor untuk memindahkan mitigasi DDoS dan pemfilteran WAF, seperti SQLi dan XSS, serta memberikan pengalaman zero-trust. Namun, alamat IP frontend Load Balancer Aplikasi eksternal tetap bersifat publik dan mungkin tidak memenuhi persyaratan kepatuhan beberapa organisasi.

Merutekan traffic melalui Load Balancer Aplikasi internal

Arsitektur dalam dokumen ini menggunakan Load Balancer Aplikasi eksternal, yang menyediakan kebijakan Cloud Armor yang andal, fitur keamanan yang lebih canggih, dan kompleksitas operasional yang lebih rendah dibandingkan dengan load balancer internal. Namun, penggunaan load balancer eksternal berarti traffic melintasi internet publik.

Untuk menjaga agar traffic sepenuhnya berada dalam jaringan Google pribadi, Anda dapat menggunakan Load Balancer Aplikasi internal. Penggunaan Load Balancer Aplikasi internal mendukung IAP untuk verifikasi identitas. Load Balancer Aplikasi eksternal global mengevaluasi kebijakan IAP di lapisan edge. Sebaliknya, Load Balancer Aplikasi internal mengevaluasi kebijakan di lapisan jaringan internal. Karena traffic tidak pernah melintasi internet publik, penggunaan Load Balancer Aplikasi internal membantu Anda memenuhi persyaratan kedaulatan data yang ketat dan alamat IP publik nol.

Untuk mempertahankan latensi rendah dan mematuhi persyaratan residensi data regional, deploy Load Balancer Aplikasi internal regional di setiap region utama. Dengan Load Balancer Aplikasi internal regional, Anda merutekan traffic dari lingkungan lokal melalui Cloud Interconnect atau melalui Cloud VPN langsung ke alamat IP internal load balancer. Load Balancer Aplikasi internal regional mendukung Cloud Armor regional untuk perlindungan WAF internal. Namun, dibandingkan dengan Load Balancer Aplikasi eksternal, Load Balancer Aplikasi internal regional mendukung serangkaian kebijakan keamanan Cloud Armor yang terbatas, tidak memiliki fitur keamanan tingkat lanjut, dan meningkatkan kompleksitas operasional.

Untuk lebih meminimalkan latensi dan membantu memastikan ketersediaan tinggi untuk memenuhi persyaratan disaster recovery, Anda dapat men-deploy Load Balancer Aplikasi internal lintas-region. Dengan Load Balancer Aplikasi internal lintas region, Anda menggunakan Cloud DNS dengan kebijakan perutean geolokasi untuk me-resolve URL internal aplikasi ke Load Balancer Aplikasi internal lintas region di Google Cloud region yang paling dekat dengan pengguna. Namun, konfigurasi lintas regional tidak mendukung integrasi Cloud Armor apa pun.

Infrastruktur komputasi

Untuk memprioritaskan pendekatan serverless-first yang memberikan pengelolaan yang lebih mudah dan overhead operasional yang lebih rendah, arsitektur dalam dokumen ini menggunakan Cloud Run untuk infrastruktur komputasinya. Anda juga dapat menjalankan aplikasi dalam container di cluster GKE. Google Kubernetes Engine (GKE) adalah mesin orkestrasi container yang mengotomatiskan deployment, penskalaan, dan pengelolaan aplikasi dalam container. GKE sepenuhnya mendukung Load Balancer Aplikasi internal dan eksternal. Untuk mengetahui informasi tentang cara memilih layanan compute untuk workload Anda di Google Cloud, lihat Menghosting Aplikasi di Google Cloud.

Server Model Context Protocol (MCP)

Untuk mengaktifkan interaksi komponen sistem agen, Anda perlu menetapkan protokol komunikasi yang jelas. MCP adalah protokol terbuka yang menyediakan antarmuka standar bagi agen untuk mengakses dan menggunakan alat, data, dan layanan lain yang diperlukan.

Untuk menghubungkan agen tenant ke penyimpanan data, pertimbangkan persyaratan aplikasi Anda untuk memilih dari opsi deployment server MCP berikut. Saat Anda memilih antara deployment MCP lokal dan bersama, pertimbangkan kompromi antara isolasi data dan efisiensi operasional.

  • Server MCP lokal: Server MCP lokal, atau server MCP khusus tenant, adalah server MCP yang Anda deploy dalam setiap project tenant dan yang memberikan akses agen ke penyimpanan data dan alat yang khusus untuk unit bisnis tersebut.

    Berikut adalah fitur dan pertimbangan utama untuk server MCP lokal:

    • Jaringan: Perimeter Kontrol Layanan VPC tingkat project dan Kebijakan PAB memberikan keamanan dan isolasi bawaan, yang membantu memastikan tidak ada akses lintas tenant.
    • Pengelolaan: Tim developer dan operasi masing-masing mengelola project tenant secara independen. Isolasi ini memberikan otonomi untuk setiap unit bisnis.
    • Keamanan: Batas IAM tetap dari project tenant membantu meminimalkan permukaan risiko lateral dan tidak memerlukan pemetaan identitas yang kompleks.

    Server MCP lokal menawarkan isolasi maksimum dan dapat menangani akses data yang sangat sensitif atau teregulasi. Namun, jika Anda men-deploy beberapa server MCP lokal, Anda akan meningkatkan beban operasional. Sebaiknya gunakan server MCP lokal untuk aplikasi yang memerlukan akses terbatas ke penyimpanan data yang mungkin berisi informasi sensitif.

  • Server MCP bersama: Server MCP bersama, atau server MCP global, adalah server MCP yang Anda deploy di project layanan bersama. Server MCP bersama memberikan akses ke alat dan sistem yang umum di beberapa tenant.

    Berikut adalah fitur dan pertimbangan utama untuk server MCP bersama:

    • Jaringan: Untuk memastikan traffic tidak melintasi internet publik, server MCP bersama memerlukan konektivitas pribadi, seperti Private Service Connect atau Peering Jaringan VPC.
    • Pengelolaan: Tim operasi terpusat mengelola penerapan untuk seluruh sistem. Pengelolaan gabungan ini mengoptimalkan efisiensi operasional dan menghilangkan persyaratan untuk menduplikasi penerapan lokal di beberapa tenant.
    • Keamanan: Anda menyebarkan identitas pengguna akhir dengan aman dari agen di project tenant ke server MCP bersama. Untuk membantu memastikan bahwa pengguna hanya dapat mengakses atau mengubah data yang diizinkan, server MCP bersama menggunakan identitas pengguna yang diteruskan untuk menerapkan kontrol akses terperinci pada sistem backend.

    Server MCP bersama memusatkan pengelolaan untuk alat umum, yang mengurangi duplikasi dan mengoptimalkan efisiensi operasional. Meskipun server MCP bersama mengurangi beban pengelolaan, server tersebut memerlukan logika otorisasi dan propagasi identitas yang andal untuk mempertahankan akses yang aman. Sebaiknya gunakan server MCP bersama untuk berinteraksi dengan sistem dan alat umum perusahaan, seperti alat pelaporan biaya, sistem sumber daya manusia (SDM), pusat informasi di seluruh perusahaan, atau pengelola kehadiran.

Dalam arsitektur ini, Anda menggunakan server MCP untuk menstandardisasi koneksi antara agen tenant dan penyimpanan data Anda. Bergantung pada persyaratan beban kerja, Anda dapat menggunakan jenis alat agen lainnya untuk menghubungkan agen dengan API dan sistem eksternal tertentu. Untuk mengetahui informasi selengkapnya tentang interaksi alat agen, lihat Alat agen.

Pertimbangan desain

Bagian berikut menjelaskan faktor desain, praktik terbaik, dan rekomendasi yang perlu dipertimbangkan saat Anda menggunakan arsitektur referensi ini untuk mengembangkan topologi yang memenuhi persyaratan spesifik Anda terkait keamanan, keandalan, biaya, dan performa. Panduan di bagian ini tidak lengkap. Bergantung pada persyaratan beban kerja Anda serta produk dan fitur yang Anda gunakan, mungkin ada faktor desain dan pertimbangan tambahan yang harus Anda pertimbangkan.

Keamanan, privasi, dan kepatuhan

Bagian ini menjelaskan pertimbangan dan rekomendasi desain untuk merancang topologi di Google Cloud yang memenuhi persyaratan keamanan, privasi, dan kepatuhan workload Anda.

Komponen Pertimbangan dan rekomendasi desain
Virtual Private Cloud (VPC) Isolasi tenant: Dalam arsitektur ini, Anda men-deploy setiap tenant dalam project Google Cloud khusus. Untuk membuat batas keamanan yang ketat, gabungkan isolasi tingkat project tenant dengan Kebijakan PAB dan Kontrol Layanan VPC di tingkat organisasi.
IAM Kontrol akses: Untuk menerapkan prinsip hak istimewa terendah, gunakan model akses berbasis persona. Misalnya, Anda dapat menentukan peran IAM kustom untuk memastikan bahwa developer yang membuat agen di satu tenant tidak dapat mengakses data di tenant lain.
Cloud Armor

Perlindungan WAF internal dan edge: Cloud Armor memberikan perlindungan keamanan dan WAF untuk melindungi portal frontend dari serangan DDoS dan kerentanan web. Load Balancer Aplikasi eksternal global mendukung rangkaian lengkap fitur edge lanjutan, seperti pengelolaan bot dan Perlindungan Adaptif Google Cloud Armor.

Jika Anda men-deploy Load Balancer Aplikasi internal regional, Cloud Armor beroperasi dengan serangkaian kebijakan WAF standar yang terbatas. Kumpulan kebijakan yang dibatasi disesuaikan untuk batas jaringan internal dan mencakup kebijakan seperti perlindungan SQLi dan XSS. Untuk mengetahui informasi selengkapnya, lihat Mengintegrasikan Cloud Armor dengan produk Google lainnya.
Agent Platform

Endpoint model bersama: Untuk mencegah penyalahgunaan dan memastikan penggunaan yang wajar untuk endpoint model bersama, terapkan salah satu strategi berikut:

  • Pembatasan kapasitas tingkat penyewa: Menerapkan kuota di portal frontend untuk setiap penyewa sebelum permintaan mencapai endpoint bersama. Terapkan kuota dengan melakukan hal berikut:
    1. Ekstrak identitas tenant dari konteks IAP.
    2. Lacak penggunaan terhadap batas yang telah ditentukan sebelumnya untuk setiap tenant dengan menggunakan penyimpanan eksternal seperti Memorystore for Redis.
    3. Menolak permintaan dari penyewa yang melebihi batasnya.
  • Gateway API: Untuk menerapkan kuota per tenant menggunakan Kunci API dan paket penggunaan, terapkan Gateway API sebelum endpoint bersama.
Cloud Run

Rendering konten: Untuk meningkatkan postur keamanan portal frontend, prioritaskan rendering sisi server (SSR) daripada rendering sisi klien (CSR). Dibandingkan dengan CSR, SSR menawarkan manfaat berikut:

  • Mengeksekusi logika aplikasi dan mengelola rahasia dalam lingkungan Google Cloud yang terkontrol.
  • Mengurangi area serangan sisi klien dan mencegah kebocoran data sensitif ke browser tidak tepercaya pengguna.
  • Membatasi eksposur data dengan hanya mengirimkan HTML yang diperlukan ke klien.
  • Menyediakan encoding output terpusat untuk melindungi dari serangan pembuatan skrip lintas situs (XSS).
Security Command Center Pemantauan keamanan terpusat: Untuk memantau ancaman dan menerapkan kebijakan keamanan seperti autentikasi multi-faktor (MFA) dan enkripsi data, gunakan alat di Security Command Center.

Rekomendasi keamanan lainnya

Keandalan

Bagian ini menjelaskan pertimbangan dan rekomendasi desain untuk membangun dan mengoperasikan infrastruktur yang andal untuk deployment Anda di Google Cloud.

Komponen Pertimbangan dan rekomendasi desain
Cloud Load Balancing Perutean global: Load Balancer Aplikasi eksternal global menyediakan satu alamat IP Anycast yang secara otomatis merutekan traffic pengguna ke edge Google geografis terdekat. Konfigurasi ini mengurangi latensi melalui penghentian Secure Sockets Layer (SSL) di edge. Layanan ini juga memastikan ketersediaan tinggi jika suatu region mengalami pemadaman layanan karena layanan ini secara cerdas mengalihkan traffic ke backend regional yang berfungsi dengan baik.
Tenant Fault tolerance: Untuk mentoleransi atau menangani kegagalan tingkat agen, deploy agen di project tenant yang terisolasi. Isolasi ini membantu memastikan bahwa masalah operasional atau insiden keamanan tetap berada dalam satu unit bisnis dan tidak memengaruhi resource atau unit bisnis lainnya.
Agent Platform Perencanaan kapasitas: Jika jumlah permintaan ke model melebihi kapasitas yang dialokasikan, model akan menampilkan kode error 429. Untuk workload yang penting bagi bisnis dan memerlukan throughput tinggi yang konsisten, Anda dapat memesan throughput menggunakan Throughput yang Disediakan.
Agent Runtime

Skalabilitas serverless: Agen yang di-deploy di Agent Runtime diskalakan secara independen berdasarkan permintaan. Lonjakan penggunaan yang tiba-tiba di satu tenant tidak akan menghabiskan resource komputasi atau memengaruhi ketersediaan agen di project tenant lain.

Penanganan error: Untuk menangani error sementara seperti batas laju kode error 429, logika orkestrasi agen menggunakan backoff eksponensial. Jika batas waktu konteks terlampaui, agen akan melakukan penghentian normal dan melaporkan progres parsial kembali kepada pengguna. Misalnya, batas waktu konteks dapat terlampaui karena panggilan alat yang lambat, latensi API pihak ketiga, pemrosesan set data yang sangat besar, atau pemrosesan yang intensif secara komputasi.

Untuk prinsip dan rekomendasi keandalan yang khusus untuk workload AI dan ML, lihat Perspektif AI dan ML: Keandalan dalam Well-Architected Framework.

Efisiensi operasional

Bagian ini menjelaskan faktor-faktor yang perlu dipertimbangkan saat Anda menggunakan arsitektur referensi ini untuk mendesain topologi Google Cloud yang dapat Anda operasikan secara efisien.

Komponen Pertimbangan dan rekomendasi desain
Google Cloud Observability Pemantauan terpusat: Logging dan Monitoring memungkinkan Anda memantau kondisi dan performa seluruh platform. Anda dapat menyiapkan pemberitahuan untuk mendeteksi dan memecahkan masalah secara proaktif tanpa mengizinkan akses ke data sensitif.
Semua produk dalam arsitektur Deployment standar: Menggunakan Agent Platform dalam pola arsitektur tenant standar memungkinkan Anda menetapkan dasar pengukuran yang konsisten saat Anda mengaktifkan tenant baru. Untuk mengurangi beban operasional, otomatiskan proses deployment menggunakan alat Infrastructure as Code (IaC) seperti Terraform. Untuk kode Terraform yang dapat Anda gunakan untuk membangun dan men-deploy sistem AI agentik multi-tenant, lihat bagian Deployment dalam dokumen ini.

Untuk mengetahui prinsip dan rekomendasi keunggulan operasional yang khusus untuk workload AI dan ML, lihat Perspektif AI dan ML: Keunggulan operasional dalam Framework yang Dirancang dengan Baik.

Pengoptimalan biaya

Bagian ini memberikan panduan untuk mengoptimalkan biaya penyiapan dan pengoperasian topologi Google Cloud yang Anda buat menggunakan arsitektur referensi ini.

Komponen Pertimbangan dan rekomendasi desain
Agent Platform

Penggunaan token: Untuk mengelola biaya dan mencegah model AI Anda melampaui jendela konteks, gunakan strategi berikut untuk mengelola konteks model AI:

  • Ringkasan konteks: Daripada menyimpan seluruh percakapan sesi sebagai konteks, gunakan model AI untuk meringkas percakapan lama dan informasi yang kurang penting.
  • Memangkas output: Mengidentifikasi dan menghapus bagian output alat atau konteks yang diambil yang kurang relevan atau terlalu panjang. Misalnya, jika Anda hanya memerlukan nama kolom dari data Anda, Anda dapat menghapus metadata yang berlebihan dari pengambilan skema database. Strategi ini memerlukan logika kustom yang menggunakan heuristik, pemfilteran, atau model bahasa kecil (SLM) untuk mengekstrak informasi yang paling penting.
  • Batas token maksimum: Untuk membantu mencegah loop tak terbatas dan membantu mengontrol biaya, terapkan batas token maksimum sesi.

Endpoint model: Untuk mengelola kuota API dan penggunaan resource, Anda dapat men-deploy endpoint Platform Agen dalam konfigurasi khusus atau konfigurasi bersama:

  • Endpoint khusus: Saat men-deploy endpoint dalam setiap project tenant, Anda menyediakan isolasi kuota bawaan. Penggunaan setiap tenant dihitung terhadap kuota projectnya sendiri, yang mencegah dampak antar-tenant. Dibandingkan dengan endpoint bersama, endpoint khusus menawarkan pengelolaan kuota yang lebih sederhana. Namun, endpoint khusus mencegah Anda memanfaatkan potensi penghematan biaya dari endpoint bersama.
  • Endpoint bersama: Untuk mengoptimalkan biaya, Anda dapat menghosting endpoint bersama di hub keamanan dan tata kelola pusat. Karena semua tenant berbagi kumpulan kuota yang sama, untuk mencegah serangan berbahaya, Anda harus menerapkan strategi mitigasi seperti pembatasan kapasitas di tingkat tenant atau penerapan kuota dengan Gateway API. Dibandingkan dengan endpoint khusus, endpoint bersama lebih hemat biaya. Namun, endpoint bersama memerlukan upaya engineering tambahan dan dapat menimbulkan latensi dan overhead pengelolaan.

Untuk mengetahui informasi tentang biaya di Agent Platform, lihat Biaya untuk membangun dan men-deploy model AI di Agent Platform.
Cloud Run Pengukuran: Pengukuran memungkinkan Anda memantau performa, memecahkan masalah, dan melacak penggunaan resource untuk setiap tenant. Untuk mengidentifikasi tenant untuk setiap permintaan, ekstrak identitas pengguna dari konteks yang disediakan IAP. Untuk mengetahui informasi tentang cara menginstrumentasikan aplikasi Anda, lihat Memilih pendekatan instrumentasi.
Model Armor Pemfilteran perintah terpusat: Untuk menerapkan tata kelola yang ketat dan postur zero-trust, arsitektur ini men-deploy Model Armor di dua lapisan: di hub perutean dan dalam setiap project tenant. Meskipun pendekatan dua lapis ini membantu memastikan kedaulatan data, pendekatan ini meningkatkan latensi dan biaya operasional. Untuk mengurangi biaya dan kompleksitas sistem, filter semua perintah dan respons dengan men-deploy Model Armor secara eksklusif di hub perutean.
Semua produk dalam arsitektur

Infrastruktur bersama: Komponen infrastruktur inti bersama, seperti portal frontend, hub keamanan dan tata kelola pusat, serta Agent Platform, dapat mengurangi biaya dibandingkan dengan saat Anda membuat stack kustom terpisah untuk setiap agen.

Overhead platform: Untuk mendistribusikan biaya bersama hub keamanan dan tata kelola pusat, gunakan model alokasi yang sesuai dengan kemampuan pelacakan dan pola penggunaan Anda. Sebaiknya gunakan salah satu model alokasi biaya berikut:

  • Alokasi pembagian yang sama: Model pembagian yang sama mengalokasikan biaya bersama secara merata di semua tenant. Gunakan model ini saat platform adalah utilitas dasar atau saat overhead pelacakan terperinci lebih besar daripada manfaat biaya.
  • Alokasi proporsional: Model proporsional, atau proses penagihan balik, mengalokasikan biaya bersama berdasarkan proporsi biaya langsung yang dikeluarkan setiap tenant. Gunakan model ini saat konsumsi tenant sangat bervariasi dan Anda memiliki telemetri yang andal, seperti label Resource Manager dan parsing log, untuk mengatribusikan biaya secara akurat.
  • Alokasi tetap: Model tetap, atau bertingkat, mengalokasikan biaya bersama berdasarkan koefisien yang ditentukan bisnis. Gunakan model ini saat tenant memerlukan perjanjian tingkat layanan (SLA) yang berbeda. Alokasi model tetap memungkinkan Anda mengenakan tarif tetap untuk kemampuan khusus premium dibandingkan kemampuan bersama standar.

Untuk mengetahui informasi selengkapnya tentang cara mengalokasikan biaya layanan bersama, lihat Cloud FinOps: Alokasi biaya layanan bersama.

Pengelolaan biaya terpusat: Untuk melacak secara akurat total biaya kepemilikan (TCO) sistem AI agentik Anda dan mengatribusikan biaya ke setiap unit bisnis, gunakan label dan data ekspor Penagihan Cloud. Untuk mengetahui informasi selengkapnya tentang cara menggunakan label untuk meningkatkan kesadaran biaya, lihat Mendorong budaya kesadaran biaya.

Untuk memperkirakan biaya resource Google Cloud , gunakan Kalkulator HargaGoogle Cloud .

Untuk prinsip dan rekomendasi pengoptimalan biaya yang khusus untuk workload AI dan ML, lihat Perspektif AI dan ML: Pengoptimalan biaya dalam Well-Architected Framework.

Deployment

Untuk men-deploy arsitektur referensi ini, gunakan contoh multi-tenant agentic AI Terraform yang tersedia di GitHub.

Langkah berikutnya

Kontributor

Penulis:

Kontributor lainnya: