Эволюция программно-аппаратного обеспечения хранения фотографий в Badoo / Дми...Ontico
На примере нашей системы хранения фотографий мы хотим рассказать о проблемах, с которыми столкнулись в течение прошедших семи лет, связанных с ее программными и аппаратными компонентами, и о путях их решений.
В данном докладе речь пойдет о том, как сохранить независимость от поставщика и построить масштабируемую систему хранения с длительным сроком эксплуатации и способностью к оперативному внесению изменений в конфигурацию. Как сделать изменения на аппаратном уровне прозрачными для разработчиков, а также о том, как упростить развертывание и обслуживание.
В общих чертах изложен опыт и проблемы, которые мы получили в ходе эксплуатации классических мультиконтроллерных СХД. Основная тема - построение собственных хранилищ на базе общедоступных компонентов (полки, адаптеры, экспандеры, интерпозеры, диски, ЦПУ и т.д.) с потенциальной возможностью замены любого из выше перечисленного на другую модель. Дублирование критически важных узлов в рамках одной СХД. Обзор используемых транспортов - SRP, FC, iSCSI и описание того, каким образом можно быстро адаптировать такое хранилище под один или несколько транспортов, с минимальными вложениями. Обзор ПО для реализации СХД (SCST/LIO или проприетарные решения в области Software Defined Storage ). Автоматизация развертывания (инсталляция/управление с помощью Puppet). Тестирование перед вводом в эксплуатацию. Multipath I/O и упрощение именования экспортируемых блочных устройств. Политика составления наборов firmware для стабильной работы. Мониторинг. Расследование сбоев (Order of failure и т.п.).
В этом докладе я в подробностях расскажу о том, как устроено хранение фотографий в нашей компании (всего около ~1 Пб).
Наша система была устроена достаточно просто — сами фотографии хранятся на SAN Storages, которые подключены через Fiber Channel к отдельной группе серверов, "*photos". На photos-серверах смонтированы разделы на соответствующих сетевых блочных устройствах, которые с точки зрения пользователя выглядят, как обычная файловая система.
Мы не используем никакие «хитрые» системы для хранения фотографий и не храним всё в одном файле — каждый размер каждой фотографии представляет из себя обычный файл на файловой системе ext3/4. Фотографии отдаются через nginx напрямую из файловой системы.
Такой способ хранения больших объемов данных весьма дешев, но приводил к проблемам, когда соответствующие SAN «падали», вплоть до повреждения файловой системы с потерей части данных пользователей.
Поэтому, для решения этой проблемы, а также проблем с производительностью, мы решили сделать «софтверную репликацию» фотографий с кешированием данных на SSD.
Также, в качестве эксперимента, мы решили попробовать ещё один способ — хранение на локальных дисках вместо использования SAN. По стоимости решение значительно дороже, но зато надежнее и проще в поддержке. Также, для обеспечения устойчивости к выходу из строя любой машины из такого кластера, мы решили сделать возможной балансировку всех поступающих запросов на весь кластер, то есть, в современных терминах, сделать «распределенное, отказоустойчивое, высокодоступное облачное хранилище».
Движок LMDB — особенный чемпион / Юрьев Леонид (Петер-Сервис R&D)Ontico
Lightning Memory-Mapped Database (LMDB) представляет собой интересный, во многом уникальный движок базы данных класса Berkeley DB и Level DB с ребус-подобным исходным кодом. Будучи относительно малоизвестным, LMDB показывает ЧЕМПИОНСКУЮ производительность по чтению. Однако при интенсивной записи всё не так радужно…
Было ещё несколько проблем и недостатков, которые нам пришлось устранить, разбираясь в ребусах исходного кода. Доклад точно будет интересен разработчикам, интересующимся внутренностями баз данных или характеристиками отдельных движков.
Проект реализуется силами компании Петер-Сервис R&D, резидента Сколково, для применения в телеком-проектах федерального масштаба.
Информация о нашем проекте https://github.com/ReOpen/ReOpenLDAP/wiki, об исходной версии LMDB http://symas.com/mdb/.
Опыт миграции между дата-центрами / Михаил Тюрин, Сергей Бурладян (Avito)Ontico
В этом докладе мы поделимся опытом, полученным в ходе масштабного проекта по миграции Avito между дата-центрами: как мы осуществляли планирование, подготовку и непосредственно переезд с переключением площадки.
Опишу общие особенности и специфику нашей миграции, "подводные камни" и неочевидные ограничения, с которыми приходилось справляться, в том числе, и в экстремальных условиях.
Загрузка больших объемов данных для бизнес-аналитикиBadoo Development
В Badoo мы разрабатываем собственную систему Business intelligence (сокращённо BI). И прежде, чем приступать к анализу данных, их необходимо извлечь (Extract) из источников, преобразовать (Transform) и загрузить (Load) в аналитическую базу.
Я расскажу об этом процессе - ETL (Extract, Transform, Load). Какие бывают источники данных, какие методы сбора мы используем. И самое главное - об инструменте под названием ETLMaster, созданным в нашей компании для автоматизации управления процессом трансформации и загрузки данных.
HDD, SSD, RAM, RAID, и кого на ком кэшировать / Михаил Конюхов (Perfect Solut...Ontico
Рассуждение, опыт, практика и примеры на тему производительности ввода-вывода.
Мы будем сравнивать "дефолтное" поведение SSD и HDD, сравним "недефолтное" поведение после тюнинга HDD. Я расскажу о плюсах и минусах в надежности HDD и SSD, о проблемах восстановления SSD и HDD после сбоев. Многие моменты будут посвящены кэшированию ввода-вывода, что очень помогает в реальных проектах.
Отдельная тема - оптимизация ФС и сервера для снижения количества операций ввода-вывода (IOPS), попробую оценить, что можно сделать с каким-нибудь проектом-примером.
Будут показаны и рассказаны реальные примеры из моего опыта оптимизации IO, я даже нарисую "карту принятия решения" для выбора накопителей для Вашего проекта.
«Миллион открытых каналов с данными по сети» – Илья Биин (Zenhotels)AvitoTech
Поговорим о том, почему это далеко не самая простая задача, и как следует разбираться с возникающими трудностями. Рассмотрим и покритикуем существующие решения. Научимся создавать свой собственный велосипед.
Эволюция программно-аппаратного обеспечения хранения фотографий в Badoo / Дми...Ontico
На примере нашей системы хранения фотографий мы хотим рассказать о проблемах, с которыми столкнулись в течение прошедших семи лет, связанных с ее программными и аппаратными компонентами, и о путях их решений.
В данном докладе речь пойдет о том, как сохранить независимость от поставщика и построить масштабируемую систему хранения с длительным сроком эксплуатации и способностью к оперативному внесению изменений в конфигурацию. Как сделать изменения на аппаратном уровне прозрачными для разработчиков, а также о том, как упростить развертывание и обслуживание.
В общих чертах изложен опыт и проблемы, которые мы получили в ходе эксплуатации классических мультиконтроллерных СХД. Основная тема - построение собственных хранилищ на базе общедоступных компонентов (полки, адаптеры, экспандеры, интерпозеры, диски, ЦПУ и т.д.) с потенциальной возможностью замены любого из выше перечисленного на другую модель. Дублирование критически важных узлов в рамках одной СХД. Обзор используемых транспортов - SRP, FC, iSCSI и описание того, каким образом можно быстро адаптировать такое хранилище под один или несколько транспортов, с минимальными вложениями. Обзор ПО для реализации СХД (SCST/LIO или проприетарные решения в области Software Defined Storage ). Автоматизация развертывания (инсталляция/управление с помощью Puppet). Тестирование перед вводом в эксплуатацию. Multipath I/O и упрощение именования экспортируемых блочных устройств. Политика составления наборов firmware для стабильной работы. Мониторинг. Расследование сбоев (Order of failure и т.п.).
В этом докладе я в подробностях расскажу о том, как устроено хранение фотографий в нашей компании (всего около ~1 Пб).
Наша система была устроена достаточно просто — сами фотографии хранятся на SAN Storages, которые подключены через Fiber Channel к отдельной группе серверов, "*photos". На photos-серверах смонтированы разделы на соответствующих сетевых блочных устройствах, которые с точки зрения пользователя выглядят, как обычная файловая система.
Мы не используем никакие «хитрые» системы для хранения фотографий и не храним всё в одном файле — каждый размер каждой фотографии представляет из себя обычный файл на файловой системе ext3/4. Фотографии отдаются через nginx напрямую из файловой системы.
Такой способ хранения больших объемов данных весьма дешев, но приводил к проблемам, когда соответствующие SAN «падали», вплоть до повреждения файловой системы с потерей части данных пользователей.
Поэтому, для решения этой проблемы, а также проблем с производительностью, мы решили сделать «софтверную репликацию» фотографий с кешированием данных на SSD.
Также, в качестве эксперимента, мы решили попробовать ещё один способ — хранение на локальных дисках вместо использования SAN. По стоимости решение значительно дороже, но зато надежнее и проще в поддержке. Также, для обеспечения устойчивости к выходу из строя любой машины из такого кластера, мы решили сделать возможной балансировку всех поступающих запросов на весь кластер, то есть, в современных терминах, сделать «распределенное, отказоустойчивое, высокодоступное облачное хранилище».
Движок LMDB — особенный чемпион / Юрьев Леонид (Петер-Сервис R&D)Ontico
Lightning Memory-Mapped Database (LMDB) представляет собой интересный, во многом уникальный движок базы данных класса Berkeley DB и Level DB с ребус-подобным исходным кодом. Будучи относительно малоизвестным, LMDB показывает ЧЕМПИОНСКУЮ производительность по чтению. Однако при интенсивной записи всё не так радужно…
Было ещё несколько проблем и недостатков, которые нам пришлось устранить, разбираясь в ребусах исходного кода. Доклад точно будет интересен разработчикам, интересующимся внутренностями баз данных или характеристиками отдельных движков.
Проект реализуется силами компании Петер-Сервис R&D, резидента Сколково, для применения в телеком-проектах федерального масштаба.
Информация о нашем проекте https://github.com/ReOpen/ReOpenLDAP/wiki, об исходной версии LMDB http://symas.com/mdb/.
Опыт миграции между дата-центрами / Михаил Тюрин, Сергей Бурладян (Avito)Ontico
В этом докладе мы поделимся опытом, полученным в ходе масштабного проекта по миграции Avito между дата-центрами: как мы осуществляли планирование, подготовку и непосредственно переезд с переключением площадки.
Опишу общие особенности и специфику нашей миграции, "подводные камни" и неочевидные ограничения, с которыми приходилось справляться, в том числе, и в экстремальных условиях.
Загрузка больших объемов данных для бизнес-аналитикиBadoo Development
В Badoo мы разрабатываем собственную систему Business intelligence (сокращённо BI). И прежде, чем приступать к анализу данных, их необходимо извлечь (Extract) из источников, преобразовать (Transform) и загрузить (Load) в аналитическую базу.
Я расскажу об этом процессе - ETL (Extract, Transform, Load). Какие бывают источники данных, какие методы сбора мы используем. И самое главное - об инструменте под названием ETLMaster, созданным в нашей компании для автоматизации управления процессом трансформации и загрузки данных.
HDD, SSD, RAM, RAID, и кого на ком кэшировать / Михаил Конюхов (Perfect Solut...Ontico
Рассуждение, опыт, практика и примеры на тему производительности ввода-вывода.
Мы будем сравнивать "дефолтное" поведение SSD и HDD, сравним "недефолтное" поведение после тюнинга HDD. Я расскажу о плюсах и минусах в надежности HDD и SSD, о проблемах восстановления SSD и HDD после сбоев. Многие моменты будут посвящены кэшированию ввода-вывода, что очень помогает в реальных проектах.
Отдельная тема - оптимизация ФС и сервера для снижения количества операций ввода-вывода (IOPS), попробую оценить, что можно сделать с каким-нибудь проектом-примером.
Будут показаны и рассказаны реальные примеры из моего опыта оптимизации IO, я даже нарисую "карту принятия решения" для выбора накопителей для Вашего проекта.
«Миллион открытых каналов с данными по сети» – Илья Биин (Zenhotels)AvitoTech
Поговорим о том, почему это далеко не самая простая задача, и как следует разбираться с возникающими трудностями. Рассмотрим и покритикуем существующие решения. Научимся создавать свой собственный велосипед.
Что нового и полезного в PostgreSQL 9.5 / Илья Космодемьянский (PostgreSQL-Co...Ontico
Доклад о новинках нового релиза PostgreSQL можно сделать экстремально скучным: взять release-notes и зачитать вслух. Но 9.5 обещает быть очень интересным релизом как с точки зрения улучшения производительности, так и функциональности - было бы жалко сделать о нем плохой доклад. Поэтому я выбрал несколько важных и нужных фич и расскажу про каждую - как она устроена, на что влияет и, главное, как ей разумно воспользоваться - максимум практических аспектов, минимум маркетинга. Без этого минимума нельзя, иначе мне никак не поделиться своим взглядом на то, как сейчас развивается PostgreSQL, и как жить пользователям Postgres'а при такой стратегии развития.
Как устроена MySQL-репликация / Андрей Аксенов (Sphinx)Ontico
Какая вообще в природе бывает репликация (sync vs. async vs. semisync, master-master vs. master-slave), как оно устроено конкретно в MySQL, в каких версиях что добавили. Про binary/relay log, про SBR/RBR/mixed форматы, про глупости с позициями и про GTID, про то, как из-за всяких бед возникают дополнительные продукты типа Tungsten и Galera. Несколько занятных фактов и парочка фокусов, которые можно учинять конкретно с MySQL-репликацией.
Доклад вчистую про внутреннее устройство, по результатам должно появляться общее понимание того, как оно работает внутри и почему именно так. Конкретные SQL-операторы подробно рассматривать НЕ будем, эти скучные мелочи необходимо будет затем самостоятельно смотреть в документации (или не смотреть).
Lightning Memory-Mapped Database (LMDB) - представляет собой интересный, во многом уникальный, движок базы данных класса Berkeley DB / Level DB. Будучи относительно малоизвестным, LMDB показывает чемпионскую производительность по чтению и предлагает ряд компромиссов для достижения невероятной производительности по записи.
LMDB был создан для использования внутри известного проекта OpenLDAP с открытым исходным кодом. Как разработчик и поставщик решений для «больших телекомов», компания «Петер-Сервис» решила задействовать связку OpenLDAP+LMDB в одном из своих проектов. Это был вход в кротовую нору, всё было как в сказке – чем дальше, тем страшнее...
В результате мы сделали клон/fork исходного проекта и создали высокопроизводительное стабильное решение промышленного масштаба с открытым исходным кодом. Расскажу о внутреннем устройстве LMDB, о выявленных недостатках и наших доработках для их устранения.
Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)Ontico
Некоторое время назад, когда в очередной раз встал вопрос о производительности большого парка mysql sharding серверов, мы не захотели покупать новые сервера и производить resharding. Мы обнаружили, что компания facebook выпустила в opensource большое количество своих разработок, в том числе и модуль ядра flashcache.
Flashcache — модуль для кэширования блоков блочного устройства, предоставляющий 4 разных режима кэширования.
В данном докладе я расскажу, как мы тестировали, поэтапно проверяя под нагрузкой, 3 из 4 режимов кэширования, сравнивая и выбирая оптимальный. Итогом данной работы стало внедрение данного модуля в нашу архитектуру (фотосервера, сервера БД).
Эволюция php code coverage в Badoo. Доклад Ильи Агеева на LoveQA РИТ.Badoo Development
Рассказали о том как у нас эволюционировала сборка code-coverage для php-кода за 4 года, каких успехов мы достигли на этом поприще и как боролись со скоростью сборки с учетом постоянно растущего количества тестов. Доклад будет полезен как тем, кто только начитает покрывать свой код тестами, так и тем, кто давно этим занимается и сталкивается с проблемами производительности при сборке покрытия.
OpenResty: превращаем NGINX в полноценный сервер приложений / Владимир Прота...Ontico
Все мы знаем, что NGINX – отличный прокси, который может качественно и эффективно распределять нагрузку между бэкендами и фильтровать запросы по определенным условиям. Но при этом часто на практике возникают задачи, которые не решаются его декларативной моделью описания конфигурации: иногда для принятия решения нам нужно сходить в базу данных (в Redis или даже в MySQL), другой сервис или произвести какую-то более сложную обработку запроса/ответа. Именно здесь к нам на помощь приходит мощь Lua и OpenResty.
Из доклада вы узнаете:
* зачем нам Lua внутри NGINX, и почему из седьмого айфона убрали разъем под наушники;
* в каких ситуациях NGINX в паре с Lua справятся с задачей лучше вашего любимого PHP/NodeJS/Ruby/Python/Visual Basic и о прелестях асинхронного ввода-вывода без callback'ов;
* как залезть к NGINX под капот, используя только высокоуровневый язык;
* при чем здесь Openresty, или как упростить себе жизнь;
* примеры бизнес-кейсов: от "умного" прокси до самостоятельного веб-приложения;
* как оно ведет себя в продакшне под большой нагрузкой.
«Как 200 строк на Go помогли нам освободить 15 серверов» – Паша Мурзаков (Badoo)AvitoTech
В Badoo я работаю в команде, которая разрабатывает на PHP. Одна из фич, которой мы занимаемся, со временем начала отъедать всё больше и больше железячных ресурсов. В итоге мы едва успевали добавлять серверы под растущую нагрузку. При этом вечера, проведённые с Go дома, подсказывали, что можно сделать на порядки производительнее, не затратив на разработку много времени.
Я расскажу о том, почему наша фича так плохо ложится на PHP и хорошо – на Go, как уговорить всех всё переписать и не показаться сумасшедшим, ну и, конечно же, как из 19 серверов оставить только 4.
Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)Ontico
Исторически сложилось так, что одни люди разрабатывают приложения (Dev), а другие эксплуатируют их в продакшне (Ops). И у последних есть немало проблем с тем, что невозможно понять, что происходит.
Причем это касается как собственных разработок, так и популярных open source решений.
Я расскажу, как устроена диагностика у некоторых популярных софтин:
- nginx
- postgresql
- mongodb
Мы попробуем разобраться, что там сделано хорошо, и чего не хватает для полного счастья.
Во второй части доклада мы поговорим про то, как нужно инструментировать собственное приложение для прозрачной работы в продакшне:
- что считать и зачем: ошибки, тайминги, разные состояния приложения,
- инструментарий: your_lang-metrics, your_lang-statsd-client, логи,
- как не перемудрить и не убить прод диагностикой.
Может показаться, что этот доклад про DevOps, но нет - про docker не будет ни слова :)
Alexandr Serbul "The Rust language for a high-load network service - a quick ...Fwdays
In this talk, we will talk about the evolution of the development of a high-load network cluster for sending push notifications using technologies from Unix / bash and PHP to asynchronous non-blocking multithreaded connections based on Rust / Tokio. Let's talk about the intricacies of Rust development, language features, pitfalls, and ways to quickly learn and use it for web developers with LAMP skills. Let's also talk about Go, Java, and the reasons for our technological decisions.
The talk will be useful for developers wishing to master the latest and popular Rust programming language, functional programming, Haskell ideas with PHP / Python / JavaScript web development experience.
Сейчас OpenStack на слуху, но детальных отзывов и описаний дизайна инфраструктуры все еще не много. Постараемся немного упростить задачу для тех, кто еще только планирует развертывание инфраструктуры виртуализации, и расскажем, как это делали мы в некоторых наших проектах:
погрузимся в нюансы реализации окружения OpenStack в боевой среде;
поговорим об отказоустойчивости;
рассмотрим варианты организации резервного копирования;
обратим внимание на конфигурацию «железок»: СХД и сети.
Создание и развитие отечественной платформы с открытым программным кодом для ...ARCCN
Доклад в рамках Международной конференции «Управление сетями электросвязи. Программно-конфигурируемые сети и виртуализация сетевых функций – SDN&NFV Russia 2016».
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...Ontico
HighLoad++ 2017
Зал «Калининград», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2964.html
Одноклассники состоят из более чем восьми тысяч железных серверов, расположенных в нескольких дата-центрах. Каждая из этих машин была специализированной под конкретную задачу - как для обеспечения изоляции отказов, так и для обеспечения автоматизированного управления инфраструктурой.
...
Что нового и полезного в PostgreSQL 9.5 / Илья Космодемьянский (PostgreSQL-Co...Ontico
Доклад о новинках нового релиза PostgreSQL можно сделать экстремально скучным: взять release-notes и зачитать вслух. Но 9.5 обещает быть очень интересным релизом как с точки зрения улучшения производительности, так и функциональности - было бы жалко сделать о нем плохой доклад. Поэтому я выбрал несколько важных и нужных фич и расскажу про каждую - как она устроена, на что влияет и, главное, как ей разумно воспользоваться - максимум практических аспектов, минимум маркетинга. Без этого минимума нельзя, иначе мне никак не поделиться своим взглядом на то, как сейчас развивается PostgreSQL, и как жить пользователям Postgres'а при такой стратегии развития.
Как устроена MySQL-репликация / Андрей Аксенов (Sphinx)Ontico
Какая вообще в природе бывает репликация (sync vs. async vs. semisync, master-master vs. master-slave), как оно устроено конкретно в MySQL, в каких версиях что добавили. Про binary/relay log, про SBR/RBR/mixed форматы, про глупости с позициями и про GTID, про то, как из-за всяких бед возникают дополнительные продукты типа Tungsten и Galera. Несколько занятных фактов и парочка фокусов, которые можно учинять конкретно с MySQL-репликацией.
Доклад вчистую про внутреннее устройство, по результатам должно появляться общее понимание того, как оно работает внутри и почему именно так. Конкретные SQL-операторы подробно рассматривать НЕ будем, эти скучные мелочи необходимо будет затем самостоятельно смотреть в документации (или не смотреть).
Lightning Memory-Mapped Database (LMDB) - представляет собой интересный, во многом уникальный, движок базы данных класса Berkeley DB / Level DB. Будучи относительно малоизвестным, LMDB показывает чемпионскую производительность по чтению и предлагает ряд компромиссов для достижения невероятной производительности по записи.
LMDB был создан для использования внутри известного проекта OpenLDAP с открытым исходным кодом. Как разработчик и поставщик решений для «больших телекомов», компания «Петер-Сервис» решила задействовать связку OpenLDAP+LMDB в одном из своих проектов. Это был вход в кротовую нору, всё было как в сказке – чем дальше, тем страшнее...
В результате мы сделали клон/fork исходного проекта и создали высокопроизводительное стабильное решение промышленного масштаба с открытым исходным кодом. Расскажу о внутреннем устройстве LMDB, о выявленных недостатках и наших доработках для их устранения.
Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)Ontico
Некоторое время назад, когда в очередной раз встал вопрос о производительности большого парка mysql sharding серверов, мы не захотели покупать новые сервера и производить resharding. Мы обнаружили, что компания facebook выпустила в opensource большое количество своих разработок, в том числе и модуль ядра flashcache.
Flashcache — модуль для кэширования блоков блочного устройства, предоставляющий 4 разных режима кэширования.
В данном докладе я расскажу, как мы тестировали, поэтапно проверяя под нагрузкой, 3 из 4 режимов кэширования, сравнивая и выбирая оптимальный. Итогом данной работы стало внедрение данного модуля в нашу архитектуру (фотосервера, сервера БД).
Эволюция php code coverage в Badoo. Доклад Ильи Агеева на LoveQA РИТ.Badoo Development
Рассказали о том как у нас эволюционировала сборка code-coverage для php-кода за 4 года, каких успехов мы достигли на этом поприще и как боролись со скоростью сборки с учетом постоянно растущего количества тестов. Доклад будет полезен как тем, кто только начитает покрывать свой код тестами, так и тем, кто давно этим занимается и сталкивается с проблемами производительности при сборке покрытия.
OpenResty: превращаем NGINX в полноценный сервер приложений / Владимир Прота...Ontico
Все мы знаем, что NGINX – отличный прокси, который может качественно и эффективно распределять нагрузку между бэкендами и фильтровать запросы по определенным условиям. Но при этом часто на практике возникают задачи, которые не решаются его декларативной моделью описания конфигурации: иногда для принятия решения нам нужно сходить в базу данных (в Redis или даже в MySQL), другой сервис или произвести какую-то более сложную обработку запроса/ответа. Именно здесь к нам на помощь приходит мощь Lua и OpenResty.
Из доклада вы узнаете:
* зачем нам Lua внутри NGINX, и почему из седьмого айфона убрали разъем под наушники;
* в каких ситуациях NGINX в паре с Lua справятся с задачей лучше вашего любимого PHP/NodeJS/Ruby/Python/Visual Basic и о прелестях асинхронного ввода-вывода без callback'ов;
* как залезть к NGINX под капот, используя только высокоуровневый язык;
* при чем здесь Openresty, или как упростить себе жизнь;
* примеры бизнес-кейсов: от "умного" прокси до самостоятельного веб-приложения;
* как оно ведет себя в продакшне под большой нагрузкой.
«Как 200 строк на Go помогли нам освободить 15 серверов» – Паша Мурзаков (Badoo)AvitoTech
В Badoo я работаю в команде, которая разрабатывает на PHP. Одна из фич, которой мы занимаемся, со временем начала отъедать всё больше и больше железячных ресурсов. В итоге мы едва успевали добавлять серверы под растущую нагрузку. При этом вечера, проведённые с Go дома, подсказывали, что можно сделать на порядки производительнее, не затратив на разработку много времени.
Я расскажу о том, почему наша фича так плохо ложится на PHP и хорошо – на Go, как уговорить всех всё переписать и не показаться сумасшедшим, ну и, конечно же, как из 19 серверов оставить только 4.
Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)Ontico
Исторически сложилось так, что одни люди разрабатывают приложения (Dev), а другие эксплуатируют их в продакшне (Ops). И у последних есть немало проблем с тем, что невозможно понять, что происходит.
Причем это касается как собственных разработок, так и популярных open source решений.
Я расскажу, как устроена диагностика у некоторых популярных софтин:
- nginx
- postgresql
- mongodb
Мы попробуем разобраться, что там сделано хорошо, и чего не хватает для полного счастья.
Во второй части доклада мы поговорим про то, как нужно инструментировать собственное приложение для прозрачной работы в продакшне:
- что считать и зачем: ошибки, тайминги, разные состояния приложения,
- инструментарий: your_lang-metrics, your_lang-statsd-client, логи,
- как не перемудрить и не убить прод диагностикой.
Может показаться, что этот доклад про DevOps, но нет - про docker не будет ни слова :)
Alexandr Serbul "The Rust language for a high-load network service - a quick ...Fwdays
In this talk, we will talk about the evolution of the development of a high-load network cluster for sending push notifications using technologies from Unix / bash and PHP to asynchronous non-blocking multithreaded connections based on Rust / Tokio. Let's talk about the intricacies of Rust development, language features, pitfalls, and ways to quickly learn and use it for web developers with LAMP skills. Let's also talk about Go, Java, and the reasons for our technological decisions.
The talk will be useful for developers wishing to master the latest and popular Rust programming language, functional programming, Haskell ideas with PHP / Python / JavaScript web development experience.
Сейчас OpenStack на слуху, но детальных отзывов и описаний дизайна инфраструктуры все еще не много. Постараемся немного упростить задачу для тех, кто еще только планирует развертывание инфраструктуры виртуализации, и расскажем, как это делали мы в некоторых наших проектах:
погрузимся в нюансы реализации окружения OpenStack в боевой среде;
поговорим об отказоустойчивости;
рассмотрим варианты организации резервного копирования;
обратим внимание на конфигурацию «железок»: СХД и сети.
Создание и развитие отечественной платформы с открытым программным кодом для ...ARCCN
Доклад в рамках Международной конференции «Управление сетями электросвязи. Программно-конфигурируемые сети и виртуализация сетевых функций – SDN&NFV Russia 2016».
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...Ontico
HighLoad++ 2017
Зал «Калининград», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2964.html
Одноклассники состоят из более чем восьми тысяч железных серверов, расположенных в нескольких дата-центрах. Каждая из этих машин была специализированной под конкретную задачу - как для обеспечения изоляции отказов, так и для обеспечения автоматизированного управления инфраструктурой.
...
Обзор перспективных баз данных для highload / Юрий НасретдиновOntico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2773.html
В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB.
...
Highload++2013: TopGun - архитектура терабитной платформы DPILeonid Yuriev
Презентация с конференции HighLoad-2013 об архитектуре новой DPI платформы Петер-Сервис.
http://www.highload.ru/2013/abstracts/1178.html
Представлен обзор архитектуры многоцелевой DPI-платформы, на основе которой могут строиться как "шпионские" приложения класса СОРМ/PRISM, так и коммерческие системы PCEF/TDF (Traffic Shaping), безопасного Интернета (интеллектуальная фильтрация содержимого), таргетирования рекламы и т. д. К особенностям рассматриваемого решения можно отнести мультитерабитное масштабирование, способ балансировки, обработку "роем" (Swarm Intelligence) и аварийного восстановления (failover) посредством репликации конечных автоматов.
Roadmap:
- offtopic: кому и зачем нужен DPI?
- offtopic: законность и морально-этические вопросы.
- на какую "луну" нужно сесть, что мы хотим сделать?
- распределение трафика за счет использования коммутаторов и MAC rewrite.
- роевой интеллект (Swarm Intellegence) для управления балансировкой и обработкой данных.
- репликация конечных автоматов (виртуальных микромашин).
- распределенное "Табло" как оперативное хранилище с элементами key-value и eventual consistency, lockfree в shared memory.
- транспортный фасад, унифицирующий DPDK, netmap, Infiniband (RDMA), 0mq и zerocopy и lockfree обмен через shared memory.
Андрей Сибирёв "Ваше собственное облако — война за независимость"Yandex
Сегодня всё больше и больше компаний решаются на перевод своей инфраструктуры и сервисов в облака. Некоторые даже начинают строить свой бизнес, не имея ни единого собственного сервера для обработки или хранения пользовательских данных, и при этом становятся лидерами в своих сегментах рынка.
Но, несмотря на очевидные преимущества этого подхода, не всех устраивает перспектива быть привязанными к конкретному поставщику облачных услуг. В докладе рассказывается об основных тенденциях в современном «облакостроении», о свободе и гибкости и, самое главное, представляется наша открытая облачная платформа.
Микросервисы: опыт использования в нагруженном проекте / Вадим Мадисон (М-Тех)Ontico
Мы прошли довольно большой путь в разработке через микросервисы.
Начинали разработку, когда это за рубежом только входило в тренд. По сути, не было никакой информации о том, как это делать правильно и, вообще, стоит ли это делать. Не было понятно, имеем ли мы дело с очередной модной штукой, или парадигма действительно решает часть проблем, характерных для больших нагруженных проектов.
Мы прошли путь от того, когда 100 микросервисов казалось много ... Сейчас цифры в 1000, 2000 кажутся чем-то обыденным.
В ходе доклада я постараюсь сделать упор на эксплуатацию системы, работающей на микросервисах. Расскажу, какой инструментарий показал себя хорошо на больших объемах, а от какого пришлось отказаться. Покажу на примерах, как эволюционировала наша система управления конфигурацией системы в целом и отдельными сервисами. Расскажу, как корректно предоставлять API сервиса и правильно поставлять его клиентские библиотеки, чтобы избегать внутренних и искусственных зависимостей. Покажу, как мы работаем с распределенными сервисами и обеспечиваем отказоустойчивость.
Жизнь проекта на production советы по эксплуатации / Николай Сивко (okmeter.io)Ontico
Ваш сайт или другой проект приносит деньги только тогда, когда он работает.
Нельзя просто выложить код на серверы, залить схему в базу данных и делегировать домен.
Будем говорить о планировании отказоустойчивости и мониторинге проектов:
- оцениваем риски отказа различных компонентов;
- какие-то из вероятных проблем просто мониторим и планируем действия при сбоях;
- проблемы, которых можно избежать легко и дешево, закрываем сразу.
Расскажу на примерах о том, что всё всегда ломается, но с этим можно жить.
This document discusses metrics monitoring systems. It provides an overview of the Graphite monitoring system architecture, including the carbon-cache and carbon-relay components. It then evaluates various open source alternatives for handling high volumes of metrics data, finding that a combination of go-carbon and carbon-c-relay can process over 1.4 million requests per second. The document also discusses tagging metrics with metadata and time series databases that support tags.
This document discusses Graphite and options for optimizing its performance for high volumes of metrics data. It summarizes the default Graphite architecture using Carbon and Whisper and different approaches for scaling it up including using go-carbon, carbon-c-relay, and evaluating alternative time series databases like Influx and OpenTSDB. Various techniques for optimizing whisper and cache configurations, I/O performance, and system parameters are also explored. Overall the best performing combination found was go-carbon with carbon-c-relay to handle over 1 million requests per second.
22. Балансеры → логи
• Время сессии
• Время ответа бэкендов
• Статус
• Сортировка по уникальной странице
• Исключить вебсокеты
• Количество запросов (соотношение к UID)
23. Балансеры → метрики
• Время сессии (перцентили)
• Время ответа бэкенда (перцентили)
• Сортировка по статусу
• Сортировка по уникальной странице
• Исключить вебсокеты
• Количество запросов (соотношение к UID)
32. Приложение → логи
• Время ответа и статус
• Включаемый сквозной UID (для отдельного юзера)
• UID в ошибках
• Время выполнения основных методов
33. Приложение → метрики
• Время ответа и статус (перцентили)
• Время выполнения методов (перцентили)
• Группируйте по типу запроса
• Успешные и неудачные — разные метрики