PPTX, 3 МБ

Типичные ошибки и проблемы
при построении
отказоустойчивости и
масштабирования и их
решение
Евгений Потапов
• Круглосуточное
администрирование и
техническая поддержка вебсайтов
• 100 миллионов уникальных
посетителей в сутки
• Штат – 50 человек
• Офисы – Иркутск, СанктПетербург
На поддержке
Содержание
๏Как растет нагрузка? Что именно надо
масштабировать?
๏Способы масштабирования нагрузки
๏Способы построения отказоустойчивости
๏Проблемы, которые возникают при
построении отказоустойчивых и
масштабируемых систем.
๏Все это чуть чуть с примерами как это
происходит
Как растут нагрузки?
๏Плановый рост посещаемости
๏Всплески траффика – внезапные
(промокампании)
๏Всплески траффика – ожидаемые
(высокий сезон)
Как растут нагрузки?
Плановый рост посещаемости
Можем предсказать рост на ближайшие месяцы и оценить потребности в ресурсах
Как растут нагрузки
Плановый рост посещаемости
Специфика принятия решений
๏Возможность запланировать аппаратные
ресурсы: «через два месяца у нас будет в
два раза больше траффика»
๏Возможность подготовить кодовую базу к
масштабированию
๏Все изменения принимаются планово,
имеется возможность хорошо
протестировать
๏Бывает редко 
Как растут нагрузки
Внезапные всплески траффика
Рост нагрузки в 2 раза за 30 минут
Как растут нагрузки
Внезапные всплески траффика
Рост нагрузки в 2 раза за 30 минут
Как растут нагрузки
Внезапные всплески траффика
Специфика принятия решений
๏Очень резкий всплеск посещаемости – от
роста нагрузки до предела возможностей минуты
๏Приток траффика не постоянный и не дает
возможности заложить большой срок
разработки
๏При такой скорости изменений велик риск
допустить ошибку
Масштабирование – немного ликбеза
Масштабирование – немного ликбеза
Вертикальное масштабирование
Увеличиваем возможности системы,
увеличивая аппаратные характеристики в
пределах одного сервера:
Технически просто, но часто – не даст
многократный запас
Масштабирование – немного ликбеза
Горизонтальное масштабирование
Увеличиваем возможности системы,
добавляя новые серверы и балансируя
нагрузку между ними
Позволяет неограниченно увеличивать
ресурсы системы, но требует
вмешательства в архитектуру
Вертикальное масштабирование –
гибридное облако
๏Большую часть времени проект работает на
основном «железе»
๏В облаках подготовлен сервер минимальной
конфигурации
๏В случае пиковой нагрузки или аварии
сервер в облаках масштабируется,
посетители переводятся на него
Гибридное облако – стандартный режим
Гибридное облако – увеличение
посещаемости
Гибридное облако – масштабирование
облака
Гибридное облако – перевод пользователей
(смена DNS)
Гибридное облако – работа под нагрузкой
Гибридное облако – снижение нагрузки
Гибридное облако – перевод пользователей
обратно
Гибридное облако – снижение
конфигурации облака
Вертикальное масштабирование проблемы
Рано или поздно – ресурсы будут
исчерпаны, а масштабировать дальше уже не получится
При этом, чаще всего, рост нагрузки не пропорционален росту посещаемости
Вертикальное масштабирование При этом сайт становится недоступным
для всех пользователей
проблемы
(не только для той части что превысила возможности системы)
Горизонтальное масштабирование – что
масштабируется
Чаще всего:
๏Нагрузка на веб-приложение – CPU
๏Производительность базы данных –
CPU/диски
๏Объем статических данных – место на
диске
Масштабирование веб-серверов
Горизонтальное масштабирование
веб-приложения
Главные проблемы
๏Сессии
๏Синхронность обновлений кода
๏Контроль ошибок
Горизонтальное масштабирование
веб-приложения
Единое место хранения сессий - проблемы
Если один серверов пула «потеряет»
центральное хранилище сессий и будет
работать сам по себе – проверяющий
(или мониторинг) может не обнаружить
проблему, а последовательность
действий пользователя будет обрываться
Горизонтальное масштабирование
веб-приложения
Единое место хранения сессий
Горизонтальное масштабирование
веб-приложения
Единое место хранения сессий - проблемы
Горизонтальное масштабирование
веб-приложения
Синхронизация обновлений кода - проблемы
Если один серверов пула не получит
новую версию кода – проверяющий (или
мониторинг) может не обнаружить
проблему, пользователь может получить
старую версию сайта, а код может
повредить всю систему в целом, работая
со старыми схемами БД
Горизонтальное масштабирование
веб-приложения
Синхронизация обновлений кода
Горизонтальное масштабирование
веб-приложения
Синхронизация обновлений кода - проблемы
Горизонтальное масштабирование
веб-приложения
Ошибки в веб-приложении - проблемы
Если один серверов в результате ошибки
конфигурации (кончилось место,
неправильно настроен софт)/самого
приложения (PHP – ошибки
apc/eaccelerator, падения пула бэкэнда)
приложение на одном из бэкэндов упало
– мониторинг может не обнаружить
проблемы
Горизонтальное масштабирование
веб-приложения
Ошибки в веб-приложении - проблемы
Горизонтальное масштабирование
веб-приложения
Ошибки связанные с масштабированием веб-приложения
решения
๏Система мониторинга должна внешне
проверять каждый из узлов пула вебсерверов в отдельности
๏Каждая такая проверка должна включать
проверку существования сессии и
возможность выполнения критичных для
сайта пользовательских действий
๏Необходим мониторинг журналов ошибок
на каждом сервере с оповещениями о
всплесках ошибок на каком-либо из них
Горизонтальное масштабирование
веб-приложения
Ошибки связанные с масштабирование веб-приложения
решения – индивидуальный мониторинг
Горизонтальное масштабирование
веб-приложения
Ошибки связанные с масштабирование веб-приложения
решения – сбор количества 5xx ошибок
Горизонтальное масштабирование
Базы данных
๏Ошибки связанные с репликацией целостность репликации
๏Ошибки связанные с репликацией время синхронизации данных
๏Ошибки связанные с шардингом распределение данных
Горизонтальное масштабирование
Базы данных
Целостность репликации данных - проблемы
При балансировке чтения базы
репликацией нормальный статус
репликации еще не означает
синхронизации всех данных и рабочей
репликации
Горизонтальное масштабирование
Базы данных
Целостность репликации данных - проблемы
Горизонтальное масштабирование
Базы данных
Целостность репликации данных - проблемы
Горизонтальное масштабирование
Базы данных
Целостность репликации данных - проблемы
Горизонтальное масштабирование
Базы данных
Целостность репликации данных - проблемы
Горизонтальное масштабирование
Базы данных
Время синхронизации данных - проблемы
Запись созданная в мастер-БД не
моментально окажется в БД,
принимающей репликацию. Если
пользователь пишет в мастер, а затем
сразу читает из слейва – есть шанс, что
записи там не будет
Горизонтальное масштабирование
Базы данных
Время синхронизации данных - проблемы
Горизонтальное масштабирование
Базы данных
Время синхронизации данных - проблемы
Горизонтальное масштабирование
Базы данных
Время синхронизации данных - проблемы
Горизонтальное масштабирование
Базы данных
Время синхронизации данных - проблемы
Горизонтальное масштабирование
Базы данных
Ошибки связанные с репликацией
решения
๏Следует следить не только за работой
репликации но и за идентичностью данных на
серверах БД(контрольные суммы критических
таблиц)
๏Не следует пытаться читать только что
записанные данные, это должно быть некое
неизменное в короткое время ядро (например
каталог товаров)
๏Если необходимо масштабировать
пользовательский контент, который часто
обновляется – лучше использовать шардинг
Горизонтальное масштабирование
Базы данных
Ошибки связанные с шардингом - проблемы
๏В случае, если один из shard-серверов
упадет или начнет медленнее отвечать,
система мониторинга может не отследить
такую аварию – запросы могут попадать на
остальные серверы
๏Неправильно выбранная архитектура
распределения данных может привести к
тому, что вся нагрузка ляжет только на один
из серверов, а остальные будут
простаивать
Горизонтальное масштабирование
Базы данных
Ошибки связанные с шардингом – медленный шард
Горизонтальное масштабирование
Базы данных
Ошибки связанные с шардингом – медленный шард
Горизонтальное масштабирование
Базы данных
Ошибки связанные с шардингом - решения
๏Индивидуальный мониторинг работы
каждого shard-сервера. Если серверы
разделены по пользователям –
создание тестового пользователя для
каждого shard-сервера.
๏Мониторинг ошибок приложения
๏Мониторинг нагрузки и количества
данных на shard-серверах
Горизонтальное масштабирование
другие вопросы
๏Синхронизация статических
данных/распределенные файловые
системы
๏Контроль целостности данных при failoverе.
๏Централизация важных функций на одном
из серверов
๏Проблемы связанные с масштабированием
кэширования
Выводы
๏Основной способ защитится – грамотно
настроенный мониторинг
๏Фатальность ошибки обратно
пропорционально скорости реакции
๏Один раз настроить – нельзя, нужна
постоянная диагностика
Типичные ошибки при построении
масштабирования и отказоустойчивости и
их решения
Евгений Потапов
http://itsumma.ru
eapotapov@itsumma.ru
http://facebook.com/eapotapov