AlloyDB Hadirkan Arsitektur Database untuk Era AI Agent

Perkembangan artificial intelligence (AI) memasuki fase baru. Jika sebelumnya AI banyak digunakan untuk menjawab pertanyaan, membuat konten, menganalisis data, atau membantu pekerjaan manusia, kini muncul sistem AI yang dapat bertindak lebih mandiri. Sistem semacam ini dikenal sebagai AI agent atau agen AI.

Agen AI tidak hanya menghasilkan jawaban berdasarkan instruksi pengguna. Agen dapat menjalankan serangkaian langkah untuk mencapai tujuan tertentu, menggunakan berbagai alat, mengambil informasi dari database, melakukan pencarian, menganalisis hasil, lalu mengambil tindakan berikutnya.

Perubahan tersebut membawa tantangan baru bagi infrastruktur teknologi perusahaan, terutama database.

Selama puluhan tahun, database dirancang dengan prinsip bahwa workload atau beban kerja dapat diperkirakan dan dikendalikan. Sistem produksi memiliki kapasitas tertentu, sementara kebutuhan tambahan biasanya ditangani melalui replica, cache, server tambahan, atau peningkatan kapasitas infrastruktur.

Namun, karakter workload agen AI berbeda.

Agen dapat muncul dalam jumlah besar secara tiba-tiba. Dalam satu skenario, ribuan agen dapat membutuhkan akses ke database yang sama dalam waktu bersamaan, kemudian berhenti bekerja beberapa detik atau menit setelah tugas selesai.

Pertanyaannya kemudian menjadi lebih kompleks: bagaimana memberikan agen AI akses terhadap data perusahaan secara real-time tanpa membuat database produksi mengalami gangguan?

Inilah persoalan yang mendorong lahirnya konsep arsitektur database agentic.

Mengapa Database Harus Berubah di Era AI Agent?

Database merupakan tempat penyimpanan data penting perusahaan. Di dalamnya terdapat informasi transaksi, pelanggan, inventaris, keuangan, operasional, hingga berbagai data yang menjadi dasar pengambilan keputusan. Dalam lingkungan perusahaan, database utama sering kali berfungsi sebagai system of record, yaitu sumber utama yang dianggap sebagai data paling benar dan paling mutakhir.

Karena itu, memberikan akses langsung kepada agen AI bukan perkara sederhana. Agen dapat menghasilkan workload yang sulit diprediksi. Jika ribuan agen secara bersamaan melakukan query terhadap database produksi, sumber daya komputasi, storage, dan jaringan dapat mengalami tekanan.

Masalahnya bukan hanya apakah database mampu menerima query tersebut. Persoalan yang lebih penting adalah apakah workload agen dapat dijalankan tanpa mengganggu sistem yang digunakan untuk menjalankan bisnis. Selama ini, berbagai arsitektur database telah dikembangkan untuk menjawab persoalan skalabilitas. Namun, masing-masing memiliki batasan.

Beberapa pendekatan mampu memberikan isolasi, tetapi sulit meningkatkan kapasitas dengan cepat. Pendekatan lain dapat meningkatkan komputasi secara cepat, tetapi storage masih menjadi bottleneck. Ada pula yang menggunakan cache untuk mempercepat akses, tetapi mengalami penurunan performa ketika data yang dibutuhkan tidak tersedia di cache.

Dalam konteks workload tradisional, kompromi tersebut masih dapat diterima. Namun, kebutuhan agen AI membuat standar tersebut berubah.

Tiga Tantangan Utama: Skala, Latensi, dan Isolasi

Arsitektur database untuk agen AI pada dasarnya harus menyelesaikan tiga persoalan utama, yaitu scale, latency, dan isolation atau skala, latensi, dan isolasi. Ketiganya saling berkaitan.

• Skala
  Agen AI dapat menghasilkan workload dalam jumlah besar secara tiba-tiba. Database yang melayani aplikasi konvensional mungkin membutuhkan 10 atau 20 server secara stabil. Sebaliknya, workload agen dapat tiba-tiba membutuhkan ratusan atau ribuan node, kemudian kembali turun setelah pekerjaan selesai. Karena itu, database agentic harus mampu:

  • meningkatkan jumlah node dalam hitungan detik;
  • menangani ribuan node;
  • melayani workload dalam waktu singkat;
  • mengurangi kembali kapasitas ketika pekerjaan selesai;
  • tidak mengharuskan perusahaan menyediakan seluruh kapasitas tersebut sejak awal.

  Inilah yang disebut sebagai elastic scaling. Dengan model seperti ini, perusahaan tidak perlu membayar atau menyediakan ribuan node secara permanen hanya karena sewaktu-waktu mungkin ada lonjakan workload.

• Latensi
  Agen AI tidak hanya membutuhkan data dalam jumlah besar. Agen juga membutuhkan data dengan cepat. Dalam proses reasoning, agen dapat melakukan serangkaian query. Hasil query pertama dapat menentukan query berikutnya, lalu hasil berikutnya menentukan langkah selanjutnya. Artinya, keterlambatan pada satu tahap dapat memengaruhi seluruh proses.

  Karena itu, akses database untuk agen membutuhkan latensi yang rendah dan konsisten. Dalam arsitektur yang dibahas, targetnya adalah sub-millisecond I/O, atau waktu akses input/output kurang dari satu milidetik.Masalah muncul ketika sistem menggunakan cache.

  Cache memang dapat membuat data yang sering digunakan tersedia dengan cepat. Namun, ketika data yang dibutuhkan tidak terdapat dalam cache atau terjadi cache miss, permintaan harus diteruskan ke storage yang lebih lambat.

  Jika setiap cache miss menyebabkan lonjakan latensi, performa agen menjadi tidak konsisten. Untuk workload agentic, kondisi seperti ini dapat menjadi masalah serius karena proses reasoning membutuhkan akses data yang cepat pada setiap langkah.

• Isolasi
  Persoalan ketiga adalah isolasi. Agen harus dapat mengakses data produksi, tetapi workload agen seharusnya tidak menggunakan sumber daya fisik yang sama dengan workload produksi.

  Mengapa?

  Karena jika dua workload menggunakan sumber daya yang sama, keduanya memiliki shared fate. Ketika workload agen meningkat dan menghabiskan kapasitas storage atau jaringan, aplikasi produksi dapat ikut terdampak.

  Idealnya, agen dapat membaca data produksi yang paling mutakhir tanpa harus berbagi komponen database dengan sistem utama. Dengan kata lain, data boleh dibagikan, tetapi sumber daya yang menjalankan workload tidak harus dibagikan.

Tiga Prinsip Dasar Database Agentic

Berdasarkan kebutuhan tersebut, arsitektur database agentic harus dibangun berdasarkan tiga prinsip fundamental.

• Pertama, isolasi sejak awal
  Agen harus dapat membaca data produksi dengan tingkat kesegaran kurang dari satu detik. Namun, jalur data yang digunakan agen harus terpisah dari cluster utama. Pemisahan ini tidak cukup hanya dengan menetapkan kuota. Isolasi harus diterapkan hingga tingkat fisik, termasuk storage.Tujuannya sederhana: ketika terjadi lonjakan aktivitas agen, workload produksi tetap berjalan seperti biasa.

• Kedua, latensi di bawah satu milidetik
  Database agentic harus mempertahankan performa I/O yang sangat rendah, termasuk ketika permintaan harus mengambil data dari storage remote. Dengan demikian, cache bukan satu-satunya mekanisme yang menentukan apakah akses data akan cepat atau lambat.

• Ketiga, skala dari nol hingga ribuan node
  Pool komputasi agen harus dapat berkembang dari nol hingga ribuan node sesuai kebutuhan. Ketika agen selesai bekerja, node tersebut harus dapat dihentikan kembali. Model ini berbeda dari pendekatan tradisional yang mengharuskan perusahaan menyediakan kapasitas berdasarkan perkiraan kebutuhan. Pada workload agen, kebutuhan dapat berubah terlalu cepat untuk diprediksi secara akurat.

Memenuhi satu atau dua prinsip saja belum cukup. Database mungkin memiliki isolasi yang sangat baik, tetapi jika membutuhkan waktu berjam-jam untuk menyediakan replica baru, sistem tersebut tidak cocok untuk workload agen yang muncul dalam hitungan detik.

Sebaliknya, database dapat menambahkan node dengan cepat, tetapi jika semua node menggunakan storage yang sama dengan sistem produksi, workload agen tetap dapat mengganggu aplikasi utama. Begitu pula dengan sistem yang memiliki performa sangat cepat tetapi hanya mampu bekerja dengan kapasitas yang telah disediakan sebelumnya.

Karena itu, arsitektur agentic harus memenuhi ketiganya secara bersamaan. Jika berhasil, perusahaan mendapatkan tiga keuntungan utama.

• Pertama, tidak ada kegagalan yang saling berkorelasi. Workload agen tidak memiliki jalur langsung untuk mengganggu sistem produksi.
• Kedua, perusahaan tidak perlu menebak kapasitas. Resource dapat ditambahkan ketika dibutuhkan dan dilepaskan ketika tidak lagi digunakan.
• Ketiga, agen memperoleh kemampuan database secara penuh. Agen tidak hanya membaca salinan data sederhana, tetapi dapat memanfaatkan SQL, indeks, vector search, full-text search, dan spatial search untuk mendukung proses reasoning.

Mengenal Arsitektur Agentic AlloyDB

Salah satu contoh pendekatan tersebut adalah arsitektur agentic pada AlloyDB. Menurut Google Cloud, AlloyDB dirancang untuk memenuhi ketiga prinsip tersebut dengan menggabungkan storage, jaringan, komputasi, dan database dalam satu arsitektur.

Konsep utamanya adalah memisahkan workload agen dari cluster produksi, tetapi tetap memberikan akses terhadap data yang sama. Cluster produksi tetap berjalan pada infrastruktur khusus yang telah disediakan.

Sementara itu, agen terhubung melalui Model Context Protocol (MCP) ke pool node AlloyDB yang bersifat independen dan sementara. Node tersebut menggunakan microVM, yaitu lingkungan virtualisasi ringan yang memberikan isolasi bagi workload. 

Apa Itu Colossus?
Colossus merupakan sistem penyimpanan terdistribusi Google yang dirancang untuk skala sangat besar. Colossus menjadi fondasi berbagai layanan Google, termasuk Search, YouTube, Gmail, Google Drive, Spanner, dan Bigtable.

Sistem ini dirancang untuk menangani storage dalam skala exabyte dan dapat melibatkan puluhan ribu mesin dalam satu cluster. Dalam arsitektur AlloyDB agentic, Colossus memiliki peran penting karena menyediakan akses data dengan latensi rendah dan throughput tinggi.

Salah satu karakteristik yang ditekankan adalah kemampuan melakukan pembacaan langsung ke lokasi data. Ketika database node membuka stream Colossus, sistem menentukan lokasi fisik data. Setelah proses otorisasi dan resolusi metadata dilakukan, pembacaan berikutnya dapat langsung menuju disk yang menyimpan data.

Dengan pendekatan tersebut, sistem tidak harus mengandalkan cache perantara untuk setiap permintaan.

Mengapa Storage Sangat Penting?
Storage sering menjadi bagian yang terlupakan ketika membicarakan skalabilitas database. Menambah server komputasi memang dapat meningkatkan kemampuan memproses query. Namun, jika storage tidak mampu menyediakan data dengan kecepatan yang sama, tambahan server justru tidak banyak membantu.

Inilah alasan arsitektur agentic tidak hanya membutuhkan komputasi elastis. I/O juga harus elastis. Jika seribu node komputasi tiba-tiba aktif, storage harus mampu menangani peningkatan permintaan tersebut. Colossus disebut mampu menyediakan throughput agregat hingga 15 TB/s dan hingga 20 juta query per detik untuk satu database AlloyDB.

Angka tersebut menunjukkan bahwa storage harus diperlakukan sebagai bagian penting dari desain skalabilitas, bukan sekadar tempat menyimpan data.

Jaringan Juga Menjadi Fondasi
Selain storage dan komputasi, jaringan merupakan bagian penting dalam arsitektur database agentic. Dalam arsitektur AlloyDB, jaringan tersebut menggunakan Jupiter, fabric jaringan data center Google.

Menurut Google Cloud satu fabric Jupiter menghubungkan lebih dari 100.000 server dengan bandwidth bisection hingga 13 petabit per detik. Tujuan penggunaan jaringan berkapasitas besar adalah memastikan node agen dapat ditempatkan secara fleksibel tanpa mengalami bottleneck ketika harus mengakses storage.

Bayangkan ribuan node agen aktif secara bersamaan.

Jika jaringan tidak mampu membawa data dari storage ke node komputasi, penambahan node justru tidak menghasilkan peningkatan performa yang sebanding. Karena itu, jaringan harus dirancang agar mampu mengikuti pertumbuhan workload.

Compute Elastis untuk Agen AI
Pada lapisan komputasi, agen menggunakan pool AlloyDB. Setiap node agen memiliki akses read-only terhadap kondisi database terbaru. Node tersebut menjalankan AlloyDB for PostgreSQL di dalam microVM sehingga workload agen dapat diisolasi dari sistem produksi maupun node agen lainnya.

Hal yang menarik adalah sifat sementara node tersebut. Node hanya disediakan ketika dibutuhkan. Setelah agen selesai melakukan pekerjaannya, node dapat dihentikan kembali. Pendekatan tersebut memungkinkan model zero-to-thousands, yaitu kapasitas dapat dimulai dari nol kemudian meningkat hingga ribuan node.

Ketika workload selesai, kapasitas kembali turun menuju nol. Konsep tersebut sangat cocok dengan karakter workload agentic yang tidak stabil dan sulit diprediksi.

Mengapa Replica Tradisional Tidak Cukup?
Salah satu cara umum meningkatkan kemampuan membaca database adalah menggunakan read replica. Dalam pendekatan ini, database utama mengirimkan log perubahan ke database replica.

Setiap replica memiliki storage sendiri. Keuntungan pendekatan ini adalah isolasi. Replica tidak harus berbagi storage fisik dengan database utama sehingga workload pembacaan dapat dipisahkan. Latensinya juga dapat rendah karena replica menggunakan storage khusus.

Namun, pendekatan tersebut memiliki kelemahan besar ketika digunakan untuk workload agen. Ketika membutuhkan replica baru, sistem harus menyediakan infrastruktur dan mengisi data ke storage replica. Jika datanya mencapai ratusan gigabyte atau terabyte, proses tersebut membutuhkan waktu yang cukup lama.

Padahal, agen AI dapat membutuhkan kapasitas tambahan hanya dalam hitungan detik. Artinya, replica tradisional memiliki masalah pada skala. Selain itu, replica yang telah disediakan tetap menggunakan resource meskipun workload agen sudah selesai.

Masalah Shared Storage
Pendekatan berikutnya menggunakan shared storage. Pada model ini, node komputasi dapat ditambah dengan cepat karena tidak perlu menyalin seluruh data. Namun, storage menjadi sumber daya bersama.

Jika agen dan sistem produksi menggunakan storage server yang sama, keduanya bersaing mendapatkan bandwidth I/O. Saat aktivitas agen meningkat tajam, storage dapat mencapai kapasitas maksimum.

Akibatnya, sistem produksi dapat ikut mengalami throttling atau penurunan performa. Pendekatan ini mungkin cepat dalam menambah node komputasi, tetapi tidak memberikan isolasi yang benar-benar dibutuhkan workload agen.

Bagaimana dengan Object Storage?
Object storage menawarkan skalabilitas dan efisiensi yang sangat menarik. Namun, object storage tradisional tidak dirancang untuk memberikan latensi serendah storage database pada setiap random read.

Dilansir dari situs Google Cloud, random read dari object storage dapat membutuhkan waktu puluhan milidetik. Karena itu, beberapa arsitektur menggunakan block server atau cache di depan object storage. Data yang sering digunakan ditempatkan pada lapisan tersebut agar dapat diakses lebih cepat.

Masalah muncul ketika data yang diminta tidak berada di cache. Terjadi cache miss dan permintaan harus diteruskan ke object storage.

Akibatnya, latensi dapat melonjak secara signifikan.

Untuk analitik dalam skala besar, pendekatan ini tetap dapat bermanfaat. Namun, agen AI memiliki kebutuhan berbeda. Agen sering kali melakukan retrieval berulang sebagai bagian dari proses reasoning. Jika agen tidak dapat memanfaatkan indeks, point lookup, atau vector search, sistem mungkin harus melakukan table scan yang lebih berat. Hal tersebut dapat meningkatkan latensi dan memperlambat proses reasoning.

Pendekatan AlloyDB: Berbagi Data, Bukan Infrastruktur
Di sinilah konsep utama arsitektur agentic AlloyDB menjadi menarik. Alih-alih memisahkan data sepenuhnya dari agen, sistem memungkinkan agen membaca data produksi secara langsung.

Namun, agen tidak harus menggunakan komponen infrastruktur yang sama dengan cluster produksi. Konsep sederhananya dapat diringkas menjadi:

• Data dibagikan, tetapi infrastrukturnya tidak.
• Cluster utama tetap menjalankan workload transaksi.

Sementara itu, agen bekerja pada node independen yang dapat dibuat dan dihentikan sesuai kebutuhan. Node agen membaca data dari segmen Colossus yang terpisah.

Dengan demikian, perusahaan dapat memberikan agen akses terhadap enterprise truth, tetapi tetap menjaga sistem utama.

Dampak terhadap Pengembangan AI Agent

Jika agen memiliki akses terhadap database dengan kemampuan penuh, agen tidak perlu selalu menggunakan data yang sudah diekspor ke sistem lain. Agen dapat mengakses data operasional yang masih baru.

Misalnya, sebuah agen yang membantu analisis bisnis dapat bekerja menggunakan data transaksi terbaru tanpa harus menunggu proses ekstraksi dan pemuatan data ke sistem lain. Dalam arsitektur yang dibahas, agen juga dapat menggunakan berbagai kemampuan PostgreSQL, termasuk SQL, indeks, pencarian vektor, full-text search, spatial search, dan berbagai mekanisme query lainnya.

Hal tersebut penting karena reasoning agen tidak hanya membutuhkan data, tetapi juga kemampuan untuk menemukan data yang relevan secara efisien.

Database Agentic Bukan Sekadar Database yang Lebih Besar

Ada kesalahpahaman bahwa database untuk AI agent cukup dibuat lebih besar. Padahal, masalahnya bukan sekadar kapasitas. Database yang memiliki ribuan node tetapi menggunakan storage atau jaringan yang sama dengan sistem produksi belum tentu memberikan isolasi.

Database yang memiliki storage sangat cepat tetapi membutuhkan waktu berjam-jam untuk menambah kapasitas juga tidak cocok untuk workload yang berubah dalam hitungan detik. Begitu pula database yang dapat melakukan scaling dengan cepat tetapi mengalami cache miss dengan latensi tinggi.

Karena itu, desain database agentic harus mempertimbangkan seluruh stack secara bersamaan. Mulai dari:

• storage, untuk menyediakan data dengan cepat;
• network, untuk menghubungkan node dan storage tanpa bottleneck;
• compute, untuk menyediakan kapasitas sesuai kebutuhan;
• database engine, agar agen tetap dapat menggunakan kemampuan query secara penuh;
• isolasi, agar workload agen tidak mengganggu produksi.

Tantangan Baru dalam Era Agentic AI

Perubahan ini juga menunjukkan bahwa infrastruktur database memasuki fase baru. Selama beberapa dekade, fokus utama database adalah konsistensi, ketersediaan, performa, dan skalabilitas.

Kini, ada dimensi tambahan: kemampuan menghadapi workload AI yang sangat dinamis. Agen tidak selalu bekerja dalam pola yang sama. Jumlah agen dapat berubah secara drastis. Jenis query dapat berubah. Durasi pekerjaan dapat berubah. Bahkan kebutuhan komputasi dapat berubah selama proses berlangsung.

Karena itu, arsitektur yang mengharuskan perusahaan memperkirakan kapasitas jauh sebelumnya akan semakin sulit memenuhi kebutuhan tersebut.

Kesimpulan

Era agentic AI membawa perubahan besar terhadap cara database dirancang. Agen AI membutuhkan akses terhadap data yang cepat, segar, lengkap, dan tersedia dalam skala besar. Namun, kebutuhan tersebut tidak boleh membuat sistem produksi perusahaan menjadi tidak stabil.

Dari pembahasan tersebut terlihat bahwa terdapat tiga prinsip utama yang harus dipenuhi secara bersamaan: isolasi, latensi rendah, dan skala elastis. Isolasi memastikan workload agen tidak memiliki shared fate dengan sistem produksi. Latensi rendah memastikan agen dapat mengambil data dengan cepat pada setiap tahapan reasoning.

Sementara itu, skala elastis memungkinkan kapasitas meningkat dari nol hingga ribuan node ketika dibutuhkan dan kembali turun setelah pekerjaan selesai. Arsitektur agentic AlloyDB mencoba menjawab persoalan tersebut dengan memisahkan workload agen dari cluster produksi, tetapi tetap memberikan akses terhadap data yang sama melalui storage terdistribusi Colossus.

Dalam pendekatan ini, data perusahaan tetap menjadi sumber informasi bersama, tetapi infrastruktur yang menjalankan workload dapat dipisahkan. Konsep tersebut dapat diringkas dalam satu gagasan sederhana: agen boleh menggunakan data yang sama, tetapi tidak harus berbagi risiko dan sumber daya dengan sistem produksi.

Bagi perusahaan yang mulai mengembangkan AI agent, perubahan ini penting untuk dipahami. AI agent bukan sekadar aplikasi baru yang membutuhkan database. Karakter workload-nya dapat memaksa perusahaan memikirkan kembali fondasi database, storage, jaringan, dan komputasi secara keseluruhan.

Pada akhirnya, masa depan database agentic bukan hanya tentang seberapa banyak data yang dapat disimpan atau seberapa cepat sebuah query dapat dijalankan. Yang lebih penting adalah apakah database mampu memberikan data real-time kepada ribuan agen secara cepat dan elastis, sambil menjaga sistem yang menjalankan bisnis tetap aman dan stabil.