0
0
Lập trình
Flame Kris
Flame Krisbacodekiller

Thiết kế Pipeline Xử lý Dữ liệu Lỗ hổng Tự động Trên AWS

Đăng vào 8 giờ trước

• 6 phút đọc

Giới thiệu

Trong việc xây dựng nền tảng SaaS đa khách hàng cho quản lý lỗ hổng, kiến trúc backend cần xử lý hiệu quả dữ liệu JSON lỗ hổng từ các công cụ như Prowler, Trivy, AWS Inspector và Kubehunter. Hệ thống yêu cầu:

  • Tiếp nhận dữ liệu an toàn
  • Chuẩn hóa theo schema tùy chỉnh
  • Tùy chọn nhúng AI cho các lỗ hổng quan trọng bằng Amazon Bedrock
  • Lưu trữ trong Amazon RDS để truy vấn dashboard theo thời gian thực

Sau khi đánh giá nhiều phương pháp serverless, thiết kế sử dụng AWS Step Functions với các tác vụ Lambda đã nổi bật như giải pháp tối ưu. Bài viết này khám phá kiến trúc đã chọn, so sánh với các lựa chọn khác và trình bày lý do cho sự lựa chọn này.

Đặt vấn đề và yêu cầu

Nền tảng phải xử lý các cấu trúc JSON khác nhau từ quét lỗ hổng, đảm bảo:

  • Tiếp nhận an toàn: Hỗ trợ URL đã ký trước cho các tải lên trực tiếp tới S3.
  • Theo dõi metadata: Lưu trữ thông tin tải lên (ví dụ: customer_id, source_tool, embedding_flag).
  • Pipeline xử lý: Xác thực tải lên, tiền xử lý, kiểm tra khách hàng và deltas, nhúng lỗ hổng quan trọng, upsert vào RDS, xác thực ghi, ghi nhật ký số liệu, và dọn dẹp dữ liệu tạm thời.
  • Xử lý lỗi: Sử dụng Dead Letter Queue (DLQ) cho phục hồi lỗi.
  • Xử lý sau: Kích hoạt thông báo hoặc phân tích tùy chọn.
  • Ràng buộc: Mục tiêu ~14-23$/tháng cho 900 tải lên/tháng trên 10 khách hàng, đảm bảo cách ly đa khách hàng, hỗ trợ truy vấn dashboard theo thời gian thực và mở rộng lên 50+ khách hàng.

Kiến trúc đã phát triển từ các khái niệm ban đầu về AWS Glue cho ETL sang Step Functions vì tính linh hoạt trong việc xử lý logic điều kiện và phân nhánh theo từng công cụ.

Tổng quan về kiến trúc đã chọn

Kiến trúc được chọn hoàn toàn serverless, sử dụng AWS Step Functions để điều phối các tác vụ Lambda cho quy trình làm việc mạch lạc:

  • Tải lên từ Frontend: API Gateway xử lý các yêu cầu tải lên, gọi một tác vụ Lambda để tạo URL S3 và lưu metadata vào DynamoDB.
  • Kích hoạt sự kiện: Tải lên S3 kích hoạt EventBridge, trực tiếp gọi Step Functions với payload sự kiện (bucket, key).
  • Điều phối quy trình làm việc: Step Functions điều phối các tác vụ:
    • Kiểm tra tính idempotent: Bỏ qua các file đã được xử lý.
    • Xác thực metadata: Lấy và xác thực customer_id, source_tool, embedding_flag từ DynamoDB.
    • Kiểm tra khách hàng/deltas: Xác minh sự tồn tại của khách hàng trong RDS và xác định các lỗ hổng mới hoặc đã được vá.
    • Tiền xử lý theo công cụ: Phân nhánh cho Prowler, Inspector, Trivy, Kubehunter để xác thực, loại bỏ trùng lặp và chuẩn hóa JSON.
    • Xác thực dữ liệu: Đảm bảo các trường yêu cầu và số lượng hàng.
    • Batch Upsert: Ghi dữ liệu đã chuẩn hóa vào RDS (PostgreSQL).
    • Xác thực sau khi upsert: Kiểm tra thành công ghi.
    • Nhúng có điều kiện: Lấy lỗ hổng quan trọng và tạo nhúng từ Bedrock.
    • Ghi nhật ký số liệu: Ghi số lượng lỗ hổng đã xử lý vào CloudWatch.
    • Dọn dẹp: Xóa file S3 và mục nhập DynamoDB.
  • Xử lý lỗi: Lỗi được chuyển đến DLQ để phân tích.
  • Xử lý sau: Cập nhật RDS kích hoạt một nhóm tự động mở rộng (ASG) tùy chọn cho thông báo.

Thiết kế này đảm bảo xử lý bất đồng bộ, tách biệt tải lên khỏi tính toán, với nhúng có điều kiện để tối ưu hóa chi phí AI. Dự kiến chi phí MVP là khoảng 14-23$/tháng.

So sánh các kiến trúc thay thế

Ba kiến trúc serverless đã được đánh giá để đáp ứng yêu cầu của nền tảng. Mỗi kiến trúc được đánh giá dựa trên chi phí, khả năng mở rộng, độ tin cậy, độ phức tạp hoạt động và khả năng xử lý logic điều kiện và phân nhánh nhiều công cụ.

1. Xử lý hoàn toàn bằng Lambda

Mô tả: Một hàm Lambda đơn (hoặc chuỗi các hàm Lambda) xử lý toàn bộ quy trình: tải từ S3, tiền xử lý, chuẩn hóa, nhúng và upsert vào RDS. Metadata được lưu trữ trong DynamoDB, với lỗi được ghi vào CloudWatch hoặc DLQ.

  • Chi phí: Thấp (~0.06$/tháng cho 900 lần gọi, bộ nhớ 128 MB, thời gian 5 giây).
  • Khả năng mở rộng: Xuất sắc, với Lambda tự động mở rộng đến hàng ngàn thực thi đồng thời.
  • Độ tin cậy: Vừa phải. Tính năng tự động thử lại xử lý lỗi tạm thời, nhưng các luồng phức tạp cần xử lý lỗi tùy chỉnh.
  • Độ phức tạp hoạt động: Trung bình. Phân nhánh và thử lại phải được lập trình thủ công.
  • Khả năng phù hợp: Hạn chế cho logic điều kiện và phân nhánh nhiều công cụ.

Nhược điểm: Thiếu cơ chế điều phối cấu trúc, dễ xảy ra lỗi cho các quy trình phức tạp.

2. Step Functions với Lambda

Mô tả: Kiến trúc được chọn sử dụng Step Functions để điều phối các tác vụ Lambda cho từng bước riêng biệt: kiểm tra idempotency, xác thực metadata, tiền xử lý theo công cụ, nhúng có điều kiện.

  • Chi phí: Cao hơn một chút so với Lambda thuần (~0.16$/tháng cho 900 thực thi).
  • Khả năng mở rộng: Cao, với Step Functions hỗ trợ 1,000+ thực thi đồng thời.
  • Độ tin cậy: Mạnh mẽ, với các tính năng thử lại tích hợp.
  • Độ phức tạp hoạt động: Thấp, nhờ vào trình chỉnh sửa trực quan.
  • Khả năng phù hợp: Xuất sắc cho logic điều kiện và phân nhánh công cụ.

Lợi ích: Cân bằng giữa tính linh hoạt, độ tin cậy và đơn giản, lý tưởng cho quy trình làm việc của nền tảng.

3. Step Functions với Glue

Mô tả: Step Functions điều phối các tác vụ AWS Glue cho ETL và Lambda cho các tác vụ không ETL.

  • Chi phí: Trung bình (~2-15$/tháng cho các tác vụ Glue).
  • Khả năng mở rộng: Mạnh mẽ cho dữ liệu lớn, nhưng không cần thiết cho MVP.
  • Độ tin cậy: Tốt, với Glue tự động thử lại.
  • Độ phức tạp hoạt động: Trung bình-cao. Phức tạp hơn cho các tác vụ nhúng có điều kiện.
  • Khả năng phù hợp: Hiệu quả cho chuẩn hóa, nhưng kém linh hoạt cho nhúng có điều kiện.

Nhược điểm: Tăng chi phí và độ phức tạp không cần thiết cho các tập dữ liệu nhỏ.

Lý do chọn Step Functions với Lambda

Kiến trúc Step Functions với Lambda được chọn vì sự cân bằng tối ưu giữa chi phí, khả năng mở rộng, độ tin cậy và sự đơn giản trong vận hành.

  • Chi phí hiệu quả: Khoảng 14-23$/tháng, tiết kiệm hơn so với Step Functions với Glue.
  • Khả năng mở rộng và linh hoạt: Tối ưu cho logic điều kiện và phân nhánh công cụ.
  • Độ tin cậy và xử lý lỗi: Các tính năng thử lại tích hợp và DLQ đảm bảo xử lý mạnh mẽ.
  • Đơn giản trong vận hành: Thiết lập nhanh chóng và dễ dàng quản lý.
  • Tương lai: Hỗ trợ mở rộng cho các tính năng mới mà không làm gián đoạn quy trình chính.

Lợi ích của kiến trúc đã chọn

  • Chi phí hiệu quả: Khoảng 14-23$/tháng cho 900 tải lên.
  • Hiệu suất: Xử lý bất đồng bộ nhanh chóng.
  • Bảo mật: URL đã ký trước và các vai trò IAM.
  • Khả năng mở rộng: Các tác vụ mô-đun cho phép thêm công cụ mới dễ dàng.
  • Giám sát: Cung cấp cái nhìn tổng quát qua CloudWatch/X-Ray.

Kết luận

Kiến trúc Step Functions với Lambda là ví dụ điển hình về các thực hành tốt nhất của AWS, cung cấp giải pháp mở rộng, đáng tin cậy và tiết kiệm chi phí cho việc xử lý dữ liệu lỗ hổng. Các nhà phát triển và kiến trúc sư có thể tham khảo tài liệu AWS để tìm hiểu chi tiết về cách triển khai hoặc chia sẻ phản hồi để hoàn thiện phương pháp này.

Gợi ý câu hỏi phỏng vấn
Không có dữ liệu

Không có dữ liệu

Bài viết được đề xuất
Bài viết cùng tác giả

Bình luận

Chưa có bình luận nào

Chưa có bình luận nào