Azure Architectural Series: Static Website

Series ini adalah kumpulan arsitektur cloud di Azure. Setiap series memiliki tujuan berbeda-beda tergantung dalam kasus apa arsitektur tersebut digunakan. Dalam satu series mencakup pembahasan mulai dari use case, architectural view, costing, implementasi, monitoring (jika ada), security (jika ada), hingga disaster recovery (jika ada).

Use Case

Static Website adalah fitur pada Azure Storage Account General Purpose. Terdapat 2 versi Azure Storage General Purpose v1 dan v2, namun disarankan untuk selalu menggunakan v2 karena lebih murah dan memiliki semua fitur dari v1 beserta fitur-fitur lainnya seperti Data Tiering (tidak digunakan pada kasus ini). Fungsi utama dari static website adalah menyimpan file static (HTML, CSS, JS, IMG, dll. ) pada blob storage dan men-serve sebagai sebuah website.

Sangat tepat menggunakan Static Website jika memang hanya akan menampilkan website berisi client side programming, namun jika ada bagian dari website tersebut berisi server side programming maka pilihan yang lebih tepat adalah menggunakan Azure AppService.

Architectural View

Berikut ini adalah bentuk arsitektur dari penggunaan static website yang direkomendasikan:

Static Website Architecture Use Case

Keterangan:

1. Repository berada pada Azure DevOps dengan Continuous Integration disimpan pada artifact.
2. Continuous Delivery dengan menggunakan artifact hasil Continuous Integration untuk dikirim ke Static Website (Blob Container) dengan REST API.
3. Azure CDN endpoint digunakan untuk menambahkan custom domain name beserta dengan custom ssl certificate, menjamin konten tetap dekat dengan lokasi pengguna. Serta dapat menggunakan fitur “rules engine” untuk memodifikasi header dan redirection.
4. Mendaftarkan service principal pada Azure Active Directory (biasanya belum ada).
5. Memberikan akses service principal dan user permission kepada Azure Key Vault.
6. Azure Key Vault menyimpan certificate SSL yang digunakan oleh Azure CDN.

Costing

Komponen-komponen yang akan menjadi pertimbangan dari sisi costing adalah:

Table of Cost Driver

Membuat Storage Account

1. Tambahkan storage account general purpose v2 dan sesuaikan lokasi dari subscription, resource group, nama harus unik karena akan menjadi bagian url untuk mengakses storage, performance standard karena premium hanya tersedia untuk disk, access tier gunakan hot karena static website merupakan data yang sering diakses. Pada bagian replikasi. Pilih berdasarkan kebutuhan misal tidak butuh redundancy level region, bisa pilih LRS atau ZRS.

2. Setelah semua pilihan terisi, klik “Review + Create”, networking kita skip karena otomatis akan menggunakan public network, sehingga kita bisa mengakses static website dari luar

3. Terakhir klik create untuk menyelesaikan

Enable Static Feature

1. Pilih “Static Website” pada blade setting di Azure Storage

2. Klik “Enabled” pada static website dan ketik nama index document dan error document untuk static website

3. Klik “Save” untuk menyimpan konfigurasi static website

4. Pada blade blob service, pilih “Containers”

5. Masuk ke folder “$web” untuk mengupload file untuk static website

6. Klik “upload” dan pilih seluruh file yang ingin di-upload dengan menggunakan multi upload

7. Setelah di-upload ubah access level pada container “$web” agar dapat diakses secara anonymous dari CDN

8. Pilih “Ok” dan selesai.

9. Buka browser dan akses endpoint URL ke static website.

Monitoring

Ada dua cara monitoring pada Azure Storage, yaitu dengan metrics dan Azure Monitor (log query). Pada topik ini akan lebih berfokus pada konten static website. Metrics digunakan untuk melihat aktivitas yang terjadi pada storage berdasarkan akses ingress (in), egress (out), availability, dll. Sementara log digunakan untuk melihat lebih detail apa yang terjadi pada storage. Pada kali ini hanya digunakan metrics untuk melakukan monitoring.

Berikut cara menggunakan metrics pada storage:

1. Pilih blade “Metrics” pada bagian “Monitoring” di Storage Account

2. Pada bagian kanan atas ada pilihan untuk menentukan rentang waktu (maksimal 30 hari) dan pengaturan waktu berdasarkan waktu lokal atau GMT. Pilih berdasarkan local time untuk menyesuaikan dengan waktu data center.

3. Pilih resource dan gunakan namespace blob karena static website tersimpan pada container blob

4. Pilih egress untuk melihat berapa banyak data yang diakses keluar dari blob container

5. Pilih “sum” untuk fungsi agregasi menjumlahkan seluruh total data yang diakses

6. Pilih property “API Name” untuk melihat pengaksesan yang lebih spesifik berdasarkan API

7. Pilih “GetWebContent” untuk hanya menampilkan konten blob yang bertipe “$web”

8. Terdapat empat opsi di metrics yang bisa digunakan untuk kustomisasi, yaitu paling kiri untuk mengubah chart, “drill into logs” untuk melihat logs, “new alert rule” untuk menambahkan aturan baru apabila kondisi pada metrics tercapai (misal: trigger untuk mengirim email apabila error 404 melebihi 40% request)

Disaster Recovery

Storage Account dan CDN merupakan service PaaS yang sudah memiliki SLA jaminan dari Azure sehingga dari Availability tidak dapat diubah. Azure CDN sudah pasti tidak bermasalah jika terjadi bencana karena memiliki banyak POP location, yang apabila salah satu down maka yang lainnya masih bisa digunakan.

Pada Storage Account minimal ada 3 stamps (instance storage) yang di-deploy setiap kita membuat satu buah storage account. Setiap stamp tersebut ditempatkan berdasarkan pilihan redundancy option yang dipilih. Untuk development dan testing pilihan redundancy yang paling murah dapat digunakan yaitu LRS, setiap stamps akan di-deploy dalam satu data center yang sama. Kemudian ZRS, setiap stamp ditempatkan pada datacenter yang berbeda namun masih dalam satu region.

Untuk Disaster Recovery ada 4 pilihan yaitu GRS, GZRS, RA-GRS, dan RA-GZRS. GRS memiliki 6 stamps dengan masing-masing 3 stamps ditempatkan pada 2 region berbeda dengan penempatan seperti LRS. GZRS mirip dengan GRS, hanya saja penempatannya 3 stamps tiap region mengikuti cara pada ZRS. RA-GRS dan RA-GZRS akan menambahkan opsi pembacaan pada storage yang berada pada secondary location, akan ada dua connection string yang bisa digunakan sehingga saat melakukan pembacaan bisa dibagi loadnya, namun untuk insert dan update tetap pada storage di primary location.

Pilihan termurah untuk Disaster Recovery Storage Account adalah GRS. Pada saat menentukan redundancy option (saat melakukan “create” Storage Account) pilih GRS. Seluruh pilihan (4 pilihan di atas) untuk Disaster Recovery harus di-set terlebih dahulu agar apabila terjadi fail di primary region dapat langsung failover ke secondary region. Replikasi yang dilakukan Storage Account bersifat asynchronous sehingga ketika terjadi failover akan ada data yang hilang pada secondary region yang belum sync. Untuk melakukan failover pada Storage Account harus digunakan cara manual sebagai berikut:

1. Pada bagian “Settings” pilih “Geo-replication”

2. Pada bagian paling bawah akan ada pilihan untuk “Prepare for failover”

3. Pada bagian text box ketik “yes”, lalu klik failover. Apabila proses telah selesai maka secondary region akan menjadi primary region.

Bagian berikutnya akan dijelaskan pada Part 2