Successfully reported this slideshow.
Your SlideShare is downloading. ×

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

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 42 Ad

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

Download to read offline

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

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

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

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

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

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

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

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

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

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

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Advertisement

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

More from Ontico (20)

Advertisement

Recently uploaded (19)

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

  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

×