Как делать classified'ы?

Легко! *
*Если у вас есть API ;)
Кто здесь и зачем?
● Никита, один из ведущих разработчиков в «Колёсах»
● В данный момент отвечаю за разработку market.kz, API и

по чуть-чуть за kolesa.kz и krisha.kz
● Знаю много страшных слов и программирую на кучке разных

языков программирования
Расскажу:
● Что было в 2010-2011
● Что есть сейчас
● Что будет завтра
Экскурс в историю
Колёса 2010
Экскурс в историю
Крыша 2010
Технологии
А что под капотом?
А что под капотом?
Технологии
Окружение 2010-2012
● PHP 5.2
● MySQL 4.x
● GlusterFS
● 100500 XML-файлов на сетевой файловой системе
● И еще больше фотографий там же
● Поиск через sphinxsearch исключительно в live
Технологии
Разработка 2010-2012
● Пилим фичу для колес
● Если все получилось, Ctrl+C / Ctrl+V на крышу с
«небольшими» изменениями
● Вечерами плачем из-за медленной сетевой FS
● Круглые сутки ревем навзрыд из-за отсутствия надежности
● Из-за угла маячат мобильные приложения
Технологии
Так жить нельзя!
Viva la revolución
Придумываем API
● API един для всех сайтов
● HTTP — это доступно, просто и легко, даже Tcl из «коробки»
умеет делать HTTP-запросы
● Отдавать все будем в JSON
● Не RESTFul!
● Весь функционал сайта повторять не нужно
● «Драйверы» для хранилищ
API
Драйвер? О чем ты?
● Реализует единые интерфейсы для всех сайтов
● Знает, что такое категории, параметры, пользователи и
объявления
● Умеет со всем этим работать (CRUD)
● Реализует специфичные для каждого сайта штуки
● Можно наследовать от других драйверов
API. Драйверы
Тот самый первый драйвер
● Пишет и читает данные объявлений из XML-файлов на
GlusterFS
● Сохраняет фотографии в GlusterFS
● Знает что и где лежит в MySQL (комментарии, пользователи,
антиспам, etc)
● Есть «печенька» — поиск по всем объявлениям через Solr
API. Драйверы
Прекращаем писать данные
объявлений напрямую в XML
API. Переезд
Перестаем дергать GlusterFS при
загрузке фотографий
API. Переезд
Учим сайт искать объявления не в
sphinx'е, а через API
API. Переезд
Сначала фотографии
● Жесткие диски сыпятся
● Писать свое надежное и реплицируемое файловое
хранилище в blob'ах — затратно (мы пока еще не facebook)
API. Надежность
У нас есть механизм драйверов и мы можем прозрачно для
клиентов делать, что хотим.
И где хранить эту кучу файлов?
API. Надежность
OpenStack Swift
● Не сетевая ФС
● Хранилище объектов
● Каждый объект реплицируется минимум на 3 ноды в двух
разных датацентрах
● Медленный :(
● Но у нас есть прокси и куча кэшей! :)
API. Надежность
А дальше по накатанной:
● Пишем новый драйвер и прозрачно уносим объявления из
XML в MongoDB
● Отдаем API партнерам (Smart TV, виджеты на других сайтах)
● Запускаем мобильные приложения
● Пишем драйвер, который все так же прозрачно
«объединяет» личные кабинеты пользователей на сайтах
● Запускаем market.kz
● Переезжаем на elasticsearch
API. Надежность
Софт
● Для кода — PHP 5.4
● Для мета-информации — Percona Server 5.5
● Для объявлений — MongoDB 2.4
● Для фотографий — OpenStack Swift
● Для поиска — Elasticsearch 1.3 и немножко Solr
● Для логов — Graylog2
● Для очередей — beanstalkd
● Для кешей — Redis
● Для анализа производительности — BTP (и клиент к нему)
API. Сегодня
BTP daemon
API. Сегодня
BTP
daemon
API. Сегодня
Грабли MongoDB
● Работаете из PHP? Сразу запускайте mongos
● Впрочем, когда не из PHP, тоже запускайте
● Не используйте точки в именах полей, иначе можно
попрощаться с версией 2.6
● Не используйте map/reduce или aggregation framework на
серверах в продакшене
● Стабильная работа replicaSet'а в двух датацентрах — миф,
%username%
● Типы данных — это важно
API. Сегодня
Грабли OpenStack Swift
● Репликация медленная
● Запись тоже не блещет скоростью, так что проксируем все
через брокер очередей и быстрое хранилище (у нас
beanstalkd+redis)
● Чем меньше нод, тем ниже производительность
API. Сегодня
Цифры
● 3 MongoDB и 26M объектов объявлений в них
● 330М объектов фотографий, занимающих 25TB в OSS (75TB
с учетом реплик)
● 85-195 запросов в секунду от мобильных приложений
● 550-1000 запросов в секунду от сайтов
● 82/164 Мбит/сек трафика
● 8 нод эластика на колесах и 1 на маркете, на крыше все еще
Solr
● 20 серверов redis'а для разных кэшей
API. Сегодня
Что будет завтра?
На самом деле, никто не знает, но попробуем погадать:
● Повышение надежности (может быть и отказ от MongoDB)
● Гео-рапределенность
● Ускорение кода, переезд на HHVM
● Разработка новых интересных фич
API. Завтра
Вопросы?
Никита Вершинин
Ведущий разработчик ТОО «Колёса»
Email: endeveit@gmail.com
Skype: endeveit
Конец
Спасибо!

Разработка API для большого, нагруженного сервиса

  • 1.
    Как делать classified'ы?
 Легко!* *Если у вас есть API ;)
  • 2.
    Кто здесь изачем? ● Никита, один из ведущих разработчиков в «Колёсах» ● В данный момент отвечаю за разработку market.kz, API и
 по чуть-чуть за kolesa.kz и krisha.kz ● Знаю много страшных слов и программирую на кучке разных
 языков программирования Расскажу: ● Что было в 2010-2011 ● Что есть сейчас ● Что будет завтра
  • 3.
  • 4.
  • 5.
  • 6.
    А что подкапотом? Технологии
  • 7.
    Окружение 2010-2012 ● PHP5.2 ● MySQL 4.x ● GlusterFS ● 100500 XML-файлов на сетевой файловой системе ● И еще больше фотографий там же ● Поиск через sphinxsearch исключительно в live Технологии
  • 8.
    Разработка 2010-2012 ● Пилимфичу для колес ● Если все получилось, Ctrl+C / Ctrl+V на крышу с «небольшими» изменениями ● Вечерами плачем из-за медленной сетевой FS ● Круглые сутки ревем навзрыд из-за отсутствия надежности ● Из-за угла маячат мобильные приложения Технологии
  • 10.
  • 11.
    Придумываем API ● APIедин для всех сайтов ● HTTP — это доступно, просто и легко, даже Tcl из «коробки» умеет делать HTTP-запросы ● Отдавать все будем в JSON ● Не RESTFul! ● Весь функционал сайта повторять не нужно ● «Драйверы» для хранилищ API
  • 12.
    Драйвер? О чемты? ● Реализует единые интерфейсы для всех сайтов ● Знает, что такое категории, параметры, пользователи и объявления ● Умеет со всем этим работать (CRUD) ● Реализует специфичные для каждого сайта штуки ● Можно наследовать от других драйверов API. Драйверы
  • 13.
    Тот самый первыйдрайвер ● Пишет и читает данные объявлений из XML-файлов на GlusterFS ● Сохраняет фотографии в GlusterFS ● Знает что и где лежит в MySQL (комментарии, пользователи, антиспам, etc) ● Есть «печенька» — поиск по всем объявлениям через Solr API. Драйверы
  • 14.
  • 15.
    Перестаем дергать GlusterFSпри загрузке фотографий API. Переезд
  • 16.
    Учим сайт искатьобъявления не в sphinx'е, а через API API. Переезд
  • 18.
    Сначала фотографии ● Жесткиедиски сыпятся ● Писать свое надежное и реплицируемое файловое хранилище в blob'ах — затратно (мы пока еще не facebook) API. Надежность У нас есть механизм драйверов и мы можем прозрачно для клиентов делать, что хотим. И где хранить эту кучу файлов?
  • 19.
  • 20.
    OpenStack Swift ● Несетевая ФС ● Хранилище объектов ● Каждый объект реплицируется минимум на 3 ноды в двух разных датацентрах ● Медленный :( ● Но у нас есть прокси и куча кэшей! :) API. Надежность
  • 21.
    А дальше понакатанной: ● Пишем новый драйвер и прозрачно уносим объявления из XML в MongoDB ● Отдаем API партнерам (Smart TV, виджеты на других сайтах) ● Запускаем мобильные приложения ● Пишем драйвер, который все так же прозрачно «объединяет» личные кабинеты пользователей на сайтах ● Запускаем market.kz ● Переезжаем на elasticsearch API. Надежность
  • 22.
    Софт ● Для кода— PHP 5.4 ● Для мета-информации — Percona Server 5.5 ● Для объявлений — MongoDB 2.4 ● Для фотографий — OpenStack Swift ● Для поиска — Elasticsearch 1.3 и немножко Solr ● Для логов — Graylog2 ● Для очередей — beanstalkd ● Для кешей — Redis ● Для анализа производительности — BTP (и клиент к нему) API. Сегодня
  • 23.
  • 24.
  • 25.
    Грабли MongoDB ● Работаетеиз PHP? Сразу запускайте mongos ● Впрочем, когда не из PHP, тоже запускайте ● Не используйте точки в именах полей, иначе можно попрощаться с версией 2.6 ● Не используйте map/reduce или aggregation framework на серверах в продакшене ● Стабильная работа replicaSet'а в двух датацентрах — миф, %username% ● Типы данных — это важно API. Сегодня
  • 26.
    Грабли OpenStack Swift ●Репликация медленная ● Запись тоже не блещет скоростью, так что проксируем все через брокер очередей и быстрое хранилище (у нас beanstalkd+redis) ● Чем меньше нод, тем ниже производительность API. Сегодня
  • 27.
    Цифры ● 3 MongoDBи 26M объектов объявлений в них ● 330М объектов фотографий, занимающих 25TB в OSS (75TB с учетом реплик) ● 85-195 запросов в секунду от мобильных приложений ● 550-1000 запросов в секунду от сайтов ● 82/164 Мбит/сек трафика ● 8 нод эластика на колесах и 1 на маркете, на крыше все еще Solr ● 20 серверов redis'а для разных кэшей API. Сегодня
  • 28.
    Что будет завтра? Насамом деле, никто не знает, но попробуем погадать: ● Повышение надежности (может быть и отказ от MongoDB) ● Гео-рапределенность ● Ускорение кода, переезд на HHVM ● Разработка новых интересных фич API. Завтра
  • 29.
    Вопросы? Никита Вершинин Ведущий разработчикТОО «Колёса» Email: endeveit@gmail.com Skype: endeveit Конец
  • 30.