Построение приложения с помощью архитектуры микросервисов. Плюсы и минусы применения на практике на примере реального проекта.
Презентация подготовлена по материалам выступления Виталия Квятковского на витебской конференции “Developer's Software Conference” (31.10.2015). Запись выступления: https://events.epam.com/events/dsc2015/talks/102.
Мастер-класс "Микросервисы: удобно, надежно, серебрянопульно" / Евгений Павло...Ontico
В процессе рефакторинга архитектуры мы начали переделывать часть системы на микросервисы, и вышло настолько клево, что мы просто обязаны этим поделиться.
Микросервисы.
Зачем они вообще:
- В простых сервисах легче разбираться и локализовывать проблемы.
- В микросервисной архитектуре проще добиваться отказоустойчивости.
- Хотим выбирать лучший инструмент для каждой задачи. Получаем зоопарк технологий, которые в монолитные сервисы интегрировать сложнее.
- Независимое обновление компонентов.
- Тестирование частей системы.
Как:
- Docker-образы как основа.
- Rancher как система деплоя и оркестрации Docker-контейнеров. High availability.
- Простота сервиса - ключевой момент.
== Критерий: Разработчик должен иметь возможность быстро понять и переписать сервис при необходимости.
== Забавное следствие: такие сервисы пишутся не на века, а под текущие требования. Получается быстро и agile-но, ведь изменения легко сможет внести любой разработчик.
== PEP8.
- HTTP API и поддержка Swagger. Резко упрощают тестирование.
- RabbitMQ pipelines как отказоустойчивая система взаимодействий между сервисами:
== DLX помогает разбираться со врЕменными проблемами.
== HTTP RPC.
- Метрики, метрики и ещё раз метрики.
== service status API.
== Graphite, Zabbix. Может, к ноябрю еще OKmeter успеем попробовать.
- Структурированые логи: JSON stdout => Fluentd => ELK => счастье. Локализация багов и пр. Об этом подробнее в отдельной презентации.
- В любой непонятной ситуации...
== Сервис должен падать, а не зависать.
== Healthchecks.
- Стабильность архитектуры.
== Осознанная деградация! Любой сервис должен быть готов к падению другого. При этом в первом должно быть явно описано, как будет при этом ограничиваться его функциональность. Это ведет к отсутствию эффекта домино, когда один малозначащий сервис, упав, утягивает за собой всю систему.
- Документация.
== Степень критичности каждого сервиса.
== Краткий обзор функциональности (вспоминаем: сервисы _простые_).
== Конфиги.
== drawback: описание архитектуры обязано быть актуальным и полным, иначе беда.
Трудности: Допишу через пару дней.
Инфраструктура распределенных приложений на nodejs / Станислав Гуменюк (Rambl...Ontico
Мы создаем nodejs приложения, используя различные современные технологии, такие как Docker, Consul, pm2. Современный спектр решений настолько обширен, что сложно не заблудиться. Как же выбрать нужные вашему проекту технологии, чтобы успешно его запустить и поддерживать? Будут рассказаны истории и, конечно же, даны вредные советы :)
Как на nodejs пройти путь от Hello world приложения до распределённого решения, состоящего из микросервисов?
Мы пройдём жизненный цикл продукта, начав с простого приложения на nodejs. Научимся его правильно запускать и будем постепенно добавлять элементы, убирая при этом ненужные. Так к нашему приложению присоединится гипервизор, а само оно будет разделено на части, где каждая сущность будет управлять своей частью приложения.
Построив таким образом архитектуру на чистом nodejs, мы займёмся развитием приложения, добавим современные технологии и применим новые подходы к организации инфраструктуры. Запакуем приложение в Docker, попутно обсудим, зачем он нужен и что может дать. И, наконец, решим проблему поиска запущенных сервисов и отслеживания их статусов, используя Consul.
Amazon SQS или не все костыли одинаково бесполезныVitebsk DSC
Общий экскурс в чудесный мир AWS. Рассказ о Amazon SQS и о том как его правильно готовить.
Краткое описание подводных камней с которыми можно столкнуться и способы их решения.
Презентация подготовлена по материалам выступления Анатолия Таразевича на витебской конференции “Developer's Software Conference” (30.11.2019).
Microsoft и Linux на одном проекте: как получить лучшее из обоих миров и не р...Ontico
2-3 года назад у нас был на 100% MS стек (Винда, Hyper-V, MSSQL, IIS, C#, WCF, Azure), и было не очень понятно, как продукт дальше развивать: C#, конечно, неплохой язык, но оставаться в рамках MS - слишком большие ограничения по выбору продуктов: чего-то на винде до сих пор нет (например, Докера), а для многих серверных продуктов рынок винды вторичен.
Получалось, что все понимают тупиковость ситуации, но продолжают тащить этот чемодан без ручки, потому что делать-то что-то надо. Переписать весь проект с нуля под новые технологии - это год работы вхолостую для бизнеса, и ни один инвестор в мире на такое не согласился бы.
Так вот, могу рассказать, как нам удалось постепенно выйти из этого тупика без остановки бизнес-девелопмента и переобучения всей команды на другой язык/платформу.
Сейчас у нас диверсифицированная система:
- виртуалки на винде и убунте. HA организуется силами Hyper-V и Rancher;
- несколько разных стораджей: Cassandra, Redis, MS SQL, PostgreSQL и Spark, который из всего этого зоопарка делает общую аналитику (нет, мы не ставили все подряд, они все нужны, зачем - расскажу);
- сервисы на C# и питоне, которые прекрасно общаются по общей шине и мы спокойно можем ждать выхода полноценного .net core еще пару лет.
И, предваряя вопрос - нет, на Mono или текущий .NET core без серьезного переписывания перейти зачастую нельзя. Мы - как раз тот случай.
Построение приложения с помощью архитектуры микросервисов. Плюсы и минусы применения на практике на примере реального проекта.
Презентация подготовлена по материалам выступления Виталия Квятковского на витебской конференции “Developer's Software Conference” (31.10.2015). Запись выступления: https://events.epam.com/events/dsc2015/talks/102.
Мастер-класс "Микросервисы: удобно, надежно, серебрянопульно" / Евгений Павло...Ontico
В процессе рефакторинга архитектуры мы начали переделывать часть системы на микросервисы, и вышло настолько клево, что мы просто обязаны этим поделиться.
Микросервисы.
Зачем они вообще:
- В простых сервисах легче разбираться и локализовывать проблемы.
- В микросервисной архитектуре проще добиваться отказоустойчивости.
- Хотим выбирать лучший инструмент для каждой задачи. Получаем зоопарк технологий, которые в монолитные сервисы интегрировать сложнее.
- Независимое обновление компонентов.
- Тестирование частей системы.
Как:
- Docker-образы как основа.
- Rancher как система деплоя и оркестрации Docker-контейнеров. High availability.
- Простота сервиса - ключевой момент.
== Критерий: Разработчик должен иметь возможность быстро понять и переписать сервис при необходимости.
== Забавное следствие: такие сервисы пишутся не на века, а под текущие требования. Получается быстро и agile-но, ведь изменения легко сможет внести любой разработчик.
== PEP8.
- HTTP API и поддержка Swagger. Резко упрощают тестирование.
- RabbitMQ pipelines как отказоустойчивая система взаимодействий между сервисами:
== DLX помогает разбираться со врЕменными проблемами.
== HTTP RPC.
- Метрики, метрики и ещё раз метрики.
== service status API.
== Graphite, Zabbix. Может, к ноябрю еще OKmeter успеем попробовать.
- Структурированые логи: JSON stdout => Fluentd => ELK => счастье. Локализация багов и пр. Об этом подробнее в отдельной презентации.
- В любой непонятной ситуации...
== Сервис должен падать, а не зависать.
== Healthchecks.
- Стабильность архитектуры.
== Осознанная деградация! Любой сервис должен быть готов к падению другого. При этом в первом должно быть явно описано, как будет при этом ограничиваться его функциональность. Это ведет к отсутствию эффекта домино, когда один малозначащий сервис, упав, утягивает за собой всю систему.
- Документация.
== Степень критичности каждого сервиса.
== Краткий обзор функциональности (вспоминаем: сервисы _простые_).
== Конфиги.
== drawback: описание архитектуры обязано быть актуальным и полным, иначе беда.
Трудности: Допишу через пару дней.
Инфраструктура распределенных приложений на nodejs / Станислав Гуменюк (Rambl...Ontico
Мы создаем nodejs приложения, используя различные современные технологии, такие как Docker, Consul, pm2. Современный спектр решений настолько обширен, что сложно не заблудиться. Как же выбрать нужные вашему проекту технологии, чтобы успешно его запустить и поддерживать? Будут рассказаны истории и, конечно же, даны вредные советы :)
Как на nodejs пройти путь от Hello world приложения до распределённого решения, состоящего из микросервисов?
Мы пройдём жизненный цикл продукта, начав с простого приложения на nodejs. Научимся его правильно запускать и будем постепенно добавлять элементы, убирая при этом ненужные. Так к нашему приложению присоединится гипервизор, а само оно будет разделено на части, где каждая сущность будет управлять своей частью приложения.
Построив таким образом архитектуру на чистом nodejs, мы займёмся развитием приложения, добавим современные технологии и применим новые подходы к организации инфраструктуры. Запакуем приложение в Docker, попутно обсудим, зачем он нужен и что может дать. И, наконец, решим проблему поиска запущенных сервисов и отслеживания их статусов, используя Consul.
Amazon SQS или не все костыли одинаково бесполезныVitebsk DSC
Общий экскурс в чудесный мир AWS. Рассказ о Amazon SQS и о том как его правильно готовить.
Краткое описание подводных камней с которыми можно столкнуться и способы их решения.
Презентация подготовлена по материалам выступления Анатолия Таразевича на витебской конференции “Developer's Software Conference” (30.11.2019).
Microsoft и Linux на одном проекте: как получить лучшее из обоих миров и не р...Ontico
2-3 года назад у нас был на 100% MS стек (Винда, Hyper-V, MSSQL, IIS, C#, WCF, Azure), и было не очень понятно, как продукт дальше развивать: C#, конечно, неплохой язык, но оставаться в рамках MS - слишком большие ограничения по выбору продуктов: чего-то на винде до сих пор нет (например, Докера), а для многих серверных продуктов рынок винды вторичен.
Получалось, что все понимают тупиковость ситуации, но продолжают тащить этот чемодан без ручки, потому что делать-то что-то надо. Переписать весь проект с нуля под новые технологии - это год работы вхолостую для бизнеса, и ни один инвестор в мире на такое не согласился бы.
Так вот, могу рассказать, как нам удалось постепенно выйти из этого тупика без остановки бизнес-девелопмента и переобучения всей команды на другой язык/платформу.
Сейчас у нас диверсифицированная система:
- виртуалки на винде и убунте. HA организуется силами Hyper-V и Rancher;
- несколько разных стораджей: Cassandra, Redis, MS SQL, PostgreSQL и Spark, который из всего этого зоопарка делает общую аналитику (нет, мы не ставили все подряд, они все нужны, зачем - расскажу);
- сервисы на C# и питоне, которые прекрасно общаются по общей шине и мы спокойно можем ждать выхода полноценного .net core еще пару лет.
И, предваряя вопрос - нет, на Mono или текущий .NET core без серьезного переписывания перейти зачастую нельзя. Мы - как раз тот случай.
Преждевременная оптимизация архитектуры / Евгений Потапов, Антон Баранов (ITS...Ontico
Работа в высоконагруженных проектах всегда была такой сферой деятельности, где можно в рамках решения прикладных задач находить и применять сложные и интересные решения.
К сожалению, очень часто во главу угла ставится не надежное решение поставленной задачи, а именно применение сложного и интересного решения, которое даст специалисту новый опыт и удовольствие от сложных архитектур.
В своем докладе я хочу пройтись по тем стандартным "набитым шишкам", которые мы встречаем в своей работе, когда сложное, новое и интересное решение не означает стабильность системы.
1. Когда "интересно" не значит "правильно"?
1.1. Специфика развития высоконагруженного проекта.
1.2. Требования бизнеса и современные технологии.
1.3. Типичные "сомнительные" решения.
2. Проблемы в архитектуре отказоустойчивых систем.
2.1. Ошибки в планировании резервирования.
2.2. Ошибки в планировании системы выкладок.
2.3. Ошибки в архитектурах систем хранения данных.
3. Проблемы в архитектуре систем, рассчитанных на высокую нагрузку.
3.1. Ошибки в планировании мощностей системы.
3.2. Ошибки в планировании возможностей масштабирования системы.
3.3. Ошибки в архитектурах систем хранения данных.
Велосипед уже изобретен. Что умеют промышленные СХД? / Антон Жбанков (Nutanix)Ontico
Зачем мы каждый раз изобретаем велосипед, только потому что можем? Корпоративные СХД существуют более 25 лет и умеют очень многое.
Защита данных, качество обслуживания, многоуровневое хранение и кэширование на флэш-памяти. Система хранения данных - это не только гигабайт по минимальной цене, но так же и гарантированная производительность и отказоустойчивость.
Вы узнаете, как можно обеспечить своим данным высокую степень защиты, значительно сократив время реализации проекта. Или, наоборот, убедитесь в том, что СХД корпоративного класса вашему проекту не подходят.
Промышленное ускорение сайтов / Николай Мациевский (Айри.рф)Ontico
Идея: обеспечить реально высокую скорость загрузки нагруженного сайта (от 100 тысяч посетителей в день) для всех пользователей, ничего не сломав и уложившись в бюджет.
Введение. Подходы к оптимизации фронтенда:
* Классический: делаем по GPSI или WPT.
* Самостоятельный: прикрутили PageSpeed и CDN.
* Промышленный: PDSA (попробовали, измерили, внедрили, подсчитали).
* Кейс: открытие новостного сайта за 1 секунду на любом устройстве.
Часть 1. Мониторинг клиентской производительности
* Google Analytics / Яндекс.Метрика / Битрикс.
* New Relic / mPulse / Айри / Navigation Timing API.
* Resource Timing API / User Timing Api: собственные метрики.
* Кейс: как понять из метрик сайта, что и где тормозит.
Часть 2. Внедрение ускорения
* Как выбрать KPI скорости сайта.
* Базовые правила: как автоматизировать, внедрить, раскатать.
* "Бюджет" на ускорение страницы: как распределить.
* Поточное и отложенное ускорение: как выбрать.
* Некоторые типичные ошибки "оптимизации".
* Кейс: нестандартные подходы к оптимизации производительности.
Часть 3. Узкое профилирование
* Тестируем CDN: что смотрим, как измеряем.
* Тестируем мобильные устройства: тормозит CPU или GPRS ?
* Тестируем асинхронную загрузку: подводные камни.
* Кейс: сколько "стоит" ошибка в клиентской производительности.
Заключение. Промышленное внедрение
* Кейс: "швейцарский нож" для оптимизации изображений.
* Кейс: когда реально работает отложенная загрузка.
* Кейс: HTTP/2. Реальные данные.
* Кейс: как ускорить 2000 ресурсов в секунду?
MySQL® и MongoDB® - когда что лучше использовать? / Петр Зайцев (Percona)Ontico
Сегодня много дискуссий о том, что лучше - MySQL или PostgreSQL? Однако перед тем, как выбирать именно реляционную базу данных для своего проекта, стоит понять, является ли реляционная база данных наилучшим решением для него.
В рамках этого доклада мы сравним наиболее популярную реляционную базу данных с открытым кодом с наиболее популярным хранилищем документов с открытым кодом. Мы определим, в каких случаях эффективнее всего работает MySQL, а в каких - MongoDB. Мы также рассмотрим ситуации, в которых ни одна из этих баз данных не будет лучшим решением и в которых целесообразно остановить свой выбор на других технологиях.
Преждевременная оптимизация архитектуры / Евгений Потапов, Антон Баранов (ITS...Ontico
Работа в высоконагруженных проектах всегда была такой сферой деятельности, где можно в рамках решения прикладных задач находить и применять сложные и интересные решения.
К сожалению, очень часто во главу угла ставится не надежное решение поставленной задачи, а именно применение сложного и интересного решения, которое даст специалисту новый опыт и удовольствие от сложных архитектур.
В своем докладе я хочу пройтись по тем стандартным "набитым шишкам", которые мы встречаем в своей работе, когда сложное, новое и интересное решение не означает стабильность системы.
1. Когда "интересно" не значит "правильно"?
1.1. Специфика развития высоконагруженного проекта.
1.2. Требования бизнеса и современные технологии.
1.3. Типичные "сомнительные" решения.
2. Проблемы в архитектуре отказоустойчивых систем.
2.1. Ошибки в планировании резервирования.
2.2. Ошибки в планировании системы выкладок.
2.3. Ошибки в архитектурах систем хранения данных.
3. Проблемы в архитектуре систем, рассчитанных на высокую нагрузку.
3.1. Ошибки в планировании мощностей системы.
3.2. Ошибки в планировании возможностей масштабирования системы.
3.3. Ошибки в архитектурах систем хранения данных.
Велосипед уже изобретен. Что умеют промышленные СХД? / Антон Жбанков (Nutanix)Ontico
Зачем мы каждый раз изобретаем велосипед, только потому что можем? Корпоративные СХД существуют более 25 лет и умеют очень многое.
Защита данных, качество обслуживания, многоуровневое хранение и кэширование на флэш-памяти. Система хранения данных - это не только гигабайт по минимальной цене, но так же и гарантированная производительность и отказоустойчивость.
Вы узнаете, как можно обеспечить своим данным высокую степень защиты, значительно сократив время реализации проекта. Или, наоборот, убедитесь в том, что СХД корпоративного класса вашему проекту не подходят.
Промышленное ускорение сайтов / Николай Мациевский (Айри.рф)Ontico
Идея: обеспечить реально высокую скорость загрузки нагруженного сайта (от 100 тысяч посетителей в день) для всех пользователей, ничего не сломав и уложившись в бюджет.
Введение. Подходы к оптимизации фронтенда:
* Классический: делаем по GPSI или WPT.
* Самостоятельный: прикрутили PageSpeed и CDN.
* Промышленный: PDSA (попробовали, измерили, внедрили, подсчитали).
* Кейс: открытие новостного сайта за 1 секунду на любом устройстве.
Часть 1. Мониторинг клиентской производительности
* Google Analytics / Яндекс.Метрика / Битрикс.
* New Relic / mPulse / Айри / Navigation Timing API.
* Resource Timing API / User Timing Api: собственные метрики.
* Кейс: как понять из метрик сайта, что и где тормозит.
Часть 2. Внедрение ускорения
* Как выбрать KPI скорости сайта.
* Базовые правила: как автоматизировать, внедрить, раскатать.
* "Бюджет" на ускорение страницы: как распределить.
* Поточное и отложенное ускорение: как выбрать.
* Некоторые типичные ошибки "оптимизации".
* Кейс: нестандартные подходы к оптимизации производительности.
Часть 3. Узкое профилирование
* Тестируем CDN: что смотрим, как измеряем.
* Тестируем мобильные устройства: тормозит CPU или GPRS ?
* Тестируем асинхронную загрузку: подводные камни.
* Кейс: сколько "стоит" ошибка в клиентской производительности.
Заключение. Промышленное внедрение
* Кейс: "швейцарский нож" для оптимизации изображений.
* Кейс: когда реально работает отложенная загрузка.
* Кейс: HTTP/2. Реальные данные.
* Кейс: как ускорить 2000 ресурсов в секунду?
MySQL® и MongoDB® - когда что лучше использовать? / Петр Зайцев (Percona)Ontico
Сегодня много дискуссий о том, что лучше - MySQL или PostgreSQL? Однако перед тем, как выбирать именно реляционную базу данных для своего проекта, стоит понять, является ли реляционная база данных наилучшим решением для него.
В рамках этого доклада мы сравним наиболее популярную реляционную базу данных с открытым кодом с наиболее популярным хранилищем документов с открытым кодом. Мы определим, в каких случаях эффективнее всего работает MySQL, а в каких - MongoDB. Мы также рассмотрим ситуации, в которых ни одна из этих баз данных не будет лучшим решением и в которых целесообразно остановить свой выбор на других технологиях.
(2 часть) 1С-Битрикс. Производительность проекта. Архитектура проекта «Битрик...ForkConf
Сергей Рыжиков. Директор "1С-Битрикс". Нагруженный Форк. Производительность проекта. Архитектура проекта «Битрикс24»: как сделать так, чтобы все летало и не падало, master-master, мастер мастер
Облако Microsoft Azure - введение в основные сервисы для разработки и инфраст...Microsoft
Введение в основные сервисы для разработки и инфраструктуры для быстрого старта проекта.
Веб-разработка
Мобильная разработка
Очереди
Traffic Manager
IoT
Azure CLI
Облачные сервисы Майкрософт для мобильных приложений. Application Insights и ...Microsoft
В этом докладе рассказано про несколько полезных облачных сервисов, которые вы можете использовать для сбора, аналитики и взаимодействия с вашими пользователями на различных платформах и с большим количеством возможностей по таргетированию.
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...Ontico
HighLoad++ 2017
Зал «Калининград», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2964.html
Одноклассники состоят из более чем восьми тысяч железных серверов, расположенных в нескольких дата-центрах. Каждая из этих машин была специализированной под конкретную задачу - как для обеспечения изоляции отказов, так и для обеспечения автоматизированного управления инфраструктурой.
...
Масштабируя DNS / Артем Гавриченков (Qrator Labs)Ontico
HighLoad++ 2017
Зал «Калининград», 8 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/3032.html
Протокол DNS на семь лет старше, чем Всемирная паутина. Стандарты RFC 882 и 883, определяющие основную функциональность системы доменных имён, появились в конце 1983 года, а первая реализация последовала уже годом позже. Естественно, что у технологии столь старой и при этом по сей день активнейшим образом используемой просто не могли не накопиться особенности, неочевидные обыкновенным пользователям.
...
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)Ontico
HighLoad++ 2017
Зал «Калининград», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/3010.html
В этом докладе я расскажу, как BigData-платформа помогает трансформировать Почту России, как мы управляем построением и развитием платформы. Расскажу про найденные удачные решения, например, как разбиение на продукты с понятными SLA и интерфейсами между ними помогло нам сохранять управляемость с ростом масштабов проекта.
...
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 10:00
Тезисы:
http://www.highload.ru/2017/abstracts/2914.html
Казалось бы, что нужно для организации тестового окружения? Тестовая железка и копия боевого окружения - и тестовый сервер готов. Но как быть, когда проект сложный? А когда большой? А если нужно тестировать одновременно много версий? А если все это вместе?
Организация тестирования большого развивающегося проекта, где одновременно в разработке и тестировании около полусотни фич - достаточно непростая задача. Ситуация обычно осложняется тем, что иногда есть желание потрогать еще не полностью готовый функционал. В таких ситуациях часто возникает вопрос: "А куда это можно накатить и где покликать?"
...
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2854.html
Из этого доклада вы узнаете о возможностях репликации и автофейловера PostgreSQL, в том числе о возможностях, ставших доступных в PostgreSQL 10.
Среди прочих, будет затронуты следующие темы:
* Виды репликации и решаемые с ее помощью проблемы.
* Настройка потоковой репликации.
* Настройка логической репликации.
* Настройка автофейловера / HA средствами Stolon и Consul.
После прослушивания доклада вы сможете самостоятельно настраивать репликацию и автофейловер PostgreSQL.
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 17:00
Тезисы:
http://www.highload.ru/2017/abstracts/3096.html
PostgreSQL is the world’s most advanced open source database. Indeed! With around 270 configuration parameters in postgresql.conf, plus all the knobs in pg_hba.conf, it is definitely ADVANCED!
How many parameters do you tune? 1? 8? 32? Anyone ever tuned more than 64?
No tuning means below par performance. But how to start? Which parameters to tune? What are the appropriate values? Is there a tool --not just an editor like vim or emacs-- to help users manage the 700-line postgresql.conf file?
Join this talk to understand the performance advantages of appropriately tuning your postgresql.conf file, showcase a new free tool to make PostgreSQL configuration possible for HUMANS, and learn the best practices for tuning several relevant postgresql.conf parameters.
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/3115.html
During this session we will cover the last development in ProxySQL to support regular expressions (RE2 and PCRE) and how we can use this strong technique in correlation with ProxySQL's query rules to anonymize live data quickly and transparently. We will explain the mechanism and how to generate these rules quickly. We show live demo with all challenges we got from the Community and we finish the session by an interactive brainstorm testing queries from the audience.
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2957.html
Расскажем о нашем опыте разработки модуля межсетевого экрана для MySQL с использованием генератора парсеров ANTLR и языка Kotlin.
Подробно рассмотрим следующие вопросы:
— когда и почему целесообразно использовать ANTLR;
— особенности разработки ANTLR-грамматики для MySQL;
— сравнение производительности рантаймов для ANTLR в рамках задачи синтаксического анализа MySQL (C#, Java, Kotlin, Go, Python, PyPy, C++);
— вспомогательные DSL;
— микросервисная архитектура модуля экранирования SQL;
— полученные результаты.
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/3114.html
ProxySQL aims to be the most powerful proxy in the MySQL ecosystem. It is protocol-aware and able to provide high availability (HA) and high performance with no changes in the application, using several built-in features and integration with clustering software. During this session we will quickly introduce its main features, so to better understand how it works. We will then describe multiple use case scenarios in which ProxySQL empowers large MySQL installations to provide HA with zero downtime, read/write split, query rewrite, sharding, query caching, and multiplexing using SSL across data centers.
MySQL Replication — Advanced Features / Петр Зайцев (Percona)Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2954.html
MySQL Replication is powerful and has added a lot of advanced features through the years. In this presentation we will look into replication technology in MySQL 5.7 and variants focusing on advanced features, what do they mean, when to use them and when not, Including.
When should you use STATEMENT, ROW or MIXED binary log format?
What is GTID in MySQL and MariaDB and why do you want to use them?
What is semi-sync replication and how is it different from lossless semi-sync?
...
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 12:00
Тезисы:
http://www.highload.ru/2017/abstracts/3120.html
Количество разработчиков мобильных приложений Сбербанк Онлайн с начала 2016 года выросло на порядок. Для того чтобы продолжать выпускать качественный продукт, мы кардинально перестраиваем процесс разработки.
Количество внутренних заказчиков тех или иных доработок в какой-то момент выросло настолько, что разработчики стали узким местом. Мы внедрили культуру разработки, которую можно условно назвать "внутренним open-source", сохранив за собой контроль над архитектурой и качеством проекта, но позволив разрабатывать новые фичи всем желающим.
...
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2836.html
При использовании Eventually Consistent распределенных баз данных нет гарантий, что чтение возвращает результаты последних изменений данных, если чтение и запись производятся на разных узлах. Это ограничивает пропускную способность системы. Поддержка свойства Causal Consistency снимает это ограничение, что позволяет улучшить масштабируемость, не требуя изменений в коде приложения.
...
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/2858.html
Аудитория Одноклассников превышает 73 миллиона человек в России, СНГ и странах дальнего зарубежья. При этом ОК.ru - первая социальная сеть по просмотрам видео в рунете и крупнейшая сервисная платформа.
Качественный и количественный рост DDoS-атак за последние годы превращает их в одну из первоочередных проблем для крупнейших интернет-ресурсов. В зависимости от вектора атаки “узким” местом становится та или иная часть инфраструктуры. В частности, при SYN-flood первый удар приходится на систему балансировки трафика. От ее производительности зависит успех в противостоянии атаке.
...
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/3008.html
Никогда не было и вот снова случилось! Компания Google в результате перенаправления трафика сделала недостпуными в Японии несколько тысяч различных сервисов, большинство из которых никак не связано с самой компанией Google. Однако, подобные инциденты происходят с завидной регулярностью, вот только не всегда попадают в большие СМИ. У таких инцидентов могут быть разные причины, начиная от ошибок сетевых инженеров и заканчивая государственным регулированием.
...
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/2925.html
Облака и виртуализация – современные тренды развития IT-технологий. Операторы связи строят свои TelcoClouds на стандартах NFV (Network Functions Virtualization) и SDN (Software-Defined Networking). В докладе начнем с основ виртуализации, далее разберемся, для чего используются NFV и SDN, потом полетим к облакам и вернемся на землю для решения практических задач!
...
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 10:00
Тезисы:
http://www.highload.ru/2017/abstracts/3045.html
Как мы заставили Druid работать в Одноклассниках.
«Druid is a high-performance, column-oriented, distributed data store» http://druid.io.
Мы расскажем о том, как, внедрив Druid, мы справились с ситуацией, когда MSSQL-based система статистики на 50 терабайт стала:
- медленной: средняя скорость ответа была в разы меньше требуемой (и увеличилась в 20 раз);
- нестабильной: в час пик статистика отставала до получаса (теперь ничего не отстает);
- дорогой: изменилась политика лицензирования Microsoft, расходы на лицензии могли составить миллионы долларов.
...
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2905.html
Прошло более года с того момента, как Microsoft выпустила первую версию своего нового фреймворка для разработки web-приложений ASP.NET Core, и с каждым днем он находит все больше поклонников. ASP.NET Core базируется на платформе .NET Core, кроссплатформенной версии платформы .NET c открытым исходным кодом. Теперь у С#-разработчиков появилась возможность использовать Mac в качестве среды разработки, и запускать приложения на Linux или внутри Docker-контейнеров.
...
100500 способов кэширования в Oracle Database или как достичь максимальной ск...Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/2913.html
Изначально будут раскрыты базовые причины, которые заставили появиться такой части механизма СУБД, как кэш результатов, и почему в ряде СУБД он есть или отсутствует.
Будут рассмотрены различные варианты кэширования результатов как sql-запросов, так и результатов хранимой в БД бизнес-логики. Произведено сравнение способов кэширования (программируемые вручную кэши, стандартный функционал) и даны рекомендации, когда и в каких случаях данные способы оптимальны, а порой опасны.
...
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2947.html
Apache Ignite — Open Source платформа для высокопроизводительной распределенной работы с большими данными с применением SQL или Java/.NET/C++ API. Ignite используют в самых разных отраслях. Сбербанк, ING, RingCentral, Microsoft, e-Therapeutics — все эти компании применяют решения на основе Ignite. Размеры кластеров разнятся от всего одного узла до нескольких сотен, узлы могут быть расположены в одном ЦОД-е или в нескольких геораспределенных.
...
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 12:00
Тезисы:
http://www.highload.ru/2017/abstracts/3005.html
Когда мы говорим о нагруженных системах и базах данных с большим числом параллельных коннектов, особый интерес представляет практика эксплуатации и сопровождения таких проектов. В том числе инструменты и механизмы СУБД, которые могут быть использованы DBA и DevOps-инженерами для решения задач мониторинга жизнедеятельности базы данных и ранней диагностики возможных проблем.
...
2. О чём мы будем рассказывать?
• Тенденции в разработке бэкенда приложений
• Реализация бессерверного бэкенда
мобильного приложения на базе AWS
• Наш опыт перехода от существующего бэкенда
к рассматриваемому решению
3. • Разработка логики
приложения
• Администрирование
• Отказоустойчивость
• Масштабирование
• Безопасность
• Разработка логики
приложения
Mobile vs Backend
10. AWS Cognito
• Авторизация пользователей
• Поддержка гостевого доступа
• Синхронизация данных между
устройствами
11. AWS Lambda
• Требуется только загрузить код функции
• HTTP-запросы, таймеры и другие виды
триггеров
• Администрирование железа и ПО
осуществляет AWS
• Автоматическое масштабирование
• Оплата только за фактическую работу
функций
12. AWS DynamoDB
• Облачная NoSQL база данных
• Поддержка триггеров
• Взаимодействие осуществляется
через SDK
• Оплата за количество операций в
секунду и объём данных
18. AWS API Gateway
• Кэширование результата запросов
• Генерация SDK для клиентов (iOS, Android,
Javascript)
• Организация версионности и окружений API
• Интеграция с CDN
• Поддержка кастомной аутентификации
21. Работа с медиа-контентом
• Возможность загружать медиа в посты
• Модерация и обработка загружаемых
файлов
• Скорость загрузки и надёжность
хранения данных
22. AWS S3
• Надёжность хранения данных на уровне
99,999999999%
• Триггеры на различные типы событий с
файлами
• Несколько классов хранилищ данных
26. Аналитика / рекомендации
• Отправка эвентов о действиях
пользователя
• Большая пропускная способность
• Обработка эвентов по заданным
правилам
• Отправка пушей/писем клиенту
27. AWS Kinesis
• Приём и обработка потоковых данных
• Высокая пропускная способность
(десятки тысяч записей в секунду)
• Оплата за выделенное количество
шардов
31. Цели достигнуты!
• Удобный для разработки
• Простой в администрировании
• Быстро масштабируемый
• Надёжный и безопасный
• Дешёвый
32. Цели достигнуты!
• Надёжный и безопасный
• Быстро масштабируемый
• Гибкий
• Простой в администрировании
“No server is easier to manage than no server”
• Оплата только за реальной использование
• Низкий TTM
33. Немного о мониторинге и devops
• AWS CloudWatch — логи и мониторинг
• Изменение пропускной способности
DynamoDB
• Serverless фреймворк — организация
процесса разработки
• AWS CloudFormation — создание
инфраструктуры с помощью шаблонов
34. Опыт Upmind
• Сделали полностью бессерверный бэкенд
• Отказались от системных администраторов
• Сэкономили на инфраструктуре ~ 60%
• Увеличилась скорость разработки
• Для некоторых задач использование
серверов всё равно эффективней