Image Migration to Google Cloud Platform

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

Bối cảnh

• trivago nhận ảnh khách sạn từ OTA, chuỗi khách sạn, nhà cung cấp nội dung; nhiều pipeline lọc, gắn nhãn (ML), chọn ảnh chính và gallery.
• Khởi đầu: framework PHP nội bộ, RabbitMQ, worker trong data center, mọi pipeline dùng chung một DB.
• Lần 1 (2018), sang AWS: input tăng từ khoảng 100 lên gần 150 triệu ảnh; DB chung đã phình và nhiều team khác vẫn coi là nguồn sự thật, nên chỉ chuyển pipeline consumer: ảnh lên S3, replicate phần DB liên quan sang AWS qua Kafka + Debezium, đổi PHP sang Python, thêm pipeline sinh ID ảnh mới nhưng phải giữ bảng ánh xạ ID cũ ↔ mới vì vài team còn dùng ID cũ. Kết quả là ba phần phải nuôi: pipeline ở data center, pipeline replication, pipeline consumer.
• Lần 2, sang GCP (chiến lược thu gọn số nhà cung cấp cloud): chuyển ảnh một lần quá đắt, pipeline gắn với đường dẫn S3, DB replica và ID mới khó chuyển; nên chỉ dời phần xử lý sang GCP, để file ảnh và pipeline ID ở AWS. Sau một thập kỷ, hạ tầng ảnh trải trên ba môi trường, khó sửa, khó debug.

Thay đổi chính

• Ba sai lầm theo trivago:
  1. Bắt đầu từ pipeline consumer để khỏi làm vỡ người dùng DB/API; nhưng DB là trái tim, chuyển nó trước sẽ khó hơn lúc đầu mà sạch hơn nhiều;
  2. không dừng lại đánh giá lại yêu cầu trước khi migrate, chỉ dời nguyên các thành phần cũ;
  3. theo mẫu kiến trúc đang thịnh (Kinesis → Lambda) mà không phân tích có hợp không: chậm và làm chi phí cloud tăng mạnh; Spark/Beam hợp hơn.
• Lần cuối (giữa 2022 → khoảng 1,5 năm): một team ảnh chuyên trách (gộp hai team) thiết kế lại thay vì migrate:
  • liệt kê stakeholder, yêu cầu, pipeline và giới hạn theo luồng dữ liệu (hơn một tháng);
  • API trước: thống nhất schema Swagger với hai team dùng để họ làm song song;
  • MySQL managed, chuẩn hoá bảng, sinh ID ảnh ngay trong DB, bỏ pipeline ID đắt tiền chạy trên AWS;
  • ingest batch bằng Apache Beam (Dataflow); ID thống nhất giúp khử trùng ảnh cùng URL hay từ nhiều đối tác; ảnh ở GCS sau CDN;
  • thống nhất schema topic Kafka với các team consumer.
• Go-live theo giai đoạn qua A/B test: staging nối với staging của các team liên quan vài tuần; production theo thứ tự API (công cụ admin, Business Studio) → pipeline ảnh chính → gallery. Phải viết thêm thành phần làm nóng cache CDN để nhóm dùng hạ tầng mới không bị bất lợi so với control.
• Kết quả: khách sạn đổi ảnh chính thấy trên trivago sau vài giây, so với khoảng một ngày ở hạ tầng AWS cũ.
• Khó khăn: gộp hai team (hai lead, hai PM phải chia vai); hơn một năm không có kết quả end-to-end vì các thành phần chỉ test riêng; tài liệu hoá mọi thứ và bắt mọi người ký đọc.

Vì sao

• Hai lần migrate từng phần để lại hệ phân tán qua nhiều môi trường; chỉ thiết kế lại theo yêu cầu hiện tại mới gỡ được.

Bài học cho SWE

• Migrate từng phần mà để lại DB chung và ánh xạ ID ở chỗ cũ thì mỗi lần chuyển lại thêm một lớp đồng bộ; đôi khi phải chuyển trái tim trước (Migration không downtime).
• "Lift-and-shift" pipeline dữ liệu kéo theo mọi giả định cũ; khi nền đã đổi, viết lại theo yêu cầu có thể rẻ hơn (Pipeline dữ liệu và analytics).
• Chốt hợp đồng (API schema, schema topic) sớm để các team làm song song.
• A/B test cả một hạ tầng cần đảm bảo hai nhánh công bằng (cache nóng như nhau).

Liên quan

• Cùng công ty: trivago 2018 · trivago 2021 · trivago 2026 · trivago 2026
• Pipeline ảnh tương tự: Expedia 2016
• Migration không downtime · Pipeline dữ liệu và analytics