Компания "Ленвендо" занимается созданием, развитием и поддержкой крупномасштабных онлайн-проектов.
Сегодня «Ленвендо» отвечает за работу ресурсов «Эльдорадо», «Связной», HomeMe, Газпромбанк, Эхо Москвы в Петербурге.
Tempesta FW: challenges, internals, use cases / Александр Крижановский (Tempe...Ontico
Tempesta FW — это Open Source гибрид Web-акселератора и файервола, специально разработанный для высокопроизводительной доставки контента вне зависимости от DDoS или наплыва посетителей.
В докладе будет рассказано про задачи, которые ставились при разработке проекта и пути их решения. Рассмотрим проблемы современных операционных систем в приложении к Web-стеку (система фильтрации, Web-сервер, application слой, БД), и как они решаются в Tempesta — некоторые уже решены, некоторые еще в процессе работы.
И самое главное — у нас появился рабочий прототип, и я расскажу про типовые примеры инсталляции, фичи и конфигурацию, а также покажу бенчмарки.
Chronicle Map — key-value хранилище для трейдинга на Java / Левентов Роман (C...Ontico
Сфера финансовых приложений и трейдинга выдвигает особые требования к системам обработки данных: ультракороткие задержки, конкурентные обновления (в т.ч. из разных процессов), репликация высокочастотных обновлений.
Существовавшие открытые key-value хранилища не справлялись, поэтому мы сделали свое — Chronicle Map.
В докладе я отвечу на вопросы:
+ Почему бывает эффективнее разбить систему, работающую с общим состоянием, на несколько отдельных процессов?
+ Зачем вам может захотеться распилить JVM на несколько частей?
+ Как добиться от key-value хранилища медианной latency меньше 1 микросекунды?
+ Как сделать репликацию, если она упирается в пропускную способность сети из-за слишком частых обновлений?
Развею миф о том, что Java — это медленно :)
Также, в докладе будет сравнение Chronicle Map с redis, one-nio и ConcurrentHashMap.
Tempesta FW: challenges, internals, use cases / Александр Крижановский (Tempe...Ontico
Tempesta FW — это Open Source гибрид Web-акселератора и файервола, специально разработанный для высокопроизводительной доставки контента вне зависимости от DDoS или наплыва посетителей.
В докладе будет рассказано про задачи, которые ставились при разработке проекта и пути их решения. Рассмотрим проблемы современных операционных систем в приложении к Web-стеку (система фильтрации, Web-сервер, application слой, БД), и как они решаются в Tempesta — некоторые уже решены, некоторые еще в процессе работы.
И самое главное — у нас появился рабочий прототип, и я расскажу про типовые примеры инсталляции, фичи и конфигурацию, а также покажу бенчмарки.
Chronicle Map — key-value хранилище для трейдинга на Java / Левентов Роман (C...Ontico
Сфера финансовых приложений и трейдинга выдвигает особые требования к системам обработки данных: ультракороткие задержки, конкурентные обновления (в т.ч. из разных процессов), репликация высокочастотных обновлений.
Существовавшие открытые key-value хранилища не справлялись, поэтому мы сделали свое — Chronicle Map.
В докладе я отвечу на вопросы:
+ Почему бывает эффективнее разбить систему, работающую с общим состоянием, на несколько отдельных процессов?
+ Зачем вам может захотеться распилить JVM на несколько частей?
+ Как добиться от key-value хранилища медианной latency меньше 1 микросекунды?
+ Как сделать репликацию, если она упирается в пропускную способность сети из-за слишком частых обновлений?
Развею миф о том, что Java — это медленно :)
Также, в докладе будет сравнение Chronicle Map с redis, one-nio и ConcurrentHashMap.
Что особенного в СУБД для данных в оперативной памяти / Константин Осипов (Ta...Ontico
Оперативная память становится всё более дешёвой и производительной, что позволяет использовать её для хранения рабочего набора данных всё большего числа приложений. Хранение всех данных в оперативной памяти позволяет сделать их высоко доступными, а алгоритмы для работы с данными либо существенно упростить, либо ускорить, а иногда — и то, и другое.
Тезисы - http://www.highload.ru/2015/abstracts/1964.html
Защита данных и датацентров от катастроф. Подход Nutanix / Максим Шапошников ...Ontico
+ Защита данных — это не "одна кнопка", нет годного любому единого решения. Задача всегда диктует выбор средств и решений.
+ RTO — Recovery Time Objective — максимальное время, за которое все ваши бизнес-задачи должны полностью быть восстановлены в работоспособное состояние после полной катастрофы ДЦ.
+ RPO — Recovery Point Objective — максимально приемлемый для ваших задач промежуток времени, за который вы готовы потерять данные.
+ Защита на уровне приложений. Приложение лучше всех знает, как защищать и реплицировать свои данные.
+ Асинхронная репликация — наилучший выход с точки зрения производительности, единственно возможный вариант в случае значительного географического разнесения дата-центров (сотни и более километров). Работает на уровне виртуальных машин.
+ Метро / "растянутые" кластеры и синхронная репликация — нулевой RPO, минимальный RTO, большие потери производительности и множество ограничений. Но иногда — единственный выход, если уровень приложения не умеет реплицировать данные.
+ Лучший подход — комбинация из репликации на уровне приложений, асинхронной и синхронной репликации средствами хранилища.
+ Что есть у Nutanix для решения подобных задач: DR (Async replication), Metro availability cluster, Timestream Backup.
+ Реализация решения с использованием Nutanix на примере FBI: крупнейший VDI в США. Защищенная, mission-critical инфраструктура на 70 тысяч виртуальных десктопов. Асинхронная репликация дата-центров на 1500 миль, защита данных от катастроф.
сравнение производительности СУБД MySQL и PostgreSQL для "типичной задачи стартапа".
Презентация сопровождала тестовую online-сессию и потому не содержит результатов тестирования.
Конференция Highload++ 2014, "Отказоустойчивый микрокластер своими руками", "...Lenvendo
inShare
0 views
Компания "Ленвендо" занимается созданием, развитием и поддержкой крупномасштабных онлайн-проектов.
Сегодня «Ленвендо» отвечает за работу ресурсов «Эльдорадо», «Связной», HomeMe, Газпромбанк, Эхо Москвы в Петербурге
Что особенного в СУБД для данных в оперативной памяти / Константин Осипов (Ta...Ontico
Оперативная память становится всё более дешёвой и производительной, что позволяет использовать её для хранения рабочего набора данных всё большего числа приложений. Хранение всех данных в оперативной памяти позволяет сделать их высоко доступными, а алгоритмы для работы с данными либо существенно упростить, либо ускорить, а иногда — и то, и другое.
Тезисы - http://www.highload.ru/2015/abstracts/1964.html
Защита данных и датацентров от катастроф. Подход Nutanix / Максим Шапошников ...Ontico
+ Защита данных — это не "одна кнопка", нет годного любому единого решения. Задача всегда диктует выбор средств и решений.
+ RTO — Recovery Time Objective — максимальное время, за которое все ваши бизнес-задачи должны полностью быть восстановлены в работоспособное состояние после полной катастрофы ДЦ.
+ RPO — Recovery Point Objective — максимально приемлемый для ваших задач промежуток времени, за который вы готовы потерять данные.
+ Защита на уровне приложений. Приложение лучше всех знает, как защищать и реплицировать свои данные.
+ Асинхронная репликация — наилучший выход с точки зрения производительности, единственно возможный вариант в случае значительного географического разнесения дата-центров (сотни и более километров). Работает на уровне виртуальных машин.
+ Метро / "растянутые" кластеры и синхронная репликация — нулевой RPO, минимальный RTO, большие потери производительности и множество ограничений. Но иногда — единственный выход, если уровень приложения не умеет реплицировать данные.
+ Лучший подход — комбинация из репликации на уровне приложений, асинхронной и синхронной репликации средствами хранилища.
+ Что есть у Nutanix для решения подобных задач: DR (Async replication), Metro availability cluster, Timestream Backup.
+ Реализация решения с использованием Nutanix на примере FBI: крупнейший VDI в США. Защищенная, mission-critical инфраструктура на 70 тысяч виртуальных десктопов. Асинхронная репликация дата-центров на 1500 миль, защита данных от катастроф.
сравнение производительности СУБД MySQL и PostgreSQL для "типичной задачи стартапа".
Презентация сопровождала тестовую online-сессию и потому не содержит результатов тестирования.
Конференция Highload++ 2014, "Отказоустойчивый микрокластер своими руками", "...Lenvendo
inShare
0 views
Компания "Ленвендо" занимается созданием, развитием и поддержкой крупномасштабных онлайн-проектов.
Сегодня «Ленвендо» отвечает за работу ресурсов «Эльдорадо», «Связной», HomeMe, Газпромбанк, Эхо Москвы в Петербурге
Повышаем отказоустойчивость без дорогих решенийLenvendo
Презентация технического директора "Ленвендо" Виталия Гаврилова на конференции Failover Conference, 10 апреля 2015 года.
Компания "Ленвендо" занимается развитием и поддержкой онлайн-проектов.
Сегодня «Ленвендо» отвечает за работу ресурсов «Эльдорадо», «Связной», HomeMe, Газпромбанк, Два берега, oodji.
Решение Digift - электронные подарочные карты "под ключ"Lenvendo
Процессинговая платформа Digift - готовое решение, которое позволит максимально быстро запустить на вашем сайте продажу и прием электронных подарочных карт.
DaruYou - это пополняемый деньгами мультибрендовый подарочный сертификат с возможностью брендирования.
Особенности сертификата:
- Сертификат принимают более 200 партнеров - магазины, рестораны, салоны красоты по всей Украине;
- Средства можно тратить частями в разных магазинах, пока баланс положительный;
- Упаковка для сертификата и сама карточка может быть оформлена в соответствии с фирменным стилем Вашей компании;
- Сертификат DaruYou, как и банковскую карту, можно пополнять с любой регулярность и на любую сумму.
Дмитрий Лазаренко-«Живая миграция и отказоустойчивость контейнеров в гибридно...Tanya Denisyuk
"Контейнеры могут динамически появляться и исчезать, являются легковесными, не резервируют все необходимые ресурсы при старте, потому их оркестрация дается не простой ценой. Каждый из виртуальных контейнеров в один момент времени может потребовать максимум доступных ему ресурсов и это может привести к тому, что закончатся все ресурсы на физическом сервере, на котором они размещаются. В докладе мы поговорим о механизме, который решает эту непростую задачу, и умеет проводить непрерывную балансировку нагрузки, перемещать контейнеры с одного физического сервера на другие для проведения технических работ без простоя приложений - умная живая миграция (Smart Live Migration).
Многие считают, что контейнеры не подходят для хранения важных данных, т.к. в любой момент они могут упасть и все данные пропадут навсегда. Мы расскажем как этого избежать с помощью технологии Software-defined-storage."
Корпоративный Linux: осваиваем с нуля Red Hat Enterprise LinuxSkillFactory
Никита Войтов – ведущий инструктор SkillFactory по направлению Linux – об особенностях и преимуществах корпоративного стандарта ОС Linux – Red Hat Enterprise.
Инфраструктура Big data - от источников до быстрых витрин - версия для МИСиСYury Petrov
В докладе я постараюсь донести до аудитории общую концепцию построения инфраструктуры Big Data, которую многие не видят.
Будут и инсайты и самый главный из них это то, что за долгое время работы с Big Data я таки вывел определение для этого термина
Кэширование данных в web приложениях. Использование memcached / Юрий Красноще...Ontico
Каждый разработчик web приложений рано или поздно сталкивается с довольно типичной проблемой: перед ним стоит задача построить фабрику по производству омнониевых торсиометров.
Фабрика производит омнониевые торсиометры очень быстро, но для калибровки прибора (как известно) необходим омноний, за которым приходится летать на Андромеду.
Пока корабль летит до Андромеды, фабрика простаивает.
Самый очевидный выход из ситуации - построить склад омнониума прямо рядом с фабрикой.
Терминология кэширования
Выбор места для кэширования в WEB
Выбор данных для кэширования
Кэширование на стороне бэкенда
Отдельный кэширующий сервис
Пара слов о memcached
Пара слов о Redis
2. Содержание
Инструменты кеширования данных
• Memcached
• Redis
• Основные различия Memcached & Redis
• Практическое использование Memcached & Redis
Очереди
• RabbitMQ, основные понятия и принцип работы
• Различные типы обменников – Direct, Fanout, Topic
• Практическое применение очередей
3. Кеширование
Кеш - посредник между клиентом, который запрашивает данные, и основным
хранилищем, способный очень быстро отдавать данные
• скорость получения данных из кеша на порядок выше, чем из основной
большой и медленной БД
• как правило, кеш хранится в оперативной памяти сервера, за счет чего доступ
к таким данным происходит моментально
• эффективное использование кеша снижает нагрузку на сервер
Когда, что и какими инструментами кешировать?
• полезно кешировать часто запрашиваемые данные
• необходимо понимать, какие данные можно кешировать, а какие нет
• инструменты: Memcached, Redis и др.
4. Memcached
• Memcached - сервис для кеширования данных в оперативной
памяти, обладающий высокой производительностью
• История – разработан Brad Fitzpatrick для Livejournal в 2003
г.
• Цели - кеширование часто запрашиваемых данных, для
снижения нагрузки на БД
• Используют – Livejournal, Twitter, Youtube и др.
5. Memcached. Возможности
Возможности:
1. Быстрая работа, нет зависимости от количества данных О(1)
2. Простой интерфейс – set/get/del
3. Атомарные операции – incr/decr, append/prepend
4. Хранение ключей на нескольких серверах
Ограничения:
1. Длина ключа – 250 байт
2. Объём данных по одному ключу – 1Mb
3. Потеря ключей – при лимите памяти, по ttl, отказ сервера
6. Memcached. Пример
Реализации для PHP:
• расширение для libmemcached
• расширение php-memcache
Использование: простой интерфейс set / get / delete
7. Redis
1. Поддержка различных типов данных – строки, хэши, списки,
множества, сортированные множества
2. Сохранение на диск
3. Поддержка LRU, различные стратегии очистки ключей
4. master-slave репликация
5. Реализация очередей Sub/Pub
6. Транзакции MULTI/EXEC
7. Поддержка LUA скриптов
8. Отличная документация
9. Redis. Типы данных
3. Множества (Sets)
4. Сортированные множества (Sorted Sets)
10. Redis. Клиенты для PHP
• phpredis – модуль для PHP, написан на С
• Predis – библиотека, написанная на PHP
• Rediska – PHP реализация
• RedisServer – класс для работы с Redis, написанный на PHP
• Resident – форк RedisServer, используется phpredis, если он установлен
Рекомендации:
использование расширения phpredis, написанного на C, по тестам - самый
быстрый для работы с Redis
11. Memcached или Redis?
Redis:
• больше возможностей: очереди,
транзакции, различные типы
данных
• позволяет хранить до 512 Mb в
значениях
• поддерживает master-slave
репликацию, кластеризация с
версии 3.0 (RC)
• можно использовать как
постоянное хранилище данных
• производительность сравнима
с Memcached
Memcached :
• быстрее, чем Redis, но на
практике эта разница
практически не заметна
• хорош в качестве кеша, но есть
множество задач с которыми
Redis справится не хуже, а для
некоторых задач и лучше, чем
Memcached в силу своих
возможностей
12. Пример 1. Кеш карточки товара
Задача: реализация быстрого просмотра в Popup карточки товара, с минимальным
обращением в бэкенд
13. Пример 1. Кеш карточки товара
На схеме:
1 - данные из Memcached
2 - данных в Memcached нет
2a - но есть в Redis
2b - запрос в MySQL +
сохранение в
Redis/Memcached
14. Пример 2. Параметрический поиск
Реализация:
• хранение заранее
обсчитанных множеств
товаров (ID) для каждого
варианта фильтра в Redis
Используемы типы данных:
• Hashes (информация о
фильтрах)
• Sets (множества товаров)
• Sorted Sets (список фильтров
и их вариантов)
15. Пример 2. Параметрический поиск
Данные по фильтрам в категории “Телефоны” (id = 100):
Фильтр / Вариант ID товаров Ключ в Redis
1. Производитель / SAMSUNG { 201, 202, 203, 204 } plist:c:100:f:producer:v:samsung
2. Производитель / PHILIPS { 301, 302, 303 } plist:c:100:f:producer:v:philips
3. Цвет / Красный { 202, 303, 701 } plist:c:100:f:color:v:red
Конкретные выборки:
Телефоны Samsung + Philips (7 эл.): { 201, 202, 203, 204, 301, 302, 303 }
Телефоны Samsung + Philips / красные (2 эл.): { 202, 303 }
Особенности реализации:
• существенно быстрее, чем сложные выборки из MySQL
НО: необходимо обновлять необходимые множества при каждом
изменении сущностей, которые могут повлиять на состав фильтров
16. Очереди. RabbitMQ
Платформа, реализующая систему обмена сообщениями посредством протокола
AQMP (Advanced Messaging Queue Protocol)
Особенности:
• надежность
• гибкая система маршрутов сообщений
• поддержка кластеризации
• поддержка плагинов (мониторинг системы, кастомное поведение, и др.)
• написан на Erlang
• клиенты для большинства языков: Java, Ruby, Python, .NET, PHP, Perl,
C/C++ и др.
17. RabbitMQ. Основные термины
Producer – программа, которая посылает сообщения
Exchange – обменник, все сообщения проходят через обменник
Queue – очередь, хранится в «кролике», может содержать сколь
угодно много сообщений (бесконечный буфер). Сообщения лежат
именно в очередях. Посылать сообщения может один и более
producer-ов, читать их тоже
Consumer – программа получатель сообщений
Простейший workflow:
18. Обменник с типом Direct
• для задания маршрута
необходимо «забиндить»
очередь с обменником,
используя binding_key
• сообщения попадают в
очередь согласно правилу
равенства ключей:
routing_key = binding_key
19. Обменник с типом Fanout
• сообщения попадают во
все очереди, связанные с
обменником
• не важно какой
routing_key у сообщения
20. Обменник с типом Topic
Правила для binding_key:
1. * (звездочка) может быть заменена на
ровно на одно слово
2. # (решетка) может быть заменена на 0
и более слов
Routing Key Queue
quick.orange.rabbit (*.orange.*, *.*.rabbit) Q1, Q2
lazy.orange.elephant (lazy.#, *.orange.*) Q1, Q2
quick.orange.fox (*.orange.*) Q1
lazy.red.fox (lazy.#) Q2
21. RabbitMQ на практике
• Использование брокера сообщений RabbitMQ для выполнения отложенных
трудоемких задач
• Пересчет множеств хранящихся в Redis при изменениях сущностей системы
• Консьюмеры пишут в master
• Фронтэнд читает со slave