«Масштабируемый DevOps» Александр КолесеньIT Share
Типичные подходы к развертыванию приложений: как правильные, так и неправильные, но повсеместно применяемые.
Как сделать так, чтобы развертывание не стало проблемой с линейным ростом количества поддерживаемых окружений.
Методы обновления проекта с нулевым временем простоя: когда это уместно и принципиально возможно.
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.
— Анализ применимости и производительности способов деплоя.
— Выводы.
«Масштабируемый DevOps» Александр КолесеньIT Share
Типичные подходы к развертыванию приложений: как правильные, так и неправильные, но повсеместно применяемые.
Как сделать так, чтобы развертывание не стало проблемой с линейным ростом количества поддерживаемых окружений.
Методы обновления проекта с нулевым временем простоя: когда это уместно и принципиально возможно.
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.
— Анализ применимости и производительности способов деплоя.
— Выводы.
В этом докладе я в подробностях расскажу о том, как устроено хранение фотографий в нашей компании (всего около ~1 Пб).
Наша система была устроена достаточно просто — сами фотографии хранятся на SAN Storages, которые подключены через Fiber Channel к отдельной группе серверов, "*photos". На photos-серверах смонтированы разделы на соответствующих сетевых блочных устройствах, которые с точки зрения пользователя выглядят, как обычная файловая система.
Мы не используем никакие «хитрые» системы для хранения фотографий и не храним всё в одном файле — каждый размер каждой фотографии представляет из себя обычный файл на файловой системе ext3/4. Фотографии отдаются через nginx напрямую из файловой системы.
Такой способ хранения больших объемов данных весьма дешев, но приводил к проблемам, когда соответствующие SAN «падали», вплоть до повреждения файловой системы с потерей части данных пользователей.
Поэтому, для решения этой проблемы, а также проблем с производительностью, мы решили сделать «софтверную репликацию» фотографий с кешированием данных на SSD.
Также, в качестве эксперимента, мы решили попробовать ещё один способ — хранение на локальных дисках вместо использования SAN. По стоимости решение значительно дороже, но зато надежнее и проще в поддержке. Также, для обеспечения устойчивости к выходу из строя любой машины из такого кластера, мы решили сделать возможной балансировку всех поступающих запросов на весь кластер, то есть, в современных терминах, сделать «распределенное, отказоустойчивое, высокодоступное облачное хранилище».
VDS: обнаружение, выявление причин и устранение проблемных ситуаций. Диагнос...Oleg Lipin
Слайды к лекции об анализе VDS серверов, прозвучавшей на петербургском Линуксфесте в июле 2014 года.
Развернутая статья доступна по адресу http://debian-help.ru/vps-server-debian-analiz-problem-optimizaciya-nastroek
Повышаем отказоустойчивость без дорогих решенийLenvendo
Презентация технического директора "Ленвендо" Виталия Гаврилова на конференции Failover Conference, 10 апреля 2015 года.
Компания "Ленвендо" занимается развитием и поддержкой онлайн-проектов.
Сегодня «Ленвендо» отвечает за работу ресурсов «Эльдорадо», «Связной», HomeMe, Газпромбанк, Два берега, oodji.
DPDK в виртуальном коммутаторе Open vSwitch / Александр Джуринский (Selectel)Ontico
Intel DPDK (Data Plane Development Kit) — набор драйверов и библиотек, позволяющих приложениям взаимодействовать с сетевым устройством напрямую, минуя сетевой стек Linux. Это значительно увеличивает скорость обработки пакетов. DPDK интегрируется с рядом популярных программных решений, например, c виртуальным коммутатором Open vSwitch.
Возможностям и перспективам использования связи Open vSwitch + DPDK в облачных проектах и будет посвящен наш доклад. Мы подробно остановимся на проведённых тестах производительности и интерпретируем их результаты. Отдельное внимание будет уделено анализу трудностей и ограничений, с которыми пришлось столкнуться в ходе экспериментов.
О чем нам могут рассказать access логи вебсервера? Поиск аномалий и отклонений от нормы? Откуда наши пользователи? Город? Страна? Сайт? Сколько запросов генерируют роботы? Когда в последний раз к нам приходил поисковик для индексации? Какая динамика по ошибкам и страницам отсутствующим на сайте?
В этом докладе я в подробностях расскажу о том, как устроено хранение фотографий в нашей компании (всего около ~1 Пб).
Наша система была устроена достаточно просто — сами фотографии хранятся на SAN Storages, которые подключены через Fiber Channel к отдельной группе серверов, "*photos". На photos-серверах смонтированы разделы на соответствующих сетевых блочных устройствах, которые с точки зрения пользователя выглядят, как обычная файловая система.
Мы не используем никакие «хитрые» системы для хранения фотографий и не храним всё в одном файле — каждый размер каждой фотографии представляет из себя обычный файл на файловой системе ext3/4. Фотографии отдаются через nginx напрямую из файловой системы.
Такой способ хранения больших объемов данных весьма дешев, но приводил к проблемам, когда соответствующие SAN «падали», вплоть до повреждения файловой системы с потерей части данных пользователей.
Поэтому, для решения этой проблемы, а также проблем с производительностью, мы решили сделать «софтверную репликацию» фотографий с кешированием данных на SSD.
Также, в качестве эксперимента, мы решили попробовать ещё один способ — хранение на локальных дисках вместо использования SAN. По стоимости решение значительно дороже, но зато надежнее и проще в поддержке. Также, для обеспечения устойчивости к выходу из строя любой машины из такого кластера, мы решили сделать возможной балансировку всех поступающих запросов на весь кластер, то есть, в современных терминах, сделать «распределенное, отказоустойчивое, высокодоступное облачное хранилище».
VDS: обнаружение, выявление причин и устранение проблемных ситуаций. Диагнос...Oleg Lipin
Слайды к лекции об анализе VDS серверов, прозвучавшей на петербургском Линуксфесте в июле 2014 года.
Развернутая статья доступна по адресу http://debian-help.ru/vps-server-debian-analiz-problem-optimizaciya-nastroek
Повышаем отказоустойчивость без дорогих решенийLenvendo
Презентация технического директора "Ленвендо" Виталия Гаврилова на конференции Failover Conference, 10 апреля 2015 года.
Компания "Ленвендо" занимается развитием и поддержкой онлайн-проектов.
Сегодня «Ленвендо» отвечает за работу ресурсов «Эльдорадо», «Связной», HomeMe, Газпромбанк, Два берега, oodji.
DPDK в виртуальном коммутаторе Open vSwitch / Александр Джуринский (Selectel)Ontico
Intel DPDK (Data Plane Development Kit) — набор драйверов и библиотек, позволяющих приложениям взаимодействовать с сетевым устройством напрямую, минуя сетевой стек Linux. Это значительно увеличивает скорость обработки пакетов. DPDK интегрируется с рядом популярных программных решений, например, c виртуальным коммутатором Open vSwitch.
Возможностям и перспективам использования связи Open vSwitch + DPDK в облачных проектах и будет посвящен наш доклад. Мы подробно остановимся на проведённых тестах производительности и интерпретируем их результаты. Отдельное внимание будет уделено анализу трудностей и ограничений, с которыми пришлось столкнуться в ходе экспериментов.
О чем нам могут рассказать access логи вебсервера? Поиск аномалий и отклонений от нормы? Откуда наши пользователи? Город? Страна? Сайт? Сколько запросов генерируют роботы? Когда в последний раз к нам приходил поисковик для индексации? Какая динамика по ошибкам и страницам отсутствующим на сайте?
Как понять, что происходит на сервере? / Александр Крижановский (NatSys Lab.,...Ontico
Запускаем сервер (БД, Web-сервер или что-то свое собственное) и не получаем желаемый RPS. Запускаем top и видим, что 100% выедается CPU. Что дальше, на что расходуется процессорное время? Можно ли подкрутить какие-то ручки, чтобы улучшить производительность? А если параметр CPU не высокий, то куда смотреть дальше?
Мы рассмотрим несколько сценариев проблем производительности, рассмотрим доступные инструменты анализа производительности и разберемся в методологии оптимизации производительности Linux, ответим на вопрос за какие ручки и как крутить.
Основы индексирования и расширенные возможности EXPLAIN в MySQL / Василий Лук...Ontico
Индексы
- типы индексов;
- типы доступа к таблице;
- составные индексы (когда они работают);
- получение информации об индексе (show index; - описание формата);
- примеры с поиском по нескольким полям и сортировкой: какие индексы будут использоваться, а какие нет;
- что делать в случае нескольких условий по диапазону;
- как сервер выбирает индекс, который будет использован;
- директивы use/force/ignore index.
EXPLAIN
- как работает оптимизатор запросов;
- недостатки explain;
- explain extended;
- получение sql запроса, восстановленного из плана;
- формат выводимой explain информации:
-- что означает каждый столбец;
-- какие значения принимает (для extra только самые часто встречающиеся);
-- на что обратить внимание с точки зрения производительности;
-- как правильно читать план-разбор сложного примера с join-ами, подзапросами (обычными и from) и union-ами;
- новые возможности explain в последних версиях.
Практические примеры (исходный запрос, план, оптимизация, итоговый план) для разных случаев оптимизации:
1. добавление индексов;
2. эквивалентное изменение запроса: or --> union, подзапрос --> join;
3. разбиение запроса на несколько с сохранением промежуточных данных во временной таблице;
4. изменение структуры данных;
5. использование пользовательских переменных.
Принципы и приёмы обработки очередей / Константин Осипов (Mail.ru)Ontico
Насколько повысится среднее время обработки одного запроса если увеличить нагрузку вдвое? Почему производительность базы данных может снизиться при росте числа клиентов? Как добиться эффективного распределения большого числа задач на весь кластер? О практике и о теории обработки очередей на которой основана практика в моём докладе.
Современная операционная система: что надо знать разработчику / Александр Кри...Ontico
Мы проговорим про связь приложения и ОС, какие компоненты есть в современной ОС на примере Linux, как настройки этих компонент могут повлиять на приложение.
Я расскажу про планировщик процессов, дисковый и сетевой ввод-вывод и соответствующие планировщики, управление памятью - как это все в общих чертах работает и как его потюнить.
Обзорный доклад про базовое внутреннее устройство любого современного поискового движка. Про сжатые списки документов и позиций, как затем с ними работает поиск совпадающих документов (и разные операторы), как устроено ранжирование найденных документов, как бывают устроены и работают с фильтрацией и агрегацией дополнительные (нетекстовые) атрибуты документов. По возможности, упоминание всех известных вариантов реализаций (как, вообще, можно, как сделано в Sphinx, как в Lucene).
Горизонтальное масштабирование: что, зачем, когда и как /Александр Макаров (Y...Ontico
Масштабирование — способность наращивать систему для обработки большего количества трафика, не теряя при этом пользовательские качества: скорость и отзывчивость.
Масштабирование различают двух типов: вертикальное (больше памяти, диска, лучше процессор) и горизонтальное (больше серверов в кластере).
- Зачем оно нужно, если и так всё работает?
- Когда? Мониторинг, необдуманные решения, оптимизация и жизнь с одним сервером.
- Типичная схема.
- Балансировка нагрузки.
- Какие, вообще, проблемы на стороне приложения?
- Почему PHP так хорош для масштабирования.
- Сессии.
- База данных.
- Файлы.
- Как быть со статистикой?
Как балансировать на «сетевом» канате под куполом тяжелой нагрузки? / Сергей ...Ontico
Цель доклада – рассмотреть и систематизировать информацию о том, как балансировка нагрузки помогает делать миллионы людей счастливыми, сохраняя им нервные клетки, спасает беззащитные ПК и прочие девайсы от приступов ярости их владельцев во время бесконечных загрузок сайтов, а посетителям онлайн магазинов не дает побросать их виртуальные корзинки в бесконечных очередях на кассе.
Вашему вниманию будет представлен небольшой сравнительный анализ методов балансировки трафика, мы рассмотрим плюсы и минусы каждой схемы. Я расскажу, к каким хитростям можно прибегать, минуя большие затраты на покупку готовых решений и получая максимум профита от существующей инфраструктуры.
Доклад будет полезен всем, кто хочет знать, но боится спросить, благодаря чему HighLoad-проекты такие устойчивые и надежные. Тема наверняка заинтересует тех, кто только начинает свои шаги на пути к уверенному и высокопроизводительному сервису.
Тезисы доклада:
1. Что такое балансировка и зачем она вообще нужна? Когда хорошо бы об этом задуматься?
2. Реализация балансировки: виды, способы, практики.
3. Методы локальной балансировки
3.1. Балансировка на канальном уровне (L2-метод)
• Используем отдельным балансировщик
• Сократим расходы, избавимся от выделенного балансировщика
• Плюсы и минусы
3.2. Балансировка на сетевом уровне (L3-метод)
• Преимущества и недостатки
4. Методы глобальной балансировки
4.1. DNS балансировка.
• DNS Round Robin
• Сильные и слабые стороны подхода
4.2. HTTP Redirect
• Механизм балансировки на основе Redirect запросов
• Плюсы и минусы метода
4.3. Балансировка на базе Anycast
• Когда Anycast – это хорошо, а когда - не очень?
5. Некоторые не менее расп
Эволюция процесса деплоя в проекте / Денис Яковлев (2ГИС)Ontico
Если наш проект — это не коробочный продукт, а, например, веб-сервис, на который постоянно ходят пользователи, их много и они сразу видят изменения, то в жизненном цикле разработки у нас возникает еще одна задача — задача деплоя готового кода в боевое окружение.
В самом начале, когда наш проект маленький и простой, на эту задачу никто может и не обращать внимания, так как все происходит быстро и просто. Процесс деплоя состоит из 2-3 общеизвестных шагов — git pull, yii migrate, etc..., которые легко запомнить и в них сложно ошибиться.
С развитием проекта его сложность возрастает — он уже крутится на нескольких серверах, появляются новые компоненты (утилиты, библиотеки и т.д.), новые сущности (балансеры, кэшы, и т.д.). Держать всю инфраструктуру в голове становится невозможным, ведение документации привносит больше проблем, нежели решений, люди ошибаются чаще и т.д.
В докладе:
— рассмотрим подробно вышеуказанные проблемы, с которыми неизбежно сталкиваются проекты;
— обсудим, какие решения существуют в индустрии (chef, ansible, etc), чем они отличаются, какой выбрать и в чем их задача;
— поговорим про административные вопросы, которые с этим связаны.
Как устроена 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-операторы подробно рассматривать НЕ будем, эти скучные мелочи необходимо будет затем самостоятельно смотреть в документации (или не смотреть).
Производительность запросов в PostgreSQL - шаг за шагом / Илья Космодемьянски...Ontico
Вы взяли ваш любимый фреймворк™ и быстро запустили крутой проект, который раскручивается, приносит деньги и требует быстрого развития, чтобы оставить конкурентов далеко позади.
В один далеко не прекрасный момент вы понимаете, что корень всех зол - медленное время ответа базы данных, а ваш админ зло смотрит на разработчиков красными от бессонницы глазами и ругается на безумные запросы, которые генерирует ORM. Тот самый ORM, который позволил вам так быстро запустить ваш замечательный проект.
Знакомо? Тогда вам будет интересно послушать, как заставить вашу базу данных работать прямо сейчас. А именно:
- какое место в общей производительности базы данных занимает оптимизация запросов?
- когда прекращать “крутить гайки” и заниматься медленными запросами?
- что такое медленный запрос и когда их надо начинать оптимизировать?
- как оптимизировать?
- EXPLAIN, EXPLAIN ANALYZE - как читать и на что обращать внимание?
- как работает оптимизатор запросов PostgreSQL и где могут быть узкие места?
- для чего нужны и для чего не нужны индексы, методики индексирования, и как быть уверенным, что ваш индекс правильно используется?
- какие запросы не будут работать быстро никогда, и как с этим жить?
- ошибается ли оптимизатор и, если да, то почему и как его в таком случае призвать к порядку?
Какие бывают провайдеры услуг дата-центров и как выбрать оптимальный? / Игорь...Ontico
Все знают поговорку "два переезда равны одному пожару" и все понимают, что значит "перенос highload проекта с одного провайдера хостинга на другого с обеспечением непрерывности функционирования сервисов для пользователей".
Выбор "правильного" провайдера услуг дата-центров очень важен, но есть две проблемы:
1) "Все лгут" - маркетинг провайдера и реальность далеко не всегда совпадают, все провайдеры рассказывают о своих сильных сторонах и умалчивают о слабых;
2) "когда у вас в руках молоток - все вокруг превращается в гвозди" - все провайдеры услуг имеют свою специализацию и любую задачу клиента они стремятся решить так, как умеют, а не так как надо клиенту.
В своем докладе я постараюсь рассмотреть все аспекты вопроса выбора провайдера/провайдеров услуг хостинга/дата-центров.
Данный доклад ориентирован на широкую аудиторию и будет полезен всем, кому надо выбирать провайдера услуг хостинга/дата-центров для внутренних и/или внешних проектов.
В рамках доклада будут рассмотрены следующие вопросы:
1) формализация ТЗ на оказание услуг провайдерами или "а что нам надо";
2) классификация провайдеров дата-центров по спектру оказываемых услуг;
3) SLA - что это? какие SLA бывают? что подразумевают провайдеры и чего ожидаете вы в документе под названием Service Level Agreement;
4) магическое слово compliance, или что хочет государство;
5) чем отличаются одни провайдеры от других;
6) как проверить провайдера - uptime/связанность/рейтинги/спектр услуг;
7) пишем RFP - как сформулировать потребности так, чтобы потом результат не разочаровал.
NoSQL - коротко о главном / Сергей Туленцев (TextMaster)Ontico
В последнее время сайты и веб-приложения растут всё быстрее, а задачи, стоящие перед БД, эволюционируют. Поэтому для (успешных) проектов традиционная реляционная СУБД часто не может удовлетворить все нужды. В ответ на эту проблему возникло большое количество разнообразных решений, очень различающихся по функциональности и характеристикам. При этом они все заносятся под один большой зонтик "NoSQL", что не способствует пониманию вещей. Запутанные веб-разработчики пытаются взять текущую модную и обсуждаемую NoSQL БД и приспособить её под свои нужды, не всегда понимая, нужную ли технологию они выбрали (референс к MongoDB is Web Scale http://www.youtube.com/watch?v=b2F-DItXtZs).
Целью доклада является упорядочение хаоса в головах разработчиков.
- Обзор популярных БД и их классификация (KV store, document store, columnar, etc).
- CAP-теорема и её применение к выбору БД (где-то параметры можно настроить, где-то подпереть сбоку костылем, где-то - увы).
- Типичные примеры применения.
- Антипаттерны применения (из личного опыта и тысяч прочитанных вопросов на stackoverflow :) ).
Осваиваем Tarantool 1.6 / Евгений Шадрин (Sberbank Digital Ventures)Ontico
Tarantool - отечественная Opensource NoSQL база данных.
В докладе мы обсудим:
- Какое место занимают NoSQL базы данных в highload проектах?
Почему и для чего вам стоит NoSQL решения?
Какие NoSQL решения вы можете использовать?
- Рассмотрим, что из себя представляет Tarantool 1.6 - база данных и сервер приложений в одном лице.
Какие основные особенности Tarantool как NoSQL базы данных?
Lua как встроенный язык сервера приложений.
- Посмотрим, как можно начать использовать Tarantool в своих проектах, и сделаем первые шаги.
Как установить Tarantool.
Первый запуск и основы конфигурирования.
Модель данных.
Как создавать и работать с хранилищем данных.
Как использовать пакеты tarantool.
- Узнаем об интересных модулях и фичах Tarantool
Чем полезен application server
Tarantool http
Tarantool queue
- Познакомимся с сообществом Tarantool opensource
Почему сообщество - это важно?
Чем полезны opensource проекты начинающему разработчику?
Поддержка высоконагруженного проекта: мониторинг, резервирование, обслуживани...Ontico
1. Мониторинг высоконагруженного проекта.
1.1. Специфика мониторинга высоконагруженного проекта: гранулярность мониторинга, надежность системы мониторинга, система оповещений.
1.2. Мониторинг и контроль распределенных систем.
1.3. Специфика организации оповещений в высоконагруженном проекте. Превентивный мониторинг.
2. Резервирование и резервное копирование в высоконагруженном проекте.
2.1. Резервирование и резервное копирование - разные вещи.
2.2. Резервирование: на уровне сервера, дата-центра, географически распределенных площадок.
2.1. Организация резервного копирования. Сохранность часто обновляемых данных.
3. Обслуживание высоконагруженного проекта.
3.1. Организация поддержки высоконагруженного проекта: опыт, специфика работы.
3.2. Организация дежурств, эскалация оповещений.
3.3. Аварии в высоконагруженных проектах: примеры из жизни.
Кэширование данных в web приложениях. Использование memcached / Юрий Красноще...Ontico
Каждый разработчик web приложений рано или поздно сталкивается с довольно типичной проблемой: перед ним стоит задача построить фабрику по производству омнониевых торсиометров.
Фабрика производит омнониевые торсиометры очень быстро, но для калибровки прибора (как известно) необходим омноний, за которым приходится летать на Андромеду.
Пока корабль летит до Андромеды, фабрика простаивает.
Самый очевидный выход из ситуации - построить склад омнониума прямо рядом с фабрикой.
Терминология кэширования
Выбор места для кэширования в WEB
Выбор данных для кэширования
Кэширование на стороне бэкенда
Отдельный кэширующий сервис
Пара слов о memcached
Пара слов о Redis
1. Вводная часть: базовые понятия и определения
1.1. Что такое “файл”
1.2. Роль файлов в современном мире, миф о ненужности файлов
1.3. Файловое хранилище АКА файловая система
1.3.1. внутреннее устройство
1.3.1.1. винтажные и журналируемые. зачем нужен журнал
1.3.1.2. плоские и иерархические
1.3.1.3. контроль доступа
1.3.2. POSIX
1.3.2.1. произвольное чтение
1.3.2.2. произвольная запись
1.3.2.3. атомарные операции
1.3.3. bells and whistles
1.3.3.1. сжатие, шифрование, дедупликация
1.3.3.2. snapshots
1.4. кеширование чтения и записи
2. HighLoad - это сеть
2.1. что вообще такое “HighLoad”, или “ведет ли кроилово к попадалову”
2.2. протоколы доступа: stateless и stateful
2.3. отказоустойчивость и ее двуличие
2.3.1. целостность данных
2.3.2. бесперебойные запись и чтение
2.4. Теорема CAP
3. Так в чем проблема?
3.1. Берем большую-пребольшую СХД и…
3.1.1. локальный кеш?!
3.1.2. конкурентная запись?!!
3.1.3. Берем OCFS2 и…
3.1.3.1. Как “падают виртуалки”?!
3.1.3.2. И почему так медленно?
3.1.4. А еще большую-пребольшую СХД довольно трудно получить в свое распоряжение
3.2. Берем CEPH/Lustre/LeoFS и…
3.2.1. Почему так медленно?!
3.2.2. Что значит “ребалансинг”?!
3.3. И немного о резервном копировании
3.3.1. Резервное копирование - это не отказоустойчивость
3.4. И снова про атомарные операции
3.5. Так почему все-таки нельзя просто сложить файлы в базу?
4. Что же делать?
4.1. В первую очередь это зависит от того, какова наша задача
4.1.1. А надо ли экономить?
4.1.2. POSIX - нужен ли он?
4.1.3. Большие файлы - нужны ли они?
4.1.4. Атомарные операции - нужны ли они?
4.1.5. Версионирование - нужно ли версионирование?
4.1.6. Насколько большим должно быть наше хранилище?
4.1.7. И собираемся ли мы удалять файлы?
4.1.8. И каков будет профиль нагрузки?
4.2. I’m feeling lucky - для некоторых сочет�
Устройство фреймворка symfony 2 (http://frontend-dev.ru)Александр Егурцов
Презентация к вебинару об устройстве фреймворка symfony 2.
Видеозапись вебинара находится в моём блоге по адресу http://frontend-dev.ru/2012/12/12/symfony2-основы
Кадры решают все, или стриминг видео в «Одноклассниках». Александр Тобольodnoklassniki.ru
Я расскажу, как нам удалось более чем в 10 раз ускорить старт просмотра кино и сериалов с использованием технологий адаптивного стриминга MPEG-DASH и HLS. Вы узнаете, какие технологии попали в поле зрения команды, как ин-фраструктурные особенности, размер аудитории и специфика потребления на разных пользовательских устройствах повлияли на принятие решения о выборе технологии. Естественно, будет дан и подробный отчет о результатах внедрения решения и полученном эффекте.
То есть около 50 млн. роликов, которые есть на «Одноклассниках», нужно раздать пользователям по стриминг-протоколу на скорости 40 Гбит/с с одного сервера и не хранить копии видео в разных форматах
Движение по хрупкому дну / Сергей Караткевич (servers.ru)Ontico
Сегодня Интернет увлечен микросервисами, контейнерами и immutable-инфраструктурой. Очень сложно не поддаться искушению внедрить что-то подобное в компании, в которой вы работаете сейчас. Я попытаюсь отговорить вас использовать эти технологии во вред приложению, себе и бизнесу компании в целом. Я расскажу о типовом проекте, который был запущен в 20 странах за 4 месяца, проблемах, которые я встретил, и выводах, которые я сделал.
- Почему микросервисы не спасут, а похоронят ваш проект.
Я расскажу на основе собственного опыта, почему не стоит увлекаться микросервисами для небольших проектов, почему благие намерения — упрощение деплоя и увеличение числа деплоев, увеличение доступности и улучшение масштабирования ведут к отсутствию гибкости и критическому уменьшению стабильности системы.
- Почему ваша система слишком сложна для своих задач.
Я расскажу, почему не стоит усложнять систему, почему, скорее всего, ваша система слишком сложна для задач, которые она решает и почему вы не контролируете то, что происходит в системе. Я объясню, почему вы потратите все свое время на отладку сложной системы, вместо того чтобы решать задачи бизнеса.
- Почему Docker используется неправильно.
Будут предоставлены реальные примеры использования Docker для нового проекта и для портированного проекта, я объясню, с какими проблемами сталкиваются операторы при работе с Docker на живых примерах, объясню, почему вы, скорее всего, используете Docker неправильно, и предложу варианты, как этого избежать.
- Почему immutable слишком статичен для вашей компании.
Я расскажу про свой опыт работы с immutable и объясню, почему, на мой взгляд, переход к подобной инфраструкт
Опенсорс-инструменты на страже безопасности бэкенда — Петр ВолковYandex
Антивирусная система Яндекса ежедневно обнаруживает тысячи взломанных сайтов. Периодически среди них встречаются крупные и известные интернет-ресурсы.
Администраторы сайтов часто оказываются не готовы к тому, что злоумышленник может пробраться через внешний периметр и исполнить произвольный код на стороне сервера. В результате перед ними встаёт нелегкая задача: обнаружить последствия и предотвратить дальнейшие проблемы.
Доклад посвящён практикам и инструментам, которые могут существенно повысить эффективность противодействия вредоносной активности, и профилактике её возникновения.
Как и зачем создавать NginX-модуль — теория, практика, профит. Часть 2 / Васи...Ontico
HighLoad++ 2017
Зал Дели + Калькутта, 7 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2940.html
Почти год назад я выступил с докладом 'Как и зачем создавать NginX-модуль - теория, практика, профит'. У меня не получилось рассказать обо всех возможностях Nginx и, уверяю вас, в этом докладе у меня это тоже не получится - тема слишком большая!
Сразу перейдем к делу. "Так что нового будет в этом докладе?" - спросите вы. В нем будут ответы на вопросы, на которые я не успел ответить в прошлом году, а именно:
- Как и зачем создавать upstream-модули?
...
2. Архитектура
• Морда видеохостинга
• Файловые сервера (связываются с
кодирующим(-и) сервером(-ами) по NFS)
• Сервер для загрузки видео (используем
http://pecl.php.net/package/uploadprogress)
• Сервер(-а) для кодирования видео
3. Путь и инструментарий
• ffmpeg
• nginx
• shell-скриптинг, perl
• плеер (uppod например) и клиентская
часть
• ??????
• PROFIT!
8. 5. Пару советов по настройке и выбору железа:
– Чем больше ядер у файлового раздающего сервера – тем лучше
(воркеры выставляем в конфиге по количеству ядер -
worker_processes 4)
– Файловой системой лучше всего выбрать xfs (быстрая, без
журналирования) и монтировать с –noatime
– Обязательно использовать AIO, тем более, что nginx его
поддерживает
– Контент лучше всего дублировать на разные винты и отдавать его
поочередно, таким образом балансируя нагрузку
– Контент хранить в древовидной структуре (/ab/cd/ef/abcdef.mp4), а не
держать в одной папке – можно будет обслужить большее
количество клиентов
– Ограничивать скорость отдачи видео и количество одновременных
подключений – больше клиентов сможет потребить контент.
– «Горячий контент» стоит отдавать с отдельных быстрых винтов,
подойдет даже SSD
9. SHELL-скриптинг, PERL
• Кодирования видео с использованием очередей
• Скачивание видео по ссылке (YouTube,
RuTube, Vimeo etc)
• Обнаружение горячего контента
• CDN для более «умной» раздачи контента
…об этом и другом в следующие разы
10. Плеер и клиентская часть
• Выбрать подходящий плеер (рекомендую
Uppod + Pro аккаунт) и настроить,
использовать HTML5 + flash fallback
• Правильно закодировать ссылку к видео,
чтобы защититься от хотлинкинга:
public function secureLink($url) {
$time = time() + 14400;
$string = 'pass' .$url.$time.$_SERVER['REMOTE_ADDR'];
$hash = md5($string, true);
return $url.'/'.$hash.'/'.$time;
}