Insight IT

Реинкарнация сайта

Иван Блинков — Sat, 30 May 2015 20:10:00 +0300

После, пожалуй, самого длительного периода без обновлений в истории Insight IT, сайт прошел через "реинкарнацию" - был переделан с нуля, сохранен лишь контент. Этого сложно не заметить, если Вы здесь не впервые. Желающих получить ответы на вопросы в духе "как так?", "зачем?", "что поменялось?" и "что дальше?" - прошу читать далее.

Как так?

Многие годы, занимаясь Insight IT, я совмещал приятное с полезным: по большому счёту оставаясь просто хобби, сайт помогал мне знакомиться с будущими партнерами, клиентами, коллегами, что долгое время позволяло мне обходиться без стабильного источника дохода. Когда я в итоге "сдался" и пошел работать в крупную компанию за зарплату - эта дополнительная ценность стала менее значимой. Во многом из-за этого здесь нельзя найти ни одной записи датированной прошлым годом (хотя есть и другие причины, конечно, но об этом в заключении).

Зачем?

Резонный вопрос - зачем вкладывать столько сил, чтобы всё переделать на в заброшенном сайте? Началось всё со спортивного интереса: я начал замечать, что постепенно теряю хватку в мирах opensource и веб-разработки. В Яндексе вокруг меня по большей части разный backend внутренней разработки. Кандидат для экспериментов в лице Insight IT нашелся быстро, что из этого получилось - в следующем разделе.

Что поменялось?

R.I.P. WordPress

Первые 6 c половиной лет своего существования Insight IT проработал на WordPress в качестве CMS. С пьедестала самой популярной CMS в мире, насколько я знаю, за всё это время WordPress так никто и не сместил. Думаю, в первую очередь благодаря крайне простому в использовании интерфейсу для управления сайтом, а во вторую - выдающемуся ассортименту плагинов и тем. Плюс имевший место в 2008-м акцент на блоги отходит в сторону, сейчас на нем какие только сайты не делают.

Но за ~~красоту~~ простоту приходится платить:

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

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

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

Уже в 2009-м минусы WordPress для меня начали перевешивать плюсы. Тогда достойной альтернативы, увы, не нашлось и всё осталось как есть. Но не в этот раз.

Статические сайты

Несколько лет назад начал набирать популярность подход с генерацией статических сайтов:

Вместо хранения в базе данных статьи и другой контент приравнивается к исходному коду, то есть:
- Хранятся в системе контроля версий в виде файлов в специализированном формате (как правило, Markdown или ReStructured Text), который удобен для написания человеко-читаемых текстов и однозначно преобразовывается в чистый, валидный, HTML.
- Пишутся в текстовых редакторах, ориентированных на разработчиков, с подсветкой синтаксиса, автодополнением и т.п.
- При необходимости легко начать использовать общепринятые инструменты для работы с кодом, в том числе совместной (ревью кода, ветвление, непрерывная интеграция, отслеживание проблем).
С помощью make или аналога сайт собирается примерно так же, как это делала бы программа на C++:
- Создается output директория с будущим результатом.
- В ней генерируются все страницы сайта - для статей с помощью шаблонизатора добавляется вся необходимая HTML-обвязка, а навигационные страницы (по категориям и тегам, с по-страничным выводом) создаются с нуля, тоже по шаблону.
- Весь клиентский код на JavaScript и CSS, а также статические файлы вроде изображений, группируются и прогоняются через разные фильтры для уменьшения количества файлов и их размеров.
- Внутренние ссылки в исходном коде как правило реализованы по путям в локальной файловой системе, а как они будут выглядеть в итоговом сайте конфигурируется и тоже применяется при сборке.
В итоге, чтобы посмотреть на результат в браузере подойдет любой веб-сервер, умеющий отдавать статические файлы из папки, то есть совсем любой за вычетом специализированных.
Как легко такую папочку кешировать на всех уровнях, а также как быстро и дешево можно такой сайт показывать пользователям, рассказывать, думаю, не нужно.
Но у отсутствия динамической серверной логики есть и минусы:
- ~~Тоска по гламурной админке WordPress.~~
- Для реализации некоторого функционала (в нашем случае - комментариев и поиска по сайту) требуется как-то изворачиваться, возможные варианты:
  - Воспользоваться сторонним сервисом - Disqus уже использовался и раньше, а обе лидирующие поисковые системы предоставляют сервис поиска по конкретному сайту, так что я пошел по этому пути).
  - Поселить рядом с кучей статики какой-о набор скриптов, но не очень понятно как их интегрировать с системой сборки сайта, которая по сути выполняет роль CMS.
  - Реализовать его на JavaScript - скажем для поиска по сайту можно при сборке сложить весь контент в один большой JSON, и искать по нему уже на клиенте. Но я решил пожалеть пользователей с долгоиграющими ноутбуками, особенно новых без вентиляторов. Раньше ещё можно было пожалеть владельцев смартфонов, но когда их стали делать восьми-ядерными...
- Время, которое технически необходимо для публикации нового контента или изменений в шаблонах, начинает зависеть от размера самого сайта - не смотря на попытки реализовать кеширование при сборке, многие изменения требуют перегенерации примерно всего сайта.
И, напоследок, ввиду низкой серверной ресурсоемкости таких сайтов, для него легко найти качественный хостинг бесплатно.

Взвесив "за" и "против", я решил, что для Insight IT такой вариант очень даже подходит. Осталось выбрать конкретную реализацию такой системы сборки сайта.

Первопроходцем и лидером рынка здесь является Jekyll. Всем хорош, очень много кем используется, масса тем и плагинов. Но один субъективный минус поставил на нём лично для меня крест - Ruby. Вот тошнит меня от его синтаксиса и всё.

Был вариант, конечно, закрыть на это глаза и не лезть вглубь, а просто собрать сайт из готовых компонентов, но опыт подсказывает, что без напильника нынче ничего не взлетает.

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

https://

Как при желании можно было заметить, Insight IT уже много лет живет за CloudFlare - многофункциональной распределенной прокси, выполняющей роль CDN, DNS,защиты от разного рода атак и многого другого. Изначально поддержка SSL была доступна только на платном тарифе, который некоммерческому проекту был ни к чему, но с недавних пор это стало не так и я за компанию решил перейти на https://, раз уж всё равно все внутренние ссылки переехали. Плюсы не критичны, но всё же есть:

Само отображение защищенного соединения в адресной строке браузеров внушает уверенность если не всем, то какой-то части посетителей
Поддержка современных протоколов в лице SPDY и, вероятно, со временем HTTP/2.0
Говорят, использование защищенного соединения положительно сказывается на репутации сайта в глазах как минимум поиска Google
Владельцы публичных WiFi точек не могут показывать свою рекламу на сайте

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

К слову, стоявший за CloudFlare простенький VPS тоже заменен, на наиболее популярный среди хостингов статичных сайтов GitHub Pages.

Контент

В состав Pelican входит инструмент для конвертации статей из XML-формата WordPress в Markdown, которым я и воспользоваться. Большую часть работы он сделал, но всё равно потребовался ручной просмотр и адаптация всех страниц сайта. Это заняло уйму времени, но в целом того стоило:

Везде причёсан HTML, во многом благодаря Markdown; лучше оформлены изображения и врезки, ещё раз проверены опечатки.
Исторически статьи раскладывались по рубрикам по мере написания, по-этому общая структура сайта была хаотичной. Теперь разбил их на категории по-другому, на этот раз, надеюсь, более логичным образом.
Пока перечитывал осознал, что значительная часть контента морально устарела и годится только для совсем начинающих или как историческая перспектива. Решил сделать некоторый акцент на годе публикации - теперь он присутствует в URL статей, а также в оглавлении публикаций об архитектуре высоконагруженных интернет-проектов. Совсем-совсем неактуальным пришлось пожертвовать или явно подписать соответствующим образом.
Как следствие из предыдущих двух пунктов, в очередной раз полностью поменялась структура ссылок сайта. По-возможности со старых адресов сохранены редиректы, но, к сожалению, в концепции статических сайтов возможны только клиентские, через meta-тег или JavaScript. Поисковые системы же предпочитают серверные, через 301/307 HTTP-код и заголовок Location.
В общем, позиции Insight IT в поисковых системах определенно пострадают, остается лишь надеяться что не катастрофическим образом - ведь сейчас это основной источник посетителей. Если вам не безразлична судьба сайта - твиты, лайки и прочие входящие ссылки по новым адресам крайне приветствуются.
Теперь весь контент публикуется под лицензией Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License, о чем свидетельствует значок в правом-нижнем углу каждой страницы.

Дизайн

В плане дизайна я не особо гурман, но предыдущий определенно требовал замены. Изыски здесь ни к чему, так что всё свелось к выбору готовой визуальной концепции.

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

В своё время мне приглянулось своей стройностью и логичностью концепция Material Design от Google, которую они активно внедряют сами и всем советуют. Не долго думая, я пошел поискать opensource решения с готовой реализацией для веб-сайтов и остановился на варианте, который одновременно имел достаточный функционал, сколько-либо большое сообщество и минимум зависимостей, особенно от громоздких JavaScript-библиотек, чем грешили альтернативные варианты.

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

Итого, с моей субъективной колокольни получилось заметно лучше прежнего, но хочется всё же услышать и ваше мнение в комментариях.

Что дальше?

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

С закрытием Google Reader два года назад число подписчиков на счетчике от FeedBurner упало почти на два порядка, так что можно считать, что сейчас и правда для Insight IT всё начинается почти с начала.

Вакансии: разработчики облачной IaaS платформы в Крок

Иван Блинков — Thu, 19 Sep 2013 19:40:00 +0400

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

Ведущая российская ИТ-компания ищет талантливых, креативных и энергичных инженеров и разработчиков для развития коммерческой облачной платформы КРОК, предоставляющей услугу типа «Инфраструктура как сервис» (IaaS). В современном высокотехнологичном офисе Вас ждет дружная сплоченная команда профессионалов, занимающаяся разработкой передовой «облачной» платформы, у которой всегда найдется для Вас множество интересных, сложных и разнообразных задач, способных удовлетворить даже самые заоблачные амбиции!

Разработчик на платформе Linux

Обязанности

Проектирование архитектуры компонентов «облачного» решения;
Разработка и интеграция модулей облачной платформы;
Исследования в области распределенных высоконагруженных систем.

Требования

Опыт в области shell-программирования;
Уверенное знание Python, приветствуется знание С++ или Java;
Владение средствами разработки (autotools, git, svn и др.);
Опыт администрирования ОС Linux от 1 года (преимущественно RHEL, CentOS, Debian или SLES);
Опыт работы с технологиями виртуализации (Qemu/KVM, XEN, Hyper-V или VMware);
Знание «облачных» технологий особенно приветствуется.

Инженер по облачным решениям

Обязанности

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

Требования

Навыки администрирования современных ОС GNU/Linux и Windows;
Понимание принципов виртуализации вычислительных ресурсов;
Приветствуется опыт написания сценариев на языках shell и Python;
Личные качества: коммуникабельность, общительность, активная жизненная позиция.

Условия

Конкурентная заработная плата по результатам собеседования;
Возможность профессионального и карьерного роста;
Компания оплачивает обучение и сертификацию;
Социальный пакет (медицинская страховка, бесплатное питание в офисе, спортивные программы и компенсация фитнеса, английский язык);
Компания оказывает помощь при переезде в Москву (оплата стоимости проезда для прохождения собеседований, «подъемные» при выходе на работу).

Куда отправлять резюме?

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

Вакансии: команда 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

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

Вакансии: PHP и Python разработчики в Киеве

Иван Блинков — Thu, 20 Sep 2012 20:16:00 +0400

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

Киевская команда разработчиков игр для социальных и мобильных платформ Level UP ищет опытных специалистов по веб-разработке на Python и PHP.

Senior Python Developer

Задачи:

Разработка высоконагруженных веб-приложений;
Разработка внутренних и публичных API;
Разработка архитектуры комплексных сервисов;
Конвертирование бизнес-задач в технические решения (R&D).

Требования:

Опыт разработки на Python более 3х лет;
Сильные навыки применения реляционных и нереляционных баз данных;
Опыт в разработке высоконагруженных веб-приложений;
Дружба с Linux и Git;
Хорошее знание клиентских технологий (HTML, CSS, Javascript);
Опыт работы в команде.

Плюсом будет:

Опыт разработки комплексных проектов на PHP или серверном Javascript (node.js);
Опыт разработки инструментов для верстки, автоматизации верстки, шаблонизаторов и пр.

Senior PHP Developer

Задачи:

Разработка высоконагруженных социальных веб-приложений;
Работа в небольшой дружной команде до 15 человек;
Решение нетривиальных задач и создание инструментов для внутреннего использования;

Требования:

Опыт разработки на PHP более 3х лет;
Опыт работы с MySQL и MongoDB;
Опыт в разработке высоконагруженных веб-приложений;
Дружба с Linux и Git;
Хорошее знание клиентских технологий (HTML, CSS, Javascript);
Опыт примененения функционарного и юнит тестирования.

Плюсом будет:

Опыт разработки на Python или серверном Javascript (nodejs).

Условия для обоих вакансий

Зарплата в диапазоне \$2500-4000 в месяц по результатам собеседования;
Полный рабочий день в Киевском офисе, иногородним помощь с переездом;
За успешную рекомендацию специалиста по данным вакансиям компания выплачивает бонус в размере $1000 так что сообщите своим знакомым, кому-то это может быть интересно.

Заинтересовало?

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

Не лишним будет, если кроме резюме Вы напишите - почему Вам нравится серверная разработка на Python или PHP и почему Вам интересна данная вакансия. Плюс упомяните, пожалуйста, что Вы узнали о данной вакансии через Insight IT.

Архитектура Pinterest

Иван Блинков — Wed, 15 Aug 2012 22:26:00 +0400

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

Платформа

Amazon AWS - хостинг и вспомогательные сервисы
nginx - вторичная балансировка нагрузки, отдача статики
Python - язык программирования
Django - фреймворк
MySQL - основная СУБД
memcached - кэширование объектов
Redis - кэширование коллекций объектов
Solr - поиск
Hadoop - анализ данных

Статистика

3 миллиона уникальных посетителей в день
18 миллионов уникальных посетителей в месяц
4-я по популярности социальная сеть в США после Facebook, Twitter и LinkedIn
Порядка 500 виртуальных машин в EC2
80 миллионов объектов в S3
410Тб пользовательских данных

Развитие

Март 2010

1 маленький виртуальный веб-сервер
1 маленький виртуальный сервер MySQL
Все это в Rackspace, 1 разработчик

Январь 2011

1 сервер nginx для балансировки нагрузки, 4 веб-сервера
2 сервера MySQL с master/slave репликацией
3 сервера для отложенного выполнения задач
1 сервер MongoDB
Переехали на Amazon EC2 + S3 + CloudFront

Осень 2011

2 сервера nginx, 16 веб-серверов, 2 сервера для API
5 функционально разделенных серверов MySQL с 9 read slave
Кластер из 4 узлов Cassandra
15 серверов Membase в 3 отдельных кластерах
8 серверов memcached
10 серверов Redis
7 серверов для отложенной обработки задач
4 сервера Elastic Search
3 кластера MongoDB
3 разработчика
Если кто-то может объяснить зачем им сдался такой зоопарк, кроме как потестировать разные варианты, можете взять с полки пирожок.

Зима 2011-2012

Заменили CloudFront на Akamai - вполне объяснимо, так как у Akamai намного лучше покрытие по миру, а качественный CDN для сайта с большим количеством изображений - чуть ли не залог успеха.
90 веб серверов и 50 серверов для API
66 + 66 MySQL серверов на m1.xlarge инстансах EC2
59 серверов Redis
51 серверов memcached
25+1 сервер для отложенной обработки задач на основе Redis
Кластеризованный Solr
6 разработчиков

Весна-лето 2012

Снова сменили CDN, на этот раз в пользу ранее неизвестного мне Edge Cast. Покрытие по всему миру довольно скромное, так что единственное логичное объяснение, которое мне приходит в голову - не потянули Akamai по деньгам.
135 веб серверов и 75 серверов для API
80 + 80 серверов MySQL
110 серверов Redis
60 серверов memcached
60 + 2 сервера для отложенной обработки задач на основе Redis
25 разработчиков

Выбор

Почему Amazon Ec2/S3?

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

Почему MySQL?

Очень "зрелая", хорошо известная и любимая многими
Редки катастрофичные потери данных
Линейная зависимость времени отклика от частоты запросов
Хорошая поддержка сторонним ПО (XtraBackup, Innotop, Maatkit)
Надежное активное сообщество
Отличная поддержка от Percona
Бесплатна

Почему memcached?

Очень "зрелый", отличная производительность, хорошо известный и любимый многими
Никогда не ломается
Бесплатен

Почему Redis?

Много удобных структур данных
Поддержка персистентности и репликации
Также многим известен и нравится
Стабильно хорошая производительность и надежность
Также бесплатен

Архитектура

Сlustering vs Sharding

Большую часть презентации, на основе которой написана данная статья (ссылка, если не охота листать до секции источников информации), занимает раздел под названием "Clustering vs Sharding". В связи с путаницей в терминологии пришлось несколько раз перечитывать, чтобы понять к чему они клонят, сейчас попробую объяснить.
Вообще есть два фундаментальных способа распределить данные между несколькими серверами:
- Вертикально: разные таблицы (или просто логически разные типы данных) разносятся на разные сервера.
- Горизонтально: каждая таблица разбивается на некоторое количество частей и эти части разносятся на разные сервера по определенному алгоритму.
С первого взгляда казалось, что они пытаются вертикальное разбиение назвать sharding, а горизонтальное - clustering. Хотя вообще они почти синонимы и на русский я их обычно примерно одинаково перевожу.
По факту же оказалось, что под словом clustering они понимают все программные продукты для хранения данных, которые имеют встроенную поддержку работы в кластере. В частности они имеют ввиду Cassandra, Membase, HBase и Riak, которые прозрачно для пользователя горизонтально распределяют данные по кластеру.
За словом sharding в их терминологии стоит аналогичная схема собственной разработки, использующая огромное количество логических БД в MySQL, распределенных между меньшим количеством ~~физических серверов~~ виртуальных машин. Именно по этому пути и пошли в Pinterest, плюс очень похожий подход используется в Facebook.
От себя добавлю, что хоть при наличии должных ресурсов разработка собственной системы распределения данных и может быть целесообразной, в большинстве случаев на начальном этапе проще основываться на готовых решениях вроде перечисленных выше. К слову в opensource доступны и основанные на MySQL подобные решения:
- Vitess от Google / YouTube
- FlockDB от Twitter
В их проекте данная подсистема развивалась следующим образом:
- 1 БД + внешние ключи + join'ы →
- 1 БД + денормализация + кэш →
- 1 БД + master/slave + кэш →
- несколько функциональных разделенных БД + master/slave + кэш →
- вертикально и горизонтально разделенные БД (по идентификаторам) + по резервные БД (пассивный slave) + кэш
При использовании аналогичного решения остерегайтесь:
- Невозможности выполнять большинство запросов с join
- Отсутствия транзакций
- Дополнительных манипуляций для поддержания ограничений уникальности
- Необходимости тщательного планирования для изменений схемы
- Необходимости выполнения одного и того же запроса с последующей агрегацией для построения отчетов

Остальные моменты

Кэширование многоуровневое:
- Коллекции объектов хранятся в списках Redis
- Сами объекты - в memcached
- На уровне SQL запросы в основном примитивны и написаны вручную, так что часты попадания в кэш MySQL
- Кэш файловой системы - само собой
Еще пара фактов про кэширование в Pinterest:
- Кэш разбит также на несколько частей (шардов), для упрощения обслуживания и масштабирования
- В коде для кэширования используются Python'овские декораторы, на вид собственной разработки, хотя точно не уверен
Балансировка нагрузки осуществляется в первую очередь за счет Amazon ELB, что позволяет легко подключать/отключать новые сервера посредством API.
Так как большинство пользователей живут в США по ночам нагрузка сильно падает, что позволяет им по ночам отключать до 40% виртуальных машин. В пиковые часы EC2 обходится порядка 52$ в час, а по ночам - всего 15$.
Elastic Map Reduce, основанный на Hadoop, используется для анализа данных и стоит всего несколько сотен долларов в месяц
Текущие проблемы:
- Масштабирование команды
- Основанная на сервисах архитектура:
  - Ограничения соединений
  - Изоляция функционала
  - Изоляция доступа (безопасность)

Уроки от команды Pinterest

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

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

Scaling Pinterest @ MySQL Meetup
- В презентации можно посмотреть примеры кода и SQL-запросов
- Если кто-то знает где можно посмотреть/послушать запись этого мероприятия - поделитесь ссылкой, пожалуйста
Pinterest Architecture Update
Вакансии в Pinterest

Архитектура Instagram

Иван Блинков — Fri, 13 Apr 2012 20:11:00 +0400

Instagram - всего лишь iOS, а теперь и Android, приложение для обмена фотографиями с друзьями. Последнее время находится на слуху благодаря новости о покупке проекта Facebook'ом за кругленькую сумму. Недавно один из основателей проекта, Mike Krieger, выступил на конференции с докладом о техническом аспекте проекта, который я и хотел бы вкратце пересказать.

Статистика

Начало:

1 сервер слабее Macbook Pro
25к регистраций в первый день
2 разработчика

Сегодня:

40+ миллионов пользователей
100+ виртуальных серверов в EC2, в том числе:
Проект куплен Facebook за 1 млрд. долл
1 миллион регистраций за 12 часов после запуска Android-версии
5 разработчиков

Технологии

Ubuntu Linux 11.04 - основная операционная система
Python - основной язык программирования серверной части
Django - фреймворк
Amazon:
- EC2 - хостинг
- ELB - балансировка входящих HTTP-запросов
- Route53 - DNS
- S3 - хранение фотографий
- CloudFront - CDN
nginx - второй уровень балансировки входящихHTTP-запросов
gunicorn - WSGI-сервер
HAProxy - балансировка нагрузки внутри системы
PostgreSQL - основное хранилище данных
postgis - поддержка гео-запросов
pgfouine - отчеты на основе логов
pgbouncer - создание пула соединений
Redis - дополнительное хранилище данных
Memcached - кэширование
Gearman - очередь задач
Solr - гео-поиск
munin, statsd, pingdom - мониторинг
Fabric - управление кластером
xfs - файловая система

Философия

Простота
Минимизация операционных издержек
Использование подходящих инструментов

История

Забыли сделать favicon.ico до запуска - в первый же день логи пестрили ошибками 404
Для хранения данных использовали просто Django ORM и PostgreSQL (из-за postgis)
Начали с одного слабого сервера, после успешного запуска решили переехать на EC2
Довольно быстро пришлось вынести СУБД на отдельный сервер (виртуальный, естественно)
Количество фотографий продолжало расти и расти, даже самый большой инстанс EC2 не справлялся
Решили вертикально разделить данные на несколько баз, с использованием механизма routers из ORM, параллельно избавившись от внешних ключей
Через несколько месяцев суммарный размер базы данных перевалил за 60Гб и перестало справляться и это решение
Следующим шагом стало горизонтальное разбиение данных (sharding):
Создали несколько тысяч логических баз данных.
Распределили их по существенно меньшему количеству физических серверов (читай: виртуальных машин).
Написали свой механизм определения где искать какую базу данных, с поддержкой миграции (вероятно тоже на основе routers).
По последним данным под PostgreSQL используется 12+12 виртуальных машин с максимальной оперативной памятью (68.4Гб), а также сетевые диски EBS, объединенные в программный RAID посредством mdadm. Это необходимо, чтобы весь массив данных помещался в памяти, EBS не в состоянии обеспечить достаточную производительность.
С некоторыми задачами лучше справляется Redis:
Для каждого пользователя в Redis есть список идентификаторов новых фотографий от других пользователей, на которых он подписан.
При отображении потока новых для пользователя фотографий делается выборка части такого списка, после чего посредством multiget достается подробная о них информация из memcached.
Пробовали возложить на него задачу хранения списков подписчиков, но в итоге вернулись к решению на PostgreSQL с небольшим кэшированием.
В Redis также хранится информация о сессиях.
Несколько фактов о Redis:
- Так как все находится в памяти - очень быстрые операции записи и работы с множествами.
- Является не заменой, а дополнением к основному хранилищу данных.
- Redis хорош для структур данных, которые относительно ограничены.
- Отлично подходит для кэширования комплексных структур данных, где нужно большее, чем просто получить значение по ключу (например - счетчики, подмножества, проверка вхождения в множества).
- Механизм репликации (посредством slaveof) позволяет легко масштабировать операции чтения.
Пользователи синхронно загружают фотографии на медиа-сервер с (опциональными) заголовком и месте на карте, все остальное происходит асинхронно посредством очередей, например:
- Сохраняются гео-метки, обновляется Solr (который впоследствии заменил postgis).
- Идентификатор нового фото добавляется в обсуждавшиеся выше списки для всех подписчиков автора.
Поначалу использовали Apache + mod_wsgi для запуска Django, впоследствии перешли к gunicorn из-за меньшего потребления ресурсов и простоты настройки.
С недавних пор начали использовать Amazon ELB вместо DNS round-robin для первичной балансировки входяших HTTP-запросов, что позволило:
избежать необходимости дешифровки SSL посредством nginx;
ускорить исключение из балансировки проблемных серверов.
Благодаря использованию xfs есть возможность "замораживать" и "размораживать" дисковые массивы при резервном копировании.

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

Многие проблемы с масштабируемостью - результат банальных человеческих ошибок.
Масштабирование = замена всех деталей в машине на скорости 150 км/ч.
Заранее сложно узнать как в основном будут обращаться к данным, без реального использования.
В первую очередь попытайтесь адаптировать известные Вам технологии и инструменты для создания простого и понятного решения, прежде чем бросаться на поиски чего-то нетривиального.
Дополните свое основное хранилище более гибким компонентом, вроде Redis.
Постарайтесь не использовать два инструмента для решения одной и той же задачи.
Оставайтесь гибкими и ловкими = напоминайте себе о том, что на самом деле имеет значение.
Разрабатывайте решения, к которым не придется постоянно возвращаться из-за их сбоев.
Активное юнит- и функциональное тестирование стоят потраченного на них времени.
DRY: не делайте одну и ту же работу несколько раз.
Слабая связанность посредством уведомлений или сигналов позволяет легко менять структуру проекта.
Дисковый ввод-вывод часто оказывается узким местом, особенно на EC2.
Спускаться до C нужно только при необходимости, большую часть работы лучше делать в Python.
Короткий цикл разработки - залог быстрого развития.
Частые совместные рассмотрения кода нужны, чтобы все были в курсе происходящего.
Не изобретайте велосипед.
Окружите себя с толковыми консультантами.
Культура открытости вокруг разработки.
Делитесь с opensource сообществом.
Фокусируйтесь на том, что вы делаете лучше всего.
Вашим пользователям абсолютно без разницы, написали ли Вы собственную СУБД или нет.
Не переоптимизируйте и не предполагайте заранее как сайт будет расти.
Не рассчитывайте, что "кто-то еще присоединится к команде и разберется с этим".
Для социальных стартапов очень мало, или даже совсем нет, нерешимых вопросов, связанных с масштабируемостью.

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

Упоминавшаяся во вступлении неприлично длинная презентация из 185 слайдов:

На видео, к сожалению, это выступление не записывалось.

Часть информации взята из технического блога Instagram.

Архитектура YouTube 2012

Иван Блинков — Sat, 24 Mar 2012 16:50:00 +0400

Выбирайте самое простое решение с наиболее общими гарантиями, которые практически полезны.

- Дао YouTube

YouTube практически на протяжении всех 7 лет своего существования является мировым лидером в сфере интернет-видео. С точки зрения технической реализации проект оказался достаточно консервативным - команда придерживается того же курса и стека технологий, с которых все начиналось еще до приобретения проекта Google. Но с 2008 года, когда я написал первый обзор архитектуры YouTube, все же произошли интересные изменения, о которых я и хотел бы сегодня вкратце рассказать.

Статистика

4 млрд. просмотров страниц в день
60 часов видео загружается каждую минуту
350 миллионов устройств подключено к YouTube
На февраль 2012 года в США по данным comScore:
- 147,4 млн. уникальных зрителей
- 16,7 млрд. просмотров видео (в октябре 2011 было больше 20 млрд.)
- Каждый зритель посмотрел в среднем 7 часов видео за месяц
- 1.1 млрд. просмотров видео рекламы, суммарной длительностью в 10.8 млн. часов

Технологии

Linux - операционная система
Apache - основной HTTP-сервер
lighttpd - отдача видео из YouTube CDN
Zookeeper - распределенные блокировки, хранение конфигураций
Python:
- wiseguy - FastCGI-прослойка между Apache и Python
- pycurl - лучшая доступная реализация HTTP-клиента, но в итоге все равно заменили на самописное низкоуровневое решение, выиграв 8% в потреблении вычислительных ресурсов.
- spitfire - высокопроизводительный шаблонизатор на основе абстрактного синтаксического дерева с регулируемым уровнем оптимизации (как в gcc)
- bson в качестве формата сериализации
BigTable - хранение изображений
MySQL - используется просто как хранилище данных, версия 5.1.52 с InnoDB
Vitess - система для масштабирования MySQL-кластера

Vitess

Основная цель проекта - предоставление всех необходимых инструментов и серверов для горизонтального масштабирования баз данных на основе MySQL, с учетом потребностей современных интернет-проектов.
Реализован на Go - все еще экзотическом языке программирования, также родившемся в стенах Google. Сравним по производительности с C++ и Java, но несколько более "выразителен".
Опубликован в opensource 24 февраля 2012 года, совсем недавно, так что YouTube - по-прежнему единственный пример его использования на практике в крупном проекте.
Готовые клиентские библиотеки пока только для Python и Go, что не удивительно, но есть и универсальные интерфейсы на основе HTTP и просто TCP-сокетов.
Основной формат данных - bson, как и в MongoDB, но по словам разработчиков Vitess их реализация выполняет (де)сериализацию в 10-15 раз быстрее.
Ядром проекта выступает Vtocc, SQL-прокси с RPC интерфейсом, позволяющий перераспределять запросы от большого количества (более 10 тыс.) одновременно подключенных клиентов в сравнительно небольшое количество соединений с базами данных. Пропускная способность порядка 10 тыс. запросов в секунду.
Встроенные возможности Vtocc:
- парсер и анализатор SQL-запросов для оптимизации их выполнения;
- заполнение типичных запросов переменными с поддержкой кэширования результатов;
- управление транзакциями и сроками их выполнения ("убивает" затянувшиеся);
- для каждого пространства ключей (логической таблицы) можно указать фактор репликации, что создаст необходимое количество второстепенных баз данных в дополнение к мастеру;
- можно явно указать, что чтение необходимо произвести с мастера (важно когда пользователь только что выполнил какое-то действие и должен сразу же увидеть его результат);
- отдельные пулы соединений для выполнения операций чтения и записи;
- исключение "зависших" соединений из пулов;
- перезапуск без простоя системы;
- поддержка DML.

Партиционирование

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

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

YouTube - еще один проект мирового масштаба, который с самого начала использовал MySQL и оказался не в силах от него отказаться, не смотря на трудности с горизонтальным масштабированием.
По аналогичному пути пошли и другие проекты, схожие с Vitess надстройки над MySQL используются в Facebook и Twitter:
- В Facebook она дополнена сильной интеграцией с memcached и сильно ограниченным интерфейсом, не имеющим практически ничего общего с SQL. Планы о публикации в opensource, кажется, были, но я не слышал чтобы они воплотились в жизнь. // Уже почти дописав статью случайно заметил в коде, а потом и мелким шрифтом в документации, что в Vitess тоже используется memcached для кэширования из-за проблем со сборщиком мусора Go.
- Twitter по-прежнему использует свою связку FlockDB + Gizzard на Scala, которые уже пару лет публично доступны. В отличии от Vitess она заточена на хранение информации о социальных графах, по-этому сфера её применения как в Twitter, так и за его пределами ограничена.
Vitess - пожалуй первая относительно успешная попытка построить распределенную горизонтально масштабируемую СУБД на основе реляционной базы данных, сохранив при этом SQL-интерфейс, пускай и с некоторыми ограничениями.
Выбирайте подходящее хранилище для каждого типа данных в системе - если Vitess стал подходящим решением для структурированных данных вроде информации о пользователях, метаданных видео и комментариев, это не значит, что он хорошо (или плохо) справится, например, с медиа-файлами вроде изображений и видео (для них в YouTube по-прежнему используют стек технологий Google, подробности не публикуются).
Python - вполне пригодный инструмент для реализации бизнес-логики интернет-проектов, свет клином на PHP не сошелся. Python предлагает широкий ассортимент инструментов для решения любых типичных для интернет-проектов задач, хотя субъективно выбор некоторых из них разработчиками YouTube мне кажется странным.

В комментариях предлагаю обсудить слабые и сильные стороны использования надстроек над реляционными базами данных, скажем по сравнению с использованием изначально-распределенных СУБД, таких как Riak, Cassandra и многих других. Может быть кто-то уже успел прикрутить к своему проекту Vitess или хотя бы FlockDB и готов поделиться впечатлениями?

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

Mike Solomon на PyCon'12 (один из первых разработчиков проекта)
О проекте Vitess
Статистика comScore на февраль '12

Tornado

Иван Блинков — Tue, 28 Feb 2012 23:03:00 +0400

Tornado - масштабируемый неблокирующий HTTP-сервер на основе epoll, написанный полностью на Python. Изначально он был разработан в рамках проекта FriendFeed, на сегодняшний же день его поддержкой занимается Facebook. Сегодня я хотел бы рассказать о том, как с его помощью можно быстро и легко создавать веб-проекты на Python, которые в дальнейшем будет относительно легко горизонтально масштабировать.

HTTP

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

он работает в рамках одного процесса;
использование потоков внутри него нежелательно;
для использования всех доступных ядер процессора обычно запускают несколько копий одинаковых процессов на разных портах (недавно добавили модуль tornado.process для упрощения реализации этого);
обычно обрабатывает HTTP-запросы не напрямую, а через балансировщик нагрузки (nginx или HAProxy).

Эта ситуация мотивирует с самого начала задумываться о распределении нагрузки, а также о выносе выполнения вычислительно сложных задач в отдельные сервисы, скажем конвертирование фото/видео или подсчет какой-то статистики.

Стоит добавить, что вместе с проектом поставляется модуль tornado.wsgi, который позволяет запускать внутри себя другие веб-ориентированные проекты на Python (в частности небезызвестный Django), а также "притворяться" таковым для каких-то внешних серверов или сервисов, которые умеют общаться с Python-приложениями только по WSGI-протоколу, например таковым является Google App Engine. Пользоваться этим модулем крайне не рекомендую, только при постепенном мигрировании проекта с каких-то других технологий.

Обработка запросов

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

При создании этих классов настоятельно рекомендую по полной воспользоваться возможностями ООП, в частности наследования. Tornado предоставляет базовый класс RequestHandler, который берет на себя всю грязную работу, а разработчику предлагается реализовать лишь логику, переопределив метод(ы) get, post, delete или head. На практике же обычно удобнее иметь свой собственный базовый класс для обработчиков запросов, который унаследован от RequestHandler и реализовывает общую для текущего конкретного проекта логику (примеры ниже).

Доступ к базе данных

Модуль tornado.database предлагает довольно простой доступ к MySQL. С одной стороны благодаря нему можно сходу начинать разрабатывать приложение на Tornado без использования дополнительных библиотек, с другой - далеко не в каждом проекте используется именно эта СУБД.

В любом случае никто не запрещает использовать любую другую библиотеку для доступа к любой другой СУБД, но есть одно большое НО! Большинство из них являются блокирующими, то есть не возвращают управление до тех пор, пока СУБД не вернет ответ. Почуяли неладное? Правильно, в таком случае весь процесс Tornado, вместе со всеми попавшими в него запросами, будет простаивать пока управление не будет получено обратно, что очень не здорово.

Решается эта неприятная ситуация путем отправки асинхронных запросов к СУБД, то есть после отправки запроса управление сразу же возвращается, а для обработки запроса регистрируется callback, который получит управление, когда прийдет ответ от СУБД. За планирование очередности передачи управления отвечает IOLoop, который и является "сердцем" Tornado.

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

Взаимодействие с внешним миром

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

С Thrift и Protocol Buffers ситуация несколько более печальна - о прецедентах их интеграции в Tornado IOLoop я не слышал, если кто-то может поделиться информацией - буду благодарен, довольно актуальный вопрос.

Генерация HTML

Шаблонизатор также предлагается свой собственный (не очень удачный, но вполне можно использовать), но его особо никто не навязывает - необходимо лишь переопределить метод render у базового RequestHandler с использованием любого другого аналогичного продукта.

Например, Jinja2, о котором я недавно писал, подключается примерно вот так:

from connections import env
from tornado.web import RequestHandler

class BaseHandler(RequestHandler):
  def render(self, template, context = None):
    if not context: context = {}
    context['user'] = self.current_user
    self.write(env.get_template(template).render(context))
    self.flush()

Прочие бонусы

tornado.gen - набор инструментов для упрощения написания асинхронного кода. Благодаря использованию механизма генераторов (yield), позволяет уместить в рамках одного метода и отправку асинхронного запроса и обработку его результата.
tornado.websocket предлагает реализацию нескольких последних редакций одноименного протокола, доступна пара более кроссбраузерных альтернатив с поддержкой нескольких протоколов: sockjs-tornado и TornadIO.
С помощью tornado.platform.twisted можно запускать код, написанный под Twisted (несколько более громоздкий и пожилой конкурент), внутри Tornado IOLoop. Актуально для "мигрирующих" проектов и прикручивания библиотек, написанных под Twisted.
Без tornado.autoreload разработка превратилась бы в настоящий кошмар.

Заключение

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

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

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

Jinja2

Иван Блинков — Sun, 19 Feb 2012 18:39:00 +0400

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

Встречаем!

Введение

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

Прежде чем перейти к делу, хочу напомнить что имеется ввиду под словом шаблонизатор: механизм для создания HTML-страниц путем заполнения HTML-шаблонов динамическими данными, получаемыми из СУБД или внешних источников. Шаблонизатор предоставляет некую надстройку над синтаксисом HTML для создания шаблонов и API для их использования.

Базовый функционал

Многое из этого можно увидеть и в альтернативных реализациях шаблонизаторов, так что ничего особенного:

{{ ... }} позволяет распечатать значение переменной или какого-то выражения, синтаксис достаточно свободный - можно обращаться к элементам коллекций, методам/атрибутам объектов и.т.п.
{% ... %} позволяет вызвать дополнительные теги, среди которых условные выражения, различные варианты циклов и многое другое.
Присутствиет концепция фильтров, сильно напоминающих UNIX pipes: начинается все с переменной или выражения, после чего можно через символ | указать как её обработать перед выводом в итоговый документ. Например, {{ foo|lower }} выведет содержимое строки foo в нижнем регистре. Как и в pipes, из фильтров можно делать цепочки.
Механизм наследования позволяет избежать избыточности в коде. В коде шаблона выделяются именованные блоки тегом {% block ... %}, после чего шаблон-потомок может переопределить содержимое блоков шаблона-родителя произвольным образом. Типичный пример использования:
- Создается базовый шаблон страницы, состоящий из основного каркаса страницы и всех общих для всего сайта элементов (ссылки на файлы стилей, общие JavaScript файлы и библиотеки, какие-то мета теги, title по-умолчанию)
- В базовом шаблоне содержимое каждой части выделяется в именованный блок (как минимум шапка, место под контент, 1-2 сайдбара и подвал), иногда рядом со стилями и скриптами оставляют по пустому блоку на случай, если шаблонам-наследникам потребуется что-то специфичное.
- Если какой-то блок будет содержать одну и ту же информацию на большинстве страниц сайта, то её тоже обычно помещают в базовый шаблон.
- Создается по шаблону-потомку на каждый тип используемых на сайте страниц, в которых переопределяется как правило (но далеко не всегда) только блок с конткентом и заголовок страницы. Из шаблонов-потомков также можно составить иерархию в случае, если у них есть много общей информации.
- Стоит упомянуть, что есть альтернативный механизм включения (include) шаблонов по-аналогии с PHP-файлами, но я достойных применений ему не нашел.
Очень много внимания уделено экранированию символов, хотя особо на него надеяться не стоит - с точки зрения безопасности намного важнее фильтровать попадающие на сайт данные, а не выводимые в шаблонах. Хотя как дополнительная подстраховка не помешает.
Простая интеграция с gettext придется кстати интернациональным проектам.
Опциональное считывание шаблонов с диска при каждом запросе страницы незаменимо при разработке.

Производительность

Сравнительные тесты производительности шаблонизаторов под Python довольно условны, очень многое зависит от конкретных шаблонов и динамических данных. Тем не менее, во всех из них Jinja2 определенно не в аутсайдерах, в топ5 вполне стабильно.

Шаблоны компилируются в байткод для последующего использования, с этой особенностью связаны два момента, которые спользовать:

Байткод можно хранить в memcached или любом другом внешним хранилище, достаточно лишь реализовать минимальный get/set интерфейс.
Доступен опциональный модуль на C, который берет на себя часть работы по заполнению шаблонов, что делает этот процесс несколько быстрее.

Расширяемость

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

Webassets

Этот проект позволяет делать с подключаемыми внешними Javascript и CSS файлами практически все, что угодно. В типичном варианте использования используется тег {% assets %} для:

Указания списка изначальных CSS/JS файлов, для конкатенации и последующей обработки.
Указания окружения ссылки на итоговый файл, т.е. как именно должен выглядеть тег <script> или <style>.
Списка фильтров, для минимизации или других преобразований кода.
Возможно использование sass или less файлов вместо чистого CSS.
Отключение конкатенации и минимизации при разработке доступно изменением одного флага.

В итоге вопрос с подготовкой минимизированных статических файлов становится полностью автоматическим.

Доступна интегрирация и с другими Python шаблонизаторами, в Jinja2 он подключается просто как расширение.

Минимизация HTML

Этот вопрос решается путем наследования от поставляемого вместе с шаблонизатором загрузчика шаблонов. API позволяет делать между чтением шаблона и генерацией байткода что угодно с текстом шаблона, например можно пропустить все через примитивную регулярку (вернее через несколько) и свернуть тем самым весь HTML в одну строку. Хочется обратить внимание, что осуществляется этот процесс очень редко (особенно при использовании кэша байт кода), так что можно делать на этом этапе даже сильно ресурсоемкие преобразования текста.

Другой формат данных

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

Да, наверняка многие скажут, что в этой ситуации надо было использовать универсальные шаблоны для JS и серверной части, но на Jinja2 такое тожно можно реализовать, с той лишь разницей, что пришлось гонять по сети не только сами данные, но и часть HTML-разметки (что, порой, тоже не плохо). Реализуется как и минимизация HTML посредством переопределения загрузчика страниц, который использовался вместо стандартного, если запрос пришел через AJAX.

Сэкономим еще пару байт

С подобного рода оптимизацией не заборачивается, наверное и 0.01% интернет-проектов, но я в свое время как-то увлекся и написал штуку для "выжимания" десятка-другого байт с большинства страниц и CSS/JS файлов. "Проблема" состоит в следующем: классы и идентификаторы, использующиеся в HTML, в "культурных" проектах имеют хотя бы отдаленно человекочитаемые названия, что почти всегда означает их длинность, что, учитывая их частую повторяемость в коде, в свою очередь негативно влияет на итоговый размер HTML/JS/CSS документов. Теоретическое решение лежит на поверхности: использовать "длинные" идентификаторы и классы в HTML при разработке, а при развертывании на публику переименовывать их в "короткие": a, b, c, ..., aa, ab, ac, ...

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

Если у кого-то возникнет желание тоже сделать что-то подобное средствами Jinja2, то советую "вмешиваться" в обработку JS/CSS посредством дополнительного фильтра в Webassets, а сами шаблоны редактировать как и в предыдущих разделах при считывании их с диска.

Спрайты и обработка изображений

Создание спрайтов как таковых не предусмотрено, так как по сути это не по части шаблонизатора. Но есть вариант подключить их к Webassets, например через интеграцию Ruby-проектом compass (у которого есть плагин-генератор спрайтов).

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

Идеи для фильтров и глобальных функций

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

Форматирования даты/времени по шаблону
Фильтрации HTML с белым списком тегов
Получения атрибута объекта с неизвестным заранее именем (getattr)
Вывода строки в режиме "первая - заглавная, остальные - прописные
Генерации часто используемых HTML-тегов, например <a href="..."></a>

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

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

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

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

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

Спасибо за внимание, подписавшись на Insight IT можно узнавать о новых материалах одним из первых :)

Добро пожаловать в Сказку! (вакансия закрыта)

Иван Блинков — Mon, 14 Mar 2011 15:32:00 +0300

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

Компания SKAZKA, российский разработчик и издатель онлайн-игр, ищет опытного веб-разработчика на Python. Предлагается работа в команде MMO-проекта "Королевство", а также участие в разработке ряда новых игр (одна в активной разработке, а другая проектируется).

О проекте

Проект "Королевство" состоит из 2-х частей:

непосредственно игра (сервер – C+Python, клиент – Flash)
социальная сеть – веб-часть проекта, содержащая все полагающиеся атрибуты соцсетей в реалиях игры (nginx, Python, Twisted, XSLT, memcached, PostgreSQL)

Обязанности

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

Требования к кандидату

Уверенное знание Python
Уверенное знание JavaScript
Знание XSLT
Умение разбираться в чужом коде
Умение объективно оценивать собственные трудозатраты по той или иной задаче и укладываться в поставленные сроки
Английский язык на уровне чтения технической документации
Коммуникабельность, дисциплинированность и ответственность
Приветствуется опыт работы над сложными/высоконагруженными web-проектами

Условия работы

Полный рабочий день в офисе в Москве (пять минут пешком от метро Третьяковская)
Работа над интересными, перспективными проектами
Отличная команда единомышленников, каждый из которых является профессионалом в своей области
Начало рабочего дня: с 10.00 до 12.00 (по желанию)
Зарплата: 50-100 тыс. руб. в месяц

Куда писать?

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

P.S.: Если Вы не дотягиваете до требований, но в Сказку хочется - все равно пишите, еще есть вакансия джуниора.

Архитектура DISQUS

Иван Блинков — Wed, 02 Mar 2011 03:37:00 +0300

DISQUS - самая популярная система комментирования и одновременно самое большое в мире Django-приложение. Она установлена более чем на полумиллионе сайтов и блогов, в том числе и очень крупных, таких как Engadget, CNN, MTV, IGN. Основной особенностью в её реализации является тот факт, что DISQUS не является тем сайтом, который хотят увидеть пользователи, он лишь предоставляет механизмы комментирования, авторизации и интеграции с социальными сетями. Пики нагрузки возникают одновременно c появлением какой-то шумихи в Интернете, что достаточно непредсказуемо. Как же им удается справляться с этой ситуацией?

Платформа

Linux - операционная система
Python - язык программирования
Django - основной framework
Apache 2.2 + mod_wsgi - веб-сервер
PostgreSQL - СУБД
memcached - кэширование
HAProxy - балансировка нагрузки
Slony - репликация данных
heartbeat - обеспечение доступности

Статистика

До 17 тысяч запросов в секунду
500 000 сайтов
15 миллионов зарегистрированных пользователей
75 миллионов комментариев
250 миллионов посетителей (на август 2010г.)

Основные трудности

Непредсказуемость нагрузки (основными причинами шумихи в Интернете являются катастрофы и выходки знаменитостей)
Обсуждения никогда не теряют актуальность (нельзя держать в кэше все дискуссии с 2008 года)
Нельзя угадать на каком сайте из тысяч возникнет пик трафика
Персональные настройки, динамическое разбиение на страницы и сортировки снижают эффективность кэширования
Высокая доступность (из-за разнообразия сайтов и их аудитории сложно запланировать технические работы)

Архитектура

Оборудование, в сумме около 100 серверов:
- 30% веб-серверов (Apache + mod_wsgi)
- 10% серверов баз данных (PostgreSQL)
- 25% кэш-серверов (memcached)
- 20% балансировка нагрузки и обеспечение доступности (HAProxy + heartbeat)
- 15% прочие сервера (Python скрипты)
Балансировка нагрузки:
- HAProxy:
  - Высокая производительность
  - Интеллектуальная проверка доступности
  - Неплохая статистика
Репликация:
- Используется Slony-I
- Основана на триггерах
- Master/Slave для обеспечения большего объема операций чтения
Высокая доступность:
- heartbeat
- Пассивная копия мастер баз данных на случай сбоя основной
Партиционирование:
- Реализовано на уровне кода
- Простая реализация, быстрые положительные результаты
- Два метода разделения данных:
  - Вертикальное:
    - Создание нескольких таблиц с меньшим количеством колонок вместо одной (она же нормализация)
    - Позволяет разделять базы данных
    - Данные объединяются в коде (медленнее, чем на уровне СУБД, но не намного)
    - Бартер производительности на масштабируемость
    - Более эффективное кэшировние
    - Механизм роутеров в Django позволяет достаточно легко реализовать данный функционал
  - Горизонтальное:
    - Некоторые сайты имеют очень большие массивы данных
    - Партнеры требуют повышенного уровня доступности
    - Помогает снижать загрузку по записи на мастер базе данных
    - В основном используется все же вертикальное партиционирование
Производительность базы данных:
- Особое внимание уделяется тому, чтобы индексы помещались в оперативную память
- Логирование медленных запросов (автоматизировано с помощью syslog-ng + pgFouine + cron)
- Использование пулов соединений (Django не умеет этого, используется pgbouncer, позволяет экономить на ресурсоемких операциях установления и прекращения соединений)
- Оптимизация QuerySet'ов:
  - Не используется чистый SQL
  - Встроенный кэш позволяет выделять части выборки
  - Но это не всегда нужно, они убрали этот кэш
- Атомарные операции:
  - Поддерживают консистентность данных
  - Использование update(), так как save() не является thread-safe
  - Отлично работают для таких вещей, как счетчики
- Транзакции:
  - TransactionMiddleware поначалу использовалось, но со временем стало обузой
  - В postgrrsql_psycopg2 есть опция autocommit:
    - Это означает что каждый запрос выполняется в отдельной транзакции
    - Обработка каждого пользовательского HTTP-запроса не начинает новую транзакцию
    - Но все же транзакции из нескольких операций записи в СУБД нужны (сохранение нескольких объектов одновременно и полный откат в случае ошибки)
    - В итоге все HTTP-запросы по-умолчанию начинаются в режиме autocommit, но в случае необходимости переключаются в транзакционный режим
Отложенные сигналы:
- Постановка в очередь низкоприоритетных задач (даже если они не длинные по времени)
- Асинхронные сигналы очень удобны для разработчика (но не так, как настоящие сигналы)
- Модели отправляются в очередь в сериализованном виде
Кэширование:
- Используется memcached
- Новый pylibmcна основе libmemcached в качестве клиента (проекты django-pylibmc и django-newcache)
- Настраиваемые алгоритмы поведения клиента
- Используется _auto_reject_hosts и _retry_timeout для предотвращения повторных подключений к вышедшим из строя кэш-серверам
- Алгоритм размещения ключей: консистентное хэширование на основе libketama
- Существует проблема, когда одно очень часто используемое значение в кэше инвалидируется:
  - Множество клиентов одновременно пытаются получить новое значение из СУБД одновременно
  - В большинстве случаев правильным решением было бы вернуть большинству устаревшие данные и позволить одному клиенту обновить кэш
  - django-newcache и MintCache умеют это делать
  - Заполнение кэша новым значением вместо удаления при инвалидации также помогает избежать этой проблемы
Мониторинг:
- Информация о производительности запросов к БД, внешних вызовов и рендеринге шаблонов записывается через собственный middleware
- Сбор и отображение с помощью Ganglia
Отключение функционала:
- Необходим способ быстро отключить новый функционал, если оказывается, что он работает не так, как планировалось
- Система должна срабатывать мгновенно, по всем серверам, без записи на диск
- Позволяет запускать новые возможности постепенно, лишь для части аудитории
- Позволяет постоянно использовать основную ветку кода
- Аналогичная система используется и в Facebook
Масштабирование команды разработчиков:
- Небольшая команда
- Месячная аудитория / количество разработчиков = 40 миллионов
- Это означает:
  - Автоматическое тестирование
  - И максимально простой процесс разработки
- Новый сотрудник может начать работать уже через несколько минут, нужно лишь:
  - Установить и настроить PostgreSQL
  - Скачать исходный код из git
  - С помощью pip и virtualenv установить зависимости
  - Изменить настройки в settings.py
  - Выполнить автоматическое создание структуры данных средствами Django
Непрерывное тестирование:
- Ежедневное развертывание с помощью Fabric
- Hudson обеспечивает регулярно осуществляет и тестирует сборки
- Интегрирован Selenium
- Быстрое тестирование с помощью Pyflakes и post-commit hooks
- 70 тысяч строк Python кода, 73% покрытие тестами, прогон всех тестов занимает 20 минут
- Собственная система исполнения тестов с поддержкой XML, Selenium, подсчета количества запросов, тестирования Master/Slave базы данных и интеграцией с очередью
Отслеживание проблем и задач:
- Переключились с Trac на Redmine (из-за поддержки под-задач)
- Отправка исключений на e-mail - плохая идея
- Раньше использовали django-db-log, но теперь опубликовали свою систему сбора ошибок и логов под названием Sentry

Делаем выводы

Язык программирования, каким бы он ни был, не является проблемой
Django в целом очень хорош (но приходится все же использовать набор собственных патчей)
Даже при использовании низкопроизводительного framework можно построить масштабируемую систему
Вертикальное партиционирование позволяет пожертвовать производительностью в пользу масштабируемости
Даже небольшой командой разработчиков можно добиться высоких результатов, если не пренебрегать автоматизацией тестирования
Большое значение имеет возможность вовремя отслеживать и оперативно реагировать на сбои

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

Данная статья написана на основе выступления Jason Yan и David Cramer на DjangoConf 2010. В презентации можно найти примеры кода, ссылки на упоминаемые проекты и дополнительные материалы:

Другие статьи по масштабируемости высоконагруженных систем можно почитать в соответствующем разделе, а вовремя узнавать о новых - подписавшись на RSS. Вчера, кстати, прикрутил DISQUS к Insight IT, приглашаю постоянных читателей и всех остальных потестировать :)

Piccolo - построение распределенных систем в 11 раз быстрее Hadoop

Иван Блинков — Sat, 12 Feb 2011 23:49:00 +0300

Piccolo - это система для распределенных вычислений, использующая новую ориентированную на данные модель программирования для разработки приложений по параллельным вычислениям в памяти в масштабах дата-центров. В отличии от существующих моделей, основывающихся на потоках данных, Piccolo позволяет вычислениям выполняться на различных машинах, при этом имея общее изменяющееся состояния через интерфейс таблиц пар "ключ-значение". Традиционные ориентированные на данные модели (такие как используются в Apache Hadoop) предоставляют пользователю для работы лишь единственный объект в определенный момент времени, когда в Piccolo используется глобальная таблица состояний, одновременно доступная для всех частей вычисления. Это позволяет пользователям указывать алгоритм вычисления в интуитивно-понятной манере, очень похожей на разработку программ для одного компьютера.

Использование хранилища, позволяющего хранить в памяти пары "ключ-значение", сильно отличается от канонического подхода map-reduce, который основан на распределенных файловых системах. Результаты впечатляют:

Эксперименты показали, что Piccolo очень быстр и отличные возможности по масштабируемости для многих прикладных задач. Производительность вычисления PageRank и k-средних выросла в 11 и 4 раза, соответственно, по сравнению с Hadoop. Вычисление PageRank для связанного графа из 1 миллиарда страниц заняло лишь 70 секунд на 100 машинах в Amazon EC2. Распределенная система по скачиванию веб-страниц легко может полностью загрузить 100Мбит интернет-канал при работе на 12 машинах.

При разработке на Piccolo программисты создают наборы прикладных функций, которые принято называть ядром. Функции ядра запускаются параллельно на нескольких вычислительных узлах, при этом у них есть доступ к общему изменяемому состоянию, которое реализовано в виде набора таблиц, располагающихся в оперативной памяти различных узлов системы. Для доступа к этому состоянию используется примитивный интерфейс, позволяющий узнать (get) и изменить (put) то или иное состояние. Процесс отправки сообщений удаленным узлам, непосредственно имеющим в памяти требуемые данные, полностью берет на себя сам код Piccolo.

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

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

В Piccolo используется ряд оптимизаций, обеспечивающий не только удобное использование интерфейса к таблице состояний, но и его быстроту:

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

Проект реализован в виде библиотеки для Python и C++. Более детально примеры использования и принципы работы системы разбираются в источниках информации (правда на английском), не поленитесь - загляните. Вместо заключения хотелось бы по традиции порекомендовать подписаться на RSS блога, если Вы еще этого не сделали.

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

Russell Power - автор проекта Piccolo
Piccolo: Building Fast, Distributed Programs with Partitioned Tables
Проект был презентован на OSDI10: презентация и видео

Django в гостях у Google

Иван Блинков — Mon, 19 Oct 2009 23:53:00 +0400

~~Давным-давно, в далекой-предалекой галактике...~~

Хотя да, достаточно давно уже Google выпустили в свет платформу Google App Engine. Описание этого продукта меня заинтересовало еще до открытия публичного доступа к системе и я даже записался на полу-закрытое тестирование. Вскоре пришло подтверждение, что мол "мы рады сообщить, что Ваша учетная запись активирована и теперь у Вас есть возможность попробовать наш новый продукт, для этого нажмите ссылку такую-то". Но пришло оно как-то не очень удачно, когда ни лишнего свободного времени не было, да и идеи подходящей для создания чего-нибудь эдакого на новой платформе тоже на горизонте не наблюдалось. В общем зашел на их сайт, посмотрел админку, поставил демо-приложение, поигрался чуток и забросил. Но с тех пор руки так и не прекращали чесаться от желания попробовать GAE на каком-нибудь более приближенном к реальности приложении, что мне совсем недавно и довелось сделать. Спешу поделиться впечатлениями. Если Вы даже краем уха не слышали о платформе Google App Engine и после прочтения вступления не удосужились скопировать это название в свою любимую поисковую систему, чтобы почитать по-подробнее, то Вам повезло: для порядка я все-таки расскажу чуть-чуть о тех вкусностях, которые так долго поддерживали мой интерес к данному проекту.

Если взглянуть издалека, то GAE представляет собой условно-бесплатный хостинг для веб-приложений, для разработчиков предоставляется все необходимое: начиная от минимально-необходимого SDK со встроенным веб-сервером, локально эмулирующим саму платформу, заканчивая неплохой документацией по самой системе и доступным из нее API от Google. Почему условно-бесплатный? Бесплатно приложениям выделяется лишь ограниченное количество вычислительных ресурсов, при превышении которых по выбору владельца приложения либо взимается вполне скромная плата, либо всем пользователям начинают показывать "извиняйте, заходите завтра" (в прямом смысле, счетчики потребления ресурсов сбрасываются ежедневно).

Но финансовый вопрос далеко не самый интересный, давайте взглянем на техническую сторону медали. Написанное с использованием SDK приложение загружается в production-окружение, которое физически размещается на тех самых известных кластерах Google, о которых у меня даже есть пост (конечно же под GAE используется только очень небольшая часть их вычислительных можностей). Причем все заботы о распределенной работе приложения на большом количестве машин платформа берет на себя: разработчику не нужно думать ни о балансировке нагрузки, ни о партиционировании данных, ни о других аспектах. Сразу же после окончания процессов загрузки и развертывания приложение готово становится готово к работе и доступно по домену третьего уровня на *.appspot.com, либо можно подключить свой отдельный домен.

Технические ограничения тоже имеют быть: для разработки под GAE можно использовать лишь небольшой набор языков программирования, в частности Python 2.5, а также Java и все остальные языки, компилируемые или интерпретируемые под JVM (JRuby, Scala, Rhino, etc.). Все приложения исполняются в песочнице, ограничивающей доступ к окружающему миру, то есть определенные подмножества языков становятся недоступны, например: доступ к файловым системам, встроенные средства обработки изображений, доступ к сторонним ресурсам по HTTP, отправка почты. Про реляционные базы данных, memcached и библиотеки, использующие нативный, платформозависимый код, также стоит забыть. Но не все так плохо, как кажется: для реализации всех "отобранных" у разработчиков функциональных компонент Google предоставляет собственные сервисы-заменители, доступные через хорошо документированный API или вовсе замаскированные под стандартные методы языка. В качестве дополнительных бонусов предоставляются и возможности по интеграции с другими продуктами Google, скажем можно легко сделать авторизацию пользователей в приложении по учетным записям от GMail или нотификацию пользователей по Jabber через GTalk.

Отдельного внимания заслуживает используемая в данной платформе система хранения данных, основанная на BigTable, о которой более подробно можно почитать в уже упомянутом посте об архитектуре Google. Если в двух словах, то она представляет собой распределенное нереляционное хранилище данных, автоматически обеспечивающее репликацию и кеширование данных, а также практически гарантирующее постоянную доступность данных вне зависимости от сбоев низлежащего оборудования. Для доступа к нему разработчикам предоставляется специальный API и язык доступа к данным GQL, слегка напоминающий упрощенный диалект SQL (лишь отдаленно). Продукт в обращении достаточно своеобразен, как оказалось самый простой способ привыкнуть к работе с ним - выкинуть из головы все знания о традиционных СУБД и взглянуть на процесс хранения данных с чистого листа. Разномастные JOIN'ы и прочие изыски лишь мешают думать в терминах подобных систем.

Закончив тему с рекламой GAE, позвольте перейти к моим личным впечатлениям. Попробовал я данную платформу на вполне конкретном примере (в конце поста дам ссылочку на частично-готовый результат, если кому интересно), надо же в конце-концов на что-то с пользой убивать внезапно появившееся свободное время. ОтJava и прочей компании языков, основанных на JVM, я невероятно устал на теперь уже "прошлой" работе, так что взор мой упал на Python и давно находящийся у меня на слуху (в основном благодаря Ивану Сагалаеву) фреймворк Django. Ни с тем, ни с другим я ранее почти не был знаком на практике, разве что когда-то пытался помогать своим очень хорошим подругам с прохождением Python в университете (пользуясь случаем, передаю привет Полине, Кате и Юле, очень по вам скучаю ;) ). Стоит упомянуть, что существует несколько сборок Django, адаптированных под GAE, наиболее продуманным и готовым к эксплуатации мне показался проект под названием app engine patch, которым я и воспользовался для экспериментов.

Django, как известно, является вполне традиционным веб-фрейморком, пропагандирующим свою вариацию на тему MVC (именуемую MVT - Model-View-Template, но по сути абсолютно то же самое), а также целый ряд философских верований (вроде DRY, Don't repeat yourself), которым даже отведена отдельная страница на официальном сайте. Адаптированная под GAE версия фреймворка отличается от стандартной по большому счету лишь замененной частью Model, в которую очень неплохо вписался предоставляемый API к уже упоминавшемуся хранилищу данных. По всем остальным компонентам системы официальная документация по Django практически полностью актуальна и сильно помогла понять всю картину разработки веб-приложений с использованием данных технологий.

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

Предложение Google по использованию платформы GAE выглядит очень заманчиво, не смотря на все ограничения под нее можно как портировать существующие приложения, так и легко создавать новые. Бесплатное использование до превышения квот также не может не радовать (кстати квоты там рассчитаны на мировой рынок, превысить большинство из них в рамках рунета - надо постараться, мне кажется). Но закончить данное повествование мне всетаки хотелось парой недокументированных или вкратце официально упоминавшихся "ложек дегтя". Первая неприятная особенность: процессы, обрабатывающие пользовательские запросы приложений, умирают после очень небольшого времени простоя (таймаут судя по всему секунд 20-30). По истечении таймаута система освобождает использующиеся приложением ресурсы и когда после перерыва приходит очередной пользователь система вынуждена заново инициализироваться (чуть ли не заново компилировать байткод, хотя не уверен), что занимает около 5 секунд, а то и больше, во время которых пользователю ничего не остается кроме как терпеливо ждать. Сделали данный механизм видимо в связи с тем фактом, что подавляющее большинство развернутых приложений были сделаны просто чтобы побаловаться и были сразу же заброшены, что делает неэффективным постоянное держание в готовом состоянии даже одного процесса для каждого приложения. Таким образом использование GAE для тяжелых веб-приложений с небольшой целевой аудиторией не очень эффективно. Минус второй: существуют некоторые жесткие ограничения, которые не разрешают увеличивать даже за деньги (по крайней мере расценок не видно). В их число входят максимальное время обработки одного запроса (30 секунд, правда не ясно распространяется ли это на выполнение задач в Task Queue и местном аналоге Cron'а), 30 активных процессов, обрабатывающих запросы приложения (что влечет за собой достаточно жесткое ограничение на количество запросов в секунду в районе нескольких сотен), максимальный размер HTTP запроса/ответа в 10 мегабайт и некоторые другие. В итоге "тяжелые" вычисления на GAE не погоняешь (хотя есть варианты с применением AJAX и, соответственно, большого количества запросов к GAE), от Digg-эффекта или DDOS'а есть шанс не уберечься, хостинг файлов не соорудить, но... разве это ограничения? Есть масса более интересных типов веб-приложений, способных прекрасно существовать в такой среде. Да и в крайнем случае всегда можно связаться с представителями Google с просьбой в виде исключение для Вашего приложения, судя по их заявлениям все ограничения носят искусственный характер и служат лишь для защиты от потребления неоправданно большого количества вычислительных ресурсов плохо спроектированных приложениями.

Кстати в американской части Интернета о GAE ходят в основном негативные мнения, мол тормозит, большое время отклика, сплошные таймауты и ошибки. На практике пока не удалось столкнуться с чем-то подобным, но реально работающего приложения с активной пользовательской базой у меня пока нет для того, чтобы делать какие-то относительно объективные выводы. Может быть со временем что-нибудь изменится и более тонкие нюансы станут выползать на поверхность - время покажет. Как раз будет повод написать еще один пост на эту же тему :)

Архитектура YouTube

Иван Блинков — Sat, 01 Mar 2008 16:07:00 +0300

Рост YouTube был феноменально быстр, количество просмотров видео превысило 100 миллионов в сутки при том, что только около пяти человек работало над масштабированием проекта. Как им удается управлять предоставлением всех этих видеороликов своим посетителям? Как они развивались с тех пор, как были приобретены Google?

Платформа

Apache
Python
Linux (SuSe)
MySQL
psyco, динамический компилятор Python → C
lighttpd для видео

Что внутри?

Статистика

Поддержка обработки более 100 миллионов видеороликов в сутки
Сервис был запущен в феврале 2005 года
В марте 2006 года в среднем производилось около 30 миллионов просмотров видео в день
К июлю 2006 года эта цифра достигла 100 миллионов просмотров в день
Над проектом работают: 2 системных администратора, 2 архитектора масштабируемости программного обеспечения, 2 разработчика новых возможностей, 2 инженера по сетям, 1 архитектор баз данных

Рецепт управления огромными темпами роста

while (true)
{
   identify_and_fix_bottlenecks();
   drink();
   sleep();
   notice_new_bottleneck();
}

Этот цикл проходит далеко не одну итерацию ежедневно.

Веб-серверы

NetScalar используется для балансировки нагрузки и кэширования статического контента.
Apache работает с включенным mod_fast_cgi
Запросы отправляются на обработку с помощью серверного приложения на Python.
Приложение взаимодействует с различными базами данных и другими источниками информации для формирования финальной HTML-страницы.
Масштабирование обычно происходит просто добавлением дополнительных компьютеров.
Код на Python обычно не является узким местом системы, он проводит большую часть времени заблокированным RPC.
Python предоставляет быстроту и гибкость в процессе разработки и развертывания. Этот факт является очень актуальным, если учесть кто является их конкурентами.
На формирование страницы обычно уходит не более 100 миллисекунд.
psyco, динамический компилятор Python → C, использует JIT подход к компилированию для оптимизации внутренних циклов
Для интенсивных вычислений, таких как шифрование, используются расширения, написанные на C.
Какая-то часть заранее сгенерированного HTML хранится в кэше.
Кэширование данных в СУБД на уровне строк.
Кэшируются полностью сформированные объекты Python.
Некие данные вычисляются и отправляется каждому серверу для кэширования в локальной оперативной памяти. Эта стратегия годится далеко не всегда, чаще всего более эффективен другой метод: самым быстрым кэшем является само серверное приложение, а отправка уже готовых данных остальным серверам для дальнейшей обработки обычно не занимает так много времени. Для организации такого подхода необходимы агенты, осуществляющие отслеживание изменений, предварительную обработку и отправку данных.

Управление видео

Издержки включают в себя затраты на пропускную способность каналов связи, приобретение нового оборудования и оплату огромных счетов за электроэнергию.
Каждый видеоролик расположен на мини-кластере, что означает управление работой с ним группой из нескольких компьютеров.
Использование кластеров влечет за собой: – увеличение производительности пропорционально количеству дисков, на которых расположен контент; – возможность поддержания функционирования всей системы даже в случае прекращения работоспособности части компьютеров; – возможность организации создания резервных копий online.
В роли HTTP-сервера для работы с видео используется lighttpd: – Он способен дать фору Apache в плане производительности предоставления статического контента; – Для работы с событиями ввода-вывода используется epoll; – Многопоточная конфигурация способна обрабатывать большее количество соединений одновременно;
Самая популярная часть контента размещается в CDN – CDN реплицирует весь контент в разных частях системы; – Компьютеры CDN в основном предоставляют данные напрямую из кэша в оперативной памяти, так как ассортимент популярного видео с течением времени меняется достаточно медленно.
Менее популярный контент, количество просмотров в день которого варьируется в диапазоне от одного до двадцати, обычно размещается на серверах YouTube, расположенных в датацентрах на colocation: – Не смотря на тот факт, что такое видео может быть просмотрено всего несколько раз за день, количество таких роликов велико, что приводит к случайным блокировкам данных на жестких дисках; – В такой ситуации кэширование практически бесполезно, инвестиции в кэширование контента с низкой вероятностью востребованности обычно является пустой тратой средств; – Более детальная настройка низкоуровневых компонентов системы, таких как, например, RAID-контроллеры, в этой ситуации может достаточно положительно повлиять на производительность; – Выбор оптимального размера оперативной памяти на каждой машине также очень важен: как недостаточное, так и излишнее ее количество не являются эффективными решениями.

Ключевые моменты

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

Управление миниатюрами видео

На удивление сложно решаемая задача, особенно если необходима эффективность;
Для каждого видео хранится 4 миниатюры, что приводит к существенному преобладанию количества миниатюр над количеством видеороликов;
Миниатюры хранятся всего на нескольких компьютерах;
Некоторые проблемы наблюдаются в связи с работой с большим количеством маленьких объектов: – Проблемы на уровне операционной системы, связанные с большим количеством запросов на поиск данных, а также кэшем страниц и inode'ов файловой системы; – Ограничение на количество файлов в одной директории (особенно актуально для ext3), возможно частичное решение в виде перехода к более иерархической структуре хранения данных, а также переходе к ядру Linux версии 2.6, что может привести к более чем стократному росту производительности, но в любом случае хранение такого огромного количества файлов в локальной файловой системе - не самая лучшая идея; – Большое количество запросов в секунду, так как одна страница может содержать до 60 миниатюр различных видеороликов; – В условиях таких нагрузок Apache показывает плохую производительность; – Проводились эксперименты с использованием squid (обратной proxy) между Apache и посетителями. Какое-то время такой вариант казался работоспособным, но с ростом нагрузки производительность начала падать. С обработки 300 запросов в секунду она упала до 20; – Попытки использовать lighttpd также не завершились успехом: однопоточный режим не справлялся с задачей, а многопоточный требовал отдельного кэша для каждого потока, что сводило на нет его эффективность; – С таким количеством изображений добавление в систему нового компьютера могло занимать более 24 часов; – Перезагрузка занимала 6-10 часов, так как кэш должен был "разогреться" прежде чем перестать использовать данные с жестких дисков.
Решением всех описанных выше проблем стала распределенная система хранения данных BigTable от Google: – Она позволяет избежать проблем, связанных с большим количеством файлов, так как объединяет маленькие файлы вместе. – Она работает быстро и устойчива к сбоям, помимо этого она прекрасно приспособлена для работы по ненадежной сети. – Уменьшает задержки, так как использует распределенный многоуровневый кэш, который способен работать даже между удаленными датацентрами.

Базы данных

Раньше: – MySQL использовалась для хранения данных: пользователей, тэгов, описаний и так далее. – Данные хранились на монолитном RAID 10 массиве, состоящем из 10 жестких дисков; – Оборудование арендовалось, что негативно сказывалось на состоянии их кредитных карточек. В случае необходимости нового оборудования, на оформление заказа и доставку мог уходить далеко не один день. – Они прошли через весь путь эволюции: сначала был один сервер, затем добавилось несколько дополнительных серверов, обслуживающих операции чтения, после чего они решили разбить базу данных на части, и, наконец, они пришли к полноценной распределенной архитектуре. – Поначалу их система страдала от задержек, связанных с реплицированием. Основной сервер, обрабатывающий операции записи, являлся мощным сервером, работающим в многопоточном режиме, это было необходимо для своевременного выполнения большого объема работы. Второстепенные сервера, которые обрабатывали только операции чтения, асинхронно реплицировали данные в одном потоке, что влекло за собой возможность серьезного отставания некоторых из них. – Обновления были причиной частого отсутствия необходимой информации в кэше, что заставляло сервера читать данные с жестких дисков. Этот факт сильно замедлял процесс чтения и репликации. – Реплицирующая архитектура требует немалых вложений в оборудование, необходимого для поддержания постоянно растущих темпов записи информации. – Основным из кардинальных решений, принятых в архитектуре системы было отделение обеспечения процесса просмотра видео от основного кластера. Основной целью посетителей является просмотр видео, а второстепенные задачи можно возложить и на менее производительный кластер.
Сейчас: – Используются распределенные базы данных; – Сегментированная система (прим.: по аналогии с Flickr); – Распределенные чтение и запись; – Более эффективное расположение кэша, что ведет к уменьшению работы с жесткими дисками; – Такая архитектура привела к 30%-й экономии на оборудовании; – Задержки в реплицировании сведены к нулю; – Размеры базы данных могут расти практически неограниченно

Стратегия размещения в датацентрах

Поначалу использовались хостинг провайдеры, предоставляющие услуги colocation. Не самый экономичный подход, но тогда не было другого выхода.
Хостинг провайдеры не могут поспеть за темпами роста проекта. Не всегда получается получить контроль над необходимым оборудованием или сделать необходимые соглашения о предоставлению сетевых услуг.
Решением этой проблемы стало создание собственной базы для размещения оборудования. Появилась возможность настраивать абсолютно все и подписывать свои собственные контракты такого рода.
Было использовано 5 или 6 разных датацентров в дополнение к CDN.
Видео поступает из случайного датацентра, никаких специальных проверок не проводится. Если ролик становится достаточно популярным - он перемещается в CDN.
Основным фактором, влияющим на доступность того или иного ролика является пропускная способность канала связи.
Для изображений же более актуальны задержки, особенно если на одной страницы должно быть размещено под 60 изображений.
Репликация изображений производится средствами BigTable. В этом случае используются различные меры для определения ближайшего места, откуда можно получить необходимые данные.

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

Остановитесь на секунду. Креативные и рискованные трюки могут помочь справиться с задачей в краткосрочном периоде, но со временем понадобятся более продуманные решения.
Расставьте приоритеты. Определите какие части Вашего сервиса являются более важными и стройте систему обеспечения ресурсами и усилиями именно в соответствии с поставленными приоритетами.
Выбирайте свои битвы. Не бойтесь пользоваться аутсорсингом в некоторых ключевых сервисах. YouTube использует CDN для распределения своего наиболее популярного контента. Создание своей собственной подобной сети стоило бы им слишком много и потребовало бы слишком много времени. Возможно у Вас появятся подобные возможности в отношении Вашей системы.
Будьте проще! Простота позволяет изменять архитектуру более быстро, что позволяет своевременно реагировать на возникающие проблемы. Никто на самом деле не знает что такое простота, но если Вы не боитесь делать изменения, то это неплохой знак что вашей системе свойственна та самая простота.
Сегментирование. Сегментирование позволяет изолировать и ограничить дисковое пространство, процессорное время, оперативную память и ввод-вывод. Оно выполняется не только для повышения производительности операций записи.
Постоянная работа над поиском и устранением узких мест в системе: – на программном уровне это чаще всего бывает кэширование и работа с СУБД; – на уровне операционной системы - операции ввода-вывода; – на уровне оборудования - оперативная память и RAID массивы.
Залог Вашего успеха - командная работа. Хорошая команда разного рода специалистов должна понимать принцип системы вцелом и того, что лежит под ней. Каждый должен знать свое дело: настраивать принтеры, подключать к системе новые компьютеры, строить сети и так далее. С отличной командой Вам по силам все что угодно.

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

В отличии от остальных, этот перевод статьи от Todd Hoff'а уже был выполнен до меня (при желании можно найти в любой поисковой системе), но я все равно решил опубликовать свою версию просто для собственного развития и полноты коллекции, да и многим читателям, возможно, покажется интересным. Что ж, перейдем к источнику информации оригинала:

Google Video