Chọn đúng Amazon Aurora Endpoint: Hướng dẫn thực tế

Tôi biết bạn đang nghĩ… Tôi sẽ chỉ kết nối đến Cluster Endpoint cho ghi, Reader Endpoint cho tất cả đọc, và tại sao tôi bao giờ kết nối đến instance cụ thể – đó là bỏ qua fault tolerance tích hợp sẵn và đang tự tìm rắc rối, đúng? Như đã gợi ý trước đó, ứng dụng của bạn và sự tương tác của nó với Aurora tạo ra một hệ thống phức tạp (hoặc ít nhất là phi tầm thường). Với hệ thống phức tạp, one-size-fits-all không phải quy tắc để dựa vào… trừ khi bạn thích cuộc gọi giữa đêm.

Hãy đi qua một số kịch bản và xem khi nào và nơi dùng các endpoint khác nhau.

Tính nhất quán tức thì (Immediate consistency)

Một số ứng dụng mong đợi dữ liệu nhất quán ngay lập tức. Khi ứng dụng này ghi dữ liệu, chúng ngay lập tức đọc dữ liệu tuân thủ nghiêm ngặt với nhiều design pattern nói, "dựa vào model, không phải local data của bạn". Amazon Aurora tuân thủ ACID; đọc từ Cluster Endpoint ngay sau ghi commit thành công sẽ truy xuất dữ liệu mong đợi (giả sử transaction khác không sửa đổi dữ liệu trước lần đọc tiếp theo).

Vấn đề xảy ra khi ghi được gửi đến Cluster Endpoint và đọc được thực hiện đến Reader Endpoint. Điều này do độ trễ giữa ghi dữ liệu và khi nó hiển thị cho reader. Mặc dù độ trễ replication dưới 100 milliseconds, nó không phải tức thì, dẫn đến race condition. Nếu bạn có kịch bản cần đọc ngay dữ liệu sau khi ghi, hãy dùng Cluster Endpoint cho cả đọc và ghi. Cần lưu ý, nếu cần hiệu suất thêm, bạn phải tăng kích thước primary instance.

Tuy nhiên, nếu eventual consistency (nhất quán cuối cùng) chấp nhận được và ứng dụng của bạn hỗ trợ nó, dùng Reader Endpoint là cách tuyệt vời để giảm tải trên primary instance.

Chuyển tải đọc (Offloading reads)

Nếu đọc ngay sau ghi không ổn, thì ý nghĩa của việc có Reader Endpoint riêng biệt là gì? Có nhiều use-case nơi dữ liệu hơi không nhất quán không phải vấn đề. Ví dụ: báo cáo hàng ngày. Khi chạy batch job tạo báo cáo từ dữ liệu hôm qua, độ trễ replication 100-millisecond là không đáng kể. Dễ tưởng tượng các kịch bản khác, như mô tả sản phẩm trên trang thương mại điện tử… bạn có nhiều khả năng có dữ liệu cũ trong trình duyệt người dùng hơn bị ảnh hưởng bởi độ trễ replication.

Nói chung, workload đọc nhiều không dựa vào immediate consistency nên cân nhắc dùng Reader Endpoint.

Workload không đồng đều (Non-uniform workloads)

Có tình huống dùng Instance Endpoints có ý nghĩa. Giả sử bạn có ứng dụng với một số stateless microservices sau Elastic Load Balancer. Trong tình huống này, hợp lý giả định truy vấn được phân bố đều qua các client, và do đó, qua Read Replicas – khi dùng Reader Endpoint.

Nhưng workload của mỗi client không đồng đều thì sao? Nếu thêm reporting service vào, một Read Replica có tải cao bất cân xứng so với các cái khác. Nếu microservices trước đó cũng dùng Read Replica này, có xác suất cao hiệu suất truy vấn kém khi truy vấn instance được dùng bởi reporting service. Một cách để tránh là quản lý phân phối kết nối phía client, thay vì để Amazon Aurora làm việc đó. May mắn thay, việc này dễ dàng bằng cách dùng Instance Endpoints thay vì Reader Endpoint. Với MariaDB Connector/J for Aurora for MySQL hoặc Fast Failover with Amazon Aurora PostgreSQL, driver có thể nhận biết các instance riêng lẻ bạn muốn dùng làm Read Replicas, cho phép driver trực tiếp quản lý cách truy vấn được phân phối đến các instance riêng lẻ.

Quản lý DNS caching (Manage DNS caching)

Ngoài việc hiểu bản chất workload, quan trọng là hiểu cách kết nối được phân bổ để cung cấp High Availability của Aurora và Reader Endpoint load balancing.

Quản lý tự động Cluster Endpoint failover và Reader Endpoint load balancing được xử lý qua DNS (Amazon Route 53), không ở lớp IP, TCP, hoặc database client protocol. Việc xử lý phân phối kết nối qua DNS nghĩa là ứng dụng của bạn phải thực hiện truy vấn DNS cho mỗi yêu cầu kết nối mới. Ứng dụng dùng DNS caching nên điều chỉnh cache timeout khớp với DNS record TTL cho Amazon Aurora. Cache DNS response lâu hơn Aurora DNS record TTL sẽ dẫn đến một vài điều kiện lỗi. Nếu có sự kiện High-Availability (HA) failover, tức là Read Replica được promote thành Primary, cached DNS response nghĩa là ứng dụng sẽ cố kết nối lại instance cũ, failed. Trong trường hợp Reader Endpoint, cache DNS response dẫn đến nhiều kết nối đi đến một Read Replica cụ thể thay vì được phân phối qua các Read Replicas có sẵn.

Tóm lại (Wrapping up)

Như chúng ta thấy, không có giải pháp one-size-fits-all khi nói đến workload production phi tầm thường. Nếu ứng dụng cần immediate consistency, hãy đảm bảo cả đọc và ghi gửi đến Cluster Endpoint. Khi truy vấn đọc có thể chịu được chút replication lag, chuyển tải truy vấn đọc đến Reader Endpoint. Nếu bạn có thể dùng Read Replicas nhưng truy vấn không phân bố đồng đều qua tất cả client, thì dùng Instance Endpoints và quản lý phân phối kết nối phía client. Chỉ đừng quên, nếu ứng dụng dùng DNS caching với cache timeout lâu hơn DNS record TTL, endpoint có vẻ không hoạt động như kỳ vọng trong Cluster Endpoint HA failover hoặc khi dùng Reader Endpoint.

Hiểu bản chất ứng dụng, cách Aurora Endpoints hoạt động, và áp dụng đúng kiến thức đó sẽ dẫn đến môi trường ứng dụng mạnh mẽ hơn, điều rất quan trọng đối với bạn và khách hàng. Không ai muốn cuộc gọi sự cố giữa đêm.

Sử dụng tab Feedback để bình luận hoặc đặt câu hỏi.