Александр Киракозов "Архитектура загрузчика Яндекс.Диска"Yandex
Каждый день на Яндекс.Диск заливается более десятка терабайт данных. Из доклада вы узнаете про то, как справиться с такой нагрузкой, и про другие интересные архитектурные особенности сервиса.
Балансировка нагрузки и отказоустойчивость в ОдноклассникахOntico
Главная → Тезисы и презентации
Балансировка нагрузки и отказоустойчивость в Одноклассниках Системное администрирование
Доклад принят в Программу конференции
Никита Духовный
Одноклассники
Ведущий системный администратор в Одноклассниках. Начинал IT-карьеру разработчиком, занимался релиз инженерией, выбрал системное администрирование.
Возглавляет одну из команд. Занимается задачами, обеспечивающими работу портала - автоматизацией, запуском новых решений, поддержкой инфраструктуры. Ведёт несколько хардкорных проектов, в том числе - по повышению отказоустойчивости портала.
Тезисы
Проект Одноклассники начинал свою жизнь в одном датацентре.
С ростом популярности растёт и нагрузка. С ростом нагрузки открываются проблемы:
- Ни один, даже самый мощный, сервер больше не справляется в одиночку.
- Нагрузка растёт, а в датацентре нет места для нового оборудования.
- Падение датацентра безоговорочно приводит к даунтайму.
- Сетевой сбой выводит портал из строя.
- Пользователи в удалённых регионах страдают от низкой скорости.
Я без прикрас расскажу вам, как мы в Одноклассниках решаем эти проблемы. Поговорим о следующем:
- CDN - каким пользователям важен, его архитектура, устройство наших CDN-приложений, что происходит при авариях.
- Датацентры - почему мы используем три основных датацентра, где они расположены (и почему именно там), распределение пользовательского трафика между ними.
- Сеть - как и до чего мы балансируем трафик.
- Балансировщики - как мы используем LVS, почему (и в каких случаях) используем и другие решения. Что делаем с приложениями, которые нельзя ставить за балансировщик.
- Модули портала - о балансировке в нашем RPC протоколе, о том, что происходит с Одноклассниками при падении датацентра.
Александр Киракозов "Архитектура загрузчика Яндекс.Диска"Yandex
Каждый день на Яндекс.Диск заливается более десятка терабайт данных. Из доклада вы узнаете про то, как справиться с такой нагрузкой, и про другие интересные архитектурные особенности сервиса.
Балансировка нагрузки и отказоустойчивость в ОдноклассникахOntico
Главная → Тезисы и презентации
Балансировка нагрузки и отказоустойчивость в Одноклассниках Системное администрирование
Доклад принят в Программу конференции
Никита Духовный
Одноклассники
Ведущий системный администратор в Одноклассниках. Начинал IT-карьеру разработчиком, занимался релиз инженерией, выбрал системное администрирование.
Возглавляет одну из команд. Занимается задачами, обеспечивающими работу портала - автоматизацией, запуском новых решений, поддержкой инфраструктуры. Ведёт несколько хардкорных проектов, в том числе - по повышению отказоустойчивости портала.
Тезисы
Проект Одноклассники начинал свою жизнь в одном датацентре.
С ростом популярности растёт и нагрузка. С ростом нагрузки открываются проблемы:
- Ни один, даже самый мощный, сервер больше не справляется в одиночку.
- Нагрузка растёт, а в датацентре нет места для нового оборудования.
- Падение датацентра безоговорочно приводит к даунтайму.
- Сетевой сбой выводит портал из строя.
- Пользователи в удалённых регионах страдают от низкой скорости.
Я без прикрас расскажу вам, как мы в Одноклассниках решаем эти проблемы. Поговорим о следующем:
- CDN - каким пользователям важен, его архитектура, устройство наших CDN-приложений, что происходит при авариях.
- Датацентры - почему мы используем три основных датацентра, где они расположены (и почему именно там), распределение пользовательского трафика между ними.
- Сеть - как и до чего мы балансируем трафик.
- Балансировщики - как мы используем LVS, почему (и в каких случаях) используем и другие решения. Что делаем с приложениями, которые нельзя ставить за балансировщик.
- Модули портала - о балансировке в нашем RPC протоколе, о том, что происходит с Одноклассниками при падении датацентра.
Преждевременная оптимизация архитектуры / Евгений Потапов, Антон Баранов (ITS...Ontico
Работа в высоконагруженных проектах всегда была такой сферой деятельности, где можно в рамках решения прикладных задач находить и применять сложные и интересные решения.
К сожалению, очень часто во главу угла ставится не надежное решение поставленной задачи, а именно применение сложного и интересного решения, которое даст специалисту новый опыт и удовольствие от сложных архитектур.
В своем докладе я хочу пройтись по тем стандартным "набитым шишкам", которые мы встречаем в своей работе, когда сложное, новое и интересное решение не означает стабильность системы.
1. Когда "интересно" не значит "правильно"?
1.1. Специфика развития высоконагруженного проекта.
1.2. Требования бизнеса и современные технологии.
1.3. Типичные "сомнительные" решения.
2. Проблемы в архитектуре отказоустойчивых систем.
2.1. Ошибки в планировании резервирования.
2.2. Ошибки в планировании системы выкладок.
2.3. Ошибки в архитектурах систем хранения данных.
3. Проблемы в архитектуре систем, рассчитанных на высокую нагрузку.
3.1. Ошибки в планировании мощностей системы.
3.2. Ошибки в планировании возможностей масштабирования системы.
3.3. Ошибки в архитектурах систем хранения данных.
Как не положить тысячи серверов с помощью системы централизованного управлени...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.
* Приложение - это не только исходный код, но и операционное окружение. Разработка, тестирование и версионирование всего полностью.
* Сервер как программа - компонентный подход.
Стратегия и тактика улучшения производительности BSS систем оператора мобильн...Ontico
В докладе поделимся опытом построения комплексного процесса последовательного улучшения производительности информационных систем мобильного оператора, расскажем об используемых инструментах и компонентах (Oracle, Tarantool, Java, Jmeter и т.д.).
Особенность нашего оператора в том, что основной канал взаимодействия с клиентом - это мобильное приложение или web Личный кабинет, а не USSD команды и СМС, как у основной массы операторов. Данная особенность создает высокие требования к времени отклика и доступности сервисов и ставит перед нами целый ряд вопросов:
- Как достичь приемлемого времени отрисовки страниц (не более 2х секунд) и не "уронить" backend при увеличении кол-ва абонентов в несколько раз за год до 4х миллионов?
- Как обеспечить приемлемую производительность при наличии сложных оркестрирующих процессов на ESB и достаточно медленного, основанного на Oracle биллинга?
- Как контролировать и улучшать производительность и доступность постоянно и на упреждение, а не когда "жареный петух клюнет"?
Мы расскажем о том, как мы отвечаем на выше обозначенные вопросы. В частности, расскажем о внедрении двух БД - inmemory БД на чтение и Oracle на запись с соответствующей синхронизацией, о технике кэширования на нескольких уровнях, оптимизации синхронных и асинхронных процессов, о постоянном выявлении узких мест на тестировании, о кластеризации и других аспектах улучшения общей и частной производительности и доступности при быстро растущей абонентской базе и беспощадной креативности бизнеса.
Нагрузочное тестирование API. Как летать, а не ползать?IT61
Вячеслав Марков, инженер по автоматизированному тестированию в Distillery, расскажет об особенностях нагрузочного тестирования REST API с помощью JMeter.
Вот что пишет Вячеслав: "Вместе со слушателями постараемся разобраться, каким аспектам нагрузочного тестирования стоит уделить наибольшее внимание. Порассуждаем о том, как составить реалистичный тестовый сценарий и выясним, чем же так хорош JMeter. В заключении уделим немного внимания стресс-тестированию."
Javascript-фреймворки: должен остаться только одинSergey Xek
Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет.
В докладе пойдет речь о том, что производительность фронтенда — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но циферки тоже будут.
1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.
Высокопроизводительная и отказоустойчивая архитектура фронтальных систем / Ма...Ontico
Это реальный рассказ об архитектуре Единой Фронтальной Системы (ЕФС) - системы, которая будет обслуживать абсолютно всех клиентов Сбербанка во всех каналах (отделения, интернет-банки, мобильные приложения, АТМ и т.д.). Это означает: десятки миллионов активных клиентов, 24х7, и еще пара NFR'ов, от которых порой вздрагиваешь по ночам :)
С одной стороны мы должны гарантировать 99.99% доступность, с другой стороны мы должны сокращать time-to-market для новых продуктов и быть готовыми обновлять ЕФС очень часто и по кусочкам – и это малая часть вызовов, с которыми нам приходиться сталкиваться.
В моем докладе я расскажу:
· Как мы гарантируем 99.99% доступности для всего ЕФС, включая хранилище (и особенно включая хранилище).
· Как мы масштабируемся на миллионы пользователей, оставаясь внешнее единой системой.
· Как мы реализуем zero downtime deployment, чтобы оставаться в 99.99% в условиях частых обновлений.
Мониторинг в высоконагруженных (и не только) проектах: сравнительный анализ с...Ontico
Выбор системы мониторинга - это практически holy-war-ная тема среди администраторов и разработчиков. Какая система лучше? Что удобнее? Какая система сможет выдержать большое количество статистики, а какая - лучше собрать и представить данные?
В своем докладе мы попробуем предельно непредвзято рассмотреть существующие решения и понять, что и когда можно использовать.
См. тезисы - http://rootconf.ru/2015/abstracts/1746
Андрей Федоренчик- «Высоконагруженная система с аналитикой на InfoBright»Tanya Denisyuk
Наша рекламная сеть прошла путь от 1М до 150M показов в сутки. На этом пути пришлось столкнуться с проблемами при логировании и анализе больших объемов данных. В итоге отказались от использования NonSQL базы данных и выбрали column-based InfoBright. В своем докладе я расскажу, как мы накапливаем, храним, обрабатываем и анализируем сотни гигабайт информации в день c использованием InfoBright.
Автоматизация нагрузочного тестирования в связке JMeter + TeamСity + Grafana ...Positive Hack Days
1. Описание старого процесса сбора данных о тестах: как было до, что хорошего, что плохого
2. Influxdb, как хранилище time-series данных,
3. Zabbix - мониторинг нагрузочных стендов: windows и linux агенты, активный сбор данных, autodiscovery виртуальных машин в esx
4. Grafana, как способ превратить графики и дашборды в конфетку
5. Автоматизация нагрузки от пользователей через web-UI при помощи Jmeter, отображение статистики в реальном времени, CI в Teamcity
Компания «Моё дело» прошла путь от маленького стартапа до лидера рынка в своем сегменте. Вместе с ростом компании росла и ее it структура. Инфраструктура эволюционировала космическими темпами, кол-во проектов стремительно росло. Естественно, всем этим необходимо уметь грамотно оркестрировать. Как это делаем мы и во что это превращается мы и хотим вам рассказать.
Преждевременная оптимизация архитектуры / Евгений Потапов, Антон Баранов (ITS...Ontico
Работа в высоконагруженных проектах всегда была такой сферой деятельности, где можно в рамках решения прикладных задач находить и применять сложные и интересные решения.
К сожалению, очень часто во главу угла ставится не надежное решение поставленной задачи, а именно применение сложного и интересного решения, которое даст специалисту новый опыт и удовольствие от сложных архитектур.
В своем докладе я хочу пройтись по тем стандартным "набитым шишкам", которые мы встречаем в своей работе, когда сложное, новое и интересное решение не означает стабильность системы.
1. Когда "интересно" не значит "правильно"?
1.1. Специфика развития высоконагруженного проекта.
1.2. Требования бизнеса и современные технологии.
1.3. Типичные "сомнительные" решения.
2. Проблемы в архитектуре отказоустойчивых систем.
2.1. Ошибки в планировании резервирования.
2.2. Ошибки в планировании системы выкладок.
2.3. Ошибки в архитектурах систем хранения данных.
3. Проблемы в архитектуре систем, рассчитанных на высокую нагрузку.
3.1. Ошибки в планировании мощностей системы.
3.2. Ошибки в планировании возможностей масштабирования системы.
3.3. Ошибки в архитектурах систем хранения данных.
Как не положить тысячи серверов с помощью системы централизованного управлени...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.
* Приложение - это не только исходный код, но и операционное окружение. Разработка, тестирование и версионирование всего полностью.
* Сервер как программа - компонентный подход.
Стратегия и тактика улучшения производительности BSS систем оператора мобильн...Ontico
В докладе поделимся опытом построения комплексного процесса последовательного улучшения производительности информационных систем мобильного оператора, расскажем об используемых инструментах и компонентах (Oracle, Tarantool, Java, Jmeter и т.д.).
Особенность нашего оператора в том, что основной канал взаимодействия с клиентом - это мобильное приложение или web Личный кабинет, а не USSD команды и СМС, как у основной массы операторов. Данная особенность создает высокие требования к времени отклика и доступности сервисов и ставит перед нами целый ряд вопросов:
- Как достичь приемлемого времени отрисовки страниц (не более 2х секунд) и не "уронить" backend при увеличении кол-ва абонентов в несколько раз за год до 4х миллионов?
- Как обеспечить приемлемую производительность при наличии сложных оркестрирующих процессов на ESB и достаточно медленного, основанного на Oracle биллинга?
- Как контролировать и улучшать производительность и доступность постоянно и на упреждение, а не когда "жареный петух клюнет"?
Мы расскажем о том, как мы отвечаем на выше обозначенные вопросы. В частности, расскажем о внедрении двух БД - inmemory БД на чтение и Oracle на запись с соответствующей синхронизацией, о технике кэширования на нескольких уровнях, оптимизации синхронных и асинхронных процессов, о постоянном выявлении узких мест на тестировании, о кластеризации и других аспектах улучшения общей и частной производительности и доступности при быстро растущей абонентской базе и беспощадной креативности бизнеса.
Нагрузочное тестирование API. Как летать, а не ползать?IT61
Вячеслав Марков, инженер по автоматизированному тестированию в Distillery, расскажет об особенностях нагрузочного тестирования REST API с помощью JMeter.
Вот что пишет Вячеслав: "Вместе со слушателями постараемся разобраться, каким аспектам нагрузочного тестирования стоит уделить наибольшее внимание. Порассуждаем о том, как составить реалистичный тестовый сценарий и выясним, чем же так хорош JMeter. В заключении уделим немного внимания стресс-тестированию."
Javascript-фреймворки: должен остаться только одинSergey Xek
Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет.
В докладе пойдет речь о том, что производительность фронтенда — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но циферки тоже будут.
1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.
Высокопроизводительная и отказоустойчивая архитектура фронтальных систем / Ма...Ontico
Это реальный рассказ об архитектуре Единой Фронтальной Системы (ЕФС) - системы, которая будет обслуживать абсолютно всех клиентов Сбербанка во всех каналах (отделения, интернет-банки, мобильные приложения, АТМ и т.д.). Это означает: десятки миллионов активных клиентов, 24х7, и еще пара NFR'ов, от которых порой вздрагиваешь по ночам :)
С одной стороны мы должны гарантировать 99.99% доступность, с другой стороны мы должны сокращать time-to-market для новых продуктов и быть готовыми обновлять ЕФС очень часто и по кусочкам – и это малая часть вызовов, с которыми нам приходиться сталкиваться.
В моем докладе я расскажу:
· Как мы гарантируем 99.99% доступности для всего ЕФС, включая хранилище (и особенно включая хранилище).
· Как мы масштабируемся на миллионы пользователей, оставаясь внешнее единой системой.
· Как мы реализуем zero downtime deployment, чтобы оставаться в 99.99% в условиях частых обновлений.
Мониторинг в высоконагруженных (и не только) проектах: сравнительный анализ с...Ontico
Выбор системы мониторинга - это практически holy-war-ная тема среди администраторов и разработчиков. Какая система лучше? Что удобнее? Какая система сможет выдержать большое количество статистики, а какая - лучше собрать и представить данные?
В своем докладе мы попробуем предельно непредвзято рассмотреть существующие решения и понять, что и когда можно использовать.
См. тезисы - http://rootconf.ru/2015/abstracts/1746
Андрей Федоренчик- «Высоконагруженная система с аналитикой на InfoBright»Tanya Denisyuk
Наша рекламная сеть прошла путь от 1М до 150M показов в сутки. На этом пути пришлось столкнуться с проблемами при логировании и анализе больших объемов данных. В итоге отказались от использования NonSQL базы данных и выбрали column-based InfoBright. В своем докладе я расскажу, как мы накапливаем, храним, обрабатываем и анализируем сотни гигабайт информации в день c использованием InfoBright.
Автоматизация нагрузочного тестирования в связке JMeter + TeamСity + Grafana ...Positive Hack Days
1. Описание старого процесса сбора данных о тестах: как было до, что хорошего, что плохого
2. Influxdb, как хранилище time-series данных,
3. Zabbix - мониторинг нагрузочных стендов: windows и linux агенты, активный сбор данных, autodiscovery виртуальных машин в esx
4. Grafana, как способ превратить графики и дашборды в конфетку
5. Автоматизация нагрузки от пользователей через web-UI при помощи Jmeter, отображение статистики в реальном времени, CI в Teamcity
Компания «Моё дело» прошла путь от маленького стартапа до лидера рынка в своем сегменте. Вместе с ростом компании росла и ее it структура. Инфраструктура эволюционировала космическими темпами, кол-во проектов стремительно росло. Естественно, всем этим необходимо уметь грамотно оркестрировать. Как это делаем мы и во что это превращается мы и хотим вам рассказать.
Presentation about Windows Azure Internals. The next topics covered:
1) Azure Datacenters
2) Windows Azure Hypervisor
3) Windows Azure Fabric Controller
4) Service deployment steps
5) Windows Azure virtual machine structure
Создание облачных приложений по модели PaaS (Platform as Service) позволяет сосредоточиться на решении задач по созданию программного обеспечения, вместо того чтобы беспокоиться о базовой инфраструктуры. Но иногда построение комплексного решения или интеграция с существующими системами требуется больше контроля, чем предоставляет модель PaaS, требуется контроль над инфраструктурой, т.е. IaaS (Infrastructure as Service). В рамках доклада будут рассмотрены основные архитектурные особенности Windows Azure, которые необходимо учитывать при миграции приложения в PaaS модели, а так же новые инфраструктурные возможности Windows Azure, такие как виртуальные машины и виртуальные сети, которые позволяют использовать IaaS модель миграции.
IBM Cloudant и Apache CouchDB: NoSQL базы данных эпохи облаковMaxim Zinal
Какой должна быть NoSQL СУБД эпохи облаков? Что такое IBM Cloudant и Apache CouchDB?
Как они связаны друг с другом, и есть ли польза для Open Source проекта от коммерческого облачного сервиса на его основе?
Высокая доступность приложений в гибридном облаке на базе Jelastic и Azure Tr...Dmitry Lazarenko
Высокая доступность в гибридном облаке на базе Azure Traffic Manager.
Jelastic - контейнерная платформа как сервис, которая может быть установлена как в частный ЦОД, так и в глобальное облако, например Microsoft Azure. Также возможен гибридный сценарий, когда часть приложения размещается в частном ЦОД, а другая часть в одном или нескольких регионов Azure.
Мы пытались решить задачу организации максимальной доступности и отказоустойчивости приложений в гибридном облаке, а также миграции комплексных приложений без downtime из одного ЦОД в другой.
Решая ее мы перепробовали несколько архитектурных вариантов: Anycast IP, Global IP, Anycast DNS на базе Nginx и bind, а также Azure Traffic Manager.
В докладе расскажем про апробацию различных архитектурных паттернов высокой доступности и отказоустойчивости в многоцодовой конфигурации, а также про реализацию итогового решения на базе Azure Traffic Manager.
Андрей Зайчиков "Архитектура распределенных кластеров NoSQL на AWS"IT Event
Мы рассмотрим важные особенности построения архитектуры распреденных кластеров NoSQL с использованием ресурсов Amazon Web Services, мы затронем такие аспекты как: архитектура гео распределенных кластеров, оптимизация производительности, выбор основных опций для деплоймента и ряд других аспектов. В докладе мы сконцентрируемся на таких популярных базах данных, как Cassandra, MongoDB и некоторых других.
Дмитрий Лазаренко-«Живая миграция и отказоустойчивость контейнеров в гибридно...Tanya Denisyuk
"Контейнеры могут динамически появляться и исчезать, являются легковесными, не резервируют все необходимые ресурсы при старте, потому их оркестрация дается не простой ценой. Каждый из виртуальных контейнеров в один момент времени может потребовать максимум доступных ему ресурсов и это может привести к тому, что закончатся все ресурсы на физическом сервере, на котором они размещаются. В докладе мы поговорим о механизме, который решает эту непростую задачу, и умеет проводить непрерывную балансировку нагрузки, перемещать контейнеры с одного физического сервера на другие для проведения технических работ без простоя приложений - умная живая миграция (Smart Live Migration).
Многие считают, что контейнеры не подходят для хранения важных данных, т.к. в любой момент они могут упасть и все данные пропадут навсегда. Мы расскажем как этого избежать с помощью технологии Software-defined-storage."
Разгоняем 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-контейнеров.
...
Delphix Dynamic Data Platform, как попробовать и правильно оценить решениеSergii Stukan
Не смотря на то, что Delphix Dynamic Data Platform широко используется с комплексными бизнес-платформами от таких производителей как SAP, Oracle, Microsoft, IBM и многих других.Попробовать ее и оценить, как она может положительно повлиять нетолько на ИТ но и на весь бизнес вашей компании довольно просто. В презентации кратко описан подход Efficient IT к проведению Proof of Value Delphix Dynamic Data Platform.
Загрузка больших объемов данных для бизнес-аналитикиBadoo Development
В Badoo мы разрабатываем собственную систему Business intelligence (сокращённо BI). И прежде, чем приступать к анализу данных, их необходимо извлечь (Extract) из источников, преобразовать (Transform) и загрузить (Load) в аналитическую базу.
Я расскажу об этом процессе - ETL (Extract, Transform, Load). Какие бывают источники данных, какие методы сбора мы используем. И самое главное - об инструменте под названием ETLMaster, созданным в нашей компании для автоматизации управления процессом трансформации и загрузки данных.
13. • Опрос необходимости перезагрузки кэша
• Опрос выполнения задач
• Передача данных между сервисами
системы
Антипаттерн: Shared Database
14.
15. • Сигналы о перегрузке кэша
• Команды
• Данные команды
Шина сообщений
16.
17. • Подписка только на нужные события
• Отправка изменений пачкой
• Применение изменений пачкой
Оптимизация накатывания
изменений в кэшах
18. • Последовательное чтение из БД
• Последовательное чтение из БД и уже
прогрузившихся нод
• Единая отдельная точка прогрузки и
раздачи кэша
Оптимизация холодного старта
кэшей
19. • Единая точка записи в БД
Событий слишком много —
блокировки в БД
20.
21. • Отдельная БД на быструю запись
нетранзакционных данных, кластер БД
• Транзакционная БД для «важных» данных
Оптимизация БД — разделение на
SQL и NoSQL
22.
23. • Разделение обязанностей
• Подписка на изменения в соответствии с
состоянием кэша
• Отслеживание исполнения
(диспетчеризация)
• Взаимодействие между собой нодов одного
типа — эффект роя
Оптимизация однотипных нодов
24. • Дублирование всего
• Балансировка нагрузки
• Мониторинг с автопереключением (БД,
балансировщики, сетевые интерфейсы и т.д.)
• Разнесение дублирующих виртуалок на
физически разные хосты
• Авторазворачивание сервисов взамен упавших
• Пессимистичная архитектура кода!
Отказоустойчивость
25. • Тестирование разворачивания бекапов
• Тестирование отказа отдельных сервисов
• Тестирование массовых отказов (хоста с
несколькими виртуалками и др. сценарии)
• Нагрузочное тестирование
• Регрессионное!
Тестирование отказоустойчивости
26. • Уровни алертинга
• debug / info / error / critical
• в понедельник / с утра / посреди ночи
• Автоматические меры
• Dashboard
• Функциональное тестирование
• Тестирование мониторинга
• Взаимодействие с кодом!
• Сравнение параметров разных окружений
Мониторинг
27.
28. КАК?
• Итеративно, как можно проще
• Тестовое окружение, максимально
приближенное к боевому
• Логирование
• R&D
29. • Нагрузка — потоки данных
• Кэширование
• своя структура данных в кэше
• оптимальная инвалидация
• холодный старт — не заDDоSить самим себя
• Шина сообщений — среда общения сервисов
• логика при подписке, а не при отправке
• «внутривидовое» общение роя
Еще разок
30. • Запись в БД
• Минимизация параллельной записи
• разделение БД по назначениям
• Автомасштабирование, отказоустойчивость и
мониторинг
• Тестирование
• функциональности
• отказоустойчивости
• нагрузкоустойчивости
• мониторинга
Еще разок