Arsitektur Aplikasi dan Infrastruktur: Tantangan dan Solusi (1)

• July 13, 2016
• Dian Boyke
• 1 comment

Arsitektur Aplikasi dan Infrastruktur: Beberapa waktu lalu saya menemukan slide yang berisikan perkembangan infrastruktur di Tokopedia dari waktu ke waktu. Dari desain stack yang sangat sederhana dengan hanya terdiri Webserver dan Database saja untuk mewadahi aplikasi monolitik mereka, sampai merombak arsitektur ke arah yang lebih kompleks dengan tujuan agar sistem tetap mampu melayani traffic mereka yang besar.

Disini saya akan berbicara lebih dalam mengenai bagaimana arsitektur aplikasi dan infrastruktur dapat menyelesaikan banyak persoalaan di dunia digital, terutama pada layanan website. Pada contoh kasus di Tokopedia, kita dapat melihat bawah kebutuhan scaling sejalan dengan kebutuhan yang semakin meningkat.

Dan pada implementasinya, scaling arsitektur adalah sebuah proses, melalui banyak tahapan yang disesuaikan dengan kebutuhan dan kondisi pada saat itu. Dan semua itu melibatkan banyak faktor, diantaranya adalah:

• Kesesuaian arsitektur aplikasi dengan arsitektur infrastruktur
• Alokasi dana untuk implementasi scaling
• Load yang semakin meningkat (jumlah pengunjung, internal processing, kompleksitas)
• Kebutuhan service yang spesifik sehingga memaksa menggunakan stack teknologi yang berbeda-beda

Mari kita bahas satu persatu dengan mencotoh dari website-website yang populer berikut ini.

Disclaimer: Semua yang materi disini berdasarkan informasi yang didapatkan di lapangan, dan ditulis hanya untuk tujuan sharing-knowledge. Dengan mempertimbangkan hal-hal security dan informasi yang credential maka setiap materi tidak akan dijelaskan secara detail, dan beberapa stack teknologi akan disamarkan.

Tokopedia

Dari slide yang dipaparkan oleh tim Tokopedia, terlihat bahwa mereka melakukan scaling secara bertahap. Mulai dari memisahkan proses antara konten dinamis dengan statis, dilanjut dengan memisahkan antara Database untuk write dengan yang befungsi untuk read, kemudian menggunakan teknologi untuk kebutuhan yang lebih khusus, dalam hal ini adalah menggunakan Solr sebagai search engine mereka, dan beberapa penyesuaian-penyesuaian lainnya yang telah mereka berhasil terapkan.

Apa yang dilakukan oleh Tokopedia dalam melakukan tahapan scaling patut untuk dicontoh oleh startup lainnya yang baru mulai merintis dan menghadapi load yang semakin meningkat. Mulai dengan scaling di layer aplikasi, kemudian layer distribusi, sampai ke layer data.

Wikipedia

By Logo and trademark of the Wikimedia foundation, designed by Wikipedia user “Neolux” (SVG version created by DarkEvil, revised by Philip Ronan and optimized by Zscout370 and Artem Karimov) – Wikimedia Foundation website logo converted to SVG., Public Domain, https://commons.wikimedia.org/w/index.php?curid=1443256

Yang saya ingin fokuskan disini adalah dibagian frontend yang bertanggung jawab dalam mendistribusikan konten ke pengakses.

Wikipedia distribution layer

Karakteristik: Sebagian besar load Wikipedia berasal dari traffic untuk membaca konten (proses baca database) ketimbang pengunjung yang memasukan atau meng-update konten (proses tulis database).

Arsitektur: Dengan karakteristik tersebut, Wikipedia menggunakan caching di layer distribution. Jadi distribusi konten tidak melalui web server melainkan mereka menggunakan proxy untuk melakukan cache halaman-halamannya. Alhasil, proses di database tidak akan tinggi, dan load server menjadi lebih aman.

Revive / OpenX / OpenAds

Arsitektur Revive

Revive atau pernah dikenal dengan nama OpenX dan OpenAds, adalah aplikasi ad management yang berbasis Php dan Mysql. Menyedikan fitur-fitur untuk mengelola inventori iklan di website, berikut dengan statistik Impression, Click, CPC dan fitur lainnya.

Karakteristik: Load pada aplikasi akan lebih besar untuk proses pencatatan log dan statistik (proses tulis database), ketimbang proses membaca inventory iklan (proses baca database). Bahkan proses yang terjadi di aplikasi ini mencapai n kali dari proses website utama. Apabila kita memiliki 5 banner dalam satu halaman static yang memiliki real time user sebanyak 1000 request, maka load di aplikasi ad management ini sebesar 5 x 1000 = 5000 request, atau sebanyak 5x dari halaman tersebut.

Arsitektur: Revive memisahkan aplikasi menjadi dua bagian utama, yakni bagian administrasi dan bagian distribusi. Pada bagian administrasi tidak memerlukan spesifikasi server yang besar, karena halaman ini hanya diakses oleh personil ad serving, atau klien yang membutuhkan report. Dibagian ini menggunakan database replikasi yang berfungsi sebagai master. Dimana semua konfigurasi aplikasi, inventory, fitur disimpan di database master, dan kemudian di distribusikan ke database-database slave.

Sedangkan pada bagian distribusi yang bertugas untuk menampilkan iklan dan mencatat data statistik, semua dilakukan secara independent di masing-masing server. Jadi di setiap server terdapat aplikasi Revive yang terhubung langsung dengan database slave yang terdapat di localhost masing-masing. Dengan pendekatan ini maka load traffic ke database yang bertugas untuk mencatat log (proses tulis database) akan terisolir ke masing-masing server, yang efeknya akan mengurangi load server database.

Dan setiap interval waktu tertentu, masing-masing server distribusi tersebut akan menjalankan crond yang berfungsi untuk mengirim akumulasi data statistik ke database master. Dengan catatan, table statistik tersebut tidak dimasukan kedalam table replikasi (exclude) untuk menghindari error duplicate entry pada replikasi database.

Pada bagian kedua kita akan membahas bagaimana pengaplikasian di website-website besar di Indonesia seperti Kompas.com, Detik.com, Mataharimall.com dan Kompasiana.com. Penasaran? silahkan lanjut baca di link ini.