Как делать 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

Конец

Спасибо!