«Детские болезни live-чата» Ольга Сентемова, Тинькофф Банк

Más contenido relacionado

La actualidad más candente

В процессе рефакторинга архитектуры мы начали переделывать часть системы на микросервисы, и вышло настолько клево, что мы просто обязаны этим поделиться. Микросервисы. Зачем они вообще: - В простых сервисах легче разбираться и локализовывать проблемы. - В микросервисной архитектуре проще добиваться отказоустойчивости. - Хотим выбирать лучший инструмент для каждой задачи. Получаем зоопарк технологий, которые в монолитные сервисы интегрировать сложнее. - Независимое обновление компонентов. - Тестирование частей системы. Как: - 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: описание архитектуры обязано быть актуальным и полным, иначе беда. Трудности: Допишу через пару дней.

Мастер-класс "Микросервисы: удобно, надежно, серебрянопульно" / Евгений Павло...

Ontico

NodeJS — достаточно молодой фреймворк, и пока не каждый решается использовать его в продакшене, а тем более в highload. В течение последнего года мы разрабатывали проект DMP (Data Management Platform), используя NodeJS для прототипирования. На данный момент проект в большей степени все еще остался на JS и без труда справляется с текущими нагрузками в 10 000 запросов в секунду. В докладе я расскажу, почему остановились именно на NodeJS и совсем не жалеем об этом. К сожалению, никакое дело не обходится без граблей и костылей. Я расскажу обо всех встретившихся проблемах и уделю особое внимание проблемам со спагетти-кодом, утечками и нехваткой памяти. Как мы убили немало времени, тщетно ища источник проблем, и какие правила мы составили для себя на будущее, чтобы не повторить своих ошибок. Расскажу немного о применении микросервисов для решения проблемы спагетти-кода. И, как итог, опишу ряд рекомендаций, которые помогут избежать большой траты времени при использовании NodeJS.

NodeJS в HighLoad проекте / Акрицкий Владимир (iAge Engineering)

Ontico

+ Функционал разных решений для балансировки. + Виды балансировщиков (DNS, hardware, software, облачные решения). + Поведение при скачках трафика и возможности скалирования сервиса. + Специфика трафика RTB в контексте балансировки. + Проблемы, которые возникали у нас, и как мы их решали.

Сравнение решений по балансировке высоконагруженных систем / Евгений Пивень (...

Ontico

Александр Афенов

CodeFest

Sivko

kuchinskaya

HeadHunter - сайт, где соискатели находят работу, а работодатели - сотрудников. Днем к нам приходит 3K запросов в секунду (без статики), что превращается в 25K rps к бэкендам и 50K rps к базам данных. Раньше стабильность сайта могла быть ниже 99%. Теперь - это 99.9% и лучше. Стабильностью сайта у нас занимается как служба эксплуатации, так и команда разработчиков SRE (site reliability engineering). В прошлом году Николай Сивко уже рассказывал об организации службы эксплуатации и мониторинге сайта. Но эксплуатация отвечает за железо, сеть и ОС, а за приложения - команда SRE. В докладе хочу рассказать о том, как мы построили процесс, позволяющий каждый месяц улучшать стабильность сайта, с какими техническими проблемами сталкиваемся и как решаем. В частности: - как мы определяем, когда сайт работает, а когда - нет? - что делаем, когда сайт лежит? - как настроили мониторинг и другие инструменты для быстрой локализации проблемы; - как нагружаем сайт, чтобы заранее выявить узкое место? Чтобы не было скучно, расскажу о конкретных кейсах: - как мы масштабировали реплики базы данных; - почему отказались от PgBouncer для высоконагруженных бэкендов; - почему нам не подошел Graylog, и как мы ищем в логах другим гораздо более простым и быстрым способом; - как решили проблему заваливания себя ретраями; - и др.

Как SRE следит за стабильностью и скоростью HeadHunter / Антон Иванов (HeadHu...

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 без серьезного переписывания перейти зачастую нельзя. Мы - как раз тот случай.

Microsoft и Linux на одном проекте: как получить лучшее из обоих миров и не р...

Ontico

Highload, высокие нагрузки — популярный и дорогой buzzword, ради него проводятся огромные конференции, разработчики указывают его в резюме, претендуя на большие деньги, а работодатели в вакансиях, обещая более интересную работу. В докладе я показываю, что современная производительность серверов позволяет не думать о нагрузке для 95% "highload" проектов, знания из конференций не нужны в реальной жизни. Для разработки почти любого, даже очень крупного сайта достаточно PHP+MySQL, здравого смысла и совсем-совсем базовых правил, не обсуждающихся даже на Highload Junior. План выступления. 1. Ликбез о производительности. RPS, latency — что это значит, как считается, к каким числам надо стремиться? Из чего складывается время отклика? База данных, фронтенд, верстка или мобильное приложение. 2. Замеры достижимой производительности теплого LAMP-ового сервера. Бенчмарк без индексов в базе. Бенчмарк с индексами в базе. Сравнение с требуемыми цифрами. 3. Перечисление возможных детских ошибок, которые могут испортить эти результаты в жизни. Все эти ошибки объясняются не в академии Highload или институте Highload Junior, а в школе. Примеры ошибок: - выгрузка всей базы, а не нужных 20 элементов; - паразитный вызов тяжелой страницы; - плохой хостинг; - чужие тормозные элементы; - неадекватный объём html/js-кода. 4. Отсутствие детских ошибок позволяет эффективно программировать 90% крупных сайтов, 3-4 приема превратят 90% в 95%. - nginx; - репликация; - кэширование и предрасчет. Этому, кстати, тоже почти не учат на highload junior, но этому я вас уже научил. 5. Примеры продуктов, в которых на самом деле нужен highload? - Очень-очень-очень много хитов, дешевле highload, чем новое железо. - Очень много очен�

Миф об очень сложном Highload / Александр Горный (Mail.Ru Group)

Ontico

Выбор системы мониторинга - это практически holy-war-ная тема среди администраторов и разработчиков. Какая система лучше? Что удобнее? Какая система сможет выдержать большое количество статистики, а какая - лучше собрать и представить данные? В своем докладе мы попробуем предельно непредвзято рассмотреть существующие решения и понять, что и когда можно использовать. См. тезисы - http://rootconf.ru/2015/abstracts/1746

Мониторинг в высоконагруженных (и не только) проектах: сравнительный анализ с...

Ontico

Сегодня много дискуссий о том, что лучше - MySQL или PostgreSQL? Однако перед тем, как выбирать именно реляционную базу данных для своего проекта, стоит понять, является ли реляционная база данных наилучшим решением для него. В рамках этого доклада мы сравним наиболее популярную реляционную базу данных с открытым кодом с наиболее популярным хранилищем документов с открытым кодом. Мы определим, в каких случаях эффективнее всего работает MySQL, а в каких - MongoDB. Мы также рассмотрим ситуации, в которых ни одна из этих баз данных не будет лучшим решением и в которых целесообразно остановить свой выбор на других технологиях.

MySQL® и MongoDB® - когда что лучше использовать? / Петр Зайцев (Percona)

Ontico

Мы создаем nodejs приложения, используя различные современные технологии, такие как Docker, Consul, pm2. Современный спектр решений настолько обширен, что сложно не заблудиться. Как же выбрать нужные вашему проекту технологии, чтобы успешно его запустить и поддерживать? Будут рассказаны истории и, конечно же, даны вредные советы :) Как на nodejs пройти путь от Hello world приложения до распределённого решения, состоящего из микросервисов? Мы пройдём жизненный цикл продукта, начав с простого приложения на nodejs. Научимся его правильно запускать и будем постепенно добавлять элементы, убирая при этом ненужные. Так к нашему приложению присоединится гипервизор, а само оно будет разделено на части, где каждая сущность будет управлять своей частью приложения. Построив таким образом архитектуру на чистом nodejs, мы займёмся развитием приложения, добавим современные технологии и применим новые подходы к организации инфраструктуры. Запакуем приложение в Docker, попутно обсудим, зачем он нужен и что может дать. И, наконец, решим проблему поиска запущенных сервисов и отслеживания их статусов, используя Consul.

Инфраструктура распределенных приложений на nodejs / Станислав Гуменюк (Rambl...

Ontico

Вы когда-нибудь плакали, открывая Amazon EC2 калькулятор? Мучились ли вы над тем, куда поставить сервер — на балкон или в кладовку? Готовились ли вы морально платить по 100-200 тысяч рублей за самый примитивный вариант сервера? Из этой ситуации есть выход и это — Android-планшеты :) Как установить Linux на ваш Android-планшет, как развернуть LAMP, MEAN stack, сколько RPS могут выдать Android-планшеты, как хорошо они масштабируются, map/reduce, готовы ли Android-планшеты для production? Все это и многое другое вы узнаете из этого доклада.

Android Cloud... точнее Cloud из Android / Охрименко Алексей (Acronis)

Ontico

В выпуске 4.8 ядра Linux появилась поддержка NVMf (NVM Express over Fabrics) — стандартизованной возможности присоединять по сети как блочные устройства твердотельные накопители, установленные в разъёмы PCI Express. NVMf лишён многих недостатков iSCSI, повторяющего по сети SCSI-команды со всеми их издержками времён дисковых накопителей, и главное — позволяет по полной использовать возможности сетей с прямым доступом к оперативной памяти (RDMA). Таким образом, можно под управлением одного узла собрать сверхбыстрый и сверхотзывчивый пул блочных устройств, не прибегая к покупке дорогого флэш-массива. Но как воспользоваться этим пулом, не загубив теоретические показатели программными обёртками? В докладе будут рассмотрены варианты применения NVMf для различных конфигураций PostgreSQL, Oracle Database, Hadoop, файловых хранилищ, о разработках в направлении «программно-определяемой памяти» с применением NVMe-устройств, доступных по сети, обсуждены текущие проблемы, ограничения и перспективы. Особое внимание будет уделено практическим способам измерения производительности ввода-вывода с учётом задачи, решаемой подсистемой хранения.

NVMf: 5 млн IOPS по сети своими руками / Андрей Николаенко (IBS)

Ontico

Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет. В докладе пойдет речь о том, что производительность фронтенда — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но циферки тоже будут. 1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код. 2) Как измеряли, что примерно стоит брать (исследование популярности). 3) Что рассматривали. 4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи). 5) Два пилотных демо-проекта: цифры. 6) Оценка трудоемкости перехода.

Javascript-фреймворки:  должен остаться только один

Sergey Xek

Если наш проект — это не коробочный продукт, а, например, веб-сервис, на который постоянно ходят пользователи, их много и они сразу видят изменения, то в жизненном цикле разработки у нас возникает еще одна задача — задача деплоя готового кода в боевое окружение. В самом начале, когда наш проект маленький и простой, на эту задачу никто может и не обращать внимания, так как все происходит быстро и просто. Процесс деплоя состоит из 2-3 общеизвестных шагов — git pull, yii migrate, etc..., которые легко запомнить и в них сложно ошибиться. С развитием проекта его сложность возрастает — он уже крутится на нескольких серверах, появляются новые компоненты (утилиты, библиотеки и т.д.), новые сущности (балансеры, кэшы, и т.д.). Держать всю инфраструктуру в голове становится невозможным, ведение документации привносит больше проблем, нежели решений, люди ошибаются чаще и т.д. В докладе: — рассмотрим подробно вышеуказанные проблемы, с которыми неизбежно сталкиваются проекты; — обсудим, какие решения существуют в индустрии (chef, ansible, etc), чем они отличаются, какой выбрать и в чем их задача; — поговорим про административные вопросы, которые с этим связаны.

Эволюция процесса деплоя в проекте / Денис Яковлев (2ГИС)

Ontico

Компания «Моё дело» прошла путь от маленького стартапа до лидера рынка в своем сегменте. Вместе с ростом компании росла и ее it структура. Инфраструктура эволюционировала космическими темпами, кол-во проектов стремительно росло. Естественно, всем этим необходимо уметь грамотно оркестрировать. Как это делаем мы и во что это превращается мы и хотим вам рассказать.

SECON'2016. Панин Сергей, Лебедев Андрей, Храмушин Дмитрий, IT-инфраструктура...

SECON

Каждый день пользователи совершают миллионы действий в Интернете. Нам в FACETz DMP необходимо структурировать эти данные и проводить сегментацию для выявления предпочтений пользователей. Хочу рассказать, как мы: - Сегментируем в реальном времени 600 миллионов пользователей ежедневно; - Поставляем данные партнерам, DSP, Google с минимальной задержкой; - Храним статистику по количеству уникальных пользователей в сегменте при потоковой обработке; - Отслеживаем влияние изменения параметров сегментации; - Ведем подсчет аффинитивности домена к сегменту для аналитики аудиторий.

Сегментируем 600 млн. пользователей в режиме реального времени каждый день. H...

Ontico

За последние годы мечты фантастов XX века стали реальностью: смартфоны, видеозвонки, виртуальная реальность и, наконец, Интернет вещей. К сожалению, у прогресса всегда есть темная сторона. Я думаю, ни для кого не секрет, что такие компании как Sony, Yahoo, Adobe, Target и многие другие столкнулись с проблемами безопасности в последние годы. Количество скомпрометированных систем растет день ото дня. Node.js - это одна из самых быстрорастущих экосистем разработки приложений на рынке, которая постепенно перестает быть инструментом для разработки стартапов и проникает в корпоративный сектор. Вы уверены, что ваше приложение, разработанное на базе MEAN-стека, безопасно? В своем докладе я хотел бы рассмотреть данный вопрос. Мы поговорим о криптографии, аутентификации, авторизации, уязвимостях web-приложений, построенных на базе Node.js. К концу доклада вы получите пошаговое руководство, как уменьшить вероятность взлома вашего проекта.

Безопасность Node.js / Илья Вербицкий (Независимый консультант)

Ontico

Исторически сложилось так, что одни люди разрабатывают приложения (Dev), а другие эксплуатируют их в продакшне (Ops). И у последних есть немало проблем с тем, что невозможно понять, что происходит. Причем это касается как собственных разработок, так и популярных open source решений. Я расскажу, как устроена диагностика у некоторых популярных софтин: - nginx - postgresql - mongodb Мы попробуем разобраться, что там сделано хорошо, и чего не хватает для полного счастья. Во второй части доклада мы поговорим про то, как нужно инструментировать собственное приложение для прозрачной работы в продакшне: - что считать и зачем: ошибки, тайминги, разные состояния приложения, - инструментарий: your_lang-metrics, your_lang-statsd-client, логи, - как не перемудрить и не убить прод диагностикой. Может показаться, что этот доклад про DevOps, но нет - про docker не будет ни слова :)

Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)

Ontico

Почти год назад мы завершили проект по универсальному мониторингу и в процессе приобрели кучу секретных знаний и умений, которыми хотим поделиться: * как сделать мониторинг простым, отказоустойчивым и горизонтально масштабируемым; * как понять, что важно, что не важно, а что важно, но чуть-чуть; * полезные логи: конвертация логов в метрики и обратно; * как диагностировать реальные проблемы и отличить их от ложной тревоги (на примере связки js-фронтенд + балансеры + java-бэкенд); * и, конечно же, как внедрить практики DevOps посредством мониторинга (и подготовить разработчиков к тому, что они ответственны за алерты). Стек мониторинга: sensu, graphite, cassandra, logstash, heka, influxdb, elsticsearch, chef, statsd, nginx. Стек поддержки: js, java, erlang, lisp, python, ruby, nginx, mysql, haproxy

Путь мониторинга: модульность, гибкость, devops / Всеволод Поляков (Grammarly)

Ontico

La actualidad más candente (20)