Это старая версия документа!

Облачные и периферийные вычисления

Раздел о развитии вычислительных архитектур: от облачных моделей (IaaS/PaaS/SaaS) и частных облаков до распределённых решений на периферии (edge) и у устройств. Рассматриваются состав современного ИТ-стека, варианты размещения нагрузки и ключевые тенденции.

Архитектуры и сервисы

Периферия и тенденции

Куда размещать нагрузку: дерево решений

flowchart TD classDef big font-size:26px,stroke-width:1.2px,padding:10px; W["Рабочая нагрузка"]:::big --> L{Нужна задержка ≤ 10–20 мс
или офлайн-устойчивость?}:::big L -->|Да| EDGE["Edge/он-прем на площадке"]:::big L -->|Нет| REG{Есть требования к размещению
и суверенитету данных?}:::big REG -->|Да| PRIVATE["Частное облако / региональный ЦОД"]:::big REG -->|Нет| ELAS{Нужна высокая эластичность
и управляемые сервисы?}:::big ELAS -->|Да| PUBLIC["Публичное облако"]:::big ELAS -->|Нет| COLO["Колокация / собственный ЦОД"]:::big %% типовые гибридные паттерны (пунктир) EDGE -.-> PUBLIC PRIVATE -.-> PUBLIC COLO -.-> PUBLIC

Опорная таблица: архитектурные варианты и применимость

Архитектурный вариант	Основные случаи применения	Типовые риски	Результаты (артефакты)
Публичное облако (IaaS/PaaS/SaaS)	Быстрый запуск, эластичные и переменные нагрузки, глобальный охват, управляемые сервисы	Стоимость трафика на выход (egress), зависимость от провайдера, требования к размещению данных	Архитектурные паттерны, landing zone, IaC/политики, соглашения по SLO/SLA
Частное облако (on-prem)	Контроль над данными и конфигурацией, предсказуемая нагрузка, требования соответствия	CAPEX и цикл обновления, сложность эксплуатации	Техническая архитектура, каталог сервисов, процессы эксплуатации и обновлений
Гибридная модель	Стабильное ядро on-prem + эластичные пики/DR в облаке, интеграция с существующими системами	Сложность сетевой и IAM-интеграции, единая наблюдаемость	Схема связности, единая идентификация и политики, план миграции/обмена данными
Мультиоблако	Избежание привязки к одному поставщику, нормативные ограничения по регионам, спецсервисы разных вендоров	Рост сложности, различия сервисов и API, согласование SLO	Абстракции/платформа оркестрации, матрица соответствия сервисов, единые практики FinOps
Edge-вычисления (локальные узлы)	Низкая задержка, офлайн-устойчивость, предварительная фильтрация/агрегация данных IoT, локальная аналитика/ИИ	Обслуживание распределённых узлов, физическая безопасность, обновления ПО	Стандартизованный edge-образ, конвейер обновлений, политика кэширования/ретрансляции
Вычисления на устройстве	Мгновенный отклик, приватность данных, работа без сети	Ограничения по ресурсам, управление версиями моделей/ПО	Модель обновлений, телеметрия, стратегии деградации функционала

Ключевые показатели для управления

Задержка (p50/p95) и джиттер по критическим транзакциям.
Надёжность/доступность (SLA/SLO) по доменам отказа и зонам доступности.
Стоимость: $/vCPU-час, $/GB-месяц, $/GB egress; совокупная стоимость по сценарию (TCO).
Пропускная способность/трафик и модели передачи (потоки/батчи).
Размещение данных и соответствие (регион, требования отрасли).
Эластичность и время масштабирования (auto-/right-sizing, холодный/тёплый старт).
Наблюдаемость: полнота телеметрии, трассировка, покрытие алертами, MTTR.

Контрольные вопросы

Определены требования к задержке/пропускной способности и к размещению данных по регионам?
Рассчитана совокупная стоимость по сценариям (включая egress, хранение, резервирование, поддержку)?
Выбран целевой уровень абстракции: IaaS/PaaS/SaaS; определены границы ответственности?
Описаны паттерны интеграции: сеть, идентификация/доступы, журналирование, наблюдаемость?
Разработана стратегия для периферии: стандарт узла, обновления, защита, сбор телеметрии?
Предусмотрены механизмы межоблачной/гибридной переносимости (CI/CD, образ базовой платформы, политика данных)?