Bởi Sashi Varanasi, Roberto Luna Rojas, and Steven Hancz

Khách hàng thường phải đối mặt với thách thức tối ưu hóa chi phí cho môi trường cơ sở dữ liệu của mình, đồng thời phải cải thiện hiệu suất ứng dụng và thời gian phản hồi khi cả khối lượng dữ liệu và người dùng của họ đều tăng lên. Các ứng dụng quy mô Internet có khối lượng dữ liệu lớn và thông lượng cao cần các kiến trúc dữ liệu cơ bản có thể hỗ trợ với độ trễ micro giây. Cải thiện hiệu suất ứng dụng cho phép khách hàng của chúng tôi, phục vụ khách hàng bên ngoài và nội bộ tốt hơn thông qua thời gian phản hồi tốt hơn. Kết quả truy vấn được lưu trong bộ nhớ đệm giúp tăng hiệu suất ứng dụng đồng thời cung cấp cho khách hàng khả năng phát triển hoạt động kinh doanh và mở rộng thị trường một cách hiệu quả.

Thêm bộ đệm tập hợp kết quả được phân phối vào cơ sở dữ liệu là cách phổ biến để tăng  hiệu suất ứng dụng và giảm chi phí. Grab, Wiz, DBS Bank nằm trong số nhiều khách hàng sử dụng Amazon ElastiCache for Redis kết hợp với cơ sở dữ liệu chính của họ để hỗ trợ hiệu quả về mặt chi phí cho nhu cầu về hiệu suất ứng dụng theo thời gian thực của họ. Đây là dịch vụ tương thích với Redis được quản lý toàn phần, mang lại hiệu suất theo thời gian thực, tối ưu hóa chi phí cho các ứng dụng hiện đại. ElastiCache có quy mô lên tới hàng trăm triệu thao tác mỗi giây với thời gian phản hồi micro giây, đồng thời cung cấp độ tin cậy và bảo mật cấp doanh nghiệp. Khách hàng sử dụng ElastiCache để tăng tốc hiệu suất ứng dụng và cơ sở dữ liệu hoặc làm kho dữ liệu chính cho các trường hợp sử dụng không yêu cầu độ bền của dữ liệu, chẳng hạn như bảng xếp hạng trò chơi, phát trực tuyến, phân tích dữ liệu và  tính năng lưu trữ để phục vụ suy luận ML. Trong bài đăng này, chúng tôi giải thích cách bạn có thể tối ưu hóa chi phí cơ sở dữ liệu quan hệ bằng bộ nhớ đệm trong bộ nhớ bằng Amazon ElastiCache. Dữ liệu được đưa ra ở đây dựa trên các bài kiểm tra mà chúng tôi đã chạy trên Amazon Relational Database Service (Amazon RDS) cho MySQL phiên bản 8.0.28 trên loại phiên bản db.r6g.xlarge.

Amazon ElastiCache for Redis

Amazon ElastiCache là dịch vụ lưu bộ nhớ đệm được xây dựng bơi Amazon Web Services (AWS). ElastiCache bổ sung cho cơ sở dữ liệu chính, tối ưu hóa hiệu suất tổng thể với chi phí thấp và cho phép mở rộng quy mô nhanh chóng.

ElastiCache là dịch vụ AWS được quản lý hoàn toàn:

• Cực kỳ nhanh – như một bộ nhớ đệm trong bộ nhớ với thời gian phản hồi dưới một phần nghìn giây.
• Có thể mở rộng theo cả chiều dọc và chiều ngang mà không bị gián đoạn để đáp ứng nhu cầu khối lượng công việc.
• Phần cứng và phần mềm được quản lý hoàn toàn, bao gồm các nâng cấp nhỏ về phiên bản công cụ điện toán. Nó có tính sẵn sàng cao với multi-AZ , bao gồm tự động chuyển đổi dự phòng và tự động khôi phục phiên bản trong trường hợp dịch vụ bị gián đoạn. Nó có khả năng tự động thay đổi quy mô cho các khối lượng công việc khác nhau, đồng thời hỗ trợ data tiering và reserved instance types.
• Tương thích với Redis mã nguồn mở.

Tối ưu hóa chi phí của Amazon RDS for MySQL với Amazon ElastiCache

Khi triển khai ElastiCache, một giải pháp bộ nhớ đệm, trên cơ sở dữ liệu quan hệ như Oracle, SQL Server hoặc Amazon RDS cho MySQL, bạn có thể cải thiện hiệu suất ứng dụng của mình và giảm chi phí. Bạn có thể “tiết kiệm tới 55% chi phí và đạt được hiệu suất đọc nhanh hơn tới 80 lần bằng cách sử dụng ElastiCache với RDS for MySQL (so với RDS chỉ dành cho MySQL).”

ElastiCache có thể lưu kết quả của  vào bộ nhớ đệm và giảm IOPS  của cơ sở dữ liệu để giảm chi phí và cải thiện hiệu suất của cả cơ sở dữ liệu và ứng dụng. Việc thêm lớp bộ nhớ đệm lên trên cơ sở dữ liệu chính của bạn sẽ tiết kiệm chi phí hơn so với việc mở rộng dung lượng phiên bản cơ sở dữ liệu. Một  ElastiCache node có thể xử lý hơn 250.000 yêu cầu mỗi giây. Khối lượng công việc đọc nhiều với các truy vấn cơ sở dữ liệu phổ biến trả về cùng một tập kết quả sẽ được hưởng lợi rất nhiều bằng cách lưu các kết quả truy vấn vào bộ nhớ đệm. Không phải tất cả khối lượng công việc cơ sở dữ liệu đều được hưởng lợi từ việc thêm dịch vụ bộ nhớ đệm. Cơ sở dữ liệu nặng về ghi, với hầu hết các giao dịch được chèn hoặc cập nhật, không phải là lựa chọn phù hợp nhất. Các ứng dụng cần xử lý ở cấp cơ sở dữ liệu cũng sẽ không được hưởng lợi từ bộ nhớ đệm. ElastiCache sẽ mang lại lợi ích cho các ứng dụng:

1. Cần phải xử lý khối lượng lớn thông lượng
2. Có nhiều đột biến (lưu lượng truy cập cao điểm tăng trong khoảng thời gian ngắn),
3. Xử lý, hợp nhất khối lượng lớn dữ liệu trong bộ nhớ và theo thời gian thực trước khi cập nhật cơ sở dữ liệu
4. Cần hỗ trợ thời gian phản hồi tức thời của người dùng.

ElastiCache + nguồn dữ liệu chính

Bạn có thể sử dụng ElastiCache với cơ sở dữ liệu quan hệ và các công cụ tự quản lý như MySQL, Oracle, PostgreSQL, SQL Server; Cơ sở dữ liệu NoSQL như Amazon DynamoDB hoặc Amazon DocumentDB (có khả năng tương thích MongoDB); với Amazon Simple Storage Service  (Amazon S3); hoặc không có tầng cơ sở dữ liệu nào, điều này thường xảy ra với các ứng dụng điện toán phân tán.

Sơ đồ 1 – Amazon ElastiCache có thể giúp lưu trữ nhiều nguồn thông tin đáng tin cậy vào bộ nhớ đệm.

Giảm footprint của read replica và tiết kiệm chi phí với ElastiCache

Trong hình minh họa sau đây, chúng tôi đã thay thế RDS for MySQL read replicas và cung cấp khả năng đọc từ cụm ElastiCache. Việc thêm cụm ElastiCache được phân phối đầy đủ sẽ ít tốn kém hơn so với việc thêm bản sao chỉ có quyền đọc, cung cấp hiệu suất đọc tương đương với chi phí thấp hơn và hiệu suất tốt hơn. Bộ nhớ đệm cung cấp bộ nhớ, mạng và CPU chuyên dụng được sử dụng để mang lại độ trễ thấp hơn đáng kể và thông lượng cao hơn nhiều. Chúng tôi cần lưu ý rằng, chúng tôi không sao chép 100% dữ liệu cơ sở dữ liệu của mình trong bộ nhớ đệm. Chỉ kết quả của các truy vấn cần được lưu vào bộ nhớ đệm, loại bỏ nhu cầu sao chép toàn bộ cơ sở dữ liệu.

Sơ đồ 2 – Amazon ElastiCache có thể giảm nhu cầu sử dụng nhiều RDS replicas.

Bộ nhớ đệm – Chiến lược triển khai ứng dụng

Bạn có thể triển khai các chiến lược sau trong ứng dụng của mình để lưu trữ dữ liệu vào bộ nhớ đệm.

Lazy load caching

Lazy load caching, còn được gọi là chiến lược bộ nhớ đệm dành riêng cho bộ nhớ đệm, là hình thức chiến lược bộ nhớ đệm phổ biến nhất được khách hàng sử dụng. Ý tưởng cơ bản là chỉ điền vào bộ đệm khi một đối tượng thực sự được ứng dụng yêu cầu. Luồng ứng dụng tổng thể diễn ra như sau:

1. Ứng dụng của bạn nhận được một truy vấn về dữ liệu, ví dụ như 10 tin bài gần đây nhất.
2. Ứng dụng của bạn sẽ kiểm tra bộ đệm để xem đối tượng có nằm trong bộ đệm hay không. Nếu không (lỗi bộ nhớ đệm), đối tượng được lưu trong bộ nhớ đệm sẽ được trả về và luồng gọi kết thúc.
3. Nếu không (lỗi bộ đệm), thì cơ sở dữ liệu sẽ được truy vấn đối tượng.
4. Bộ đệm được điền và đối tượng được trả về.

Sơ đồ 3 – Lazy Loading or Cache Aside Strategy

Write-through caching

Đối với khối lượng công việc cần tính nhất quán, chiến lược  Write-through có thể được sử dụng để làm mới bộ đệm khi dữ liệu trong kho dữ liệu nguồn bị thay đổi. Write-through yêu cầu cơ chế phát hiện các thay đổi và cập nhật bộ đệm trên các bản cập nhật kho dữ liệu nguồn hoặc cần quy trình ghi kép vào cả bộ đệm và nguồn khi dữ liệu thay đổi. Các ứng dụng khách triển khai tính năng  Write-through sẽ cập nhật cơ sở dữ liệu và khi ghi thành công, sẽ đọc lại dữ liệu từ cơ sở dữ liệu và lưu các kết quả truy vấn mới vào bộ nhớ đệm một cách đồng bộ. Khách hàng thường triển khai Write-through với Time-To-Live (TTL) trong ứng dụng khách của họ để giữ lại dữ liệu của họ.

Sơ đồ 4 – Write-Through Caching Strategy

Các ứng dụng gọi lớp bộ nhớ đệm ElastiCache thông qua Redis client API. Mặc dù chiến lược lazy-load giúp tải dữ liệu vào bộ đệm nhưng mục đích chính của nó là đọc dữ liệu từ bộ đệm khi nó tồn tại, tránh thực hiện các truy vấn đến nguồn dữ liệu chính. Mặc dù chiến lược write-through giúp giữ cho dữ liệu được đồng bộ hóa với cơ sở dữ liệu, nhưng khách hàng thường triển khai cả chiến lược Lazy-load và Write-through để đọc từ bộ đệm khi có dữ liệu và ghi vào bộ đệm để giữ cho dữ liệu được làm mới.

Ví dụ – RDS for MySQL + ElastiCache

80:20 – Read:Write Ratio, chỉ 80% dữ liệu đọc được lưu vào bộ nhớ đệm

Bây giờ chúng ta đã xem xét các lợi ích về hiệu suất,chi phí và chiến lược triển khai ứng dụng cho bộ nhớ đệm, hãy xem lại một ví dụ về tiết kiệm chi phí và cải thiện hiệu suất. Giả sử bạn cần đạt được thông lượng 30.000 truy vấn mỗi giây (queries per second QPS). Để đáp ứng yêu cầu này, một cách tiếp cận là sử dụng RDS for MySQL với các bản sao chỉ có quyền đọc và một cách khác là sử dụng RDS + ElastiCache. Khi chúng ta chỉ sử dụng RDS mà không có ElastiCache, chúng ta cần 4 RDS read replicas để hỗ trợ yêu cầu thông lượng và điều đó sẽ khiến chúng ta phải trả 1740 USD/tháng (đối với db.r6g.xlarge). Khi sử dụng ElastiCache với RDS, bạn có thể loại bỏ các read replicas và thay vào đó sử dụng 1 ElastiCache node và node read replicas của nó để đạt được cùng thông lượng. Việc loại bỏ các RDS read replicas và triển khai ElastiCache có giá 780 USD/tháng. Chi phí của ElastiCache với RDS giúp giảm 55% chi phí khi so sánh với việc chỉ sử dụng RDS với các read replicas của chúng. Bảng sau đây cung cấp cho bạn thông tin chi tiết về các node được sử dụng và chi phí của chúng.

Cấu hình và kích thước cho RDS for MySQL:

RDS data set: kích thước khoảng 80GB với dung lượng lưu trữ  300GB.

Cấu hình RDS node: Phiên bản MySQL 8.0.28 ( db.r6g.xlarge )

Ví dụ câu lệnh được sử dụng:

SELECT firstname, lastname, from_airport FROM booking WHERE passenger_id = <passenger id>

Metrics	RDS primary instance only	RDS with one read replica	RDS with 4 read replicas	ElastiCache with 1 read replica
Avg resp time	200ms	80ms	80ms	1ms
Avg read QPS	8000 QPS	16000 QPS	30000 QPS	32,000 QPS
Pricing $/month	$348 /month	$696 / month	$1740 / month	$780 / month
Nodes used:	1 read/write primary db.r6g.xlarge	1 writer 1 readers = 2x db.r6g.xlarge	1 writer 4 readers = 5x db.r6g.xlarge	1x db.r6g.xlarge + 2x cache.m6g.xlarge

Tiết kiệm cao hơn cho thông lượng cao – 100% dữ liệu được lưu vào bộ nhớ đệm giúp tiết kiệm nhiều hơn

Khi bạn triển khai bộ nhớ đệm, yêu cầu thông lượng cho ứng dụng của bạn càng cao thì mức tiết kiệm chi phí càng cao. Trong ví dụ sau, tất cả dữ liệu được đọc, được cung cấp bởi ElastiCache, công suất đọc tăng lên 250.000 QPS – chỉ với RDS, việc hỗ trợ thông lượng này sẽ tốn thêm 87%. Bằng cách triển khai bộ nhớ đệm cho các ứng dụng đọc nhiều thông lượng cao, bạn có thể tiết kiệm đáng kể chi phí.

Metrics	1 RDS + 9 read replicas	1 ElastiCache + 1 EC read replica (on 1 RDS + 1 read replica)
Avg resp time	80ms	9ms
Avg QPS	250,000	250,000
Pricing	$7,840/ month	$784 (RDS) + $432 (EC)/ month
Nodes used:	10 x db.r6g.xlarge	2 x db.r6g.xlarge + 2 x cache.m6g.xlarge

Kết luận

Chi phí tiết kiệm đạt được bằng cách triển khai ElastiCache với cơ sở dữ liệu quan hệ chính như RDS tỷ lệ thuận với thông lượng đọc mà ứng dụng của bạn cần. Nhu cầu thông lượng đọc càng cao thì mức tiết kiệm chi phí càng cao. Điều này là do khi nhu cầu thông lượng tăng lên, việc mở rộng cơ sở dữ liệu quan hệ sẽ trở nên đắt đỏ hơn. Mặt khác, mỗi ElastiCache node có thể hỗ trợ thông lượng lên tới 400.000 Truy vấn mỗi giây ( Queries Per Second QPS ). Bằng cách thêm ElastiCache vào kiến trúc ứng dụng của mình, bạn có thể đạt được hiệu suất và giảm chi phí.