Tôi đã xoá hơn 3 triệu ảnh rác từ hệ thống legacy

Vừa rồi mình mới tối ưu lại việc sử dụng dung lượng ổ share chung (NAS), xoá đi hơn 3,1 triệu ảnh rác dư thừa trong quy trình ekyc, giải phóng hơn 2TB dữ liệu, giảm khoảng 12% tổng capacity hiện tại đang sử dụng.

Dung lượng trước khi xoá:

Dung lượng sau khi xoá:

Tính đến thời điểm mình viết bài này, thì số lượng ảnh đã xoá được là: 3.136.696

Mục Lục

1 Tại sao cần phải dọn dẹp ảnh rác?
2 Những việc đã xử lý trước đây
3 Ảnh nào sẽ được coi là rác
4 Điều kiện xác định ảnh đủ điều kiện xoá
5 Cách thực hiện
6 Hướng triển khai tiếp theo

Tại sao cần phải dọn dẹp ảnh rác?

Trong quy trình định danh (ekyc) của bên mình (trước đây được xây dựng bởi 1 team BE Platform, hiện tại các thành viên của team này đã nghỉ hết) thì nó lại như này:

Luồng định danh khách hàng mới sẽ phải làm đủ các bước sau: OCR giấy tờ hai mặt -> quét NFC -> quét mặt để xác định thực thể sống, chính chủ.

Cứ mỗi phiên (ekyc session) thành công như vậy thì hệ thống lại lưu ra 4 ảnh: mặt trước, mặt sau, ảnh chip, ảnh mặt khách hàng. Chưa kể những lần quét lỗi cũng thực hiện lưu lại ảnh.

Dẫn tới ở những thời điểm mà khách hàng cần phải chuyển đổi từ tài khoản giao thông lên ví nhiều, thì lượng ảnh mỗi ngày lưu lại có thời điểm lên tới 70-80GB/ngày.

Nghĩa là sẽ có những trường hợp khách hàng thực hiện rất nhiều lần định danh thành công (mình giả sử 70 lần, đã từng có khách hàng trong 1 ngày thực hiện 70 lần định danh như vậy), thì số lượng ảnh rác của một khách hàng có thể lên tới: 70*4= 280 ảnh rác.

Thực sự quá kinh khủng và có vấn đề về cách xử lý, nên sau khi giãn giãn việc triển khai các dự án về ví trả sau, ví khách hàng doanh nghiệp thì mình quay lại bóc tách vấn đề và xử lý lại việc dọn dẹp ảnh này.

Đội hạ tầng công nghệ báo cáo rằng hệ thống lưu trữ của bên mình chỉ có khoảng 40TB để lưu trữ dữ liệu (cho domain về Ví), nếu không xử lý ngay thì sẽ không còn đủ dung lượng để lưu trữ ảnh cho khách hàng mới, cũng như để sử dụng cho những công việc backup khác.

Những việc đã xử lý trước đây

Thực ra trước khi thực hiện việc xoá hơn 3 triệu ảnh này, thì mình đã thực hiện một phần tối ưu trước đó rồi, đó là giảm việc gia tăng dung lượng quá nhiều của việc lưu trữ ảnh của các phiên lỗi.

Cũ: ảnh của phiên ekyc bị lỗi vẫn đang luôn luôn được lưu vào ổ share chung

Mới: chỉ lưu ảnh cho phiên thành công, các phiên bị lỗi sẽ không thực hiện lưu ảnh

Sau khi phần này golive thì dung lượng ổ NAS đã giảm đi được khá nhiều, mức sử dụng hằng ngày đã giảm từ đỉnh 80GB/ngày xuống chỉ còn ở mức 10GB/ngày, tuy nhiên mình cảm thấy vẫn chưa thực sự triệt để, nhưng thôi cần phải ưu tiên xử lý những cái quan trọng hơn.

Bài này mình sẽ không đi chi tiết vào việc thực hiện của việc giảm đó, mà mình sẽ tập trung vào phần xử lý ảnh đã tồn tại từ trước, vì lượng này nhiều và cần loại bỏ sớm.

Ảnh nào sẽ được coi là rác

Có hai thư mục ảnh đang tồn tại song song, đó là /originals/ và /temps/, nó có sự khác nhau như sau:

/originals/: đây là thư mục ảnh gốc của khách hàng sau quy trình định danh thành công, không được phép xoá ảnh ở thư mục này

/temps/: về mặt thiết kế ban đầu thì thư mục này lưu trữ ảnh tạm và có thể xoá bất kì khi nào

Tuy nhiên sau khi mình rà soát về logic trong code thì không thể nào xoá 100% ảnh trong thư mục /temps/ này được, vì có nhiều khách hàng vẫn đang sử dụng ảnh ở thư mục này cho các việc như: login, đổi thiết bị, xác thực giao dịch, mở ví trả sau,…

Dẫn tới mình phải đi lò dò từng bước để tìm ra những ảnh phù hợp để xoá, chứ không thể nào chém sạch ảnh trong thư mục /temps/ đi được.

Điều kiện xác định ảnh đủ điều kiện xoá

Sau khi rà soát dữ liệu hiện tại, mình tập trung xử lý xoá ảnh rác cho những khách hàng thoả mãn những điều kiện sau:

Khách hàng đã định danh chip (quét NFC, xác thực RAR thành công).
Khách hàng phải có đủ ảnh ở thư mục /originals/, nghĩa là 4 thông tin ảnh chính của khách hàng phải nằm ở thư mục gốc, không được phép có ảnh đang sử dụng nằm ở thư mục /temps/.
Khách hàng chỉ có 1 phiên ekyc định danh thành công, nghĩa là mình sẽ tập trung xử lý cho những khách hàng chỉ làm duy nhất 1 phiên định danh thành công (lượng này xấp xỉ khoảng 780k khách hàng), tệp khách hàng thực hiện nhiều hơn 1 phiên mình sẽ xử lý sau.
Đường dẫn ảnh của các phiên định danh cần xoá phải nằm ở thư mục /temps/, và mình sẽ chỉ thực hiện xoá các ảnh nằm ở thư mục này, tuyệt đối không xoá nhầm ảnh ở trong thư mục /originals/.

Cách thực hiện

Mình thực hiện chia làm ba phần xử lý như sau:

1. Job quét 1 lần để xác định các bản ghi thoả mãn điều kiện xoá

Trước tiên mình chọn thời điểm cutoff là ngày 05/02/2026.

Mình triển khai 1 con job chạy 1 lần, xử lý các bản ghi khách hàng đã định danh thành công trước ngày 05/02/2026.

Job này sẽ xử lý quét toàn bộ khách hàng của VETC với bộ điều kiện ở đoạn trên, thực hiện một vài logic nhất định để xác định ra các khách hàng mà chỉ có 1 phiên định danh thành công, đẩy dữ liệu đủ điều kiện cần xoá vào 1 bảng cleanup_tasks.

Ở thời điểm job chạy, mình quên mất là mình đang quét danh sách khách hàng trên 1 cái view đã tổng hợp dữ liệu, nên việc quét diễn ra chậm hơn so với dự kiến của mình.

Thông thường việc scan 3 triệu khách hàng chỉ ở mức vài phút, tuy nhiên mình quét trên 1 cái view, view này không có index nên việc quét diễn ra chậm hơn bình thường (mình sẽ rút kinh nghiệm ở đoạn quét này).

Trước đây mình từng viết bài về phương pháp để quét dữ liệu nhanh, các bạn có thể xem cách thức ở bài: Tổng hợp dữ liệu cho 1 triệu tài khoản trong 4 phút

Tổng số bản ghi của job all đã quét được là 775.754 bản ghi thoả mãn điều kiện cần xoá.

Về cơ bản thì mỗi bản ghi sẽ bao gồm 4 ảnh cần xoá, 775.754 *4 = 3.103.016 ảnh cần xoá

2. Job quét hằng ngày để xác định các bản ghi thoả mãn điều kiện xoá

Tại sao có job chạy 1 lần rồi mà vẫn phải có job daily này, đơn giản là vì cái job chạy 1 lần ở trên, mình chỉ chạy với các khách hàng định danh từ thời điểm trước ngày 05/02/2026, còn job daily này sẽ chạy từ thời điểm 05/02/2026 đổ về sau.

Tức là nó sẽ luôn chạy để xác định ra những khách hàng mới có 1 phiên định danh thoả mãn bộ điều kiện, và đưa vào bảng tạm cleanup_tasks để sau này xoá dần.

Số bản ghi mà job daily đã thực hiện quét được tính đến thời điểm từ sau lần chạy job all là 8420 bản ghi, khoảng 33.680 ảnh cần xoá.

3. Job quét hằng ngày để thực hiện xoá ảnh thực tế trong ổ NAS

Sau khi dữ liệu đủ điều kiện xoá được đưa vào bảng cleanup_tasks, thì mình triển khai thêm job chuyên thực hiện logic nghiệp vụ xoá ảnh thực tế, cập nhật một số trạng thái, ghi lại log để theo dõi.

Ban đầu mình để job chạy 5p/lần, tuy nhiên job xử lý xoá 400*4 = 1600 ảnh khá là nhanh, mỗi job chỉ mất cỡ dưới 10s, nên mình nâng tần suất lên thành chạy từng phút.

Logic xử lý ở đây không nặng, chủ yếu là việc xử lý I/O tương tác với ổ NAS sẽ là chính, nên lúc job chạy mình đều phải theo dõi log khá kĩ, tần suất xử lý, trạng thái I/O.

Sau hai ngày cuối tuần thứ 7 và chủ nhật thì kết quả khá là khả quan:

Số ảnh đã xoá: 3.120.260 ảnh (3 triệu )
Dung lượng sử dụng giảm từ 94% xuống 82% (giảm 12% tổng capacity)
Quá trình thực hiện ổn định, không ảnh hưởng đến hiệu năng hệ thống và không ghi nhận lỗi phát sinh từ phía người dùng
Job daily vẫn tiếp tục chạy để xử lý dữ liệu phát sinh mới

Hướng triển khai tiếp theo

Hiện tại phần triển khai xoá đã xong, kết quả dung lượng đã giảm được hơn 2,3TB, mình lại có thêm thời gian để nghiên cứu xử lý xoá tiếp với các tập dữ liệu còn lại.

Sau khi nhờ DevOps thống kê thêm dung lượng ổ NAS sau khi xoá 3 triệu ảnh, thì có hai thư mục đang chiếm nhiều dữ liệu nhất ở ổ NAS:

Các bạn có thể thấy ở ảnh trên,

4.1TB là lượng dữ liệu dành cho lưu trữ ảnh gốc (/originals/) của người dùng: sẽ không xoá gì ở thư mục này
5.1TB là dữ liệu của thư mục /temps/, nghĩa là có thể xoá thêm nhiều ảnh rác nữa ở thư mục /temps/ này

Để có phương án xử lý cho 5.1TB kia thì mình sẽ rà soát và xử lý ở bài viết sau nhé, hiện tại thì mình cũng chuẩn bị nghỉ Tết rồi, ra Tết sẽ hoàn thiện phương án để xử lý tiếp.

Xem thêm các bài viết nổi bật bên dưới:

Post Views: 104