Cara Discord Meminimalkan Latensi Disk Jaringan

• Mengoperasikan klaster DB NoSQL (ScyllaDB) yang memproses 2 juta pesan per detik
• Faktor yang paling memengaruhi performa DB adalah latensi perangkat keras disk fisik
  → Pada tingkat volume kueri yang rendah hal ini tidak terlalu berpengaruh, tetapi setelah melewati titik tertentu, waktu baca 1–2ms saja sudah cukup menyebabkan antrean pembacaan di disk dan memicu timeout pada kueri itu sendiri
• Latensi disk biasanya berada pada skala mikrodetik, jadi mengapa operasi disk bisa memakan waktu 1–2ms?
• Discord menjalankan sebagian besar perangkat kerasnya di Google Cloud
  • Mendukung Local SSD berbasis NVMe, tetapi dari hasil pengujian internal ada masalah keandalan sehingga tidak cukup meyakinkan untuk dipakai sebagai penyimpanan data penting
  • Persistent Disk dapat dipasang/dilepas ke server secara real time, dapat di-resize tanpa downtime, snapshot bisa dibuat kapan saja, dan secara bawaan dirancang dengan replikasi
    → Masalahnya, disk ini tidak terpasang langsung ke server melainkan terhubung lewat jaringan
• Sekecil apa pun latensi koneksi jaringan lokal, tetap tidak akan lebih rendah daripada PCI/SATA
  → Jaringan berada di kisaran 1–2ms, sedangkan disk yang terhubung langsung sekitar 0.5ms
• Local SSD, seperti HDD, akan kehilangan data di disk tersebut jika terjadi masalah perangkat keras, dan jika host itu sendiri bermasalah maka snapshot pun tidak memungkinkan sehingga bisa berujung pada kehilangan data total
  → Karena itu Discord tidak menggunakan Local SSD, melainkan memakai Persistent Disk

Analisis masalah

• Akan ideal jika ada perangkat penyimpanan yang menggabungkan kelebihan Local SSD dan Persistent Disk, tetapi perangkat seperti itu tidak ada. Bagaimana jika hanya mengambil sebagian kelebihannya?
• Bagi Discord, latensi tulis bukan masalah. Yang memengaruhi performa adalah "latensi baca"
• "Resize disk tanpa downtime" bukan fitur yang wajib. Ukurannya bisa diperkirakan sebelumnya
• Persyaratan akhirnya adalah
  • Tetap berada di GCP
  • Menggunakan snapshot point-in-time untuk backup data
  • Menjadikan minimisasi latensi baca sebagai prioritas tertinggi
  • Tidak mengorbankan jaminan uptime database yang ada
• Akan ideal jika pembacaan memanfaatkan Local SSD milik GCP, sementara penulisan dilakukan ke Persistent Disk
  → Apakah mungkin membuat Super-disk seperti ini di level software?

Membuat Super-Disk

• Pada dasarnya kebutuhannya adalah cache write-through. Menggunakan Local SSD GCP sebagai cache, dan PD sebagai lapisan penyimpanan
• Server DB menggunakan Ubuntu, jadi cache level disk bisa diterapkan di level kernel Linux (modul seperti dm-cache, lvm-cache, bcache)
• Namun dari hasil eksperimen, ketika bad sector muncul di disk cache, seluruh operasi baca gagal
  • Saat bad sector muncul, data seharusnya dibaca dari storage layer lalu ditimpa ulang, tetapi solusi caching disk yang dievaluasi tidak memiliki fungsi semacam ini
  • Ketika bad sector terjadi, database malah shutdown karena masalah integritas data
• Muncul persyaratan tambahan: "harus tetap bertahan meski bad sector terjadi di Local SSD"
• Karena itu mereka meneliti md di kernel Linux
  • md mendukung pembuatan software RAID
  • Hanya melakukan mirroring antara SSD dan PD tidak menyelesaikan masalah, karena lebih dari setengah pembacaan akan tetap berasal dari PD
  • Di md ada fitur write-mostly yang tidak ada pada RAID tradisional
    • Jika disk tertentu ditandai sebagai write-mostly, maka disk itu dikecualikan dari pembacaan normal dan hanya akan dibaca saat tidak ada opsi lain. "Berguna untuk perangkat yang terhubung lambat"
    • Artinya, jika SSD dan PD digabung sebagai RAID1 lalu PD disetel sebagai write-mostly, persyaratan tersebut bisa dipenuhi
• Masalah terakhir yang tersisa adalah ukuran GCP Local SSD yang tetap 375GB
• Untuk aplikasi tertentu, Discord kadang membutuhkan lebih dari 1TB per instance DB
• Karena itu beberapa SSD digabungkan dengan RAID0
• Bentuk akhirnya adalah
  • Empat Local SSD yang digabung dengan RAID0 menjadi md0
  • md0 dan Persistent Disk kemudian digabung sebagai RAID1 untuk membentuk md1

Performa DB

• Hasilnya persis seperti yang diperkirakan
• Bahkan saat puncak, operasi disk tidak menumpuk di antrean, dan latensi kueri tetap tidak berubah
• Ada peningkatan performa sehingga jumlah kueri yang bisa diproses per server ikut meningkat
• Bagi orang yang pernah memakai RAID, mungkin akan muncul keraguan apakah ini "benar-benar bisa berjalan begitu saja?", tetapi kenyataannya ada banyak hal yang terjadi, dan sisanya akan dibahas lebih detail secara terpisah

[eajrezz]

Sebelumnya mereka tampaknya tidak puas dengan performa golang sampai-sampai menulis server dengan rust, jadi menurut saya tingkat ke-geek-an perusahaan Discord juga luar biasa.

[psyrenpark]

Rasanya seperti mencegah masalah kecil dengan solusi yang berlebihan.

[xguru]

Di HN juga ada yang bilang, bukannya ini cuma masalah GCP? sih...
https://news.ycombinator.com/item?id=32474093
Tapi sepertinya bagus juga untuk diketahui sekadar sebagai contoh bahwa percobaan seperti ini juga memungkinkan.