Arsitektur garis besar obrolan Azure OpenAI di zona pendaratan Azure

Artikel ini adalah bagian dari seri yang dibangun di arsitektur garis besar obrolan end-to-end Azure OpenAI Service. Anda harus membiasakan diri dengan arsitektur garis besar sehingga Anda dapat memahami perubahan yang perlu Anda buat saat menyebarkan arsitektur dalam langganan zona pendaratan aplikasi Azure.

Artikel ini menjelaskan arsitektur beban kerja AI generatif yang menyebarkan aplikasi obrolan dasar yang sama tetapi menggunakan sumber daya yang berada di luar cakupan tim beban kerja. Sumber daya tersebut dibagikan di antara tim beban kerja lainnya dan dikelola secara terpusat oleh tim platform organisasi. Sumber daya bersama mencakup sumber daya jaringan untuk menyambungkan ke atau dari lokasi lokal, sumber daya manajemen akses identitas, dan kebijakan. Panduan ini untuk organisasi yang menggunakan zona pendaratan Azure untuk memastikan tata kelola yang konsisten dan efisiensi biaya.

Sebagai pemilik beban kerja, Anda dapat membongkar manajemen sumber daya bersama ke tim platform sehingga Anda dapat fokus pada upaya pengembangan beban kerja. Artikel ini menyajikan perspektif tim beban kerja. Rekomendasi untuk tim platform ditentukan.

Perubahan dari garis besar: Kebijakan ini baru dalam arsitektur ini.

Unduh file Visio arsitektur ini.

Semua arsitektur zona pendaratan Azure memiliki pemisahan kepemilikan antara tim platform dan tim beban kerja, yang disebut sebagai demokratisasi langganan. Arsitek aplikasi, ilmuwan data, dan tim DevOps harus memiliki pemahaman yang kuat tentang pemisahan tanggung jawab ini untuk mengetahui apa yang berada di bawah pengaruh atau kontrol langsung mereka dan apa yang tidak.

Seperti kebanyakan implementasi zona pendaratan aplikasi, tim beban kerja sebagian besar bertanggung jawab atas konfigurasi, manajemen, dan penyebaran komponen beban kerja, termasuk semua layanan AI yang digunakan dalam arsitektur ini.

Sumber daya berikut sebagian besar tidak berubah dari arsitektur garis besar.

• Azure OpenAI adalah layanan terkelola yang menyediakan akses REST API ke model bahasa Azure OpenAI, termasuk model GPT-4, GPT-3.5 Turbo, dan penyematan.

• Azure Pembelajaran Mesin digunakan untuk mengembangkan dan menyebarkan logika alur prompt yang digunakan dalam beban kerja ini.

• Titik akhir online terkelola digunakan sebagai titik akhir platform as a service (PaaS) untuk aplikasi UI obrolan, yang memanggil alur prompt yang dihosting oleh Pembelajaran Mesin.

• Azure App Service digunakan untuk menghosting contoh aplikasi web untuk UI obrolan. Dalam arsitektur ini, dimungkinkan juga untuk menggunakan layanan ini untuk menghosting alur prompt dalam kontainer untuk kontrol lebih besar atas lingkungan hosting yang menjalankan alur prompt. App Service memiliki tiga instans, masing-masing di zona Azure yang berbeda.

• AI Search adalah layanan umum yang digunakan dalam alur di belakang aplikasi obrolan. Anda dapat menggunakan Pencarian AI untuk mengambil data terindeks yang relevan untuk kueri pengguna.

• Azure Storage digunakan untuk mempertahankan file sumber alur perintah untuk pengembangan alur perintah.

• Azure Container Registry digunakan untuk menyimpan alur yang dipaketkan sebagai gambar kontainer.

• Azure Application Gateway digunakan sebagai proksi terbalik untuk merutekan permintaan pengguna ke UI obrolan yang dihosting di App Service. SKU yang dipilih juga digunakan untuk menghosting firewall aplikasi web Azure untuk melindungi aplikasi front-end dari lalu lintas yang berpotensi berbahaya.

• Key Vault digunakan untuk menyimpan rahasia dan sertifikat aplikasi.

• Azure Monitor, Azure Monitor Logs, dan Application Insights digunakan untuk mengumpulkan, menyimpan, dan memvisualisasikan data pengamatan.

• Azure Policy digunakan untuk menerapkan kebijakan yang khusus untuk beban kerja untuk membantu mengatur, mengamankan, dan menerapkan kontrol dalam skala besar.

Tim beban kerja mempertahankan sumber daya berikut:

• Subnet jaringan virtual spoke dan kelompok keamanan jaringan (NSG) yang ditempatkan pada subnet tersebut untuk mempertahankan segmentasi dan mengontrol arus lalu lintas.

• Titik akhir privat untuk mengamankan konektivitas ke solusi PaaS.

Tim platform memiliki dan memelihara sumber daya terpusat ini. Arsitektur ini mengasumsikan bahwa sumber daya ini telah disediakan sebelumnya dan menganggapnya dependensi.

• Azure Firewall di jaringan hub digunakan untuk merutekan, memeriksa, dan membatasi lalu lintas keluar. Lalu lintas keluar beban kerja masuk ke internet, tujuan lintas tempat, atau ke zona pendaratan aplikasi lainnya.

  Ubah dari garis besar: Komponen ini baru dalam arsitektur ini. Azure Firewall tidak hemat biaya atau praktis bagi setiap tim beban kerja untuk mengelola instans mereka sendiri.

• Azure Bastion di jaringan hub menyediakan akses operasional yang aman ke komponen beban kerja dan juga memungkinkan akses ke komponen Azure AI Studio.

  Perubahan dari garis besar: Tim beban kerja memiliki komponen ini dalam arsitektur dasar.

• Jaringan virtual spoke adalah tempat beban kerja disebarkan.

  Ubah dari garis besar: Tim beban kerja memiliki jaringan ini dalam arsitektur garis besar.

• Rute yang ditentukan pengguna (UDR) digunakan untuk memaksa penerowongan ke jaringan hub.

  Ubah dari garis besar: Komponen ini baru dalam arsitektur ini.

• Batasan tata kelola berbasis Azure Policy dan DeployIfNotExists (DINE) adalah bagian dari langganan beban kerja. Anda dapat menerapkan kebijakan ini di tingkat grup manajemen milik tim platform atau menerapkannya ke langganan beban kerja secara langsung.

  Perubahan dari garis besar: Kebijakan ini baru dalam arsitektur ini.

• Zona DNS privat Azure menghosting A rekaman untuk titik akhir privat. Untuk informasi selengkapnya, lihat Private Link dan integrasi DNS dalam skala besar.

  Perubahan dari garis besar: Komponen ini dipindahkan ke hub dan dikelola platform.

• Layanan resolusi DNS untuk jaringan virtual spoke dan stasiun kerja lintas lokasi. Layanan tersebut biasanya berbentuk Azure Firewall sebagai proksi DNS atau Azure DNS Private Resolver. Dalam arsitektur ini, layanan ini menyelesaikan catatan DNS titik akhir privat untuk semua permintaan DNS yang berasal dari spoke.

• Azure DDoS Protection digunakan untuk melindungi alamat IP publik dari serangan terdistribusi.

  Perubahan dari garis besar: Tim beban kerja membeli DDoS Protection dalam arsitektur garis besar.

Dalam konteks zona pendaratan, tim beban kerja yang menerapkan arsitektur ini harus memberi tahu tim platform tentang persyaratan spesifik mereka. Tim platform kemudian harus mengkomunikasikan persyaratan mereka ke tim beban kerja.

Misalnya, tim beban kerja Anda harus menyertakan informasi terperinci tentang ruang jaringan yang dibutuhkan beban kerja Anda, sehingga tim platform dapat mengalokasikan sumber daya yang diperlukan. Tim Anda menentukan persyaratan, dan tim platform menentukan alamat IP yang akan ditetapkan dalam jaringan virtual.

Tim platform menetapkan grup manajemen yang sesuai berdasarkan kekritisan bisnis dan persyaratan teknis beban kerja. Contohnya adalah jika beban kerja terekspos ke internet seperti dalam arsitektur ini. Tim platform menetapkan tata kelola dengan mengonfigurasi dan menerapkan grup manajemen. Tim beban kerja Anda harus merancang dan mengoperasikan beban kerja dalam batasan tata kelola. Untuk informasi selengkapnya tentang perbedaan grup manajemen yang khas, lihat Menyesuaikan arsitektur zona pendaratan Azure.

Pada akhirnya, tim platform menyiapkan langganan untuk arsitektur ini. Bagian berikut memberikan panduan tentang penyiapan langganan awal karena berkaitan dengan arsitektur ini.

Untuk arsitektur ini, tim beban kerja dan tim platform perlu berkolaborasi pada beberapa topik: penetapan grup manajemen, termasuk tata kelola Azure Policy terkait, dan penyiapan jaringan. Siapkan daftar periksa persyaratan untuk memulai diskusi dan negosiasi dengan tim platform. Daftar periksa ini berfungsi sebagai contoh dalam konteks arsitektur ini.

Komputasi yang menghosting alur prompt dan UI obrolan tetap sama dengan arsitektur garis besar.

Organisasi mungkin memberlakukan persyaratan pada tim beban kerja yang mengamanatkan penggunaan runtime Pembelajaran Mesin tertentu. Misalnya, persyaratannya mungkin untuk menghindari runtime otomatis atau runtime instans komputasi dan sebaliknya mendukung host kontainer alur prompt yang memenuhi mandat kepatuhan, keamanan, dan pengamatan.

Tata kelola organisasi mungkin menambahkan lebih banyak persyaratan untuk pemeliharaan gambar dasar kontainer dan pelacakan paket dependensi daripada yang ditunjukkan oleh persyaratan beban kerja. Tim beban kerja harus memastikan bahwa lingkungan runtime beban kerja, kode yang disebarkan ke dalamnya, dan operasinya selaras dengan standar organisasi ini.

Alih-alih menghosting kode alur perintah di lingkungan runtime Pembelajaran Mesin, Anda dapat menghostingnya di App Service. Dalam pendekatan ini, lalu lintas keluar dikontrol, jika dibandingkan dengan jaringan virtual terkelola komputasi Pembelajaran Mesin. Logika itu sendiri tidak berubah tetapi instans App Service membutuhkan akses internet.

Dalam arsitektur garis besar, beban kerja disediakan dalam satu jaringan virtual.

Perubahan dari garis besar: Beban kerja secara efektif dibagi melalui dua jaringan virtual. Salah satu jaringan adalah untuk komponen beban kerja dan satu untuk mengontrol konektivitas internet dan hibrid. Tim platform menentukan bagaimana jaringan virtual beban kerja terintegrasi dengan arsitektur jaringan organisasi yang lebih besar, yang biasanya dengan topologi hub-spoke.

Unduh file Visio arsitektur ini.

• Jaringan virtual hub: Hub regional yang berisi layanan terpusat, dan sering dibagikan, yang berkomunikasi dengan sumber daya beban kerja di wilayah yang sama. Hub terletak 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 spoke. Jaringan virtual di-peering ke jaringan hub oleh tim platform. Tim platform memiliki dan mengelola jaringan spoke ini, peering,dan konfigurasi DNS-nya. Jaringan ini berisi banyak sumber daya beban kerja. Tim beban kerja memiliki sumber daya dalam jaringan ini, termasuk subnetnya.

Karena pemisahan manajemen dan kepemilikan ini, pastikan Anda mengomunikasikan persyaratan beban kerja dengan jelas kepada tim platform.

Dalam jaringan virtual spoke, tim beban kerja membuat dan mengalokasikan subnet yang selaras dengan persyaratan beban kerja. Menempatkan kontrol untuk membatasi lalu lintas masuk dan keluar dari subnet membantu menyediakan segmentasi. Arsitektur ini tidak menambahkan subnet apa pun di luar subnet tersebut yang menjelaskan arsitektur garis besar. Namun arsitektur jaringan tidak lagi memerlukan AzureBastionSubnet subnet karena tim platform menghosting layanan ini dalam langganan mereka.

Anda masih harus menerapkan kontrol jaringan lokal saat menyebarkan beban kerja di zona pendaratan Azure. Organisasi mungkin memberlakukan pembatasan jaringan lebih lanjut untuk melindungi dari eksfiltrasi data dan memastikan visibilitas untuk pusat operasi keamanan pusat (SOC) dan tim jaringan TI.

Arus lalu lintas ingress tetap sama dengan arsitektur garis besar.

Tim beban kerja Anda bertanggung jawab atas sumber daya apa pun yang terkait dengan masuknya internet publik ke dalam beban kerja. Misalnya, dalam arsitektur ini, Application Gateway dan alamat IP publiknya ditempatkan di jaringan spoke dan bukan jaringan hub. Beberapa organisasi mungkin menempatkan sumber daya dengan lalu lintas masuk dalam langganan konektivitas dengan menggunakan implementasi jaringan perimeter terpusat (juga dikenal sebagai DMZ, zona demiliterisasi, dan subnet yang disaring). Integrasi dengan topologi tertentu berada di luar cakupan untuk artikel ini.

Arsitektur ini tidak menggunakan Azure Firewall untuk memeriksa lalu lintas masuk. Terkadang tata kelola organisasi memerlukan pendekatan ini. Tim platform mendukung implementasi untuk menyediakan lapisan deteksi dan pencegahan intrusi tambahan kepada tim beban kerja untuk memblokir lalu lintas masuk yang tidak diinginkan. Arsitektur ini membutuhkan lebih banyak konfigurasi UDR untuk mendukung topologi ini. Untuk informasi selengkapnya tentang pendekatan ini, lihat Jaringan Zero Trust untuk aplikasi web dengan Azure Firewall dan Application Gateway.

Dalam arsitektur garis besar, Azure DNS digunakan langsung oleh semua komponen untuk resolusi DNS.

Ubah dari garis besar: DNS biasanya didelegasikan ke satu atau beberapa server DNS di hub. Ketika jaringan virtual dibuat untuk arsitektur ini, properti DNS pada jaringan virtual diharapkan sudah diatur. Layanan DNS dianggap buram untuk tim beban kerja Anda.

Komponen beban kerja dalam arsitektur ini dikonfigurasi dengan DNS dengan cara berikut.

Tidak ada pengaturan DNS yang dikonfigurasi untuk komponen yang tersisa dalam arsitektur karena tidak ada komunikasi keluar yang terjadi dari layanan tersebut. Tidak diperlukan resolusi DNS untuk komponen tersebut.

Banyak dari komponen ini memerlukan catatan DNS yang sesuai di server DNS hub untuk menyelesaikan banyak titik akhir privat beban kerja ini. Untuk informasi selengkapnya, lihat Zona DNS Privat Azure. Untuk komponen di mana resolusi DNS berbasis hub tidak dapat terjadi, Anda dihadapkan dengan batasan berikut:

• Tim platform tidak dapat mencatat permintaan DNS, yang mungkin merupakan persyaratan tim keamanan organisasi.

• Mengatasi layanan yang diekspos Azure Private Link di zona pendaratan Anda atau zona pendaratan aplikasi lainnya mungkin tidak mungkin. Beberapa layanan, seperti Pembelajaran Mesin komputasi, mengatasi batasan ini melalui fitur khusus layanan.

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.

Dalam arsitektur dasar, kontrol keluar internet hanya tersedia melalui konfigurasi jaringan pada ruang kerja Pembelajaran Mesin dan App Service, dikombinasikan dengan menggunakan NSG pada berbagai subnet.

Perubahan dari garis besar: Kontrol keluar lebih lanjut ditambah. Semua lalu lintas yang meninggalkan jaringan virtual spoke dialihkan melalui jaringan hub yang di-peering melalui firewall keluar. Lalu lintas yang berasal dari dalam jaringan virtual terkelola untuk komputasi Pembelajaran Mesin tidak tunduk pada rute keluar ini.

Unduh file Visio arsitektur ini.

Komunikasi klien timur-barat ke titik akhir privat untuk Container Registry, Key Vault, Azure OpenAI, dan lainnya tetap sama dengan arsitektur dasar. Jalur itu dihilangkan dari diagram sebelumnya untuk brevity.

Rute dilampirkan ke semua subnet yang mungkin di jaringan spoke yang mengarahkan semua lalu lintas yang menuju ke internet (0.0.0.0/0) terlebih dahulu ke Azure Firewall hub.

Tidak ada pengaturan terowongan paksa yang dikonfigurasi untuk komponen yang tetap berada dalam arsitektur karena tidak ada komunikasi keluar yang terjadi dari layanan tersebut.

Untuk komponen atau fitur komponen di mana kontrol keluar melalui perutean hub tidak dimungkinkan, tim beban kerja Anda harus selaras dengan persyaratan organisasi pada lalu lintas ini. Gunakan kontrol kompensasi, desain ulang beban kerja untuk mengecualikan fitur-fitur ini, atau mencari pengecualian formal. Beban kerja pada akhirnya bertanggung jawab untuk mengurangi eksfiltrasi dan penyalahgunaan data.

Terapkan rute internet yang disediakan platform ke semua subnet, bahkan jika subnet tidak diharapkan memiliki lalu lintas keluar. Pendekatan ini memastikan bahwa setiap penyebaran tak terduga ke subnet tersebut tunduk pada pemfilteran keluar rutin. Pastikan subnet yang berisi titik akhir privat memiliki kebijakan jaringan yang diaktifkan untuk perutean penuh dan kontrol NSG.

Saat Anda menerapkan konfigurasi rute ini ke arsitektur, semua koneksi keluar dari App Service, ruang kerja Pembelajaran Mesin, atau layanan lain yang berasal dari jaringan virtual beban kerja diteliti dan dikontrol.

Arsitektur yang menggunakan titik akhir privat untuk lalu lintas timur-barat dalam beban kerja mereka memerlukan rekaman zona DNS di penyedia DNS yang dikonfigurasi. Arsitektur ini mengharuskan banyak rekaman zona DNS berfungsi dengan baik: Key Vault, Azure OpenAI, dan banyak lagi untuk mendukung Private Link.

Perubahan dari garis besar: Tim beban kerja bertanggung jawab langsung atas zona DNS privat dalam arsitektur garis besar. Dalam arsitektur zona pendaratan, tim platform biasanya mempertahankan zona DNS privat. Mereka mungkin menggunakan teknologi lain, tetapi untuk arsitektur ini, ini adalah catatan zona DNS privat. Tim beban kerja harus memahami dengan jelas persyaratan dan harapan tim platform untuk manajemen catatan zona DNS privat tersebut.

Dalam arsitektur ini, tim platform harus memastikan hosting DNS yang andal dan tepat waktu untuk titik akhir Private Link berikut:

• Pencarian AI
• Azure OpenAI
• Container Registry
• Key Vault
• Akun penyimpanan

Seperti arsitektur garis besar, akses masuk publik ke ruang kerja Pembelajaran Mesin dan pengalaman berbasis browser lainnya dinonaktifkan. Arsitektur garis besar menyebarkan jump box untuk menyediakan browser dengan alamat IP sumber dari jaringan virtual yang digunakan oleh berbagai peran beban kerja.

Saat beban kerja Anda tersambung ke zona arahan Azure, lebih banyak opsi tersedia untuk tim Anda untuk akses ini. Bekerja dengan tim platform Anda untuk melihat apakah akses privat ke berbagai studio AI berbasis browser dapat dicapai tanpa perlu mengelola dan mengatur komputer virtual (VM). Akses ini mungkin dicapai melalui akses transitif dari koneksi ExpressRoute atau VPN Gateway yang sudah dibuat. Akses berbasis stasiun kerja asli memerlukan perutean lintas tempat dan resolusi DNS, yang dapat membantu disediakan oleh tim platform. Buat persyaratan ini diketahui dalam permintaan penjual langganan Anda.

Menyediakan akses berbasis stasiun kerja asli ke portal ini adalah peningkatan produktivitas di atas garis besar dan dapat lebih sederhana untuk dipertahankan daripada jump box VM.

Memiliki jump box dalam arsitektur ini sangat berharga tetapi tidak untuk tujuan runtime atau AI atau tujuan 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 dikelola oleh tim beban kerja.

Dalam arsitektur ini, Azure Bastion disebarkan dalam langganan konektivitas sebagai sumber daya regional bersama yang dikelola oleh tim platform. Untuk menunjukkan bahwa kasus penggunaan dalam arsitektur ini, Azure Bastion berada dalam langganan konektivitas dan tidak lagi disebarkan oleh tim beban kerja.

VM yang digunakan 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.

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 konsisten dengan arsitektur garis besar.

Tim beban kerja menyediakan sumber daya pemantauan, yang meliputi:

• Application Insights sebagai layanan manajemen performa aplikasi (APM) untuk tim beban kerja. Fitur ini dikonfigurasi di UI obrolan dan kode alur perintah.

• Ruang kerja Log Azure Monitor sebagai sink terpadu untuk semua log dan metrik yang dikumpulkan dari sumber daya Azure milik beban kerja.

Mirip dengan garis besar, semua sumber daya dikonfigurasi untuk mengirim log Diagnostik Azure ke ruang kerja Log Azure Monitor yang disediakan tim beban kerja sebagai 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 dalam langganan manajemen.

Tim platform mungkin juga memiliki proses yang memengaruhi sumber daya zona pendaratan aplikasi Anda. Misalnya, mereka mungkin menggunakan kebijakan DINE untuk mengonfigurasi diagnostik dan mengirim log ke langganan manajemen terpusat mereka. Atau mereka mungkin menggunakan pemberitahuan garis besar Monitor yang diterapkan melalui kebijakan. Penting untuk memastikan bahwa implementasi Anda tidak membatasi alur log dan pemberitahuan tambahan.

Arsitektur garis besar merekomendasikan beberapa kebijakan umum untuk membantu mengatur beban kerja. Saat Anda menyebarkan arsitektur ini ke zona pendaratan aplikasi, Anda tidak perlu menambahkan atau menghapus kebijakan lagi. Terus terapkan kebijakan ke langganan, grup sumber daya, atau sumber daya Anda yang membantu menegakkan tata kelola dan meningkatkan keamanan beban kerja ini.

Harapkan langganan zona pendaratan aplikasi memiliki kebijakan yang sudah diterapkan, bahkan sebelum beban kerja disebarkan. Beberapa kebijakan membantu tata kelola organisasi dengan mengaudit atau memblokir konfigurasi tertentu dalam penyebaran. Berikut adalah beberapa contoh kebijakan yang mungkin menyebabkan kompleksitas penyebaran beban kerja:

• Kebijakan: "Rahasia [di Key Vault] harus memiliki periode validitas maksimum yang ditentukan."

  Komplikasi: Pembelajaran Mesin mengelola rahasia di Key Vault beban kerja, dan rahasia tersebut tidak memiliki tanggal kedaluwarsa yang ditetapkan.

• Kebijakan: "Pembelajaran Mesin ruang kerja harus dienkripsi dengan kunci yang dikelola pelanggan."

  Komplikasi: Arsitektur ini tidak dirancang semata-mata untuk menangani kunci yang dikelola pelanggan. Namun, dapat diperluas untuk menggunakannya.

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 dengan tim platform.

Layanan dan operasi yang disediakan platform dianggap sebagai dependensi eksternal dalam arsitektur ini. Tim platform terus menerapkan perubahan, zona pendaratan onboard, dan menerapkan kontrol biaya. Tim platform yang melayani organisasi mungkin tidak memprioritaskan beban kerja individual. Perubahan pada dependensi tersebut, seperti modifikasi firewall, dapat memengaruhi beberapa beban kerja.

Tim beban kerja dan platform harus berkomunikasi secara efisien dan tepat waktu untuk mengelola semua dependensi eksternal. Penting untuk menguji perubahan sebelumnya agar tidak berdampak negatif pada 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. Penting untuk mengevaluasi 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. Misalnya, mungkin ada perubahan kebijakan langsung atau pergerakan zona pendaratan ke dalam hierarki grup manajemen baru. Perubahan ini mungkin lugas sampai ada penyebaran baru, jadi penting untuk mengujinya secara menyeluruh.

  Contoh: Kebijakan tidak lagi mengizinkan penyebaran instans Azure OpenAI yang mendukung akses kunci API.

• 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: Server pembaruan vendor yang diblokir menyebabkan pembaruan sistem operasi yang gagal pada jump box atau agen build.

• 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: Mencegah alur prompt untuk mengakses penyimpanan vektor yang dioperasikan oleh tim lain atau tim ilmu data agar tidak mengakses pengalaman berbasis browser di portal AI dari stasiun kerja mereka.

• Host Azure Bastion: Perubahan pada ketersediaan atau konfigurasi host Azure Bastion.

  Contoh: Mencegah akses ke jump box dan membangun VM agen.

Contoh berikut adalah perubahan beban kerja dalam arsitektur ini yang harus Anda komunikasikan ke tim platform. Penting bagi tim platform untuk memvalidasi keandalan, keamanan, operasi, dan target performa layanan platform terhadap perubahan tim beban kerja baru 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 kemungkinan tidak akan mengalami perubahan signifikan dalam pola lalu lintas keluar.

• Akses publik: Perubahan akses publik ke komponen beban kerja mungkin memerlukan pengujian lebih lanjut. 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 jika portal AI berbasis browser diubah untuk diekspos ke internet, yang tidak disarankan.

• Peringkat kekritisan bisnis: Jika ada perubahan pada perjanjian tingkat layanan (SLA) beban kerja, Anda mungkin memerlukan pendekatan kolaborasi baru antara platform dan tim beban kerja.

  Contoh: Beban kerja Anda dapat beralih dari bisnis rendah ke tinggi secara kritis dengan peningkatan adopsi dan keberhasilan beban kerja.

Arsitektur ini selaras dengan jaminan keandalan dalam arsitektur garis besar. Tidak ada pertimbangan keandalan baru untuk komponen beban kerja inti.

Tujuan tingkat layanan komposit (SLO) maksimum yang mungkin untuk arsitektur ini lebih rendah dari tujuan tingkat layanan komposit dasar (SLO) karena komponen baru seperti kontrol jaringan keluar. Komponen-komponen ini, umum di lingkungan zona pendaratan, tidak unik untuk arsitektur ini. SLO juga berkurang jika tim beban kerja secara langsung mengontrol layanan Azure ini.

Lihat semua fungsionalitas yang dilakukan beban kerja di platform dan zona pendaratan aplikasi sebagai dependensi. Rencana respons insiden mengharuskan tim beban kerja mengetahui titik dan metode informasi kontak untuk dependensi ini. Sertakan juga dependensi ini dalam analisis mode kegagalan beban kerja (FMA).

Untuk arsitektur ini, pertimbangkan dependensi beban kerja berikut:

• Firewall keluar: Firewall keluar terpusat, dibagikan oleh beberapa beban kerja, mengalami perubahan yang tidak terkait dengan beban kerja.

• Resolusi DNS: Arsitektur ini menggunakan DNS yang disediakan oleh tim platform alih-alih langsung berinteraksi dengan Azure DNS. Ini berarti bahwa pembaruan tepat waktu untuk catatan DNS untuk titik akhir privat dan ketersediaan layanan DNS adalah dependensi baru.

• Kebijakan DINE: Kebijakan DINE untuk zona DNS privat Azure DNS, atau dependensi lain yang disediakan platform, adalah upaya terbaik, tanpa SLA saat Anda menerapkannya. Misalnya, penundaan konfigurasi DNS untuk titik akhir privat arsitektur ini dapat menyebabkan keterlambatan kesiapan UI obrolan untuk menangani lalu lintas atau alur prompt dari menyelesaikan kueri.

• Kebijakan grup manajemen: Kebijakan yang konsisten di antara lingkungan adalah kunci untuk keandalan. Pastikan bahwa lingkungan praproduksi mirip dengan lingkungan produksi untuk memberikan pengujian yang akurat dan untuk 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, tetapi beban kerja dan tim platform perlu secara kolaboratif mengatasi masalah ini untuk memastikan bahwa kebutuhan terpenuhi. Untuk informasi selengkapnya, lihat Rekomendasi untuk melakukan analisis mode kegagalan.

Rekomendasi di bagian berikut didasarkan pada daftar periksa tinjauan desain keamanan di Well-Architected Framework.

Isolasi beban kerja Anda dari spoke beban kerja lain dalam organisasi Anda dengan menggunakan NSG pada subnet Anda dan 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, tim beban kerja 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.

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 memiliki tanggung jawab untuk menghentikan lalu lintas keluar yang tidak diinginkan sedekat sumber yang dapat dipraktekkan.

Meskipun Anda memiliki subnet beban kerja dalam jaringan virtual, 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 masih kompatibel dengan permintaan asli Anda. Bekerja dengan tim jaringan Anda untuk memastikan kelangsungan kontrol keluar akses paling sedikit.

Tabel berikut menunjukkan contoh egress dalam arsitektur ini.

Untuk lalu lintas yang meninggalkan jaringan virtual arsitektur ini, kontrol paling baik diterapkan pada tingkat beban kerja melalui NSG dan di tingkat platform melalui firewall jaringan hub. NSG menyediakan aturan lalu lintas jaringan luas awal yang lebih dipersempit oleh aturan firewall tertentu di jaringan hub platform untuk keamanan tambahan. Tidak ada harapan bahwa lalu lintas timur-barat dalam komponen beban kerja, seperti antara studio Pembelajaran Mesin dan akun Penyimpanan dalam arsitektur ini, harus dirutekan melalui hub.

Tentukan siapa yang harus menerapkan paket DDoS Protection yang mencakup semua alamat IP publik solusi Anda. Tim platform mungkin menggunakan paket perlindungan alamat IP, atau menggunakan Azure Policy untuk memberlakukan rencana perlindungan jaringan virtual. Arsitektur ini harus memiliki cakupan karena melibatkan alamat IP publik untuk masuk dari internet. Untuk informasi selengkapnya, lihat Rekomendasi untuk jaringan dan konektivitas.

Kecuali jika diperlukan oleh otomatisasi tata kelola tim platform Anda, tidak ada harapan persyaratan otorisasi ekstra pada arsitektur ini karena keterlibatan tim platform. Kontrol akses berbasis peran Azure (RBAC) harus terus memenuhi prinsip hak istimewa paling sedikit, yang memberikan akses terbatas hanya kepada mereka yang membutuhkannya dan hanya jika diperlukan. Untuk informasi selengkapnya, lihat Rekomendasi untuk manajemen identitas dan akses.

Tim beban kerja biasanya mendapatkan sertifikat TLS untuk alamat IP publik di Application Gateway dalam arsitektur ini. Bekerja sama dengan tim platform Anda untuk memahami bagaimana proses pengadaan dan manajemen sertifikat harus selaras dengan harapan organisasi.

Semua layanan penyimpanan data dalam arsitektur ini mendukung kunci enkripsi yang dikelola oleh Microsoft atau oleh pelanggan. Gunakan kunci enkripsi yang dikelola pelanggan jika desain atau organisasi beban kerja Anda memerlukan kontrol lebih. Zona pendaratan Azure sendiri tidak mengamanatkan satu atau yang lain.

Untuk sumber daya beban kerja, semua strategi pengoptimalan biaya dalam arsitektur garis besar juga berlaku untuk arsitektur ini.

Arsitektur ini sangat mendapat manfaat dari sumber daya platform zona pendaratan Azure. 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 SLO, tujuan waktu pemulihan (RTO), atau tujuan titik pemulihan (RPO).

Tim beban kerja masih bertanggung jawab atas semua pertimbangan keunggulan operasional yang tercakup dalam arsitektur garis besar, seperti pemantauan, GenAIOps, jaminan kualitas, dan praktik penyebaran yang aman.

Log dan metrik beban kerja serta komponen infrastrukturnya disimpan di ruang kerja Azure Monitor Logs beban kerja. Namun, log dan metrik dari layanan terpusat, seperti Azure Firewall, DNS Private Resolver, dan Azure Bastion, sering disimpan di ruang kerja Azure Monitor Logs pusat. Menghubungkan data dari beberapa sink bisa menjadi tugas yang kompleks.

Data berkorelasi sering digunakan selama respons insiden. Pastikan runbook triase untuk arsitektur ini mengatasi situasi ini dan menyertakan titik 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.

Banyak layanan dalam arsitektur ini menggunakan titik akhir privat. Mirip dengan arsitektur garis besar, desain ini berpotensi menjadikan agen build sebagai persyaratan arsitektur ini. Penyebaran agen build yang aman dan andal adalah tanggung jawab tim beban kerja, tanpa keterlibatan tim platform. Namun, pastikan bahwa manajemen agen build mematuhi organisasi. Misalnya, gunakan gambar sistem operasi yang disetujui platform, jadwal patching, pelaporan kepatuhan, dan metode autentikasi pengguna.

Pertimbangan efisiensi performa yang dijelaskan dalam arsitektur garis besar juga berlaku untuk arsitektur ini. Tim beban kerja mempertahankan kontrol atas sumber daya yang digunakan dalam alur permintaan, bukan tim platform. Skalakan host UI obrolan, host alur prompt, model bahasa, dan 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 berasal dari tata kelola penahanan biaya

Penyebaran zona pendaratan untuk arsitektur referensi ini tersedia di GitHub.

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

• Chad Kittel | Pola & praktik Azure - Microsoft
• Freddy Ayala | Arsitek Solusi Cloud Microsoft

Untuk melihat profil LinkedIn nonpublik, masuk ke LinkedIn.

Tinjau kolaborasi dan detail teknis yang dibagikan antara tim beban kerja dan tim platform.