Mendesain arsitektur aplikasi yang terdistribusi secara geografis
Ketika komponen jaringan kami merutekan permintaan ke beberapa wilayah untuk mengurangi efek pemadaman regional, kami harus mendesain layanan aplikasi yang dapat merespons permintaan di wilayah utama dan siaga.
Ingat dari sebelumnya bahwa kami berencana untuk mengonfigurasi Azure Front Door dengan penetapan back-end prioritas. Kami menetapkan wilayah AS Timur sebagai wilayah utama kami, dan wilayah US Barat sebagai wilayah siaga kami. Ketika kegagalan regional terjadi, permintaan merutekan ke App Service di wilayah yang tidak jatuh. Kami harus mengonfigurasi sumber daya di setiap wilayah untuk mendukung failover ini untuk akses pengguna, penyimpanan yang direplikasi, dan kode aplikasi.
Di sini, kami memeriksa layanan aplikasi dalam solusi kami dan menentukan apakah mereka perlu dimodifikasi untuk berfungsi dalam arsitektur multi-wilayah. Secara khusus, kita melihat Active Directory, penyimpanan konten statis, aplikasi web, API web, antrean, fungsi Azure, dan cache data.
Microsoft Entra ID
Di portal pelacakan pengiriman kami, pengguna dapat melacak pengiriman pembelian mereka dengan memasukkan nomor pelacakan. Namun, pengguna reguler dapat mendaftar keanggotaan untuk mengakses fitur lanjutan, seperti ketepatan waktu pengiriman dan statistik lainnya. Kami telah mengembangkan portal pelacakan untuk menyimpan akun pengguna di ID Microsoft Entra.
ID Microsoft Entra dirancang sebagai sistem global secara default. Dengan demikian, Azure AD tidak rentan terhadap kegagalan regional, dan kami tidak perlu memodifikasi komponen sistem ini.
Azure Blob Storage
Konten statis, seperti gambar dan video, disimpan di akun Azure Storage sebagai Objek Besar Biner (Blob) dan disajikan ke pengguna melalui Azure CDN.
Dalam desain asli kami, akun penyimpanan terkandung dalam satu wilayah karena kami memilih untuk menggunakan Locally Redundant Storage (LRS). Data kami hanya direplikasi dalam satu pusat data dengan LRS. Akun penyimpanan, oleh karena itu, tidak tersedia jika ada pemadaman regional dalam konfigurasi ini. Konten statis apa pun yang sudah di-cache oleh CDN tetap tersedia untuk pengguna.
Hal yang sama berlaku untuk Zone Redundant Storage (ZRS). Meskipun data direplikasi ke pusat data yang berbeda dalam konfigurasi ini, semua pusat data ini masih berada di wilayah yang sama. Pemadaman regional juga memengaruhi akun penyimpanan dalam konfigurasi ini.
Dalam desain kami, kami sangat bergantung pada konfigurasi CDN untuk menyimpan konten statis. Ada kemungkinan bahwa, selama pemadaman, pengguna dapat meminta file statis yang belum ada di cache SDN. Permintaan ini akan menghasilkan grafik atau video yang tidak dapat ditampilkan.
Kami dapat menghilangkan kemungkinan ini dengan mereplikasi akun penyimpanan ke beberapa wilayah ketika kami memilih opsi penyimpanan redundan geo. Opsi replikasi baca-saja juga tersedia untuk mencegah penambahan konten statis selama ketidaktersediaan regional.
Kami memiliki dua opsi untuk dipilih ketika kami perlu mengaktifkan redundansi-geo. Opsi ini adalah Read-Access Geo-Redundant Storage (RA-GRS) dan Read-Access Geo-Zone-Redundant Storage (RA-GZRS). Pilihan yang kita buat tergantung pada anggaran kita dan persentase waktu aktif yang kita butuhkan.
Azure App Service dan Aplikasi Fungsi Azure
Portal pelacakan pengiriman kami menerapkan dua Azure App Services. App Service pertama menghosting aplikasi web yang mengimplementasikan antarmuka web yang menghadap pengguna, dan yang kedua menghosting API web yang digunakan oleh aplikasi seluler untuk melacak data pengiriman. Semua tugas latar belakang kami berjalan sebagai aplikasi Fungsi Azure.
Dalam desain asli kami, setiap Azure App Service dialirkan ke satu wilayah Azure. Kami membuat App Service kedua di wilayah sekunder (US Barat) dan menyebarkan proyek web di sana untuk mendukung arsitektur multi-wilayah baru. Kami mengonfigurasi mode perutean prioritas Azure Front Door untuk mengirim permintaan ke wilayah sekunder kami saat wilayah utama tidak tersedia.
Untuk memastikan failover semulus mungkin, pastikan aplikasi web tidak menyimpan informasi status sesi apa pun di memori. Kami mengubah situs web kami untuk memastikan kami tidak berakhir dengan kehilangan data. Misalnya, jika kode kami menyimpan daftar pengiriman pengguna dalam memori, daftar ini akan hilang jika terjadi kegagalan.
Setiap permintaan web ditangani tanpa memengaruhi yang lain ketika tidak ada status sesi yang disimpan. Jika failover terjadi di tengah sesi pengguna, failover harus transparan kepada pengguna.
Kami membuat perubahan serupa dengan aplikasi Azure Function kami. Kami membuat instans terpisah Azure Function di wilayah sekunder dan menyebarkan kode kustom yang sama dengan yang dijalankan di wilayah utama.
Penting
Saat Anda menerapkan pembaruan ke kode kustom di Layanan Aplikasi atau layanan Aplikasi Fungsi, ingatlah untuk mendistribusikannya ke semua contoh Layanan Aplikasi. Jika Anda ingin mengotomatiskan proses ini, Azure DevOps memiliki alat yang dapat membantu.
Azure Storage Queues
Dalam arsitektur satu wilayah asli kami, kami menggunakan antrean di akun Penyimpanan Azure untuk mengelola komunikasi antara Layanan Aplikasi dan aplikasi fungsi. Ketika web app atau web API perlu menjalankan tugas latar belakang, itu menempatkan pesan dengan semua informasi yang diperlukan dalam antrian. Aplikasi fungsi memantau antrean untuk pesan baru dan menjalankan tugas latar belakang dengan menjalankan kueri yang diperlukan terhadap penyimpanan data.
Kami dapat mengelola permintaan web yang tinggi dengan cara yang teratur ketika kami menggunakan antrian dengan cara ini. Ketika ada banyak tugas latar belakang untuk dijalankan, antrean dapat dibangun, tetapi tugas tidak dihilangkan. Mereka tetap dalam antrean sampai diproses. Ketika ada banyak tugas latar belakang yang harus dijalankan, antrean dapat membangun, tetapi tugas tidak akan dijatuhkan dan tetap dalam antrean sampai diproses. Jika permintaan berlanjut, kami meningkatkan jumlah instans aplikasi fungsi.
Untuk versi multi-wilayah dari portal pelacakan pengiriman, kita harus memastikan bahwa item antrean tidak hilang ketika kegagalan terjadi. Antrean kami didefinisikan dalam Penyimpanan Azure, dan kami dapat menggunakan opsi redundansi untuk replikasi geografis.
Perlu diingat bahwa kami tidak dapat menggunakan opsi redundansi akses baca karena antrean kami mendukung operasi baca dan tulis. Layanan Aplikasi harus menambahkan item ke antrean, dan aplikasi fungsi harus menghapus item yang selesai dari antrean. Gunakan Geo-Redundant (GRS) atau Geo-Zone-Redundant Storage (GZRS) sebagai gantinya.
Cache Redis Azure
Kami menggunakan Azure Redis Chace untuk memaksimalkan kinerja penyimpanan data. Mengulangi semua hasil kueri yang dihasilkan dari aplikasi kami saat mereka meminta data dari database kami. Kueri lebih lanjut untuk data serupa tidak memerlukan kueri database, dan diambil dari cache Redis.
Untuk arsitektur multi-wilayah, kami membuat instans Redis Cache di wilayah primer dan siaga. Perlu diingat bahwa ketika kegagalan terjadi, Redis Cache di wilayah siaga cenderung kosong. Cache kosong tersebut tidak menyebabkan kesalahan apa pun, tetapi performa dapat menurun untuk sementara, karena data mengisi cache baru.