Làm chủ việc triển khai và nhân rộng nhiều cụm với Kafka

Tổng quan ngắn gọn về Apache Kafka và các trường hợp sử dụng phổ biến, các công cụ hiện tại để mở rộng quy mô triển khai nhiều cụm và các giải pháp kết nối để đơn giản hóa việc triển khai nhiều cụm.

Mục lục

• Kafka là gì?

• Kafka và Kubernetes

• Trường hợp cho Kafka nhiều cụm

• Kafka nhiều cụm

  • Cụm kéo dài - Sao chép đồng bộ
  • Cụm được kết nối - Sao chép không đồng bộ

• Phần kết luận

  
  

Kafka là gì?

Thường được gọi đơn giản là Kafka , Apache Kafka là một nền tảng phát trực tuyến sự kiện nguồn mở được duy trì bởi Quỹ phần mềm Apache. Ban đầu được hình thành tại LinkedIn , Apache Kafka được Jay Kreps , Neha Narkhede và Jun Rao hợp tác tạo ra, và sau đó được phát hành dưới dạng một dự án nguồn mở vào năm 2011. Trang Wiki

Ngày nay, Kafka là một trong những nền tảng phát trực tuyến sự kiện phổ biến nhất được thiết kế để xử lý nguồn cấp dữ liệu theo thời gian thực. Nó được sử dụng rộng rãi để xây dựng các đường ống dữ liệu truyền phát có khả năng mở rộng, có khả năng chịu lỗi và hiệu suất cao.

Công dụng của Kafka liên tục được mở rộng, với 5 trường hợp hàng đầu được Brij Pandey minh họa độc đáo trong hình ảnh kèm theo.

Là phần tóm tắt ngắn gọn, điều quan trọng là phải hiểu các thành phần của nền tảng Kafka và cách chúng hoạt động..

Kafka hoạt động như một nền tảng phát trực tuyến sự kiện phân tán, được thiết kế để xử lý nguồn cấp dữ liệu theo thời gian thực một cách hiệu quả. Nó hoạt động dựa trên mô hình nhắn tin đăng ký xuất bản và tuân theo kiến trúc phân tán và có khả năng chịu lỗi. Nó duy trì một chuỗi các bản ghi liên tục, có thứ tự và được phân vùng gọi là "chủ đề". Nhà sản xuất ghi dữ liệu vào các chủ đề này và người tiêu dùng đọc từ chúng. Điều này cho phép tách rời giữa nhà sản xuất dữ liệu và người tiêu dùng và cho phép nhiều ứng dụng sử dụng cùng một luồng dữ liệu một cách độc lập.

Các thành phần chính của Kafka bao gồm:

1. Chủ đề và phân vùng: Kafka sắp xếp dữ liệu thành các chủ đề. Mỗi chủ đề là một luồng bản ghi và dữ liệu trong một chủ đề được chia thành nhiều phân vùng. Mỗi phân vùng là một chuỗi các bản ghi có thứ tự, bất biến . Các phân vùng cho phép khả năng mở rộng theo chiều ngang và tính song song bằng cách cho phép dữ liệu được phân phối trên nhiều nhà môi giới Kafka.

   
   

2. Nhà sản xuất : Nhà sản xuất là ứng dụng ghi dữ liệu vào chủ đề Kafka. Họ xuất bản các bản ghi theo chủ đề cụ thể, sau đó được lưu trữ trong các phân vùng của chủ đề. Nhà sản xuất có thể gửi bản ghi đến một phân vùng cụ thể một cách rõ ràng hoặc cho phép Kafka xác định phân vùng bằng chiến lược phân vùng.

   
   

3. Người tiêu dùng : Người tiêu dùng là những ứng dụng đọc dữ liệu từ các chủ đề Kafka. Họ đăng ký một hoặc nhiều chủ đề và sử dụng các bản ghi từ các phân vùng mà họ được chỉ định. Các nhóm người tiêu dùng được sử dụng để mở rộng quy mô mức tiêu thụ và mỗi phân vùng trong một chủ đề chỉ có thể được sử dụng bởi một người tiêu dùng trong một nhóm. Điều này cho phép nhiều người tiêu dùng làm việc song song để xử lý dữ liệu từ các phân vùng khác nhau của cùng một chủ đề.

   
   

4. Nhà môi giới : Kafka chạy như một cụm máy chủ và mỗi máy chủ được gọi là nhà môi giới. Các nhà môi giới chịu trách nhiệm xử lý các yêu cầu đọc và ghi từ nhà sản xuất và người tiêu dùng, cũng như quản lý các phân vùng chủ đề. Một cụm Kafka có thể có nhiều nhà môi giới để phân phối tải và đảm bảo khả năng chịu lỗi.

   
   

5. Phân vùng/Sao chép : Để đạt được khả năng chịu lỗi và độ bền dữ liệu, Kafka cho phép định cấu hình sao chép cho các phân vùng chủ đề. Mỗi phân vùng có thể có nhiều bản sao, trong đó một bản sao được chỉ định là người dẫn đầu và những bản sao còn lại là người theo sau. Bản sao của người dẫn đầu xử lý tất cả các yêu cầu đọc và ghi cho phân vùng đó, trong khi những người theo dõi sao chép dữ liệu từ người dẫn đầu để luôn đồng bộ hóa. Nếu một nhà môi giới có bản sao người lãnh đạo không thành công, một trong những người theo dõi sẽ tự động trở thành người lãnh đạo mới để đảm bảo hoạt động liên tục.

   
   

6. Quản lý bù đắp : Kafka duy trì khái niệm bù đắp cho từng phân vùng. Phần bù đại diện cho một mã định danh duy nhất cho một bản ghi trong một phân vùng. Người tiêu dùng theo dõi mức bù đắp hiện tại của họ, cho phép họ tiếp tục tiêu thụ từ nơi họ đã dừng lại trong trường hợp bị lỗi hoặc phải xử lý lại.

   
   

7. ZooKeeper : Mặc dù không phải là một phần của Kafka, ZooKeeper thường được sử dụng để quản lý siêu dữ liệu và điều phối các nhà môi giới trong cụm Kafka. Nó giúp bầu chọn người lãnh đạo, thông tin về chủ đề và phân vùng cũng như quản lý sự phối hợp của nhóm người tiêu dùng. [Lưu ý: Công cụ quản lý siêu dữ liệu Zookeeper sẽ sớm bị loại bỏ để nhường chỗ cho Kafka Raft hoặc KRaft, một giao thức dành cho siêu dữ liệu được quản lý nội bộ ]

   
   

Nhìn chung, thiết kế và kiến trúc của Kafka làm cho nó trở thành một nền tảng có khả năng mở rộng cao, có khả năng chịu lỗi và hiệu quả để xử lý khối lượng lớn luồng dữ liệu thời gian thực. Nó đã trở thành thành phần trung tâm trong nhiều ứng dụng và cơ sở hạ tầng dữ liệu dựa trên dữ liệu, tạo điều kiện thuận lợi cho việc tích hợp dữ liệu, xử lý sự kiện và phân tích luồng.

Một kiến trúc Kafka điển hình sẽ như sau:

Phân cụm Kafka đề cập đến thực tiễn điều hành nhiều nhà môi giới Kafka cùng nhau thành một nhóm để tạo thành một cụm Kafka. Phân cụm là một khía cạnh cơ bản của kiến trúc Kafka, cung cấp một số lợi ích, bao gồm khả năng mở rộng, khả năng chịu lỗi và tính sẵn sàng cao. Cụm Kafka được sử dụng để xử lý các luồng dữ liệu quy mô lớn và đảm bảo rằng hệ thống vẫn hoạt động ngay cả khi gặp lỗi.

Trong cụm, các chủ đề Kafka được chia thành nhiều phân vùng để đạt được khả năng mở rộng và song song. Mỗi phân vùng là một chuỗi các bản ghi bất biến, được sắp xếp tuyến tính. Do đó, các phân vùng cho phép dữ liệu được phân phối trên nhiều nhà môi giới trong cụm.

Cần lưu ý rằng một cụm Kafka tối thiểu bao gồm 3 nhà môi giới Kafka, mỗi nhà môi giới có thể chạy trên một máy chủ riêng biệt (ảo hoặc vật lý). Hướng dẫn 3 nút là giúp tránh tình huống chia não trong trường hợp nhà môi giới thất bại.

Kafka và Kubernetes

Khi ngày càng nhiều công ty áp dụng Kafka, mối quan tâm đến việc triển khai Kafka trên Kubernetes cũng ngày càng tăng.

Trên thực tế, báo cáo Kubernetes in the Wild gần đây nhất năm 2023 của Dynatrace cho thấy hơn 40% tổ chức lớn chạy nền tảng nhắn tin nguồn mở của họ trong Kubernetes - phần lớn trong số này là Kafka.

Nguồn .

Báo cáo tương tự cũng đưa ra một tuyên bố táo bạo rằng “Kubernetes đang nổi lên như một 'hệ điều hành' của đám mây”.

Khi đó, quản trị viên Kafka bắt buộc phải hiểu được sự tương tác giữa Kafka và Kubernetes cũng như cách triển khai những điều này một cách phù hợp với quy mô.

Trường hợp cho Kafka nhiều cụm

Về mặt lý thuyết, việc chạy một cụm Kafka trong một thiết lập cụm Kubernetes khá đơn giản và cho phép khả năng mở rộng khi cần thiết. Tuy nhiên, trong quá trình sản xuất, hình ảnh có thể hơi mờ.

Chúng ta nên phân biệt cách sử dụng cụm thuật ngữ giữa Kafka và Kubernetes. Việc triển khai Kubernetes cũng sử dụng cụm thuật ngữ để chỉ định một nhóm các nút được kết nối, được gọi là cụm Kubernetes. Khi khối lượng công việc Kafka được triển khai trên Kubernetes, bạn sẽ có một cụm Kafka chạy bên trong cụm Kubernetes, nhưng phù hợp hơn với cuộc thảo luận của chúng ta, bạn cũng có thể có một cụm Kafka trải rộng trên nhiều cụm Kubernetes - để có khả năng phục hồi, hiệu suất, chủ quyền dữ liệu vân vân.

Đầu tiên, Kafka không được thiết kế để thiết lập nhiều người thuê. Về mặt kỹ thuật, Kafka không hiểu các khái niệm như không gian tên Kubernetes hoặc cách ly tài nguyên. Trong một chủ đề cụ thể, không có cơ chế dễ dàng nào để thực thi các hạn chế truy cập bảo mật giữa nhiều nhóm người dùng.

Ngoài ra, các khối lượng công việc khác nhau có thể có các yêu cầu về quy mô và tần suất cập nhật khác nhau, ví dụ như ứng dụng hàng loạt so với ứng dụng thời gian thực. Việc kết hợp hai khối lượng công việc vào một cụm duy nhất có thể gây ra tác động tiêu cực hoặc tiêu tốn nhiều tài nguyên hơn mức cần thiết.

Chủ quyền dữ liệu và tuân thủ quy định cũng có thể áp đặt các hạn chế đối với việc định vị dữ liệu và chủ đề trong một khu vực hoặc ứng dụng cụ thể.

Tất nhiên, khả năng phục hồi là một động lực mạnh mẽ khác thúc đẩy nhu cầu về nhiều cụm Kafka. Mặc dù các cụm Kafka được thiết kế để đảm bảo khả năng chịu lỗi của các chủ đề, nhưng chúng tôi vẫn phải lập kế hoạch cho sự cố nghiêm trọng của toàn bộ cụm. Trong những trường hợp như vậy, nhu cầu về một cụm được sao chép đầy đủ sẽ giúp lập kế hoạch kinh doanh liên tục phù hợp.

Đối với các doanh nghiệp đang di chuyển khối lượng công việc sang đám mây hoặc có chiến lược đám mây lai, bạn có thể muốn thiết lập nhiều cụm Kafka và thực hiện di chuyển khối lượng công việc theo kế hoạch theo thời gian thay vì di chuyển Kafka quy mô đầy rủi ro.

Đây chỉ là một số lý do tại sao trong thực tế, các doanh nghiệp thấy mình phải tạo nhiều cụm Kafka nhưng vẫn cần tương tác với nhau.

Kafka nhiều cụm

Để có nhiều cụm Kafka được kết nối với nhau, các mục chính từ một cụm phải được sao chép sang (các) cụm khác. Chúng bao gồm các chủ đề, phần bù và siêu dữ liệu. Theo thuật ngữ của Kafka, sự trùng lặp này được coi là Phản chiếu. Có hai cách tiếp cận để thiết lập nhiều cụm có thể thực hiện được. Cụm kéo dài hoặc cụm kết nối.

Cụm kéo dài - Sao chép đồng bộ

Cụm kéo dài là cụm logic được 'kéo dài' trên một số cụm vật lý. Các chủ đề và bản sao được phân phối trên các cụm vật lý, nhưng vì chúng được biểu diễn dưới dạng cụm logic nên bản thân các ứng dụng không nhận thức được tính đa dạng này.

Các cụm kéo dài có tính nhất quán cao và dễ quản lý và điều hành hơn. Vì các ứng dụng không biết đến sự tồn tại của nhiều cụm nên chúng dễ triển khai hơn trên các cụm kéo dài so với các cụm được kết nối.

Nhược điểm của cụm kéo dài là nó yêu cầu kết nối đồng bộ giữa các cụm. Chúng không lý tưởng cho việc triển khai đám mây lai và sẽ yêu cầu số lượng tối thiểu ít nhất 3 cụm để tránh tình huống 'phân chia não'.

Cụm được kết nối - Sao chép không đồng bộ

Mặt khác, Cụm được kết nối được triển khai bằng cách kết nối nhiều cụm độc lập. Các cụm độc lập này có thể chạy ở các vùng hoặc nền tảng đám mây khác nhau và được quản lý riêng lẻ.

Lợi ích chính của mô hình cụm được kết nối là không có thời gian ngừng hoạt động trong trường hợp cụm bị lỗi vì các cụm khác đang chạy độc lập. Mỗi cụm cũng có thể được tối ưu hóa cho các tài nguyên cụ thể của nó.

Nhược điểm chính của các cụm được kết nối là nó dựa vào kết nối không đồng bộ giữa các cụm. Các chủ đề được sao chép giữa các cụm không phải là 'sao chép khi ghi' mà phụ thuộc vào tính nhất quán cuối cùng. Điều này có thể dẫn đến mất dữ liệu trong quá trình sao chép không đồng bộ.

Ngoài ra, các ứng dụng hoạt động trên các cụm được kết nối phải được sửa đổi để nhận biết được nhiều cụm.

Trước khi chúng tôi giải quyết giải pháp cho câu hỏi hóc búa này, tôi sẽ trình bày ngắn gọn về các công cụ phổ biến trên thị trường để kích hoạt kết nối cụm Kafka.

Bản thân Kafka mã nguồn mở cung cấp một công cụ phản chiếu có tên Mirror Maker.

Mirror Maker sao chép chủ đề giữa các cụm khác nhau thông qua trình sản xuất tích hợp sẵn. Bằng cách này, dữ liệu được sao chép chéo giữa các cụm với tính nhất quán cuối cùng nhưng không làm gián đoạn các quy trình riêng lẻ.

Điều quan trọng cần lưu ý là mặc dù Mirror Maker có khái niệm đơn giản nhưng việc thiết lập Mirror Maker trên quy mô lớn có thể là một thách thức khá lớn đối với các tổ chức CNTT. Việc quản lý địa chỉ IP, quy ước đặt tên, số lượng bản sao, v.v. phải được thực hiện chính xác, nếu không nó có thể dẫn đến hiện tượng được gọi là 'sao chép vô hạn' trong đó một chủ đề được sao chép vô hạn, dẫn đến sự cố cuối cùng.

Nhược điểm khác của Mirror Maker là thiếu cấu hình động của danh sách được phép/không được phép cập nhật. Mirror Maker cũng không đồng bộ hóa các thuộc tính chủ đề một cách chính xác, điều này khiến việc vận hành trên quy mô lớn trở nên khó khăn khi thêm hoặc xóa các chủ đề cần sao chép. Mirror Maker 2 cố gắng khắc phục một số thách thức này nhưng nhiều cửa hàng CNTT vẫn gặp khó khăn trong việc thiết lập Mirror Maker chính xác.

Các công cụ Nguồn mở khác để sao chép Kafka bao gồm Mirus từ Salesforce, uReplicator từ Uber và Flink tùy chỉnh từ Netflix .

Đối với các tùy chọn được cấp phép thương mại, Confluent cung cấp hai tùy chọn, Confluent Replicator và Cluster Linking. Confluent Replicator về cơ bản là một trình kết nối Kafka Connect cung cấp một cách hiệu suất cao và linh hoạt để sao chép dữ liệu chủ đề giữa các cụm. Liên kết cụm là một dịch vụ khác, được phát triển nội bộ và nhằm mục đích nhân rộng ở nhiều khu vực trong khi vẫn duy trì sự bù đắp chủ đề.

Mặc dù vậy, Liên kết cụm là một công cụ sao chép không đồng bộ với dữ liệu phải vượt qua ranh giới mạng và đi qua các đường dẫn lưu lượng truy cập công cộng. Như đã rõ, sao chép Kafka là một chiến lược quan trọng cho các ứng dụng sản xuất trên quy mô lớn, câu hỏi đặt ra là nên chọn tùy chọn nào.

Các quản trị viên Kafka giàu trí tưởng tượng sẽ nhanh chóng nhận ra rằng bạn có thể cần các cụm được kết nối và các cụm kéo dài hoặc kết hợp các hoạt động triển khai này, tùy thuộc vào hiệu suất ứng dụng và yêu cầu về khả năng phục hồi.

Tuy nhiên, điều đáng ngại là những thách thức cấp số nhân trong việc thiết lập cấu hình cụm và quản lý chúng trên quy mô lớn trên nhiều cụm. Cách thanh lịch hơn để giải quyết cơn ác mộng này là gì?

KubeSlice của Avesha là một cách đơn giản để tận dụng tối đa cả hai thế giới. Bằng cách tạo Kết nối dịch vụ trực tiếp giữa các cụm hoặc không gian tên, KubeSlice loại bỏ nhu cầu định cấu hình kết nối riêng lẻ theo cách thủ công giữa các cụm Kafka.

Về cốt lõi, KubeSlice tạo ra một cổng mạng Lớp 3 đồng bộ, an toàn giữa các cụm; bị cô lập ở cấp độ ứng dụng hoặc không gian tên. Sau khi thiết lập điều này, quản trị viên Kafka có thể tự do triển khai các nhà môi giới Kafka trong bất kỳ cụm nào.

Mỗi nhà môi giới có kết nối đồng bộ với mọi nhà môi giới khác được tham gia thông qua lát cắt, mặc dù bản thân các nhà môi giới có thể nằm trên các cụm riêng biệt. Điều này tạo ra một cụm kéo dài giữa các nhà môi giới một cách hiệu quả và mang lại lợi ích về tính nhất quán mạnh mẽ và chi phí quản trị thấp.

Lấy phần bánh của mình đi !

Đối với những người muốn triển khai Mirror Maker vào cụm của họ, việc này có thể được thực hiện mà không tốn nhiều công sức vì khả năng kết nối giữa các cụm được ủy quyền cho KubeSlice. Do đó, các ứng dụng Kafka có thể có lợi ích về sao chép đồng bộ (tốc độ, khả năng phục hồi) VÀ không đồng bộ (độc lập, quy mô) trong cùng một quá trình triển khai với khả năng kết hợp và kết hợp các khả năng khi cần thiết. Điều này đúng với các trung tâm dữ liệu tại chỗ, trên các đám mây công cộng hoặc bất kỳ sự kết hợp nào trong số này trong một thiết lập kết hợp.

Điều tuyệt vời nhất là KubeSlice là một quá trình triển khai không gây gián đoạn, nghĩa là không cần phải gỡ cài đặt bất kỳ công cụ nào đã được triển khai. Đó chỉ đơn giản là vấn đề thiết lập một lát cắt và thêm triển khai Kafka vào lát cắt đó.

Phần kết luận

Blog này cung cấp cái nhìn tổng quan ngắn gọn về Apache Kafka và đề cập đến một số trường hợp sử dụng phổ biến hơn. Chúng tôi đã đề cập đến các công cụ hiện có để mở rộng quy mô triển khai Kafka trên nhiều cụm và thảo luận về ưu điểm/nhược điểm của từng cụm. Cuối cùng, bài viết cũng giới thiệu Kubeslice - giải pháp kết nối dịch vụ mới nổi giúp đơn giản hóa việc triển khai nhiều cụm Kafka và loại bỏ những vấn đề đau đầu liên quan đến việc định cấu hình sao chép Kafka trên nhiều cụm trên quy mô lớn.

Một số liên kết mà người đọc có thể thấy hữu ích:

Một blog cũ hơn về các phương pháp hay nhất chạy Kafka trên AWS (trước khi KubeSlice được giới thiệu)

Hướng dẫn thiết lập KubeSlice

Triển khai Kafka trên GKE