5 poin oleh GN⁺ 2025-12-14 | Belum ada komentar. | Bagikan ke WhatsApp
  • Twilio Segment sempat mengoperasikan ratusan arsitektur mikroservis, tetapi beralih ke layanan tunggal (monolitik) karena kompleksitas dan beban pemeliharaan
  • Pada awalnya, mereka memisahkan setiap Destination API untuk mendapatkan isolasi gangguan dan skalabilitas, tetapi saat jumlah layanan bertambah menjadi lebih dari 140, overhead operasional meningkat tajam
  • Pengelolaan banyak repositori dan pustaka bersama menjadi sulit, dan saat pengujian serta deployment dilakukan, muncul masalah yang memengaruhi seluruh layanan
  • Untuk mengatasinya, mereka mengadopsi sistem Centrifuge dan struktur monorepo, serta membangun Traffic Recorder untuk otomatisasi pengujian
  • Hasilnya, kecepatan pengembangan dan stabilitas meningkat signifikan, dan Twilio Segment kini mempertahankan struktur monolitik demi produktivitas dan efisiensi operasional

Adopsi mikroservis dan batasannya

  • Twilio Segment mengadopsi arsitektur mikroservis untuk infrastruktur data pelanggan, dengan rancangan agar setiap layanan berdasarkan tujuan memproses event secara independen
    • Mengirimkan data ke ratusan server-side destinations (misalnya Google Analytics, Optimizely, dan lain-lain)
    • Pada awalnya mereka menggunakan satu antrean, tetapi ketika destination tertentu mengalami gangguan, muncul masalah head-of-line blocking yang menyebabkan keterlambatan menyeluruh
  • Untuk mengatasinya, mereka membuat layanan dan antrean terpisah untuk tiap destination, sehingga tercapai isolasi gangguan dan penskalaan independen
  • Namun, seiring bertambahnya jumlah layanan, kompleksitas operasional dan biaya pemeliharaan meningkat drastis, yang berujung pada perlambatan pengembangan dan naiknya tingkat cacat

Masalah repositori terpisah dan pustaka bersama

  • Setiap destination memakai format API yang berbeda sehingga memerlukan kode transformasi kustom
    • Awalnya semua dikelola dalam satu repo, tetapi karena kegagalan pengujian memengaruhi semuanya, mereka kemudian memisahkan repo
  • Setelah lebih dari 50 destination baru ditambahkan, muncul lebih dari 50 repositori
    • Mereka memperkenalkan pustaka bersama untuk fungsi umum, tetapi ketidakcocokan versi dan beban deployment ikut membesar
  • Karena pola beban setiap layanan berbeda, pengaturan autoscaling menjadi sulit, dan dalam beberapa kasus operator harus menyesuaikannya secara manual

Peralihan ke monolitik dan adopsi Centrifuge

  • Mereka memutuskan untuk menggabungkan lebih dari 140 layanan menjadi satu layanan tunggal
    • Untuk menggantikan antrean terpisah, mereka mengembangkan sistem Centrifuge yang mengirimkan semua event ke satu layanan tunggal
    • Centrifuge kemudian berkembang menjadi infrastruktur backend Connections milik Twilio Segment
  • Dengan beralih ke struktur layanan tunggal, mereka berhasil mengurangi beban operasional dan menyederhanakan penanganan gangguan

Monorepo dan otomatisasi pengujian

  • Seluruh kode destination digabungkan ke dalam satu repositori, dan lebih dari 120 dependensi disatukan ke satu versi
    • Pengelolaan versi menjadi lebih sederhana dan efisiensi pemeliharaan meningkat
  • Untuk otomatisasi pengujian, mereka memperkenalkan Traffic Recorder
    • Permintaan dan respons HTTP nyata direkam lalu diputar ulang untuk menghilangkan ketergantungan pada jaringan eksternal
    • Kecepatan pengujian dipangkas dari hitungan menit menjadi milidetik, dengan peningkatan stabilitas yang besar
  • Tingkat kegagalan pengujian menurun, dan produktivitas pengembang meningkat signifikan

Dampak dan trade-off struktur monolitik

  • Setelah digabungkan ke satu layanan, kecepatan deployment dan efisiensi pengembangan meningkat signifikan
    • Dalam 1 tahun, jumlah perbaikan pustaka bersama meningkat dari 32 menjadi 46
    • Satu engineer dapat melakukan deployment dalam hitungan menit
  • Efisiensi operasional juga membaik, sehingga lonjakan beban dapat diserap oleh worker pool berskala besar
  • Namun, tetap ada kelemahan seperti sulitnya isolasi cacat, menurunnya efisiensi cache, dan risiko pembaruan dependensi
    • Sebagian kerugian ini diimbangi oleh kesederhanaan operasional dan peningkatan produktivitas

Kesimpulan

  • Mikroservis menyelesaikan masalah performa pada tahap awal, tetapi kurang cocok untuk skalabilitas besar dan pembaruan massal
  • Peralihan ke monolitik meningkatkan stabilitas operasional dan kecepatan pengembangan sekaligus
  • Untuk transisi yang sukses, diperlukan sistem pengujian yang kokoh dan penerimaan terhadap trade-off
  • Twilio Segment masih mempertahankan mikroservis di sebagian infrastrukturnya, tetapi untuk server-side destinations, monolitik dinilai sebagai struktur yang lebih cocok

Belum ada komentar.

Belum ada komentar.