Netflix Billing Migration to AWS

Netflix · 2016 · 4. Điều chỉnh · Độ khó: Trung bình — bài gốc

Series 3 phần: phần 1 (tổng quan, bài này) · Netflix 2016 (ứng dụng và dữ liệu khách hàng) · Netflix 2016 (database Oracle → MySQL).

Bối cảnh

• Billing là mảnh cuối cùng của Netflix còn ở data center khi cả streaming đã lên AWS (Netflix 2016). Ngày 4/1/2016, ngay trước đợt mở rộng ra 130 nước mới, billing chạy 100% trên AWS.
• Billing gồm batch job tạo đơn gia hạn định kỳ, đẩy dữ liệu doanh thu vào sổ cái (GL), tax service; API cho website và chăm sóc khách hàng; tích hợp với account, payment, messaging, DVD. Dữ liệu từ năm 1997, hàng tỷ dòng, nằm trong một Oracle dùng chung khổng lồ và đổi từng phút.
• Ràng buộc: không downtime cho luồng người dùng; hệ mới phải scale theo số thành viên tăng nhanh; là hệ SOX nên mọi công cụ migration phải tuân quy trình kiểm toán; không được làm chậm các team khác cũng đang migrate và mở nước mới.

Thay đổi chính

• Tách Oracle theo nhu cầu nhất quán: dữ liệu subscriber sang Cassandra (cần multi-region, sẵn sàng cao); dữ liệu thanh toán cần giao dịch ACID sang MySQL.
• Đơn giản hoá trước khi chuyển: chặt code thành module nhỏ, chuyển tax service lên cloud trước; bỏ việc phục vụ lịch sử billing từ các bảng lớn dùng chung, xây app mới ghi sự kiện billing vào Cassandra; purge dữ liệu: xét từng bảng, hỏi team pháp lý và CSKH họ thật sự cần lịch sử nào, chuyển phần còn lại sang kho khác rồi xoá.
• Công cụ để vừa an toàn vừa tuân thủ: proxy và redirector đẩy dữ liệu ngược về DC để ứng dụng chưa chuyển không bị ảnh hưởng; Spinnaker ghi sự kiện deploy cho audit; Cassandra client có xác thực và audit; comparator đối chiếu dữ liệu Cassandra với Oracle theo từng nước qua Hive.
• Thử trước bằng dữ liệu sạch: các nước mới mở được chạy luôn trên một hạ tầng billing "gầy" ở cloud, rồi mới mở rộng cho nước cũ lớn (Mỹ có cả DVD).
• Tách luồng người dùng khỏi downtime: chuyển tích hợp signup/đổi gói sang mô hình bất đồng bộ có retry và quản lý trạng thái lạc quan, nên lúc dừng xử lý để chuyển dữ liệu một nước thì thành viên không bị phạt.
• Database có kế hoạch riêng: RDS lúc đó không chứa nổi DB nhiều TB nên chọn MySQL tự vận hành trên EC2, master có bản DRBD, read replica ở nhiều region, ETL chạy trên replica. Dữ liệu đang đổi được đồng bộ bằng Oracle GoldenGate chạy song song production vài tháng; vài tuần trước khi chuyển, môi trường test chạy hẳn trên MySQL để sửa lỗi sớm.

Vì sao

• Theo Netflix: hệ cũ không theo kịp tốc độ tăng thành viên và kế hoạch toàn cầu; billing là "mạch sống tài chính" nên ưu tiên đường đi an toàn, chia nhỏ hơn tốc độ.

Bài học cho SWE

• Nhìn lại, Netflix nói họ đánh giá thấp nhu cầu test tự động: không có cách tốt để test luồng end-to-end, đầu tư sớm thì đã nhanh hơn.
• Migration là dịp xoá: code chết, bảng không ai cần, tích hợp lỗi thời. Hỏi người dùng dữ liệu thật sự cần gì trước khi chuyển hàng tỷ dòng.
• Chia theo đơn vị có thể cắt riêng (ở đây là quốc gia) cho phép bắt đầu với phần nhỏ, sạch và lùi lại từng phần.
• Đổi tích hợp đồng bộ sang bất đồng bộ trước khi migrate biến "downtime của hệ sau" thành "trễ xử lý" mà người dùng không thấy.

Liên quan

• Migration không downtime · Chọn database theo workload · Monolith và microservices — đi và quay lại
• Bức tranh migration chung: Netflix 2016