Ensuring High Availability of Ads Realtime Streaming Services

Pinterest · 2021 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bối cảnh

Mảng quảng cáo của Pinterest tăng nhiều lần trong vài năm. Luồng thời gian thực: Ads Server ghi event hiển thị và hành động → Spend Aggregator (Flink) gộp thành event chi tiêu theo nhà quảng cáo → ba service Kafka Streams: Budget Enforcer (dừng chi khi chạm ngân sách ngày/trọn đời), Pacer (dàn chi đều trong ngày), Bidder (chỉnh giá thầu) → Ads Retriever dùng kết quả để lọc ứng viên.
Ba service này hỏng thì mất tiền theo hai chiều: chi vượt (không thu được của nhà quảng cáo, mà chỗ đó lẽ ra cho quảng cáo khác) hoặc chi thiếu (không tiêu hết ngân sách). Giữ 100% uptime với lượng event lớn là rất khó.

Thay đổi chính

Hai pipeline hot-hot giống hệt (primary và standby) cho mỗi service, cô lập hoàn toàn, trên hai cụm Kafka riêng; lịch deploy so le để bug lọt lưới không lên cả hai cùng lúc.
Health Monitor (một ứng dụng Kafka Streams nhỏ) gom "health metric" của từng service mỗi 2–5 phút, dựa trên hai chỉ số: QPS đầu vào (event chi tiêu nhận được mỗi giây) và độ trễ event (từ lúc Spend Aggregator sinh ra tới lúc service nhận). QPS thấp bất thường hoặc trễ cao bất thường thì pipeline bị coi là không khoẻ. Kết quả ghi vào file cấu hình phân tán (ZooKeeper).
Chuyển tự động: Ads Retriever luôn đọc output của cả hai pipeline; một thread nền ở Ads Server đọc trạng thái khoẻ và gắn vào mỗi request truy xuất thông tin "dùng giá trị của pipeline nào". Họ không muốn người trực phải chuyển tay, nhất là ngoài giờ.
Chống flip-flop: bản đầu chuyển qua lại mỗi khoảng 2 phút vì cách Kafka Streams tự hồi phục. Thêm grace period: pipeline phải khoẻ liên tục một khoảng (ví dụ 10 phút) mới được chuyển về.
Bug state store: Health Monitor thấy độ trễ tăng vọt dù upstream và Kafka không tồn đọng. Gốc: stream được repartition về một partition và lưu vào state store, bước xử lý ghi kết quả vào chính state store đó, kích hoạt xử lý lại cùng event thành vòng lặp. Sửa bằng hai state store riêng.

Kết quả (theo Pinterest)

Budget Enforcer dùng đầu tiên, tin cậy với ít công vận hành, đặc biệt mùa lễ khi lượng event và chi tiêu cao; Pacer và Bidder theo sau.

Bài học cho SWE

Hệ streaming khó giữ 100% uptime thì chạy hai pipeline song song và chọn ở phía đọc, thay vì failover bên trong pipeline (Độ tin cậy và multi-region).
Health dựa trên tín hiệu nghiệp vụ (QPS vào, độ trễ event) bắt được cả lỗi ở upstream.
Chuyển tự động cần trễ khi quay lại (hysteresis) để không lật qua lật lại (Tự động hoá vận hành và auto-remediation).
Deploy so le giữa hai bản dự phòng để một bug không hạ cả hai.
Kafka Streams che giấu đường dữ liệu bên trong; vòng lặp qua state store chỉ lộ ra qua độ trễ (Event-driven, message queue và Kafka).