Слайд 1Типичные ошибки и проблемы при построении отказоустойчивости и масштабирования и
их решение
Слайд 2Евгений Потапов
Круглосуточное администрирование и техническая поддержка веб-сайтов
100 миллионов уникальных посетителей
в сутки
Штат – 50 человек
Офисы – Иркутск, Санкт-Петербург
Слайд 4Содержание
Как растет нагрузка? Что именно надо масштабировать?
Способы масштабирования нагрузки
Способы построения
отказоустойчивости
Проблемы, которые возникают при построении отказоустойчивых и масштабируемых систем.
Все это
чуть чуть с примерами как это происходит
Слайд 5Как растут нагрузки?
Плановый рост посещаемости
Всплески траффика – внезапные (промокампании)
Всплески траффика
– ожидаемые (высокий сезон)
Слайд 6Плановый рост посещаемости
Можем предсказать рост на ближайшие месяцы и оценить
потребности в ресурсах
Как растут нагрузки?
Слайд 7Как растут нагрузки
Возможность запланировать аппаратные ресурсы: «через два месяца у
нас будет в два раза больше траффика»
Возможность подготовить кодовую базу
к масштабированию
Все изменения принимаются планово, имеется возможность хорошо протестировать
Бывает редко
Плановый рост посещаемости
Специфика принятия решений
Слайд 8Как растут нагрузки
Рост нагрузки в 2 раза за 30 минут
Внезапные
всплески траффика
Слайд 9Как растут нагрузки
Внезапные всплески траффика
Рост нагрузки в 2 раза за
30 минут
Слайд 10Как растут нагрузки
Очень резкий всплеск посещаемости – от роста нагрузки
до предела возможностей - минуты
Приток траффика не постоянный и не
дает возможности заложить большой срок разработки
При такой скорости изменений велик риск допустить ошибку
Внезапные всплески траффика
Специфика принятия решений
Слайд 11Масштабирование – немного ликбеза
Слайд 12Масштабирование – немного ликбеза
Вертикальное масштабирование
Увеличиваем возможности системы, увеличивая аппаратные характеристики
в пределах одного сервера:
Технически просто, но часто – не даст
многократный запас
Слайд 13Масштабирование – немного ликбеза
Горизонтальное масштабирование
Увеличиваем возможности системы, добавляя новые серверы
и балансируя нагрузку между ними
Позволяет неограниченно увеличивать ресурсы системы, но
требует вмешательства в архитектуру
Слайд 14Вертикальное масштабирование – гибридное облако
Большую часть времени проект работает на
основном «железе»
В облаках подготовлен сервер минимальной конфигурации
В случае пиковой нагрузки
или аварии сервер в облаках масштабируется, посетители переводятся на него
Слайд 15Гибридное облако – стандартный режим
Слайд 16Гибридное облако – увеличение посещаемости
Слайд 17Гибридное облако – масштабирование облака
Слайд 18Гибридное облако – перевод пользователей (смена DNS)
Слайд 19Гибридное облако – работа под нагрузкой
Слайд 20Гибридное облако – снижение нагрузки
Слайд 21Гибридное облако – перевод пользователей обратно
Слайд 22Гибридное облако – снижение конфигурации облака
Слайд 23Вертикальное масштабирование - проблемы
Рано или поздно – ресурсы будут исчерпаны,
а масштабировать дальше уже не получится
При этом, чаще всего, рост
нагрузки не пропорционален росту посещаемости
Слайд 24Вертикальное масштабирование - проблемы
При этом сайт становится недоступным для всех
пользователей
(не только для той части что превысила возможности системы)
Слайд 25Горизонтальное масштабирование – что масштабируется
Нагрузка на веб-приложение – CPU
Производительность базы
данных – CPU/диски
Объем статических данных – место на диске
Чаще всего:
Слайд 27Горизонтальное масштабирование
веб-приложения
Сессии
Синхронность обновлений кода
Контроль ошибок
Главные проблемы
Слайд 28Горизонтальное масштабирование
веб-приложения
Единое место хранения сессий - проблемы
Если один серверов пула
«потеряет» центральное хранилище сессий и будет работать сам по себе
– проверяющий (или мониторинг) может не обнаружить проблему, а последовательность действий пользователя будет обрываться
Слайд 29Горизонтальное масштабирование
веб-приложения
Единое место хранения сессий
Слайд 30Горизонтальное масштабирование
веб-приложения
Единое место хранения сессий - проблемы
Слайд 31Горизонтальное масштабирование
веб-приложения
Синхронизация обновлений кода - проблемы
Если один серверов пула не
получит новую версию кода – проверяющий (или мониторинг) может не
обнаружить проблему, пользователь может получить старую версию сайта, а код может повредить всю систему в целом, работая со старыми схемами БД
Слайд 32Горизонтальное масштабирование
веб-приложения
Синхронизация обновлений кода
Слайд 33Горизонтальное масштабирование
веб-приложения
Синхронизация обновлений кода - проблемы
Слайд 34Горизонтальное масштабирование
веб-приложения
Ошибки в веб-приложении - проблемы
Если один серверов в результате
ошибки конфигурации (кончилось место, неправильно настроен софт)/самого приложения (PHP –
ошибки apc/eaccelerator, падения пула бэкэнда) приложение на одном из бэкэндов упало – мониторинг может не обнаружить проблемы
Слайд 35Горизонтальное масштабирование
веб-приложения
Ошибки в веб-приложении - проблемы
Слайд 36Горизонтальное масштабирование
веб-приложения
Ошибки связанные с масштабированием веб-приложения
решения
Система мониторинга должна внешне проверять
каждый из узлов пула веб-серверов в отдельности
Каждая такая проверка должна
включать проверку существования сессии и возможность выполнения критичных для сайта пользовательских действий
Необходим мониторинг журналов ошибок на каждом сервере с оповещениями о всплесках ошибок на каком-либо из них
Слайд 37Горизонтальное масштабирование
веб-приложения
Ошибки связанные с масштабирование веб-приложения
решения – индивидуальный мониторинг
Слайд 38Горизонтальное масштабирование
веб-приложения
Ошибки связанные с масштабирование веб-приложения
решения – сбор количества 5xx
ошибок
Слайд 39Горизонтальное масштабирование
Базы данных
Ошибки связанные с репликацией - целостность репликации
Ошибки связанные
с репликацией - время синхронизации данных
Ошибки связанные с шардингом -
распределение данных
Слайд 40Горизонтальное масштабирование
Базы данных
Целостность репликации данных - проблемы
При балансировке чтения базы
репликацией нормальный статус репликации еще не означает синхронизации всех данных
и рабочей репликации
Слайд 41Горизонтальное масштабирование
Базы данных
Целостность репликации данных - проблемы
Слайд 42Горизонтальное масштабирование
Базы данных
Целостность репликации данных - проблемы
Слайд 43Горизонтальное масштабирование
Базы данных
Целостность репликации данных - проблемы
Слайд 44Горизонтальное масштабирование
Базы данных
Целостность репликации данных - проблемы
Слайд 45Горизонтальное масштабирование
Базы данных
Время синхронизации данных - проблемы
Запись созданная в мастер-БД
не моментально окажется в БД, принимающей репликацию. Если пользователь пишет
в мастер, а затем сразу читает из слейва – есть шанс, что записи там не будет
Слайд 46Горизонтальное масштабирование
Базы данных
Время синхронизации данных - проблемы
Слайд 47Горизонтальное масштабирование
Базы данных
Время синхронизации данных - проблемы
Слайд 48Горизонтальное масштабирование
Базы данных
Время синхронизации данных - проблемы
Слайд 49Горизонтальное масштабирование
Базы данных
Время синхронизации данных - проблемы
Слайд 50Горизонтальное масштабирование
Базы данных
Следует следить не только за работой репликации но
и за идентичностью данных на серверах БД(контрольные суммы критических таблиц)
Не
следует пытаться читать только что записанные данные, это должно быть некое неизменное в короткое время ядро (например каталог товаров)
Если необходимо масштабировать пользовательский контент, который часто обновляется – лучше использовать шардинг
Ошибки связанные с репликацией
решения
Слайд 51Горизонтальное масштабирование
Базы данных
Ошибки связанные с шардингом - проблемы
В случае, если
один из shard-серверов упадет или начнет медленнее отвечать, система мониторинга
может не отследить такую аварию – запросы могут попадать на остальные серверы
Неправильно выбранная архитектура распределения данных может привести к тому, что вся нагрузка ляжет только на один из серверов, а остальные будут простаивать
Слайд 52Горизонтальное масштабирование
Базы данных
Ошибки связанные с шардингом – медленный шард
Слайд 53Горизонтальное масштабирование
Базы данных
Ошибки связанные с шардингом – медленный шард
Слайд 54Горизонтальное масштабирование
Базы данных
Ошибки связанные с шардингом - решения
Индивидуальный мониторинг работы
каждого shard-сервера. Если серверы разделены по пользователям – создание тестового
пользователя для каждого shard-сервера.
Мониторинг ошибок приложения
Мониторинг нагрузки и количества данных на shard-серверах
Слайд 55Горизонтальное масштабирование
другие вопросы
Синхронизация статических данных/распределенные файловые системы
Контроль целостности данных при
failover-е.
Централизация важных функций на одном из серверов
Проблемы связанные с масштабированием
кэширования
Слайд 56Выводы
Основной способ защитится – грамотно настроенный мониторинг
Фатальность ошибки обратно пропорционально
скорости реакции
Один раз настроить – нельзя, нужна постоянная диагностика
Слайд 57Евгений Потапов
http://itsumma.ru
eapotapov@itsumma.ru
http://facebook.com/eapotapov
Типичные ошибки при построении масштабирования и отказоустойчивости и их
решения