การสเกลดาต้าสโตร์ของ Slack ด้วย Vitess

• เรื่องราวที่ Slack เปลี่ยนจากสถาปัตยกรรมคลัสเตอร์แบบ Active-Active มาใช้ Vitess ซึ่งเป็นระบบสเกลแนวนอนสำหรับ MySQL

• เริ่มย้ายมาตั้งแต่ปี 2017 และตอนนี้ Vitess ประมวลผลคิวรีทั้งหมด 99% แล้ว โดยมีแผนย้ายเสร็จสมบูรณ์ภายในสิ้นปี

→ ปัจจุบันช่วงพีกอยู่ที่ 2.3 ล้าน QPS (อ่าน 2 ล้าน, เขียน 3 แสน)

→ ค่ามัธยฐานของ query latency อยู่ที่ 2ms และ p99 query latency อยู่ที่ 11ms

• Slack เริ่มต้นจากสแตก LAMP (Linux, Apache, MySQL, PHP)

• มี DB คลัสเตอร์ 3 ชุด

→ ชาร์ด: ข้อมูลผู้ใช้ทั้งหมด เช่น ข้อความ แชนเนล DM เป็นต้น ถูกพาร์ทิชันตาม workspace ID ดังนั้นหนึ่งเวิร์กสเปซจะอยู่ในหนึ่งชาร์ด

กล่าวคือ แอป Slack จำเป็นต้องเชื่อมต่อกับ DB เพียงตัวเดียว

→ เมทาดาต้าคลัสเตอร์: lookup table สำหรับเชื่อมเวิร์กสเปซกับชาร์ด

→ คลัสเตอร์ kitchen sink: เก็บข้อมูลทั้งหมดที่ไม่ได้เป็นของเวิร์กสเปซใดโดยเฉพาะ เช่น App directory

• การชาร์ดถูกจัดการและควบคุมโดยโมโนลิทชื่อ "webapp"

• แต่ละคลัสเตอร์ประกอบด้วยชาร์ดตั้งแต่หนึ่งชุดขึ้นไป และแต่ละชาร์ดถูก provision ด้วย MySQL instance อย่างน้อย 2 ตัวที่อยู่คนละดาต้าเซ็นเตอร์

• ข้อดีของการตั้งค่าแบบ Active-Active

→ ความพร้อมใช้งานสูง

→ ความเร็วในการพัฒนาผลิตภัณฑ์สูง

→ ดีบักได้ง่าย

→ ขยายระบบได้ง่าย

แต่เมื่อองค์กรใหญ่ขึ้นและทีมผลิตภัณฑ์เริ่มสร้างฟีเจอร์ใหม่ ความเร็วในการพัฒนากลับช้าลง

• ข้อเสียของ Active-Active

→ ข้อจำกัดด้านการสเกล: เมื่อลูกค้ารายใหญ่ขึ้น ระบบก็เริ่มชนขีดจำกัดที่โฮสต์ประสิทธิภาพสูงจะรองรับได้

→ ติดกับดักของ data model เดียว:

เมื่อมีฟีเจอร์อย่าง Enterprise Grid และ Slack Connect ก็เริ่มขัดกับพาราไดม์ที่เชื่อมต่อกับเซิร์ฟเวอร์เพียงตัวเดียว

→ ฮอตสปอต: ใช้ประโยชน์จาก database fleet ได้ไม่ดี การแยกชาร์ดและย้ายทีมทำได้ยาก และเนื่องจากคาดการณ์ปริมาณการใช้งาน Slack ได้ยาก จึงต้อง provision ชาร์ดส่วนใหญ่เกินความจำเป็น ทำให้ใช้ประโยชน์จาก long tail ได้ยาก

→ ปัญหาความพร้อมใช้งานของเวิร์กสเปซและชาร์ด: ถ้าชาร์ดมีปัญหา ลูกค้าทั้งหมดในชาร์ดนั้นจะใช้งาน Slack ไม่ได้

→ การปฏิบัติการ: เพราะไม่ได้ใช้ MySQL configuration แบบทั่วไป จึงต้องเขียนเครื่องมือภายในจำนวนมาก

• ในฤดูใบไม้ร่วงปี 2016 Slack ดูแล MySQL query หลายแสนรายการต่อวินาที และโฮสต์ MySQL แบบชาร์ดหลายพันเครื่อง

• เจอปัญหาด้านการสเกลและประสิทธิภาพเป็นประจำ จึงเริ่มพิจารณาแนวทางใหม่

• เคยพิจารณาทั้งการพัฒนาระบบเดิมต่อและการนำผลิตภัณฑ์ใหม่มาใช้ แต่มีเงื่อนไขว่า

→ ต้องการใช้ MySQL ที่รันอยู่บนคลาวด์ของตนเองต่อไป

→ มีคิวรีเฉพาะทางหลายพันแบบ และบางส่วนใช้ MySQL configuration พิเศษ

→ ระบบ deploy, backup, data warehouse ETL, compliance ฯลฯ ต่างก็อิงกับ MySQL ทั้งหมด

• ทำไมต้องเป็น Vitess? : เพราะตอบโจทย์ทั้งฝั่งแอปและการปฏิบัติการเป็นส่วนใหญ่

→ MySQL Core: Vitess สร้างอยู่บน MySQL

→ Scalability: ผสานความสามารถหลักของ MySQL เข้ากับความสามารถในการสเกลแบบฐานข้อมูล NoSQL ด้วยการชาร์ดในตัว ทำให้ขยายได้ยืดหยุ่นโดยไม่ต้องเพิ่มลอจิกพิเศษ

→ Operability: จัดการ failover และ backup พื้นฐานให้อัตโนมัติ พร้อมติดตามเมทาดาต้าของการตั้งค่าคลัสเตอร์เพื่อคงความสอดคล้อง

→ Extensibility: เป็นโอเพนซอร์สที่พัฒนาด้วย Go มี test coverage กว้างขวางและมีชุมชนนักพัฒนาแบบเปิด

• เริ่มใช้งาน Vitess จริงจากฟีเจอร์เล็ก ๆ

→ ปี 2017 ทดลองสร้างฟีเจอร์รวม RSS feed เข้ากับ Slack channel

→ ปี 2018 ตารางใหม่ทั้งหมดถูกสร้างบน Vitess เท่านั้น

→ ช่วงกลางปี 2019 ปริมาณการเขียนบน Vitess แซง legacy DB ไปแล้ว

→ และ Slack ก็มีส่วนร่วมกับโอเพนซอร์สของ Vitess อย่างต่อเนื่อง

→ ตลอด 3 ปีที่ผ่านมา ย้ายงาน 99% มายัง Vitess แล้ว และจะเสร็จอีก 1% ที่เหลือภายในปีนี้

• การนำ Vitess มาใช้ที่ Slack ประสบความสำเร็จหรือไม่?

→ ปัจจุบันมี Vitess หลายคลัสเตอร์ในหลายภูมิภาคทั่วโลกที่ดูแลหลายสิบ keyspace

→ keyspace คือคอลเลกชันเชิงตรรกะที่สเกลตามจำนวนผู้ใช้ ทีม และแชนเนล

→ การชาร์ดที่ยืดหยุ่นทำให้ Slack สเกลได้ดีขึ้น

→ ในช่วง COVID-19 จำนวนคิวรีของ Slack เพิ่มขึ้น 50% ภายในเวลาเพียงหนึ่งสัปดาห์

→ keyspace ที่มีงานหนาแน่นที่สุดถูกสเกลแนวนอนด้วย workflow การ split ของ Vitess

→ ถ้าเป็นแต่ก่อน ระบบคงสเกลไม่ไหวและน่าจะเกิด downtime

[xguru]

https://vitess.io/

Vitess: "Sharding Middleware for MySQL"

• โซลูชันที่สร้างขึ้นเพื่อให้สามารถติดตั้ง/ขยายระบบ/จัดการ MySQL และ MariaDB บนคลาวด์ได้อย่างง่ายดาย

• รันและจัดการ MySQL shards บน Docker (โลคัล) และ Kubernetes

• แอปพลิเคชันสามารถใช้งานผ่านพร็อกซีชื่อ VTGate ได้เหมือนสื่อสารกับ MySQL โดยภายในจะเชื่อมต่อไปยังเซิร์ฟเวอร์อื่น ๆ ผ่าน gRPC

[xguru]

บริการอีเมลอย่าง Hey ก็ใช้ Vitess อยู่เช่นกัน

สแต็กเทคโนโลยีของ Hey https://th.news.hada.io/topic?id=2355