Kiến trúc nền tảng tập trung để xóa dữ liệu an toàn tại Netflix

Bạn đã bao giờ lỡ tay chạy lệnh xóa dữ liệu và ngay lập tức hoảng loạn chưa? Cảm giác ấy, đặc biệt là khi chạy lệnh rm -rf vào thời điểm không mong muốn, là cơn ác mộng của mọi kỹ sư. Một lệnh duy nhất có thể xóa sạch years of production load (dữ liệu sản xuất tích lũy qua nhiều năm). Đây là lời nhắc nhở chilling (rùng mình) rằng chúng ta phải nghiêm túc coi trọng việc mất mát và xóa dữ liệu.

Tại hội nghị QCon San Francisco, Vidhya Arvind (Staff Engineer) và Shawn Liu (Senior Software Engineer) từ Netflix đã chia sẻ về hành trình xây dựng một nền tảng tập trung để giải quyết vấn đề này. Họ thảo luận về các thách thức kiến trúc khi thực hiện xóa dữ liệu an toàn trên các hệ thống lưu trữ phân tán, cân bằng giữa độ bền (durability), khả dụng (availability) và tính chính xác (correctness).

Ba trụ cột của việc xóa dữ liệu an toàn

Để xóa dữ liệu an toàn, Netflix tập trung vào ba trụ cột chính:

1. Độ bền (Durability): Đảm bảo dữ liệu bị xóa và sẽ không bao giờ xuất hiện lại.
2. Khả dụng (Availability): Đảm bảo hệ thống vẫn vận hành trơn tru và an toàn khi quá trình xóa đang diễn ra.
3. Tính chính xác (Correctness): Đảm bảo các thao tác xóa là chính xác và hoàn chỉnh, đặc biệt trong môi trường có các ghi đồng thời (concurrent writes).

Độ bền: Thách thức với các hệ thống lưu trữ khác nhau

Mỗi hệ thống lưu trữ dữ liệu xử lý việc xóa theo cách riêng. Cassandra sử dụng cơ chế tombstone (đánh dấu xóa) và chờ quá trình nén (compaction) để thực sự xóa dữ liệu. DynamoDB xóa ngay lập tức, trong khi EVCache và Redis dựa vào TTL (Time To Live) hoặc cơ chế loại bỏ lười (lazy eviction). Elasticsearch và RDS lại yêu cầu các quy trình nền hoặc lifecycle management riêng.

Vấn đề phát sinh khi các cơ chế này tạo ra các chi phí ẩn. Ví dụ, việc tích lũy quá nhiều tombstone trong Cassandra có thể dẫn đến việc đọc chậm hơn do phải quét qua các đánh dấu xóa, gây ra read timeouts. Quá trình compaction để dọn dẹp các tombstone này tiêu tốn nhiều tài nguyên CPU và I/O, thậm chí gây ra "compaction storm" (bão nén dữ liệu), làm destabilize (làm mất ổn định) toàn bộ cụm cluster.

Một vấn đề khác là "ghost data" (dữ liệu ma). Vidhya Arvind kể lại một sự cố khi misconfiguration trong cụm Cassandra khiến các process không khởi động lại quá 24 giờ. Khi node được đưa lên lại, dữ liệu vốn lẽ đã bị xóa lại "hồi sinh" (resurrect), gây ra tác động dây chuyền phức tạp.

Khả dụng: Không ảnh hưởng đến lưu lượng trực tiếp

Việc xóa hàng loạt (bulk deletes) có thể làm cạn kiệt tài nguyên và làm chậm hệ thống. Để giảm thiểu rủi ro này, Netflix áp dụng một số kỹ thuật:

• Xóa theo cấp độ phân vùng (Partition-level deletes): Thay vì xóa từng hàng một, việc xóa cả một phân vùng giúp giảm thiểu số lượng tombstone tạo ra.
• TTL Jitter: Thêm tính ngẫu nhiên vào thời gian hết hạn của từng mục để phân tán các thao tác xóa, tránh việc chúng xảy ra đồng thời gây quá tải.
• Giới hạn tốc độ (Rate Limiting): Kiểm soát tốc độ xóa dựa trên các chỉ số sử dụng tài nguyên của hệ thống lưu trữ. Nếu CPU hoặc lưu lượng truy cập tăng cao, quá trình xóa sẽ được giảm tốc độ hoặc tạm dừng để ưu tiên cho traffic trực tiếp.

Tính chính xác: Xử lý xung đột và ghi đồng thời

Trong các hệ thống phân tán, xung đột là điều không thể tránh khỏi. Khi một client đang xóa dữ liệu trong khi một client khác đang ghi vào cùng một ID, hệ thống cần cơ chế giải quyết xung đột.

• Last Write Wins: Cassandra sử dụng cơ chế này, nơi thao tác ghi cuối cùng dựa trên timestamp sẽ thắng.
• Idempotency Token: Sử dụng token duy nhất cho mỗi thao tác ghi để đảm bảo tính thứ tự và cho phép retry (thử lại) một cách an toàn mà không làm thay đổi trạng thái cuối cùng.
• Compare-and-Set: Các hệ thống như RDS sử dụng ghi có điều kiện để đảm bảo chỉ một thao tác thành công, từ đó duy trì tính nhất quán.

Kiến trúc nền tảng xóa dữ liệu tập trung

Để quản lý việc xóa dữ liệu trên quy mô lớn, Netflix đã xây dựng một kiến trúc tập trung với các giai đoạn chính:

1. Nhận diện (Identification): Xác định dữ liệu nào cần xóa và nằm ở đâu. Điều này được thực hiện thông qua input từ chủ sở hữu dữ liệu (data owners), schema registry và các annotation.
2. Kiểm toán và Xác thực (Audit & Validation): Chạy các workflow định kỳ để sao lưu bảng định danh và bảng dữ liệu vào S3. Các công việc kiểm toán sẽ so khớp và xác thực để tìm ra dữ liệu đủ điều kiện xóa. Một bước xác thực tiếp theo đảm bảo rằng dữ liệu được đánh dấu là an toàn để xóa thực sự nên bị xóa (ví dụ: chưa được khôi phục lại trong lúc chờ xử lý).
3. Thực thi xóa (Deletion): Dịch vụ xóa sẽ nhận danh sách cuối cùng và thực hiện xóa dữ liệu từ các hệ thống tương ứng (Cassandra, RDS, v.v.). Quá trình này được điều phối cẩn thận để tránh quá tải hệ thống. Tất cả các thao tác xóa đều được ghi lại vào một Journal Service thông qua Kafka để đảm bảo tính truy vết (traceability).
4. Giám sát liên tục (Continuous Monitoring): Ngay cả sau khi xóa, hệ thống vẫn tiếp tục chạy các chu kỳ kiểm toán để bắt bất kỳ sự thất bại hoặc xóa không hoàn chỉnh nào. Các chỉ số như số lượng bản ghi có thể xóa, thời gian lưu trữ quá hạn và tỷ lệ xóa thành công/thất bại được theo dõi chặt chẽ.

Xây dựng lòng tin và Khôi phục dữ liệu

Một trong những thách thức lớn nhất khi tập trung hóa việc xóa dữ liệu là xây dựng lòng tin từ các đội ngũ khác. Không ai muốn một đội trung tâm xóa dữ liệu của họ nếu không có sự đảm bảo an toàn.

• Trust but Verify (Tin nhưng vẫn kiểm tra): Các công việc kiểm toán giúp xác minh rằng dữ liệu đã bị xóa thực sự biến mất và không bị "hồi sinh" do lỗi hệ thống.
• Khả năng khôi phục (Recovery): Journal Service không chỉ ghi log mà còn lưu trữ dữ liệu thực tế trong 30 ngày trên S3 với chi phí thấp. Điều này cho phép khôi phục dữ liệu nhanh chóng nếu phát hiện lỗi hoặc xóa nhầm trong vòng một tháng.
• Giao diện xóa có thể cắm (Pluggable Deletion Interface): Cho phép người dùng tùy chỉnh logic xóa thông qua plugins và callback URLs, tăng tính linh hoạt và khả năng mở rộng cho nền tảng.

Bài học kinh nghiệm

Thông qua quá trình triển khai, Netflix đã xác định được 1.300 tập dữ liệu đủ điều kiện xóa và đang quản lý 76,8 tỷ hàng dữ liệu cần xóa. Các bài học chính rút ra được bao gồm:

• Kiểm toán liên tục: Luôn kiểm tra những gì thực sự bị xóa để phát hiện vấn đề sớm.
• Nền tảng tập trung: Cung cấp khả năng hiển thị rõ ràng và nhất quán.
• Thích ứng với từng hệ thống: Điều chỉnh cách tiếp cận cho từng công cụ lưu trữ (Cassandra khác với RDS hay S3).
• Tính đàn hồi: Sử dụng các kỹ thuật như phân tán TTL, giới hạn tốc độ và loại bỏ tải (load shedding) để giữ hệ thống ổn định.
• Tối ưu hóa cho xóa hàng loạt: Sử dụng định dạng gốc và công cụ cụ thể (như SSTables cho Cassandra) để giảm chi phí và cải thiện hiệu suất.

Với chiến lược này, Netflix đã có thể "đẩy viên domino đầu tiên" — thực hiện một yêu cầu xóa — và tin tưởng rằng mọi thứ sẽ diễn ra an toàn, suôn sẻ trên toàn bộ hệ thống phân tán phức tạp của họ.