Цифровой двойник прикладного проекта в K8s

Жизнь в облаках и без

Программный комитет ещё не принял решения по этому докладу

Целевая аудитория

DevOps-инженеры, архитекторы cloud-решений. Разработчики, работающие с K8s и микросервисами, руководители оптимизирующие потребление

Тезисы

Цифровой двойник прикладного проекта в K8s

1. Представление докладчиков

2. С чего все началось
2.1 Попытка создать "предиктивный автоскейлер" для проекта в K8s
2.2 Причины неудачи (Стоимость сбора и хранения информации превышает ее ценность)
2.3 Разработка on-premise автоскейлера
2.4 Где и как проверять политики автоскейлинга, почему не подойдет стенд нагрузочного тестирования

3. Цифровой двойник проекта в K8s
3.1 Основная проблема - как учитывать постоянные изменения в проекте
3.2 Что у нас есть в наличии
3.3 Цифровая архитектура (архитектура как код)
3.4 Телеметрия K8s, Istio, метрики утилизации, метрики запросов, трейсы
3.5 Основные элементы цифрового двойника (компоненты, внешние ресурсы, связи, описание входных нагрузок)

4. Модель Pod-a
4.1 Исследования отдельного компонента с помощью локального нагрузочного тестирования
4.2 Требования к заглушкам
4.3 Обработка результатов исследования: апроксимация полиномами
4.4 Основные типы компонентов
4.5 Формат хранения модели Pod-a
4.6 Версионирование модели Pod-a

5. Модель внешнего ресурса
5.1 Данные для внешнего ресурса
5.2 Формат хранения модели внешнего ресурса
5.3 Особенности использования асинхронных ресурсов в модели

6. Цифровая архитектура
6.1 Описание всех компонентов системы
6.2 Описание связей между компонентами
6.3 Формат для обработки в модели
6.4 Версионирование архитектуры

7. Описание нагрузки
7.1 tps и трафик

8. Собираем все вместе
8.1 Алгоритм работы симулятора
8.2 Нагрузочное моделирование вместо нагрузочного тестирования
8.3 Что можно увидеть в симуляторе
8.3.1 Отклонение во времени отклика
8.3.2 Увеличение входного/выходного трафика
8.3.3 Изменение трафика при обращении к внешним ресурсамbelet)
8.4 Наша модель
8.4.1 Сравнение результатов разных систем
8.4.2 Точность попадания
8.4.3 Перспективы развития

9. Заключение

Илья Семёнов

Сбер

Работает в Сбере 6 лет в разных ролях: разработчик, product owner, архитектор.
Ключевые проекты:
* высоконагруженные backend’ы;
* интеграционные решения;
* etl-процессы;
* AI-инициативы;
* архитектурные решения.

Sber certified architect.

Алексей Игнатов

Приглашенный эксперт

29 лет опыта разработки ПО в различных ролях: developer, product owner, manager, solution architect, project manager.

Ключевые области проектов:
* высоконагруженные бэкенды;
* высоконагруженные интеграционные решения;
* распределенные платформенные решения на базе облачных технологий;
* CI/CD-решения для облачных сред.