Всему своё время / Роман Ивлиев (Банки.ру)

Всему своё время Роман Ивлиев, CIO, Банки.ру

• Тестировщик

• Разработчик

• Руководитель разработчиков

• Руководитель тестировщиков

• Руководитель проектов

• CTO

• CIO

С 2002 года до сих пор

• 11 лет в Интернете;

• в среднем 400К уников в сутки;

• 40 инженеров;

• 70Тб трафика в месяц.

О Банки.ру

О чем мы с вами поговорим

• HighLoad или неHighload?

• Хабрэффект – причина или следствие?

• Про «костыли».

• Когда начинать делать круто?

• Что делать дальше, чтобы не окаменеть.

Highload или неHighload

Так ли ваш проект нагружен?

Как понять, highload у вас или нет?

• Можно ли понять это по числу серверов?

• Можно ли понять это по числу пользователей?

• Можно ли понять это по числу запросов?

• Можно ли понять это по числу строк в БД?

Как понять, highload у вас или нет?

• Сервера справляются с нагрузкой?

• Есть необходимость в масштабировании?

• Надо ли применять «нестандартные» решения?

Хабрэффект

Конец или начало?

Реактивный рост

• Скорее всего это какое-то событие

• Может быть ожидаемый

• Например, реклама

• А может быть случайный

• Например, реакция на пост на Хабре

• Или происки конкурентов

Нужен анализ

• Понятно, что сломалось первым?

• Почему произошёл рост?

• Есть шансы, что это повторится?

• Что можно сделать сейчас, чтобы выстоять?

«Костыли»

Или высокотехнологичное решение ?

Костыль

• Это не всегда плохо;

• Это «быстро» решает задачу, НО

• Не всегда ловко;

• Не всегда технологично;

• Почти всегда в нарушение процессов (если они есть);

• Теперь вы должны.

Технологичное решение

• Это ловко (чаще всего);

• Технологично (чаще всего);

• Без нарушения процессов (чаще всего), НО

• Не всегда быстро;

• Не всегда вовремя.

Один из алгоритмов:

• Имеет место:

• Горит?

• Нужен Proof Of Concept?

• Шэф психанул?

• Прочие факторы ускорения

• Костыль!

• Сняли боль, но не вылечили проблему

• Или вылечили

Когда нужно начинать?

Или когда можно начинать?

Как искать точку начала перемен?

• Мониторинг с первого дня проекта

• Аналитика с первого дня проекта

Рост нагрузки редко бывает линейным

• Вот так

• 10usr = 10%CPU

• 20usr =20%CPU

• ….

• 100usr=100%CPU

• не бывает почти никогда

Рост нагрузки редко бывает линейным

• Может случиться вот так

• 100usr = 10%CPU

• 200usr=100%CPU

• Или вот так:

• 10usr=10%CPU

• 200usr=10%CPU, но 100% IO

Можно найти закономерности?

• Безусловно да, но не всегда вы угадаете

• Дисковое пространство? - скорее всего да

• Поведение СУБД? – скорее всего да

• IO, CPU, Net – очень примерно

• Помните, что есть про профиль нагрузки

Можно найти закономерности?

• Безусловно да, но не всегда вы угадаете

• Дисковое пространство? - скорее всего да

• Поведение СУБД? – скорее всего да

• IO, CPU, Net – очень примерно

• Помните про профиль нагрузки

• Бойтесь «среднего»

Преждевременная оптимизация

• Возможно, вы угадаете;

• Но может быть иначе

• Лучше потратить время на

• Автоматизацию;

• Мониторинг;

• Работу с технодолгом.

Компонентная оптимизация

• Вместо «прокачки» всей системы;

• Анализируем узкие места;

• Исследуем возможность улучшения;

• Улучшаем.

Время и деньги

• Наверняка есть бюджет;

• Наверняка есть ограничение по людям;

• Наверняка у шэфа есть дэдлайн;

Есть ли лёгкий способ?

«Список Бунина» подойдёт?

Список «Бунина»?

• Сервисно-ориентированная архитектура;

• Вертикальное масштабирование;

• Горизонтальное масштабирование;

• Отложенные вычисления;

• Асинхронная обработка;

• Конвейерная обработка;

• Использование толстого клиента;

• Кеширование;

• Функциональное разделение;

• Шардинг;

• Виртуальные шарды;

• Центральный диспетчер;

• Репликация;

• Партиционирование;

• Кластеризация;

• Денормализация;

• Введение избыточности;

• Нереляционные СУБД;

• Параллельное выполнение

• И так далее….

Список «Бунина»?

• 20+ паттернов разработки и проектирования

• Из них часть реально можно сделать на коленке

• Из них ещё часть никогда не будут нужны в вашем проекте

• Из них часть никогда не будут нужны во всех ваших проектах

Важно помнить

• Нет стандарта на разработку высоконагруженных систем;

• Не всё нужно здесь и сейчас;

• Иногда простое решение самое эффективное;

• То, что сделал Badoo, наверняка не для вас;

• Hype – бойтесь его.

Hype – это

• Интересно (почти всегда);

• Полезно (почти всегда);

• Риски (всегда!)

• Много новой документации;

• Проект может закрыться;

• Баги продукта станут вашими проблемами;

• Поддержка стоит денег и времени;

• Сложности поиска людей;

• Зоопарк.

Как работать с тех.долгом?

Планомерно достаём «костыли»

Работа с тех.долгом

• 1 «костыль» = 1 задача в долг;

• Долг – полноправный участник планирования;

• Долг - полноправный по приоритетам;

• Регулярный просмотр и актуализация долга;

Важно!

• Время не на вашей стороне;

• Технологии не на вашей стороне;

• Бизнес не на вашей стороне;

• Вас ждёт «технический дефолт».

Заключение

Необходимость и достаточность

Двигайтесь вперёд

• Следите за системой;

• Изучайте узкие места;

• Оценивайте риски;

• Пробуйте на кошках;

• Внедряйте.

Прикрывайте тыл

• Стабильность;

• Прозрачность;

• Гибкость;

• Свежие версии того, что вы уже используете.

«Слова вы услышали, поиск пути за вами» Уильям Деминг

С удовольствием отвечу на Ваши вопросы

@dumtest

[email protected]

roman.ivliyev