We’ll talk about a path that we’ve gone through @ Concert.ua: from a ticketing start-up to a leader of the ticketing market of the country. DDOS, f*ck-ups and victories. How did we manage to overcome a monolith piece of software and got to a distributed web-application architecture with high peak loads.

1. От Legacy до High-load
Эволюция веб-приложения
Евгений Лысенко
Concert.ua

2. ОТ LEGACY ДО
HIGH-LOADЭВОЛЮЦИЯ ВЕБ-
ПРИЛОЖЕНИЯ

3. КТО МЫ?

5. С ЧЕГО НАЧИНАЛСЯ
CONCERT.UA?
Билетная система v-Ticket была создана для продажи билетов на события
VIRUS Music в 2010 году

6. ЧЕМ МЫ
ЗАНИМАЕМСЯ?
• IT-development
• Аналитика

7. ЧТО БЫЛО ПОД
КАПОТОМ В 2010?
Software stack:
• FreeBSD 8
• PHP5.2
• MySQL 5.1
• Apache 2.2 + mod_php

8. ИНТЕГРАЦИЯ С
ВНЕШНИМИ
СЕРВИСАМИ
Other
ticketing
systems
SMS
gateway
Payment
gateways
Delivery
service
Misc adv
networks

9. РОЖДЕНИЕ
CONCERT.UA
В 2012 мы разделили билетную систему
и продающий сайт и начали продвигать
Concert.ua как самостоятельный бренд

10. РАЗДЕЛЕНИЕ
ОБЯЗАННОСТЕЙ

11. НАЧАЛЬНАЯ
АРХИТЕКТУРА
ПРОЕКТА
Б.К.Г.

12. НАГРУЗКА НА 2012
3000 посещений
300 билетов в 200 заказах
…в сутки

13. ПЕРИОД РОСТА

14. ВСКРЫВШИЕСЯ
ПРОБЛЕМЫ
Неуклюжий самописный фреймворк
Отсутствие документации и комментариев
Синхронная обработка всего
Проект был не по канонам ООП и MVC
Зависимости впаяны в репозиторий
Непродуманная схема данных в db
Почти полное отсутствие индексов в db
Прямые SQL-запросы из контроллеров
Отсутствовала полноценная корзина
Не обрабатывались многие ошибки
AJAX-запросы не авторизовывались
Довольно часто получались дубли мест
Поиск по названию занимал до 30 сек
Типичное время отклика было 3-10 сек
Разнились цифры в отчётах

15. ГДЕ ВЫХОД?

16. ВАРИАНТЫ РЕШЕНИЯ
1. Эволюционный путь
2. Революционный путь
3. Параллельная реальность

17. УСПЕХИ В ЭВОЛЮЦИИ
 Поиск событий и площадок через ElasticSearch
 Созданы индексы в db
 Хранение сессий и кеш сущностей в Redis
 Тюнинг apache и добавление nginx как reverse proxy
 Добавлены обработчики ошибок
 Исправлены злостные просчёты в схеме данных

18. F*CK-UP: SERVICE
OUTAGE ;-(

19. ТРАНСФОРМАЦИЯ:
PHASE 1
 Переход на PHP7
 Замена Apache на nginx + PHP-FPM для legacy
 Переписывание Frontstore на Yii2
 Внедрение билетного ядра vCORE
 Создание экосистемы stateless-сервисов
 Очереди на RabbitMQ
 Разделение монолитной DB

20. EUROVISION SONG
CONTEST 2017
Переезд в облако Digital Ocean
Тонкая настройка CloudFlare
Anti-scalper Lua-скрипты для nginx
Боевое крещение ядра vCORE
Queue-It сервис электронных очередей

21. ТРАНСФОРМАЦИЯ:
PHASE 2
 dRPC-архитектура ядра vCORE на основе WAMP v2 (Crossbar)
 New-gen v-Ticket Frontend (Angular, WAMP v2 over WSS)
 Storage service: хранение изображений и документов
 Sentry: централизованный сбор ошибок и исключений
 Analytics service: сбор и агрегация big data
 ELK-стек: сбор логов со всех служб
 Prometheus: слежение за heart-beat критических служб
 Контейнеризация приложений и сервисов

22. MariaDB 1
MariaDB 2
MariaDB 5
MariaDB 3
MariaDB 4
Block storage
bi-daily backups
Galera Cluster
MySQL
MaxScale 1
MaxScale 2
CloudFlare
Concert.ua
Load Balancer
CloudFlare
v-Ticket
HTTPS
Balancer-1
Internal DNS1
HTTPS
WSS
WS
Balancer-2
Internal DNS2
PHP Session storage
application cache
Redis
HTTP
concertua-app01
concertua-app02
concertua-app03
(staging)
Concert.ua cluster
HTTP
vticket-app00
(API)
vticket-app01
vticket-app02
v-Ticket legacy cluster
MySQL
Block storage
volume-01-fra1
storage1
(static & logs)
NFS
Redis
PHP Session storage
application cache
ElasticSearch 1 ElasticSearch 2 ElasticSearch 3
ElasticSearch cluster
RabbitMQ srv1
Crossbar srv1
PostgreSQLPostgreSQL
Exim 1
HAProxy
Exim 2 Exim 3
Mail out cluster
AMQP
AMQP
SMTP
WAMP
over WS or TCP
SMTP
MySQL
Redis
AMQP
vticket-core01 SMTP
MySQL
Redis
RabbitMQ
storage.concert.ua
HTTPS
CloudFlare
storage.concert.ua
HTTP
HTTP
HTTP
sentry.concert.ua
HTTPS
CloudFlare
sentry.concert.ua
vticket-worker01
vsync-common-dispatcher
vsync-common
ticket-renderer
sms-sender
email-sender
ladesk-worker
order-operation-migrator
core-auth-service
google-analytics-worker
vticket-worker02
vsync-common-dispatcher
vsync-common
ticket-renderer
sms-sender
email-sender
ladesk-worker
order-operation-migrator
core-auth-service
google-analytics-worker
Redis srv2Redis srv1
ТЕКУЩАЯ
АРХИТЕКТУРА

23. IMAGE & DOC
STORAGE
 Абстракция от физического хранилища
 CRUD по RESTful интерфейсу
 Автоматический ресайз картинок по конфигурации
 Возможность миграции между физическими хранилищами

24. IMAGE & DOC
STORAGE – SAVE
pic1.jpg
Storage Service
Physical Storage
HTTP PUT SAVE

25. IMAGE & DOC
STORAGE – FETCH
pic1.jpg:31-event-poster
Storage Service
Physical Storage
HTTP GET TRY FETCH
SAVE

26. RPC WITH
CROSSBAR.IO (WAMP)

27. IMAGINE DRAGONS
2018
Полностью новый сайт
Queue-It сервис электронных очередей
 Абсолютный рекорд Украины:
50% стадиона за 6 часов
 Concert.ua продал 84%
Sales
Concert.ua Others

28. НАГРУЗКА НА 2018
50000-80000 посещений
5000 билетов в 3000 заказах
в сутки
Билетный сайт №2 по посещаемости в СНГ

29. ОТРАЖЕНИЕ DDOS
o CloudFlare: WAF, Rate Limiter, Country Block, Load Balancer
o Распознавание паттернов атаки
o Правила на nginx (ограничения PUT/POST, referrer и т.п.)
o Кастомные правила WAF на CloudFlare
o Barracuda Cloudgen Firewall или a10 WAF

30. ВЫВОДЫ
 При проектировании архитектуры стоит держать в голове вопрос: «Как это
будет работать завтра?»
 Переделывать рабочий проект намного дольше, дороже и сложнее,
нежели написать такой с нуля
 PHP-приложение может стабильно работать в качестве демона и даже
мульти-процессно
 WS стабильно работает даже в условиях DDOS
 Оправдано дальнейшее дробление сервисов на более мелкие