Định tuyến Lưu lượng Video Châu Á - Thái Bình Dương với etcd

Một nền tảng phát video trực tuyến phục vụ tám thị trường Châu Á - Thái Bình Dương đã chấm dứt một lỗi định tuyến lặp đi lặp lại bằng cách chuyển các cấu hình đặc thù theo khu vực vào etcd. Thời gian lan truyền các thay đổi định tuyến đã giảm xuống còn khoảng một giây. Các biên tập viên giờ đây có thể tăng cường một kho nhạc trong vài giờ mà không cần chạm vào mã nguồn, và nền tảng đã ngừng gửi luồng dữ liệu từ Tokyo cho người xem tại Hàn Quốc.

Tại sao cách tiếp cận cũ bị lỗi

Mỗi bộ định tuyến (router) đọc ba giá trị cho mỗi yêu cầu: kho nhạc đang thịnh hành (trending pool), bộ tách từ (tokenizer) theo ngôn ngữ, và một chuỗi dự phòng. Các quyết định kinh doanh—như quảng bá một nghệ sĩ mới, phản ứng với sự cố khu vực, hay thử nghiệm thuật toán gợi ý—là yếu tố thúc đẩy các giá trị này, chứ không phải là các thay đổi về mã nguồn.

Ban đầu, mỗi lần triển khai đều đi kèm với một tệp JSON chứa bảng định tuyến. Trong một sự cố, một kỹ sư trực ca đã chỉnh sửa tệp trên một nút (node) để chuyển lưu lượng sang một kho dự phòng nhưng lại không cập nhật bảy nút còn lại. Sự sai lệch cấu hình (config drift) đã xuất hiện: tám quốc gia chạy các bảng định tuyến khác nhau, và không có một nguồn duy nhất nào xác minh được "sự thật". Lỗi gửi người xem ở Seoul đến Tokyo vẫn tồn tại vì mã nguồn không đổi; chỉ có cấu hình ẩn là khác nhau.

Chọn etcd làm nguồn sự thật duy nhất

Nhóm đã so sánh ba lựa chọn:

  • SQLite/MySQL – sẽ buộc mỗi router phải thăm dò (poll) cơ sở dữ liệu, làm tăng độ trễ hoặc gây quá tải các truy vấn.
  • Consul – một công cụ khám phá dịch vụ (service-discovery) mạnh mẽ, nhưng nền tảng không cần đến toàn bộ các tính năng mesh của nó.
  • etcd – một kho lưu trữ key-value có tính nhất quán mạnh với cơ chế watch giúp thông báo cho các client ngay khi một key thay đổi.

Tính năng watch đã làm thay đổi cục diện. Thay vì mỗi router liên tục hỏi "có gì thay đổi không?", các router sẽ ở trạng thái chờ cho đến khi etcd đẩy bản cập nhật tới. Lưu lượng mạng không cần thiết biến mất và mọi thực thể (instance) đều nhận được thông tin về thay đổi cùng một lúc.

Các mô hình giúp hệ thống an toàn

Bản thân etcd không giải quyết được mọi rủi ro. Các kỹ sư đã bổ sung thêm ba mô hình bổ trợ:

  1. Leases – một biên tập viên có thể thiết lập một đợt tăng cường tạm thời (ví dụ: tăng trọng số của một kho nhạc K-pop trong sáu giờ). Lease sẽ tự động hết hạn, vì vậy đợt tăng cường sẽ biến mất mà không cần hoàn tác (rollback) thủ công.
  2. Compare-and-swap (CAS) – khi hai người cùng chỉnh sửa một cài đặt tại một thời điểm, CAS sẽ báo lỗi rõ ràng cho một người, ngăn chặn việc ghi đè âm thầm.
  3. Tiến trình sidecar – PHP gặp khó khăn với các kết nối duy trì lâu dài. Một sidecar nhỏ bằng Go trên mỗi máy sẽ theo dõi etcd và ghi một bản chụp (snapshot) của bảng định tuyến vào một tệp bộ nhớ dùng chung (/dev/shm). PHP sẽ đọc tệp cục bộ đó, tránh được mọi vòng lặp mạng (network round-trip) trong quá trình xử lý yêu cầu.

Khả năng phục hồi được xây dựng vào kiến trúc

Thiết kế mới bổ sung một số lưới an toàn:

  • Đọc không độ trễ – luồng xử lý chính (hot path) của PHP đọc từ bộ nhớ cục bộ, vì vậy các yêu cầu không bao giờ bị đình trệ để chờ đợi kho lưu trữ từ xa.
  • Suy giảm chức năng có kiểm soát (Graceful degradation) – nếu etcd gặp sự cố, các router vẫn tiếp tục phục vụ cấu hình tốt nhất được biết đến gần nhất, ngăn chặn sự cố sụp đổ đột ngột.
  • Cập nhật đáng tin cậy – sidecar xử lý logic kết nối lại và đảm bảo không bỏ lỡ bất kỳ thay đổi nào, ngay cả khi kết nối etcd bị ngắt tạm thời.

Những gì đã thay đổi trên thực tế

Sau khi di chuyển, nhóm đã thấy sự sụt giảm rõ rệt các sự cố gây ra bởi dữ liệu định tuyến cũ hoặc không khớp. Giờ đây, một bảng điều khiển duy nhất hiển thị cấu hình hiện tại, và bất kỳ chỉnh sửa nào cũng được lan truyền đến cả tám khu vực trong vòng một giây. Các đợt tăng cường tạm thời sẽ tự dọn dẹp khi lease hết hạn, loại bỏ các bước dọn dẹp thủ công vốn trước đây thường dẫn đến lỗi do con người.

Quan điểm ngược lại: chi phí của sidecar

Việc thêm một sidecar đồng nghĩa với việc có thêm một tiến trình thứ hai trên mỗi máy chủ và một runtime Go trong một stack tập trung vào PHP. Một số người vận hành lo ngại về việc sử dụng thêm bộ nhớ và nhu cầu giám sát thêm một tệp thực thi (binary) khác. Trên thực tế, dấu chân (footprint) của sidecar là rất khiêm tốn, và những lợi ích về độ tin cậy—đặc biệt là sự đảm bảo rằng PHP không bao giờ bị chặn bởi một lệnh gọi mạng—vượt xa chi phí vận hành.

Những gì cần theo dõi tiếp theo

Các nhóm quản lý dịch vụ đa khu vực nên giám sát:

  • Các chỉ số sức khỏe của etcd – lớp định tuyến phụ thuộc vào một kho lưu trữ duy nhất; hãy để mắt đến trạng thái quorum và độ trễ.
  • Xử lý hết hạn lease – hãy khớp thời gian lease với các khung thời gian kinh doanh; các lease quá dài sẽ để lại các đợt tăng cường lỗi thời.
  • Mở rộng tải watch – khi số lượng router tăng lên, các kết nối watch cũng tăng theo; hãy lập kế hoạch năng lực cho các máy chủ etcd một cách tương ứng.

Bài học rút ra

Đối với bất kỳ dịch vụ nào cần thực hiện các thay đổi cấu hình nhanh chóng và có sự phối hợp trên nhiều vùng, các nguyên ngữ watch, lease và transaction của etcd cung cấp một giải pháp thay thế nhẹ nhàng và có tính nhất quán mạnh mẽ so với các cấu hình dựa trên tệp tin hoặc các mesh nặng nề. Việc chuyển đổi cấu hình thành một kho lưu trữ được thúc đẩy bởi cơ chế push và có khả năng tự làm sạch đã loại bỏ hoàn toàn một nhóm các sự cố và mang lại cho nền tảng khả năng kiểm soát thời gian thực đối với logic định tuyến của mình.