Desain arsitektur yang tersebar secara geografis
Azure adalah sistem global. Dengan mendesain arsitektur yang hadir di lebih dari satu wilayah Azure, kami dapat membangun aplikasi yang tahan terhadap bencana bahkan di seluruh wilayah.
Portal penelusuran pengiriman Anda dapat diskalakan karena dibuat menggunakan berbagai sumber daya Azure yang dapat diskalakan. Ini juga tahan terhadap banyak kegagalan karena komponennya dapat memiliki beberapa instans. Namun, dewan direksi Anda menjadi khawatir bahwa bencana skala besar dapat menyebabkan gangguan karena portal sepenuhnya terdapat di wilayah Azure AS Timur. Anda ingin mengusulkan arsitektur yang dimodifikasi yang dapat gagal ke wilayah kedua jika AS Timur gagal.
Di sini, kami mempelajari cara menyesuaikan arsitektur aplikasi kami untuk mendukung aplikasi yang didistribusikan secara geografis. Kami juga melihat mengapa arsitektur tersebut menguntungkan untuk aplikasi yang penting bagi bisnis.
Arsitektur aplikasi web asli
Mari kita lihat bagaimana desain arsitektur portal penelusuran, dan komponen yang digunakan dalam solusi. Setelah kami memahami bagaimana menggunakan semua bagian, kami dapat menyelidiki cara mendukung masing-masing komponen ini dalam skenario geo-redundansi.
Desain portal penelusuran didasarkan pada arsitektur referensi yang diperlihatkan dalam diagram berikut.
Perhatikan bagaimana aplikasi kami menggunakan satu grup sumber daya Azure. Grup sumber daya ini memungkinkan kami untuk mengelompokkan dan mengelola semua sumber daya kami secara logis, dan menyederhanakan manajemen. Kami memilih untuk menyebarkan kelompok sumber daya ini ke wilayah AS Timur. Meskipun grup sumber daya tidak membatasi kami untuk menggunakan wilayah Azure yang sama untuk sumber daya yang disertakan, kami telah memutuskan untuk menggunakan wilayah AS Timur untuk semua sumber daya yang diterapkan dalam aplikasi kami.
Aplikasi kami menggunakan tiga kategori sumber daya Azure. Mari kita lihat setiap kategori, dan lihat sumber daya mana yang digunakan.
Komponen jaringan
Portal penelusuran menggunakan layanan jaringan berikut.
| Layanan | Deskripsi |
|---|---|
| DNS Azure | Kami telah mengonfigurasi Azure DNS untuk menghosting rekaman DNS kami di Azure. Azure DNS memungkinkan kami mengelola rekaman DNS kami menggunakan kredensial Azure kami di portal Azure. |
| Application Gateway | Kami telah mengonfigurasi penyeimbang muatan Application Gateway untuk menyeimbangkan lalu lintas antara beberapa instance ujung depan web. Layanan ini dilokalkan ke satu wilayah Azure. |
| Azure CDN | Kami telah mengonfigurasi Azure CDN untuk memaksimalkan pengiriman konten statis yang tidak aman, seperti grafik untuk konten situs web kami. Layanan global ini menyimpan konten statis di titik-titik keberadaan di seluruh dunia. |
Komponen aplikasi
Portal penelusuran menggunakan layanan berikut untuk mendukung kode, cache, dan persyaratan penyimpanan menengah.
| Layanan | Deskripsi |
|---|---|
| Microsoft Entra ID | Pengguna mengakses portal pelacakan menggunakan akun Microsoft Entra. Direktori dan akun secara otomatis direplikasi secara global. |
| Azure App Service | Portal pelacakan menggunakan dua Azure App Services. Yang pertama menjalankan set halaman web dinamis, dan yang kedua API web. |
| Aplikasi Azure Function | Portal penelusuran menggunakan Aplikasi Azure Function untuk menjalankan semua tugas latar belakang. Beberapa tugas ini berjalan pada jadwal reguler, dan tugas lain beroperasi pada pesan dalam antrean. |
| Azure Storage Queues | Portal pelacakan menggunakan Antrean Azure Storage dengan Azure Function Apps. Portal penelusuran menempatkan pesan yang dihasilkan ke antrean dari tempat aplikasi Fungsi memproses pesan-pesan ini. |
| Redis cache | Portal penelusuran menggunakan cache Redis antara layanan aplikasi front-end dan sistem penyimpanan data untuk memaksimalkan performa kueri. |
| Penyimpanan Blob Azure | Konten statis, seperti grafik dan file video, disimpan sebagai Objek Besar Biner (Blobs) di akun Azure Storage, dan dikirimkan melalui CDN Azure. |
| Azure Search | Kami telah mengaktifkan Azure Search di portal penelusuran. Azure Search memungkinkan kami untuk membuat semua konten dapat dicari, dan memberikan saran pencarian dan hasil pencarian kabur pada pengguna kami. |
Komponen penyimpanan data
Portal penelusuran menggunakan layanan penyimpanan yang dipertahankan berikut.
| Layanan | Deskripsi |
|---|---|
| Azure SQL Database | Kami menyimpan data relasional, seperti detail pesanan dan pelanggan di Azure SQL Database. |
| Cosmos DB | Kami menyimpan data semi-terstruktur, termasuk katalog produk kami di Cosmos DB. |
Masalah dengan arsitektur asli
Arsitektur yang ada untuk portal pelacakan didesain untuk memungkinkan skalabilitas dan ketersediaan.
Misalnya, jika permintaan tinggi, dan respons terhadap permintaan web pengguna lambat, Anda dapat mempertimbangkan untuk menambahkan lebih banyak instans aplikasi web front-end di App Service. Di sini, Application Gateway dapat merutekan permintaan ke instans yang baru dibuat.
Namun, ada skenario di mana desain arsitektur kita memiliki tantangan untuk diatasi, atau bahkan gagal. Mari kita lihat setiap skenario untuk mendapatkan pemahaman yang lebih baik tentang dampak pada portal penelusuran.
Kegagalan regional
Beberapa peristiwa penting berpotensi mengganggu seluruh wilayah Azure. Pusat data Azure didesain agar sangat tangguh, tetapi peristiwa cuaca besar, seperti badai atau banjir, dapat mengganggu layanan dari wilayah tersebut.
Peristiwa ini adalah kejadian yang tidak biasa, dan banyak perusahaan merasa mereka dapat mempertahankan risiko itu. Namun, konsekuensi dari kegagalan regional menonaktifkan portal penelusuran adalah risiko tinggi tim eksekutif perusahaan telah memutuskan untuk menghilangkan risiko.
Perjanjian Tingkat Layanan
Sebagian besar layanan Azure menawarkan Perjanjian Tingkat Layanan (SLA) atau jaminan waktu aktif. Ketika kami mendesain arsitektur aplikasi yang terdiri dari beberapa layanan Azure, kami menghitung SLA keseluruhan untuk aplikasi sebagai gabungan dari semua SLA layanan lainnya.
Anda menghitung SLA ini dengan mengalikan bersama-sama SLA layanan komponen. Misalnya, asumsikan aplikasi kami terdiri dari Azure App Service (99,95% SLA), dan ID Microsoft Entra (99,9% SLA). SLA terhitung akhir adalah 99,85%.
Jika uptime persentase ini tidak cukup untuk aplikasi kami, kami dapat mengatur agar aplikasi gagal ke wilayah lain.
Komponen global, regional, dan dapat dikonfigurasi
Dalam desain kami, beberapa komponen adalah global secara default dan tidak rentan terhadap kegagalan regional.
Beberapa komponen terbatas pada satu wilayah, misalnya, Application Gateway. Kita harus memilih layanan alternatif untuk jenis komponen ini.
Beberapa komponen dapat dikonfigurasi untuk mendukung beberapa wilayah. Misalnya, kita dapat menggunakan opsi Geo-Redundant Storage (GRS) di akun Penyimpanan Azure yang menyimpan konten statis. GRS mereplikasi blobs ke wilayah lain.
Tabel berikut ini memperlihatkan komponen mana yang dapat dikonfigurasi secara global, regional, dan dapat dikonfigurasi.
| Komponen | Dukungan untuk beberapa wilayah | Komentar |
|---|---|---|
| DNS Azure | Global | Tidak ada perubahan yang diperlukan. |
| Application Gateway | Wilayah | Setiap instans Application Gateway terletak di satu wilayah. |
| Azure CDN | Global | Tidak ada perubahan yang diperlukan, konten di-cache secara global secara default. |
| Microsoft Entra ID | Global | Tidak ada perubahan yang diperlukan. |
| Azure App Service | Wilayah | Setiap instans aplikasi terletak di satu wilayah. |
| Azure Function Apps | Wilayah | Setiap instans aplikasi fungsi terletak di satu wilayah. |
| Azure Storage Queues | Dapat dikonfigurasi | Anda dapat memilih untuk mereplikasi akun Azure Storage ke beberapa wilayah. |
| Cache Redis Azure | Wilayah | Setiap instans cache terletak di satu wilayah. |
| Azure Blob Storage | Dapat dikonfigurasi | Anda dapat memilih untuk mereplikasi akun Azure Storage ke beberapa wilayah. |
| Pencarian Azure | Wilayah | Setiap instans layanan pencarian terletak di satu wilayah. |
| Database Azure SQL | Dapat dikonfigurasi | Anda dapat menggunakan replikasi geografis untuk sinkronkan data ke beberapa wilayah. |
| Azure Cosmos DB | Dapat dikonfigurasi | Anda dapat menggunakan replikasi geografis untuk sinkronkan data ke beberapa wilayah. |
Arsitektur terdistribusi yang diusulkan
Setelah beberapa penyelidikan, Anda mengusulkan arsitektur seperti yang ditunjukkan dalam diagram berikut.
Dalam desain ini, ada wilayah aktif (AS Timur) dan wilayah siaga (AS Barat). Wilayah AS Timur menangani semua permintaan oleh komponen dalam keadaan biasa. Jika bencana menyebabkan kegagalan regional, aplikasi gagal ke wilayah AS Barat.
Mari kita periksa, pada tingkat tinggi, bagaimana Anda telah memodifikasi arsitektur asli. Kami menjelajahi perubahan ini secara lebih rinci di unit selanjutnya.
Jaringan
Azure DNS dan Azure CDN secara default merupakan sistem global dan sudah tahan terhadap kegagalan regional. Kami meninggalkan mereka di tempat.
Saat kami membuat Azure Application Gateway, kami menetapkan layanan ke satu wilayah. Kami menghapus kerentanan ini dengan mengganti layanan ini dengan Azure Front Door. Front Door dapat melakukan polling beberapa App Services, dan menangani failover App Service dari wilayah US Timur ke wilayah US Barat.
Layanan Aplikasi
MICROSOFT Entra ID adalah sistem global, dan tidak memerlukan modifikasi.
Akun Azure Storage dapat dikonfigurasi untuk mereplikasi konten ke beberapa wilayah. Kami menggunakan salah satu opsi penyimpanan geo-redundan untuk mengubah konfigurasi kami.
Komponen lain, yang mencakup App Service, Function Apps, cache Redis, dan Pencarian Azure, bersifat regional. Kami membuat instans duplikat komponen-komponen ini di wilayah US Barat dalam desain arsitektur baru kami. Dalam desain ini, wilayah baru dapat mengambil alih saat terjadi failover.
Penyimpanan data
Azure SQL Database dan Azure Cosmos DB keduanya mendukung replikasi geo data ke wilayah lainnya. Kami mengonfigurasi layanan ini untuk mereplikasi data AS Timur ke layanan yang setara di US Barat.
Pasangan regional
Wilayah Azure adalah area dengan satu geografi yang berisi satu atau beberapa pusat data Azure. Semua wilayah berpasangan dengan wilayah lainnya dalam geografi yang sama. Dalam pasangan ini, pembaruan dan pemeliharaan terencana dilakukan hanya pada satu wilayah pada satu waktu. Jika ada kegagalan yang memengaruhi beberapa wilayah, setidaknya satu wilayah di setiap pasangan diprioritaskan untuk pemulihan cepat.
Praktik terbaik adalah menempatkan arsitektur dua wilayah untuk aplikasi Anda di dua wilayah dalam pasangan regional. Sebagai contoh, AS Timur berpasangan dengan AS Barat. Desain yang kami usulkan menggunakan AS Timur untuk wilayah aktifnya, dan AS Barat untuk wilayah siaganya.