Insight IT

Вакансии: команда Python разработчиков в EVAplacer

Иван Блинков — Fri, 08 Feb 2013 10:20:00 +0400

Вакансии более не актуальны

Новая международная геоинформационная социальная сеть EVAplacer набирает команду разработчиков.

Ведущий разработчик серверной части на Python

Задачи

Разработка серверной части проекта на Python
Проектирование архитектуры системы и схемы базы данных
Организация взаимодействия серверной части проекта с клиентской
Принятие технических решений

Требования

Свежий опыт веб-разработки на Python без использования Django
Суммарный опыт веб-разработки от 5 лет
Самостоятельность и заинтересованность в качестве результата своей работы
Умение делегировать часть работы коллегам

Технологии

Предстоит работать со следующими технологиями:
- Flask + Jinja2
- MongoDB + Solr + memcached
- ZeroMQ
Опыт работы именно с ними очень желателен, но не обязателен

Зарплата

В диапазоне 100-150 тысяч рублей в месяц в зависимости от опыта

Клиентский разработчик

Задачи

Разработка клиентской части проекта
Работа на стыке с серверной частью (Python), создание HTML и других шаблонов на Jinja2
Оптимизация скорости загрузки страниц
Принятие технических решений по клиентской части

Требования

Опыт разработки на JavaScript/CoffeeScript и валидной верстки на HTML5
Понимание основных принципов клиентской оптимизации
Суммарный опыт веб-разработки от 3 лет
Усидчивость, самостоятельность и заинтересованность в качестве результата своей работы

Технологии

Предстоит работать со следующими технологиями:
- Jinja2 + webassets
- CoffeeScript + SASS
- Twitter Bootstrap
- jQuery
- Leaflet
Опыт работы именно с ними очень желателен, но не обязателен

Зарплата

В диапазоне 60-100 тысяч рублей в месяц в зависимости от опыта

Специалист по тестированию

Задачи

Основные:
- Разработка автоматических тестов для серверной части проекта на Python
- Регрессионное тестирование сайта с помощью Selenium или альтернатив
Дополнительные:
- Нагрузочное тестирование с использованием JMeter или альтернатив
- Ручное визуальное тестирование, в т.ч. на кроссбраузерность

Требования

Свежий опыт тестирования интернет-проектов, желательно на Python
Суммарный опыт в тестировании от 3 лет
Внимательность, самостоятельность и заинтересованность в качестве результата работы команды

Зарплата

В диапазоне 50-100 тысяч рублей в месяц в зависимости от опыта

Условия

Премии по достижении ключевых вех проекта
Офис в центре Москвы (м. Охотный ряд, меньше 5 минут пешком)
Работа на MacBook Pro

Вакансии более не актуальны

Вакансии: команда IT-звезд

Иван Блинков — Fri, 04 May 2012 18:20:00 +0400

Вакансии более не актуальны

Благодаря сайту Insight IT, компания RDM-Soft нашла ОТЛИЧНОГО тимлида! Теперь, тимлидер ищет в свою команду единомышленников и просто IT-звезд.

О компании

История компании началась в 2003 году. С этого момента выпущено много проектов. Некоторыми из них Вы, возможно, так или иначе пользовались. Сейчас запускается еще один проект: SEO-биржа. У Вас есть прекрасная возможность оказаться у истоков будущего хита!

Кто нужен?

Mr. Backend. Он же программист. (вакансия закрыта)
Мастер-ломастер. Он же инженер по контролю качества, проще говоря тестер.
Dr. Frontend. Он же фронтендщик. (вакансия закрыта)

Mr. Backend

Требования

Отличные знания: PHP, ООП, SQL, MVC, ZendFramework (либо альтернатив), Linux.
Опыт работы по специальности: от 3 лет.
Опыт работы в команде.
Желание развиваться и изучать новое.
Отсутствие желания искать работу в ближайшие 3 года.

Задачи

Разработка серверной части проекта. Включает в себя :
- бухгалтерия;
- бизнес-логика;
- статистика;
- различные парсеры.

Мастер-Ломастер (SQA)

Требования

Хорошие знания: PHP, SQL, Linux.
Отличные знания принципов whitebox и blackbox тестирования.
Опыт работы по специальности: от 2 лет.
Опыт работы в команде.
Желание развиваться и изучать новое.
Отсутствие желания искать работу в ближайшие 3 года.

Задачи

Написание юнит-тестов, автотестов.
Тестирование:
- бекенда;
- фронтенда;
- бизнес-логики;
- производительности;
- безопасности.
В общем, тоже очень много интересной работы.

Dr. Frontend

Требования

Понимание, как сделать интерфейс удобным и приятным для пользователя
Отличные знания: HTML, CSS, JavaScript (jQuery, ExtJS или других распространенных библиотек)
Опыт проектирования и реализации пользовательского интерфейса

Задачи

Прототипирование UI сервиса
Реализация спроектированного UI
Разработка расширений для Firefox и Chrome.

Условия

Удаленная работа.
Работа в профессиональной команде.
Полный рабочий день (5 дней в неделю по 8 часов).
Карьерный и профессиональный рост.
Прислушивание к Вашему мнению.
Зарплата по результатам собеседования:
- Mr. Backend: от $1500 до $2000
- Мастер-Ломастер: от $700 до $1500
- Dr. Frontend: от $1000 до $2000

Вакансии более не актуальны

Клиентская часть интерактивного сайта

Иван Блинков — Fri, 06 Apr 2012 21:17:00 +0400

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

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

Организация кода

Сборка

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

На вопрос "Какую систему сборки использовать?" в большинстве случаев правильный ответ: ту же, что и для сборки серверной части. Make, rake, maven, ant, rebar... - любому из них без труда можно поручить эту задачу. Для конкатенации можно использовать хоть консольную команду >>, для минимизации есть много альтернативных библиотек, в порядке моих симпатий:

Если хочется чего-то более гибкого, могу порекомендовать воспользоваться Webassets, который я уже упоминал в статье про Jinja2. В консольном режиме прекрасно подключается к любой системе сборки и языку программирования. Описать процесс сборки JavaScript и CSS можно очень подробно и именно так, как считаете нужным, естественно на Python. Сопоставимый по возможностям проект из мира Ruby - Asset Packager, наверняка есть много других.

Читабельный код

Не знаю как Вы, а я тихо ненавижу JavaScript все ~10 лет, которые я с ним знаком. Так как он по сути является монополией на рынке браузерных приложений (Flash, Java апплеты и ActiveX за альтернативы можно даже не считать), использовать его так или иначе приходится в любом сколько-либо серьезном интернет-проекте. Даже Google Dart вряд ли всерьез приживется.

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

Если Вас тоже не раз посещали подобные мысли, то Вы вероятно как и я при первой же возможности пересядете (или уже пересели) на CoffeeScript, компилируемый в JavaScript язык программирования. Немного рекламы этого проекта:

Золотое правило CoffeeScript: "It's just Javascript" (это просто JavaScript)
Прямое преобразование кода в JavaScript
Доступны абсолютно все JavaScript-библиотеки
Никаких точек с запятой в конце каждой строки
Структурирование кода на основе отступов, как в Python
Объявление функций просто стрелочкой ->
При вызове методов даже скобки писать не обязательно

Человеческое наследование: простое class MyClass extends MyParent превращается в довольно хитрую конструкцию с использованием прототипов и замыканий:

MMyClass = (function() {
    __extends(MyClass, MyParent);
    function MyClass() {
        MyClass.__super__.constructor.apply(this,
            arguments);
    }
    MyClass.prototype.initialize = function() {};
    return MyClass;
})();

Много укороченных команд ветвления кода (if, switch, циклы и т.п.)
В целом код выходит раза в полтора-два короче и намного приятнее для глаз
Консольный компилятор с функцией наблюдения за директориями
Легко подключается как фильтр в Webassets
Подробнее с примерами на официальном сайте
В общем рекомендую :)

Логическое разделение кода

Если Вы сталкивались со сколько-либо сложным пользовательским интерфейсом "на jQuery", то скорее всего не по наслышке понимаете откуда взялось выражение "спагетти-код". В связи с событийной парадигмой разработки браузерных приложений, очень часто JavaScript-код с использованием jQuery или альтернатив превращается в так называемый "коллбек на коллбеке, коллбеком погоняет" (коллбек - транслит от английского callback - обработчик события). При отсутствии четкой структуры такой код становится очень сложно поддерживать при его увеличении в объемах. Но это не повод отказываться от jQuery - от событий никуда не деться, и эта библиотека отлично справляется с абстракций от особенностей их реализации в различных браузерах.

На мой взгляд, одним из наиболее резонных способов решения (или заблаговременного предотвращения) этой проблемы является использование в разумных пределах объектно-ориентированные возможности JavaScript (благо CoffeeScript это дело сильно упрощает). Соответственно, используемые классы можно разумно располагать в какой-то иерархии с точки зрения наследования (для обеспечения DRY, don't repeat yourself - "не повторяйся") и с точки зрения расположения в файловой системе (с разложенными по папкам файлами работать намного проще, чем с здоровенной вереницей обработчиков событий в одном файле).

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

Модель (Model) - как и в традиционном MVC представляет собой класс, объект которого содержит локальную копию каких-то данных и предоставляет механизмы для её синхронизации с внешним хранилищем. Основное отличие от серверных моделей - хранилищем выступает не СУБД, а либо локальное хранилище браузера через HTML5, либо удаленный сервис через REST или другой интерфейс. Плюс так как они находятся вне "зоны доверия", то полученные от них данные нужно обязательно валидировать, фильтровать и проверять на серверной стороне, прежде чем что-либо с ними делать.
Представление (View) или контроллер (Controller) - тут, по моим впечатлениям, образовалась путаница и за обоими названиями в нашем контексте имеют ввиду примерно одно и то же. Объект такого класса следит за изменениями и событиями в связанных с ним моделях и элементах DOM, каким-либо образом на них реагируя. Таким образом большая часть кода, которая раньше была "вереницей обработчиков событий", оказывается методами этого класса. При этом базовый класс из библиотеки берет на себя нормальное поведение this и следит за тем, чтобы обработчики автоматически добавлялись на динамические созданные элементы DOM.
Маршрутизатор (Router) - следит за состоянием адресной строки и позволяет обрабатывать изменения, понадобится для восстановления поведения браузера.
Коллекция (Collection) - отсортированный набор однотипных моделей, с которым можно работать как с единым целым.

Не стоит рассматривать эти абстракций как единственный верный способ делать клиентские приложения, но при их использовании появляется хоть какая-то логика и становится более-менее понятно где какой кусок кода должен находиться и где его потом искать. Для абстракции особенностей реализаций браузеров они по-прежнему полагаются на $ в виде jQuery или Zepto.

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

Backbone.js - самая широко распространенная из трех, используется во многих серьезных проектах. Основана на библиотеке Underscore.js, которая с одной стороны предоставляет массу удобных функций и шаблонизатор, но с другой стороны - не особо-то и часто они оказываются нужны.
Spine.js - библиотека по-моложе, которая очень похожа на Backbone.js, но написана на CoffeeScript и из-за отсутствия внешних зависимостей вышла компактнее. Отличия в основном в терминологии и деталях реализации.
Knockout.js - эта библиотека пропагандирует использование data-* атрибутов из HTML5 для хранения метаданных, которые как-то управляют изменениями тегов-владельцев при определенных событиях, практически забирая на себя роль представления. Концепция кажется мне мутноватой, так что лично для себя я её использование всерьез и не рассматривал никогда.

Когда в этой статье дело будет доходить до примеров кода, я буду приводить их на основе Backbone.js, так как в свое время я остановился именно на ней. Почему? В основном из-за того, что она используется в очень многих проектах и стоит за ней целая компания, а не просто один разработчик, которому однажды может надоесть поддерживать проект (как в случае с Spine.js). Но в глубине души я, конечно, надеюсь, что однажды они уберут эту жесткую зависимость от Underscore.js, а то и может быть тоже перепишут все на CoffeeScript.

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

Обработчики событий

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

Напомню, то, что раньше было просто независимым обработчиком событий становится методом представления (по терминологии Backbone.js). У каждого представления создается "оглавление" методов-обработчиков в атрибуте events. Наверное многим хотелось бы увидеть какой-то пример кода, но так как статьями с примерами примитивных приложений на Backbone.js пестрит весь Интернет, тратить на это время желания совершенно никакого, сошлюсь на самый популярный: список задач TODO, для сравнения то же самое на Spine.js. К слову, при использовании CoffeeScript использовать стандартный механизм Backbone.****.extend({ ... }) не обязательно, class MyClass extends Backbone.**** прекрасно делает то же самое.

По мне, так намного интереснее не какие именно события обрабатываются (все равно 90% уникальны для проекта), а как их распределить по разным представлениям. Обычно получается что-то в этом духе:

Пользовательское представление будет модифицировать страницу в тех местах, где оно как-то связано с текущим пользователем: форма авторизации, надпись "Привет, ****!", кнопка выхода и пр. Вероятно, оно будет использовать модель текущего пользователя или в тривиальных случаях просто самостоятельно работать с cookie сессии.
Классы модели и представления, а вероятно и коллекции, понадобятся каждой логической сущности, которая каким-либо образом отражается в пользовательском интерфейсе. Это может быть что угодно, например задача в TODO-списке, статья, комментарий - все зависит от тематики проекта.
Если навигация по сайту каким-то образом динамически видоизменяется, то представление понадобится и для нее. Например, часто подсвечивают пункты в глобальной навигации на основе изменений в текущем адресе страницы.
И, последний пункт, который собственно и относится к сегодняшней теме - одно представление будет общим для всего сайта и будет отвечать за его интерактивность. Давайте его рассмотрим подробнее.

Для отсутствия перезагрузок браузера внутри сайта, нам нужно переопределить:

События клика на ссылки: по содержимому атрибута href нужно определить, что ссылка внутренняя и вызвать "цепную реакцию" в других представлениях, чтобы в итоге пользователь увидел то, что должен.
При отправке формы есть два сценария:
- Обновляется связанная модель и синхронизируется с сервером. В таком сценарии при необходимости можно вообще скрыть кнопку отправки и "автосохранять" изменения в модели.
- Связанной модели по каким-то причинам нет и нужно просто на основе данных формы что-то сделать, например выполнить поиск по указанной в форме фразе или отправить запрос на авторизацию.
Для отмены стандартной реакции браузера на события у jQuery есть два основных механизма: event.preventDefault() и return false. В данной ситуации (да и большинстве других), целесообразнее пользоваться последним, так как если вдруг в коде обработчика окажется какая-то ошибка, то пользователь просто увидит стандартную реакцию браузера, а не окажется в ситуации "некликающихся ссылок" и "неотправляющихся форм".

Восстановление поведения браузера

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

И первое, с чего стоит начать - с адресной строки, именно там должен появиться тот адрес, который был в href ссылки и action формы. Но на самом деле проще сказать, чем сделать:

Возможность просто полностью поменять текущий адрес в адресной строке из JavaScript без инициализации открытия страницы есть только в совсем свежих браузерах посредством HTML5 History API (pushState).
В старых браузерах переходы между внутренними страницами сайта можно эмулировать через изменения якоря ссылки, который в URL идет после # и обычно используется для "перелистывания" на середину HTML-документа. Для отслеживания таких изменений используется событие onhashchange.
В еще более старых браузерах это событие эмулируют разными трюками с iframe и setInterval.

Backbone.history.start() берет на себя абстракцию изменений в адресной строке, правда поддержку pushState нужно явно включить в аргументах. Заодно восстанавливается нормальное поведение кнопок "Назад" и "Вперед" в браузере.

Для обработки и создания событий, отражающихся в адресной строке, нужно сделать подкласс Backbone.Router. C ситуациями когда их имеет смысл создать несколько, я не сталкивался. По аналогии с серверными фреймворками в атрибуте routes задается соответствие паттернов адресов к методам-обработчикам, которые будут выполниться при переходе. В них вызываются необходимые изменения в коллекциях, моделях и представлениях, чтобы привести в нужное состояние текущий документ.

Для инициации "виртуального" перехода на новую внутреннюю страницу нужно вызвать метод navigate у нашего объекта-маршрутизатора, первым аргументом передав её адрес без первого /, а вторым - настройки:

trigger - вызывать ли обработчик из маршрутизатора?
replace - добавлять ли страницу, с которой мы уходим в историю браузера, чтобы можно было на нее вернуться при нажатии кнопки "назад"?

Таким образом, во внутренних ссылках мы используем нормальные относительные URL, начинающиеся с /. По ним будут нормально ходить роботы и браузеры без JavaScript. В обработчике кликов на них мы:

проверяем правда ли она внутренняя (начинается ли она с /);
"отменяем" стандартный переход, вернув false;
вызываем router.navigate(href.substring(1), {trigger: true}).

Осталась еще несколько атрибутов поведения браузера, которые необходимо починить, чтобы визуально все выглядело "как обычно":

Клик по ссылке с зажатым Shift должен открывать её в новом окне, а с зажатым Ctrl или при клике средней кнопкой мыши - в новой вкладке. Довольно не хитро делается на основе атрибутов объекта-события, который передает обработчику jQuery (button, shiftkey, metakey), для открытия окна или вкладки - window.open.
Если пользователь сделал какое-то действие, а прореагировать на него мгновенно не получается (так как что-то грузится, вероятно) - нужно включить курсор ожидания, установив в CSS cursor: wait, и, желательно, анимированный favicon.ico. И, соответственно, вернуть все как было, когда страница примет нужный вид. Для смены favicon до сих пор пользуюсь каким-то довольно старым плагином к jQuery, который не особо шикарно, но все же работает. Его сайт, видимо, накрылся, так что продублировал: https://gist.github.com/2320740, если кто знает более адекватные альтернативы - дайте знать в комментариях, пожалуйста, руки поискать все никак не доходят.

Синхронизация состояния

По-умолчанию Backbone.js предлагает хранить все состояние клиента в моделях и синхронизировать его с серверным посредством реализации простенького REST API на сервере (подробнее), к которому запросы отправляются посредством обычного $.ajax. Чтобы инициировать процесс нужно вручную вызвать у экземпляра модели метод fetch, чтобы обновить клиентское состояние данными с сервера, или метод save, для обратного процесса.

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

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

Эта статья - вторая в серии про Интерактивные сайты, автор - Иван Блинков, основано на личном опыте. До встречи на страницах Insight IT!

Архитектура Stack Exchange Network

Иван Блинков — Thu, 31 Mar 2011 16:05:00 +0400

Stack Exchange Network представляет собой сеть из 46 сайтов вопросов-ответов на совершенно разные темы от программирования до кулинарии. Проект вырос из известной в узких кругах тусовки программистов Stack Overflow, об архитектуре которой я уже рассказывал чуть больше года назад. Проект активно развивается и уже появилось приличное количество новой информации, которой я и спешу с Вами поделиться.

Статистика

95 миллионов просмотров страниц в месяц
800 HTTP запросов в секунду
180 DNS запросов в секунду
Загруженность интернет-канала в 55 Мбит/с
16 миллионов уникальных пользователей в месяц

Технологии

Разработка

C# - основной язык программирования
Visual Studio 2010 Team Suite - IDE
Microsoft ASP.NET 4.0 - framework
ASP.NET MVC 3 - web Framework
Razor - генератор шаблонов
jQuery 1.4.2 - JavaScript framework
LINQ to SQL и немного чистого SQL - доступ к данным
Mercurial и Kiln - контроль версий исходного кода
Beyond Compare 3 - инструмент для сравнения

Программное обеспечение

WISC стек получен условно-бесплатно с помощью BizSpark
Windows Server 2008 R2 x64 - основная операционная система
MS SQL Server 2008 R2 на Windows Server 2008 Enterprise Edition x64 - база данных
Ubuntu Server
CentOS
IIS 7.0 - веб-сервер
HAProxy - балансировка нагрузки
Redis - используется как распределенная система кэширования
CruiseControl.NET - сборки и автоматическая система развертывания кода
Lucene.NET - полнотекстовый поиск
Bacula - резервное копирование
Nagios (с плагинами n2rrd и drraw) для мониторинга
Splunk - сбор и агрегация логов
SQL Monitor от Red Gate - мониторинг SQL Server
Bind - DNS
DotNetOpenId - реализация OpenID на .NET
WMD - текстовый редактор
Prettify - подсветка синтаксиса
MarkdownSharp - обработчик разметки Markdown на C#
Flot - построение графиков на JavaScript

Внешние сервисы

reCAPTCHA - защита от спама
Google Analytics - веб-аналитика
Kiln - Mercurial хостинг
Pingdom - внешний мониторинг и уведомления
CDN не используется, его роль выполняет sstatic.net, отдельный домен для статичных файлов SEN без cookie

Оборудование

Датацентры

1 стойка в Peak Internet, штат Орегон (чат и обнаружение данных)
2 стойки в Peer 1, Нью-Йорк (остальная часть SEN)

Серверы

10 веб-серверов:
- Dell R610
- 1x Intel Xeon Processor E5640 @ 2.66 GHz
- 16 GB RAM
- Windows Server 2008 R2
- IIS
2 сервера баз данных:
- Dell R710
- 2x Intel Xeon Processor X5680 @ 3.33 GHz
- 64 GB RAM
- 8 жестких дисков
- MS SQL Server 2008 R2
2 виртуальных сервера для балансировки нагрузки:
- 1x Intel Xeon Processor E5640 @ 2.66 GHz
- 4 GB RAM
- Ubuntu Server
- HAProxy
2 сервера для кэша:
- Dell R610
- 2x Intel Xeon Processor E5640 @ 2.66 GHz
- 16 GB RAM
- CentOS
- Redis
1 сервер для резервного копирования:
- Dell R610
- 1x Intel Xeon Processor E5640 @ 2.66 GHz
- 32 GB RAM
- Linux
- Bacula
1 сервер для мониторинга, управления и сбора логов:
- Dell R610
- 1x Intel Xeon Processor E5640 @ 2.66 GHz
- 32 GB RAM
- Linux
- Nagios
2 сервера для виртуализации:
- Dell R610
- 1x Intel Xeon Processor E5640 @ 2.66 GHz
- 16 GB RAM
- VMWare ESXi

Сетевое оборудование

2 маршрутизатора на Linux
5 свитчей Dell PowerConnect

Прочее

Rovio - маленький робот, позволяющий удаленным разработчиком посетить офис "виртуально"

Команда

14 разработчиков
2 системных администратора

Что нового?

HAProxy стал использоваться вместо Windows NLB так как HAProxy является быстрым, нересурсоемким, бесплатным решением, которое работает. Полностью прозрачен для серверов, легче обслуживать по сравнению со старым решением, располагается на виртуальных машинах.
CDN не используется, так как даже "недорогие" решения обходятся в очень приличную сумму по сравнению с тем трафиком, который входит в тарифный план хостинг-провайдера. Самое дешевой решение CDN от Amazon обошлось бы как минимум на тысячу долларов в месяц дороже при текущем уровне использования трафика.
Резервное копирование на диски для быстрого восстановления и на кассеты для "истории".
Полнотекстный поиск в SQL Server плохо интегрируется, нестабилен и обладает низким качеством результатов, так что они перешли на Lucene.
Все сайты в SEN теперь работают на общей платформе: используется общее оборудование и программное обеспечение.
Проект разделен на разные сайты для разных ниш, чтобы полностью изолировать группы аудитории, специализирующиеся в каждой конкретной области.
Используется агрессивное кэширование, большинство страниц кэшируются в виде HTML для анонимных пользователей средствами IIS.
Используется три уровня кэширования: локальный, относящийся к каждому сайту и глобальный.
Локальный кэш доступен только для каждой пары сайт/сервер:
- Используется для уменьшения сетевых задержек, по сути просто через HttpRuntime.Cache.
- Содержит такие вещи как пользовательские сессии, будущие обновления счетчиков просмотров страниц.
- Располагается полностью в оперативной памяти веб-сервера.
Кэш сайта доступен для каждого сервера, обрабатывающий запрос к конкретному сайту:
- Большинство кэшируемых данных располагаются здесь.
- Располагается в Redis.
- Redis настолько быстр, что большую часть времени доступа к кэшу занимает передача данных по сети.
- Данные сжимаются перед отправкой в Redis, так как большинство данных являются строками и у них есть масса свободных вычислительных ресурсов.
- Использование процессорных ресурсов на серверах с Redis стремится к нулю.
Глобальный кэш является общим для всех серверов и сайтов:
- Личные сообщения, квоты по API и несколько других по-настоящему глобальных вещей располагаются здесь.
- Также используется Redis.
Большинство данных в кэше удаляются через заданный период времени (обычно в районе нескольких минут) и практически никогда явно не удаляются.
Когда требуется инвалидация кэша на уровне готовых страниц, используется система подписки внутри Redis для отправки сообщений в соответствующую часть системы кэширования.
Для системы ввода-вывода они выбрали Intel X25 SSD в RAID10. RAID решил многие вопросы с надежностью, а SSD показывают отличную производительностью по сравнению с FusionIO при существенно более низкой цене.
Стоимость лицензий используемых продуктов Microsoft составила бы 242 тысячи долларов. Но так как они используют программу BizSpark, им не пришлось платить большую часть этой суммы.
Сетевые карты от Broadcom заменяются на сетевые карты от Intel на основных production серверах. Это решило большинство проблем с потерями соединений, пакетов и таблицами ARP.

Источники информации

Спасибо за внимание! Для оперативного получения свежей информации о высоконагруженных интернет-проектах рекомендую подписаться на RSS.

Архитектура Stack Overflow

Иван Блинков — Fri, 08 Jan 2010 00:31:00 +0300

Stack Overflow является любимым многими программистами сайтом, где можно задать профессиональный вопрос и получить ответы от коллег. Этот проект был написан двумя никому не известными парнями, о которых никто никогда раньше не слышал. Хорошо, не совсем так. Stack Overflow был создан топовыми программистами и звездами блогосферы: Jeff Atwood и Joel Spolsky. В этом отношении Stack Overflow похож на ресторан, владельцами которого являются знаменитости. По оценкам Joel'а около 1/3 программистов всего мира использовали этот интернет-ресурс, так что должно быть он представляет собой что-то достаточно полезное и интересное.

Одним из ключевых моментов в истории Stack Overflow является использование вертикального масштабирования, как достаточно работоспособного решения достаточного большого класса проблем. Не смотря на то, что публика на сегодняшний день больше склоняется к подходу с использованием горизонтальным масштабирования и не-SQL баз данных.

Если Вы стремитесь к масштабу Google, у Вас нет другого выхода, как двигаться в направлении не-SQL. Но Stack Overflow - это не Google, ровно как и подавляющее большинство других сайтов. Когда Вы задумываетесь о возможных вариантов дизайна Вашего проекта, попробуйте учесть и историю Stack Overflow, она тоже имеет право на жизнь. В этот век многоядерных машин с большим объемом оперативной памяти и невероятными темпами развития методов параллельного программирования, вертикальное масштабирование все еще является жизнеспособной стратегией и не должна сразу же отбрасываться в сторону просто так как это теперь больше не модно. Возможно в один прекрасный день мы получим лучшее из обоих миров, но на сегодняшний момент перед нами лежит большой болезненный выбор стратегии масштабирования, от которого определенно зависит судьба Вашего проекта.

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

Перевод статьи, автор оригинала - Todd Hoff. Возможно будет еще один пост с менее формальной информацией на ту же тему.

Статистика

16 миллионов просмотров страниц в месяц
3 миллионов уникальных пользователей в месяц (для сравнения: Facebook насчитывает около 77 миллионов уникальных пользователей в месяц)
6 миллионов посещений в месяц
86% трафика приходит с Google
9 миллионов активных программистов во всем мире и 30% пользуются Stack Overflow
Более дешевые лицензии были получены через программу Microsoft BizSpark. Скорее всего они заплатили около 11000\$ за лицензии на ОС и MSSQL.

Стратегия монетизации: ненавязчивая реклама, вакансии, конференции DevDays, достижения других смежных ниш (Server Fault, Super User), разработка StackExchange и возможно каких-то других систем рейтингов для программистов.

Платформа

Microsoft ASP.NET MVC
SQL Server 2008
C#
Visual Studio 2008 Team Suite
jQuery
LINQ to SQL
Subversion
Beyond Compare 3
VisualSVN 1.5
Веб уровень:
- 2 x Lenovo ThinkServer RS110 1U
- 4 ядра, 2.83 Ghz, 12 MB L2 cache
- 500 GB жесткие диски, зеркалирование RAID1
- 8 GB RAM
Уровень базы данных:
- 1 x Lenovo ThinkServer RD120 2U
- 8 ядер, 2.5 Ghz, 24 MB L2 cache
- 48 GB RAM
Четвертый сервер был добавлен для запуска superuser.com. Все сервера вместе обеспечивают работу Stack Overflow, Server Fault, и Super User.
QNAP TS-409U NAS для резервного копирования данных. Было принято решение не использовать "облачные" решения, так как вызванные ими дополнительные 5GB трафика ежедневно были бы накладными.
Сервера располагаются у Peak Internet. В основном из-за впечатляющей детализации технических ответов и разумных расценок.
Полнотекстный поиск в SQL Server активно используется для реализации поиска по сайту и выявления повторных вопросов. Lucene .NET рассматривается как достаточно заманчивая альтернатива.

Подводим итоги

Данный список является сборником уроков от Jeff и Joel, а также из комментариев к их записям:

Если Вы комфортно себя чувствуете в деле управления серверами - не бойтесь покупать их. Две основных проблемы с издержками аренды оборудования:
1. невероятные цены на дополнительную оперативную память и жесткие диски;
2. хостинг-провайдеры на самом деле не могут управлять чем-либо за Вас.
Делайте одноразовые более крупные инвестиции в оборудование, чтобы избежать быстро растущих ежемесячных издержек по аренде, которые окажутся более высокими в долгосрочном периоде.
Обновляйте сетевые драйвера. Производительность запросто может удвоиться.
Использование 48GB RAM требует обновления до MS Enterprise edition.
Оперативная память невероятно дешевая. Используйте возможности по её расширению по максимуму для получения практически бесплатной производительности. У Dell, например, переход от 4GB памяти до 128GB стоит всего 4378\$.
Stack Overflow скопировали ключевую часть структуры базы данных у Wikipedia. Это обернулось огромной ошибкой, для исправления которой потребуется большой и болезненный рефакторинг базы данных. Основным направлением изменений будет избавление от излишних операций по объединению данных в большом количестве ключевых запросов. Это ключевой урок, который стоит усвоить у гигантских много-терабайтных схем (вроде Google BigTable), которые полностью избавлены от операций объединения данных. Этот вопрос был достаточно важен для Stack Overflow, так как их база данных практически полностью располагается в оперативной памяти и операции join по прежнему требуют относительно много вычислительных ресурсов.
Производительность CPU оказывается на удивление важным фактором для серверов баз данных. Переход от 1.86 GHz, к 2.5 GHz, и к 3.5 GHz процессорам дает практически линейный прирост к времени выполнения типичных запросов. Исключение: запросы, которые затрагивают не только оперативную память.
Когда оборудование арендуется, обычно никто не платит за дополнительную оперативную память, если только вы не на помесячном контракте.
В 90% случаев наиболее узким местом является база данных.
При небольшом количестве серверов, ключевым компонентом издержек становится не место в стойках, электроэнергия, интернет-канал, сервера или программное обеспечение, а СЕТЕВОЕ ОБОРУДОВАНИЕ. Вам потребуется как минимум гигабитное соединение между уровнями веб-серверов и баз данных. Между интернетом и веб-серверами потребуется firewall, маршрутизатор и VPN. К моменту добавления второго веб-сервера понадобится решение для балансировки нагрузки. Суммарная стоимость такого оборудования может запросто вдвое превосходить стоимость пяти серверов.
EC2 предназначен для горизонтального масштабирования, для того чтобы нагрузка могла быть распределена между большим количеством машин (достаточно хорошая идея, если Вы планируете расширяться). Еще больше смысла в таком подходе появляется, если вы планируете масштабироваться по необходимости (то есть добавлять и убирать машины в зависимости от уровня нагрузки).
Горизонтальное масштабирование может проходить относительно безболезненно только при использовании open source программного обеспечения. В противном случае вертикальное масштабирование значит сокращение издержек, связанных с лицензиями, в ущерб стоимости оборудования, а горизонтальное масштабирование - наоборот: экономия на оборудовании, но требуется существенно больше лицензий на программное обеспечение.
RAID-10 отлично работает для баз данных с высокой нагрузкой операций чтения и записи.
Разделяйте работу приложений и баз данных таким образом, чтобы они могли масштабироваться независимо друг от друга. Например, базы данных могут масштабироваться вертикально, а сервера приложений - горизонтально.
Приложения должны хранить все информацию о своем состоянии в базе данных для обеспечения возможности роста путем простого добавления серверов приложений в кластер.
Одна из основных проблем со стратегией вертикального масштабирования - недостаток избыточности. Кластеризация добавляет надежности, но когда стоимость каждого сервера высока - это не так просто реализовать.
Некоторые приложения могут масштабироваться линейно относительно числа процессоров. Но зачастую будут использоваться механизмы блокировки, что приведет к сериализации вычислений и в итоге к существенному уменьшению эффективности приложения.
С более крупными серверами, занимающими от 7U в стойке, электроэнергия и охлаждение становятся критичными вопросами. Возможно использование чего-то среднего между 1U и 7U может облегчить Ваши взаимоотношения с датацентром.
С добавлением все новых и новых серверов баз данных издержки на лицензии SQL Server могут стать очень существенными. Если Вы начнете с вертикального масштабирования и постепенно начнете переходить к горизонтальному с использованием не open source продуктов, возможно это сильно ударит по Вашему финансовому состоянию. Это справедливо, что в этой заметке речь идет не совсем об архитектуре проекта. Мы знаем об их серверах, об используемом наборе инструментов, об их двухуровневой схеме, где база данных используется напрямую из кода веб-серверов. Но мы не знаем практически ничего о самой реализации, например таких мелочей как теги. Если Вам интересен этот вопрос, возможно Вам удастся получить интересующую Вас информацию из описания их схемы базы данных.