Blog

SIRCLO Talk @East Ventures Hive: Scalable Architecture for SaaS Product

Akhir pekan lalu, East Ventures Hive mengundang Chief Technology Officer SIRCLO, Leontius Pradhana, untuk mengisi sesi knowledge sharing dari serangkaian Tech Talk series yang diadakan secara berkala. Pada acara berikut, Leontius (akrab disapa Leon) berbagi wawasan mengenai teknologi di balik SIRCLO, atau pengalamannya dalam scaling arsitektur SIRCLO untuk aplikasi SaaS (Software-as-a-Service) sehingga dapat menampung dan maintain ribuan toko online yang terus berkembang dalam jumlah angka maupun trafik.

Dari sesi tersebut, ia membagi topik pembahasannya menjadi 4;
1. Karakteristik SaaS;
2. Evolusi arsitektur SIRCLO;
3. Evolusi infrastruktur SIRCLO, dan;
4. Menghadapai proses migrasi datacenter.
Simak pokok pembahasannya di bawah ini!

1. Tentang SaaS dan karakteristiknya
Apa itu SaaS?

Dikutip dari Wikipedia, SaaS merupakan model lisensi dan penyampaian software, di mana software dilisensikan
secara subscription dan di-host secara terpusat oleh vendor. Beberapa contoh SaaS yang kita kenali di antaranya adalah SalesForce, Dropbox, Zendesk dan Google (Apps).

Karakteristik Saas:

  • Produk di-host oleh Vendor: Semua aspek di-control oleh vendor, termasuk data, update, testing, network dan konfigurasi.
  • Setiap user relatif independen terhadap satu sama lain: Tiap user dapat melakukan scale up secara independen, di mana perubahan tersebut tidak akan berpengaruh pada network (no network effect). Contohnya, seorang user Zendesk biasanya tidak berinteraksi sama sekali dengan user Zendesk lainnya saat menggunakan platform.

2. Arsitektur SIRCLO

SIRCLO sekarang merupakan sebuah aplikasi PHP dengan desain yang bersifat monolithicBeberapa komponennya saat ini sedang dalam proses re-factoring sehingga menjadi lebih service-oriented (misalnya authentication, shipping information). Monolithic dan microservice sendiri bukan 1 dan 0, melainkan sebuah spektrum.
Adapun perbedaan antara monolithic dan service-oriented/microservices sebagai beikut:
Monolithic Service-oriented Microservices
Kecepatan implementasi/development lebih cepat (tidak perlu bingung urusan wire protocol, network latency, dll). Implementasi lebih kompleks (minimal butuh wire protocol, API definition yang lengkap).
Development dilakukan secara menyeluruh. Development setiap servis dapat dilakukan secara independen asal tidak mengubah API.
Perubahan cross-cutting concerns lebih mudah. Perubahan cross-cutting concerns lebih sulit.
Deployment lebih mudah karena hanya ada 1 moving part. Deployment lebih sulit karena banyak moving parts, dan semuanya harus dihubungkan satu sama lain.
Performance mudah terprediksi. Performance tiap service berbeda-beda, wire protocol dapat mempengaruhi performance.
Seluruh aplikasi harus di-scale secara bersamaan. Tiap service dapat di-scale secara independen.

 
3. Evolusi Infrastruktur SIRCLO
Beberapa masalah yang dihadapi antara lain:

  • Kesulitan dalam reproduksi appserver karena deployment tidak terdokumentasi: beberapa URL / endpoint butuh waktu yang lama untuk debugging.
  • Database menjadi bottleneck: “SELECT * FROM session WHERE session_id = ?” bisa menjadi slow query.
  • Performance glusterFS tidak terkendali; CPU utilization terlalu tinggi.

Untuk itu, dibutuhkan vendor-provided load balancer : HAProxy

  • Endpoint / URL tertentu dapat dipoint ke appserver baru (unstable), sedangkan yang lain point ke appserver lama (stable).
  • Misalnya untuk SIRCLO, kita pernah membuat appserver khusus yang hanya dipakai oleh toko tertentu.
  • Biaya bisa jadi lebih tinggi dengan me-maintain HAProxy sendiri.

HAProxy ACL

Pointing URL (atau domain / subdomain tertentu) ke downstream server tertentu. Untuk kasus tertentu, fitur ini bisa menghindari early refactoring (untuk menjadi lebih service-oriented).

Kegunaan HAProxy ACL

  • Migrasi domain / subdomain / API endpoint tertentu dari 1 instance ke instance yang lain, atau dari monolithic ke service yang baru.
  • Load balancing untuk domain / subdomain / API endpoint tertentu, walaupun aplikasi masih bersifat monolithic.
    • Tentunya endpoint harus menggunakan HTTP atau websocket.
  • Semua aspek di atas dapat dilakukan tanpa downtime.
  • Load balancing akan sulit dilakukan jika application state / data tier terlalu terikat dengan business logic / logic tier.

Apa yang terjadi kalau HAProxy mati / butuh direstart?

  • HAProxy melayani public IP secara langsung…
  • Solusi:
    • Nyalakan instance HAProxy yang baru lalu point Elastic IP ke instance yang baru
    • Gunakan ELB di atas HAProxy?

“Bare metal” app deployment : docker

  • Kesulitan untuk reproduce appserver (terlalu banyak moving parts).
  • Pilihan solusi:
    • Dokumentasi deployment
    • Tulis ansible playbook
    • Buat docker image
  • Appserver bersifat stateless.
4. The Great Migration

Beberapa bulan lalu SIRCLO melakukan proses migrasi server dari Softlayer ke Amazon Web Services (AWS). Prosesnya antara lain:

  • Set up seluruh cluster di AWS
  • Untuk setiap toko:
    • Set toko ke “Maintenance mode”
    • Stream database dari legacy ke AWS: mysqldump -u username -p -h legacydbhost database | ssh awsdb mysql -u username -p -h awsdbhost
    • Unset “maintenance mode” toko di AWS
    • Set HAProxy di semua datacenter untuk menggunakan appserver di AWS (menggunakan “-f” flag (load patterns from a file)
    • Point DNS ke HAProxy yang baru di AWS
  • Matikan cluster di legacy datacenter kecuali HAProxy
  • Setelah semua domain ter-propagate DNSnya, matikan HAProxy di legacy datacenter.

Monitoring

  • Monitoring dilakukan melalui munin
    • Pros: banyak grafik
    • Cons: terlalu banyak grafik
  • Sebab & akibat
    • Traffic meningkat -> disk utilization database tinggi
    • Reserved IOPS habis -> IOWAIT meningkat -> Redis number of connected clients meningkat
  • Selengkapnya dapat dilihat di sini.


/etc/hosts -> internal DNS server : consul

  • Problem: service discovery – di mana letak (IP, port) sebuah service?
  • Solusi:
    • /etc/hosts
    • Ansible playbook atau script yang menulis / etc / hosts
    • Internal DNS server
    • consul

Consul

  • Distributed DNS server
  • Service registration
  • Tidak ada SPOF
  • Merangkap sebagai lightweight eventing / messaging system

Konklusi

  • Dengan menggunakan HTTP, tools seperti HAProxy dapat di-leverage untuk “menunda” rewrite / refactoring.
  • Fleksibilitas lebih besar dengan menggunakan infra roll-your-own, tetapi biaya lebih tinggi.

To SIRCLO, the success of your online business is a priority.

Start your success story now!