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

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

Архитектура 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, приглашаю постоянных читателей и всех остальных потестировать :)