Rekomendasi untuk merancang untuk kesederhanaan dan efisiensi
Berlaku untuk rekomendasi daftar periksa Keandalan Azure Well-Architected Framework ini:
| RE:01 | Rancang beban kerja Anda agar selaras dengan tujuan bisnis dan hindari kompleksitas atau overhead yang tidak perlu. Gunakan pendekatan praktis dan seimbang untuk membuat keputusan desain yang memberikan hasil yang diinginkan. Berisi desain Anda untuk kebutuhan untuk mengurangi inefisiensi dan potensi masalah. |
|---|
Panduan ini menjelaskan rekomendasi untuk meminimalkan kompleksitas dan overhead yang tidak perlu untuk menjaga beban kerja Anda tetap sederhana dan efisien. Pilih komponen terbaik untuk melakukan tugas beban kerja yang diperlukan untuk mengoptimalkan keandalan beban kerja Anda. Untuk mengurangi beban pengembangan dan manajemen Anda, manfaatkan efisiensi yang ditawarkan layanan yang disediakan platform. Desain ini membantu Anda membuat arsitektur beban kerja yang tangguh, dapat diulang, dapat diskalakan, dan dapat dikelola.
Definisi
| Istilah | Definisi |
|---|---|
| Beban kerja | Kemampuan diskrit atau tugas komputasi yang bisa Anda pisahkan secara logis dari tugas lain. |
Strategi desain utama
Prinsip utama merancang untuk keandalan adalah menjaga semuanya tetap sederhana dan efisien. Fokuskan desain beban kerja Anda pada memenuhi persyaratan bisnis untuk mengurangi risiko kompleksitas atau kelebihan overhead yang tidak perlu. Pertimbangkan rekomendasi dalam artikel ini untuk membantu Anda membuat keputusan tentang desain Anda untuk membuat beban kerja yang ramping, efisien, dan andal. Beban kerja yang berbeda mungkin memiliki persyaratan yang berbeda untuk ketersediaan, skalabilitas, konsistensi data, dan pemulihan bencana.
Anda harus membenarkan setiap keputusan desain dengan persyaratan bisnis. Prinsip desain ini mungkin tampak jelas, tetapi sangat penting untuk desain beban kerja. Apakah aplikasi Anda mendukung jutaan pengguna, atau beberapa ribu? Apakah ada ledakan lalu lintas besar, atau beban kerja yang stabil? Tingkat pemadaman aplikasi apa yang dapat diterima? Persyaratan bisnis mendorong pertimbangan desain ini.
Tradeoff: Solusi kompleks dapat menawarkan lebih banyak fitur dan fleksibilitas, tetapi dapat memengaruhi keandalan beban kerja karena membutuhkan lebih banyak koordinasi, komunikasi, dan manajemen komponen. Atau, solusi yang lebih sederhana mungkin tidak sepenuhnya memenuhi harapan pengguna, atau mungkin memiliki efek negatif pada skalabilitas dan ekstensibilitas saat beban kerja berkembang.
Latihan desain kolaboratif
Bekerja sama dengan pemangku kepentingan untuk:
Tentukan dan tetapkan tingkat kekritisan ke alur pengguna dan alur sistem beban kerja Anda. Fokuskan desain Anda pada alur penting untuk membantu Anda menentukan komponen yang diperlukan dan pendekatan terbaik untuk mencapai tingkat ketahanan yang diperlukan.
Tentukan persyaratan fungsional dan tidak berfungsi. Pertimbangkan persyaratan fungsi untuk menentukan apakah aplikasi melakukan tugas. Pertimbangkan persyaratan nonfungsi untuk menentukan seberapa baik aplikasi melakukan tugas. Pastikan Anda memahami persyaratan nonfungsi seperti skalabilitas, ketersediaan, dan latensi. Persyaratan ini memengaruhi keputusan desain dan pilihan teknologi.
Menguraikan beban kerja menjadi komponen. Prioritaskan kesederhanaan, efisiensi, dan keandalan dalam desain Anda. Tentukan komponen yang Anda butuhkan untuk mendukung alur Anda. Beberapa komponen mendukung beberapa alur. Identifikasi tantangan mana yang ditangani komponen secara konseptual, dan pertimbangkan untuk menghapus komponen dari alur individual untuk menyederhanakan desain keseluruhan sambil tetap menyediakan fungsionalitas penuh. Untuk informasi selengkapnya, lihat Rekomendasi untuk melakukan analisis mode kegagalan.
Gunakan analisis mode kegagalan untuk mengidentifikasi satu titik kegagalan dan potensi risiko. Pertimbangkan apakah Anda perlu mempertimbangan situasi yang tidak mungkin, misalnya area geografis yang mengalami bencana alam besar yang memengaruhi semua zona ketersediaan di wilayah tersebut. Ini mahal dan melibatkan tradeoff yang signifikan untuk mengurangi risiko yang jarang terjadi ini. Pahami dengan jelas toleransi bisnis Anda terhadap risiko. Untuk informasi selengkapnya, lihat Rekomendasi untuk melakukan analisis mode kegagalan.
Tentukan target ketersediaan dan pemulihan untuk alur Anda untuk menginformasikan arsitektur beban kerja Anda. Metrik bisnis mencakup tujuan tingkat layanan (SLA), perjanjian tingkat layanan (SLA), waktu rata-rata untuk pulih (MTTR), waktu rata-rata antara kegagalan (MTBF), tujuan waktu pemulihan (RTO), dan tujuan titik pemulihan (RPO). Tentukan nilai target untuk metrik ini. Latihan ini mungkin memerlukan kompromi dan pemahaman bersama antara tim teknologi dan bisnis untuk memastikan bahwa tujuan setiap tim memenuhi tujuan bisnis dan realistis. Untuk informasi selengkapnya, lihat Rekomendasi untuk menentukan target keandalan.
Rekomendasi desain tambahan
Anda dapat melakukan rekomendasi berikut tanpa keterlibatan pemangku kepentingan:
Berusahalah untuk kesederhanaan dan kejelasan dalam desain Anda. Gunakan tingkat abstraksi dan granularitas yang sesuai untuk komponen dan layanan Anda. Hindari overengineering atau under-engineering solusi Anda. Misalnya, jika Anda memecah kode menjadi beberapa fungsi kecil, sulit untuk memahami, menguji, dan memelihara.
Yakin bahwa semua aplikasi yang berhasil berubah dari waktu ke waktu, apakah akan memperbaiki bug, menerapkan fitur atau teknologi baru, atau membuat sistem yang ada lebih dapat diskalakan dan tangguh.
Gunakan opsi platform as a service (PaaS) alih-alih infrastruktur sebagai layanan (IaaS) jika memungkinkan. Infrastruktur sebagai layanan seperti memiliki sekotak suku cadang. Anda dapat membangun apa saja, tetapi Anda harus merakitnya sendiri. Opsi Platform as a Service lebih mudah dikonfigurasi dan dikelola. Anda tidak perlu menyiapkan komputer virtual (VM) atau jaringan virtual. Anda juga tidak perlu melakukan tugas pemeliharaan, seperti menginstal patch dan pembaruan.
Gunakan pesan asinkron untuk memisahkan produsen pesan dari konsumen.
Infrastruktur abstrak jauh dari logika domain. Pastikan bahwa logika domain tidak mengganggu fungsionalitas terkait infrastruktur, seperti olahpesan atau persistensi.
Pindahkanmasalah pemotongan silang ke layanan terpisah. Minimalkan kebutuhan untuk menduplikasi kode di berbagai fungsi, lebih suka menggunakan kembali layanan dengan antarmuka yang terdefinisi dengan baik yang dapat dengan mudah dikonsumsi oleh komponen yang berbeda. Misalnya, jika beberapa layanan perlu mengautentikasi permintaan, Anda dapat memindahkan fungsionalitas ini ke layanannya sendiri. Kemudian Anda dapat mengembangkan layanan autentikasi. Misalnya, Anda dapat menambahkan alur autentikasi baru tanpa menyentuh salah satu layanan yang menggunakannya.
Evaluasi kesesuaian pola dan praktik umum untuk kebutuhan Anda. Hindari tren atau rekomendasi berikut yang mungkin tidak terbaik untuk konteks atau persyaratan Anda. Misalnya, layanan mikro bukanlah opsi terbaik untuk setiap aplikasi karena dapat memperkenalkan masalah kompleksitas, overhead, dan dependensi.
Kembangkan kode yang cukup
Prinsip-prinsip kesederhanaan, efisiensi, dan keandalan juga berlaku untuk praktik pengembangan Anda. Dalam beban kerja komponen yang digabungkan secara longgar, tentukan fungsionalitas yang disediakan komponen. Kembangkan alur Anda untuk memanfaatkan fungsionalitas tersebut. Pertimbangkan rekomendasi ini untuk praktik pengembangan Anda:
Gunakan kemampuan platform saat memenuhi persyaratan bisnis Anda. Misalnya, untuk membongkar pengembangan dan manajemen, gunakan solusi kode rendah, tanpa kode, atau tanpa server yang ditawarkan penyedia cloud Anda.
Gunakan pustaka dan kerangka kerja.
Memperkenalkan sesi pemrograman pasangan atau peninjauan kode khusus sebagai praktik pengembangan.
Terapkan pendekatan untuk mengidentifikasi kode mati. Bersikaplah skeptis dengan kode yang tidak dicakup oleh pengujian otomatis Anda.
Menggunakan penyimpanan data terbaik untuk data Anda
Di masa lalu, banyak organisasi menyimpan semua data mereka dalam database SQL relasional besar. Database relasional memberikan jaminan atom, konsisten, terisolasi, dan tahan lama (ACID) untuk transaksi data relasional. Tetapi database ini memiliki kerugian:
Kueri dapat memerlukan gabungan yang mahal.
Anda perlu menormalkan data dan merestrukturisasinya untuk skema saat menulis.
Ketidakcocokan kunci dapat memengaruhi performa.
Alternatif untuk database relasional
Dalam solusi besar, satu teknologi penyimpanan data kemungkinan tidak memenuhi semua kebutuhan Anda. Alternatif untuk database relasional meliputi:
Penyimpanan kunci-nilai
Database dokumen
Database mesin pencari
Data deret waktu
Database keluarga kolom
Database grafik
Setiap opsi memiliki pro dan kontra. Jenis data yang berbeda lebih cocok untuk berbagai jenis penyimpanan data. Pilih teknologi penyimpanan yang paling cocok untuk data Anda dan cara Anda menggunakannya.
Misalnya, Anda dapat menyimpan katalog produk dalam database dokumen, seperti Azure Cosmos DB, yang mendukung skema fleksibel. Setiap deskripsi produk adalah dokumen mandiri. Untuk kueri di seluruh katalog, Anda mungkin mengindeks katalog dan menyimpan indeks di Azure Cognitive Search. Inventori produk mungkin masuk ke database SQL karena data tersebut memerlukan jaminan ACID.
Rekomendasi
Pertimbangkan penyimpanan data lainnya. Database relasional tidak selalu sesuai. Untuk informasi selengkapnya, lihat Memahami model penyimpanan data.
Ingat bahwa data mencakup lebih dari sekadar data aplikasi yang bertahan. Data itu juga termasuk log aplikasi, kejadian, pesan, dan cache.
Rangkul persistensi poliglot atau solusi yang menggunakan kombinasi teknologi penyimpanan data.
Pertimbangkan jenis data yang Anda miliki. Misalnya, simpan:
Data transaksi dalam database SQL.
Dokumen JSON dalam database dokumen.
Telemetri dalam database rangkaian waktu.
Log aplikasi di Azure Cognitive Search.
Blob di Azure Blob Storage.
Prioritaskan ketersediaan daripada konsistensi. Teori CAP menyiratkan bahwa Anda harus melakukan tradeoff antara ketersediaan dan konsistensi dalam sistem terdistribusi. Anda tidak dapat sepenuhnya menghindari partisi jaringan, yang merupakan komponen lain dari teori CAP. Tetapi Anda dapat mengadopsi model konsistensi akhir untuk mencapai ketersediaan yang lebih tinggi.
Pertimbangkan set keterampilan tim pengembangan Anda. Ada keuntungan dalam menggunakan persistensi poliglot, tetapi ada kemungkinan untuk melakukannya dengan berlebihan. Ini membutuhkan set keterampilan baru untuk mengadopsi teknologi penyimpanan data baru. Untuk mendapatkan hasil maksimal dari teknologi ini, tim pengembangan Anda harus:
Optimalkan kueri.
Sesuaikan performa.
Bekerja dengan pola penggunaan yang sesuai.
Pertimbangkan faktor-faktor ini saat Anda memilih teknologi penyimpanan:
Gunakan transaksi kompensasi. Dengan persistensi poliglot, satu transaksi mungkin menulis data ke beberapa penyimpanan. Jika ada kegagalan, gunakan kompensasi transaksi untuk membatalkan langkah apa pun yang telah selesai.
Pertimbangkan konteks terikat, yang merupakan konsep desain berbasis domain. Konteks terikat adalah batas eksplisit di sekitar model domain. Konteks terikat menentukan bagian domain mana yang diterapkan model. Idealnya, konteks terbatas memetakan subdomain dari domain bisnis. Pertimbangkan persistensi poliglot untuk konteks terikat dalam sistem Anda. Misalnya, produk mungkin muncul di subdomain katalog produk dan subdomain inventori produk. Tetapi kemungkinan besar, kedua subdomain ini memiliki persyaratan yang berbeda untuk menyimpan, memperbarui, dan mengkueri produk.
Fasilitasi Azure
Azure menawarkan layanan berikut:
Azure Functions adalah layanan komputasi tanpa server yang dapat Anda gunakan untuk membangun orkestrasi dengan kode minimal.
Azure Logic Apps adalah platform integrasi alur kerja tanpa server yang dapat Anda gunakan untuk membangun orkestrasi dengan GUI atau dengan mengedit file konfigurasi.
Azure Event Grid adalah layanan distribusi pesan terbitkan-berlangganan yang sangat dapat diskalakan dan dikelola sepenuhnya yang menawarkan pola konsumsi pesan fleksibel yang menggunakan protokol MQTT dan HTTP. Dengan Event Grid, Anda dapat membangun alur data dengan data perangkat, membangun arsitektur tanpa server berbasis peristiwa, dan mengintegrasikan aplikasi.
Untuk informasi selengkapnya, lihat:
Contoh
Untuk contoh beban kerja yang menentukan komponen dan fiturnya berdasarkan persyaratan, lihat Pola Reliable Web App.
Tautan terkait
Daftar periksa keandalan
Lihat serangkaian rekomendasi lengkap.
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk