Đây là bài đăng được đồng sáng tác với Rivlin Pereira & Vaibhav Pandey từ Tanzu CloudHealth (VMware by Broadcom).

VMware Tanzu CloudHealth là nền tảng quản lý chi phí đám mây được hơn 20,000 tổ chức trên toàn thế giới lựa chọn. Họ dựa vào nền tảng này để tối ưu hóa và quản lý môi trường nhiều đám mây lớn nhất và phức tạp nhất của họ. Trong bài đăng này, chúng tôi thảo luận về cách nhóm VMware Tanzu CloudHealth DevOps di chuyển khối lượng công việc Apache Kafka tự quản lý của họ (chạy phiên bản 2.0) sang Truyền trực tuyến được quản lý của Amazon cho Apache Kafka (Amazon MSK) đang chạy phiên bản 2.6.2. Chúng tôi thảo luận về kiến ​​trúc hệ thống, quy trình triển khai, tạo chủ đề, khả năng quan sát, kiểm soát truy cập, di chuyển chủ đề và tất cả các vấn đề chúng tôi gặp phải với cơ sở hạ tầng hiện có, cùng với cách thức và lý do chúng tôi chuyển sang thiết lập Kafka mới cũng như một số bài học kinh nghiệm.

Tổng quan về cụm Kafka

Trong bối cảnh phát triển nhanh chóng của các hệ thống phân tán, nền tảng vi dịch vụ thế hệ tiếp theo của VMware Tanzu CloudHealth dựa vào Kafka làm xương sống nhắn tin. Đối với chúng tôi, hệ thống nhật ký phân tán hiệu suất cao của Kafka vượt trội trong việc xử lý các luồng dữ liệu lớn, khiến hệ thống này không thể thiếu cho giao tiếp liền mạch. Hoạt động như một hệ thống nhật ký phân tán, Kafka ghi lại và lưu trữ các nhật ký đa dạng một cách hiệu quả, từ nhật ký truy cập máy chủ HTTP đến nhật ký kiểm tra sự kiện bảo mật.

Tính linh hoạt của Kafka tỏa sáng trong việc hỗ trợ các mẫu tin nhắn chính, coi tin nhắn dưới dạng nhật ký cơ bản hoặc kho lưu trữ khóa-giá trị có cấu trúc. Phân vùng động và sắp xếp nhất quán đảm bảo tổ chức tin nhắn hiệu quả. Độ tin cậy vững chắc của Kafka phù hợp với cam kết của chúng tôi về tính toàn vẹn dữ liệu.

Việc tích hợp các dịch vụ Ruby với Kafka được sắp xếp hợp lý thông qua thư viện Karafka, hoạt động như một trình bao bọc cấp cao hơn. Các dịch vụ ngăn xếp ngôn ngữ khác của chúng tôi sử dụng các trình bao bọc tương tự. Các tính năng gỡ lỗi mạnh mẽ và các lệnh quản trị của Kafka đóng vai trò then chốt trong việc đảm bảo hoạt động trơn tru và tình trạng cơ sở hạ tầng.

Kafka như một cột trụ kiến ​​trúc

Trong nền tảng vi dịch vụ thế hệ tiếp theo của VMware Tanzu CloudHealth, Kafka nổi lên như một trụ cột kiến ​​trúc quan trọng. Khả năng xử lý tốc độ dữ liệu cao, hỗ trợ các kiểu nhắn tin đa dạng và đảm bảo việc gửi tin nhắn phù hợp liền mạch với nhu cầu hoạt động của chúng tôi. Khi chúng tôi tiếp tục đổi mới và mở rộng quy mô, Kafka vẫn là người bạn đồng hành kiên định, cho phép chúng tôi xây dựng cơ sở hạ tầng linh hoạt và hiệu quả.

Tại sao chúng tôi chuyển sang Amazon MSK

Đối với chúng tôi, việc di chuyển sang Amazon MSK có ba điểm quyết định chính:

• Hoạt động kỹ thuật đơn giản hóa – Chạy Kafka trên cơ sở hạ tầng tự quản lý là một chi phí hoạt động đối với chúng tôi. Chúng tôi đã không cập nhật Kafka phiên bản 2.0.0 trong một thời gian và các nhà môi giới Kafka đang ngừng sản xuất, gây ra sự cố với các chủ đề ngoại tuyến. Chúng tôi cũng phải chạy các tập lệnh theo cách thủ công để tăng hệ số sao chép và cân bằng lại các chỉ huy dẫn đầu, đây là một nỗ lực bổ sung thủ công.
• Các quy trình cũ không được dùng nữa và các quyền được đơn giản hóa – Chúng tôi đang tìm cách loại bỏ các quy trình hiện có được viết bằng Có khả năng để tạo chủ đề Kafka trên cụm. Chúng tôi cũng có một quy trình phức tạp trong việc cấp cho các thành viên trong nhóm quyền truy cập vào máy Kafka trong quá trình dàn dựng và sản xuất, đồng thời chúng tôi muốn đơn giản hóa việc này.
• Chi phí, vá lỗi và hỗ trợ - Bởi vì Người quản lý vườn thú Apache được quản lý và vá lỗi hoàn toàn bởi AWS, việc chuyển sang Amazon MSK sẽ giúp chúng tôi tiết kiệm thời gian và tiền bạc. Ngoài ra, chúng tôi phát hiện ra rằng việc chạy Amazon MSK với cùng loại nhà môi giới trên Đám mây điện toán đàn hồi Amazon (Amazon EC2) chạy trên Amazon MSK rẻ hơn. Kết hợp với thực tế là chúng tôi nhận được các bản vá bảo mật do AWS áp dụng cho các nhà môi giới, việc chuyển sang Amazon MSK là một quyết định dễ dàng. Điều này cũng có nghĩa là nhóm được tự do để làm những việc quan trọng khác. Cuối cùng, việc nhận được sự hỗ trợ dành cho doanh nghiệp từ AWS cũng rất quan trọng trong quyết định cuối cùng của chúng tôi là chuyển sang giải pháp được quản lý.

Cách chúng tôi di chuyển sang Amazon MSK

Sau khi xác định được các trình điều khiển chính, chúng tôi đã tiến hành thiết kế được đề xuất để di chuyển Kafka tự quản lý hiện có sang Amazon MSK. Chúng tôi đã tiến hành các bước di chuyển trước sau đây trước khi triển khai thực tế:

• Đánh giá:
  • Đã tiến hành đánh giá tỉ mỉ về cụm EC2 Kafka hiện có, tìm hiểu cấu hình và các phần phụ thuộc của nó
  • Đã xác minh khả năng tương thích của phiên bản Kafka với Amazon MSK
• Thiết lập Amazon MSK với Terraform
• Cấu hình mạng:
  • Đảm bảo kết nối mạng liền mạch giữa cụm EC2 Kafka và MSK, tinh chỉnh các nhóm bảo mật và cài đặt tường lửa

Sau các bước di chuyển trước, chúng tôi đã triển khai những nội dung sau cho thiết kế mới:

• Quy trình triển khai, nâng cấp và tạo chủ đề tự động cho cụm MSK:
  • Trong thiết lập mới, chúng tôi muốn triển khai và nâng cấp tự động các cụm MSK theo cách có thể lặp lại bằng cách sử dụng công cụ IaC. Do đó, chúng tôi đã tạo các mô-đun Terraform tùy chỉnh để triển khai cũng như nâng cấp cụm MSK. Các mô-đun này được gọi từ một Jenkins đường dẫn để triển khai và nâng cấp tự động các cụm MSK. Để tạo chủ đề Kafka, chúng tôi đã sử dụng quy trình trồng tại nhà dựa trên Ansible, quy trình này không ổn định và dẫn đến nhiều khiếu nại từ các nhóm phát triển. Kết quả là chúng tôi đã đánh giá các tùy chọn để triển khai Kubernetes các cụm và sử dụng Toán tử chủ đề Strimzi để tạo chủ đề trên cụm MSK. Việc tạo chủ đề được tự động hóa bằng cách sử dụng quy trình Jenkins mà nhóm nhà phát triển có thể tự phục vụ.
• Khả năng quan sát tốt hơn cho các cụm:
  • Các cụm Kafka cũ không có khả năng quan sát tốt. Chúng tôi chỉ có cảnh báo về kích thước đĩa của nhà môi giới Kafka. Với Amazon MSK, chúng tôi đã tận dụng được giám sát mở sử dụng Prometheus. Chúng tôi đã thiết lập một máy chủ Prometheus độc lập để lấy số liệu từ các cụm MSK và gửi chúng đến công cụ quan sát nội bộ của chúng tôi. Nhờ khả năng quan sát được cải thiện, chúng tôi đã có thể thiết lập cảnh báo mạnh mẽ cho Amazon MSK, điều không thể thực hiện được với thiết lập cũ của chúng tôi.
• COGS được cải thiện và cơ sở hạ tầng điện toán tốt hơn:
  • Đối với cơ sở hạ tầng Kafka cũ của chúng tôi, chúng tôi phải trả tiền để quản lý các phiên bản Kafka, Zookeeper, cộng với mọi chi phí lưu trữ môi giới bổ sung và chi phí truyền dữ liệu. Với việc chuyển sang Amazon MSK, vì Zookeeper hoàn toàn do AWS quản lý nên chúng tôi chỉ phải trả phí cho các nút Kafka, chi phí lưu trữ của nhà môi giới và chi phí truyền dữ liệu. Kết quả là, trong quá trình thiết lập Amazon MSK cuối cùng cho hoạt động sản xuất, chúng tôi không chỉ tiết kiệm được chi phí cơ sở hạ tầng mà còn cả chi phí vận hành.
• Đơn giản hóa hoạt động và tăng cường bảo mật:
  • Với việc chuyển sang Amazon MSK, chúng tôi không phải quản lý bất kỳ phiên bản Zookeeper nào. Bản vá bảo mật của nhà môi giới cũng được AWS đảm nhiệm cho chúng tôi.
  • Việc nâng cấp cụm trở nên đơn giản hơn khi chuyển sang Amazon MSK; đó là một quá trình đơn giản để bắt đầu từ bảng điều khiển Amazon MSK.
  • Với Amazon MSK, chúng tôi có nhà môi giới tự động mở rộng quy mô ngoài cái hộp. Kết quả là chúng tôi không phải lo lắng về việc các nhà môi giới hết dung lượng ổ đĩa, từ đó dẫn đến sự ổn định hơn nữa của cụm MSK.
  • Chúng tôi cũng nhận được mức bảo mật bổ sung cho cụm vì theo mặc định, Amazon MSK hỗ trợ mã hóa ở trạng thái lưu trữ và cũng có sẵn nhiều tùy chọn khác nhau để mã hóa khi truyền. Để biết thêm thông tin, hãy tham khảo Bảo vệ dữ liệu trong Amazon Managed Streaming cho Apache Kafka.

Trong các bước trước khi di chuyển, chúng tôi đã xác thực thiết lập trên môi trường chạy thử trước khi tiếp tục sản xuất.

Chiến lược di chuyển chủ đề Kafka

Khi quá trình thiết lập cụm MSK hoàn tất, chúng tôi đã thực hiện di chuyển dữ liệu các chủ đề Kafka từ cụm cũ chạy trên Amazon EC2 sang cụm MSK mới. Để đạt được điều này, chúng tôi đã thực hiện các bước sau:

• Thiết lập MirrorMaker với Terraform – Chúng tôi đã sử dụng Terraform để sắp xếp việc triển khai một Máy làm gương cụm gồm 15 nút. Điều này chứng tỏ khả năng mở rộng và tính linh hoạt bằng cách điều chỉnh số lượng nút dựa trên nhu cầu sao chép đồng thời của quá trình di chuyển.
• Triển khai chiến lược sao chép đồng thời – Chúng tôi đã triển khai chiến lược sao chép đồng thời với 15 nút MirrorMaker để đẩy nhanh quá trình di chuyển. Cách tiếp cận dựa trên Terraform của chúng tôi đã góp phần tối ưu hóa chi phí bằng cách quản lý hiệu quả các tài nguyên trong quá trình di chuyển, đồng thời đảm bảo độ tin cậy và tính nhất quán của cụm MSK và MirrorMaker. Nó cũng giới thiệu cách thiết lập đã chọn tăng tốc truyền dữ liệu, tối ưu hóa cả thời gian và tài nguyên.
• Di chuyển dữ liệu – Chúng tôi đã di chuyển thành công 2 TB dữ liệu trong một khung thời gian ngắn đáng kể, giảm thiểu thời gian ngừng hoạt động và thể hiện tính hiệu quả của chiến lược sao chép đồng thời.
• Thiết lập giám sát sau di chuyển – Chúng tôi đã triển khai tính năng giám sát và cảnh báo mạnh mẽ trong quá trình di chuyển, góp phần giúp quá trình di chuyển diễn ra suôn sẻ bằng cách xác định và giải quyết kịp thời các vấn đề.

Sơ đồ sau minh họa kiến ​​trúc sau khi quá trình di chuyển chủ đề hoàn tất.

Những thách thức và bài học kinh nghiệm

Bắt tay vào hành trình di chuyển, đặc biệt là với các bộ dữ liệu lớn, thường đi kèm với những thách thức không lường trước được. Trong phần này, chúng tôi đi sâu vào những thách thức gặp phải trong quá trình di chuyển các chủ đề từ EC2 Kafka sang Amazon MSK bằng MirrorMaker, đồng thời chia sẻ những hiểu biết sâu sắc và giải pháp có giá trị đã định hình nên sự thành công của quá trình di chuyển của chúng tôi.

Thử thách 1: Bù đắp sự khác biệt

Một trong những thách thức mà chúng tôi gặp phải là sự không khớp về độ lệch chủ đề giữa cụm nguồn và cụm đích, ngay cả khi đã bật đồng bộ hóa độ lệch trong MirrorMaker. Bài học rút ra ở đây là các giá trị offset không nhất thiết phải giống hệt nhau, miễn là tính năng đồng bộ hóa offset được bật, điều này đảm bảo các chủ đề có vị trí chính xác để đọc dữ liệu.

Chúng tôi đã giải quyết vấn đề này bằng cách sử dụng một công cụ tùy chỉnh để chạy thử nghiệm trên các nhóm người tiêu dùng, xác nhận rằng chênh lệch đã dịch nhỏ hơn hoặc bắt kịp, biểu thị sự đồng bộ hóa theo MirrorMaker.

Thử thách 2: Di chuyển dữ liệu chậm

Quá trình di chuyển gặp phải nút thắt cổ chai—truyền dữ liệu chậm hơn dự kiến, đặc biệt là với tập dữ liệu có dung lượng lớn 2 TB. Mặc dù có cụm MirrorMaker 20 nút nhưng tốc độ vẫn không đủ.

Để khắc phục điều này, nhóm đã nhóm các nút MirrorMaker một cách chiến lược dựa trên số cổng duy nhất. Các cụm gồm năm nút MirrorMaker, mỗi nút có một cổng riêng biệt, đã tăng thông lượng đáng kể, cho phép chúng tôi di chuyển dữ liệu trong vòng vài giờ thay vì vài ngày.

Thử thách 3: Thiếu tài liệu quy trình chi tiết

Việc điều hướng lãnh thổ chưa được khám phá trong việc di chuyển các tập dữ liệu lớn bằng MirrorMaker đã nêu bật việc thiếu tài liệu chi tiết cho các tình huống như vậy.

Thông qua thử nghiệm và sai sót, nhóm đã tạo ra mô-đun IaC bằng cách sử dụng Terraform. Mô-đun này đã sắp xếp hợp lý toàn bộ quy trình tạo cụm với các cài đặt được tối ưu hóa, cho phép bắt đầu di chuyển liền mạch trong vòng vài phút.

Thiết lập cuối cùng và các bước tiếp theo

Do việc chuyển sang Amazon MSK, thiết lập cuối cùng của chúng tôi sau khi di chuyển chủ đề trông giống như sơ đồ sau.

Chúng tôi đang xem xét những cải tiến sau đây trong tương lai:

Kết luận.

Trong bài đăng này, chúng tôi đã thảo luận về cách VMware Tanzu CloudHealth di chuyển cơ sở hạ tầng Kafka dựa trên Amazon EC2 hiện có của họ sang Amazon MSK. Chúng tôi đã hướng dẫn bạn về kiến ​​trúc mới, quy trình triển khai và tạo chủ đề, các cải tiến về khả năng quan sát và kiểm soát quyền truy cập, các thách thức di chuyển chủ đề cũng như các vấn đề chúng tôi gặp phải với cơ sở hạ tầng hiện tại, cùng với cách thức và lý do chúng tôi di chuyển sang thiết lập Amazon MSK mới. Chúng tôi cũng nói về tất cả những lợi ích mà Amazon MSK đã mang lại cho chúng tôi, kiến ​​trúc cuối cùng mà chúng tôi đạt được trong quá trình di chuyển này và các bài học kinh nghiệm.

Đối với chúng tôi, sự tương tác giữa đồng bộ hóa offset, nhóm nút chiến lược và IaC đã chứng minh vai trò then chốt trong việc vượt qua các trở ngại và đảm bảo quá trình di chuyển thành công từ Amazon EC2 Kafka sang Amazon MSK. Bài đăng này đóng vai trò là minh chứng cho sức mạnh của khả năng thích ứng và đổi mới trong các thách thức di cư, cung cấp thông tin chi tiết cho những người khác đang đi theo con đường tương tự.

Nếu bạn đang chạy Kafka tự quản lý trên AWS, chúng tôi khuyến khích bạn dùng thử sản phẩm Kafka được quản lý, Amazon MSK.

Về các tác giả

Rivlin Pereira là Kỹ sư DevOps nhân viên tại VMware Tanzu Division. Anh ấy rất đam mê Kubernetes và làm việc trên CloudHealth Platform, xây dựng và vận hành các giải pháp đám mây có khả năng mở rộng, đáng tin cậy và tiết kiệm chi phí.

Vaibhav Pandey, Kỹ sư phần mềm nhân viên tại Broadcom, là người đóng góp quan trọng vào việc phát triển các giải pháp điện toán đám mây. Chuyên về kiến ​​trúc và kỹ thuật các lớp lưu trữ dữ liệu, anh đam mê xây dựng và mở rộng quy mô các ứng dụng SaaS để có hiệu suất tối ưu.

Raj Ramasubbu là Kiến trúc sư giải pháp chuyên gia phân tích cao cấp tập trung vào dữ liệu lớn và phân tích cũng như AI/ML với Amazon Web Services. Anh ấy giúp khách hàng thiết kế kiến ​​trúc và xây dựng các giải pháp dựa trên đám mây có khả năng mở rộng, hiệu quả và bảo mật cao trên AWS. Raj đã cung cấp kiến ​​thức chuyên môn kỹ thuật và khả năng lãnh đạo trong việc xây dựng kỹ thuật dữ liệu, phân tích dữ liệu lớn, giải pháp kinh doanh thông minh và khoa học dữ liệu trong hơn 18 năm trước khi gia nhập AWS. Ông đã giúp khách hàng trong nhiều ngành dọc khác nhau như chăm sóc sức khỏe, thiết bị y tế, khoa học đời sống, bán lẻ, quản lý tài sản, bảo hiểm xe hơi, REIT nhà ở, nông nghiệp, bảo hiểm quyền sở hữu, chuỗi cung ứng, quản lý tài liệu và bất động sản.

Todd McGrath là chuyên gia truyền dữ liệu tại Amazon Web Services, nơi ông tư vấn cho khách hàng về chiến lược truyền phát, tích hợp, kiến ​​trúc và giải pháp của họ. Về mặt cá nhân, anh ấy thích quan sát và hỗ trợ 3 thiếu niên của mình trong các hoạt động yêu thích của chúng cũng như theo đuổi những sở thích của riêng mình như câu cá, ném bóng ném, khúc côn cầu trên băng và giờ vui vẻ cùng bạn bè và gia đình trên thuyền phao. Kết nối với anh ấy trên LinkedIn.

Satya Pattanaik là Kiến trúc sư giải pháp cấp cao tại AWS. Anh ấy đã và đang giúp ISV xây dựng các ứng dụng có khả năng mở rộng và linh hoạt trên Đám mây AWS. Trước khi gia nhập AWS, anh đóng vai trò quan trọng trong các phân khúc Doanh nghiệp với sự phát triển và thành công của chúng. Ngoài công việc, anh dành thời gian học “cách nấu món BBQ thơm ngon” và thử các công thức nấu ăn mới.

• Phân phối nội dung và PR được hỗ trợ bởi SEO. Được khuếch đại ngay hôm nay.
• PlatoData.Network Vertical Generative Ai. Trao quyền cho chính mình. Truy cập Tại đây.
• PlatoAiStream. Thông minh Web3. Kiến thức khuếch đại. Truy cập Tại đây.
• Trung tâmESG. Than đá, công nghệ sạch, Năng lượng, Môi trường Hệ mặt trời, Quản lý chất thải. Truy cập Tại đây.
• PlatoSức khỏe. Tình báo thử nghiệm lâm sàng và công nghệ sinh học. Truy cập Tại đây.
• nguồn: https://aws.amazon.com/blogs/big-data/how-vmware-tanzu-cloudhealth-migrated-from-self-managed-kafka-to-amazon-msk/