Resiliency and Disaster Recovery with Kafka

eBay · 2020 · 3. Quy mô lớn · Độ khó: Nâng cao — bài gốc

Bối cảnh

Team Motors Vertical (eBay Classifieds Group) chạy phần mềm ở nhiều region, định kỳ diễn tập tắt cả một region. Kafka là thành phần quan trọng nhất, nhưng chạy Kafka nhiều cluster active/active vẫn khó, kể cả với MirrorMaker 2.0 (Kafka 2.4).
Bài toán: mỗi listing (tin đăng) phát event khi tạo, sửa, xoá; consumer chống gian lận, gửi thông báo, index search, khuyến mãi. Có hai nhóm consumer:
- chỉ cần event của region mình, ít nhất một lần;
- cần toàn bộ dữ liệu của mọi region (index search mỗi region riêng, join trong Kafka Streams).
Kafka chỉ bảo đảm thứ tự trong một partition của một cluster, không bảo đảm giữa nhiều cluster. Topic listing lại dùng log compaction và tombstone.

Bốn phương án (theo tác giả)

Active/active + mirror topic (MirrorMaker 2 tạo topic có tiền tố theo cluster nguồn, consumer đọc bằng regex): đủ dữ liệu, nhưng mất thứ tự. Các phiên bản v1, v3 ở region 1 và v2, v4 ở region 2; sau compaction và tombstone có thể còn lại bản cũ ở cả hai nơi.
Ghi toàn cục, đọc cục bộ: topic cần thứ tự chỉ ghi vào một cluster, rồi mirror đi. Có thứ tự, nhưng:
- consumer đọc trùng (webhook bị gọi hai lần, tốn tiền vì dịch vụ bên thứ ba tính theo lượt gọi);
- cluster chính chết thì producer mất kết nối, và phần chưa kịp mirror (bất đồng bộ) bị mất;
- region xa chịu thêm latency.
Active/passive: đơn giản, có thứ tự. Đổi lại cụm passive ngồi không, region xa chịu latency, và offset của consumer group khác nhau giữa hai cluster. MirrorMaker 2 có checkpoint offset và RemoteClusterUtils để dịch offset, nhưng service phải tự biết mình đang chuyển cluster, tra offset và chỉ làm một lần. Làm sai thì đọc lại từ đầu.
Active/active + Kafka Streams sắp lại thứ tự: gửi số phiên bản của document trong header, một service sắp theo phiên bản rồi ghi ra topic listing.ordered. Chạy được, nhưng tốn công, thêm latency và tài nguyên. Tác giả khuyên không sắp theo timestamp ("không có thời điểm hiện tại").

Kết luận (theo tác giả)

Mỗi cách đều có giá. Với nhiều trường hợp, một cluster trải trên 3 AZ của một region có thể đã đủ sẵn sàng. Thiết kế đơn giản của Kafka làm nó rẻ và nhanh, nhưng chính thiết kế đó không hợp với đa region active/active hay active/passive.

Bài học cho SWE

Thứ tự event chỉ được bảo đảm trong một log. Nhân bản sang nhiều cluster là mất thứ tự, trừ khi có một nơi ghi duy nhất hoặc số phiên bản để sắp lại (Realtime và fan-out).
Failover hệ streaming không chỉ là đổi địa chỉ broker: còn offset của consumer và việc xử lý trùng (Độ tin cậy và multi-region).
Cân nhắc lại có thật cần đa region không: nhiều AZ trong một region thường đã đủ. Cùng câu hỏi với Coinbase (mất một AZ) và WarpStream (bán cụm đa region như tính năng cao cấp).