Работа в высоконагруженных проектах всегда была такой сферой деятельности, где можно в рамках решения прикладных задач находить и применять сложные и интересные решения.
К сожалению, очень часто во главу угла ставится не надежное решение поставленной задачи, а именно применение сложного и интересного решения, которое даст специалисту новый опыт и удовольствие от сложных архитектур.
В своем докладе я хочу пройтись по тем стандартным "набитым шишкам", которые мы встречаем в своей работе, когда сложное, новое и интересное решение не означает стабильность системы.
1. Когда "интересно" не значит "правильно"?
1.1. Специфика развития высоконагруженного проекта.
1.2. Требования бизнеса и современные технологии.
1.3. Типичные "сомнительные" решения.
2. Проблемы в архитектуре отказоустойчивых систем.
2.1. Ошибки в планировании резервирования.
2.2. Ошибки в планировании системы выкладок.
2.3. Ошибки в архитектурах систем хранения данных.
3. Проблемы в архитектуре систем, рассчитанных на высокую нагрузку.
3.1. Ошибки в планировании мощностей системы.
3.2. Ошибки в планировании возможностей масштабирования системы.
3.3. Ошибки в архитектурах систем хранения данных.
3. О нас
Антон Баранов
ITSumma, начальник отдела по работе с
клиентами
В прошлом - системный администратор Linux.
Более 7 лет опыта работы с Linux-системами и
web-проектами различной сложности.
Последние три года тружусь над
обеспечением стабильной работы highload-
проектов для посетителей со всего мира.
4. • Работаем с 2008 года
• Штат 60 человек
• Офисы в Иркутске, Санкт-
Петербурге и Москве
• Более 200 клиентов
• 100 активных чатов в день
• 150000 оповещений в
месяц
ITSumma
8. Главные причины аварий
•Ошибки в работе, связанные с новыми
версиями приложения
•Проблемы, связанные с ростом нагрузки и
масштабированием
9. Главные причины аварий
•Ошибки в работе, связанные с новыми
версиями приложения
•Проблемы, связанные с ростом нагрузки и
масштабированием
•Аварии, связанные с ошибками
планирования архитектуры проекта
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 часов
24. Небольшой проект
…но и там бывают проблемы
Горизонтальное масштабирование и
резервирование проекта:
•Балансировка web-инстансов
•Балансировка нагрузки на БД
28. Небольшой проект
За чем следить:
• Мониторинг статуса реплики
• Мониторинг отставания репликации
• Мониторинг консистентности репликации
синхронная репликация не панацея
29. Несколько web-серверов – единый балансировщик
Проект F: падение балансировщика приводит к падению всего проекта
30. Несколько web-серверов – единый балансировщик
Проект F: падение узла без failover портит весь трафик (а не треть)
41. Средний проект
Ошибки системы деплоя:
•Различие dev и prod баз данных по количеству
данных
•Не учитывается нагрузка на prod
42. Средний проект
Ошибки системы деплоя:
•Различие dev и prod баз данных по количеству
данных
•Не учитывается нагрузка на prod
•Разные конфигурации ПО dev и prod серверов
43. Средний проект
Ошибки системы деплоя:
•Различие dev и prod баз данных по количеству
данных
•Не учитывается нагрузка на prod
•Разные конфигурации ПО dev и prod серверов
•Разное «железо» у stage и prod
51. Крупный проект
•Любовь к новым технологиям и
«построению архитектур»
•Безоговорочная вера в автоматизацию
•Отсутствие регулярных аудитов
производительности
52. Крупный проект
«Любовь к новым технологиям»
•«мы хотим как-то использовать докер и
консул в своем проекте»
53. Крупный проект
«Любовь к новым технологиям»
•«мы хотим как-то использовать докер и
консул в своем проекте»
•«обновление конфигурации только через
chef»
54. Крупный проект
«Любовь к новым технологиям»
•«мы хотим как-то использовать докер и
консул в своем проекте»
•«обновление конфигурации только через
chef»
•«давайте сделаем кластер»
55. Крупный проект
«Любовь к новым технологиям» - как жить?
• Нельзя использовать технологии ради технологий
• Простые действия становятся сложными – об этом
надо помнить
57. Крупный проект
Вера в автоматизацию
• «Наш кластер будет отказоустойчивым»
• «Оно само перебалансируется в случае аварии»
58. Крупный проект
Вера в автоматизацию
• «Наш кластер будет отказоустойчивым»
• «Оно само перебалансируется в случае аварии»
• «Наш стек технологий полностью исключает такую
ситуацию»
60. Крупный проект
Не забываем про оптимизацию:
•1 страница – 8000 запросов к SQL
•Частые деплои – отсутствие профилирования
•Отсутствует регулярный аудит
производительности