Kafka в Авито постоянно развивается, и вот настало время начать жить на 3 ДЦ. Мы провели исследование различных топологий размещения кластеров, разных способов межкластерной репликации и реализовали итоговое решение. В докладе я расскажу, какие вызовы может встретить компания при использовании Kafka в нескольких ДЦ и как эти вызовы решили мы в Авито. Также пройдемся по возможностям Kafka (версия 2.4+) и технологиям из Kafka-экосистемы, помогающим организовать мультиДЦ-кластеры.

Расскажу об успешном внедрении bleeding edge-технологии автоматического мониторинга на основе Prometheus Operator.Prometheus Operator  – это "практически" коробочное решение, позволяющее покрыть большинство потребностей Experienced DevOps/SRE-аудитории.Позволяет исключить bottleneck в виде отдела Operationals, автоматизировать рутину мониторинга и уменьшить time to market бизнесовых метрик.Вы узнаете о возможности автоматического выкатывания метрик без участия админов. И если раньше от действия вас удерживал скепсис относительно большого пласта работ, то с новыми знаниями вы сможете практически безболезненно внедрить решение у себя.Что будет внутри? Разберем детали конструктивных особенностей современного инструментария мониторинга архитектуры решения, покрывающего все необходимые требования к мониторингу, которые выдвигают пользователи современных кластерных платформ конфигурирования и деплоймента оператора при помощи Ansible- / Helm-мониторинга инфраструктуры вне K8S ci/cd-практики для алертов и дашбордов.P.S.…

Митап для всех, кто заинтересован в надёжности и безопасности своих приложений, делает в этом направлении первые шаги или же просто смотрит в ту сторону

Мы используем распределенное хранилище Apache Ignite в продакшне, как следствие — предъявляем к нему высокие требования по надежности и доступности.Раньше в случае выхода узла из строя обработка поступающих операций приостанавливалась на продолжительный период времени, до десятков секунд в некоторых кейсах. Простои такой длительности недопустимы для наших сервисов, поэтому процедура восстановления в Apache Ignite была мною доработана. Расскажу о том, как было, что изменилось и что еще предстоит сделать. В докладе рассмотрим:- гарантии сохранности данных в распределенных хранилищах,- партиционирование и ребалансировку данных,- разницу между кластером, кэшом и партицией,- типы распределенных кэшей, типы партиций,- механизмы, позволяющие кластеру сохранять работоспособность при смене топологии (входе и выходе узлов),- механизмы обеспечения консистентности данных при смене топологии,- "трюки", позволяющие минимизировать время простоя при смене топологии,- как мы проверяем эффективность оптимизаций, разрабатываемых…

Дмитрий Калугин-Балашов большую часть своей жизни писал поиск: с 2011 года в компании Mail.ru был поиск по почте, затем был небольшой перерыв из-за работы в США,...

Аналитические платформы обрабатывают все больше данных, и все чаще возникает вопрос об их производительности. У каждой платформы есть свои методы и приемы по оптимизации, но для создания действительно высокопроизводительной системы мы должны иметь глубокое понимание всех составляющих элементов платформы и потоков данных. Одной из наиболее дорогостоящих операций в системе доставки данных является работа с файловой системой, её и нужно оптимизировать. Прямая работа с диском при файловом I/O — не самая дешевая операция и современные ОС применяют различные оптимизации, такие как кэширование и readahead, чтобы уменьшить ее влияние на производительность. В некоторых случаях обращений к диску можно почти полностью избежать, читая большую часть данных из кэша. В докладе мы рассмотрим методы оптимизации I/O в JVM и копирования памяти в ядре Linux и как это позволяет увеличить пропускную способность передачи данных на 20%.

Наши друзья из e-legion cоздают успешные цифровые продукты для крупного бизнеса с 2005 года.https://www.e-legion.ru/Чат подкаста в Телеграме — https://t.me/m...

- Математика прогнозирования сложных зависимостей временных рядов;- эффективные архитектуры для прогнозирования временных рядов;- ансамблирование подходов в прогнозе временных рядов;- инфраструктура автоматического решения в облаке.Презентация - https://docs.google.com/presentation/d/1amBu57gzR4z7vqfHUXB_umTpH9hPycQcg3_glON91EI/edit?usp=sharing

Мы вывернем финтех-компанию наизнанку и посмотрим туда, куда смотреть неприятно. Разберем проблемы инцидент-менеджмента на составляющие и поймем, как оптимиз...

Apache Airflow широко используется для оркестрации ETL data-пайплайнов.Давайте более детально взглянем на Airflow с точки зрения разработки и эксплуатации: какие особенности помогут избежать проблем, а какие могут потенциально привести к отказу работы распределенных систем.Кроме того, обсудим:- Какие есть альтернативы и почему именно Airflow?- Как выглядит типичный Airflow pipeline и какую функциональность предоставляет?- С какими трудностями предстоит столкнуться при разработке?- Можно ли иметь гибкую оркестрацию as a code, с тестами, CI/CD и документацией?- Способы мониторинга и восстановления после отказов.- Как можно упростить процесс поддержки кода?- Интеграция с облачными сервисами и внешними системами: стоит ли пробовать?

Митап для тех, кому интересно узнать о перспективах и трендах stateful

Опять боль и страдания!!! Внедряя NoOps в большой компании, я услышал много разного — от простых эмоций:  - Да вы теперь просто операторы приватного облака!..  - У нас кончилось админство в компании!!!  - А что я теперь и в мидлваре должен разбираться?..до вполне интересных вопросов:  - Оптимизацией СУБД кто теперь занимается?  - Кто отвечает за бэкап?  - А кто теперь отвечает за инциденты?Есть, безусловно, полезные вещи, которые очень трудно оспорить, например, автоматизация запросов на обслуживание (любые действия, имеющие обкатанный скрипт исполнения), где вы интегрируете свою инфраструктуру с роботами и нет больше лагов и ошибок при исполнении. Все "энтерпрайз-вахтёры" (политики и регламенты безопасности) тоже эффективно автоматизируются, и самое прикольное тут, что никто вам даже спасибо не скажет, все привыкнут к хорошему через неделю, даже не вспомнят, что может быть по-другому. Самое тонкое место — это передача компетенций, как быть Томом Сойером, а не "вертухаем", заставляющим делать «чужую» работу.…

Митап для тех, кому интересно узнать о перспективах и трендах stateful

Митап для тех, кому интересно узнать о перспективах и трендах stateful

Для разработчиков, которые уже размещают свои приложения в SmartMarket, а также для тех, кто только знакомится с платформой.

Для разработчиков, которые уже размещают свои приложения в SmartMarket, а также для тех, кто только знакомится с платформой.

Практический опыт создания и эволюции одного из крупнейших в России Озера Данных.  Задачи, которые приходится решать, и как удается совмещать технические желания и бизнес-рационализм. Как совместить классические и более современные подходы к архитектуре данных с  Hadoop-экосистемой, концептуальная архитектура данных — современные подходы, в чем разница концепций Data Lake и Data Mesh.

Два года назад мы (компания Scentbird), пережив серьезный рост, решили строить свою систему аналитики для обеспечения необходимой гибкости. Мы постоянно совершенствуемся в этом направлении, и самым качественным изменением в нашей архитектуре за последнее время стал переход от ETL к ELT-концепции посредством инструмента DBT. Это позволило нам сосредоточится на бизнес-смысле перевозимых данных, вместо технических особенностей процесса трансформации данных.В отведенные 45 минут обсудим:- отличия концепции ETL и ELT на примере нашего стека технологий;- базовые концепции инструмента для преобразования данных DBT;- как мы используем DBT для построения сложных моделей, а также осуществляем тестирование данных;- как масштабируется такое решение.

Бизнес-модели клиентов создают разные сценарии использования продукта и разные профили нагрузки. Подготовить под каждого индивидуальную тестовую среду невозможно и не имеет смысла. Достаточно создать усредненный вариант и покрыть там самые популярные кейсы использования платформы. Расскажу, как был написан PoC Tester — фреймворк для описания логики работы клиентских узлов, которые симулируют реальную нагрузку на тестовый кластер — и какие задачи пришлось решить в процессе: * как оптимально сконфигурировать тестовый стенд по количеству узлов;* как добавить в один тестовый сценарий наибольшее количество пользовательских кейсов;* какие внешние воздействия можно внедрить в сценарий для проверки надежности и устойчивости кластера при возникновении нештатных ситуаций;* как после прогона настолько сложного сценария понять, что он успешен.