Ghi chú. bản dịch.: Trong bài viết này, Banzai Cloud chia sẻ một ví dụ về cách sử dụng các công cụ tùy chỉnh của nó để giúp Kafka dễ sử dụng hơn trong Kubernetes. Các hướng dẫn sau minh họa cách bạn có thể xác định kích thước tối ưu của cơ sở hạ tầng của mình và tự định cấu hình Kafka để đạt được thông lượng cần thiết.
Apache Kafka là một nền tảng phát trực tuyến phân tán để tạo các hệ thống phát trực tuyến thời gian thực đáng tin cậy, có thể mở rộng và hiệu suất cao. Khả năng ấn tượng của nó có thể được mở rộng bằng Kubernetes. Đối với điều này, chúng tôi đã phát triển và một công cụ tên là . Chúng cho phép bạn chạy Kafka trên Kubernetes và sử dụng các tính năng khác nhau của nó, chẳng hạn như tinh chỉnh cấu hình môi giới, chia tỷ lệ dựa trên số liệu với tính năng tái cân bằng, nhận biết về giá, “mềm” (duyên dáng) tung ra các bản cập nhật, v.v.
Hãy thử Supertubes trong cụm của bạn:
curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>Hoặc liên hệ . Bạn cũng có thể đọc về một số khả năng của Kafka, công việc được tự động hóa bằng cách sử dụng toán tử Supertubes và Kafka. Chúng tôi đã viết về họ trên blog:
- ;
- ;
- ;
- ;
- ;
- ;
- .
Khi quyết định triển khai cụm Kafka trên Kubernetes, bạn có thể sẽ phải đối mặt với thách thức trong việc xác định kích thước tối ưu của cơ sở hạ tầng cơ bản và nhu cầu tinh chỉnh cấu hình Kafka của mình để đáp ứng các yêu cầu về thông lượng. Hiệu suất tối đa của mỗi nhà môi giới được xác định bởi hiệu suất của các thành phần cơ sở hạ tầng cơ bản, chẳng hạn như bộ nhớ, bộ xử lý, tốc độ ổ đĩa, băng thông mạng, v.v.
Lý tưởng nhất là cấu hình của nhà môi giới phải sao cho tất cả các yếu tố cơ sở hạ tầng được sử dụng với khả năng tối đa của chúng. Tuy nhiên, trong thực tế việc thiết lập này khá phức tạp. Nhiều khả năng người dùng sẽ định cấu hình các trình môi giới để tối đa hóa việc sử dụng một hoặc hai thành phần (đĩa, bộ nhớ hoặc bộ xử lý). Nói chung, một nhà môi giới thể hiện hiệu suất tối đa khi cấu hình của nó cho phép sử dụng tối đa thành phần chậm nhất. Bằng cách này, chúng ta có thể biết sơ bộ về tải trọng mà một nhà môi giới có thể xử lý.
Về mặt lý thuyết, chúng ta cũng có thể ước tính số lượng nhà môi giới cần thiết để xử lý một lượng tải nhất định. Tuy nhiên, trong thực tế có rất nhiều tùy chọn cấu hình ở các cấp độ khác nhau nên rất khó (nếu không nói là không thể) đánh giá hiệu suất tiềm năng của một cấu hình cụ thể. Nói cách khác, rất khó lập kế hoạch cấu hình dựa trên hiệu suất nhất định.
Đối với người dùng Supertubes, chúng tôi thường thực hiện cách tiếp cận sau: chúng tôi bắt đầu với một số cấu hình (cơ sở hạ tầng + cài đặt), sau đó đo hiệu suất của nó, điều chỉnh cài đặt của nhà môi giới và lặp lại quy trình. Điều này xảy ra cho đến khi thành phần chậm nhất của cơ sở hạ tầng được sử dụng đầy đủ.
Bằng cách này, chúng ta có được ý tưởng rõ ràng hơn về số lượng nhà môi giới mà một cụm cần để xử lý một tải nhất định (số lượng nhà môi giới cũng phụ thuộc vào các yếu tố khác, chẳng hạn như số lượng bản sao thông báo tối thiểu để đảm bảo khả năng phục hồi, số lượng phân vùng). người lãnh đạo, v.v.). Ngoài ra, chúng tôi còn hiểu rõ hơn về những thành phần cơ sở hạ tầng nào yêu cầu mở rộng quy mô theo chiều dọc.
Bài viết này sẽ nói về các bước chúng tôi thực hiện để tận dụng tối đa các thành phần chậm nhất trong cấu hình ban đầu và đo lường thông lượng của cụm Kafka. Một cấu hình có khả năng phục hồi cao cần có ít nhất ba nhà môi giới đang chạy (min.insync.replicas=3), được phân bổ trên ba vùng tiếp cận khác nhau. Để định cấu hình, mở rộng quy mô và giám sát cơ sở hạ tầng Kubernetes, chúng tôi sử dụng nền tảng quản lý vùng chứa của riêng mình cho các đám mây lai - . Nó hỗ trợ tại chỗ (bare metal, VMware) và năm loại đám mây (Alibaba, AWS, Azure, Google, Oracle), cũng như bất kỳ sự kết hợp nào của chúng.
Suy nghĩ về cơ sở hạ tầng và cấu hình cụm Kafka
Đối với các ví dụ bên dưới, chúng tôi đã chọn AWS làm nhà cung cấp đám mây và EKS làm bản phân phối Kubernetes. Một cấu hình tương tự có thể được thực hiện bằng cách sử dụng - Phân phối Kubernetes từ Banzai Cloud, được chứng nhận bởi CNCF.
Lái
Amazon cung cấp nhiều loại . cốt lõi gp2 и io1 tuy nhiên vẫn có ổ SSD để đảm bảo thông lượng cao gp2 tiêu thụ tín dụng tích lũy (Tín dụng I/O), vì vậy chúng tôi ưa thích loại io1, cung cấp thông lượng cao nhất quán.
Các loại phiên bản
Hiệu suất của Kafka phụ thuộc nhiều vào bộ đệm trang của hệ điều hành, vì vậy chúng tôi cần các phiên bản có đủ bộ nhớ cho trình môi giới (JVM) và bộ đệm trang. Ví dụ c5.2xlarge - một khởi đầu tốt vì nó có bộ nhớ 16 GB và . Nhược điểm của nó là chỉ có khả năng cung cấp hiệu suất tối đa không quá 30 phút mỗi 24 giờ. Nếu khối lượng công việc của bạn yêu cầu hiệu năng cao nhất trong khoảng thời gian dài hơn, bạn có thể muốn xem xét các loại phiên bản khác. Đó chính xác là những gì chúng tôi đã làm, dừng lại ở c5.4xlarge. Nó cung cấp thông lượng tối đa trong 593,75 Mb/giây. Thông lượng tối đa của một ổ EBS io1 cao hơn ví dụ c5.4xlarge, do đó, yếu tố chậm nhất của cơ sở hạ tầng có thể là thông lượng I/O của loại phiên bản này (điều mà các thử nghiệm tải của chúng tôi cũng sẽ xác nhận).
Сеть
Thông lượng mạng phải đủ lớn so với hiệu suất của phiên bản VM và ổ đĩa, nếu không mạng sẽ trở thành nút cổ chai. Trong trường hợp của chúng tôi, giao diện mạng c5.4xlarge hỗ trợ tốc độ lên tới 10 Gb/s, cao hơn đáng kể so với thông lượng I/O của phiên bản VM.
Triển khai môi giới
Các nhà môi giới nên được triển khai (được lên lịch trong Kubernetes) đến các nút chuyên dụng để tránh cạnh tranh với các quy trình khác về tài nguyên CPU, bộ nhớ, mạng và ổ đĩa.
Phiên bản Java
Lựa chọn hợp lý là Java 11 vì nó tương thích với Docker theo nghĩa là JVM xác định chính xác bộ xử lý và bộ nhớ có sẵn cho vùng chứa mà nhà môi giới đang chạy. Biết rằng giới hạn CPU là quan trọng, JVM thiết lập nội bộ và minh bạch số lượng luồng GC và luồng JIT. Chúng tôi đã sử dụng hình ảnh Kafka banzaicloud/kafka:2.13-2.4.0, bao gồm Kafka phiên bản 2.4.0 (Scala 2.13) trên Java 11.
Nếu bạn muốn tìm hiểu thêm về Java/JVM trên Kubernetes, hãy xem các bài đăng sau của chúng tôi:
- ;
- .
Cài đặt bộ nhớ môi giới
Có hai khía cạnh chính để định cấu hình bộ nhớ môi giới: cài đặt cho JVM và cho nhóm Kubernetes. Giới hạn bộ nhớ được đặt cho một nhóm phải lớn hơn kích thước vùng heap tối đa để JVM có chỗ cho siêu không gian Java nằm trong bộ nhớ của chính nó và cho bộ đệm trang của hệ điều hành mà Kafka tích cực sử dụng. Trong các thử nghiệm của mình, chúng tôi đã khởi chạy các nhà môi giới Kafka với các tham số -Xmx4G -Xms2Gvà giới hạn bộ nhớ cho nhóm là 10 Gi. Xin lưu ý rằng cài đặt bộ nhớ cho JVM có thể được lấy tự động bằng cách sử dụng -XX:MaxRAMPercentage и -X:MinRAMPercentage, dựa trên giới hạn bộ nhớ cho nhóm.
Cài đặt bộ xử lý môi giới
Nói chung, bạn có thể cải thiện hiệu suất bằng cách tăng tính song song bằng cách tăng số lượng luồng được Kafka sử dụng. Càng có nhiều bộ xử lý cho Kafka thì càng tốt. Trong thử nghiệm của mình, chúng tôi bắt đầu với giới hạn 6 bộ xử lý và dần dần (thông qua các lần lặp lại) đã nâng số lượng của chúng lên 15. Ngoài ra, chúng tôi đặt num.network.threads=12 trong cài đặt môi giới để tăng số lượng luồng nhận dữ liệu từ mạng và gửi nó. Ngay lập tức phát hiện ra rằng các nhà môi giới theo dõi không thể nhận được bản sao đủ nhanh, họ đã huy động num.replica.fetchers lên 4 để tăng tốc độ mà người môi giới theo dõi sao chép thông điệp từ các nhà lãnh đạo.
Công cụ tạo tải
Bạn nên đảm bảo rằng trình tạo tải đã chọn không hết công suất trước khi cụm Kafka (đang được đo điểm chuẩn) đạt mức tải tối đa. Nói cách khác, cần phải tiến hành đánh giá sơ bộ về khả năng của công cụ tạo tải, đồng thời chọn loại phiên bản có đủ số lượng bộ xử lý và bộ nhớ cho nó. Trong trường hợp này, công cụ của chúng tôi sẽ tạo ra nhiều tải hơn mức mà cụm Kafka có thể xử lý. Sau nhiều thử nghiệm, chúng tôi đã quyết định được ba bản sao c5.4xlarge, mỗi nơi đều có một máy phát điện đang chạy.
Đo điểm chuẩn
Đo lường hiệu suất là một quá trình lặp đi lặp lại bao gồm các giai đoạn sau:
- thiết lập cơ sở hạ tầng (cụm EKS, cụm Kafka, công cụ tạo tải, cũng như Prometheus và Grafana);
- tạo tải trong một khoảng thời gian nhất định để lọc các sai lệch ngẫu nhiên trong các chỉ số hiệu suất được thu thập;
- điều chỉnh cơ sở hạ tầng và cấu hình của nhà môi giới dựa trên các chỉ số hiệu suất được quan sát;
- lặp lại quá trình cho đến khi đạt được mức thông lượng cụm Kafka cần thiết. Đồng thời, nó phải có khả năng tái tạo nhất quán và thể hiện sự thay đổi tối thiểu về thông lượng.
Phần tiếp theo mô tả các bước được thực hiện trong quá trình đo điểm chuẩn của cụm thử nghiệm.
Dụng cụ
Các công cụ sau đây được sử dụng để nhanh chóng triển khai cấu hình cơ sở, tạo tải và đo lường hiệu suất:
- để tổ chức cụm EKS từ Amazon c (để thu thập số liệu Kafka và cơ sở hạ tầng) và (để trực quan hóa các số liệu này). Chúng tôi đã tận dụng lợi thế tích hợp в các dịch vụ cung cấp chức năng giám sát liên kết, thu thập nhật ký tập trung, quét lỗ hổng, khắc phục thảm họa, bảo mật cấp doanh nghiệp và nhiều dịch vụ khác.
- - một công cụ để kiểm tra tải cụm Kafka.
- Bảng điều khiển Grafana để trực quan hóa các số liệu và cơ sở hạ tầng của Kafka: , .
- Supertubes CLI để biết cách dễ dàng nhất để thiết lập cụm Kafka trên Kubernetes. Zookeeper, Kafka operator, Envoy và nhiều thành phần khác được cài đặt và định cấu hình đúng cách để chạy cụm Kafka sẵn sàng sản xuất trên Kubernetes.
- Để cài đặt siêu ống CLI sử dụng các hướng dẫn được cung cấp .
Cụm EKS
Chuẩn bị một cụm EKS với các nút công nhân chuyên dụng c5.4xlarge trong các vùng sẵn sàng khác nhau dành cho các nhóm có nhà môi giới Kafka, cũng như các nút chuyên dụng cho cơ sở hạ tầng giám sát và tạo tải.
banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.jsonKhi cụm EKS được thiết lập và chạy, hãy kích hoạt tính năng tích hợp của nó — cô ấy sẽ triển khai Prometheus và Grafana thành một cụm.
Các thành phần hệ thống Kafka
Cài đặt các thành phần hệ thống Kafka (Zookeeper, kafka-operator) trong EKS bằng supertubes CLI:
supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>Cụm Kafka
Theo mặc định, EKS sử dụng loại khối lượng EBS gp2, vì vậy bạn cần tạo một lớp lưu trữ riêng dựa trên khối lượng io1 cho cụm Kafka:
kubectl create -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
type: io1
iopsPerGB: "50"
fsType: ext4
volumeBindingMode: WaitForFirstConsumer
EOF
Đặt tham số cho nhà môi giới min.insync.replicas=3 và triển khai nhóm môi giới trên các nút ở ba vùng khả dụng khác nhau:
supertubes cluster create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/kafka_202001_3brokers.yaml --wait --timeout 600Chủ đề
Chúng tôi đã chạy song song ba phiên bản trình tạo tải. Mỗi người trong số họ viết theo chủ đề riêng của mình, nghĩa là chúng ta cần tổng cộng ba chủ đề:
supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
name: perftest1
spec:
name: perftest1
partitions: 12
replicationFactor: 3
retention.ms: '28800000'
cleanup.policy: delete
EOF
supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
name: perftest2
spec:
name: perftest2
partitions: 12
replicationFactor: 3
retention.ms: '28800000'
cleanup.policy: delete
EOF
supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
name: perftest3
spec:
name: perftest3
partitions: 12
replicationFactor: 3
retention.ms: '28800000'
cleanup.policy: delete
EOFĐối với mỗi chủ đề, hệ số sao chép là 3—giá trị tối thiểu được đề xuất cho các hệ thống sản xuất có tính sẵn sàng cao.
Công cụ tạo tải
Chúng tôi đã đưa ra ba bản sao của trình tạo tải (mỗi bản viết theo một chủ đề riêng). Đối với nhóm trình tạo tải, bạn cần đặt mối quan hệ của nút để chúng chỉ được lên lịch trên các nút được phân bổ cho chúng:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
app: loadtest
name: perf-load1
namespace: kafka
spec:
progressDeadlineSeconds: 600
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
app: loadtest
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
creationTimestamp: null
labels:
app: loadtest
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: nodepool.banzaicloud.io/name
operator: In
values:
- loadgen
containers:
- args:
- -brokers=kafka-0:29092,kafka-1:29092,kafka-2:29092,kafka-3:29092
- -topic=perftest1
- -required-acks=all
- -message-size=512
- -workers=20
image: banzaicloud/perfload:0.1.0-blog
imagePullPolicy: Always
name: sangrenel
resources:
limits:
cpu: 2
memory: 1Gi
requests:
cpu: 2
memory: 1Gi
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30Một số điểm cần lưu ý:
- Trình tạo tải tạo các tin nhắn có độ dài 512 byte và xuất bản chúng lên Kafka theo lô 500 tin nhắn.
- Sử dụng một đối số
-required-acks=allViệc xuất bản được coi là thành công khi tất cả các bản sao đồng bộ của tin nhắn đều được các nhà môi giới Kafka nhận và xác nhận. Điều này có nghĩa là trong điểm chuẩn, chúng tôi không chỉ đo tốc độ nhận thông điệp của các nhà lãnh đạo mà còn cả những người theo dõi họ sao chép thông điệp. Mục đích của bài kiểm tra này không phải để đánh giá tốc độ đọc của người tiêu dùng (người tiêu dùng) các tin nhắn nhận được gần đây vẫn còn trong bộ đệm của trang hệ điều hành và so sánh nó với tốc độ đọc các tin nhắn được lưu trữ trên đĩa. - Máy tạo tải chạy song song 20 công nhân (
-workers=20). Mỗi công nhân có 5 nhà sản xuất chia sẻ kết nối của công nhân với cụm Kafka. Kết quả là, mỗi trình tạo có 100 nhà sản xuất và tất cả họ đều gửi tin nhắn đến cụm Kafka.
Theo dõi tình trạng của cụm
Trong quá trình kiểm tra tải của cụm Kafka, chúng tôi cũng theo dõi tình trạng của cụm Kafka để đảm bảo không có lần khởi động lại nhóm nào, không có bản sao không đồng bộ và thông lượng tối đa với biến động tối thiểu:
- Trình tạo tải ghi số liệu thống kê tiêu chuẩn về số lượng tin nhắn được xuất bản và tỷ lệ lỗi. Tỷ lệ lỗi phải giữ nguyên
0,00%. - , được triển khai bởi kafka-operator, cung cấp một bảng điều khiển nơi chúng ta cũng có thể theo dõi trạng thái của cụm. Để xem bảng này, hãy làm:
supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> - cấp độ ISR (số lượng bản sao “không đồng bộ”) co lại và giãn nở đều bằng 0.
Kết quả đo lường
3 nhà môi giới, kích thước tin nhắn - 512 byte
Với các phân vùng được phân bổ đều trên ba nhà môi giới, chúng tôi có thể đạt được hiệu suất ~500 Mb/giây (khoảng 990 nghìn tin nhắn mỗi giây):
Mức tiêu thụ bộ nhớ của máy ảo JVM không vượt quá 2 GB:
Thông lượng ổ đĩa đã đạt thông lượng nút I/O tối đa trên cả ba phiên bản mà trình môi giới đang chạy:
Từ dữ liệu về mức sử dụng bộ nhớ của các nút, có thể thấy rằng bộ đệm và bộ nhớ đệm của hệ thống chiếm khoảng 10-15 GB:
3 nhà môi giới, kích thước tin nhắn - 100 byte
Khi kích thước tin nhắn giảm, thông lượng giảm khoảng 15-20%: thời gian xử lý mỗi tin nhắn sẽ ảnh hưởng đến nó. Ngoài ra, tải của bộ xử lý đã tăng gần gấp đôi.
Vì các nút môi giới vẫn còn lõi chưa được sử dụng nên hiệu suất có thể được cải thiện bằng cách thay đổi cấu hình Kafka. Đây không phải là một nhiệm vụ dễ dàng, vì vậy để tăng thông lượng thì tốt hơn nên làm việc với các tin nhắn lớn hơn.
4 nhà môi giới, kích thước tin nhắn - 512 byte
Bạn có thể dễ dàng tăng hiệu suất của cụm Kafka bằng cách thêm các trình môi giới mới và duy trì sự cân bằng của các phân vùng (điều này đảm bảo rằng tải được phân bổ đồng đều giữa các trình môi giới). Trong trường hợp của chúng tôi, sau khi thêm một nhà môi giới, thông lượng của cụm tăng lên ~580 Mb/giây (~1,1 triệu tin nhắn mỗi giây). Sự tăng trưởng hóa ra thấp hơn mong đợi: điều này chủ yếu được giải thích là do sự mất cân bằng giữa các phân vùng (không phải tất cả các nhà môi giới đều hoạt động ở mức cao nhất khả năng của họ).
Mức tiêu thụ bộ nhớ của máy JVM vẫn ở mức dưới 2 GB:
Công việc của những người môi giới với ổ đĩa bị ảnh hưởng do sự mất cân bằng của các phân vùng:
Những phát hiện
Cách tiếp cận lặp lại được trình bày ở trên có thể được mở rộng để bao gồm các tình huống phức tạp hơn liên quan đến hàng trăm người tiêu dùng, phân vùng lại, cập nhật luân phiên, khởi động lại nhóm, v.v. Tất cả điều này cho phép chúng tôi đánh giá các giới hạn về khả năng của cụm Kafka trong các điều kiện khác nhau, xác định các điểm nghẽn trong hoạt động của nó và tìm cách giải quyết chúng.
Chúng tôi đã thiết kế Supertubes để triển khai một cụm, định cấu hình cụm đó một cách nhanh chóng và dễ dàng, thêm/xóa các nhà môi giới và chủ đề, phản hồi các cảnh báo và đảm bảo Kafka nói chung hoạt động bình thường trên Kubernetes. Mục tiêu của chúng tôi là giúp bạn tập trung vào nhiệm vụ chính (“tạo” và “tiêu thụ” tin nhắn Kafka) và giao mọi công việc khó khăn cho Supertubes và người điều hành Kafka.
Nếu bạn quan tâm đến công nghệ Banzai Cloud và các dự án Nguồn mở, hãy đăng ký với công ty tại , hoặc .
Tái bút từ người dịch
Đọc thêm trên blog của chúng tôi:
- «»;
- «»;
- «'.
Nguồn: www.habr.com