1. Масштабирование баз данных
1.1. scale up (более мощное железо)
1.1.1. Больше CPU
1.1.1.1. Ограниченная масштабируемость большинства СУБД
1.1.1.1.1. Особенно mysql
1.1.2. Больше памяти
1.1.2.1. Больше кэшей
1.2. Вертикальное масштабирование
1.2.1. Выделение ролей для серверов (разные таблицы на разных серверах)
1.2.1.1. Проблемы
1.2.1.1.1. Всё равно упираемся в пределы физической машины
1.2.1.1.2. До свиданья джойны...
1.2.2. Partitioning (разные куски таблицы / разные таблицы на разных дисках)
1.2.2.1. Можно физически хранить на разных storage...
1.2.2.2. Минусы
1.2.2.2.1. Узким местом всё равно становится CPU / масштабируемость СУБД
1.3. Репликация
1.3.1. Виды
1.3.1.1. master / slave
1.3.1.2. Синхронная / асинхронная
1.3.2. Проблемы
1.3.2.1. Выигрыш нелинейный
1.3.2.2. Большой overhead на синхронизацию
1.3.2.2.1. иерархия серверов
1.3.2.3. Неконсистентные данные
1.3.2.4. Упираемся в запись
1.3.2.4.1. master / master
2. Масштибирование web-серверов
2.1. Ловушки / проблемы
2.1.1. share nothing
2.1.1.1. примеры: общие данные на NFS: сессии, код
2.1.1.2. минимум доступа к разделяемым ресурсам
2.1.1.3. share accuretely
2.1.2. общий кэш
2.1.2.1. больше cache hits
2.2. Frontend / акселлератор
2.2.1. Двухуровневая система: frontend / backend
2.2.1.1. принципиально разные задачи у frontend и backend
2.2.1.1.1. Разве повар вместо официанта принимает заказ?
2.2.2. Преимущества
2.2.2.1. Медленные клиенты (spoon feeding)
2.2.2.2. Большое количество соединений (> 100000)
2.2.2.3. Раздача статики
2.2.2.4. Кэширование динамики
2.2.2.5. Шифрование
2.2.2.6. Сжатие трафика
2.2.2.7. Аутентификация
2.2.2.8. Интеллектуальная обработка / доп. логика
2.2.2.8.1. nginx-perl
2.2.3. Примеры
2.2.3.1. nginx
2.2.3.2. haproxy
2.2.3.3. lighttpd
2.3. DNS-LB
2.4. IP-LB
2.5. http-переадресация
3. Enterprise vs WebSphere
3.1. Бесплатный софт
3.1.1. Огромное количество машин, накладные расходы
3.2. Открытый софт
3.2.1. manageable
3.2.2. нет полностью готовых решений
3.2.2.1. всё собирается как из конструктора
3.3. Относительно дешёвое железо
4. Основные проблемы и вызовы
4.1. Большая нагрузка (тысячи и миллионы хитов)
4.2. Высокие ставки
4.2.1. Потребность в быстрой разработке
4.2.1.1. Высококонкурентное окружение
4.2.2. Высокие риски
4.2.2.1. резкий рост нагрузок
4.2.2.2. Высокая надёжность
4.2.2.3. DDoS
4.2.3. Большая ответственность на разработчике
4.3. Зоопарк технологий и сервисов
4.4. Большая команда
4.5. Хороший проект
4.5.1. Технический менеджмент
4.5.2. Системное администрирование
4.5.3. Поддержка
4.5.4. Разработка
4.6. Ловушки
4.6.1. не масштабируемая архитуктура
4.6.1.1. высокая степень связности
4.6.1.1.1. данные
4.6.1.1.2. компоненты
4.6.2. "полурешения"
4.6.2.1. накапливаемые риски
4.6.3. "горе от ума"
4.6.3.1. теоретики vs практики
5. Виды кластеров
5.1. HP
5.1.1. High Performance
5.2. HA
5.2.1. High Availability
5.3. HL
5.3.1. High Load
6. Асинхронная обработка
6.1. Очереди
6.1.1. Почта
6.1.1.1. Двойная асинхронность
6.2. Всё что можно сделать потом -- делаем потом
7. Как будем повышать пропускную способность?
7.1. P = C / t
7.1.1. Пропускная способность в единицу времени = кол-во одновременно обрабатываемых запросов / время обработки одного запроса
7.2. Уменьшение времени отклика
7.2.1. Оптимизация
7.2.1.1. premature optimization
7.2.1.1.1. 80% опт. алгоритма
7.2.1.1.2. 15% опт. кода
7.2.1.1.3. 5% отп. машинного кода
7.2.1.2. замеряйте прежде чем менять!
7.2.2. Кэширование
7.2.3. Тюнинг ОС / СУБД / инфраструктурного ПО
7.2.3.1. Тюнинг ОС
7.2.3.2. Тюнинг СУБД
7.2.3.2.1. Сложно
7.2.3.3. Тюнинг ФС
7.2.3.3.1. xfs
7.3. Увеличение количества одновременно обрабатываемых запросов
7.3.1. Масштабирование
7.3.1.1. График: затраты / профит
7.3.1.2. Почти никогда не бывает полностью линейным
7.3.1.2.1. Overhead
7.3.1.3. web-серверов
7.3.1.4. баз-данных
7.3.1.5. Способы масштабирования
7.3.1.5.1. scale up (вертикальное)
7.3.1.5.2. scale out (горизонтальное)
8. Уровни зрелости высоконагруженного проекта
8.1. Рост проекта
8.1.1. Один сервер
8.1.2. Несколько серверов
8.1.3. Много серверов (сотни, тысячи)
8.1.4. Много ДЦ
8.2. Переход между уровнями -- обычно кризис
8.3. Ключевое значение -- масштабируемая архитектура
8.4. Грамотное многоуровневое проектирование
8.4.1. Масштабируемость и производительность должна учитываться на всех уровнях
8.4.1.1. Софт
8.4.1.2. Библиотеки
8.4.1.3. СУБД
8.4.1.4. ФС
8.4.1.5. hardware: диски, память, сеть, CPU