1. Преждевременная
оптимизация архитектуры
Евгений Потапов
Антон Баранов

2. Евгений Потапов
ITSumma, генеральный директор
15 лет опыта системного
администрирования
Компания основана в 2008 году
О нас

3. О нас
Антон Баранов
ITSumma, начальник отдела по работе с
клиентами
В прошлом - системный администратор Linux.
Более 7 лет опыта работы с Linux-системами и
web-проектами различной сложности.
Последние три года тружусь над
обеспечением стабильной работы highload-
проектов для посетителей со всего мира.

4. • Работаем с 2008 года
• Штат 60 человек
• Офисы в Иркутске, Санкт-
Петербурге и Москве
• Более 200 клиентов
• 100 активных чатов в день
• 150000 оповещений в
месяц
ITSumma

6. Откуда берется беда?

7. Главные причины аварий
•Ошибки в работе, связанные с новыми
версиями приложения

8. Главные причины аварий
•Ошибки в работе, связанные с новыми
версиями приложения
•Проблемы, связанные с ростом нагрузки и
масштабированием

9. Главные причины аварий
•Ошибки в работе, связанные с новыми
версиями приложения
•Проблемы, связанные с ростом нагрузки и
масштабированием
•Аварии, связанные с ошибками
планирования архитектуры проекта

10. Ошибки планирования архитектуры

11. Ошибки планирования архитектуры
• Новые решения создают дополнительную сложность

12. Ошибки планирования архитектуры
• Новые решения создают дополнительную сложность
• Сложность уменьшает надежность эксплуатации

13. Ошибки планирования архитектуры
• Новые решения создают дополнительную сложность
• Сложность уменьшает надежность эксплуатации
• Закон Луссера

14. Закон Луссера
надёжность ракеты равна произведению
надёжности всех компонентов, а не надёжности
самого ненадёжного элемента

15. Закон Луссера

16. Причины создания сложности
•Решение для данной проблемы уникальное

17. Причины создания сложности
•Решение для данной проблемы уникальное
•О существующем решении не известно

18. Причины создания сложности
•Решение для данной проблемы уникальное
•О существующем решении не известно
•Решение известно, но оно неинтересное

20. Небольшой проект
Ожидаемая посещаемость после старта
проекта
3000 – 5000 RPS

21. Небольшой проект
«Облако – это очень надежно»
Падения Amazon Web Services:
21 апреля 2011 года: US East – 53 часа
7 августа 2011 года: EU West – 36 часов
29 июня 2012 года: US East – 7 часов
20 сентября 2015 года: US East – 5 часов
4 июня 2016 года: AWS Sydney – 5 часов

22. Небольшой проект
«Облако масштабируется»
Большинство хостингов в РФ – 12 ядер, максимум 24 –
дальше – горизонтальное масштабирование

23. Небольшой проект
Проще и надежнее железного сервера ничего нет

24. Небольшой проект
…но и там бывают проблемы
Горизонтальное масштабирование и
резервирование проекта:
•Балансировка web-инстансов
•Балансировка нагрузки на БД

25. Небольшой проект
Проект T: резервные инстансы находятся на одних и тех же физических серверах

26. Небольшой проект
Резервирование
•Резервная площадка должна быть в другом
ЦОДе
•Виртуализация добавляет осложнений
•Резерв это не бэкап

27. Распределение нагрузки между БД
Проект Х: пост не успевает появиться в списке после создания записи

28. Небольшой проект
За чем следить:
• Мониторинг статуса реплики
• Мониторинг отставания репликации
• Мониторинг консистентности репликации
синхронная репликация не панацея

29. Несколько web-серверов – единый балансировщик
Проект F: падение балансировщика приводит к падению всего проекта

30. Несколько web-серверов – единый балансировщик
Проект F: падение узла без failover портит весь трафик (а не треть)

31. Небольшой проект
Несколько web-серверов – общие данные –
NFS
•Простое, понятное решение
•Нет проблем с синхронизацией данных
•Понятная настройка

32. Небольшой проект
Проблемы с NFS:
•Сбой связи между NFS-сервером и web-
сервером
•Восстановление работоспособности требует
перезагрузки

33. Небольшой проект
Деплой
•Git pull – неинтересно
•CI – очень интересно

34. Небольшой проект
Деплой
•CI – необходим контроль информационной
схемы
•CI – overhead на внедрение
•CI – дополнительная сложность во время
деплоя

35. Средний проект
Выбор замены для NFS:
CEPH? Слишком сложно, а для
конфигурирования, нет времени
- MOOSEFS!

36. Средний проект
MooseFS
•Всё идеально, но…

37. Средний проект
MooseFS
•Сбой по питанию

38. Средний проект

39. Средний проект
Выбор решения для хранения данных -
вопрос открытый

40. Средний проект
Ошибки системы деплоя:
•Различие dev и prod баз данных по количеству
данных

41. Средний проект
Ошибки системы деплоя:
•Различие dev и prod баз данных по количеству
данных
•Не учитывается нагрузка на prod

42. Средний проект
Ошибки системы деплоя:
•Различие dev и prod баз данных по количеству
данных
•Не учитывается нагрузка на prod
•Разные конфигурации ПО dev и prod серверов

43. Средний проект
Ошибки системы деплоя:
•Различие dev и prod баз данных по количеству
данных
•Не учитывается нагрузка на prod
•Разные конфигурации ПО dev и prod серверов
•Разное «железо» у stage и prod

44. Высокая нагрузка на БД

45. Средний проект
На что надеемся?
•Апгрейд «железа» вместо оптимизации
запросов к БД

46. Средний проект
На что надеемся?
•Апгрейд «железа» вместо оптимизации
запросов к БД
•«Тюнинг сервера»

47. Средний проект
На что надеемся?
•Апгрейд «железа» вместо оптимизации
запросов к БД
•«Тюнинг сервера»
•Переход на другую БД

48. Средний проект
•Сбор статистики и анализ долгих запросов

49. Средний проект
•Сбор статистики и анализ долгих запросов
•Сбор статистики по числу запросов

50. Средний проект
•Сбор статистики и анализ долгих запросов
•Сбор статистики по числу запросов
•Кластеризация данных

51. Крупный проект
•Любовь к новым технологиям и
«построению архитектур»
•Безоговорочная вера в автоматизацию
•Отсутствие регулярных аудитов
производительности

52. Крупный проект
«Любовь к новым технологиям»
•«мы хотим как-то использовать докер и
консул в своем проекте»

53. Крупный проект
«Любовь к новым технологиям»
•«мы хотим как-то использовать докер и
консул в своем проекте»
•«обновление конфигурации только через
chef»

54. Крупный проект
«Любовь к новым технологиям»
•«мы хотим как-то использовать докер и
консул в своем проекте»
•«обновление конфигурации только через
chef»
•«давайте сделаем кластер»

55. Крупный проект
«Любовь к новым технологиям» - как жить?
• Нельзя использовать технологии ради технологий
• Простые действия становятся сложными – об этом
надо помнить

56. Крупный проект
Вера в автоматизацию
• «Наш кластер будет отказоустойчивым»

57. Крупный проект
Вера в автоматизацию
• «Наш кластер будет отказоустойчивым»
• «Оно само перебалансируется в случае аварии»

58. Крупный проект
Вера в автоматизацию
• «Наш кластер будет отказоустойчивым»
• «Оно само перебалансируется в случае аварии»
• «Наш стек технологий полностью исключает такую
ситуацию»

59. Вера в автоматизацию - как жить?

60. Крупный проект
Не забываем про оптимизацию:
•1 страница – 8000 запросов к SQL
•Частые деплои – отсутствие профилирования
•Отсутствует регулярный аудит
производительности

61. Бомба замедленного действия:
Проект К: рост нагрузки на CPU не пропорционален росту траффика

62. Бомба замедленного действия:
Проект К: каждый деплой немного увеличивает время ответа

63. Вместо выводов
•Не все новое – хорошее

64. Вместо выводов
•Не все новое – хорошее
•Не все интересное – нужное

65. Вместо выводов
•Не все новое – хорошее
•Не все интересное – нужное
•Не все крутое – полезное

66. Вместо выводов
•Не все новое – хорошее
•Не все интересное – нужное
•Не все крутое – полезное
•Во многой мудрости много печали

67. Евгений Потапов
http://facebook.com/eapotapov
eapotapov@itsumma.ru
Антон Баранов
https://www.facebook.com/anton.s.baranov
abaranov@itsumma.ru
http://itsumma.ru
Вопросы?