Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Azure Traffic Manager adalah load balancer global yang dapat mendistribusikan lalu lintas di beberapa wilayah Azure, zona dalam suatu wilayah, atau pusat data dalam zona tersebut. Ini menggunakan protokol Sistem Nama Domain (DNS) untuk membuat jalur komunikasi antara klien dan titik akhir beban kerja Anda. Setelah koneksi dibuat, klien dapat terhubung langsung ke titik akhir tanpa bantuan Traffic Manager.
Artikel ini mengasumsikan bahwa sebagai arsitek, Anda telah meninjau opsi penyeimbangan beban di Azure dan memilih Azure Traffic Manager untuk beban kerja Anda, yang disebarkan di beberapa wilayah baik dalam model aktif-aktif atau pasif aktif. Panduan dalam artikel ini memberikan rekomendasi arsitektur yang dipetakan ke prinsip pilar kerangka kerja Well-Architected.
Penting
Cara menggunakan panduan ini
Setiap bagian memiliki daftar periksa desain yang menyajikan area perhatian arsitektur bersama strategi desain yang disesuaikan dengan cakupan teknologi.
Juga termasuk rekomendasi untuk kemampuan teknologi yang dapat membantu mewujudkan strategi tersebut. Rekomendasi tidak mewakili daftar lengkap semua konfigurasi yang tersedia untuk Traffic Manager dan dependensinya. Sebaliknya, mereka mencantumkan rekomendasi utama yang dipetakan ke perspektif desain. Gunakan rekomendasi untuk membangun bukti konsep Anda atau untuk mengoptimalkan lingkungan Anda yang ada.
Arsitektur dasar yang menunjukkan rekomendasi utama: Penyeimbangan beban Multiregion dengan Traffic Manager, Azure Firewall, dan Application Gateway.
cakupan teknologi
Tinjauan ini berfokus pada keputusan yang saling terkait untuk sumber daya Azure berikut:
- Manajer Lalu Lintas
Nota
Untuk beban kerja yang menghosting aplikasi HTTP, Azure Front Door adalah pilihan alami karena fiturnya, seperti jaringan pengiriman konten, penghentian Keamanan Lapisan Transportasi (TLS), dan firewall terintegrasi.
Dibandingkan dengan Azure Front Door, Traffic Manager lebih mudah diatur, dikonfigurasi, dan dikelola. Traffic Manager tidak memiliki titik akhir yang dapat Anda kontrol secara langsung. Tidak seperti Front Door, yang menangani permintaan klien, Traffic Manager hanya menghubungkan klien ke titik akhir beban kerja.
Tetapi kesederhanaan ini datang dengan kompromi yang dapat memperkenalkan kompleksitas dalam desain arsitektur. Misalnya, Anda mungkin perlu menerapkan langkah-langkah keamanan tambahan untuk memblokir jenis serangan Open Worldwide Application Security Project (OWASP). Web Application Firewall (WAF) di Azure Front Door atau Azure Application Gateway menyediakan kemampuan ini. Atau Anda mungkin menambahkan cache, yang dapat mempercepat pengiriman konten tetapi menambahkan kompleksitas karena Anda harus mengelola penyimpanan data.
Untuk informasi selengkapnya, lihat perspektif Well-Architected Framework di Azure Front Door.
Keandalan
Tujuan dari pilar Keandalan adalah untuk memberikan fungsionalitas berkelanjutan dengan membangun ketahanan yang cukup dan kemampuan untuk memulihkan dengan cepat dari kegagalan.
prinsip desain Keandalan menyediakan strategi desain tingkat tinggi yang diterapkan untuk komponen individu, alur sistem, dan sistem secara keseluruhan.
Daftar periksa desain
Mulai strategi desain Anda berdasarkan daftar periksa tinjauan desain untuk Keandalan. Tentukan relevansinya dengan kebutuhan bisnis Anda sambil mengingat sifat aplikasi Anda dan kekritisan komponennya. Perluas strategi untuk menyertakan lebih banyak pendekatan sesuai kebutuhan.
Memperhitungkan potensi kegagalan. Traffic Manager dirancang agar tangguh. Tetapi itu masih bisa menjadi satu titik kegagalan untuk beban kerja Anda. Untuk mengurangi risiko ini, tentukan jalur sekunder ke layanan alternatif yang menjadi aktif jika Traffic Manager tidak tersedia. Untuk menghindari masalah perutean, jangan gunakan Traffic Manager dan layanan alternatif bersamaan.
Memiliki pemahaman yang baik tentang cakupan perjanjian tingkat layanan (SLA). Saat Anda mengevaluasi SLA Traffic Manager, pahami cakupan terkait persentil yang dipublikasikan. Misalnya, pencarian DNS Anda mungkin gagal beberapa kali. Kegagalan tersebut tidak dianggap sebagai waktu henti sampai terjadi kegagalan pencarian DNS yang berkelanjutan selama satu menit penuh.
Masukkan redundansi dalam arsitektur beban kerja Anda. Jika layanan Anda diekspos melalui alamat IP publik, gunakan Traffic Manager untuk menerapkan redundansi di seluruh wilayah Azure, lokal, dan cloud lainnya. Misalnya, Anda mungkin memiliki aplikasi lokal yang memiliki instans sekunder di cloud. Jika sistem lokal gagal, instans cloud dapat menjadi aktif, yang membantu memastikan kelangsungan.
Gunakan arsitektur penyebaran yang andal untuk mendukung redundansi. Sebagai penyeimbang beban, Traffic Manager mendistribusikan lalu lintas di seluruh titik akhir beban kerja berdasarkan konfigurasi metode perutean yang Anda tetapkan. Anda menentukan konfigurasi ini di profil Traffic Manager. Profil adalah komponen utama dari strategi penyebaran Anda. Anda dapat menggunakan konfigurasi profil yang sesuai untuk menerapkan model aktif-aktif atau model pasif aktif yang memiliki cadangan hangat.
Setiap profil menentukan satu metode perutean lalu lintas. Beberapa skenario memerlukan perutean lalu lintas yang lebih canggih. Anda dapat menggabungkan profil Traffic Manager untuk memanfaatkan lebih dari satu metode perutean lalu lintas.
Untuk informasi selengkapnya, lihat metode perutean Traffic Manager .
Mengevaluasi durasi penyimpanan sementara respons DNS. Pengaturan time-to-live (TTL) untuk pencarian DNS di Traffic Manager menentukan berapa lama penyelesai DNS hilir men-cache respons DNS. TTL default dapat mengakibatkan waktu penyimpanan sementara yang lebih lama dari yang diperlukan, yang berpotensi menyebabkan waktu henti jika titik akhir gagal. Kurangi TTL untuk meningkatkan frekuensi pembaruan cache. Metode ini dapat membantu mengurangi waktu henti tetapi meningkatkan frekuensi pencarian DNS.
Hindari mengirim trafik jaringan ke instans yang tidak sehat atau disusupi. Tinjau fitur pemeriksaan kesehatan bawaan di Traffic Manager.
Untuk aplikasi HTTPS dan HTTP, terapkan pola Pemantauan Titik Akhir Kesehatan untuk menyediakan halaman kustom dalam aplikasi Anda. Berdasarkan pemeriksaan tertentu, halaman mengembalikan kode status HTTPS yang sesuai. Selain ketersediaan endpoint, pengecekan kesehatan Anda harus memantau semua dependensi aplikasi Anda.
Untuk aplikasi lain, Traffic Manager menggunakan Protokol Kontrol Transmisi (TCP) untuk menentukan ketersediaan titik akhir.
Untuk informasi selengkapnya, lihat pola Pemantauan Titik Akhir Kesehatan dan Pahami Pemeriksaan Traffic Manager.
Tentukan toleransi pemadaman Anda. Jika backend menjadi tidak tersedia, bisa memakan waktu sebelum Traffic Manager mengenali kegagalan tersebut dan berhenti mengarahkan lalu lintas ke titik akhir yang tidak tersedia. Ada periode waktu ketika permintaan klien tidak dapat dilayani. Gunakan toleransi ini untuk mengonfigurasi pengaturan probe, yang menentukan seberapa cepat Anda ingin memulai operasi kelangsungan bisnis Anda.
Sertakan titik akhir sebagai bagian dari pengujian ketahanan Anda. Simulasikan titik akhir yang tidak tersedia untuk melihat bagaimana Traffic Manager menangani kegagalan. Misalkan beban kerja Anda menggunakan load balancer seperti Application Gateway di jaringan virtual privat. Anda dapat menggunakan aturan kelompok keamanan jaringan (NSG) di Azure Chaos Studio untuk mensimulasikan kegagalan titik akhir. Anda dapat memblokir akses ke subnet tempat Application Gateway berada.
Rekomendasi
Rekomendasi | Manfaat |
---|---|
Pasang beberapa endpoint di profil Traffic Manager, dan aktifkan. Jika sebuah titik akhir tidak diaktifkan, maka titik akhir tersebut tidak diperiksa dalam pemeriksaan kesehatan atau dimasukkan dalam rotasi perutean lalu lintas. Tempatkan titik akhir ini di wilayah yang berbeda. | Instans redundan membantu memastikan ketersediaan jika satu titik akhir gagal. |
Evaluasi berbagai metode pengaturan rute lalu lintas . Konfigurasikan satu atau kombinasi metode untuk selaras dengan strategi penyebaran Anda. Traffic Manager menerapkan metode yang dipilih untuk setiap kueri DNS dan menggunakan metode untuk menentukan titik akhir mana yang dikembalikan dalam respons DNS. - Metode berbobot mendistribusikan lalu lintas berdasarkan koefisien bobot yang telah dikonfigurasi. Metode ini mendukung model aktif-aktif. - Metode berbasis prioritas mengonfigurasi wilayah utama untuk menerima lalu lintas dan mengirimkannya ke wilayah sekunder sebagai cadangan. Metode ini mendukung model pasif aktif. - Metode geografis merutekan lalu lintas berdasarkan asal geografis kueri DNS. Untuk mencakup semua wilayah, konfigurasikan setidaknya satu titik akhir dengan properti Semua (Dunia). |
Metode perutean yang dioptimalkan membantu memastikan bahwa Anda mendistribusikan lalu lintas secara efisien di seluruh titik akhir Anda. Anda dapat mendukung tujuan model penyebaran aktif-aktif atau aktif-pasif Anda. Metode perutean yang efisien membantu memastikan bahwa wilayah sekunder dapat mengelola lalu lintas atau bertindak sebagai cadangan. Perutean geografis membantu mengarahkan pengguna ke titik akhir terdekat berdasarkan lokasi mereka. Ini membantu memastikan bahwa lalu lintas dikelola secara efisien dan tidak hilang. |
Atur durasi interval TTL DNS ke nilai rendah, sebaiknya kurang dari 60 detik. Untuk mengoptimalkan performa, sesuaikan waktu pemeriksaan kesehatan dan TTL catatan DNS. | Durasi TTL yang rendah membantu memastikan pembaruan cache resolver DNS di hilir yang lebih sering dan failover yang lebih cepat. Ini juga meminimalkan waktu henti dan meningkatkan respons keseluruhan aplikasi Anda. |
Siapkan pemeriksaan kesehatan untuk memantau titik akhir. - Jangan aktifkan AlwaysServe , yang akan menonaktifkan pemantauan endpoint dan mengirim permintaan ke endpoint tersebut, terlepas dari kondisi kesehatannya. - Atur nilai probing interval . Pertimbangkan kompromi antara seberapa cepat Anda dapat mendeteksi kegagalan dan jumlah permintaan ke endpoint. Jumlah permintaan dapat substansial karena Traffic Manager adalah layanan global yang melakukan ping secara bersamaan dari berbagai lokasi. - Atur nilai probe timeout . Pertimbangkan berapa lama menunggu sebelum mendeklarasikan titik akhir tidak sehat. Sertakan false positive dalam jumlah kegagalan. |
Pemeriksaan kesehatan memastikan bahwa hanya instans sehat yang melayani permintaan pengguna. Mereka juga membantu menentukan apakah kegagalan tidak bersifat sementara dan seberapa cepat operasi failover harus berlangsung. |
Keamanan
Tujuan pilar Keamanan adalah untuk memberikan jaminan kerahasiaan, integritas, dan ketersediaan terhadap beban kerja.
Prinsip desain Security menyediakan strategi desain tingkat tinggi untuk mencapai tujuan tersebut dengan menerapkan pendekatan pada desain teknis Traffic Manager.
Daftar periksa desain
Tinjau garis besar keamanan. Untuk meningkatkan postur keamanan Anda, tinjau garis besar keamanan untuk Traffic Manager.
Mencegah modifikasi pengalihan lalu lintas yang tidak sah. Perlakukan profil Traffic Manager sebagai sumber daya beban kerja penting karena berisi pengaturan konfigurasi untuk merutekan lalu lintas. Hanya identitas yang berwenang yang harus memiliki akses ke profil ini. Terapkan kontrol akses berbasis peran (RBAC) pada sarana kontrol untuk membatasi tugas seperti membuat, menghapus, atau memodifikasi sumber daya. Hanya identitas yang berwenang yang boleh mengaktifkan atau menonaktifkan endpoint. Akses yang tidak sah dapat mengakibatkan perubahan konfigurasi dan berpotensi mengalihkan lalu lintas ke implementasi berbahaya.
Lindungi aplikasi dari ancaman di tepi jaringan. Traffic Manager tidak menyediakan fitur keamanan bawaan, seperti WAF. Untuk membantu mengamankan aplikasi HTTP, Anda harus menerapkan inspeksi lalu lintas di tingkat titik akhir.
Arsitektur umum mungkin mencakup Traffic Manager dan beberapa titik akhir. Untuk setiap titik akhir, gateway aplikasi yang menangani penghentian TLS dan fungsi keamanan lainnya memberikan perlindungan. Untuk arsitektur referensi yang menunjukkan pola tersebut, lihat penyeimbangan beban Multiregion dengan Traffic Manager, Azure Firewall, dan Application Gateway.
Mengeraskan entri DNS. Traffic Manager dapat rentan terhadap serangan yang memanipulasi data DNS, yang dapat mengalihkan lalu lintas ke situs berbahaya dan menyebabkan masalah keamanan. Ancaman umum adalah pengambilalihan subdomain, di mana catatan DNS menunjuk ke sumber daya Azure yang dideprovisi. Untuk mencegah pengalihan subdomain, gunakan catatan alias Azure DNS dan pasangan siklus hidup rekaman DNS dengan sumber daya Azure.
Untuk informasi selengkapnya, lihat Mencegah entri DNS yang menggantung.
Rekomendasi
Rekomendasi | Manfaat |
---|---|
Tambahkan gateway aplikasi ke titik akhir beban kerja. Untuk menerapkan inspeksi keamanan dengan firewall untuk aplikasi HTTP, tambahkan gateway aplikasi ke titik akhir beban kerja. |
Anda dapat memeriksa lalu lintas HTTP masuk untuk membantu melindungi aplikasi dari serangan umum. |
Membuat catatan alias di Azure DNS untuk domain puncak beban kerja Anda guna mereferensikan profil Traffic Manager. | Catatan alias menggabungkan siklus hidup rekaman DNS dengan sumber daya Azure dengan erat. Konfigurasi ini membantu mencegah referensi mengambang jika beban kerja dihentikan. Jika profil Traffic Manager dihapus, catatan alias DNS menjadi kumpulan catatan kosong. Ini tidak lagi mereferensikan sumber daya yang dihapus. |
Pengoptimalan Biaya
Pengoptimalan Biaya berfokus pada mendeteksi pola pengeluaran, memprioritaskan investasi di area penting, dan mengoptimalkan area lainnya untuk memenuhi anggaran organisasi seraya memenuhi persyaratan bisnis.
Prinsip desain pengoptimalan biaya menyediakan strategi desain tingkat tinggi untuk mencapai tujuan tersebut dan membuat tradeoff seperlunya dalam desain teknis yang terkait dengan Traffic Manager dan lingkungannya.
Daftar periksa desain
Mulailah strategi desain Anda berdasarkan daftar periksa ulasan desain untuk pengoptimalan biaya dalam investasi. Sesuaikan desain sehingga beban kerja selaras dengan anggaran yang dialokasikan untuk beban kerja. Desain Anda harus menggunakan kemampuan Azure yang tepat, memantau investasi, dan menemukan peluang untuk dioptimalkan dari waktu ke waktu.
Mengevaluasi biaya fitur. Fitur dasbor tampilan lalu lintas menunjukkan dari mana klien Anda terhubung dan latensi terkait. Informasi ini membantu mengoptimalkan performa dan menyempurnakan desain Anda, yang berkontribusi pada keunggulan operasional dan efisiensi sistem. Namun, itu dikenakan biaya tambahan. Untuk informasi selengkapnya, lihat Penagihan tampilan lalu lintas.
Pertimbangkan juga biaya yang terkait dengan pemeriksaan kesehatan. Traffic Manager melakukan ping pada titik akhir yang ditentukan dari berbagai lokasi untuk memeriksa ketersediaannya. Anda dapat memilih ping lambat dan ping cepat. Ping cepat mendeteksi kegagalan lebih cepat tetapi dikenakan biaya yang lebih tinggi. Mereka juga menambahkan lebih banyak beban pada beban kerja karena pemeriksaan kesehatan lebih sering.
Evaluasi biaya strategi perutean Anda. Misalnya, jika sebagian besar klien mengakses titik akhir Anda dari wilayah latensi tinggi, Anda dapat membuat titik akhir lain yang lebih dekat dengan pengguna tersebut dan menyesuaikan metode perutean di Traffic Manager. Praktik ini mengurangi latensi sehingga Anda dapat memproses lebih banyak permintaan dengan kapasitas yang lebih sedikit, yang menyebabkan penghematan biaya.
Rekomendasi
Rekomendasi | Manfaat |
---|---|
Gunakan kalkulator harga untuk memperkirakan biaya fitur-fitur Traffic Manager. | Anda dapat memiliki model biaya yang lebih akurat dan mengatur tata kelola sekeliling sumber daya, jika perlu. |
Aktifkan dasbor tampilan lalu lintas selama upaya pengoptimalan Anda. | Fitur ini membantu Anda lebih memahami pola penggunaan. Gunakan data ini untuk penyetelan performa untuk membantu memenuhi target beban kerja Anda. Aktifkan fitur pada waktu yang tepat, dan terapkan tingkat yang tepat untuk menghindari sumber daya yang kurang digunakan. |
Pilih ping cepat atau lambat untuk uji kesehatan , tergantung pada metrik pemulihan Anda. Ping cepat mendeteksi kegagalan lebih cepat tetapi lebih mahal. Ping yang lebih lambat biayanya lebih murah. Jangan nonaktifkan ping. |
Ping lebih jarang untuk mengoptimalkan biaya dan mengurangi beban pada titik akhir beban kerja. |
Keunggulan Operasional
Keunggulan Operasional terutama berfokus pada prosedur untuk praktik pengembangan, observabilitas, dan manajemen rilis.
Prinsip desain Operational Excellence menyediakan strategi desain tingkat tinggi untuk mencapai tujuan tersebut untuk persyaratan operasional beban kerja.
Daftar periksa desain
Kumpulkan dan analisis data operasional sebagai bagian dari pemantauan beban kerja Anda. Ambil log dan metrik Traffic Manager yang relevan. Gunakan data ini untuk memecahkan masalah, memahami perilaku lalu lintas, dan menyempurnakan logika perutean.
Lihat data lalu lintas untuk profil. Data ini membantu menentukan area untuk peningkatan, seperti memperluas kehadiran Azure Anda di wilayah latensi tinggi. Ini juga menyoroti pola lalu lintas di berbagai wilayah untuk membantu Anda menentukan tempat untuk meningkatkan atau mengurangi investasi.
Menerapkan operasi pemulihan bencana. Implementasi pemulihan bencana Anda dapat dirancang untuk mengalihkan lalu lintas jaringan/web dari situs utama ke situs cadangan. Metode pemulihan bencana ini dapat diimplementasikan menggunakan Azure DNS dan Azure Traffic Manager (DNS). Jika terjadi bencana, jika titik akhir utama terdegradasi, Traffic Manager mengalihkan lalu lintas ke titik akhir sekunder yang sehat. Secara default, Traffic Manager memberikan prioritas ke titik akhir utama, tetapi juga dapat diatur dengan titik akhir failover tambahan atau load balancer untuk mendistribusikan beban lalu lintas. Untuk informasi selengkapnya, lihat Menyiapkan pemulihan bencana dan deteksi pemadaman.
Hindari operasi failback otomatis. Saat Anda melakukan failback, jangan gunakan failback otomatis, yang langsung beralih kembali ke titik akhir asli di sistem primer saat tersedia. Sebagai gantinya, nonaktifkan titik akhir asli, dan gunakan titik akhir sekunder hingga Anda ingin beralih. Pendekatan ini memberikan waktu untuk stabilisasi. Failback yang segera dapat menyebabkan beban dan penundaan tambahan.
Untuk informasi selengkapnya, lihat arsitektur referensi penyeimbangan beban multiregion .
Menguji pengaturan konfigurasi. Kesalahan konfigurasi dapat memengaruhi semua aspek beban kerja, terutama keandalan. Uji konfigurasi dengan beberapa klien di berbagai lokasi. Untuk informasi selengkapnya, lihat Periksa pengaturan Traffic Manager.
Rekomendasi
Rekomendasi | Manfaat |
---|---|
Aktifkan log diagnostik untuk profil Traffic Manager. Gunakan alat untuk memutar ulang log dan menganalisis data pemeriksaan kesehatan. |
Log diagnostik memberikan wawasan tentang perilaku profil Traffic Manager. Misalnya, Anda dapat mengidentifikasi alasan waktu pemeriksaan individual habis terhadap titik akhir. |
Aktifkan dasbor tampilan lalu lintas . Dapatkan wawasan tentang dari mana klien Anda terhubung dan latensi terkait. | Informasi ini membantu mengoptimalkan performa dan biaya karena Anda dapat menyempurnakan desain Anda. |
Manfaatkan REST API Peta Panas , yang menyediakan data tentang lokasi dan latensi klien. | Pendekatan ini menawarkan fleksibilitas, seperti mengatur periode waktu tertentu. Anda dapat menambahkan data ke alat atau dasbor kustom. Anda juga dapat menggunakan API ini untuk berintegrasi dengan alat eksternal. |
Nonaktifkan titik akhir untuk aktivitas operasional. Misalnya, Anda dapat menonaktifkan failback setelah failover untuk melakukan pemeliharaan atau pengujian. | Menonaktifkan titik akhir dari load balancer bermanfaat untuk tugas operasional karena Anda tidak dapat menghentikan lalu lintas langsung. Selama pemeliharaan, instans tidak menerima lalu lintas jika Anda menonaktifkan titik akhir. Pendekatan ini mencegah failback otomatis. |
Efisiensi Performa
Efisiensi Performa adalah tentang mempertahankan pengalaman pengguna bahkan ketika ada peningkatan beban dengan mengelola kapasitas. Strategi ini mencakup penskalaan sumber daya, mengidentifikasi dan mengoptimalkan potensi hambatan, dan mengoptimalkan performa puncak.
Prinsip desain Efisiensi Performa menyediakan strategi desain tingkat tinggi untuk mencapai tujuan kapasitas tersebut terhadap penggunaan yang diharapkan.
Daftar periksa desain
Mulailah strategi desain Anda berdasarkan daftar periksa tinjauan desain untuk Efisiensi Kinerja. Tentukan garis besar yang didasarkan pada indikator performa utama untuk Traffic Manager.
Mengukur dampak performa konfigurasi Anda. Traffic Manager tidak mengganggu koneksi langsung antara klien dan titik akhir Anda. Dampak performa utama adalah pencarian DNS awal. Pengaturan TTL memengaruhi seberapa sering pencarian ini terjadi. TTL yang lebih rendah berarti resolusi DNS yang lebih sering, yang sedikit dapat memengaruhi performa. Jika Anda mengatur TTL ke nol, setiap permintaan memerlukan pencarian DNS, yang menambahkan penundaan kecil sebelum mengakses titik akhir.
Karena Traffic Manager beroperasi di tingkat DNS, Traffic Manager tidak mendukung afinitas sesi. Traffic Manager mungkin mengarahkan pengguna ke titik akhir yang berbeda untuk setiap panggilan. Jika Anda memerlukan kecocokan sesi, Anda harus menyimpan status ke penyimpanan data terpisah.
Untuk informasi selengkapnya, lihat pertimbangan Performa untuk Traffic Manager.
Sesuaikan perilaku perutean lalu lintas untuk mengoptimalkan kinerja. Satu profil dapat memiliki beberapa titik akhir, tetapi Anda hanya dapat menerapkan satu metode perutean pada satu waktu.
Untuk skenario yang lebih kompleks, pertimbangkan untuk membuat hierarki profil untuk menggabungkan metode perutean yang berbeda. Misalnya, Anda mungkin memprioritaskan wilayah, lalu menggunakan perutean berbasis kinerja di dalam wilayah.
Rekomendasi
Rekomendasi | Manfaat |
---|---|
Gunakan metode perutean performa saat Anda memiliki titik akhir di lokasi geografis yang berbeda. | Metode ini memprioritaskan pengiriman lalu lintas ke titik akhir yang memiliki latensi terendah. Metode ini membantu memastikan layanan cepat untuk pengguna. |
Gunakan alat khusus untuk mengoptimalkan performa. Ukur performa pemeriksaan DNS Anda. Untuk menganalisis performa lalu lintas, gunakan dasbor tampilan lalu lintas atau Heat Map REST API. | Alat pengukuran latensi DNS melakukan pencarian DNS lengkap dan menyediakan data performa. Anda dapat menggunakan data ini untuk mengatur durasi TTL dan mengoptimalkan performa. |
Gabungkan metode lalu lintas dengan profil berlapis untuk performa optimal, sebagaimana ditentukan oleh persyaratan beban kerja Anda. | Metode perutean yang dioptimalkan membantu memastikan bahwa lalu lintas diarahkan ke titik akhir yang paling responsif dan terdekat. Pendekatan ini membantu meningkatkan performa aplikasi dan pengalaman pengguna. |
Gunakan fitur pengukuran pengguna nyata untuk melihat pengukuran latensi jaringan ke wilayah Azure. Fitur ini tersedia tanpa biaya tambahan. | Anda dapat membuat keputusan perutean berbasis data untuk mengarahkan kueri ke wilayah Azure yang menyediakan latensi terendah. |
Atur interval TTL DNS ke nilai yang lebih tinggi. | Klien dapat menyimpan hasil untuk jangka waktu yang lebih lama, yang mengurangi kebutuhan untuk mengatasi DNS setiap kali. |
Kebijakan Azure
Azure menyediakan serangkaian kebijakan bawaan yang luas yang terkait dengan Traffic Manager dan dependensinya. Beberapa rekomendasi sebelumnya dapat diaudit melalui Azure Policy. Misalnya, Anda dapat memeriksa apakah:
- Catatan sumber daya diaktifkan untuk pelacakan aktivitas.
- Log untuk profil Traffic Manager dikirim ke Azure Event Hubs.
Untuk tata kelola yang komprehensif, tinjau definisi bawaan Azure Policy untuk layanan jaringan Azure.
Rekomendasi Azure Advisor
Azure Advisor adalah konsultan cloud yang dipersonalisasi yang membantu Anda mengikuti praktik terbaik untuk mengoptimalkan penyebaran Azure Anda. Berikut adalah beberapa rekomendasi yang dapat membantu Anda meningkatkan keandalan, keamanan, efektivitas biaya, performa, dan keunggulan operasional instans aplikasi web Anda.
Kompromi
Anda mungkin harus membuat kompromi desain jika Anda menggunakan pendekatan pada daftar periksa pilar. Berikut adalah beberapa contoh keuntungan dan kelemahannya.
Keandalan dan Efisiensi Performa
Pengaturan TTL untuk pencarian DNS. Pengaturan TTL default dapat menghasilkan waktu penyimpanan yang lebih lama. Waktu penyimpanan cache yang lama dapat menyebabkan gangguan jika titik akhir gagal karena aplikasi terus mencoba menyambung ke titik akhir yang gagal selama durasi TTL.
Kurangi TTL untuk membantu mengurangi masalah ini. TTL yang lebih rendah memiliki pembaruan yang lebih sering dan failover yang lebih cepat, tetapi meningkatkan frekuensi pencarian DNS. Pendekatan ini dapat memengaruhi performa dan meningkatkan beban pada server DNS.
Keandalan dan Pengoptimalan Biaya
- Pemeriksaan kesehatan. Traffic Manager menggunakan probe kesehatan untuk melakukan ping pada titik akhir Anda dari berbagai lokasi guna memeriksa ketersediaannya. Anda dapat memilih ping lambat atau ping cepat. Ping cepat mendeteksi kegagalan lebih cepat tetapi menambahkan biaya. Ping lambat membutuhkan waktu lebih lama untuk mendeteksi kegagalan tetapi lebih murah. Seimbangkan kecepatan deteksi kegagalan dan pemulihan dengan biaya terkait.
Langkah berikutnya
Pertimbangkan sumber daya berikut yang menunjukkan rekomendasi dalam artikel ini.
Gunakan arsitektur referensi berikut sebagai contoh bagaimana Anda dapat menerapkan panduan artikel ini ke beban kerja:
Gunakan dokumentasi produk berikut untuk meningkatkan keahlian implementasi Anda: