Anh em làm DevOps hay System Administrator đã từng đối mặt với bài toán Lưu trữ các Artifact sao cho nhanh, ổn định, tiết kiệm chi phí và dễ dàng quản lý. Đây không chỉ là nơi chứa các gói package như JAR, WAR, NPM, Docker Images, Helm Charts mà còn là Phần chính của quy trình CI/CD và ảnh hưởng trực tiếp đến Deployment Speed và Disaster Recovery của toàn hệ thống.

Trong một dự án quy mô lớn, khi số lượng Microservices lớn, số lần build/ngày lớn, và dung lượng lưu trữ tăng trưởng theo cấp số nhân thì đôi khi là Terabytes mỗi tháng, việc lựa chọn một giải pháp Artifact Storage phù hợp không còn là một lựa chọn tùy ý mà là một quyết định chiến lược ảnh hưởng Operational Efficiency.

Phân Tích Yêu Cầu và Đặc Tính Của Artifact Storage

Trước khi benchmark, anh em mình cùng tìm hiểu rõ các yêu cầu bắt buộc mà một giải pháp Artifact Storage cần đáp ứng trong môi trường doanh nghiệp đã nhể (nói chung là cũng lý thuyết lắm nhưng nên biết):

• High Availability: Hệ thống không được phép downtime, vì nó sẽ làm stuck quy trình CI/CD. Cần có cơ chế Load Balancing và Failover giữa các Node.
• Scalability: Phải dễ dàng mở rộng dung lượng và hiệu năng khi số lượng dự án và artifact tăng lên.
• Multi-Format Support: Cần hỗ trợ các định dạng phổ biến như Maven, NuGet, NPM, Python, Docker, Helm Charts, Generic files…
• Fine-Grained Access Control: Phân quyền chi tiết cho từng Repository, từng nhóm người dùng Dev, QA, Release Team để đảm bảo bảo mật.
• Tính Năng Caching/Proxy: Có khả năng cache các package từ Public Repository như Maven Central, Docker Hub để tăng tốc độ build và giảm thiểu rủi ro phụ thuộc vào bên thứ ba.
• Content Distribution/Replication: Quan trọng cho các doanh nghiệp có nhiều Site/Region. Cần cơ chế Replication để đồng bộ Artifact giữa các trung tâm dữ liệu.

The Contenders

Trên thị trường thường có 3 nhóm giải pháp chính được chúng ta đưa vào đánh giá:

Feature-Rich

JFrog Artifactory: Giải pháp dẫn đầu thị trường, mạnh mẽ, Security Scanning – Xray và Lifecycle Management cực kỳ đầy đủ. Thường dùng trong các highly regulated.

Sonatype Nexus Repository: Phổ biến trong cộng đồng, có phiên bản mã nguồn mở OSS và phiên bản Pro. Dễ cài đặt, quản lý tốt các định dạng cơ bản.

Storage + Registry

• Amazon S3 + ECR + CodeArtifact: Sử dụng S3 làm backend lưu trữ chính, rất rẻ và HA, sau đó tích hợp với các dịch vụ Registry/Repository chuyên biệt của AWS.
• Google Cloud Storage + Google Container Registry (GCR)/Artifact Registry: Tương tự, tận dụng sức mạnh của Google Cloud.

Self-Hosted/Lightweight

• MinIO/Ceph + Docker Registry OSS: Tự xây dựng trên nền tảng Object Storage mã nguồn mở. Cần nhiều công sức vận hành hơn nhưng linh hoạt và tiết kiệm chi phí license. Tôi nghĩ nó tối ưu về lâu dài

Benchmarking

Chúng ta cần đánh giá về Performance và Cost.

Latency & Throughput

Chúng ta sẽ tập trung vào 2 chỉ số quan trọng là Deploy và Resolve Artifact.

Test Environment:

• Client: Một VM tiêu chuẩn, băng thông mạng ổn định (ví dụ: 10 Gbps).
• Artifact Size:
  • Small: 100 files, kích thước 5MB/file.
  • Large: 1 Docker Image, kích thước 1GB.
• Load: Sử dụng công cụ JMeter hoặc Gatling để mô phỏng 100 Concurrent Users thực hiện:
  1. Deploy: 50% Load.
  2. Resolve: 50% Load.

Script Test:

Đây là cách tôi dùng để test nhanh tốc độ Pull Docker Image một trong những tác vụ nặng nhất:

# Giả định đang Pull một image 1GB từ Artifactory
# Thay thế $ARTIFACTORY_URL và $IMAGE_NAME
echo "=== Bắt đầu Benchmark Pull Image ==="
time (
    for i in {1..100}; do
        # cURL với authentication, pull image layer, và đẩy về /dev/null
        # Chú ý: Docker pull phức tạp hơn, nhưng cURL mô phỏng tải các layer
        curl -s -o /dev/null -w "Thời gian phản hồi: %{time_total}s\t Tốc độ: %{speed_download}\n" \
        -u "user:password" "$ARTIFACTORY_URL/v2/$IMAGE_NAME/blobs/sha256:..." &
    done
    wait
)
echo "=== Kết thúc Benchmark ==="

Các Kết Quả:

Tự Động Hóa Artifact Clean-up

Sau vài tháng, nếu như không có các chiến lược dọn mà dựng xong để đó thì hệ thống sẽ đầy rác nên việc xóa bỏ các bản Build cũ theo chính sách lưu giữ và thực hiện Garbage Collection để loại bỏ các Docker Layer/Blob đã orphaned hoặc không còn liên kết với bất kỳ Docker Image Manifest hợp lệ nào là cực kỳ quan trọng.

Ví dụ Script Clean-up cho Nexus/Artifactory Sử dụng API:

Hầu hết các Artifact Repository đều hỗ trợ API để tự động hóa việc xóa. Đây là ví dụ về một AQL để tìm và xóa các bản Build cũ:

// Yêu cầu Request đến Artifactory API (/api/search/aql)
{
  "find": {
    // Tìm các tập tin trong repository 'maven-releases'
    "aql": "items.find({\"repo\": \"maven-releases\", \"type\": \"file\",",
    // Chỉ giữ lại 10 version cuối cùng của mỗi GroupId/ArtifactId
    "aql_filter": [
      {
        "property": "@build.number", // Lọc theo Build Number
        "operator": "$lt",
        "value": "100" 
      },
      {
        "property": "stat.uploaded", // Lọc theo thời gian tải lên
        "operator": "$lt",
        "value": "14d" 
      }
    ]
    // Kết quả được sắp xếp để có thể xóa từ bản cũ nhất
    "aql_sort": "desc"
  }
}

Giải thích: Thay vì xóa trực tiếp trên S3 sẽ rất nguy hiểm, chúng ta sử dụng API/AQL của Artifactory/Nexus để xóa Metadata. Sau đó, hệ thống Garbage Collection của Artifactory sẽ tự động quét và xóa các Binary Data không còn được tham chiếu trong Database nữa. Việc này thường phải chạy định kỳ trong môi trường sản xuất.

Lựa Chọn Cuối Cùng

Tùy vào quy mô và ngân sách, bạn có thể đưa ra quyết định sau:

Lời khuyên: Theo cá nhân tôi thấy thì nếu được hãy chọn Object Storage (S3/GCS) làm backend lưu trữ chính thay vì File System cho các giải pháp Artifactory/Nexus thương mại. Nó giúp giảm thiểu đáng kể rủi ro về HA và chi phí mở rộng dung lượng.

Tổng Kết

Việc lựa chọn Artifact Storage không chỉ là cài đặt một phần mềm, mà là xây dựng một thành phần trong kiến trúc CI/CD.

Kinh nghiệm tôi rút ra là:

1. Đừng bao giờ đánh giá thấp Egress Cost và Operational Overhead: Đôi khi, tiền License đắt hơn nhưng đổi lại sự ổn định và giảm bớt công sức vận hành của team Ops lại là khoản đầu tư xứng đáng.
2. Benchmark phải sát với thực tế: Đừng chỉ test tốc độ Download của 1 file lớn, hãy test khả năng xử lý Concurrent Requests và Network Load. Đây mới là điểm nghẽn thực sự.
3. Tự động hóa Garbage Collection là BẮT BUỘC: Hãy thiết lập các Retention Policy ngay từ đầu để tránh hệ thống bị đầy sau 6-12 tháng, đặc biệt là với Docker Layer.