Arsitektur beban kerja yang melibatkan Azure OpenAI Service dapat sesederhana satu atau beberapa aplikasi klien secara langsung menggunakan satu penyebaran model Azure OpenAI secara langsung, tetapi tidak semua beban kerja dapat dirancang dengan sederhana seperti itu. Skenario yang lebih kompleks termasuk topologi dengan beberapa klien, beberapa penyebaran Azure OpenAI, atau beberapa instans Azure OpenAI. Dalam situasi tersebut, memperkenalkan gateway di depan Azure OpenAI dapat bermanfaat bagi desain beban kerja.
Beberapa instans Atau penyebaran model Azure OpenAI menyelesaikan persyaratan tertentu dalam arsitektur beban kerja. Mereka dapat diklasifikasikan dalam empat topologi utama.
- Beberapa penyebaran model dalam satu instans Azure OpenAI
- Beberapa instans Azure OpenAI dalam satu wilayah dan satu langganan
- Beberapa instans Azure OpenAI dalam satu wilayah di beberapa langganan
- Beberapa instans Azure OpenAI di beberapa wilayah
Topologi ini sendiri tidak mengharuskan penggunaan gateway. Pilihan gateway bergantung pada apakah beban kerja mendapat manfaat dari penyertaannya dalam arsitektur. Artikel ini menjelaskan tantangan yang ditangani masing-masing dari empat topologi, dan manfaat dan biaya termasuk gateway di setiap topologi.
Tip
Kecuali dinyatakan lain, panduan berikut cocok untuk gateway berbasis Azure API Management atau gateway kode kustom. Diagram arsitektur mewakili komponen gateway secara umum dalam sebagian besar situasi untuk mengilustrasikan hal ini.
Beberapa penyebaran model dalam satu instans Azure OpenAI
Detail topologi untuk beberapa penyebaran model
- Penyebaran model Azure OpenAI: beberapa
- Instans Azure OpenAI: satu
- Langganan: satu
- Wilayah: satu
Kasus penggunaan topologi untuk beberapa penyebaran model
Topologi yang menyertakan satu instans Azure OpenAI tetapi berisi lebih dari satu model yang disebarkan secara bersamaan mendukung kasus penggunaan berikut:
Mengekspos kemampuan model yang berbeda, seperti
gpt-35-turbo, ,gpt-4dan model kustom yang disempurnakan.Mengekspos versi model yang berbeda, seperti
0613, ,1106dan model kustom yang disempurnakan untuk mendukung evolusi beban kerja atau penyebaran biru-hijau.Mengekspos kuota berbeda yang ditetapkan (30.000 Token-Per-Menit (TPM), 60.000 TPM) untuk mendukung pembatasan konsumsi di beberapa klien.
Memperkenalkan gateway untuk beberapa penyebaran model
Memperkenalkan gateway ke dalam topologi ini terutama dimaksudkan untuk mengabstraksi klien dari memilih sendiri instans model tertentu di antara penyebaran yang tersedia pada instans. Gateway memungkinkan kontrol sisi server untuk mengarahkan permintaan klien ke model tertentu tanpa perlu menyebarkan ulang kode klien atau mengubah konfigurasi klien.
Gateway sangat bermanfaat ketika Anda tidak mengontrol kode klien. Ini juga bermanfaat saat menyebarkan konfigurasi klien lebih kompleks atau berisiko daripada menyebarkan perubahan pada konfigurasi perutean gateway. Anda dapat mengubah model mana yang ditunjuk klien berdasarkan strategi peluncuran biru-hijau dari versi model Anda, seperti meluncurkan model baru yang disempurnakan atau berpindah dari versi X ke X+1 dari model yang sama.
Gateway juga dapat digunakan sebagai satu titik entri API yang memungkinkan gateway mengidentifikasi klien. Kemudian dapat menentukan penyebaran model mana yang digunakan untuk melayani permintaan berdasarkan identitas klien tersebut atau informasi lain dalam permintaan HTTP. Misalnya, dalam solusi multipenyewa, penyewa mungkin terbatas pada throughput tertentu, dan implementasi arsitektur adalah penyebaran model per penyewa dengan kuota tertentu. Dalam hal ini, perutean ke model penyewa akan menjadi tanggung jawab gateway berdasarkan informasi dalam permintaan HTTP.
Tip
Karena kunci API dan kontrol akses berbasis peran Azure (RBAC) diterapkan di tingkat instans Azure OpenAI dan bukan tingkat penyebaran model, menambahkan gateway dalam skenario ini memungkinkan Anda mengalihkan keamanan ke gateway. Gateway kemudian menyediakan segmentasi tambahan antara model yang disebarkan secara bersamaan yang tidak mungkin dikontrol melalui manajemen identitas dan akses (IAM) Azure OpenAI atau firewall IP.
Menggunakan gateway dalam topologi ini memungkinkan pelacakan penggunaan berbasis klien. Kecuali klien menggunakan perwakilan layanan Microsoft Entra yang berbeda, log akses untuk Azure OpenAI tidak akan dapat membedakan beberapa klien. Memiliki gateway di depan penyebaran memberi beban kerja Anda kesempatan untuk melacak penggunaan per klien di berbagai penyebaran model yang tersedia untuk mendukung model penagihan balik atau showback.
Tips untuk topologi beberapa penyebaran model
Meskipun gateway berada dalam posisi untuk sepenuhnya mengubah model mana yang digunakan, seperti
gpt-35-turbokegpt-4, perubahan itu kemungkinan akan dianggap sebagai perubahan yang melanggar pada klien. Jangan biarkan kemampuan fungsional baru gateway mengalihkan perhatian dari selalu melakukan praktik penyebaran yang aman untuk beban kerja ini.Topologi ini biasanya cukup mudah untuk diterapkan melalui kebijakan Azure API Management alih-alih solusi kode kustom.
Untuk mendukung penggunaan SDK asli dengan spesifikasi API Azure OpenAI yang diterbitkan, pertahankan kompatibilitas API dengan Azure OpenAI API. Situasi ini adalah kekhawatiran yang lebih besar ketika tim Anda tidak menulis semua kode klien beban kerja Anda. Saat memutuskan merancang API HTTP untuk gateway, pertimbangkan manfaat mempertahankan kompatibilitas API HTTP Azure OpenAI.
Meskipun topologi ini secara teknis mendukung kredensial klien pass-through (token akses atau kunci API) untuk instans Azure OpenAI, sangat mempertimbangkan untuk menerapkan penghentian kredensial dan membangun kembali. Dengan cara ini klien diotorisasi di gateway, lalu gateway diotorisasi melalui Azure RBAC ke instans Azure OpenAI.
Jika gateway dirancang untuk menggunakan kredensial pass-through, pastikan klien tidak dapat melewati gateway atau batasan model apa pun berdasarkan klien.
Sebarkan gateway Anda di wilayah yang sama dengan instans Azure OpenAI.
Sebarkan gateway ke dalam grup sumber daya khusus dalam langganan yang terpisah dari instans Azure OpenAI. Mengisolasi langganan dari ujung belakang dapat membantu mendorong pendekatan APIOps melalui pemisahan kekhawatiran.
Sebarkan gateway ke jaringan virtual yang berisi subnet untuk titik akhir privat Azure Private Link instans Azure OpenAI. Terapkan aturan kelompok keamanan jaringan (NSG) ke subnet tersebut untuk hanya mengizinkan akses gateway ke titik akhir privat tersebut. Semua akses data plane lainnya ke instans Azure OpenAI harus dilarang.
Alasan untuk menghindari gateway untuk beberapa penyebaran model
Jika mengontrol konfigurasi klien Anda semampu atau lebih mudah daripada mengontrol perutean di tingkat gateway, keandalan, keamanan, biaya, pemeliharaan, dan dampak performa gateway yang ditambahkan mungkin tidak sepadan dengan komponen arsitektur tambahan.
Selain itu, beberapa skenario beban kerja dapat memperoleh manfaat dari migrasi dari beberapa pendekatan penyebaran model ke beberapa pendekatan penyebaran instans Azure OpenAI. Misalnya, pertimbangkan beberapa instans Azure OpenAI jika Anda memiliki beberapa klien yang harus menggunakan RBAC yang berbeda atau kunci akses untuk mengakses model mereka. Menggunakan beberapa penyebaran dalam satu instans Azure OpenAI dan menangani segmentasi identitas logis di tingkat gateway dimungkinkan, tetapi mungkin berlebihan ketika pendekatan segmentasi RBAC fisik tersedia dengan menggunakan instans Azure OpenAI yang berbeda.
Beberapa instans Azure OpenAI dalam satu wilayah dan satu langganan
Detail topologi untuk beberapa instans dalam satu wilayah dan satu langganan
- Penyebaran model Azure OpenAI: satu atau beberapa
- Instans Azure OpenAI: beberapa
- Langganan: satu
- Wilayah: satu
Kasus penggunaan topologi untuk beberapa instans dalam satu wilayah dan satu langganan
Topologi yang menyertakan beberapa instans Azure OpenAI dalam satu wilayah dan satu langganan mendukung kasus penggunaan berikut:
Mengaktifkan batas segmentasi keamanan, seperti kunci atau RBAC per klien
Mengaktifkan model penagihan balik yang mudah untuk klien yang berbeda
Mengaktifkan strategi failover untuk ketersediaan Azure OpenAI, seperti pemadaman platform yang memengaruhi instans tertentu, kesalahan konfigurasi jaringan, atau penyebaran yang dihapus secara tidak sengaja
Mengaktifkan strategi failover untuk ketersediaan kuota Azure OpenAI, seperti memasangkan instans berbasis PTU dan instans berbasis konsumsi untuk spillover
Memperkenalkan gateway untuk beberapa instans dalam satu wilayah dan langganan
Model mungkin tidak dapat diakses oleh klien karena beberapa alasan. Alasan ini termasuk gangguan di Azure OpenAI Service, permintaan pembatasan Azure OpenAI, atau masalah yang terkait dengan operasi beban kerja seperti kesalahan konfigurasi jaringan atau penghapusan penyebaran model yang tidak disengaja. Untuk mengatasi tantangan ini, Anda harus menerapkan logika coba lagi dan pemutusan sirkuit.
Logika ini dapat diimplementasikan di klien atau sisi server di gateway. Menerapkan logika di gateway mengabstraksi logika dari klien, menghasilkan tidak ada kode berulang dan satu tempat untuk menguji logika. Tidak peduli apakah Anda memiliki kode klien atau tidak, pergeseran ini dapat meningkatkan keandalan beban kerja.
Menggunakan gateway dengan beberapa instans Azure OpenAI dalam satu wilayah dan langganan memungkinkan Anda memperlakukan semua ujung belakang sebagai penyebaran aktif-aktif dan tidak hanya menggunakannya dalam failover pasif aktif. Anda dapat menyebarkan model berbasis PTU yang sama di beberapa instans Azure OpenAI dan menggunakan gateway untuk menyeimbangkan beban di antara mereka.
Catatan
Kuota berbasis konsumsi adalah tingkat langganan, bukan tingkat instans Azure OpenAI. Penyeimbangan beban terhadap instans berbasis konsumsi dalam langganan yang sama tidak mencapai throughput tambahan.
Salah satu opsi yang dimiliki tim beban kerja saat menyediakan Azure OpenAI adalah memutuskan apakah model penagihan dan throughput berbasis PTU atau berbasis konsumsi. Strategi pengoptimalan biaya untuk menghindari pemborosan melalui PTU yang tidak digunakan adalah dengan sedikit memprovisikan instans PTU dan juga menyebarkan instans berbasis konsumsi di sampingnya. Tujuan dengan topologi ini adalah agar klien terlebih dahulu mengonsumsi semua PTU yang tersedia dan kemudian "meledak" ke penyebaran berbasis konsumsi untuk kelebihan penggunaan. Bentuk keuntungan failover yang direncanakan ini dari alasan yang sama seperti yang disebutkan dalam paragraf pembukaan bagian ini: menjaga kompleksitas ini dari kode klien.
Saat gateway terlibat, gateway berada dalam posisi unik untuk menangkap detail tentang semua klien penyebaran model yang berinteraksi. Meskipun setiap instans Azure OpenAI dapat mengambil telemetrinya sendiri, melakukannya dalam gateway memungkinkan tim beban kerja menerbitkan telemetri dan respons kesalahan di semua model yang digunakan ke satu penyimpanan, yang membuat dasbor terpadu dan pemberitahuan lebih mudah.
Tips untuk beberapa instans dalam satu wilayah dan topologi langganan
Pastikan gateway menggunakan informasi yang
Retry-Aftertersedia dalam respons HTTP dari Azure OpenAI saat mendukung skenario failover di gateway. Gunakan informasi otoritatif tersebut untuk mengontrol implementasi pemutus sirkuit Anda. Jangan terus-menerus mencapai titik akhir yang mengembalikan429 Too Many Requests. Sebagai gantinya, putuskan sirkuit untuk instans model tersebut.Mencoba memprediksi peristiwa pembatasan sebelum terjadi dengan melacak konsumsi model melalui permintaan sebelumnya dimungkinkan di gateway, tetapi penuh dengan kasus tepi. Dalam kebanyakan kasus, yang terbaik adalah tidak mencoba memprediksi, tetapi menggunakan kode respons HTTP untuk mendorong keputusan perutean di masa mendatang.
Saat round-robining atau failover ke titik akhir yang berbeda, termasuk PTU yang meluap ke konsumsi, selalu pastikan titik akhir tersebut menggunakan model yang sama pada versi yang sama. Misalnya, jangan melakukan failover dari
gpt-4kegpt-35-turboatau dari versi X ke versi X+1 atau keseimbangan beban di antara mereka. Perubahan versi ini dapat menyebabkan perilaku tak terduga pada klien.Penyeimbangan beban dan logika failover dapat diterapkan dalam kebijakan Azure API Management. Anda mungkin dapat memberikan pendekatan yang lebih canggih menggunakan solusi gateway berbasis kode, tetapi API Management cukup untuk kasus penggunaan ini.
Sebarkan gateway Anda di wilayah yang sama dengan instans Azure OpenAI.
Sebarkan gateway ke dalam grup sumber daya khusus dalam langganan yang terpisah dari instans Azure OpenAI. Memiliki gateway yang terisolasi dari ujung belakang dapat membantu mendorong pendekatan APIOps melalui pemisahan kekhawatiran.
Kolokasikan semua titik akhir privat Private Link instans Azure OpenAI ke dalam satu subnet di jaringan virtual gateway. Terapkan aturan NSG ke subnet tersebut untuk hanya mengizinkan akses gateway ke titik akhir privat tersebut. Semua akses data plane lainnya ke instans Azure OpenAI harus dilarang.
Untuk menyederhanakan logika dalam kode perutean gateway Anda, gunakan nama penyebaran model yang sama untuk meminimalkan perbedaan antara rute HTTP. Misalnya, nama
gpt4-v1model dapat digunakan pada semua instans load balanced atau spillover, baik berbasis konsumsi maupun berbasis PTU.
Alasan untuk menghindari gateway untuk beberapa instans dalam satu wilayah dan langganan
Gateway itu sendiri tidak meningkatkan kemampuan untuk menagih kembali model terhadap klien yang berbeda untuk topologi khusus ini. Dalam topologi ini, klien dapat diberikan akses ke instans Azure OpenAI khusus mereka sendiri, yang akan mendukung kemampuan tim beban kerja Anda untuk melakukan penagihan balik atau showback. Model ini mendukung identitas unik dan perimeter jaringan, sehingga gateway tidak perlu diperkenalkan khusus untuk segmentasi.
Jika Anda memiliki beberapa klien di area tempat Anda mengontrol kode, dan klien mudah diperbarui, logika yang harus Anda bangun ke gateway dapat ditambahkan langsung ke dalam kode. Pertimbangkan untuk menggunakan pendekatan gateway untuk failover atau penyeimbangan beban terutama ketika Anda tidak memiliki kode klien atau kompleksitas terlalu banyak untuk ditangani klien.
Beberapa instans Azure OpenAI dalam satu wilayah di beberapa langganan
Detail topologi untuk beberapa instans Azure OpenAI dalam satu wilayah di beberapa langganan
- Penyebaran model Azure OpenAI: satu atau beberapa
- Instans Azure OpenAI: beberapa
- Langganan: beberapa
- Wilayah: satu
Kasus penggunaan topologi untuk beberapa instans Azure OpenAI dalam satu wilayah di beberapa langganan
Topologi yang menyertakan beberapa instans Azure OpenAI dalam satu wilayah di beberapa langganan mendukung kasus penggunaan berikut:
Mencakup semua kasus penggunaan yang tercantum untuk beberapa instans Azure OpenAI dalam satu wilayah dan satu langganan.
Memungkinkan Anda mendapatkan lebih banyak kuota berbasis konsumsi, karena batas langganan adalah faktor yang tersedia untuk model konsumsi. Anda dapat menggunakan kuota tambahan ini untuk mendukung konsumsi yang sangat bersamaan.
Memperkenalkan gateway untuk beberapa instans dalam satu wilayah dan beberapa langganan
Alasan yang sama yang tercakup dalam Memperkenalkan gateway untuk beberapa instans dalam satu wilayah dan langganan berlaku untuk topologi ini.
Selain alasan tersebut, menambahkan gateway dalam topologi ini juga mendukung tim terpusat yang menyediakan model "Azure OpenAI as a service" untuk organisasi mereka. Karena kuota berbasis konsumsi terikat langganan, tim terpusat yang menyediakan layanan Azure OpenAI yang menggunakan model berbasis konsumsi harus menyebarkan instans Azure OpenAI di beberapa langganan untuk mendapatkan kuota yang diperlukan. Logika gateway masih sebagian besar tetap sama.
Tips untuk beberapa instans dalam satu wilayah dan beberapa topologi langganan
Idealnya langganan semuanya harus didukung dengan penyewa Microsoft Entra yang sama untuk mendukung konsistensi di Azure RBAC dan Azure Policy.
Sebarkan gateway Anda di wilayah yang sama dengan instans Azure OpenAI.
Sebarkan gateway ke langganan khusus yang terpisah dari instans Azure OpenAI. Ini membantu memberlakukan konsistensi dalam mengatasi instans Azure OpenAI dan menyediakan segmentasi tugas logis antara penyebaran Azure OpenAI dan peruteannya.
Saat merutekan permintaan dari gateway Anda di seluruh langganan, pastikan titik akhir privat dapat dijangkau. Anda dapat menggunakan perutean transitif melalui hub ke titik akhir privat untuk ujung belakang di spoke masing-masing. Anda mungkin dapat mengekspos titik akhir privat untuk layanan Azure OpenAI langsung di langganan gateway dengan menggunakan koneksi Private Link di seluruh langganan. Koneksi Private Link lintas langganan lebih disukai jika arsitektur dan organisasi Anda mendukung pendekatan ini.
Alasan untuk menghindari gateway untuk beberapa instans dalam satu wilayah dan beberapa langganan
Semua alasan untuk menghindari gateway untuk beberapa instans dalam satu wilayah dan langganan berlaku untuk topologi ini.
Beberapa instans Azure OpenAI di beberapa wilayah
Detail topologi untuk beberapa instans Azure OpenAI di beberapa wilayah
- Penyebaran model Azure OpenAI: beberapa
- Instans Azure OpenAI: beberapa
- Langganan: satu atau beberapa
- Wilayah: beberapa
Kasus penggunaan topologi untuk beberapa instans Azure OpenAI di beberapa wilayah
Topologi yang mencakup beberapa instans Azure OpenAI yang tersebar di dua wilayah Azure atau lebih mendukung kasus penggunaan berikut:
Mencakup semua kasus penggunaan yang tercantum untuk beberapa instans Azure OpenAI dalam satu wilayah di beberapa langganan.
Mengaktifkan strategi failover untuk ketersediaan layanan, seperti menggunakan pasangan lintas wilayah.
Mengaktifkan residensi data dan desain kepatuhan.
Mengaktifkan ketersediaan model campuran. Beberapa wilayah memiliki model yang berbeda dan kuota yang berbeda yang tersedia untuk model.
Meskipun secara teknis tidak berbeda wilayah Azure, topologi ini juga berlaku ketika Anda memiliki model AI yang diekspos dalam situasi lintas premsise, seperti lokal atau di cloud lain.
Memperkenalkan gateway untuk beberapa instans di beberapa wilayah
Untuk arsitektur penting bisnis yang harus bertahan dari pemadaman regional lengkap, gateway terpadu global membantu menghilangkan logika failover dari kode klien. Implementasi ini mengharuskan gateway tetap tidak terpengaruh oleh pemadaman regional.
Penyeimbangan beban di seluruh wilayah tidak khas, tetapi dapat digunakan secara strategis untuk menggabungkan kuota yang tersedia dalam penyebaran berbasis konsumsi di seluruh wilayah. Skenario ini tidak mengharuskan gateway tetap tidak terpengaruh oleh pemadaman regional, tetapi kami merekomendasikannya untuk keandalan beban kerja maksimum.
Menggunakan Azure API Management (Penyebaran wilayah tunggal)
Dalam topologi ini, Azure API Management digunakan khusus untuk teknologi gateway. Di sini, API Management disebarkan ke dalam satu wilayah. Dari instans gateway tersebut, Anda melakukan penyeimbangan beban aktif-aktif di seluruh wilayah. Kebijakan di gateway Anda mereferensikan semua instans Azure OpenAI. Gateway memerlukan garis pandang jaringan ke setiap ujung belakang di seluruh wilayah, baik melalui peering jaringan virtual lintas wilayah atau titik akhir privat. Panggilan dari gateway ini ke instans Azure OpenAI di wilayah lain dikenakan lebih banyak latensi jaringan dan biaya keluar.
Gateway Anda harus menghormati sinyal pembatasan dan ketersediaan dari instans Azure OpenAI dan menghapus ujung belakang yang rusak dari kumpulan hingga aman untuk membaca instans Azure OpenAI yang rusak atau dibatasi. Gateway harus mencoba kembali permintaan saat ini terhadap instans back-end lain di kumpulan karena kesalahan, sebelum kembali mengembalikan kesalahan gateway. Pemeriksaan kesehatan gateway harus memberi sinyal tidak sehat ketika tidak ada instans Azure OpenAI back-end yang tersedia.
Catatan
Gateway ini memperkenalkan satu titik kegagalan regional global dalam arsitektur Anda karena pemadaman layanan apa pun pada instans gateway Anda merender semua wilayah tidak dapat diakses. Jangan gunakan topologi ini untuk beban kerja penting bisnis atau di mana penyeimbangan beban berbasis klien sudah cukup.
Karena topologi ini memperkenalkan satu titik kegagalan (gateway), utilitas arsitektur khusus ini cukup terbatas. Model ini meminjamkan dirinya dengan baik untuk penagihan berbasis konsumsi di Azure OpenAI saat memprediksi alokasi PTU mungkin terbukti terlalu menantang.
Peringatan
Pendekatan ini tidak dapat digunakan dalam skenario yang melibatkan kepatuhan kedaulatan data jika salah satu wilayah Azure OpenAI mencakup batas geopolitik.
Varian pasif aktif
Model ini juga dapat digunakan untuk memberikan pendekatan pasif aktif untuk secara khusus menangani kegagalan regional hanya Azure OpenAI. Dalam mode ini, lalu lintas biasanya mengalir dari gateway ke instans Azure OpenAI di wilayah yang sama dengan layanan manajemen API. Instans Azure OpenAI itu akan menangani semua arus lalu lintas yang diharapkan tanpa kegagalan regional terjadi. Ini bisa berbasis PTU atau berbasis konsumsi, tergantung pada model penagihan pilihan Anda. Dalam kasus kegagalan regional hanya Azure OpenAI, gateway dapat mengalihkan lalu lintas ke wilayah lain dengan Azure OpenAI yang sudah disebarkan dalam mode konsumsi.
Menggunakan Azure API Management (Penyebaran multi-wilayah)
Untuk meningkatkan keandalan arsitektur berbasis Azure API Management sebelumnya, API Management mendukung penyebaran instans ke beberapa wilayah Azure. Opsi penyebaran ini memberi Anda satu sarana kontrol, melalui satu instans API Management, tetapi menyediakan gateway yang direplikasi di wilayah pilihan Anda. Dalam topologi ini, Anda menyebarkan komponen gateway ke setiap wilayah yang berisi instans Azure OpenAI yang menyediakan arsitektur gateway aktif-aktif.
Kebijakan seperti perutean dan logika penanganan permintaan direplikasi ke setiap gateway individual. Semua logika kebijakan harus memiliki logika bersyarat dalam kebijakan untuk memastikan bahwa Anda memanggil instans Azure OpenAI di wilayah yang sama dengan gateway saat ini. Untuk informasi selengkapnya, lihat Merutekan panggilan API ke layanan back end regional. Komponen gateway kemudian memerlukan garis pandang jaringan hanya untuk instans Azure OpenAI di wilayahnya sendiri, biasanya melalui titik akhir privat.
Catatan
Topologi ini tidak memiliki titik kegagalan global dari perspektif penanganan lalu lintas, tetapi arsitektur sebagian menderita satu titik kegagalan karena sarana kontrol Azure API Management hanya berada dalam satu wilayah. Mengevaluasi apakah batasan sarana kontrol mungkin melanggar standar bisnis atau misi penting Anda.
API Management menawarkan perutean nama domain global yang sepenuhnya memenuhi syarat (FQDN) di luar kotak berdasarkan latensi terendah. Gunakan fungsionalitas berbasis performa bawaan ini untuk penyebaran gateway aktif-aktif. Fungsionalitas bawaan ini membantu mengatasi performa dan menangani pemadaman gateway regional. Router global bawaan juga mendukung pengujian pemulihan bencana karena wilayah dapat disimulasikan melalui menonaktifkan gateway individual. Pastikan klien menghormati waktu hidup (TTL) pada FQDN dan memiliki logika coba lagi yang sesuai untuk menangani failover DNS baru-baru ini.
Jika Anda perlu memperkenalkan firewall aplikasi web ke dalam arsitektur ini, Anda masih dapat menggunakan solusi perutean FQDN bawaan sebagai asal ujung belakang untuk router global Anda yang mengimplementasikan firewall aplikasi web. Router global akan mendelegasikan tanggung jawab failover ke API Management. Atau, Anda dapat menggunakan FQDN gateway regional sebagai anggota kumpulan back-end. Dalam arsitektur terakhir itu, gunakan titik akhir bawaan /status-0123456789abcdef pada setiap gateway regional atau titik akhir API kesehatan kustom lainnya untuk mendukung failover regional. Jika tidak yakin, mulailah dengan pendekatan FQDN back-end asal tunggal.
Arsitektur ini berfungsi paling baik jika Anda dapat memperlakukan wilayah sebagai wilayah yang sepenuhnya tersedia atau sepenuhnya tidak tersedia. Ini berarti bahwa jika gateway API Management atau instans Azure OpenAI tidak tersedia, Anda ingin lalu lintas klien tidak lagi dirutekan ke gateway API Management di wilayah tersebut. Kecuali ketentuan lain dibuat, jika gateway regional masih menerima lalu lintas saat Azure OpenAI tidak tersedia, kesalahan harus disebarluaskan ke klien. Untuk menghindari kesalahan klien, lihat pendekatan yang ditingkatkan di gateway Aktif-aktif ditambah varian Azure OpenAI pasif aktif.
Jika suatu wilayah mengalami pemadaman gateway API Management atau ditandai sebagai tidak sehat, wilayah yang tersisa perlu menyerap 100% lalu lintas dari wilayah lain tersebut. Ini berarti Anda perlu menyediakan instans Azure OpenAI berbasis PTU secara berlebihan untuk menangani ledakan lalu lintas baru atau menggunakan pendekatan pasif aktif untuk failover. Gunakan kalkulator Kapasitas Azure OpenAI untuk perencanaan kapasitas.
Pastikan bahwa grup sumber daya yang berisi Azure API Management adalah lokasi yang sama dengan instans API Management itu sendiri untuk mengurangi radius ledakan pemadaman regional terkait yang memengaruhi kemampuan Anda untuk mengakses penyedia sumber daya untuk gateway Anda.
Peringatan
Pendekatan ini tidak dapat digunakan dalam skenario yang melibatkan kepatuhan residensi data jika salah satu wilayah gateway mencakup batas geopolitik.
Gateway aktif-aktif ditambah varian Azure OpenAI pasif aktif
Bagian sebelumnya membahas ketersediaan gateway dengan menyediakan topologi gateway aktif-aktif. Topologi ini menggabungkan gateway aktif-aktif dengan topologi Azure OpenAI aktif-pasif yang hemat biaya. Menambahkan logika pasif aktif ke gateway untuk melakukan failover ke penyebaran Azure OpenAI berbasis konsumsi dari penyebaran berbasis PTU dapat secara signifikan meningkatkan keandalan beban kerja. Model ini masih memungkinkan klien untuk menggunakan solusi perutean FQDN bawaan API Management untuk perutean berbasis performa.
Peringatan
Pendekatan aktif-aktif plus pasif ini tidak dapat digunakan dalam skenario yang melibatkan kepatuhan residensi data jika salah satu wilayah mencakup batas geopolitik.
Menggunakan gateway berkode kustom
Jika aturan perutean per gateway Anda terlalu kompleks bagi tim Anda untuk mempertimbangkan wajar sebagai kebijakan API Management, Anda perlu menyebarkan dan mengelola solusi Anda sendiri. Arsitektur ini harus merupakan penyebaran multi-wilayah gateway Anda, dengan satu unit skala yang sangat tersedia per wilayah. Anda perlu memajukan penyebaran tersebut dengan Azure Front Door (Anycast) atau Azure Traffic Manager (DNS), biasanya dengan menggunakan perutean berbasis latensi dan pemeriksaan kesehatan ketersediaan gateway yang sesuai.
Gunakan Azure Front Door jika Anda memerlukan firewall aplikasi web dan akses internet publik. Gunakan Traffic Manager jika Anda tidak memerlukan firewall aplikasi web dan DNS TTL sudah cukup. Saat memajukan instans gateway Anda dengan Azure Front Door (atau proksi terbalik apa pun), pastikan bahwa gateway tidak dapat dilewati. Buat instans gateway hanya tersedia melalui titik akhir privat saat Anda menggunakan Azure Front Door dan tambahkan validasi X_AZURE_FDID header HTTP di implementasi gateway Anda.
Tempatkan sumber daya per wilayah yang digunakan di gateway kustom Anda di grup sumber daya per wilayah. Melakukannya mengurangi radius ledakan pemadaman regional terkait yang memengaruhi kemampuan Anda untuk mengakses penyedia sumber daya untuk sumber daya gateway Anda di wilayah tersebut.
Anda juga dapat mempertimbangkan untuk memisahkan implementasi logika gateway Anda dengan API Management, untuk manfaat API Management lainnya, seperti TLS, autentikasi, pemeriksaan kesehatan, atau penyeimbangan beban round-robin. Melakukannya mengalihkan masalah API umum dari kode kustom di gateway Anda dan memungkinkan gateway Anda secara khusus mengatasi instans Azure OpenAI dan perutean penyebaran model.
Untuk kepatuhan residensi data, pastikan setiap batas geopolitik memiliki penyebaran arsitektur ini sendiri yang terisolasi dan klien hanya dapat mencapai titik akhir resmi mereka.
Alasan untuk menghindari gateway untuk beberapa instans di beberapa wilayah
Jangan terapkan gateway terpadu di seluruh wilayah geopolitik saat residensi dan kepatuhan data diperlukan. Melakukannya akan melanggar persyaratan residensi data. Gunakan gateway yang dapat diatasi secara individual per wilayah, dan ikuti panduan di salah satu bagian sebelumnya.
Jika klien tidak diharapkan untuk melakukan failover antar wilayah dan Anda memiliki kemampuan untuk memberi klien gateway tertentu untuk digunakan, maka gunakan beberapa gateway, satu per wilayah, dan ikuti panduan di salah satu bagian sebelumnya. Jangan mengikat ketersediaan wilayah lain ke wilayah yang berisi gateway Anda sebagai satu titik kegagalan.
Jangan terapkan gateway terpadu jika model dan versi Anda tidak tersedia di semua wilayah yang diekspos oleh gateway. Klien perlu dirutekan ke model yang sama dan versi model yang sama. Untuk gateway penyeimbang beban dan failover multi-wilayah, Anda perlu memilih model umum dan versi model yang tersedia di semua wilayah yang terlibat. Untuk informasi selengkapnya, lihat Ketersediaan model. Jika Anda tidak dapat menstandarkan pada model dan versi model, manfaat gateway terbatas.
Rekomendasi umum
Tidak peduli topologi mana yang dibutuhkan beban kerja Anda, ada beberapa rekomendasi lintas pemotongan yang perlu dipertimbangkan saat membangun solusi gateway Anda.
Interaksi stateful
Saat klien menggunakan fitur stateful Azure OpenAI, seperti Assistants API, Anda perlu mengonfigurasi gateway Anda untuk menyematkan klien ke back end tertentu selama interaksi tersebut. Melakukannya dapat dicapai dengan menyimpan data instans dalam cookie. Dalam skenario ini, pertimbangkan untuk mengembalikan respons Azure OpenAI API seperti ke klien yang 429 disematkan alih-alih mengalihkannya ke instans Azure OpenAI yang berbeda. Melakukannya memungkinkan klien untuk secara eksplisit menangani ketidaktersediaan tiba-tiba versus menyembunyikannya dan dirutekan ke instans model yang tidak memiliki riwayat.
Pemeriksaan kesehatan gateway
Ada dua perspektif pemeriksaan kesehatan yang perlu dipertimbangkan, terlepas dari topologi.
Jika gateway Anda dibangun di sekitar round-robining atau melakukan failover ketersediaan layanan secara ketat, Anda ingin cara untuk mengeluarkan instans Azure OpenAI (atau model) dari status ketersediaan. Azure OpenAI tidak menyediakan titik akhir pemeriksaan kesehatan apa pun untuk mengetahui apakah tersedia untuk menangani permintaan. Anda dapat mengirim transisi sintetis melalui, tetapi itu mengonsumsi kapasitas model. Kecuali Anda memiliki sumber sinyal andal lain untuk instans Azure OpenAI dan ketersediaan model, gateway Anda kemungkinan harus mengasumsikan instans Azure OpenAI aktif dan kemudian menangani 429, 500, 503 kode status HTTP sebagai sinyal ke pemutusan sirkuit untuk permintaan di masa mendatang pada instans atau model tersebut selama beberapa waktu. Untuk situasi pembatasan, selalu hormati data di header yang Retry-After ditemukan di respons Azure OpenAI API untuk 429 kode respons di logika pemutusan sirkuit Anda. Jika Anda menggunakan Azure API Management, evaluasi menggunakan fungsionalitas pemutus arus bawaan.
Klien atau tim operasi beban kerja Anda mungkin ingin memiliki pemeriksaan kesehatan yang terekspos di gateway Anda untuk tujuan perutean atau introspeksi mereka sendiri. Jika Anda menggunakan API Management, default /status-0123456789abcdef mungkin tidak cukup rinci karena sebagian besar membahas instans gateway API Management, bukan back end Anda. Pertimbangkan untuk menambahkan API pemeriksaan kesehatan khusus yang dapat mengembalikan data yang bermakna kepada klien atau sistem pengamatan pada ketersediaan gateway atau rute tertentu di gateway.
Praktik penyebaran yang aman
Anda dapat menggunakan implementasi gateway untuk mengatur penyebaran biru-hijau dari model yang diperbarui. Model Azure OpenAI diperbarui dengan versi model baru dan model baru, dan Anda mungkin memiliki model baru yang disempurnakan.
Setelah menguji efek perubahan praproduksi, evaluasi apakah klien produksi harus "dipotong" ke versi model baru atau alih-alih mengalihkan lalu lintas. Pola gateway yang dijelaskan sebelumnya memungkinkan back end untuk menyebarkan kedua model secara bersamaan. Menyebarkan model secara bersamaan memberikan daya ke gateway untuk mengalihkan lalu lintas berdasarkan praktik penyebaran aman tim beban kerja dari peluncuran bertahap.
Bahkan jika Anda tidak menggunakan penyebaran biru-hijau, pendekatan APIOps beban kerja Anda perlu ditentukan dan cukup otomatis berkommiserasi dengan tingkat perubahan instans back-end dan penyebaran model Anda.
Implementasi yang cukup
Banyak skenario yang diperkenalkan dalam artikel ini membantu meningkatkan potensi tujuan tingkat layanan (SLO) beban kerja Anda dengan mengurangi kompleksitas klien dan menerapkan teknik pelestarian diri yang andal. Yang lain meningkatkan keamanan beban kerja dengan memindahkan kontrol akses ke model tertentu dari Azure OpenAI. Pastikan bahwa pengenalan gateway tidak berakhir penghitung kerja untuk tujuan ini. Pahami risiko menambahkan satu titik kegagalan baru baik melalui kesalahan layanan atau masalah konfigurasi yang disebabkan manusia di gateway, logika perutean yang kompleks, atau risiko mengekspos lebih banyak model ke klien yang tidak sah daripada yang dimaksudkan.
Kedaulatan data
Berbagai pendekatan aktif-aktif dan pasif perlu dievaluasi dari perspektif kepatuhan residensi data untuk beban kerja Anda. Banyak dari pola ini akan berlaku untuk arsitektur beban kerja Anda jika wilayah yang terlibat tetap berada dalam batas geopolitik. Untuk mendukung skenario ini, Anda perlu memperlakukan batas geopolitik sebagai stempel terisolasi dan menerapkan penanganan aktif-aktif atau pasif secara eksklusif dalam stempel tersebut.
Secara khusus, perutean berbasis performa apa pun perlu sangat diteliti untuk kepatuhan kedaulatan data. Dalam skenario kedaulatan data, Anda tidak dapat melayani klien dengan geografi lain dan tetap patuh. Semua arsitektur gateway yang melibatkan residensi data harus memberlakukan bahwa klien hanya menggunakan titik akhir di wilayah geopolitik mereka. Klien harus diblokir agar tidak menggunakan titik akhir gateway lain dan gateway itu sendiri tidak melanggar kepercayaan klien dengan membuat permintaan lintas geopolitik. Cara yang paling dapat diandalkan untuk menerapkan segmentasi ini adalah dengan membangun arsitektur Anda di sekitar gateway yang sepenuhnya independen dan sangat tersedia per wilayah geopolitik.
Otorisasi Azure OpenAI
Gateway perlu mengautentikasi dengan semua instans Azure OpenAI yang berinteraksi dengannya. Kecuali Anda merancang gateway untuk melakukan autentikasi pass-through, gateway harus menggunakan identitas terkelola untuk kredensialnya. Jadi setiap instans Azure OpenAI perlu mengonfigurasi RBAC dengan hak istimewa paling sedikit untuk identitas terkelola gateway. Untuk arsitektur aktif-aktif dan failover, pastikan identitas gateway memiliki izin yang setara di semua instans Azure OpenAI yang terlibat.
Kebijakan Azure
Konsistensi antara penyebaran model dan instans Azure OpenAI penting dalam situasi aktif-aktif atau pasif. Gunakan Azure Policy untuk membantu memberlakukan konsistensi antara berbagai instans Azure OpenAI atau penyebaran model. Jika kebijakan bawaan untuk Azure OpenAI tidak cukup untuk memastikan konsistensi di antara mereka, pertimbangkan untuk membuat atau menggunakan kebijakan kustom yang dibuat komunitas.
Redundansi gateway
Meskipun tidak spesifik untuk beberapa ujung belakang, implementasi gateway setiap wilayah harus selalu dibangun dengan redundansi dan sangat tersedia dalam unit skala. Pilih wilayah dengan zona ketersediaan dan pastikan gateway Anda tersebar di seluruh wilayah tersebut. Sebarkan beberapa instans gateway sehingga satu titik kegagalan terbatas pada pemadaman regional lengkap dan bukan kesalahan satu instans komputasi di gateway Anda. Untuk API Management, sebarkan dua unit atau lebih di dua zona atau lebih. Untuk implementasi kode kustom, sebarkan setidaknya tiga instans dengan distribusi upaya terbaik di seluruh zona ketersediaan.
Implementasi gateway
Azure tidak menawarkan solusi turn-key atau arsitektur referensi untuk membangun gateway seperti itu. Seperti disebutkan dalam artikel pengenalan, tim beban kerja Anda harus membangun dan mengoperasikan gateway ini. Berikut adalah beberapa contoh implementasi sampel yang didukung komunitas yang mencakup beberapa kasus penggunaan yang disebutkan sebelumnya. Pertimbangkan untuk mereferensikan sampel GitHub ini saat Anda membangun bukti konsep Anda sendiri.
| implementasi | Contoh |
|---|---|
| Azure API Management | Penyeimbangan beban cerdas untuk Azure OpenAI menggunakan Azure API Management - Repositori GitHub ini berisi kode kebijakan sampel dan instruksi untuk disebarkan ke langganan Anda. Penskalaan Azure OpenAI menggunakan Azure API Management - Repositori GitHub ini berisi kode kebijakan sampel dan instruksi untuk PTU dan tumpahan konsumsi. Ada juga beberapa kebijakan API Management yang didukung komunitas di repositori toolkit gateway GenAI. |
| Kode kustom | Penyeimbangan beban cerdas untuk Azure OpenAI menggunakan Azure Container Apps Repositori GitHub ini berisi sampel kode C# dan instruksi untuk membangun kontainer dan menyebarkan ke dalam langganan Anda. |
Langkah berikutnya
Memiliki implementasi gateway untuk beban kerja Anda memberikan manfaat di luar manfaat perutean beberapa back end taktis yang dijelaskan dalam artikel ini. Pelajari tentang tantangan utama lain yang dapat diselesaikan gateway.