Высоконагруженные проекты

Что считать высоконагруженным проектом?

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

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

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

Какие важные критерии учитываются при проектировании высоконагруженного проекта?

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

• Второй критерий – специфика проекта. Как часто и кем обновляется информация? Как много информации будет одновременно находиться в системе? Структурирована она или нет? Устаревает ли она? Какие основные типы запросов? Нужен ли полнотекстовый поиск? Аудитория – живые люди, автоматизированные внешние системы или и то и другое? И многие другие вопросы, на которые нужно понять ответ и сделать выводы.

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

Есть ли «стандартные наборы» архитектуры и платформ для highload проектов или всё подбираются индивидуально?

Технологии подбираются индивидуально, но некоторые «связки», которые чаще используются вместе, чем остальные, все же существуют. Например это LAMP или стеки технологий от Microsoft и Oracle. Но, как известно, не смотря на то, что встретить в природе их можно чаще, все они относятся к «тривиальным» решениям и требуют постоянной частичной или кардинальной переработки при росте проекта.

Какие способы и приемы снижения нагрузок самые эффективные для высоконагруженных проектов?

Способов всего три: распределение, кэширование и откладывание на потом. На основе их комбинации строятся основные используемые на практике решения.

Как определить, является ли масштабируемая архитектура проекта залогом его успеха или пустой тратой сил и времени?

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

• Но лучше здесь отталкиваться от типа проекта:

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

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

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

• Технологические проекты: основанные на техническом ноу-хау проекты напрямую от него и зависят, как правило уже при проектировании самой "изюминки" проекта становится понятно какая архитектура для него больше подходит и как её развивать в дальнейшем.

Когда нужно начать задумываться о масштабируемости проекта?

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

• В качестве общей рекомендации стоит сказать, что будущие коллеги всегда имеют больше шансов определить уровень кандидата, чем любой HR-специалист, так что по возможности именно они должны проводить собеседование (по крайней мере задавать вопросы и оценивать адекватность ответов).

• Давайте пройдемся по основным позициям и рассмотрим на что стоит обратить внимание при найме:

• Лицо принимающее технические решения (ЛПТР): официально такого человека в зависимости от ситуации могли бы обозначить как "технически директор", "системный архитектор", "начальник отдела/департамента разработки", "ИТ-менеджер", "тим лид", просто "программист" - суть от этого не меняется. Это тот человек, который собственно будет отвечать за то, как будет [технически] выглядеть проект в дальнейшем, он может даже и не быть начальником, а просто говорить "вот так надо", а начальник, ничего толком не понимая, со всем соглашаться - даже такое бывает. От него будет зависеть архитектура проекта, план развития, выбор технологий, масштабируемость, отказоустойчивость и безопасность, а также многое и многое другое. Не всегда заранее понятно кто в команде окажется в итоге этим человеком, но руководству компании очень желательно как можно раньше его выявить (желательно до найма) и максимально пристально обратить на него внимание. К нему стоит относиться как к юристу - проверить именно знания и навыки достаточно сложно, а вот ознакомиться с его историей, прошлыми проектами, мнением о нем коллег и просто других профессионалов в отрасли необходимо в любом случае. Посмотреть его в деле можно обсуждая виртуальные (придуманные) проекты с конкретными особенностями, ограничениями и проблемами; нужно просить кандидата порассуждать вслух о возможных вариантах решения трудностей, в чем преимущества каждого их них, каким он отдал бы предпочтения и почему.

• Разработчики: их принято делить на клиентских и серверных.

  • Серверный разработчик обычно отвечает в первую очередь бизнес-логику проекта, во вторую - за генерацию шаблонов, взаимодействие с СУБД, обработку файлов и многое другое, что могут на него повесить. Так или иначе его роль заключается (но не ограничивается) в написании кода проекта на одном из языков программирования (в большинстве проектов на серверной стороне используется один ЯП, реже - два, и совсем редко - больше). Помимо кода он отвечает за выбор деталей реализации проекта: алгоритмов, библиотек, вспомогательных инструментов и пр. Из всего этого напрямую следует процесс его найма: нужно просить писать код и обсуждать алгоритмы, библиотеки, базы данных, шаблонизаторы и т.п. тоже на примере вымышленных ситуаций. Прямо на собеседовании код лучше писать не на компьютере (бумага, маркерная доска, печатная машинка), а также можно попросить посмотреть написанный им старый код и проверить на адекватность читабельность и соответствие общепринятым стандартам (это лучше доверить его будущему коллеге по возможности).

  • Клиентский разработчик занимается всем тем, что происходит в браузере пользователя. Уклон бывает в две стороны: внешний вид (верстальщик, HTML+CSS) и динамика (JavaScript разработчик). На собеседовании также основное внимание стоит уделять коду, плюс принципам работы браузера и особенностям основных реализаций и их версий. Для верстальщика стоит попросить несколько примеров работы и проверить на валидность и кроссбраузерность, для обоих проверок существуют автоматизированные сервисы, но и глазами посмотреть тоже стоит на предмет читабельности и по возможности отсутствия неудачных решений (табличная верстка, стили внутри HTML, отсутствие семантики). С JavaScript разработчиками стоит обсудить опыт работы с различными библиотеками, понимание основных событий, происходящих внутри браузере, принципы организации кода, полезным навыком будет опыт организации навигации без перезагрузок страницы и постоянного поддержания с сервером для обновлений страницы в реальном времени.

• Системные администраторы: как ни странно, они тоже должны уметь программировать, так как при соотношении серверов к сисадминам больше чем 1 к 3 ключевую роль в их работе начинает играть автоматизация. Обычно это самое основное на что стоит обратить внимание на собеседовании: обсудить с какими подходами к автоматизации в системном администрировании кандидат знаком, что предпочитает, попросить написать пару-тройку скриптов (обычно на bash, Python или Ruby, хотя это не так важно) для параллельного выполнения каких-то действий на кластере из >100 серверов. Вторая по важности тема, пожалуй, мониторинг и реагирование в случае проблем. Собственно понимание серверных операционных систем и основных сетевых протоколов также должно быть на очень высоком уровне, причем желательно чтобы человек мог объяснить все это так, чтобы даже не технарю все стало понятно.

• Тестировщики: бывает три основных типа тестирования, применительно к интернет-проектам и, соответственно, три типа тестировщиков.

  • Автоматическое тестирование кода - по сути своей работы и требованиям очень похож на серверного разработчика, разница в том, необходимо понимание основных типов тестирования и сопутствующих инструментов. На собеседовании, естественно, стоит спрашивать как кандидат протестировал бы ту или иную часть (воображаемого) проекта, порой бывает интересно пообсуждать тестирование внутри браузера посредством Selenium или аналогов.

  • Нагрузочное тестирование - проверка поведения сайта в целом при определенном уровне нагрузки (потоке входящих пользовательских запросов). Кандидат должен понимать как максимально точно воспроизвести поведение пользователей в системе, предложить варианты сбора данных и построения на их основе сценариев, уметь определять узкие места в системе, те, которые являются причиной неполадок.

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

  • Какие нужны специалисты для разработки высоконагруженного проекта и как их выбирать?

    • На самом деле какого-то особого секрета, который непременно нужно знать, здесь нет.

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

• Как устроены и работают основные веб-протоколы, как минимум TCP/IP, HTTP, SSL, DNS, остальные менее важны.

• Основные принципы работы браузеров, особенности основных пяти и их версий, HTML, CSS, JavaScript, "водопад" загрузки ресурсов, процесс отрисовки страниц, AJAX.

• Новые стандарты и возможности, которые обычно называют HTML5 (WebSockets, History API, различные варианты хранения данных на клиенте и др.) - как минимум быть в курсе их существования и понимать в каких случаях целесообразно их использовать.

• Серверные операционные системы: минимальными навыками работы с Linux и общим представлении о схеме их работы стоит обладать даже клиентским разработчикам и верстальщики, если человек знаком только с Windows - это тревожный знак. Процессы, потоки, сигналы, файловые системы и основные демоны.

• Базы данных - это тема уже более узкая и не нужна совсем всем, но понимать как они работают, какие бывают основные типы, их преимущества и недостатки определенно стоит. Аббревиатуры CAP и ACID должны что-то говорить.

• Основные принципы масштабируемости (распределение работы, кэширование, отложенные задачи), отказоустойчивости (единственные точки отказа, DDoS, сбои оборудования) и сетевой (без)опасности (инъекции, XSS, уязвимости ПО, человеческий фактор и др.). Особенности, варианты реализации, готовые решения.