Банки.ру — проект с 10-летней историей. В разные времена мы испытывали разные нагрузки. Портал перестраивался под новые требования как логически, так и технологически, что-то мы меняли в авральном режиме, что-то — эволюционным путём. Сейчас в среднем в день у нас примерно 2КК просмотра страниц, т.е. мы уже не маленькие, но ещё и не совсем большие. Я хочу поговорить об оптимизации, её своевременности, и о субоптимизации, о том, что далеко не всегда лучшие практики разработки нагруженных систем идут на пользу бизнесу. Посмотрим примеры и поищем ответы на вопросы: 1) Настолько ли ваш highload — highload? 2) Считать ли хабрэффект поводом для внедрения высоких технологий? 3) "Костыль" или "высокотехнологичное решение" — что выбрать? Плюсы и минусы. 4) Как выбрать момент для начала новой эры? Есть ли критерии, когда имеет смысл начинать оптимизировать ваше приложение и внедрять крутые штуки "по-взрослому". 5) Как можно использовать "список Бунина" для достижения очень неплохих показателей, и все ли пункты реально нужны вам? 6) Как работать с тех. долгом, чтобы он не зарастал мхом? В заключение я расскажу про несколько примеров из жизни banki.ru в части замены технологических решений в области высоких нагрузок, и что из этого вышло. P.S. Мнение докладчика может не совпадать с вашим, но это его опыт:)

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

2. • Тестировщик
• Разработчик
• Руководитель разработчиков
• Руководитель тестировщиков
• Руководитель проектов
• CTO
• CIO
С 2002 года до сих пор

3. • 11 лет в Интернете;
• в среднем 400К уников в сутки;
• 40 инженеров;
• 70Тб трафика в месяц.
О Банки.ру

4. О чем мы с вами поговорим
• HighLoad или неHighload?
• Хабрэффект – причина или следствие?
• Про «костыли».
• Когда начинать делать круто?
• Что делать дальше, чтобы не окаменеть.

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

7. Как понять, highload у вас или нет?
• Можно ли понять это по числу серверов?
• Можно ли понять это по числу пользователей?
• Можно ли понять это по числу запросов?
• Можно ли понять это по числу строк в БД?

8. Как понять, highload у вас или нет?
• Сервера справляются с нагрузкой?
• Есть необходимость в масштабировании?
• Надо ли применять «нестандартные» решения?

9. Хабрэффект
Конец или начало?

10. Реактивный рост
• Скорее всего это какое-то событие
• Может быть ожидаемый
• Например, реклама
• А может быть случайный
• Например, реакция на пост на Хабре
• Или происки конкурентов

12. Нужен анализ
• Понятно, что сломалось первым?
• Почему произошёл рост?
• Есть шансы, что это повторится?
• Что можно сделать сейчас, чтобы выстоять?

13. «Костыли»
Или высокотехнологичное решение ?

14. Костыль
• Это не всегда плохо;
• Это «быстро» решает задачу, НО
• Не всегда ловко;
• Не всегда технологично;
• Почти всегда в нарушение процессов (если они есть);
• Теперь вы должны.

15. Технологичное решение
• Это ловко (чаще всего);
• Технологично (чаще всего);
• Без нарушения процессов (чаще всего), НО
• Не всегда быстро;
• Не всегда вовремя.

16. Один из алгоритмов:
• Имеет место:
• Горит?
• Нужен Proof Of Concept?
• Шэф психанул?
• Прочие факторы ускорения
• Костыль!
• Сняли боль, но не вылечили проблему
• Или вылечили

17. Когда нужно начинать?
Или когда можно начинать?

18. Как искать точку начала перемен?
• Мониторинг с первого дня проекта
• Аналитика с первого дня проекта

19. Рост нагрузки редко бывает линейным
• Вот так
• 10usr = 10%CPU
• 20usr =20%CPU
• ….
• 100usr=100%CPU
• не бывает почти никогда

20. Рост нагрузки редко бывает линейным
• Может случиться вот так
• 100usr = 10%CPU
• 200usr=100%CPU
• Или вот так:
• 10usr=10%CPU
• 200usr=10%CPU, но 100% IO

21. Можно найти закономерности?
• Безусловно да, но не всегда вы угадаете
• Дисковое пространство? - скорее всего да
• Поведение СУБД? – скорее всего да
• IO, CPU, Net – очень примерно
• Помните, что есть про профиль нагрузки

23. Можно найти закономерности?
• Безусловно да, но не всегда вы угадаете
• Дисковое пространство? - скорее всего да
• Поведение СУБД? – скорее всего да
• IO, CPU, Net – очень примерно
• Помните про профиль нагрузки
• Бойтесь «среднего»

25. Преждевременная оптимизация
• Возможно, вы угадаете;
• Но может быть иначе
• Лучше потратить время на
• Автоматизацию;
• Мониторинг;
• Работу с технодолгом.

26. Компонентная оптимизация
• Вместо «прокачки» всей системы;
• Анализируем узкие места;
• Исследуем возможность улучшения;
• Улучшаем.

27. Время и деньги
• Наверняка есть бюджет;
• Наверняка есть ограничение по людям;
• Наверняка у шэфа есть дэдлайн;

28. Есть ли лёгкий способ?
«Список Бунина» подойдёт?

29. Список «Бунина»?
• Сервисно-ориентированная
архитектура;
• Вертикальное масштабирование;
• Горизонтальное масштабирование;
• Отложенные вычисления;
• Асинхронная обработка;
• Конвейерная обработка;
• Использование толстого клиента;
• Кеширование;
• Функциональное разделение;
• Шардинг;
• Виртуальные шарды;
• Центральный диспетчер;
• Репликация;
• Партиционирование;
• Кластеризация;
• Денормализация;
• Введение избыточности;
• Нереляционные СУБД;
• Параллельное выполнение
• И так далее….

31. Список «Бунина»?
• 20+ паттернов разработки и проектирования
• Из них часть реально можно сделать на
коленке
• Из них ещё часть никогда не будут нужны в
вашем проекте
• Из них часть никогда не будут нужны во всех
ваших проектах

32. Важно помнить
• Нет стандарта на разработку высоконагруженных
систем;
• Не всё нужно здесь и сейчас;
• Иногда простое решение самое эффективное;
• То, что сделал Badoo, наверняка не для вас;
• Hype – бойтесь его.

33. Hype – это
• Интересно (почти всегда);
• Полезно (почти всегда);
• Риски (всегда!)
• Много новой документации;
• Проект может закрыться;
• Баги продукта станут вашими проблемами;
• Поддержка стоит денег и времени;
• Сложности поиска людей;
• Зоопарк.

34. Как работать с тех.долгом?
Планомерно достаём «костыли»

35. Работа с тех.долгом
• 1 «костыль» = 1 задача в долг;
• Долг – полноправный участник планирования;
• Долг - полноправный по приоритетам;
• Регулярный просмотр и актуализация долга;

36. Важно!
• Время не на вашей стороне;
• Технологии не на вашей стороне;
• Бизнес не на вашей стороне;
• Вас ждёт «технический дефолт».

37. Заключение
Необходимость и достаточность

39. Двигайтесь вперёд
• Следите за системой;
• Изучайте узкие места;
• Оценивайте риски;
• Пробуйте на кошках;
• Внедряйте.

40. Прикрывайте тыл
• Стабильность;
• Прозрачность;
• Гибкость;
• Свежие версии того, что вы уже используете.

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

42. С удовольствием отвечу на Ваши вопросы
@dumtest
roman@ivliev.info
roman.ivliyev