21 мая 2024

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

Термин «высоконагруженное веб-приложение» говорит сам за себя: это комплексная информационная система, содержащая огромные объемы информации и сохраняющая оптимальную производительность в условиях высокой нагрузки – например, при одновременном обращении к ней сотен, тысяч и даже миллионов пользователей. Разумеется, такие системы требуют особых подходов в плане разработки – к архитектуре, масштабированию, хранению и обработке данных и другим характеристикам. Опытом создания и поддержки таких приложений делится Степан Бочаров, ведущий руководитель группы компании IT_ONE.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подход "In-Memory"

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

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

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

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

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

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

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

Источник: Tadviser

Читайте наш кейс на РБК: как ИТ-компании прокачать бренд работодателя

16 июля 2024

Как вырастить штат ИТ-компании в 15 раз за 3 года - рассказываем в совместном кейсе с IT_ONE

 

Ася Власова – в шоу «Стражи Леса» на радио «ЭХО лОСЕЙ»

10 июля 2024

Ася Власова, сооснователь и управляющий партнёр агентства iTrend, приняла участие в шоу “Стражи Леса” на радио "ЭХО лОСЕЙ". Вместе с Еленой Бочеровой из компании "Киберпротект" поговорили о том, как выстраивать PR и коммуникации в ИТ.

 

Приглашаем на конференцию для директоров по маркетингу и PR-руководителей ИТ-компаний 

5 июня 2024

На мероприятии встретятся директора по маркетингу и PR-руководители крупных российских ИТ-компаний.

 

Экс-редактор Comnews присоединился к команде iTrend

30 мая 2024

На позицию руководителя проектов коммуникационного агентства iTrend вышел Денис Шишулин – ранее многолетний выпускающий редактор издательской группы ComNews, одного из самых авторитетных ИТ-изданий в России. В iTrend Денис будет отвечать за стратегическое руководство ряда PR-проектов с ИТ-компаниями, оперативное взаимодействие со СМИ, координацию работы команд, а также за качество проектов, которыми руководит в агентстве.

 

iTrend — в числе топ-агентств России по версии «Рейтинга Рунета»

28 мая 2024

Опубликованы итоги ранкинга коммуникационных агентств от «Рейтинга Рунета–2024». iTrend занял лидирующие места в ключевых для агентства срезах — PR в ИТ-отрасли, SMM в ИТ-отрасли, PR и SMM на аудиторию b2b enterprise, PR-аналитика, PR первых лиц и др.

 
Все новости iTrend