Arsitektur referensi obrolan Dasar Azure AI Foundry di zona pendaratan Azure
Artikel ini adalah bagian dari seri yang dibangun di arsitektur referensi obrolan Baseline AI Foundry. Tinjau arsitektur dasar sehingga Anda dapat mengidentifikasi penyesuaian yang diperlukan sebelum menyebarkannya di langganan zona pendaratan aplikasi Azure.
Artikel ini menjelaskan arsitektur beban kerja AI generatif yang menyebarkan aplikasi obrolan dasar tetapi menggunakan sumber daya yang berada di luar cakupan tim beban kerja. Tim platform mengelola sumber daya secara terpusat, dan beberapa tim beban kerja menggunakannya. Sumber daya bersama mencakup sumber daya jaringan untuk koneksi lintas tempat, sistem manajemen akses identitas, dan kebijakan. Panduan ini membantu organisasi yang menggunakan zona pendaratan Azure mempertahankan tata kelola yang konsisten dan efisiensi biaya.
Azure AI Foundry menggunakan akun dan proyek untuk mengatur pengembangan dan penyebaran AI. Misalnya, implementasi zona pendaratan mungkin menggunakan akun sebagai sumber daya terpusat di tingkat grup bisnis dan proyek sebagai sumber daya yang didelegasikan untuk setiap beban kerja dalam grup bisnis tersebut. Karena faktor organisasi sumber daya, dan batasan alokasi biaya, kami tidak merekomendasikan topologi ini, dan artikel ini tidak memberikan panduan tentang hal itu. Sebaliknya, arsitektur ini memperlakukan beban kerja sebagai pemilik instans Azure AI Foundry, yang merupakan pendekatan yang direkomendasikan.
Sebagai pemilik beban kerja, Anda mendelegasikan manajemen sumber daya bersama ke tim platform sehingga Anda dapat fokus pada upaya pengembangan beban kerja. Artikel ini menyajikan perspektif tim beban kerja dan menentukan rekomendasi untuk tim platform.
Penting
Apa itu zona pendaratan Azure?
Zona pendaratan Azure membagi jejak cloud organisasi Anda menjadi dua area utama:
Zona pendaratan aplikasi adalah langganan Azure tempat beban kerja berjalan. Zona pendaratan aplikasi terhubung ke sumber daya platform bersama organisasi Anda. Koneksi tersebut menyediakan zona pendaratan dengan akses ke infrastruktur yang mendukung beban kerja, seperti jaringan, manajemen akses identitas, kebijakan, dan pemantauan.
Zona pendaratan platform adalah kumpulan berbagai langganan yang dapat dikelola oleh beberapa tim platform. Setiap langganan memiliki fungsi tertentu. Misalnya, langganan konektivitas menyediakan resolusi Sistem Nama Domain (DNS) terpusat, konektivitas lintas lokasi, dan appliance virtual jaringan (NVA) untuk tim platform.
Untuk membantu Anda menerapkan arsitektur ini, pahami zona pendaratan Azure, prinsip desainnya, dan area desainnya.
Tata letak artikel
| Arsitektur | Keputusan desain | Pendekatan Azure Well-Architected Framework |
|---|---|---|
| ▪ Diagram arsitektur ▪ Sumber daya beban kerja ▪ Sumber daya federasi |
▪ Penyiapan langganan ▪ Jaringan ▪ Akses ilmuwan data ▪ Memantau sumber daya ▪ Tata kelola organisasi ▪ Mengubah manajemen |
▪ Keandalan ▪ Keamanan ▪ Pengoptimalan Biaya ▪ Keunggulan Operasional ▪ Efisiensi Performa |
Petunjuk / Saran
Implementasi referensi garis besar obrolan Azure AI Foundry Agent Service menunjukkan praktik terbaik yang dijelaskan dalam artikel ini. Tinjau dan coba sumber daya penyebaran ini sebelum Anda memilih dan menerapkan keputusan desain Anda.
Arsitektur
Unduh file Visio dari arsitektur ini.
Komponen
Semua arsitektur zona pendaratan Azure memisahkan kepemilikan antara tim platform dan tim beban kerja, yang disebut sebagai demokratisasi langganan. Arsitek aplikasi, ilmuwan data, dan tim DevOps harus memahami divisi ini dengan jelas untuk menentukan apa yang termasuk dalam pengaruh atau kontrol langsung mereka dan apa yang tidak.
Seperti kebanyakan implementasi zona pendaratan aplikasi, tim beban kerja terutama mengelola konfigurasi, penyebaran, dan pengawasan komponen beban kerja, termasuk layanan AI dalam arsitektur ini.
Sumber daya milik tim beban kerja
Sumber daya berikut sebagian besar tidak berubah dari arsitektur garis besar.
Akun dan proyek Azure AI Foundry memungkinkan tim beban kerja untuk menghosting model AI generatif sebagai layanan, menerapkan keamanan konten, dan membangun koneksi khusus beban kerja ke sumber pengetahuan dan alat.
Jika Pusat Keunggulan AI organisasi Anda membatasi akses ke penyebaran model AI, tim beban kerja mungkin tidak menghosting model dalam proyek dan akun. Sebaliknya, mereka mungkin perlu menggunakan sumber daya AI terpusat. Dalam skenario ini, semua konsumsi model biasanya mengalir melalui gateway yang disediakan tim platform AI Anda.
Artikel ini mengasumsikan bahwa model AI generatif dalam skenario ini adalah sumber daya yang dimiliki beban kerja. Jika tidak, host model, atau gateway ke model, menjadi dependensi beban kerja. Tim platform harus mempertahankan konektivitas jaringan yang andal ke API.
Foundry Agent Service memperlakukan dependensi model dengan cara tertentu, sehingga tantangan dapat terjadi ketika Anda menggunakan model yang dihosting secara terpusat. Anda mungkin perlu menggunakan orkestrator alternatif.
Foundry Agent Service menyediakan lapisan orkestrasi untuk interaksi obrolan. Ini menghosting dan mengelola agen obrolan yang memproses permintaan pengguna.
Gunakan penyiapan agen standar dalam arsitektur ini. Hubungkan agen Anda ke subnet khusus di jaringan virtual spoke Anda, dan rutekan lalu lintas keluar melalui langganan konektivitas Anda.
Tim beban kerja menyediakan sumber daya Azure khusus untuk status agen, riwayat obrolan, dan penyimpanan file. Sumber daya ini adalah Azure Cosmos DB untuk NoSQL, Azure Storage, dan Azure AI Search. Instans Foundry Agent Service Anda mengelola sumber daya ini dan datanya secara eksklusif. Komponen aplikasi lain dalam beban kerja Anda atau beban kerja lain di organisasi Anda tidak boleh menggunakannya.
Azure App Service menghosting aplikasi web yang berisi antarmuka pengguna obrolan (UI). App Service memiliki tiga instans di zona Azure yang berbeda.
Akun Azure Storage menghosting kode aplikasi web sebagai file ZIP, yang dipasang dalam App Service.
Pencarian AI mengambil data terindeks yang relevan untuk kueri pengguna aplikasi. AI Search berfungsi sebagai penyimpanan pengetahuan beban kerja untuk pola Retrieval Augmented Generation. Pola ini mengekstrak kueri yang sesuai dari permintaan, mengkueri Pencarian AI, dan menggunakan hasilnya sebagai data dasar untuk model fondasi AI generatif.
Azure Application Gateway berfungsi sebagai proksi terbalik untuk merutekan permintaan pengguna ke UI obrolan yang dihosting di App Service. SKU yang dipilih juga menghosting firewall aplikasi web Azure untuk melindungi aplikasi front-end dari lalu lintas yang berpotensi berbahaya.
Azure Key Vault menyimpan sertifikat Keamanan Lapisan Transportasi (TLS) gateway aplikasi.
Azure Monitor, Azure Monitor Logs, dan Application Insights mengumpulkan, menyimpan, dan memvisualisasikan data observabilitas.
Azure Policy menerapkan kebijakan khusus beban kerja untuk membantu mengatur, mengamankan, dan menerapkan kontrol dalam skala besar.
Tim beban kerja juga mempertahankan sumber daya berikut:
Subnet jaringan virtual spoke dan kelompok keamanan jaringan (NSG) pada subnet tersebut mempertahankan segmentasi dan mengontrol arus lalu lintas.
Titik akhir privat mengamankan konektivitas ke solusi platform as a service (PaaS).
Sumber daya milik tim platform
Tim platform memiliki dan memelihara sumber daya terpusat berikut. Arsitektur ini mengasumsikan bahwa sumber daya ini telah disediakan sebelumnya dan memperlakukannya sebagai dependensi.
Azure Firewall di rute jaringan hub , memeriksa, dan membatasi lalu lintas keluar yang berasal dari beban kerja, termasuk lalu lintas agen. Lalu lintas keluar beban kerja masuk ke internet, tujuan lintas tempat, atau ke zona pendaratan aplikasi lainnya.
Ubah dari garis besar: Dalam arsitektur garis besar, tim beban kerja memiliki komponen ini. Dalam arsitektur ini, tim platform mengelolanya di bawah langganan konektivitas.
Azure Bastion di jaringan hub menyediakan akses operasional yang aman ke komponen beban kerja dan memungkinkan akses ke komponen Azure AI Foundry.
Ubah dari garis besar: Dalam arsitektur garis besar, tim beban kerja memiliki komponen ini.
Jaringan virtual spoke adalah tempat beban kerja disebarkan.
Ubah dari garis besar: Dalam arsitektur garis besar, tim beban kerja memiliki jaringan ini.
Rute yang ditentukan pengguna (UDR) memberlakukan penerowongan ke jaringan hub.
Ubah dari garis besar: Dalam arsitektur garis besar, tim beban kerja memiliki jaringan ini.
Batasan tata kelola berbasis Azure Policy dan
DeployIfNotExists(DINE) berlaku untuk langganan beban kerja. Anda dapat menerapkan kebijakan ini di tingkat grup manajemen milik tim platform atau ke langganan beban kerja secara langsung.Perubahan dari garis besar: Kebijakan ini baru dalam arsitektur ini. Tim platform menerapkan kebijakan yang membatasi beban kerja Anda. Beberapa kebijakan mungkin menduplikasi batasan beban kerja yang ada atau memperkenalkan batasan baru.
Zona DNS privat Azure menghosting
Arekaman untuk titik akhir privat. Untuk informasi selengkapnya, lihat Azure Private Link dan integrasi DNS dalam skala besar.Ubah dari garis besar: Dalam arsitektur garis besar, tim beban kerja memiliki jaringan ini. Dalam arsitektur ini, tim platform mengelola komponen ini di bawah langganan konektivitas.
Layanan resolusi DNS mendukung jaringan virtual spoke dan stasiun kerja lintas tempat. Layanan ini biasanya menggunakan Azure Firewall sebagai proksi DNS atau Azure DNS Private Resolver. Dalam arsitektur ini, layanan menyelesaikan catatan DNS titik akhir privat untuk semua permintaan DNS dari spoke. Dns Private Resolver dan ruleset tertaut adalah cara yang direkomendasikan bagi tim platform untuk mengaktifkan persyaratan resolusi arsitektur ini karena karakteristik resolusi DNS dari Foundry Agent Service.
Azure DDoS Protection membantu melindungi alamat IP publik dari serangan terdistribusi.
Ubah dari garis besar: Dalam arsitektur garis besar, tim beban kerja membeli DDoS Protection.
Penting
Zona pendaratan Azure menyediakan beberapa sumber daya sebelumnya sebagai bagian dari langganan zona pendaratan platform. Langganan beban kerja Anda menyediakan sumber daya lain. Banyak sumber daya ini berada di langganan konektivitas, yang juga mencakup Azure ExpressRoute, Azure VPN Gateway, dan DNS Private Resolver. Sumber daya ini menyediakan akses lintas tempat dan resolusi nama. Manajemen sumber daya ini berada di luar cakupan artikel ini.
Penyiapan langganan
Tim beban kerja harus memberi tahu tim platform tentang persyaratan zona pendaratan tertentu untuk menerapkan arsitektur ini. Dan tim platform harus mengkomunikasikan persyaratannya kepada tim beban kerja.
Misalnya, tim beban kerja harus memberikan informasi terperinci tentang ruang jaringan yang diperlukan. Tim platform menggunakan informasi ini untuk mengalokasikan sumber daya yang diperlukan. Tim beban kerja menentukan persyaratan, dan tim platform menetapkan alamat IP yang sesuai dalam jaringan virtual.
Tim platform menetapkan grup manajemen berdasarkan kekritisan bisnis dan kebutuhan teknis beban kerja. Misalnya, jika beban kerja terekspos ke internet, seperti arsitektur ini, tim platform memilih grup manajemen yang sesuai. Untuk membangun tata kelola, tim platform juga mengonfigurasi dan menerapkan grup manajemen. Tim beban kerja harus merancang dan mengoperasikan beban kerja dalam batasan tata kelola ini. Untuk informasi selengkapnya tentang perbedaan grup manajemen yang khas, lihat Menyesuaikan arsitektur zona pendaratan Azure.
Tim platform menyiapkan langganan untuk arsitektur ini. Bagian berikut ini menyediakan panduan tentang penyiapan langganan awal.
Persyaratan dan pemenuhan beban kerja
Tim beban kerja dan tim platform harus berkolaborasi pada detail seperti penetapan grup manajemen, tata kelola Azure Policy, dan penyiapan jaringan. Siapkan daftar periksa persyaratan untuk memulai diskusi dan negosiasi dengan tim platform. Daftar periksa berikut berfungsi sebagai contoh.
| Pertimbangan desain | Persyaratan beban kerja untuk arsitektur ini | |
|---|---|---|
| ☐ | Jumlah jaringan virtual spoke dan ukurannya: Tim platform membuat dan mengonfigurasi jaringan virtual, lalu mengintipnya ke hub regional untuk menunjuknya sebagai spoke. Mereka juga perlu memastikan bahwa jaringan dapat mengakomodasi pertumbuhan beban kerja di masa depan. Untuk melakukan tugas-tugas ini secara efektif, mereka harus mengetahui jumlah spoke yang diperlukan. | Sebarkan semua sumber daya dalam satu jaringan virtual spoke khusus. Minta /22 ruang alamat yang berdampingan untuk mendukung operasi dan skenario skala penuh seperti penyebaran berdampingan. Faktor-faktor berikut menentukan sebagian besar kebutuhan alamat IP: - Persyaratan Application Gateway untuk ukuran subnet (ukuran tetap). - Titik akhir privat dengan alamat IP tunggal untuk layanan PaaS (ukuran tetap). - Ukuran subnet untuk agen build (ukuran tetap). - Foundry Agent Service memerlukan subnet dalam /24 awalan. |
| ☐ | Awalan alamat jaringan virtual: Biasanya, tim platform menetapkan alamat IP berdasarkan konvensi yang ada, menghindari tumpang tindih dengan jaringan yang di-peering, dan ketersediaan dalam sistem manajemen alamat IP (IPAM). | Subnet integrasi agen harus menggunakan awalan alamat yang dimulai dengan 172. atau 192. seperti 192.168.45.1/24. Pembatasan runtime di host kemampuan Foundry Agent Service memberlakukan persyaratan ini. Foundry Agent Service tidak mendukung subnet yang menggunakan 10.. Minta tim platform Anda untuk menyediakan spoke yang memiliki awalan alamat yang valid untuk subnet agen Anda. |
| ☐ | Wilayah penyebaran: Tim platform perlu menyebarkan hub di wilayah yang sama dengan sumber daya beban kerja. | Komunikasikan wilayah yang dipilih untuk beban kerja dan wilayah untuk sumber daya komputasi yang mendasar. Pastikan bahwa wilayah mendukung zona ketersediaan. Azure OpenAI dalam Model Foundry memiliki ketersediaan regional terbatas. |
| ☐ | Jenis, volume, dan pola lalu lintas: Tim platform perlu menentukan persyaratan masuk dan keluar dari sumber daya bersama beban kerja Anda. | Berikan informasi tentang faktor-faktor berikut: - Bagaimana pengguna harus menggunakan beban kerja ini. - Bagaimana beban kerja ini mengonsumsi sumber daya di sekitarnya. - Protokol transportasi yang dikonfigurasi. - Pola lalu lintas dan puncak yang diharapkan dan di luar jam sibuk. Berkomunikasi ketika Anda mengharapkan sejumlah besar koneksi bersamaan ke internet (cerewet) dan ketika Anda mengharapkan beban kerja menghasilkan lalu lintas jaringan minimal (kebisingan latar belakang). |
| ☐ | Konfigurasi firewall: Tim platform perlu menetapkan aturan untuk mengizinkan lalu lintas keluar yang sah. | Bagikan detail tentang lalu lintas keluar dari jaringan spoke, termasuk lalu lintas agen. Membangun agen dan mesin jump box membutuhkan patching OS reguler. Agen mungkin perlu berinteraksi dengan sumber internet grounding, alat, atau agen lain yang dihosting di luar beban kerja. |
| ☐ | Lalu lintas masuk dari peran khusus: Tim platform perlu menyediakan peran yang ditentukan dengan akses jaringan ke beban kerja dan menerapkan segmentasi yang tepat. | Bekerja dengan tim platform untuk menentukan cara terbaik untuk memungkinkan akses resmi untuk peran berikut: - Ilmuwan dan pengembang data yang mengakses portal Azure AI Foundry dari stasiun kerja mereka pada koneksi jaringan perusahaan - Operator yang mengakses lapisan komputasi melalui jump box yang dikelola beban kerja |
| ☐ |
Akses internet publik ke beban kerja: Tim platform menggunakan informasi ini untuk penilaian risiko, yang mendorong beberapa keputusan: - Penempatan beban kerja dalam grup manajemen dengan pagar pembatas yang sesuai - Perlindungan penolakan layanan terdistribusi (DDoS) untuk alamat IP publik yang dilaporkan oleh tim beban kerja - Pengadaan dan manajemen sertifikat TLS |
Beri tahu tim platform tentang profil lalu lintas masuk: - Lalu lintas bersumber internet yang menargetkan alamat IP publik di Application Gateway - Nama domain yang sepenuhnya memenuhi syarat (FQDN) yang terkait dengan alamat IP publik untuk pengadaan sertifikat TLS |
| ☐ | Penggunaan titik akhir privat: Tim platform perlu menyiapkan zona DNS privat Azure untuk titik akhir privat dan memastikan bahwa firewall di jaringan hub melakukan resolusi DNS dengan benar. | Beri tahu tim platform tentang semua sumber daya yang menggunakan titik akhir privat, termasuk sumber daya berikut: - Pencarian AI - Azure Cosmos DB untuk NoSQL - Key Vault - Azure AI Foundry - Akun penyimpanan Pahami bagaimana hub menangani resolusi DNS, dan tentukan tanggung jawab tim beban kerja untuk pengelolaan rekaman zona DNS privat dan penautan set aturan DNS Private Resolver. |
| ☐ |
Sumber daya AI terpusat: Tim platform harus memahami penggunaan model dan platform hosting yang diharapkan. Mereka menggunakan informasi ini untuk membangun jaringan ke sumber daya AI terpusat dalam organisasi Anda. Setiap organisasi mendefinisikan adopsi AI dan rencana tata kelolanya sendiri, dan tim beban kerja harus beroperasi dalam batasan tersebut. |
Beri tahu tim platform tentang AI dan sumber daya pembelajaran mesin yang anda rencanakan untuk digunakan. Arsitektur ini menggunakan Azure AI Foundry, Foundry Agent Service, dan model fondasi generatif yang dihosting di Azure AI Foundry. Pahami dengan jelas layanan AI terpusat mana yang harus Anda gunakan dan bagaimana dependensi tersebut memengaruhi beban kerja Anda. |
Penting
Tim platform harus mengikuti proses penjual langganan yang menggunakan serangkaian pertanyaan terstruktur untuk mengumpulkan informasi dari tim beban kerja. Pertanyaan-pertanyaan ini mungkin bervariasi di seluruh organisasi, tetapi tujuannya adalah untuk mengumpulkan input yang diperlukan untuk menerapkan langganan secara efektif. Untuk informasi selengkapnya, lihat Penjual langganan.
Komputasi
Lapisan orkestrasi dan hosting UI obrolan tetap sama dengan arsitektur garis besar.
Jaringan
Dalam arsitektur garis besar, beban kerja disediakan dalam satu jaringan virtual.
Ubah dari garis besar: Arsitektur ini membagi beban kerja melalui dua jaringan virtual. Satu jaringan menghosting komponen beban kerja. Jaringan lain mengelola konektivitas internet dan hibrid. Tim platform menentukan bagaimana jaringan virtual beban kerja terintegrasi dengan arsitektur jaringan organisasi yang lebih besar, yang biasanya mengikuti topologi hub-spoke.
Unduh file Visio dari arsitektur ini.
Jaringan virtual hub: Jaringan virtual ini berfungsi sebagai hub regional yang berisi layanan terpusat, dan sering dibagikan, yang berkomunikasi dengan sumber daya beban kerja di wilayah yang sama. Hub berada di langganan konektivitas. Tim platform memiliki sumber daya dalam jaringan ini.
Jaringan virtual spoke: Dalam arsitektur ini, jaringan virtual tunggal dari arsitektur garis besar pada dasarnya menjadi jaringan virtual spoke. Tim platform mengintip jaringan spoke ini ke jaringan hub. Mereka memiliki dan mengelola jaringan spoke, termasuk peering dan konfigurasi DNS-nya. Tim beban kerja memiliki sumber daya dalam jaringan ini, termasuk subnetnya. Jaringan ini berisi banyak sumber daya beban kerja.
Karena pembagian manajemen dan kepemilikan ini, tim beban kerja harus mengkomunikasikan persyaratan beban kerja dengan jelas kepada tim platform.
Penting
Untuk tim platform: Jangan langsung melakukan peering jaringan spoke ke jaringan spoke lain, kecuali beban kerja secara khusus memerlukannya. Praktik ini melindungi tujuan segmentasi beban kerja. Tim Anda harus memfasilitasi semua koneksi jaringan virtual transitif. Namun, jika tim zona pendaratan aplikasi secara langsung menghubungkan jaringan mereka dengan menggunakan titik akhir privat yang dikelola sendiri, tim Anda tidak mengelola koneksi tersebut.
Pahami sumber daya beban kerja mana yang dikelola tim eksternal. Misalnya, pahami konektivitas jaringan antara agen obrolan dan database vektor konteks grounding yang dikelola tim lain.
Subnet jaringan virtual
Di jaringan virtual spoke, Anda membuat dan mengalokasikan subnet berdasarkan persyaratan beban kerja. Untuk menyediakan segmentasi, terapkan kontrol yang membatasi lalu lintas ke dalam dan ke luar subnet. Arsitektur ini tidak menambahkan subnet di luar subnet dalam arsitektur garis besar. Namun, arsitektur jaringan tidak lagi memerlukan AzureBastionSubnet subnet atau AzureFirewallSubnet karena tim platform kemungkinan menghosting kemampuan ini dalam langganan mereka.
Anda masih harus menerapkan kontrol jaringan lokal saat menyebarkan beban kerja di zona pendaratan Azure. Organisasi Anda mungkin memberlakukan pembatasan jaringan lebih lanjut untuk melindungi dari eksfiltrasi data dan memastikan visibilitas untuk pusat operasi keamanan pusat dan tim jaringan TI.
Lalu lintas masuk
Arus lalu lintas ingress tetap sama dengan arsitektur garis besar.
Anda mengelola sumber daya yang terkait dengan masuknya internet publik ke dalam beban kerja. Misalnya, dalam arsitektur ini, Application Gateway dan alamat IP publiknya berada di jaringan spoke daripada jaringan hub. Beberapa organisasi menempatkan sumber daya yang menghadap masuk dalam langganan konektivitas dengan menggunakan implementasi jaringan perimeter terpusat (juga dikenal sebagai DMZ, zona demiliterisasi, dan subnet yang disaring). Integrasi dengan topologi spesifik tersebut berada di luar cakupan artikel ini.
Pendekatan alternatif untuk memeriksa lalu lintas masuk
Arsitektur ini tidak menggunakan Azure Firewall untuk memeriksa lalu lintas masuk, tetapi terkadang tata kelola organisasi memerlukannya. Dalam kasus tersebut, tim platform mendukung implementasi untuk menyediakan tim beban kerja dengan lapisan ekstra deteksi dan pencegahan intrusi. Lapisan ini membantu memblokir lalu lintas masuk yang tidak diinginkan. Untuk mendukung topologi ini, arsitektur ini memerlukan lebih banyak konfigurasi UDR. Untuk informasi selengkapnya, lihat Jaringan Zero Trust untuk aplikasi web dengan Azure Firewall dan Application Gateway.
Konfigurasi DNS
Dalam arsitektur garis besar, semua komponen menggunakan Azure DNS secara langsung untuk resolusi DNS.
Ubah dari garis besar: Dalam arsitektur ini, biasanya satu atau beberapa server DNS di hub melakukan resolusi DNS. Ketika jaringan virtual dibuat, properti DNS pada jaringan virtual harus sudah diatur sesuai. Tim beban kerja tidak perlu memahami detail implementasi layanan DNS.
Arsitektur ini mengonfigurasi komponen beban kerja dengan DNS dengan cara berikut.
| Komponen | Konfigurasi DNS |
|---|---|
| Application Gateway | Diwariskan dari jaringan virtual |
| App Service (UI obrolan) | Diwariskan dari jaringan virtual |
| Pencarian AI | Tidak dapat ditimpa, menggunakan Azure DNS |
| Azure AI Foundry | Tidak dapat ditimpa, menggunakan Azure DNS |
| Layanan Agen Pengecoran | Tidak dapat ditimpa, menggunakan Azure DNS |
| Azure Cosmos DB | Tidak dapat ditimpa, menggunakan Azure DNS |
| Jump box | Diwariskan dari jaringan virtual |
| Membangun agen | Diwariskan dari jaringan virtual |
Arsitektur ini tidak mengonfigurasi pengaturan DNS untuk komponen yang tidak memulai komunikasi keluar. Komponen-komponen ini tidak memerlukan resolusi DNS.
Banyak komponen dalam arsitektur ini mengandalkan catatan DNS yang dihosting di server DNS hub untuk menyelesaikan titik akhir privat beban kerja ini. Untuk informasi selengkapnya, lihat Zona DNS privat Azure.
Saat resolusi DNS berbasis hub tidak dimungkinkan, komponen tersebut menghadapi batasan berikut:
Tim platform tidak dapat mencatat permintaan DNS, yang mungkin melanggar persyaratan tim keamanan organisasi.
Mengatasi layanan yang diekspos Private Link di zona pendaratan Anda atau zona pendaratan aplikasi lainnya mungkin tidak mungkin.
Sebaiknya Anda membiasakan diri dengan cara tim platform mengelola DNS. Untuk informasi selengkapnya, lihat Private Link dan integrasi DNS dalam skala besar. Saat Anda menambahkan fitur komponen yang secara langsung bergantung pada Azure DNS, Anda mungkin memperkenalkan kompleksitas dalam topologi DNS yang disediakan platform. Anda dapat mendesain ulang komponen atau menegosiasikan pengecualian untuk meminimalkan kompleksitas.
Lalu lintas egress
Dalam arsitektur garis besar, semua lalu lintas keluar merutekan ke internet melalui Azure Firewall.
Ubah dari garis besar: Dalam arsitektur ini, platform menyediakan UDR yang menunjuk ke instans Azure Firewall yang dihostingnya. Terapkan UDR ini ke subnet yang sama dalam arsitektur garis besar.
Semua lalu lintas yang meninggalkan jaringan virtual spoke, termasuk lalu lintas dari subnet integrasi agen, dialihkan melalui jaringan hub yang di-peering melalui firewall keluar.
Unduh file Visio dari arsitektur ini.
Komunikasi klien timur-barat ke titik akhir privat untuk Key Vault, Azure AI Foundry, dan layanan lainnya tetap sama dengan arsitektur garis besar. Diagram sebelumnya tidak menyertakan jalur tersebut.
Merutekan lalu lintas internet ke firewall
Semua subnet dalam jaringan spoke menyertakan rute yang mengarahkan semua lalu lintas yang terikat internet, atau 0.0.0.0/0 lalu lintas, ke instans Azure Firewall hub.
| Komponen | Mekanisme untuk memaksa lalu lintas internet melalui hub |
|---|---|
| Application Gateway | Tidak ada. Lalu lintas yang terikat internet yang berasal dari layanan ini tidak dapat dipaksa melalui firewall tim platform. |
| App Service (UI obrolan) | Integrasi jaringan virtual regional dan pengaturan vnetRouteAllEnabled diaktifkan. |
| Pencarian AI | Tidak ada. Lalu lintas yang berasal dari layanan ini tidak dapat dipaksa melalui firewall. Arsitektur ini tidak menggunakan keterampilan. |
| Layanan Agen Pengecoran | UDR diterapkan ke subnet snet-agentsEgress. |
| Jump box | UDR diterapkan ke subnet snet-jumpbox. |
| Membangun agen | UDR diterapkan ke subnet snet-agents. |
Arsitektur ini tidak mengonfigurasi penerowongan paksa untuk komponen yang tidak memulai komunikasi keluar.
Untuk komponen atau fitur yang tidak dapat merutekan lalu lintas keluar melalui hub, tim beban kerja Anda harus selaras dengan persyaratan organisasi. Untuk memenuhi persyaratan tersebut, gunakan kontrol kompensasi, desain ulang beban kerja untuk mengecualikan fitur yang tidak didukung, atau meminta pengecualian formal. Anda bertanggung jawab untuk mengurangi eksfiltrasi dan penyalahgunaan data.
Terapkan rute internet yang disediakan platform ke semua subnet, bahkan jika Anda tidak mengharapkan subnet memiliki lalu lintas keluar. Pendekatan ini memastikan bahwa penyebaran tak terduga di subnet tersebut melalui pemfilteran keluar rutin. Untuk subnet yang berisi titik akhir privat, aktifkan kebijakan jaringan untuk mendukung perutean penuh dan kontrol NSG.
Konfigurasi rute ini memastikan bahwa semua koneksi keluar dari App Service, Azure AI Foundry dan proyeknya, dan layanan lain yang berasal dari jaringan virtual beban kerja diperiksa dan dikontrol.
Zona DNS pribadi Azure
Beban kerja yang menggunakan titik akhir privat untuk lalu lintas timur-barat memerlukan rekaman zona DNS di penyedia DNS yang dikonfigurasi. Untuk mendukung Private Link, arsitektur ini bergantung pada banyak rekaman zona DNS untuk layanan seperti Key Vault, Azure AI Foundry, dan Azure Storage.
Ubah dari garis besar: Dalam arsitektur garis besar, tim beban kerja secara langsung mengelola zona DNS privat. Dalam arsitektur ini, tim platform biasanya mempertahankan zona DNS privat. Tim beban kerja harus memahami dengan jelas persyaratan dan harapan tim platform untuk pengelolaan catatan zona DNS privat. Tim platform dapat menggunakan teknologi lain alih-alih catatan zona DNS privat.
Dalam arsitektur ini, tim platform harus menyiapkan DNS untuk titik akhir Azure AI Foundry FQDN API berikut:
privatelink.services.ai.azure.comprivatelink.openai.azure.comprivatelink.cognitiveservices.azure.com
Tim platform juga harus menyiapkan DNS untuk FQDN berikut, yang merupakan dependensi Foundry Agent Service:
privatelink.search.windows.netprivatelink.blob.core.windows.netprivatelink.documents.azure.com
Penting
Resolusi DNS harus berfungsi dengan benar dari dalam virtual spoke sebelum Anda menyebarkan host kemampuan untuk Foundry Agent Service dan selama pengoperasian Foundry Agent Service. Kemampuan Foundry Agent Service tidak menggunakan konfigurasi DNS jaringan virtual spoke Anda. Oleh karena itu, disarankan agar tim platform Anda mengonfigurasi set aturan untuk zona DNS privat beban kerja di DNS Private Resolver, menautkan aturan tersebut ke spoke zona arahan aplikasi Anda.
Sebelum Anda menyebarkan Azure AI Foundry dan kemampuan agennya, Anda harus menunggu hingga dependensi Foundry Agent Service sepenuhnya dapat diselesaikan ke titik akhir privat mereka dari dalam jaringan spoke. Persyaratan ini sangat penting jika kebijakan DINE menangani pembaruan ke zona privat DNS. Jika Anda mencoba menyebarkan kemampuan Foundry Agent Service sebelum rekaman DNS privat dapat diselesaikan dari dalam subnet Anda, penyebaran gagal.
Tim platform juga harus menghosting zona DNS privat untuk dependensi beban kerja lainnya dalam arsitektur ini:
privatelink.vaultcore.azure.netprivatelink.azurewebsites.net
Ilmuwan data dan akses pengembang agen
Seperti arsitektur garis besar, arsitektur ini menonaktifkan akses masuk publik ke portal Azure AI Foundry dan pengalaman berbasis browser lainnya. Arsitektur garis besar menyebarkan jump box untuk menyediakan browser dengan alamat IP sumber dari jaringan virtual yang digunakan berbagai peran beban kerja.
Saat beban kerja Anda tersambung ke zona arahan Azure, tim Anda mendapatkan lebih banyak opsi akses. Bekerja dengan tim platform untuk melihat apakah Anda bisa mendapatkan akses privat ke berbagai portal Azure AI Foundry berbasis browser tanpa mengelola dan mengatur komputer virtual (VM). Akses ini mungkin dilakukan melalui perutean transitif dari koneksi ExpressRoute atau VPN Gateway yang ada.
Akses berbasis stasiun kerja asli memerlukan perutean lintas tempat dan resolusi DNS, yang dapat membantu disediakan oleh tim platform. Sertakan persyaratan ini dalam permintaan penjual langganan Anda.
Menyediakan akses berbasis stasiun kerja asli ke portal ini meningkatkan produktivitas dan menyederhanakan pemeliharaan dibandingkan dengan mengelola jump box VM.
Peran jump box
Jump box dalam arsitektur ini memberikan nilai untuk dukungan operasional, bukan untuk tujuan runtime atau AI dan pengembangan pembelajaran mesin. Jump box dapat memecahkan masalah DNS dan perutean jaringan karena menyediakan akses jaringan internal ke komponen yang tidak dapat diakses secara eksternal.
Dalam arsitektur garis besar, Azure Bastion mengakses jump box, yang Anda kelola.
Dalam arsitektur ini, Azure Bastion disebarkan dalam langganan konektivitas sebagai sumber daya regional bersama yang dikelola tim platform. Untuk menunjukkan bahwa kasus penggunaan dalam arsitektur ini, Azure Bastion berada dalam langganan konektivitas dan tim Anda tidak menyebarkannya.
VM yang berfungsi sebagai jump box harus mematuhi persyaratan organisasi untuk VM. Persyaratan ini mungkin mencakup item seperti identitas perusahaan dalam ID Microsoft Entra, gambar dasar tertentu, dan rezim patching.
Memantau sumber daya
Platform zona pendaratan Azure menyediakan sumber daya pengamatan bersama sebagai bagian dari langganan manajemen. Namun, kami sarankan Anda menyediakan sumber daya pemantauan Anda sendiri untuk memfasilitasi tanggung jawab kepemilikan beban kerja. Pendekatan ini selaras dengan arsitektur garis besar.
Anda menyediakan sumber daya pemantauan berikut:
Application Insights berfungsi sebagai layanan manajemen performa aplikasi (APM) untuk tim Anda. Anda mengonfigurasi layanan ini di UI obrolan, Foundry Agent Service, dan model.
Ruang kerja Log Azure Monitor berfungsi sebagai sink terpadu untuk semua log dan metrik dari sumber daya Azure milik beban kerja.
Mirip dengan arsitektur garis besar, semua sumber daya harus mengirim log diagnostik Azure ke ruang kerja Log Azure Monitor yang disediakan tim Anda. Konfigurasi ini adalah bagian dari penyebaran infrastruktur sebagai kode (IaC) sumber daya. Anda mungkin juga perlu mengirim log ke ruang kerja Log Azure Monitor pusat. Di zona pendaratan Azure, ruang kerja tersebut biasanya berada di langganan manajemen.
Tim platform mungkin memiliki lebih banyak proses yang memengaruhi sumber daya di zona pendaratan aplikasi. Misalnya, mereka mungkin menggunakan kebijakan DINE untuk mengonfigurasi diagnostik dan mengirim log ke langganan manajemen terpusat. Mereka mungkin juga menerapkan pemberitahuan garis besar Azure Monitor melalui kebijakan. Pastikan implementasi Anda tidak memblokir alur pengelogan dan pemberitahuan tambahan ini.
Azure Policy
Arsitektur garis besar merekomendasikan kebijakan umum untuk membantu mengatur beban kerja. Saat Anda menyebarkan arsitektur ini ke zona pendaratan aplikasi, Anda tidak perlu menambahkan atau menghapus kebijakan tambahan. Untuk membantu menerapkan tata kelola dan meningkatkan keamanan beban kerja ini, terus terapkan kebijakan ke langganan, grup sumber daya, atau sumber daya Anda.
Harapkan langganan zona pendaratan aplikasi memiliki kebijakan yang ada, bahkan sebelum Anda menyebarkan beban kerja. Beberapa kebijakan membantu tata kelola organisasi dengan mengaudit atau memblokir konfigurasi tertentu dalam penyebaran.
Contoh kebijakan berikut dapat menyebabkan kompleksitas penyebaran beban kerja:
Policy:Secrets [in Key Vault] harus memiliki periode validitas maksimum yang ditentukan.
Komplikasi: Azure AI Foundry dapat menyimpan rahasia yang terkait dengan pengetahuan dan koneksi alat di Key Vault yang terhubung. Rahasia tersebut tidak memiliki tanggal kedaluwarsa yang ditetapkan oleh layanan. Arsitektur garis besar tidak menggunakan jenis koneksi ini, tetapi Anda dapat memperluas arsitektur untuk mendukungnya.
Layanan Policy:AI Search harus menggunakan kunci yang dikelola pelanggan untuk mengenkripsi data tidak aktif.
Komplikasi: Arsitektur ini tidak memerlukan kunci yang dikelola pelanggan. Tetapi Anda dapat memperluas arsitektur untuk mendukungnya.
Model Policy:AI Foundry tidak boleh dipratinjau.
Komplikasi: Anda mungkin sedang dalam pengembangan menggunakan model pratinjau yang Anda antisipasi untuk tersedia secara umum pada saat Anda mengaktifkan kemampuan agen dalam beban kerja produksi Anda.
Tim platform mungkin menerapkan kebijakan DINE untuk menangani penyebaran otomatis ke dalam langganan zona pendaratan aplikasi. Terlebih dahulu menggabungkan dan menguji pembatasan dan perubahan yang dimulai platform ke dalam templat IaC Anda. Jika tim platform menggunakan kebijakan Azure yang bertentangan dengan persyaratan aplikasi, Anda dapat menegosiasikan resolusi.
Mengelola perubahan dari waktu ke waktu
Dalam arsitektur ini, layanan dan operasi yang disediakan platform berfungsi sebagai dependensi eksternal. Tim platform terus menerapkan perubahan, zona pendaratan onboard, dan menerapkan kontrol biaya. Tim platform mungkin tidak memprioritaskan beban kerja individual. Perubahan pada dependensi tersebut, seperti modifikasi firewall, dapat memengaruhi beberapa beban kerja.
Anda harus berkomunikasi dengan tim platform secara efisien dan tepat waktu untuk mengelola semua dependensi eksternal. Penting untuk menguji perubahan sebelumnya agar tidak berdampak negatif pada beban kerja.
Perubahan platform yang memengaruhi beban kerja
Dalam arsitektur ini, tim platform mengelola sumber daya berikut. Perubahan pada sumber daya ini berpotensi memengaruhi keandalan, keamanan, operasi, dan target performa beban kerja. Evaluasi perubahan ini sebelum tim platform mengimplementasikannya untuk menentukan bagaimana perubahan tersebut memengaruhi beban kerja.
Kebijakan Azure: Perubahan pada kebijakan Azure dapat memengaruhi sumber daya beban kerja dan dependensinya. Perubahan ini mungkin termasuk pembaruan kebijakan langsung atau pergerakan zona pendaratan ke dalam hierarki grup manajemen baru. Perubahan ini mungkin lugas hingga penyebaran baru terjadi, jadi Anda harus mengujinya secara menyeluruh.
Contoh: Kebijakan tidak lagi mengizinkan penyebaran instans Azure Cosmos DB yang memerlukan enkripsi kunci yang dikelola pelanggan, dan arsitektur Anda menggunakan enkripsi kunci yang dikelola Microsoft.
Aturan firewall: Modifikasi pada aturan firewall dapat memengaruhi jaringan virtual beban kerja atau aturan yang berlaku secara luas di semua lalu lintas. Modifikasi ini dapat mengakibatkan lalu lintas yang diblokir dan bahkan kegagalan proses senyap. Potensi masalah ini berlaku untuk firewall keluar dan aturan NSG yang diterapkan Azure Virtual Network Manager.
Contoh: Lalu lintas yang diblokir ke API Bing menyebabkan pemanggilan alat agen yang gagal untuk data grounding internet.
Perutean di jaringan hub: Perubahan dalam sifat perutean transitif di hub berpotensi memengaruhi fungsionalitas beban kerja jika beban kerja bergantung pada perutean ke jaringan virtual lainnya.
Contoh: Perubahan perutean mencegah agen Azure AI Foundry mengakses penyimpanan vektor yang dioperasikan oleh tim lain atau mencegah tim ilmu data mengakses portal AI Foundry dari stasiun kerja mereka.
Host Azure Bastion: Perubahan pada ketersediaan atau konfigurasi host Azure Bastion.
Contoh: Perubahan konfigurasi mencegah akses ke jump box dan membangun VM agen.
Perubahan beban kerja yang memengaruhi platform
Contoh berikut menjelaskan perubahan beban kerja yang harus Anda komunikasikan ke tim platform. Tim platform harus memvalidasi keandalan, keamanan, operasi, dan target performa layanan platform terhadap perubahan baru Anda sebelum diterapkan.
Keluarnya jaringan: Pantau peningkatan signifikan keluar jaringan untuk mencegah beban kerja menjadi tetangga yang bising pada perangkat jaringan. Masalah ini berpotensi memengaruhi target performa atau keandalan beban kerja lainnya. Arsitektur ini sebagian besar mandiri dan tidak mungkin mengalami perubahan signifikan dalam pola lalu lintas keluar.
Akses publik: Perubahan pada akses publik untuk komponen beban kerja mungkin memerlukan pengujian tambahan. Tim platform mungkin merelokasi beban kerja ke grup manajemen yang berbeda.
Contoh: Dalam arsitektur ini, jika Anda menghapus alamat IP publik dari Application Gateway dan membuat aplikasi ini hanya internal, paparan beban kerja terhadap perubahan internet. Contoh lain adalah mengekspos portal AI berbasis browser ke internet, yang tidak kami rekomendasikan.
Peringkat kekritisan bisnis: Perubahan pada perjanjian tingkat layanan (SLA) beban kerja mungkin memerlukan pendekatan kolaborasi baru antara platform dan tim beban kerja.
Contoh: Beban kerja Anda mungkin beralih dari bisnis rendah ke tinggi secara kritis karena peningkatan adopsi dan keberhasilan.
Tim arsitektur perusahaan
Beberapa organisasi memiliki tim arsitektur perusahaan yang mungkin memengaruhi desain beban kerja Anda dan arsitekturnya. Tim tersebut memahami strategi adopsi AI perusahaan dan prinsip dan rekomendasi dalam beban kerja AI pada desain Azure . Bekerja dengan tim ini untuk memastikan bahwa beban kerja obrolan ini memenuhi tujuan khusus skenario dan selaras dengan strategi dan rekomendasi organisasi.
Pertimbangan
Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat Anda gunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Well-Architected Framework.
Keandalan
Keandalan membantu memastikan bahwa aplikasi Anda dapat memenuhi komitmen yang Anda buat kepada pelanggan Anda. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Keandalan.
Arsitektur ini mempertahankan jaminan keandalan dalam arsitektur garis besar. Ini tidak memperkenalkan pertimbangan keandalan baru untuk komponen beban kerja inti.
Dependensi kritis
Perlakukan semua fungsionalitas yang dilakukan beban kerja di platform dan zona pendaratan aplikasi sebagai dependensi. Pertahankan rencana respons insiden yang mencakup metode kontak dan jalur eskalasi untuk setiap dependensi. Sertakan dependensi ini dalam analisis mode kegagalan beban kerja (FMA).
Pertimbangkan dependensi beban kerja dan contoh skenario berikut yang mungkin terjadi:
Firewall keluar: Firewall keluar terpusat mengalami perubahan yang tidak terkait dengan beban kerja. Beberapa beban kerja berbagi firewall.
Resolusi DNS: Arsitektur ini menggunakan DNS yang disediakan oleh tim platform untuk sebagian besar sumber daya, dikombinasikan dengan Azure DNS dan aturan DNS Private Resolver tertaut untuk Foundry Agent Service. Akibatnya, beban kerja bergantung pada pembaruan tepat waktu pada catatan DNS untuk titik akhir privat dan ketersediaan layanan DNS.
Kebijakan DINE: Kebijakan DINE untuk zona DNS privat Azure, atau dependensi lain yang disediakan platform, beroperasi berdasarkan upaya terbaik dan tidak menyertakan SLA. Misalnya, penundaan konfigurasi DNS untuk titik akhir privat arsitektur ini dapat mencegah antarmuka pengguna obrolan menjadi agen siap lalu lintas atau memblokir penyelesaian kueri Foundry Agent Service.
Kebijakan grup manajemen: Kebijakan yang konsisten di antara lingkungan mendukung keandalan. Pastikan bahwa lingkungan praproduksi cocok dengan lingkungan produksi untuk memberikan pengujian yang akurat dan mencegah penyimpangan khusus lingkungan yang dapat memblokir penyebaran atau skala. Untuk informasi selengkapnya, lihat Mengelola lingkungan pengembangan aplikasi di zona pendaratan Azure.
Banyak dari pertimbangan ini mungkin ada tanpa zona pendaratan Azure. Anda perlu bekerja dengan tim platform secara kolaboratif untuk mengatasi masalah ini dan memastikan bahwa Anda memenuhi semua persyaratan. Untuk informasi selengkapnya, lihat Mengidentifikasi dependensi.
Keamanan
Keamanan memberikan jaminan terhadap serangan yang disukai dan penyalahgunaan data dan sistem berharga Anda. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Keamanan.
Kontrol lalu lintas Ingress
Untuk mengisolasi beban kerja Anda dari spoke beban kerja lain dalam organisasi Anda, terapkan NSG pada subnet Anda dan gunakan sifat atau kontrol nontransitif di hub regional. Buat NSG komprehensif yang hanya mengizinkan persyaratan jaringan masuk aplikasi Anda dan infrastrukturnya. Kami menyarankan agar Anda tidak hanya mengandalkan sifat nontransitif jaringan hub untuk keamanan.
Tim platform menerapkan kebijakan Azure untuk keamanan. Misalnya, kebijakan mungkin memastikan bahwa Application Gateway memiliki firewall aplikasi web yang diatur ke mode tolak, yang membatasi jumlah alamat IP publik yang tersedia untuk langganan Anda. Selain kebijakan tersebut, Anda harus menyebarkan lebih banyak kebijakan yang berpusat pada beban kerja yang memperkuat postur keamanan ingress.
Tabel berikut ini memperlihatkan contoh kontrol ingress dalam arsitektur ini.
| Sumber | Tujuan | Kontrol beban kerja | Kontrol platform |
|---|---|---|---|
| internet | Arus lalu lintas aplikasi | Corong semua permintaan beban kerja melalui NSG, firewall aplikasi web, dan aturan perutean sebelum memungkinkan lalu lintas publik beralih ke lalu lintas privat untuk UI obrolan. | Tidak ada |
| internet | Akses portal Azure AI Foundry dan akses REST API sarana data | Tolak semua akses melalui konfigurasi tingkat layanan. | Tidak ada |
| internet | Akses sarana data ke semua layanan kecuali Application Gateway | Tolak semua akses melalui aturan NSG dan konfigurasi tingkat layanan. | Tidak ada |
| Azure Bastion | Jump box dan membangun akses agen | Terapkan NSG pada subnet jump box yang memblokir semua lalu lintas ke port akses jarak jauh, kecuali sumbernya adalah subnet Azure Bastion yang ditunjuk platform. | Tidak ada |
| Lintas lokasi | Akses portal Azure AI Foundry dan akses REST API sarana data | Tolak semua akses. Jika Anda tidak menggunakan jump box, izinkan akses hanya dari stasiun kerja di subnet resmi untuk ilmuwan data. | Menerapkan perutean nontransitif atau menggunakan Azure Firewall di hub aman Azure Virtual WAN |
| Spoke lainnya | Tidak ada | Diblokir melalui aturan NSG. | Menerapkan perutean nontransitif atau menggunakan Azure Firewall di hub aman Virtual WAN |
Kontrol lalu lintas keluar
Terapkan aturan NSG yang mengekspresikan persyaratan konektivitas keluar yang diperlukan dari solusi Anda dan tolak yang lainnya. Jangan hanya mengandalkan kontrol jaringan hub. Sebagai operator beban kerja, Anda harus menghentikan lalu lintas keluar yang tidak diinginkan sedekat mungkin dengan sumber.
Anda memiliki subnet beban kerja Anda dalam jaringan virtual, tetapi tim platform kemungkinan membuat aturan firewall untuk secara khusus mewakili persyaratan yang diambil sebagai bagian dari proses penjual langganan Anda. Pastikan bahwa perubahan subnet dan penempatan sumber daya selama masa pakai arsitektur Anda tetap kompatibel dengan permintaan asli Anda. Bekerja dengan tim jaringan Anda untuk memastikan kelangsungan kontrol keluar akses paling sedikit.
Tabel berikut ini memperlihatkan contoh kontrol keluar dalam arsitektur ini.
| Titik akhir | Tujuan | Kontrol beban kerja | Kontrol platform |
|---|---|---|---|
| Sumber internet publik | Agen Anda mungkin memerlukan pencarian internet untuk membumikan Azure OpenAI dalam permintaan Model Foundry | Menerapkan NSG pada subnet integrasi agen | Menerapkan aturan aplikasi firewall untuk penyimpanan pengetahuan dan alat eksternal |
| Bidang data Azure AI Foundry | UI obrolan berinteraksi dengan agen obrolan | Izinkan TCP/443 dari subnet integrasi App Service ke subnet titik akhir privat Azure AI Foundry | Tidak ada |
| Azure Cosmos DB | Untuk mengakses database memori dari Foundry Agent Service | Mengizinkan TCP pada setiap port ke subnet titik akhir privat Azure Cosmos DB | Tidak ada |
Untuk lalu lintas yang meninggalkan jaringan virtual beban kerja, arsitektur ini menerapkan kontrol pada tingkat beban kerja melalui NSG dan di tingkat platform melalui firewall jaringan hub. NSG menyediakan aturan lalu lintas jaringan awal yang luas. Di hub platform, firewall menerapkan aturan yang lebih spesifik untuk keamanan tambahan.
Arsitektur ini tidak memerlukan lalu lintas timur-barat antara komponen internal, seperti Foundry Agent Service dan instans Pencarian AI dependennya, untuk merutekan melalui jaringan hub.
DDoS Protection
Tentukan siapa yang harus menerapkan paket DDoS Protection yang mencakup alamat IP publik solusi Anda. Tim platform mungkin menggunakan paket perlindungan alamat IP, atau mereka mungkin menggunakan Azure Policy untuk memberlakukan rencana perlindungan jaringan virtual. Arsitektur ini memerlukan cakupan DDoS Protection karena memiliki alamat IP publik untuk masuk dari internet. Untuk informasi selengkapnya, lihat Rekomendasi untuk jaringan dan konektivitas.
Manajemen identitas dan akses
Kecuali otomatisasi tata kelola tim platform memerlukan kontrol ekstra, arsitektur ini tidak memperkenalkan persyaratan otorisasi baru karena keterlibatan tim platform. Kontrol akses berbasis peran Azure (RBAC) harus terus memenuhi prinsip hak istimewa paling sedikit, yang memberikan akses terbatas hanya kepada individu yang membutuhkannya dan hanya ketika diperlukan. Untuk informasi selengkapnya, lihat Rekomendasi untuk manajemen identitas dan akses.
Sertifikat dan enkripsi
Tim Anda biasanya mendapatkan sertifikat TLS untuk alamat IP publik di Application Gateway. Bekerja sama dengan tim platform untuk memahami bagaimana proses pengadaan sertifikat dan manajemen harus selaras dengan harapan organisasi.
Semua layanan penyimpanan data dalam arsitektur ini mendukung kunci enkripsi yang dikelola Microsoft atau yang dikelola pelanggan. Gunakan kunci enkripsi yang dikelola pelanggan jika desain atau organisasi beban kerja Anda memerlukan kontrol lebih. Zona pendaratan Azure sendiri tidak mengamanatkan metode tertentu.
Pengoptimalan Biaya
Pengoptimalan Biaya berfokus pada cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk optimalisasi biaya.
Semua strategi pengoptimalan biaya dalam arsitektur garis besar berlaku untuk sumber daya beban kerja dalam arsitektur ini.
Arsitektur ini sangat mendapat manfaat dari sumber daya platform zona pendaratan Azure. Misalnya, sumber daya seperti Azure Firewall dan transisi DDoS Protection dari beban kerja ke sumber daya platform. Bahkan jika Anda menggunakan sumber daya tersebut melalui model penagihan balik, keamanan tambahan dan konektivitas lintas lokasi lebih hemat biaya daripada mengelola sumber daya tersebut sendiri. Manfaatkan penawaran terpusat lainnya dari tim platform Anda untuk memperluas manfaat tersebut ke beban kerja Anda tanpa mengorbankan tujuan tingkat layanan, tujuan waktu pemulihan, atau tujuan titik pemulihannya.
Penting
Jangan mencoba mengoptimalkan biaya dengan mengonsolidasikan dependensi Azure AI Foundry sebagai sumber daya platform. Layanan ini harus tetap menjadi sumber daya beban kerja.
Keunggulan Operasi
Keunggulan Operasional mencakup proses operasi yang menyebarkan aplikasi dan membuatnya tetap berjalan dalam produksi. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Keunggulan Operasional.
Anda tetap bertanggung jawab atas semua pertimbangan keunggulan operasional dari arsitektur garis besar. Tanggung jawab ini termasuk pemantauan, GenAIOps, jaminan kualitas, dan praktik penyebaran yang aman.
Menghubungkan data dari beberapa sink
Ruang kerja Azure Monitor Logs beban kerja menyimpan log dan metrik beban kerja serta komponen infrastrukturnya. Namun, ruang kerja Log Azure Monitor pusat sering menyimpan log dan metrik dari layanan terpusat, seperti Azure Firewall, DNS Private Resolver, dan Azure Bastion. Menghubungkan data dari beberapa sink bisa menjadi tugas yang kompleks.
Data berkorelasi membantu mendukung respons insiden. Runbook triase untuk arsitektur ini harus mengatasi situasi ini dan menyertakan informasi kontak organisasi jika masalah meluas di luar sumber daya beban kerja. Administrator beban kerja mungkin memerlukan bantuan dari administrator platform untuk menghubungkan entri log dari jaringan perusahaan, keamanan, atau layanan platform lainnya.
Penting
Untuk tim platform: Jika memungkinkan, berikan izin RBAC untuk mengkueri dan membaca sink log untuk sumber daya platform yang relevan. Aktifkan log firewall untuk evaluasi aturan jaringan dan aplikasi dan proksi DNS. Tim aplikasi dapat menggunakan informasi ini untuk memecahkan masalah tugas. Untuk informasi selengkapnya, lihat Rekomendasi untuk pemantauan dan deteksi ancaman.
Membangun agen
Banyak layanan dalam arsitektur ini menggunakan titik akhir privat. Mirip dengan arsitektur garis besar, desain ini mungkin memerlukan agen build. Tim Anda menyebarkan agen build dengan aman dan andal. Tim platform tidak terlibat dalam proses ini.
Pastikan bahwa manajemen agen build mematuhi standar organisasi. Standar ini mungkin termasuk penggunaan gambar sistem operasi yang disetujui platform, jadwal patching, pelaporan kepatuhan, dan metode autentikasi pengguna.
Efisiensi Performa
Efisiensi Performa mengacu pada kemampuan beban kerja Anda untuk menskalakan untuk memenuhi tuntutan pengguna secara efisien. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Efisiensi Kinerja.
Pertimbangan efisiensi performa dalam arsitektur garis besar juga berlaku untuk arsitektur ini. Tim Anda mempertahankan kontrol atas sumber daya dalam alur aplikasi, bukan tim platform. Skalakan host UI obrolan, model bahasa, dan komponen lainnya sesuai dengan beban kerja dan batasan biaya. Bergantung pada implementasi akhir arsitektur Anda, pertimbangkan faktor-faktor berikut saat Anda mengukur performa terhadap target performa:
- Latensi keluar dan lintas lokasi
- Batasan SKU dari tata kelola penahanan biaya
Menyebarkan skenario ini
Sebarkan implementasi zona pendaratan dari arsitektur referensi ini.
Kontributor
Microsoft mempertahankan artikel ini. Kontributor berikut menulis artikel ini.
Penulis utama:
- Bilal Amjad | Arsitek Solusi Cloud Microsoft
- Freddy Ayala | Arsitek Solusi Cloud Microsoft
- Chad Kittel | Insinyur Perangkat Lunak Utama - Pola & Praktik Azure
Untuk melihat profil LinkedIn nonpublik, masuk ke LinkedIn.
Langkah selanjutnya
Pelajari cara berkolaborasi pada detail teknis dengan tim platform.
Sumber daya terkait
- Perspektif kerangka kerja Well-Architected tentang beban kerja AI di Azure