Жизнь в эпоху высоконагруженных информационных систем. Основные подходы к разработке

Веб-приложение: от «обычного» к высоконагруженному

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

Однако высоконагруженной может быть система не только из упомянутых выше категорий. Сегодня существует огромное количество ИТ-систем, которые обрабатывают большие объемы запросов от внешних или внутренних пользователей, а также от IoT-устройств, программных роботов и смежных систем. Часто бывает, что стандартный сайт какого-то производства после расширения бизнеса набирает аудиторию, получает новую функциональность (онлайн-заказы, сервисная поддержка, база знаний с видеопрезентациями и т. д.), и вычислительных мощностей, выделенных на его сопровождение, компании уже не хватает. Требуется не только его масштабирование, но и новые подходы к архитектуре приложения, а также во многих случаях – дополнительные инструменты информационной безопасности.

Далее мы рассмотрим основные принципы архитектуры высоконагруженных приложений и приведем реальные примеры из практики.

Масштабирование

Масштабируемость информационной системы – это ее возможность увеличивать качественные и количественные характеристики без необходимости переработки, с помощью наращивания мощностей. Различают два вида масштабирования: вертикальное и горизонтальное. При вертикальном масштабировании производительность и пропускная способность системы достигается посредством увеличения мощности существующего сервера – понятно, что у такого способа существует определенный предел. При горизонтальном масштабировании происходит добавление в ИТ-инфраструктуру дополнительных серверов, инстансов или узлов.

По нашему опыту, масштабируемость информационной системы необходимо обеспечивать на всех уровнях.

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

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

В-третьих, на интеграционном уровне. Брокеры сообщений так же должны быть реализованы на базе кластерных решений, таки, как Kafka и RabbitMQ.

Асинхронная обработка

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

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

Для этого мы используем брокеры Apache Kafka. Запись сообщения в брокер – это операция простая, линейная и предсказуемая. Соответственно, мы можем зафиксировать ответ системы на запрос в текущий момент, а сами данные поставить в очередь для дальнейшего сохранения. Важно, что в случае высоконагруженных систем применяется решение на базе кластера из нескольких брокеров Kafka, чтобы количество реплик (экземпляров одного сервиса-консьюмера) было больше, чем один. Таким образом обеспечивается надежность решения. Для того, чтобы топик (инструмент управления потоками сообщений) поддерживал потребление несколькими консьюмерами, используется партиционирование.

Подход "In-Memory"

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

Один из сценариев применения In-Memory – онлайн-обработка запросов, когда веб-приложению нужно очень быстро обработать данные и вернуть результат. В нашей компании есть опыт работы с такими СУБД, как с Redis, Tarantool, Apache Ignite. В целом их смысл сводится к тому, что мы помещаем данные внутрь In-Memory хранилища и дальше с ними работаем всегда быстрее, чем если бы данные сохранялись на диске. Особенно это касается операций записи.

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

Шардирование и репликация

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

Шардирование – это распределение данных на фрагменты с целью одновременной более быстрой их обработки одновременно на нескольких серверах. Это дает возможность существенно увеличить трафик веб-приложения и при этом сохранить целостность данных.

Репликация – масштабирование баз данных посредством копирования данных с одного сервера на другие. Она позволяет распределить нагрузку между серверами.