AetherGrid – Điều phối tính toán AI phân tán không cần Kubernetes (K8s)

Một bộ điều phối tác vụ AI phân tán được xây dựng để giải quyết các vấn đề khiến việc lập lịch trở nên khó khăn ở quy mô lớn: quyền sở hữu thực thi độc quyền khi xảy ra lỗi, đối chiếu sau các lỗi cục bộ và giới hạn tài nguyên được thực thi. Đây không phải là một hướng dẫn CRUD với chủ đề lập lịch. AetherGrid tiếp nhận các tác vụ, đối sánh chúng với các nút tính toán khả dụng dựa trên yêu cầu và ràng buộc tài nguyên, đồng thời quản lý toàn bộ vòng đời: xếp hàng, được lập lịch, đang chạy, đã hoàn thành, thất bại, thử lại, bị hủy. Các tác vụ chạy thông qua các worker được đăng ký với các nút, và quyền sở hữu thực thi tác vụ được thực thi thông qua các hợp đồng thuê (lease) có thời hạn thay vì một cờ gán đơn giản. Mọi tuyến đường đều yêu cầu xác thực bằng khóa API, bao gồm cả điểm cuối cấp khóa. Lý do tồn tại Hầu hết các dự án phụ về lập lịch là một tập lệnh `main.py` duy nhất được gói trong một vòng lặp `while True` thăm dò một từ điển trong bộ nhớ. Chúng hoạt động tốt, cho đến khi cần thay đổi công cụ lưu trữ, thêm loại ràng buộc mới, hoặc tìm hiểu lý do tại sao một tác vụ biến mất một cách âm thầm, hoặc tại sao hai worker lại nhận cùng một tác vụ cùng một lúc. AetherGrid được xây dựng dựa trên một quy tắc: logic nghiệp vụ không biết hoặc không quan tâm dữ liệu nằm ở đâu. Các tác vụ, nút, worker và thuật toán phân bổ là Python thuần túy không có phụ thuộc cơ sở hạ tầng. Cơ sở dữ liệu là một chi tiết, không phải nền tảng. Dự án này là một minh chứng cụ thể rằng các mẫu kiến trúc này không chỉ là từ vựng trong các buổi hội thảo; chúng là những rào chắn giúp mã nguồn dễ hiểu khi nó phát triển, và khi các yêu cầu về tính đúng đắn của nó trở nên khó khăn hơn. Hồ sơ Quyết định Kỹ thuật (Engineering Decision Records - ADRs) Mọi quyết định không hiển nhiên trong mã nguồn này, lý do tại sao một quy tắc nghiệp vụ tồn tại ở một vị trí cụ thể, tại sao một lối tắt có vẻ hiển nhiên bị từ chối, điều gì đã hỏng và cách nó được sửa, đều được ghi lại tại thời điểm nó được đưa ra, chứ không phải được tái cấu trúc sau đó cho một hồ sơ năng lực. 21 ADRs nằm trong thư mục `/docs/adr`. Một vài ADR đáng đọc trực tiếp nếu muốn xem lý do, không chỉ kết luận: ADR 0007 — Vòng lặp đối chiếu (Reconciliation Loop): cách hệ thống phát hiện và sửa chữa trạng thái không nhất quán do các worker bị lỗi và các hợp đồng thuê hết hạn để lại, thay vì giả định rằng con đường thuận lợi là con đường duy nhất. ADR 0011 — Thu hồi tác vụ và sửa chữa đối chiếu (Job Reclaim and Reconciliation Repair): khắc phục một điều kiện tranh chấp thực tế khi việc gia hạn hợp đồng thuê của một worker đang chết có thể đến sau khi quá trình đối chiếu đã bắt đầu gán lại công việc của nó. ADR 0012 — Thực thi tác vụ thực sự (Real Job Execution): xây dựng quá trình thực thi tiến trình con (subprocess) thực sự với thời gian chờ được thực thi, sau đó cố tình giữ nó không thể truy cập được từ API công khai cho đến khi hệ thống có xác thực, và chứng minh sự vắng mặt đó bằng một thử nghiệm thay vì một bình luận. ADR 0014 — Gia hạn hợp đồng thuê liên tục (Continuous Lease Renewal): lý do tại sao một hợp đồng thuê được gia hạn liên tục trong toàn bộ thời gian chạy của một tác vụ thay vì chỉ một lần khi được cấp. ADR 0015 — Xác thực bằng khóa API (API Key Authentication): lý do tại sao các token mờ do máy chủ cấp được chọn thay vì JWT cho một hệ thống cần thu hồi ngay lập tức, và tại sao việc xây dựng xác thực vẫn không trả lời được liệu `Job.command` có nên được công khai hay không, câu hỏi đó vẫn bỏ ngỏ cho đến ADR 0020, đã giải quyết nó một cách hẹp: một worker có thể đọc một lệnh đã được gán cho nó, không có gì rộng hơn. ADR 0018 — Miền sở hữu chính sách lập lịch (Domain Owns Scheduling Policy): lý do tại sao `list_available()` được chuyển hoàn toàn ra khỏi kho lưu trữ, vì việc quyết định nút nào đủ điều kiện để lập lịch là một quy tắc nghiệp vụ, không phải là một mối quan tâm về lưu trữ, và việc để cơ sở hạ tầng quyết định điều đó sẽ khiến hành vi lập lịch phụ thuộc vào loại cơ sở dữ liệu đang chạy. ADR 0019 — Quy trình tác nhân Worker độc lập: thay thế việc thực thi tác vụ nội bộ bằng một tác nhân ngoài quy trình thực sự, xác nhận việc bắt đầu thực thi của chính nó qua mạng. Văn bản cũng giải thích lý do chọn cơ chế thăm dò dựa trên "kéo" (pull-based polling) thay vì phân phối "đẩy" (push delivery), vì nó tái sử dụng cơ chế đối chiếu mà cơ sở mã này đã tin cậy, thay vì đưa vào logic đảm bảo phân phối và lỗi mới. Nếu đang đánh giá khả năng vận hành ở cấp độ hệ thống thay vì cấp độ tính năng của một người, đây là cách kiểm tra nhanh nhất. Các khả năng chính Xác thực khóa API kiểm soát mọi tuyến đường: không có điểm cuối nào trong hệ thống, kể cả điểm cấp khóa, có thể truy cập được nếu không có thông tin xác thực hợp lệ. Cách duy nhất để tạo khóa đầu tiên là chạy một tập lệnh cục bộ với quyền truy cập trực tiếp vào cơ sở dữ liệu, không bao giờ qua HTTP, nhằm đóng lỗ hổng tự phục vụ thông tin xác thực mà mô hình đó có thể để lại. Quản lý vòng đời tác vụ: chuyển đổi trạng thái rõ ràng (Đã xếp hàng → Đã lên lịch → Đang chạy → Đã hoàn thành/Thất bại/Đã hủy) với các chính sách thử lại có thể cấu hình và lên lịch ưu tiên, cùng với các hành động hủy và thử lại có thể truy cập từ bảng điều khiển. Lịch sử vòng đời từng tác vụ: mỗi tác vụ có một trang chi tiết riêng (/jobs/{id}) hiển thị toàn bộ dòng thời gian sự kiện thực tế của nó, từ khi Tạo tác vụ (JobCreated) cho đến khi hoàn thành, không chỉ trạng thái hiện tại. Bộ cấp phát phù hợp nhất có nhận thức về ràng buộc: khớp khối lượng công việc với các nút dựa trên yêu cầu tài nguyên và nhãn, đồng thời bỏ qua các nút đang bị rút tải hoặc ngoại tuyến. Rút tải nút: một nút khỏe mạnh có thể được đưa ra khỏi vòng quay lên lịch để bảo trì mà không cần tắt hoàn toàn; bộ lập lịch ngừng gán công việc mới cho nó trong khi bất kỳ công việc nào đang chạy trên đó vẫn tiếp tục cho đến khi hoàn thành. Đăng ký và tín hiệu giữ sống (heartbeat) của worker: việc đăng ký một nút sẽ tự động đăng ký một worker vào nút đó, để nó có thể ngay lập tức yêu cầu và thực thi công việc, chứ không chỉ tồn tại như một dung lượng không sử dụng. Tác nhân worker độc lập với quyền sở hữu tác vụ độc quyền: tập lệnh scripts/run_agent.py chạy như một quy trình riêng biệt, thăm dò API qua HTTP để tìm công việc được giao, thực thi nó như một quy trình con cục bộ thực sự và gửi tín hiệu giữ sống trên luồng nền của riêng nó trong suốt vòng đời của tác nhân, độc lập với bất kỳ tác vụ nào nó đang thực thi (xem ADR 0019). Điều này thay thế tín hiệu giữ sống phía máy khách của bảng điều khiển làm cơ chế kiểm tra sự sống cho bất kỳ worker nào đang chạy nó; một worker không có quy trình tác nhân đính kèm vẫn chỉ dựa vào sự sống của nút. Mỗi worker được gắn thẻ với một trường managed_by rõ ràng được đặt khi đăng ký (DASHBOARD hoặc AGENT); vòng lặp lập lịch nội bộ bỏ qua hoàn toàn bất kỳ worker nào được đánh dấu AGENT, do đó các tác vụ của một tác nhân độc lập được thực thi chính xác một lần, bởi tác nhân.