From inevitable overprovisioning to the “on-demand” tax: why DynamoDB is bloody hard to cost-control Gần đây với mục tiêu cụ thể là giúp khách hàng tiềm năng của ScyllaDB hiểu được chi phí thực sự của việc chạy DynamoDB. Bây giờ, nếu bạn lùi lại và nhìn vào mục tiêu của tôi, nó không có nhiều ý nghĩa, phải không? Máy tính chi phí DynamoDB Naively, this is what I thought, at first too. But then, I started to peel back the internal workings of DynamoDB cost calculations. At that point, I realized that there are many reasons why teams end up paying hundreds of thousands (if not millions) of dollars to run DynamoDB at scale. Điều chính tôi tìm thấy: DynamoDB rất dễ áp dụng, nhưng rất khó kiểm soát chi phí. Đồng nghiệp của tôi Guilherme và tôi Nhưng nếu bạn không có thời gian để xem, hãy đọc tiếp để khám phá những phát hiện chính. Gửi một webinar theo các dòng này Sự hiểu lầm phổ biến đầu tiên là chính xác những gì DynamoDB tính phí cho bạn. Bạn có thể đã nghe thấy các thuật ngữ như Đơn vị Khả năng Đọc và Đơn vị Khả năng Viết, và có được sự kết hợp của "Bạn trả tiền cho những gì bạn sử dụng" về số lượng đọc và viết. DynamoDB viết rất tốn kém... Nếu bạn nhìn vào , bạn sẽ thấy rằng một đơn vị yêu cầu đọc (RRU) chi phí $ 0,125 mỗi triệu đơn vị, và một đơn vị yêu cầu viết (WRU) chi phí $ 0,625 mỗi triệu đơn vị. Vì vậy, viết là 5 lần đắt hơn so với đọc. Tôi không biết lý do kỹ thuật chính xác, nhưng không có nghi ngờ gì liên quan đến con đường viết là nặng hơn (độ bền, nhất quán, lập chỉ mục, vv) và có lẽ một số headroom. 5x dường như là một chút về phía dốc cho cơ sở dữ liệu và một trong những cái bẫy đầu tiên từ quan điểm chi phí. Giá cho khả năng on-demand Nói về những gì ... có chế độ khác: Như tên cho thấy, điều này có nghĩa là bạn có thể chỉ định bao nhiêu bạn sẽ sử dụng (ngay cả khi bạn không sử dụng nó), và hy vọng sẽ trả ít hơn một chút. Hãy kiểm tra tỷ lệ mặc dù. Một Đơn vị Khả năng Đọc (RCU) chi phí $0.00013 mỗi RCU và một Đơn vị Khả năng Viết (WCU) chi phí $0.00065, vì vậy viết là đáng ngạc nhiên 5 lần đắt hơn so với đọc. Vì vậy, ngay cả trong chế độ dự trữ, bạn vẫn đang trả một hình phạt 5x trên viết. do đó, là đáng kể, đặc biệt là đối với khối lượng lớn viết tải công việc. Không có giảm giá dự trữ trên viết cho bạn! Năng lực dự kiến Bạn không cung cấp yêu cầu, bạn cung cấp tỷ lệ ... Đây là câu đố: các đơn vị dung lượng dự trữ được đo mỗi giây, không phải mỗi triệu yêu cầu, như trong yêu cầu theo yêu cầu. Điều đó khiến tôi bắt đầu.Tại sao không chỉ cung cấp tổng số yêu cầu?Nhưng từ quan điểm của AWS, nó có ý nghĩa kinh doanh hoàn hảo. N hoạt động mỗi giây, cho dù bạn sử dụng khả năng đó hay không. Khả năng xử lý Vì vậy, nếu lưu lượng truy cập của bạn bị bùng nổ, hoặc bạn đang vượt quá dự trữ để tránh yêu cầu throttling (nhiều hơn về điều đó trong một chút), bạn về cơ bản đang trả tiền cho dung lượng không hoạt động. Nói một cách đơn giản, bạn đang mua dung lượng bền vững, ngay cả khi bạn chỉ cần nó thỉnh thoảng. Giống như thành viên phòng tập thể dục của tôi 😉 Khả năng dự trữ... Vì vậy, đây là thỏa thuận: nếu bạn đặt chỗ, bạn đang đặt cược lớn trước để hy vọng tiết kiệm một chút sau đó. Nếu bạn tự tin về việc sử dụng cơ sở của mình, AWS cung cấp cho bạn tùy chọn để dự trữ khả năng DynamoDB, giống như với EC2 hoặc RDS. Đó là một cam kết trả trước 1 hoặc 3 năm, nơi bạn khóa trong một tỷ lệ cố định của đọc và viết mỗi giây. Một gotcha: không có lựa chọn trước một phần; nó là trả đầy đủ hoặc đi xa. Hãy xem một trường hợp sử dụng đơn giản để so sánh các mô hình giá ... Giả sử khối lượng công việc trung bình của bạn là 10.000 đọc / giây và 10.000 viết / giây trong một giờ. Giá On Demand: Viết: $22.50 / giờ ... 10,000 * 3600 * 0.625 / 1M Đọc: $4.50 / giờ ... 10,000 * 3600 * 0.125 / 1M (5x rẻ hơn so với viết, như thường lệ) Giá dự trữ (không dự trữ): Chữ viết: $6.50/giờ ... 10,000 * $0.00065 Đọc: $1.30/giờ ... 10,000 * $0.00013 Cung cấp với 1 năm bảo hành: Chữ viết: ~$2.99/giờ Đọc: ~$0.59/giờ “Này, toán học dự trữ ở đâu?” tôi nghe thấy bạn. Bạn lấy giá dự trữ cho 100 WCUs ($0.0128/giờ) và RCUs ($0.0025/giờ), chia cho 730 giờ trong một tháng, chia cho 12 tháng trong một năm, chia lại cho 100 đơn vị, nhân với tỷ lệ cần thiết của bạn ... sau đó làm tròn nó, khóc một chút, và dán vào meme “math lady”. Điểm của tôi là: Provisioned là ~3.4x rẻ hơn so với on-demand Đặt phòng là ~7.5x rẻ hơn so với on-demand On-demand là dành cho những người thích trả tiền quá mức, hoặc ghét dự đoán Trả thuế, Đối với: AWS đề nghị On-Demand Các mô hình giao thông phát triển theo thời gian Spiky hoặc batchy workloads Sử dụng thấp (giảm xuống 0 hoặc dưới 30% đỉnh) Đó là về cơ bản mọi khối lượng công việc thực tế - ít nhất là đối với khách hàng của ScyllaDB. Vì vậy, có, mong đợi trả tiền thưởng cho tính linh hoạt đó trừ khi lưu lượng truy cập của bạn trông giống như một làn sóng của sách giáo khoa và bạn có một quả bóng tinh thể. Nó không phải là kích thước của mặt hàng, nhưng nó là ... Đây là một cái bẫy mà bạn có thể không đạt được cho đến khi bạn sử dụng dữ liệu ứng dụng thực sự ... tại thời điểm đó bạn sẽ ngay lập tức hối tiếc khi bỏ qua nó. Trong DynamoDB, bạn không chỉ trả tiền cho mỗi hoạt động; bạn trả tiền cho mỗi phần dữ liệu được chuyển. Writes được tính cho mỗi 1KB (Write Request Units hoặc WRU) Đọc được tính phí mỗi 4KB (Đọc yêu cầu đơn vị hoặc RRUs) Vì vậy, nếu bạn viết một mục 1.1KB, đó là 2 WRUs. Viết một mục 3KB? Vẫn 3 WRUs, mỗi 1KB (hoặc một phần của nó) được tính. Đọc hoạt động theo cách tương tự, chỉ ở ranh giới 4KB. Đọc một mục 1KB? 1 RRU. Đọc một mục 4.1KB? Đó là 2 RRUs. Tôi chắc chắn có những lý do kỹ thuật mạnh mẽ cho những giới hạn này. Bạn có thể thấy cái bẫy ở đây. Kết hợp điều này với chi phí viết gấp 5 lần so với đọc, và mọi thứ có thể trở nên tồi tệ một cách nhanh chóng, đặc biệt là nếu kích thước mục của bạn vượt qua những ngưỡng đó mà bạn không nhận ra. Nó có thể ổn nếu bạn có kích thước mục cố định trong sơ đồ của bạn, nhưng chắc chắn không ổn với các loại trường hợp sử dụng mà chúng tôi thấy tại ScyllaDB. Ví dụ, khách hàng có thể đã niêm phong các trường JSON hoặc blob có thể thu hẹp hoặc phát triển với việc sử dụng. Và hãy nhớ, đó là kích thước mục thực tế, không chỉ là kích thước sơ đồ logic. Lạm dụng quá mức, bởi vì bạn phải... Một điểm đau đớn khác, và một sự thiếu sót tồi tệ từ máy tính của riêng AWS, là sự cần thiết phải cung cấp quá nhiều khi sử dụng dung lượng dự trữ. Điều này nghe có vẻ không trực giác, nhưng bạn buộc phải cung cấp quá nhiều - không phải vì bạn muốn, mà bởi vì DynamoDB trừng phạt bạn nếu bạn không. Nếu bạn trượt vượt quá công suất được cung cấp, bạn sẽ nhấn Tôi thích sự rõ ràng của loại thông điệp ngoại lệ này. tôi không thích những gì nó thực sự làm, mặc dù: yêu cầu throttling. Điều này giữ lại khả năng đọc và viết chưa được sử dụng.Nhưng bên ngoài đó, ứng dụng của bạn chỉ đơn giản là thất bại. ProvisionedThông quaExceededException 300s cửa sổ burst khả năng Vì vậy, cách tốt nhất để chống lại điều này là cung cấp quá mức. Bằng bao nhiêu? Điều đó đảm bảo một câu trả lời "nó phụ thuộc". Nhưng nó phụ thuộc vào loại khối lượng công việc của bạn. Chúng tôi đã thêm chức năng này vào máy tính của chúng tôi để bạn có thể năng động cung cấp quá mức bằng một tỷ lệ phần trăm, chỉ để tính vào các chi phí bổ sung cho khối lượng công việc của bạn. Rõ ràng, những chi phí này có thể tăng lên nhanh chóng bởi vì trong thực tế, bạn đang trả tiền cho đỉnh ngay cả khi bạn đang hoạt động trong lò. Nếu bạn không cung cấp đủ công suất cao, đỉnh của bạn có nguy cơ bị hỏng, mang lại cho bạn thất bại đối với khách hàng vào thời điểm tồi tệ nhất có thể. Trước khi di chuyển... Nếu có một chủ đề lặp đi lặp lại ở đây, đó là: giá của DynamoDB không phải là bản chất sai. Bạn trả tiền cho những gì bạn sử dụng. Tuy nhiên, nó là vô cùng không thể tha thứ cho bất kỳ khối lượng công việc nào không trông giống như một làn sóng hoàn hảo, có thể dự đoán được. Cho dù đó là: 5x Writing Cost Multiplier (nhiều lượng viết) Bộ nhân chi phí 7.5x on-demand Opaque Per-second Provisioned Rates (Tỷ lệ dự trữ mỗi giây) Tròn hình phạt và ranh giới nhân tạo của kích thước mặt hàng Hoặc chỉ cần cung cấp quá mức để tránh trồng mặt trong quá trình tải trọng đỉnh Bạn liên tục phải đoán thứ hai về kiến trúc của mình chỉ để ở trước các cuộc bùng nổ chi phí. Sự mỉa mai là DynamoDB được đánh dấu là "không có máy chủ" và "hoàn toàn quản lý" nhưng bạn cuối cùng quản lý toán công suất, lỗi throttling, mức giá arcane, và tập thể dục thông lượng vô tận.Sau khi quan sát nhiều dự báo bảng tính của khách hàng của chúng tôi (và xuất khẩu AWS Cost Explorer) cho DynamoDB, ngay cả các nhóm trưởng thành chạy các hệ thống quy mô lớn cũng không biết chi phí là gì ... cho đến khi quá muộn. Đó là lý do tại sao chúng tôi đã xây dựng một máy tính mô hình khối lượng công việc thực tế, không chỉ trung bình.Bởi vì bước đầu tiên để cố định chi phí là hiểu họ đến từ đâu. Trong , Tôi đi qua một số ví dụ thế giới thực của khách hàng đã chuyển từ DynamoDB sang ScyllaDB để hiển thị tác động thực sự của các mô hình lưu lượng truy cập, kích thước mục, bộ nhớ đệm và topologies đa khu vực. tại . Next Post Blog của tôi Nhảy về phía trước và mô hình tải công việc của riêng bạn máy tính.scylladb.com Mô hình tải công việc DynamoDB của riêng bạn trên máy tính chi phí mới của chúng tôi Về Tim Koopmans Tim đã có bàn tay của mình trong tất cả các hình thức kỹ thuật trong vài thập kỷ qua với một xu hướng về độ tin cậy và bảo mật. Trong năm 2013, ông thành lập Flood IO; một nền tảng kiểm tra hiệu suất phân tán. Sau khi nó được mua lại, ông thích mở rộng sản phẩm, kinh doanh và nhóm trước khi chuyển sang các nỗ lực liên quan đến hiệu suất khác.
