Dzmitry Lazerka, Đồng sáng lập VictoriaMetrics – Loạt phỏng vấn

Dzmitry Lazerka, Đồng sáng lập VictoriaMetrics là một kỹ sư phần mềm dày dặn kinh nghiệm và nhà lãnh đạo công nghệ với chuyên môn sâu về học máy, hệ thống dữ liệu quy mô lớn, quan sát khả năng và hạ tầng. Trước khi đồng sáng lập VictoriaMetrics vào năm 2018, ông đã làm việc với vai trò Kỹ sư Học máy tại bộ phận xe tự lái Level 5 của Lyft, nơi ông góp phần phát triển các hệ thống nhận dạng và phân tích các kịch bản lái xe thực tế. Trước đó, ông đã lãnh đạo các dự án học máy và hạ tầng dữ liệu tại Spire Global, từng là đồng sáng lập kỹ thuật tại Bellgram, và làm việc trên các hệ thống dữ liệu và phân tích tại Duetto Research và Google thông qua EPAM Systems. Trong suốt sự nghiệp, Lazerka đã xây dựng và dẫn dắt các dự án bao gồm lái xe tự động, dự báo hàng hải, tìm kiếm, phân tích, xử lý dữ liệu phân tán và các hệ thống backend có khả năng mở rộng cao.

VictoriaMetrics là một công ty quan sát khả năng mã nguồn mở, xây dựng các công cụ để thu thập, lưu trữ, truy vấn và phân tích khối lượng lớn dữ liệu vận hành. Công nghệ của họ bắt đầu với VictoriaMetrics, một cơ sở dữ liệu chuỗi thời gian hiệu năng cao và giải pháp giám sát được thiết kế cho khả năng mở rộng, truy vấn nhanh, lưu trữ hiệu quả và chi phí vận hành thấp, và sau đó đã mở rộng thành một bộ công cụ quan sát toàn diện bao gồm số liệu, log và trace phân tán thông qua VictoriaMetrics, VictoriaLogs và VictoriaTraces. Công ty cũng cung cấp các triển khai doanh nghiệp và đám mây được quản lý hoàn toàn, cùng với khả năng phát hiện bất thường áp dụng học máy vào dữ liệu chuỗi thời gian. Nền tảng của họ hỗ trợ các công nghệ như OpenTelemetry, quy trình tương thích Prometheus, Grafana và Kubernetes, mang lại cho các tổ chức sự linh hoạt để tích hợp VictoriaMetrics vào môi trường quan sát hiện có.

Trước khi đồng sáng lập VictoriaMetrics, bạn đã làm việc trên các hệ thống dữ liệu quy mô lớn, phân tích và học máy tại Google, Spire Global, bộ phận xe tự lái của Lyft và các công ty khởi nghiệp khác. Điều gì cuối cùng đã dẫn bạn thành lập VictoriaMetrics, và những vấn đề nào từ những vai trò trước đó đã thuyết phục bạn rằng việc giám sát và quan sát khả năng cần một cách tiếp cận hoàn toàn khác?

Tôi đã dành cả sự nghiệp của mình làm việc với lượng dữ liệu lớn. Tại Google, Spire, Lyft và các công ty khác, bạn nhanh chóng nhận ra rằng một thứ hoạt động tốt ở một quy mô có thể trở nên tốn kém hoặc khó vận hành ở quy mô khác. Giám sát gặp đúng vấn đề này.

Khi hạ tầng phát triển, bạn tạo ra nhiều số liệu hơn. Bạn thêm nhiều dịch vụ, nhiều instance và nhiều nhãn cho đến khi đột nhiên hệ thống giám sát tự nó cần một lượng hạ tầng đáng kể, điều mà chúng tôi không bao giờ thấy hợp lý. Một hệ thống được thiết kế để giám sát môi trường sản xuất của bạn không nên trở nên phức tạp và tốn kém hơn để vận hành.

Đây là những gì các đồng sáng lập của tôi, Aliaksandr Valialkin và Roman Khavronenko, đã thấy trực tiếp. Họ có kinh nghiệm vận hành Prometheus và gặp phải giới hạn bộ nhớ. Thêm các hệ thống như Thanos đã giải quyết một số vấn đề mở rộng, nhưng cũng đưa vào nhiều thành phần và độ phức tạp vận hành hơn. Và với InfluxDB, chúng tôi đã thấy cách một thay đổi giấy phép có thể ảnh hưởng đến quyết định kỹ thuật sau khi các nhóm đã đầu tư vào công nghệ đó.

Vì vậy, ý tưởng đằng sau VictoriaMetrics mang tính thực tiễn: Liệu chúng ta có thể xây dựng một cơ sở dữ liệu chuỗi thời gian thực hiện cùng một công việc với tài nguyên ít hơn đáng kể và đơn giản hơn trong việc vận hành không?

Chúng tôi không bắt đầu với kế hoạch xây dựng một công ty quan sát khả năng lớn. Chúng tôi bắt đầu bằng việc giải quyết một vấn đề kỹ thuật.

Việc đưa nó thành mã nguồn mở là một phần của điều đó. Các kỹ sư có thể tải xuống VictoriaMetrics, đưa các tải công việc thực tế vào và tự so sánh kết quả. Chúng tôi không cần phải nói với họ rằng nó nhanh hơn hay hiệu quả hơn. Họ có thể đo lường nó.

Đây là cách tốt nhất để xây dựng phần mềm hạ tầng. Nếu công nghệ tốt, các kỹ sư nên có khả năng chứng minh nó bằng chính mình.

Chi phí quan sát khả năng có thể âm thầm trở thành một phần đáng kể trong hóa đơn đám mây của công ty. Những chi phí này thường tăng vọt ở đâu, và các quyết định kiến trúc hoặc mua sắm nào mà các đội kỹ thuật thường mắc phải?

Tôi sẽ xem xét độ đa dạng trước tiên.

Giả sử bạn bắt đầu với một số liệu hợp lý, sau đó thêm một nhãn với các giá trị có thể có. Đột nhiên, một số liệu trở thành hàng ngàn hoặc hàng triệu chuỗi thời gian duy nhất. Hệ thống bây giờ có nhiều dữ liệu hơn để thu thập, lập chỉ mục, lưu trữ và truy vấn, dẫn đến nhu cầu CPU, bộ nhớ và lưu trữ tăng lên.

Phần khó khăn là điều này không xảy ra vì ai đó đưa ra một quyết định sai lầm. Nó diễn ra dần dần. Thêm nhiều dịch vụ, pod K8s, khách hàng và nhãn, và chi phí sẽ nhân lên.

Vấn đề thứ hai là lưu trữ mọi thứ ở cùng độ phân giải và cùng thời gian. Không phải tất cả dữ liệu quan sát khả năng đều có cùng giá trị. Các số liệu bạn cần cho một cảnh báo hoặc SLO khác với dữ liệu đo lường chẩn đoán có khối lượng lớn mà bạn có thể xem một lần trong một sự cố.

Nếu bạn xử lý tất cả dữ liệu đó giống nhau, cuối cùng bạn sẽ phải trả giá cao cho hạ tầng hoặc dịch vụ SaaS cho dữ liệu không cần mức độ cao như vậy.

Đây là lý do tại sao một số công ty xem quan sát khả năng như một vấn đề mua sắm, hỏi nền tảng nào dễ triển khai nhất hiện nay. Tôi đặt các câu hỏi như: “Điều gì xảy ra khi lượng dữ liệu đo lường tăng gấp 10 lần? Độ đa dạng sẽ như thế nào? Chúng ta đang lưu gì? Trong bao lâu? Và chi phí sẽ thay đổi ra sao?”

Có những giải pháp kỹ thuật cho những vấn đề này. Ví dụ, với tổng hợp luồng, bạn có thể tổng hợp các số liệu trước khi chúng tới lưu trữ thay vì lưu trữ mọi chuỗi thời gian thô và tổng hợp sau này. Bạn có thể tách các tải công việc độ đa dạng cao ra khỏi giám sát quan trọng cho doanh nghiệp. Bạn cũng có thể sử dụng các chính sách lưu trữ và độ phân giải khác nhau tùy thuộc vào giá trị của dữ liệu.

Mục tiêu không phải là thu thập càng ít dữ liệu đo lường càng tốt. Bạn cần đủ thông tin để hiểu hệ thống của mình đang làm gì.

Mục tiêu là tránh việc tiêu tốn tài nguyên để thu thập, xử lý và lưu trữ dữ liệu mà không mang lại giá trị bổ sung.

Quan sát khả năng là một hệ thống kỹ thuật. Chi phí của nó cũng nên được thiết kế kỹ lưỡng.

Grammarly cho biết bằng chứng khái niệm của họ với VictoriaMetrics đã giảm hóa đơn AWS tới 10 lần. Khi các công ty đạt được mức tiết kiệm như vậy, thực tế gì đang thay đổi phía sau: nén dữ liệu, yêu cầu tính toán, kiến trúc lưu trữ, độ phức tạp vận hành, hay một sự kết hợp của các yếu tố này?

Đó là một sự kết hợp, nhưng nén dữ liệu và dung lượng tài nguyên là những yếu tố chính. VictoriaMetrics sử dụng nén được thiết kế riêng cho dữ liệu chuỗi thời gian, vì vậy cùng một số liệu chỉ chiếm một phần rất nhỏ dung lượng đĩa so với cơ sở dữ liệu đa mục đích. Thêm vào đó, chúng tôi tiêu thụ RAM nhẹ hơn từ bốn đến năm lần so với Prometheus ở tốc độ thu thập tương đương, và nhẹ hơn tới 10 lần trên đĩa. Khi Grammarly thực hiện bằng chứng khái niệm, điều này đã phản ánh trực tiếp trên hóa đơn AWS của họ, vì họ không chỉ lưu trữ ít dữ liệu hơn; họ còn chạy ít và các instance nhỏ hơn để thực hiện.

Phần độ phức tạp vận hành cũng quan trọng, nhưng nó mang tính gián tiếp hơn. Nhiều đội tính chi phí quan sát khả năng chỉ xem xét các mục lưu trữ và tính toán và bỏ qua thời gian kỹ thuật dành cho việc vận hành một stack Thanos gồm năm thành phần so với một binary duy nhất. Đó là tiền thật; chỉ là khó đưa ra con số cụ thể.

Prometheus đã trở thành nền tảng cho việc giám sát đám mây-native, tuy nhiên một số tổ chức cuối cùng gặp phải các hạn chế về khả năng mở rộng hoặc vận hành. Điều gì thường khiến một công ty bắt đầu tìm kiếm ngoài một triển khai Prometheus truyền thống, và khi nào VictoriaMetrics trở thành một lựa chọn hợp lý?

Prometheus xuất sắc trong mục đích mà nó được xây dựng: một công cụ thu thập và cảnh báo trên một nút duy nhất. Các đội thường gặp giới hạn theo hai cách: Hoặc độ đa dạng của chúng tăng vượt quá khả năng bộ nhớ của một instance Prometheus duy nhất, hoặc họ cần lưu trữ dài hạn và truy vấn toàn cầu trên nhiều cụm, điều mà Prometheus không bao giờ được thiết kế để thực hiện một mình. Đó là lúc mọi người gắn thêm Thanos hoặc Cortex, thường là nơi bắt đầu các vấn đề vận hành. Bạn chuyển từ việc chạy một binary duy nhất sang chạy một hệ thống phân tán với một compactor, một querier, một store gateway và nhiều thành phần khác có thể gặp sự cố vào lúc 3 giờ sáng.

VictoriaMetrics trở thành bước tiếp theo hợp lý vì nó là một giải pháp thay thế ngay lập tức, không phải một kiến trúc lại. Các đội chỉ cần trỏ cấu hình thu thập Prometheus hiện có sang VictoriaMetrics và giữ nguyên mọi bảng điều khiển Grafana, cảnh báo và quy tắc ghi lại mà họ đã xây dựng. Việc di chuyển chỉ là một thay đổi cấu hình, không phải một dự án, và họ đạt được quy mô mà không phải thêm năm thành phần mới để vận hành.

Chúng tôi đang thấy các đội kỹ thuật xem xét lại liệu họ có cần các nền tảng quan sát lớn, được quản lý hoàn toàn hay họ có thể xây dựng các ngăn xếp hiệu quả hơn từ các thành phần mã nguồn mở. Bạn có thấy đây là một sự chuyển dịch cấu trúc rộng hơn trong thị trường quan sát, và mã nguồn mở đang tạo ra bao nhiêu áp lực lên các mô hình định giá truyền thống không?

Nó là cấu trúc; không phải một phản ứng tạm thời đối với một năm ngân sách kém. Các nhà cung cấp quan sát lịch sử đã định giá dựa trên khối lượng nhập liệu hoặc số lượng máy chủ, và mô hình đó gây bất lợi cho khách hàng khi doanh nghiệp của họ phát triển. Công ty càng thành công, chi phí càng tăng, và mức giá không có mối quan hệ thực tế với giá trị mang lại. Các đội kỹ thuật đã bắt đầu tự tính toán, nhận ra rằng một ngăn xếp mã nguồn mở tự lưu trữ, hiệu quả làm thay đổi hoàn toàn phương trình này. Điều này là vì chi phí tăng tỷ lệ với hạ tầng thực tế được vận hành thay vì một công thức đo lường do nhà cung cấp kiểm soát.

Điều này tạo ra áp lực thực sự lên mức giá hiện hành. Khi một đội có thể trỏ cấu hình thu thập hiện có sang một giải pháp mã nguồn mở và giảm chi phí từ 60 đến 80% mà không mất tính năng, thì cuộc trò chuyện nội bộ không còn khó khăn. Các nhà cung cấp vẫn tính phí theo máy chủ hoặc metric tùy chỉnh sẽ tiếp tục làm mất khách hàng không thực hiện phép tính này.

Hạ tầng AI đưa vào một tài nguyên mới vô cùng đắt đỏ vào phương trình: GPU. Các công ty chạy đào tạo hoặc suy luận AI nên giám sát gì ngoài mức sử dụng GPU cơ bản, và việc quan sát tốt hơn có thể chuyển đổi trực tiếp thành giảm chi phí hạ tầng AI ở đâu?

Chỉ mức sử dụng GPU không cung cấp đủ thông tin.

Bạn có thể thấy mức sử dụng 90% trên bảng điều khiển và cho rằng mọi thứ ổn. Nhưng điều bạn thực sự muốn biết là: GPU đang làm gì?

Bạn cần xem sâu hơn. Các kernel CUDA nào đang chạy? Bộ nhớ GPU được cấp phát như thế nào? Bao nhiêu thời gian được tiêu tốn cho việc di chuyển bộ nhớ thay vì thực hiện tính toán? Công việc có đang sử dụng Tensor Cores khi cần không? GPU thực sự là nút thắt cổ chai, hay nó đang chờ dữ liệu từ nơi khác?

Đây là những câu hỏi quan trọng vì GPU rất đắt đỏ. Một sự kém hiệu quả nhỏ lặp lại trên hàng trăm hoặc hàng nghìn GPU sẽ trở thành một khoản tiền rất lớn.

Ví dụ, nếu GPU đang chờ vì pipeline dữ liệu không thể cung cấp đủ nhanh, việc mua thêm GPU sẽ không giải quyết được vấn đề. Bạn phải tìm ra nút thắt cổ chai. Điều tương tự cũng áp dụng cho bộ nhớ. Nếu các công việc cấp phát bộ nhớ không hiệu quả, việc quan sát tốt hơn có thể giúp kỹ sư điều chỉnh kích thước batch hoặc chạy nhiều công việc hơn trên cùng một phần cứng.

Đây là nơi quan sát trở nên thú vị đối với hạ tầng AI. Nó không chỉ về việc phát hiện một thứ gì đó bị hỏng. Nó có thể cho bạn biết bạn đang lãng phí tính toán ở đâu.

Cũng có một vấn đề quan sát do toàn bộ việc giám sát này gây ra. GPU có thể tạo ra rất nhiều dữ liệu telemetry chi tiết, độ đa dạng cao. Nếu bạn thu thập mọi thứ và gửi trực tiếp vào một nền tảng SaaS đắt tiền, bạn có thể giảm chi phí GPU và sau đó dùng một phần tiết kiệm để lưu trữ dữ liệu giám sát. Nhưng đó không phải là một tối ưu tốt.

Với OpenTelemetry và các dự án như OpenLIT, chúng ta có thể có khả năng quan sát sâu hơn nhiều vào các công việc GPU. Sau đó, với VictoriaMetrics, chúng ta có thể tổng hợp dữ liệu, loại bỏ các chiều không hữu ích và lưu trữ hiệu quả thông tin mà các kỹ sư thực sự cần.

Câu hỏi hữu ích không phải là, “GPU của tôi được sử dụng bao nhiêu?”

Mà là, “Công việc hữu ích nào tôi nhận được từ các GPU mà tôi đang trả tiền?”

Khi bạn có thể trả lời câu hỏi đó, bạn có thể bắt đầu đưa ra các quyết định kỹ thuật và chi phí tốt hơn.

Các tác nhân AI tạo ra những thách thức quan sát rất khác so với phần mềm truyền thống vì một yêu cầu duy nhất có thể kích hoạt các cuộc gọi mô hình, sử dụng công cụ, truy vấn cơ sở dữ liệu vector, chuyển giao, và có thể là chuỗi dài các hành động tự động. Quan sát cần phát triển như thế nào khi các ứng dụng doanh nghiệp ngày càng trở nên mang tính tác nhân?

Quan sát truyền thống giả định một yêu cầu đi theo một lộ trình khá dự đoán được qua hạ tầng của bạn. Các khối lượng công việc mang tính tác nhân không hoạt động như vậy. Một tác nhân duy nhất có thể gọi một mô hình, sau đó một công cụ, rồi một mô hình khác và thử lại ba lần trước khi trả về bất kỳ kết quả nào. Mỗi bước trong số đó đều cần có khả năng quan sát riêng.

Các chế độ thất bại cũng khác nhau. Một dịch vụ truyền thống hoặc phản hồi đúng hoặc không phản hồi. Một tác nhân có thể phản hồi thành công nhưng vẫn sai, chậm hoặc tốn kém, và không có gì trong số đó xuất hiện như một lỗi điển hình trên bảng điều khiển được xây dựng cho thời gian hoạt động.

Phần khiến các đội bất ngờ là độ đa dạng. Một quy trình công việc tác nhân duy nhất có thể tạo ra các metric liên quan đến người dùng cụ thể, lời nhắc và cuộc gọi công cụ, và khối lượng này tăng nhanh, đặc biệt là với các vòng lặp đệ quy nơi một planner liên tục gọi cùng một công cụ. Bất kỳ hệ thống nào nhằm quan sát các khối lượng công việc tác nhân đều phải xử lý quy mô đó mà không làm đường cong chi phí tăng dọc, đây chính là vấn đề chúng tôi đang giải quyết. Metric, log và trace vẫn là các khối xây dựng đúng. Điều cần thay đổi là khối lượng và mô hình chi phí bên dưới chúng.

VictoriaMetrics cũng đã áp dụng học máy và quy trình hỗ trợ AI vào việc phát hiện bất thường. Bạn tin rằng AI có thể thực sự cải thiện việc giám sát và phản hồi sự cố như thế nào hiện nay, và ở đâu quyết định của con người vẫn khó thay thế?

Việc giữ một người trong vòng lặp để tạo ra ý tưởng, định hướng triển khai và xác thực kết quả là quan trọng. Nói cách khác, không có gì thực sự thay đổi so với quy trình truyền thống. Điều đã thay đổi là khả năng tạo ra giải pháp được tăng cường. Bây giờ bất kỳ ai cũng có thể tạo phần mềm, nhưng điều đó không nên hạ thấp tiêu chuẩn chấp nhận. Nó nên nâng cao chúng đáng kể.

Nơi AI thực sự hữu ích là việc phát hiện những gì một người có thể bỏ lỡ trong tiếng ồn, như các ngoại lệ và xu hướng mà không kích hoạt ngưỡng thủ công. Tại VictoriaMetrics, chúng tôi có một chính sách AI nội bộ đơn giản: Nhân viên tự do tự động hoá quy trình làm việc của họ theo cách họ muốn, nhưng họ vẫn chịu trách nhiệm về kết quả cuối cùng. Đó là tiêu chuẩn tương tự chúng tôi áp dụng cho việc phát hiện bất thường trong môi trường sản xuất của khách hàng. Mô hình có thể đánh dấu, nhưng một người vẫn phải quyết định nó có ý nghĩa gì và phải làm gì.

VictoriaMetrics vẫn duy trì mã nguồn mở và đã áp dụng cách tiếp cận tự tài trợ, tài trợ bởi khách hàng thay vì theo mô hình startup hạ tầng truyền thống được hỗ trợ bởi vốn đầu tư. Điều này đã ảnh hưởng như thế nào đến cách bạn xây dựng sản phẩm, định giá và quyết định công nghệ nào vẫn giữ mã nguồn mở?

Tự tài trợ thay đổi cấu trúc động lực nhiều hơn so với mong đợi của mọi người. Không có hội đồng nào yêu cầu chúng tôi đạt chỉ tiêu ARR trong một quý cụ thể, chúng tôi không phải thực hiện những đánh đổi thường đi kèm với áp lực đó, như làm suy yếu phiên bản mã nguồn mở để buộc người dùng chuyển sang cấp trả phí, hoặc thay đổi giấy phép như InfluxDB hay HashiCorp đã làm khi họ cần bảo vệ doanh thu khỏi các nhà cung cấp đám mây. VictoriaMetrics OSS hiện đang sử dụng Apache 2.0, và chúng tôi không có kế hoạch thay đổi điều đó.

Cách chúng tôi quyết định phần nào sẽ giữ ở dạng mã nguồn mở rất đơn giản: lõi engine, thành phần mà các kỹ sư cần tin tưởng để xử lý dữ liệu sản xuất của họ, vẫn được mở. Chúng tôi tính phí cho những gì một công ty cần khi đã vận hành ở quy mô lớn và cần một bên chịu trách nhiệm: multi-tenancy, enterprise authentication, compliance support, một CVE SLA và truy cập trực tiếp tới các kỹ sư đã viết mã thay vì qua hàng đợi hỗ trợ. Được tài trợ bởi khách hàng cũng đồng nghĩa lộ trình được xác định bởi những vấn đề thực tế mà người dùng gặp trong môi trường sản xuất, không phải bởi những gì có thể gây quỹ trong bản pitch deck.

Khi các chỉ số, log, trace, dữ liệu đo lường ứng dụng AI, giám sát GPU và phát hiện bất thường tự động ngày càng hội tụ, bạn nghĩ stack quan sát sẽ như thế nào trong vài năm tới, và các đội kỹ thuật sẽ mong đợi gì từ các nền tảng muốn duy trì tính liên quan?

Stack hội tụ về mặt vận hành trước khi nó hội tụ thành một sản phẩm duy nhất, và sự khác biệt này rất quan trọng. Hầu hết các đội không muốn một nền tảng monolithic với một giao diện duy nhất khóa mọi thứ lại với nhau. Họ muốn các chỉ số, log và trace chạy trên cùng một mô hình vận hành, cùng một nhà cung cấp và cùng một câu chuyện cấp phép, mà không phải từ bỏ khả năng chạy từng tín hiệu một cách độc lập nếu đội đó cần. Đó là hướng mà VictoriaMetrics đang xây dựng. Chúng tôi không cố gắng gộp mọi thứ vào một binary duy nhất. Chúng tôi muốn đảm bảo ba tín hiệu chia sẻ cùng một engine và cùng các đặc tính hiệu suất, vì vậy việc thêm tín hiệu thứ hai hay thứ ba không đồng nghĩa với việc nhận thêm gánh nặng vận hành.

Các nền tảng duy trì tính liên quan là những nền tảng có thể tích hợp dữ liệu đo lường AI và giám sát GPU vào cùng mô hình mà không làm phá vỡ đường cong chi phí. Các khối lượng công việc AI tạo ra dữ liệu đo lường với mức độ mà mô hình định giá theo chỉ số hoặc theo host truyền thống chưa từng được thiết kế để đáp ứng. Các đội hoặc ngừng thu thập dữ liệu cần thiết hoặc hóa đơn quan sát của họ tăng nhanh hơn mức đầu tư AI mà chúng đang giám sát. Các đội kỹ thuật sẽ mong đợi các nền tảng xử lý khối lượng này giống như họ mong đợi bất kỳ hạ tầng nào mở rộng, mà không phải yêu cầu họ tái kiến trúc hoặc đàm phán lại mỗi khi khối lượng công việc tăng.

Cảm ơn bạn đã tham gia phỏng vấn tuyệt vời, độc giả muốn tìm hiểu thêm nên truy cập VictoriaMetrics.