Penskalaan datastore Slack dengan Vitess

• Kisah Slack beralih dari arsitektur klaster Active-Active ke Vitess, sistem penskalaan horizontal MySQL

• Migrasi dimulai pada 2017, dan kini Vitess menangani 99% dari seluruh kueri; migrasi penuh direncanakan selesai pada akhir tahun

→ Saat ini pada puncaknya mencapai 2,3 juta QPS (2 juta baca, 300 ribu tulis)

→ Median latensi kueri adalah 2 ms, dan latensi kueri p99 adalah 11 ms

• Slack memulai dengan stack LAMP (Linux, Apache, MySQL, PHP)

• 3 klaster DB

→ Shard: semua data pengguna seperti pesan, kanal, DM, dan lain-lain. Dipartisi berdasarkan workspace ID sehingga satu workspace berada di satu shard

Artinya aplikasi Slack hanya perlu terhubung ke satu DB saja

→ Klaster metadata: tabel lookup untuk menghubungkan workspace ke shard

→ Klaster kitchen sink: menyimpan semua data yang tidak khusus untuk workspace tertentu, seperti direktori App

• Sharding dikelola dan dikoordinasikan oleh monolit webapp

• Setiap klaster terdiri dari satu atau lebih shard, dan tiap shard diprovisikan dengan setidaknya dua instance MySQL yang berada di data center berbeda

• Kelebihan konfigurasi Active-Active

→ Ketersediaan tinggi

→ Kecepatan pengembangan produk yang tinggi

→ Debugging yang mudah

→ Skalasi yang mudah

Namun, seiring organisasi membesar dan tim produk membuat fitur baru, kecepatan pengembangan mulai melambat

• Kekurangan Active-Active

→ Batas skalabilitas: saat pelanggan yang lebih besar masuk, sistem mencapai batas yang bisa ditangani host berperforma tinggi

→ Terikat pada satu model data:

Dengan hadirnya fitur seperti Enterprise Grid dan Slack Connect, paradigma hanya terhubung ke satu server menjadi tidak memadai

→ Hotspot: armada database tidak dimanfaatkan dengan baik. Sulit membagi shard dan memindahkan tim, penggunaan Slack juga sulit diprediksi sehingga sebagian besar shard diprovisikan berlebihan, membuat long tail sulit dimanfaatkan

→ Masalah ketersediaan workspace dan shard: jika ada masalah pada shard, semua pelanggan di shard itu tidak bisa menggunakan Slack

→ Operasional: karena konfigurasinya bukan konfigurasi MySQL umum, banyak alat internal harus dibuat

• Pada musim gugur 2016, Slack mengelola ratusan ribu kueri MySQL per detik dan ribuan host MySQL yang sudah di-shard

• Secara rutin mengalami masalah skalabilitas dan performa sehingga mulai memikirkan pendekatan baru

• Mereka mempertimbangkan mengembangkan sistem lama atau mengadopsi produk baru, tetapi

→ Tetap ingin menggunakan MySQL yang berjalan di cloud milik sendiri

→ Memiliki ribuan kueri unik, dan beberapa di antaranya menggunakan konfigurasi MySQL khusus

→ Deployment, backup, ETL data warehouse, kepatuhan, dan lainnya semuanya berbasis MySQL

• Mengapa Vitess? Karena memenuhi sebagian besar kebutuhan aplikasi dan operasional

→ MySQL Core: Vitess berbasis MySQL

→ Scalability: menggabungkan fitur utama MySQL dengan skalabilitas DB NoSQL. Dengan sharding bawaan, sistem bisa diskalakan secara fleksibel tanpa perlu menambahkan logika khusus

→ Operability: secara otomatis menangani failover dasar, backup, dan sebagainya. Ia juga melacak metadata untuk konfigurasi klaster agar konsistensi tetap terjaga

→ Extensibility: open source berbasis Go dengan cakupan pengujian luas dan komunitas pengembang yang terbuka

• Penerapan Vitess dimulai dari fitur kecil

→ Pada 2017, mereka mencoba membuat fitur integrasi feed RSS ke kanal Slack

→ Pada 2018, semua tabel baru dibuat hanya di Vitess

→ Pada pertengahan 2019, jumlah write ke Vitess sudah lebih banyak daripada ke DB lama

→ Dan Slack terus berkontribusi ke open source Vitess

→ Selama 3 tahun, 99% sistem telah dipindahkan ke Vitess. Sisa 1% akan diselesaikan tahun ini

• Apakah adopsi Vitess oleh Slack berhasil?

→ Beberapa klaster Vitess di berbagai wilayah dunia kini menjalankan puluhan keyspace

→ Keyspace adalah koleksi logis yang diskalakan berdasarkan jumlah pengguna/tim/kanal

→ Sharding yang fleksibel memungkinkan Slack untuk terus berkembang

→ Saat COVID-19, jumlah kueri Slack meningkat 50% hanya dalam satu minggu

→ Keyspace tersibuk diskalakan secara horizontal menggunakan workflow split milik Vitess

→ Dalam sistem lama, hal seperti itu tidak akan mungkin diskalakan dan kemungkinan akan menimbulkan downtime

[xguru]

https://vitess.io/

Vitess: "Sharding Middleware for MySQL"

• Solusi yang dibuat agar MySQL dan MariaDB dapat dengan mudah di-deploy, di-scale, dan dikelola di cloud

• Mengoperasikan dan mengelola shard MySQL di atas Docker (lokal) dan Kubernetes

• Aplikasi dapat menggunakannya seperti berkomunikasi dengan MySQL melalui proxy bernama VTGate, lalu di dalamnya terhubung ke server lain melalui gRPC

[xguru]

Layanan email Hey juga menggunakan Vitess

Tech stack Hey https://id.news.hada.io/topic?id=2355