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

© Copyright 2014 Andrey Smirnov

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

Андрей Смирнов, 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

18:00


Приложение


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

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

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

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

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

18:00


Архитектура


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

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

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

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

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


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


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

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

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

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

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

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

18:00


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


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

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

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

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

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

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

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

18:00


Данные 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% доступность


ЭкономикаЗа

траты

1

100

10000

Нагрузка

10k 100k 1M 10M 100M

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


ЭкономикаЗа

траты

0

15000

30000

45000

60000

Нагрузка

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

• [email protected]

• Skype: smirnov.andrey

http://goo.gl/bbWKaZ

mailto:[email protected]

Education

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