Desain aplikasi beban kerja misi penting di Azure
Saat Anda merancang aplikasi, persyaratan aplikasi fungsi dan non-fungsi sangat penting. Area desain ini menjelaskan pola arsitektur dan strategi penskalakan yang dapat membantu membuat aplikasi Anda tahan terhadap kegagalan.
Penting
Artikel ini adalah bagian dari seri beban kerja misi penting Azure Well-Architected Framework. Jika Anda tidak terbiasa dengan seri ini, kami sarankan Anda memulai dengan Apa itu beban kerja misi penting?.
Arsitektur unit skala
Semua aspek fungsi dari solusi harus mampu menskalakan untuk memenuhi perubahan permintaan, idealnya penskalaan otomatis sebagai respons terhadap beban. Kami menyarankan agar Anda menggunakan arsitektur unit skala untuk mengoptimalkan skalabilitas end-to-end melalui kompartementalisasi, dan juga untuk menstandarkan proses penambahan dan penghapusan kapasitas. Unit skala adalah unit logis atau fungsi yang dapat diskalakan secara independen. Unit dapat terdiri dari komponen kode, platform hosting aplikasi, stempel penyebaran yang mencakup komponen terkait, dan bahkan langganan untuk mendukung persyaratan multi-penyewa.
Kami merekomendasikan pendekatan ini karena mengatasi batas skala sumber daya individu dan seluruh aplikasi. Ini membantu dengan skenario penyebaran dan pembaruan yang kompleks karena unit skala dapat disebarkan sebagai satu unit. Selain itu, Anda dapat menguji dan memvalidasi versi komponen tertentu dalam unit sebelum mengarahkan lalu lintas pengguna ke unit tersebut.
Misalkan aplikasi misi penting Anda adalah katalog produk online. Ini memiliki alur pengguna untuk memproses komentar dan peringkat produk. Alur ini menggunakan API untuk mengambil dan memposting komentar dan peringkat, dan komponen pendukung seperti titik akhir OAuth, datastore, dan antrean pesan. Titik akhir API stateless mewakili unit fungsional granular yang harus beradaptasi dengan perubahan sesuai permintaan. Platform aplikasi yang mendasar juga harus dapat menskalakan yang sesuai. Untuk menghindari penyempitan performa, komponen dan dependensi hilir juga harus menskalakan ke tingkat yang sesuai. Mereka dapat menskalakan secara independen, sebagai unit skala terpisah, atau bersama-sama, sebagai bagian dari satu unit logis.
Contoh unit skala
Gambar berikut menunjukkan kemungkinan cakupan untuk unit skala. Cakupannya berkisar dari pod layanan mikro hingga node kluster dan stempel penyebaran regional.
Pertimbangan Desain
Cakupan. Cakupan unit skala, hubungan antara unit skala, dan komponennya harus ditentukan sesuai dengan model kapasitas. Pertimbangkan persyaratan non-fungsi untuk performa.
Batas skala. Batas dan kuota skala langganan Azure mungkin memiliki bantalan pada desain aplikasi, pilihan teknologi, dan definisi unit skala. Unit skala dapat membantu Anda melewati batas skala layanan. Misalnya, jika kluster AKS dalam satu unit hanya dapat memiliki 1.000 simpul, Anda dapat menggunakan dua unit untuk meningkatkan batas tersebut menjadi 2.000 simpul.
Beban yang diharapkan. Gunakan jumlah permintaan untuk setiap alur pengguna, tingkat permintaan puncak yang diharapkan (permintaan per detik), dan pola lalu lintas harian/mingguan/musiman untuk menginformasikan persyaratan skala inti. Juga memperhitungkan pola pertumbuhan yang diharapkan untuk lalu lintas dan volume data.
Performa terdegradasi yang dapat diterima. Tentukan apakah layanan yang terdegradasi dengan waktu respons tinggi dapat diterima di bawah beban. Saat Anda memodelkan kapasitas yang diperlukan, performa solusi yang diperlukan di bawah beban adalah faktor penting.
Persyaratan non-fungsi. Skenario teknis dan bisnis memiliki pertimbangan yang berbeda untuk ketahanan, ketersediaan, latensi, kapasitas, dan pengamatan. Analisis persyaratan ini dalam konteks alur pengguna end-to-end utama. Anda akan memiliki fleksibilitas relatif dalam desain, pengambilan keputusan, dan pilihan teknologi pada tingkat alur pengguna.
Rekomendasi desain
Tentukan cakupan unit skala dan batasan yang akan memicu unit untuk diskalakan.
Pastikan bahwa semua komponen aplikasi dapat diskalakan secara independen atau sebagai bagian dari unit skala yang mencakup komponen terkait lainnya.
Tentukan hubungan antara unit skala, berdasarkan model kapasitas dan persyaratan non-fungsional.
Tentukan stempel penyebaran regional untuk menyatukan penyediaan, manajemen, dan pengoperasian sumber daya aplikasi regional ke dalam unit skala heterogen tetapi saling bergantung. Saat beban meningkat, stempel tambahan dapat disebarkan, dalam wilayah Azure yang sama atau yang berbeda, untuk menskalakan solusi secara horizontal.
Gunakan langganan Azure sebagai unit skala sehingga batas skala dalam satu langganan tidak membatasi skalabilitas. Pendekatan ini berlaku untuk skenario aplikasi skala tinggi yang memiliki volume lalu lintas yang signifikan.
Model kapasitas yang diperlukan seputar pola lalu lintas yang diidentifikasi untuk memastikan kapasitas yang memadai disediakan pada waktu sibuk untuk mencegah penurunan layanan. Atau, optimalkan kapasitas selama jam sibuk.
Ukur waktu yang diperlukan untuk melakukan operasi peluasan skala dan penyempitan skala untuk memastikan bahwa variasi alami dalam lalu lintas tidak menciptakan tingkat penurunan layanan yang tidak dapat diterima. Lacak durasi operasi skala sebagai metrik operasional.
Catatan
Saat Anda menyebarkan di zona pendaratan Azure, pastikan bahwa langganan zona pendaratan didedikasikan untuk aplikasi untuk memberikan batas manajemen yang jelas dan untuk menghindari antipattern Noisy Neighbor.
Distribusi global
Tidak mungkin untuk menghindari kegagalan di lingkungan yang sangat terdistribusi. Bagian ini menyediakan strategi untuk mengurangi banyak skenario kesalahan. Aplikasi harus dapat menahan kegagalan regional dan zonal. Ini harus disebarkan dalam model aktif/aktif sehingga beban didistribusikan di antara semua wilayah.
Tonton video ini untuk mendapatkan gambaran umum tentang cara merencanakan kegagalan dalam aplikasi misi penting dan memaksimalkan ketahanan:
Pertimbangan Desain
Redundansi. Aplikasi Anda harus disebarkan ke beberapa wilayah. Selain itu, dalam suatu wilayah, kami sangat menyarankan Anda menggunakan zona ketersediaan untuk memungkinkan toleransi kesalahan di tingkat pusat data. Zona ketersediaan memiliki perimeter latensi kurang dari 2 milidetik antara zona ketersediaan. Untuk beban kerja yang "cerewet" di seluruh zona, latensi ini dapat menimbulkan penalti performa untuk transfer data interzone.
Model aktif/aktif. Strategi penyebaran aktif/aktif direkomendasikan karena memaksimalkan ketersediaan dan menyediakan perjanjian tingkat layanan komposit (SLA) yang lebih tinggi. Namun, ini dapat memperkenalkan tantangan sekeliling sinkronisasi data dan konsistensi untuk banyak skenario aplikasi. Atasi tantangan di tingkat platform data sambil mempertimbangkan trade-off peningkatan biaya dan upaya teknik.
Penyebaran aktif/aktif di beberapa penyedia cloud adalah cara untuk berpotensi mengurangi dependensi pada sumber daya global dalam satu penyedia cloud. Namun, strategi penyebaran aktif/aktif multicloud memperkenalkan sejumlah besar kompleksitas di sekitar CI/CD. Selain itu, mengingat perbedaan spesifikasi dan kemampuan sumber daya di antara penyedia cloud, Anda memerlukan stempel penyebaran khusus untuk setiap cloud.
Distribusi geografis. Beban kerja mungkin memiliki persyaratan kepatuhan untuk residensi data geografis, perlindungan data, dan retensi data. Pertimbangkan apakah ada wilayah tertentu di mana data harus berada atau di mana sumber daya perlu disebarkan.
Asal permintaan. Kedekatan geografis dan kepadatan pengguna atau sistem dependen harus menginformasikan keputusan desain tentang distribusi global.
Konektivitas. Bagaimana beban kerja diakses oleh pengguna atau sistem eksternal akan memengaruhi desain Anda. Pertimbangkan apakah aplikasi tersedia melalui internet publik atau jaringan privat yang menggunakan sirkuit VPN atau Azure ExpressRoute.
Untuk rekomendasi desain dan pilihan konfigurasi di tingkat platform, lihat Platform aplikasi: Distribusi global.
Arsitektur berbasis peristiwa yang digabungkan secara longgar
Coupling memungkinkan komunikasi antar layanan melalui antarmuka yang terdefinisi dengan baik. Kopling longgar memungkinkan komponen aplikasi beroperasi secara independen. Gaya arsitektur layanan mikro konsisten dengan persyaratan misi penting. Ini memfasilitasi ketersediaan tinggi dengan mencegah kegagalan berkala.
Untuk konektor longgar, kami sangat menyarankan Agar Anda menggabungkan desain berbasis peristiwa. Pemrosesan pesan asinkron melalui perantara dapat membangun ketahanan.
Dalam beberapa skenario, aplikasi dapat menggabungkan kopling yang longgar dan ketat, tergantung pada tujuan bisnis.
Pertimbangan Desain
Dependensi runtime. Layanan yang digabungkan secara longgar tidak boleh dibatasi untuk menggunakan platform komputasi, bahasa pemrograman, runtime, atau sistem operasi yang sama.
Penskalaan. Layanan harus dapat diskalakan secara independen. Optimalkan penggunaan infrastruktur dan sumber daya platform.
Toleransi kegagalan. Kegagalan harus ditangani secara terpisah dan tidak boleh memengaruhi transaksi klien.
Integritas transaksi. Pertimbangkan efek pembuatan dan persistensi data yang terjadi di layanan terpisah.
Pelacakan terdistribusi. Pelacakan end-to-end mungkin memerlukan orkestrasi yang kompleks.
Rekomendasi desain
Sejajarkan batas layanan mikro dengan alur pengguna penting.
Gunakan komunikasi asinkron berbasis peristiwa jika memungkinkan untuk mendukung skala berkelanjutan dan performa optimal.
Gunakan pola seperti Kotak Keluar dan Sesi Transaksi untuk menjamin konsistensi sehingga setiap pesan diproses dengan benar.
Contoh: Pendekatan berbasis peristiwa
Implementasi referensi Mission-Critical Online menggunakan layanan mikro untuk memproses satu transaksi bisnis. Ini menerapkan operasi tulis secara asinkron dengan broker pesan dan pekerja. Operasi baca sinkron, dengan hasilnya langsung dikembalikan ke pemanggil.
Pola ketahanan dan penanganan kesalahan dalam kode aplikasi
Aplikasi misi penting harus dirancang agar tangguh sehingga mengatasi skenario kegagalan sebanyak mungkin. Ketahanan ini memaksimalkan ketersediaan dan keandalan layanan. Aplikasi harus memiliki kemampuan pemulihan mandiri, yang dapat Anda terapkan dengan menggunakan pola desain seperti Coba Lagi dengan Backoff dan Circuit Breaker.
Untuk kegagalan non-sementara yang tidak dapat Anda mitigasi sepenuhnya dalam logika aplikasi, model kesehatan dan pembungkus operasional perlu mengambil tindakan korektif. Kode aplikasi harus menggabungkan instrumentasi dan pengelogan yang tepat untuk menginformasikan model kesehatan dan memfasilitasi pemecahan masalah berikutnya atau analisis akar penyebab sesuai kebutuhan. Anda perlu menerapkan pelacakan terdistribusi untuk memberi pemanggil pesan kesalahan komprehensif yang menyertakan ID korelasi saat kegagalan terjadi.
Alat seperti Application Insights dapat membantu Anda mengkueri, menghubungkan, dan memvisualisasikan jejak aplikasi.
Pertimbangan Desain
Konfigurasi yang tepat. Tidak jarang masalah sementara menyebabkan kegagalan berkala. Misalnya, mencoba kembali tanpa back-off yang sesuai memperburuk masalah ketika layanan sedang dibatasi. Anda dapat memberi ruang penundaan coba lagi secara linier atau meningkatkannya secara eksponensial untuk mundur melalui penundaan yang terus bertambah.
Titik akhir kesehatan. Anda dapat mengekspos pemeriksaan fungsi dalam kode aplikasi dengan menggunakan titik akhir kesehatan yang dapat dijajaki solusi eksternal untuk mengambil status kesehatan komponen aplikasi.
Rekomendasi desain
Berikut adalah beberapa pola rekayasa perangkat lunak umum untuk aplikasi tangguh:
| Pola | Ringkasan |
|---|---|
| Perataan Beban Berbasis Antrean | Memperkenalkan buffer antara konsumen dan sumber daya yang diminta untuk memastikan tingkat beban yang konsisten. Saat permintaan konsumen diantrekan, proses pekerja menanganinya terhadap sumber daya yang diminta dengan kecepatan yang ditetapkan oleh pekerja dan oleh kemampuan sumber daya yang diminta untuk memproses permintaan. Jika konsumen mengharapkan balasan atas permintaan mereka, Anda perlu menerapkan mekanisme respons terpisah. Terapkan urutan yang diprioritaskan sehingga aktivitas terpenting dilakukan terlebih dahulu. |
| Pemutus Sirkuit | Memberikan stabilitas dengan menunggu pemulihan atau dengan cepat menolak permintaan daripada memblokir saat menunggu layanan atau sumber daya jarak jauh yang tidak tersedia. Pola ini juga menangani kesalahan yang mungkin membutuhkan waktu variabel untuk pulih dari ketika koneksi dibuat ke layanan atau sumber daya jarak jauh. |
| Sekat | Upaya untuk mempartisi instans layanan ke dalam grup berdasarkan persyaratan beban dan ketersediaan, mengisolasi kegagalan untuk mempertahankan fungsionalitas layanan. |
| Saga | Mengelola konsistensi data di seluruh layanan mikro yang memiliki penyimpanan data independen dengan memastikan bahwa layanan saling memperbarui melalui saluran peristiwa atau pesan yang ditentukan. Setiap layanan melakukan transaksi lokal untuk memperbarui statusnya sendiri dan menerbitkan peristiwa untuk memicu transaksi lokal berikutnya dalam saga. Jika pembaruan layanan gagal, saga menjalankan kompensasi transaksi untuk melawan langkah-langkah pembaruan layanan sebelumnya. Langkah-langkah pembaruan layanan individual dapat menerapkan pola ketahanan, seperti mencoba kembali. |
| Pemantauan Titik Akhir Kesehatan | Menerapkan pemeriksaan fungsi dalam aplikasi yang dapat diakses alat eksternal melalui titik akhir yang diekspos secara berkala. Anda dapat menginterpretasikan respons dari titik akhir dengan menggunakan metrik operasional utama untuk menginformasikan kesehatan aplikasi dan memicu respons operasional, seperti menaikkan pemberitahuan atau melakukan penyebaran pembatalan kompensasi. |
| Coba lagi | Menangani kegagalan sementara secara elegan dan transparan. - Batal jika kesalahan tidak mungkin sementara dan tidak mungkin berhasil jika operasi dicoba lagi. - Coba lagi jika kesalahan tidak biasa atau langka dan operasi kemungkinan akan berhasil jika dicoba lagi segera. - Coba lagi setelah penundaan jika kesalahan disebabkan oleh kondisi yang mungkin membutuhkan waktu singkat untuk pulih, seperti konektivitas jaringan atau kegagalan beban tinggi. Terapkan strategi back-off yang sesuai saat penundaan coba lagi meningkat. |
| Pembatasan | Mengontrol konsumsi sumber daya yang digunakan oleh komponen aplikasi, melindunginya dari menjadi terlalu tertanam. Ketika sumber daya mencapai ambang beban, sumber daya menunda operasi berprioritas lebih rendah dan menurunkan fungsionalitas yang tidak penting sehingga fungsionalitas penting dapat berlanjut hingga sumber daya yang memadai tersedia untuk kembali ke operasi normal. |
Berikut adalah beberapa rekomendasi tambahan:
Gunakan SDK yang disediakan vendor, seperti Azure SDK, untuk menyambungkan ke layanan dependen. Gunakan kemampuan ketahanan bawaan alih-alih menerapkan fungsionalitas kustom.
Terapkan strategi back-off yang sesuai saat mencoba kembali panggilan dependensi yang gagal untuk menghindari skenario DDoS yang ditimpa sendiri.
Tentukan kriteria rekayasa umum untuk semua tim layanan mikro aplikasi untuk mendorong konsistensi dan kecepatan dalam penggunaan pola ketahanan tingkat aplikasi.
Terapkan pola ketahanan dengan menggunakan paket standar yang terbukti, seperti Polly untuk C# atau Sentinel untuk Java.
Gunakan ID korelasi untuk semua peristiwa pelacakan dan pesan log untuk menautkannya ke permintaan tertentu. Mengembalikan ID korelasi ke pemanggil untuk semua panggilan, bukan hanya permintaan yang gagal.
Gunakan pengelogan terstruktur untuk semua pesan log. Pilih sink data operasional terpadu untuk jejak aplikasi, metrik, dan log untuk memungkinkan operator men-debug masalah dengan mudah. Untuk informasi selengkapnya, lihat Mengumpulkan, mengagregasi, dan menyimpan data pemantauan untuk aplikasi cloud.
Pastikan bahwa data operasional digunakan bersama dengan persyaratan bisnis untuk menginformasikan model kesehatan aplikasi.
Pemilihan bahasa pemrograman
Penting untuk memilih bahasa dan kerangka kerja pemrograman yang tepat. Keputusan ini sering didorong oleh set keterampilan atau teknologi standar dalam organisasi. Namun, penting untuk mengevaluasi performa, ketahanan, dan kemampuan keseluruhan dari berbagai bahasa dan kerangka kerja.
Pertimbangan Desain
Kemampuan kit pengembangan. Ada perbedaan dalam kemampuan yang ditawarkan oleh SDK layanan Azure dalam berbagai bahasa. Perbedaan ini dapat memengaruhi pilihan layanan Azure atau bahasa pemrograman Anda. Misalnya, jika Azure Cosmos DB adalah opsi yang layak, Go mungkin bukan bahasa pengembangan yang sesuai karena tidak ada SDK pihak pertama.
Pembaruan fitur. Pertimbangkan seberapa sering SDK diperbarui dengan fitur baru untuk bahasa yang dipilih. SDK yang umum digunakan, seperti pustaka .NET dan Java, sering diperbarui. SDK atau SDK lain untuk bahasa lain mungkin lebih jarang diperbarui.
Beberapa bahasa atau kerangka kerja pemrograman. Anda dapat menggunakan beberapa teknologi untuk mendukung berbagai beban kerja komposit. Namun, Anda harus menghindari keseleo karena memperkenalkan kompleksitas manajemen dan tantangan operasional.
Opsi komputasi. Perangkat lunak warisan atau kepemilikan mungkin tidak berjalan di layanan PaaS. Selain itu, Anda mungkin tidak dapat menyertakan perangkat lunak warisan atau kepemilikan dalam kontainer.
Rekomendasi desain
Evaluasi semua Azure SDK yang relevan untuk kemampuan yang Anda butuhkan dan bahasa pemrograman pilihan Anda. Verifikasi perataan dengan persyaratan non-fungsional.
Optimalkan pemilihan bahasa dan kerangka kerja pemrograman di tingkat layanan mikro. Gunakan beberapa teknologi yang sesuai.
Prioritaskan .NET SDK untuk mengoptimalkan keandalan dan performa. .NET Azure SDK biasanya menyediakan lebih banyak kemampuan dan sering diperbarui.
Langkah selanjutnya
Tinjau pertimbangan untuk platform aplikasi.