Trường hợp sử dụng – Viết Plugin Hiệu Suất Người Dùng cho Môi Trường HA
Talk Transcription:
Tôi là Daryl Spartz, làm việc tại Yahoo. Tôi mới bắt đầu làm quen với Artifactory từ tháng 10 năm ngoái.
Nhiệm vụ đầu tiên của tôi là tối ưu hóa và dọn dẹp các artifact. Đó là tình trạng phổ biến khi dữ liệu liên tục gia tăng, khiến dung lượng lưu trữ nhanh chóng bị lấp đầy. Chúng tôi đã phân bổ 27TB cho volume filer và lúc đó đã dùng đến khoảng 23TB. Các nỗ lực dọn dẹp trước đây đều gặp nhiều khó khăn, nên mục tiêu lần này là xử lý mà không làm gián đoạn hệ thống. Môi trường của chúng tôi là high availability với hai filer được đồng bộ hóa qua snap-mirror, tôi sẽ nói thêm về kiến trúc này.
Hiệu năng trong môi trường này nghĩa là gì? Tôi sẽ trình bày qua một case study sử dụng plugin Artifactory Cleanup, đồng thời giới thiệu kiến trúc high availability mà chúng tôi vận hành. Sau khi hoàn thiện quy trình dọn dẹp, chúng tôi còn tiến hành migrate từ Artifactory 3.9 lên 4.7. Ngoài ra, tôi cũng đã chuyển phần lớn công việc quản trị sang Chef – tôi sẽ trình bày về cookbook cùng các recipe đang sử dụng và cách vận hành chúng. Nếu còn thời gian, tôi rất sẵn sàng trả lời các câu hỏi.
Vậy “hiệu năng” ở đây là gì? Đối với mọi phần mềm, nếu triển khai không đúng sẽ ảnh hưởng trực tiếp tới Artifactory như tiêu thụ CPU, chiếm dụng bộ nhớ lớn và đặc biệt là I/O khi thực hiện dọn dẹp. Là plugin, bạn bị giới hạn về mức kiểm soát nhưng vẫn có thể điều chỉnh số lượng và tần suất gọi API, hoặc giới hạn, điều tiết khối lượng công việc khi hệ thống phải xử lý dữ liệu lớn, từ đó tối ưu hiệu quả vận hành.
Bắt đầu với plugin Cleanup gốc của Artifactory (có trên Github tổ chức JFrog), mục đích là xóa đi các artifact không còn sử dụng. Script gọi API để lấy danh sách artifact theo tuổi đời, sau đó duyệt và xóa từng artifact một. Tuy nhiên, với khối lượng lên tới 23TB, mỗi lần xóa sẽ tạo ra hàng loạt hoạt động trên filer. Nếu để tự động chạy liên tục, cơ sở dữ liệu sẽ gánh nhiều transaction kéo dài, dễ gây ra tình trạng “lock” và ảnh hưởng hệ thống. Chúng tôi thậm chí phải liên hệ JFrog để nhận hướng dẫn xử lý.
Trong môi trường high availability sử dụng NFS, chạy full workload gây ảnh hưởng rõ rệt tới filer do chồng chất hoạt động I/O. Điều này ảnh hưởng đến mọi tenant dùng chung tài nguyên. Ngoài ra, khi chạy cleanup trên một host cụ thể, tải CPU tăng đột biến có thể khiến hệ thống cảnh báo. Nếu host này là một phần của cluster cân bằng tải, người dùng sẽ bị ảnh hưởng. Do đó, yêu cầu tiên quyết là đảm bảo hiệu năng cho toàn hệ thống.
Khi chạy script, chúng tôi thường gặp lỗi lock wait timeout, buộc phải điều chỉnh lại cách vận hành. Một chi tiết kỹ thuật: plugin được load khi khởi động JVM cùng Artifactory, có thể khai báo nhiều endpoint để quản lý từng chức năng trong cùng một class.
Biết được cơ chế đó, tôi đã phát triển cải tiến cho plugin Cleanup: thêm tuỳ chọn pacing khi gọi API REST hoặc scheduling để kiểm soát tốc độ xóa, tránh làm nghẽn tài nguyên đĩa hay network. Thông số pacing có thể điều chỉnh linh hoạt; nếu tác động hệ thống thấp, có thể giảm delay để tăng tốc quá trình hoặc tăng delay khi phát hiện ảnh hưởng.
Bổ sung thêm chức năng pause, resume, stop giúp kiểm soát truy vấn: khi cần tạm dừng để giảm tải hệ thống, trạng thái xóa sẽ lưu lại, có thể khôi phục và làm tiếp sau giờ làm việc. Ngoài ra, bổ sung chi tiết logging để dễ dàng xác định trạng thái tiến trình — ví dụ đã xử lý được bao nhiêu file, còn bao nhiêu dung lượng đã dọn dẹp,…
Bản plugin gốc sử dụng file cấu hình properties chỉ cho phép một chính sách áp dụng chung cho nhiều repo, tôi đã phát triển thêm cho phép tùy biến nhiều policy khác nhau cho từng repo hoặc nhóm repo, linh hoạt theo nhu cầu từng phòng ban.
Tôi đã đóng góp các cải tiến này lên cộng đồng mã nguồn mở, bạn có thể tải về từ Github JFrog, lưu ý cần bản Groovy 4.x để hỗ trợ tốt khả năng cập nhật động cấu hình.
Lệnh curl để tích hợp cleanup cũng được mở rộng: bạn có thể chỉ định số tháng, tên repo hoặc danh sách repo, tuỳ chọn dry run để kiểm tra trước mà không thực sự xóa dữ liệu, và pacing theo milliseconds cho mỗi lần xóa. Các lệnh dừng (stop), tạm dừng (pause), tiếp tục (resume) đều đã tích hợp sẵn để kiểm soát hiệu năng. Mọi code đều sẵn sàng trên Github.
Dưới đây là ví dụ chi tiết về một phiên chạy với logging: hai repo “Mobile” và “Fastbreak” áp dụng chính sách cũ hơn 3 tháng và pacing 1 giây cho mỗi tác vụ xóa (con số này có thể điều chỉnh). Log sẽ trả về tiến trình xử lý, ví dụ “đã xóa 2 trong số 257,000 file”, tổng số byte đã dọn dẹp, v.v… Log này được điều chỉnh cấp độ trong logback.xml của Artifactory.
Về mặt cấu hình, hệ thống hỗ trợ nhiều policy cùng lúc cho phép tùy biến linh hoạt cho từng nhóm artifact, chọn pacing, dry run,… và mở rộng theo từng repo. Bản plugin hiện tại đã giúp chúng tôi giải phóng khoảng 9TB dữ liệu, thời gian xử lý khoảng một tuần với pacing 1 giây, hoàn toàn không gây gián đoạn cho hệ thống – phù hợp khi bạn chưa bị áp lực dung lượng quá lớn.
Lúc này, một số câu hỏi đến từ phía người nghe:
(Cử tọa) Bạn có ngắt snap-mirror backup trước khi chạy hay không?
Chúng tôi không ngắt snap-mirror, vẫn giữ cho các snapshot hoạt động; việc giải phóng dung lượng chỉ thực sự xảy ra khi các snapshot này được xoay vòng và hết hạn.
(Cử tọa) Bạn có cleanup các artifact Docker không?
Ở thời điểm thực hiện, chúng tôi chưa dùng Artifactory cho Docker, các repo “Mobile” và “Fastbreak” chủ yếu là ảnh iOS và Android.
(Cử tọa) Bạn có nghĩ dùng CLI sẽ tiện hơn GUI?
Về mặt chức năng, plugin và CLI đều cho phép scripting tự động, CLI có thể cần script thêm để pacing hoặc scheduling phù hợp. Ưu điểm của plugin là đã có job lên lịch sẵn (ví dụ chủ nhật 5h sáng), quản lý dễ dàng hơn qua file properties, tuy nhiên cả hai đều linh hoạt như nhau tuỳ vào cách bạn triển khai.
(Cử tọa) Bạn có làm cleanup cho các folder trống hay file đặc biệt không?
Đúng vậy, chúng tôi sử dụng thêm một plugin khác để xóa folder trống, hiện tại công đoạn này thực hiện thủ công nhưng hoàn toàn có thể tự động hóa.
(Cử tọa) Bạn xác định chính sách cleanup như thế nào?
Chúng tôi làm việc với các bộ phận để xác lập policy phù hợp, bắt đầu từ các nhóm tiêu thụ dung lượng nhiều nhất và điều chỉnh dần. Đã có thảo luận về việc dùng tag để lọc các artifact cần giữ lại, tránh rủi ro xóa nhầm artifact còn sử dụng ngoài production; cách này hoàn toàn có thể thực hiện được thông qua scripting với CLI hoặc mở rộng plugin.
Chuyển sang chủ đề tiếp theo, tôi muốn nói về quá trình migrate Artifactory 3.9 lên 4.7 và chuyển đổi hoàn toàn sang quản lý bằng Chef. Mọi công đoạn từ cài đặt, cấu hình Artifactory (standalone lẫn HA), khởi động/dừng dịch vụ đều thực hiện qua recipe Chef, hoàn toàn data driven, được chia thành các environment (test, staging, production) và tất cả thông số có thể ghi đè dễ dàng.
Bao gồm việc thiết lập kho lưu trữ mirror, quản lý bản quyền qua Chef Vault, cấu hình,bundle thông qua template cho từng môi trường, sử dụng resource ‘mount’ cho thiết lập NFS, sử dụng link để symlink thư mục Artifactory vào filer volume, cùng cookbook mở rộng để chỉnh chu XML cấu hình (SSL, Tomcat connector, logging cho plugin…), mọi thay đổi đều tự động và có thể mở rộng dễ dàng.
Đặc biệt, tôi dành nhiều thời gian xây dựng kitchen environment (test trên Vagrant) để kiểm thử mọi option cấu hình, đảm bảo bản build luôn đúng trước khi commit và deploy vào pipeline thực tế – điều này cực kỳ hữu ích cho việc thử nghiệm thay đổi một cách an toàn và nhanh chóng.
Nhìn chung, cải tiến plugin cleanup, áp dụng Chef data driven giúp đội ngũ vừa tối ưu hiệu suất, chủ động kiểm soát rủi ro, vừa hỗ trợ cho chiến lược tự động hóa quản trị hệ thống quy mô lớn.
Các giải pháp quản lý artifact, cleanup, tự động hóa HA hoặc migration luôn đóng vai trò trọng yếu trong môi trường doanh nghiệp tăng trưởng nhanh. Nếu doanh nghiệp của bạn cũng đang đối mặt với những thách thức tương tự về quy mô hệ thống, quản lý artifact hoặc tự động hóa hạ tầng DevOps, hãy liên hệ ngay Softribution để được tư vấn triển khai giải pháp tối ưu nhất hoặc mua các sản phẩm giải pháp phù hợp với nhu cầu của bạn.
Bạn có thắc mắc nào? Đội ngũ chuyên gia của Softribution luôn sẵn sàng hỗ trợ bạn!
