03 Cách giải quyết khi Amazon DynamoDB Table bị nghẽn Throttled

Như các bạn đã biết DynamoDB là một dịch vụ NoSQL rất xịn của AWS, tốc độ truy xuất tính đến hàng milisecond, nếu có áp dụng DAX nữa có thể lên tới microsecond, giúp tăng hiệu năng lên tới hàng triệu request per second.

Tuy nhiên nếu giả sử các bạn có bao giờ tò mò giới hạn cao nhất của DynamoDB là bao nhiêu hay không? Và khi gặp các giới hạn nhất định thì chúng ta có thể có những giải pháp nào để xử lý?

Trước khi đi sâu vào bài Kevin chia sẻ hai thuật ngữ Soft Limit và Hard Limit khi nói về những giới hạn dịch vụ.

Soft Limit chỉ định những giới hạn có thể mở rộng. Giả sử mặc định DynamoDB có giới hạn 20 Global Secondary Indexes và đây là Soft limit. Với những giới hạn là Soft Limit bạn có thể Raise Request để xin mở rộng, tất nhiên bạn cũng phải có lý do thỏa đáng.

Với những giới hạn ghi là Hard Limit thì bạn không thể thay đổi để có capacity hơn giới hạn này.

Về DynamoDB, bạn đã biết DynamoDB tổ chức dữ liệu trong các table theo các partition. Mặc dù không có giới hạn nào về table size nhưng với mỗi item (attribute name & attribute values) không quá 400KB và giới hạn về đọc ghi trên mỗi partition.

Cụ thể, mỗi paritition có giới hạn hard limit là 1,000 WCU và 3,000 RCU. Có nghĩa khi sử dụng partition bạn có provision cỡ nào cũng ko quá được giới hạn này nhé.

Xem thử Amazon DynamoDB 1000 WCU và 3000 RCU lớn cỡ nào?

Mỗi WCU có item size tối đa 1KB => 1,000 WCU tối đa 1,000KB (~1MB)

Với Eventual Consistency 1 RCU = 2 read requests, mỗi request tối đa 4KB. Như vậy sẽ có 3,000*2*4 = 24,000KB (~24MB). Với Transaction giới hạn là 4MB.

Trong phần lớn các trường hợp ta sẽ ko dùng đến các limits khủng thế này. Nhưng giả sử ta provision một table với lượng W và R là 10. trong một table có nhiều partition và trong đó có một partition có tần suất truy cập cao hơn bình thường. AWS gọi đó là hot partition. Để luân chuyển và điều phối WCU và RCU trong DynamoDB có một tính năng gọi đó là DynamoDB Adaptive Capacity. Nhưng lưu ý là có luân chuyển thế nào thì cũng ko quá được hard limit.

Một trong những cách có thể đối phó throttled hiệu quả nhất đó là DynamoDB hỗ trợ tính năng DynamoDB Adaptive Capacity.

Tuy nhiên như các bạn đã biết mỗi một partition có giới hạn hard limit. Để tránh bị throttled, ta cần monitor và tối ưu cấu trúc table cũng như partition.

Giải pháp tránh throttled của Amazon DynamoDB

Trước khi implementing bất cứ giải pháp nào bạn có thể sử dụng Amazon CloudWatch Contributor Insights để xem các item nào bị truy xuát nhiều nhất mà dẫn đến throttled. Sau đó mới dùng giải pháp phù hợp giải quyết.

Do the right things at the first time

Giải pháp quan trọng nhất là bạn thiết kế DynamoDB đúng với loại dữ liệu phù hợp với nó. Nhiều khi ko phải cứ thấy DynamoDB là nhét loại dữ liệu nào cũng chạy được. Mỗi một loại dịch vụ phù hợp với một tác vụ nào đó mà thôi, nếu không thì AWS ko sinh ra hơn 15+ loại cơ sở dữ liệu đâu. Việc thiết kế bị lệch sẽ dễ tạo hot partition. Các bạn làm software architect và solution architect cần phối hợp để có thiết kế thông minh chỗ này hen.

Ref: Designing Partition Keys to Distribute Your Workload Evenly.

Caching, caching and caching

Sử dụng cache làm tăng tốc độ đọc của partition, nếu bạn có dữ liệu static nhiều và truy xuất đọc nhiều thì ko nên bỏ qua caching với DAX có thể giúp dynamodb giảm từ milisecond thành microsecond, hỗ trợ hàng triệu read request per second. Thật là kinh khủng khiếp phải ko?

Ngoài ra bạn cũng có thể sử dụng Amazon ElastiCache.

Cuối cùng nếu bạn là một lập trình viên chân chính bạn cũng có thể sử dụng Exponential Backoff.

Hy vọng bạn có những thiết kế đúng chuẩn mực khi dùng DynamoDB. DynamoDB sẽ rất tốt nếu biết cách sử dụng, ko thì sẽ rất đắt mà lại kém nha. Đừng vì mình dùng ko đúng lại chê DynamoDB chậm nha ^^ Nó nhanh đến quái vật luôn ấy. Ví dụ Pokemon GO là một tựa game mình rất thích cũng chạy hạ tầng trên AWS sử dụng DynamoDB có tần suất truy cập 300 người mỗi giây. @@

Ref: https://aws.amazon.com/solutions/case-studies/the-pokemon-company-case-study/

%d bloggers like this: