Создание сайтов. Как управляться с высокими нагрузками на сайт.

   К сфере highload вам следует прикоснуться, еще когда вы будете составлять ТЗ на создание сайта. Как мы заметили ранее, внутреннее устройство проекта зависит от типа интернет-ресурса и от ваших исходных амбиций.

   • Определитесь с типом проекта и его задачами. Четко понимая их, вы сэкономите свое время и деньги. Почти наверняка вам нет надобности нанимать системного архитектора, трех инженеров и пятерых кодеров, если вы запускаете нишевой интернет-магазин подарков. И наоборот, будет самонадеянно доверять разработку «второго “ВКонтакте”» соседу-студенту, а не команде профи.

   Еще обсуждая бриф, попробуйте вме сте с потенциальным исполнителем хотя бы в первом приближении ответить на вопросы, касающиеся ресурсов, которые понадобятся проекту. С какой частотой будет обновляться информация на сайте? Как много данных будет одновременно находиться в системе? Насколько сложно они структурированы? Какая часть из них должна единовременно держаться в оперативной памяти сервера? Какие основные типы запросов будут актуальны в проекте? И так далее. Не пугайтесь. Вам не нужно разбираться в методах кластеризации или репликации данных. Достаточно внятно и исчерпывающе описать функциональность задуманного вами сайта: «Посетитель может загружать фотографии и на лету редактировать их с помощью предустановленных фильтров, делиться снимками в общем чате (до 20 человек в беседе), одним кликом скачивать чужие галереи целиком на свой жесткий диск…» – и квалифицированный веб-разработчик сам обратится к теме нагрузок и прикинет масштабность замысла. Возвращаемся к пройденному: чем детальнее вы представляете себе сайт и его сервисы на самой ранней стадии, тем лучше.

   • Выберите правильных технических специалистов. Веб-разработчики, умеющие проектировать и реализовывать highload-системы, в российском Интернете на вес золота. Если вы дерзаете собирать большую техническую команду самостоятельно, первым делом ищите главного разработчика или системного архитектора и обязательно привлекайте его к поиску остальных специалистов. Иначе, даже при условии, что набранные вами программисты будут асами каждый в своей нише, не факт, что сумма их компетенцией окажется подходящей для вашего проекта. Бывает, что «зоопарк технологий» возникает по уважительным причинам (давняя история сайта и необходимость безболезненно добавить в него новую функциональность на ходу, нетривиальность продукта и т. д.), но зачастую загвоздка именно в том, что у команды изначально не было общего стратегического видения проекта, поэтому языки программирования и серверные технологии выбирались «по случаю», исходя из уз колокальных соображений.

   • При необходимости обратитесь в компании, которые специализируются на разработке высоконагруженных систем. Если сайт вы задумали масштабный, в перспективе – с высокой посещаемостью, но в веб-разработке у вас нет опыта, то разумнее всего будет поручить создание технической инфраструктуры мастерам своего дела. Например, «Онтико» (http://www.ontico.ru) и HighloadLab (http://highloadlab.com). То же касается сложных интернет-ресурсов любого типа, к которому вы ранее не подступались. В противном случае риски возрастают многократно: легко нанять непрофильных специалистов, наизобретать велосипедов и потратить деньги вовсе не на то, что нужно.

   • Вместе с командой определите, какие звенья сайта могут оказаться слабыми. Разберите все составные части проекта, от аппаратной базы и хостинга до настроек сервера, от используемых баз данных до связки front-end – back-end. Мы не будем вдаваться в подробности методов и решений, использ уемых в работе над высоконагруженными сайтами, но опишем базовые принципы, на которые опирается highload-разработка.

 

   I. Продуманность и масштабируемость архитектуры. Нельзя спроектировать сайт так, чтобы навсегда забыть о высоких нагрузках. Но можно сделать его таким образом, чтобы при необходимости увеличения мощности на порядок не приходилось переделывать архитектуру с нуля, а достаточно было включить дополнительные серверы и провести их небольшую настройку. Исходите не из того, что умеет тот программист, который у вас под рукой, а из того, что именно вам нужно, из особенностей сайта. Для начала – кто на него будет ходить: люди, боты – сборщики информации сторонних сервисов, те и другие? От ответа зависит, на каком фундаменте возводить серверную архитектуру. RTB-сеть [22 - RTB (от англ. real-time bidding – «торги в реальном времени») – рекламный аукцион, в рамках которого информацией обмениваются между собой автоматизированные системы.] требует не совсем тех средств масштабирования, что открытая онлайн-энциклопедия наподобие Wikipedia. Выбор базы данных и сопутствующих решений также зависит от того, с какими задачи и процедурами сайту предстоит иметь дело главным образом. У фотохостинга и сервиса онлайн-бухгалтерии такие круги задач пересекается лишь в малой части.

   II. Предварительные вычисления и кэширование. Упрощенно, кэширование – сохранение определенной информации (результатов работы) в готовом виде, чтобы не выполнять вычисления всякий раз заново. Кэшированию поддаются как отдельные фрагменты информации, так и целые веб-страницы. Другой пример предварительных вычислений: заранее получить результат, к которому в дальнейшем часто будут обращаться посетители сайта, и держать его наготове, чтобы при первом запросе не обрабатывать его динамически. Никого не удивляет, когда под кэш в крупных высоконагруженных веб-проектах задействуются десятки гигабайт. Общая концепция обработки данных на интернет-ресурсе сводится к приоритизации задач.

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

 

  Обратите внимание  

   Будьте осторожнее с исполнителями, которые возводят ту или иную технологию в ранг религии. На каждый случай есть свое оптимальное решение, универсальных средств нет. Тот же nginx прекрасен, но чаще на высоконагруженных проектах используется лишь как часть связки: на клиентской стороне – nginx, на серверной – Apache.

 

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