Azure App Service: Matikan ARR Affinity kalau bisa

Kalau kita membuka tab Application Setting di azure app service, ada setting yang namanya ARR Affinity:

Di situ ada keterangan seperti ini:

You can improve the performance of your stateless applications by turning off the Affinity Cookie, stateful applications should keep the Affinity Cookie turned on for increased compatibility. Click to learn more.

Maksudnya gimana?

Azure app service memiliki feature yang namanya scale-out. Scale out ini pada intinya menambah jumlah server yang melayani request (load balancing). Proses scale-out bisa dilakukan secara automatis bisa juga secara manual.

Misal scenarionya gini:

  • Kita punya aplikasi web yang dihosting di app service plan,
  • Kita setting agar auto scale-out saat CPU Load > 80% selama 15 menit terakhir.
  • Saat ini ada 1000 user sedang menggunakan aplikasi, dan semua orang ini adalah signed in user (bukan pengunjung anonim).

Ceritanya karena heavy load akhirnya proses auto scale-out terjadi. Si app service plan menambah server jadi dua ~ namanya A dan B.

Selanjutnya apa yang terjadi? Apakah request-request berikutnya secara automatis akan dibagi rata ke dua server itu?

Tergantung.

Ada beberapa aplikasi dimana si user gak bisa dipindahin gitu aja ke server lain. Kalau dipindahin maka data-data dia yang ada di session akan hilang dan proses jadi macet. Aplikasi model kayak gitu  disebut dengan stateful application.

Azure mengatasi problematika stateful application dengan menggunakan affinity cookie. Kalau ada affinity cookie, sekali user dilayani oleh server A maka dia akan terus dilayani oleh server A. Nanti kalau ada user fresh baru dia akan dibagi antara A dan B.

Oke, kayaknya keren, terus masalahnya apa? Masalahnya adalah, proses scale out tidak akan secara instant membagi load ke server baru. Jadi percuma kita punya dua atau tiga server kalau requestnya tetep masuk ke server pertama doang. Jadinya server pertama tetep full load, server sisanya nganggur, dan user tetep akan mengeluh lambat.

So.. matikan ARR cookie kalau aplikasi kita stateless. Nyimpan user data di Session variable? Statefull. Nyimpan temporary user data di static variable? Statefull. Tapi kalau data di static variable bisa di-create ulang tanpa masalah (kayak data cache), maka aman.

Buat memastikan aman atau enggak, coba deploy si web apps ke app service plan dan setting si app service plan secara manual agar selalu menggunakan minimum 2 server. Matikan ARR affinity lalu coba login dan gunakan aplikasi seperti biasa. Kalau muncul error aneh atau kita ketendang terus, tandanya emang gak bisa.

More: https://azure.microsoft.com/en-us/blog/disabling-arrs-instance-affinity-in-windows-azure-web-sites/

 

 

Catatan Mengkonfigurasi koneksi Point-to-Site Azure VPN

Point-to-Site (P2S) connection adalah cara untuk membuat koneksi langsung dari masing-masing komputer ke Azure Virtual Network. Kalau konfigurasinya berhasil hasil akhirnya seperti ini:

Cara untuk membuat koneksi P2S sudah dijabarkan dengan jelas di halaman dokumentasi yang berhubungan, yang pengen gw tulis di sini adalah beberapa catatan soal pengalaman gw setting P2S (meskipun cuma sekali).

Buat Apa?

  • Pertama buat keamanan. Kita bisa membuat koneksi (RDP dll) ke VM azure tanpa harus mengexpose si VM ke internet. Bahkan si VM gak perlu punya IP public sama sekali.
  • Terus kalau mau diakses dari app service gimana? App service bisa melakukan koneksi ke azure vpn selama si vpn sudah ada gateway-nya.

Apa saja yang dibutuhkan dan Biayanya

  • Pertama jelas butuh azure virtual network. Kalau bikin VM azure zaman sekarang (model resource manager) kita akan dibuatin secara automatis.
  • Virtual Network ini kalau gak salah gratis, cuma bayar network traffic doang (dan sangat murah)
  • Kedua kita butuh Azure VPN Gateway. Si gateway ini nanti punya IP Public sendiri.
  • VPN gateway tidak gratis. Biaya per bulan adalah sekitar Rp 365.000 untuk yang basic, 2 juta untuk yang standard, dan seterusnya.
  • IP Public juga tidak gratis, sekitar 55rb per bulan.
  • Setting VPN gateway itu gak instant, ada jeda sekitar beberapa puluh menit sampai siap untuk digunakan.
  • Public certificates.  Silahkan baca cara bikinnya di sini

Catatan Lain

  • Hati-hati mengkonfigurasi IP address (subnet). Usahain alamatnya jangan sampai bentrok dengan subnet-subnet yang sudah digunakan di jaringan lokal. Ini tidak cuma berlaku untuk gateway subnet tapi untuk subnet yang digunakan di azure VPN secara keseluruhan.
  • Kalau sudah berhasil konek, coba dulu di komputer lain dan coba di versi windows beda (windows 7 dan 10) baru bikin tutorial untuk teman sekantor.
  • Paling sering gagal koneksi karena masalah certificate. Jadi mohon besabar aja soal itu. Sayang gw udah gak ada catatan soal problem-problem yang dihadapi waktu pertama kali membuat koneksi (dan rada males untuk mengulang).
  • Satu problem yang gw masih ingat adalah, untuk client windows 7 ada satu certificate lagi yang harus diinstall yaitu certificate milik vpn client-nya. Si sertifikat ini bisa kita dapat dengan cara meng-extract file exe dari software VPN Client yang didownload dari azure. Udah kaya teka-teki aja. Entahlah apakah problem itu sudah solve sekarang atau belum.

Karena dulu gw lumayan frustasi saat mengconfigure ini semua, waktu berhasil rasanya seneng banget dan langsung aja bikin tutorial terus bagiin vpn client dan certificatenya. Kalau dipikir-pikir sekarang, idealnya kita bikin satu certificate untuk tiap karyawan. Biar apa? Biar kalau dia resign gampang me-revoke aksesnya.

Kalau karyawannya banyak gimana? Ya.. mungkin gak bisa pake P2S, tapi pake site to site IPSEC (harus modal VPN hardware), atau kasih ke sebagian karyawan aja.

Aturan Penamaan Azure Storage yang Membingungkan

Azure Storage adalah salah satu service dari ms azure yang paling sering gw pakai.  Azure storage terdiri atas beberapa macam service: blob, table, queue, file share, dan  disk.

Satu hal yang lumayan mengesalkan dari azure storage ini adalah soal aturan penamaan.

Storage Account

Untuk menggunakan layanan dari azure storage kita harus membuat storage account terlebih dahulu. Nama storage account harus terdiri atas 3-24 karakter alphanumeric dan harus huruf kecil semua.

Bikin storage account biasanya jarang ada masalah karena langsung lewat portal. Kalau di portal pesan validasinya jelas dan langsung keliatan.

Yang sering jadi masalah adalah servie2 didalamnya karena biasanya kita bikin via code. Saat validasi gagal, si azure akan mengembalikan pesan 400 bad request error tanpa menjelaskan dimana errornya (bisa pas bikin udah salah bisa juga pas insert data baru salah) ~ oke, mungkin ngasih pesan validasi tapi gw gak baca.

Blob

Blob itu simplenya file. Berbeda dengan  nama storage account yang harus huruf kecil semua, nama blob boleh huruf besar dan kecil dan case-sensitive. Panjangnya antara 1-1024 karakter.  Karena alamat si file bentuknya url  maka karakter yang boleh digunakan sama dengan karakter yang boleh digunakan di alamat url.

Container

Container itu kayak folder lah sederhananya, isinya ya si blob-blob itu. Kita bikin container dulu baru nanti naro blob didalamnya.

Aturan penamaan container beda lagi. Nama cotainer harus dimulai dengan angka atau huruf, tapi boleh ada strip (-). Panjang nama container antara 3-63 karakter dan harus huruf kecil semua.

Queues

Digunakan untuk.. well.. queues. Rada panjang ngejelasinnya kalau gak pernah pakai queue. Aturan penamaan queue sama dengan container.

Azure Table

Azure table adalah nosql service dari azure, tapi jauh lebih sederhana dari azure cosmos atau documentdb. Gw suka pakai azure table karena super murah.

Anyway, aturan penamaan azure table yang gw paling gak suka. Nama table boleh huruf besar huruf kecil, tapi case insensitive, panjang dibatasi 3-63 karakter, terus hanya boleh terdiri atas karakter dan angka.

Yang bikin frustasi adalah kita gak ada karakter yang cocok untuk digunakan sebagai separator kayak underscore atau dash. Jadi kita terpaksa pakai CamelCase atau Pisahin99Pakai99Angka.

Aturan lain dari azure table adalah, aturan nama property sama dengan aturan nama identifier C#.

~

Yah, pasti ada alasan sih kenapa aturannya macem-macem gini, tapi tetep aja bikin bingung.

C# Hello World

Sekedar ingin mencoba tampilan source code di blog ini.
Menggunakan Pre:

public class HelloWorld
{
   public static void Main()
   {
      System.Console.WriteLine("Hello, World!");
   }
}

Menggunakan Code:

public class HelloWorld
{
public static void Main()
{
System.Console.WriteLine("Hello, World!");
}
}

Oke, jadi kesimpulannya lebih bagus pakai ‘pre’

Halo dunia!

Akhirnya bisa bergabung di Microsoft User Group Indonesia. Ini adalah tulisan pertama saya di blog komunitas ini yang secara otomatis di-generate oleh sistem sebagai penyemangat untuk mulai dan terus menulis. Saya berharap dapat berkontribusi lebih dan menebarkan manfaat untuk komunitas ini. Salam kenal semua! 🙂