Текст книги "Создание сайтов"

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

Если у вас обычное онлайн-СМИ и посетитель читает на нем по три-четыре статьи за визит, фактически потребляя статичный контент, то и при 20–30 тысячах заходов в сутки оно, скорее всего, будет благополучно существовать на стандартном виртуальном хостинге или, максимум, на одном выделенном сервере (см. главу 7 «Домен и хостинг: паспорт, прописка, жилье»). Зато сайт знакомств почти всегда highload в чистом виде, к чему надо быть готовым еще на старте. «Яндекс» и «ВКонтакте» – это, безусловно, высоконагруженные проекты в хрестоматийном понимании. Но в ту же категорию попадают кинопортал «Кинопоиск. ру», интернет-магазин Wildberries.ru, доска объявлений Avito.ru, портал госуслуг Gosuslugi.ru. Заметим, первый и второй начинали очень скромно, и ничто не говорило о том, что они завоюют первенство каждый в своем направлении.

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

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

Оговоримся, что высокие нагрузки возникают как по естественным причинам, так и вследствие злого умысла; о втором случае – DDoS-атаках – мы подробнее поговорим в третьей и четвертой частях главы. Посещаемость площадки может подскочить благодаря удачным мерам интернет-маркетинга, например «посеву» вирусного видео на YouTube, благодаря целенаправленной продуманной рекламе и органическому росту бизнеса. Распространено также явление, в Рунете известное как «хабраэффект»: неоднократно случалось, что в популярном сообществе IT-профессионалов «Хабрахабр» публиковалась ссылка на интересный его аудитории сайт, ввиду чего за короткий промежуток времени совершались сотни и тысячи переходов по ней. Ниже мы разберемся прежде всего с органическим ростом аудитории и с тем, как к нему лучше подготовиться.

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

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

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

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

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

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

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


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

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

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

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

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

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

Чтобы быть в курсе тенденций в области высоких нагрузок, веб-разработчикам настоятельно рекомендуется посещать профильные конференции или, как минимум, изучать в Сети видеозаписи сделанных на них докладов. Следите за датами проведения Highload++ (http://www.highload.ru/), DevCon (http://www.msdevcon.ru/), «Российские интернет-технологии» (http://ritconf.ru). Для специалистов также может оказаться полезной «прокачка» в технопарке Mail.ru при МГТУ им. Н.Э. Баумана (http://tp.mail.ru/).

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

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

Большей частью мы говорим о DDoS-атаках, которые у интернет-бизнесменов на устах. Но нельзя забывать и об их «прародителе» – DoS-атаках. Почему аббревиатура на одну букву D меньше? Эта D означает не что иное, как distributed – «распределенная». Стало быть, мы говорим о потоке запросов, которые валятся на ваш сервер не из разных точек, а с определенного интернет-адреса. Впрочем, и с DoS можно хлебнуть лиха, хотя одолеть его проще. Но если для вашего сайта не продуманы меры обороны, то и тривиальный «флуд» – бомбардировка веб-сервера потоком однотипных пакетов информации – грозит «опрокинуть» его.

Мы вплотную подступили к важнейшему (после методов обороны, о них чуть позже) вопросу: «Кому это выгодно?» И ответ фактически был дан в предыдущем абзаце: в большинстве случаев – тем, кому сайт поперек горла. Расценки на DDoS-атаки неуклонно снижаются, а организаторы таких черных дел зачастую не стесняются открыто рекламировать свои услуги в Сети, так что послать «луч ненависти» более удачливому конкуренту по карману многим. Реже в амплуа мстителей выступают уволенные сотрудники компании, которой принадлежит площадка, «рассерженные потребители» и другие персоны, имеющие личностно-бытовые поводы испортить жизнь владельцам сайта.

Кроме того, даже если в вашей индустрии не принято в столь грубой форме выяснять отношения и с конкурентами у вас негласный договор о ненападении, вы не застрахованы от DDoS. Хозяева ботнетов (дидосеры) имеют неприятную привычку разминать мускулы и когда ради демонстрации силы, когда ради рекламы своих услуг тренироваться на объектах, которые выбирают по самым прихотливым критериям. Например, ткнув пальцем в одну из первых трех строчек выдачи «Яндекса» по запросу «интернет-магазин посуды». Какое-то время назад популярнейшей мишенью был сайт шоу «Дом-2». А поскольку в 2012–2013 годах возникло огромное количество зомби-сетей микроформата, порой даже из 2–3 тысяч инфицированных компьютеров (крупные ботнеты включают десятки и сотни тысяч), и владеют и помыкают ими подчас едва ли не школьники, то в их взбесившийся прицел может попасть какой угодно, даже самый безобидный, сайт.

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

Не всегда организаторы DDoS-атак – «сетевые гопники». По поведению – бесспорно (сам метод априори разбойный), но, к сожалению, эту порочную стезю нередко избирают деятели технически подкованные, которые подходят к процессу творчески, с выдумкой. С каждым годом распределенные кибератаки становятся все более изощренными, и эксперты по IT-безопасности регулярно расширяют их и без того разветвленную классификацию. Методы и цели у DDoS-атак разнятся в широчайшем диапазоне. В частности, «долбить» могут как сам сайт, отдельные его страницы, так и напрямую сетевое оборудование на стороне провайдера (например, роутер), особенно когда злоумышленник осведомлен о техническом оснащении хостера. Гарантированно от атаки не защищен ни один интернет-протокол, по которому осуществляется обмен данными между узлами Веба: HTTP, DNS, UDP, TPC и т. д.

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

Что же нужно сделать, чтобы обезопасить себя от DDoS-атак, насколько только возможно в современных условиях?

• Учесть риски на стадии разработки архитектуры. Как точно сформулировал руководитель компании «Онтико» Олег Бунин в программе «Рунетология», «ваш сайт должен быть спрограммирован таким образом, чтобы не замечать DDoS». С одной стороны, это все-таки утопия, с другой – действительно можно сделать так, чтобы мелкие и средние атаки проходили для площадки наименее болезненно. Например, одна из уязвимостей уровня архитектуры – слабая продуманность в работе с процедурой SSL handshake, которая сильно нагружает процессор; грубо говоря, это взаимное «обнюхивание» клиента и сервера, требующее шифрования данных. Если ваш веб-сервер не оптимизирован с расчетом на сокращение числа таких операций, в эту слабую точку будет чрезвычайно соблазнительно ударить киберпреступникам. И таких слабых мест может быть вагон и маленькая тележка.

Чрезвычайно полезно проводить учебные нагрузочные тестирования, с тем чтобы проверить, как сайт держится под наплывом трафика того или иного типа. Из подобных инструментов популярны в профессиональном сообществе Load Impact (http://loadimpact.com/) и Tsung (http://tsung.erlang-projects.org). С их помощью вы заранее выявите узкие места в своем проекте, что полезно не только в аспекте профилактики DDoS-конфузов.

Александр Лямин, руководитель компании HighloadLab, советует: «Обязательно нужно иметь запас производительности приложения, как минимум двукратный от его маршевой нагрузки». И он глубоко прав. Рекомендация касается как архитектуры, так и площадки, на которой развернут сайт (см. ниже).

• Выбрать клиентоориентированный «ударостойкий» хостинг. Часто дидосер попросту заполняет до отказа мусорным трафиком доступный проекту канал, что характерно, например, для атак на DNS-серверы сайта. Бывает, забивают пустыми запросами не только входящую, но и исходящую полосу, что, само собой, вдвойне неприятно хостинг-компании.

Хоть сколько-нибудь серьезные хостеры используют межсетевые экраны (файерволы) – программные или программно-аппаратные комплексы, способные гасить DDoS-атаки, фильтруя трафик по сложным правилам. Непременно уточняйте, входит ли такая оборона в плату по тарифу, и если нет, то сколько стоит.

Будьте требовательны к хостеру, но не жадничайте. Если ваш сайт «крутится» на одном виртуальном хостинге еще с несколькими десятками площадок, а то и сотней, то удар по вашему проекту затронет и их. Дабы обезопасить ваших ни в чем не виноватых соседей, в случае сильной DDoS-атаки провайдер, скорее всего, заблокирует доступ к вашему ресурсу. Лучше разоритесь на выделенный хостинг.

Широко разрекламированный как «антидидосерский», SaaS-хостинг не панацея: да, при лавинообразном росте входящего трафика на вашем сайте вам будут автоматически выделяться все новые и новые мощности, сайт может и не рухнуть. Однако если заказчик атаки и хозяин ботнета настроены серьезно, они усилят напор, и оборона, основанная на количественном принципе, влетит вам в копеечку. Значит, ваши недруги не мытьем, так катаньем добьются, чего хотели.

Серьезному, поставившему себя на твердую ногу веб-проекту, экономическая база которого зависит от его устойчивости, следует обеспечить себе подключение сразу к нескольким провайдерам по каналам пропускной способностью не менее 10 Гбит/c каждый (такова рекомендация компании «Лаборатория Касперского»).

• Следить за своим серверным хозяйством. Вовремя обновляйте все модули, проверяйте правильность конфигураций, чтобы не открывать своими же руками лазейку злоумышленникам. Инсталлируйте все патчи – «заплатки» на программное обеспечение. Регулярно изучайте серверные логи. Уделите внимание и настройкам операционной системы, под управлением которой работает машина (обычно имеет смысл увеличение объема памяти, доступной TCP-стеку, и т. д.).

От DoS-атак – несравненно более слабых, чем DDoS, – способны когда частично, а когда и полностью предохранить правильные серверные настройки: ограничение числа открытых портов, лимит на количество соединений с одного адреса, на объем передаваемого за единицу времени трафика с одного IP-адреса или из одной сети. Однако в случае с DDoS нужны гораздо более серьезные меры противодействия.

Часто ботнеты имеют географическую привязку: большая часть входящих в них компьютеров находится в каком-то одном регионе мира. Едва ли у вас в «мирное время» много посетителей из Индонезии и Уругвая, так что если большинство атакующих адресов расположено в такой экзотической стране, можно временно поставить блокировку на трафик из нее. Вяленький DDoS таким манером вы с высокой степенью вероятности ослабите в достаточной степени, чтобы хотя бы глубоко вдохнуть и развернуть полноформатную обороту. Для DoS-атак по понятным причинам бывает достаточно точечной блокировки конкретных IP.

Небесполезны методы маскировки подлинного IP-адреса сайта. Перед совсем уж недалекими киберпреступниками эти меры поставят серьезную преграду.

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

• Озаботиться аппаратной защитой. Если у вас по-настоящему крупный и заметный на рынке проект, то в обязательном порядке. Производители телекоммуникационного оборудования (в первую очередь упомянем Cisco и HP / 3Com) выпускают целые аппаратные комплексы, предназначение которых – блокировать кибератаки разных категорий. Впрочем, нужно еще учесть, что, скажем, в 2013 году в Рунете участились атаки на уровне веб-приложений, которые сравнительно легко проходят аппаратные фильтры, поскольку умело имитируют «поведение» обычных пользовательских браузеров.

Есть ультрамощные решения, прямо-таки «крепостные валы», и особенно популярно предлагаемое Arbor Networks, но их может позволить себе не каждый хостинг-провайдер: цена вопроса – в районе миллиона долларов, как минимум – в несколько сотен тысяч.

• Убедиться в том, что всегда имеете черный ход для удаленной перезагрузки сервера и для перевода управлениям им по SSH-протоколу на другой IP-адрес. Эту деталь нужно проговаривать до того, как заключать договор с хостинг-провайдером. Кроме того, в расчете на критические ситуации многие хостеры предлагают услугу прямого доступа к серверу IP-KVM.

• Заранее договориться с профессиональными защитниками от DDoS. Возможно, установить превентивную стороннюю защиту. Из числа заслуживающих доверия, по нашему мнению, порекомендуем сервисы Qrator (http://qrator.net), DDoS-Protection.ru (http://ddos-protection.ru), Kaspersky DDoS Prevention (http://www.kaspersky.ru/ddos-prevention/). У большинства из них имеются терпимые тарифы на абонентское обслуживание малого и среднего бизнеса. При соблюдении базовых предосторожностей не помешает заручиться и такой поддержкой.

Особняком стоят CDN-сервисы (англ. content delivery networks – «сети доставки контента»), рассчитанные не только на ускорение работы сайта в разных точках мира, но и в том числе на оборону против простых DDoS-атак. Например, CloudFlare (https://ru.cloudflare.com). По существу, он представляет собой CDN-прокси, который пропускает через себя трафик на подступах к вашему сайту.