Высокие нагрузки для начинающих

Что такое высокие нагрузки? Это нагрузки, когда система, созданная  на стандартных технологиях не справляется и нужно осуществлять уже не наращивание мощностей компьютера, а что-то качественно менять. Какие технологии применяются для высоких нагрузок?

Балансировщик нагрузки

Вот вы запускаете веб-сервис и ему нужно справляться с большим количеством запросов. И вот он в какой-то момент перестал справляться. А давайте добавим второй сервер - возникает мысль. А как запросы будут попадать на эти сервера? Есть решение - сервис Nginx, созданный давным давно русским разработчиком. Этот сервис устанавливают на отдельный сервер и он принимает от клиентов запросы и передает дальше. Есть множество других альтернатив, но Nginx стал уже стандартом де-факто и у нас в компании он используется повсеместно. Наши сервисы работают для всей России и этот маленький балансировщик прекрасно справляется. Как он распределяет запросы? Довольно распространенным подходом является Round Robin, когда для каждого нового запроса выбирается следующая реплика. Когда доходим до конца списка - начинаем сначала. При таком подходе у некоторых разработчиков возникает желание реализовать прилипание пользователей к репликам, чтобы использовать кеширование внутри реплик. Но сейчас прилипание считается плохим подходом и не рекомендуется. Nginx сейчас также используется не только для балансировки, но и просто как веб-сервер, являясь альтернативой для Apache Web Server. Долгое время для хостинга стандартным стеком был LAMP (linux-apache-mysql-php). Сейчас вместо apache многие используют nginx.

Балансировка балансировщиков

У вас возможно возник вопрос - но все равно же балансировщик упрется в производительность? Как работает Яндекс и Гугл? Для этих целей пользователям выдаются разные IP-адреса по одному и тому же имени. Этим уже занимаются DNS-сервера, которые определяют какой IP-адрес соответствует доменному имени. Тут также можно использовать подход RoundRobin, выдавая последовательно IP-адреса или можно основываться на географическом положении пользователя и таким образом выдавать адреса тех серверов, которые ближе географически.

Микросервисы

Довольно модной темой было разделение приложения на микросервисы. В чем удобство?

- Каждый сервис можно независимо развертывать (устанавливать на сервера, deploy)

- Микросервисы могут разрабатывать разные команды.

- Если микросервис ломается, то он не ломает все остальные (как правило).

- Помогает изолировать проблему потребления ресурсов. Вы сразу видите, кто потребляет CPU или память.

В настоящее время появилось большое количество противников микросервисов, поскольку за всё нужно платить. 

- Сетевые запросы между сервисами - дорогое удовольствие. Они замедляют вашу систему.

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

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

- Вы все равно при развертывании обновляете все свои сервисы, поскольку так проще и надежнее.

- Вы все равно разрабатываете все свои сервисы одной командой разработчиков.

Очередь задач

Другим подходом решения проблемы высокой нагрузки является очередь задач. Она применяется для выполнения длительных операций. Например, для конвертации картинок, шифрования, построения отчетов. Применяется, когда нет необходимости отвечать сразу же. Вы выполняете запрос на операцию, вам сервер выдает ID задачи и потом через некоторое время вы по ID проверяете, готова ли задача. Все задачи складываются в очередь и исполнители задач постепенно разгребают задачи в n потоков. Сервисы, реализующие очереди, достаточно умные и не дают одну и ту же задачу разным исполнителям (если все работает стабильно). Такой подход помогает справиться с большим потоком задач.

В нашей компании прижились сервисы RabbitMQ, Kafka и очередь сообщений собственной разработки.

Кеширование

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

Шардирование

По мере роста базы данных вы можете упереться объем дискового пространства. Вы можете наращивать диски на сервере, но и это может закончиться. Чтобы хранить данные на множестве серверов применяется механизм шардирование. Как это может работать? Например у вас 10 серверов и вам нужно хранить на них пользователей. Вы вычисляете из UserId хеш-функцию от 0 до 9 и сохраняете пользователя на соответствующий сервер.

Также не нужно забывать о репликации данных и на каждый сервер добавьте еще по 1-2 реплики для надежности.

NoSQL

NoSQL базы данных как правило имеют очень сильные ограничения по возможностям выборок данных и по структуризации данных по сравнению с SQL-базами данных. Но они решают проблему производительности. Также из коробки может идти решение по шардированию данных, чего обычно нет в SQL-базах данных.

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

При использовании NoSQL распространен подход денормализации данных, когда одни  и теже данные дублируются в разных структурах, чтобы сократить время выборки. 

CDN

Для новостных сайтов и других, которые находятся под постоянной высокой нагрузкой есть решение, которое называется Content Delivery Network. Статические файлы веб-сайта, а именно стили, HTML и Javascript (сейчас уже модно весь код сводить только к Javascript) можно сохранять в отдельном сервисе сторонней компании. В нашей компании я не слышал, чтобы использовались такие сервисы. Видимо, потому что у нас не такие высокие нагрузки.