How we modified our infrastructure to deploy an EU data center

Asana · 2020 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bối cảnh

Khách hàng doanh nghiệp muốn chọn nơi đặt dữ liệu; Asana mở hạ tầng ở châu Âu (12/2019).
Từ 2015 Asana shard theo domain (mỗi domain nằm trọn trong một database, mỗi DB chứa nhiều domain), cộng một master shard lưu user và quan hệ thành viên domain. Mọi DB và service ở một vùng AWS tại Mỹ; service được viết với giả định đọc/ghi được mọi database.

Pageload Service (phục vụ HTML ban đầu) xác định domain của phiên nằm ở vùng nào và ghi vùng đó vào HTML; trình duyệt kết nối thẳng tới LunaDb (server đồ thị dữ liệu, gần giống GraphQL có đẩy cập nhật) ở châu Âu, không proxy qua Mỹ.
Domain DB đặt ở châu Âu, không mở qua ranh giới vùng; chạy bản sao các service cần thiết ở châu Âu để dữ liệu châu Âu không đi qua hạ tầng Mỹ. Ràng buộc cứng này làm khó lưu/xử lý nhầm vùng.
Master shard vẫn ở Mỹ, truy cập từ châu Âu qua kênh mã hoá bằng framework service mesh xuyên vùng mới (AsanaServices). Mỗi lần gọi xuyên vùng thêm khoảng 100 ms nên chép các field hay dùng của master shard sang domain DB, hiếm khi phải gọi master shard.
Ràng buộc mới: mỗi session chỉ truy cập master shard và đúng một domain shard, nên một session chỉ nói chuyện với một vùng. Code cũ vi phạm ràng buộc này được tìm bằng giám sát ẩn (không hiện cho user) báo mỗi lần vi phạm, sửa trước khi ra mắt.

Data residency biến giả định "đọc được mọi DB" thành sai; ràng buộc phạm vi truy cập của session là cách đơn giản nhất để không bao giờ phải đọc xuyên vùng.

Shard theo tenant (domain) từ sớm giúp đặt tenant vào vùng khác về sau khá tự nhiên; phần dữ liệu toàn cục (master shard) mới là chỗ khó.
Ràng buộc kiểm được bằng máy (một session một shard) + giám sát vi phạm trước khi bắt buộc, thay vì rà code bằng tay.
Latency xuyên vùng giải bằng denormalize dữ liệu ít đổi về gần nơi dùng.