Mở rộng datastore của Slack bằng Vitess

• Câu chuyện Slack chuyển từ kiến trúc cụm Active-Active sang Vitess, hệ thống mở rộng ngang cho MySQL

• Bắt đầu di chuyển từ năm 2017, hiện Vitess đang xử lý 99% tổng số truy vấn, dự kiến hoàn tất chuyển đổi hoàn toàn vào cuối năm

→ Hiện tại ở mức đỉnh điểm là 2,3 triệu QPS (2 triệu đọc, 300 nghìn ghi)

→ Độ trễ truy vấn trung vị là 2ms, độ trễ truy vấn p99 là 11ms

• Slack khởi đầu với stack LAMP (Linux, Apache, MySQL, PHP)

• 3 cụm DB

→ Shard: toàn bộ dữ liệu người dùng như tin nhắn, kênh, DM... được phân vùng theo workspace ID, nên một workspace sẽ nằm trong một shard

Tức là ứng dụng Slack chỉ cần kết nối tới một DB duy nhất

→ Cụm metadata: bảng tra cứu để ánh xạ workspace tới shard

→ Cụm kitchen sink: lưu mọi dữ liệu không dành cho một workspace cụ thể. Như thư mục App

• Việc sharding được "webapp" nguyên khối quản lý và điều phối

• Mỗi cụm bao gồm một hoặc nhiều shard, và mỗi shard được cấp phát với ít nhất 2 instance MySQL nằm ở các datacenter khác nhau

• Ưu điểm của cấu hình Active-Active

→ Tính sẵn sàng cao

→ Tốc độ phát triển sản phẩm nhanh

→ Dễ debug

→ Dễ mở rộng

Tuy nhiên, khi tổ chức lớn dần và các nhóm sản phẩm bắt đầu xây dựng tính năng mới, tốc độ phát triển bị chậm lại

• Nhược điểm của Active-Active

→ Giới hạn mở rộng: khi các khách hàng lớn hơn tham gia, hệ thống chạm tới giới hạn mà các host hiệu năng cao có thể đáp ứng

→ Bị cố định vào một mô hình dữ liệu:

Khi có các tính năng như Enterprise Grid và Slack Connect, điều này đi ngược lại với mô hình chỉ kết nối tới một máy chủ duy nhất

→ Hotspot: không tận dụng tốt toàn bộ fleet cơ sở dữ liệu. Khó tách shard và di chuyển nhóm, khó dự đoán mức sử dụng Slack nên đa số shard bị cấp phát quá mức, khiến khó tận dụng phần đuôi dài

→ Vấn đề về tính sẵn sàng của workspace và shard: nếu shard gặp sự cố thì mọi khách hàng trên shard đó đều không thể dùng Slack

→ Vận hành: do đây không phải cấu hình MySQL thông thường nên đã phải viết rất nhiều công cụ nội bộ.

• Mùa thu năm 2016, họ đã quản lý hàng trăm nghìn truy vấn MySQL mỗi giây và hàng nghìn host MySQL được sharding

• Thường xuyên gặp vấn đề về mở rộng và hiệu năng nên bắt đầu tìm cách tiếp cận mới

• Họ cân nhắc việc phát triển tiếp hệ thống hiện có hoặc đưa vào một sản phẩm mới, nhưng

→ Vẫn muốn tiếp tục dùng MySQL chạy trên cloud riêng

→ Có hàng nghìn truy vấn đặc thù, trong đó một số tận dụng cấu hình MySQL đặc biệt

→ Triển khai, sao lưu, ETL cho data warehouse, tuân thủ... đều dựa trên MySQL

• Vì sao là Vitess? : đáp ứng phần lớn yêu cầu của ứng dụng/vận hành

→ MySQL Core: Vitess dựa trên MySQL

→ Scalability: kết hợp các tính năng chính của MySQL với khả năng mở rộng của DB NoSQL. Nhờ sharding tích hợp sẵn, có thể mở rộng linh hoạt mà không cần thêm logic đặc biệt

→ Operability: tự động xử lý các tác vụ như failover và backup mặc định. Theo dõi metadata về cấu hình cụm để duy trì tính nhất quán

→ Extensibility: mã nguồn mở dựa trên Go. Có độ bao phủ kiểm thử rộng và cộng đồng nhà phát triển cởi mở

• Bắt đầu áp dụng Vitess vào thực tế từ những tính năng nhỏ

→ Năm 2017 thử xây dựng tính năng tích hợp RSS feed vào kênh Slack

→ Năm 2018, mọi bảng mới đều chỉ được tạo trên Vitess

→ Đến giữa năm 2019, số lượng ghi trên Vitess đã nhiều hơn DB legacy

→ Và Slack tiếp tục đóng góp cho mã nguồn mở Vitess

→ Trong 3 năm đã chuyển 99% sang Vitess. 1% còn lại sẽ hoàn tất trong năm nay

• Việc Slack áp dụng Vitess có thành công không?

→ Nhiều cụm Vitess tại nhiều khu vực trên thế giới đang vận hành hàng chục keyspace

→ Keyspace là các tập hợp logic mở rộng theo số lượng người dùng/đội nhóm/kênh

→ Sharding linh hoạt giúp Slack có thể mở rộng

→ Do COVID-19, số lượng truy vấn của Slack tăng 50% chỉ trong một tuần

→ Họ mở rộng ngang keyspace bận rộn nhất bằng workflow split của Vitess

→ Nếu là trước đây thì việc scale như vậy là không thể và có lẽ đã xảy ra downtime

[xguru]

https://vitess.io/

Vitess: "Sharding Middleware for MySQL"

• Giải pháp được tạo ra để có thể dễ dàng triển khai/mở rộng quy mô/quản lý MySQL và MariaDB trên đám mây

• Vận hành và quản lý các shard MySQL trên Docker (cục bộ) và Kubernetes

• Ứng dụng có thể sử dụng bằng cách giao tiếp với proxy tên là VTGate giống như đang giao tiếp với MySQL, còn bên trong thì kết nối tới các máy chủ khác qua gRPC

[xguru]

Dịch vụ email Hey cũng đang sử dụng Vitess

Tech stack của Hey: https://vi.news.hada.io/topic?id=2355