Discord ने नेटवर्क डिस्क की latency को न्यूनतम कैसे किया

• प्रति सेकंड 20 लाख संदेशों को प्रोसेस करने वाला NoSQL DB क्लस्टर (ScyllaDB) चला रहे हैं
• DB performance पर सबसे बड़ा असर physical disk hardware की latency का पड़ता है
  → query volume कम होने पर यह मायने नहीं रखता, लेकिन एक निश्चित बिंदु के बाद केवल 1~2ms का read time भी disk read queue बना देता है और query पर timeout होने लगता है
• disk latency आम तौर पर microsecond स्तर की होती है, फिर disk operation में 1~2ms क्यों लगते हैं?
• Discord अपना अधिकांश hardware Google Cloud पर चलाता है
  • NVMe आधारित local SSD का support है, लेकिन अपने परीक्षणों में reliability की समस्या मिली, इसलिए महत्वपूर्ण data store के लिए इसे निश्चिंत होकर इस्तेमाल करना संभव नहीं था
  • Persistent Disk को server से real-time में attach/detach किया जा सकता है, downtime के बिना resize किया जा सकता है, कभी भी snapshot बनाया जा सकता है, और इसे default रूप से replicated होने के लिए design किया गया है
    → समस्या यह है कि यह server से सीधे जुड़ी नहीं होती, बल्कि network के ज़रिए connected होती है
• local network connection latency कितनी भी कम हो, वह PCI/SATA से कम नहीं हो सकती
  → network पर 1~2ms, सीधे जुड़ी disk पर 0.5ms
• local SSD में HDD की तरह hardware समस्या आने पर उस disk का data खो सकता है, और host में समस्या आने पर snapshot भी संभव नहीं होता, जिससे data पूरी तरह खोने की स्थिति बन सकती है
  → इसलिए Discord Local SSD का उपयोग नहीं करता और Persistent Disk का उपयोग करता है

समस्या का विश्लेषण

• अगर local SSD और Persistent Disk, दोनों के फायदे एक साथ देने वाला storage होता तो सबसे अच्छा होता, लेकिन ऐसा कुछ नहीं है। तो क्या इनके कुछ फायदे ही लिए जा सकते हैं?
• Discord के लिए write latency समस्या नहीं है। performance को प्रभावित करने वाली चीज़ है "read latency"
• "downtime के बिना disk resize" अनिवार्य feature नहीं है। size का पहले से अनुमान लगाया जा सकता है
• अंतिम आवश्यकताएँ थीं
  • GCP पर ही बने रहना
  • data backup के लिए Point-in-Time snapshot का उपयोग
  • read latency को न्यूनतम करना सर्वोच्च प्राथमिकता हो
  • मौजूदा database uptime की गारंटी से समझौता न करना
• अगर read के लिए GCP की Local SSD और write के लिए Persistent Disk का उपयोग किया जाए तो अच्छा लगेगा
  → क्या software स्तर पर ऐसा Super-disk बनाया जा सकता है?

Super-Disk बनाना

• मूल requirement दरअसल Write-Through cache की थी। GCP की local SSD को cache की तरह और PD को storage layer की तरह इस्तेमाल करना था
• DB server पर Ubuntu इस्तेमाल हो रहा था, इसलिए Linux kernel स्तर पर disk-level cache लागू की जा सकती थी (dm-cache, lvm-cache, bcache जैसे modules)
• लेकिन प्रयोग करने पर पता चला कि cache disk में bad sector आने पर पूरा read operation fail हो जाता है
  • bad sector आने पर storage layer से पढ़कर ऊपर से overwrite करना चाहिए, लेकिन जिन disk caching solutions का मूल्यांकन किया गया, उनमें यह सुविधा नहीं थी
  • bad sector आने पर database, data stability की समस्या के कारण shutdown हो जाता था
• इसलिए एक अतिरिक्त requirement जुड़ी: "local SSD में bad sector आने पर भी survive करना चाहिए"
• इसके बाद Linux kernel के md की जाँच की गई
  • md software RAID बनाने का support देता है
  • SSD और PD को mirror करने भर से समस्या हल नहीं होती। क्योंकि आधे से ज़्यादा reads PD से होंगे
  • md में पारंपरिक RAID में न मिलने वाला "write-mostly" विकल्प है
    • किसी disk को write-mostly सेट करने पर उसे सामान्य read में शामिल नहीं किया जाता, और केवल तब पढ़ा जाता है जब कोई दूसरा विकल्प न हो। यह "धीमे कनेक्शन वाले device के लिए उपयोगी" है
    • यानी SSD और PD को RAID1 में बाँधकर, PD को write-mostly पर सेट करने से requirement पूरी हो सकती है
• आख़िरी बची समस्या यह थी कि GCP की Local SSD का आकार ठीक 375GB होता है
• Discord को कुछ applications के लिए प्रति DB instance 1TB से ज़्यादा चाहिए होता है
• इसलिए कई SSD को RAID0 में बाँधने का निर्णय लिया गया
• अंतिम configuration यह थी
  • RAID0 में बँधी 4 local SSD को md0
  • md0 और Persistent Disk को RAID1 में बाँधकर md1 तैयार किया गया

DB performance

• परिणाम बिल्कुल अपेक्षा के अनुसार आए
• peak पर भी disk operations queue में नहीं जमा हुए, और query latency में बदलाव नहीं आया
• performance बेहतर हुई, जिससे प्रति server संभाली जाने वाली queries की संख्या बढ़ गई
• जिन लोगों ने RAID इस्तेमाल किया है, उन्हें शायद यह शक हो कि "क्या यह बस ऐसे ही काम कर जाएगा?", लेकिन वास्तव में इसमें कई तरह की घटनाएँ हुईं, और बाकी विवरण बाद में अलग से साझा किए जाएँगे

[eajrezz]

पहले golang की performance से संतुष्ट न होकर अगर वे server भी rust में लिखते दिखते हैं, तो लगता है कि Discord कंपनी की geekness भी काफ़ी शानदार है।

[psyrenpark]

लगता है जैसे जिसे बलगम से रोकना चाहिए था, उसे कुदाल से रोकने की कोशिश की गई हो।

[xguru]

HN में यह बात भी कही गई है कि क्या यह बस GCP की समस्या नहीं है?..
https://news.ycombinator.com/item?id=32474093
लेकिन इतना जानकर रखना अच्छा लगता है कि इस तरह की कोशिश भी संभव है.