From inevitable overprovisioning to the “on-demand” tax: why DynamoDB is bloody hard to cost-control В последнее время с конкретной целью помочь потенциальным клиентам ScyllaDB понять реальную стоимость запуска DynamoDB. Теперь, если вы сделаете шаг назад и посмотрите на мою цель, это не имеет большого смысла, верно? Калькулятор затрат DynamoDB Наивно, это то, что я тоже думал, вначале. но потом я начал отжимать внутреннюю работу расчетов затрат DynamoDB. В этот момент я понял, что есть много причин, почему команды в конечном итоге платят сотни тысяч (если не миллионы) долларов, чтобы запустить DynamoDB в масштабе. Главное, что я нашел: DynamoDB легко принять, но кроваво трудно контролировать затраты. Мой коллега Гильерме и я , но если у вас нет времени, чтобы посмотреть, читайте дальше, чтобы узнать ключевые выводы. Веб-семинар по этим линиям Вы, вероятно, уже слышали такие термины, как единицы способности чтения и единицы способности письма, и получаете лозунг «Вы платите за то, что вы используете» с точки зрения количества прочитанных и написанных. DynamoDB пишут дорого... Если вы посмотрите на , вы увидите, что единица запроса на чтение (RRU) стоит $ 0,125 за миллион единиц, а единица запроса на написание (WRU) стоит $ 0,625 за миллион единиц. Так, письма в 5 раз дороже, чем письма. Я не знаю точной технической причины, но это несомненно что-то связано с тем, что путь письма тяжелее (продолжительность, последовательность, индексация и т. Д.) и, возможно, немного головной комнаты. 5x кажется немного на крутой стороне для баз данных и одной из первых ловушек с точки зрения затрат. Цены на мощности по запросу Говоря о том, что... вот другой режим: Как говорит название, это означает, что вы можете указать, сколько вы собираетесь использовать (даже если вы не используете его), и, надеюсь, заплатите немного меньше. Давайте проверим соотношение, однако. Единица способности чтения (RCU) стоит $0.00013 за RCU и единица способности письма (WCU) стоит $0.00065, поэтому письма неожиданно в 5 раз дороже, чем письма. Так что даже в предусмотренном режиме вы все еще платите штраф в 5 раз за письма. Предполагаемая мощность Вы не предоставляете запросы, вы предоставляете тарифы... Вот улов: предусмотренные единицы мощности измеряются в секунду, а не на миллион запросов, как в случае по запросу. Это меня вначале поразило. Почему бы не просто предоставить общее количество запросов? N операций в секунду, независимо от того, используете вы эту мощность или нет. Способность справляться Так что, если ваш трафик взорван, или вы перепрофилируете, чтобы избежать запроса (более подробно об этом немного), вы по существу платите за свободную мощность. Проще говоря, вы покупаете поддерживаемую мощность, даже если вам она нужна только время от времени. Резервная мощность... Итак, вот сделка: если вы зарезервируете емкость, вы делаете большие ставки заранее, чтобы, надеюсь, сэкономить немного позже. Если вы уверены в использовании базовой линии, AWS предоставляет вам возможность резервировать емкость DynamoDB, как и в случае с EC2 или RDS. Это предварительно оплаченное обязательство сроком на 1 или 3 года, где вы заблокируете фиксированную скорость чтения и записи в секунду. Одна гоча: нет частичного варианта аванса; это оплата в полном объеме или уход. Давайте рассмотрим простой случай использования для сравнения ценовых моделей... Предположим, что ваша рабочая нагрузка составляет в среднем 10 000 ч/сек и 10 000 ч/сек в течение часа. Цены по запросу: Написано: $22.50/ч ... 10000 * 3600 * 0.625 / 1М Читает: $4.50/ч ... 10000 * 3600 * 0.125 / 1М (5x дешевле, чем пишут, как обычно) Предварительная цена (не зарезервированная ) : Написано: $6.50/ч ... 10000 * $0.00065 Читает: $1.30/ч ... 10000 * $0.00013 С 1 годом резервации: Написано: ~ $ 2.99 / час Читает: ~$0,59 / ч «Эй, где резервная математика?» я слышу вас. Вы принимаете зарезервированную цену на 100 WCUs ($0.0128/ч) и RCUs ($0.0025/ч), делитесь на 730 часов в месяц, делитесь на 12 месяцев в году, делитесь еще раз на 100 единиц, умножьте на необходимую скорость... затем округлите ее, немного плачьте и вставьте в мему «математическая леди». Моя точка заключается в том, Провизионный ~3.4x дешевле, чем по запросу Забронировано ~7.5x дешевле, чем по запросу On-demand для людей, которые любят переплачивать или ненавидят предсказывать НДС , Для : AWS рекомендует On-Demand Трафические модели, которые эволюционируют с течением времени Spiky или batchy рабочие нагрузки Низкая эффективность использования (падение до нуля или ниже 30% от пика) Это практически каждая рабочая нагрузка в реальной жизни — по крайней мере для клиентов ScyllaDB. Так что да, ожидайте, что вы заплатите премию за эту гибкость, если ваш трафик не похож на синусовую волну учебника и у вас есть кристаллический шар. Это не размер предмета, но это... Это та ловушка, которую вы, возможно, не ударите, пока не используете реальные данные приложений... в этот момент вы сразу пожалеете о том, что пропустили ее. В DynamoDB вы не просто платите за операцию; вы платите за кусочек переданных данных. Письменные запросы рассчитываются по 1 КБ (Write Request Units или WRUs). Читается по 4 КБ (Request Units или RRUs). Так что если вы записываете пункт 1.1KB, то это 2 WRUs. Напишите пункт 3KB? Все еще 3 WRUs, каждый 1KB (или его часть) подсчитывается. Читатели работают точно так же, только в пределах 4 КБ. Читать 1 КБ? 1 РРУ. Читать 4.1 КБ? Это 2 РРУ. Я уверен, что есть сильные технические причины для этих границ. Вы можете увидеть ловушку здесь. Соедините это с 5x стоимостью письма по сравнению с чтением, и вещи могут быть неприятными быстро, особенно если ваш размер элемента преодолевает эти пороги, не осознавая этого. Вероятно, это хорошо, если у вас есть фиксированный размер элемента в вашей схеме, но определенно не в порядке с типами случаев использования, которые мы видим в ScyllaDB. Например, клиенты могут иметь встроенные поля JSON или blob, которые могут сокращаться или расти с использованием. И помните, это реальный размер элемента, а не просто логический размер схемы. Сверхпрофилактика, потому что вы должны ... Другой болезненный момент, и отвратительное упущение от собственного калькулятора AWS, - это необходимость перераспределения при использовании предусмотренной емкости. Это звучит контринтуитивно, но вы вынуждены перераспределить - не потому, что вы хотите, а потому, что DynamoDB наказывает вас, если вы этого не делаете. Если вы пройдете мимо предусмотренной емкости, вы ударите Я люблю ясность этого типа исключительного сообщения.Я не люблю то, что он на самом деле делает, хотя: запрос затягивает. что сохраняет неиспользованные возможности чтения и письма. но помимо этого, ваше приложение просто проваливается. ПредоставлениеПравитьИсключение 300 окна мощности взрыва Таким образом, лучший способ противостоять этому — перераспределению. На сколько? Это гарантирует ответ «зависит». Но это зависит от типа вашей рабочей нагрузки. Мы добавили эту функциональность в наш калькулятор, чтобы вы могли динамически перераспределить на процент, просто чтобы учитывать дополнительные затраты на вашу рабочую нагрузку. Очевидно, эти затраты могут быстро увеличиваться, потому что на практике вы платите за пик, даже если вы работаете в трубе. Если вы не обеспечиваете достаточно высокую мощность, ваши пики рискуют быть забитыми, давая вам неудачи перед клиентами в худшее время. Прежде чем мы перейдем на... Если есть повторяющаяся тема здесь, это следующее: ценообразование DynamoDB не является по своей сути неправильным. Вы платите за то, что используете. Однако, это безумно непростительно для любой рабочей нагрузки, которая не выглядит как идеальная, предсказуемая синовая волна. Будь то это: 5x писать мультипликатор затрат 7.5x мультипликатор затрат по запросу Прогнозируемые ставки за секунду Наказательное округление и искусственные границы размеров предметов Или просто необходимость перенасыщения, чтобы избежать посадки лица во время пиковой нагрузки ...Вы постоянно должны второму угадать вашу архитектуру, чтобы оставаться впереди затрат. Ирония в том, что DynamoDB маркируется как «безсерверный» и «полностью управляемый», но вы в конечном итоге управляете математикой емкости, ошибками, аркадными ценовыми уровнями и бесконечной гимнастикой пропускной способности.После наблюдения за многими прогнозами таблиц наших клиентов (и экспортом AWS Cost Explorer) для DynamoDB даже зрелые команды, работающие с крупномасштабными системами, не имеют представления о стоимости... пока не стало слишком поздно. Вот почему мы построили калькулятор, который моделирует реальные нагрузки, а не только средние, потому что первым шагом к фиксированию затрат является понимание того, откуда они берутся. В , Я прохожу через некоторые реальные примеры клиентов, которые перешли от DynamoDB к ScyllaDB, чтобы показать истинное влияние моделей трафика, размеров элементов, кэш и топологий нескольких регионов. на . Мой следующий блог пост Пройдите вперед и моделируйте собственные рабочие нагрузки калькулятор.scylladb.com Моделируйте собственные рабочие нагрузки DynamoDB на нашем новом калькуляторе затрат О компании Tim Koopmans В течение последних нескольких десятилетий Тим занимался всеми видами инженерии, стремясь к надежности и безопасности.В 2013 году он основал Flood IO; распределенную платформу для тестирования производительности.После приобретения он наслаждался масштабированием продукта, бизнеса и команды, прежде чем перейти к другим усилиям, связанным с производительностью.
