Планирование емкости для баз данных

Опубликовано: 2016-06-21

Примечание. Этот пост основан на недавнем посте Джулии Эванс о планировании емкости.

СУБД

Во-первых, давайте установим некоторые основные правила. Да… этот пост предназначен для тех из нас, кто использует MySQL с одним модулем записи одновременно и двумя или более репликами чтения. Многое из того, о чем я буду здесь говорить, по-другому или вообще не относится к кластерным хранилищам данных с несколькими записями, хотя они также имеют свой собственный набор компромиссов и предостережений. Так что… ваш пробег определенно изменится.

Тем не менее, это сообщение в блоге БУДЕТ применяться независимо от того, используете ли вы самостоятельные физические хосты или находитесь в AWS, где вы можете использовать магические зарезервированные экземпляры и почти мгновенное выделение ресурсов. Нахождение в «облаке» не помешает вам знать возможности и ограничения вашей инфраструктуры, а также не освободит вас от этой ответственности перед вашей командой и клиентами.

Разделение

Я уже подробно рассказывал об этом в одном из своих предыдущих постов, я в основном сосредоточился там на преимуществах функционального или горизонтального сегментирования. Да, это обязательное условие, поскольку то, что вы используете для доступа к уровню базы данных, БУДЕТ определять степень гибкости, которую вы сможете масштабировать.

Если вы совершенно новая компания, вам может не понадобиться функциональное сегментирование в первый день, но, если вы надеетесь (и я подозреваю, что надеетесь) на рост, не ограничивайте себя ORM с открытым исходным кодом, который не позволит вам разделить ваши данные на функциональной основе в дальнейшем. Бонусные баллы, если вы также не начинаете свою компанию со всеми своими реляционными данными в одной схеме.

Возможность разделения чтения и записи

Это то, что вам нужно будет уметь делать, но не обязательно применять как непреложное правило. Будут случаи использования, когда запись должна быть прочитана очень скоро после этого, и когда устойчивость к таким вещам, как задержка/согласованность в конечном счете, низкая. Это нормально, но в тех же приложениях у вас также будут сценарии для чтения, которые могут выдержать более длительный период согласованности в конечном итоге. Когда такие чтения выполняются в больших объемах, действительно ли вы хотите, чтобы этот объем достался вашему единственному писателю, если на самом деле это не обязательно? Сделайте себе одолжение и убедитесь, что вскоре в дни вашего роста вы можете контролировать использование IP-адресов для чтения или записи в своем коде.

Теперь перейдем к мыслительному процессу фактического планирования емкости… Кластер базы данных не справляется, что мне делать?

Определить узкое место в системе

  • У вас есть проблемы с записью или чтением?
  • Проблема проявляется в высокой загрузке ЦП?
  • Выставляется ли он как емкость ввода-вывода?
  • Растет ли задержка на репликах без явного виновника запроса на чтение?
  • Это замки?
  • Откуда я вообще знаю, что это такое?

Каждый из них может быть отдельным постом. Я пытаюсь подчеркнуть, что вы должны быть знакомы с вашей системой и конкретными показателями БД, чтобы иметь возможность выяснить, какая часть является узким местом.

Вам нужен базовый уровень

Всегда следите за тем, чтобы у вас были доступны базовые системные метрики для визуализации хотя бы за несколько недель до этого. Многие инструменты обеспечивают это (Cacti, Munin, Graphite и т. д.). Как только вы узнаете, к какой системной метрике вы в основном привязаны, вам необходимо установить базовые и пиковые значения. В противном случае определение того, является ли ваша текущая проблема новой ошибкой в ​​​​приложении или реальным ростом, будет гораздо более подвержено ошибкам, чем вам хотелось бы.

Тем не менее, базовые серверные метрики могут быть ограничены — в какой-то момент вы обнаружите, что вам также нужны контекстные метрики. Производительность запросов и воспринимаемая производительность на стороне приложения расскажут вам, что приложение считает временем ответа на запросы. Существует множество инструментов для интенсивного отслеживания этого контекста. Некоторые из них с открытым исходным кодом, такие как Anemometer, и коммерческие инструменты, такие как Vivid Cortex (мы используем их в SendGrid. См., что мы говорим об этом здесь). Даже простое отслеживание этих показателей с точки зрения приложения и использование их в качестве показателей статистики будет хорошим первым шагом. Но сначала вы должны привыкнуть к тому факту, что ваше приложение воспринимает то, что воспринимают ваши клиенты. И вы должны сначала найти способ узнать.

Изучите модели трафика вашего бизнеса

Ваш бизнес подвержен экстремальным пиковым нагрузкам в определенные дни недели (например, маркетинг)? У вас есть регулярные запуски, которые увеличивают ваш трафик втрое или вчетверо, как игры? Такого рода вопросы будут определять, сколько зарезервированного запаса вы должны сохранить или нужно ли вам инвестировать в эластичный рост.

Определить соотношение количества необработанного трафика к используемой емкости

Это просто ответ на вопрос: «Если бы мы не оптимизировали код, сколько сообщений электронной почты/продаж/пользователей в Интернете/что угодно» мы можем обслуживать с экземплярами базы данных, которые у нас есть прямо сейчас?

В идеале это конкретное значение, которое превращает математику планирования годового роста в простое математическое уравнение. Но жизнь никогда не бывает идеальной, и это значение будет меняться в зависимости от сезона или совершенно внешних счастливых факторов, таких как регистрация нового крупного клиента. В ранних стартапах это число является более быстрой целью, но оно должно стабилизироваться по мере того, как компания переходит от ранних дней к более устоявшемуся бизнесу с более предсказуемыми моделями роста бизнеса.

Действительно ли мне нужно покупать больше машин?

Вам нужно найти способ определить, действительно ли это емкость — мне нужно разделить записи, чтобы поддерживать более параллельную нагрузку записи, или добавить больше реплик чтения — против. узкое место производительности на основе кода (этот новый запрос из недавнего развертывания действительно может кэшировать свои результаты в чем-то более дешевом и не так сильно превосходить базу данных).

Как ты это делаешь? Вам нужно ознакомиться с вашими запросами. Первым шагом для этого является комбинация innotop, slow log и pt-query-digest из Percona Toolkit. Вы можете автоматизировать это, отправив журналы БД в центральное расположение и автоматизировав часть дайджеста.

Но это еще не вся картина, медленные журналы требуют высокой производительности, если вы слишком сильно снижаете их порог. Если вы можете жить с менее выборочной выборкой, вам нужно будет обнаруживать все диалоги между приложением и хранилищем данных. В стране с открытым исходным кодом вы можете использовать простой tcpdump или размещаемые продукты, такие как Datadog, New Relic или VividCortex.

Позвонить

Планирование мощности может быть на 90 % наукой и на 10 % искусством, но эти 10 % не должны означать, что мы не должны стремиться к как можно большей части картины. Как инженеры мы можем иногда зацикливаться на недостающих 10% и не осознавать, что если мы проделаем работу, то эти 90% могут помочь нам лучше понять состояние нашего стека, более эффективно использовать наше время, оптимизируя производительность и планируя ресурсы. тщательно увеличивается, что в конечном итоге приводит к гораздо более высокой окупаемости инвестиций в нашу продукцию.