https://www.facebook.com/tr?id=592246827906368&ev=PageView &noscript=1"/>
Для отображения персонализированного контента и рекламных сообщений, а также хранения личных настроек на локальном компьютере веб-сайт www.rdn-grp.ru используют технологию cookie и аналогичные. Продолжив использование наших веб-сайтов, Вы даете согласие на обработку персональных данных, выражаете согласие с Политикой конфиденциальности www.rdn-grp.ru и применением этих технологий.
portfolio_item_page
Москва, Большая Черемушкинская 34, лофт «Микроэкономика», 6 этаж

Основные ошибки внедрения высоконагруженных сайтов

Статья подготовлена на основе вебинара от 12 августа 2021 года


Спикеры:

Директор RDN Group Дмитрий Россихин

DevOps-инженер RDN Group Андрей Коненко


Эта статья создана на основе последнего вебинара из серии обучающих семинаров RDN Group по работе с высоконагруженными проектами.

Для начала давайте ответим на вопрос – что же является Highload проектом и всегда ли они связны с ЛК?

В нашем случае – это почти всегда именно так: ЛК сайтов и порталов, в которые необходимо «подтягивать» информацию из разных источников и проводить интеграцию различных систем, начиная от остатков и резерва товара и т.д.,– несомненный атрибут крупной современной компании.

Высоконагруженные проекты с ЛК, которые упрощают путь к продукции и услугам, наиболее востребованы корпорациями и холдингами, крупнейшими промышленными корпорациями. Для них мы разрабатываем аукционы и торговые площадки, большие корпоративные порталы от 2 тыс. пользователей̆, а также реализуем сложные интеграции (от 3-х и более, так называемая микросервисная архитектура).

Специалисты RDN Group занимались интеграцией̆ еще тогда, когда в нашей стране не был распространен DevOps-подход и гибкие методологии. Делали много нетипичных интеграций Битрикс24 с 1С. Один из примеров –это обмен 3млн. единиц товаров в рамках проекта для компании Лонмади. Классический обмен, если его не переписывать, занял бы почти 3 недели. Потребовалось нестандартное решение и архитекторы нашли его: создали промежуточную базу в качестве интеграционного слоя. Была переписана топология обмена, за счет чего скорость увеличилась многократно. Результат – несколько тысяч товаров выгружаются за 3 секунды.

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

Учитываем особенности систем, которые использует заказчик

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

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

Каждый IT-специалист знает, что доступность данных является одной из целей информационной безопасности. Если система будет недоступна в критические моменты, то это может привести к дополнительным издержкам: потере репутации и убыткам.

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

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

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

Мониторинг в Highload

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

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

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

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

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

Кластеризация

Кластеризация решает вопрос как масштабирования, так и надежности нашего приложения, она не заменяет резервного копирования, контроля ошибок, тестирования, но она необходима.

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

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

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

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

Представьте, поступила задача – собрать кластер для обеспечения отказоустойчивости аппаратной части, но БД оказалась не готова, потому что ее структура не предполагала в некоторых таблицах уникальных ключей.Нет понимания, какие данные скопированы, а которые еще не перенесены. Ограничения таковы, что при не корректной кластеризации мы можем повредить данные, а резервная копия в высоконагруженных проектах не панацея. Если мы повредим данные, то откат даже на час назад может быть критичен, особенно для аукционов, торговых площадок и т.п. Тоже самое может быть и стороны web-сервера. Для Highload требуется несколько узлов передачи и хранения информации. 

Чтобы не витать в облаках

У бизнеса существует мнение, что для повышения отказоустойчивости достаточно просто перенести свое приложение в облако, например в Яндекс,Гугл, Амазон и т. д. – это решает проблемы с издержками на содержание собственной инфраструктуры, ее модернизации, поддержки, но это может оказаться и капканом. Например, многие облачные инфраструктуры используют свои уникальные интерфейсы, у них свои особенности по работе с дисковыми хранилищами. Если мы пишем наше приложение, т. е. создаем масштабируемость на базе Амазона, то миграция в Яндекс.Облако может влететь нам в копеечку, потребуется переписать ряд скриптов, технологических решений. Также мы понимаем, что если существует миграция, то появляются геополитические угрозы. Выбирать облако нужно ответственно, опираясь на ФЗ РФ о защите персональных данных.

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

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

Разговор о Highload проектах мы готовы продолжить 9 сентября на бизнес-завтраке, где подробнее рассмотрим темы, которые мы подняли в рамках этого вебинара. На такие завтраки мы приглашаем наших enterprise-заказчиков, кому интересны темы высоконагруженных проектов, понимая, что они не так актуальны для малого и среднего бизнеса, однако, будем рады видеть всех желающих. 

Если вам интересно принять участие в мероприятии напишите нам на почту info@rdn-group.ru.



Веб-интегратор RDN Group
Большая Черемушкинская 34, лофт «Микроэкономика», офис 619 117218 Москва г, РФ info@rdn-grp.ru

Рассчитать стоимость
проекта

ОСТАВИТЬ ЗАЯВКУ
Рассчитать стоимость проекта

ЗАКАЗАТЬ ОБРАТНЫЙ ЗВОНОК

ОСТАВЬТЕ НОМЕР ТЕЛЕФОНА
Остались вопросы? Мы перезвоним вам и поможем!