Pola Geode

Pola Geode melibatkan penyebaran koleksi layanan backend ke dalam satu set nodegeografi, yang masing-masing dapat melayani permintaan apa pun untuk klien mana pun di wilayah mana pun. Pola ini memungkinkan melayani permintaan dalam gaya aktif-aktif, meningkatkan latensi dan meningkatkan ketersediaan dengan mendistribusikan pemrosesan permintaan di seluruh dunia.

Konteks dan masalah

Banyak layanan berskala besar memiliki tantangan khusus seputar ketersediaan dan skala geografis. Desain klasik sering membawa data ke komputasi dengan menyimpan data di server SQL jarak jauh yang berfungsi sebagai tingkat komputasi untuk data itu, mengandalkan peningkatan skala untuk pertumbuhan.

Pendekatan klasik dapat menghadirkan sejumlah tantangan:

• Masalah latensi jaringan bagi pengguna yang berasal dari sisi lain dunia untuk terhubung ke titik akhir hosting
• Manajemen lalu lintas untuk ledakan permintaan yang dapat membanjiri layanan di satu wilayah
• Kompleksitas menyebarkan salinan infrastruktur aplikasi ke beberapa wilayah untuk layanan 24x7 dengan biaya yang terlalu tinggi

Infrastruktur cloud modern telah berevolusi untuk memungkinkan penyeimbangan beban geografis dari layanan frontend, sementara memungkinkan replikasi geografis layanan backend. Untuk ketersediaan dan performa, mendapatkan data lebih dekat dengan pengguna itu baik. Saat data didistribusikan secara geografis di seluruh basis pengguna yang jauh, penyimpanan data yang didistribusikan secara geografis juga harus dikosongkan dengan sumber daya komputasi yang memproses data. Pola geode membawa komputasi ke data.

Solusi

Menyebarkan layanan ke sejumlah penyebaran satelit yang tersebar di seluruh dunia, yang masing-masing disebut geode. Pola geode memanfaatkan fitur utama Azure untuk merutekan lalu lintas melalui jalur terpendek ke geode terdekat, yang meningkatkan latensi dan performa. Setiap geode berada di belakang penyeimbang beban global, dan menggunakan layanan baca-tulis yang direplikasi secara geografis seperti Azure Cosmos DB untuk menghosting bidang data, memastikan konsistensi data lintas geode. Layanan replikasi data memastikan bahwa penyimpanan data identik di seluruh geode, sehingga semua permintaan dapat dilayani dari semua geode.

Perbedaan utama antara stempel penyebaran dan geode adalah bahwa geode tidak pernah ada secara terpisah. Harus selalu ada lebih dari satu geode dalam platform produksi.

Geode memiliki karakteristik sebagai berikut:

• Terdiri dari kumpulan jenis sumber daya yang berbeda, sering didefinisikan dalam templat.
• Tidak memiliki ketergantungan di luar jejak geode dan mandiri. Tidak ada geode yang bergantung pada geode yang lain untuk beroperasi, dan jika satu nonaktif, geode lain terus beroperasi.
• Secara longgar digabungkan melalui jaringan tepi dan backplane replikasi. Misalnya, Anda dapat menggunakan Azure Traffic Manager atau Azure Front Door untuk menampilkan geode di depan, sementara Azure Cosmos DB dapat bertindak sebagai backplane replikasi. Geode tidak sama dengan kluster karena berbagi backplane replikasi, sehingga platform menangani masalah kuorum.

Pola geode terjadi dalam arsitektur big data yang menggunakan perangkat keras komoditas untuk memproses data ditempatkan pada mesin yang sama, dan MapReduce untuk mengonsolidasikan hasil di seluruh mesin. Penggunaan lain adalah komputasi dekat tepi, yang membawa komputasi lebih dekat ke tepi cerdas jaringan untuk mengurangi waktu respons.

Layanan dapat menggunakan pola ini lebih dari puluhan atau ratusan geode. Selain itu, ketahanan seluruh solusi meningkat dengan setiap geode tambahan, karena setiap geode dapat mengambil alih jika pemadaman regional mengambil satu atau beberapa geode secara offline.

Dimungkinkan juga untuk meningkatkan teknik ketersediaan lokal, seperti zona ketersediaan atau wilayah yang dipasangkan, dengan pola geode untuk ketersediaan global. Ini meningkatkan kompleksitas, tetapi berguna jika arsitektur Anda didukung oleh mesin penyimpanan seperti penyimpanan blob yang hanya dapat mereplikasi ke wilayah yang dipasangkan. Anda dapat menyebarkan geode ke dalam jejak intra-zona, zonal, atau regional, dengan pikiran untuk kendala peraturan atau latensi di lokasi.

Masalah dan pertimbangan

Gunakan teknik dan teknologi berikut untuk menerapkan pola ini:

• Praktik dan alat DevOps modern untuk memproduksi dan menyebarkan geode yang identik di sejumlah besar wilayah atau instans dengan cepat.
• Penskalaan otomatis untuk meluaskan skala instans throughput komputasi dan database dalam geode. Setiap geode secara individual diluaskan skalanya, dalam kendala backplane umum.
• Layanan frontend seperti Azure Front Door yang melakukan akselerasi konten dinamis, TCP terpisah, dan perutean Anycast.
• Penyimpanan data replika seperti Azure Cosmos DB untuk mengontrol konsistensi data.
• Teknologi tanpa server jika memungkinkan, untuk mengurangi biaya penyebaran yang selalu aktif, terutama ketika beban sering diseimbangkan kembali di seluruh dunia. Strategi ini memungkinkan banyak geode disebarkan dengan investasi tambahan minimal. Teknologi penagihan tanpa server dan berbasis penggunaan mengurangi limbah dan biaya dari penyebaran geo-distribusi duplikat.
• API Management tidak diperlukan untuk menerapkan pola desain, tetapi dapat ditambahkan ke setiap geode yang menampilkan ke Azure Function App di wilayah ini di depan untuk menyediakan lapisan API yang lebih kuat, memungkinkan penerapan fungsionalitas tambahan seperti pembatasan tarif, misalnya.

Pertimbangkan poin-poin berikut saat memutuskan cara menerapkan pola ini:

• Pilih apakah akan memproses data secara lokal di setiap wilayah, atau untuk mendistribusikan agregasi dalam satu geode dan mereplikasi hasilnya di seluruh dunia. Prosesor umpan perubahan Azure Cosmos DB menawarkan kontrol granular ini menggunakan konsep kontainer sewanya, dan leasecollectionprefix dalam pengikatan Azure Functions yang sesuai. Setiap pendekatan memiliki kelebihan dan kekurangan yang berbeda.
• Geode dapat bekerja bersama-sama, menggunakan umpan balik perubahan Azure Cosmos DB dan platform komunikasi real time seperti SignalR. Geode dapat berkomunikasi dengan pengguna jarak jauh melalui geode lain dalam pola jala, tanpa mengetahui atau peduli di mana pengguna jarak jauh berada.
• Pola desain ini secara implisit memisahkan semuanya, menghasilkan arsitektur yang sangat terdistribusi dan dipisahkan. Pertimbangkan cara melacak komponen yang berbeda dari permintaan yang sama karena dapat mengeksekusi secara asinkron pada instans yang berbeda. Strategi pemantauan yang tepat sangat penting. Azure Front Door dan Azure Cosmos DB dapat dengan mudah diintegrasikan dengan Log Analytics dan Azure Functions harus disebarkan bersama Application Insights untuk menyediakan sistem pemantauan yang kuat di setiap komponen dalam arsitektur.
• Penyebaran terdistribusi memiliki lebih banyak rahasia dan titik ingress yang memerlukan langkah-langkah keamanan properti. Key Vault menyediakan lapisan aman untuk manajemen rahasia dan setiap lapisan dalam arsitektur API harus diamankan dengan benar sehingga satu-satunya titik ingress untuk API adalah layanan frontend seperti Azure Front Door. Azure Cosmos DB harus membatasi lalu lintas ke Azure Function Apps, dan aplikasi Fungsi ke Azure Front Door menggunakan ID Microsoft Entra atau praktik seperti pembatasan IP.
• Performa secara drastis dipengaruhi oleh jumlah geode yang digunakan dan App Service Plans tertentu yang diterapkan pada teknologi API di setiap geode. Penyebaran geode tambahan atau perpindahan ke tingkat premium datang dengan peningkatan biaya untuk memori dan komputasi tambahan, tetapi jangan melakukannya berdasarkan per transaksi. Pertimbangkan pengujian beban arsitektur API setelah digunakan dan kontras meningkatkan jumlah geode dengan meningkatkan tingkat harga sehingga model yang paling hemat biaya digunakan untuk kebutuhan Anda.
• Tentukan persyaratan ketersediaan untuk data Anda. Azure Cosmos DB memiliki bendera opsional untuk mengaktifkan penulisan multi-wilayah, zona ketersediaan, dan banyak lagi. Ini meningkatkan ketersediaan untuk instans Azure Cosmos DB dan membuat lapisan data yang lebih tangguh, tetapi dilengkapi dengan biaya tambahan.
• Azure menawarkan berbagai penyeimbang beban yang menyediakan fungsi berbeda untuk distribusi lalu lintas. Gunakan pohon keputusan untuk membantu memilih opsi yang tepat untuk frontend API Anda.

Kapan menggunakan pola ini

Gunakan pola ini:

• Untuk menerapkan platform skala tinggi yang telah didistribusikan pengguna di area yang luas.
• Untuk setiap layanan yang membutuhkan ketersediaan dan karakteristik ketahanan ekstrim, karena layanan berdasarkan pola geode dapat bertahan dari hilangnya beberapa wilayah layanan pada saat yang sama.

Pola ini mungkin tidak cocok untuk

• Arsitektur yang memiliki batasan sehingga semua geode tidak bisa sama untuk penyimpanan data. Misalnya, mungkin ada persyaratan residensi data, aplikasi yang perlu mempertahankan keadaan sementara untuk sesi tertentu, atau pembobotan permintaan yang berat terhadap satu wilayah. Dalam hal ini, pertimbangkan untuk menggunakan stempel penyebaran dalam kombinasi dengan bidang perutean global yang mengetahui lokasi data pengguna berada, seperti komponen perutean lalu lintas yang dijelaskan dalam pola stempel penyebaran.
• Situasi saat tidak ada distribusi geografis yang diperlukan. Sebagai gantinya, pertimbangkan zona ketersediaan dan wilayah berpasangan untuk pengklusteran.
• Situasi saat platform warisan perlu dipasang. Pola ini hanya berfungsi untuk pengembangan cloud native, dan bisa sulit untuk dipasang.
• Arsitektur dan persyaratan sederhana, saat geo-redundansi dan geo-distribusi tidak diperlukan atau menguntungkan.

Desain beban kerja

Arsitek harus mengevaluasi bagaimana pola Geode dapat digunakan dalam desain beban kerja mereka untuk mengatasi tujuan dan prinsip yang tercakup dalam pilar Azure Well-Architected Framework. Contohnya:

Seperti halnya keputusan desain apa pun, pertimbangkan tradeoff terhadap tujuan pilar lain yang mungkin diperkenalkan dengan pola ini.

Contoh

• Windows Active Directory menerapkan varian awal dari pola ini. Replikasi multiprimer berarti semua pembaruan dan permintaan secara teori dapat dilayani dari semua node yang dapat disajikan, tetapi peran Flexible Single Master Operation (FSMO) berarti bahwa semua geode tidak sama.
• Akselerator pola geode pada GitHub menampilkan pola desain ini dalam praktiknya dan dirancang untuk membantu pengembang menerapkannya dengan API dunia nyata.