5 способов деплоя PHP-кода в условиях хайлоада / Юрий Насретдинов (Badoo)Ontico
В дата-центрах нашей компании несколько тысяч серверов, и примерно на половине из них нужно выкладывать PHP-код 2 раза в день. Помимо раскладки на production также не стоит забывать о том, что код нужен на стейджинге, и в стейджинг-кластер у нас входит около 50 машин, код на которых обновляется раз в несколько минут. Также есть «хотфиксы» — небольшие (1-5) наборы файлов, которые выкладываются во внеочередном порядке на все или на выделенную часть серверов, чтобы устранить существующие проблемы на продакшне, не дожидаясь полной выкладки.
В этом докладе я расскажу о том, как мы деплоились в течение 10 лет, о том, какую новую систему для деплоя PHP-кода мы разработали и внедрили в production, а также проведу обзор решений для масштабного деплоя кода на PHP и анализ их производительности.
План доклада:
— Наша старая система деплоя, достоинства и недостатки.
— Существующие решения:
* "svn up" / "git pull".
* rsync.
* phar, hhbc (HHVM-specific), "loop".
* rsync + 2 директории + realpath_root (Rasmus-style).
— Требования для новой системы деплоя.
* быстрый деплой на стейджинг (5-10 секунд на 50 серверов).
* возможность атомарно патчить несколько файлов и быстро их выкладывать (10 секунд на весь кластер).
* совместимость с docker.
* поддержка «долгоиграющих» CLI-скриптов (несколько часов).
* низкое потребление ресурсов на принимающей стороне.
* отсутствие необходимости сбрасывать opcache.
* высокая скорость деплоя на продакшн (1-2 минуты на 1500 серверов).
— MDK — multiversion deployment kit.
— Анализ применимости и производительности способов деплоя.
— Выводы.
Эволюция программно-аппаратного обеспечения хранения фотографий в Badoo / Дми...Ontico
На примере нашей системы хранения фотографий мы хотим рассказать о проблемах, с которыми столкнулись в течение прошедших семи лет, связанных с ее программными и аппаратными компонентами, и о путях их решений.
В данном докладе речь пойдет о том, как сохранить независимость от поставщика и построить масштабируемую систему хранения с длительным сроком эксплуатации и способностью к оперативному внесению изменений в конфигурацию. Как сделать изменения на аппаратном уровне прозрачными для разработчиков, а также о том, как упростить развертывание и обслуживание.
В общих чертах изложен опыт и проблемы, которые мы получили в ходе эксплуатации классических мультиконтроллерных СХД. Основная тема - построение собственных хранилищ на базе общедоступных компонентов (полки, адаптеры, экспандеры, интерпозеры, диски, ЦПУ и т.д.) с потенциальной возможностью замены любого из выше перечисленного на другую модель. Дублирование критически важных узлов в рамках одной СХД. Обзор используемых транспортов - SRP, FC, iSCSI и описание того, каким образом можно быстро адаптировать такое хранилище под один или несколько транспортов, с минимальными вложениями. Обзор ПО для реализации СХД (SCST/LIO или проприетарные решения в области Software Defined Storage ). Автоматизация развертывания (инсталляция/управление с помощью Puppet). Тестирование перед вводом в эксплуатацию. Multipath I/O и упрощение именования экспортируемых блочных устройств. Политика составления наборов firmware для стабильной работы. Мониторинг. Расследование сбоев (Order of failure и т.п.).
Building the Enterprise infrastructure with PostgreSQL as the basis for stori...PavelKonotopov
In my talk, I will tell how we built a geographically distributed system of personal data storage based on Open Source software and PostgreSQL. The concept of the inCountry business is to provide customers with a ready-to-use infrastructure for personal data storage. Our business customers are ensured that their customer’s personal data is securely stored within their country’s borders. We wrote an API and SDK and built a variety of services. Our system complies with generally accepted security standards (SOC Type 1, Type 2, PCI DSS, etc.). We built our infrastructure with Consul, Nomad, and Vault, used PostgreSQL, ElasticSearch as a storage system, Nginx, Jenkins, Artifactory, other tools to automate management and deployment. We have assembled our development and management teams - DevOps, Security, Monitoring, and DBA. We use both cloud providers and bare-metal servers located in different regions of the world. Development of the system architecture and ensuring the stability of the infrastructure, consistent and secure operation of all its components is the main task facing our teams.
MySQL 5.7 - NoSQL - JSON, Protocol X, Document Store / Петр Зайцев (Percona)Ontico
В MySQL 5.7 появился целый ряд новых возможностей, позволяющих использовать MySQL в приложениях и как хранилище JSON-документов, и как реляционную базу данных.
В этом докладе мы расскажем о поддержке JSON в MySQL 5.7, а также поговорим о том, когда имеет смысл её использовать, и насколько хорошо она работает. Кроме того, мы остановимся на новом протоколе доступа к MySQL, поддерживающем SQL. Помимо этого, мы рассмотрим CRUD-операции и такие дополнительные функции, как асинхронная коммуникация и пайплайнинг (pipelining).
В заключительной части доклада мы расскажем о возможностях MySQL 5.7 в качестве хранилища документов.
Виртуализированные сетевые сервисы на line rate в серверном окружении / Алекс...Ontico
Технологии NFV идут вперед и никого уже нельзя удивить тем, что сетевые сервисы вместо специализированного оборудования запускают на обычных серверах с хорошей пропускной способностью. Мир уже привык к тому, что на сервере можно обрабатывать 100 Гбит сетевого трафика. Однако эти числа характерны только тогда, когда запускают единственный сервис на сервере, например, только коммутацию пакетов (vSwitch), только NAT, только балансировку нагрузки и т.п. Сейчас же появляется потребность в запуске нескольких сервисов на одной машине, выстраивать сложные pipeline, которые учитывают различные сетевые функции, ACL, L2, L3, QoS, интегрированных с виртуальными машинами и контейнерами.
Для этого в сообществах разрабатываются более сложные фреймворки по обработке сетевых сервисов, которые позволяют разбивать задачи на этапы (stage) — каждый со своей сложностью и временем обработки, автоматически распределять такие этапы по вычислительным мощностям, планировать обработку пакетов так, чтобы увеличить суммарную пропускную способность.
В докладе будет представлен сравнительный обзор таких фреймворков: Intel DPDK Packet Framework, FD.io, Open Dataplane, Open Virtual Network (от проекта Open vSwtich). Будут представлены числовые характеристики и рекомендованные сценарии применения. Также будет освещена интеграция с системами виртуализации.
5 способов деплоя PHP-кода в условиях хайлоада / Юрий Насретдинов (Badoo)Ontico
В дата-центрах нашей компании несколько тысяч серверов, и примерно на половине из них нужно выкладывать PHP-код 2 раза в день. Помимо раскладки на production также не стоит забывать о том, что код нужен на стейджинге, и в стейджинг-кластер у нас входит около 50 машин, код на которых обновляется раз в несколько минут. Также есть «хотфиксы» — небольшие (1-5) наборы файлов, которые выкладываются во внеочередном порядке на все или на выделенную часть серверов, чтобы устранить существующие проблемы на продакшне, не дожидаясь полной выкладки.
В этом докладе я расскажу о том, как мы деплоились в течение 10 лет, о том, какую новую систему для деплоя PHP-кода мы разработали и внедрили в production, а также проведу обзор решений для масштабного деплоя кода на PHP и анализ их производительности.
План доклада:
— Наша старая система деплоя, достоинства и недостатки.
— Существующие решения:
* "svn up" / "git pull".
* rsync.
* phar, hhbc (HHVM-specific), "loop".
* rsync + 2 директории + realpath_root (Rasmus-style).
— Требования для новой системы деплоя.
* быстрый деплой на стейджинг (5-10 секунд на 50 серверов).
* возможность атомарно патчить несколько файлов и быстро их выкладывать (10 секунд на весь кластер).
* совместимость с docker.
* поддержка «долгоиграющих» CLI-скриптов (несколько часов).
* низкое потребление ресурсов на принимающей стороне.
* отсутствие необходимости сбрасывать opcache.
* высокая скорость деплоя на продакшн (1-2 минуты на 1500 серверов).
— MDK — multiversion deployment kit.
— Анализ применимости и производительности способов деплоя.
— Выводы.
Эволюция программно-аппаратного обеспечения хранения фотографий в Badoo / Дми...Ontico
На примере нашей системы хранения фотографий мы хотим рассказать о проблемах, с которыми столкнулись в течение прошедших семи лет, связанных с ее программными и аппаратными компонентами, и о путях их решений.
В данном докладе речь пойдет о том, как сохранить независимость от поставщика и построить масштабируемую систему хранения с длительным сроком эксплуатации и способностью к оперативному внесению изменений в конфигурацию. Как сделать изменения на аппаратном уровне прозрачными для разработчиков, а также о том, как упростить развертывание и обслуживание.
В общих чертах изложен опыт и проблемы, которые мы получили в ходе эксплуатации классических мультиконтроллерных СХД. Основная тема - построение собственных хранилищ на базе общедоступных компонентов (полки, адаптеры, экспандеры, интерпозеры, диски, ЦПУ и т.д.) с потенциальной возможностью замены любого из выше перечисленного на другую модель. Дублирование критически важных узлов в рамках одной СХД. Обзор используемых транспортов - SRP, FC, iSCSI и описание того, каким образом можно быстро адаптировать такое хранилище под один или несколько транспортов, с минимальными вложениями. Обзор ПО для реализации СХД (SCST/LIO или проприетарные решения в области Software Defined Storage ). Автоматизация развертывания (инсталляция/управление с помощью Puppet). Тестирование перед вводом в эксплуатацию. Multipath I/O и упрощение именования экспортируемых блочных устройств. Политика составления наборов firmware для стабильной работы. Мониторинг. Расследование сбоев (Order of failure и т.п.).
Building the Enterprise infrastructure with PostgreSQL as the basis for stori...PavelKonotopov
In my talk, I will tell how we built a geographically distributed system of personal data storage based on Open Source software and PostgreSQL. The concept of the inCountry business is to provide customers with a ready-to-use infrastructure for personal data storage. Our business customers are ensured that their customer’s personal data is securely stored within their country’s borders. We wrote an API and SDK and built a variety of services. Our system complies with generally accepted security standards (SOC Type 1, Type 2, PCI DSS, etc.). We built our infrastructure with Consul, Nomad, and Vault, used PostgreSQL, ElasticSearch as a storage system, Nginx, Jenkins, Artifactory, other tools to automate management and deployment. We have assembled our development and management teams - DevOps, Security, Monitoring, and DBA. We use both cloud providers and bare-metal servers located in different regions of the world. Development of the system architecture and ensuring the stability of the infrastructure, consistent and secure operation of all its components is the main task facing our teams.
MySQL 5.7 - NoSQL - JSON, Protocol X, Document Store / Петр Зайцев (Percona)Ontico
В MySQL 5.7 появился целый ряд новых возможностей, позволяющих использовать MySQL в приложениях и как хранилище JSON-документов, и как реляционную базу данных.
В этом докладе мы расскажем о поддержке JSON в MySQL 5.7, а также поговорим о том, когда имеет смысл её использовать, и насколько хорошо она работает. Кроме того, мы остановимся на новом протоколе доступа к MySQL, поддерживающем SQL. Помимо этого, мы рассмотрим CRUD-операции и такие дополнительные функции, как асинхронная коммуникация и пайплайнинг (pipelining).
В заключительной части доклада мы расскажем о возможностях MySQL 5.7 в качестве хранилища документов.
Виртуализированные сетевые сервисы на line rate в серверном окружении / Алекс...Ontico
Технологии NFV идут вперед и никого уже нельзя удивить тем, что сетевые сервисы вместо специализированного оборудования запускают на обычных серверах с хорошей пропускной способностью. Мир уже привык к тому, что на сервере можно обрабатывать 100 Гбит сетевого трафика. Однако эти числа характерны только тогда, когда запускают единственный сервис на сервере, например, только коммутацию пакетов (vSwitch), только NAT, только балансировку нагрузки и т.п. Сейчас же появляется потребность в запуске нескольких сервисов на одной машине, выстраивать сложные pipeline, которые учитывают различные сетевые функции, ACL, L2, L3, QoS, интегрированных с виртуальными машинами и контейнерами.
Для этого в сообществах разрабатываются более сложные фреймворки по обработке сетевых сервисов, которые позволяют разбивать задачи на этапы (stage) — каждый со своей сложностью и временем обработки, автоматически распределять такие этапы по вычислительным мощностям, планировать обработку пакетов так, чтобы увеличить суммарную пропускную способность.
В докладе будет представлен сравнительный обзор таких фреймворков: Intel DPDK Packet Framework, FD.io, Open Dataplane, Open Virtual Network (от проекта Open vSwtich). Будут представлены числовые характеристики и рекомендованные сценарии применения. Также будет освещена интеграция с системами виртуализации.
Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)Ontico
Некоторое время назад, когда в очередной раз встал вопрос о производительности большого парка mysql sharding серверов, мы не захотели покупать новые сервера и производить resharding. Мы обнаружили, что компания facebook выпустила в opensource большое количество своих разработок, в том числе и модуль ядра flashcache.
Flashcache — модуль для кэширования блоков блочного устройства, предоставляющий 4 разных режима кэширования.
В данном докладе я расскажу, как мы тестировали, поэтапно проверяя под нагрузкой, 3 из 4 режимов кэширования, сравнивая и выбирая оптимальный. Итогом данной работы стало внедрение данного модуля в нашу архитектуру (фотосервера, сервера БД).
В этом докладе я в подробностях расскажу о том, как устроено хранение фотографий в нашей компании (всего около ~1 Пб).
Наша система была устроена достаточно просто — сами фотографии хранятся на SAN Storages, которые подключены через Fiber Channel к отдельной группе серверов, "*photos". На photos-серверах смонтированы разделы на соответствующих сетевых блочных устройствах, которые с точки зрения пользователя выглядят, как обычная файловая система.
Мы не используем никакие «хитрые» системы для хранения фотографий и не храним всё в одном файле — каждый размер каждой фотографии представляет из себя обычный файл на файловой системе ext3/4. Фотографии отдаются через nginx напрямую из файловой системы.
Такой способ хранения больших объемов данных весьма дешев, но приводил к проблемам, когда соответствующие SAN «падали», вплоть до повреждения файловой системы с потерей части данных пользователей.
Поэтому, для решения этой проблемы, а также проблем с производительностью, мы решили сделать «софтверную репликацию» фотографий с кешированием данных на SSD.
Также, в качестве эксперимента, мы решили попробовать ещё один способ — хранение на локальных дисках вместо использования SAN. По стоимости решение значительно дороже, но зато надежнее и проще в поддержке. Также, для обеспечения устойчивости к выходу из строя любой машины из такого кластера, мы решили сделать возможной балансировку всех поступающих запросов на весь кластер, то есть, в современных терминах, сделать «распределенное, отказоустойчивое, высокодоступное облачное хранилище».
DNS в условиях хостинг-провайдера / Константин Новаковский (Selectel)Ontico
DNS — это одна из основополагающих служб и протоколов современного интернета, сервис, который должен всегда работать. Каждый раз, когда конечный пользователь обращается к какому-либо ресурсу глобальной паутины, он использует DNS, и чтобы этот самый первый шаг к проектам у наших клиентов не занимал много времени, мы построили свой DNS-хостинг с использованием Anycast-балансировки. Чуть позже мы применили этот метод для балансировки и повышения доступности рекурсивных серверов внутри наших дата-центров.
В своём докладе я расскажу о способах обеспечения непрерывного обслуживания DNS-запросов, подводных камнях использования anycast’а, постараюсь раскрыть актуальные проблемы обслуживания DNS-серверов и поведаю о современных тенденциях в мире DNS.
HDD, SSD, RAM, RAID, и кого на ком кэшировать / Михаил Конюхов (Perfect Solut...Ontico
Рассуждение, опыт, практика и примеры на тему производительности ввода-вывода.
Мы будем сравнивать "дефолтное" поведение SSD и HDD, сравним "недефолтное" поведение после тюнинга HDD. Я расскажу о плюсах и минусах в надежности HDD и SSD, о проблемах восстановления SSD и HDD после сбоев. Многие моменты будут посвящены кэшированию ввода-вывода, что очень помогает в реальных проектах.
Отдельная тема - оптимизация ФС и сервера для снижения количества операций ввода-вывода (IOPS), попробую оценить, что можно сделать с каким-нибудь проектом-примером.
Будут показаны и рассказаны реальные примеры из моего опыта оптимизации IO, я даже нарисую "карту принятия решения" для выбора накопителей для Вашего проекта.
Чем заняться вечером, если я знаю сколько будет ++i + ++i / Андрей Бородин (Y...Ontico
HighLoad++ 2017
Зал «Пекин + Шанхай», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2960.html
При изучении алгоритмов и структур данных я предлагаю студентам закрепить знания и попытаться сделать мир лучше, выполнив небольшие проекты по внедрению эффективных алгоритмов в свободное программное обеспечение. В этом докладе я расскажу несколько идей для таких проектов.
Мы рассмотрим существующие фрагменты исходного кода, поговорим о том, что в нём можно допилить, и обсудим, сколько баллов за это надо давать.
Реализацией идей могут заняться, разумеется, все желающие.
Современная операционная система: что надо знать разработчику / Александр Кри...Ontico
Мы проговорим про связь приложения и ОС, какие компоненты есть в современной ОС на примере Linux, как настройки этих компонент могут повлиять на приложение.
Я расскажу про планировщик процессов, дисковый и сетевой ввод-вывод и соответствующие планировщики, управление памятью - как это все в общих чертах работает и как его потюнить.
Архитектура HAWQ / Алексей Грищенко (Pivotal)Ontico
HAWQ — один из лучших на рынке движков SQL-on-Hadoop, который не раз доказывал свою лидирующую позицию в открытых тестированиях. Что еще более интересно, в конце сентября этого года Pivotal открыл его исходный код под лицензией Apache, а также разместил сам проект в инкубаторе Apache (http://hawq.incubator.apache.org), что делает этот инструмент доступным большому кругу пользователей и намного более привлекательным для компаний — лидеров интернет-индустрии.
Работая в Pivotal, я участвовал в развитии и внедрении этого продукта с первого дня его существования.
В этой презентации я раскрою следующие темы:
+ Что такое HAWQ и зачем он был создан.
+ Кластерная архитектура HAWQ.
+ Принципы работы HAWQ.
+ Внутреннее устройство процессов HAWQ.
+ Интеграция с внешними системами.
+ Альтернативные решения.
Реализация восстановления после аварий / Сергей Бурладян (Avito)Ontico
Базы данных PostgreSQL занимают одно из центральных мест в Авито. Они являются разделяемой платформой, вокруг которой построено множество дополнительных сервисов. Одной из основных задач при их администрировании является задача восстановления после аварий как самих баз, так и связанной с ними инфраструктуры.
В своём докладе я постараюсь рассказать про:
+ общую схему связей баз данных между собой и с другими компонентами;
+ точки отказа и виды аварий, затрагиваемые связи;
+ бинарную репликацию и архив;
+ логическую репликацию, pgq, londiste, UNDO (REDO), пересоздание репки;
+ скрипт и процедуру переключения при аварии;
+ планы: развитие «восстановлений» по всем связям, автоматика на основе системы zookeeper (etcd и т.п.).
Клиентские приложения под нагрузкой (HighLoad 2014)Andrey Smirnov
"Что там писать клиентское приложение - вот сервер, который выдерживает 10 тысяч запросов в секунду!"... "Да они там только API делают, вот бы хоть одно приложение под iOS написали!"
Подобный обмен претензиями частенько можно услышать в спорах клиентских и серверных разработчиков. В этом докладе я попробую примирить обе стороны. Только от успешного взаимодействия клиентского приложения и серверной части зависит успех высоконагруженного проекта в целом.
* Как сделать так, чтобы клиент не "завалил" сервер?
* Коммуникация ошибок от сервера к клиенту.
* Синхронизация, разрешение конфликтов.
* Работа в offline-режиме.
* Разработка эффективного и корректного API.
* Асинхронное взаимодействие.
* Почему клиент и сервер на самом деле очень похожи?
Александр Крашенинников "Hadoop High Availability: опыт Badoo"IT Event
Инфраструктура Hadoop – популярное решение для таких задач, как распределённое хранение данных и вычисления Map/Reduce на кластере. Хорошая масштабируемость и развитая экосистема подкупают и обеспечивают Hadoop’у прочное место в инфраструктуре различных информационных систем. Но чем больше ответственности возлагается на этот компонент, тем важнее обеспечивать его отказоустойчивость и high availability.
Что нужно знать о трёх топовых фичах MySQLSveta Smirnova
MySQL прочно удерживает второе по популярности место после Oracle в рейтинге DB-engines: https://db-engines.com/en/ranking_trend Репликация, табличные движки и поддержка NoSQL не дают MySQL сдавать позиции с 2012 года: года основания рейтинга. Что особенного в этих фичах? Что нужно знать, чтобы использовать их на полную мощность?
Я расскажу про дизайн. Именно он отвечает за то, чтобы ваше приложение не достигло потолка производительности. Понимание архитектуры поможет при проектирование нового приложения, которое впоследствии будет легко масштабироваться.
Доклад рассчитан для начинающих пользователей MySQL. Однако поможет освежить свои знания и более опытным.
Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)Ontico
Некоторое время назад, когда в очередной раз встал вопрос о производительности большого парка mysql sharding серверов, мы не захотели покупать новые сервера и производить resharding. Мы обнаружили, что компания facebook выпустила в opensource большое количество своих разработок, в том числе и модуль ядра flashcache.
Flashcache — модуль для кэширования блоков блочного устройства, предоставляющий 4 разных режима кэширования.
В данном докладе я расскажу, как мы тестировали, поэтапно проверяя под нагрузкой, 3 из 4 режимов кэширования, сравнивая и выбирая оптимальный. Итогом данной работы стало внедрение данного модуля в нашу архитектуру (фотосервера, сервера БД).
В этом докладе я в подробностях расскажу о том, как устроено хранение фотографий в нашей компании (всего около ~1 Пб).
Наша система была устроена достаточно просто — сами фотографии хранятся на SAN Storages, которые подключены через Fiber Channel к отдельной группе серверов, "*photos". На photos-серверах смонтированы разделы на соответствующих сетевых блочных устройствах, которые с точки зрения пользователя выглядят, как обычная файловая система.
Мы не используем никакие «хитрые» системы для хранения фотографий и не храним всё в одном файле — каждый размер каждой фотографии представляет из себя обычный файл на файловой системе ext3/4. Фотографии отдаются через nginx напрямую из файловой системы.
Такой способ хранения больших объемов данных весьма дешев, но приводил к проблемам, когда соответствующие SAN «падали», вплоть до повреждения файловой системы с потерей части данных пользователей.
Поэтому, для решения этой проблемы, а также проблем с производительностью, мы решили сделать «софтверную репликацию» фотографий с кешированием данных на SSD.
Также, в качестве эксперимента, мы решили попробовать ещё один способ — хранение на локальных дисках вместо использования SAN. По стоимости решение значительно дороже, но зато надежнее и проще в поддержке. Также, для обеспечения устойчивости к выходу из строя любой машины из такого кластера, мы решили сделать возможной балансировку всех поступающих запросов на весь кластер, то есть, в современных терминах, сделать «распределенное, отказоустойчивое, высокодоступное облачное хранилище».
DNS в условиях хостинг-провайдера / Константин Новаковский (Selectel)Ontico
DNS — это одна из основополагающих служб и протоколов современного интернета, сервис, который должен всегда работать. Каждый раз, когда конечный пользователь обращается к какому-либо ресурсу глобальной паутины, он использует DNS, и чтобы этот самый первый шаг к проектам у наших клиентов не занимал много времени, мы построили свой DNS-хостинг с использованием Anycast-балансировки. Чуть позже мы применили этот метод для балансировки и повышения доступности рекурсивных серверов внутри наших дата-центров.
В своём докладе я расскажу о способах обеспечения непрерывного обслуживания DNS-запросов, подводных камнях использования anycast’а, постараюсь раскрыть актуальные проблемы обслуживания DNS-серверов и поведаю о современных тенденциях в мире DNS.
HDD, SSD, RAM, RAID, и кого на ком кэшировать / Михаил Конюхов (Perfect Solut...Ontico
Рассуждение, опыт, практика и примеры на тему производительности ввода-вывода.
Мы будем сравнивать "дефолтное" поведение SSD и HDD, сравним "недефолтное" поведение после тюнинга HDD. Я расскажу о плюсах и минусах в надежности HDD и SSD, о проблемах восстановления SSD и HDD после сбоев. Многие моменты будут посвящены кэшированию ввода-вывода, что очень помогает в реальных проектах.
Отдельная тема - оптимизация ФС и сервера для снижения количества операций ввода-вывода (IOPS), попробую оценить, что можно сделать с каким-нибудь проектом-примером.
Будут показаны и рассказаны реальные примеры из моего опыта оптимизации IO, я даже нарисую "карту принятия решения" для выбора накопителей для Вашего проекта.
Чем заняться вечером, если я знаю сколько будет ++i + ++i / Андрей Бородин (Y...Ontico
HighLoad++ 2017
Зал «Пекин + Шанхай», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2960.html
При изучении алгоритмов и структур данных я предлагаю студентам закрепить знания и попытаться сделать мир лучше, выполнив небольшие проекты по внедрению эффективных алгоритмов в свободное программное обеспечение. В этом докладе я расскажу несколько идей для таких проектов.
Мы рассмотрим существующие фрагменты исходного кода, поговорим о том, что в нём можно допилить, и обсудим, сколько баллов за это надо давать.
Реализацией идей могут заняться, разумеется, все желающие.
Современная операционная система: что надо знать разработчику / Александр Кри...Ontico
Мы проговорим про связь приложения и ОС, какие компоненты есть в современной ОС на примере Linux, как настройки этих компонент могут повлиять на приложение.
Я расскажу про планировщик процессов, дисковый и сетевой ввод-вывод и соответствующие планировщики, управление памятью - как это все в общих чертах работает и как его потюнить.
Архитектура HAWQ / Алексей Грищенко (Pivotal)Ontico
HAWQ — один из лучших на рынке движков SQL-on-Hadoop, который не раз доказывал свою лидирующую позицию в открытых тестированиях. Что еще более интересно, в конце сентября этого года Pivotal открыл его исходный код под лицензией Apache, а также разместил сам проект в инкубаторе Apache (http://hawq.incubator.apache.org), что делает этот инструмент доступным большому кругу пользователей и намного более привлекательным для компаний — лидеров интернет-индустрии.
Работая в Pivotal, я участвовал в развитии и внедрении этого продукта с первого дня его существования.
В этой презентации я раскрою следующие темы:
+ Что такое HAWQ и зачем он был создан.
+ Кластерная архитектура HAWQ.
+ Принципы работы HAWQ.
+ Внутреннее устройство процессов HAWQ.
+ Интеграция с внешними системами.
+ Альтернативные решения.
Реализация восстановления после аварий / Сергей Бурладян (Avito)Ontico
Базы данных PostgreSQL занимают одно из центральных мест в Авито. Они являются разделяемой платформой, вокруг которой построено множество дополнительных сервисов. Одной из основных задач при их администрировании является задача восстановления после аварий как самих баз, так и связанной с ними инфраструктуры.
В своём докладе я постараюсь рассказать про:
+ общую схему связей баз данных между собой и с другими компонентами;
+ точки отказа и виды аварий, затрагиваемые связи;
+ бинарную репликацию и архив;
+ логическую репликацию, pgq, londiste, UNDO (REDO), пересоздание репки;
+ скрипт и процедуру переключения при аварии;
+ планы: развитие «восстановлений» по всем связям, автоматика на основе системы zookeeper (etcd и т.п.).
Клиентские приложения под нагрузкой (HighLoad 2014)Andrey Smirnov
"Что там писать клиентское приложение - вот сервер, который выдерживает 10 тысяч запросов в секунду!"... "Да они там только API делают, вот бы хоть одно приложение под iOS написали!"
Подобный обмен претензиями частенько можно услышать в спорах клиентских и серверных разработчиков. В этом докладе я попробую примирить обе стороны. Только от успешного взаимодействия клиентского приложения и серверной части зависит успех высоконагруженного проекта в целом.
* Как сделать так, чтобы клиент не "завалил" сервер?
* Коммуникация ошибок от сервера к клиенту.
* Синхронизация, разрешение конфликтов.
* Работа в offline-режиме.
* Разработка эффективного и корректного API.
* Асинхронное взаимодействие.
* Почему клиент и сервер на самом деле очень похожи?
Александр Крашенинников "Hadoop High Availability: опыт Badoo"IT Event
Инфраструктура Hadoop – популярное решение для таких задач, как распределённое хранение данных и вычисления Map/Reduce на кластере. Хорошая масштабируемость и развитая экосистема подкупают и обеспечивают Hadoop’у прочное место в инфраструктуре различных информационных систем. Но чем больше ответственности возлагается на этот компонент, тем важнее обеспечивать его отказоустойчивость и high availability.
Что нужно знать о трёх топовых фичах MySQLSveta Smirnova
MySQL прочно удерживает второе по популярности место после Oracle в рейтинге DB-engines: https://db-engines.com/en/ranking_trend Репликация, табличные движки и поддержка NoSQL не дают MySQL сдавать позиции с 2012 года: года основания рейтинга. Что особенного в этих фичах? Что нужно знать, чтобы использовать их на полную мощность?
Я расскажу про дизайн. Именно он отвечает за то, чтобы ваше приложение не достигло потолка производительности. Понимание архитектуры поможет при проектирование нового приложения, которое впоследствии будет легко масштабироваться.
Доклад рассчитан для начинающих пользователей MySQL. Однако поможет освежить свои знания и более опытным.
Юрій Свірський "Місто і стартапи: як грамотно взаємодіяти, щоб сприяти розвит...Lviv Startup Club
Юрій Свірський - керівник відділу розумних сервісів Львівської міської ради
Тема доповіді: "Місто і стартапи: як грамотно взаємодіяти, щоб сприяти розвитку".
- HipHop – replacement for Zend PHP
- HPHPc and HHVM
- Supported OS
- Compatibility with PHP: version, extensions
- Operational modes: CLI, Server
- Configuration features
- Performance: capital.ua on Symfony 1.4, Sylius on Symfony 2.3
- HHVM with your project: Vagrant
- Popular frameworks and CMS support
- Competitors: kPHP
Обзор перспективных баз данных для highload / Юрий НасретдиновOntico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2773.html
В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB.
...
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2905.html
Прошло более года с того момента, как Microsoft выпустила первую версию своего нового фреймворка для разработки web-приложений ASP.NET Core, и с каждым днем он находит все больше поклонников. ASP.NET Core базируется на платформе .NET Core, кроссплатформенной версии платформы .NET c открытым исходным кодом. Теперь у С#-разработчиков появилась возможность использовать Mac в качестве среды разработки, и запускать приложения на Linux или внутри Docker-контейнеров.
...
Подходы и технологии, используемые в разработке iOS-клиента Viber, Кирилл Лаш...Yandex
Рассказ об основных принципах, которых придерживается Viber в длительной разработке приложения с большой кодовой базой — если разработкой занимается распределённая команда. Мы обсудим используемые технологии, библиотеки, работу с кодом и многое другое.
Rust позволяет писать быстрые и надёжные программы. Особенно когда они многопоточные. Это делает его хорошим выбором для написания серверной части разнообразных веб-приложений.
Но что для этого нужно? Зачем терпеть все эти длиннющие ошибки от borrow checker'а? Что с продуктивностью разработки? Где взять библиотеки? А что если библиотеки нет? Какой веб-фреймворк выбрать? Как отлаживать и профилировать код?
В своём докладе я отвечу на эти и другие вопросы. Ещё я расскажу, что нужно делать, чтобы обойти проблемные места, которые у Rust, конечно, тоже есть.
Всё это — на примере кода инфраструктурного сервера, обеспечивающего «всегда зелёный master» (commit gatekeeper, аналог homu и zuul).
6. История
• Автор Salvatore Sanfilippo, @antirez, http://antirez.com/
• Зарелизен в марте 2009
• BSD лицензия
• Спонсируется компанией VMWare
• В марте 2010 VMWare наняла Salvatore
• Позже наняли Pieter Noordhuis (key contributor)
7. Redis
• Быстрый, простой, легкий key-value storage в памяти
• Разные структуры данных (String, Hash, List, Sets, ZSet)
• Expire для данных
• Персистентность через асинхронные snapshots или AOF
• Master-slave репликация
• Атомарные операции и транзакционность
• Поддержка нескольких DB
• Pub/Sub
8. Redis
• Написан на ANSI C и работает во многих POSIX системах
• Существует порт для Windows ( https://github.com/dmajkic/redis )
• Очень легко установить и настроить
• Использует память как основной storage
• Диск используется для персистентности
• Single thread (один поток)
14. Performance http://redis.io/topics/benchmarks
• Высокая производительность
• ~50K read/write операций в секунду
• 100K+ read/write операций в секунду на регулярном EC2 instance
• Xeon L5420 clocked at 2.5 GHz 64 bit:
~$ ./redis-benchmark -q -n 100000
PING: 111731.84 requests per second
SET: 108114.59 requests per second
GET: 98717.67 requests per second
INCR: 95241.91 requests per second
LPUSH: 104712.05 requests per second
LPOP: 93722.59 requests per second
15. Persistence - Snapshotting
• # redis.conf
save 60 1000
• Как это работает: fork, temporary new RDB file, replace the old file
• Надежность
• SAVE
/opt/local/var/db/redis/dump.rdb
• BGSAVE
/opt/local/var/db/redis/dump.rdb
16. Persistence - AOF
• Append-only file
• # redis.conf
appendonly yes
• Как это работает: при каждом изменении данных, все команды
записываются в AOF-файл. При перезагрузке Redis - все команды
перевыполняются до текущего состояния
• AOF файл становится большим
• BGREWRITEAOF - оптимизация AOF
17. Virtual Memory http://redis.io/topics/virtual-memory
• # redis.conf
vm-enabled yes
• Позволяет работать данными, которые не помещаются в память
• Прежде чем использовать VM задайте себе вопрос: «Мне действительно
нужен VM?»
• Redis - это storage для размещения данных в памяти!
• VM позволяет хранить keys в памяти, а values читать из диска
18. Virtual Memory
• IMPORTANT NOTE: Redis VM is now deprecated. Redis 2.4 will be the
latest Redis version featuring Virtual Memory (but it also warns you that
Virtual Memory usage is discouraged). We found that using VM has several
disadvantages and problems. In the future of Redis we want to simply provide
the best in-memory database (but persistent on disk as usually) ever, without
considering at least for now the support for databases bigger than RAM. Our
future efforts are focused into providing scripting, cluster, and better
persistence.
http://redis.io/topics/virtual-memory
19. Redis Cluster http://redis.io/topics/cluster-spec
• The Redis core team is already hacking on Redis Cluster. We already have have
some kind of experimental version in the unstable branch, while a Release
Candidate or at least a fully working beta is expected for the end of 2011
• Идея
• распределенность и отказоустойчивость c функционалом stand alone
сервера
• Node может выступить как master так и slave
• Презентация http://bit.ly/rcluster
• Branch 2.4 - https://github.com/antirez/redis
20. Replication http://redis.io/topics/replication
• Master-Slaves
• Slaves-Slave (структура в виде графа)
• Репликация является неблокирующей для мастера
• Репликацию можно использовать для масштабируемости: выполнение
тяжелых операций с SORT или для резервирования данных
• # redis.conf
slaveof 192.168.1.1 6379
• Команда SYNC
21. Sharding
• Распределение данных по нескольким серверам
• Временное решение, пока не реализован Redis Cluster
• Мультиплексный прокси-сервер. Горизонтальное масштабирование
• https://github.com/kni/redis-sharding (Perl) - проект закрыт
• http://github.com/kni/redis-sharding-hs (Haskell) => 4x
23. redis 127.0.0.1:6379> SELECT 1
OK
redis 127.0.0.1:6379[1]> SET mykey "Hello"
OK
redis 127.0.0.1:6379[1]> GET mykey
"Hello"
redis 127.0.0.1:6379[1]> SELECT 0
OK
redis 127.0.0.1:6379> GET mykey
(nil)
redis 127.0.0.1:6379[1]> SELECT 10
OK
redis 127.0.0.1:6379[10]>
26. Keys
• Не бинарно безопасны
• Не должны содержать пробельные символы и rn
• Рекомендации
• Не использовать слишком длинные keys
Не использовать слишком короткие keys
• Как вариант использовать формат keys «object:id:field».
Например:
«user:100:name»
«user:100:email»
29. Strings http://redis.io/commands#string
• Binary Safe
• Максимум 512 Mb
• Основные команды:
SET
GET
APPEND
SETEX
SETNX
STRLEN
30. Strings - Use Cases
• Кеширование
• Инвалидация по признаку (Strings + Sets + DEL)
• Сессии
31. Integers http://redis.io/commands#string
• Атомарные счетчики
• Тип данных Strings
• Команды:
INCR
INCRBY
DECR
DECRBY
32. Integers - Use Cases
• Счетчики
• Генерация уникального ID
33. Hashes http://redis.io/commands#hash
• Напоминает ассоциативный массив в PHP
• Один Hash key и несколько fields
• User => [username => ‘antirez’, password => ‘P1pp0’, age => 34]
• Каждый Hash может хранить 2^32-1 пар field-value
• Основные команды:
HSET HGET HGETALL HDEL HVALS HKEYS HLEN
34. Hashes - Use Cases
• Структурные данные (Posts, Users)
• Настройки приложения/пользователя
36. Sets http://redis.io/commands#set
• Неупорядоченный набор строк
• tags => [tag5, tag3, tag7,]
• В Set хранится только одна уникальная копия элемента / Набор
уникальных элементов
• Максимальное количество элементов в Set 2^32-1
• Основные команды:
SADD SMEMBERS SISMEMBER SREM
37. Sets - Use Cases
• Подсчет уникальных просмотров поста (IP)
• Списки AD объявлений
• Tags, категории
• Relations (Friends/followers)
• Кто в онлайне
39. Lists http://redis.io/commands#list
• Похожи на Sets, за исключением порядка добавление новых элементов
• Подходят для создания очередей или стеков
• Блокирование
• Основные команды:
[B]LPUSH [B]LPOP LLEN LINDEX LRANGE
40. Lists - Use Cases
• Хранение IDs
• Timeline
• Очереди или стеки (сообщения, последние комментарии)
• Логи, статистика
• Background Jobs / Queues
https://github.com/seatgeek/djjob
https://github.com/jamm/Tasks
https://github.com/treffynnon/PHP-at-Job-Queue-Wrapper
http://www.restmq.com
https://github.com/defunkt/resque
42. Sorted Sets http://redis.io/commands#sorted_set
• Похожи на Sets, но отсортированы по score значению
• Быстрый доступ по score или диапазону score
• Основные команды:
ZADD ZRANGE ZRANGEBYSCORE ZREVRANGE
43. Sorted Sets - Use Cases
• Рейтинг игроков
• Индексы для данных (например, age)
• Индексы по возрастанию/убыванию score
• Cчетчики (downloads, hits, votes)
46. Pub/Sub http://redis.io/topics/pubsub
• В основе парадигма Publish/Subscribe
• Сообщения публикуются в каналах, не зная ничего о подписчиках
• Подписчики подписываются на каналы, не задумываясь про
отправителей
• Команды:
[P]SUBSCRIBE PUBLISH [P]UNSUBSCRIBE
53. Redis: The Definitive Guide
• Salvatore Sanfilippo, Pieter Noordhuis
• Released: April 2012
• http://bit.ly/tU6fOD
54. NoSQL Handbook
• Mathias Meyer
• Released: ????
• A handy and outright awesome ebook guide
to the world of NoSQL databases. Includes
heaps of practical material on how to use
NoSQL databases like Redis, MongoDB,
CouchDB, Riak and Cassandra.
• http://nosqlhandbook.com/
• @nosqlhandbook
55. CookBooks
• The Redis cookbook
http://rediscookbook.org/
• Redis tutorial
http://simonwillison.net/static/2010/redis-tutorial/
• Redis: under the hood
http://pauladamsmith.com/articles/redis-under-the-hood.html
• Redis Use Cases
http://highscalability.com/blog/2010/12/6/what-the-heck-are-you-actually-
using-nosql-for.html
59. Ложка дегтя
• Redis это дополнительное решение. Оно не заменит SQL. Хотя аналог
Twitter на нем написан
• Redis-сервер - single-threaded. Но можно запустить один Redis-сервер
на одно свободное ядро
• Redis Cluster еще не готов
• Redis нужно столько памяти - сколько у Вас данных
• Если много данных, то snapshot будет сохранятся на диск долго.
Используете AOF!
• Не стоит использовать команду «KEYS pattern» на продакшене, она
предназначена для отладки. Читайте доки!