2. Обо мне
• Павел Брылов
• Родом из Казахстана, три года в Эстонии
• Переехал по приглашению Skype и не жалею
• До Skype работал начальником Отдела развития Интернетпроектов Казахстанской фондовой биржи
3. Обо мне
• Работаю разработчиком в команде Wallet team (ex. Secure Web)
• Мы занимаемся платежами, интеграцией с платежными
провайдерами, предоставлением API для совершения платежей всем
остальным подразделениям Skype
• Ввиду очевидной важности платежей, много работаем над
улучшением инфраструктуры, технической и организационной части
процесса, чтобы обеспечить бесперебойную работу
4. О чем доклад?
• О PHP!
• О том как мы (практически) избавились от монилитного приложения,
и построили “облачную” SOA архитектуру
• О практиках и подходах, которые мы считаем обязательными для того
чтобы работать с большими нагрузками
• О том как взять инфраструктуру в свои руки, и быть уверенным что
каждый из тысяч серверов настроен так же как остальные
6. Несколько лет назад
• Монолитные приложения на каждый user-faced компонент:
• Компоненты тесно связаны между собой, изменение в каком-то общем классе
влечет к немедленным изменениям везде где он используется
• Боязнь что-то менять, изменение одной строчки может сломать что угодно где
угодно
• Очень много кода, несколько общих библиотек, которые менять еще страшнее
• Высокая стоимость внесения изменений, сложно предсказать временные
рамки
7. Несколько лет назад
• Монолитные приложения на каждый user-faced компонент:
• Одна большая команда которая занимается всеми компонентами. Shared
responsibility = no responsibility
• Спасает только тестирование. Всего функционала. Занимает долгое время,
даже с учетом автоматизации
• Длинные релизы, длинное тестирование, редкий деплоймент
• Масштабируются, но непредсказуемо. Баг в одном месте влияет на всю систему
в целом
8. Несколько лет назад
• Production сервера настраиваются практически вручную
• Настройка серверов занимает дни, а то и недели
• Даже с готовыми образами операционной системы, слишком много дополнительных
настроек
• Все настройки документированы, но поддерживать документацию в актуальном
состоянии очень трудно
• Быстро выкатить несколько новых серверов в случае пика нагрузки практически
невозможно
• Код деплоится с помощью svn export из тэга, все зависимости - вручную
10. Нет, так не может продолжаться
Любой стартап достигает фазы когда технический долг мешает развитию
11. Stratus
• Все началось с фреймворка на PHP, но вскоре переросло в
архитектурную модель с набором договоренностей
• Не зависит от языка программирования и платформы: сейчас в
той же архитектуре прекрасно сосуществуют приложения на
Python, Node.JS и .NET. Работает как на Linux так и в Windows
Azure
12. Stratus
• Service oriented architecture:
• Вместо большого монолитного приложения много небольших, выполняющих
определенную задачу, и установленных на свой собственный сервер
• Приложения предоставляют и используют API других приложений, таким образом
имплементация может меняться как угодно, прозрачно для остальных компонентов
• SLA и версионизирование гарантирует пользователям API что им не прийдется срочно
менять свой код, если другой компонент изменился
• Четкая изоляция сервисов позволяет лучше планировать нагрузку, и дает возможность
для graceful degradation в случае недоступности сервиса
13. Stratus
• REST + JSON
• Общее дерево REST ресурсов для всех приложений: позволяет
разделять одну и ту же логическую группу ресурсов между
разными приложениями
• Автоматическое нахождение сервисов (Service auto discovery)
15. Stratus
• Приложение регистрируется в Registry, сообщая всю информацию о
себе: какие ресурсы оно предоставляет, какие html страницы может
обслуживать, на каких Gateway должно присутствовать
• Registry в свою очередь передает эту информацию на Gateway (load
balancer), что делает эти ресурсы доступными для пользователя
• Registry знает все и обо всем, и ничем кроме этого не занимается
• Gateway - точка входа и балансировщик нагрузки одновременно
17. Stratus
• Четыре обязательных интерфейса для каждого приложения:
• /stratus/register – Регистрирует приложение в Registry
• /stratus/manifest – Возвращает информацию о приложении, его версии,
библиотеках которые это приложение использует и т.д.
• /stratus/info – Возвращает все доступные в этом приложении ресурсы, в
купе с параметрами, их типами и комментариями об их назначении
• /stratus/health – Сообщает о состоянии приложения
18. Stratus PHP Framework
• Написан на PHP:
• PHP сильно эволюционировал со времен PHP4, о котором все с удовольствием
шутят. Сегодня это полноценный язык с вполне адекватной реализацией ООП
• Вырос не только язык, но и инфраструктура вокруг него: PHPUnit, CodeSniffer,
PHPMD, Composer, behat и другое
• Низкий уровень входа в язык является и плюсом и минусом: много “PHP
программистов на Wordpress”, мало тех кто пишет действительно хороший код
20. <?php
namespace SkypeHighLoad;
class Greeter extends SkypeStratusLocatorAbstractService
{
/**
* Greet HighLoad.ru participant
*
* @param string $username Username
*
* @return object Greeting object
*/
public function greet ($username)
{
return (object)array(
'message' => sprintf("Hello, HighLoad.ru, and especially %s!“, $username)
);
}
}
service.properties:
[service]
HighLoadGreeter.server = "#class:SkypeHighLoadGreeter"
21. Stratus PHP Framework
• Stratus Core - ядро фреймворка, содержит только базово необходимый
функционал:
• Request/Response negotiation
• Работа с Registry и обязательные для всех приложений REST ресурсы
• Реализация Dependency injection
• Базовые классы для конфигурации приложения, логгер
• Работа с аннотациями методов на базе Reflection API
• Core - единственная обязательная часть для Stratus приложений написанных на
PHP
23. Stratus framework
• А все остальное в версионизированных библиотеках
• Зависимости управляются Maven’ом. Изменения в библиотеке больше
не сломают ваше приложение
• Stratus Maven плагин:
• Раскладывает зависимости собранные Maven’ом в определенную структуру,
для дальнейшей упаковки в .deb пакет
• Прогоняет PHPUnit тесты, CodeSniffer, PHPMD, PHPCPD, Code Coverage
• Генерирует документацию с помощью Doxygen
24.
25. Stratus framework
• Самые популярные Stratus библиотеки:
• Db – библиотека для работы с БД, поддерживает «асинхронные» запросы
• HttpClient – библиотека для работы с HTTP сервисами на базе curl,
поддерживает «асинхронные» запросы
• Cache – предоставляет сервисы для работы с различными кешами, и
абстракцию над кешом на уровне логики (InstanceStash, SharedStash т.д.)
• Jobs/Consumer – библиотеки для выполнения фоновых заданий и работе с
очередями
26. Continuous Integration
• Билд сервер следит за изменениями в репозиториях, при наличии изменений
запускает Maven, собирает SNAPSHOT пакет и загружает в тестовый deb
репозиторий
• Полученный пакет автоматически устанавливается на тестовые машины
• В тестовом окружении постоянно бегают integration тесты. Если вы что-то сломали,
вы об этом узнаете
• Когда приложение готово к релизу, билд сервер повторяет процедуру, но собирает
релиз пакет, который при условии отсутствия в нем багов попадет в продакшн
27. Continuous Integration
• Integration тесты написаны на Python и запускаются тестовым фреймворком Taffy
• Тестируются как внутренние и внешние API, так и full flow тесты в браузерах с
использованием Selenium и WebDriver
• Тесты, как и все остальное относящееся к приложению находятся в одном с ним
репозитории
• Результаты тестирования аггрегируются в web-интерфейсе, таким образом все
заинтересованные, включая менеджемент, могут в любой момент посмотреть
готов ли компонент к деплою в production
28. В итоге
• Все компоненты логически разделены и изолированы, внесение изменений не вызывает
страха. Время и стоимость изменений легко прогнозируется
• Вместо одной большой команды, занимающейся всем на свете, несколько небольших,
сконцентрированных на своих компонентах и библиотеках. Работа над общими
компонентами ведется по логике open source: pull request’ы, ревью и т.д.
• Так как мы строим свои сервисы на базе тех же API, которые предоставляем пользователям,
мы уверены в их качестве и стабильности
• Легко горизонтально масштабировать: простым добавлением серверов с приложением, на
которое увеличилась нагрузка
30. Chef
• Система автоматизации инфраструктуры, гарантирует что все сервера с
определенной ролью/набором рецептов будут настроены одинаково
• Разработчик приложения - тот кто знает как оно должно быть настроено
• Мы не любим писать документацию, зато мы любим писать код
• Мы тестируем наши приложения, но мы не тестируем нашу инфраструктуру.
Это не правильно
• Ruby с простым DSL, порог вхождения минимальный
31. package “apache2” do
action :install
version “2.2.23”
end
service “apache2” do
action :enable
supports :restart => true, :reload => true
end
template “/etc/apache2/conf/httpd.conf” do
source “httpd.conf.erb”
mode 0644
variables(
:server_name => “highload.ru”,
:doc_root => “/usr/local/apache2/htdocs”
)
notifies :restart, "service[apache2]“
end
httpd.conf.erb:
ServerName <%=@server_name %>
DocumentRoot "<%=@doc_root %>"
32. Chef
• Все измнения в cookbook’ах проходят тот же путь что и
приложения: разработка, тестирование, пакетирование и
деплоймент
• Тестирование с помощью foodcritic и test-kitchen
• Knife плагин для работы с репозиторием
33. Chef
• Версионизированные роли: stratus-highload-1-0
• Постепенное развезтывание (Gradual rollout)
• Обработчики ошибок (Exception и Report handlers)
• Автоматическое добавление в мониторинг
34. Cloud
• Chef - очень мощный инструмент, но всю свою мощь он показывает в облачной
инфраструктуре
• Собственная cloud платформа на базе XEN
• Позволяет иметь одинаковые контейнеры в тестовом окружении и в production
• Создать 10 серверов для приложения можно одной командой:
• knife cloud server create [cloud name] [application-role] -c 10
• Аналогичные плагины есть для Windows Azure, Amazon EC2, Rackspace, Linode и т.д.
36. Relman
• Все измнения в базе данных проходят тот же путь что и приложения:
разработка, тестирование, пакетирование и деплоймент
• Relman – программный продукт для деплоя на разные сервера БД
• UI для деплоймента позволяет в интерактивном режиме смотреть diff
функций, таблиц и других компонентов баз данных, давая возможность DBA
быстро и наглядно увидеть что конкретно они деплоят
• Даже в ручном режиме relman позволяет двум администраторам базы
данных деплоить ~150 релизов в неделю
38. -- database: highloaddb (highload_user)
CREATE OR REPLACE FUNCTION “highload_${db.safe_version}”.list_participants(
OUT status int,
OUT status_text text,
OUT id_participant bigint,
OUT name text
) RETURNS SETOF record AS $BODY$
BEGIN
RETURN QUERY
SELECT 200, 'OK'::text, p.id_participant, p.name
FROM highload.participants p;
RETURN;
END;
$BODY$ LANGUAGE plpgsql SECURITY DEFINER;
release.yaml
- !tables:
- ./tables/participants.yaml
- highloaddb:
- sql_file: highload/participants.data.sql
41. Air Traffic Control
• Центр управления полетами на базе тикет системы
• Следит за всем что происходит вокруг и реагирует на изменения:
• Создает деплоймент задания с полным changelog-ом и списком коммитеров
• Запускает релевантные тесты и добавляет результаты к таску
• Отмечает и следит за зависимостями
• Мониторит статус задания, и как только он достигает статуса «Deploy to production» и все
зависимости задеплоены - инициирует автоматический gradual deployment
• Skype бот, сообщающий всем заинтересованным лицам о том какие изменения
происходят с теми компонентами над которыми они работают
42. Будущее
• Windows Azure!
• Свое облако хорошо – но сложно, и дорого
• C#/.NET
• Абсолютная уверенность в том что эта миграция пройдет легко и
непринужденно
