- Discord merombak total arsitektur lama berbasis Elasticsearch menjadi desain ulang penuh berbasis Kubernetes untuk mengatasi keterbatasan infrastruktur pencarian yang ada, sekaligus meningkatkan kinerja dan stabilitas pengindeksan pesan secara drastis
- Antrean Redis lama memiliki risiko kehilangan pesan, tetapi digantikan oleh PubSub untuk menjamin pengiriman pesan yang andal, sambil mengelompokkan pesan berdasarkan klaster/indeks agar diproses lebih efisien
- Dengan memperkenalkan arsitektur "cell", beban didistribusikan ke banyak klaster Elasticsearch kecil, sehingga masalah kelebihan beban node dan ketidakmampuan melakukan pembaruan dapat diatasi
- Pesan DM pribadi dan pesan server (guild) kini diindeks ke cell terpisah, menjadi fondasi bagi fitur pencarian seluruh DM yang baru diperkenalkan
- Komunitas superbesar (BFGs) dapat diskalakan melampaui batas maksimum jumlah pesan Lucene melalui cell khusus dan indeks multi-shard
Keterbatasan infrastruktur lama
- Antrean pesan berbasis Redis menjadi bottleneck saat node Elasticsearch mengalami gangguan, dan ada kemungkinan kehilangan pesan
- Klaster besar (200+ node) mencatat tingkat kegagalan pengindeksan hingga 40% hanya karena kegagalan satu node
- Indeks yang mencapai batas
MAX_DOCS Lucene (2 miliar pesan) dapat menyebabkan penghentian total pengindeksan
- Karena sistem sudah menua, bahkan patch log4shell baru bisa diterapkan setelah seluruh sistem dimatikan
Strategi penyelesaian
Membangun ulang berbasis Kubernetes
- Operasional klaster Elasticsearch diotomatisasi dengan memanfaatkan Elastic Kubernetes Operator (ECK)
- Rolling restart, upgrade OS, dan pembaruan perangkat lunak dapat dilakukan dengan aman
Distribusi klaster dengan arsitektur “cell”
- Alih-alih satu klaster besar, kini digunakan banyak klaster kecil yang membentuk satu cell
- Di setiap cell, jumlah indeks dibatasi, dan ukuran shard dijaga di 50GB serta maksimal 200 juta pesan
- Kinerja pengindeksan dan kueri meningkat, sekaligus mengurangi beban menjaga status klaster
Antrean pesan berbasis PubSub
- Peralihan Redis → PubSub memungkinkan pemeliharaan antrean tanpa kehilangan pesan
- Pemanfaatan PubSub juga sedang diperluas ke fungsi lain seperti penjadwalan pekerjaan
Batch indexing per klaster
- Pesan yang diterima lewat PubSub diklasifikasikan berdasarkan klaster dan indeks tujuan, lalu diproses paralel sebagai task terpisah
- Struktur pemrosesan distribusi pesan diimplementasikan dengan tokio task + channel di Rust
Peningkatan fitur pencarian
Pencarian DM berbasis pengguna
- Sebelumnya, DM diindeks per channel sehingga pencarian seluruh DM menjadi tidak efisien
- Kini, pesan DM diindeks ganda ke indeks per pengguna, sehingga semua DM bisa dicari sekaligus
Menangani BFG (Big Freaking Guilds)
- Indeks multi-shard diperkenalkan untuk komunitas superbesar yang melampaui batas jumlah pesan Lucene
- BFG diproses dengan struktur multi-primary-shard di cell Elasticsearch khusus
- Setelah melakukan pengindeksan ganda secara bersamaan ke indeks lama dan indeks baru, target kueri dialihkan secara bertahap
Hasil
- Mengindeks triliunan pesan, dengan throughput pengindeksan 2x lebih tinggi dibanding sebelumnya
- Kecepatan respons kueri: rata-rata 500ms → 100ms, p99 dari 1s → di bawah 500ms
- Lebih dari 40 klaster dan ribuan indeks kini sedang dioperasikan
- Upgrade klaster dan rolling restart kini sepenuhnya otomatis tanpa downtime layanan
4 komentar
Bahwa pekerjaan seperti itu dijalankan sambil tetap beroperasi... saya hormat.
Engineering Discord memang selalu jadi panutan. Saya iri.
Saya sempat bertanya-tanya apa itu pubsub, ternyata itu IaaS yang disediakan oleh GCP.
https://cloud.google.com/pubsub?hl=en
Mengesankan. Termasuk membongkar total demi menyelesaikan masalah.