Bạn có biết Zendesk, công ty phần mềm CRM hàng đầu, đã giải quyết thách thức lưu trữ dữ liệu khổng lồ như thế nào không? Họ đã chuyển từ DynamoDB sang giải pháp kết hợp MySQL và Amazon S3, giúp tiết kiệm tới 80% chi phí! Bài viết này chia sẻ chi tiết về hành trình tối ưu hóa của Zendesk, từ việc thiết kế pipeline dữ liệu đến triển khai các kỹ thuật nâng cao như Bloom Filter và Count-Min Sketch. Nếu bạn quan tâm đến big data, cloud computing hoặc đang tìm cách tối ưu chi phí cho hệ thống của mình, đây chắc chắn là một case study đáng đọc. Hãy cùng khám phá cách Zendesk đạt được hiệu suất cao với chi phí thấp!
Tags: #database, #system desgin
Zendesk là một công ty phần mềm dịch vụ chăm sóc khách hàng (CRM) có trụ sở tại San Francisco, California. Được thành lập vào năm 2007, Zendesk cung cấp một nền tảng dịch vụ chăm sóc khách hàng dựa trên đám mây cho các doanh nghiệp thuộc mọi quy mô.
Các sản phẩm chính của Zendesk bao gồm:
Zendesk phục vụ hàng trăm nghìn khách hàng trên toàn thế giới, từ các startup nhỏ đến các tập đoàn lớn. Với quy mô hoạt động lớn như vậy, Zendesk cần xử lý và lưu trữ một lượng lớn dữ liệu, bao gồm logs sự kiện từ các tương tác của khách hàng trên nền tảng của họ.
Kiến trúc ban đầu của Zendesk như sau:
Đứng trước thách thức này, đội ngũ kỹ thuật của Zendesk bắt đầu tìm kiếm một giải pháp thay thế có thể duy trì hiệu suất cao trong khi giảm đáng kể chi phí vận hành.
Các giải pháp thay thế
Trong quá trình tìm kiếm giải pháp thay thế, Zendesk tập trung vào các công nghệ trong hệ sinh thái AWS, vì đó là nền tảng chính của Zendesk:
Amazon S3:
Apache Hudi kết hợp với Amazon S3:
Elasticsearch:
MySQL:
Cách tiếp cận
Cuối cùng, đội ngũ Zendesk đã quyết định sử dụng một cách tiếp cận kết hợp để tận dụng ưu điểm của các giải pháp. Họ chọn sử dụng MySQL để ghi logs từ Kafka, và định kỳ tải dữ liệu lên S3 để cho phép xóa dữ liệu đó khỏi MySQL nhằm tránh quá tải DB. Những ưu điểm của giải pháp này bao gồm:
Quy trình làm việc được mô tả chi tiết như sau:
metadata, xác định bản ghi cuối cùng đã được tải lên S3.buffer và tải chúng lên một file S3.metadata cho mỗi file S3, lưu trữ đường dẫn S3, số lượng logs trong file, ID log cuối cùng và timestamp cuối cùng được lưu trong file đó.Cấu trúc bảng metadata được định nghĩa như sau:
buffer đã được tải lên, ngoại trừ dữ liệu 5 phút cuối cùng để tránh sự chậm trễ của Kafka gây ra vấn đề về thứ tự.buffer.Truy vấn
Sau khi thiết lập pipeline dữ liệu, câu hỏi đặt ra là liệu hệ thống có thể trả về dữ liệu kịp thời khi client gửi các request API hay không.
Biểu đồ trên so sánh hiệu suất của Aurora (màu vàng) với S3-Select (màu tím) khi truy vấn dữ liệu. Đáng chú ý, S3-Select thể hiện tốc độ ấn tượng, đặc biệt khi xét đến việc mỗi file chỉ chứa 10.000 mục. Hơn nữa, chi phí sử dụng S3-Select rất thấp.
Quy trình truy vấn được mô tả chi tiết như sau:
metadata của MySQL.log_count trong bảng metadata.timestamp là một trường trong JSON được lưu trữ trong file.buffer trong MySQL để bổ sung.Tối ưu hóa
Sau khi triển khai hệ thống cơ bản, đội ngũ Zendesk đã phát hiện một vấn đề về hiệu suất khi khách hàng muốn lọc kết quả bằng các trường khác ngoài timestamp. Ví dụ, khi tìm logs cho một user-id cụ thể, trong trường hợp xấu nhất, hệ thống phải quét tất cả dữ liệu S3 trong phạm vi thời gian để tìm bất kỳ logs nào liên quan, điều này làm cho việc tìm ra những truy vấn nào cần thực hiện song song trở nên khó khăn.
Để giải quyết vấn đề này, họ đã thực hiện một số bước tối ưu hóa:
Quy trình làm việc mới được mô tả như sau:
Cấu trúc dữ liệu mới được lưu trữ trong bảng metadata_bloom_filters:
Phương pháp này cho phép hỗ trợ lọc trên nhiều trường bằng cách kiểm tra các Bộ lọc Bloom tương ứng.
Mặc dù đã cải thiện đáng kể, hệ thống vẫn có thể gặp trường hợp xấu nhất khi nhận được nhiều kết quả giả từ Bộ lọc Bloom. Để giải quyết vấn đề này, Zendesk sử dụng Phân trang dựa trên Con trỏ trong API của họ. Họ cung cấp trường has_more trong phản hồi, cho phép client yêu cầu trang tiếp theo nếu có khả năng còn kết quả trong các file S3 tiếp theo. Trường has_more sẽ được đặt thành false khi không còn file S3 nào để quét trong phạm vi thời gian.
Kết quả của việc chuyển đổi từ DynamoDB sang giải pháp kết hợp MySQL và S3 đã thành công vượt xa mong đợi của đội ngũ Zendesk. Họ đặc biệt ấn tượng với hiệu suất của S3-Select, một công cụ mà ban đầu họ dự đoán sẽ có thời gian phản hồi trong khoảng vài giây. Thực tế, hầu hết các truy vấn chỉ mất khoảng 200-500ms, với một số trường hợp đỉnh điểm lên đến vài giây - một kết quả mà họ tin rằng còn có thể tối ưu hóa thêm bằng cách điều chỉnh số lượng logs trên mỗi file S3. Về mặt tài chính, sự chuyển đổi này đã mang lại lợi ích đáng kể. Chi phí tổng thể của giải pháp mới chỉ bằng chưa đến 20% chi phí trước đây khi sử dụng DynamoDB. Đáng chú ý hơn, trong 20% chi phí này, chỉ có chưa đến 10% là dành cho việc sử dụng kết hợp lưu trữ S3 và S3-Select. Phần còn lại, chiếm hơn 90%, là chi phí cho Aurora - cơ sở dữ liệu MySQL được quản lý của AWS.
Tuy nhiên, khi Zendesk mở rộng quy mô hoạt động, họ nhận ra rằng chi phí sử dụng DynamoDB tăng nhanh chóng. Zendesk đã thử chuyển sang thức thanh toán provisioned billing mode(đặt trước một lượng tài nguyên nhất định và trả phí cố định cho lượng tài nguyên đó, bất có sử dụng hết hay không) của DynamoDB, giúp giảm chi phí khoảng 50%. Tuy nhiên, giải pháp này vẫn không đủ bền vững khi Zendesk tiếp tục mở rộng phục vụ nhiều khách hàng hơn. Đặc biệt, mỗi khi họ muốn cho phép truy vấn trên một trường mới trong logs, phải tạo thêm Global Secondary Indices, làm tăng đáng kể chi phí.