Tác giả: Jonathan Woods và Pengfei Shao, 

Ngày đăng: 07 tháng 05 năm 2025

Danh Mục: AWS WAF, Best Practices, Security, Identity, & Compliance

Amazon DynamoDB là một cơ sở dữ liệu key-value và document được quản lý toàn phần, được thiết kế để cung cấp hiệu suất nhất quán ở mức mili-giây đơn lẻ ở bất kỳ quy mô nào. Khi bắt đầu sử dụng DynamoDB, một trong những quyết định đầu tiên mà bạn cần đưa ra là chọn giữa hai throughput modes: on-demand (theo yêu cầu) và provisioned (cấp phát trước). Chế độ on-demand là lựa chọn mặc định và được khuyến nghị vì nó đơn giản hóa việc xây dựng các ứng dụng hiện đại theo mô hình serverless, có thể bắt đầu từ quy mô nhỏ và mở rộng tới hàng triệu yêu cầu mỗi giây. Tuy nhiên, việc chọn chiến lược thông lượng phù hợp đòi hỏi phải đánh giá các nhu cầu vận hành, tốc độ phát triển và đặc điểm của ứng dụng, trong đó chi phí là một yếu tố quan trọng.

Trong bài viết này, chúng ta sẽ xem xét chi tiết cả hai chế độ thông lượng, khám phá các đặc điểm, ưu điểm và các trường hợp sử dụng lý tưởng của chúng. Bất kể bạn chọn chế độ dung lượng nào hoặc table class nào, DynamoDB vẫn cung cấp độ trễ vài mili-giây một cách nhất quán ở mọi quy mô, và các bảng của bạn đều được hưởng lợi từ các tính năng cấp doanh nghiệp như built-in fault tolerance, backup and restore, encryption at rest, và global tables.

Chế độ dung lượng 

DynamoDB cung cấp hai chế độ dung lượng để xử lý yêu cầu đọc và ghi của ứng dụng của bạn. Thông lượng của mỗi bảng DynamoDB có thể được cấu hình độc lập, bạn có thể có một số bảng ở chế độ dung lượng on-demand (theo yêu cầu) và một số khác ở chế độ dung lượng được cấp phát trước. Bảng sau đây cho thấy một so sánh cấp cao giữa chúng dựa trên các tính năng khác nhau. Các phần bên dưới sẽ mở rộng từng mục một cách chi tiết.

Tóm tắt những điểm khác biệt chính

Tính năng	Theo yêu cầu (On-demand)	Được cấp phát (Provisioned)
Yêu cầu lập kế hoạch dung lượng	Tùy chọn	Bắt buộc
Chi phí	Dựa trên số lượng yêu cầu	Dựa trên dung lượng đọc và ghi được cấp phát mỗi giờ, không phụ thuộc vào mức sử dụng
Giới hạn mở rộng	Dựa trên hạn ngạch bảng và tài khoản, và thông lượng tối đa. (Giá trị mặc định là 40.000 RCU và WCU nhưng bạn có thể request a quota increase).	Dựa trên dung lượng được cấp phát, giới hạn bảng và tài khoản và thông lượng tối đa.
Tối ưu hóa chi phí	Tốt hơn cho khối lượng công việc thay đổi và khó dự đoán.	Tốt hơn cho khối lượng công việc ổn định và có thể dự đoán.
Mức độ phức tạp trong quản lý	Rất thấp (được quản lý hoàn toàn).	Cần nỗ lực để xác định cấu hình cấp phát phù hợp và cần điều chỉnh thường xuyên khi khối lượng công việc thay đổi
Nguyên nhân có thể gây giới hạn	Vì nó tự động mở rộng nên ít có khả năng gặp lỗi giới hạn hơn.	Phụ thuộc vào dung lượng được cấp phát và cấu hình tự động mở rộng. Cần ít nhất 2 phút liên tiếp vượt ngưỡng sử dụng trước khi tự động mở rộng thêm dung lượng, nên dễ gặp lỗi giới hạn hơn.
Nguyên nhân tiềm ẩn gây throttling (nghẽn)	Tự động mở rộng mà không cần quản lý dung lượng.Mô hình định giá on-demand (theo yêu cầu).Lưu lượng thay đổi hoặc không thể dự đoán.Ứng dụng mới hoặc khối lượng công việc chưa biết trước.Cần vận hành không máy chủ (serverless).Ưu tiên chi phí vận hành tối thiểu.	Mẫu lưu lượng ổn định, có thể dự đoán.Có thể dự báo dung lượng một cách đáng tin cậy.Mức sử dụng ổn định trên 50%.Chu kỳ lưu lượng hàng ngày hoặc hàng giờ đều đặn.Có đợt tăng lưu lượng nhỏ và có thể dự đoán.

Dung lượng theo yêu cầu (On-demand capacity)

On-demand capacity mode cung cấp cho bạn trải nghiệm cơ sở dữ liệu serverless được quản lý hoàn toàn, tự động mở rộng theo lưu lượng truy cập ứng dụng. Nó loại bỏ nhu cầu dự đoán mức sử dụng dung lượng và cấp phát tài nguyên trước cho hoạt động hàng ngày. DynamoDB tự động tạo ra một khoảng dung lượng dự phòng (headroom) (lên tới gấp đôi mức lưu lượng đỉnh trước đó) cho các workload có sự tăng trưởng tự nhiên, hỗ trợ lên đến hàng triệu yêu cầu mỗi giây. Bạn chỉ phải trả tiền cho các thao tác đọc và ghi thực tế mà ứng dụng thực hiện, với hóa đơn thanh toán có thể dự đoán được, tương ứng trực tiếp với mức sử dụng của bạn — và bạn không cần lo về việc lập kế hoạch dung lượng.

On-demand còn cung cấp các khả năng bổ sung như  maximum throughput, một thiết lập tùy chọn ở cấp bảng giúp kiểm soát chi phí tốt hơn và cho phép bạn chỉ định thông lượng đọc hoặc ghi (hoặc cả hai) tối đa. Ngoài ra, warm throughput cung cấp thông tin chi tiết về các thao tác đọc và ghi mà bảng của bạn có thể xử lý ngay lập tức mà không bị giới hạn. Mặc dù giá trị warm throughput tăng tự động khi mức sử dụng tăng, bạn cũng có thể chủ động thiết lập giá trị cao hơn thông qua quy trình pre-warming.

Với bảng on-demand, warm throughput đại diện cho công suất tối thiểu mà bảng của bạn sẵn sàng xử lý ngay lập tức. Quá trình pre-warming không cấp phát dung lượng trước, mà thay vào đó sẽ chuẩn bị sẵn cấu trúc phân vùng (partition) nội bộ của bảng để có thể xử lý được mức tải dự kiến. Đây là một thao tác không đồng bộ và không chặn, giúp đảm bảo bảng của bạn có thể xử lý sự tăng đột biến của lưu lượng mà không bị giới hạn.

Các bảng on-demand mới bắt đầu với giá trị warm throughput khởi điểm là 4.000 yêu cầu ghi và 12.000 yêu cầu đọc mỗi giây. Nếu không pre-warming, việc vượt qua các giá trị này có thể dẫn đến giới hạn tạm thời khi DynamoDB mở rộng dần để đáp ứng nhu cầu tăng cao.

Dung lượng được cấp phát (Provisioned capacity)

Trong provisioned capacity mode, bạn phải chỉ định số lượng thao tác đọc và ghi mỗi giây cần thiết cho lưu lượng của ứng dụng. Bạn sẽ bị tính phí dựa trên dung lượng đọc và ghi được cấp phát theo giờ không dựa trên mức sử dụng thực tế. Do đó, ngay cả khi hoạt động thấp hoặc không có hoạt động, bạn vẫn bị tính phí cho toàn bộ dung lượng được cấp phát. Chế độ dung lượng được cấp phát là lý tưởng cho khối lượng công việc có lưu lượng ổn định, có thể dự đoán và theo chu kỳ trong ngày hoặc giờ.

Với chế độ dung lượng được cấp phát, bạn có thể:

• Schedule scaling activities cho các mẫu sử dụng đã biết
• Điều chỉnh dung lượng theo cách thủ công khi cần
• Sử dụng auto-scaling để điều chỉnh dung lượng tự động

Tuy nhiên, chi phí thực tế có thể thay đổi trong chế độ provisioned do các hoạt động của auto-scaling. Khi auto-scaling phản ứng với thay đổi lưu lượng, dung lượng được cấp phát của bạn (và do đó chi phí) có thể vẫn ở mức cao ngay cả sau khi nhu cầu giảm xuống. Ngược lại, chế độ on-demand cung cấp mô hình tính phí dự đoán hơn vì chi phí phản ánh chính xác khối lượng yêu cầu thực tế, không bị ảnh hưởng bởi hành vi mở rộng.

Với auto-scaling của DynamoDB, bạn có thể cấu hình ngưỡng sử dụng từ 20% đến 90% của dung lượng được cấp phát. Dịch vụ sẽ giám sát mức tiêu thụ của bảng qua các chỉ số Amazon CloudWatch theo từng phút. Khi mức dung lượng tiêu thụ vượt quá ngưỡng mục tiêu trong 2 phút liên tiếp, auto-scaling sẽ bắt đầu hoạt động mở rộng. Có thể có một độ trễ ngắn lên đến vài phút trước khi auto-scaling thực sự được kích hoạt.

Đối với hoạt động thu hẹp dung lượng (scale-down), DynamoDB sử dụng các ngưỡng thận trọng hơn (conservative) để bảo vệ hiệu năng của ứng dụng. Việc sử dụng phải duy trì dưới 20% của ngưỡng hiện tại và kéo dài trong 15 phút. Các cảnh báo CloudWatch có thể mất thêm vài phút để kích hoạt việc thu hẹp thực sự.

Ngay cả khi đã bật auto-scaling, bạn nên thường xuyên giám sát các thiết lập dung lượng, cấu hình tự động mở rộng và yêu cầu ứng dụng để đảm bảo rằng các thiết lập của bạn luôn tối ưu về hiệu suất và chi phí.

Quản lý throttling và thay đổi lưu lượng

Cách bảng của bạn phản ứng với sự gia tăng đột ngột của lưu lượng là yếu tố then chốt khi lựa chọn giữa các chế độ dung lượng. Chế độ on-demand có thể xử lý ngay lập tức các yêu cầu mà không cần tăng hoặc giảm tài nguyên, khiến nó trở thành lựa chọn lý tưởng cho traffic changes. Chế độ provisioned, với auto-scaling, phù hợp hơn cho lưu lượng tăng dần theo từng phút.

Mặc dù cả hai chế độ đều giúp quản lý thông lượng, chúng không ngăn chặn hoàn toàn việc throttling. Có hai loại throttling quan trọng có thể xảy ra bất kể chế độ nào:

• Throttling cấp bảng xảy ra khi ứng dụng của bạn cố gắng sử dụng nhiều dung lượng hơn dung lượng được cấp phát. Đối với bảng provisioned, điều này xảy ra khi bạn vượt quá dung lượng được cấp phát và dung lượng burst. Để xử lý, bạn có thể tăng dung lượng provisioned, hạ thấp ngưỡng auto-scaling hoặc điều chỉnh lưu lượng của ứng dụng để tăng dần, đảm bảo có đủ dung lượng burst khi cần. Đối với  on-demand tables, throttling cấp bảng ít phổ biến hơn, nhưng bạn có thể sử dụng warm throughput để chuẩn bị cho các chiến dịch marketing đặc biệt có thể tạo ra lưu lượng tăng mạnh. Trong cả hai trường hợp, điều quan trọng là phải xác minh giới hạn bảng và tài khoản.
• Throttling phân vùng nóng (hot-partition) xảy ra khi nhiều yêu cầu nhắm vào các mục có cùng khóa phân vùng, làm dồn lưu lượng vào một số ít phân vùng. Mặc dù DynamoDB có thể mở rộng gần như không giới hạn ở cấp bảng, mỗi phân vùng riêng lẻ vẫn có giới hạn thông lượng. Các giới hạn này thích nghi theo thông lượng tổng thể của bảng, chứ không phải là giá trị cố định.
  Khi một phân vùng nhận quá nhiều lưu lượng so với các phân vùng khác, yêu cầu có thể bị giới hạn dù bảng còn dung lượng chưa dùng. Đây được gọi là vấn đề phân vùng nóng (hot partition). Để xử lý, thường phải thay đổi cách mô hình hóa dữ liệu để distribute lưu lượng đều hơn qua nhiều phân vùng.

Dung lượng burst và hành vi auto-scaling (chỉ dành cho chế độ Provisioned)

Đối với bảng ở chế độ provisioned, DynamoDB cung cấp dung lượng burst để xử lý các đợt tăng lưu lượng ngắn. burst capacity này được lấy từ thông lượng chưa sử dụng và giúp ngăn chặn throttling khi có sự gia tăng đột ngột ngắn hạn về lưu lượng. Tuy nhiên, nếu lưu lượng cao kéo dài, bạn có thể bị giới hạn sau khi dung lượng burst cạn kiệt và trước khi auto-scaling thêm dung lượng mới.

Hiểu về ngưỡng sử dụng

Đối với các bảng ở chế độ dung lượng được cấp phát (provisioned mode), các ngưỡng auto-scaling quyết định mức dung lượng dự phòng mà bảng của bạn duy trì. Ngưỡng cao hơn (chẳng hạn 80%) tối ưu hóa chi phí nhưng cung cấp ít vùng đệm hơn cho các đợt tăng lưu lượng, trong khi ngưỡng thấp hơn (chẳng hạn 60%) tốn kém hơn nhưng bảo vệ tốt hơn trước các đợt tăng đột ngột. Khi đặt ngưỡng, hãy cân nhắc mức độ tăng lưu lượng của ứng dụng bạn, khả năng chịu đựng throttling và sự cân bằng giữa yêu cầu về chi phí và hiệu suất.

Biểu đồ sau đây cho thấy các ngưỡng khác nhau ảnh hưởng đến việc cấp phát dung lượng như thế nào. Đường màu xanh lá thể hiện mức tiêu thụ thực tế WCU. Đường màu cam cho thấy dung lượng được cấp phát provisioned capacity tại ngưỡng sử dụng 80%, hãy chú ý cách nó bám sát mức tiêu thụ, mang lại hiệu quả chi phí nhưng rủi ro throttling cao hơn. Ở ngưỡng sử dụng 70%, đường dung lượng được cấp phát cung cấp nhiều vùng đệm hơn cho các đợt tăng lưu lượng đột ngột. Phương pháp thận trọng nhất thể hiện ngưỡng 60%, cung cấp sự bảo vệ bổ sung chống lại các đợt tăng lưu lượng với chi phí là dung lượng không được sử dụng.

Với chế độ on-demand, bạn chỉ phải trả cho thông lượng bạn sử dụng, loại bỏ nhu cầu theo dõi mức sử dụng.

Mô hình tải công việc và thay đổi lưu lượng

Hiểu rõ đặc điểm tải công việc của bạn là điều quan trọng để lựa chọn giữa các chế độ dung lượng. Hai yếu tố chính cần xem xét là khả năng dự đoán của tải công việc và cách nó xử lý sự thay đổi lưu lượng.

Khả năng dự đoán tải công việc ảnh hưởng đến việc chế độ nào sẽ phục vụ bạn tốt hơn. Chế độ dung lượng được cấp phát hoạt động tốt nhất cho các tải công việc có sự thay đổi thông lượng dần dần, mượt mà. Ví dụ bao gồm các ứng dụng doanh nghiệp với các giai đoạn giờ làm việc hàng ngày, các quy trình theo lô đã biết có thể mở rộng và thu hẹp theo lịch trình, hoặc các hệ thống có sự tăng trưởng ổn định theo thời gian. Ngay cả khi tổng lưu lượng thay đổi theo từng ngày, chế độ provisioned vẫn hiệu quả miễn là những thay đổi này tuân theo các quy luật có thể dự đoán trước, cho phép bạn có đủ thời gian để điều chỉnh dần dung lượng cho phù hợp.

Đối với hầu hết các ứng dụng hiện đại, đặc biệt là những ứng dụng có mẫu lưu lượng thay đổi, chế độ on-demand tỏ ra hiệu quả hơn. Ecommerce, media and entertainment, trò chơi và các ứng dụng Internet of Things (IoT) đều hưởng lợi từ khả năng xử lý yêu cầu khối lượng công việc năng động mà không cần lập kế hoạch dung lượng. Điều này trở nên đặc biệt quan trọng khi lưu lượng thay đổi theo từng giây hoặc từng phút.

Để minh họa sự khác biệt này, hãy xem xét một kịch bản nơi ứng dụng của bạn sẽ trải qua sự tăng lưu lượng đột ngột do một chiến dịch tiếp thị. Đây sẽ là mức lưu lượng cao nhất mà bảng của bạn từng trải qua và bạn không chắc khi nào nó sẽ xảy ra. Hãy xem mỗi chế độ xử lý tình huống này như thế nào.

Cả hai chế độ đều có thể hưởng lợi từ warm throughput để chuẩn bị tài nguyên trước cho khối lượng mới. Tuy nhiên, yêu cầu vận hành giữa các chế độ khác nhau đáng kể:

Với chế độ on-demand, khi bảng của bạn đã được pre-warmed, nó có thể hỗ trợ tức thì mức warm throughput đó mà không cần sự can thiệp của người dùng, và bạn chỉ phải trả cho số yêu cầu đọc và ghi thực tế đã thực hiện.

Với chế độ provisioned, ngay cả khi có warm throughput, bạn vẫn cần cập nhật cài đặt auto-scaling hiện tại, đặt giá trị tối đa mới phù hợp với tải dự kiến, giảm mục tiêu sử dụng (có thể từ 30-40%) để duy trì vùng đệm đáng kể, vì bảng dựa vào burst capacity trong thời gian mở rộng, giám sát hiệu quả auto-scaling, và chấp nhận rủi ro throttling nếu burst capacity cạn kiệt trước khi auto-scaling hoàn tất.

Sự không chắc chắn về thời điểm lưu lượng tăng tạo ra sự đánh đổi đầy thách thức với chế độ provisioned: đặt mục tiêu sử dụng thấp đồng nghĩa với việc phải trả cho dung lượng không được sử dụng cho đến khi sự kiện xảy ra, trong khi đặt cao hơn để kiểm soát chi phí lại làm tăng rủi ro throttling khi lưu lượng tăng đột ngột.

Sự khác biệt cơ bản trong cách xử lý thay đổi lưu lượng khiến chế độ on-demand trở nên đặc biệt có giá trị đối với các ứng dụng nơi hiệu suất ổn định là yếu tố then chốt.

Chi phí và giá trị vận hành

Cân nhắc về chi phí nên tính đến cả chi phí tuyệt đối và chi phí vận hành khi lựa chọn giữa chế độ on-demand và provisioned. Mặc dù chế độ on-demand có mức giá cố định cho mỗi yêu cầu, hiệu quả chi phí tổng thể của nó phụ thuộc vào mẫu sử dụng của bạn. Đối với tải công việc có sự biến động lớn về lưu lượng, như biểu đồ tiếp theo chỉ ra, chế độ on-demand có thể tiết kiệm chi phí hơn vì nó tự động mở rộng mà không cần cấp phát dư thừa.

Chi phí theo giờ hiệu quả của chế độ provisioned thay đổi dựa trên ngưỡng sử dụng được cấu hình. Ở mức sử dụng thấp, bạn có thể sẽ phải trả nhiều hơn cho mỗi yêu cầu so với chế độ on-demand. Ví dụ, nếu bạn cần duy trì dung lượng cao để xử lý các đợt tăng định kỳ, bạn sẽ phải trả cho dung lượng đó ngay cả trong các giai đoạn lưu lượng thấp, vốn có thể chiếm phần lớn thời gian vận hành. Việc cấp phát dư thừa này có thể làm tăng đáng kể chi phí của bạn.

Ngoài ra, chế độ provisioned yêu cầu quản lý nhiều chi phí gián tiếp: trả tiền cho dung lượng được cấp phát dù có sử dụng hay không, thời gian giám sát mức sử dụng, chi phí điều chỉnh dung lượng để phù hợp với nhu cầu, và rủi ro cấp phát dư để xử lý đợt tăng lưu lượng. Chế độ on-demand loại bỏ phần lớn chi phí quản lý này vì không có dung lượng cần theo dõi hoặc điều chỉnh.

Tuy nhiên, đối với tải công việc dự đoán được, sử dụng cao như biểu đồ sau minh họa, chế độ provisioned có thể tiết kiệm chi phí hơn nếu được quản lý hiệu quả. Chìa khóa là phân tích kỹ các mẫu sử dụng và nhu cầu vận hành của bạn khi đưa ra lựa chọn giữa hai chế độ. Bạn có thể sử dụng reserved provisioned cho các tải công việc có mẫu rất dự đoán được và nhu cầu mở rộng rõ ràng, nơi bạn có thể tiết kiệm đến 77% so với giá dung lượng provisioned thông thường.

Mô hình tính phí theo mức sử dụng của on-demand có thể mang lại lợi ích chi phí rõ ràng trong nhiều kịch bản phổ biến:

• Ứng dụng có các đợt tăng lưu lượng không thường xuyên, vốn yêu cầu cấp phát dư nếu dùng chế độ provisioned
• Tải công việc có các giai đoạn dài không hoạt động xen kẽ với giai đoạn bận rộn
• Hệ thống có mẫu sử dụng không thể dự đoán

Ngoài chi phí trực tiếp, giá trị cốt lõi của chế độ on-demand nằm ở sự đơn giản trong vận hành và sự linh hoạt cho doanh nghiệp (business agility):

• Quản lý tài nguyên:
  • Đầu tư vào việc theo dõi liên tục và lập kế hoạch dung lượng
  • Tốn thời gian kỹ thuật để tinh chỉnh cài đặt auto-scaling
• Giảm rủi ro:
  • Giảm thiểu tác động đến doanh nghiệp do throttling trong đợt tăng lưu lượng
  • Cấp phát dư như một chiến lược giảm thiểu rủi ro

Sự đơn giản này đặc biệt phù hợp với các ứng dụng hiện đại nơi tốc độ phát triển và hiệu suất ổn định ảnh hưởng trực tiếp đến thành công của doanh nghiệp.

Chỉ nên xem xét chế độ provisioned khi bạn có tải công việc dự đoán được với ít biến động và có thể duy trì mức sử dụng cao của dung lượng được cấp phát một cách nhất quán. Nếu không, sự đơn giản trong vận hành và việc loại bỏ nhu cầu quản lý dung lượng khi sử dụng chế độ on-demand thường mang lại giá trị tổng thể tốt hơn.

Chi phí giám sát

Việc quản lý dung lượng được cấp phát yêu cầu sự chú ý liên tục từ nhóm kỹ sư của bạn. Bạn cần theo dõi các chỉ số từ CloudWatch thường xuyên để hiểu các mẫu sử dụng (Consumed WCU so với provisioned WCU  để hiểu mức sử dụng ghi, và consumed RCU so với provisioned RCU để hiểu mức sử dụng đọc), xác định các vấn đề tiềm tàng về throttling (read  write), và tinh chỉnh cấu hình auto-scaling dựa trên nhu cầu của ứng dụng. Việc giám sát các chỉ số đã tiêu thụ so với cấp phát giúp bạn hiểu cách bảng đang được sử dụng. Việc bảo trì liên tục này không chỉ đơn thuần là theo dõi dashboard nó đòi hỏi bạn phải hiểu các mẫu sử dụng phức tạp và đưa ra các quyết định sáng suốt về việc điều chỉnh dung lượng.

Chế độ dung lượng on-demand (theo yêu cầu) loại bỏ phần lớn chi phí vận hành này, cho phép bạn chỉ cần theo dõi mức tiêu thụ qua các chỉ số consumed WCU and consumed RCU . Tuy nhiên, cả hai chế độ dung lượng đều yêu cầu một số bước chuẩn bị cho các sự kiện lớn như mùa khuyến mãi hoặc chiến dịch tiếp thị. Đối với các sự kiện lưu lượng cao này, hãy cấu hình thông lượng “warm throughput” để đảm bảo rằng bảng của bạn có thể xử lý khối lượng yêu cầu dự kiến. Tuy nhiên, quy trình chuẩn bị khác nhau đáng kể giữa hai chế độ.

Việc chuẩn bị cho các sự kiện có lưu lượng cao khi sử dụng chế độ provisioned bao gồm một kế hoạch toàn diện: ước tính và điều chỉnh dung lượng cơ sở, cấu hình các tham số auto-scaling, duy trì đủ dung lượng đệm, và lên kế hoạch cho cả giai đoạn tăng và giảm dung lượng. Bạn sẽ cần theo dõi và điều chỉnh các thiết lập này trước, trong và sau sự kiện để đảm bảo hiệu suất tối ưu.

Với chế độ on-demand, việc chuẩn bị tập trung vào việc đặt các mức warm throughput và giới hạn thông lượng tối đa phù hợp. Phương pháp tinh gọn này cho phép nhóm của bạn tập trung vào thành công của sự kiện thay vì phải lo lắng về quản lý dung lượng, trong khi vẫn kiểm soát được chi phí và tác động hệ thống.

Tinh chỉnh auto-scaling

Nếu bạn đang sử dụng chế độ dung lượng được cấp phát, bạn phải hiểu cách hoạt động thực tế của quá trình auto-scaling. Trong khi các bảng on-demand thích ứng tức thì với thay đổi lưu lượng, các bảng provisioned có các quy tắc mở rộng cụ thể. Để tăng dung lượng, DynamoDB yêu cầu có hai phút liên tiếp mà mức sử dụng vượt quá mục tiêu hiện tại trước khi bắt đầu quá trình scale up. Trong khoảng thời gian này, bảng của bạn cần có đủ dung lượng đệm (bao gồm cả burst capacity) để xử lý lưu lượng tăng lên.

Việc giảm dung lượng tuân theo một mô hình thận trọng hơn. DynamoDB chờ 15 phút sau khi lưu lượng giảm để đảm bảo đó không phải là một sự sụt giảm tạm thời. Sau khi xác nhận mẫu lưu lượng giảm, bảng của bạn có thể giảm dung lượng tối đa four times in the first hour, and once per hour thereafter. Những ràng buộc về thời gian này giúp ngăn chặn việc mở rộng/quy mô quá mức, đồng thời duy trì hiệu suất ổn định.

Việc đặt ngưỡng sử dụng thích hợp đòi hỏi bạn phải cân bằng giữa việc có đủ dung lượng đệm để tăng lưu lượng và tối ưu hóa việc sử dụng dung lượng trong điều kiện hoạt động bình thường. Cách tiếp cận auto-scaling này hoạt động tốt đối với các ứng dụng có tải công việc ổn định, dự đoán được, nơi mẫu lưu lượng được hiểu rõ. Đối với các ứng dụng có tải công việc thay đổi, bạn có thể cần duy trì dung lượng đệm cao hơn hoặc chấp nhận đôi khi bị throttling trong các đợt tăng lưu lượng đột ngột.

Kết luận

Cả hai chế độ dung lượng của DynamoDB đều cung cấp các đặc điểm hiệu năng như nhau và các tính năng sẵn sàng cho doanh nghiệp. Tuy nhiên, chế độ on-demand được khuyến nghị cho hầu hết các ứng dụng hiện đại do khả năng xử lý các mẫu lưu lượng bất ngờ, loại bỏ gánh nặng lập kế hoạch dung lượng, và giảm độ phức tạp trong vận hành.

Hãy cân nhắc chế độ on-demand nếu bạn:

• Cần phản hồi tức thì với các thay đổi về lưu lượng
• Muốn giảm thiểu gánh nặng vận hành
• Có tải công việc thay đổi hoặc không thể dự đoán
• Ưu tiên sự linh hoạt trong phát triển và đơn giản hóa vận hành

Chế độ provisioned vẫn là một lựa chọn khả thi cho các trường hợp sử dụng cụ thể nếu bạn:

• Có tải công việc ổn định, dự đoán được với mức sử dụng ổn định trên 50%
• Có thể tận dụng việc mua trước dung lượng (reserved capacity), mở rộng theo lịch trình và tinh chỉnh auto-scaling
• Có đủ khả năng vận hành để theo dõi và tối ưu hóa dung lượng thường xuyên

Để giúp bạn hình dung quá trình ra quyết định, dưới đây là sơ đồ cây giúp bạn xác định khi nào nên chọn chế độ on-demand và khi nào nên chọn chế độ provisioned:

Mặc dù chế độ on-demand cung cấp sự đơn giản trong vận hành cho hầu hết các ứng dụng hiện đại, chế độ provisioned vẫn có thể mang lại tiết kiệm chi phí đáng kể nếu bạn có khả năng chấp nhận các chi phí vận hành bổ sung. Tuy nhiên, hãy đánh giá cẩn thận xem liệu các khoản tiết kiệm tiềm năng này có xứng đáng với độ phức tạp trong việc quản lý dung lượng hay không.

Hãy nhớ rằng bạn luôn có thể bắt đầu với chế độ on-demand để hiểu rõ mẫu sử dụng của mình và chuyển sang chế độ provisioned sau nếu đặc điểm tải công việc của bạn phù hợp với change.

Để tìm hiểu thêm, hãy xem:

• Learn about DynamoDB throughput capacity
• Review DynamoDB best practices
• Explore DynamoDB pricing

Trong bài viết tiếp theo, chúng tôi sẽ khám phá các trường hợp sử dụng và tình huống cụ thể để giúp bạn đưa ra quyết định phù hợp về chế độ dung lượng cho nhu cầu cụ thể của mình.

Giới thiệu về tác giả

Esteban Serna, Kiến trúc sư giải pháp chuyên gia chính của DynamoDB, là một người đam mê cơ sở dữ liệu với 15 năm kinh nghiệm. Từ việc triển khai cơ sở hạ tầng trung tâm liên lạc đến yêu thích NoSQL, hành trình của Esteban đã đưa anh chuyên về điện toán phân tán. Ngày nay, anh giúp khách hàng thiết kế các ứng dụng quy mô lớn với độ trễ mili giây bằng DynamoDB. Đam mê công việc của mình, Esteban không thích gì hơn là chia sẻ kiến thức của mình với người khác.