Вебинар "Разработка высоконагруженных и надежных...

Разработка высоконагруженных и надежных систем

Андрей Смирнов, 2014

Введение

Вебинар №1

Обо мне

О серии вебинаров

План вебинаров1. Введение (этот вебинар)

2. Данные I. От основ хранения до РСУБД

3. Данные II. Шардинг, key-value и распределенные хранилища

4. Приложение

5. Архитектура веб-систем

6. Взаимодействие с клиентским приложением. Тестирование

7. Отказоустойчивость, мониторинг и выкатывание

Данные I + II

Данные I. От основ хранения до РСУБД

• Базовые принципы хранения данных. Хранение на диске и в памяти.

• ACID. Реляционные БД.

• Проектирование схемы реальной БД в различных моделях данных.

• Индексы, денормализация, использование разных типов хранилищ для разных данных.

• Партиционирование. Репликация.

• Полнотекстовый поиск. 20 января 201518:00

Данные II. Шардинг, key-value и распределенные хранилища• Масштабирование: шардинг в реляционных и key-

value хранилищах.

• Key-value хранилища.

• CAP-теорема.

• Распределенные хранилища. Консистентность.

• Кешированные данных: инвалидация кеша, тегирование кешей. 21 января 2015

Приложение

Приложение• Структура серверного и клиентского приложения, анализ узких и проблемных мест.

• Сетевой ввод-вывод: синхронный, асинхронный. Реактор, обслуживание большого числа соединений (C10K, C100K).

• Многозадачность: процессы, нити, кооперативная многозадачность, комбинации.

• Краткий обзор фреймворков и языков программирования: Ruby, Python, Go, Java, C#, Erlang, JavaScript.

• Безопасность. Типичные уязвимости. Пользователи и пароли. CSRF. 3 февраля 2015

Архитектура

Архитектура веб-систем• Архитектура системы: монолитная, сервис-ориентированная (SOA).

• Непосредственный вызов (RPC), очереди, персистентные очереди, очереди фоновых задач.

• Шины, широковещательные каналы.

• Примеры и разбор реальных архитектур веб-приложений.

5 февраля 2015 18:00

Клиент,Тестирование

Взаимодействие с клиентским приложением. Тестирование

• Синхронизация данных, работа в offline, информирование пользователя.

• Сетевое взаимодействие с сервером. Ошибки API. Клиент как веб-сервис. Алгоритмы повтора запроса.

• Нагрузочное и системное тестирование.

• Почему unit-тестирование бесполезно.

• Непрерывное тестирование, постоянное выкатывание. 10 февраля 2015

Эксплуатация

Отказоустойчивость, мониторинг и выкатывание

• Оценка нагрузки и планирование ресурсов.

• Резервное копирование, репликация. Master-Slave. Hot-Spare.

• Несколько дата-центров, схемы Active-Failover, Master-Slave, Active-Active.

• Обеспечение консистентности. Протоколы голосования.

• Выбор между “облаком” и железом.

• Выкатывание проекта, управление конфигурацией. Логирование. Мониторинг. 17 февраля 2015

Данные I + II

Приложение

Клиент,Тестирование

Архитектура

Эксплуатация

Бронируйте места!

• Сегодня каждый вебинар стоит 4 000 руб. (5 000 для юрлиц)

• Все 6 вебинаров: 16 000 руб. (скидка 33%) (21 000 руб. для юрлиц)

• Цена будет увеличиваться ближе к дате начала вебинаров!

Нагрузка

• Что такое высокая нагрузка?

• Что такое нагрузка?

Примеры

• Google: 70 000 req/s (поиск)

• Twitter: 700 tweet/s (новые твиты), 24 000 req/s (поиск)

• Facebook: 3000 msg/s

• Yandex: 2000 req/s (поиск)

Еще примеры

• Fastly (CDN): 500 000 req/s, 77 Gbit/s

• Akamai (CDN): 12 000 000 req/s (2010)

И еще

• Google Public DNS: 1 504 629 req/s 47 450 000 000 000 (47 триллионов) запросов в год лог запросов (100 байт на запрос) занял бы 4315 Тб

Нагрузка

• Запросы, кол-во запросов в секунду

• Задержка, время обработки запроса

• Конкурентность, одновременные запросы

• Отказы

Производительность

• Нагрузка отнесенная к используемым ресурсам и времени выполнения

Надежность

• Доступность - процент время, когда система работоспособна с точки зрения пользователя

• Почему надежность важна?

• Надежность vs. ошибки

• Надежность с точки зрения пользователя

Примеры

• Amazon: выручка за 2013: $74.5 * 109, $2362/sec

Google Apps

• Доступность: кол-во ошибок > 5% в течение минуты

• 99.9% доступности в месяц (43 минуты downtime)

Доступность• 99% - 89 часов недоступности в год

• 99.9% - 9 часов

• 99.99% - 53 минуты

• 99.999% - 5 минут

• 99.9999% - 30 секунд

Amazon S3

• 99.999999999% долговечность

• 99.99% доступность

ЭкономикаЗа

траты

Нагрузка

10k 100k 1M 10M 100M

Проект А Проект Б

ЭкономикаЗа

траты

Нагрузка

10k 100k 1M 10M 100M

Проект А Проект Б

Ресурсы• Процессор, память, диск, …

• Сеть

• Место

• Электропитание

• Деньги

Ограниченность

• Ресурсы одной машины ограничены

• Ресурсы одной стойки ограничены

• Ресурсы одного ДЦ ограничены

• Финансовый ресурс ограничен

Ресурсы одной машины

• PostgreSQL: 350 000 reads/s, 14 000 writes/s

• HTTP-сервер: 1000+ req/s (1 core)

Высокая нагрузка

• Нагрузка, подбирающаяся к пределу доступных ресурсов

Надежность компонентов• Надежность системы = MIN(надежность компонентов)

• Большое число компонентов - больше вероятность индивидуального сбоя

• Любой компонент всегда может дать сбой

• Архитектура, нацеленная на надежность, не всегда надежна на практике

Серебряная пуля

• Пример: RabbitMQ - будем использовать его, он масштабируется, у него High Availability

• А Вы умеете администрировать Erlang?

• А как масштабируется mnesia?

• Нет серебряной пули

Простота и надежность• Понятные (простые) решения “надежнее” сложных

• Проверенные решения: мы знаем сильные и слабые стороны

• Простота - проверка надежности проще

• Простота - понятнее действия в случае отказа

• Отказоустойчивые системы сложные

Отказы компонентов

• Какие отказы самые частые?

• Что делать в случае отказа?

• Дублирование

• Совместные отказы

Если у меня…

• 1 сервер, и он дает сбой 1 раз в год

• 365 таких серверов, то каждый день один из них дает сбой

Если у меня…

• Две копии компонента, каждый с надежностью 99%

• и они дают сбои независимо

• надежность 99.99%

Независимость сбоев• Общая инфраструктура (сеть, питание, охлаждение, …)

• Одинаковое “железо”

• Одинаковое ПО (одинаковые баги)

• Одинаковое время

• …

Сложность и надежность

• Отказоустойчивые решения сложные

• Сложность может быть причиной отказов

• Сложность должна быть понятной

Переключение Master-Slave

Масштабирование

Виды масштабирования

• Вертикальное масштабирование (увеличение производительности узла)

• Горизонтальное масштабирование (увеличение количества узлов)

Вертикальное масштабирование

• Доступные ресурсы одного сервера растут каждый год

• Стоимость топового сервера меньше сложности горизонтального масштабирования

• Ограничение производительности одного сервера

• Оптимизация кода

Горизонтальное масштабирование

• Если 1 сервис может выполнить 100 операций/секунду

• То N сервисов могут выполнить N*100 операций/секунду

• Бесконечное масштабирование!

Очередь. Worker

Очередь. Масштабирование?

Модель масштабирования и отказоустойчивости

• Пусть есть сервис, который умеет выполнять две операции:

• GET(key) ⇛ value

• PUT(key, value)

Две копии сервиса

Две копии сервиса• Масштабирование

• по чтению

• по записи (?)

• Консистентность:

• передача состояния, синхронизация

• синхронно/асинхронно

Отказ одного сервиса

• Клиент замечает отказ сервиса

• Переключение на “живой”экземпляр

• Синхронизация при восстановлении

Отказ сети

Отказ сети• Отказ сети междуэкземплярами сервиса

• отказ свитча, соединяющего стойки

• Связность с клиентами не нарушена

• Неконсистентность по данным

• Что делать при восстановлении связи?

Работа из двух ДЦ

• Канал связи между ДЦ:

• задержки

• ненадежность

• ограниченная пропускная способность

Изменения

Изменения• Рефакторинг

• Изменение архитектуры

• Смена языка программирования

• Внедрение CI, автоматизация процессов

• Переход к другой базе данных

• Изменение структуры команд

• Изменение процесса эксплуатации

Распространение изменений

Принятие решений

• Один человек принимает решение и двигает вперед

• Коллектив принимает решение и исполняет его

• Решения навязывается “сверху” и применяется

Мотивация

• Какие проблемы есть сегодня? (Какие проблемы могут появиться завтра?)

• Стоимость изменения

• Какую пользу принесет изменение?

Измеряемый результат• Метрика, показывающая результат изменений

• Зависимость метрики от прочих факторов

• Ожидаемое изменение метрики

• Примеры:

• кол-во релизов в год

• кол-во багов

• доступность системы

Авторитет• Имеет влияние на коллектив

• Заслужил уважение (опыт, профессионализм)

• Способен донести мысль на уровне слушающих:

• разработчики

• менеджмент

Кривая изменений

текущее состояние

новое состояние

время

производительность

сопротивление

хаос

принятие,интеграция

Virginia Satir’s Change Curve

Проектирование проекта, подобного TwitterЛента твитов, following, @упоминания, поиск

“twtr”: данные• Пользователь: account (login/password) + profile

(@username/full name)

• Твиты: 140 символов, автор, дата

• Follow: каждый пользователь followит произвольное количество других пользователей

• Лента: мои твиты + твиты тех, за кем я слежу, + упоминания

“twtr”: запросы

• пользователь: получить профиль, регистрация, авторизация, удаление

• лента: отправить твит, получить мою ленту (N записей), получить мою ленту с k-ой записи, получить новые элементы (от j-ой записи)

• поиск: по произвольным словам

Какая будет схема базы данных? Какие запросы? Какие из них самые сложные? Какая архитектура? Какой язык программирования? Как тестировать? Как масштабировать? Как обеспечить отказоустойчивость? Какой будет мониторинг? …

Резюме

• Высокая нагрузка - это нагрузка, подбирающаяся к пределу доступных ресурсов

• Доступность - процент времени, когда система работает с точки зрения пользователя

• Проект, масштабирующийся экономически эффективно, выигрывает

Резюме

• Ответ на растущую нагрузку - масштабирование (вертикальное или горизонтальное)

• Отказоустойчивость через сложные или простые, но понятные решения

• Внедрение изменений: мотивация, метрика, авторитет, готовность к сопротивлению и хаосу

Спасибо!• Небольшой тест: http://goo.gl/bbWKaZ

• Жду ваших комментариев:

• @smira

• me@smira.ru

• Skype: smirnov.andrey

Вебинар "Разработка высоконагруженных и надежных...

Education

Мониторинг в высоконагруженных (и не только) проектах: сравнительный анализ существующих решений

CodeFest 2010. Молчанов Д. — Разработка высоконагруженных систем

последний вебинар

вебинар панюкова

Direct вебинар

MySQL для высоконагруженных проектов

Вебинар "Мотивация"

Основы построения масштабируемых высоконагруженных веб-проектов Семинар (8 часов)

вебинар инфографика

SECON'2016. Тюменцев Евгений, Разработка надежных параллельных, распределенных приложений: быстро и дешево

вебинар нпс

Инструменты высоконагруженных проектов - кэширование и очереди, Вячеслав Москаленко (Ленвендо)

Разработка надежных параллельных, распределенных приложений: быстро и дешево

Сравнение решений по балансировке высоконагруженных систем / Евгений Пивень (IPONWEB)

край вебинар

Zappos вебинар

2015-12-06 Евгений Тюменцев - Разработка надежных параллельных, распределенных приложений: быстро и дешево

Практический вебинар «Простой старт рассылок». Вебинар WebPromoExperts #109

вводный вебинар

вебинар 23.01