Опыт миграции между дата-центрами / Михаил Тюрин, Сергей Бурладян (Avito)Ontico
В этом докладе мы поделимся опытом, полученным в ходе масштабного проекта по миграции Avito между дата-центрами: как мы осуществляли планирование, подготовку и непосредственно переезд с переключением площадки.
Опишу общие особенности и специфику нашей миграции, "подводные камни" и неочевидные ограничения, с которыми приходилось справляться, в том числе, и в экстремальных условиях.
Эволюция программно-аппаратного обеспечения хранения фотографий в Badoo / Дми...Ontico
На примере нашей системы хранения фотографий мы хотим рассказать о проблемах, с которыми столкнулись в течение прошедших семи лет, связанных с ее программными и аппаратными компонентами, и о путях их решений.
В данном докладе речь пойдет о том, как сохранить независимость от поставщика и построить масштабируемую систему хранения с длительным сроком эксплуатации и способностью к оперативному внесению изменений в конфигурацию. Как сделать изменения на аппаратном уровне прозрачными для разработчиков, а также о том, как упростить развертывание и обслуживание.
В общих чертах изложен опыт и проблемы, которые мы получили в ходе эксплуатации классических мультиконтроллерных СХД. Основная тема - построение собственных хранилищ на базе общедоступных компонентов (полки, адаптеры, экспандеры, интерпозеры, диски, ЦПУ и т.д.) с потенциальной возможностью замены любого из выше перечисленного на другую модель. Дублирование критически важных узлов в рамках одной СХД. Обзор используемых транспортов - SRP, FC, iSCSI и описание того, каким образом можно быстро адаптировать такое хранилище под один или несколько транспортов, с минимальными вложениями. Обзор ПО для реализации СХД (SCST/LIO или проприетарные решения в области Software Defined Storage ). Автоматизация развертывания (инсталляция/управление с помощью Puppet). Тестирование перед вводом в эксплуатацию. Multipath I/O и упрощение именования экспортируемых блочных устройств. Политика составления наборов firmware для стабильной работы. Мониторинг. Расследование сбоев (Order of failure и т.п.).
NoSQL внутри SQL: приземленные вопросы практического применения / Дмитрий До...Ontico
Чтобы добиться от системы максимальной производительности, необходимо учитывать структуру данных, с которыми вы работаете. Проблемы возникают, если данные очень неоднородные, и один из способов решения этих проблем - использовать возможности современных реляционных БД для хранения данных в документо-ориентированной форме.
Этот подход имеет свои плюсы и минусы, которые будут обсуждаться в докладе на примерах PostgreSQL/MySQL/MariaDB etc.
Основные вопросы:
* конечно, производительность тех или иных решений и подходов - чего необходимо избегать, а чего бояться не стоит (бенчмарки для разных конфигураций и видов нагрузки);
* способы безболезненного переноса данных в такой формат.
Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)Ontico
Исторически сложилось так, что одни люди разрабатывают приложения (Dev), а другие эксплуатируют их в продакшне (Ops). И у последних есть немало проблем с тем, что невозможно понять, что происходит.
Причем это касается как собственных разработок, так и популярных open source решений.
Я расскажу, как устроена диагностика у некоторых популярных софтин:
- nginx
- postgresql
- mongodb
Мы попробуем разобраться, что там сделано хорошо, и чего не хватает для полного счастья.
Во второй части доклада мы поговорим про то, как нужно инструментировать собственное приложение для прозрачной работы в продакшне:
- что считать и зачем: ошибки, тайминги, разные состояния приложения,
- инструментарий: your_lang-metrics, your_lang-statsd-client, логи,
- как не перемудрить и не убить прод диагностикой.
Может показаться, что этот доклад про DevOps, но нет - про docker не будет ни слова :)
За счет чего Tarantool такой оптимальный / Денис Аникин (Mail.Ru)Ontico
Многие из вас, наверное, видели результаты тестов сравнения Tarantool с остальными СУБД, которые показывают, что Tarantool быстрее всех, оптимальней по памяти, обрабатывает наибольшее количество транзакций в секунду.
И, несмотря на то, что исходные коды всех тестов полностью открыты и хорошо откомментированы, позволяя всем желающим повторить тесты, все равно остаются вопросы - за счет чего Tarantool такой быстрый и оптимальный?
Я решил суммировать мои ответы на эти вопросы в докладе на Highload++.
Итак, почему Tarantool такой быстрый?
Краткий ответ: потому что он с самого начала разрабатывался и до сих пор разрабатывается во главе угла с производительностью/оптимальностью/минимальным потреблением всех ресурсов системы.
Более полный ответ я раскрою в своем выступлении. Приходите, будет интересно! :)
Как ускорить MySQL Handler Socket в 9 раз / Александр Яковлев (Мамба)Ontico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 11:00
Тезисы:
http://backendconf.ru/2017/abstracts/2782.html
Мы использовали MySQL Handler Socket в качестве интерфейса к данным пользователей на высоконагруженном проекте Wamba.ru. Почему Handler Socket? Потому что стандартный SQL-интерфейс не выдерживал наши нагрузки. Время шло, нагрузки росли, и в итоге и HandlerSocket перестал справляться. Мы только успевали доставлять и доставлять реплики MySQL, чтобы распределять увеличивающуюся нагрузку между ними.
...
Опыт миграции между дата-центрами / Михаил Тюрин, Сергей Бурладян (Avito)Ontico
В этом докладе мы поделимся опытом, полученным в ходе масштабного проекта по миграции Avito между дата-центрами: как мы осуществляли планирование, подготовку и непосредственно переезд с переключением площадки.
Опишу общие особенности и специфику нашей миграции, "подводные камни" и неочевидные ограничения, с которыми приходилось справляться, в том числе, и в экстремальных условиях.
Эволюция программно-аппаратного обеспечения хранения фотографий в Badoo / Дми...Ontico
На примере нашей системы хранения фотографий мы хотим рассказать о проблемах, с которыми столкнулись в течение прошедших семи лет, связанных с ее программными и аппаратными компонентами, и о путях их решений.
В данном докладе речь пойдет о том, как сохранить независимость от поставщика и построить масштабируемую систему хранения с длительным сроком эксплуатации и способностью к оперативному внесению изменений в конфигурацию. Как сделать изменения на аппаратном уровне прозрачными для разработчиков, а также о том, как упростить развертывание и обслуживание.
В общих чертах изложен опыт и проблемы, которые мы получили в ходе эксплуатации классических мультиконтроллерных СХД. Основная тема - построение собственных хранилищ на базе общедоступных компонентов (полки, адаптеры, экспандеры, интерпозеры, диски, ЦПУ и т.д.) с потенциальной возможностью замены любого из выше перечисленного на другую модель. Дублирование критически важных узлов в рамках одной СХД. Обзор используемых транспортов - SRP, FC, iSCSI и описание того, каким образом можно быстро адаптировать такое хранилище под один или несколько транспортов, с минимальными вложениями. Обзор ПО для реализации СХД (SCST/LIO или проприетарные решения в области Software Defined Storage ). Автоматизация развертывания (инсталляция/управление с помощью Puppet). Тестирование перед вводом в эксплуатацию. Multipath I/O и упрощение именования экспортируемых блочных устройств. Политика составления наборов firmware для стабильной работы. Мониторинг. Расследование сбоев (Order of failure и т.п.).
NoSQL внутри SQL: приземленные вопросы практического применения / Дмитрий До...Ontico
Чтобы добиться от системы максимальной производительности, необходимо учитывать структуру данных, с которыми вы работаете. Проблемы возникают, если данные очень неоднородные, и один из способов решения этих проблем - использовать возможности современных реляционных БД для хранения данных в документо-ориентированной форме.
Этот подход имеет свои плюсы и минусы, которые будут обсуждаться в докладе на примерах PostgreSQL/MySQL/MariaDB etc.
Основные вопросы:
* конечно, производительность тех или иных решений и подходов - чего необходимо избегать, а чего бояться не стоит (бенчмарки для разных конфигураций и видов нагрузки);
* способы безболезненного переноса данных в такой формат.
Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)Ontico
Исторически сложилось так, что одни люди разрабатывают приложения (Dev), а другие эксплуатируют их в продакшне (Ops). И у последних есть немало проблем с тем, что невозможно понять, что происходит.
Причем это касается как собственных разработок, так и популярных open source решений.
Я расскажу, как устроена диагностика у некоторых популярных софтин:
- nginx
- postgresql
- mongodb
Мы попробуем разобраться, что там сделано хорошо, и чего не хватает для полного счастья.
Во второй части доклада мы поговорим про то, как нужно инструментировать собственное приложение для прозрачной работы в продакшне:
- что считать и зачем: ошибки, тайминги, разные состояния приложения,
- инструментарий: your_lang-metrics, your_lang-statsd-client, логи,
- как не перемудрить и не убить прод диагностикой.
Может показаться, что этот доклад про DevOps, но нет - про docker не будет ни слова :)
За счет чего Tarantool такой оптимальный / Денис Аникин (Mail.Ru)Ontico
Многие из вас, наверное, видели результаты тестов сравнения Tarantool с остальными СУБД, которые показывают, что Tarantool быстрее всех, оптимальней по памяти, обрабатывает наибольшее количество транзакций в секунду.
И, несмотря на то, что исходные коды всех тестов полностью открыты и хорошо откомментированы, позволяя всем желающим повторить тесты, все равно остаются вопросы - за счет чего Tarantool такой быстрый и оптимальный?
Я решил суммировать мои ответы на эти вопросы в докладе на Highload++.
Итак, почему Tarantool такой быстрый?
Краткий ответ: потому что он с самого начала разрабатывался и до сих пор разрабатывается во главе угла с производительностью/оптимальностью/минимальным потреблением всех ресурсов системы.
Более полный ответ я раскрою в своем выступлении. Приходите, будет интересно! :)
Как ускорить MySQL Handler Socket в 9 раз / Александр Яковлев (Мамба)Ontico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 11:00
Тезисы:
http://backendconf.ru/2017/abstracts/2782.html
Мы использовали MySQL Handler Socket в качестве интерфейса к данным пользователей на высоконагруженном проекте Wamba.ru. Почему Handler Socket? Потому что стандартный SQL-интерфейс не выдерживал наши нагрузки. Время шло, нагрузки росли, и в итоге и HandlerSocket перестал справляться. Мы только успевали доставлять и доставлять реплики MySQL, чтобы распределять увеличивающуюся нагрузку между ними.
...
Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)Ontico
Некоторое время назад, когда в очередной раз встал вопрос о производительности большого парка mysql sharding серверов, мы не захотели покупать новые сервера и производить resharding. Мы обнаружили, что компания facebook выпустила в opensource большое количество своих разработок, в том числе и модуль ядра flashcache.
Flashcache — модуль для кэширования блоков блочного устройства, предоставляющий 4 разных режима кэширования.
В данном докладе я расскажу, как мы тестировали, поэтапно проверяя под нагрузкой, 3 из 4 режимов кэширования, сравнивая и выбирая оптимальный. Итогом данной работы стало внедрение данного модуля в нашу архитектуру (фотосервера, сервера БД).
Балансировка нагрузки и отказоустойчивость в ОдноклассникахOntico
Главная → Тезисы и презентации
Балансировка нагрузки и отказоустойчивость в Одноклассниках Системное администрирование
Доклад принят в Программу конференции
Никита Духовный
Одноклассники
Ведущий системный администратор в Одноклассниках. Начинал IT-карьеру разработчиком, занимался релиз инженерией, выбрал системное администрирование.
Возглавляет одну из команд. Занимается задачами, обеспечивающими работу портала - автоматизацией, запуском новых решений, поддержкой инфраструктуры. Ведёт несколько хардкорных проектов, в том числе - по повышению отказоустойчивости портала.
Тезисы
Проект Одноклассники начинал свою жизнь в одном датацентре.
С ростом популярности растёт и нагрузка. С ростом нагрузки открываются проблемы:
- Ни один, даже самый мощный, сервер больше не справляется в одиночку.
- Нагрузка растёт, а в датацентре нет места для нового оборудования.
- Падение датацентра безоговорочно приводит к даунтайму.
- Сетевой сбой выводит портал из строя.
- Пользователи в удалённых регионах страдают от низкой скорости.
Я без прикрас расскажу вам, как мы в Одноклассниках решаем эти проблемы. Поговорим о следующем:
- CDN - каким пользователям важен, его архитектура, устройство наших CDN-приложений, что происходит при авариях.
- Датацентры - почему мы используем три основных датацентра, где они расположены (и почему именно там), распределение пользовательского трафика между ними.
- Сеть - как и до чего мы балансируем трафик.
- Балансировщики - как мы используем LVS, почему (и в каких случаях) используем и другие решения. Что делаем с приложениями, которые нельзя ставить за балансировщик.
- Модули портала - о балансировке в нашем RPC протоколе, о том, что происходит с Одноклассниками при падении датацентра.
Владимир Бородин: Как спать спокойно - 2015.10.14 PostgreSQLRussia.org meetu...Nikolay Samokhvalov
More: http://PostgreSQLRussia.org
Доклад посвящён резервному хранению СУБД PostgreSQL. Мы поговорим о том, как устроено хранение данных на диске и организован WAL в PostgreSQL, какие есть средства для резервного копирования и восстановления данных. Обсудим, как перестать беспокоиться за свои данные и почему PostgreSQL славится своей надёжностью.
Обзор перспективных баз данных для highload / Юрий НасретдиновOntico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2773.html
В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB.
...
Разработка real-time приложений с RethinkDB / Илья Вербицкий (Независимый кон...Ontico
RethinkDB - это распределенное документо-ориентированное хранилище данных с открытым исходным кодом. Данная система ориентирована на разработку систем обработки данных реального времени, позволяя клиентскому приложению подписываться на изменение тех или иных данных.
В данном докладе я бы хотел осветить не только вопросы разработки приложений на базе RethinkDB, но и поговорить о том, как все это работает. Мы поговорим о ReQL (язык запросов), “changefeeds”, индексах, шардинге, репликациях, а также затронем вопросы особенностей проектирования баз данных под данную платформу.
Раздатчик музыки непосредственно занимается отдачей байтов аудиопотока многочисленным пользователям https://ok.ru/music. В пике суммарный трафик достигает 100 Гб/с через сотни тысяч соединений, а время до первого байта составляет не больше 100 мс. Предыдущая версия раздатчика на основе файлов и Apache Tomcat не устраивала нас требуемым количеством оборудования и неспособностью утилизировать современное железо. При разработке новой версии мы поставили перед собой цель сохранить внешнюю функциональность сервиса неизменной, но обойтись существенно меньшим количеством машин, сохранив при этом масштабируемость и отказоустойчивость сервиса.
В докладе мы рассмотрим, как различные архитектурные решения помогли нам обеспечить масштабируемость и отказоустойчивость сервиса за счёт распределения и репликации музыкальных треков между нодами. Затем подробно поговорим про устройство отдельной ноды, включая отказоустойчивую подсистему хранения, сетевую подсистему, а также использование подхода reactive streams. Уделим особое внимание собранным граблям и трюкам, позволившим увеличить производительность системы, упростить отладку и эксплуатацию системы.
Доклад ориентирован на разработчиков, которые хотят расширить свой арсенал подходов и инструментов для создания распределённых и/или высоконагруженных систем с интенсивным I/O.
Горизонтальное масштабирование: что, зачем, когда и как /Александр Макаров (Y...Ontico
Масштабирование — способность наращивать систему для обработки большего количества трафика, не теряя при этом пользовательские качества: скорость и отзывчивость.
Масштабирование различают двух типов: вертикальное (больше памяти, диска, лучше процессор) и горизонтальное (больше серверов в кластере).
- Зачем оно нужно, если и так всё работает?
- Когда? Мониторинг, необдуманные решения, оптимизация и жизнь с одним сервером.
- Типичная схема.
- Балансировка нагрузки.
- Какие, вообще, проблемы на стороне приложения?
- Почему PHP так хорош для масштабирования.
- Сессии.
- База данных.
- Файлы.
- Как быть со статистикой?
Хранение данных на виниле / Константин Осипов (tarantool.org)Ontico
В rfc1149 дан исчерпывающий обзор преимуществ голубиной почты для протокола IP: низкая пропускная способность, невысокая надёжность, простая топология сети. Для того чтобы дать адекватный ответ вызовам эпохи мемристоров и квантовых вычислений, Tarantool 1.7 содержит новый движок для хранения данных на классических жёстких дисках и флэш-накопителях: Vinyl. Tarantool известен своей скоростью, и мы постарались не ударить в грязь лицом и на этот раз.
В докладе я расскажу об устройстве нашего нового storage engine:
- как мы объединили in-memory технологию и LSM (log structured merge) деревья для достижения оптимальной производительности и утилизации ресурса накопителя,
- как работает multiversion concurrency control в Vinyl,
- основной компонент в промышленной реализации LSM дерева - merge scheduler, т.е. планировщик слияний и сборки мусора дерева. Я расскажу о подходе, который позволяет максимально снизить износ накопителя, при этом уложиться в заданные рамки производительности запросов.
Кластеры баз данных делаем сложные вещи просто / Андрей Тихонов (Avito)Ontico
Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?
Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных.
Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения.
В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения.
В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД.
План доклада:
- Введение. Методы масштабирования БД: репликация, шардирование.
- Создаём шардированные кластеры in-memory БД прозрачно для приложений: Twemproxy, Redis-proxy, Mcrouter.
- Уменьшаем накладные расходы от большого количества одновременных подключений на PostgreSQL с помощью PgBouncer.
- Создаём шардированный кластер PostgreSQL с помощью PL/Proxy.
- Добавляем прозрачную для приложения отказо�
Внутреннее устройство PostgreSQL: временные таблицы и фрагментация памяти / Г...Ontico
Всем известно о существовании временных таблиц в PostgreSQL, но как они устроены, и чем грозит их некорректное использование - не столь очевидно.
На примере одного известного приложения, активно и некорректно использующего временные таблицы, мы расскажем о создаваемой ими проблеме фрагментации памяти.
Что такое фрагментация памяти, по каким признакам можно определить ее наличие, чем она грозит, почему она возникает при активном использовании временных таблиц, и как мы пропатчили PostgreSQL, чтобы ее избежать - обо всем этом можно узнать из нашего доклада.
Системный администратор Vkontakte. Как? / Антон Кирюшкин (Vkontakte)Ontico
Достаточно давно уже был какой-то доклад о том, что собой представляет Вконтакте изнутри. В своем докладе я хотел быть отчасти обновить те знания и рассказать, какие из общедоступных инструментов есть в руках системных администраторов социальной сети. Разумеется, кроме чистой головы и прямых рук (лишнее зачеркнуть).
Я намереваюсь коснуться таких вопросов, как:
- Управление конфигурацией на очень большом числе серверов.
- Разграничение доступа.
- Развертывание кода на рабочей площадке.
- Мониторинг.
- Как мы, вообще, справляемся с таким гигантом малым числом людей?
КРИ 2013. "Базы данных в онлайн играх. От Аллодов до Skyforge". Андрей ФроловАндрей Фролов
Конференция разработчиков игры. 2013 год.
Андрей Фролов. Mail.Ru Games. "Базы данных в онлайн играх. От Аллодов до Skyforge"
Created using YouTube Video
Эксперименты с Postgres в Docker и облаках — оптимизация настроек и схемы ва...Nikolay Samokhvalov
Администрирование баз данных в будущем будет полностью автоматизировано. Это уже так для базовых операций DBA: поднятие инстансов, бэкапы, управление репликацией, failover — мы наблюдаем это по бурному развитию облачных «управляемых» СУБД (AWS RDS, Google Cloud SQL и десятков игроков поменьше), работе над k8s-оператором для Postgres и MySQL в ряде компаний, внедрению внутренних RDS-like DBaaS (database-as-a-service) решений внутри крупных организаций.
Но диагностика и оптимизация производительности баз данных сегодня всё ещё очень «ручные». Например, в Postgres: находим медленную группу запросов в pg_stat_statements, ищем конкретный пример (а то и «выдумываем» его на ходу), пробуем EXPLAIN ANALYZE сначала в dev/staging-окружении, где, как правило, данных не так много, а потом на prod'е... Подбираем индекс, убеждаемся, что он ускоряет (вроде бы) один SQL-запрос и — всё, отправляем в production. Метод «чик-чик и в production» должен остаться в прошлом! Как остались в прошлом развёртывание и настройка серверов и сервисов вручную.
Nancy CLI (https://github.com/postgres-ai/nancy) – открытый фреймворк для проведения экспериментов над базами данных PostgreSQL, позволяющий любому инженеру наладить системный подход к анализу и оптимизации производительности БД. Nancy поддерживает проведение экспериментов локально (на любом сервере) и удалённо на дешёвых высокопроизводительных спот-инстансах AWS EC2.
Без каких-либо специальных знаний, используя Nancy CLI, любой инженер может теперь:
- собрать подробную информацию о поведении «SQL-запросов с прода» на «клоне прода», но «не трогая прод» с целью выявления узких мест (на «проде» под нагрузкой включать обширную диагностику неразумно, а иногда и невозможно);
- проверить, как тот или иной индекс влияет на производительность SQL (в том числе, насколько он замедлит UPDATE'ы);
- подобрать оптимальные параметры настройки Postgres'а (пример: запустить в облаке проверку 100 вариантов default_statistics_target с подробным исследованием эффекта и анализом для каждой группы SQL-запросов);
- сравнить 2+ прогонов моделированной нагрузки на клоне реальной БД в различных условиях (разное оборудование, разные версии Postgres, разные настройки, разные наборы индексов).
В докладе мы также обсудим конкретные примеры внедрения метода автоматизации экспериментов над БД и Nancy CLI в ряд проектов различных компаний (БД до 2ТБ, hybrid workload, до 15k TPS) и трудности, которые пришлось преодолеть на пути:
1. Включение полного логирования запросов: когда это просто страх, а когда это действительно серьёзный стресс для сервера? Как быть, если диски «не тянут» полное логирование?
2. Вопросы безопасности: нужно ли давать доступ к экспериментальным узлам всем разработчикам или можно обойтись без этого? Обфускировать ли данные?
3. Как убедиться, что результаты эксперимента достоверны?
4. Как проводить эксперименты над терабайтной базой данных быстро?
5. Стоит ли включать Nancy в CI/CD-конвейер?
Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)Ontico
Некоторое время назад, когда в очередной раз встал вопрос о производительности большого парка mysql sharding серверов, мы не захотели покупать новые сервера и производить resharding. Мы обнаружили, что компания facebook выпустила в opensource большое количество своих разработок, в том числе и модуль ядра flashcache.
Flashcache — модуль для кэширования блоков блочного устройства, предоставляющий 4 разных режима кэширования.
В данном докладе я расскажу, как мы тестировали, поэтапно проверяя под нагрузкой, 3 из 4 режимов кэширования, сравнивая и выбирая оптимальный. Итогом данной работы стало внедрение данного модуля в нашу архитектуру (фотосервера, сервера БД).
Балансировка нагрузки и отказоустойчивость в ОдноклассникахOntico
Главная → Тезисы и презентации
Балансировка нагрузки и отказоустойчивость в Одноклассниках Системное администрирование
Доклад принят в Программу конференции
Никита Духовный
Одноклассники
Ведущий системный администратор в Одноклассниках. Начинал IT-карьеру разработчиком, занимался релиз инженерией, выбрал системное администрирование.
Возглавляет одну из команд. Занимается задачами, обеспечивающими работу портала - автоматизацией, запуском новых решений, поддержкой инфраструктуры. Ведёт несколько хардкорных проектов, в том числе - по повышению отказоустойчивости портала.
Тезисы
Проект Одноклассники начинал свою жизнь в одном датацентре.
С ростом популярности растёт и нагрузка. С ростом нагрузки открываются проблемы:
- Ни один, даже самый мощный, сервер больше не справляется в одиночку.
- Нагрузка растёт, а в датацентре нет места для нового оборудования.
- Падение датацентра безоговорочно приводит к даунтайму.
- Сетевой сбой выводит портал из строя.
- Пользователи в удалённых регионах страдают от низкой скорости.
Я без прикрас расскажу вам, как мы в Одноклассниках решаем эти проблемы. Поговорим о следующем:
- CDN - каким пользователям важен, его архитектура, устройство наших CDN-приложений, что происходит при авариях.
- Датацентры - почему мы используем три основных датацентра, где они расположены (и почему именно там), распределение пользовательского трафика между ними.
- Сеть - как и до чего мы балансируем трафик.
- Балансировщики - как мы используем LVS, почему (и в каких случаях) используем и другие решения. Что делаем с приложениями, которые нельзя ставить за балансировщик.
- Модули портала - о балансировке в нашем RPC протоколе, о том, что происходит с Одноклассниками при падении датацентра.
Владимир Бородин: Как спать спокойно - 2015.10.14 PostgreSQLRussia.org meetu...Nikolay Samokhvalov
More: http://PostgreSQLRussia.org
Доклад посвящён резервному хранению СУБД PostgreSQL. Мы поговорим о том, как устроено хранение данных на диске и организован WAL в PostgreSQL, какие есть средства для резервного копирования и восстановления данных. Обсудим, как перестать беспокоиться за свои данные и почему PostgreSQL славится своей надёжностью.
Обзор перспективных баз данных для highload / Юрий НасретдиновOntico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2773.html
В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB.
...
Разработка real-time приложений с RethinkDB / Илья Вербицкий (Независимый кон...Ontico
RethinkDB - это распределенное документо-ориентированное хранилище данных с открытым исходным кодом. Данная система ориентирована на разработку систем обработки данных реального времени, позволяя клиентскому приложению подписываться на изменение тех или иных данных.
В данном докладе я бы хотел осветить не только вопросы разработки приложений на базе RethinkDB, но и поговорить о том, как все это работает. Мы поговорим о ReQL (язык запросов), “changefeeds”, индексах, шардинге, репликациях, а также затронем вопросы особенностей проектирования баз данных под данную платформу.
Раздатчик музыки непосредственно занимается отдачей байтов аудиопотока многочисленным пользователям https://ok.ru/music. В пике суммарный трафик достигает 100 Гб/с через сотни тысяч соединений, а время до первого байта составляет не больше 100 мс. Предыдущая версия раздатчика на основе файлов и Apache Tomcat не устраивала нас требуемым количеством оборудования и неспособностью утилизировать современное железо. При разработке новой версии мы поставили перед собой цель сохранить внешнюю функциональность сервиса неизменной, но обойтись существенно меньшим количеством машин, сохранив при этом масштабируемость и отказоустойчивость сервиса.
В докладе мы рассмотрим, как различные архитектурные решения помогли нам обеспечить масштабируемость и отказоустойчивость сервиса за счёт распределения и репликации музыкальных треков между нодами. Затем подробно поговорим про устройство отдельной ноды, включая отказоустойчивую подсистему хранения, сетевую подсистему, а также использование подхода reactive streams. Уделим особое внимание собранным граблям и трюкам, позволившим увеличить производительность системы, упростить отладку и эксплуатацию системы.
Доклад ориентирован на разработчиков, которые хотят расширить свой арсенал подходов и инструментов для создания распределённых и/или высоконагруженных систем с интенсивным I/O.
Горизонтальное масштабирование: что, зачем, когда и как /Александр Макаров (Y...Ontico
Масштабирование — способность наращивать систему для обработки большего количества трафика, не теряя при этом пользовательские качества: скорость и отзывчивость.
Масштабирование различают двух типов: вертикальное (больше памяти, диска, лучше процессор) и горизонтальное (больше серверов в кластере).
- Зачем оно нужно, если и так всё работает?
- Когда? Мониторинг, необдуманные решения, оптимизация и жизнь с одним сервером.
- Типичная схема.
- Балансировка нагрузки.
- Какие, вообще, проблемы на стороне приложения?
- Почему PHP так хорош для масштабирования.
- Сессии.
- База данных.
- Файлы.
- Как быть со статистикой?
Хранение данных на виниле / Константин Осипов (tarantool.org)Ontico
В rfc1149 дан исчерпывающий обзор преимуществ голубиной почты для протокола IP: низкая пропускная способность, невысокая надёжность, простая топология сети. Для того чтобы дать адекватный ответ вызовам эпохи мемристоров и квантовых вычислений, Tarantool 1.7 содержит новый движок для хранения данных на классических жёстких дисках и флэш-накопителях: Vinyl. Tarantool известен своей скоростью, и мы постарались не ударить в грязь лицом и на этот раз.
В докладе я расскажу об устройстве нашего нового storage engine:
- как мы объединили in-memory технологию и LSM (log structured merge) деревья для достижения оптимальной производительности и утилизации ресурса накопителя,
- как работает multiversion concurrency control в Vinyl,
- основной компонент в промышленной реализации LSM дерева - merge scheduler, т.е. планировщик слияний и сборки мусора дерева. Я расскажу о подходе, который позволяет максимально снизить износ накопителя, при этом уложиться в заданные рамки производительности запросов.
Кластеры баз данных делаем сложные вещи просто / Андрей Тихонов (Avito)Ontico
Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?
Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных.
Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения.
В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения.
В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД.
План доклада:
- Введение. Методы масштабирования БД: репликация, шардирование.
- Создаём шардированные кластеры in-memory БД прозрачно для приложений: Twemproxy, Redis-proxy, Mcrouter.
- Уменьшаем накладные расходы от большого количества одновременных подключений на PostgreSQL с помощью PgBouncer.
- Создаём шардированный кластер PostgreSQL с помощью PL/Proxy.
- Добавляем прозрачную для приложения отказо�
Внутреннее устройство PostgreSQL: временные таблицы и фрагментация памяти / Г...Ontico
Всем известно о существовании временных таблиц в PostgreSQL, но как они устроены, и чем грозит их некорректное использование - не столь очевидно.
На примере одного известного приложения, активно и некорректно использующего временные таблицы, мы расскажем о создаваемой ими проблеме фрагментации памяти.
Что такое фрагментация памяти, по каким признакам можно определить ее наличие, чем она грозит, почему она возникает при активном использовании временных таблиц, и как мы пропатчили PostgreSQL, чтобы ее избежать - обо всем этом можно узнать из нашего доклада.
Системный администратор Vkontakte. Как? / Антон Кирюшкин (Vkontakte)Ontico
Достаточно давно уже был какой-то доклад о том, что собой представляет Вконтакте изнутри. В своем докладе я хотел быть отчасти обновить те знания и рассказать, какие из общедоступных инструментов есть в руках системных администраторов социальной сети. Разумеется, кроме чистой головы и прямых рук (лишнее зачеркнуть).
Я намереваюсь коснуться таких вопросов, как:
- Управление конфигурацией на очень большом числе серверов.
- Разграничение доступа.
- Развертывание кода на рабочей площадке.
- Мониторинг.
- Как мы, вообще, справляемся с таким гигантом малым числом людей?
КРИ 2013. "Базы данных в онлайн играх. От Аллодов до Skyforge". Андрей ФроловАндрей Фролов
Конференция разработчиков игры. 2013 год.
Андрей Фролов. Mail.Ru Games. "Базы данных в онлайн играх. От Аллодов до Skyforge"
Created using YouTube Video
Эксперименты с Postgres в Docker и облаках — оптимизация настроек и схемы ва...Nikolay Samokhvalov
Администрирование баз данных в будущем будет полностью автоматизировано. Это уже так для базовых операций DBA: поднятие инстансов, бэкапы, управление репликацией, failover — мы наблюдаем это по бурному развитию облачных «управляемых» СУБД (AWS RDS, Google Cloud SQL и десятков игроков поменьше), работе над k8s-оператором для Postgres и MySQL в ряде компаний, внедрению внутренних RDS-like DBaaS (database-as-a-service) решений внутри крупных организаций.
Но диагностика и оптимизация производительности баз данных сегодня всё ещё очень «ручные». Например, в Postgres: находим медленную группу запросов в pg_stat_statements, ищем конкретный пример (а то и «выдумываем» его на ходу), пробуем EXPLAIN ANALYZE сначала в dev/staging-окружении, где, как правило, данных не так много, а потом на prod'е... Подбираем индекс, убеждаемся, что он ускоряет (вроде бы) один SQL-запрос и — всё, отправляем в production. Метод «чик-чик и в production» должен остаться в прошлом! Как остались в прошлом развёртывание и настройка серверов и сервисов вручную.
Nancy CLI (https://github.com/postgres-ai/nancy) – открытый фреймворк для проведения экспериментов над базами данных PostgreSQL, позволяющий любому инженеру наладить системный подход к анализу и оптимизации производительности БД. Nancy поддерживает проведение экспериментов локально (на любом сервере) и удалённо на дешёвых высокопроизводительных спот-инстансах AWS EC2.
Без каких-либо специальных знаний, используя Nancy CLI, любой инженер может теперь:
- собрать подробную информацию о поведении «SQL-запросов с прода» на «клоне прода», но «не трогая прод» с целью выявления узких мест (на «проде» под нагрузкой включать обширную диагностику неразумно, а иногда и невозможно);
- проверить, как тот или иной индекс влияет на производительность SQL (в том числе, насколько он замедлит UPDATE'ы);
- подобрать оптимальные параметры настройки Postgres'а (пример: запустить в облаке проверку 100 вариантов default_statistics_target с подробным исследованием эффекта и анализом для каждой группы SQL-запросов);
- сравнить 2+ прогонов моделированной нагрузки на клоне реальной БД в различных условиях (разное оборудование, разные версии Postgres, разные настройки, разные наборы индексов).
В докладе мы также обсудим конкретные примеры внедрения метода автоматизации экспериментов над БД и Nancy CLI в ряд проектов различных компаний (БД до 2ТБ, hybrid workload, до 15k TPS) и трудности, которые пришлось преодолеть на пути:
1. Включение полного логирования запросов: когда это просто страх, а когда это действительно серьёзный стресс для сервера? Как быть, если диски «не тянут» полное логирование?
2. Вопросы безопасности: нужно ли давать доступ к экспериментальным узлам всем разработчикам или можно обойтись без этого? Обфускировать ли данные?
3. Как убедиться, что результаты эксперимента достоверны?
4. Как проводить эксперименты над терабайтной базой данных быстро?
5. Стоит ли включать Nancy в CI/CD-конвейер?
Доклад от Parallels:
Методики тестировния производительности database-centric приложений
Описание: При работе над сложными продуктами в database-centric приложениях изменения в коде и тем более в SQL запросах к базе данных могут приводить к неожиданным падениям производительности или же деградации производительности приложения с ростом размера базы данных. Поэтому важно уметь как можно быстрее отлавливать и исправлять причины таких деградаций.
Доклад о том, как устроен процесс мониторинга производительности продукта автоматизации хостинга и облачных сервисов Parallels Automation, для которого определяющим фактором является производительность базы данных.
Компания покажет, как анализирует планы исполнения SQL запросов внутри PostgreSQL, как проверяет насколько быстро и эффективно в целом работают SQL запросы, как определяет стратегию дальнейшей оптимизации.
Технологические решения для импортозамещения в программной инфраструктуреКРОК
Семинар «Вендорозамещение на 100%: инфраструктура, телеком и все-все-все»
http://www.croc.ru/action/detail/50595/
Презентация Андрея Есенкова, эксперта департамента информационных технологий
Open source субд глазами обычного программистаSlach
Попытался "быстренько" пробежаться по всем СУБД с которыми работал за 20 лет и постараться вложить слушателям мысль что СУБД надо выбирать под нагрузку
и что для СУБД надо знать "алгоритмы" и "эксплуатацию"
Пишем свою платформу для управления данными. Это очень просто / Суханов Васил...Ontico
На примере платформы SAP HANA рассмотрим подходы к созданию высокопроизводительной платформы для управления большими массивами данных и выполнения сложных вычислений. В ходе сессии будут представлены архитектурные решения, которые частично легли в основу платформы, а также будет проведён сравнительный анализ предложенных решений в приложении к современным разработкам Intel в области архитектуры ЭВМ.
Тезисы - http://www.highload.ru/2015/abstracts/1856.html
Денис Колошко, Пример нагруженной системы на базе продуктов Microsoft, Amazon...Tanya Denisyuk
Будет показан пример архитектуры популярной социальной сети в Англии, переработанной на новом стеке, чтобы решить проблемы производительности, отказоустойчивости и горизонтального масштабирования. Новый стек базируется на технологиях: .NET, SignalR, Couchbase, RabbitMQ, ElasticSearch, Amazon Services (CloudFront, S3, EC2, Route 53, Balancer), Windows, Linux. Цель: показать одну из моделей архитектуры нагруженных веб-систем, практики и возможные подводные камни при разработке высоконагруженных Интернет систем.
СУБД Firebird: Краткий обзор, Дмитрий Еманов (in Russian)Alexey Kovyazin
Небольшая презентация Дмитрия Еманова, ведущего разработчика Firebird, посвящена обзору СУБД Firebird, в том числе текущему состоянию и планам развития.
3. Запущена в 2000
10+ миллионов пользователей в сутки
200.000 RPS в бэкенды web/mobile/imap
150+ миллионов писем покладки в сутки
20+ ПБ данных
3
О Яндекс.Почте
4. Миграция из Oracle в PostgreSQL
300+ ТБ метаданных без избыточности
250k запросов в секунду
OLTP: 80% чтений, 20% записи
Предыдущие попытки
MySQL
Самописное решение
4
Об этом рассказе
8. Всё хранилось в Oracle
Очень много PL/SQL логики
Эффективная утилизация аппаратного обеспечения
10+ ТБ данных на шард
Рабочий LA 100
Много ручных операций
Тёплые (SSD) и холодные (SATA) базы для разных пользователей
75% SSD, 25% SATA
8
Метаданные Яндекс.Почты
12. PL/SQL deploy
Library cache
Множество ручных операций
Переключение мастера, наливка новой базы, переносы данных
Только синхронный интерфейс в OCCI
Проблемы с разработческими окружениями
Не очень отзывчивая поддержка
12
Наиболее популярные проблемы
15. Октябрь 2012 — политическое решение
Избавиться от Oracle за 3 года
Апрель 2013 — первые эксперименты с разными СУБД
PostgreSQL
Множество NoSQL решений
Самописное решение на основе поискового бэкенды
Июль 2013 — июнь 2014 — эксперимент со сборщиками
https://simply.name/ru/video-pg-meetup-yandex.html
15
Эксперименты
16. Август 2014 — декабрь 2014
Прокладка всего боевого потока писем в PostgreSQL
Асинхронно
Первоначальные решения со схемой данных
Важно для слоя абстракции
Нагрузочное тестирование под живой нагрузкой
Выбор аппаратного обеспечения
Множество другого опыта работы с PostgreSQL
https://simply.name/ru/postgresql-and-systemtap.html
16
Прототип всей почты
17. Январь 2015 — январь 2016 — разработка
Июнь 2015 — dog fooding
Ускорение разработки
Сентябрь 2015 — начало миграции неактивных пользователей
Исправление ошибок в коде переноса
Обратный перенос (план Б)
Январь 2016 — апрель 2016 — миграция
17
Основная работа
25. Тёплые базы (SSD) для большинства активных пользователей
Холодные базы (SATA) для всех неактивных пользователей
Горячие базы для очень активных пользователей
2% пользователей создают 50% нагрузки
Автоматизация переноса пользователей между типами шардов
TBD: перемещение старых писем активных пользователей с SSD на
SATA
25
Аппаратное обеспечение
26. В Oracle все идентификаторы (mid, fid, lid, tid) глобально уникальны
Диапазоны для sequence’ов каждого шарда в отдельной БД
NUMBER(20, 0) — 20 байт
В PostgreSQL идентификаторы уникальны в пределах одного логина
Вместо уникального mid уникальная пара (uid, mid)
Bigint + bigint — 16 байт
26
Идентификаторы
27. Меньше конкуренция за одну страницу индекса
Обычный B-Tree вместо реверсивных индексов
Ревизии для всех объектов
Возможность читать с реплик только актуальные данные
Инкрементальные обновления для IMAP и мобильных
Денормализация части данных
Массивы и GIN
Композитные типы
27
Изменения схемы
28. xdb01g/maildb M # dS mail.box
Table "mail.box"
Column | Type | Modifiers
---------------+--------------------------+------------------------
uid | bigint | not null
mid | bigint | not null
lids | integer[] | not null
<...>
Indexes:
"pk_box" PRIMARY KEY, btree (uid, mid)
"i_box_uid_lids" gin (mail.ulids(uid, lids)) WITH (fastupdate=off)
<...>
xdb01g/maildb M #
28
Пример
29. PL/pgSQL прекрасен
Сильно сократили количество логики
Только для гарантии логической целостности данных
Сильно увеличили покрытие тестами
Цена ошибки очень высока
Простой deploy
29
Хранимая логика
30. SaltStack
Детальный diff между текущим и ожидаемым состоянием
Все изменения схемы и кода через миграции
Все частые операции автоматизированы
Репрезентативные тестовые окружения
30
Подход к обслуживанию
32. Problem with ExclusiveLock on inserts
Checkpoint distribution
ExclusiveLock on extension of relation with huge shared_buffers
Hanging startup process on the replica after vacuuming on master
Replication slots and isolation levels
Segfault in BackendIdGetTransactionIds
Значительно больше решено без помощи сообщества
32
До начала основного переноса
35. В Oracle бэкапы (inc0 + 6 * inc1) и archive логи ≈ размер БД
В PostgreSQL с barman’ом ≈ N * размер БД, где N > 5
WAL’ы сжимаются, а бэкапы нет
File-level increment’ы толком не работают
Все операции однопоточные и очень медленные
Для 300 ТБ данных понадобилось бы ≈ 2 ПБ под бэкапы
https://github.com/2ndquadrant-it/barman/issues/21
http://pgday.ru/ru/2016/papers/80
35
Резервные копии
36. Проблемы не с PostgreSQL
Проблемы с данными
Очень много legacy за 10+ лет
Ошибки в коде переноса
36
Во время основного переноса
38. Declarative partitioning
Хороший recovery manager
Параллелизм/сжатие/page-level increment’ы
Частичное восстановление (например, одной таблицы) в online
Дальнейшее развитие интерфейса ожиданий
Большой разделяемый кэш, O_DIRECT и асинхронное I/O
Quorum commit
38
Нам не хватает в PostgreSQL
39. 1 PB с отказоустойчивостью (100+ миллиардов строк)
250k TPS
Три календарных года / 10+ человеколет
Быстрее deploy / эффективнее использование времени DBA
Рефакторинг кода всего бэкенда
В 3 раза больше аппаратного обеспечения
Ни одной крупной аварии пока :)
Linux, nginx, postfix, PostgreSQL
39
Итоги