Vitess का उपयोग करके Slack के datastore का scaling

• Slack ने Active-Active क्लस्टर संरचना से MySQL horizontal scaling सिस्टम Vitess पर जाने की कहानी साझा की

• 2017 से migration शुरू हुआ और अब Vitess कुल queries का 99% संभाल रहा है, साल के अंत तक पूरी तरह migration पूरा होने की योजना है

→ फिलहाल peak पर 23 लाख QPS (20 लाख read, 3 लाख write)

→ query latency का median 2ms, p99 query latency 11ms

• Slack की शुरुआत LAMP stack (Linux, Apache, MySQL, PHP) से हुई

• 3 DB clusters

→ Shard: messages, channels, DM आदि सभी user data. इसे workspace ID के आधार पर partition किया गया है, इसलिए एक workspace एक shard में रहता है

यानी Slack app को केवल एक DB से connect करना पड़ता है

→ Metadata cluster: workspace को shard से जोड़ने के लिए lookup table

→ Kitchen sink cluster: ऐसा सारा data जो किसी खास workspace के लिए नहीं है. जैसे App directory

• Sharding को monolith "webapp" manage और coordinate करता था

• हर cluster एक या उससे अधिक shards से बना था, और हर shard को अलग data center में मौजूद कम-से-कम 2 MySQL instances के साथ provision किया गया था

• Active-Active setup के फायदे

→ high availability

→ तेज product development speed

→ आसान debugging

→ आसान scaling

लेकिन, जैसे-जैसे संगठन बड़ा हुआ और product teams ने नए features बनाने शुरू किए, development की speed धीमी पड़ने लगी

• Active-Active की कमियां

→ scaling की सीमा: बड़े customers आने लगे तो high-performance hosts की capacity limit सामने आने लगी

→ एक ही data model में बंध जाना:

Enterprise Grid और Slack Connect जैसे features आने पर यह उस paradigm के खिलाफ गया जिसमें केवल एक server से connect किया जाता है

→ hotspots: database fleet का बेहतर उपयोग नहीं हो पा रहा था. shards को split करना और teams को move करना मुश्किल था, और Slack usage का अनुमान लगाना कठिन था, इसलिए ज़्यादातर shards को overprovision किया गया था और long tail का लाभ लेना मुश्किल था

→ workspace और shard availability की समस्या: अगर shard में समस्या आए तो उस shard के सभी customers Slack इस्तेमाल नहीं कर पाते

→ operations: यह सामान्य MySQL configuration नहीं थी, इसलिए बहुत सारे internal tools लिखने पड़े

• 2016 की शरद ऋतु तक, वे प्रति सेकंड कई लाख MySQL queries और हज़ारों sharded MySQL hosts manage कर रहे थे

• उन्हें नियमित रूप से scaling और performance समस्याओं का सामना करना पड़ता था, इसलिए उन्होंने नए approach के बारे में सोचना शुरू किया

• उन्होंने मौजूदा सिस्टम को आगे बढ़ाने या नया product अपनाने पर विचार किया, लेकिन

→ वे अपने private cloud में चल रहे MySQL का उपयोग जारी रखना चाहते थे

→ उनके पास हज़ारों unique queries थीं, जिनमें से कुछ special MySQL configurations का उपयोग करती थीं

→ deployment, backup, data warehouse ETL, compliance आदि सब MySQL पर आधारित थे

• Vitess क्यों? : यह app और operations की ज़्यादातर requirements पूरी करता था

→ MySQL Core: Vitess, MySQL पर आधारित है

→ Scalability: यह MySQL की मुख्य capabilities और NoSQL DB की scalability को जोड़ता है. built-in sharding की वजह से बिना खास logic जोड़े flexible scaling संभव है

→ Operability: failover और backup जैसी चीज़ों को default रूप से automate करता है. cluster configuration के metadata को track करके consistency बनाए रखता है

→ Extensibility: Go-आधारित open source. व्यापक test coverage और खुला developer community

• छोटे features से Vitess को production में लागू करना शुरू किया गया

→ 2017 में RSS feed को Slack channels में integrate करने वाला feature बनाया गया

→ 2018 में सभी नई tables केवल Vitess पर बनाई गईं

→ 2019 के मध्य तक legacy DB की तुलना में Vitess पर अधिक writes होने लगीं

→ और Slack ने Vitess open source में लगातार योगदान दिया

→ 3 साल में 99% migration Vitess पर पूरा हुआ. इस साल के भीतर बाकी 1% भी पूरा होने वाला है

• क्या Slack का Vitess अपनाना सफल रहा?

→ दुनिया के कई regions में कई Vitess clusters दर्जनों keyspaces चला रहे हैं

→ keyspace एक logical collection है जो users/teams/channels की संख्या के अनुसार scale होता है

→ flexible sharding की मदद से Slack को scale करना संभव हुआ

→ COVID-19 के दौरान Slack की queries की संख्या एक हफ्ते में 50% बढ़ गई

→ सबसे व्यस्त keyspace को Vitess के split workflow का उपयोग करके horizontally scale किया गया

→ पहले ऐसा होता तो scaling संभव नहीं होती और downtime होता

[xguru]

https://vitess.io/

Vitess : "MySQL के लिए Sharding Middleware"

• MySQL और MariaDB को cloud में आसानी से deploy/scale/manage करने के लिए बनाया गया solution

• Docker (local) और Kubernetes के ऊपर MySQL shard को चलाना और manage करना

• application, VTGate नाम के proxy को ऐसे इस्तेमाल कर सकती है जैसे वह MySQL से communicate कर रही हो, और अंदरूनी तौर पर यह gRPC के जरिए दूसरे servers से connect होने का तरीका है

[xguru]

ईमेल सेवा Hey भी Vitess का उपयोग कर रही है

Hey का तकनीकी स्टैक https://hi.news.hada.io/topic?id=2355