Đo điểm chuẩn Apache Kafka: Hiệu suất trên mỗi giá

Trong bài viết này, tôi trình bày một nghiên cứu so sánh các môi trường cho Apache Kafka. Mục tiêu cuối cùng là tìm ra cách thiết lập hiệu quả nhất và đạt được tỷ lệ giá/hiệu suất tốt nhất.

Nền tảng dữ liệu của chúng tôi cung cấp các dịch vụ được quản lý để xây dựng nền tảng phân tích cho các tập dữ liệu lớn, cạnh tranh với các giải pháp thị trường khác. Để duy trì tính cạnh tranh, chúng tôi thường xuyên tiến hành nghiên cứu nội bộ để xác định và cải thiện thế mạnh của mình, đảm bảo các giao dịch tốt hơn. Bài viết này giới thiệu một nghiên cứu như vậy. Hiện tại, nền tảng của chúng tôi hỗ trợ AWS và GCP với tư cách là nhà cung cấp đám mây. Cả hai đều cung cấp nhiều thế hệ điện toán và hai kiến trúc CPU (x86 với Intel, AMD và ARM). Tôi so sánh các thiết lập này bằng cách sử dụng nhiều Máy ảo Java (JVM) khác nhau để đánh giá hiệu suất của các phiên bản mới trên các bộ xử lý mới hơn.

Nếu bạn muốn có đá TL; DR: ARM. Kiến trúc hiện đại đắt tiền không phải lúc nào cũng có nghĩa là “tốt hơn”. Bạn có thể xem ngay kết quả hoặc tiếp tục tìm hiểu thêm về phương pháp và cách thiết lập.

Phương pháp luận

Tôi đã cân nhắc việc thử nghiệm hiệu suất bằng dịch vụ của riêng mình nhưng muốn so sánh nó trong các môi trường khác nhau mà chúng tôi chưa hỗ trợ. Tôi muốn khám phá các máy ảo, khu vực mới và thậm chí cả các nhà cung cấp đám mây khác. Vì vậy, tôi bắt đầu bằng cách triển khai một dự án đồ chơi sử dụng Kafka cơ bản với các hình ảnh vùng chứa cơ sở khác nhau. Bằng cách này, tôi có thể chạy các công cụ đo điểm chuẩn trên phần cứng cụ thể và đo lường hiệu suất.

Tôi muốn thử nghiệm các cấu hình khác nhau để xác định kết quả thú vị nhất. Vì vậy, tôi sử dụng ý tưởng về ma trận thử nghiệm để lọc những phát hiện ban đầu. Tôi sẽ phân tích sâu những phát hiện này bằng cách sử dụng các công cụ như perf và eBPF để tinh chỉnh hiệu suất hơn nữa.

Các trường hợp thử nghiệm

Trước tiên hãy mô tả các mục tiêu thử nghiệm. Tôi có nhiều kinh nghiệm với OpenJDK JVM, nhưng ngày nay, có nhiều lựa chọn thay thế từ Microsoft, Amazon và các công ty khác. Ví dụ: Amazon Correto bao gồm các tính năng bổ sung và bản vá được tối ưu hóa cho AWS. Vì hầu hết khách hàng của chúng tôi đều sử dụng AWS nên tôi muốn đưa Amazon Correto vào thử nghiệm để xem các JVM này hoạt động như thế nào trên nền tảng đó.

Tôi đã chọn những phiên bản này để so sánh đầu tiên:

• OpenJDK 11 (để so sánh hồi cứu, mặc dù nó đã lỗi thời)
• OpenJDK 17 (JVM hiện đang được sử dụng)
• Amazon Coretto 11.0.22-amzn (một bản so sánh hồi cứu thay thế)
• Amazon Coretto 17.0.10-amzn (một phiên bản thay thế cho phiên bản hiện tại của chúng tôi)
• Amazon Coretto 21.0.2-amzn (phiên bản LTS mới hơn sẽ tốt hơn)

Sau khi xác định được các phiên bản, tôi đã chuẩn bị một số tập lệnh để xây dựng hình ảnh Kafka bằng Amazon Correto và OpenJDK .

Cài đặt hình ảnh

Đối với các bài kiểm tra điểm chuẩn, tôi đã thay đổi cài đặt Kafka để tập trung vào các số liệu hiệu suất cụ thể. Tôi muốn thử nghiệm các kết hợp khác nhau của [JVM] x [instance_type] x [architecture] x [cloud_provider] , vì vậy điều quan trọng là phải giảm thiểu ảnh hưởng của kết nối mạng và hiệu suất ổ đĩa. Tôi đã làm điều này bằng cách chạy các thùng chứa với tmpfs để lưu trữ dữ liệu:

 podman run -ti \ --network=host \ --mount type=tmpfs,destination=/tmp \ kfbench:3.6.1-21.0.2-amzn-arm64

Đương nhiên, thiết lập này không dành cho sản xuất nhưng việc cách ly các tắc nghẽn CPU và bộ nhớ là cần thiết. Cách tốt nhất là loại bỏ ảnh hưởng của mạng và ổ đĩa khỏi các bài kiểm tra. Nếu không, những yếu tố đó sẽ làm sai lệch kết quả.

Tôi đã sử dụng công cụ đo điểm chuẩn trên cùng một phiên bản để đảm bảo độ trễ tối thiểu và khả năng tái tạo cao hơn. Tôi cũng đã thử kiểm tra mà không cần cấu hình mạng máy chủ và với mạng ảo cách ly cgroup, nhưng những thử nghiệm này chỉ làm tăng thêm độ trễ không cần thiết và tăng mức sử dụng CPU để chuyển tiếp gói.

Mặc dù tmpfs phân bổ bộ nhớ một cách linh hoạt và có thể gây ra hiện tượng phân mảnh cũng như độ trễ nhưng nó vẫn đủ cho thử nghiệm của chúng tôi. Thay vào đó, tôi có thể sử dụng ramdisk để phân bổ bộ nhớ tĩnh và tránh những vấn đề này, nhưng tmpfs dễ triển khai hơn và vẫn cung cấp những hiểu biết sâu sắc mà chúng tôi đang theo đuổi. Đối với mục đích của chúng tôi, nó đạt được sự cân bằng phù hợp.

Ngoài ra, tôi đã áp dụng một số cài đặt Kafka bổ sung để xóa dữ liệu khỏi bộ nhớ thường xuyên hơn:

 ############################# Benchmark Options ############################# # https://kafka.apache.org/documentation/#brokerconfigs_log.segment.bytes # Chaged from 1GB to 256MB to rotate files faster log.segment.bytes = 268435456 # https://kafka.apache.org/documentation/#brokerconfigs_log.retention.bytes # Changed from -1 (unlimited) to 1GB evict them because we run in tmpfs log.retention.bytes = 1073741824 # Changed from 5 minutes (300000ms) to delete outdated data faster log.retention.check.interval.ms=1000 # Evict all data after 15 seconds (default is -1 and log.retention.hours=168 which is ~7 days) log.retention.ms=15000 # https://kafka.apache.org/documentation/#brokerconfigs_log.segment.delete.delay.ms # Changed from 60 seconds delay to small value to prevent memory overflows log.segment.delete.delay.ms = 0

Dưới đây là tóm tắt về những thay đổi:

• Thời gian lưu giữ nhật ký được đặt thành 15 giây để xóa dữ liệu nhanh hơn và kích thước lưu giữ nhật ký được giới hạn ở 1 GB để quản lý bộ nhớ trong tmpfs. Kích thước phân đoạn nhật ký cũng được thay đổi thành 256 MB để xoay tệp nhanh hơn
• Khoảng thời gian Retention check giảm xuống còn 1 giây giúp xóa nhanh dữ liệu cũ
• Độ trễ xóa phân đoạn được đặt thành 0 để tránh các vấn đề về bộ nhớ

Cấu hình này không phù hợp để sử dụng trong sản xuất nhưng nó quan trọng đối với các bài kiểm tra điểm chuẩn của chúng tôi vì nó làm giảm tác động của các yếu tố không liên quan.

Các loại phiên bản

Tại DoubleCloud, tính đến thời điểm viết bài này, chúng tôi hỗ trợ các thế hệ tài nguyên máy tính chính sau:

• họ s1 : các phiên bản m5a (với i1 đại diện cho m5 với bộ xử lý Intel)
• Họ s2 : phiên bản m6a (với i2 đại diện cho m6i với bộ xử lý Intel)
• Họ sg1 : Các phiên bản tiêu chuẩn GCP n2 với bộ xử lý AMD Rome

Đối với bộ xử lý Graviton, chúng tôi hỗ trợ:

• Họ g1 : phiên bản m6g (Graviton 2)
• Họ g2 : phiên bản m7g (Graviton 3)

Ngoài ra, tôi đã thử nghiệm các phiên bản t2a trên GCP thay thế cho Graviton trên Ampere Altra. Chúng tôi không cung cấp những thứ này cho khách hàng do sự hỗ trợ khu vực hạn chế của AWS, nhưng tôi đã đưa chúng vào điểm chuẩn để so sánh hiệu suất. Đây có thể là một lựa chọn tốt nếu bạn đang ở một trong những khu vực “phù hợp”.

Công cụ tính điểm chuẩn

Để đo điểm chuẩn, tôi đã phát triển một công cụ nhẹ dựa trên thư viện franz-go và ví dụ . Công cụ này bão hòa Kafka một cách hiệu quả mà không trở thành nút cổ chai.

Mặc dù librdkafka được biết đến với độ tin cậy và mức độ phổ biến nhưng tôi đã tránh nó do các vấn đề tiềm ẩn với cgo.

Bài kiểm tra

Kafka nổi tiếng với khả năng mở rộng, cho phép chia các chủ đề thành nhiều phân vùng để phân bổ khối lượng công việc theo chiều ngang một cách hiệu quả giữa các nhà môi giới. Tuy nhiên, tôi tập trung đánh giá hiệu suất lõi đơn để tập trung cụ thể vào tỷ lệ hiệu suất trên giá cả.

Do đó, các bài kiểm tra đã sử dụng các chủ đề có các phân vùng duy nhất để tận dụng tối đa các khả năng cốt lõi của từng cá nhân.

Mỗi trường hợp thử nghiệm bao gồm hai loại:

• Sản xuất đồng bộ: chờ xác nhận tin nhắn, lý tưởng để đo các môi trường có độ trễ thấp trong đó mili giây quan trọng, chẳng hạn như các ứng dụng thời gian thực
• Sản xuất không đồng bộ: đệm các tin nhắn và gửi chúng theo đợt, điển hình cho các máy khách Kafka cân bằng nhu cầu gần thời gian thực với độ trễ có thể chấp nhận được là 10-100 mili giây

Tôi đã sử dụng tin nhắn 8 KB, lớn hơn một trường hợp khách hàng trung bình, để bão hòa hoàn toàn các chuỗi phân vùng chủ đề.

Kết quả

Tôi trình bày một loạt sơ đồ so sánh các trường hợp thử nghiệm khác nhau bằng cách sử dụng thước đo hiệu quả tổng hợp để đánh giá các kiến trúc khác nhau. Số liệu này định lượng hàng triệu hàng mà chúng tôi có thể nhập vào phần trăm của nhà môi giới Kafka , cung cấp đánh giá đơn giản về hiệu quả chi phí của kiến trúc.

Điều quan trọng là phải thừa nhận rằng kết quả thực tế có thể thay đổi do các khoản giảm giá bổ sung của nhà cung cấp dịch vụ đám mây. Bất cứ khi nào có thể, các thử nghiệm đều được tiến hành ở Frankfurt cho cả hai nhà cung cấp đám mây (hoặc ở Hà Lan trong trường hợp các tùy chọn loại phiên bản bị hạn chế).

Biểu đồ

Trên tất cả các biểu đồ, tôi sử dụng tên thông thường cho các phiên bản, giống như tên mà nhà cung cấp của họ sử dụng. Các phiên bản được sắp xếp trước tiên theo nhà cung cấp đám mây (AWS, sau đó là GCP) và sau đó theo thế hệ: từ cũ đến mới hơn.

Các kết quả đầy đủ, mặc dù ở dạng thô, đều có sẵn trong bảng điểm chuẩn toàn diện của tôi. Ở đó, bạn có thể tìm thấy nhiều dữ liệu hơn những gì tôi trình bày trong bài viết này, bao gồm số lượng độ trễ và băng thông cũng như hiệu suất so sánh của các JVM khác nhau.

Phát hiện của AWS

Gia đình s1: hiệu suất chậm nhất

Các phiên bản s1 “thế hệ 1” dựa trên thế hệ m5a với AMD EPYC 7571, có từ quý 3 năm 2019, là lựa chọn cũ của chúng tôi. Chúng kém hiệu quả nhất và chậm nhất trong số các lựa chọn của chúng tôi ở Frankfurt, có giá khoảng ~0,2080 €/giờ theo yêu cầu. Chuyển sang dòng s2 mới hơn, có giá ~0,2070 €/giờ, mang lại hiệu quả gấp đôi với cùng một mức giá. Chúng tôi khuyến khích khách hàng chuyển sang các tùy chọn hiệu quả và tiết kiệm chi phí hơn này để nâng cao thời gian truy vấn và tốc độ nhập cho các ứng dụng phân tích.

Dòng g1: hiệu quả tương đương với dòng s2

Dòng g1 dựa trên Graviton 2 và trước đây đã mang lại giá trị tốt, nhưng dòng s2 mới hơn với bộ xử lý AMD hiện phù hợp với mức hiệu quả của nó đối với Apache Kafka. Mặc dù cung cấp băng thông thấp hơn một chút và lợi thế về giá không đáng kể, dòng g1 hiện được coi là lỗi thời so với các tùy chọn mới hơn.

Dòng g2: hiệu quả vượt trội

Dòng g2, được hỗ trợ bởi Graviton 3, nổi bật là đề xuất hàng đầu của chúng tôi nhờ hiệu quả vượt trội. Nó hoạt động tốt hơn dòng s2 và i2 tới 39% trong một số trường hợp nhất định, cung cấp giải pháp tiết kiệm chi phí trên hầu hết các khu vực, khiến nó trở nên lý tưởng cho hầu hết các trường hợp sử dụng Apache Kafka. Với tính chất ràng buộc IO điển hình của Kafka, việc tối ưu hóa hiệu quả tính toán là rất quan trọng để tiết kiệm chi phí. Tôi đã nhận thấy xu hướng áp dụng kiến trúc arm64 ngày càng tăng, với gần một nửa số cụm của chúng tôi đã tận dụng công nghệ mới hơn này.

xu hướng hiệu quả x86_64

Các thử nghiệm cho thấy mọi bộ xử lý AMD hoặc Intel mới đều cải thiện về thông lượng và độ trễ tổng thể. Mặc dù vậy, mức tăng hiệu quả của các thế hệ m6 và m7 mới hơn đã chững lại. Theo thử nghiệm của chúng tôi, ngay cả thế hệ m7, mặc dù có khả năng cung cấp độ trễ thấp hơn ở một số khu vực, nhưng vẫn kém hiệu quả so với dòng g2.

Dòng m7a: hiệu suất độ trễ hàng đầu

Dòng m7a vượt trội trong các ứng dụng có độ trễ thấp, vượt qua cả Intel và các thế hệ AMD trước đó về thông lượng và độ trễ. Mặc dù không phổ biến nhưng kiến trúc này phản ánh sự tiến bộ của AMD trong việc nâng cao hiệu suất. Nếu có sẵn ở khu vực của bạn, hãy xem xét m7a để có kết quả vượt trội.

phát hiện của GCP

So sánh hiệu quả với AWS

Các phiên bản GCP thường có hiệu suất thấp hơn so với các lựa chọn thay thế AWS của chúng. Đây là một thông tin chi tiết tuyệt vời đối với tôi, vì khách hàng thường thích GCP vì tính hiệu quả về mặt chi phí trong các ứng dụng phân tích, dẫn đến chi phí thấp hơn. Dòng sg1 của chúng tôi sử dụng thế hệ tiêu chuẩn n2, có thể so sánh với dòng AWS s2. Tuy nhiên, nỗ lực của tôi nhằm mở rộng sự so sánh này với các loại phiên bản khác bị hạn chế bởi tính khả dụng trong khu vực, đặc biệt là đối với thế hệ c3 và n2.

Bộ xử lý Arm Tau: hiệu quả chi phí

Các phiên bản Arm sử dụng bộ xử lý Tau của GCP mang lại hiệu suất cải thiện 5-7% so với Graviton 2, khiến chúng trở thành một lựa chọn tiết kiệm chi phí hợp lý nếu có ở khu vực của bạn . Mặc dù hỗ trợ GCP cho các phiên bản arm bị giới hạn ở bốn vùng nhưng nó mang lại hiệu năng và hiệu quả tương đương với dòng g1.

Giảm giá sử dụng liên tục

Vì các cụm Apache Kafka thường xuyên sử dụng VM nên việc tận dụng Chiết khấu sử dụng bền vững cho phép giảm giá lên tới 20%. Điều này làm cho sức mạnh tính toán thậm chí cũ hơn, như Ampere Altra, có thể cạnh tranh với Graviton 3 về mặt hiệu quả. Tuy nhiên, việc so sánh trực tiếp ở đây rất khó khăn do các khoản chiết khấu bổ sung của AWS cũng có thể được áp dụng.

Thông tin chi tiết về JVM

Tôi nghĩ rằng tôi sẽ thấy sự cải thiện đáng kể với các phiên bản JVM mới hơn trên kiến trúc ARM. Tuy nhiên, có vẻ như openjdk-11 và corretto-11 đã được tối ưu hóa khá tốt cho ARM. Vì các phiên bản mới hơn của Kafka yêu cầu Java 17 trở lên nên tôi đã chuyển sang Java 17, điều này giúp tăng hiệu suất khoảng 4-8% trong các điểm chuẩn của chúng tôi.

Ngoài ra, 21.0.2-amzn có vẻ đầy hứa hẹn, mang lại hiệu suất tăng thêm 10-20% trên các loại phiên bản mới hơn.

Kết luận

Thỉnh thoảng, tôi thực hiện nghiên cứu nội bộ để tìm ra giải pháp tối ưu cho các cụm sản xuất của mình và thu thập những hiểu biết hữu ích. Việc chuyển sang kiến trúc ARM có lợi cho các dịch vụ được quản lý vì nó tiết kiệm tiền và giảm mức sử dụng năng lượng.

Việc dựa vào ARM đã tỏ ra có lợi, cải thiện hiệu suất và hiệu quả chi phí của cả Dịch vụ được quản lý cho Apache Kafka và Dịch vụ được quản lý cho ClickHouse. Nghiên cứu này đã giúp tinh chỉnh ma trận thử nghiệm của chúng tôi, xác định các môi trường và khu vực hiệu quả nhất để tối ưu hóa hơn nữa. Chúng tôi luôn nỗ lực: tinh chỉnh và cải tiến một cách sâu sắc và tôi rất vui được chia sẻ kiến thức của mình với cộng đồng. Giữ nguyên!