Pola Stempel Penyebaran

Pola stempel penyebaran melibatkan provisi, pengelolaan, dan pemantauan grup sumber daya yang heterogen untuk menampung dan mengoperasikan banyak beban kerja atau penyewa. Setiap salinan individu disebut stempel, atau terkadang unit layanan, unit skala, atau sel. Di lingkungan multipenyewa, setiap stempel atau unit skala dapat melayani jumlah penyewa yang telah ditentukan sebelumnya. Beberapa stempel dapat disebarkan untuk menskalakan solusi hampir secara linier dan melayani makin banyak penyewa. Pendekatan ini dapat meningkatkan skalabilitas solusi Anda, memungkinkan Anda menyebarkan instans di beberapa wilayah, dan memisahkan data pelanggan Anda.

Konteks dan masalah

Saat menghosting aplikasi di cloud, penting untuk mempertimbangkan performa dan keandalan aplikasi Anda. Jika Anda menghosting satu instans dari solusi Anda, Anda mungkin tunduk pada batasan berikut:

• Batas skala. Menyebarkan satu instans aplikasi Anda dapat menghasilkan batas penyekalaan alami. Misalnya, Anda mungkin menggunakan layanan yang memiliki batasan jumlah koneksi masuk, nama host, soket TCP, atau sumber daya lainnya.
• Penyekalaan atau biaya non-linier. Beberapa komponen solusi Anda mungkin tidak menskalakan secara linier dengan jumlah permintaan atau jumlah data. Sebaliknya, dapat terjadi penurunan performa secara tiba-tiba atau peningkatan biaya setelah ambang batas terpenuhi. Misalnya, Anda mungkin menggunakan database dan menemukan bahwa biaya marginal untuk menambahkan lebih banyak kapasitas (peningkatan skala) menjadi penghalang, dan bahwa penyekalaan adalah strategi yang lebih hemat biaya.
• Pemisahan pelanggan. Anda mungkin perlu menjaga agar data pelanggan tertentu tetap terisolasi dari data pelanggan lain. Demikian pula, Anda mungkin memiliki beberapa pelanggan yang memerlukan lebih banyak sumber daya sistem untuk dilayani daripada yang lain, dan pertimbangkan untuk mengelompokkannya pada kumpulan infrastruktur yang berbeda.
• Menangani instans tunggal dan multipenyewa. Anda mungkin memiliki beberapa pelanggan besar yang membutuhkan instans independennya sendiri dari solusi Anda. Anda mungkin juga memiliki kumpulan pelanggan yang lebih kecil yang dapat berbagi penyebaran multipenyewa.
• Persyaratan penyebaran yang kompleks. Anda mungkin perlu menyebarkan pembaruan ke layanan Anda dengan cara yang terkontrol, dan menyebarkannya ke sub kumpulan basis pelanggan yang berbeda pada waktu yang berbeda.
• Frekuensi pembaruan. Anda mungkin memiliki beberapa pelanggan yang toleran untuk sering memperbarui sistem Anda, sementara yang lain mungkin menghindari risiko dan menginginkan pembaruan yang jarang pada sistem yang melayani permintaan mereka. Mungkin masuk akal jika pelanggan ini disebarkan ke lingkungan yang terisolasi.
• Pembatasan geografis atau geopolitik. Untuk mendesain latensi rendah, atau untuk mematuhi persyaratan kedaulatan data, Anda dapat menyebarkan beberapa pelanggan Anda ke wilayah tertentu.

Keterbatasan ini sering berlaku untuk vendor perangkat lunak independen (ISV) yang membangun perangkat lunak sebagai layanan (SaaS), yang sering dirancang untuk menjadi multipenyewa. Namun, batasan yang sama juga dapat berlaku untuk skenario lain.

Solusi

Untuk menghindari masalah ini, pertimbangkan untuk mengelompokkan sumber daya dalam unit skala dan memprovisikan beberapa salinan stempel Anda. Setiap unit skala akan menghosting dan melayani subset penyewa Anda. Stempel beroperasi secara independen satu sama lain dan dapat disebarkan dan diperbarui secara independen. Satu wilayah geografis mungkin berisi satu stempel, atau mungkin berisi beberapa stempel untuk memungkinkan peluasan skala horizontal di dalam wilayah tersebut. Stempel berisi subset pelanggan Anda.

Stempel penyebaran dapat menerapkan apakah solusi Anda menggunakan komponen infrastruktur sebagai layanan (IaaS) atau platform as a service (PaaS), atau campuran keduanya. Biasanya beban kerja IaaS memerlukan lebih banyak intervensi untuk penyekalaan, sehingga polanya mungkin berguna untuk beban kerja IaaS yang berat untuk memungkinkan peluasan skala.

Stempel dapat digunakan untuk menyebarkan cincin penyebaran. Jika pelanggan yang berbeda ingin menerima pembaruan layanan pada frekuensi yang berbeda, mereka dapat dikelompokkan ke dalam stempel yang berbeda, dan setiap stempel dapat memiliki pembaruan yang disebarkan pada irama yang berbeda.

Karena stempel berjalan secara independen satu sama lain, data secara implisit dipecah. Selain itu, satu stempel dapat menggunakan sharding lebih lanjut untuk memungkinkan skalabilitas dan elastisitas secara internal di dalam stempel.

Pola stempel penyebaran digunakan secara internal oleh banyak layanan Azure, termasuk App Service, Azure Stack, dan Azure Storage.

Stempel penyebaran terkait dengan, tetapi berbeda dari, geode. Dalam arsitektur stempel penyebaran, beberapa instans independen dari sistem Anda disebarkan dan berisi subset pelanggan dan pengguna Anda. Dalam geode, semua instans dapat melayani permintaan dari pengguna mana pun, tetapi arsitektur ini sering kali lebih kompleks untuk didesain dan dibangun. Anda mungkin juga mempertimbangkan untuk mencampur dua pola dalam satu solusi; pendekatan perutean lalu lintas yang dijelaskan nanti dalam artikel ini adalah contoh skenario hibrid tersebut.

Penyebaran

Karena kompleksitas yang terlibat dalam menyebarkan salinan identik dari komponen yang sama, praktik DevOps yang baik sangat penting untuk memastikan keberhasilan saat menerapkan pola ini. Pertimbangkan untuk mendeskripsikan infrastruktur Anda sebagai kode, seperti dengan menggunakan Bicep, templat Azure Resource Manager (templat ARM) JSON, Terraform, dan skrip. Dengan pendekatan ini, Anda dapat memastikan bahwa penyebaran setiap stempel dapat diprediksi dan diulang. Ini juga mengurangi kemungkinan kesalahan manusia seperti ketidakcocokan yang tidak disengaja dalam konfigurasi antar stempel.

Anda dapat menyebarkan pembaruan secara otomatis ke semua stempel secara paralel, dalam hal ini Anda dapat mempertimbangkan teknologi seperti Bicep atau templat Resource Manager untuk mengoordinasikan penyebaran infrastruktur dan aplikasi Anda. Atau, Anda mungkin memutuskan untuk meluncurkan pembaruan secara bertahap ke beberapa stempel terlebih dahulu, lalu secara bertahap ke yang lain. Pertimbangkan untuk menggunakan alat manajemen rilis seperti Azure Pipelines atau GitHub Actions untuk mengatur penyebaran ke setiap stempel. Untuk informasi selengkapnya, lihat:

• Mengintegrasikan Bicep dengan Azure Pipelines
• Mengintegrasikan templat ARM JSON dengan Azure Pipelines

Pertimbangkan dengan cermat topologi langganan Azure dan grup sumber daya untuk penyebaran Anda:

• Biasanya langganan berisi semua sumber daya untuk satu solusi, jadi secara umum pertimbangkan untuk menggunakan satu langganan untuk semua stempel. Namun, beberapa layanan Azure memberlakukan kuota seluruh langganan, jadi jika Anda menggunakan pola ini untuk memungkinkan peluasan skala yang lebih tinggi, Anda mungkin perlu mempertimbangkan untuk menyebarkan stempel di berbagai langganan.
• Grup sumber daya umumnya digunakan untuk menyebarkan komponen dengan siklus hidup yang sama. Jika Anda berencana untuk menyebarkan pembaruan ke semua stempel Anda sekaligus, pertimbangkan untuk menggunakan satu grup sumber daya untuk memuat semua komponen untuk semua stempel Anda, dan gunakan konvensi penamaan sumber daya dan tag untuk mengidentifikasi komponen yang dimiliki setiap stempel. Atau, jika Anda berencana untuk menyebarkan pembaruan ke setiap stempel secara independen, pertimbangkan untuk menyebarkan setiap stempel ke dalam grup sumber dayanya sendiri.

Perencanaan kapasitas

Gunakan pengujian beban dan performa untuk menentukan perkiraan beban yang dapat ditampung oleh stempel tertentu. Metrik beban mungkin didasarkan pada jumlah pelanggan/penyewa yang dapat diakomodasi oleh satu stempel, atau metrik dari layanan yang dipancarkan oleh komponen di dalam stempel. Pastikan Anda memiliki instrumentasi yang memadai untuk mengukur saat stempel yang diberikan mendekati kapasitasnya, dan kemampuan untuk menyebarkan stempel baru dengan cepat untuk merespons permintaan.

Perutean lalu lintas

Pola Stempel Penyebaran bekerja dengan baik jika setiap stempel ditangani secara independen. Misalnya, jika Contoso menyebarkan aplikasi API yang sama di beberapa stempel, Contoso mungkin mempertimbangkan untuk menggunakan DNS untuk merutekan lalu lintas ke stempel yang relevan:

• unit1.aus.myapi.contoso.com merutekan lalu lintas ke stempel unit1 di wilayah Australia.
• unit2.aus.myapi.contoso.com merutekan lalu lintas ke stempel unit2 di wilayah Australia.
• unit1.eu.myapi.contoso.com merutekan lalu lintas ke stempel unit1 di wilayah Eropa.

Klien kemudian bertanggung jawab untuk menyambungkan ke stempel yang benar.

Jika satu titik ingress untuk semua lalu lintas diperlukan, layanan perutean lalu lintas dapat digunakan untuk menyelesaikan stempel untuk permintaan, pelanggan, atau penyewa tertentu. Layanan perutean lalu lintas mengarahkan klien ke URL yang relevan untuk stempel (misalnya, menggunakan kode status respons HTTP 302), atau mungkin bertindak sebagai proksi terbalik dan meneruskan lalu lintas ke stempel yang relevan, tanpa klien sadar.

Layanan perutean lalu lintas terpusat dapat menjadi komponen yang kompleks untuk didesain, terutama ketika solusi berjalan di beberapa wilayah. Pertimbangkan untuk menyebarkan layanan perutean lalu lintas ke beberapa wilayah (berpotensi termasuk setiap wilayah tempat stempel disebarkan), lalu memastikan penyimpanan data (memetakan penyewa ke stempel) disinkronkan. Komponen perutean lalu lintas mungkin merupakan instans pola geode.

Misalnya, Azure API Management dapat disebarkan untuk bertindak dalam peran layanan perutean lalu lintas. Ini dapat menentukan stempel yang sesuai untuk permintaan dengan mencari data dalam koleksi Azure Cosmos DB yang menyimpan pemetaan antara penyewa dan stempel. API Management kemudian dapat mengatur URL back-end secara dinamis ke layanan API stempel yang relevan.

Untuk mengaktifkan geo-distribusi permintaan dan geo-redundansi layanan perutean lalu lintas, API Management dapat disebarkan di beberapa wilayah, atau Azure Front Door dapat digunakan untuk mengarahkan lalu lintas ke instans terdekat. Front Door dapat dikonfigurasi dengan kumpulan backend, memungkinkan permintaan diarahkan ke instans API Management terdekat yang tersedia. Jika aplikasi Anda tidak diekspos melalui HTTP/S, Anda dapat menggunakan Azure Load Balancer lintas wilayah untuk mendistribusikan panggilan masuk ke Azure Load Balancer regional. Fitur distribusi global Azure Cosmos DB dapat digunakan untuk terus memperbarui informasi pemetaan di setiap wilayah.

Jika layanan perutean lalu lintas disertakan dalam solusi Anda, pertimbangkan apakah layanan tersebut bertindak sebagai gateway dan karenanya dapat melakukan offloading gateway untuk layanan lain, seperti validasi token, pembatasan, dan otorisasi.

Contoh arsitektur perutean lalu lintas

Pertimbangkan contoh arsitektur perutean lalu lintas berikut, yang menggunakan Azure Front Door, Azure API Management, dan Azure Cosmos DB untuk perutean lalu lintas global, lalu serangkaian stempel khusus wilayah:

Misalkan pengguna biasanya tinggal di New York. Data mereka disimpan di stempel 3, di wilayah US Timur.

Jika pengguna melakukan perjalanan ke California dan kemudian mengakses sistem, koneksi mereka kemungkinan akan dirutekan melalui wilayah US Barat 2 karena yang paling dekat dengan tempat mereka secara geografis ketika mereka membuat permintaan. Namun, permintaan pada akhirnya harus dilayani oleh stempel 3, karena di situlah data mereka disimpan. Sistem perutean lalu lintas memastikan bahwa permintaan dirutekan ke stempel yang benar.

Masalah dan pertimbangan

Anda harus mempertimbangkan poin berikut saat memutuskan cara menerapkan pola ini:

• Proses penyebaran. Saat menyebarkan beberapa stempel, sangat disarankan untuk memiliki proses penyebaran otomatis dan sepenuhnya dapat diulang. Pertimbangkan untuk menggunakan bicep, templat JSON ARM, atau modul Terraform untuk menentukan stempel Anda secara deklaratif, dan untuk menjaga definisi tetap konsisten.
• Operasi lintas stempel. Saat solusi Anda disebarkan secara independen di beberapa stempel, pertanyaan seperti "berapa banyak pelanggan yang dimiliki di semua stempel?" bisa menjadi lebih kompleks untuk dijawab. Kueri mungkin perlu dijalankan terhadap setiap stempel dan hasilnya diagregasikan. Sebagai alternatif, pertimbangkan agar semua stempel menerbitkan data ke dalam gudang data terpusat untuk pelaporan terkonsolidasi.
• Menentukan kebijakan peluasan skala. Stempel memiliki kapasitas terbatas, yang dapat ditentukan menggunakan metrik proksi seperti jumlah penyewa yang dapat disebarkan untuk stempel. Penting untuk memantau kapasitas yang tersedia dan kapasitas yang digunakan untuk setiap stempel, dan secara proaktif menyebarkan stempel tambahan untuk memungkinkan penyewa baru diarahkan ke mereka.
• Jumlah stempel minimum. Saat Anda menggunakan pola Stempel Penyebaran, disarankan untuk menyebarkan setidaknya dua stempel solusi Anda. Jika Anda hanya menyebarkan satu stempel, mudah untuk secara tidak sengaja mengkodekan asumsi hard-code ke dalam kode atau konfigurasi Anda yang tidak akan berlaku saat Anda meluaskan skala.
• Biaya. Pola Stempel Penyebaran melibatkan penyebaran banyak salinan komponen infrastruktur Anda, yang kemungkinan akan melibatkan peningkatan substansial dalam biaya pengoperasian solusi Anda.
• Bergerak di antara stempel. Setiap stempel disebarkan dan dioperasikan secara independen, sehingga memindahkan penyewa antar stempel bisa sulit. Aplikasi Anda memerlukan logika kustom untuk mengirimkan informasi tentang pelanggan tertentu ke stempel yang berbeda, lalu menghapus informasi penyewa dari stempel asli. Proses ini mungkin memerlukan backplane untuk komunikasi antar stempel, yang selanjutnya meningkatkan kompleksitas solusi keseluruhan.
• Perutean lalu lintas. Seperti yang dijelaskan sebelumnya dalam artikel ini, merutekan lalu lintas ke stempel yang benar untuk permintaan tertentu dapat memerlukan komponen tambahan untuk menyelesaikan penyewa ke stempel. Komponen ini, pada gilirannya, mungkin perlu dibuat sangat tersedia.
• Komponen bersama. Anda mungkin memiliki beberapa komponen yang dapat dibagikan di seluruh stempel. Misalnya, jika Anda memiliki aplikasi satu halaman bersama untuk semua penyewa, pertimbangkan untuk menyebarkannya ke dalam satu wilayah dan menggunakan Azure CDN untuk mereplikasinya secara global.

Kapan menggunakan pola ini

Pola ini berguna jika Anda memiliki:

• Batas alami pada skalabilitas. Misalnya, jika beberapa komponen tidak dapat atau tidak seharusnya menskalakan melampaui jumlah pelanggan atau permintaan tertentu, pertimbangkan untuk melakukan peluasan skala menggunakan stempel.
• Persyaratan untuk memisahkan penyewa tertentu dari penyewa lain. Jika Anda memiliki pelanggan yang tidak dapat disebarkan ke dalam stempel multipenyewa dengan pelanggan lain karena masalah keamanan, mereka dapat disebarkan ke stempel terisolasi mereka sendiri.
• Kebutuhan untuk memiliki beberapa penyewa pada versi yang berbeda dari solusi Anda pada waktu yang sama.
• Aplikasi multi-wilayah yang data dan lalu lintas setiap penyewanya harus diarahkan ke wilayah tertentu.
• Keinginan untuk mencapai ketahanan selama penonaktifan. Karena stempel tidak tergantung satu sama lain, jika penonaktifan memengaruhi satu stempel, penyewa yang ditempatkan di stempel lain tidak akan terpengaruh. Isolasi ini membantu menahan 'radius ledakan' dari suatu insiden atau penonaktifan.

Pola ini tidak cocok untuk:

• Solusi sederhana yang tidak perlu diskalakan ke tingkat yang tinggi.
• Sistem yang dapat dengan mudah diluaskan skalanya atau ditingkatkan skalanya dalam satu instans, seperti dengan meningkatkan ukuran lapisan aplikasi atau dengan meningkatkan kapasitas yang dicadangkan untuk database dan tingkat penyimpanan.
• Solusi yang datanya harus direplikasi di semua instans yang disebarrkan. Pertimbangkan pola geode untuk skenario ini.
• Solusi yang hanya beberapa komponennya yang perlu diskalakan, tetapi tidak yang lain. Misalnya, pertimbangkan apakah solusi Anda dapat diskalakan dengan sharding penyimpanan data daripada menyebarkan salinan baru dari semua komponen solusi.
• Solusi hanya terdiri dari konten statik, seperti aplikasi JavaScript front-end. Pertimbangkan untuk menyimpan konten tersebut di akun penyimpanan dan menggunakan Azure CDN.

Desain beban kerja

Arsitek harus mengevaluasi bagaimana pola Stempel Penyebaran 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.

Teknologi pendukung

• Infrastruktur sebagai kode. Misalnya, Bicep, templat Resource Manager, Azure CLI, Terraform, PowerShell, Bash.
• Azure Front Door, yang dapat mengarahkan lalu lintas ke stempel tertentu atau ke layanan perutean lalu lintas.

Contoh

Contoh berikut menyebarkan beberapa stempel dari solusi PaaS sederhana, dengan layanan aplikasi dan SQL Database di setiap stempel. Sementara stempel dapat dikonfigurasi di wilayah mana pun yang mendukung layanan yang disebarkan dalam templat, untuk tujuan ilustrasi, templat ini menyebarkan dua stempel di wilayah US Barat 2 dan stempel lebih lanjut di wilayah Eropa Barat. Di dalam stempel, layanan aplikasi menerima nama host DNS publiknya sendiri dan dapat menerima koneksi secara independen dari semua stempel lainnya.

Klik link di bawah untuk menyebarkan solusi.

Contoh pendekatan perutean lalu lintas

Contoh berikut menyebarkan penerapan solusi perutean lalu lintas yang dapat digunakan dengan sekumpulan stempel penyebaran untuk aplikasi API hipotetis. Untuk memungkinkan distribusi geografis dari permintaan masuk, Front Door disebarkan bersama beberapa instans API Management pada tingkat konsumsi. Setiap instans API Management membaca ID penyewa dari URL permintaan lalu mencari stempel yang relevan untuk permintaan dari penyimpanan data Azure Cosmos DB yang didistribusikan secara geografis. Permintaan tersebut kemudian diteruskan ke stempel back-end yang relevan.

Klik link di bawah untuk menyebarkan solusi.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

• John Downs | Manajer Program Utama

Kontributor lain:

• Daniel Larsen | Teknisi Pelanggan Utama, FastTrack untuk Azure
• Angel Lopez | Insinyur Perangkat Lunak Senior, Pola dan Praktik Azure
• Paolo Salvatori | Teknisi Pelanggan Utama, FastTrack untuk Azure
• Arsen Vladimirskiy | Teknisi Pelanggan Utama, FastTrack untuk Azure

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Sumber daya terkait

• Sharding dapat digunakan sebagai pendekatan lain yang lebih sederhana untuk meluaskan skala tingkat data Anda. Stempel secara implisit memecah datanya, tetapi sharding tidak memerlukan Stempel Penyebaran. Untuk informasi selengkapnya, lihat Pola sharding.
• Jika layanan perutean lalu lintas disebarkan, pola Perutean Gateway dan Pemindahan Gateway dapat digunakan bersama untuk memanfaatkan komponen ini dengan sebaik-baiknya.