Виртуальный ЦОД для корпоративных клиентов на базе Virtuozzo: стабильность, п...Ontico
Услуга виртуального дата-центра предъявляет жесткие требования к платформе виртуализации - клиенты хотят высокую производительность и стабильность, а провайдерам нужна возможность максимально плотно размещать нагрузки клиентов.
Мы расскажем:
1. как мы работали с Virtuozzo, чтобы сделать его более производительным и стабильным и, вместе с тем, добиться максимальной плотности размещения виртуальных машин;
2. контейнеры Virtuozzo прекрасно решают эту задачу, но не подходят для размещения некоторых типов приложений, например, Windows;
3. как мы будем переходить на Virtuozzo с KVM, каких целей мы хотим добиться.
Вадим Мадисон "Опыт разработки через микросервисы"Tanya Denisyuk
Мы начали разработку через микросервисы когда это еще не было трендом, было не ясно - это реально работающий подход или просто очередная модная штука. Не было понимания как это делать правильно, где подводные камни и что за одним словом “микросервисы” по факту стоит куча всего, что придется узнать, изучить и понять.
Сейчас у нас большой парк микросервисов, но оперировать ими становится все проще - сказывается опыт.
В ходе доклада я поделюсь основными моментами в разработке микросервисов, расскажу как это делаем мы и что для этого используем.
NVMf: 5 млн IOPS по сети своими руками / Андрей Николаенко (IBS)Ontico
В выпуске 4.8 ядра Linux появилась поддержка NVMf (NVM Express over Fabrics) — стандартизованной возможности присоединять по сети как блочные устройства твердотельные накопители, установленные в разъёмы PCI Express. NVMf лишён многих недостатков iSCSI, повторяющего по сети SCSI-команды со всеми их издержками времён дисковых накопителей, и главное — позволяет по полной использовать возможности сетей с прямым доступом к оперативной памяти (RDMA). Таким образом, можно под управлением одного узла собрать сверхбыстрый и сверхотзывчивый пул блочных устройств, не прибегая к покупке дорогого флэш-массива. Но как воспользоваться этим пулом, не загубив теоретические показатели программными обёртками?
В докладе будут рассмотрены варианты применения NVMf для различных конфигураций PostgreSQL, Oracle Database, Hadoop, файловых хранилищ, о разработках в направлении «программно-определяемой памяти» с применением NVMe-устройств, доступных по сети, обсуждены текущие проблемы, ограничения и перспективы. Особое внимание будет уделено практическим способам измерения производительности ввода-вывода с учётом задачи, решаемой подсистемой хранения.
AWS и GCP: трудная жизнь в облаках / Максим Пугачев (IPONWEB)Ontico
Разница между “несколько серверов в облаках” и “вся инфраструктура в облаках“ огромна. С одной стороны, мы перекладываем миллион забот на гигантские плечи Amazon и Google. С другой стороны, к сожалению, обретаем много новых и порой необычных проблем.
Как жить в облаках двух самых популярных провайдеров? Что это за проблемы и как их решать? В чем особенности облаков, если вы живете в мире highload? Как выжимать максимум из того, что предоставляют провайдеры?
Я попытаюсь рассказать о наиболее важных, на мой взгляд, особенностях:
- Почему не стоит полагаться на заявленные характеристики виртуальных машин.
- Почему нет разницы между загрузкой CPU в 85% и 100%.
- Всевозможные аномалии и неожиданные "спайки" в метриках.
- "Облачные" диски и их особенности.
Сравнение решений по балансировке высоконагруженных систем / Евгений Пивень (...Ontico
+ Функционал разных решений для балансировки.
+ Виды балансировщиков (DNS, hardware, software, облачные решения).
+ Поведение при скачках трафика и возможности скалирования сервиса.
+ Специфика трафика RTB в контексте балансировки.
+ Проблемы, которые возникали у нас, и как мы их решали.
Опыт построения СХД на базе Windows Server для использования в публичном обла...Ontico
В докладе мы поделимся опытом, полученным в ходе создания публичного облака, построенного на базе продуктов Microsoft. В частности, речь пойдет о построении программно-определяемой системы хранения данных на основе технологии Storage Spaces. Основное предназначение полученной СХД объемом около 80ТБ - использование в кластере Hyper-V для запуска порядка 5000 ВМ.
Мы рассмотрим архитектуру хранилища, проблемы снижения latency сетевого трафика, а также подходы повышения производительности при создании пулов и использовании кэша. Кроме того, буду затронуты вопросы тестирования производительности и сценарии миграции на Storage Spaces Direct.
MySQL® и MongoDB® - когда что лучше использовать? / Петр Зайцев (Percona)Ontico
Сегодня много дискуссий о том, что лучше - MySQL или PostgreSQL? Однако перед тем, как выбирать именно реляционную базу данных для своего проекта, стоит понять, является ли реляционная база данных наилучшим решением для него.
В рамках этого доклада мы сравним наиболее популярную реляционную базу данных с открытым кодом с наиболее популярным хранилищем документов с открытым кодом. Мы определим, в каких случаях эффективнее всего работает MySQL, а в каких - MongoDB. Мы также рассмотрим ситуации, в которых ни одна из этих баз данных не будет лучшим решением и в которых целесообразно остановить свой выбор на других технологиях.
Стратегия и тактика улучшения производительности BSS систем оператора мобильн...Ontico
В докладе поделимся опытом построения комплексного процесса последовательного улучшения производительности информационных систем мобильного оператора, расскажем об используемых инструментах и компонентах (Oracle, Tarantool, Java, Jmeter и т.д.).
Особенность нашего оператора в том, что основной канал взаимодействия с клиентом - это мобильное приложение или web Личный кабинет, а не USSD команды и СМС, как у основной массы операторов. Данная особенность создает высокие требования к времени отклика и доступности сервисов и ставит перед нами целый ряд вопросов:
- Как достичь приемлемого времени отрисовки страниц (не более 2х секунд) и не "уронить" backend при увеличении кол-ва абонентов в несколько раз за год до 4х миллионов?
- Как обеспечить приемлемую производительность при наличии сложных оркестрирующих процессов на ESB и достаточно медленного, основанного на Oracle биллинга?
- Как контролировать и улучшать производительность и доступность постоянно и на упреждение, а не когда "жареный петух клюнет"?
Мы расскажем о том, как мы отвечаем на выше обозначенные вопросы. В частности, расскажем о внедрении двух БД - inmemory БД на чтение и Oracle на запись с соответствующей синхронизацией, о технике кэширования на нескольких уровнях, оптимизации синхронных и асинхронных процессов, о постоянном выявлении узких мест на тестировании, о кластеризации и других аспектах улучшения общей и частной производительности и доступности при быстро растущей абонентской базе и беспощадной креативности бизнеса.
Виртуальный ЦОД для корпоративных клиентов на базе Virtuozzo: стабильность, п...Ontico
Услуга виртуального дата-центра предъявляет жесткие требования к платформе виртуализации - клиенты хотят высокую производительность и стабильность, а провайдерам нужна возможность максимально плотно размещать нагрузки клиентов.
Мы расскажем:
1. как мы работали с Virtuozzo, чтобы сделать его более производительным и стабильным и, вместе с тем, добиться максимальной плотности размещения виртуальных машин;
2. контейнеры Virtuozzo прекрасно решают эту задачу, но не подходят для размещения некоторых типов приложений, например, Windows;
3. как мы будем переходить на Virtuozzo с KVM, каких целей мы хотим добиться.
Вадим Мадисон "Опыт разработки через микросервисы"Tanya Denisyuk
Мы начали разработку через микросервисы когда это еще не было трендом, было не ясно - это реально работающий подход или просто очередная модная штука. Не было понимания как это делать правильно, где подводные камни и что за одним словом “микросервисы” по факту стоит куча всего, что придется узнать, изучить и понять.
Сейчас у нас большой парк микросервисов, но оперировать ими становится все проще - сказывается опыт.
В ходе доклада я поделюсь основными моментами в разработке микросервисов, расскажу как это делаем мы и что для этого используем.
NVMf: 5 млн IOPS по сети своими руками / Андрей Николаенко (IBS)Ontico
В выпуске 4.8 ядра Linux появилась поддержка NVMf (NVM Express over Fabrics) — стандартизованной возможности присоединять по сети как блочные устройства твердотельные накопители, установленные в разъёмы PCI Express. NVMf лишён многих недостатков iSCSI, повторяющего по сети SCSI-команды со всеми их издержками времён дисковых накопителей, и главное — позволяет по полной использовать возможности сетей с прямым доступом к оперативной памяти (RDMA). Таким образом, можно под управлением одного узла собрать сверхбыстрый и сверхотзывчивый пул блочных устройств, не прибегая к покупке дорогого флэш-массива. Но как воспользоваться этим пулом, не загубив теоретические показатели программными обёртками?
В докладе будут рассмотрены варианты применения NVMf для различных конфигураций PostgreSQL, Oracle Database, Hadoop, файловых хранилищ, о разработках в направлении «программно-определяемой памяти» с применением NVMe-устройств, доступных по сети, обсуждены текущие проблемы, ограничения и перспективы. Особое внимание будет уделено практическим способам измерения производительности ввода-вывода с учётом задачи, решаемой подсистемой хранения.
AWS и GCP: трудная жизнь в облаках / Максим Пугачев (IPONWEB)Ontico
Разница между “несколько серверов в облаках” и “вся инфраструктура в облаках“ огромна. С одной стороны, мы перекладываем миллион забот на гигантские плечи Amazon и Google. С другой стороны, к сожалению, обретаем много новых и порой необычных проблем.
Как жить в облаках двух самых популярных провайдеров? Что это за проблемы и как их решать? В чем особенности облаков, если вы живете в мире highload? Как выжимать максимум из того, что предоставляют провайдеры?
Я попытаюсь рассказать о наиболее важных, на мой взгляд, особенностях:
- Почему не стоит полагаться на заявленные характеристики виртуальных машин.
- Почему нет разницы между загрузкой CPU в 85% и 100%.
- Всевозможные аномалии и неожиданные "спайки" в метриках.
- "Облачные" диски и их особенности.
Сравнение решений по балансировке высоконагруженных систем / Евгений Пивень (...Ontico
+ Функционал разных решений для балансировки.
+ Виды балансировщиков (DNS, hardware, software, облачные решения).
+ Поведение при скачках трафика и возможности скалирования сервиса.
+ Специфика трафика RTB в контексте балансировки.
+ Проблемы, которые возникали у нас, и как мы их решали.
Опыт построения СХД на базе Windows Server для использования в публичном обла...Ontico
В докладе мы поделимся опытом, полученным в ходе создания публичного облака, построенного на базе продуктов Microsoft. В частности, речь пойдет о построении программно-определяемой системы хранения данных на основе технологии Storage Spaces. Основное предназначение полученной СХД объемом около 80ТБ - использование в кластере Hyper-V для запуска порядка 5000 ВМ.
Мы рассмотрим архитектуру хранилища, проблемы снижения latency сетевого трафика, а также подходы повышения производительности при создании пулов и использовании кэша. Кроме того, буду затронуты вопросы тестирования производительности и сценарии миграции на Storage Spaces Direct.
MySQL® и MongoDB® - когда что лучше использовать? / Петр Зайцев (Percona)Ontico
Сегодня много дискуссий о том, что лучше - MySQL или PostgreSQL? Однако перед тем, как выбирать именно реляционную базу данных для своего проекта, стоит понять, является ли реляционная база данных наилучшим решением для него.
В рамках этого доклада мы сравним наиболее популярную реляционную базу данных с открытым кодом с наиболее популярным хранилищем документов с открытым кодом. Мы определим, в каких случаях эффективнее всего работает MySQL, а в каких - MongoDB. Мы также рассмотрим ситуации, в которых ни одна из этих баз данных не будет лучшим решением и в которых целесообразно остановить свой выбор на других технологиях.
Стратегия и тактика улучшения производительности BSS систем оператора мобильн...Ontico
В докладе поделимся опытом построения комплексного процесса последовательного улучшения производительности информационных систем мобильного оператора, расскажем об используемых инструментах и компонентах (Oracle, Tarantool, Java, Jmeter и т.д.).
Особенность нашего оператора в том, что основной канал взаимодействия с клиентом - это мобильное приложение или web Личный кабинет, а не USSD команды и СМС, как у основной массы операторов. Данная особенность создает высокие требования к времени отклика и доступности сервисов и ставит перед нами целый ряд вопросов:
- Как достичь приемлемого времени отрисовки страниц (не более 2х секунд) и не "уронить" backend при увеличении кол-ва абонентов в несколько раз за год до 4х миллионов?
- Как обеспечить приемлемую производительность при наличии сложных оркестрирующих процессов на ESB и достаточно медленного, основанного на Oracle биллинга?
- Как контролировать и улучшать производительность и доступность постоянно и на упреждение, а не когда "жареный петух клюнет"?
Мы расскажем о том, как мы отвечаем на выше обозначенные вопросы. В частности, расскажем о внедрении двух БД - inmemory БД на чтение и Oracle на запись с соответствующей синхронизацией, о технике кэширования на нескольких уровнях, оптимизации синхронных и асинхронных процессов, о постоянном выявлении узких мест на тестировании, о кластеризации и других аспектах улучшения общей и частной производительности и доступности при быстро растущей абонентской базе и беспощадной креативности бизнеса.
Преждевременная оптимизация архитектуры / Евгений Потапов, Антон Баранов (ITS...Ontico
Работа в высоконагруженных проектах всегда была такой сферой деятельности, где можно в рамках решения прикладных задач находить и применять сложные и интересные решения.
К сожалению, очень часто во главу угла ставится не надежное решение поставленной задачи, а именно применение сложного и интересного решения, которое даст специалисту новый опыт и удовольствие от сложных архитектур.
В своем докладе я хочу пройтись по тем стандартным "набитым шишкам", которые мы встречаем в своей работе, когда сложное, новое и интересное решение не означает стабильность системы.
1. Когда "интересно" не значит "правильно"?
1.1. Специфика развития высоконагруженного проекта.
1.2. Требования бизнеса и современные технологии.
1.3. Типичные "сомнительные" решения.
2. Проблемы в архитектуре отказоустойчивых систем.
2.1. Ошибки в планировании резервирования.
2.2. Ошибки в планировании системы выкладок.
2.3. Ошибки в архитектурах систем хранения данных.
3. Проблемы в архитектуре систем, рассчитанных на высокую нагрузку.
3.1. Ошибки в планировании мощностей системы.
3.2. Ошибки в планировании возможностей масштабирования системы.
3.3. Ошибки в архитектурах систем хранения данных.
Компания «Моё дело» прошла путь от маленького стартапа до лидера рынка в своем сегменте. Вместе с ростом компании росла и ее it структура. Инфраструктура эволюционировала космическими темпами, кол-во проектов стремительно росло. Естественно, всем этим необходимо уметь грамотно оркестрировать. Как это делаем мы и во что это превращается мы и хотим вам рассказать.
Сегментируем 600 млн. пользователей в режиме реального времени каждый день. H...Ontico
Каждый день пользователи совершают миллионы действий в Интернете. Нам в FACETz DMP необходимо структурировать эти данные и проводить сегментацию для выявления предпочтений пользователей.
Хочу рассказать, как мы:
- Сегментируем в реальном времени 600 миллионов пользователей ежедневно;
- Поставляем данные партнерам, DSP, Google с минимальной задержкой;
- Храним статистику по количеству уникальных пользователей в сегменте при потоковой обработке;
- Отслеживаем влияние изменения параметров сегментации;
- Ведем подсчет аффинитивности домена к сегменту для аналитики аудиторий.
Артем Маринов "Сегментируем 600 млн. пользователей в режиме реального времени...Tanya Denisyuk
Каждый день пользователи совершают миллионы действий в Интернете. Нам в FACETz DMP необходимо структурировать эти данные и проводить сегментацию для выявления предпочтений пользователей.
Хочу рассказать, как мы:
- Сегментируем в реальном времени 600 миллионов пользователей ежедневно;
- Поставляем данные партнерам, DSP, Google с минимальной задержкой;
- Храним статистику по количеству уникальных пользователей в сегменте при потоковой обработке;
- Отслеживаем влияние изменения параметров сегментации;
- Ведем подсчет аффинитивности домена к сегменту для аналитики аудиторий.
Как SRE следит за стабильностью и скоростью HeadHunter / Антон Иванов (HeadHu...Ontico
HeadHunter - сайт, где соискатели находят работу, а работодатели - сотрудников.
Днем к нам приходит 3K запросов в секунду (без статики), что превращается в 25K rps к бэкендам и 50K rps к базам данных.
Раньше стабильность сайта могла быть ниже 99%. Теперь - это 99.9% и лучше.
Стабильностью сайта у нас занимается как служба эксплуатации, так и команда разработчиков SRE (site reliability engineering).
В прошлом году Николай Сивко уже рассказывал об организации службы эксплуатации и мониторинге сайта. Но эксплуатация отвечает за железо, сеть и ОС, а за приложения - команда SRE.
В докладе хочу рассказать о том, как мы построили процесс, позволяющий каждый месяц улучшать стабильность сайта, с какими техническими проблемами сталкиваемся и как решаем. В частности:
- как мы определяем, когда сайт работает, а когда - нет?
- что делаем, когда сайт лежит?
- как настроили мониторинг и другие инструменты для быстрой локализации проблемы;
- как нагружаем сайт, чтобы заранее выявить узкое место?
Чтобы не было скучно, расскажу о конкретных кейсах:
- как мы масштабировали реплики базы данных;
- почему отказались от PgBouncer для высоконагруженных бэкендов;
- почему нам не подошел Graylog, и как мы ищем в логах другим гораздо более простым и быстрым способом;
- как решили проблему заваливания себя ретраями;
- и др.
Сергей Аверин "Распространенные ошибки применения баз данных"Tanya Denisyuk
Выбор хранилища данных — сложная задача, с которой часто сталкиваются разработчики. Чаще всего результат этого выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.
Дизайн REST API для высокопроизводительных систем / Александр Лебедев (Новые ...Ontico
Доклад осветит вопросы устройства REST API для веб-приложений и мобильных клиентов, от которых требуется высокая производительность.
Проектирование высокопроизводительных REST API.
- Кто должен участвовать в проектировании.
- Как узнать, что оптимизировать.
- Как измерять производительность REST API.
Паттерны и антипаттерны.
- Почему pagination - это плохо, и на что лучше заменить.
- Проблема N+1 и как с ней бороться.
- Бесполезные данные - как обнаружить и уничтожить.
- Как не ломать кэширование на клиенте.
- Эффективная работа с интерфейсами "мастер-детали".
Кэширование.
- Три слоя кэширования.
- Самый быстрый запрос - тот, которого не было. Как увеличить их количество.
- Экономия трафика.
- Исключение ненужных вычислений.
- Подходы к инвалидации кэша.
Приемы оптимизации работы с API на клиенте.
- Параллельные запросы.
- Эффективный разбор данных.
- In-memory DB на клиенте.
- Стратегии кэширования на клиенте.
Велосипед уже изобретен. Что умеют промышленные СХД? / Антон Жбанков (Nutanix)Ontico
Зачем мы каждый раз изобретаем велосипед, только потому что можем? Корпоративные СХД существуют более 25 лет и умеют очень многое.
Защита данных, качество обслуживания, многоуровневое хранение и кэширование на флэш-памяти. Система хранения данных - это не только гигабайт по минимальной цене, но так же и гарантированная производительность и отказоустойчивость.
Вы узнаете, как можно обеспечить своим данным высокую степень защиты, значительно сократив время реализации проекта. Или, наоборот, убедитесь в том, что СХД корпоративного класса вашему проекту не подходят.
Как не положить тысячи серверов с помощью системы централизованного управлени...Ontico
В 2012 году мы начали внедрение CFEngine в нашу инфраструктуру. Переход на централизованное управление конфигурацией в проектах такого масштаба подобен ремонту - его невозможно закончить, его можно только прекратить. И уже весной 2013 года (в день 404 ошибки и международного дня Интернета) этот "ремонт" превратился в катастрофу и был остановлен. После 3 суток недоступности портала нам пришлось изобрести схему, которая бы физически ограничивала возможность повторения катастрофы. Схема включает в себя тестирование политик на тестовых серверах различной важности и конфигурации. "Маринование" в этой тестовой среде сопровождается автоматизированным контролем характеристик нагрузки этих серверов. Далее происходит обязательный ревью и плавное распространение последовательно по всем датацентрам.
В докладе будет рассказано:
1. почему мы выбрали CFEngine, а не Chief или Puppet;
2. как мы научили CFEngine быть дружелюбным (примеры политик и выдержки из библиотеки);
3. 100500 предпринятых мер, что бы не повторить "день 404" и соблюсти баланс между безопасностью и удобством;
4. как ещё можно использовать системы управления серверами.
Как devops исчерпывает себя, и что будет дальше / Кирилл Вечера (Jetware)Ontico
* Следующее поколение моделей проектирования и эксплуатации серверных приложений в публичных облаках и на классических серверах.
* Сравнение методов эксплуатации: "традиционных" Chef/Salt/Ansible, immutage images/virtual appliances/Docker, и автономных рабочих окружений Jetware/Snappy/Nix/Habitat.
* Самоконфигурация, самоадминистрирование и самовосстановление серверов.
** Управление большими системами Mesos, Kubernetes, Docker Swarm.
** Управление внутри микросервисов.
* Независимость рабочего окружения приложений от операционной системы и ядра, just enough OS.
* Приложение - это не только исходный код, но и операционное окружение. Разработка, тестирование и версионирование всего полностью.
* Сервер как программа - компонентный подход.
10 способов достижения HighLoad'а и BigData на ровном месте / Илья Космодемья...Ontico
Веб-сайт нужно делать так, чтобы о перипетиях его разработки и поддержки бессонными ночами через пару лет можно было рассказать на конференции Highload++, а тамошнюю аудиторию сложно удивить велосипедом с треугольными каменными колесами. Большинство разработчиков свято следуют этому принципу то ли в силу природной любознательности и трудолюбия, то ли по причине отсутствия конференции LowLoad--.
Примерно такие мысли приходят в голову практически любому специалисту по хранилищам данных, когда он видит успешный веб-проект, испытывающий стандартные проблемы с базой данных.
В этом докладе я расскажу о 10-ти очень распространенных ошибках проектирования и эксплуатации хранилища в веб-проекте — от преждевременного шардирования базы и непродуманной системы архивации ненужных данных до особенностей работы всеми любимых фреймворков. Про каждую из них я расскажу подробно и поделюсь рецептами, как такие ошибки исправлять.
За счет чего Tarantool такой оптимальный / Денис Аникин (Mail.Ru)Ontico
Многие из вас, наверное, видели результаты тестов сравнения Tarantool с остальными СУБД, которые показывают, что Tarantool быстрее всех, оптимальней по памяти, обрабатывает наибольшее количество транзакций в секунду.
И, несмотря на то, что исходные коды всех тестов полностью открыты и хорошо откомментированы, позволяя всем желающим повторить тесты, все равно остаются вопросы - за счет чего Tarantool такой быстрый и оптимальный?
Я решил суммировать мои ответы на эти вопросы в докладе на Highload++.
Итак, почему Tarantool такой быстрый?
Краткий ответ: потому что он с самого начала разрабатывался и до сих пор разрабатывается во главе угла с производительностью/оптимальностью/минимальным потреблением всех ресурсов системы.
Более полный ответ я раскрою в своем выступлении. Приходите, будет интересно! :)
HDD, SSD, RAM, RAID, и кого на ком кэшировать / Михаил Конюхов (Perfect Solut...Ontico
Рассуждение, опыт, практика и примеры на тему производительности ввода-вывода.
Мы будем сравнивать "дефолтное" поведение SSD и HDD, сравним "недефолтное" поведение после тюнинга HDD. Я расскажу о плюсах и минусах в надежности HDD и SSD, о проблемах восстановления SSD и HDD после сбоев. Многие моменты будут посвящены кэшированию ввода-вывода, что очень помогает в реальных проектах.
Отдельная тема - оптимизация ФС и сервера для снижения количества операций ввода-вывода (IOPS), попробую оценить, что можно сделать с каким-нибудь проектом-примером.
Будут показаны и рассказаны реальные примеры из моего опыта оптимизации IO, я даже нарисую "карту принятия решения" для выбора накопителей для Вашего проекта.
Кэширование данных в web приложениях. Использование memcached / Юрий Красноще...Ontico
Каждый разработчик web приложений рано или поздно сталкивается с довольно типичной проблемой: перед ним стоит задача построить фабрику по производству омнониевых торсиометров.
Фабрика производит омнониевые торсиометры очень быстро, но для калибровки прибора (как известно) необходим омноний, за которым приходится летать на Андромеду.
Пока корабль летит до Андромеды, фабрика простаивает.
Самый очевидный выход из ситуации - построить склад омнониума прямо рядом с фабрикой.
Терминология кэширования
Выбор места для кэширования в WEB
Выбор данных для кэширования
Кэширование на стороне бэкенда
Отдельный кэширующий сервис
Пара слов о memcached
Пара слов о Redis
Master-Master Replication and Scaling of an Application Between Each of the I...vsoshnikov
Solutions to the problem of gathering and processing data in large-scale wireless sensor networks in the industrial IoT.
The rapid growth of wireless SCADA networks based on technologies like LoRa and 6LoWPAN has given birth to the problem of gathering and processing data from thousands of sensors and replicating this data to the cloud and to devices based on ARMv7+.
This report addresses ways and methods of solving this problem, including solutions for low-speed gateways and devices in industrial IoT networks.
Преждевременная оптимизация архитектуры / Евгений Потапов, Антон Баранов (ITS...Ontico
Работа в высоконагруженных проектах всегда была такой сферой деятельности, где можно в рамках решения прикладных задач находить и применять сложные и интересные решения.
К сожалению, очень часто во главу угла ставится не надежное решение поставленной задачи, а именно применение сложного и интересного решения, которое даст специалисту новый опыт и удовольствие от сложных архитектур.
В своем докладе я хочу пройтись по тем стандартным "набитым шишкам", которые мы встречаем в своей работе, когда сложное, новое и интересное решение не означает стабильность системы.
1. Когда "интересно" не значит "правильно"?
1.1. Специфика развития высоконагруженного проекта.
1.2. Требования бизнеса и современные технологии.
1.3. Типичные "сомнительные" решения.
2. Проблемы в архитектуре отказоустойчивых систем.
2.1. Ошибки в планировании резервирования.
2.2. Ошибки в планировании системы выкладок.
2.3. Ошибки в архитектурах систем хранения данных.
3. Проблемы в архитектуре систем, рассчитанных на высокую нагрузку.
3.1. Ошибки в планировании мощностей системы.
3.2. Ошибки в планировании возможностей масштабирования системы.
3.3. Ошибки в архитектурах систем хранения данных.
Компания «Моё дело» прошла путь от маленького стартапа до лидера рынка в своем сегменте. Вместе с ростом компании росла и ее it структура. Инфраструктура эволюционировала космическими темпами, кол-во проектов стремительно росло. Естественно, всем этим необходимо уметь грамотно оркестрировать. Как это делаем мы и во что это превращается мы и хотим вам рассказать.
Сегментируем 600 млн. пользователей в режиме реального времени каждый день. H...Ontico
Каждый день пользователи совершают миллионы действий в Интернете. Нам в FACETz DMP необходимо структурировать эти данные и проводить сегментацию для выявления предпочтений пользователей.
Хочу рассказать, как мы:
- Сегментируем в реальном времени 600 миллионов пользователей ежедневно;
- Поставляем данные партнерам, DSP, Google с минимальной задержкой;
- Храним статистику по количеству уникальных пользователей в сегменте при потоковой обработке;
- Отслеживаем влияние изменения параметров сегментации;
- Ведем подсчет аффинитивности домена к сегменту для аналитики аудиторий.
Артем Маринов "Сегментируем 600 млн. пользователей в режиме реального времени...Tanya Denisyuk
Каждый день пользователи совершают миллионы действий в Интернете. Нам в FACETz DMP необходимо структурировать эти данные и проводить сегментацию для выявления предпочтений пользователей.
Хочу рассказать, как мы:
- Сегментируем в реальном времени 600 миллионов пользователей ежедневно;
- Поставляем данные партнерам, DSP, Google с минимальной задержкой;
- Храним статистику по количеству уникальных пользователей в сегменте при потоковой обработке;
- Отслеживаем влияние изменения параметров сегментации;
- Ведем подсчет аффинитивности домена к сегменту для аналитики аудиторий.
Как SRE следит за стабильностью и скоростью HeadHunter / Антон Иванов (HeadHu...Ontico
HeadHunter - сайт, где соискатели находят работу, а работодатели - сотрудников.
Днем к нам приходит 3K запросов в секунду (без статики), что превращается в 25K rps к бэкендам и 50K rps к базам данных.
Раньше стабильность сайта могла быть ниже 99%. Теперь - это 99.9% и лучше.
Стабильностью сайта у нас занимается как служба эксплуатации, так и команда разработчиков SRE (site reliability engineering).
В прошлом году Николай Сивко уже рассказывал об организации службы эксплуатации и мониторинге сайта. Но эксплуатация отвечает за железо, сеть и ОС, а за приложения - команда SRE.
В докладе хочу рассказать о том, как мы построили процесс, позволяющий каждый месяц улучшать стабильность сайта, с какими техническими проблемами сталкиваемся и как решаем. В частности:
- как мы определяем, когда сайт работает, а когда - нет?
- что делаем, когда сайт лежит?
- как настроили мониторинг и другие инструменты для быстрой локализации проблемы;
- как нагружаем сайт, чтобы заранее выявить узкое место?
Чтобы не было скучно, расскажу о конкретных кейсах:
- как мы масштабировали реплики базы данных;
- почему отказались от PgBouncer для высоконагруженных бэкендов;
- почему нам не подошел Graylog, и как мы ищем в логах другим гораздо более простым и быстрым способом;
- как решили проблему заваливания себя ретраями;
- и др.
Сергей Аверин "Распространенные ошибки применения баз данных"Tanya Denisyuk
Выбор хранилища данных — сложная задача, с которой часто сталкиваются разработчики. Чаще всего результат этого выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.
Дизайн REST API для высокопроизводительных систем / Александр Лебедев (Новые ...Ontico
Доклад осветит вопросы устройства REST API для веб-приложений и мобильных клиентов, от которых требуется высокая производительность.
Проектирование высокопроизводительных REST API.
- Кто должен участвовать в проектировании.
- Как узнать, что оптимизировать.
- Как измерять производительность REST API.
Паттерны и антипаттерны.
- Почему pagination - это плохо, и на что лучше заменить.
- Проблема N+1 и как с ней бороться.
- Бесполезные данные - как обнаружить и уничтожить.
- Как не ломать кэширование на клиенте.
- Эффективная работа с интерфейсами "мастер-детали".
Кэширование.
- Три слоя кэширования.
- Самый быстрый запрос - тот, которого не было. Как увеличить их количество.
- Экономия трафика.
- Исключение ненужных вычислений.
- Подходы к инвалидации кэша.
Приемы оптимизации работы с API на клиенте.
- Параллельные запросы.
- Эффективный разбор данных.
- In-memory DB на клиенте.
- Стратегии кэширования на клиенте.
Велосипед уже изобретен. Что умеют промышленные СХД? / Антон Жбанков (Nutanix)Ontico
Зачем мы каждый раз изобретаем велосипед, только потому что можем? Корпоративные СХД существуют более 25 лет и умеют очень многое.
Защита данных, качество обслуживания, многоуровневое хранение и кэширование на флэш-памяти. Система хранения данных - это не только гигабайт по минимальной цене, но так же и гарантированная производительность и отказоустойчивость.
Вы узнаете, как можно обеспечить своим данным высокую степень защиты, значительно сократив время реализации проекта. Или, наоборот, убедитесь в том, что СХД корпоративного класса вашему проекту не подходят.
Как не положить тысячи серверов с помощью системы централизованного управлени...Ontico
В 2012 году мы начали внедрение CFEngine в нашу инфраструктуру. Переход на централизованное управление конфигурацией в проектах такого масштаба подобен ремонту - его невозможно закончить, его можно только прекратить. И уже весной 2013 года (в день 404 ошибки и международного дня Интернета) этот "ремонт" превратился в катастрофу и был остановлен. После 3 суток недоступности портала нам пришлось изобрести схему, которая бы физически ограничивала возможность повторения катастрофы. Схема включает в себя тестирование политик на тестовых серверах различной важности и конфигурации. "Маринование" в этой тестовой среде сопровождается автоматизированным контролем характеристик нагрузки этих серверов. Далее происходит обязательный ревью и плавное распространение последовательно по всем датацентрам.
В докладе будет рассказано:
1. почему мы выбрали CFEngine, а не Chief или Puppet;
2. как мы научили CFEngine быть дружелюбным (примеры политик и выдержки из библиотеки);
3. 100500 предпринятых мер, что бы не повторить "день 404" и соблюсти баланс между безопасностью и удобством;
4. как ещё можно использовать системы управления серверами.
Как devops исчерпывает себя, и что будет дальше / Кирилл Вечера (Jetware)Ontico
* Следующее поколение моделей проектирования и эксплуатации серверных приложений в публичных облаках и на классических серверах.
* Сравнение методов эксплуатации: "традиционных" Chef/Salt/Ansible, immutage images/virtual appliances/Docker, и автономных рабочих окружений Jetware/Snappy/Nix/Habitat.
* Самоконфигурация, самоадминистрирование и самовосстановление серверов.
** Управление большими системами Mesos, Kubernetes, Docker Swarm.
** Управление внутри микросервисов.
* Независимость рабочего окружения приложений от операционной системы и ядра, just enough OS.
* Приложение - это не только исходный код, но и операционное окружение. Разработка, тестирование и версионирование всего полностью.
* Сервер как программа - компонентный подход.
10 способов достижения HighLoad'а и BigData на ровном месте / Илья Космодемья...Ontico
Веб-сайт нужно делать так, чтобы о перипетиях его разработки и поддержки бессонными ночами через пару лет можно было рассказать на конференции Highload++, а тамошнюю аудиторию сложно удивить велосипедом с треугольными каменными колесами. Большинство разработчиков свято следуют этому принципу то ли в силу природной любознательности и трудолюбия, то ли по причине отсутствия конференции LowLoad--.
Примерно такие мысли приходят в голову практически любому специалисту по хранилищам данных, когда он видит успешный веб-проект, испытывающий стандартные проблемы с базой данных.
В этом докладе я расскажу о 10-ти очень распространенных ошибках проектирования и эксплуатации хранилища в веб-проекте — от преждевременного шардирования базы и непродуманной системы архивации ненужных данных до особенностей работы всеми любимых фреймворков. Про каждую из них я расскажу подробно и поделюсь рецептами, как такие ошибки исправлять.
За счет чего Tarantool такой оптимальный / Денис Аникин (Mail.Ru)Ontico
Многие из вас, наверное, видели результаты тестов сравнения Tarantool с остальными СУБД, которые показывают, что Tarantool быстрее всех, оптимальней по памяти, обрабатывает наибольшее количество транзакций в секунду.
И, несмотря на то, что исходные коды всех тестов полностью открыты и хорошо откомментированы, позволяя всем желающим повторить тесты, все равно остаются вопросы - за счет чего Tarantool такой быстрый и оптимальный?
Я решил суммировать мои ответы на эти вопросы в докладе на Highload++.
Итак, почему Tarantool такой быстрый?
Краткий ответ: потому что он с самого начала разрабатывался и до сих пор разрабатывается во главе угла с производительностью/оптимальностью/минимальным потреблением всех ресурсов системы.
Более полный ответ я раскрою в своем выступлении. Приходите, будет интересно! :)
HDD, SSD, RAM, RAID, и кого на ком кэшировать / Михаил Конюхов (Perfect Solut...Ontico
Рассуждение, опыт, практика и примеры на тему производительности ввода-вывода.
Мы будем сравнивать "дефолтное" поведение SSD и HDD, сравним "недефолтное" поведение после тюнинга HDD. Я расскажу о плюсах и минусах в надежности HDD и SSD, о проблемах восстановления SSD и HDD после сбоев. Многие моменты будут посвящены кэшированию ввода-вывода, что очень помогает в реальных проектах.
Отдельная тема - оптимизация ФС и сервера для снижения количества операций ввода-вывода (IOPS), попробую оценить, что можно сделать с каким-нибудь проектом-примером.
Будут показаны и рассказаны реальные примеры из моего опыта оптимизации IO, я даже нарисую "карту принятия решения" для выбора накопителей для Вашего проекта.
Кэширование данных в web приложениях. Использование memcached / Юрий Красноще...Ontico
Каждый разработчик web приложений рано или поздно сталкивается с довольно типичной проблемой: перед ним стоит задача построить фабрику по производству омнониевых торсиометров.
Фабрика производит омнониевые торсиометры очень быстро, но для калибровки прибора (как известно) необходим омноний, за которым приходится летать на Андромеду.
Пока корабль летит до Андромеды, фабрика простаивает.
Самый очевидный выход из ситуации - построить склад омнониума прямо рядом с фабрикой.
Терминология кэширования
Выбор места для кэширования в WEB
Выбор данных для кэширования
Кэширование на стороне бэкенда
Отдельный кэширующий сервис
Пара слов о memcached
Пара слов о Redis
Master-Master Replication and Scaling of an Application Between Each of the I...vsoshnikov
Solutions to the problem of gathering and processing data in large-scale wireless sensor networks in the industrial IoT.
The rapid growth of wireless SCADA networks based on technologies like LoRa and 6LoWPAN has given birth to the problem of gathering and processing data from thousands of sensors and replicating this data to the cloud and to devices based on ARMv7+.
This report addresses ways and methods of solving this problem, including solutions for low-speed gateways and devices in industrial IoT networks.
Хранение данных на виниле / Константин Осипов (tarantool.org)Ontico
В rfc1149 дан исчерпывающий обзор преимуществ голубиной почты для протокола IP: низкая пропускная способность, невысокая надёжность, простая топология сети. Для того чтобы дать адекватный ответ вызовам эпохи мемристоров и квантовых вычислений, Tarantool 1.7 содержит новый движок для хранения данных на классических жёстких дисках и флэш-накопителях: Vinyl. Tarantool известен своей скоростью, и мы постарались не ударить в грязь лицом и на этот раз.
В докладе я расскажу об устройстве нашего нового storage engine:
- как мы объединили in-memory технологию и LSM (log structured merge) деревья для достижения оптимальной производительности и утилизации ресурса накопителя,
- как работает multiversion concurrency control в Vinyl,
- основной компонент в промышленной реализации LSM дерева - merge scheduler, т.е. планировщик слияний и сборки мусора дерева. Я расскажу о подходе, который позволяет максимально снизить износ накопителя, при этом уложиться в заданные рамки производительности запросов.
NoSQL — это слово громко "жужжит".
К сожалению, оно при этом ничего не означает. Это не продукт, не технология, и даже не концепция. Это даже не подход к проектированию. Это, скорее, декларация отказа от некоторых паттернов проектирования, господствовавших в разработке клиент-серверных систем долгие годы.
На этом доклад можно было бы и закончить. Если бы мы не знали достоверно, что на свете есть люди, которые умудряются извлекать прибыль, используя NoSQL в своих проектах. Ну или сокращать убытки, по крайней мере.
Попробуем еще раз.
NoSQL — это именно декларация отказа от некоторых паттернов.
- От чего именно придется отказаться? Упомянутые паттерны так живучи совсем не случайно.
- Как это ударит по проекту? Не сомневайтесь, оно ударит, в этом мире нет ни серебряных пуль, ни бесплатного сыра.
- Какими свойствами должен обладать проект, чтобы внедрение NoSQL СУБД принесло ему пользу? Избегать NoSQL — это не трусость, это осторожность.
- Каковы сильные стороны NoSQL СУБД, и в чем профит? Выбор NoSQL — это всегда выбор в пользу меньшего зла.
- Как выбрать NoSQL СУБД под свою задачу? На http://nosql-database.org/ есть список LIST OF NOSQL DATABASES [currently >225], и даже просто прочесть его — тяжелая работа.
- Почему реальный выбор NoSQL СУБД — это выбор между Aerospike и Cassandra? Да, это провокационный вопрос, но на него есть not-so-provocative ответ.
- С какими проблемами сталкиваются разработчики и администраторы при эксплуатации "тяжелой" NoSQL базы? К сожалению, большая часть этих проблем создается именно присутствием NoSQL.
- Что можно делать с NoSQL СУБД и чего нельзя? На какие параметры производительности и отказоустойчивости можно рассчитывать? В чем особенности выбора "железа" для NoSQL?
- И в чем, все-таки, profit?
На эти и некоторые другие, связанные с этими, вопросы автор намерен дать ответ в своем докладе.
Использование Tarantool в качестве платформы виртуализации данных / Константи...Ontico
Инфраструктура хранения данных современного предприятия отражает историю развития бизнеса и индустрии и зачастую разнородна: проприетарные системы хранения и обработки данных, кэширующие системы, системы хранения данных для Интернет-сервисов.
Всё большее проникновение цифровых технологий в бизнес бросает вызов существующей IТ-инфраструктуре. Для сохранения имеющихся позиций на рынке необходимо обрабатывать всё большие объёмы всё быстрее меняющихся данных.
Проприетарные решения не отвечают этому вызову не только в технологической, но и в экономической составляющей: лицензионная политика, общая стоимость владения часто линейно зависят от объёма обрабатываемых данных, что является недопустимым в условиях шквального роста цифровой составляющей бизнеса.
Облачные решения недостаточно сформировались, с одной стороны, и ограничены в применении, с другой, особенно если речь идёт об обработке персональных данных, либо данных, имеющих жизненно
важное значение для бизнеса.
Единственным возможным на сегодняшний день ответом на вызов digital трансформации является внедрение решений с открытым исходным кодом.
В данном докладе будет изложен опыт такого внедрения в крупную компанию телекоммуникационной индустрии. Речь пойдёт о построении платформы виртуализации данных на основе решения Tarantool.
Преимуществами подхода виртуализации данных являются:
- безболезненная интеграция с существующей IТ-инфраструктурой, платформа может выступать в качестве высокопроизводительного "фасада" к существующим источникам данных;
- чрезвычайно высокая скорость работы с данными;
- возможность работать с данными, а не с ис
Dennis Anikin - Tarantool Case Studies in Mail.Ru GroupMail.ru Group
Денис рассказал о трех кейсах использования Tarantool в Mail.Ru Group - это система аутентификации пользователей, система нотификаций для мобильных приложений и система показа рекламы. Во всех трех кейсах Tarantool является краеугольным камнем распределенной серверной инфраструктуры, которая обслуживает суммарно порядка 100 миллионов пользователей в месяц.
This document contains messages from several fans expressing their love and admiration for country singer Kellie Pickler. The fans praise Kellie for her talent, down-to-earth personality, inspiring life story, and ability to make people smile with her unique and heartfelt music.
The news article discusses Sriviroj Farm No. 1, located in the northeast region of Thailand. It is one of the largest pig farms in the country, housing over 10,000 pigs. The farm uses advanced technology and management practices to raise the pigs in a sustainable and humane way.
Our core message is “joined up governance”. We are joining up project/portfolio governance with service delivery governance, financial governance, outsourcing governance and corporate governance within a single cloud-based system and SLAs, KPIs, actions, risks, issues, projects, financials, commercials, people’s opinions - all in one place at last. Drives ownership and accountability. Brilliant reports and even better context, perspective, accountability and audit trails across the big things you are managing.
The document is a news clipping from the Thai monthly magazine 'E-SURVEY' dated 30 April 2009 discussing e-commerce. It has a circulation of 85,000 and is located in Thailand.
This document discusses rubber and the rubber production process. It mentions key ingredients used to make rubber such as carbon black, zinc oxide, sulfur, and additives. It also discusses the vulcanization process where sulfur is added to create cross-linking between polymer chains, and how this process strengthens the rubber and improves its elasticity and durability. The document provides contact information for an organization that may be able to provide more details on rubber production and properties.
In 4 days in Madrid, the group of teachers, friends and students took an 8 hour bus ride from Vilalonga to Madrid, where they visited several popular attractions including the Prado Museum, a fairground, zoo and Retiro Park. They had a great time exploring the city.
The document summarizes Genares Worldwide Reservations services which include a central reservation system, connectivity to global distribution systems and online travel sites, a booking engine, voice reservation services, travel agent commission processing, and RFP and consortia programs. The goal is to provide exposure and maximize bookings for hotels through all distribution channels.
Путь от монолита на PHP к микросервисам на Scala / Денис Иванов (2GIS)Ontico
В своём проекте мы решали следующие задачи:
+ Скорость разработки задачи;
+ Стоимость поддержки задачи;
+ Возможность распараллеливать вычисления и задачи;
+ Возможность максимально просто масштабировать приложение;
+ CI/CD с минимальными усилиями.
Я расскажу о том, как мы решали эти задачи, на какие грабли мы наступали, что из этого всего получилось, и что делать дальше.
Что получили в итоге:
+ Мощь JVM под капотом Scala;
+ 15 минут от нажатия на кнопку "Merge request" до продакшена в 3 датацентра и 6 серверов с прохождением тестов (юнит + функциональные + интеграционные + нагрузочные);
+ 6 нод с приложениями вместо 18 (по 2 в каждом датацентре для отказоустойчивости) с запасом прочности в 60%;
+ Независимые пофичные релизы без даунтайма всех компонентов приложения;
+ Масштабирование только того функционала и в том количестве, которое необходимо данному сервису.
Дмитрий Лазаренко-«Живая миграция и отказоустойчивость контейнеров в гибридно...Tanya Denisyuk
"Контейнеры могут динамически появляться и исчезать, являются легковесными, не резервируют все необходимые ресурсы при старте, потому их оркестрация дается не простой ценой. Каждый из виртуальных контейнеров в один момент времени может потребовать максимум доступных ему ресурсов и это может привести к тому, что закончатся все ресурсы на физическом сервере, на котором они размещаются. В докладе мы поговорим о механизме, который решает эту непростую задачу, и умеет проводить непрерывную балансировку нагрузки, перемещать контейнеры с одного физического сервера на другие для проведения технических работ без простоя приложений - умная живая миграция (Smart Live Migration).
Многие считают, что контейнеры не подходят для хранения важных данных, т.к. в любой момент они могут упасть и все данные пропадут навсегда. Мы расскажем как этого избежать с помощью технологии Software-defined-storage."
Управление данными и защита от сбоев. Решения КРОК на основе продуктов COMMVAULTКРОК
Веб-семинар «Управление данными и защита от сбоев. Решения КРОК на основе продуктов CommVault».
Подробнее о мероприятии http://www.croc.ru/action/detail/1466/
Презентация Дениса Мурунова, Эксперта группы системных инженеров департамента информационных технологий КРОК
«Сетевые протоколы для веб разработчика — выжимаем максимум» Гузель Рахимова
Автор: Александр Сербул, руководитель направления контроля качества и внедрений компании "1С-Битрикс".
Pасскажет об эффективной работе с сетевыми технологиями (tcp/ip, dns, tls, spdy, websockets, long polling, http 2.0) при разработке
Компания "Ленвендо" занимается созданием, развитием и поддержкой крупномасштабных онлайн-проектов.
Сегодня «Ленвендо» отвечает за работу ресурсов «Эльдорадо», «Связной», HomeMe, Газпромбанк, Эхо Москвы в Петербурге.
Презентация технологии веб-кластеров
Основные задачи, которые решает веб-кластер:
Обеспечение высокой доступности сервиса (так называемые HA - High Availability или Failover кластеры)
Масштабирование веб-проекта в условиях возрастающей нагрузки (HP - High Performance кластеры)
Балансирование нагрузки, трафика, данных между несколькими серверами
Создание целостной резервной копии данных для MySQL
Презентация Владимира Храмцова к докладу про оптимизацию двух маленьких PHP проектов. Основыне тезисы: что происходит, когда увеличивается нагрузка, какие возникают проблемы и способы их решения.
Доклад от Parallels:
Методики тестировния производительности database-centric приложений
Описание: При работе над сложными продуктами в database-centric приложениях изменения в коде и тем более в SQL запросах к базе данных могут приводить к неожиданным падениям производительности или же деградации производительности приложения с ростом размера базы данных. Поэтому важно уметь как можно быстрее отлавливать и исправлять причины таких деградаций.
Доклад о том, как устроен процесс мониторинга производительности продукта автоматизации хостинга и облачных сервисов Parallels Automation, для которого определяющим фактором является производительность базы данных.
Компания покажет, как анализирует планы исполнения SQL запросов внутри PostgreSQL, как проверяет насколько быстро и эффективно в целом работают SQL запросы, как определяет стратегию дальнейшей оптимизации.
Основные кейсы использования in-memory СУБД на примере Тарантула и проектов M...Ontico
Основные кейсы использования Тарантула:
1. Когда нужна OLTP-система, позволяющая обрабатывать транзакции в режиме почти реального времени (с милисекундными задержками) и/или с огромной пропускной способностью (сотни тысяч запросов в секунду). Примеры — система сессий, система антибрутфорса, система противодействия атакам, система очередей и пуш-уведомлений, роутинг запросов между серверами.
Далее - http://backendconf.ru/2016/abstracts/2096.html
Tempesta FW: challenges, internals, use cases / Александр Крижановский (Tempe...Ontico
Tempesta FW — это Open Source гибрид Web-акселератора и файервола, специально разработанный для высокопроизводительной доставки контента вне зависимости от DDoS или наплыва посетителей.
В докладе будет рассказано про задачи, которые ставились при разработке проекта и пути их решения. Рассмотрим проблемы современных операционных систем в приложении к Web-стеку (система фильтрации, Web-сервер, application слой, БД), и как они решаются в Tempesta — некоторые уже решены, некоторые еще в процессе работы.
И самое главное — у нас появился рабочий прототип, и я расскажу про типовые примеры инсталляции, фичи и конфигурацию, а также покажу бенчмарки.
Maksym Bezuglyi "Universal highload patterns on a specific example of a game ...Fwdays
Analysis of the architecture of the game server on Haskell. From a high-level model to code features - transactional memory, immutable data structures, actors, queues, parallel and concurrent computing. The model of dynamic scaling, optimization, solved problems and trade-offs.
Reasons for choosing Haskell
What technologies were considered and why they were not used (no spoilers)
Full stack of used technologies and their highload potential
Universal design patterns
Similar to РИФ 2016, Tarantool – кейсы использования (20)
2. Что такое Tarantool?
• СУБД с сервером приложений
• Открытый исходный код
• Разрабатывается в Mail.Ru
• Существует с 2008 года
• Основное применение: высоконагруженные системы
• Настоящая СУБД с транзакциями, но быстрая как кэш!
5. Когда использовать Tarantool?
Отсутствуют свойства кэша
• Sub 1 ms latency
• 100K-300K QPS per one CPU core
• 100K updates per node
• Small number of nodes (money saver)
• Expiration
• Always up, no maintenance windows
• Optimized for heavy parallel workloads
СУБД
6. Когда использовать Tarantool?
Присутствуют свойства кэша!
• Sub 1 ms latency
• 100K-300K QPS per one CPU core
• 100K updates per node
• Small number of nodes (money saver)
• Expiration
• Always up, no maintenance windows
• Optimized for heavy parallel workloads
И свойства СУБД никуда не потерялись
TarantoolDB
DB
DB
DB
СУБД
7. Когда использовать Tarantool?
Cache
Отсутствуют свойства СУБД
• Persistence
• ACID Transactions
• Replication
• Stored procedures
• Tables, Indexes, Secondary indexes
• Cursors, range and full scan queries
8. Когда использовать Tarantool?
СУБД
Свойства СУБД
• Persistence
• ACID Transactions
• Replication
• Stored procedures
• Tables, Indexes, Secondary indexes
• Cursors, range and full scan queries
И все свойства кэша
Tarantool
10. Когда использовать Tarantool?
Database
Свойства СУБД
• Persistence
• ACID Transactions
• Replication
• Stored procedures
• Tables, Indexes, Secondary indexes
• Cursors, range and full scan queries
Cache
11. Когда использовать Tarantool?
Database
Cache Свойства кэша
• Sub 1 ms latency
• 100K-300K QPS per one CPU core
• 100K updates per node
• Small number of nodes (money saver)
• Expiration
• Always up, no maintenance windows
• Optimized for heavy parallel workloads
17. Кейсы использования
• Система аутентификации
• Система пуш уведомлений
• Система показа рекламы
• Видео проигрыватель
• Веб аналитика
• Хранилище сообщений мессенджеров
• Антиспам
• Замена memcached
• Система мониторинга
• Система рейтингов
• И многое другое …
18. Система аутентификации
• Востребованная (10-1M RPS) КЭШ
• Низкая latency (sub 1 ms) КЭШ
• Высокая доступность
• Постоянно ходит в хранилище КЭШ
• Anti brute-force/anti fraud
• Почти каждое обращение – это транзакция
• Много неизбежной лишней работы
• Большой размер данных
• Expiration КЭШ
• Persistence
19. Система аутентификации
• Востребованная (10-1M RPS)
• Низкая latency (sub 1 ms)
• Высокая доступность СУБД
• Постоянно ходит в хранилище
• Anti brute-force/anti fraud СУБД
• Почти каждое обращение – это транзакция СУБД
• Много неизбежной лишней работы
• Большой размер данных
• Expiration
• Persistence СУБД
32. Система показа рекламы
Web
server
Source
Of
data
10+ рекламных блоков
Web
server
Web
server
Ad
system
Source
Of
data
Source
Of
data
• На каждый блок из10+
• Лукапим источники данных
• Аггрегируем результат
• Понимаем, что показать
• Тратим несколько ms!
34. Вывод такой:
• вам нужно читать/писать горячие данные КЭШ
• с производительностью 100K QPS КЭШ
• параллельно КЭШ
• и вам нужно время ответа менее чем 1 мс КЭШ
• и 99.99% uptime СУБД
• и вы хотите выжать все соки из ваших серверов КЭШ
• при этом иметь транзакции, репликацию, persistence и
все другие свойства классических СУБД СУБД
• и все это в базе данных, которую легко
администрировать СУБД
If