Redundansi perutean global untuk aplikasi web yang sangat penting

Penting

Merancang implementasi redundansi yang menangani pemadaman platform global untuk arsitektur misi-kritis bisa rumit dan mahal. Karena potensi masalah yang mungkin muncul dengan desain ini, pertimbangkan dengan cermat tradeoff.

Dalam kebanyakan situasi, Anda tidak memerlukan arsitektur yang dijelaskan dalam artikel ini.

Sistem misi penting berusaha untuk meminimalkan satu titik kegagalan dengan membangun kemampuan redundansi dan penyembuhan diri dalam solusi sebanyak mungkin. Setiap titik masuk terpadu dari sistem dapat dianggap sebagai titik kegagalan. Jika komponen ini mengalami pemadaman, seluruh sistem akan offline bagi pengguna. Saat memilih layanan perutean, penting untuk mempertimbangkan keandalan layanan itu sendiri.

Dalam arsitektur garis besar untuk aplikasi yang sangat penting, Azure Front Door dipilih karena perjanjian tingkat Layanan (SLA) waktu aktif yang tinggi dan set fitur yang kaya:

• Merutekan lalu lintas ke beberapa wilayah dalam model aktif-aktif
• Failover transparan menggunakan TCP anycast
• Menyajikan konten statis dari simpul tepi dengan menggunakan jaringan pengiriman konten terintegrasi (CDN)
• Memblokir akses tidak sah dengan firewall aplikasi web terintegrasi

Front Door dirancang untuk memberikan ketahanan dan ketersediaan paling besar untuk tidak hanya pelanggan eksternal kami, tetapi juga untuk beberapa properti di seluruh Microsoft. Untuk informasi selengkapnya tentang kemampuan Front Door, lihat Mempercepat dan mengamankan aplikasi web Anda dengan Azure Front Door.

Kemampuan Front Door lebih dari cukup untuk memenuhi sebagian besar persyaratan bisnis, namun, dengan sistem terdistribusi apa pun, mengharapkan kegagalan. Jika persyaratan bisnis menuntut SLA komposit yang lebih tinggi atau waktu tanpa henti jika terjadi pemadaman, Anda harus mengandalkan jalur masuk lalu lintas alternatif. Namun, pengejaran SLA yang lebih tinggi dilengkapi dengan biaya yang signifikan, overhead operasional, dan dapat menurunkan keandalan Anda secara keseluruhan. Pertimbangkan dengan cermat tradeoff dan potensi masalah yang mungkin diperkenalkan jalur alternatif di komponen lain yang berada di jalur kritis. Bahkan ketika dampak tidak tersedia signifikan, kompleksitas mungkin melebihi manfaatnya.

Salah satu pendekatannya adalah menentukan jalur sekunder, dengan layanan alternatif, yang menjadi aktif hanya ketika Azure Front Door tidak tersedia. Paritas fitur dengan Front Door tidak boleh diperlakukan sebagai persyaratan yang sulit. Prioritaskan fitur yang benar-benar Anda butuhkan untuk tujuan kelangsungan bisnis, bahkan berpotensi berjalan dalam kapasitas terbatas.

Pendekatan lain adalah menggunakan teknologi pihak ketiga untuk perutean global. Pendekatan ini akan memerlukan penyebaran aktif-aktif multicloud dengan stempel yang dihosting di dua penyedia cloud atau lebih. Meskipun Azure dapat secara efektif diintegrasikan dengan platform cloud lainnya, pendekatan ini tidak disarankan karena kompleksitas operasional di berbagai platform cloud.

Artikel ini menjelaskan beberapa strategi untuk perutean global menggunakan Azure Traffic Manager sebagai router alternatif dalam situasi di mana Azure Front Door tidak tersedia.

Pendekatan

Diagram arsitektur ini menunjukkan pendekatan umum dengan beberapa jalur lalu lintas yang berlebihan.

Dengan pendekatan ini, kami akan memperkenalkan beberapa komponen dan memberikan panduan yang akan membuat perubahan signifikan yang terkait dengan pengiriman aplikasi web Anda:

1. Azure Traffic Manager mengarahkan lalu lintas ke Azure Front Door atau ke layanan alternatif yang telah Anda pilih.

   Azure Traffic Manager adalah penyeimbang beban global berbasis DNS. Data CNAME domain Anda menunjuk ke Traffic Manager, yang menentukan tujuan berdasarkan cara Anda mengonfigurasi metode peruteannya. Menggunakan perutean prioritas akan membuat arus lalu lintas melalui Azure Front Door secara default. Traffic Manager dapat secara otomatis mengalihkan lalu lintas ke jalur alternatif Anda jika Azure Front Door tidak tersedia.

   Penting

   Solusi ini mengurangi risiko yang terkait dengan pemadaman Azure Front Door, tetapi rentan terhadap pemadaman Azure Traffic Manager sebagai titik kegagalan global.

   Anda juga dapat mempertimbangkan untuk menggunakan sistem perutean lalu lintas global yang berbeda, seperti penyeimbang beban global. Namun, Traffic Manager bekerja dengan baik untuk banyak situasi.

2. Anda memiliki dua jalur masuk:

   • Azure Front Door menyediakan jalur utama dan proses serta merutekan semua lalu lintas aplikasi Anda.

   • Router lain digunakan sebagai cadangan untuk Azure Front Door. Lalu lintas hanya mengalir melalui jalur sekunder ini jika Front Door tidak tersedia.

   Layanan spesifik yang Anda pilih untuk router sekunder tergantung pada banyak faktor. Anda dapat memilih untuk menggunakan layanan asli Azure, atau layanan pihak ketiga. Dalam artikel ini, kami menyediakan opsi asli Azure untuk menghindari penambahan kompleksitas operasional tambahan ke solusi. Jika Anda menggunakan layanan pihak ketiga, Anda perlu menggunakan beberapa sarana kontrol untuk mengelola solusi Anda.

3. Server aplikasi asal Anda harus siap menerima lalu lintas dari salah satu layanan. Pertimbangkan bagaimana Anda mengamankan lalu lintas ke asal Anda, dan tanggung jawab apa yang disediakan Front Door dan layanan hulu lainnya. Pastikan aplikasi Anda dapat menangani lalu lintas dari jalur mana pun yang dilalui arus lalu lintas Anda.

Tradeoffs

Meskipun strategi mitigasi ini dapat membuat aplikasi tersedia selama pemadaman platform, ada beberapa tradeoff yang signifikan. Anda harus menimbang potensi manfaat terhadap biaya yang diketahui, dan membuat keputusan berdasarkan informasi tentang apakah manfaatnya sepadan dengan biaya tersebut.

• Biaya finansial: Saat Anda menyebarkan beberapa jalur redundan ke aplikasi, Anda perlu mempertimbangkan biaya penyebaran dan menjalankan sumber daya. Kami menyediakan dua contoh skenario untuk kasus penggunaan yang berbeda, yang masing-masing memiliki profil biaya yang berbeda.

• Kompleksitas operasional: Setiap kali Anda menambahkan komponen tambahan ke solusi, Anda meningkatkan overhead manajemen Anda. Setiap perubahan pada satu komponen dapat berdampak pada komponen lain.

  Misalkan Anda memutuskan untuk menggunakan kemampuan baru Azure Front Door. Anda perlu memeriksa apakah jalur lalu lintas alternatif Anda juga menyediakan kemampuan yang setara, dan jika tidak, Anda perlu memutuskan cara menangani perbedaan perilaku antara dua jalur lalu lintas. Dalam aplikasi dunia nyata, kompleksitas ini dapat memiliki biaya tinggi, dan dapat memberikan risiko besar bagi stabilitas sistem Anda.

• Performa: Desain ini memerlukan pencarian CNAME tambahan selama resolusi nama. Di sebagian besar aplikasi, ini bukan masalah yang signifikan, tetapi Anda harus mengevaluasi apakah performa aplikasi Anda terpengaruh dengan memperkenalkan lapisan tambahan ke jalur masuk Anda.

• Biaya peluang: Merancang dan mengimplementasikan jalur ingress redundan membutuhkan investasi teknik yang signifikan, yang pada akhirnya datang dengan biaya kesempatan untuk menampilkan pengembangan dan peningkatan platform lainnya.

Peringatan

Jika Anda tidak berhati-hati dalam bagaimana Anda merancang dan menerapkan solusi ketersediaan tinggi yang kompleks, Anda benar-benar dapat memperburuk ketersediaan Anda. Meningkatkan jumlah komponen dalam arsitektur Anda meningkatkan jumlah titik kegagalan. Ini juga berarti Anda memiliki tingkat kompleksitas operasional yang lebih tinggi. Ketika Anda menambahkan komponen tambahan, setiap perubahan yang Anda buat perlu ditinjau dengan hati-hati untuk memahami bagaimana hal itu memengaruhi solusi Anda secara keseluruhan.

Ketersediaan Azure Traffic Manager

Azure Traffic Manager adalah layanan yang andal, tetapi perjanjian tingkat layanan tidak menjamin ketersediaan 100%. Jika Traffic Manager tidak tersedia, pengguna Anda mungkin tidak dapat mengakses aplikasi Anda, meskipun Azure Front Door dan layanan alternatif Anda keduanya tersedia. Penting untuk merencanakan bagaimana solusi Anda akan terus beroperasi dalam keadaan ini.

Traffic Manager mengembalikan respons DNS yang dapat di-cache. Jika time to live (TTL) pada catatan DNS Anda memungkinkan penembolokan, pemadaman Traffic Manager yang singkat mungkin tidak menjadi perhatian. Itu karena pemecah masalah DNS hilir mungkin telah menyimpan cache respons sebelumnya. Anda harus merencanakan pemadaman yang berkepanjangan. Anda dapat memilih untuk mengonfigurasi ulang server DNS Anda secara manual untuk mengarahkan pengguna ke Azure Front Door jika Traffic Manager tidak tersedia.

Konsistensi perutean lalu lintas

Penting untuk memahami kemampuan dan fitur Azure Front Door yang Anda gunakan dan andalkan. Saat Anda memilih layanan alternatif, putuskan kemampuan minimum yang Anda butuhkan dan hilangkan fitur lain saat solusi Anda dalam mode terdegradasi.

Saat merencanakan jalur lalu lintas alternatif, berikut adalah beberapa pertanyaan utama yang harus Anda pertimbangkan:

• Apakah Anda menggunakan fitur penembolokan Azure Front Door? Jika penembolokan tidak tersedia, dapatkah server asal Anda mengikuti lalu lintas Anda?
• Apakah Anda menggunakan mesin aturan Azure Front Door untuk melakukan logika perutean kustom, atau untuk menulis ulang permintaan?
• Apakah Anda menggunakan firewall aplikasi web (WAF) Azure Front Door untuk mengamankan aplikasi Anda?
• Apakah Anda membatasi lalu lintas berdasarkan alamat IP atau geografi?
• Siapa yang menerbitkan dan mengelola sertifikat TLS Anda?
• Bagaimana Anda membatasi akses ke server aplikasi asal Anda untuk memastikannya datang melalui Azure Front Door? Apakah Anda menggunakan Private Link, atau apakah Anda mengandalkan alamat IP publik dengan tag layanan dan header pengidentifikasi?
• Apakah server aplikasi Anda menerima lalu lintas dari mana saja selain Azure Front Door? Jika mereka melakukannya, protokol mana yang mereka terima?
• Apakah klien Anda menggunakan dukungan HTTP/2 Azure Front Door?

Firewall aplikasi web (WAF)

Jika Anda menggunakan WAF Azure Front Door untuk melindungi aplikasi Anda, pertimbangkan apa yang terjadi jika lalu lintas tidak melalui Azure Front Door.

Jika jalur alternatif Anda juga menyediakan WAF, pertimbangkan pertanyaan berikut:

• Dapatkah dikonfigurasi dengan cara yang sama seperti Waf Azure Front Door Anda?
• Apakah perlu disetel dan diuji secara independen, untuk mengurangi kemungkinan deteksi positif palsu?

Peringatan

Anda dapat memilih untuk tidak menggunakan WAF untuk jalur masuk alternatif Anda. Pendekatan ini dapat dipertimbangkan untuk mendukung target keandalan aplikasi. Namun, ini bukan praktik yang baik dan kami tidak merekomendasikannya.

Pertimbangkan tradeoff dalam menerima lalu lintas dari internet tanpa pemeriksaan apa pun. Jika penyerang menemukan jalur lalu lintas sekunder yang tidak terlindungi ke aplikasi Anda, penyerang mungkin mengirim lalu lintas berbahaya melalui jalur sekunder Anda bahkan ketika jalur utama menyertakan WAF.

Yang terbaik adalah mengamankan semua jalur ke server aplikasi Anda.

Nama domain dan DNS

Aplikasi misi penting Anda harus menggunakan nama domain kustom. Anda akan mengontrol bagaimana lalu lintas mengalir ke aplikasi Anda, dan Anda mengurangi dependensi pada satu penyedia.

Ini juga merupakan praktik yang baik untuk menggunakan layanan DNS berkualitas tinggi dan tangguh untuk nama domain Anda, seperti Azure DNS. Jika server DNS nama domain Anda tidak tersedia, pengguna tidak dapat menjangkau layanan Anda.

Disarankan agar Anda menggunakan beberapa pemecah masalah DNS untuk meningkatkan ketahanan keseluruhan lebih jauh.

Penautan CNAME

Solusi yang menggabungkan Traffic Manager, Azure Front Door, dan layanan lainnya menggunakan proses resolusi DNS CNAME multi-lapisan, juga disebut penautan CNAME. Misalnya, saat Anda menyelesaikan domain kustom Anda sendiri, Anda mungkin melihat lima atau beberapa data CNAME sebelum alamat IP dikembalikan.

Menambahkan tautan tambahan ke rantai CNAME dapat memengaruhi performa resolusi nama DNS. Namun, respons DNS biasanya di-cache, yang mengurangi dampak performa.

Sertifikat TLS

Untuk aplikasi penting misi, disarankan agar Anda menyediakan dan menggunakan sertifikat TLS Anda sendiri alih-alih sertifikat terkelola yang disediakan oleh Azure Front Door. Anda akan mengurangi jumlah potensi masalah dengan arsitektur kompleks ini.

Berikut adalah beberapa manfaatnya:

• Untuk menerbitkan dan memperbarui sertifikat TLS terkelola, Azure Front Door memverifikasi kepemilikan domain Anda. Proses verifikasi domain mengasumsikan bahwa data CNAME domain Anda menunjuk langsung ke Azure Front Door. Tapi, asumsi itu sering kali tidak benar. Menerbitkan dan memperbarui sertifikat TLS terkelola di Azure Front Door mungkin tidak berfungsi dengan lancar dan Anda meningkatkan risiko pemadaman karena masalah sertifikat TLS.

• Bahkan jika layanan Anda yang lain menyediakan sertifikat TLS terkelola, mereka mungkin tidak dapat memverifikasi kepemilikan domain.

• Jika setiap layanan mendapatkan sertifikat TLS terkelola mereka sendiri secara independen, mungkin ada masalah. Misalnya, pengguna mungkin tidak mengharapkan untuk melihat sertifikat TLS yang berbeda yang dikeluarkan oleh otoritas yang berbeda, atau dengan tanggal kedaluwarsa atau thumbprint yang berbeda.

Namun, akan ada operasi tambahan yang terkait dengan perpanjangan dan pembaruan sertifikat Anda sebelum kedaluwarsa.

Keamanan asal

Saat Anda mengonfigurasi asal Anda untuk hanya menerima lalu lintas melalui Azure Front Door, Anda mendapatkan perlindungan terhadap serangan DDoS lapisan 3 dan lapisan 4. Karena Azure Front Door hanya merespons lalu lintas HTTP yang valid, azure Front Door juga membantu mengurangi paparan Anda terhadap banyak ancaman berbasis protokol. Jika Anda mengubah arsitektur untuk mengizinkan jalur masuk alternatif, Anda perlu mengevaluasi apakah Anda secara tidak sengaja meningkatkan paparan asal Anda terhadap ancaman.

Jika Anda menggunakan Private Link untuk menyambungkan dari Azure Front Door ke server asal Anda, bagaimana arus lalu lintas melalui jalur alternatif Anda? Dapatkah Anda menggunakan alamat IP privat untuk mengakses asal Anda, atau harus menggunakan alamat IP publik?

Jika asal Anda menggunakan tag layanan Azure Front Door dan header X-Azure-FDID untuk memvalidasi bahwa lalu lintas telah mengalir melalui Azure Front Door, pertimbangkan bagaimana asal Anda dapat dikonfigurasi ulang untuk memvalidasi bahwa lalu lintas telah mengalir melalui salah satu jalur Anda yang valid. Anda harus menguji bahwa Anda belum secara tidak sengaja membuka asal Anda ke lalu lintas melalui jalur lain, termasuk dari profil Azure Front Door pelanggan lain.

Saat Anda merencanakan keamanan asal Anda, periksa apakah jalur lalu lintas alternatif bergantung pada penyediaan alamat IP publik khusus. Ini mungkin memerlukan proses yang dipicu secara manual untuk membuat jalur cadangan online.

Jika ada alamat IP publik khusus, pertimbangkan apakah Anda harus menerapkan Azure DDoS Protection untuk mengurangi risiko penolakan serangan layanan terhadap asal Anda. Selain itu, pertimbangkan apakah Anda perlu menerapkan Azure Firewall atau firewall lain yang mampu melindungi Anda dari berbagai ancaman jaringan. Anda mungkin juga memerlukan lebih banyak strategi deteksi intrusi. Kontrol ini bisa menjadi elemen penting dalam arsitektur multi-jalur yang lebih kompleks.

Pemodelan kesehatan

Metodologi desain misi penting memerlukan model kesehatan sistem yang memberi Anda pengamatan keseluruhan solusi dan komponennya. Saat Anda menggunakan beberapa jalur masuk lalu lintas, Anda perlu memantau kesehatan setiap jalur. Jika lalu lintas Anda dialihkan ke jalur masuk sekunder, model kesehatan Anda harus mencerminkan fakta bahwa sistem masih beroperasi tetapi berjalan dalam keadaan terdegradasi.

Sertakan pertanyaan-pertanyaan ini dalam desain model kesehatan Anda:

• Bagaimana berbagai komponen solusi Anda memantau kesehatan komponen hilir?
• Kapan pemantauan kesehatan harus menganggap komponen hilir tidak sehat?
• Berapa lama waktu yang dibutuhkan untuk pemadaman terdeteksi?
• Setelah pemadaman terdeteksi, berapa lama waktu yang dibutuhkan lalu lintas untuk dirutekan melalui jalur alternatif?

Ada beberapa solusi penyeimbangan beban global yang memungkinkan Anda memantau kesehatan Azure Front Door dan memicu failover otomatis ke platform cadangan jika pemadaman terjadi. Azure Traffic Manager cocok dalam banyak kasus. Dengan Traffic Manager, Anda mengonfigurasi pemantauan titik akhir untuk memantau layanan hilir dengan menentukan URL mana yang akan diperiksa, seberapa sering memeriksa URL tersebut, dan kapan harus menganggap layanan hilir tidak sehat berdasarkan respons pemeriksaan. Secara umum, semakin pendek interval antara pemeriksaan, semakin sedikit waktu yang diperlukan Traffic Manager untuk mengarahkan lalu lintas melalui jalur alternatif untuk mencapai server asal Anda.

Jika Front Door tidak tersedia, maka beberapa faktor memengaruhi jumlah waktu pemadaman memengaruhi lalu lintas Anda, termasuk:

• Time to live (TTL) pada catatan DNS Anda.
• Seberapa sering Traffic Manager menjalankan pemeriksaan kesehatannya.
• Berapa banyak pemeriksaan yang gagal yang dikonfigurasi Traffic Manager untuk melihat sebelum mengalihkan lalu lintas.
• Berapa lama klien dan server DNS upstream menyimpan respons DNS Traffic Manager.

Anda juga perlu menentukan faktor mana yang berada dalam kontrol Anda dan apakah layanan upstram di luar kontrol Anda dapat memengaruhi pengalaman pengguna. Misalnya, bahkan jika Anda menggunakan TTL rendah pada catatan DNS Anda, cache DNS upstram mungkin masih melayani respons kedaluarsa lebih lama dari yang seharusnya. Perilaku ini mungkin memperburuk efek pemadaman atau membuatnya tampak seperti aplikasi Anda tidak tersedia, bahkan ketika Traffic Manager telah beralih untuk mengirim permintaan ke jalur lalu lintas alternatif.

Tip

Solusi misi-kritis memerlukan pendekatan failover otomatis sedapat mungkin. Proses failover manual dianggap lambat agar aplikasi tetap responsif.

Lihat: Area desain misi penting: Pemodelan kesehatan

Penyebaran waktu henti nol

Saat Anda merencanakan cara mengoperasikan solusi dengan jalur ingress yang berlebihan, Anda juga harus merencanakan cara Anda menyebarkan atau mengonfigurasi layanan saat terdegradasi. Untuk sebagian besar layanan Azure, SLA berlaku untuk waktu aktif layanan itu sendiri, dan bukan untuk operasi manajemen atau penyebaran. Pertimbangkan apakah proses penyebaran dan konfigurasi Anda perlu dibuat tahan terhadap pemadaman layanan.

Anda juga harus mempertimbangkan jumlah sarana kontrol independen yang perlu berinteraksi dengan Anda untuk mengelola solusi Anda. Saat Anda menggunakan layanan Azure, Azure Resource Manager menyediakan sarana kontrol terpadu dan konsisten. Namun, jika Anda menggunakan layanan pihak ketiga untuk merutekan lalu lintas, Anda mungkin perlu menggunakan sarana kontrol terpisah untuk mengonfigurasi layanan, yang memperkenalkan kompleksitas operasional lebih lanjut.

Peringatan

Penggunaan beberapa sarana kontrol memperkenalkan kompleksitas dan risiko terhadap solusi Anda. Setiap titik perbedaan meningkatkan kemungkinan seseorang secara tidak sengaja melewatkan pengaturan konfigurasi, atau menerapkan konfigurasi yang berbeda ke komponen redundan. Pastikan bahwa prosedur operasional Anda mengurangi risiko ini.

Lihat: Area desain misi-kritis: Penyebaran zero-downtime

Validasi berkelanjutan

Untuk solusi misi penting, praktik pengujian Anda perlu memverifikasi bahwa solusi Anda memenuhi kebutuhan Anda terlepas dari jalur yang dilalui lalu lintas aplikasi Anda. Pertimbangkan setiap bagian dari solusi dan bagaimana Anda mengujinya untuk setiap jenis pemadaman.

Pastikan bahwa proses pengujian Anda menyertakan elemen-elemen ini:

• Dapatkah Anda memverifikasi bahwa lalu lintas dialihkan dengan benar melalui jalur alternatif ketika jalur utama tidak tersedia?
• Dapatkah kedua jalur mendukung tingkat lalu lintas produksi yang Anda harapkan untuk diterima?
• Apakah kedua jalur diamankan secara memadai, untuk menghindari membuka atau mengekspos kerentanan saat Anda dalam keadaan terdegradasi?

Lihat: Area desain misi penting: Validasi berkelanjutan

Skenario umum

Berikut adalah skenario umum di mana desain ini dapat digunakan:

• Pengiriman konten global biasanya berlaku untuk pengiriman konten statis, media, dan aplikasi eCommerce skala tinggi. Dalam skenario ini, penembolokan adalah bagian penting dari arsitektur solusi, dan kegagalan untuk cache dapat mengakibatkan performa atau keandalan yang terdegradasi secara signifikan.

• Ingress HTTP global biasanya berlaku untuk aplikasi dan API dinamis misi-kritis. Dalam skenario ini, persyaratan intinya adalah merutekan lalu lintas ke server asal dengan andal dan efisien. Sering kali, WAF adalah kontrol keamanan penting yang digunakan dalam solusi ini.

Peringatan

Jika Anda tidak berhati-hati dalam bagaimana Anda merancang dan menerapkan solusi multi-ingress yang kompleks, Anda sebenarnya dapat membuat ketersediaan Anda lebih buruk. Meningkatkan jumlah komponen dalam arsitektur Anda meningkatkan jumlah titik kegagalan. Ini juga berarti Anda memiliki tingkat kompleksitas operasional yang lebih tinggi. Ketika Anda menambahkan komponen tambahan, setiap perubahan yang Anda buat perlu ditinjau dengan hati-hati untuk memahami bagaimana hal itu memengaruhi solusi Anda secara keseluruhan.

Langkah berikutnya

Tinjau ingress HTTP global dan skenario pengiriman konten global untuk memahami apakah itu berlaku untuk solusi Anda.