Truyền trực tuyến thay đổi trò chơi: Apache Pulsar giới thiệu Autoscaling

Apache Pulsar luôn coi mình là đám mây bản địa. Nó ở ngay trên trang chủ:

“Apache® Pulsar™ là một nền tảng truyền phát và nhắn tin phân tán, mã nguồn mở được xây dựng cho đám mây”

Pulsar chắc chắn là hiện thân của nhiều nguyên tắc dựa trên đám mây, bao gồm việc tách điện toán khỏi bộ lưu trữ trong đó trình môi giới Pulsar xử lý việc phân phát tin nhắn và Apache BookKeeper xử lý việc lưu trữ chúng và ý tưởng về các thành phần phi trạng thái có thể tăng giảm theo ý muốn như nhà môi giới Pulsar.

Tuy nhiên, nó chưa bao giờ thực sự mang lại lời hứa cuối cùng của đám mây: tự động thay đổi quy mô. Ít nhất, không phải cho đến ngày hôm nay.

Tôi rất vui được giới thiệu Kubernetes Autoscaling cho Apache Pulsar hoặc KAAP. KAAP là toán tử Kubernetes có sẵn trên OperatorHub. Nó bao gồm tất cả những điều thú vị mà bạn mong đợi từ một nhà điều hành Kubernetes. Khi bạn đã cài đặt toán tử trong cụm Kubernetes của mình, bạn có thể nhận được cụm Pulsar đầy đủ chức năng bằng cách áp dụng một định nghĩa tài nguyên tùy chỉnh (CRD) như sau:

 apiVersion: kaap.oss.datastax.com/v1alpha1 kind: PulsarCluster metadata: name: pulsar spec: global: name: pulsar image: 'apachepulsar/pulsar:3.0.0'

Pulsar có nhiều thành phần: ZooKeeper, BookKeeper, nhà môi giới và proxy. Người vận hành xử lý việc định cấu hình tất cả chúng bằng PulsarCluster CRD. Vì toán tử hoạt động ở cấp độ cụm nên bạn không phải lo lắng về cách các thành phần hoạt động cùng nhau. Nhà điều hành sẽ chăm sóc điều đó cho bạn.

Nâng cấp theo giai đoạn tự động

Đã vận hành dịch vụ đám mây sản xuất cho Pulsar lâu hơn bất kỳ ai mà tôi biết (lúc đầu kesque và bây giờ với DataStax Astra Streaming), tôi biết trực tiếp mất bao lâu để thực hiện nâng cấp thích hợp cụm Pulsar. Mặc dù bạn chỉ có thể YOLO nâng cấp tất cả các thành phần cùng một lúc, nhưng phương pháp được đề xuất và an toàn nhất là nâng cấp từng thành phần một, đảm bảo mỗi thành phần đã nâng cấp thành công trước khi chuyển sang thành phần tiếp theo.

Đây là quy trình mà chúng tôi tuân theo khi nâng cấp các cụm Pulsar trong dịch vụ Truyền trực tuyến Astra của chúng tôi vì tính sẵn có của dịch vụ khách hàng của chúng tôi là điều tối quan trọng, nhưng nó lại rất tốn thời gian đối với nhóm kỹ thuật sản xuất của chúng tôi. Trên thực tế, đây là yêu cầu số một của họ: bạn có thể nâng cấp thông minh hơn và tự động hơn không? Chà, với KAAP, chúng tôi đã làm được điều đó.

Với một thay đổi dòng duy nhất trong PulsarCluster CRD, bạn có thể kích hoạt nâng cấp theo giai đoạn cho cụm Pulsar của mình. Nhà điều hành KAAP sẽ sắp xếp việc nâng cấp theo giai đoạn, cẩn thận cho cụm của bạn. Tất nhiên, bạn nên theo dõi các số liệu trong quá trình nâng cấp, nhưng bạn có thể để người điều hành KAAP lái xe (không ngủ gật).

Tự động thay đổi mã nguồn mở

Nâng cấp theo giai đoạn tự động là tốt, nhưng đó không phải là điều tôi hào hứng nhất với KAAP. Khái niệm về tài nguyên đàn hồi là một hứa hẹn quan trọng của đám mây. Đó là lý do tại sao nhiều dịch vụ AWS có tên "co giãn". Tôi (thực ra là ChatGPT ) đã tìm kiếm nhanh và có ít nhất 10 trong số đó.

Đám mây cho phép bạn thu nhận và giải phóng tài nguyên theo yêu cầu, vì vậy bạn có thể sử dụng các kỹ thuật tự động thay đổi quy mô để phù hợp với số lượng tài nguyên mà ứng dụng của bạn đang sử dụng để tải trên đó. Khi tải tăng lên, bạn có thể tự động thêm nhiều tài nguyên hơn. Khi tải giảm, bạn có thể giải phóng tài nguyên. Vì các nhà cung cấp dịch vụ đám mây tính phí sử dụng tài nguyên nên tính năng tự động thay đổi quy mô có thể giúp bạn sử dụng hiệu quả nhất chi tiêu trên đám mây của mình.

Tôi chắc rằng tất cả chúng ta đều có thể nghĩ ra các ví dụ về dịch vụ đám mây có tính năng tự động điều chỉnh tỷ lệ ở hậu trường. Hầu hết các dịch vụ AWS “co giãn” đó đều hoạt động như vậy. Tuy nhiên, việc triển khai tính năng tự động thay đổi quy mô là độc quyền, bị khóa trong kho lưu trữ riêng của nhà cung cấp. Đôi khi họ sẽ nói về cách họ đã triển khai tính năng tự động thay đổi quy mô, như trong phần này giấy về AWS DynamoDB hoặc cái này bài viết trên blog về cách Confluent Cloud khiến Kafka linh hoạt. Nhưng theo hiểu biết của tôi, không có ai làm cho việc triển khai tự động thay đổi quy mô của họ trở thành nguồn mở, sẵn có miễn phí cho tất cả người dùng theo giấy phép nguồn mở thực sự. Đó chính xác là những gì chúng tôi đang làm với KAAP.

KAAP bổ sung các khả năng tự động tính tỷ lệ phức tạp cho Pulsar của bạn (hoặc phát trực tuyến luna , bản phân phối Pulsar của chúng tôi) theo giấy phép Apache 2.0. Bạn có thể kiểm tra nó trong của chúng tôi kho lưu trữ GitHub . Nếu thấy hay nhớ cho 1 sao nhé.

Pulsar + tự động điều chỉnh tỷ lệ: Một sự kết hợp hoàn hảo

KAAP cung cấp cho bạn cách thêm tính năng tự động thay đổi quy mô vào Pulsar khi chạy trong Kubernetes. Không đơn giản, Horizontal Pod Autoscaler (HPA) được bổ sung vào quá trình triển khai của nhà môi giới Pulsar, mà là một công cụ chia tỷ lệ tự động tinh vi hoạt động với các thành phần gốc trên nền tảng đám mây hiện có của Pulsar để cung cấp một hệ thống truyền phát và nhắn tin linh hoạt thực sự. Theo tôi, đây là một sự kết hợp không thể đánh bại.

Nhân rộng môi giới không quốc tịch

Chúng ta hãy xem xét hai khía cạnh tự động tính tỷ lệ chính của KAAP. Đầu tiên, chúng ta sẽ xem xét các nhà môi giới Pulsar. Như bạn có thể biết, các nhà môi giới Pulsar không có trạng thái, điều đó có nghĩa là bạn có thể dễ dàng mở rộng quy mô của chúng theo yêu cầu. Nhưng điều mà bạn có thể không biết là Pulsar có cơ chế cân bằng tải tích hợp sẵn của nhà môi giới giúp giám sát liên tục CPU, bộ nhớ và băng thông mạng trên mỗi nhà môi giới. Sử dụng thông tin đó và một trong các thuật toán cân bằng tải có thể định cấu hình, Pulsar sẽ chuyển các chủ đề từ nhà môi giới này sang nhà môi giới khác để ngăn nhà môi giới bị quá tải.

Một giải pháp tự động thay đổi quy mô ngây thơ sẽ là định cấu hình Kubernetes Horizontal Pod Autoscaler (HPA) trên các bộ trung gian và khi một số chỉ số như CPU tăng cao, hãy mở rộng một nhóm trung gian khác. Nhưng điều này có thể không thực sự cần thiết vì bộ cân bằng tải của nhà môi giới Pulsar có thể quyết định chuyển các chủ đề để cân bằng tải cùng một lúc. Bây giờ, bạn đã mở rộng nhóm môi giới không cần thiết vì bộ cân bằng tải Pulsar đã cân bằng mọi thứ. Vì vậy, bây giờ HPA quyết định thu nhỏ nhóm môi giới mới, điều này khiến bất kỳ chủ đề mới nào đã được tạo trên đó được chuyển sang một nhà môi giới hiện có. Như bạn có thể tưởng tượng, bộ cân bằng tải Pulsar và HPA có thể tạo ra một mớ hỗn độn các nhà môi giới lên xuống và các chủ đề được chuyển từ nhà môi giới này sang nhà môi giới khác.

KAAP tránh vấn đề này bằng cách tích hợp trực tiếp với bộ cân bằng tải Pulsar. KAAP tăng quy mô của các trình trung gian khi các chỉ số trên toàn cụm từ bộ cân bằng tải Pulsar cho thấy rằng cụm sắp hết công suất, chứ không phải khi một nhóm trình trung gian đơn lẻ đang bận. Và nó chỉ giảm quy mô của một nhà môi giới nếu việc sử dụng toàn bộ cụm giảm xuống dưới ngưỡng đã định cấu hình. Toán tử KAAP hoạt động với bộ cân bằng tải của nhà môi giới Pulsar, không chống lại nó.

Tăng và giảm dung lượng lưu trữ: Đáng chú ý!

Thay đổi quy mô lớp tính toán (hoặc cung cấp) của Pulsar là rất tốt, nhưng nó không đủ để triển khai tự động thay đổi quy mô thực sự. Chắc chắn, số lượng thư (hoặc sự kiện) cần được xử lý có thể thay đổi theo thời gian, nhưng còn số lượng thư cần được lưu trữ thì sao? Có lẽ tất cả chúng ta đều đã từng phải xử lý một đống thư tồn đọng do lỗi của hệ thống xuôi dòng. Khi sự cố ngừng hoạt động kéo dài, dung lượng lưu trữ khả dụng trên hệ thống phát trực tuyến bắt đầu cạn kiệt.

Đây là một kịch bản mà Pulsar và sự phụ thuộc của nó vào BookKeeper tỏa sáng. Để thêm dung lượng lưu trữ cho cụm Pulsar, bạn chỉ cần thêm một nút BookKeeper mới, được gọi một cách trìu mến là “nhà cái”. Bởi vì lưu trữ BookKeeper dựa trên các phân đoạn chủ đề chứ không phải toàn bộ chủ đề, nên nhà cái mới có sẵn ngay lập tức để giảm bớt áp lực cho việc lưu trữ, với bất kỳ sự tái cân bằng khó khăn nào của các chủ đề hoặc bất kỳ can thiệp vận hành nào khác.

Tất nhiên, KAAP có thể xử lý trường hợp này cho bạn. Nó liên tục giám sát việc sử dụng đĩa của các nút nhà cái và nếu dung lượng lưu trữ khả dụng sắp hết, nó sẽ mở rộng một nút nhà cái mới. Đây không phải là tất cả những gì đáng chú ý (ít nhất là đối với Pulsar). Việc thêm một bản sao mới vào Kubernetes khá đơn giản, ngay cả khi nó ở trạng thái và được hỗ trợ bởi các ổ đĩa liên tục. Nhưng khi ngừng hoạt động và công việc tồn đọng đã được giải quyết thì sao? Bây giờ bạn có đang mắc kẹt với một nút đặt cược bổ sung tiêu tốn tài nguyên không thực sự cần thiết nữa không?

Không phải với KAAP, bạn thì không. Sau khi dung lượng lưu trữ BookKeeper giảm xuống dưới ngưỡng đã định cấu hình, nhà điều hành KAAP sẽ sắp xếp cẩn thận việc loại bỏ nút đặt sách không cần thiết. Nó thực hiện điều này theo cách rất an toàn, đảm bảo rằng không có thông báo nào bị mất và hệ số sao chép cần thiết luôn được duy trì. Ví dụ: nếu bạn đã định cấu hình Pulsar để giữ ba bản sao của mỗi tin nhắn (viết và xác nhận đại biểu đều bằng ba), KAAP sẽ tương tác với BookKeeper để sao chép tin nhắn từ nhà cái đang được thu nhỏ sang các nhà cái khác để đảm bảo có ít nhất ba bản sao của tin nhắn có sẵn. Sau khi hoàn tất thành công, nó sẽ tiến hành xóa nhà cái không cần thiết.

Với KAAP, bạn có thể tự động tăng và giảm dung lượng lưu trữ trong cụm Pulsar của mình để bạn có thể tối ưu hóa việc sử dụng dung lượng lưu trữ trong cụm của mình và không bị kẹt với dung lượng nhàn rỗi sau sự cố sản xuất đáng tiếc. Tôi không biết về bạn, nhưng tôi nghĩ điều đó khá đáng chú ý.

Công cụ di chuyển và nhận biết vùng

KAAP có thể thực hiện nâng cấp theo giai đoạn và mở rộng quy mô thông minh cho cụm Pulsar của bạn. Nhưng có nhiều hơn nữa. Để vận hành một cụm có tính sẵn sàng cao trong nhà cung cấp đám mây, điều quan trọng là phải xem xét các vùng khả dụng (AZ). Nếu bạn không trải rộng các thành phần của mình, đặc biệt là BookKeeper, trên khắp các vùng sẵn sàng, thì bạn sẽ không thể vượt qua sự cố AZ và cung cấp nhiều điểm sẵn sàng.

May mắn thay, Pulsar có các khả năng tích hợp sẵn tuyệt vời như nhận biết giá đỡ để hỗ trợ triển khai tính sẵn sàng cao. Phần khó khăn là để thiết lập nó đúng cách, bạn cần định cấu hình Kubernetes chính xác với nhận thức vùng và cũng định cấu hình Pulsar. Toán tử KAAP hỗ trợ bạn bằng cách giới thiệu khái niệm về bộ tài nguyên, cho phép bạn nhóm các thành phần và cung cấp nhận thức về giá đỡ. Toán tử KAAP sẽ tự động áp dụng cả cấu hình Kubernetes và Pulsar dựa trên cấu hình khai báo của các bộ tài nguyên. Các bộ tài nguyên rất linh hoạt, cho phép bạn hỗ trợ nhiều tùy chọn triển khai Pulsar.

Và điều gì sẽ xảy ra nếu bạn đang chạy Pulsar của mình bằng biểu đồ Helm hoặc có thể chỉ là một số phép thuật hiển thị Kubernetes? KAAP có một công cụ di chuyển để giúp bạn. Bạn có thể trỏ công cụ di chuyển vào triển khai Kubernetes Pulsar hiện tại của mình và nó sẽ tự động tạo cấu hình CRD phù hợp mà bạn có thể sử dụng để yêu cầu toán tử KAAP tiếp quản việc vận hành cụm cho bạn.

Ngăn xếp KAAP

Toán tử KAAP có rất nhiều tính năng tuyệt vời, tăng cường cụm Pulsar thông thường của bạn thành một cỗ máy tự động thay đổi tỷ lệ được bôi trơn tốt, có tính sẵn sàng cao. Nhưng với tư cách là người đã vận hành các cụm Pulsar sản xuất trong một thời gian dài, tôi biết rằng có rất nhiều cân nhắc khác để tạo cụm Pulsar sản xuất, chẳng hạn như quản lý, xác thực và giám sát chứng chỉ TLS.

Đó là lý do tại sao chúng tôi đã bao gồm cái mà chúng tôi gọi là ngăn xếp KAAP với toán tử. Đó là biểu đồ Helm ô cài đặt toán tử KAAP cùng với các công cụ sản xuất quan trọng, bao gồm:

• Người quản lý chứng chỉ
• áo choàng chìa khóa
• Ngăn xếp Prometheus (Grafana)
• Bảng điều khiển Pulsar Grafana

Đây là những công cụ bắt buộc phải có khi chạy các cụm Pulsar sản xuất của chúng tôi và chúng tôi không muốn để bạn cạn kiệt, vì vậy chúng tôi đã tập hợp tất cả chúng lại với nhau và tích hợp chúng vào một gói tiện lợi.

Tại sao nên sử dụng KAAP?

Vậy là bạn đã nghe nói về tất cả các tính năng tuyệt vời của Kubernetes Autoscaling cho Apache Pulsar. Bạn có thể tạo toàn bộ cụm Pulsar bằng một CRD duy nhất. Bạn có thể đặt các bản nâng cấp của mình ở chế độ lái tự động và để người vận hành KAAP thực hiện các bản nâng cấp theo giai đoạn, an toàn. Bạn có thể tự động tăng và giảm quy mô trình môi giới Pulsar dựa trên bộ cân bằng tải của trình môi giới Pulsar cho biết các trình môi giới đang bị quá tải và bạn có thể tăng và giảm quy mô các nút BookKeeper (!) một cách an toàn dựa trên yêu cầu lưu trữ của các cụm của bạn. Bạn có thể dễ dàng định cấu hình cụm của mình để nhận biết vùng khả dụng để có tính sẵn sàng cao. Và nó thậm chí còn bao gồm một công cụ di chuyển để bạn có thể dễ dàng chuyển từ triển khai dựa trên Helm cũ của mình sang triển khai dựa trên nhà điều hành KAAP, được tăng áp.

Vì vậy, rất nhiều tính năng tuyệt vời, nhưng lợi ích của KAAP là gì? Tôi có thể nghĩ về một số:

• Dễ dàng định cấu hình và vận hành các cụm Pulsar có tính sẵn sàng cao chạy trong Kubernetes dẫn đến bạn và nhóm sản xuất của bạn tốn ít công sức hơn
• Đơn giản hóa đáng kể quy mô Pulsar để phù hợp với nhu cầu thay đổi bằng cách tự động thay đổi quy mô tài nguyên cụm để phù hợp với nhu cầu
• Giảm tổng chi phí sở hữu cụm Pulsar bằng cách loại bỏ việc cung cấp cho tải cao điểm hoặc cung cấp quá mức do sự cố sản xuất
• Tránh khóa nhà cung cấp bằng cách sử dụng tất cả các công nghệ nguồn mở

Theo tôi, việc phát hành KAAP là một thời điểm thực sự đổi mới trong không gian truyền phát và nhắn tin. Không có dự án nguồn mở nào khác kết hợp sức mạnh phát trực tuyến và nhắn tin của Apache Pulsar với lời hứa cuối cùng về điện toán đám mây: hoàn toàn đàn hồi, tự động thay đổi quy mô. Tôi rất mong bạn thử nó. Tham gia Thảo luận GitHub trong repo của chúng tôi và cho chúng tôi biết suy nghĩ của bạn!

Tìm hiểu thêm

Nếu bạn muốn tìm hiểu sâu về kỹ thuật trong KAAP, hãy xem bài đăng trên blog này . Bạn có thể tìm thấy tài liệu đầy đủ cho KAAP đây . Và đây là kho lưu trữ GitHub.

Bởi Chris Bartholomew, DataStax