Что такое горизонтальное и вертикальное масштабирование
Вертикальное и горизонтальное масштабирование, scaling для web
Для примера можно рассмотреть сервера баз данных. Для больших приложений это всегда самый нагруженный компонент системы.
Возможности для масштабирования для серверов баз данных определяются применяемыми программными решениями: чаще всего это реляционные базы данных (MySQL, Postgresql) или NoSQL (MongoDB, Cassandra и др).
Горизонтальное масштабирование для серверов баз данных при больших нагрузках значительно дешевле
Веб-проект обычно начинают на одном сервере, ресурсы которого при росте заканчиваются. В такой ситуации возможны 2 варианта:
MySQL является самой популярной RDBMS и, как и любая из них, требует для работы под нагрузкой много серверных ресурсов. Масштабирование возможно, в основном, вверх. Есть шардинг (для его настройки требуется вносить изменения в код) и репликация, которая может быть сложной в поддержке.
Вертикальное масштабирование 
NoSQL масштабируется легко и второй вариант с, например, MongoDB будет значительно выгоднее материально, при этом не потребует трудозатратных настроек и поддержки получившегося решения. Шардинг осуществляется автоматически.
Таким образом с MySQL нужен будет сервер с большим количеством CPU и оперативной памяти, такие сервера имеют значительную стоимость.
Горизонтальное масштабирование
С MongoDB можно добавить еще один средний сервер и полученное решение будет стабильно работать давая дополнительно отказоустойчивость. 
Scale-out или горизонтальное масштабирование является закономерным этапом развития инфраструктуры. Любой сервер имеет ограничения и когда они достигнуты или когда стоимость более мощного сервера оказывается неоправданно высокой добавляются новые машины. Нагрузка распределяется между ними. Также это дает отказоустойчивость.
Добавлять средние сервера и настраивать кластеры нужно начинать когда возможности для увеличения ресурсов одной машины исчерпаны или когда приобретение сервера мощнее оказывается невыгодно
Приведенный пример с реляционными базами данных и NoSQL является ситуацией, которая имеет место чаще всего. Масштабируются также фронтэнд и бэкенд сервера.
Вертикальное и горизонтальное масштабирование
Вводные сведения о масштабируемости баз данных при облачных вычислениях
Данные повсюду: что скрывается за понятием «масштабируемость»
Масштабируемость при облачных вычислениях — это возможность быстро и без труда увеличить или уменьшить размер либо мощность ИТ-решения или ресурса. В то время как термин «масштабируемость» может означать способность любой системы справиться с растущим объемом работы, в контексте горизонтального и вертикального масштабирования речь часто идет о базах данных и больших объемах данных.
Обеспечение масштабируемости базы данных — самая приоритетная задача для разработчиков современных приложений. Предположим, новое приложение становится популярным. Спрос на него возрастает от нескольких пользователей до миллионов пользователей по всему миру. На этом этапе эффективное масштабирование критически необходимо разработчикам приложений, чтобы адаптироваться к спросу и свести к минимуму время простоя.
Это обсуждение различий между горизонтальным и вертикальным масштабированием сосредоточено на способах, с помощью которых масштабируемость позволяет адаптироваться к огромным объемам разнообразных данных и управлять ими, изменяя объемы данных и шаблоны рабочих нагрузок, которые создаются в облаке, на мобильных устройствах, в социальных сетях и источниках больших данных.
Сравнение горизонтального и вертикального масштабирования
На самом базовом уровне масштабируемость баз данных можно разделить на два типа:
Vertical scaling, or scaling up or down, where you increase or decrease computing power or databases as needed—either by changing performance levels or by using elastic database pools to automatically adjust to your workload demands.
Horizontal scaling, or scaling out or in, where you add more databases or divide your large database into smaller nodes, using a data partitioning approach called sharding, which can be managed faster and more easily across servers.
Вертикальное масштабирование
Вертикальное масштабирование используется, когда необходимо быстро реагировать на проблемы с производительностью, которые нельзя решить с помощью классической методики оптимизации базы данных, например изменения запросов или индексирования. Вертикальное масштабирование помогает справиться с пиками в рабочих нагрузках, когда текущий уровень производительности не может удовлетворить все требования. Вертикальное увеличение масштаба позволяет добавлять дополнительные ресурсы, чтобы легко адаптироваться к пиковым рабочим нагрузкам. Затем, если ресурсы больше не нужны, можно выполнить вертикальное уменьшение масштаба, чтобы вернуться к исходному состоянию и сократить затраты на облако.
Вертикальное масштабирование выполняется в следующих случаях:
Горизонтальное масштабирование
Разработчики приложений начинают применять горизонтальное масштабирование, если им не удается получить достаточно ресурсов для рабочих нагрузок даже на самых высоких уровнях производительности. При горизонтальном масштабировании данные разбиваются на несколько баз данных (или сегментов) между серверами. Масштаб каждого сегмента можно вертикально увеличивать или уменьшать по отдельности.
Как секционирование данных повышает масштабируемость? При вертикальном увеличении масштаба отдельной базы данных путем добавления таких ресурсов, как виртуальные машины, в конечном итоге будет достигнуто физическое ограничение оборудования. Каждая секция данных размещается на отдельном сервере, поэтому, если разделить данные на несколько сегментов, можно практически без ограничений горизонтально увеличивать масштаб системы.
Некоторые типы технологий баз данных, особенно нереляционные базы данных или базы данных NoSQL, разрабатываются с уникальными возможностями горизонтального увеличения масштаба данных путем сегментирования. Это позволяет таким базам данных управлять объемными, несвязанными, неопределенными или быстро изменяющимися данными.
Кроме того, некоторые реляционные службы баз данных (SQL), изначально предлагавшие услуги вертикального увеличения или уменьшения масштаба, начинают предоставлять интересные возможности, позволяя достичь уровня масштабируемости нереляционных баз данных. Службы гипермасштабирования, такие как Гипермасштабирование Базы данных SQL Microsoft Azure и Гипермасштабирование Базы данных Azure PostgreSQL, дают пользователям возможность быстро масштабировать хранилище до 100 ТБ, обеспечивают ориентированную на облако гибкую архитектуру, позволяя увеличивать объем хранилища в соответствии с потребностями, а также включать почти моментальные операции резервного копирования и быстрые операции восстановления баз данных за несколько минут.
Горизонтальное масштабирование выполняется в следующих случаях:
Автомасштабирование
Автоматическое масштабирование — это процесс автоматического и динамического согласования ресурсов с требованиями к производительности системы. По мере увеличения объема работы приложениям могут потребоваться дополнительные ресурсы для поддержки необходимых уровней производительности или удовлетворения растущих потребностей. Если потребность уменьшается и дополнительные ресурсы больше не нужны, вы можете сократить расходы на облако с помощью автоматической службы, которая отменит выделение неиспользуемых ресурсов.
Автоматическое масштабирование использует преимущества эластичности облачных сред. Это упрощает управление, уменьшая необходимость для системных операторов постоянно принимать решения о добавлении либо удалении ресурсов или проверке производительности системы.
Есть два основных способа масштабирования приложений: вертикальное и горизонтальное. Вертикальное масштабирование реже выполняется автоматически, так как при нем часто требуется, чтобы система была временно недоступна во время повторного развертывания.
Автоматическое масштабирование чаще выполняется при горизонтальном масштабировании, так как горизонтальное увеличение или уменьшение масштаба означает просто добавление или удаление экземпляров ресурса. При этом ваше приложение продолжает работу без прерывания во время подготовки новых ресурсов. Если потребность уменьшается, вы можете беспрепятственно и без простоев завершить работу ресурсов, а также отменить их выделение.
Многие поставщики облачных систем, такие как Microsoft Azure, поддерживают автоматическое горизонтальное масштабирование.
Часто задаваемые вопросы
База данных — это любая коллекция взаимосвязанных сведений, которая хранится и упорядочивается для упрощения управления и доступа. Новые данные и типы данных создаются с головокружительной скоростью. Поэтому обеспечить упорядоченность, доступность и защиту этих данных становится непросто. Для обработки огромных объемов данных часто используются системы управления базами данных (СУБД), которые включают в себя слой средств управления.
Для адаптации к огромному объему разнообразных данных, создаваемых в облаке, на мобильных устройствах, а также в социальных сетях и источниках больших данных, разрабатываются все новые типы баз данных и технологии.
Базы данных NoSQL, часто называемые нереляционными или not only SQL (не только SQL), —это разнообразные технологии, которые позволяют по-разному хранить данные и извлекать их из традиционной реляционной базы данных (SQL).
Базы данных NoSQL не нуждаются в предопределенной схеме и могут использовать несколько моделей данных. Это делает их чрезвычайно эффективными при обработке больших объемов неструктурированных данных и масштабировании проектов баз данных для больших данных.
PostgreSQL — это надежная база данных с открытым кодом, которая работает с реляционными и нереляционными запросами. Решение известно своей надежностью и способностью обеспечить целостность данных. PostgreSQL широко используется в таких сферах, как финансовые услуги, производство, государственные географические информационные системы и веб-технологии. Разработчики с помощью PostgreSQL создают приложения, а администраторы доверяют этому решению защиту данных.
Кэширование — это распространенный способ, используемый разработчиками и ИТ-специалистами для повышения производительности и масштабируемости системы. При кэшировании часто запрашиваемые данные временно копируются в быстрое хранилище данных, расположенное ближе к приложению. Если это быстрое хранилище данных находится ближе к приложению, чем исходный оригинал, кэширование может значительно улучшить время отклика для клиентских приложений путем более быстрой обработки данных. Разработчики часто создают приложения с возможностью кэширования обработанных данных, а затем перепрофилируют кэш для ускоренного обслуживания запросов (по сравнению со стандартными базами данных).
Сегментирование данных — это тип горизонтального секционирования данных, который позволяет разделить большую базу данных на базы данных меньшего размера, которыми проще и быстрее управлять, используя разные серверы.
Платформа как услуга (PaaS) — это служба от поставщика облачных служб, которая предоставляет среду по запросу для разработки, тестирования и доставки приложений, а также управления ими. Модель «платформа как услуга» упрощает и ускоряет разработчикам задачу создания веб-приложений или мобильных приложений без настройки и администрирования базовой инфраструктуры серверов, хранилища, сети и баз данных, которые необходимы при разработке.
Горизонтальное масштабирование. Что, зачем, когда и как?
Александр Макаров ( SamDark )
Здравствуйте! Я Александр Макаров, и вы можете меня знать по фреймворку «Yii» — я один из его разработчиков. У меня также есть full-time работа — и это уже не стартап — Stay.com, который занимается путешествиями.
Сегодня я буду рассказывать про горизонтальное масштабирование, но в очень-очень общих словах.
Что такое масштабирование, вообще? Это возможность увеличить производительность проекта за минимальное время путем добавления ресурсов.
Обычно масштабирование подразумевает не переписывание кода, а либо добавление серверов, либо наращивание ресурсов существующего. По этому типу выделяют вертикальное и горизонтальное масштабирование.
Вертикальное — это когда добавляют больше оперативки, дисков и т.д. на уже существующий сервер, а горизонтальное — это когда ставят больше серверов в дата-центры, и сервера там уже как-то взаимодействуют.
Самый классный вопрос, который задают, — а зачем оно надо, если у меня все и на одном сервере прекрасно работает? На самом-то деле, надо проверить, что будет. Т.е., сейчас оно работает, но что будет потом? Есть две замечательные утилиты — ab и siege, которые как бы нагоняют тучу пользователей конкурента, которые начинают долбить сервер, пытаются запросить странички, послать какие-то запросы. Вы должны указать, что им делать, а утилиты формируют такие вот отчеты:
Главные два параметра: n — количество запросов, которые надо сделать, с — количество одновременных запросов. Таким образом они проверяют конкурентность.
На выходе получаем RPS, т.е. количество запросов в секунду, которое способен обработать сервер, из чего станет понятно, сколько пользователей он может выдержать. Все, конечно, зависит от проекта, бывает по-разному, но обычно это требует внимания.
Есть еще один параметр — Response time — время ответа, за которое в среднем сервер отдал страничку. Оно бывает разное, но известно, что около 300 мс — это норма, а что выше — уже не очень хорошо, потому что эти 300 мс отрабатывает сервер, к этому прибавляются еще 300-600 мс, которые отрабатывает клиент, т.е. пока все загрузится — стили, картинки и остальное — тоже проходит время.
Бывает, что на самом деле пока и не надо заботиться о масштабировании — идем на сервер, обновляем PHP, получаем 40% прироста производительности и все круто. Далее настраиваем Opcache, тюним его. Opcache, кстати, тюнится так же, как и APC, скриптом, который можно найти в репозитории у Расмуса Лердорфа и который показывает хиты и мисы, где хиты — это сколько раз PHP пошел в кэш, а мисы — сколько раз он пошел в файловую систему доставать файлики. Если прогнать весь сайт, либо запустить туда какой-то краулер по ссылкам, либо вручную потыкать, то у нас будет статистика по этим хитам и мисам. Если хитов 100%, а мисов — 0%, значит, все нормально, а если есть мисы, то надо выделить больше памяти, чтобы весь наш код влез в Opcache. Это частая ошибка, которую допускают — вроде Opcache есть, но что-то не работает…
Еще часто начинают масштабировать, но не смотрят, вообще, из-за чего все работает медленно. Чаще всего лезем в базу, смотрим — индексов нет, ставим индексы — все сразу залетало, еще на 2 года хватит, красота!
Ну, еще надо включить кэш, заменить apache на nginx и php-fpm, чтобы сэкономить память. Будет все классно.
Все перечисленное достаточно просто и дает вам время. Время на то, что когда-то этого станет мало, и к этому уже сейчас надо готовиться.
Как, вообще, понять, в чем проблема? Либо у вас уже настал highload, а это не обязательно какое-то бешеное число запросов и т.д., это, когда у вас проект не справляется с нагрузкой, и тривиальными способами это уже не решается. Надо расти либо вширь, либо вверх. Надо что-то делать и, скорее всего, на это мало времени, что-то надо придумывать.
Первое правило — никогда ничего нельзя делать вслепую, т.е. нам нужен отличный мониторинг. Сначала мы выигрываем время на какой-то очевидной оптимизации типа включения кэша или кэширования Главной и т.п. Потом настраиваем мониторинг, он нам показывает, чего не хватает. И все это повторяется многократно – останавливать мониторинг и доработку никогда нельзя.
Что может показать мониторинг? Мы можем упереться в диск, т.е. в файловую систему, в память, в процессор, в сеть… И может быть такое, что, вроде бы, все более-менее, но какие-то ошибки валятся. Все это разрешается по-разному. Можно проблему, допустим, с диском решить добавлением нового диска в тот же сервер, а можно поставить второй сервер, который будет заниматься только файлами.
На что нужно обращать внимание прямо сейчас при мониторинге? Это:
Вот список замечательных инструментов, которые позволяют мониторить ресурсы и показывать результаты в очень удобном виде:
Для мониторинга ошибок есть два хороших сервиса:
Sentry можно поставить к себе на сервер, есть исходник, а Rollbar — нет, но Rollbar лучше, потому что он берет деньги за количество ошибок, т.е. стимулирует их исправлять.
Про нотификации повторю, что спамить не стоит, теряется внимание.
Что, вообще, надо анализировать?
RPS и Responce time — если у нас начинает время ответа падать, то надо что-то делать.
Количество процессов, потоков и размеры очередей — если это все начинает плодиться, забиваться и т.д., то что-то здесь опять не так, надо анализировать более детально и как-то менять инфраструктуру.
Также стоит смотреть на бизнес-анализ. Google Analytics для сайтовых типов отлично подходит, а mixpanel — для логирования ивентов, он работает на десктопных приложениях, на мобильных, на веб. Можно и на основе каких-то своих данных писать, но я бы советовал готовые сервисы. Смысл в том, что наш мониторинг может показывать, что сервис жив, что все работает, что общий Responce time нормальный, но когда мы, допустим, регистрацию в mixpanel’е начинаем трекать, он показывает, что их как-то маловато. В этом случае надо смотреть, насколько быстро отрабатывают определенные ивенты, страницы, и в чем состоят проблемы. Проект всегда должен быть «обвешан» анализом, чтобы всегда знать, что происходит, а не работать вслепую.
Нагрузка, вообще, возникает или запланировано, или нет, может возникать постепенно, может не постепенно:
Как бороться с нагрузкой? Решает все бизнес, и важна только цена вопроса. Важно:
Если дешевле попрофайлить, оптимизировать, записать в кэш, поправить какие-то конфиги, то это и надо делать, не задумываясь пока о масштабировании и о том, чтобы докупать «железо» и т.д. Но бывает, что «железо» становится дешевле, чем работа программиста, особенно, если программисты очень подкованные. В этом случае уже начинается масштабирование.
На рисунке синяя штука — это Интернет, из которого идут запросы. Ставится балансировщик, единственная задача которого — распределить запросы на отдельные фронтенды-сервера, принять от них ответы и отдать клиенту. Смысл тут в том, что 3 сервера могут обработать (в идеале) в 3 раза больше запросов, исключая какие-то накладные расходы на сеть и на саму работу балансировщика.
Что это нам дает? Указанную выше возможность обработать больше запросов, а еще надежность. Если в традиционной схеме валится nginx или приложение, или в диск уперлись и т.п., то все встало. Здесь же, если у нас один фронтенд отвалился, то ничего страшного, балансировщик, скорее всего, это поймет и отправит запросы на оставшиеся 2 сервера. Может, будет чуть помедленнее, но это не страшно.
Вообще, PHP — штука отличная для масштабирования, потому что он следует принципу Share nothing по умолчанию. Это означает, что если мы возьмем, допустим, Java для веба, то там приложение запускается, читает весь код, записывает по максимуму данных в память программы, все там крутится, работает, на request уходит очень мало времени, очень мало дополнительных ресурсов. Однако есть засада — т.к. приложение написано так, что оно должно на одном инстансе работать, кэшироваться, читать из своей же памяти, то ничего хорошего у нас при масштабировании не получится. А в PHP по умолчанию ничего общего нет, и это хорошо. Все, что мы хотим сделать общим, мы это помещаем в memcaсhed, а memcaсhed можно читать с нескольких серверов, поэтому все замечательно. Т.е. достигается слабая связанность для слоя серверов приложений. Это прекрасно.
Чем, вообще, балансировать нагрузку?
Чаще всего это делали Squid’ом или HAProxy, но это раньше. Сейчас же автор nginx взял и партировал из nginx+ балансировщик в nginx, так что теперь он может делать все то, что раньше делали Squid’ом или HAProxy. Если оно начинает не выдерживать, можно поставить какой-нибудь крутой дорогой аппаратный балансировщик.
Проблемы, которые решает балансировщик — это как выбрать сервер и как хранить сессии? Вторая проблема — чисто PHP’шная, а сервер может выбираться либо по очереди из списка, либо по географии каких-то IP’шников, либо по какой-то статистике (nginx поддерживает least-connected, т.е. к какому серверу меньше коннектов, на него он и будет перекидывать). Можем написать для балансировщика какой-то код, который будет выбирать, как ему работать.
Вот, по этой ссылке описан балансировщик, свежепартированный в nginx:
Всем рекомендую, там очень простые конфиги, все максимально просто.
Что, если мы упремся в балансировщик?
Есть такая штука как DNS Round robin — это замечательный трюк, который позволяет нам не тратиться на аппаратный балансировщик. Что мы делаем? Берем DNS-сервер (обычно DNS-сервера у себя никто не хостит, это дорого, несильно надежно, если он выйдет из строя, то ничего хорошего не получится, все пользуются какими-то компаниями), в А-записи прописываем не один сервер, а несколько. Это будут А-записи разных балансировщиков. Когда браузер туда идет (гарантий, на самом деле, нет, но все современные браузеры так действуют), он выбирает по очереди какой-нибудь IP-адрес из А-записей и попадает либо на один балансировщик, либо на второй. Нагрузка, конечно, может размазываться не равномерно, но, по крайней мере, она размазывается, и балансировщик может выдержать немного больше.
Что делать с сессиями?
Сессии у нас по умолчанию в файлах. Это не дело, потому что каждый из серверов-фронтендов у нас будет держать сессии в своей файловой системе, а пользователь может попадать то на один, то на второй, то на третий, т.е. сессии он будет каждый раз терять.
Возникает очевидное желание сделать общую файловую систему, подключить NFS. Но делать так не надо — она до жути медленная.
Можно записать в БД, но тоже не стоит, т.к. БД не оптимальна для этой работы, но если у вас нет другого выхода, то, в принципе, сойдет.
Можно писать в memcached, но очень-очень осторожно, потому что memcached — это, все-таки, кэш и он имеет свойство вытираться, как только у него мало ресурсов, или некуда писать новые ключи — тогда он начинает терять старые без предупреждения, сессии начинают теряться. За этим надо либо следить, либо выбрать тот же Redis.
Redis — нормальное решение. Смысл в том, что Redis у нас на отдельном сервере, и все наши фронтенды ломятся туда и начинают с Redis’а свои сессии считывать. Но Redis однопоточный и рано или поздно можем хорошенько упереться. Тогда делают sticky-сессии. Ставится тот же nginx и сообщается ему, что нужно сделать сессии так, чтобы юзер, когда он пришел на сервер и ему выдалась сессионная cookie, чтобы он впоследствии попадал только на этот сервер. Чаще всего это делают по IP-хэшу. Получается, что если Redis на каждом инстансе, соответственно, сессии там свои, и пропускная способность чтения-записи будет гораздо лучше.
Как насчет cookies? Можно писать в cookies, никаких хранилищ не будет, все хорошо, но, во-первых, у нас все еще куда-то надо девать данные о сессии, а если мы начнем писать в cookies, она может разрастись и не влезть в хранилище, а, во-вторых, можно хранить в cookies только ID, и нам все равно придется обращаться к БД за какими-то сессионными данными. В принципе, это нормально, решает проблему.
Есть классная штука — прокси для memcached и Redis:
Они, вроде как, поддерживают распараллеливание из коробки, но делается это, я не сказал бы, что очень оптимально. А вот эта штука — twemproxy — она работает примерно как nginx с PHP, т.е. как только ответ получен, он сразу отправляет данные и в фоне закрывает соединение, получается быстрее, меньше ресурсов потребляет. Очень хорошая штука.
Очень часто возникает такая ошибка «велосипедирования», когда начинают писать, типа «мне сессии не нужны! я сейчас сделаю замечательный токен, который будет туда-сюда передаваться»… Но, если подумать, то это опять же сессия.
В PHP есть такой механизм как session handler, т.е. мы можем поставить свой handler и писать в cookies, в БД, в Redis — куда угодно, и все это будет работать со стандартными session start и т.д.
Сессии надо закрывать вот этим замечательным методом.
Как только мы из сессии все прочитали, мы не собираемся туда писать, ее надо закрыть, потому что сессия частенько блокируется. Она, вообще-то, должна блокироваться, потому что без блокировок будут проблемы с конкурентностью. На файлах это видно сразу, на других хранилищах блокировщики бывают не на весь файл сразу, и с этим немного проще.
Что делать с файлами?
С ними можно справляться двумя способами:
И Amazon S3 — это, если вы в облаке Amazon’а, — тоже хорошая файловая система.
Если вы реализуете со стороны PHP, есть замечательная библиотека Flysystem, покрытая отличными тестами, ее можно использовать для работы со всякими файловыми системами, что очень удобно. Если вы сразу напишете всю работу с файлами с этой библиотекой, то потом перенести с локальной файловой системы на Amazon S3 или др. будет просто — в конфиге строчку переписать.
Как это работает? Пользователь из браузера загружает файл, тот может попадать либо на фронтенд и оттуда расползаться по файловым серверам, либо на каждом файловом сервере делается скрипт для аплоада и файл заливается сразу в файловую систему. Ну и, параллельно в базу пишется, какой файл на каком сервере лежит, и мы читать его можем непосредственно оттуда.
Лучше всего раздавать файлы nginx’ом или Varnish’ем, но лучше все делать nginx’ом, т.к. мы все его любим и используем — он справится, он хороший.
Что у нас происходит с базой данных?
Если у вас все уперлось в код PHP, мы делаем кучу фронтендов и все еще обращаемся к одной БД — она справится достаточно долгое время. Если нагрузка не страшная, то БД живет хорошо. Например, мы делали JOIN’ы по 160 млн. строк в таблице, и все было замечательно, все бегало хорошо, но там, правда, оперативки надо больше выделить на буферы, на кэш…
Что делать с БД, если мы уперлись в нее? Есть такие техники как репликация. Обычно делается репликация мастер-слэйв, есть репликация мастер-мастер. Можно делать репликацию вручную, можно делать шардирование и можно делать партицирование.
Что такое мастер-слэйв?
Выбирается один сервер главным и куча серверов — второстепенными. На главный пишется, а читать мы можем с мастера, а можем и со слэйвов (на картинке красные стрелочки — это то, что мы пишем, зеленые — то, что мы читаем). В типичном проекте у нас операций чтения гораздо больше, чем операций записи. Бывают нетипичные проекты.
В случае типичного проекта большое количество слэйвов позволяет разгрузить как мастер, так и, вообще, увеличить скорость чтения.
Также это дает отказоустойчивость — если упал один из слэйвов, то делать ничего не надо. Если упал мастер, мы можем достаточно быстро сделать один из слэйвов мастером. Правда, это обычно не делается автоматически, это внештатная ситуация, но возможность есть.
Ну, и бэкапы. Бэкапы базы все делают по-разному, иногда это делается MySQL-дампом, при этом он фризит весь проект намертво, что не очень хорошо. Но если делать бэкап с какого-нибудь слэйва, предварительно остановив его, то пользователь ничего не заметит. Это прекрасно.
Кроме этого, на слэйвах можно делать тяжелые вычисления, чтобы не затронуть основную базу, основной проект.
Есть такая штука как read/write split.Делается 2 пула серверов — мастер, слэйв, соединение по требованию, и логика выбора соединения варьируется. Смысл в том, что если мы будем всегда читать со слэйвов, а писать всегда в мастер, то будет небольшая засада:
т.е. репликация выполняется не немедленно, и нет гарантий, что она выполнилась, когда мы делаем какой-либо запрос.
Есть два типа выборок:
Причины подобного лага — это либо медленная сеть, либо не справляется реплика, либо слишком много слэйвов (больше 20 на 1 мастер). Если медленная сеть, то понятно, ее надо как-то ускорять, собирать в единые дата-центры и т.д. Если не справляется реплика, значит надо добавить реплик. Если же слишком много слэйвов, то надо уже придумывать что-то интересное, скорее всего, делать какую-то иерархию.
Что такое мастер-мастер?
Это ситуация, когда стоит несколько серверов, и везде и пишется, и читается. Плюс в том, что оно может быть быстрее, оно отказоустойчивое. В принципе, все то же, что и у слэйвов, но логика, вообще, простая — мы просто выбираем рандомное соединение и с ним работаем. Минусы: лаг репликации выше, есть шанс получить какие-то неконсистентные данные, и, если произошла какая-нибудь поломка, то она начинает раскидываться по всем мастерам, и никому уже неизвестно, какой мастер нормальный, какой поломался… Это все дело начинает реплицироваться по кругу, т.е. очень неслабо забивает сеть. Вообще, если пришлось делать мастер-мастер, надо 100 раз подумать. Скорее всего, можно обойтись мастер-слэйвом.
Можно делать репликацию всегда руками, т.е. организовать пару соединений и писать сразу в 2, в 3, либо что-то делать в фоне.
Что такое шардирование?
Фактически это размазывание данных по нескольким серверам. Шардировать можно отдельные таблицы. Берем, допустим, таблицу фото, таблицу юзеров и др., растаскиваем их на отдельные сервера. Если таблицы были большие, то все становится меньше, памяти ест меньше, все хорошо, только нельзя JOIN’ить и приходится делать запросы типа WHERE IN, т.е. сначала выбираем кучу ID’шников, потом все эти ID’шники подставляем запросу, но уже к другому коннекту, к другому серверу.
Можно шардировать часть одних и тех же данных, т.е., например, мы берем и делаем несколько БД с юзерами.
Можно достаточно просто выбрать сервер — остаток от деления на количество серверов. Альтернатива — завести карту, т.е. для каждой записи держать в каком-нибудь Redis’е или т.п. ключ значения, т.е. где какая запись лежит.
Есть вариант проще:
Сложнее — это когда не удается сгруппировать данные. Надо знать ID данных, чтобы их достать. Никаких JOIN, ORDER и т.д. Фактически мы сводим наш MySQL или PostgreSQL к key-valuе хранилищу, потому что мы с ними ничего делать не можем.
Обычные задачи становятся необычными:
Из коробки шардинг поддерживается такими штуками как:
Часто статистику любят считать с основного сервера — с единственного сервера БД. Это прекрасно, но запросы в статистике обычно жуткие, многостраничные и т.д., поэтому считать статистику по основным данным — это большая ошибка. Для статистики в большинстве случаев realtime не нужен, так что мы можем настроить мастер-слэйв репликацию и на слэйве эту статистику уже посчитать. Или мы можем взять что-нибудь готовое — Mixpanel, Google Analytics или подобное.
Это основная идея, которая помогает раскидывать все по разным серверам и масштабировать. Во-первых, от этого сразу виден профит — даже если у вас один сервер и вы начинаете в фоне что-то выполнять, юзер получает ответ гораздо быстрее, но и впоследствии размазывать нагрузку, т.е. мы можем перетащить всю эту обработку на другой сервер, можно обрабатывать даже не на PHP. Например, в Stay.com картинки ресайзятся на Go.
Можно сразу взять Gearman. Это готовая штука для обработки в фоне. Есть под PHP библиотеки, драйвера… А можно использовать очереди, т.е. ActiveMQ, RabbitMQ, но очереди пересылают только сообщения, сами обработчики они не вызывают, не выполняют, и тогда придется что-то придумывать.
Общий смысл всегда один — есть основное ПО, которое помещает в очереди какие-то данные (обычно это «что сделать?» и данные для этого), и какой-то сервис – он либо достает, либо ему прилетают (если очередь умеет активно себя вести) эти данные, он все обрабатывает в фоне.
Перейдем к архитектуре.
Самое главное при масштабировании — это в проекте сделать как можно меньше связанности. Чем меньше связанности, тем проще менять одно решение на другое, тем проще вынести часть на другой сервер.
Связанность бывает в коде. SOLID, GRASP — это принципы, которые позволяют избежать связанности именно в коде. Но связанность в коде на разнос по серверам, конечно, влияет, но не настолько, насколько связанность доменного слоя с нашим окружением. Если мы в контроллере пишем много-много кода, получается, что в другом месте мы это использовать, скорее всего, не сможем. Нам непросто будет все это переносить из веб-контроллера в консоль и, соответственно, сложнее переносить на другие сервера и там обрабатывать по-другому.
Есть 2 подхода разбиения систем на части:
Еще важно то, что части всегда должны взаимодействовать через интерфейсы. Так, в нашем примере, если Sales с чем-то взаимодействует, то он не пишет в БД, не использует общую модель, а с другими областями «разговаривает» через определенный контракт.
Что с доменным слоем?
Доменный слой разбивается на какие-то сервисы и т.п. — это важно для разработки приложения, но для масштабирования его проектирование не очень-то и важно. В доменном слое сверхважно отделить его от среды, контекста, в котором он выполняется, т.е. от контроллера, консольного окружения и т.д., чтобы все модели можно было использовать в любом контексте.
Есть 2 книги про доменный слой, которые всем советую:
Не стоит недооценивать браузерную оптимизацию. Как я уже говорил, из тех 300-600 мс, которые запросы выполняются на сервере, к ним прибавляется 300-600 мс, которые тратятся на клиенте. Клиенту все равно, сервер ли у нас быстрый, или это сайт так быстро отработал, поэтому советую использовать Google PageSpeed и т.д.
Как обычно, абстракция и дробление совсем не бесплатны. Если мы раздробим сервис на много микросервисов, то мы больше не сможем работать с новичками и придется много-много платить нашей команде, которая будет во всем этом рыться, все слои перебирать, кроме этого сервис может начать медленнее работать. Если в компилируемых языках это не страшно, то в PHP, по крайней мере, до версии 7, это не очень…
Никогда не действуйте вслепую, всегда мониторьте, анализируйте. Вслепую практически все решения по умолчанию неправильные. Думайте! Не верьте, что существует «серебряная пуля», всегда проверяйте.
Еще немного ссылок полезных:
На ruhighload.com в супердоступной форме расписаны практически все принципы, очень поверхностно, но классно, с рисунками и т.д. Советую там посмотреть обзоры того, как различные большие компании находили классные решения.
В англоязычном Интернете не знают слова «highload», поэтому там ищите по слову «sclability».
Часто это пробуют на живых серверах. Делать этого ни в коем случае не надо, есть такие классные штуки как DigitalOcean и Linode, где можно поднять ноду, развернуть там любое окружение, любой сервер, все потестить, заплатив за это 1-2 бакса, максимум.
Контакты
Этот доклад — расшифровка одного из лучших выступлений на обучающей конференции разработчиков высоконагруженных систем HighLoad++ Junior за 2015 год.
— Старьё! — скажите вы.
— Вечные ценности! — ответим мы.
Также некоторые из этих материалов используются нами в обучающем онлайн-курсе по разработке высоконагруженных систем HighLoad.Guide — это цепочка специально подобранных писем, статей, материалов, видео. Уже сейчас в нашем учебнике более 30 уникальных материалов. Подключайтесь!
Ну и главная новость — мы начали подготовку весеннего фестиваля «Российские интернет-технологии», в который входит восемь конференций, включая HighLoad++ Junior.