From inevitable overprovisioning to the “on-demand” tax: why DynamoDB is bloody hard to cost-control 最近は 潜在的なScyllaDBの顧客がDynamoDBを実行する本当のコストを理解するのを助けるという具体的な目標で、今、あなたが後退して私の目標を見ると、それはあまり意味がありませんよね?誰かがDynamoDBを使用している場合、彼らはすでに規模で技術を実行するのにどれだけのコストがかかるかを知りませんか? DynamoDBコスト計算機 しかし、その後、私はDynamoDBのコスト計算の内部機能を覆い始めました。その時点で、チームが規模でDynamoDBを実行するために何十万ドル(もしくは何百万ドル)を支払う理由がたくさんあることに気がつきました。 私が発見した主なことは、DynamoDBは採用しやすいが、コストコントロールは難しい。 My Workmate Guilherme and I(私の労働者Guilhermeと私は) しかし、あなたが観る時間がない場合は、重要な発見を発見するために続きを読む。 これらのラインでウェビナーを行いました。 最初の一般的な誤解は、DynamoDBがあなたに何を請求しているかです。あなたはすでに読書容量単位と書き込み容量単位のような用語を聞いたことがあり、読書と書き込みの数に関して「あなたが使用するものに支払う」という言葉を得ています。 DynamoDBの書き込みは高価です。 If you look at 読書要求単位(RRU)は100万単位あたり0.125ドルで、書き込み要求単位(WRU)は100万単位あたり0.625ドルで、書き込みは読書よりも5倍高く、正確な技術的な理由は分からないが、書き込みパスがより重い(耐久性、一貫性、インデックスなど)と何らかのヘッドルームと関係があることは間違いない。 On-Demand Capacityの価格設定 言い換えれば、もう一つのモードは、 . 名前が示唆するように、これはあなたがどれだけ使用するかを指定できることを意味します(あなたがそれを使用しない場合でも)、そして少し少ない金額を支払うことを希望します。しかし、比率をチェックしましょう。 読み込み能力ユニット(RCU)はRCUあたり0,00013ドル、書き込み能力ユニット(WCU)は0,00065ドルで、書き込みは読み込みよりも驚くほど高価です。 したがって、提供モードでさえも、あなたは書き込みに対して5倍の罰金を支払っています。 予想容量 あなたはリクエストを提供するのではなく、料金を提供しています... ここでは、予想された容量単位が毎秒で測定され、リクエスト100万件ではなく、リクエスト1百万件で測定されます。最初に私を惹きつけました。なぜ単にリクエストの総数を提供しないのですか?しかし、AWSの視点から言えば、ビジネスには完璧な意味があります。 1秒あたりの N オペレーション、その容量を使用するか否か。 対処する能力 したがって、あなたのトラフィックが爆発している場合、またはあなたはリクエストのトロトリングを避けるためにプロビジョニングを超えている場合(もう少しでそれについて)、あなたは本質的に無駄な容量のために支払っています。 保有能力... したがって、ここに合意があります:あなたが容量を予約する場合、あなたは少し後で節約することを希望するために大きな前進を賭けています。 ベースラインの使用に自信がある場合は、EC2 または RDS と同様に、DynamoDB の容量を予約するオプションを AWS に提供します. It is a prepaid 1 or 3 year commitment, where you lock in a fixed rate of read and writes per second. And yes, it is still a rate, not a total number of requests. 1つのゴッチャ:部分的な前払いオプションはありません;それは完全に支払うか、歩くかです。 価格モデルを比較するための簡単な用例を見てみましょう... あなたのワークロードの平均は1時間あたり1万読み/秒、1時間あたり1万書き/秒です。 On Demand 価格: 書き込み: $22.50/hr ... 10,000 * 3600 * 0.625 / 1M 読み方: $4.50/hr ... 10,000 * 3600 * 0.125 / 1M (通常より5倍安い) 予想価格(未予約): 書き込み: $6.50/hr ... 10,000 * $0.00065 読み方: $1.30/hr ... 10,000 * $0.00013 1年保証付き: 書き込み: ~$2.99/hr 読み方: ~$0.59/hr 「こんにちは、保留数学はどこにありますか?」私はあなたを聞きます。 あなたは100 WCUs($0.0128/hr)とRCUs($0.0025/hr)の予約価格をとり、月の730時間で分け、年に12ヶ月で分け、再び100ユニットで分け、必要な割合で倍増します...それから丸め、少し泣き、そして「数学の女」メームに入れてください。 私のポイントは、 Provisioned は ~3.4x on-demand より安いです。 予約は ~7.5x on-demandより安いです。 On-demandは、過払いを好む人々のためにあるいは予測を嫌う。 税金、 のために: AWS は On-Demand を推奨 時間とともに進化するトラフィックパターン Spiky または Batchy Workloads 低利用率(ピークの0%以下または30%以下) ScyllaDBの顧客にとっては少なくともすべてのリアルライフのワークロードであるため、その柔軟性のためのプレミアムを支払うことを期待してください。 アイテムのサイズではありませんが、それは... これは、実際のアプリケーションデータを使用するまで、あなたが触れないかもしれない1つです...その時点であなたはすぐにそれを無視して後悔するでしょう。 DynamoDB では、操作ごとに支払うだけでなく、転送されたデータの単位ごとに支払います。 Writes は 1KB (Write Request Units or WRUs) で請求されます。 リクエスト単位(RRUs: Read Request Units) したがって、1.1KBの項目を書く場合、それは2 WRU です。3KBの項目を書く? それでも3 WRU は、1KB (またはその一部) が数えられます。 Reads は 4KB の境界線で同じように動作します。 1KB の項目を読みますか? 1 RRU を読みますか? 4.1KB の項目を読みますか? それは 2 RRU です。 これらの限界には強力な技術的な理由があると私は確信しています。ここで落とし穴を見ることができます。読むよりも5倍の書き込みコストとこれを組み合わせることで、物事が素早く悪くなることがあります、特にあなたのアイテムのサイズがそれらの限界を踏み越える場合に、あなたが気づいていません。あなたがあなたのスケジュールに固定アイテムのサイズを持っている場合、それはおそらくOKですが、確かにScyllaDBで私たちが見ている使用ケースの種類とOKではありません。 過剰摂取、なぜなら、あなたは... もう一つの痛みと、AWS の独自の計算機からの誤解は、予備容量を使用する際に過剰供給の必要性です。それは直感的に聞こえるが、あなたが過剰供給を余儀なくされている - あなたが望むからではなく、DynamoDBがあなたを罰するためです。 提供された容量を超えてスライドすると、あなたは I love the clarity of this type of exceptional message. I don't like what it actually does, though: request throttling. (私はこのタイプの例外メッセージの明確さが好きです。 未使用の読み書き容量を保持しますが、それ以上に、あなたのアプリは失敗します。 300s window of burst capacity ウィンドウ したがって、これを対処する最善の方法は、過剰供給です。どれくらいですか? それは「それに依存する」という答えを保証します。しかし、それはあなたのワークロードの種類に依存します。 私たちはこの機能を私たちの計算機に追加しましたので、あなたはダイナミックにパーセントで過剰供給することができます、あなたのワークロードに追加のコストを考慮するだけです。明らかに、これらのコストは迅速に増加することができ、実践では、あなたがトリックで動作する場合でも、ピークのために支払っています。 引っ越す前に... もしここに繰り返し話題があるなら、これは次の通りです:DynamoDBの価格設定は本質的に間違っているわけではありません。あなたは使用するものに支払います。 それが何であろうと: 5x Writing Cost Multiplier(5x書くコストの倍数) 7.5x on-demand cost multiplier Opaque Per-Second Provisioned Rates (Opaque Per-Second Provisioned Rates) Punitive rounding and artificial boundaries of item sizes(物件サイズの人工の枠組み) Or just the need to overprovision to avoid face-planting during peak load. ピーク負荷中に顔植えを避けるために過剰供給する必要性 ...あなたは常にコストの爆発に先立つために、あなたのアーキテクチャを2番目に推測する必要があります。 皮肉なことに、DynamoDBは「サーバーレス」と「完全に管理されている」とブランド化されていますが、容量数学、ゲットリングエラー、アーカニーな価格レベル、そして無限のパスプートギネスティックを管理するようになります。DynamoDBの顧客の多くのスプレッドシート予測(およびAWSコストエクスプレーヤー輸出)を観察した後、大規模なシステムを実行する成熟したチームでさえ、コストがどのようになるか分からないのです。 したがって、実際のワークロードをモデル化する計算機を作成したのは、単なる平均値ではなく、コストを固定するための最初のステップは、コストがどこから来ているかを理解することだからです。 イン , 私は、DynamoDB から ScyllaDB に切り替えた顧客のいくつかの現実世界の例を歩いて、トラフィックパターン、アイテムサイズ、キャッシュ、および複数の地域トポロジーの真の影響を示します。 AT . 次のブログ記事 Skip forward and model your own workloads(自分のワークロードをモデル化) トップページ > Scylladb.com 新しいコスト計算機で独自のDynamoDBワークロードをモデル化 Tim Koopmansについて ティムは、信頼性とセキュリティのための傾向を持って、過去数十年間、あらゆる形のエンジニアリングに携わってきました。2013年に彼は、分散型パフォーマンステストプラットフォームであるFlood IOを設立しました。
