Microsoft Fabric CI/CD: Khoảng cách trong triển khai
Quá trình triển khai của bạn kết thúc thành công. Pipeline Azure DevOps của bạn vượt qua tất cả các bước. Workspace môi trường production trông thật hoàn hảo.
Thế rồi, sáng thứ Hai ập đến.
Việc làm mới semantic model thất bại. Các phân vùng (partitions) của lakehouse bị lỗi. Các báo cáo bị timeout đối với mọi người dùng.
Đây chính là khía cạnh của Microsoft Fabric CI/CD mà hầu hết các bài hướng dẫn đều bỏ qua.
Hầu hết các tài liệu tiếng Anh chỉ hướng dẫn thiết lập kiểu "hello world". Họ chỉ cho bạn cách đồng bộ hóa các item. Họ không chỉ cho bạn cách vận hành một môi trường production thực thụ.
Tôi đã nghiên cứu các tài liệu từ cộng đồng nhà phát triển Nhật Bản trên Qiita. Họ đã tìm ra những vấn đề thực tế đối với việc triển khai Fabric sẵn sàng cho môi trường production.
Fabric coi mọi thứ là các item. Chúng bao gồm semantic models, lakehouses, pipelines, reports và notebooks. Mục tiêu là coi các item này như là mã nguồn (code).
Quy trình làm việc tiêu chuẩn trông như sau:
- Source control: Xuất các item dưới dạng định nghĩa JSON trong repo của bạn.
- Build stage: Xác thực các cấu hình và các phụ thuộc (dependencies).
- Release stage: Triển khai tới các workspace đích bằng cách sử dụng các tham số môi trường (environment parameters).
Nhưng quy trình đơn giản này sẽ thất bại khi mở rộng quy mô. Đây là lý do tại sao:
Lỗi phụ thuộc (Dependency errors) Các bài hướng dẫn nói rằng bạn có thể triển khai các item theo bất kỳ thứ tự nào. Điều này là sai. Một semantic model phụ thuộc vào một lakehouse. Nếu bạn triển khai model trước khi lakehouse được cập nhật, việc refresh sẽ thất bại.
Giới hạn API (API limits) Các bài hướng dẫn gợi ý dùng một pipeline cho mọi thứ. Các workspace lớn sẽ chạm ngưỡng giới hạn tốc độ (rate limits) của Fabric API trong quá trình triển khai đồng thời. Bạn cần có logic để làm chậm quá trình này lại.
Sự khác biệt về capacity (Capacity differences) Một model có thể hoạt động tốt trong môi trường test nhưng lại thất bại trong production. Các workspace production thường có các cấp độ capacity (capacity tiers) và các hạn chế về tính năng khác nhau.
Nếu bạn muốn chuyển từ một bài hướng dẫn sang một thiết lập production thực tế, hãy tuân thủ các quy tắc sau:
- Sử dụng triển khai tuần tự (sequential deployment). Xác định thứ tự của các item dựa trên các phụ thuộc của chúng.
- Triển khai cơ chế khóa workspace (workspace locking). Ngăn chặn hai pipeline chạy cùng một lúc. Điều này giúp tránh làm hỏng (corruption) workspace.
- Duy trì một workspace dự phòng (backup workspace). Sử dụng nó làm mục tiêu rollback nếu việc triển khai thất bại.
- Sử dụng các tham số nhận biết capacity (capacity-aware parameters). Kiểm tra các thiết lập của bạn dựa trên capacity production thực tế.
Các công cụ đã có sẵn. Mô hình này hoạt động hiệu quả. Bạn chỉ cần chuẩn bị cho những thất bại mà các bài hướng dẫn thường bỏ qua.
Đội ngũ của bạn đã từng gặp phải các lỗi triển khai mà các bài hướng dẫn không đề cập đến chưa? Còn điều gì khác nên có trong một danh sách kiểm tra (checklist) cho production?
Optional learning community: https://t.me/GyaanSetuAi