Thanh niên ở Việt Nam thì đã quen với ứng dụng thanh toán trực tuyến như Momo/ZaloPay để mua hàng online. Ở công ty Fxx thì có thêm Utop, ứng dụng tự nguyện bắt buộc để trả tiền ăn uống, cafe ở canteen. Tuy nhiên shoping online như Amazon, eBay thì thế giới người ta xài Visa và Paypal. Paypal là ứng dụng thanh toán trực tuyến và chuyển tiền quốc tế, quá nổi tiếng rồi
Theo thống kê thì đến Q1/2023, Paypal có khoảng 429 triệu người dùng, 19.3 tỉ transaction năm 2021 và 1.2 nghìn tỉ $ được processed . Mỗi một ngày, Paypal xử lý 41 triệu transaction
Với lượng data growth, transaction lớn như thế thì PayPal làm thế nào để xử lý được?? Kỹ sư Paypal đã sử dụng Kafka trong hệ thống của mình
Kafka là gì, kiến trúc thế nào thì trên Google giải thích nhiều rồi, tuy nhiên nội dung hàn lâm quá đọc có khả năng bị lú nên giaosucan’s blog sẽ giải thích ngắn gọn cho dễ hiểu như sau
Tưởng tượng một hệ thống bán hàng online như lazada, đây là hệ thống phân tán gồm nhiều microservice kết nối với nhau
Booking service gọi vào Payment service
Payment service write data vào database
Chat service connect vào real time monitoring
XX kết với YYY
Nếu kết nối trực tiếp thì sẽ tạo thành 1 đống hỗn độn spagetty
Để giải quyết vấn đề này thì kafka ra đời. Kafka tách rời các data pipeline giữa các hệ thống để làm cho việc communicate giữa các hệ thống trở nên đơn giản hơn và dễ quản lý hơn, hoạt động theo cơ chế Pub/Sub
Thế câu hỏi đặt ra, communicate giữa các service thì có message bus, AMQP hàng đầy ra đó, cần gì phải đẻ ra anh Kafka, vì nhìn chức năng giữa Kafka và AMQP là na ná nhau. Ví dụ như cái hệ thống Lazada ở trên thì xài RabbitMQ là đủ rồi còn giề.
Vấn đề ở đây là use case.
Use case 1: Hãy xem một hệ thống như Grab, khi bạn book Grab, rồi giở map lên xem, sẽ thấy Grab lại cập nhật vị trí của tài xế liên tục. Bởi vì trên Grab trên máy của tài xế (producer) liên tục gửi message chứa driver_id và driver_position đến 1 topic driver_gps, Grab của user sẽ consume message này và hiển thị lên. Grab thì có đến hàng chục triệu tài xế. Tức là Grab cần data realtime streaming độ vài trăm K hoặc triệu message/second. Case này AMQP như RabbitMQ với max throughput tầm 40K+ message/seconds không đáp ứng nổi nhưng Kafka thì throughput lên tới 1T message/seconds, nó sẽ giải quyết được bài toán
Use case 2: Đối với RabbitMQ, message được lưu trong queue, sau khi application consume message thì nó bị remove khỏi queue. Nhưng với Kafka, message vẫn nằm đó ngay cả khi application consume the message, tức là có thể re-process lại tất cả những message đã consume trước đó. Chức năng lại rất tiện, nếu như application có bug phải deploy lại version khác và re-process những message bị lỗi trước đó.
Kafka at Paypal
Tại Paypal, Kafka được sử dụng vào collection application logs, batch processing, đồng bộ hóa database, streaming application metrics, trung bình khoảng 100 tỉ message một ngày
Hiên tại hệ thống của Paypal có khoảng 85+ kafka cluster, 1500 broker chứa 20K topic. Vào ngày black friday 2022, traffic volume tại thời điểm peak là 1.3 nghìn tỉ message/day.
Lượng data streaming lớn như thế thì bài toán Scaling Kafka cần được giải. Cái khó ở đây là Kafka là Stateful , cho nên làm sao scaling kafka cluster mà đảm bảo data vẫn consistency mới là vấn đề
Kafka cluster của Paypal được deploy cross zone
Để replicas data giữa Kafka cluster, Paypal sử dụng MirrorMaker để replicas data giữa source và target Kafka cluster
Idea là sử dụng Kafka consumer để consume message từ Source cluster rồi produce vào topic của Kafka target.
Quản lý Kafka
Kafka Config Service
Với hơn 85+ Kafka cluster, Paypal đã phát triển một số giải pháp trong việc quản cluster, monitor & alert, configuration management và enhancement
Message Kafka được lưu ở topic, topic này lưu trên 1 server instance gọi là Kafka broker, 1 Kafka cluster sẽ bao nhiều broker (mult-servers), như nói ở trên thì Paypal có khoảng 1500+ broker/server
Mỗi broker sẽ có IP/ID tương ứng được quản lý bởi zookeeper , các application phải hardcode những IP broker mà nó muốn kết nối tới. Trong khi team infra của Paypal thường xuyên upgrade thay thế các broker, nên IP thay đổi liên tục. Cho nên việc maintance hơn 1500+ broker sẽ là thảm họa nếu làm theo cách này , do đó SRE team mới phát triển Kafka config service
Tức là các thông tin của Kafka Metadata (IP/Config) sẽ được đọc từ Kafka config service, client app thay vì hardcode những Kafka info này trong app thì chỉ việc gọi API của Kafka config service là xong, Kafka Config Service sẽ làm phần còn lại.
Kafka Security
Kafka của Paypal có 20K+ topic, mỗi topic chứa data khác nhau, nếu application nào cũng access lấy data từ mọi topic thì cả một vấn đề về security . Paypal đã phát triển Access Control Lists (ACL), phân quyền access vào Kafka cluster, đại loại app muốn gain access vào cluster và topic là phải có authorization
Có thể hiểu ACL làm một pluggable authorization framework (Authorizer), được set trong Kafka broker config
file, ACL được lưu trong Zookeeper
authorizer.class.name=kafka.security.authorizer.AclAuthorizer
Nếu đã lưu ACL trong Zookeeper thì phải enable ZK security lên đảm bảo chỉ admin mới được access
zookeeper.set.acl=true
Enable ZK authen bằng SASL
authProvider.sasl=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
Việc cuối cùng là là làm sao monitoring được hơn 85+ Kafka cluster này, đón đọc bài sau
0 Nhận xét