Тема 2/4: Масштабирование с репликацией и шардированием → Урок 1/5
Введение в масштабирование
Представьте себе динамичную стартап-компанию «Мегашоп», специализирующуюся на онлайн-торговле. В самом начале «Мегашоп» был небольшим проектом, его база данных легко справлялась с десятками тысяч товаров и сотнями заказов в день.
Благодаря успешной маркетинговой стратегии и отличному сервису, популярность «Мегашопа» выросла. Сначала рост был постепенным, и сервер базы данных справлялся с увеличивающимся количеством пользователей и данных. Но наступает Чёрная пятница — и поток заказов резко увеличивается в десятки раз. Сайт начинает работать медленнее, страницы загружаются с задержкой, а некоторые пользователи даже сталкиваются с ошибками при попытке оформить заказ — приложение падает и перезапускается. Всё это приводит к недовольству клиентов и потере потенциальной прибыли.
Руководство «Мегашопа» понимает, что если не принять меры, то при следующей волне роста бизнеса проблемы могут стать катастрофическими. А проблему с нынешними отказами приложения нужно решать уже сейчас. Пора задуматься о поддержке высокого уровня производительности и доступности даже при максимальных нагрузках. А для этого нужно понять, как проблема бизнеса отражается на текущей архитектуре.
Сейчас архитектура компании «Мегашоп» выглядит так:
Пока компания была маленькой, всего хватало. Теперь нужно подумать, где именно происходит поломка сейчас и что может сломаться дальше.
- Сервер Он один и достаточно мощный, но находится внутри компании. Если сломается — работа встанет.
- База данных У неё та же проблема, что и у севера, только она уже сейчас не справляется с нагрузкой.
- Приложение Один экземпляр, уже подтормаживает, а под нагрузкой вообще падает. Перезапуск требует времени, а продажи в это время стоят.
- Сайт на ReactJS и Nginx К нему меньше всего вопросов, но он не зарезервирован — не обеспечена отказоустойчивость. Плюс есть неочевидная проблема, которая влияет на UX пользователя: на nginx выгружаются ролики для товаров и при запуске в других регионах пользователи ждут дольше.
Проблемы выявлены — теперь нужно подумать, как справляться с ростом нагрузки. В этом уроке узнаете про вертикальное и горизонтальное масштабирование, а также про разные методы горизонтального масштабирования. В следующих уроках расскажем про них подробнее и дадим практические задания. Для сервера и базы данных вы изучите методы масштабирования решения, включая шардирование и репликацию, узнаете критерии выбора подходящей стратегии для конкретных сценариев.
Как нам это сделать?
Введение в масштабирование решения
✏️ Масштабирование решения — это адаптация программного обеспечения к увеличению нагрузки или требований с сохранением высокой производительности и доступности.
Масштабирование нужно, когда приложение сталкивается с резким увеличением пользовательской базы или трафика, что приводит к перегрузке текущей инфраструктуры. Причём такое увеличение должно быть регулярным: разовые всплески обычно приводят только к тому, что мы проверяем систему на прочность и начинаем думать, как защититься в следующий раз.
Существует два самых известных способа масштабирования. Расскажем о них подробнее.
Вертикальное и горизонтальное масштабирование
Вертикальное масштабирование. Подразумевает добавление ресурсов к одному узлу, например, увеличение объёма оперативной памяти (RAM), мощности процессора (CPU), объёма жёсткого диска (HDD) на сервере. То есть мы берём и просто делаем мощнее наш сервер «Мегашопа». Это может быть эффективным решением для небольших приложений, но имеет физические ограничения и часто стоит дорого.
Горизонтальное масштабирование. Заключается в добавлении новых узлов в систему, что позволяет распределить нагрузку между ними. Это обеспечивает практически неограниченный рост и лучшую отказоустойчивость, но требует более сложной настройки и управления.
В случае «Мегашопа» серверов должно быть больше, а располагаться они должны не только внутри компании, чтобы даже если отключат свет, сайт продолжал получать заказы.
Горизонтальное масштабирование предпочтительнее для обработки больших объёмов данных и высоких нагрузок. Вертикальное масштабирование эффективнее для улучшения производительности отдельных операций (например, по выборке данных из нескольких десятков таблиц).
💡 Кроме вертикального и горизонтального масштабирования, есть ещё так называемое облачное, или гибридное масштабирование, — использование облачных сервисов для масштабирования IT-решений. Это обеспечивает быстрое масштабирование в зависимости от потребностей, снижение затрат на инфраструктуру и обслуживание. По факту это комбинация вертикального и горизонтального масштабирования за счёт ресурсов облака.
Вспоминаем наши узкие места. Самой проблемной сейчас кажется база данных: ведь она уже не справляется и её отказ тянет за собой и приложение. На её примере и разберём способы масштабирования.
Профили нагрузки
Чтобы эффективно продумать и реализовать стратегию масштабирования, необходимо понимать так называемый профиль нагрузки — насколько, когда и как долго происходит недостаток ресурсов.
Примеры профилей нагрузки:
- Статический Каждую ночь в 00:00 количество активных пользователей составляет менее 100, а загрузка ЦП на серверах приложений снижается на 90% на всех узлах.
- Динамический, регулярный и предсказуемый Каждый понедельник утром в систему 1С входит 1000 сотрудников из нескольких регионов.
- Динамический, нерегулярный и предсказуемый Запуск продукта происходит в первый день месяца, и есть исторические данные о том, как увеличивается трафик в таких ситуациях.
- Динамический, нерегулярный и непредсказуемый Крупномасштабное событие вызывает всплеск спроса на продукт. Например, распродажа остатков.
Прежде чем выбирать решение для своего продукта, нужно оценить, насколько всё может быть плохо, в том числе с помощью моделирования рисков с учётом профилей нагрузки.
Если это статическая нагрузка, то масштабирование понадобится, когда будет достигнут верхний предел. В этом случае может подойти как горизонтальное, так и вертикальное масштабирование.
Если нагрузка динамическая, то выбор зависит от того, как именно она изменяется динамически.
Для регулярной и предсказуемой нагрузки можно выбрать репликацию, кэширование, шардирование. Если же нагрузка распределена ещё и по регионам, то подойдёт географическое распределение ресурсов.
Для динамической нерегулярной и непредсказуемой нагрузки к методам регулярной и предсказуемой подойдёт ещё автоматическое масштабирование (как горизонтально, так и вертикально) для оперативного реагирования.
C вертикальным масштабированием всё просто: оно требует просто добавления ресурсов. Интереснее горизонтальное масштабирование, которого можно достичь разными методами.
Примеры методов горизонтального масштабирования
Репликация
✏️ Репликация — это процесс копирования и распространения данных между различными базами данных для обеспечения их согласованности и доступности.
Представьте, есть крупная социальная сеть, где пользователи публикуют фотографии и видео.
Чтобы обеспечить быструю загрузку контента и минимальные задержки при взаимодействии с приложением, данные должны быть доступны пользователям в любой момент, независимо от их географического положения. С помощью репликации можно в центральном дата-центре разместить главный сервер для записи данных и серверы-реплики для чтения, а в реплики помещать копии данных с главного сервера.
Когда пользователь из Китая захочет просмотреть фотографию, которая была загружена пользователем из Канады, запрос будет направлен к ближайшему серверу-реплике в Китае, а не к главному серверу в Канаде. Это значительно сократит время загрузки контента.
Комбинирование шардирования и репликации
Шардирование — это метод разделения данных на отдельные фрагменты (шарды), который используется для повышения производительности и надёжности баз данных. Существует два основных вида шардирования: вертикальное и горизонтальное. О них в теме ещё расскажем подробнее.
Шардирование применяют вместе с репликацией для достижения наибольшего эффекта.
Например, данные можно разбить на шарды по регионам или типам данных и каждый шард может иметь несколько реплик для обеспечения высокой доступности и производительности.
Пример: В крупной социальной сети пользовательские данные разделены по регионам (шардирование), а каждая региональная база данных реплицируется для обеспечения отказоустойчивости и распределения нагрузки на чтение.
Кэширование (англ. Caching)
Кэширование данных часто используется для повышения производительности, особенно при частых запросах к одним и тем же данным. Данные временно сохраняются в памяти, чтобы сократить время доступа.
Пример: В интернет-магазине данные о самых популярных товарах хранятся в кэше, чтобы ускорить загрузку страниц и снизить нагрузку на основную базу данных.
Географически распределённые ресурсы
В системах с глобальной аудиторией данные могут храниться в географически распределённых центрах обработки данных, чтобы обеспечить минимальные задержки доступа для пользователей из разных регионов.
Пример: В потоковом видеосервисе данные кэшируются и хранятся в дата-центрах по всему миру. Так пользователи могут получать контент с минимальной задержкой, независимо от их местоположения.
Автоматическое масштабирование (англ. Auto-Scaling)
Некоторые системы используют автоматическое масштабирование, которое позволяет динамически добавлять или удалять ресурсы в зависимости от текущей нагрузки.
Пример: В облачных сервисах, таких как Amazon Web Services (AWS) или Google Cloud Platform (GCP), базы данных могут автоматически масштабироваться в ответ на изменения нагрузки. Это обеспечивает оптимальное использование ресурсов и минимальные затраты.
Использование специализированных баз данных для разных типов данных
В некоторых случаях целесообразно использовать различные базы данных для разных типов данных: например, реляционные базы данных для транзакционных данных и NoSQL для больших объёмов неструктурированных данных.
Пример: В электронной коммерции транзакции и данные о пользователях хранятся в реляционной базе данных. Данные о продуктах и каталогах — в NoSQL-базе данных для быстрой обработки запросов и большей гибкости.
Эти примеры показывают, как разные стратегии масштабирования можно применить в зависимости от специфики и требований системы.
Теперь давайте посмотрим на нашу базу данных. Какую стратегию здесь выбрать?
Вариант с вертикальным масштабированием не очень подходит: он не решит проблему отказов. Стоит посмотреть в сторону горизонтального масштабирования. В следующем уроке начнём с репликации — рассмотрим применение кэширования и дальше пройдёмся по всем стратегиям. Не затронем только применение специализированных баз данных для разных типов информации: здесь информация достаточно однородна и мы уже применяем достаточно гибкий вариант БД — Mongo DB.
Итоги
- Масштабирование решения — это адаптация программного обеспечения к увеличению нагрузки или требований с сохранением высокой производительности и доступности. Оно нужно, когда приложение сталкивается с резким увеличением пользовательской базы или трафика, что приводит к перегрузке текущей инфраструктуры.
- Масштабирование бывает вертикальным, когда увеличивается объём ресурсов. И горизонтальным, когда в систему добавляются новые узлы с распределением нагрузки между ними.
- Чтобы эффективно продумать и реализовать стратегию масштабирования, необходимо понимать так называемый профиль нагрузки — насколько, когда и как долго происходит недостаток ресурсов.
- У вертикального масштабирования один метод — простое добавление ресурсов. А у горизонтального есть разные методы: репликация, шардирование и репликация, географически распределённые ресурсы, автоматическое масштабирование, использование специализированных баз данных для разных типов данных. Разные стратегии масштабирования можно применить в зависимости от специфики и требований системы.
В следующем уроке продолжим знакомство с методами масштабирования. Расскажем про репликацию и кэширование. Какие они имеют преимущества и ограничения, когда их использовать. Вы выполните практику в Redis и настроите распределённое кэширование данных.