Journey to the cloud part II: Migrating Stack Overflow for Teams to Azure

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

Phần 2 của series; phần 1 (lý do và pha 1, đổi domain): Stack Overflow 2023.

Bối cảnh

Sau pha 1, Teams đã chạy ở stackoverflowteams.com nhưng mới tách "bề ngoài". Phía sau vẫn dùng chung với stackoverflow.com: DB Sites (nền của multi-tenancy), DMZ nhận request rồi chuyển vào vùng khoá kín TFZ, và quy trình deploy TeamCity.

Thay đổi chính

Pha 2: tách hạ tầng ngay trong data center.
- Dựng môi trường Teams độc lập ở dev, deploy bằng Octopus Deploy (bỏ dần TeamCity).
- Viết kịch bản 27 bước (cấu hình IIS, chép DB Sites sang TFZ, tắt code Teams ở DMZ, deploy app vào TFZ, đổi load balancer) và tập dượt trên dev. Lần tập đầu dự kiến 1 giờ, sau 4 giờ thì bỏ: câu hỏi mới mất 5 phút mới hiện trên trang tổng quan, vì sai tiền tố key Redis dùng để báo cho TagEngine có câu hỏi mới. Sửa rồi tập lại. Cắt chuyển thật ngày 11/3/2023 không có sự cố.
Pha 3: dựng bản sao chỉ đọc trên Azure, chọn lift-and-shift để không đổi cùng lúc cả hạ tầng lẫn ứng dụng:
- Web: ảnh VM dựng bằng Packer (gồm bản vá OS, IIS, .NET, chứng chỉ), chạy trên VM Scale Set. Ảnh là bất biến: cập nhật OS thì tạo VM mới rồi xoá VM cũ; nhờ đó bỏ được công cụ vá nội bộ Patcher, Ansible và Puppet. App thì không bake vào ảnh, vì build ảnh mất vài giờ còn deploy app mất vài phút.
- Production có 4 VM 32 nhân, 128 GB RAM (nhiều RAM vì cache và TagServer). Mỗi VM chạy 6 app: web, API v2/v3, Scheduler, TeamsDbApi, StackMail, TagServer.
- Rolling: VM mới có agent Octopus, agent tự deploy mọi app; health endpoint của web app chỉ báo khoẻ khi mọi app khác đã sẵn sàng. App lỗi thì VMSS dừng rolling, VM lỗi không nhận traffic. Deploy app thường thì đánh dấu từng app trên từng VM là unhealthy ở Application Gateway trước khi deploy. Theo bài, cách này phức tạp và dễ hỏng, "đủ tốt cho lift-and-shift".
- Edge: giữ Fastly, thêm hai Azure Application Gateway (trong và ngoài, hai subnet). mTLS giữa Fastly và Gateway để chỉ Fastly vào được. Tách cấu hình Fastly từ một khối chung thành mỗi workload một service, để dựng được nhiều môi trường song song.
- Redis: dùng Azure Cache for Redis (managed) qua Private Link.
- Elasticsearch: Elastic Cloud chạy được ở test nhưng khi nạp nhiều dữ liệu thì node master chết ngẫu nhiên. Chuyển sang tự chạy trên AKS bằng Elastic Operator, nhờ nhìn rõ hơn mà tìm ra nguyên nhân: mỗi Team một filtered alias (để không khách nào truy vấn được dữ liệu của khách khác) và số alias quá lớn làm chậm một API. Sửa bằng cấu hình cho phép nhiều alias hơn.
- SQL Server: on-prem là một availability group trải hai data center (4 node; đọc chỉ-đọc từ secondary cùng region, DR ở region kia). DB Sites cùng hàng chục DB, mỗi DB khoảng 1.000 Team. Để đồng bộ dữ liệu, họ mở rộng AG sang VM SQL Server trên Azure, vì vậy không dùng được Azure SQL Database hay Managed Instance. Môi trường Azure chạy chỉ đọc, app tắt mọi route ghi.
- Môi trường tạm (ephemeral) dùng Azure SQL Database, tạo bằng một PR, ví dụ môi trường chạy test Mabl mỗi đêm.
Pha 4: chuyển Azure thành primary. Viết lại cấu hình Fastly (mTLS, chứng chỉ Let's Encrypt tự động). Failover AG liên tục timeout vì độ trễ mạng, nên phải ép node Azure thành primary và cho node on-prem ngừng hoạt động; sau đó restore DB về một node on-prem và nối lại vào AG để vẫn fail-back được. Thêm region West US làm secondary, dựng dễ nhờ infrastructure as code.
Pha 5: chặn firewall, gỡ node on-prem khỏi AG, tắt máy chủ Teams on-prem. Tổng cộng gần hai năm.

Vì sao

Theo bài: lift-and-shift để giảm rủi ro, hiện đại hoá sau khi đã lên cloud; managed service chỉ dùng chỗ "chạy được ngay" (Redis).

Việc còn lại (theo bài, 2023)

AG giữa East US và West US chậm khi VM SQL được join domain; đang xem chuyển sang Azure SQL Database.
Muốn bỏ VM, chuyển app sang container (đã có AKS cho Elastic). Theo Stack Overflow 2025, sau đó họ chuyển hết lên Kubernetes.

Bài học cho SWE

Tập dượt kịch bản cắt chuyển trên dev cho tới khi trơn tru; lỗi cấu hình nhỏ (tiền tố key) chỉ lộ ra khi tập.
Đồng bộ dữ liệu bằng cách mở rộng cụm replica sang nơi mới rồi failover là mẫu chung, nhưng độ trễ giữa hai nơi có thể làm failover tự động thất bại; cần sẵn phương án ép.
Ảnh bất biến cho OS nhưng deploy app riêng là thoả hiệp giữa tính bất biến và tốc độ.
Cách cô lập tenant (một alias mỗi tenant) có thể chạm giới hạn ẩn của hệ bên dưới khi số tenant lớn.