Nếu bạn đang đọc điều này, bạn có thể đã nghe về Amazon Aurora. Như bạn biết, Amazon Aurora là dịch vụ PaaS do AWS cung cấp như một phần của bộ dịch vụ RDS. Nó cung cấp hệ thống quản lý cơ sở dữ liệu quan hệ (RDBMS) được quản lý hoàn toàn, có hai phiên bản, MySQL và Postgres, trong khi duy trì wire compatibility với cả hai. Nhưng điều này ảnh hưởng thế nào đến chiến lược và tùy chọn high availability của bạn?
Bạn có thể thắc mắc Amazon Aurora khác như thế nào so với MySQL hoặc PostgreSQL trên Amazon RDS. Đây cũng là dịch vụ RDBMS được quản lý hoàn toàn, đúng không? Có, nhưng về cơ bản chúng là các triển khai open-source tiêu chuẩn chạy trên đội xe EC2 và được quản lý bởi AWS. Sự khác biệt chính với Aurora là AWS tách storage engine ra khỏi database engine. AWS áp dụng Nguyên tắc Separation of Concerns (Tách biệt mối quan tâm) cho database open-source.
Tách biệt mối quan tâm (Separation of concerns)
Bình thường, một RDBMS phải chạy trên phần cứng phổ biến. Điều này nghĩa là triển khai phải hoạt động trong giới hạn do OS và phần cứng áp đặt để hoàn thành tất cả tính năng chúng ta mong đợi từ database hiện đại, như: xử lý DML và DDL, transaction tuân thủ ACID, replication, high-availability (HA), và fault tolerance. Nếu, tuy nhiên, triển khai không yêu cầu chạy trên phần cứng phổ biến mà chỉ trong môi trường được thiết kế đặc biệt cho database, các trách nhiệm khác nhau có thể tách thành các lớp, cho phép database engine và storage engine được tập trung và chuyên biệt. Kết quả, high-availability và hiệu suất có thể tăng đáng kể – lên đến 5x hiệu suất hơn MySQL chuẩn và lên đến 3x hơn PostgreSQL chuẩn.
Được, nó nhanh hơn, nhưng database engine và storage engine chuyên biệt giúp chúng ta như thế nào với HA? Có một vài cách điều này giúp đạt được HA. Trước khi đi vào chi tiết, hãy nhìn nhanh cách Aurora storage engine hoạt động để hiểu HA xuất phát từ sự tách biệt này như thế nào.
Khi dữ liệu được ghi vào Aurora storage engine, engine đảm bảo dữ liệu được ghi nhất quán, đúng, và bền vững. Dữ liệu được ghi ở hai vị trí trong mỗi của ba availability zones, tổng cộng sáu nơi khác nhau. Storage engine xử lý độ phức tạp đảm bảo tất cả xảy ra đúng. Mặc dù có thể hơi đơn giản hóa, về cơ bản database engine giờ có thể "fire-and-forget" (bắn và quên), không còn lo lắng về việc dữ liệu có được ghi, transaction logs, khả năng cần recover, v.v.
Loại bỏ mối quan tâm storage khỏi database engine, một số chiến lược HA trở nên khả thi.
Read Replicas (Replica đọc)
Mặc dù khái niệm Read Replicas xuất hiện từ lâu trước Aurora, triển khai trong giải pháp open-source liên quan đến log shipping hoặc query replay. Với Aurora, Read Replicas có quyền truy cập chỉ đọc vào chính xác cùng storage với master. Điều này nghĩa là độ trễ replication rất nhỏ từ lúc dữ liệu được ghi đến lúc nó hiển thị cho Read Replica (replication lag là thuật ngữ sai trong kịch bản này). Khi cần nhiều Read Replicas, tất cả Read Replicas thấy cùng dữ liệu, loại bỏ overhead và độ phức tạp đặt lên master, tìm thấy trong triển khai MySQL và PostgreSQL tiêu chuẩn. Các tính năng này cùng nhau cho phép Read Replica ngay lập tức接管 nếu master thất bại. Ngoài ra, AWS xử lý thay thế instance thất bại, để đáp ứng capacity đã provision, bằng instance mới và cập nhật DNS để trỏ đến master mới.
Đây là giải pháp tuyệt vời cho ứng dụng có tỷ lệ đọc/ghi cao. Tuy nhiên, hãy nhớ primary instance phải đủ lớn để xử lý toàn bộ tải ghi. Ngoài ra, cho write HA, bạn muốn provision ít nhất một Read Replica cùng kích thước với master. Sau đó, đặt Read Replica này làm instance ưu tiên để promote thành primary instance. Trong trường hợp thất bại, bạn sẽ duy trì high availability cho cả capacity đọc và ghi.
Autoscaling (Tự động mở rộng)
Autoscaling là khả năng mở rộng ngang (scale out - thêm instance) hoặc thu hẹp (scale in - bớt instance) từ tập server có sẵn. Bạn có thể đã nghe về Autoscaling cho EC2 instances, nhưng bạn có biết bạn cũng có thể có elasticity (độ co giãn) trong Aurora Read Replicas? Thông thường, bạn cấu hình số lượng Read Replicas tối thiểu để xử lý base load và có autoscaling policies để thêm hoặc bớt instance khi nhu cầu thay đổi. Khả năng tận dụng elasticity là một derivative khác của việc storage engine tách biệt khỏi database engine.
Ví dụ kịch bản nơi điều này hữu ích là trang thương mại điện tử B2B. Nó sẽ chịu lưu lượng lớn trong giờ làm việc ngày tuần nhưng rất ít vào ban đêm và cuối tuần. Hình ảnh và mô tả nội dung có tỷ lệ đọc/ghi cao và hưởng lợi từ cả Read Replicas và Autoscaling. Autoscaling Read Replicas cho phép bạn đáp ứng nhu cầu giờ cao điểm trong khi tối thiểu hóa chi phí giờ thấp điểm.
Cross-Region replication (Sao chép跨 khu vực)
Nếu bạn cần đưa availability lên mức tiếp theo, hãy replicate sang region khác. Bằng cách cho database engine replicate dữ liệu sang region khác, nó có thể đọc cục bộ hoặc dùng trong trường hợp region primary thất bại. Instance trong region thứ hai được xem như Read Replica (đây không phải multi-master), nhưng nó cũng có thể có Read Replicas riêng hoặc trở thành master nếu region primary thất bại.
Có nhiều lý do cần cross-region replication. Đôi khi dữ liệu quan trọng quá mức để lưu trữ trong một vùng địa lý đơn lẻ. Điều này có thể do business continuity, quy định, hoặc lý do tài chính. Lý do khác là giảm độ trễ giữa user và database backend. Dùng thương mại điện tử làm ví dụ một lần nữa, thay đổi hình ảnh và mô tả có thể áp dụng cho master trong một region nhưng được phân phối toàn cầu để đọc cục bộ.
External replication (Sao chép bên ngoài)
Những tình huống cần dữ liệu bên ngoài Aurora cluster thì sao? Có tình huống chính sách công ty hoặc môi trường quy định yêu cầu, hoặc bạn cần xử lý dữ liệu hoặc chạy báo cáo bên ngoài Aurora. Tất cả các trường hợp này có thể xử lý bằng External Replication.
Dễ dàng cho Aurora replicate dữ liệu đến instance Amazon EC2 MySQL, instance Amazon EC2 chạy MySQL, thậm chí instance MySQL chạy trong data center công ty của bạn. Dùng one-way replication này, dữ liệu của bạn luôn in-sync với Aurora cluster và có sẵn để dùng bên ngoài Aurora.
Serverless (Không máy chủ)
Cuối cùng nhưng chắc chắn không kém quan trọng, là serverless. Có lẽ một trong những phát triển quan trọng nhất cho availability và scalability là thêm serverless vào phương trình. Rõ ràng serverless không nghĩa là không có server. Nó nghĩa là bạn không phải lo lắng về provisioning, cấu hình, scaling, hoặc bảo trì bất kỳ server nào.
Để cấu hình Aurora Serverless, bạn chỉ định capacity có sẵn cho ứng dụng và AWS xử lý chi tiết đảm bảo capacity đó có sẵn theo yêu cầu, khi client cần nó. Cho serverless, một lớp bổ sung, proxy layer, đã được thêm vào hai lớp hiện có, database engine và storage engine.
AWS duy trì đội proxy server lắng nghe request đến. Ngoài ra, warm pool của DB capacity đang chờ phục vụ request. Khi query đầu tiên đến, proxy fleet nhận nó, yêu cầu instance từ warm pool, và chuyển request đến instance đó, sau khi nó được cấp phát cho bạn. Tốt hơn nữa, số instance cấp phát cho bạn là elastic và scale in/out dựa trên demand và giới hạn bạn chỉ định trong cấu hình Aurora Serverless. Giống các chiến lược trước, khả năng cấp phát động database engine cho bạn được làm nhờ sự tách biệt database và storage. Dựa trên cấu hình của bạn, instance database ở lại assigned cho bạn và sẵn sàng dùng ngay lập tức. Sau khi hết timeout period, instance được trả về warm pool. Bạn chỉ bị tính phí cho resource bạn đang dùng. Khi instance được cấp phát cho bạn, bạn bị tính phí cho nó cộng với storage tiêu thụ. Khi không cấp phát, bạn chỉ bị tính phí cho storage tiêu thụ.
Cho workload có spikes (đột biến), như môi trường development và test, hoặc ứng dụng mới đơn giản không có đủ lịch sử để dự đoán usage patterns, serverless là lựa chọn. Bạn không còn trả tiền cho resource không dùng, không phải lo team dev có tắt đèn trước khi đi cuối tuần, và bạn không bị đánh thức giữa đêm để điều chỉnh capacity vì múi giờ user trùng với múi giờ ngủ của bạn.
Tóm lại (Wrapping up)
Amazon Aurora được xây dựng với availability, durability, và scalability trong tâm trí. Nếu dùng như triển khai open-source tiêu chuẩn, bạn có database solid, reliable, và performant. Với cái nhìn sâu hơn vào khả năng Aurora và các pattern để tận dụng chúng, bạn có thể triển khai giải pháp đáp ứng nhu cầu, từ offload đọc cục bộ đến availability phân phối toàn cầu.
Sử dụng tab Feedback để bình luận hoặc đặt câu hỏi.