Moving the public Stack Overflow sites to the cloud: Part 1

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

Tiếp nối việc chuyển Teams lên Azure (Stack Overflow 2023, Stack Overflow 2023). Kết thúc data center: Stack Overflow 2025.

Bối cảnh

Site public (Stack Overflow và mạng Stack Exchange) chạy trên máy chủ vật lý từ đầu: một máy → thêm máy SQL → data center (2010) → thêm CDN. Theo bài, các tối ưu hiệu năng đã cản trở cách làm hiện đại như service độc lập và autonomy của team (Stack Overflow 2021).
Hạn chót cứng: 31/7/2025, khi hợp đồng data center hết và không gia hạn được vì cơ sở đó đóng cửa.
Theo tác giả, phần lớn site public "vẫn được thiết kế quanh việc có một data center": giả định về độ trễ, tên server, hiệu năng. Câu hỏi lớn nhất là "liệu nó có chạy được không".

Thay đổi chính

Bài học rút từ lần chuyển Teams (mất ba lần thử trong ba năm):
- không công bố các mốc nội bộ không ảnh hưởng tới user, để trễ nhỏ không thành vấn đề truyền thông;
- có đội chuyên trách ngay từ đầu (lần Teams chỉ tiến triển khi có người làm toàn thời gian);
- chia bước nhỏ thay vì big bang;
- sau khi lên Azure, Teams đã chuyển từ VM Windows/IIS sang Kubernetes, nhiều thành phần đã được container hoá sẵn; lần này tránh VM, trừ SQL Server.
Load test trước tiên: vì app có những giả định kiểu "phản hồi trên 30 ms là gây sự cố cho cả site". Chưa từng có load test cho site public. Môi trường test giống production (trừ quy mô và quyền truy cập), không dùng chung dependency, dựng bằng Terraform. Lúc đầu tạm chạy trên Kubernetes ở Azure vì hạ tầng GCP chưa xong. Mỗi vòng sửa các chỗ chậm mà ở data center không lộ ra, cho tới khi số request/giây chịu được vượt xa mức cần ở data center.
Chọn nền tảng: ban đầu định dùng Azure (nơi đang chạy Teams và Enterprise), sau chọn GCP do quan hệ đối tác với Google. Region us-central1 (Iowa), vì cần loại VM bộ nhớ cực lớn ở hai zone, phải cách xa các region Azure, và đặt ở Mỹ. Chạy multi-zone trong một region.
Thành phần:
- Kubernetes cho mọi app; vài app cũ còn dùng .NET Framework, không kịp nâng cấp trước hạn nên chạy trên cụm Kubernetes Windows;
- CI chuyển từ TeamCity sang GitHub Actions, artifact lưu ở CloudSmith, deploy bằng Octopus. Một số service phải deploy cho ba sản phẩm (public trên GCP; Teams multi-tenant và nhiều instance Enterprise single-tenant trên Azure), nên đóng gói script và artifact thành CNAB để các team không phải biết chi tiết từng nơi;
- SQL Server trên VM riêng: managed SQL của các cloud không đạt hiệu năng cần. Cần khoảng 1,5 TB RAM để giữ DB trong bộ nhớ, nên chọn m3-ultramem-128 (128 vCPU, 3,9 TB) và tắt một nửa số nhân để giảm phí license;
- Redis: dùng Memorystore (managed). Memorystore giới hạn số database, nên app đổi từ mỗi site một database Redis sang tiền tố key (cách Teams đã làm);
- Elasticsearch: tự chạy bằng Elastic Cloud on Kubernetes; không dùng Elastic Cloud vì không chung được hợp đồng mua qua Azure, và vấn đề Teams gặp sẽ còn lớn hơn ở quy mô public;
- Edge và bảo mật: bỏ log HAProxy và Traffic Processing Service tự viết; đưa mọi thứ ra sau Cloudflare và xử lý log bằng Snowflake, để một nơi lo cả bảo mật, cache ở edge và failover.
Kiến trúc mới: Cloudflare → nginx → Kubernetes, cùng SQL Server, Redis và Elastic. Chuyển dần từng service nhỏ nhất trước, rút kinh nghiệm rồi mới bước tiếp.

Vì sao

Theo bài: với hạ tầng phức tạp, PII/GDPR và app gắn chặt vào data center, "launch mới là 80%" chứ không phải viết code. Ở data center, môi trường test và production khác nhau nên kết quả test không đáng tin và hay gây sự cố; trên cloud, API và IaC cho phép dựng môi trường giống hệt.

Bài học cho SWE

App được tối ưu cho một môi trường cụ thể (độ trễ LAN dưới 1 ms, tên server cố định) mang theo giả định ngầm; load test trên môi trường đích là việc đầu tiên khi chuyển.
Chọn managed service ở chỗ nó đủ tốt (Redis), tự chạy ở chỗ nó không đáp ứng (SQL Server, Elastic). Giới hạn của managed service có thể buộc sửa app (database Redis → tiền tố key).
Chi phí license có thể chi phối cấu hình máy (tắt nhân CPU).
Hạn chót cứng từ bên ngoài, đội chuyên trách và các bước nhỏ là những điều họ rút ra từ lần migration trước.