Siapkan

  • 5 menit

Anda akan menambahkan penyempurnaan Anda sendiri ke arsitektur yang ada yang memenuhi persyaratan keandalan tinggi organisasi. Di sini, kita akan membahas konteks latar belakang yang Anda butuhkan untuk berhasil dengan latihan.

Konteks masalah

Sepatu Contoso harus siap untuk peluncuran produk profil tinggi berikutnya, yang diharapkan dapat menciptakan peningkatan lalu lintas yang signifikan. Dalam dua tahun terakhir, ada beberapa insiden yang menyebabkan situs web offline selama setengah hari. Sistem ini tidak diuji sepenuhnya di lingkungan dev/test, dan beberapa bug merayap ke dalam produksi. Pemecahan masalah dan remediasi membutuhkan waktu lama, karena operator tidak dapat mengidentifikasi akar penyebabnya dengan cepat.

Ada beberapa tantangan ketika komponen tertentu tidak tersedia. Operasi peluasan skala pada komputasi terpengaruh ketika Azure Key Vault salah dikonfigurasi. Selain itu, tidak ada strategi untuk pemadaman regional. Dalam insiden baru-baru ini, seluruh wilayah Eropa Barat turun. Karena beban kerja hanya berjalan di wilayah itu, perusahaan harus menanggung kerugian finansial sampai wilayah itu kembali naik.

Arsitektur saat ini

Agar Anda dapat menyelesaikan tantangan ini, Anda harus memiliki pemahaman yang baik tentang arsitektur Contoso Shoes saat ini. Mari kita fokus pada lapisan API mereka.

Diagram arsitektur dasar untuk aplikasi web.

Komponen

Semua komponen arsitektur ini disebarkan ke satu wilayah.

  • SKU Standar paket Azure App Service menyediakan platform komputasi yang menghosting aplikasi. Autoscaling diaktifkan. Lingkungan pengembangan menggunakan SKU B1 Dasar.

  • Azure App Service menyediakan platform aplikasi yang menjalankan kode API dalam kontainer. Fitur Autentikasi App Service diaktifkan untuk otorisasi.

  • Slot penyebaran memungkinkan Anda menggelar penyebaran lalu menukarnya dengan penyebaran produksi. Mereka hanya digunakan dalam produksi.

  • Azure Container Registry menyimpan kode API kontainer dan didorong melalui alur Integrasi Berkelanjutan/Pengiriman Berkelanjutan (CI/CD) yang dibuat dan dikelola tim beban kerja. Baik produksi maupun lingkungan dev/test menggunakan registri kontainer.

  • Azure Cosmos DB dengan SQL API menyimpan semua status yang terkait dengan beban kerja. Akun database Cosmos DB memiliki database tunggal yang berisi beberapa kontainer dalam model throughput Bersama. Akun Azure Cosmos menggunakan mode kapasitas Tanpa Server. Ada satu instans untuk produksi dan satu untuk dev/test.

  • Azure Key Vault menyimpan rahasia yang diperlukan api untuk melakukan panggilan HTTP POST ke API pihak ketiga eksternal sebagai bagian dari satu alur permintaan. Aplikasi mengakses rahasia melalui referensi Key Vault dalam konfigurasi aplikasi Azure App Service. Ada satu Key Vault untuk produksi dan satu untuk dev/test.

  • Azure Log Analytics digunakan sebagai sink terpadu untuk menyimpan log dan metrik untuk semua pengaturan Azure Diagnostics untuk semua komponen yang digunakan dalam solusi. Ada satu ruang kerja untuk produksi dan satu untuk dev/test.

  • Azure Application Insights digunakan untuk menangkap telemetri dan log dari API. Application Insights menggunakan mode mandiri, bukan menulis ke ruang kerja analitik log khusus. Produksi dan dev/test tidak berbagi instans umum.

  • Azure Pipelines digunakan untuk CI/CD yang membangun, menguji, dan menyebarkan beban kerja di lingkungan praproduksi dan produksi. Tim beban kerja mengelola alur, yang juga mengelola semua infrastruktur dalam solusi mereka. Bicep adalah pilihan teknologi untuk Infrastructure-as-Code (IaC).

Pilihan desain

Dalam daftar komponen, stempel penyebaran terdiri dari layanan yang berpartisipasi dalam memproses permintaan. Layanan tersebut termasuk App Services dan kode API dan Cosmos DB. Stempel ini juga mencakup komponen nonfungsi: Key Vault dan Container Registry. Aplikasi ini memiliki dependensi pihak ketiga pada kerangka kerja performa dan ketahanan. Identitas yang dikelola sistem digunakan di antara komponen stempel.

Di stempel, App Services dikonfigurasi untuk menskalakan secara otomatis berdasarkan beban.

Lingkungan terpisah digunakan untuk produksi dan dev/test. Lingkungan produksi menggunakan SKU Standar paket App Service. Perusahaan membuat pilihan ini untuk dapat menginisiasi aplikasi ke slot sebelum menyebarkannya ke produksi. Lingkungan dev/test menggunakan SKU Dasar untuk pengoptimalan biaya. Kedua lingkungan memiliki instans layanan mereka sendiri. Lingkungan hanya berbagi Container Registry.

Kode API kontainer dikirimkan dalam satu gambar kontainer yang berjalan di App Service. API memiliki beberapa titik akhir HTTP yang digunakan berbagai frontend untuk baca dan tulis. Frontend berada di luar cakupan untuk modul ini, tetapi berada dalam cakupan dalam gambaran besar untuk status misi kritis situasi ini. Kode ini diinstrumentasikan dengan Application Insights untuk mengambil beberapa telemetri dasar. Tim yang mengembangkan kode ini juga mengelola alur CI/CD untuk gambar kontainer API dan alur CI/CD.

Tradeoffs

Namun, seperti halnya semuanya, ada tradeoff dengan arsitektur saat ini. Persyaratan bisnis memprioritaskan pengoptimalan biaya daripada keandalan dan operasi. Untuk menjaga dalam batas biaya, arsitektur belum berevolusi. Komponen tidak berfungsi saat memanfaatkan kemampuan keandalan yang ditawarkan platform. Misalnya, pilihan SKU untuk komputasi mencegah beban kerja menggunakan Zona Ketersediaan. Untuk telemetri, versi Application Insights yang lebih lama digunakan yang tidak terintegrasi dengan Analitik Log.

Selain itu, akses ke beban kerja terlalu pervasif. Misalnya, tanpa integrasi jaringan virtual, semua layanan Azure dapat langsung dijangkau melalui internet publik.

Ketika solusi dikembangkan, tim pengembangan aplikasi menggunakan satu Langganan Azure, mengumpulkan dev/test dan produksi dalam langganan yang sama untuk memudahkan perkakas bagi tim DevOps. Namun, sumber daya produksi dan sumber daya dev/test tidak sepenuhnya terisolasi. Beberapa sumber daya dibagikan antara kedua lingkungan tersebut, meskipun mereka mendapatkan langganan terisolasi dari solusi Contoso Shoes lainnya.

Selain itu, lingkungan dev/test adalah satu lingkungan yang dibagikan di semua anggota tim pengembangan dan QA. Pilihan itu dibenarkan mengingat ukuran tim dan koordinasi antara mereka tidak memerlukan tingkat isolasi yang lebih tinggi. Seiring berkembangnya tim dan solusi, lingkungan dev/test tunggal semakin menyebabkan kompleksitas integrasi saat siklus hidup alur kerja bertabrakan. Churn dan dampaknya pada keandalan telah mahal.

Spesifikasi proyek

Perusahaan ingin menambahkan kemampuan ke arsitektur solusi mereka sehingga mampu menangani peningkatan beban yang diharapkan. Berikut adalah persyaratan bisnis:

  • Bangun kemampuan untuk menahan kegagalan regional dengan memperluas arsitektur ke beberapa wilayah
  • Meningkatkan pengalaman pelanggan dengan melayani klien lebih cepat di wilayah yang secara geografis lebih dekat dengan mereka
  • Selaras dengan peta jalan Azure dan manfaatkan fitur keandalan terbaru yang ditawarkan layanan Azure
  • Tangkap masalah lebih awal dan deteksi dampak bertingkat mereka dalam sistem dengan membangun model kesehatan secara keseluruhan

Persyaratan tersebut hanyalah daftar rencana perbaikan yang diprioritaskan. Tim aplikasi menyadari bahwa semua area desain harus dipertimbangkan untuk membawa keandalan solusi ini hingga standar misi penting. Yakinlah, mereka tidak akan berhenti meningkatkan solusi dan operasi mereka setelah Anda membantu mereka dengan aspek-aspek yang tercakup dalam latihan mendatang.

Selamat datang di tim! Contoso Shoes tak sabar untuk mendengar rekomendasi Anda.

Siapkan

Dalam Challenge Project ini, Anda akan mengambil peran arsitek yang akan membantu Contoso Shoes mencapai hasil keandalan mereka, dimulai dengan item yang diprioritaskan di bagian sebelumnya.

  • Kami menyarankan agar Anda menggunakan alat diagram arsitektur untuk memvisualisasikan arsitektur.
  • Anda tidak memerlukan langganan Azure untuk tantangan ini jika Anda nyaman dengan layanan dan fiturnya.