DNS fallback for better resilience

Algolia · 2015 · 2. Tăng trưởng · Độ khó: Cơ bản — bài gốc

Bối cảnh

Algolia (search-as-a-service) đặt mục tiêu kiến trúc 99,9999%: mọi thành phần phải hỏng được mà không ảnh hưởng dịch vụ.
Điểm đầu tiên request của khách chạm vào không phải router trong data center mà là DNS, phân giải từ trước đó, và thường bị bỏ qua.
Họ dùng NSONE vì hiệu năng và DNS theo dữ liệu (lái traffic của mạng search phân tán tới server gần nhất hoặc đang sống). Nhưng ngoài tầm kiểm soát của nhà cung cấp còn BGP và "tối ưu" của ISP; thời gian phân giải từ 10 lên 500 ms là không chấp nhận được với Algolia.
Họ nhớ tới các vụ DDoS vào UltraDNS (2009, 2014) làm cả Amazon và Salesforce bị ảnh hưởng.

Cách thường thấy là thêm name server của nhà cung cấp thứ hai và nhân bản record. Algolia không làm vậy: phải bỏ các tính năng riêng của NSONE để lấy tập chung, và một phần phân giải sẽ đi qua nhà cung cấp chậm hơn mà không có lý do.
Họ đặt logic vào API client do chính họ viết: client dùng nhiều tên miền. algolia.net (NSONE, nhanh và thông minh) là đường chính; algolianet.com (Route53) dùng khi gọi qua algolia.net thất bại.
Thêm một ý "đa nghi": không dựa vào một TLD duy nhất (.net và .com).

Tốn thêm công và tiền cho họ, nhưng khách, khách của khách và chính họ "ngủ ngon hơn".

Khi đếm điểm hỏng, tính cả những gì xảy ra trước request vào hạ tầng của mình: DNS, TLD (Độ tin cậy và multi-region).
Nếu kiểm soát được client (SDK), fallback ở client tránh được việc hạ chuẩn nhà cung cấp chính xuống mẫu số chung.
Dự phòng là đường thứ hai chỉ dùng khi đường chính hỏng, không phải chia đều tải.