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

1. Архитектура Справочного API 2ГИС
Сергей Коржнев
2gis.ru
@rnd2gis

2. 2
Справочное API 2ГИС
• Справочник организаций, доступный через REST API
• Возможности
• Поиск организаций, гео-объектов
• Расчет маршрутов проезда транспорта
• Посещаемость
• 16 млн. уникальных посетителей в месяц
• 1600 RPS

3. 3
Три кита
1. Отказоустойчивая архитектура
2. Обновление данных в распределенной системе
3. Ускорение веб-приложения

4. Отказоустойчивая
архитектура

5. 5
Геораспределенность

6. 6
Отказоустойчивость дата-центра

7. 7
Отказоустойчивость ноды

8. 8

9. 9
Результаты
• Готовы к выведению из строя отдельных компонент архитектуры
• Распределение нагрузки
• Удобное горизонтальное масштабирование

10. Обновление данных в
распределенной
системе

11. 11
Единый центр управления данных
• Данные готовятся в одном месте
• Затем «разливаются» по всем дата-центрам
• Минусы
• Задержки доставки данных
• Ограничение на ширину канала
• Плюс
• Простота

12. 12
База данных

13. 13
PostgreSQL 9.3

14. 14
Результаты
• Как временное простое решение — отлично работает
• Следите за трафиком
• Будущее за децентрализацией

15. 15
Поисковые индексы

16. Ускоряем
веб-приложение

17. 17
1. Ускоряем PHP
• Тяжелые вычисления на C++
• Yii-фреймворк
• 4 мс на инициализацию
• ORM для чтения
• Компоненты и Lazy Loading
• fastcgi_finish_request()
• Отвечаем, как можно раньше
• Количество Php-fpm worker'ов

18. 18
2. Кэширование

19. 19
Redis
• В сравнение с Memcache:
• Векторные структуры данных
• Поиск ключей по маске

20. 20
Хеши в Redis
• TTL на всю структуру сразу
• При превышении допустимой памяти грохается весь хеш

21. 21
Поиск ключей по маске
• geo::1::*
• На «слейве»
• На «мастере» — крайне редко и осторожно

22. 22
Shared memory
• Ограниченный набор данных небольшого размера
• PHP APC

23. 23
Результаты
• Увеличивается быстродействие системы
• При этом система может жить без кэша

24. 24
3. Realtime-мониторинг

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

26. 26
Мониторинг времени работы
методов API
• Измеряем время работы метода
• Отправляем данные по UDP на сервис сбора статистки
• Отслеживаем данных в системе комплексного мониторинга
• Pinba и Zabbix

27. 27
Анализ проблем
производительности
• Расставляем Pinba-таймеры
• Отслеживаем какие именно участки кода медленные
• Триггеры, UI
• Косвенно мониторим PostgreSQL, Redis, поисковые утилиты
• Отслеживаем медленный PHP-код на реальных данных

28. 28
Мониторинг ошибок
• Перехватываем ошибку в PHP
• Отправляем ее на некоторый сервис по UDP
• Триггеры, UI
• Graylog2

29. 29
Результаты
• Не замедляем работу приложения
• Используем Pinba, как показатель работы системы
• Не забываем про другие системные параметры мониторинга

30. 30
Выводы
• Балансировка нагрузки
• между дата-центрами и нодами (LVS)
• внутри ноды (Nginx, PgPool2, TwemProxy)
• Мониторинг системы (Zabbix, Pinba, Graylog2)
• Оптимизация веб-приложения
• Весь хардкор в C++ (Apache Trift)
• Легковесный фреймворк (Yii)
• Отвечаем, как можно раньше

31. 31
Вопросы?
Сергей Коржнев
s.korzhnev@2gis.ru