Вечер прогулок по городу, ночь в гостинице и вот он - второй день конференции. Решил доклады не пропускать (не зря же 12 часов в поезде ехал!) и пошел сразу на первый доклад.
Сергей Ломаков, Simtech. "Использование key-value хранилища redis в боевых условиях".
Рассказал о юзкейсах редиса, об основных возможностях и опыте работы с ним. Редис достаточно простой и производительный, но в нем нет встроенных инструментов горизонтального масштабирования. Поддерживает хранимые процедуры на Lua (применяли ли их на практике не понял). Упомянул, что можно на основе редиса сделать простую MQ (массив и RPUSH + LPOP), есть возможности pub-sub. Довольно интересные способы сортировки с возможностью сохранить результат как отдельный ключ. Для персистентности существуют снепшоты (позволяют быстро запускаться с него, но работает на основе fork, т.е. возможен перерасход памяти) и append-only файл (снижает производительность, довольно медленный старт сервера). Довольно быстрая и устойчивая master-slave репликация. Посоветовал использовать 32-битную сборку для экономии памяти, запускать несколько экземпляров по числу ядер. Полезно разделять экземпляры по назначению (кому-то важна персистентность, например статистике, кому-то нет, напр. кеш).
Мне доклад показался не очень интересным, скорее всего потому что с редисом уже работал, а тут было довольно много простых вещей и информации из документации. Но и были полезные советы и примеры из собственного опыта.
Юрий Бушмелев, echo. "Облако в подсобке. Строим правильную локальную инфраструктуру".
При использовании реального железа возникает множество проблем связанных, например, с привязкой к оборудованию, с конфликтами различных сервисов, запущенных на одном сервере и т.п.
Виртуализация серверов позволяет:
- Избавиться от зависимости от конкретного оборудования
- Запускать разные сервисы в разных VM
- Более эффективно использовать ресурсы (т.к. на одном хосте можно размещать одновременно виртуалки с разными профилями нагрузки (IO/процессор/память)
- упрощение бэкапов за счет снапшотов
- повышается отказоустойчивость
Для надежного и удобного хранения данных виртуальных машин нужно использовать "Системы хранения данных", в том числе для Live Migration между хост-серверами. Процесс роста такой:
- Один сервер виртуализации
- Несколько серверов виртуализации и СХД
- Несколько серверов СХД для надежности
Системы виртуализации тоже не все одинаковые. Основные типы: автономная (не нужна ОС-хост, работает сразу на железе) и на основе хостовой ОС. Автономная лучше т.к. не требуется установка хостовой ОС.
Пример реального бюджетного облака: автономный или гибридный гипервизор, СХД из 2-х серверов с SCSI-failover и софт-raid, не брендовые сервера.
Основные тормоза - на дисковом IO.
От себя - не знаю есть ли реальный смысл поднимать собственные "облака на коленке" когда есть амазоны-ракспейсы-селектелы. Скорее всего оправданы когда нужны какие-то специальные условия или имеются особые требования.
Василий Сошников, SimbirSoft. "Кроссплатформенная разработка: Windows, Linux, MacOS, iOS, Android"
Доклад читали 2 докладчика по очереди. Я не очень хорошо вник в суть, но кажется описывали опыт разработки мультиплатформенного софта на низкоуровневых языках (C++).
Структура такая: [бэкенд] <-> [Notification center] <->[фронтенд]. Важно разработать простой гибкий протокол для которого можно создать биндинг в C. Обсуждали какие-то Pimpl vs Factory, во время доклада попытался выяснить у соседей что такое pimpl - безуспешно) Отметили что важно, чтобы система сборки поддерживала командную строку и pipelining. Посоветовали иметь в проекте минимум внешних зависимостей для облегчения портирования. В качестве платформонезависимого способа передачи бинарных данных посоветовали Thrift или ProtocolBuffers.
Честно говоря, мало что понял из доклада, плюс по времени затянулся а мне нужно было из гостиницы съезжать, так что на вопросы/ответы даже не остался.
Дальше уже начинаются более интересные доклады... Хотел попасть на доклад Михаила Табунова про Backbone.JS, но из за затянувшегося доклада и гостинницы так на него и не попал. так что дальше идет
Константин Осипов, mail.ru. "Tarantool/Box 1.5. опыт оптимизации производительности NoSQL СУБД"
Tarantool - это т.н. Relaxed-relational база данных. Есть базы, есть таблицы, в них есть кортежи, часть из них описываются схемой, часть без схемы (фиксированная и нефиксированная части), есть btree и hash индексы (только на фиксированную часть, на нефиксированную появятся в след. версиях). Инкрементальное перестроение индексов/хешей. Отличается очень высокой производительностью и очень тесной интеграцией с Lua - на нем пишутся хранимые процедуры, есть множество процедур из коробки. Существуют упрощенный SQL интерфейс, собственный бинарный протокол и эмуляция Memcached протокола. При этом SQL интерфейс существует только на клиенте где сразу преобразуется в бинарный протокол. Основной "потребитель" - собственно Mail.ru. В tarantool хранятся сессии и данные о присутствии на сайте. Фактически - при каждом клике пользователя на проектах Mail.ru идет обращение к Tarantool. У mail.ru 20млн онлайн пользователей создают 100 тыс запросов к Tarantool в ссекунду. База работает на кластере из 2-х боевых серверов и 2-х реплик для надежности. На каждом сервере запущено по 2 копии tarantool и вполне справляется с нагрузкой.
В Tarantool нет транзакций, но операции атомарные, с записью на диск. Более-менее сложные вещи лучше реализовывать на хранимых процедурах.
На вопрос "чем вы лучше редиса" ответил, что у них более гибкие структуры данных, лучше интеграция с LUA, лучше организована работа с диском. Проблемы со сборщиком мусора в LUA решили.
От себя - судя по описанию, довольно интересная база с широкими возможностями, но у нее очень маленькое комьюнити и мало внешних проектов, использующих Tarantool. Создается впечатление, что автор не очень-то хочет/старается его (комьюнити)поддерживать. "Мне и так каждый день приходят советы как мне БД продвинуть, улучшить, пропиарить. Какой-то секс посреди красной площади получается". Ну что-ж, пожелаю удачи и развития, возможно найду время поковыряться.
Алексей Рыбак, badoo. "Архитектура badoo".
"Когда у вас в руках молоток, любая проблема кажется гвоздем"
Badoo - один из популярных на западе и в европе сайтов знакомств с командой разработки в России. У них 2000 серверов в 2-х датацентрах. Список используемых технологий очень короткий: Linux, Nginx,PHP, C, C++, MySQL с HandlerSocket, Memcached; есть немного MongoDB и немного Python, но их стараются выпилить О_о.
Значительная часть кода пишется как эксперимент, в случае чего можно безболезненно выкинуть. В badoo консервативны к выбору технологий и инструментов (очень!).
Для того чтобы выбрать в какой из датацентров "приземлить" пользователя используется GeoIP DNS.
Существует внутренний стандарт-соглашение что время сборки страничек не должно превышать 0.1 секунду. Сборка странички происходит синхронно в PHP, данные берутся из MySQL, C/C++ демонов,Memcached. Все обращения к другим серверам обернуты в таймеры (pinba). Для кеширования байткода PHP используют APC или eAccelerator. Создали и поддерживают шаблонизатор Blitz и менеджер процессов PHP-fpm. Логи ошибок собирают в Scribe.
Весь SQL - в коде приложения. Не используют триггеров/хранимых процедур и т.п. Используют только простые запросы, без view, без вложенных запросов, не используют внешних ключей (вроде используют JOIN). Контроль целостности, как я понял, осуществляется тоже вручную в коде. Активно используют шардинг. Написана собственная система репликации шардов между ДЦ для MySQL. Используют параллельный апгрейд схем таблиц на шардах. Используют транзакционные очереди (?). На серверах Memcached регулярно делают полный flush. Для шардинга ключей используют простой
$i/n или
crc32($s)/n. Активно используют время жизни ключей, используют prolongate для мемкеша (увеличение времени жизни при обращении к ключу). Есть система очередей в MySQL с периодическим поллингом в 20-30 секунд O_o (вроде так сделано чтобы использовать транзакции и с очередями в том числе). Какое-то время использовали RabbitMQ, но выпилили.
Для администрирования используют puppet и собственную библиотеку для PHP mssh (multi-ssh).
У меня этот доклад вызвал какой-то butthurt. Неужели оправданно так жестко подходить к выбору инструментов и, при возможности, выпиливать"проявления вольности" некоторых разработчиков (Python, Mongo, RabbitMQ)? В чем проблема развести небольшой зоопарк не понимаю. Учитывая, что у них все-таки уже довольно большая команда и найти спецов по новым технологиям не будет такой уж проблемой. Однозначно могу сказать, что в Badoo я бы работать не хотел... Возможно чего-то не понимаю конечно.
Лев Валкин, echo. "Инь и янь масштабированиия"
Шардинг! Шардинг! Шардинг!
Второй доклад Льва Валкина. На самом деле без контекста не совсем понятно о чем он рассказывал ИМХО. Т.к. я с контекстом немного знаком, расскажу.
Echo предоставляет огромным медийным и контентным западным площадкам и брендам различные социальные реалтайм социальные виджеты (комментарии, лайки, топы, голосования, шаринг и пр) плюс конструктор на основе этих виджетов и SQL - подобный язык запросов к платформе. Учитывая объемы траффика и данных, множество связей в сочетании с гибкостью платформы, получается довольно уникальная штука. 50 000 запросов в секунду, 200 серверов, куча реалтайма.
На докладе рассказал об Incident Command System - систему реагирования на внештатные ситуации, позаимствованную у пожарных: тот, кто первым обнаружил проблему становится ответственным за нее и руководит процессом "ремонта".
Затем некоторые размышления на тему программирования, когда лучше применять бесконечные очереди (RabbitMQ) а когда что-то простое (Nginx + воркеры). Рассказал, что в Echo активно используют фичи Erlang, например часто используют горячую замену кода прямо на production, но это несколько расслабляет программистов и они начинают этой возможностью злоупотреблять. Упомянул, что важно допускать остановку части серверов без потери работоспособности всей системы (устранять единые точки отказа).
Отдельно коснулся важности интроспекции и рассказал как с этим все хорошо в Эрланге. Помимо бенчмарков у них используются замеры с историей во времени чтобы наблюдать аномалии и отклонения.
Отдельно рассказал про продвинутую систему логгирования: при каждом запросе к их сервису в Erlang собираются все возможные данные и метрики и на лету анализируются и фильтруются. В среднем на каждый запрос может накопиться несколько десятков мегабайт такой отладочной информации. В случае необходимости эти данные логгируются на диск, иначе просто отбрасываются. Оверхед на такое логгирование существенный, от 5 до 30 процентов, но он размазывается по кластеру.
Значительная часть серверов живет в Amazon, но это дорого и часто встречаются аномалии и нестабильности, поэтому поддерживают и свою инфраструктуру в Colocation. В частности, все сервера баз данных свои. Главный плюс амазона - можно в случае необходимости быстро отмасштабироваться в 10 раз, но не более.
Языки разработки: в первую очередь Erlang и OCaml, так же используются Python, PHP, Haskell, C, Perl. В команде есть много хороших специалистов знающих по несколько языков. Так что выбирают язык если хорошо подходит для решения конкретных задач или есть какая-то хорошая библиотечка на нем.
Хоть и большая часть софта на Erlang, нанимают не Erlang-программистов, а просто хороших инженеров, в случае необходимости обучают Erlang-у в процессе работы.
От себя: хоть доклад был, на мой взгляд, немного несвязным, но тем не менее было весьма интересно. Радует, что не боятся новых технологий и "языкового зоопарка".
Кстати, после доклада, в кулуарах обсуждали проблемы с масштабированием, с которыми в Echo приходится сталкиваться: у них хранится сложная структура данных - социальный граф со множеством связей. А т.к. клиентам предоставляются гибкие средства работы с ним (EQL - SQL-подобный язык) то шардирование реализовать не получается, т.к. не ясно по какому критерию разбивать данные иMaterialized View так же не подходит, т.к. приведет к копированию огромных количеств данных. Как с этим бороться - еще не придумали)
Ну вот и все, конференция закончена. Огромное спасибо всем, отдельно организаторам и докладчикам. Пожалуй, одна из лучших конференций на которых я побывал. Буду надеяться что мероприятие станет как минимум ежегодным и будет держать планку на уровне. А мне пора на поезд.