Поддержка высоконагруженных систем было трендом еще в 2012 году. Но существует проблема — у нас до сих пор нет четкого определения этого термина. С чего начинаются высокие нагрузки? 10 запросов в секунду это уже высокая нагрузка или еще нет? А как насчет 100 запросов или 1000? Возможно, вы удивитесь, но цифры здесь вовсе не при чем.
Что такое High Load?
Во-первых, важно понять одну простую аксиому: High Load — понятие относительное. Его нельзя измерить количеством запросов, поступающих на сервер, или скоростью веб-сайта. Ведь не бывает «среднего» количества запросов, как и «среднего» сайта. Один веб-ресурс без проблем сможет обработать тысячу запросов в секунду, а другой рухнет на сотом подключении. Так что дело тут вовсе не в количественных показателях.
High Load означает устойчивость интернет-ресурса к высоким нагрузкам. Это не какой-то универсальный кусок кода, который можно копипастить и после которого все летает. Это настройка архитектуры сайта: работа с базами данных, сервер, использование современных технологий и языков программирования.
Если проводить аналогию с обычным магазином одежды, то вместо серверов, языков программирования и тому подобных IT терминов, у вас есть простой и понятный консультант, касса и товар. В обычный день к каждому клиенту подходит консультант, помогает подобрать размер, советует аксессуары, затем провожает до кассы и рассчитывает покупателя. Два-три консультанта вполне могут справиться с этой работой.
В Черную пятницу магазин атакуют сразу 50 покупателей — и их количество не уменьшается. По привычной схеме рядом с каждым ходят консультанты, охраняют клиентов в примерочной, бегают за нужным размером. При таком уровне только 5% тех, кто потенциально покинет магазин с покупками, имеют шанс получить качественный сервис, и то в лучшем случае. Следовательно, меньше прибыли для магазина и меньше лояльности клиентов. Очевидно, что работа консультантов нуждается в оптимизации. То же самое и с сайтом — если он не справляется с таким количеством запросов, пора что-то менять.
Самые большие проблемы с высокой нагрузкой
Инфраструктура с высокой нагрузкой обрабатывает большие объемы данных и тем самым создает большую ценность для бизнеса. Из-за этого сбои и другие проблемы с качеством приводят к дополнительным затратам для компаний. Так, согласно статье Gartner, потери крупных онлайн-сервисов достигают $300 000 в час в случае простоя.
Основным источником проблем в высоконагруженной инфраструктуре является объем данных, сложность и скорость их изменения. Поэтому важно, чтобы общая высоконагруженная архитектура большого приложения была спроектирована как с точки зрения программных компонентов, так и аппаратного обеспечения, на котором они работают. Более того, при проектировании нестандартной высоконагруженной системы необходимо четко понимать, какие сроки поставки установлены, какие существуют юридические ограничения, какой опыт имеют специалисты, занимающиеся проектированием. Кроме того, вы должны полностью осознавать связанные с этим риски и их приемлемость для компании.
После этого следующим этапом будет попытка ответить на ряд вопросов:
- как обеспечить правильность и полноту данных даже в случае сбоев
- как поддерживать высокую производительность приложения для пользователей системы
- как масштабироваться в случае роста нагрузки и т.д.
Если вы решили создавать high load приложения (в первую очередь в сфере веб-технологий), важно учитывать ряд принципов.
Доступность
Время безотказной работы напрямую связано с репутацией и эффективностью многих компаний.
Производительность
Скорость веб-ресурса влияет на удовлетворенность пользователей сервисом, а также на ранжирование в поисковой выдаче (что отражается на посещаемости).
Надежность
Запрос должен всегда возвращать пользователям одни и те же данные, чтобы пользователи были уверены, что если какие-то данные будут записаны/введены в систему, при последующем извлечении можно рассчитывать на их неизменность и сохранность.
Масштабируемость
Можно говорить о различных параметрах системы: сколько дополнительного трафика она может обработать, насколько просто увеличить емкость хранилища, сколько транзакций можно обработать сверх текущих возможностей.
Управляемость
Разработка собственной высоконагруженной системы, простой в эксплуатации, крайне важна на более поздних этапах развития проекта (легкая диагностика и понимание сути проблем при их возникновении, легкое обновление или модификация).
Расходы
Это включает затраты на оборудование и программное обеспечение. Важно учитывать и другие аспекты, необходимые для развертывания и обслуживания системы: количество времени, затрачиваемое разработчиками на сборку системы, количество усилий, необходимых для запуска системы, обучение, обучение персонала и т. Д.
Основные проблемы при проектировании заказных High-load систем возникают в следующих сегментах: объемы данных, распространение данных, коррекция данных, использование ПО с открытым исходным кодом, поиск, обработка и анализ данных и информационное моделирование.
Говоря о надежности высоконагруженных систем, необходимо упомянуть документацию по устранению неисправностей. Хорошо написанная документация по управлению сбоями должна включать простое пошаговое руководство по восстановлению вашей системы практически после любого возможного сбоя.
Известно, что когда речь идет о крупных центрах обработки данных, аппаратные сбои (будь то перебои в подаче электроэнергии, отказы жестких дисков или оперативной памяти) случаются постоянно. Одним из способов решения проблемы является создание неразделяемой высоконагруженной архитектуры. Благодаря такой архитектуре отсутствует центральный сервер, контролирующий и координирующий действия других узлов, и, соответственно, каждый узел системы может работать независимо друг от друга. У этих систем нет единой точки отказа, поэтому они гораздо более устойчивы к сбоям.
Еще одним методом предотвращения сбоев является увеличение резервирования отдельных компонентов системы для снижения частоты отказов (резервный блок питания, RAID — резервный массив дисков и т. д.). Когда один из компонентов выходит из строя, запасной компонент берет на себя его функции. Таким образом полностью избежать сбоя не удастся, однако вариант вполне приемлемый в большинстве случаев, так как есть возможность в короткие сроки восстановить систему из резервной копии.
Если говорить о глобальной избыточности, то все правила взаимодействия между серверами распространяются и на дата-центры — мы должны иметь запас прочности (емкость, вычислительная мощность и т. д.), чтобы продолжать работу при потере одного дата-центра без существенного ущерба качеству предоставляемых услуг.
Для обеспечения надежности системы рекомендуется использовать следующие подходы:
- Отделите те части системы, которые влияют на производительность системы, от частей, наиболее подверженных человеческим ошибкам.
- Внедряйте все формы тестирования, будь то модульное тестирование, комплексное системное тестирование или ручное тестирование.
- Предоставьте инструменты для восстановления системы в случае сбоя как можно скорее, чтобы свести к минимуму последствия.
- Внедрить систему метрик, мониторинга и логирования как инструментов диагностики ошибок и причин сбоев.
Приложение масштабируется настолько эффективно, насколько масштабируется самый слабый её компонент, поэтому важно помнить об определении таких мест. Попробуйте спроектировать собственную высоконагруженную систему с учетом будущего масштабирования и контролировать все, что происходит с оборудованием, через хорошо реализованную систему мониторинга компонентов системы.
Зачем рассматривать разработку высоконагруженной системы?
Необходимо определить две основные вещи. Во-первых, насколько велика аудитория, с которой может столкнуться проект. Во-вторых, проекту придется работать со структурированным набором данных, поэтому второй важный момент — понять, насколько большим и сложным будет этот набор данных.
Давайте рассмотрим типы проектов, для которых настоятельно рекомендуется использовать High-load подход:
Информационные ресурсы: в подавляющем большинстве случаев ключевым моментом здесь является то, что нет необходимости заранее планировать высоконагруженную архитектуру, очень небольшое количество информационных ресурсов перерастает возможности одного сервера с хорошо настроенной системой управления контентом. И даже если это произойдет, добавление новых серверов пройдет безболезненно благодаря широким возможностям кэширования контента и отсутствию необходимости сложных решений на уровне СУБД.
Интернет-магазины: здесь все упирается в широту ассортимента — если ассортимент теоретически не может вырасти до сотен тысяч наименований, то и особых решений не потребуется. В противном случае нужно подумать об эффективном кешировании часто посещаемых товаров и категорий, а также о минимизации «тяжелых» запросов к базе данных.
Социальные сети: основной критерий — теоретически возможное количество участников и связи между ними. Если речь идет о небольшой региональной или узко тематической социальной сети, то в реляционную базу данных можно легко поместить все, а вот для чего-то большего потребуется масштабируемое решение.
Технологические проекты: проекты, основанные на техническом ноу-хау, напрямую зависят от него и, как правило, уже на этапе проектирования «изюминки» проекта становится ясно, какая архитектура ему больше подходит и как ее развивать в будущем.
Архитектура приложения с высокой нагрузкой
Архитектура — это основа приложения. Как и в строительстве качество дома зависит от прочности фундамента, от этого же зависит успех и жизнеспособность системы.
В решениях использовать или не использовать высоконагруженные системы нужно ориентироваться на то, что нужно конкретному бизнесу. Но есть еще и планирование — то, чего бизнес не видит и от чего не получает прямой выгоды. Когда речь идет о высоконагруженных приложениях, мало разработать грамотную архитектуру. Нужно также построить связанную систему мониторинга, которая будет следить за жизнеспособностью компонентов, скоростью реакции, генерировать и отображать данные для контроля работоспособности High-load систем.
Стоимость разработки системы мониторинга может составлять до трети от общей стоимости создания высоконагруженного приложения. Но без него сложно построить надежную высоконагруженную систему.
Бизнес, к сожалению, не всегда понимает, для чего он нужен. Зачем платить деньги за дополнительный функционал, который не требуется для работы и не приносит прибыли? Есть вполне оправданное желание сэкономить, но экономить на мониторинге при высокой нагрузке — не лучшая идея.
Специфика высоконагруженных систем заключается в том, что с ними нельзя работать, как с любой другой системой. Как правило, особое внимание требуется при оптимизации высокой нагрузки. Сотни взаимосвязанных настроек могут как помогать системе, так и портить ее работу. Работа специалиста заключается в том, чтобы правильно подобрать параметры, чтобы бизнес-задачи выполнялись успешно, а для этого часто приходится изучать новые материалы, использовать предыдущий опыт, проводить множество тестов и так далее.