Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

487 views

Published on

Банки.ру — проект с 10-летней историей. В разные времена мы испытывали разные нагрузки. Портал перестраивался под новые требования как логически, так и технологически, что-то мы меняли в авральном режиме, что-то — эволюционным путём. Сейчас в среднем в день у нас примерно 2КК просмотра страниц, т.е. мы уже не маленькие, но ещё и не совсем большие.

Я хочу поговорить об оптимизации, её своевременности, и о субоптимизации, о том, что далеко не всегда лучшие практики разработки нагруженных систем идут на пользу бизнесу.

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

В заключение я расскажу про несколько примеров из жизни banki.ru в части замены технологических решений в области высоких нагрузок, и что из этого вышло.

P.S. Мнение докладчика может не совпадать с вашим, но это его опыт:)

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

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

  1. 1. Всему своё время Роман Ивлиев, CIO, Банки.ру
  2. 2. • Тестировщик • Разработчик • Руководитель разработчиков • Руководитель тестировщиков • Руководитель проектов • CTO • CIO С 2002 года до сих пор
  3. 3. • 11 лет в Интернете; • в среднем 400К уников в сутки; • 40 инженеров; • 70Тб трафика в месяц. О Банки.ру
  4. 4. О чем мы с вами поговорим • HighLoad или неHighload? • Хабрэффект – причина или следствие? • Про «костыли». • Когда начинать делать круто? • Что делать дальше, чтобы не окаменеть.
  5. 5. Highload или неHighload Так ли ваш проект нагружен?
  6. 6. Как понять, highload у вас или нет? • Можно ли понять это по числу серверов? • Можно ли понять это по числу пользователей? • Можно ли понять это по числу запросов? • Можно ли понять это по числу строк в БД?
  7. 7. Как понять, highload у вас или нет? • Сервера справляются с нагрузкой? • Есть необходимость в масштабировании? • Надо ли применять «нестандартные» решения?
  8. 8. Хабрэффект Конец или начало?
  9. 9. Реактивный рост • Скорее всего это какое-то событие • Может быть ожидаемый • Например, реклама • А может быть случайный • Например, реакция на пост на Хабре • Или происки конкурентов
  10. 10. Нужен анализ • Понятно, что сломалось первым? • Почему произошёл рост? • Есть шансы, что это повторится? • Что можно сделать сейчас, чтобы выстоять?
  11. 11. «Костыли» Или высокотехнологичное решение ?
  12. 12. Костыль • Это не всегда плохо; • Это «быстро» решает задачу, НО • Не всегда ловко; • Не всегда технологично; • Почти всегда в нарушение процессов (если они есть); • Теперь вы должны.
  13. 13. Технологичное решение • Это ловко (чаще всего); • Технологично (чаще всего); • Без нарушения процессов (чаще всего), НО • Не всегда быстро; • Не всегда вовремя.
  14. 14. Один из алгоритмов: • Имеет место: • Горит? • Нужен Proof Of Concept? • Шэф психанул? • Прочие факторы ускорения • Костыль! • Сняли боль, но не вылечили проблему • Или вылечили
  15. 15. Когда нужно начинать? Или когда можно начинать?
  16. 16. Как искать точку начала перемен? • Мониторинг с первого дня проекта • Аналитика с первого дня проекта
  17. 17. Рост нагрузки редко бывает линейным • Вот так • 10usr = 10%CPU • 20usr =20%CPU • …. • 100usr=100%CPU • не бывает почти никогда
  18. 18. Рост нагрузки редко бывает линейным • Может случиться вот так • 100usr = 10%CPU • 200usr=100%CPU • Или вот так: • 10usr=10%CPU • 200usr=10%CPU, но 100% IO
  19. 19. Можно найти закономерности? • Безусловно да, но не всегда вы угадаете • Дисковое пространство? - скорее всего да • Поведение СУБД? – скорее всего да • IO, CPU, Net – очень примерно • Помните, что есть про профиль нагрузки
  20. 20. Можно найти закономерности? • Безусловно да, но не всегда вы угадаете • Дисковое пространство? - скорее всего да • Поведение СУБД? – скорее всего да • IO, CPU, Net – очень примерно • Помните про профиль нагрузки • Бойтесь «среднего»
  21. 21. Преждевременная оптимизация • Возможно, вы угадаете; • Но может быть иначе • Лучше потратить время на • Автоматизацию; • Мониторинг; • Работу с технодолгом.
  22. 22. Компонентная оптимизация • Вместо «прокачки» всей системы; • Анализируем узкие места; • Исследуем возможность улучшения; • Улучшаем.
  23. 23. Время и деньги • Наверняка есть бюджет; • Наверняка есть ограничение по людям; • Наверняка у шэфа есть дэдлайн;
  24. 24. Есть ли лёгкий способ? «Список Бунина» подойдёт?
  25. 25. Список «Бунина»? • Сервисно-ориентированная архитектура; • Вертикальное масштабирование; • Горизонтальное масштабирование; • Отложенные вычисления; • Асинхронная обработка; • Конвейерная обработка; • Использование толстого клиента; • Кеширование; • Функциональное разделение; • Шардинг; • Виртуальные шарды; • Центральный диспетчер; • Репликация; • Партиционирование; • Кластеризация; • Денормализация; • Введение избыточности; • Нереляционные СУБД; • Параллельное выполнение • И так далее….
  26. 26. Список «Бунина»? • 20+ паттернов разработки и проектирования • Из них часть реально можно сделать на коленке • Из них ещё часть никогда не будут нужны в вашем проекте • Из них часть никогда не будут нужны во всех ваших проектах
  27. 27. Важно помнить • Нет стандарта на разработку высоконагруженных систем; • Не всё нужно здесь и сейчас; • Иногда простое решение самое эффективное; • То, что сделал Badoo, наверняка не для вас; • Hype – бойтесь его.
  28. 28. Hype – это • Интересно (почти всегда); • Полезно (почти всегда); • Риски (всегда!) • Много новой документации; • Проект может закрыться; • Баги продукта станут вашими проблемами; • Поддержка стоит денег и времени; • Сложности поиска людей; • Зоопарк.
  29. 29. Как работать с тех.долгом? Планомерно достаём «костыли»
  30. 30. Работа с тех.долгом • 1 «костыль» = 1 задача в долг; • Долг – полноправный участник планирования; • Долг - полноправный по приоритетам; • Регулярный просмотр и актуализация долга;
  31. 31. Важно! • Время не на вашей стороне; • Технологии не на вашей стороне; • Бизнес не на вашей стороне; • Вас ждёт «технический дефолт».
  32. 32. Заключение Необходимость и достаточность
  33. 33. Двигайтесь вперёд • Следите за системой; • Изучайте узкие места; • Оценивайте риски; • Пробуйте на кошках; • Внедряйте.
  34. 34. Прикрывайте тыл • Стабильность; • Прозрачность; • Гибкость; • Свежие версии того, что вы уже используете.
  35. 35. «Слова вы услышали, поиск пути за вами» Уильям Деминг
  36. 36. С удовольствием отвечу на Ваши вопросы @dumtest roman@ivliev.info roman.ivliyev

×