Menerapkan Pola WAF pada Arsitektur Nyata

Menerapkan pola WAF pada arsitektur nyata bukanlah latihan teoretis — hal ini memerlukan evaluasi setiap keputusan desain berdasarkan lima pilar dan pembuatan kompromi yang berlandaskan informasi. Titik awal yang umum adalah diagram arsitektur: telusuri jalur permintaan pengguna melalui setiap komponen dan tanyakan, untuk setiap lompatan, apa yang terjadi jika komponen ini gagal, berapa biayanya, dan bagaimana komponen tersebut diamankan.

Pertimbangkan aplikasi web monolitik tradisional: satu VM yang menjalankan server web dan basis data secara bersamaan di balik IP publik. Berdasarkan pilar WAF, arsitektur ini memperoleh skor buruk pada kelima pilar: tidak ada redundansi (keandalan), basis data berada di host yang sama dengan tingkat web (keamanan), VM selalu aktif terlepas dari lalu lintas (biaya), tidak ada CI/CD (keunggulan operasional), dan hanya penskalaan vertikal (efisiensi performa).

Untuk memenuhi pilar Keandalan, sebarkan tingkat web ke beberapa VM di zona ketersediaan yang berbeda, lindungi database dengan replikasi geografis ke wilayah sekunder, dan tempatkan Azure Load Balancer di bagian depan. Dengan demikian, tidak ada lagi satu titik kegagalan, dan aplikasi dapat tetap beroperasi saat terjadi gangguan pada zona atau wilayah tanpa intervensi manual.

Untuk pilar Keamanan, pisahkan tingkat web dan database ke subnet yang berbeda dengan aturan NSG yang hanya mengizinkan tingkat web terhubung ke port database. Simpan string koneksi database di Azure Key Vault dan gunakan identitas terkelola pada aplikasi web untuk mengambilnya saat runtime — sehingga kredensial yang ditulis secara permanen tidak perlu disimpan dalam kode aplikasi dan file konfigurasi.

Untuk Optimasi Biaya, ganti VM yang selalu aktif dengan Virtual Machine Scale Set yang mengurangi skala selama jam di luar puncak. Untuk database, evaluasi apakah layanan PaaS terkelola seperti Azure SQL Database dengan tingkat DTU yang sesuai lebih murah daripada VM lengkap dengan SQL Server. Beli Reserved Instances untuk kapasitas dasar yang dapat Anda prediksi 12 bulan sebelumnya.

Tingkatkan Keunggulan Operasional dengan mendefinisikan seluruh infrastruktur sebagai templat Bicep atau ARM yang disimpan dalam kendali versi. Buat alur kerja CI/CD di Azure Pipelines atau GitHub Actions yang secara otomatis menerapkan perubahan infrastruktur dan kode aplikasi. Tambahkan gerbang penerapan — pengujian asap otomatis dan persetujuan manual — sebelum perubahan mencapai produksi.

Untuk Efisiensi Performa, tambahkan Azure Cache for Redis di depan database untuk menyimpan kueri yang sering dibaca dalam cache dan mengurangi beban database. Terapkan aset statis (gambar, CSS, JavaScript) melalui Azure CDN agar dapat disajikan dari node tepi yang dekat dengan pengguna di seluruh dunia. Uji beban aplikasi setelah setiap perubahan untuk memastikan peningkatannya dapat diukur.

Setiap perubahan arsitektur melibatkan kompromi. Misalnya, beralih ke arsitektur multi-zona meningkatkan keandalan tetapi meningkatkan biaya (dua zona = dua VM). Menambahkan caching Redis meningkatkan performa tetapi menambah kompleksitas operasional (ada layanan lain yang harus dipantau dan dipelihara). Dokumentasi arsitektur yang baik mencatat kompromi ini secara eksplisit agar arsitek di masa mendatang memahami alasan di balik keputusan yang dibuat.

Hindari upaya mencapai kesempurnaan dalam satu kali perancangan ulang — pendekatan itu mahal, berisiko, dan lambat. Sebagai gantinya, terapkan siklus peningkatan iteratif: jalankan Well-Architected Review, identifikasi tiga masalah dengan dampak tertinggi, perbaiki masalah tersebut, ukur peningkatannya, lalu ulangi. Pendekatan ini menyelaraskan peningkatan arsitektur dengan pengiriman agile dan membuat kemajuan terlihat oleh pemangku kepentingan pada setiap sprint.

Microsoft menerbitkan arsitektur referensi untuk pola beban kerja umum di Azure Architecture Center. Di dalamnya terdapat arsitektur aplikasi web, microservices di AKS, alur kerja analitik data, dan banyak lagi. Setiap arsitektur referensi telah dievaluasi berdasarkan pilar WAF dan menyertakan catatan tentang kompromi yang dibuat untuk pola tertentu tersebut.

Gunakan Architecture Decision Records (ADRs) untuk mendokumentasikan pilihan arsitektur yang signifikan, konteks saat pilihan tersebut dibuat, alternatif yang dipertimbangkan, serta dampaknya terhadap pilar WAF. ADR yang disimpan dalam kendali versi bersama basis kode akan membentuk riwayat yang dapat diaudit dan membantu anggota tim baru memahami alasan arsitektur tersebut dibuat seperti sekarang.

Uji pemahaman Anda tentang konsep Microsoft Azure Fundamentals (AZ-900) dari pelajaran ini.

Dalam pelajaran ini Anda mempelajari bahwa: pola WAF diterapkan dengan mengevaluasi setiap keputusan arsitektur berdasarkan kelima pilar; peningkatan dapat dilakukan secara iteratif dengan memulai dari masalah dengan dampak tertinggi; dan kompromi harus didokumentasikan agar arsitek di masa mendatang memahami alasannya. Selanjutnya kita akan membahas SLA Azure dan cara menghitung SLA gabungan untuk arsitektur dengan banyak layanan.