#158 - Retry an toàn hơn với Idempotent API

Feb 01, 2021

Những bài viết hay

Airflow 2.0 and Why We Are Excited at Databand — medium.com

Airflow là một nền tảng open source được sử dụng rất phổ biến để tạo lịch trình, lên lịch và theo dõi các workflows. Đối với các bạn DevOps hay Data Engineer, hiểu và sử dụng thành tạo Airflow để thiết lập các workflows hay jobs là một phần không thể thiếu trong công việc thường nhật.

Trong thời gian gần đây, Airflow đã có bản cập nhật đáng kể lên version 2.0 với rất nhiều tính năng mới và cải thiện về performance, như cách viết DAG, hiệu suất của Scheduler, REST API để gọi dữ liệu trong Airflow, hay những thay đổi về mặt giao diện, v.v.

Trong bài viết, tác giả có đề cập đến 2 cải tiến quan trọng: hiệu suất hoạt động của Scheduler và Decorated Airflows.

Về hiệu suất, theo thử nghiệm của tác giả, thời gian phân tích cú pháp DAG đã được cải thiện gấp 10 lần, tốc độ Scheduler và hiệu suất tổng thể của Airflow đều tăng đáng kể.
Với Decorated Flows, nó thay đổi đáng kể cách chúng ta viết ra một DAG. Với những phiên bản cũ, các tasks trong một DAG tương tác với nhau qua XCOM, một lựa chọn không tối ưu khi viết code Python. Việc khởi tạo XCOM có thể không thuận tiện và dễ xảy ra lỗi, chủ yếu là do vấn đề với khả năng đọc code. Airflow 2.0 cung cấp một cách mới để viết DAG sử dụng cú pháp gần giống với cách viết hàm Python tiêu chuẩn, với việc sử dụng Python Decorator. Giờ đây, ta có thể viết DAG bằng cách annotate các hàm Python với decorator để đặt tên nó như là một tác vụ độc lập và kết nối các tác vụ này với nhau một cách dễ dàng bằng cách sử dụng các tham số của chúng.

Making retries safe with idempotent APIs — aws.amazon.com

Retry là một cơ chế để giảm thiểu lỗi không phải do nghiệp vụ mà thường là do cơ sở hạ tầng như network IO, rate limit v.v. Tuy nhiên retry chỉ hiệu quả khi một tác vụ có thể được thử lại nhiều lần mà không có side effects. Điều này trên thực tế là bất khả thi do đó các kỹ sư tại AWS đã lợi dụng tính chất idempotent để xây dựng một workaround solution cho bài toán retry mà không lo lắng vê side effects.

Khi gọi một service, client cần truyền thêm một định danh cho request (ClientRequestIdentifier - unique)
Khi nhận được request, service kiểm tra xem đã từng xử lý request này trước đây hay chưa:

Nếu chưa, service thực thi yêu cầu và tạo "session" cho request
Nếu service ghi nhận đã xử lý request này trước đây, service sẽ trả về kết quả tương ứng

Nói một cách đơn giản là biến một tác vụ non-idempontent thành idempotent bằng cách thực hiện request một lần duy nhất dựa vào ClientRequestIdentifier.

Có nhiều khía cạnh khác cần lưu tâm ở phương pháp này được đề cập trong bài viết gốc, mời bạn đọc xem thêm tại đây.

What's new in OAuth 2.1? — fusionauth.io

OAuth là một giao thức Authorization được sử dụng phổ biến hiện nay. Đặc tả OAuth 2.0 (RFC6749) chính thức phát hành vào tháng 10/2012 thay thế OAuth 1.0 (phát hành 4/2010). Version mới OAuth 2.1 đã được đề xuất và hiện đang được thảo luận. Nếu được thông qua OAuth 2.1 sẽ loại bỏ một số phần ở OAuth 2.0 và tích hợp Security Best Current Practice:

PKCE - Proof Key for Code Exchange (RFC7636) là một dạng mở rộng của Authorization Code Grant. OAuth 2.1, PKCE trở thành default implementation của Authorization Code Grant
Không sử dụng wildcard URI để thiết lập cho Redirect URIs, hay nói cách khác Redirect URIs phải được so sánh chính xác tuyệt đối
Implicit grant và Resource Owner Password Credentials grant bị loại bỏ khỏi đặc tả (specification)
Bearer tokens không được phép sử dụng trên URL (query string)
Refresh tokens phải được giới hạn người cho một client nhất định (Sender-constrained) hoặc sử dụng một lần duy nhất (Refresh token rotation)

Chi tiết về những thay đổi này mời bạn có thể đọc thêm thông tin từ bài viết gốc của tác giả Dan Moore.

Góc Distributed System

Giới thiệu Group Replication Service trong MySQL

MySQL trước đây thực hiện Replication với mô hình Primary-Secondary với primary server được coi là source to replica khi thực hiện toàn bộ việc ghi dữ liệu, gửi transactions tới các replicas để thực hiện việc cập nhật (mô hình shared-nothing - tất cả server giữ full copy). Việc replicate được thực hiện theo hai cách: 1/ asynchronous là master gửi transactions tới replicas rồi thực hiện commit 2/ semisynchronous - master gửi transactions tới replicas, đợi replicas gửi bản tin ACK xác nhận đã nhận được transactions rồi mới thực hiện commit.

Từ version 5.7, MySQL giới thiệu thêm tính năng mới là Group Replication. Tính năng này có thể được sử dụng ở hai dạng: 1/ single-primary với chỉ một master được lựa chọn để ghi dữ liệu và replicate tới các server khác, hoặc 2/ multi-primary cho phép toàn bộ servers đều có thể ghi dữ liệu. Với mô hình multi-primary, MySQL tổng hợp một số kĩ thuật failure-detection, group membership, fault-tolerance vào lại thành giao thức Group Communication System (GCS).

read-write transactions chỉ được commit khi nó nhận đủ “approve” từ group
read-only transactions được commit ngay mà không cần “approve” từ group

MySQL sử dụng Atomic Broadcast để đảm bảo transaction được gửi tới hoặc là toàn bộ nodes hoặc không node nào nhận được. Ngoài ra, total order message delivery cũng đảm bảo các transaction được gửi tới theo đúng thứ tự. Trong quá trình hoạt động sẽ có thể có những transactions xảy ra cùng thời điểm tại hai node khác nhau, quá trình certify sẽ được áp dụng để quyết định transaction nào được ưu tiên thực hiện trước. Giữa các node có xảy ra quá trình đồng thuận (consensus) và Group Replication trong MySQL là eventual consistency.

Chi tiết về quá trình Certify cũng như hành trình của transaction trong Group Replication bạn đọc cụ thể ở link này: http://mysqlhighavailability.com/mysql-group-replication-transaction-life-cycle-explained/

Cơ chế đồng thuận và quản lý membership trong Group Replication của MySQL là một biến thể của thuật toán Paxos, có tên gọi là XCOM (eXtended COMmunication). Cụ thể hoạt động của XCOM mời bạn đọc ở link này: https://mysqlhighavailability.com/the-king-is-dead-long-live-the-king-our-homegrown-paxos-based-consensus/

Code & Tools

This Week Sponsors

POPS is a creative, innovative & hyper-growth working environment where storytelling meets technology.

POPS is the leading digital entertainment company in Southeast Asia. With over 12 years in entertainment, we provide thousands of exclusive, high-quality, carefully curated local and international contents and bring a unique entertainment experience through POPS Original series, concerts, movies, comics, esports and more.

We are on a journey to find talents who are passionate about technology and love to develop POPS APP the digital entertainment product with the latest technologies such as: OTT, Video On Demand, Microservices, etc. to give end users in the region great experiences with an all-inclusive digital entertainment platform.

Góc Tuyển Dụng

Visit https://popsww.com/en/careers for current job openings.

Quotes

If it doesn’t work, it doesn’t matter how fast it doesn’t work.

– Mich Ravera