Jenis Topologi Webserver dari Low-Availability sampai dengan High-Availability

Seperti kita ketahui untuk menjalankan aplikasi berbasis web kita perlu web service application entah itu apache, nginx, litespeed, IIS, dsb. Selain web service juga dibutuhkan database application seperti MySQL, Maria DB, Oracle, Microsoft SQL, Postgrey SQL maupun SQLite. Kebanyakan web application menggunakan kombinasi apache dan MySQL. Saya akan bahas beberapa topologi yang bisa digunakan

1. Satu mesin

Topologi ini hanya menggunakan 1 server yang digunakan untuk web service dan database aplikasi. Banyak sekali website menggunakan topologi seperti ini. Shared hosting yang belum berasis cloud juga banyak yang menggunakan topologi semacam ini. Untuk penggunaan biasa saja topologi semacam ini memang masih bisa ditoleransi namun jika kebutuhannya lebih advance seperti untuk corporate, menurut saya tidak disarankan menggunakan topologi ini. Kelemahan topologi ini adalah jika salah satu baik itu web service maupun database service loadnya tinggi maka akan mengganggu secara keseluruhan. Penggunaan resource juga menjadi tidak terbagi optimal.

2. Web service dan database aplikasi terpisah

Topologi ini menggunakan 2 server. 1 Server untuk web service dan 1 server untuk database aplikasi. Dengan topologi ini resource server memiliki pembagian yang jelas. Kita bisa memonitor mana yang perlu resource tambahan apakah web service atau database applicationya. Selain itu topologi ini juga memberikan keamanan untuk database. Biasanya topologi ini menggunakan 2 server dalam 1 data center yang sama. Server terkoneksi melalui private IP. Jadi server database bisa dibatasi hanya dapat diakses dari server web service saja. Anda bahkan bisa menonaktifkan incoming koneksi ke server database dari IP Public jadi lebih secure.

Topologi juga memiliki kelemahan jika resource belum bisa ditangani dengan baik. Apabila server web service terlalu banyak request maka tetap saja web aplikasi tidak dapat diakses karena server web servicenya kepenuhan. Namun hal ini memberikan informasi kepada kita untuk meningkatkan hardware atau bahkan menambahkan lagi server web servicenya.

3. Multi Web Service Server dengan satu database server

Nah topologi selanjutnya ini adalah pengembangan dari topologi sebelumnya. Dengan pemisahan server web service dan database server memberikan kita peluang untuk meningkatkan scalabilitynya dengan lebih cepat. Meskipun menambahkan resource server sekarang ini bisa dilakukan hitungan menit dengan adanya teknologi virtualisasi namun menambah server bisa jadi alternative jika kebutuhannya mendesak.

Topologi setidaknya memiliki 1 server Load Balancer, 2 atau lebih server untuk web service dan 1 server untuk database. Fungsi  server Load balancer adalah untuk mendistribusikan traffic ke setiap web server. Dengan adanya load balancer ini maka traffic ke web service akan terdistribusi secara lebih optimal. Di sini setting untuk server load balaner memiliki peranan penting. Jika tidak dikonfigurasi dengan baik maka fungsi distribusi traffic menjadi tidak optimal. Load balancer ini setidaknya memiliki konfigurasi yang dirancang untuk menangani load traffic.

Kelemahan topologi ini ada pada Load balancernya jika tidak kuat menerima request bisa-bisa malah load balancer servernya yang mati dan akses ke web service server tidak terhubung.

4. Multi web server dengan multi database server

Pengembangan lanjutan dari topologi sebelumnya adalah menambahkan server untuk database. Setelah anda berhasil mengatasi load pada web server bisa jadi anda mengalami masalah traffic ke database server yang tidak mampu dihandle oleh database server. Untuk itu anda bisa menambahkan 1 lagi database server dan disinkronisenya dengan database server yang sudah ada. Nantinya load ke database server bisa dibagi resourceny dengan lebih baik.

5. Multi Load balancer

Untuk melengkapi kekurangan topologi nomer 4 bisa digunakan 2 load balancer sebagai backup. Jadi ketika load balancer mengalami kegagal secara otomatis load balancer cadangan akan bekerja menggantikan load balancer primary. tentunya perlu konfigurasi di sisi DNS untuk mengirimkan request ke load balancer cadangan apabila load balancer utama mati.

Sekian tulisan dari saya semoga bermanfaat dan bisa diaplikasikan sebagai rencana pengembangan infrastruktur web applikasi yang anda miliki.