Aplikasi web multi-wilayah dengan ketersediaan tinggi

App Service
Cosmos DB
Front Door
Penyimpanan
SQL Database

Arsitektur referensi ini menunjukkan cara menjalankan aplikasi Azure App Service di beberapa wilayah untuk mencapai ketersediaan tinggi.

Ada beberapa pendekatan umum untuk mencapai ketersediaan tinggi di seluruh wilayah:

  • Aktif/Pasif dengan siaga panas: lalu lintas menuju satu wilayah, sementara yang lain menunggu dalam siaga panas. Siaga panas berarti VM di wilayah sekunder dialokasikan dan berjalan setiap saat.

  • Aktif/Pasif dengan siaga dingin: lalu lintas menuju satu wilayah, sementara yang lain menunggu dalam siaga dingin. Siaga dingin berarti VM di wilayah sekunder tidak dialokasikan hingga diperlukan untuk failover. Pendekatan ini membutuhkan biaya lebih sedikit untuk dijalankan, tetapi umumnya akan memakan waktu lebih lama untuk online saat terjadi kegagalan.

  • Aktif/Aktif: kedua wilayah aktif, dan permintaan seimbang antara keduanya. Jika satu wilayah menjadi tidak tersedia, maka wilayah tersebut dikeluarkan dari rotasi.

Referensi ini berfokus pada aktif/pasif dengan siaga panas. Ini memperluas desain wilayah tunggal untuk aplikasi web yang dapat diskalakan. Lihat Aplikasi web yang dapat diskalakan untuk informasi tentang arsitektur dasar.

Kemungkinan kasus penggunaan

Kasus penggunaan ini dapat mengambil manfaat dari penerapan multi-wilayah:

  • Merancang rencana kelangsungan bisnis dan pemulihan bencana untuk aplikasi LoB

  • Menerapkan aplikasi misi kritis yang berjalan di Windows atau Linux

  • Tingkatkan pengalaman pengguna dengan menjaga agar aplikasi tetap tersedia

Arsitektur

Diagram yang menunjukkan arsitektur referensi untuk aplikasi web dengan ketersediaan tinggi.

Unduh file Visio arsitektur ini.

Alur kerja

Arsitektur ini dibangun berdasarkan yang ditunjukkan dalam aplikasi web yang dapat diskalakan. Perbedaan utama adalah:

  • Wilayah primer dan sekunder. Arsitektur ini menggunakan dua wilayah untuk mencapai ketersediaan yang lebih tinggi. Aplikasi ini disebarkan ke setiap wilayah. Selama operasi normal, lalu lintas jaringan diarahkan ke wilayah utama. Jika wilayah utama menjadi tidak tersedia, lalu lintas diarahkan ke wilayah sekunder.
  • Front Door. Front Door mengarahkan permintaan masuk ke wilayah utama. Jika aplikasi yang menjalankan wilayah itu menjadi tidak tersedia, Front Door melakukan failover ke wilayah sekunder.
  • Replikasi geografis Database SQL dan/atau Cosmos DB.

Arsitektur multi-wilayah dapat memberikan ketersediaan yang lebih tinggi daripada menyebarkan ke satu wilayah. Jika pemadaman wilayah memengaruhi wilayah utama, Anda dapat menggunakan Front Door untuk beralih ke wilayah sekunder. Arsitektur ini juga dapat membantu jika sub-sistem individu dari aplikasi gagal.

Komponen

Teknologi utama yang digunakan untuk mengimplementasikan arsitektur ini:

Rekomendasi

Persyaratan Anda mungkin berbeda dari arsitektur yang dijelaskan di sini. Gunakan rekomendasi di bagian ini sebagai titik awal.

Pasangan wilayah

Setiap wilayah Azure dipasangkan dengan wilayah lain dalam geografi yang sama. Secara umum, pilih wilayah dari pasangan wilayah yang sama (misalnya, AS Timur 2 dan AS Tengah). Manfaat melakukannya meliputi:

  • Jika terjadi pemadaman yang luas, pemulihan setidaknya satu wilayah lebih diprioritaskan dari setiap pasangan.
  • Pembaruan sistem Azure yang direncanakan diluncurkan ke wilayah yang dipasangkan secara berurutan untuk meminimalkan kemungkinan waktu henti.
  • Dalam kebanyakan kasus, pasangan wilayah berada dalam geografi yang sama untuk memenuhi persyaratan residensi data.

Namun, pastikan kedua wilayah mendukung semua layanan Azure yang diperlukan untuk aplikasi Anda. Lihat Layanan menurut wilayah. Untuk informasi selengkapnya tentang pasangan wilayah, lihat Keberlangsungan bisnis dan pemulihan bencana (BCDR): Wilayah Berpasangan Azure.

Grup sumber daya

Pertimbangkan untuk menempatkan wilayah utama, wilayah sekunder, dan Front Door ke dalam grup sumber daya terpisah. Ini memungkinkan Anda mengelola sumber daya yang diterapkan ke setiap wilayah sebagai satu koleksi.

Konfigurasi Front Door

Perutean. Front Door mendukung beberapa mekanisme perutean. Untuk skenario yang dijelaskan dalam artikel ini, gunakan perutean prioritas. Dengan pengaturan ini, Front Door mengirimkan semua permintaan ke wilayah utama kecuali titik akhir untuk wilayah tersebut menjadi tidak terjangkau. Pada saat itu, Traffic Manager akan secara otomatis melakukan failover ke wilayah sekunder. Atur kumpulan backend dengan nilai prioritas yang berbeda, 1 untuk wilayah aktif dan 2 atau lebih tinggi untuk wilayah siaga atau pasif.

Pemeriksaan kesehatan. Front Door menggunakan probe HTTP (atau HTTPS) untuk memantau ketersediaan setiap ujung belakang. Probe memberikan Front Door tes lulus/gagal karena gagal ke wilayah sekunder. Ini bekerja dengan mengirimkan permintaan ke jalur URL yang ditentukan. Jika mendapat respons non-200 dalam periode waktu habis, probe gagal. Anda dapat mengonfigurasi frekuensi pemeriksaan kesehatan, jumlah sampel yang diperlukan untuk evaluasi, dan jumlah sampel yang berhasil yang diperlukan agar backend ditandai sebagai sehat. Jika Front Door menandai backend sebagai terdegradasi, ia gagal ke backend lainnya. Untuk detailnya, lihat Probe Kesehatan.

Sebagai praktik terbaik, buat jalur pemeriksaan kesehatan di backend aplikasi Anda yang melaporkan kesehatan aplikasi secara keseluruhan. Pemeriksaan kesehatan ini harus memeriksa dependensi penting seperti aplikasi App Service, antrean penyimpanan, dan Database SQL. Jika tidak, probe mungkin melaporkan backend yang sehat ketika bagian penting dari aplikasi benar-benar gagal. Di sisi lain, jangan gunakan pemeriksaan kesehatan untuk memeriksa layanan dengan prioritas lebih rendah. Misalnya, jika layanan email mati, aplikasi dapat beralih ke penyedia kedua atau hanya mengirim email nanti. Untuk diskusi selengkapnya tentang pola desain ini, lihat Pola Pemantauan Titik Akhir Kesehatan.

SQL Database

Gunakan Replikasi Geografis Aktif untuk membuat replika sekunder yang dapat dibaca di wilayah yang berbeda. Anda dapat memiliki hingga empat replika sekunder yang dapat dibaca. Failover ke database sekunder jika database utama Anda gagal atau perlu dibuat offline. Replikasi Geografis Aktif dapat dikonfigurasi untuk database apa pun di kumpulan database elastis apa pun.

Cosmos DB

Cosmos DB mendukung replikasi geografis di seluruh wilayah dalam pola aktif-aktif dengan beberapa wilayah tulis. Atau, Anda dapat menetapkan satu wilayah sebagai wilayah yang dapat ditulis dan yang lainnya sebagai replika hanya-baca. Jika ada pemadaman wilayah, Anda dapat melakukan failover dengan memilih wilayah lain untuk menjadi wilayah tulis. SDK klien secara otomatis mengirimkan permintaan tulis ke wilayah penulisan saat ini, jadi Anda tidak perlu memperbarui konfigurasi klien setelah failover. Untuk informasi selengkapnya, lihat Distribusi data global dengan Azure Cosmos DB.

Catatan

Semua replika menjadi milik grup sumber daya yang sama.

Penyimpanan

Untuk Penyimpanan Azure, gunakan penyimpanan geo-redundan akses baca (RA-GRS). Dengan penyimpanan RA-GRS, data direplikasi ke wilayah sekunder. Anda memiliki akses baca-saja ke data di wilayah sekunder melalui titik akhir terpisah. Jika ada pemadaman wilayah atau bencana, tim Penyimpanan Azure mungkin memutuskan untuk melakukan geo-failover ke wilayah sekunder. Tidak ada tindakan pelanggan yang diperlukan untuk failover ini.

Untuk penyimpanan antrean, buat antrean cadangan di wilayah sekunder. Selama failover, aplikasi dapat menggunakan antrean pencadangan hingga wilayah utama tersedia kembali. Dengan begitu, aplikasi masih bisa memproses permintaan baru.

Pertimbangan

Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat digunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.

Keandalan

Keandalan memastikan aplikasi Anda dapat mencapai komitmen yang Anda buat kepada pelanggan Anda. Untuk informasi selengkapnya, lihat Gambaran umum pilar keandalan. Pertimbangkan poin-poin ini saat mendesain ketersediaan tinggi di seluruh wilayah.

Azure Front Door

Azure Front Door secara otomatis gagal jika wilayah utama menjadi tidak tersedia. Ketika Front Door gagal, ada periode waktu (biasanya sekitar 20-60 detik) ketika klien tidak dapat mencapai aplikasi. Durasi dipengaruhi oleh faktor-faktor berikut:

  • Frekuensi pemeriksaan kesehatan. Semakin sering pemeriksaan kesehatan dikirim, Front Door lebih cepat dapat mendeteksi waktu henti atau backend kembali sehat.
  • Konfigurasi ukuran sampel. Konfigurasi ini mengontrol berapa banyak sampel yang diperlukan untuk pemeriksaan kesehatan untuk mendeteksi bahwa backend utama tidak dapat dijangkau. Jika nilai ini terlalu rendah, Anda bisa mendapatkan hasil positif palsu dari masalah yang terputus-putus.

Front Door adalah kemungkinan titik kegagalan dalam sistem. Jika layanan gagal, klien tidak dapat mengakses aplikasi Anda selama waktu henti. Tinjau Perjanjian tingkat layanan (SLA) Front Door dan tentukan apakah menggunakan Front Door saja memenuhi persyaratan bisnis Anda untuk ketersediaan tinggi. Jika tidak, pertimbangkan untuk menambahkan solusi manajemen lalu lintas lain sebagai cadangan. Jika layanan Front Door gagal, ubah rekaman nama kanonik (CNAME) Anda di DNS untuk menunjuk ke layanan manajemen lalu lintas lainnya. Langkah ini harus dilakukan secara manual, dan aplikasi Anda tidak akan tersedia sampai perubahan DNS disebarkan.

Tingkat Azure Front Door Standard dan Premium menggabungkan kemampuan Azure Front Door(klasik), Azure CDN Standard dari Microsoft (klasik), dan Azure WAF ke dalam satu platform. Menggunakan Azure Front Door Standard atau Premium mengurangi titik kegagalan dan memungkinkan kontrol, pemantauan, dan keamanan yang ditingkatkan. Untuk informasi selengkapnya, lihat Gambaran Umum tingkat Azure Front Door.

SQL Database

Tujuan titik pemulihan (RPO) dan perkiraan tujuan waktu pemulihan (RTO) untuk SQL Database di dokumentasikan dalam Gambaran Umum kelangsungan bisnis dengan Azure SQL Database.

Cosmos DB

RPO dan tujuan waktu pemulihan (RTO) untuk Cosmos DB dapat dikonfigurasi melalui tingkat konsistensi yang digunakan, yang memberikan keseimbangan antara ketersediaan, ketahanan data, dan throughput. Cosmos DB memberikan RTO minimum 0 untuk tingkat konsistensi yang santai dengan multi-master atau RPO 0 untuk konsistensi yang kuat dengan single-master. Untuk mempelajari selengkapnya tentang tingkat konsistensi Cosmos DB, lihat Tingkat konsistensi dan daya tahan data di Cosmos DB.

Penyimpanan

Penyimpanan RA-GRS menyediakan penyimpanan yang tahan lama, tetapi penting untuk memahami apa yang dapat terjadi selama pemadaman:

  • Jika terjadi pemadaman penyimpanan, akan ada periode waktu ketika Anda tidak memiliki akses tulis ke data. Anda masih dapat membaca dari titik akhir sekunder selama pemadaman.

  • Jika pemadaman wilayah atau bencana memengaruhi lokasi utama dan data di sana tidak dapat dipulihkan, tim Penyimpanan Azure dapat memutuskan untuk melakukan geo-failover ke wilayah sekunder.

  • Replikasi data ke wilayah sekunder dilakukan secara asinkron. Oleh karena itu, jika geo-failover dilakukan, beberapa kehilangan data mungkin terjadi jika data tidak dapat dipulihkan dari wilayah utama.

  • Kegagalan sementara, seperti pemadaman jaringan, tidak akan memicu kegagalan penyimpanan. Rancang aplikasi Anda agar tahan terhadap kegagalan sementara. Opsi mitigasi meliputi:

    • Baca dari wilayah sekunder.
    • Beralih sementara ke akun penyimpanan lain untuk operasi tulis baru (misalnya, untuk mengantre pesan).
    • Salin data dari wilayah sekunder ke akun penyimpanan lain.
    • Menyediakan fungsionalitas yang dikurangi hingga sistem gagal kembali.

Untuk informasi selengkapnya, lihat Apa yang harus dilakukan jika pemadaman Microsoft Azure Storage terjadi.

Failover

Jika database utama gagal, lakukan failover manual ke database sekunder. Lihat Memulihkan Database Azure SQL atau failover ke sekunder. Database sekunder tetap hanya-baca sampai Anda gagal.

Keamanan

Keamanan memberikan jaminan terhadap serangan yang disengaja dan penyalahgunaan data dan sistem berharga Anda. Untuk informasi selengkapnya, lihat Gambaran umum pilar keamanan.

Arsitektur ini dibangun berdasarkan yang ditunjukkan dalam aplikasi web yang dapat diskalakan, lihat bagian Pertimbangan keamanan.

Saat menentukan identitas untuk komponen dalam arsitektur ini, gunakan identitas terkelola sistem jika memungkinkan untuk mengurangi kebutuhan Anda untuk mengelola kredensial dan risiko yang melekat pada pengelolaan kredensial. Jika tidak dimungkinkan untuk menggunakan identitas terkelola sistem, pastikan bahwa setiap identitas yang dikelola pengguna hanya ada di satu wilayah dan tidak pernah dibagikan di seluruh batas wilayah.

Saat mengonfigurasi firewall layanan untuk komponen, pastikan bahwa hanya layanan lokal wilayah yang memiliki akses ke layanan dan layanan tersebut hanya mengizinkan koneksi keluar sebagaimana diperlukan secara eksplisit untuk fungsionalitas replikasi dan aplikasi. Pertimbangkan untuk menggunakan Azure Private Link untuk kontrol dan segmentasi yang lebih ditingkatkan. Untuk informasi selengkapnya tentang mengamankan aplikasi web, lihat Aplikasi web yang diperkeras jaringan dengan konektivitas privat ke penyimpanan data PaaS.

Pengoptimalan biaya

Optimalisasi biaya adalah tentang mencari cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Gambaran umum pilar pengoptimalan biaya.

Gunakan kalkulator harga untuk memperkirakan biaya. Rekomendasi di bagian ini dapat membantu Anda mengurangi biaya.

Azure Front Door

Penagihan Front Door Azure memiliki tiga tingkatan harga: transfer data keluar, transfer data masuk, dan aturan perutean. Untuk info selengkapnya Lihat Harga Azure Front Door. Bagan harga tidak termasuk biaya mengakses data dari layanan backend dan mentransfer ke Front Door. Biaya tersebut ditagih berdasarkan biaya transfer data, yang dijelaskan dalam Rincian Harga Bandwidth.

Azure Cosmos DB

Ada dua faktor yang menentukan harga Azure Cosmos DB:

  • Throughput yang disediakan atau Unit Permintaan per detik (RU/s).

    Ada dua jenis throughput yang dapat disediakan di Cosmos DB, standar dan skala otomatis. Throughput standar mengalokasikan sumber daya yang diperlukan untuk menjamin RU/s yang Anda tentukan. Untuk penskalaan otomatis, Anda menyediakan throughput maksimum, dan Cosmos DB langsung menaikkan atau menurunkan skala tergantung pada beban, dengan minimum 10% dari throughput penskalaan otomatis maksimum. Throughput standar dikenakan biaya untuk throughput yang disediakan setiap jam. Throughput penskalaan otomatis dikenakan biaya untuk throughput maksimum yang dikonsumsi setiap jam.

  • Penyimpanan yang dikonsumsi. Anda akan dikenakan biaya tarif tetap untuk jumlah total penyimpanan (GB) yang digunakan untuk data dan indeks untuk jam tertentu.

Untuk informasi selengkapnya, lihat bagian biaya di Microsoft Azure Well-Architected Framework.

Keunggulan operasional

Keunggulan operasional mencakup proses operasi yang menyebarkan aplikasi dan menjaganya tetap berjalan dalam produksi. Untuk informasi selengkapnya, lihat Gambaran umum pilar keunggulan operasional.

Arsitektur ini mengikuti rekomendasi penerapan multi wilayah, yang dijelaskan di bagian DevOps dari Azure Well Architected Framework.

Arsitektur ini dibangun berdasarkan yang ditunjukkan dalam aplikasi web yang dapat diskalakan, lihat bagian pertimbangan DevOps.

Langkah berikutnya