Bangun Agen AI yang Menskalakan: Kembangkan hingga 10 Ribu Pengguna dengan Arsitektur yang Didorong Peristiwa

Penskalaan aplikasi AI dari ratusan hingga ribuan pengguna mengungkapkan titik infleksi arsitektur yang kritis. Arsitektur sinkron yang memungkinkan pembuatan prototipe cepat menjadi hambatan yang mencegah pertumbuhan. Bagi startups yang membangun aplikasi AI di AWS, baik menganalisis dokumen, menghasilkan konten, maupun memperkaya data, memproses beban kerja dapat memerlukan waktu beberapa detik atau menit per permintaan. Kalikan itu dengan ratusan pengguna secara bersamaan, dan arsitektur sinkron menghabiskan kumpulan koneksi, melebihi ambang waktu habis, dan memblokir kecepatan deployment.

Artikel ini menguraikan cara menskalakan pemrosesan dokumen AI dari 100 hingga 10.000 pengguna menggunakan arsitektur yang didorong peristiwa di AWS. Pemrosesan Dokumen Cerdas (IDP) berfungsi sebagai contoh utama, meskipun pola-pola ini berlaku untuk setiap beban kerja AI yang memerlukan pemrosesan multilangkah.

Kapan monolit berfungsi (dan kapan monolit tidak berfungsi)

Pada beberapa ratus pengguna, jalur pemrosesan dokumen monolitik seringkali merupakan pilihan yang tepat. Satu instans komputasi menerima pengunggahan dokumen melalui API, memanggil Amazon Textract (layanan machine learning yang secara otomatis mengekstrak teks, tulisan tangan, dan data dari dokumen yang dipindai) untuk mengekstrak data terstruktur, memvalidasi hasil terhadap aturan bisnis, memperkaya data dengan konteks tambahan, dan menulis output final ke basis data. Seluruh alur kerja dijalankan secara sinkron dalam satu siklus permintaan-respons. Untuk startup tahap awal, arsitektur ini memiliki keunggulan yang berarti: secara konseptual sederhana, mudah di-debug, serta memerlukan biaya operasional minimal.

Namun, arsitektur ini membawa asumsi yang menjadi kewajiban dalam skala besar. Pemrosesan sinkron mengasumsikan bahwa setiap langkah selesai cukup cepat untuk menahan koneksi HTTP terbuka. Ini mengasumsikan bahwa lonjakan pengunggahan dokumen tidak akan membebani langkah validasi, yang mungkin intensif CPU. Ini mengasumsikan bahwa kegagalan dalam tahap pengayaan tidak memerlukan pemrosesan ulang seluruh dokumen dari awal. Asumsi ini berlaku pada beberapa ratus pengguna. Pada skala besar, asumsi tersebut mulai goyah.

Titik kritis

Pada 1.000 pengguna, retakan pertama muncul. Ekstraksi textract, yang mungkin memerlukan waktu 2–3 detik per dokumen, mulai membuat backlog selama jam sibuk. Langkah validasi, berjalan dalam proses yang sama, tidak dapat diskalakan secara independen. Jika ekstraksi lambat, validasi menunggu. Jika validasi lambat, pengayaan menunggu. Seluruh jalur menjadi selambat komponen terlambatnya. Waktu koneksi habis meningkat. Pengguna melihat spinner “memproses” yang tidak pernah diselesaikan. Tim rekayasa menambahkan lebih banyak instans, tetapi ini hanya menunda masalah, alih-alih memecahkan hambatan arsitektur.

Dengan 5.000 pengguna, monolit tidak dapat dipertahankan. Kegagalan tunggal dalam langkah pengayaan mengalir mundur, memblokir validasi dan ekstraksi. Tim tidak dapat melakukan deployment pembaruan ke logika validasi tanpa memulai ulang seluruh jalur. Ekstraksi penskalaan secara independen dari validasi tidak mungkin, karena mereka digabungkan dalam basis kode yang sama, berjalan dalam proses yang sama. Dengan 10.000 pengguna, Anda membutuhkan pendekatan yang berbeda.

Beralih ke arsitektur yang didorong peristiwa 

Arsitektur yang didorong peristiwa menyelesaikan kendala ini dengan mengganti panggilan sinkron dengan peristiwa asinkron. Alih-alih satu komponen secara langsung memanggil yang berikutnya, setiap komponen membulikasikan peristiwa ketika menyelesaikan pekerjaannya dan berlangganan peristiwa yang memberi sinyal kapan harus dimulai. API pengunggahan dokumen memublikasikan peristiwa saat dokumen tiba. API pengunggahan dokumen memublikasikan peristiwa saat dokumen tiba. Setiap komponen berikutnya, dari ekstraksi melalui validasi hingga pengayaan, berlangganan peristiwa sebelumnya, melakukan pekerjaannya, dan memublikasikan yang berikutnya.

Pola ini memperkenalkan lapisan tidak langsung: bus peristiwa seperti Amazon EventBridge (layanan nirserver yang menghubungkan aplikasi menggunakan peristiwa) yang berada di antara produsen dan konsumen. Produsen dan konsumen tidak memiliki pengetahuan langsung satu sama lain. Pemisahan ini adalah pergeseran arsitektur yang memungkinkan penskalaan independen, isolasi kegagalan, serta kecepatan deployment.

Mengapa hal ini penting untuk beban kerja AI 

Beban kerja AI mendapat manfaat terutama dari pola ini. Ekstraksi textract mungkin memerlukan waktu 2 detik untuk faktur sederhana dan 30 detik untuk kontrak yang kompleks. Pengayaan Amazon Bedrock mungkin membutuhkan waktu 1 detik untuk klasifikasi dan 10 detik untuk ekstraksi entitas dengan model bahasa besar. Dalam arsitektur sinkron, waktu pemrosesan variabel-variabel ini menciptakan latensi yang tidak dapat diprediksi. Dalam arsitektur yang didorong peristiwa, setiap langkah memproses dengan kecepatannya sendiri, memublikasikan peristiwa setelah selesai. Throughput jalur ditentukan oleh perilaku penskalaan independen dari setiap tahap, tidak dibatasi oleh komponen yang paling lambat. Untuk beban kerja AI yang melonjak, ini juga berarti membayar hanya untuk apa yang Anda gunakan alih-alih menyediakan untuk kapasitas puncak.

Kapan harus melakukan transisi 

Pola ini menjadi penting ketika startup mencapai titik infleksi tertentu: ketika biaya hambatan sinkron (kehilangan pelanggan, waktu rekayasa yang dihabiskan untuk penanganan masalah, ketidakmampuan untuk melakukan deployment pembaruan secara aman) melebihi biaya pengelolaan kompleksitas asinkron. Anda telah mencapai titik ini ketika Anda mulai melihat tanda-tanda ini:

• Kesalahan waktu koneksi habis muncul di log selama jam sibuk
• Satu deployment memerlukan koordinasi perubahan di berbagai tim
• Anda tidak dapat menskalakan langkah pemrosesan individu secara independen
• Pemrosesan yang gagal memerlukan pemrosesan ulang seluruh dokumen dari awal
• Tingkat kesalahan Anda meningkat secara proporsional dengan lalu lintas

Bagi startups tahap awal dengan kurang dari 500 pengguna, arsitektur yang didorong peristiwa seringkali prematur, karena overhead operasional lebih besar daripada manfaatnya. Untuk startups yang berkembang dari 1.000 hingga 10.000 pengguna, ini adalah transisi yang diperlukan.

Pemrosesan dokumen yang didorong peristiwa dalam praktik 

Pertimbangkan bagaimana pola ini berlaku untuk IDP. Sebuah startup fintech yang membangun platform analisis kontrak untuk teknologi hukum menerima ratusan kontrak setiap hari: NDA, perjanjian kerja, kontrak vendor. Setiap dokumen mengikuti alur kerja multilangkah: pengunggahan, ekstraksi, validasi, pengayaan, dan penyimpanan. Dalam arsitektur yang didorong peristiwa, setiap langkah adalah komponen independen yang dipicu oleh peristiwa.

Alur kerja dimulai saat pengguna mengunggah kontrak ke bucket Amazon Simple Storage Service (S3 ). S3 memublikasikan peristiwa (Object Created) ke bus default EventBridge. Komponen yang berlangganan peristiwa ini mengambil dokumen dan memanggil Textract untuk mengekstrak teks, tabel, dan pasangan kunci-nilai. Textract memproses dokumen secara asinkron (ini penting untuk PDF besar yang mungkin membutuhkan waktu 20–30 detik untuk diproses) serta ketika ekstraksi selesai, komponen memublikasikan peristiwa extraction.complete dengan data yang diekstrak.

Komponen kedua, yang berlangganan extraction.complete, memvalidasi data yang diekstrak terhadap aturan bisnis. Apakah kontrak termasuk klausul yang diperlukan? Apakah tanggal diformat dengan benar? Apakah nama rekanan ada? Jika validasi lulus, komponen memublikasikan peristiwa validation.passed. Jika validasi gagal, komponen memublikasikan peristiwa validation.failed dan merutekan dokumen ke antrean peninjauan manual (antrean Amazon SQS yang dikonsumsi oleh alur kerja human-in-the-loop).

Komponen ketiga, yang berlangganan validation.passed, memperkaya data kontrak menggunakan Bedrock. Komponen ini dapat mengklasifikasikan tipe kontrak (NDA, pekerjaan, vendor), mengekstrak entitas (nama perusahaan, tanggal, jumlah moneter), atau meringkas istilah kunci menggunakan model bahasa besar seperti Claude Anthropic. Inferensi nirserver Bedrock berarti komponen tidak perlu mengelola infrastruktur GPU,komponen hanya memanggil API Bedrock dan menerima output terstruktur. Saat pengayaan selesai, komponen memublikasikan peristiwa enrichment.finished dan menulis data terstruktur final keAmazon DynamoDB(basis data NoSQL nirserver dengan latensi milidetik pada skala apa pun).

Baik itu jalur yang memproses kontrak, catatan medis, maupun laporan keuangan, pola yang didorong peristiwa tetap sama. Hanya layanan AI di setiap langkah yang berubah. Jalur catatan medis mungkin menggunakan Amazon Comprehend Medical untuk ekstraksi entitas alih-alih Bedrock. Jalur laporan keuangan mungkin menggunakan API AnalyzeExpense khusus Textract. Prinsip arsitektural berlaku: setiap langkah memublikasikan peristiwa, menskalakan secara independen, dan dapat di-deploy tanpa memengaruhi tahap lainnya.

Bagi para developer yang membangun jalur ini, AWS telah merilis server Protokol Konteks Model (MCP) yang terintegrasi dengan asisten pengodean AI. Server MCP Nirserver AWS menyediakan keahlian untuk menyederhanakan cara developer membangun aplikasi nirserver secara langsung di lingkungan pengodean, mengurangi waktu yang dihabiskan untuk mencari dokumentasi.

Kasus bisnis untuk pemisahan

Konsekuensi bisnis dari arsitektur ini melampaui keanggunan teknis. Arsitektur yang didorong peristiwa menggeser biaya dari tetap ke variabel. Dalam arsitektur monolitik yang berjalan pada instans komputasi, startup membayar kapasitas 24/7 terlepas dari volume dokumen. Dalam arsitektur yang didorong peristiwa menggunakan AWS Lambda, startup hanya membayar untuk penggunaan komputasi aktual berdasarkan jumlah pelaksanaan, durasi, dan memori yang dialokasikan. Untuk beban kerja dengan lalu lintas variabel, memproses 50 dokumen pada pukul 2.00 dan 500 dokumen pada pukul 14.00, ini dapat mengurangi biaya infrastruktur secara signifikan.

Ketahanan meningkat melalui isolasi kegagalan. Dalam jalur monolitik, bug di logika validasi dapat merusak seluruh proses, memblokir ekstraksi dan pengayaan. Namun, di jalur yang didorong peristiwa, kegagalan validasi hanya memengaruhi tahap validasi. Ekstraksi terus memproses dokumen baru, dan pengayaan terus memproses dokumen yang divalidasi. Peristiwa yang gagal dapat dirutekan ke antrean surat mati untuk analisis nanti, serta tim dapat melakukan deployment perbaikan ke komponen validasi tanpa memulai ulang seluruh jalur.

Kecepatan deployment meningkat karena setiap komponen dapat di-deploy secara independen. Tim dapat memperbarui logika pengayaan Bedrock, mungkin beralih dari Claude Sonnet ke Claude Opus untuk akurasi yang lebih tinggi, tanpa menyentuh kode ekstraksi atau validasi. Ini mengurangi risiko deployment dan memungkinkan tim untuk melakukan iterasi lebih cepat. Bagi startups waktu untuk memasarkan merupakan keunggulan kompetitif, ini penting.

Memulai 

Transisi dari arsitektur monolitik ke yang didorong peristiwa tidak memerlukan penulisan ulang seluruh aplikasi. Mulai memisahkan satu alur kerja asinkron, seperti ekstraksi dokumen, dari sisa jalur. Konfigurasikan S3 untuk memublikasikan peristiwa ke EventBridge saat dokumen diunggah. Buat fungsi Lambda yang berlangganan peristiwa S3 dan memanggil Textract. Fungsi Lambda kemudian memublikasikan peristiwa extraction.complete setelah selesai. Jaga agar sisa jalur tetap sinkron. Kemudian ukur dampaknya pada latensi pemrosesan dan kecepatan deployment. Metrik kunci yang harus dilacak termasuk latensi P99, tingkat kesalahan, biaya per dokumen, serta frekuensi deployment. Jika manfaatnya membenarkan kompleksitas operasional, perluas pola untuk validasi dan pengayaan.

AWS menyediakan panduan komprehensif untuk membangun arsitektur yang didorong peristiwa, termasuk arsitektur referensi untuk IDP dan praktik terbaik dari Lensa Aplikasi Nirserver AWS Well-Architected. Bagi startups yang membangun AI di AWS, pola-pola ini tidak teoretis. Pola tersebut merupakan pendekatan yang terbukti digunakan oleh perusahaan yang berkembang dari ratusan hingga jutaan pengguna.

Siap untuk mulai membangun aplikasi AI yang didorong peristiwa di AWS? AWS Activate menyediakan kredit untuk menutupi biaya Lambda, EventBridge, Bedrock, dan layanan lain yang tercakup dalam artikel ini. Para pendiri di komunitas AWS Activate juga mendapat manfaat dari sumber daya spesialis, dukungan teknis, bimbingan bisnis, serta relasi langsung dengan komunitas startup global. Bergabunglah sekarang dan mulai membangun AI tingkat produksi di AWS.