Netflix Billing Migration to AWS — Part III

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

Series 3 phần: Netflix 2016 · Netflix 2016 · phần 3 (bài này, góc nhìn team Cloud Database Engineering).

Bối cảnh

• Mảnh cuối: database billing giao dịch, khoảng 10 TB (2016), dữ liệu đổi liên tục, chỉ chuyển một phần dataset, khác phần cứng, khác OS, khác hệ quản trị (Oracle → ?), giữa DC và AWS.

Thay đổi chính

• Chọn database: Oracle trên cloud (đỡ chuyển đổi nhưng đắt license và mang theo nợ kỹ thuật); RDS MySQL (giới hạn 6 TB lúc đó, cần gần 10 TB); Aurora (đủ dung lượng nhưng còn beta); PostgreSQL (ít kinh nghiệm nội bộ, và chặn đường sang Aurora sau này). Chọn MySQL InnoDB tự chạy trên EC2 i2.8xlarge: không license, giữ đường sang Aurora.
• Kiến trúc: master có bản DRBD đồng bộ sang zone khác (ghi chỉ xong khi cả hai phía xác nhận, mất một node không mất dữ liệu, đổi lại latency ghi vẫn trong SLA); read replica cùng region và khác region, ETL đọc từ replica. Master hỏng thì failover sang bản DRBD và đổi bản ghi Route53; ứng dụng billing là batch nên chịu được khoảng gián đoạn, client mở kết nối mới sau khi CNAME lan xong.
• Công cụ migrate: tiêu chí là chạy lại được bulk load, replication hai chiều (để rollback từ MySQL về Oracle sau khi go-live), song song theo bảng, toàn vẹn dữ liệu. Chọn GoldenGate; nhược điểm là khó học và cấu hình tay dễ sai. Bảng không có primary/unique key thì GoldenGate dùng mọi cột làm khoá và sinh dòng trùng khi load gia tăng, nên các bảng đó load lại toàn phần lúc cutover.
• Chuyển schema: NUMBER của Oracle có khi là số nguyên, có khi là thập phân, có khi dài 38 chữ số, còn BIGINT của MySQL tối đa 18 chữ số; partition key của MySQL phải nằm trong primary key; MySQL tự gán default cho cột NOT NULL nên phải bật strict mode để lỗi hiện trong log GoldenGate. Công cụ chuyển schema tự động không dùng được với schema cũ; team DB và team ứng dụng duyệt kiểu dữ liệu qua nhiều vòng. GoldenGate cắt cụt giá trị không vừa kiểu, nên dựa vào so sánh dữ liệu và error log.
• Kiểm toàn vẹn: 10 TB khó so sánh toàn bộ nên so mẫu bằng công cụ bên thứ ba; dựng môi trường test từ EBS snapshot của replica nhiều lần; chạy cùng Sqoop/ETL báo cáo trên cả hai DB theo cửa sổ thời gian; đếm dòng sau khi tạm dừng load gia tăng.
• Hiệu năng: từ máy IBM Power7 750 GB RAM gộp về một EC2 32 vCPU, 244 GB RAM; RAID0 trên 5 volume EBS PIOPS 4 TB (thay một volume lớn để snapshot/restore nhanh); hai file cnf: một cho lúc bulk load (log file lớn), một cho tải giao dịch thật; tạo index trước khi load vì tạo index trong MySQL đơn luồng, còn GoldenGate load song song; số tiến trình load bằng số core. Mất khoảng 2 tuần để nạp 10 TB và cho load gia tăng đuổi kịp.

Vì sao

• Theo Netflix: database quyết định thành bại của cả migration; khả năng lùi lại (replication hai chiều) quan trọng hơn sự dễ dùng của công cụ.

Bài học cho SWE

• Đổi hệ quản trị là đổi ngữ nghĩa kiểu dữ liệu: cắt cụt và giá trị mặc định ngầm là lỗi im lặng, phải bật chế độ chặt để lỗi thành tiếng.
• Cần đường rollback sau go-live, không chỉ trước go-live.
• Không so được toàn bộ thì ghép nhiều phép kiểm rẻ: so mẫu, đếm dòng, chạy cùng báo cáo trên hai bên, chạy ứng dụng thật trên bản sao.

Liên quan

• Migration không downtime · Failover, replica và dự phòng dữ liệu · Chọn database theo workload
• Phần ứng dụng: Netflix 2016