Bagikan melalui

Keandalan di Azure API Management

Azure API Management adalah layanan terkelola penuh yang membantu organisasi menerbitkan, mengamankan, mengubah, memelihara, dan memantau API. Sebagai layanan Azure, API Management menyediakan berbagai kemampuan untuk mendukung persyaratan keandalan Anda.

Saat Anda menggunakan Azure, keandalan adalah tanggung jawab bersama. Microsoft menyediakan berbagai kemampuan untuk mendukung ketahanan dan pemulihan. Anda bertanggung jawab untuk memahami cara kerja kemampuan tersebut dalam semua layanan yang Anda gunakan, dan memilih kemampuan yang Anda butuhkan untuk memenuhi tujuan bisnis dan tujuan waktu aktif Anda.

Artikel ini menjelaskan cara membuat API Management tahan terhadap berbagai potensi pemadaman dan masalah, termasuk kesalahan sementara, pemadaman zona ketersediaan, pemadaman wilayah, dan pemeliharaan layanan. Ini juga menjelaskan bagaimana Anda dapat menggunakan cadangan untuk memulihkan dari jenis masalah lain, dan menyoroti beberapa informasi utama tentang perjanjian tingkat layanan (SLA) API Management.

Gambaran umum arsitektur keandalan

API Management menggunakan arsitektur berbasis unit skala untuk menyediakan redundansi dan skalabilitas bawaan. Saat Anda menerapkan instans API Management, Anda dapat mengonfigurasi satu atau lebih unit skala, atau unit. Setiap unit adalah representasi logis dari kapasitas yang berisi sumber daya komputasi yang diperlukan untuk menangani permintaan API.

Unit

Setiap unit terdiri dari dua sumber daya komputasi (VM atau server serupa, tergantung pada tingkat layanan) yang menangani permintaan API bersama-sama. Anda tidak melihat VM ini atau server lain. Platform ini secara otomatis mengelola pembuatan dan pemantauan kesehatan mereka. Jika satu sumber daya komputasi gagal, unit terus beroperasi tetapi pada kapasitas yang berkurang, memberikan beberapa perlindungan keandalan bawaan.

Saat Anda mengonfigurasi instans dengan dua unit atau lebih, unit yang tersedia bekerja sama untuk memproses permintaan dan menyediakan penyeimbangan beban otomatis. Jika salah satu unit menjadi tidak tersedia, unit yang tersisa terus menangani lalu lintas, tetapi dengan kapasitas yang berpotensi berkurang.

Untuk mendapatkan tingkat keandalan yang lebih tinggi, API Management mendukung distribusi unit di seluruh zona ketersediaan dalam suatu wilayah dan di beberapa wilayah.

Nota

API Management menggunakan unit untuk komponen-komponen gateway. Unit-unit tidak dapat diterapkan untuk portal pengembang atau lapisan manajemen.

Lapisan layanan

Tingkat layanan API Management memberikan tingkat keandalan yang berbeda:

  • Tingkat premium (klasik): Mendukung beberapa unit yang dapat didistribusikan di seluruh zona ketersediaan dan wilayah untuk ketahanan maksimum.

  • Tingkat premium v2: Mendukung beberapa unit yang dapat didistribusikan di seluruh zona ketersediaan. Saat ini tidak mendukung penyebaran lintas wilayah.

  • Tingkat dasar v2, Standar, dan Standar v2: Semua mendukung beberapa unit dalam satu pusat data. Mereka tidak mendukung zona ketersediaan atau penyebaran multi-wilayah.

  • Tingkat pengembang: Hanya mendukung satu unit dan tidak menyediakan zona ketersediaan atau dukungan multi-wilayah. Tingkat ini dirancang untuk skenario pengembangan dan pengujian. Ini tidak cocok untuk beban kerja produksi.

  • Tingkat konsumsi: Memiliki kemampuan ketahanan bawaan dan tahan terhadap berbagai kesalahan dalam satu pusat data Azure. Namun, tingkat Konsumsi tidak menyediakan dukungan untuk zona ketersediaan atau penyebaran multi-wilayah. Untuk memahami waktu aktif instans API Management tingkat Konsumsi yang diharapkan, tinjau perjanjian tingkat layanan (SLA).

Nota

Tingkat Pengembang dan Premium API Management mendukung gateway yang dihost sendiri, yang dapat Anda jalankan pada infrastruktur Anda sendiri. Saat Anda menggunakan gateway yang dihost sendiri, Anda bertanggung jawab untuk mengonfigurasinya untuk memenuhi persyaratan keandalan Anda. Gateway yang dihost sendiri berada di luar cakupan artikel ini.

Rekomendasi penyebaran produksi

Azure Well-Architected Framework memberikan rekomendasi dalam keandalan, performa, keamanan, biaya, dan operasi. Untuk memahami bagaimana area ini saling memengaruhi dan berkontribusi pada solusi API Management yang andal, lihat Praktik terbaik arsitektur untuk API Management.

Ketahanan terhadap kesalahan sementara

Kesalahan sementara adalah kegagalan yang bersifat sementara dan intermiten dalam komponen. Mereka sering terjadi di lingkungan terdistribusi seperti cloud, dan mereka adalah bagian normal dari operasi. Kesalahan sementara memperbaiki diri setelah waktu yang singkat. Penting bahwa aplikasi Anda dapat menangani kesalahan sementara, biasanya dengan mencoba kembali permintaan yang terpengaruh.

Semua aplikasi yang dihosting cloud harus mengikuti panduan penanganan kesalahan sementara Azure saat berkomunikasi dengan API, database, dan komponen lain yang dihosting cloud. Untuk informasi selengkapnya, lihat Rekomendasi untuk menangani kesalahan sementara.

Saat menggunakan API Management di depan API, Anda mungkin perlu mencoba kembali permintaan yang gagal karena kesalahan sementara. Untuk melindungi API backend Anda agar tidak kewalahan oleh terlalu banyak permintaan, API Management menyediakan kebijakan coba lagi, batas tarif, dan kuota. Anda juga dapat mengonfigurasi kemampuan load balancing dan pemutus sirkuit dengan menggunakan sumber daya backend.

Ketahanan terhadap kegagalan zona ketersediaan

Zona ketersediaan adalah grup pusat data yang terpisah secara fisik dalam wilayah Azure. Ketika satu zona gagal, layanan dapat melakukan failover ke salah satu zona yang tersisa.

Untuk melihat informasi tentang dukungan zona ketersediaan untuk tingkat Premium dan Premium v2, pastikan untuk memilih tingkat layanan yang sesuai di awal halaman ini.

API Management menyediakan dua jenis dukungan zona ketersediaan saat Anda menyebarkan instans API Management Premium (klasik) di wilayah yang didukung:

  • Otomatis (Disarankan): API Management menyediakan dukungan zona ketersediaan otomatis saat Anda tidak menentukan zona ketersediaan mana yang akan digunakan.

  • Manual: API Management menyediakan dukungan zona ketersediaan manual saat Anda secara eksplisit menentukan zona ketersediaan mana yang akan digunakan.

Dengan dukungan zona ketersediaan, API Management mereplikasi komponen layanan di seluruh zona untuk ketersediaan tinggi. Di wilayah utama, komponen-komponen ini termasuk gateway (unit skala), bidang manajemen, dan portal pengembang. Di wilayah sekunder, hanya unit gateway yang direplikasi. Untuk informasi selengkapnya tentang wilayah sekunder, lihat ketahanan terhadap kegagalan di seluruh wilayah.

Dukungan zona ketersediaan otomatis

Anda dapat menggunakan dukungan zona ketersediaan otomatis untuk memilih satu unit atau konfigurasi instans multiunit untuk mencapai redundansi zona:

  • Konfigurasi multi-unit (Disarankan): Jika instans Anda memiliki dua unit atau lebih, API Management melakukan upaya terbaik untuk menyebarkan unit instans Anda di antara zona ketersediaan wilayah. Anda tidak dapat menentukan zona ketersediaan mana unit Anda ditempatkan. Sebarkan minimal dua unit, yang dapat didistribusikan di dua zona.

    Diagram berikut menunjukkan instans API Management dengan tiga unit yang dikonfigurasi untuk dukungan zona ketersediaan otomatis:

    Diagram yang menunjukkan tiga unit API Management yang didistribusikan di seluruh zona ketersediaan untuk dukungan zona ketersediaan otomatis.

  • Konfigurasi unit tunggal: Jika instans Anda memiliki satu unit, sumber daya komputasi dasar unit didistribusikan ke dua zona ketersediaan. Anda tidak dapat menentukan zona ketersediaan mana sumber daya komputasi unit ditempatkan.

    Diagram yang menunjukkan satu unit API Management yang didistribusikan di dua zona ketersediaan untuk dukungan zona ketersediaan otomatis.

Dukungan zona ketersediaan manual

Jika Anda ingin secara eksplisit memilih zona ketersediaan yang akan digunakan, Anda dapat memilih antara konfigurasi zona-redundan dan zonal:

  • Zona-redundan: Konfigurasikan redundansi zona secara manual untuk instans API Management di wilayah yang didukung untuk menyediakan redundansi untuk komponen layanan. Saat Anda memilih dua atau beberapa zona ketersediaan untuk digunakan, Azure secara otomatis mereplikasi komponen layanan di seluruh zona yang dipilih.

    Diagram yang menunjukkan tiga unit API Management yang didistribusikan di seluruh zona ketersediaan untuk redundansi zona manual.

  • Zonal: Komponen layanan API Management disebarkan dalam satu zona yang Anda pilih dalam wilayah Azure. Semua unit ditempatkan ke zona ketersediaan yang sama.

    Diagram yang menunjukkan penyebaran API Management zonal yang memiliki dua unit, dalam satu zona ketersediaan.

    Penting

    Sematkan ke zona ketersediaan tunggal hanya jika latensi lintas zona terlalu tinggi untuk kebutuhan Anda dan setelah Anda memverifikasi bahwa latensi tidak memenuhi kebutuhan Anda. Dengan sendirinya, instans zonal tidak memberikan ketahanan terhadap pemadaman zona ketersediaan. Untuk meningkatkan ketahanan penyebaran API Management zonal, Anda perlu secara eksplisit menyebarkan instans terpisah ke beberapa zona ketersediaan dan mengonfigurasi perutean dan failover lalu lintas.

Di tingkat Premium v2, Anda dapat mengaktifkan redundansi zona untuk instans API Management di wilayah yang didukung.

Dengan dukungan zona ketersediaan, API Management mereplikasi gateway (unit skala), bidang manajemen, dan portal pengembang. Anda dapat memilih satu unit atau konfigurasi instans multiunit untuk mencapai redundansi zona:

  • Konfigurasi multi-unit (Disarankan): Jika instans Anda memiliki dua unit atau lebih, API Management melakukan upaya terbaik untuk menyebarkan unit instans Anda di antara zona ketersediaan wilayah. Anda tidak dapat menentukan zona ketersediaan mana unit Anda ditempatkan. Sebarkan minimal dua unit, yang dapat didistribusikan di dua zona.

    Diagram berikut menunjukkan instans API Management dengan tiga unit yang dikonfigurasi untuk dukungan zona ketersediaan:

    Diagram yang menunjukkan tiga unit API Management yang didistribusikan di seluruh zona ketersediaan.

  • Konfigurasi unit tunggal: Jika instans Anda memiliki satu unit, sumber daya komputasi dasar unit didistribusikan ke dua zona ketersediaan. Anda tidak dapat menentukan zona ketersediaan mana sumber daya komputasi unit ditempatkan.

    Diagram yang memperlihatkan satu unit API Management yang didistribusikan di dua zona ketersediaan.

Persyaratan

  • Dukungan wilayah: API Management mendukung zona ketersediaan untuk tingkat Premium (klasik) dan Premium v2 di wilayah tempat tingkat API Management tersedia dan wilayah tersebut mendukung zona ketersediaan.

  • Persyaratan tingkat: Anda harus menggunakan tingkat Premium (klasik) atau Premium v2 untuk mengonfigurasi dukungan zona ketersediaan. API Management saat ini tidak mendukung zona ketersediaan di tingkat Konsumsi, Pengembang, Dasar, dan Standar klasik atau di tingkat Dasar v2 dan Standar v2. Untuk opsi peningkatan, lihat Meningkatkan dan menskalakan instans API Management.

Pertimbangan

  • Jumlah unit untuk instans zona-redundan: Jika Anda mengonfigurasi redundansi zona secara manual untuk instans, Anda juga perlu mengonfigurasi sejumlah unit API Management yang dapat didistribusikan secara merata di semua zona ketersediaan yang Anda pilih. Misalnya, jika Anda memilih dua zona, Anda harus mengonfigurasi setidaknya dua unit. Anda dapat mengonfigurasi empat unit, atau kelipatan lain dari dua unit. Jika Anda memilih tiga zona ketersediaan, Anda harus mengonfigurasi tiga unit, enam unit, atau kelipatan lain dari tiga unit.

    Jika Anda menggunakan dukungan zona ketersediaan otomatis, tidak ada persyaratan untuk menggunakan jumlah unit tertentu. Unit yang Anda sebarkan didistribusikan di antara zona ketersediaan dengan cara upaya terbaik. Untuk redundansi zona maksimum, gunakan setidaknya dua unit sehingga pemadaman zona ketersediaan tidak memengaruhi performa gateway Anda.

    Untuk menentukan jumlah unit yang memberikan performa gateway yang diperlukan, gunakan metrik kapasitas dan pengujian Anda sendiri. Untuk informasi selengkapnya tentang penskalaan dan peningkatan instans layanan Anda, lihat Meningkatkan dan menskalakan instans API Management.

  • Autoscaling: Jika Anda mengonfigurasi zona ketersediaan secara manual pada instans API Management yang dikonfigurasi dengan autoscaling, Anda mungkin perlu menyesuaikan pengaturan skala otomatis setelah konfigurasi. Dalam hal ini, jumlah unit API Management dalam aturan dan batas skala otomatis harus berupa kelipatan jumlah zona. Jika Anda menggunakan dukungan zona ketersediaan otomatis, Anda tidak perlu menyesuaikan pengaturan skala otomatis Anda.

  • Persyaratan alamat IP: Saat Anda mengaktifkan dukungan zona ketersediaan pada instans API Management yang disebarkan di jaringan virtual eksternal atau internal, Anda harus menentukan sumber daya alamat IP publik untuk instans yang akan digunakan. Dalam jaringan virtual internal, alamat IP publik hanya digunakan untuk operasi manajemen, bukan untuk permintaan API. Untuk informasi selengkapnya, lihat Alamat IP di API Management.

Pertimbangan

  • Jumlah unit untuk instans yang memiliki redundansi zona: Di tingkat Premium v2, tidak ada persyaratan untuk menggunakan jumlah unit yang spesifik. Unit yang Anda sebarkan didistribusikan di antara zona ketersediaan dengan cara upaya terbaik. Untuk redundansi zona maksimum, gunakan setidaknya dua unit untuk memberikan kapasitas yang memadai sehingga pemadaman zona ketersediaan tidak memengaruhi performa gateway Anda.

    Untuk menentukan jumlah unit yang memberikan performa gateway yang diperlukan, gunakan metrik kapasitas dan pengujian Anda sendiri. Untuk informasi selengkapnya tentang penskalaan dan peningkatan instans layanan Anda, lihat Meningkatkan dan menskalakan instans API Management.

  • Autoscaling: Di tingkat Premium v2, Anda tidak perlu menyesuaikan pengaturan skala otomatis saat mengaktifkan dukungan zona ketersediaan.

Biaya

Terlepas dari konfigurasi zona ketersediaan Anda, jika Anda menambahkan lebih banyak unit, Anda dikenakan lebih banyak biaya. Untuk informasi, lihat Harga API Management.

Mengonfigurasi dukungan zona ketersediaan

Bagian ini menjelaskan cara mengonfigurasi dukungan zona ketersediaan untuk instans API Management Anda. Untuk informasi selengkapnya, lihat Mengaktifkan dukungan zona ketersediaan pada instans API Management.

  • Buat instans API Management yang mendukung zona ketersediaan: Saat Anda membuat instans API Management Premium (klasik) di wilayah yang mendukung zona ketersediaan, instans mendukung zona ketersediaan secara default. Anda dapat memilih dukungan zona ketersediaan otomatis atau mengonfigurasi dukungan zonal atau zona-redundan secara manual.

    Nota

    Saat Anda memilih zona ketersediaan mana yang akan digunakan, Anda benar-benar memilih zona ketersediaan logis. Jika Anda menyebarkan komponen beban kerja lain di langganan Azure yang berbeda, mereka mungkin menggunakan nomor zona ketersediaan logis yang berbeda untuk mengakses zona ketersediaan fisik yang sama. Untuk informasi selengkapnya, lihat Zona ketersediaan fisik dan logis.

  • Mengaktifkan atau mengonfigurasi ulang dukungan zona ketersediaan: Anda dapat mengubah konfigurasi zona ketersediaan untuk instans API Management, termasuk menambahkan zona ketersediaan dan memindahkan instans zona di antara zona ketersediaan. Untuk mempelajari cara mengonfigurasi dukungan zona ketersediaan pada instans API Management, lihat Mengaktifkan dukungan zona ketersediaan pada instans API Management. Tidak ada opsi konfigurasi yang memerlukan waktu henti.

    Saat Anda mengubah konfigurasi zona ketersediaan, perubahan dapat memakan waktu 15 hingga 45 menit atau lebih untuk diterapkan. Gateway API Management dapat terus menangani permintaan API selama waktu ini.

    Mengubah konfigurasi zona ketersediaan memicu perubahan alamat IP publik dan privat.

Mengonfigurasi dukungan zona ketersediaan

Bagian ini menjelaskan cara mengonfigurasi dukungan zona ketersediaan untuk instans API Management Anda. Untuk informasi selengkapnya, lihat Mengaktifkan dukungan zona ketersediaan pada instans API Management.

  • Buat instans API Management yang mendukung zona ketersediaan: Di tingkat Premium v2, aktifkan redundansi zona secara opsional saat Anda membuat instans API Management di wilayah yang mendukung zona ketersediaan. Jika redundansi zona tidak dapat diaktifkan karena kendala kapasitas atau masalah lainnya, penyebaran layanan gagal.

  • Mengaktifkan atau mengonfigurasi ulang dukungan zona ketersediaan: Anda tidak dapat mengubah konfigurasi zona ketersediaan setelah instans dibuat.

Perencanaan dan manajemen kapasitas

Dalam skenario penghentian zona operasional, tidak ada jaminan bahwa permintaan untuk lebih banyak kapasitas di zona ketersediaan lain dapat terpenuhi. Pengisian ulang unit yang hilang terjadi berdasarkan upaya terbaik. Jika Anda memerlukan kapasitas yang dijamin saat zona ketersediaan gagal, buat dan konfigurasikan instans API Management Anda untuk memperhitungkan kehilangan zona dengan mengambil semua tindakan berikut:

  • Provisikan unit instans API Management Anda secara berlebihan.

  • Gunakan konfigurasi zona ketersediaan otomatis atau zona redundan.

Untuk informasi selengkapnya, lihat Mengelola kapasitas dengan penyediaan berlebih.

Gunakan metrik kapasitas dan pengujian Anda sendiri untuk menentukan jumlah unit yang memberikan performa gateway yang diperlukan. Untuk informasi selengkapnya tentang cara menskalakan dan meningkatkan instans layanan Anda, lihat Meningkatkan dan menskalakan instans API Management.

Perilaku ketika semua zona sehat

Bagian ini menjelaskan apa yang diharapkan ketika instans API Management dikonfigurasi dengan dukungan zona ketersediaan dan semua zona ketersediaan beroperasi.

  • Perutean lalu lintas antar zona: Selama operasi normal, lalu lintas dirutekan antara semua unit API Management yang tersedia di semua zona ketersediaan yang dipilih.

  • Replikasi data antar zona: API Management menyimpan dan mereplikasi data berikut.

    • Konfigurasi gateway, seperti API dan definisi kebijakan, secara teratur menyinkronkan antara zona ketersediaan yang Anda pilih untuk instans. Penyebaran pembaruan antara zona ketersediaan biasanya memakan waktu kurang dari 10 detik.

    • Data di cache internal, jika Anda menggunakan cache internal yang disediakan API Management. Entri cache didistribusikan di antara zona ketersediaan. Cache internal volatil dan data tidak dijamin akan dipertahankan. Pertimbangkan untuk menggunakan cache eksternal jika Anda perlu mempertahankan data yang di-cache.

    • Penghitung batas tarif, jika Anda menggunakan kemampuan pembatasan tarif yang disediakan API Management. Penghitung batas tarif direplikasi secara asinkron antara zona ketersediaan yang Anda pilih untuk instans.

Perilaku selama kegagalan zona

Bagian ini menjelaskan apa yang diharapkan ketika instans API Management dikonfigurasi dengan dukungan zona ketersediaan dan ada pemadaman zona ketersediaan.

  • Deteksi dan respons: Tanggung jawab untuk deteksi dan respons tergantung pada konfigurasi zona ketersediaan yang digunakan instans Anda.

    • Otomatis dan zona-redundan: Untuk instans yang dikonfigurasi untuk menggunakan dukungan zona ketersediaan otomatis atau dikonfigurasi secara manual untuk menggunakan redundansi zona, platform API Management bertanggung jawab untuk mendeteksi kegagalan di zona ketersediaan dan merespons. Anda tidak perlu melakukan apa pun untuk memulai failover zona.

    • Zonal: Misalnya yang dikonfigurasi menjadi zonal, Anda perlu mendeteksi hilangnya zona ketersediaan dan memulai failover ke instans sekunder yang Anda buat di zona ketersediaan lain.

  • Permintaan aktif: Ketika zona ketersediaan tidak tersedia, setiap permintaan yang sedang berlangsung yang terhubung ke unit API Management di zona ketersediaan yang rusak dihentikan dan perlu dicoba kembali.

  • Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat zona tidak berfungsi. Namun, Anda dapat menggunakan Azure Resource Health untuk memantau kesehatan sumber daya individual, dan Anda dapat menyiapkan pemberitahuan Resource Health untuk memberi tahu Anda tentang masalah. Anda juga dapat menggunakan Azure Service Health untuk memahami kesehatan layanan secara keseluruhan, termasuk kegagalan zona apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.

  • Kehilangan data yang diharapkan: API Management menyimpan data berikut.

    • Perubahan konfigurasi gateway, yang direplikasi ke setiap zona ketersediaan yang dipilih dalam waktu sekitar 10 detik. Jika terjadi pemadaman zona ketersediaan, Anda mungkin kehilangan perubahan konfigurasi yang tidak direplikasi.

    • Data di cache internal, jika Anda menggunakan fitur cache internal. Cache internal volatil dan data tidak dijamin akan dipertahankan. Selama pemadaman zona ketersediaan, Anda mungkin kehilangan beberapa atau semua data yang di-cache. Pertimbangkan untuk menggunakan cache eksternal jika Anda perlu mempertahankan data yang di-cache.

    • Penghitung batas tarif, jika Anda menggunakan fitur batas tarif. Selama pemadaman zona ketersediaan, penghitung batas tarif mungkin tidak up-to-tanggal di zona yang bertahan.

  • Waktu henti yang diharapkan: Waktu henti yang diharapkan tergantung pada konfigurasi zona ketersediaan yang digunakan instans Anda.

    • Otomatis: Anda dapat mengharapkan instans yang menggunakan dukungan zona ketersediaan otomatis tidak memiliki waktu henti selama pemadaman zona ketersediaan. Unit di zona atau zona yang tidak terpengaruh terus berfungsi.

      Anda juga dapat mengharapkan instans yang menggunakan dukungan zona ketersediaan otomatis, tetapi memiliki satu unit, untuk tidak memiliki waktu henti. Dalam hal ini, API Management mendistribusikan sumber daya komputasi dasar unit ke dua zona. Sumber daya di zona yang tidak terpengaruh terus berfungsi.

    • Zona-redundan: Anda dapat mengharapkan instans redundan zona tidak memiliki waktu henti selama pemadaman zona ketersediaan.

    • Zonal: Untuk instans zonal, ketika zona tidak tersedia, instans Anda tidak tersedia hingga zona ketersediaan pulih.

  • Pengalihan lalu lintas: Perilaku perutean ulang lalu lintas tergantung pada konfigurasi zona ketersediaan yang digunakan instans Anda.

    • Otomatis dan zona-redundan: Untuk instans yang dikonfigurasi untuk menggunakan dukungan zona ketersediaan otomatis atau dikonfigurasi secara manual untuk menggunakan redundansi zona, ketika zona tidak tersedia, unit apa pun di zona yang terpengaruh juga tidak tersedia. Anda dapat memilih untuk menskalakan instans Anda untuk menambahkan lebih banyak unit.

    • Zonal: Untuk instans zonal, ketika zona tidak tersedia, instans Anda tidak tersedia. Jika Anda memiliki instans sekunder di zona ketersediaan lain, Anda bertanggung jawab untuk mengalihkan lalu lintas ke instans sekunder tersebut.

Perilaku selama kegagalan zona

Bagian ini menjelaskan apa yang diharapkan ketika instans API Management dikonfigurasi dengan dukungan zona ketersediaan dan ada pemadaman zona ketersediaan.

  • Deteksi dan respons: Di tingkat Premium v2, platform API Management bertanggung jawab untuk mendeteksi kegagalan di zona ketersediaan dan merespons. Anda tidak perlu melakukan apa pun untuk memulai failover zona.

  • Permintaan aktif: Ketika zona ketersediaan tidak tersedia, setiap permintaan yang sedang berlangsung yang terhubung ke unit API Management di zona ketersediaan yang rusak dihentikan dan perlu dicoba kembali.

  • Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat zona tidak berfungsi. Namun, Anda dapat menggunakan Azure Resource Health untuk memantau kesehatan sumber daya individual, dan Anda dapat menyiapkan pemberitahuan Resource Health untuk memberi tahu Anda tentang masalah. Anda juga dapat menggunakan Azure Service Health untuk memahami kesehatan layanan secara keseluruhan, termasuk kegagalan zona apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.

  • Kehilangan data yang diharapkan: API Management menyimpan data berikut.

    • Perubahan konfigurasi gateway, yang direplikasi ke setiap zona ketersediaan yang dipilih dalam waktu sekitar 10 detik. Jika terjadi pemadaman zona ketersediaan, Anda mungkin kehilangan perubahan konfigurasi yang tidak direplikasi.

    • Data di cache internal, jika Anda menggunakan fitur cache internal. Cache internal volatil dan data tidak dijamin akan dipertahankan. Selama pemadaman zona ketersediaan, Anda mungkin kehilangan beberapa atau semua data yang di-cache. Pertimbangkan untuk menggunakan cache eksternal jika Anda perlu mempertahankan data yang di-cache.

    • Penghitung batas tarif, jika Anda menggunakan fitur batas tarif. Selama pemadaman zona ketersediaan, penghitung batas tarif mungkin tidak up-to-tanggal di zona yang bertahan.

  • Waktu henti yang diharapkan: Anda dapat mengharapkan instans tidak mengalami waktu henti selama pemadaman zona ketersediaan. Unit di zona atau zona yang tidak terpengaruh terus berfungsi.

    Anda juga dapat mengharapkan instans yang memiliki satu unit tidak mengalami gangguan operasional. Dalam konfigurasi ini, API Management mendistribusikan sumber daya komputasi dasar unit ke dua zona. Sumber daya di zona yang tidak terpengaruh terus berfungsi.

  • Pengalihan lalu lintas: Ketika zona tidak tersedia, unit apa pun di zona yang terpengaruh juga tidak tersedia. Anda dapat meningkatkan skala instance untuk menambahkan lebih banyak unit.

Pemulihan zona

  • Otomatis dan zona-redundan: Untuk instans yang dikonfigurasi untuk menggunakan dukungan zona ketersediaan otomatis atau dikonfigurasi secara manual untuk menggunakan redundansi zona, ketika zona ketersediaan pulih, API Management secara otomatis memulihkan unit di zona ketersediaan dan mengalihkan lalu lintas antara unit Anda seperti biasa.

  • Zonal: Untuk instans zonal, Anda bertanggung jawab untuk mengalihkan lalu lintas ke instans di zona ketersediaan asli setelah zona ketersediaan pulih.

Pemulihan zona

Di tingkat Premium v2, ketika zona ketersediaan pulih, API Management secara otomatis memulihkan unit di zona ketersediaan dan mengalihkan lalu lintas antara unit Anda seperti biasa.

Uji kegagalan zona

  • Otomatis dan zona-redundan: Untuk instans yang dikonfigurasi untuk menggunakan dukungan zona ketersediaan otomatis atau dikonfigurasi secara manual untuk menggunakan redundansi zona, platform API Management mengelola perutean lalu lintas, failover, dan failback. Fitur ini dikelola sepenuhnya, sehingga Anda tidak perlu memulai atau memvalidasi proses kegagalan zona ketersediaan.

  • Zonal: Untuk instans zonal, Anda tidak dapat mensimulasikan pemadaman zona ketersediaan yang berisi instans API Management Anda. Namun, Anda dapat mengonfigurasi gateway upstream atau load balancer secara manual untuk mengalihkan lalu lintas ke instans yang berbeda di zona ketersediaan yang berbeda.

Uji kegagalan zona

Di tingkat Premium v2, platform API Management mengelola perutean lalu lintas, failover, dan failback. Fitur ini dikelola sepenuhnya, sehingga Anda tidak perlu memulai atau memvalidasi proses kegagalan zona ketersediaan.

Ketahanan terhadap kegagalan di seluruh wilayah

Dengan menggunakan penyebaran multi-wilayah, Anda dapat menambahkan gateway API regional ke instans API Management yang ada di satu atau beberapa wilayah Azure yang didukung. Penyebaran multi-wilayah membantu mengurangi latensi permintaan apa pun yang dirasakan oleh konsumen API yang didistribusikan secara geografis. Penyebaran multi-wilayah juga meningkatkan ketersediaan layanan jika satu wilayah offline.

Penting

Penyebaran multi-wilayah hanya didukung di tingkat Premium (klasik) dari API Management.

Untuk melihat informasi tentang dukungan multi-wilayah, pastikan untuk memilih tingkat Premium (klasik) di awal halaman ini.

Penyebaran Multi-Regional yang Dikelola Microsoft

Saat menambahkan wilayah, Anda mengonfigurasi:

Persyaratan

  • Dukungan wilayah: Anda dapat membuat penyebaran multi-wilayah di tingkat Premium (klasik) dengan wilayah Azure apa pun yang mendukung API Management. Untuk melihat wilayah mana yang mendukung penyebaran multi-wilayah, lihat Ketersediaan produk menurut wilayah.

  • Persyaratan tingkat: Anda harus menggunakan tingkat Premium (klasik) untuk mengonfigurasi dukungan multi-wilayah. Untuk meningkatkan instans Anda ke tingkat Premium (klasik), lihat Meningkatkan ke tingkat Premium.

Pertimbangan

  • Gateway saja: Hanya komponen gateway instans API Management Anda yang direplikasi ke beberapa wilayah. Bidang manajemen instans dan portal pengembang tetap dihosting hanya di wilayah utama tempat Anda awalnya menyebarkan layanan.

  • Persyaratan jaringan: Jika Anda ingin mengonfigurasi lokasi sekunder untuk instans API Management Anda saat disebarkan (disuntikkan) di jaringan virtual, jaringan virtual dan wilayah subnet harus cocok dengan lokasi sekunder yang Anda konfigurasi. Jika Anda menambahkan, menghapus, atau mengaktifkan zona ketersediaan di wilayah utama, atau jika Anda mengubah subnet wilayah utama, alamat IP virtual (VIP) instans API Management Anda berubah. Untuk informasi selengkapnya, lihat Perubahan pada alamat IP. Namun, jika Anda menambahkan wilayah sekunder, VIP wilayah utama tidak berubah karena setiap wilayah memiliki VIP privatnya sendiri.

  • Nama Sistem Nama Domain (DNS): Gateway di setiap wilayah, termasuk wilayah utama, memiliki nama DNS regional yang mengikuti pola https://<service-name>-<region>-01.regional.azure-api.netURL , misalnya https://contoso-westus2-01.regional.azure-api.net.

Biaya

Menambahkan wilayah dikenakan biaya. Untuk informasi, lihat Harga API Management.

Mengonfigurasi dukungan multiregional

Untuk mengonfigurasi dukungan multi-wilayah pada instans API Management, lihat Menyebarkan instans API Management ke beberapa wilayah Azure.

Untuk menghapus wilayah dari instans API Management, lihat Menghapus wilayah layanan API Management.

Perencanaan dan manajemen kapasitas

Dalam skenario region-down, tidak ada jaminan bahwa permintaan untuk lebih banyak kapasitas di wilayah lain berhasil. Jika Anda memerlukan kapasitas terjamin saat wilayah gagal, Anda harus membuat dan mengonfigurasi instans API Management untuk memperhitungkan kehilangan wilayah. Anda dapat melakukannya dengan menyediakan kapasitas instans API Management Anda secara berlebihan. Untuk mempelajari selengkapnya tentang prinsip provisi berlebihan, lihat Mengelola kapasitas dengan provisi berlebihan.

Dalam penyebaran multi-wilayah, autoscaling hanya berlaku untuk wilayah utama. Wilayah sekunder memerlukan penyesuaian skala manual atau alat kustom yang Anda kontrol.

Perilaku ketika semua wilayah sehat

Bagian ini menjelaskan apa yang diharapkan ketika instans API Management dikonfigurasi dengan dukungan multi-wilayah dan semua wilayah beroperasi.

  • Perutean lalu lintas antar wilayah: API Management secara otomatis merutekan permintaan masuk ke gateway regional. Permintaan dirutekan ke gateway regional dengan latensi terendah dari klien. Jika Anda perlu menggunakan pendekatan perutean yang berbeda, Anda dapat mengonfigurasi Traffic Manager Anda sendiri dengan aturan perutean kustom. Untuk informasi selengkapnya, lihat Menggunakan perutean kustom ke gateway regional API Management.

    Saat permintaan mencapai gateway regional API Management, permintaan dirutekan ke API backend kecuali kebijakan mengembalikan respons langsung dari gateway, seperti respons cache atau kode kesalahan. Dalam solusi multi-wilayah, Anda perlu berhati-hati untuk mengalihkan ke instans API backend yang memenuhi kebutuhan kinerja Anda. Untuk informasi selengkapnya, lihat Merutekan panggilan API ke layanan backend regional.

  • Replikasi data antar wilayah: Konfigurasi gateway, seperti API dan definisi kebijakan, secara teratur disinkronkan antara wilayah utama dan sekunder yang Anda tambahkan. Penyebaran pembaruan ke gateway regional biasanya memakan waktu kurang dari 10 detik.

    Penghitung batas tarif dan data dalam cache internal khusus wilayah, sehingga tidak direplikasi antar wilayah.

Perilaku selama kegagalan wilayah

Bagian ini menjelaskan apa yang diharapkan ketika instans API Management dikonfigurasi dengan dukungan multi-wilayah dan ada pemadaman di salah satu wilayah yang Anda gunakan.

  • Deteksi dan respons: API Management bertanggung jawab untuk mendeteksi kegagalan di suatu wilayah dan secara otomatis melakukan failover ke gateway di salah satu wilayah lain yang Anda konfigurasi.

  • Permintaan aktif: Setiap permintaan aktif yang sedang diproses di wilayah yang rusak mungkin dihilangkan dan klien harus mencobanya kembali.

  • Kehilangan data yang diharapkan: API Management tidak menyimpan data, kecuali untuk konfigurasi, cache, dan penghitung batas laju.

    Perubahan konfigurasi direplikasi ke setiap wilayah dalam waktu sekitar 10 detik. Jika terjadi pemadaman wilayah utama, Anda mungkin kehilangan perubahan konfigurasi yang tidak direplikasi.

    Penghitung batas tarif dan data dalam cache internal khusus wilayah, sehingga tidak direplikasi antar wilayah.

  • Waktu henti yang diharapkan: Tidak ada waktu henti gateway yang diharapkan.

    Jika wilayah utama offline, bidang manajemen API Management dan portal pengembang menjadi tidak tersedia. Namun, wilayah sekunder terus melayani permintaan API dengan menggunakan konfigurasi gateway terbaru.

  • Pengalihan lalu lintas: Jika wilayah offline, permintaan API secara otomatis dirutekan di sekitar wilayah yang gagal ke gateway terdekat berikutnya.

Pemulihan wilayah

Saat wilayah utama pulih, API Management secara otomatis memulihkan unit di wilayah tersebut dan mengalihkan lalu lintas antar unit Anda.

Pengujian untuk mendeteksi kegagalan wilayah

Agar siap untuk pemadaman wilayah yang tidak terduga, uji respons Anda secara teratur terhadap kegagalan wilayah. Anda dapat mensimulasikan beberapa aspek kegagalan wilayah dengan menonaktifkan perutean ke gateway regional.

Pencadangan dan pemulihan

API Management tidak menyimpan sebagian besar data runtime. Namun, Anda dapat mencadangkan konfigurasi layanan API Management Anda. Anda juga dapat menggunakan operasi pencadangan dan pemulihan untuk mereplikasi konfigurasi layanan API Management antara lingkungan operasional, seperti pengembangan dan penahapan.

Penting

Dalam prosedur pencadangan, data runtime seperti pengguna dan langganan disertakan, yang mungkin tidak selalu diinginkan.

Pencadangan didukung di tingkat Pengembang, Dasar, Standar, dan Premium.

Untuk informasi selengkapnya, lihat Cara menerapkan pemulihan bencana dengan menggunakan pencadangan dan pemulihan layanan di API Management.

Untuk pencadangan atau pemulihan beberapa komponen atau sumber daya layanan, Anda juga dapat mempertimbangkan opsi yang dikelola pelanggan seperti alat APIOps dan infrastruktur sebagai solusi kode (IaC).

Ketahanan terhadap pemeliharaan layanan

API Management melakukan peningkatan layanan reguler dan bentuk pemeliharaan lainnya.

Di tingkat Dasar, Standar, dan Premium (klasik), Anda dapat menyesuaikan kapan dalam proses pembaruan instans Anda menerima pembaruan. Jika Anda perlu memvalidasi efek peningkatan pada beban kerja Anda, pertimbangkan untuk mengonfigurasi instans pengujian untuk menerima pembaruan di awal siklus pembaruan, dan atur instans produksi Anda untuk menerima pembaruan terlambat dalam siklus. Anda juga dapat menentukan jendela pemeliharaan, yang merupakan waktu di mana Anda ingin instans menerapkan pembaruan layanan.

Untuk informasi selengkapnya, lihat Mengonfigurasi pengaturan pembaruan layanan untuk instans API Management Anda.

Perjanjian tingkat layanan

Perjanjian tingkat layanan (SLA) untuk layanan Azure menjelaskan ketersediaan yang diharapkan dari setiap layanan dan kondisi yang harus dipenuhi solusi Anda untuk mencapai harapan ketersediaan tersebut. Untuk informasi selengkapnya, lihat SLA untuk layanan online.

Saat Anda menyebarkan instans API Management di beberapa zona atau wilayah ketersediaan, persentase waktu aktif yang ditentukan dalam SLA meningkat.

Layanan ini menyediakan SLA sendiri, tetapi Anda juga perlu memperhitungkan keandalan komponen beban kerja lain yang diantisipasi, seperti backend API.

Konten terkait

  • Last updated on