Как строить архитектуру для отказоустойчивой службы такси / Минкин Андрей (Na...Ontico
Такси — это популярная тема для обсуждений, после того, как появились стартапы в виде Uber, GetTaxi, GrabTaxi и тому подобные. Ведущий разработчик службы Namba Taxi расскажет про то, как строилась текущая отказоустойчивая архитектура в Namba Taxi, с какими проблемами и неудачами мы сталкивались и как решали.
Тезисы - http://www.highload.ru/2015/abstracts/1661.html
Jelastic - гибридная платформа как сервис(PaaS) для компаний- разработчиков ПО на Java, Ruby, .NET, ASP.NET, PHP, Node.JS и Docker. Позволяет строить автомасштабируемые, отказоустойчивые среды для приложений, управлять множеством сред для разработки и тестирования
Николай Сивко "Хорошо поддерживаемое в продакшне приложение"Tanya Denisyuk
Исторически сложилось так, что одни люди разрабатывают приложения (Dev), а другие эксплуатируют их в продакшне (Ops). И у последних есть немало проблем с тем, что невозможно понять, что происходит.
Причем это касается как собственных разработок, так и популярных open source решений.
Я расскажу, как устроена диагностика у некоторых популярных софтин:
- nginx
- postgresql
- mongodb
Мы попробуем разобраться, что там сделано хорошо, и чего не хватает для полного счастья.
Во второй части доклада мы поговорим про то, как нужно инструментировать собственное приложение для прозрачной работы в продакшне:
- что считать и зачем: ошибки, тайминги, разные состояния приложения,
- инструментарий: your_lang-metrics, your_lang-statsd-client, логи,
- как не перемудрить и не убить прод диагностикой.
Может показаться, что этот доклад про DevOps, но нет - про docker не будет ни слова :)
Как строить архитектуру для отказоустойчивой службы такси / Минкин Андрей (Na...Ontico
Такси — это популярная тема для обсуждений, после того, как появились стартапы в виде Uber, GetTaxi, GrabTaxi и тому подобные. Ведущий разработчик службы Namba Taxi расскажет про то, как строилась текущая отказоустойчивая архитектура в Namba Taxi, с какими проблемами и неудачами мы сталкивались и как решали.
Тезисы - http://www.highload.ru/2015/abstracts/1661.html
Jelastic - гибридная платформа как сервис(PaaS) для компаний- разработчиков ПО на Java, Ruby, .NET, ASP.NET, PHP, Node.JS и Docker. Позволяет строить автомасштабируемые, отказоустойчивые среды для приложений, управлять множеством сред для разработки и тестирования
Николай Сивко "Хорошо поддерживаемое в продакшне приложение"Tanya Denisyuk
Исторически сложилось так, что одни люди разрабатывают приложения (Dev), а другие эксплуатируют их в продакшне (Ops). И у последних есть немало проблем с тем, что невозможно понять, что происходит.
Причем это касается как собственных разработок, так и популярных open source решений.
Я расскажу, как устроена диагностика у некоторых популярных софтин:
- nginx
- postgresql
- mongodb
Мы попробуем разобраться, что там сделано хорошо, и чего не хватает для полного счастья.
Во второй части доклада мы поговорим про то, как нужно инструментировать собственное приложение для прозрачной работы в продакшне:
- что считать и зачем: ошибки, тайминги, разные состояния приложения,
- инструментарий: your_lang-metrics, your_lang-statsd-client, логи,
- как не перемудрить и не убить прод диагностикой.
Может показаться, что этот доклад про DevOps, но нет - про docker не будет ни слова :)
Badoo Desktop: оптимизация приложения на миллион юзеров онлайнSergey Xek
Badoo Desktop: оптимизация приложения на миллион юзеров онлайн. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
Badoo Desktop: оптимизация приложения на миллион юзеров онлайнSergey Xek
Badoo Desktop: оптимизация приложения на миллион юзеров онлайн. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
In this talk, I will tell you about Vapor and will share our successful experience of moving from regular AWS EC2 servers to AWS Lambda and how everything changed after the appearance of Lambda on our project.
- When serverless architecture is the best choice.
- Overview Vapor - a platform for deploying and managing Laravel applications in AWS Lambda from Laravel.
- Our experience of migrating to Lambda, difficulties, best practices.
- How we predicted the cost and how much we pay in fact.
- Ways to optimize costs.
"Our experience of transferring Laravel microservices to AWS Lambda using Vap...Fwdays
In this talk, I will tell you about Vapor and will share our successful experience of moving from regular AWS EC2 servers to AWS Lambda and how everything changed after the appearance of Lambda on our project.
When serverless architecture is the best choice.
Overview Vapor - a platform for deploying and managing Laravel applications in AWS Lambda from Laravel.
Our experience of migrating to Lambda, difficulties, best practices.
How we predicted the cost and how much we pay in fact.
Ways to optimize costs.
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного se...Sergey Xek
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного server-side API десктопного приложения. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
Основные кейсы использования in-memory СУБД на примере Тарантула и проектов M...Ontico
Основные кейсы использования Тарантула:
1. Когда нужна OLTP-система, позволяющая обрабатывать транзакции в режиме почти реального времени (с милисекундными задержками) и/или с огромной пропускной способностью (сотни тысяч запросов в секунду). Примеры — система сессий, система антибрутфорса, система противодействия атакам, система очередей и пуш-уведомлений, роутинг запросов между серверами.
Далее - http://backendconf.ru/2016/abstracts/2096.html
HighLoad++ 2017
Зал Дели + Калькутта, 7 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2867.html
Последние несколько лет в продуктовой разработке проблемы масштабирования решаются через переход на микросервисную архитектуру. На эту тему было сказано много про подходы, плюсы и минусы, но мало кто рассматривал эту проблематику со стороны фронтенда.
В ЦИАН мы идем по пути перехода от монолита к микросервисам, в том числе и на фронтенде. Задачи и проблемы, с которыми мы сталкиваемся, очень близки к аналогичным на бэкенде, но в то же время совершенно другие.
Последние несколько лет в продуктовой разработке проблемы масштабирования решаются через переход на микросервисную архитектуру. На эту тему было сказано много про подходы, плюсы и минусы, но мало кто рассматривал эту проблематику со стороны фронтенда.
В ЦИАН мы идем по пути перехода от монолита к микросервисам, в том числе и на фронтенде. Задачи и проблемы, с которыми мы сталкиваемся, очень близки к аналогичным на бэкенде, но в то же время совершенно другие.
В своем докладе я расскажу про архитектуру фронтенда (и так называемого миддленда) в ЦИАН: какие задачи перед нами стояли, что мы решили, где мы находимся сейчас и с какими проблемами мы столкнулись.
Как строить архитектуру для отказоустойчивой службы такси / How to Build a ...Mad Devs
Доклад с конференции Highload++ 2015 об отказоустойчивой архитектуре
A report from the Highload++ 2015 conference in Moscow, describing the fallover architectures
Автор: Андрей Минкин / Andrew Minkin
http://www.highload.ru/2015/abstracts/1661.html
Преждевременная оптимизация архитектуры / Евгений Потапов, Антон Баранов (ITS...Ontico
Работа в высоконагруженных проектах всегда была такой сферой деятельности, где можно в рамках решения прикладных задач находить и применять сложные и интересные решения.
К сожалению, очень часто во главу угла ставится не надежное решение поставленной задачи, а именно применение сложного и интересного решения, которое даст специалисту новый опыт и удовольствие от сложных архитектур.
В своем докладе я хочу пройтись по тем стандартным "набитым шишкам", которые мы встречаем в своей работе, когда сложное, новое и интересное решение не означает стабильность системы.
1. Когда "интересно" не значит "правильно"?
1.1. Специфика развития высоконагруженного проекта.
1.2. Требования бизнеса и современные технологии.
1.3. Типичные "сомнительные" решения.
2. Проблемы в архитектуре отказоустойчивых систем.
2.1. Ошибки в планировании резервирования.
2.2. Ошибки в планировании системы выкладок.
2.3. Ошибки в архитектурах систем хранения данных.
3. Проблемы в архитектуре систем, рассчитанных на высокую нагрузку.
3.1. Ошибки в планировании мощностей системы.
3.2. Ошибки в планировании возможностей масштабирования системы.
3.3. Ошибки в архитектурах систем хранения данных.
Badoo Desktop: оптимизация приложения на миллион юзеров онлайнSergey Xek
Badoo Desktop: оптимизация приложения на миллион юзеров онлайн. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
Badoo Desktop: оптимизация приложения на миллион юзеров онлайнSergey Xek
Badoo Desktop: оптимизация приложения на миллион юзеров онлайн. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
In this talk, I will tell you about Vapor and will share our successful experience of moving from regular AWS EC2 servers to AWS Lambda and how everything changed after the appearance of Lambda on our project.
- When serverless architecture is the best choice.
- Overview Vapor - a platform for deploying and managing Laravel applications in AWS Lambda from Laravel.
- Our experience of migrating to Lambda, difficulties, best practices.
- How we predicted the cost and how much we pay in fact.
- Ways to optimize costs.
"Our experience of transferring Laravel microservices to AWS Lambda using Vap...Fwdays
In this talk, I will tell you about Vapor and will share our successful experience of moving from regular AWS EC2 servers to AWS Lambda and how everything changed after the appearance of Lambda on our project.
When serverless architecture is the best choice.
Overview Vapor - a platform for deploying and managing Laravel applications in AWS Lambda from Laravel.
Our experience of migrating to Lambda, difficulties, best practices.
How we predicted the cost and how much we pay in fact.
Ways to optimize costs.
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного se...Sergey Xek
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного server-side API десктопного приложения. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
Основные кейсы использования in-memory СУБД на примере Тарантула и проектов M...Ontico
Основные кейсы использования Тарантула:
1. Когда нужна OLTP-система, позволяющая обрабатывать транзакции в режиме почти реального времени (с милисекундными задержками) и/или с огромной пропускной способностью (сотни тысяч запросов в секунду). Примеры — система сессий, система антибрутфорса, система противодействия атакам, система очередей и пуш-уведомлений, роутинг запросов между серверами.
Далее - http://backendconf.ru/2016/abstracts/2096.html
HighLoad++ 2017
Зал Дели + Калькутта, 7 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2867.html
Последние несколько лет в продуктовой разработке проблемы масштабирования решаются через переход на микросервисную архитектуру. На эту тему было сказано много про подходы, плюсы и минусы, но мало кто рассматривал эту проблематику со стороны фронтенда.
В ЦИАН мы идем по пути перехода от монолита к микросервисам, в том числе и на фронтенде. Задачи и проблемы, с которыми мы сталкиваемся, очень близки к аналогичным на бэкенде, но в то же время совершенно другие.
Последние несколько лет в продуктовой разработке проблемы масштабирования решаются через переход на микросервисную архитектуру. На эту тему было сказано много про подходы, плюсы и минусы, но мало кто рассматривал эту проблематику со стороны фронтенда.
В ЦИАН мы идем по пути перехода от монолита к микросервисам, в том числе и на фронтенде. Задачи и проблемы, с которыми мы сталкиваемся, очень близки к аналогичным на бэкенде, но в то же время совершенно другие.
В своем докладе я расскажу про архитектуру фронтенда (и так называемого миддленда) в ЦИАН: какие задачи перед нами стояли, что мы решили, где мы находимся сейчас и с какими проблемами мы столкнулись.
Как строить архитектуру для отказоустойчивой службы такси / How to Build a ...Mad Devs
Доклад с конференции Highload++ 2015 об отказоустойчивой архитектуре
A report from the Highload++ 2015 conference in Moscow, describing the fallover architectures
Автор: Андрей Минкин / Andrew Minkin
http://www.highload.ru/2015/abstracts/1661.html
Преждевременная оптимизация архитектуры / Евгений Потапов, Антон Баранов (ITS...Ontico
Работа в высоконагруженных проектах всегда была такой сферой деятельности, где можно в рамках решения прикладных задач находить и применять сложные и интересные решения.
К сожалению, очень часто во главу угла ставится не надежное решение поставленной задачи, а именно применение сложного и интересного решения, которое даст специалисту новый опыт и удовольствие от сложных архитектур.
В своем докладе я хочу пройтись по тем стандартным "набитым шишкам", которые мы встречаем в своей работе, когда сложное, новое и интересное решение не означает стабильность системы.
1. Когда "интересно" не значит "правильно"?
1.1. Специфика развития высоконагруженного проекта.
1.2. Требования бизнеса и современные технологии.
1.3. Типичные "сомнительные" решения.
2. Проблемы в архитектуре отказоустойчивых систем.
2.1. Ошибки в планировании резервирования.
2.2. Ошибки в планировании системы выкладок.
2.3. Ошибки в архитектурах систем хранения данных.
3. Проблемы в архитектуре систем, рассчитанных на высокую нагрузку.
3.1. Ошибки в планировании мощностей системы.
3.2. Ошибки в планировании возможностей масштабирования системы.
3.3. Ошибки в архитектурах систем хранения данных.
3. Разработчики любят писать программы
и ненавидят администрировать сервера
10:15 Install OS
11:20 Configure the system
12:05 Coffee Break
13:05 Configure security
14:15 Configure Web server
15:40 Configure Database
16:20 Couple of sandwiches
16:50 Configure firewall
17:20 Deploy application
17:45 Call wife and apologize for the late return
18:00 Identify library dependencies
20:30 Upgrade packages
22:15 Fix dependencies
23:50 Couple cans of Red Bull
01:30 Run!!!
02:05 The end of the working day ~ 16 hours
5. 10:15 Choose the configuration
10:17 Specify the domain name
10:20 Upload application
10:25 Run!!!
~ 10 минут
• Быстро, просто
• Економия времени и денег
9. • Утечки памяти в JVM (запостили кучу багов )
• Странное поведение системы виртуализации
(virtuozzo)
• Очень проблематичный сервер Glassfish
• Сложность репликации сессий для обеспечения HA
• Придумали собственный алгоритм балансировки
(ребята из Nginx спрашивали как мы такое сделали
)
11. • Алгоритм распределения новых контейнеров
по физическим машинам с учетом
комплексного показателя загрузки
• Алгоритм равномерного размазывания
контейнеров одного окружения
• Алгоритм умной живой миграции окружений
на загруженных машинах
• Обеспечение HA