#170 - Dịch vụ Quotas ở Grab - xử lý bài toán API rate limiting nội bộ

May 10, 2021

Tối thứ 7 ngày 08/05, Grokking đã tổ chức Webinar #9 về những công việc kỹ thuật liên quan tới data, không chỉ giới hạn trong Data Science mà còn mở rộng cho Data Engineering hay Machine Learning Engineering, dựa trên chia sẻ từ hai khách mời dày dặn kinh nghiệm trong lĩnh vực này, anh Lộc và anh Đức. Bạn có thể xem lại chi tiết tại đường link sau:

https://www.youtube.com/watch?v=lLIBaT0pKmY

Những bài viết hay

Hiểu rõ hơn về Data lake

Data lake là gì? Làm thế nào để một data lake phù hợp với các chiến lược dữ liệu doanh nghiệp? Bài viết đi sâu giải thích các thắc mắc, lầm tưởng phổ biến liên quan đến các chiến lược, triển khai, hạng tầng kiến trúc, qua đó giúp chúng ta có cái nhìn chi tiết và đơn giản hơn về data lake. Phá vỡ những lầm tưởng này sẽ giúp giải thích tại sao chúng ta sử dụng data lake không hiệu quả và gặp nhiều thách thức. Bài viết cũng chỉ ra những tình huống mà phía vendor hay consultant có thể cung cấp một giải pháp trái ngược với best practices khi làm việc với data lake.

Data lake khác với data warehouse. Không có gì lạ khi tìm thấy lời khuyên đưa ra sự lựa chọn giữa data warehouse truyền thống, cloud data warehouse hoặc data lake để truy cập dữ liệu. Sự lựa chọn giữa data warehouse hay data lake là một sự lựa chọn sai lầm vì chúng khác nhau về bản chất và mục đích sử dụng. Thay vì tranh luận về việc sử dụng data lake khác hay data warehouse, cuộc thảo luận đúng đắn dành cho hầu hết các doanh nghiệp là làm sao để chúng cùng tồn tại, qua đó giúp tối ưu hóa nguồn dữ liệu, giúp ích cho các mục đích business khác nhau.

Data lake khác với Hadoop. Đôi khi, bạn thường sẽ tìm thấy các cuộc thảo luận và ví dụ trong đó data lake tương tự hoặc liên quan đến Apache Hadoop. Việc quảng bá mô hình hệ sinh thái Hadoop tạo ấn tượng rằng data lake có ràng buộc chặt chẽ với các công nghệ cụ thể. Trong khi Hadoop được sử dụng trong một số data lake, chúng không phản ánh chiến lược và kiến trúc của data lake. Cần phải hiểu rằng data lake phải phản ánh một cách tiếp cận, chiến lược và kiến trúc, chứ không phải một công nghệ nhất định nào đó.

Data lake không chỉ là một nơi để lưu trữ. Data lake không giống một ổ cứng trong máy tính, nơi mà bạn ném tất cả các files vào mà thậm chí không cần đặt tên cho folder. Nếu được đóng gói và cấu trúc một cách chính xác, một data lake có thể cung cấp giá trị cho các downstream services sử dụng dữ liệu từ nó, bao gồm cả data warehouse, qua đó mang lại các giá trị nhất định từ nguồn dữ liệu cho doanh nghiệp.

Ngoài ra, tác giả cũng phân tích những lỗi hay lầm tưởng về Data lake chúng ta hay gặp như: Data lake chỉ chứa raw data, chỉ sử dụng cho Big Data, bảo mật thấp, thiếu phân loại dữ liệu hay data governance v.v.

Đảm bảo CI/CD pipelines an toàn trước các rủi ro về bảo mật

Trong những năm gần đây, các lỗ hổng bảo mật đã gây ra nhiều vụ rò rỉ dữ liệu người dùng nghiêm trọng. Để hạn chế các rủi ro về bảo mật, hầu hết các công ty xây dựng nhiều lớp bảo mật khác nhau thay vì chỉ có một tầng bảo vệ là tường lửa (firewall).

Tuy nhiên một thực tế dễ nhận thấy cho dù với nhiều lớp phòng thủ khác nhau nhưng có một lỗ hổng cố hữu không thể nào ngăn chặn được đó là con người. Do đó, thay vì ngăn chặn con người mắc sai lầm, các công ty chuyển hướng sang xây dựng các quy trình tự động nhằm loại bỏ yếu tố con người.

CI/CD (Continuous Integration/Continuous Delivery) là nơi tốt nhất để thêm các lớp bảo mật vì có ít sự can thiệp của con người. Sau khi tự động hoá quá trình tạo các tài nguyên cần thiết cho service như server, database, phân quyền... (thường được biết đến với infrastructure as code ), các kỹ sư sẽ không cần yêu cầu các quyền truy cập vào cơ sở hạ tầng để tạo các tài nguyên này một cách thủ công như trước.

Ngoài ra, bạn cũng có thêm nhiều sự lựa chọn khác khi triển khai bảo mật tại CI/CD:

Scanning hệ thống một cách dễ dàng. Có rất nhiều công cụ giúp bạn scan mã nguồn (source code) để phát hiện các lỗ hổng bảo mật trong các thư viện đang sử dụng. Ngoài mã nguồn, bạn cũng có thể scan container và infrastructure để
Thực thi các bài test bảo mật (Security testing). CI/CD cũng có thể thực thi các kiểm tra bảo mật khác nhau giúp bạn phát hiện ra vấn đề bảo mật sớm hơn (shift left).

Sau khi đã thiết lập xong CI/CD pipelines với nhiều lớp bảo mật khác nhau, công việc tiếp theo là giám sát và kiểm soát các CI/CD pipelines này để đảm bảo chúng hoạt động như mong đợi.

Starting a New App With Redux? Consider Context API First

Trước đây, nếu bạn cần xây dựng ứng dụng React từ đầu, Redux dường như là sự lựa chọn mặc định để quản lý state. Các phiên bản React mới nhất đưa ra nhiều tính năng quản lí state tiện lợi và hiệu quả. Câu hỏi đặt ra lúc này, Redux có còn là sự lựa chọn mặc định nữa hay không? Trong một số trường hợp đơn giản, sử dụng redux có thể overkill, hooks và Context API có thể thay thế Redux.

Một trong những lý do để sử dụng Redux là giải quyết truyền props từ component cha xuống các tất cả các components con. Với Context API, bạn cũng có thể giải quyết vấn đề này.

Chúng ta có thể sử dụng kết hợp hooks và Context API để thay thế Redux như application settings, fetch data từ server và chia sẻ data giữa các components khác nhau.

Một ví dụ phức tạp hơn, xây dựng form cho người dùng nhập liệu, câu chuyện giờ đã trở nên phức tạp hơn rất nhiều vì chúng ta phải xử lý rất nhiều events khác nhau, validate input, thông báo lỗi v.v. Trong trường hợp này, lời khuyên là chúng ta nên dùng Formik thay vì hooks + Context API hay Redux.

Context API cũng có một số hạn chế nhất định ví dụ một khi data được lưu trong Provider thay đổi, tất cả các components con sẽ re-render điều này có thể ảnh hưởng tới performance của ứng dụng. Ngoài ra, Context API chỉ thích hợp cho các ứng dụng đơn giản, nếu ứng dụng của bạn đủ phức tạp, Redux vẫn là một lựa chọn hợp lý.

Góc Distributed System

Dịch vụ Quotas ở Grab - xử lý bài toán API rate limiting nội bộ

Trong microservices, các vấn đề như service discovery, security, load balancing, monitoring và rate limiting là những bài toán khó. Bài viết này mô tả Quotas service được xây dựng ở Grab để giải quyết bài toán API rate limiting cho các microservices nội bộ Grab. Quotas được sử dụng cho toàn bộ services của Grab, do đó nó cần phải thiết kế đảm bảo high scale và high reliability. Grab thiết kế Quotas đi theo những guidelines sau:

Cung cấp thin client implementation (SDK) cho các services sử dụng Quotas để chuẩn hoá
Sử dụng asynchronous processing pipeline tăng khả năng scale cho Quotas.
Cho phép horizontally autoscaling Quotas tự động thông qua config, tránh bottle neck bởi toàn bộ Grab microservices sẽ sử dụng Quotas.

Vì lẽ đó, Quotas sử dụng Kafka làm trung tâm.

Các services sẽ gửi API usage information tới Quotas thông qua các Kafka topics riêng. Các Quotas instances (stateless, autoscaled) sẽ consume thông tin và xử lý.
Quotas gửi các quyết định về Rate limiting cũng thông qua các Kafka topics riêng và Quotas SDK trên các services sẽ consume thông tin đó và update local rate-limiting cache.
Có một thành phần là Archiver sẽ lưu các Kafka events lên AWS S3 cho các bài toán phân tích phụ.

Quotas client-side logic:

Mỗi service khi sử dụng Quotas sẽ sử dụng hai thành phần: Quotas middleware và Quotas SDK. Quotas middleware khi nhận API request tới sẽ thực hiện:

gửi API request info cho server qua Kafka
Nhận quyết định rate limit từ Quotas SDK để xử lý request

Quotas SDK có nhiệm vụ:

Nhận quyết định rate limit từ Quotas server thông qua Kafka
Cập nhật local cache.

Quotas server-side logic:

Tổng hợp API usages thông qua API request counts từ các Kafka topics.
Cập nhật rate counters vào hệ thống Redis
Quyết định rate limiting, gửi quyết định về service thông qua Kafka topic
Một số tích hợp khác về monitoring & alert lên Datadog.

Để tối ưu bài toán Kafka stream, Grab tự xây dựng hệ thống Sprinkler, cung cấp SDK cho các service sử dụng (build on top of OSS tên là Sarama). Thuật toán sử dụng trong Quotas là sliding window, với mức 1 giây và 5 giây. Một số thông tin benchmark nội bộ cũng được cung cấp trong bài viết. Mời bạn đọc chi tiết ở link này:

https://engineering.grab.com/quotas-service

Code & Tools

This Week Sponsors

Theo đuổi sứ mệnh rút ngắn khoảng cách giữa con người, thông tin và dịch vụ, LINE đã phát triển thành nền tảng mạng xã hội với hàng trăm triệu người dùng thường xuyên trên toàn cầu, tập trung chiến lược vào thị trường châu Á vốn luôn tăng trưởng sôi động.

Là một trung tâm phát triển của Tập đoàn LINE, đội ngũ LINE Technology Vietnam đang sát cánh cùng LINE toàn cầu xây dựng và tối ưu các ứng dụng, dịch vụ đa dạng quanh hệ sinh thái LINE.

Góc Tuyển Dụng

See other openings at LINE Technology Vietnam

Quotes

A good programmer is someone who always looks both ways before crossing a one-way street.

– Doug Linder